Catching a hot potato
Marco Leise
Marco.Leise at gmx.de
Mon Oct 17 10:29:56 PDT 2011
Am 17.10.2011, 15:04 Uhr, schrieb Gor Gyolchanyan
<gor.f.gyolchanyan at 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?
More information about the Digitalmars-d
mailing list