Another option is to force a segfault, ie assign to the area when the pointer is null. The values of the various CPU registers, especially the program counter, can then (in combination with a disasembler) be used to determine the location of the crash and hence, the condition at the time of the test.
I am trying to use DUMA to find the problem and am getting the following error when I try to link to the DUMA library:
# LD_PRELOAD=/lib/libduma.a /bin/snmpd & # ERROR: ld.so: object '/lib/libduma.a' from LD_PRELOAD cannot be preloaded: ignored.
What can cause this error when using LD_PRELOAD?
Only an executable object (.e_type is ET_DYN or ET_EXEC) can be pre-loaded. An archive library (*.a) that contains ET_REL files cannot be pre-loaded.
It amazes me that in all this time you never managed to answer a simple question: is the crash *in* malloc, or is it in your own code?
You are continuing to debug this as if there is malloc corruption, and this will prove futile if the crash is (as I suspect) in your own code instead.
You can only preload shared libraries.
Besides, reading man page for libduma, I see that it uses *exact* same strategy as efence: a guard page after every allocation.
So, once you manage to build a shared libduma.so, and preload it; it will most likely fail just like efence did, because the overhead of guard pages is too great for majority of real-world (non-toy) applications.
Cheers,
Have something to add? Share your thoughts — no account required.
Ask the community — no account required