Howdy,
I am attempting to isolate the location of a memory leak in a 4GL program,
and have hit a bit of a snag. When I LD_PRELOAD libumem and run the
application server, "::findleaks -fdv" reports numerous leaks:
CACHE LEAKED BUFCTL CALLER
0000000100b49068 15 0000000100ef2d50 fdcon+0x6c4
0000000100b50028 1 0000000100b72ac0 fdcon+0x6c4
0000000100b49068 2 0000000100cdfb30 fdcon+0x6c4
0000000100b44368 93 0000000100c98ee0 rnrq+0x204
0000000100b44028 1 0000000100c6e8f0 rnrq+0x204
0000000100b44028 17 0000000100c6ef10 rnrq+0x204
0000000100b3b6e8 1 0000000100b737e0 rnrq+0x204
0000000100b486a8 5 000000010119e030 umEdSetAttr+0x5fc
----------------------------------------------------------------------
Total 135 buffers, 37680 bytes
Since the application server opens a 4GL program each time it wants to
execute it (thank goodness for inefficiency), I thought I would use arg0
to open and rnrq+0x204 to isolate the program file that contains the
problematic code. When I attempt to run the following DTrace to enable the
probe at rnrq:204:
$ dtrace -p 4243 -n ''pid$target::rnrq:204 { ustack(); }''
dtrace: description ''pid$target::rnrq:204 '' matched 1 probe
The probe never fires. Does anyone see anything wrong with what I am doing?
Thanks for any insight,
- Ryan
--
UNIX Administrator
http://daemons.net/~matty
To display the full stack for any one of the leaks displayed by ::findleaks, use the bufctl address: eg. mdb> 0000000100ef2d50::bufctl_audit -- Renaud Matty wrote:> > Howdy, > > I am attempting to isolate the location of a memory leak in a 4GL > program, and have hit a bit of a snag. When I LD_PRELOAD libumem and run > the application server, "::findleaks -fdv" reports numerous leaks: > > CACHE LEAKED BUFCTL CALLER > 0000000100b49068 15 0000000100ef2d50 fdcon+0x6c4 > 0000000100b50028 1 0000000100b72ac0 fdcon+0x6c4 > 0000000100b49068 2 0000000100cdfb30 fdcon+0x6c4 > 0000000100b44368 93 0000000100c98ee0 rnrq+0x204 > 0000000100b44028 1 0000000100c6e8f0 rnrq+0x204 > 0000000100b44028 17 0000000100c6ef10 rnrq+0x204 > 0000000100b3b6e8 1 0000000100b737e0 rnrq+0x204 > 0000000100b486a8 5 000000010119e030 umEdSetAttr+0x5fc > ---------------------------------------------------------------------- > Total 135 buffers, 37680 bytes > > Since the application server opens a 4GL program each time it wants to > execute it (thank goodness for inefficiency), I thought I would use arg0 > to open and rnrq+0x204 to isolate the program file that contains the > problematic code. When I attempt to run the following DTrace to enable > the probe at rnrq:204: > > $ dtrace -p 4243 -n ''pid$target::rnrq:204 { ustack(); }'' > dtrace: description ''pid$target::rnrq:204 '' matched 1 probe > > The probe never fires. Does anyone see anything wrong with what I am doing? > > Thanks for any insight, > - Ryan > -- > UNIX Administrator > http://daemons.net/~matty > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
On Fri, 3 Mar 2006, Renaud Manus wrote:> To display the full stack for any one of the leaks displayed by ::findleaks, > use the bufctl address: > > eg. > mdb> 0000000100ef2d50::bufctl_auditHi Renaud / Eric, Thanks for the info. I can grab a stack backtrace with mdb, but that doesn''t really help me with locating the 4GL program(s) that are responsible for the leaks (each 4GL program is opened, read, and executed by the application server, so the top most stackframe resolves to a function in the application server, not a procedure call from a 4GL program). Since the application server performs an open() prior to executing the program, I thought I would be able to locate the offending 4GL program by enabling probes on open:entry and the offset reported by findleaks. Does anyone happen to know why the probe pid$target::rnrq:204 won''t fire? Thanks for the awesome replies, Thanks, - Ryan -- UNIX Administrator http://daemons.net/~matty> -- Renaud > > Matty wrote: >> >> Howdy, >> >> I am attempting to isolate the location of a memory leak in a 4GL program, >> and have hit a bit of a snag. When I LD_PRELOAD libumem and run the >> application server, "::findleaks -fdv" reports numerous leaks: >> >> CACHE LEAKED BUFCTL CALLER >> 0000000100b49068 15 0000000100ef2d50 fdcon+0x6c4 >> 0000000100b50028 1 0000000100b72ac0 fdcon+0x6c4 >> 0000000100b49068 2 0000000100cdfb30 fdcon+0x6c4 >> 0000000100b44368 93 0000000100c98ee0 rnrq+0x204 >> 0000000100b44028 1 0000000100c6e8f0 rnrq+0x204 >> 0000000100b44028 17 0000000100c6ef10 rnrq+0x204 >> 0000000100b3b6e8 1 0000000100b737e0 rnrq+0x204 >> 0000000100b486a8 5 000000010119e030 umEdSetAttr+0x5fc >> ---------------------------------------------------------------------- >> Total 135 buffers, 37680 bytes >> >> Since the application server opens a 4GL program each time it wants to >> execute it (thank goodness for inefficiency), I thought I would use arg0 to >> open and rnrq+0x204 to isolate the program file that contains the >> problematic code. When I attempt to run the following DTrace to enable the >> probe at rnrq:204: >> >> $ dtrace -p 4243 -n ''pid$target::rnrq:204 { ustack(); }'' >> dtrace: description ''pid$target::rnrq:204 '' matched 1 probe >> >> The probe never fires. Does anyone see anything wrong with what I am doing? >> >> Thanks for any insight, >> - Ryan >> -- >> UNIX Administrator >> http://daemons.net/~matty >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org
After a bit more analysis, it looks like findleaks wasn''t able to resolve the symbols after rnrq:> 0000000100c98ee0::bufctl_auditADDR BUFADDR TIMESTAMP THREAD CACHE LASTLOG CONTENTS 100c98ee0 100c97960 21ff452829f0c 1 100b44368 0 0 libumem.so.1`umem_cache_alloc+0x21c libumem.so.1`umem_alloc+0x5c libumem.so.1`malloc+0x40 0x10085f2a0 0x1004fd388 0x10044a93c 0x100517748 0x10055ca44 0x10055f588 rnrq+0x204 main+0x600 _start+0x17c Now that I know this, I can hand resolve 0x10085f2a0 to get the info I need. Thanks to the folks who provided the nifty dcmds. Thanks, - Ryan -- UNIX Administrator http://daemons.net/~matty On Fri, 3 Mar 2006, Matty wrote:> > On Fri, 3 Mar 2006, Renaud Manus wrote: > >> To display the full stack for any one of the leaks displayed by >> ::findleaks, use the bufctl address: >> >> eg. >> mdb> 0000000100ef2d50::bufctl_audit > > Hi Renaud / Eric, > > Thanks for the info. I can grab a stack backtrace with mdb, but that > doesn''t really help me with locating the 4GL program(s) that are > responsible for the leaks (each 4GL program is opened, read, and executed > by the application server, so the top most stackframe resolves to a function > in the application server, not a procedure call from a 4GL program). Since > the application server performs an open() prior to executing the program, I > thought I would be able to locate the offending 4GL program by enabling > probes on open:entry and the offset reported by findleaks. Does anyone happen > to know why the probe pid$target::rnrq:204 won''t fire? > > Thanks for the awesome replies, > > Thanks, > - Ryan > -- > UNIX Administrator > http://daemons.net/~matty > >> -- Renaud >> >> Matty wrote: >>> >>> Howdy, >>> >>> I am attempting to isolate the location of a memory leak in a 4GL program, >>> and have hit a bit of a snag. When I LD_PRELOAD libumem and run the >>> application server, "::findleaks -fdv" reports numerous leaks: >>> >>> CACHE LEAKED BUFCTL CALLER >>> 0000000100b49068 15 0000000100ef2d50 fdcon+0x6c4 >>> 0000000100b50028 1 0000000100b72ac0 fdcon+0x6c4 >>> 0000000100b49068 2 0000000100cdfb30 fdcon+0x6c4 >>> 0000000100b44368 93 0000000100c98ee0 rnrq+0x204 >>> 0000000100b44028 1 0000000100c6e8f0 rnrq+0x204 >>> 0000000100b44028 17 0000000100c6ef10 rnrq+0x204 >>> 0000000100b3b6e8 1 0000000100b737e0 rnrq+0x204 >>> 0000000100b486a8 5 000000010119e030 umEdSetAttr+0x5fc >>> ---------------------------------------------------------------------- >>> Total 135 buffers, 37680 bytes >>> >>> Since the application server opens a 4GL program each time it wants to >>> execute it (thank goodness for inefficiency), I thought I would use arg0 >>> to open and rnrq+0x204 to isolate the program file that contains the >>> problematic code. When I attempt to run the following DTrace to enable the >>> probe at rnrq:204: >>> >>> $ dtrace -p 4243 -n ''pid$target::rnrq:204 { ustack(); }'' >>> dtrace: description ''pid$target::rnrq:204 '' matched 1 probe >>> >>> The probe never fires. Does anyone see anything wrong with what I am >>> doing? >>> >>> Thanks for any insight, >>> - Ryan >>> -- >>> UNIX Administrator >>> http://daemons.net/~matty >>> _______________________________________________ >>> dtrace-discuss mailing list >>> dtrace-discuss at opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org