----- 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