Hi Semih, Thanks a lot. Is one of the options going to reduce the memory overhead? I can't reproduce the issue with libumem's debug as I run out of memory long before the point in the program when the problem happens.
Anyway, thanks a lot for this information. On Thu, Mar 11, 2010 at 5:59 PM, Semih Cemiloglu <semih.cemilo...@nec.com.au > wrote: > Please try undocumented libumem settings: > > > > export UMEM_DEBUG=audit,contents,guards,verbose,firewall=1 > > export UMEM_LOGGING=transaction,fail > > export UMEM_OPTIONS=backend=mmap > > > > For details see: > > http://blogs.sun.com/peteh/entry/hidden_features_of_libumem_firewalls > > > > Kind regards > > Semih Cemiloglu > > > > > > > > *From:* dtrace-discuss-boun...@opensolaris.org [mailto: > dtrace-discuss-boun...@opensolaris.org] *On Behalf Of *Pierre-Olivier > Gaillard > *Sent:* Friday, 12 March 2010 2:04 AM > *To:* dtrace-discuss@opensolaris.org > *Subject:* [dtrace-discuss] Replacing libumem's debug with dtrace? > > > > 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 > - wait for the crash > - search in the log for areas containing the pointers involved in the > crash > > This seems pretty daunting and I wonder if I could not reduce libumem > memory usage instead. I don't mind running the program a couple times. > Are there ways to use dtrace that would allow me to disable the libumem > options that use the most memory? > > Thanks for your help, > >
_______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
