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
