----- Original Message ----- > Hello Dave, > > Several weeks ago there was a bugzilla report about crash-trace-command > which was caused by load_module structure change: > https://bugzilla.redhat.com/show_bug.cgi?id=1520825 > > We can solve the problem by updating crash-trace-cmd with the latest > crash-devel package. Right. I try my best to enforce that any changes made to defs.h do not affect previously compiled extension modules, and one way is to add any new data structure members to the end of the export structures. And I did add the new member to the end of the load_module structure -- but I was not aware that the trace.c module walked through an array of the (modified) load_module data structures that are linked to the global symbol_data_data structure. If I was aware of that at the time, I may have looked at doing it differently. > > And I'm wondering if there is a need for trace.c to have an error check > function for this kind of data structure change problems I thought about suggesting something like that at first, but I'm not sure how it could best be done. Perhaps by adding a "size" or "version" field to the data structure? But doing so would require yet another update. > or for crash to have some "extensions" test processes when new version > is released which can find these problems ealier. Perhaps, but it wouldn't be easy to implement. But again, 99% of the changes to defs.h should not affect extension modules. Although walking through arrays of (modified) exported structures is a problem, the example of "trace.c" walking through the load_module array is fairly rare. Thanks, Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
