Fletcher, libc malloc being called or not only had to do with the naming of your probe. Looking at your configure options : --with-pymalloc This imples to me that python has his own malloc.
I do not recall, but why do you think you have a memory leak ? Just because the process grows over time and does not diminish in size does not necessarily mean a memory leak. How do you measure the size of your process and are you examining the virtual size or the RSS ? The virtual size only grows upward, but I would expect it to eventually stabilize. RSS will go up and down over time. I would be more concerned with RSS than virtual size except for the possibility of exceeding a 4 GB address space for 32 bit applications. pmap -xs would be interesting. rick On Wed, Jul 02, 2008 at 02:27:31PM -0700, Fletcher Cocquyt wrote: > Date: Wed, 02 Jul 2008 14:27:31 -0700 > From: Fletcher Cocquyt <[EMAIL PROTECTED]> > Subject: Re: [dtrace-discuss] Memory leak scripts - analysis > In-reply-to: <[EMAIL PROTECTED]> > To: rickey c weisner <[EMAIL PROTECTED]> > Cc: [email protected] > Thread-topic: [dtrace-discuss] Memory leak scripts - analysis > Thread-index: Acjcim8+knqA/bONQ0GtOzL8hEW0mg== > X-PMX-Version: 5.4.1.325704 > X-Brightmail-Tracker: AAAAAA== > X-Antispam: No, score=0.0/5.0, scanned in 0.085sec at (localhost [127.0.0.1]) > by smf-spamd v1.3.1 - http://smfs.sf.net/ > User-Agent: Microsoft-Entourage/12.11.0.080522 > Original-recipient: rfc822;[EMAIL PROTECTED] > > Ok, maybe this is significant in the context of explaining why my python > (mailman) processes seem to grow abnormally? > If the libc malloc is not being called, why and is that an important issue? > > > [EMAIL PROTECTED]:~ 2:17pm 54 # ldd /bin/python > libresolv.so.2 => /lib/libresolv.so.2 > libsocket.so.1 => /lib/libsocket.so.1 > libnsl.so.1 => /lib/libnsl.so.1 > librt.so.1 => /lib/librt.so.1 > libdl.so.1 => /lib/libdl.so.1 > libm.so.2 => /lib/libm.so.2 > libc.so.1 => /lib/libc.so.1 > libmp.so.2 => /lib/libmp.so.2 > libmd.so.1 => /lib/libmd.so.1 > libscf.so.1 => /lib/libscf.so.1 > libaio.so.1 => /lib/libaio.so.1 > libdoor.so.1 => /lib/libdoor.so.1 > libuutil.so.1 => /lib/libuutil.so.1 > libgen.so.1 => /lib/libgen.so.1 > > This is Python 2.5.2, built with no configure options besides --prefix on > Solaris 10. > > Config.log excerpt: > configure:14433: checking for --with-pymalloc > configure:14453: result: yes > > thanks > > On 7/2/08 7:46 AM, "rickey c weisner" <[EMAIL PROTECTED]> wrote: > > > Fletcher, > > This looks suspicious. Perhaps your malloc is not in libc ? > >> [690] | 0| 0|FILE |LOCL |0 |ABS |obmalloc.c > > remove the libc.so.1 from your probe description. > > rick > > > > On Wed, Jul 02, 2008 at 07:23:49AM -0700, Fletcher Cocquyt wrote: > >> Date: Wed, 02 Jul 2008 07:23:49 -0700 > >> From: Fletcher Cocquyt <[EMAIL PROTECTED]> > >> Subject: Re: [dtrace-discuss] Memory leak scripts > >> In-reply-to: <[EMAIL PROTECTED]> > >> To: rickey c weisner <[EMAIL PROTECTED]> > >> Cc: [email protected] > >> Thread-topic: [dtrace-discuss] Memory leak scripts > >> Thread-index: AcjcTz6M0DPfSSwvAEuYeh4RTBFiig== > >> X-PMX-Version: 5.4.1.325704 > >> X-Brightmail-Tracker: AAAAAA== > >> X-Antispam: No, score=0.0/5.0, scanned in 0.102sec at (localhost > >> [127.0.0.1]) > >> by smf-spamd v1.3.1 - http://smfs.sf.net/ > >> User-Agent: Microsoft-Entourage/12.11.0.080522 > >> Original-recipient: rfc822;[EMAIL PROTECTED] > >> > >> Looks OK: > >> > >> [EMAIL PROTECTED]:~ 7:22am 60 # !nm > >> nm /bin/python | egrep malloc > >> [3597] | 134599012| 0|FUNC |GLOB |0 |UNDEF |malloc > >> > >> > >> > >> On 7/2/08 6:11 AM, "rickey c weisner" <[EMAIL PROTECTED]> wrote: > >> > >>> Fletcher, > >>> First confirm that malloc is in your binary. > >>> > >>> arwen:nm a.out | grep malloc > >>> [70] | 134547228| 0|FUNC |GLOB |0 |UNDEF |malloc > >>> > >>> Then key on any malloc. > >>> Something like: > >>> pid$target::malloc:return, > >>> pid$target::memalign:return, > >>> pid$target::realloc:return, > >>> pid$target::valloc:return > >>> > >>> rick > >> > >> -- > >> Fletcher Cocquyt > >> Senior Systems Administrator > >> Information Resources and Technology (IRT) > >> Stanford University School of Medicine > >> > >> Email: [EMAIL PROTECTED] > >> Phone: (650) 724-7485 > >> > >> > > -- > Fletcher Cocquyt > Senior Systems Administrator > Information Resources and Technology (IRT) > Stanford University School of Medicine > > Email: [EMAIL PROTECTED] > Phone: (650) 724-7485 > > -- Rickey C. Weisner Software Development and Performance Specialist Sun Microsystems, INC cell phone: 615-308-1147 email: [EMAIL PROTECTED] _______________________________________________ dtrace-discuss mailing list [email protected]
