On Thu, 2008-07-17 at 15:42 -0700, Eric Schrock wrote: > This is due to a dynamically loaded library that has been closed. You > want to set the 'TOPONODLCLOSE' environment variable to avoid this in > this particular situation.
Thanks very much Eric. Works as advertised. -scott > > On Thu, Jul 17, 2008 at 01:47:03PM -0700, Scott Davenport wrote: > > Hello, > > > > I'm trying to trace down a memory leak, and ::findleaks -d > > isn't decoding all of the symbols. Ex: > > > > # UMEM_DEBUG=default /usr/lib/fm/fmd/fmtopo -C > /dev/null > > ... > > > ::findleaks -v > > ... > > umem_alloc_16 leak: 2 buffers, 16 bytes each, 32 bytes total > > ADDR BUFADDR TIMESTAMP THREAD > > ^[[4m CACHE LASTLOG > > CONTENTS^[[m > > ^[[1m 2d6c30^[[m 2cfaa0 b85d1620cf > > 1 > > 82008 0 0 > > libumem.so.1`umem_cache_alloc+0x148 > > libumem.so.1`umem_alloc+0xa8 > > 0xfe8633d0 > > 0xfe863a8c > > 0xfe861bb0 > > libtopo.so.1`rtld_init+0x160 > > libtopo.so.1`topo_mod_start+0x40 > > libtopo.so.1`topo_mod_create+0xcc > > libtopo.so.1`topo_modhash_load+0x20 > > libtopo.so.1`topo_mod_load+0xc0 > > libtopo.so.1`mem_enum+0x28 > > libtopo.so.1`topo_mod_enumerate+0xac > > libtopo.so.1`topo_builtin_create+0xa0 > > libtopo.so.1`topo_open+0x384 > > main+0x238 > > > > Is this just an instance of "6398977 findleaks not resolving symbol > > names"? Or are there othe > > > > Meanwhile starting to sift through nm output. > > > > Thanks > > -- scott > > http://blogs.sun.com/sdaven > > > > > _______________________________________________ > > mdb-discuss mailing list > > mdb-discuss at opensolaris.org > > > -- > Eric Schrock, Fishworks http://blogs.sun.com/eschrock -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3177 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/mdb-discuss/attachments/20080717/b2bfe515/attachment.bin>
