Hi Michael, Yes I can look at the core dump and get a stack. That's why I wanted to purify, because it really looks like a situation where purify would show an FMR (Free Memory Read). The FMR would show me: current stack where the application read from free memory, stack that freed the block, stack that allocated it first. I thought libumem could replace purify: - cause the app to crash on first access to free memory (thanks to the guards?) - log the transaction that freed the block and its stack - log the transaction that allocated the block So I was hoping to get into mdb after the crash and retrieve the above information but libumem runs out of memory before the problem occurs. I suppose that libumem's debug features have a big memory overhead but I could not figure out what to disable to avoid running out of memory before I can reproduce my problem.
This is why I am considering dtrace as its overhead is easy to control. I think I'll start with adapting Chris Gerhard's blog entry: http://blogs.sun.com/chrisg/entry/usind_dtrace_to_find_double My crash stack is in a function that deallocates objects, so I suppose that even though we don't reach a double free we are probably calling the function twice. Thanks, On Thu, Mar 11, 2010 at 10:18 AM, Michael Schuster <michael.schus...@sun.com > wrote: > On 11.03.10 16:03, Pierre-Olivier Gaillard wrote: > >> Hi all, >> >> I have a program that crashes. From the stack I suspect it's trying to >> read >> free memory, probably because it's trying to clean some structures twice. >> Unfortunately I can't run the program under Purify as it's a 32 bit >> program >> and the purify runs out of 4GB. So I tried libumem as I think it should be >> able to find the error but libumem is running out of memory too. >> >> I am now trying to reduce the logging some more in the hope that the >> program will run: >> LD_PRELOAD="libumem.so.1" >> UMEM_LOGGING='transaction' >> UMEM_DEBUG='audit,guards,verbose' >> >> My other idea is to try to emulate the feature I want from these tools >> with >> dtrace and a huge log file: >> - trace all malloc and free, including stack, address and size >> > > I'd add a trace that is triggered when the program dumps core (elfcore, eg, > IIRC) and print ustack() here. > > - wait for the crash >> > > can you examine the core dump? > > Michael > -- > Michael Schuster http://blogs.sun.com/recursion > Recursion, n.: see 'Recursion' >
_______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
