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
_______________________________________________
dtrace-discuss mailing list
[email protected]
