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