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
