Am 17.10.2011, 15:04 Uhr, schrieb Gor Gyolchanyan
<gor.f.gyolchan...@gmail.com>:
I see. That's what i said: overwritten allocated memory is the
hardest-to-find bug.
But you've shown me, that i can't possibly track down the misbehaving
module by catching a sigsegv.
There has to be a way to make thrid-party DLL usage safe and rid the
user from dunno-why crashes.
The user at least needs to know which DLL to throw away.
Any ideas how it could be achieved?
You can't possibly track down the module? Not with a 100% hit rate of
course - you'd need to separate the memory for that. But if you want to go
with hacks, I think the following could work for you in most cases,
assuming you trust your main application to not send invalid data to your
modules:
Look at the stack in your sigsegv handler. Assign the return addresses to
locations inside the loaded libraries and print a list of all 'involved'
code modules at the point of the seg fault. If you only call into a single
library at a time (no callbacks) you only need to look at the top of the
stack. Parse /proc/self/smaps for example, to know what memory range
belongs to which module. Crazy enough?
