Hi Pierre These options will not reduce libumem's memory requirements since they still require guard pads for the allocated memory. I advise you to trim your test cases so that you can identify the defect with reduced memory requirements.
Your other options are watchmalloc, mtmalloc libraries and bcheck (bounds checking) script. Followings are notes from my engineering notebook, demonstrating their typical use. In practice however I found libumem is the easiest and most helpful tool to identify defects. Kind regards Semih Cemiloglu * Bounds checking via bcheck ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ $ bcheck <flags> <app> <parameters> Possible options for bheck: -leaks Check for memory leaks (default) -access Also perform access checking on the program -memuse Also perform memory use checking on program -all Combine all See man rtc_api dbx Usage: $ dbx -C bad_mem ... (dbx) check -all ... (dbx) cont Read from unallocated (rua): ... (dbx) dbxenv rtc_auto_suppress on (dbx) cont ... (dbx) dbxenv rtc_auto_continue on (dbx) dbxenv rtc_error_log_file_name /tmp/rtc.log (dbx) cont ... (dbx) quit * watchmalloc ~~~~~~~~~~~~~ Solaris provides an alternative memory library, called watchmalloc.so, which helps in detecting usage of previously freed memory. It also ensures that previously freed memory is not returned to the application for reuse. export LD_PRELOAD=watchmalloc.so.1 export MALLOC_DEBUG=WATCH export MALLOC_DEBUG=WATCH,RW,STOP The MALLOC_DEBUG environment variable determines whether watchmalloc checks for writes outside allocated memory, or reads outside allocated memory. Possible values: WATCH Checks memory for writes to past end of allocated memory, or writes of previously deallocated memory. This will cause a program execution slowdown on the order of ten to 100 times. RW Checks for reads past end of allocated memory, or reads of previously deallocated memory. This will cause a program execution slowdown on the order of 1000 times. See: man watchmalloc * mtmalloc ~~~~~~~~~~ The mtmalloc library has options that you can access through the programmatic mallocctl interface that control whether allocated and freed memory is overwritten with a pattern so that accesses to uninitialized data, or to data after it has been freed, are more apparent. See: man mtmalloc From: Pierre-Olivier Gaillard [mailto:pierreolivier.gaill...@gmail.com] Sent: Saturday, 13 March 2010 3:05 AM To: Semih Cemiloglu Cc: dtrace-discuss@opensolaris.org Subject: Re: [dtrace-discuss] Replacing libumem's debug with dtrace? 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<mailto: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> [mailto: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<mailto: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