dtrace discuss - Dec 2008 - Is there any way to trace malloc without using pid provider?

Hi,

Is there any way to trace malloc without using pid provider?

The issue is that the program we need to trace is a short-living one and we
don''t know its pid at the time dtrace is launched; but we can get this
pid some moment later.
-- 
This message posted from opensolaris.org

Malloc calls the brk system call to actually get new memory blocks from
the system, but it manages that memory itself, keeping a free list for
future allocation.  So that may or may not be helpful.

Does the program have a unique enough execname, that you can check that
in the predicate rather than the pid?  Or is there a unique call at the
beginning, like an mmapped or opened file that you can use as a trigger?

Chip
> -----Original Message-----
> From: dtrace-discuss-bounces at opensolaris.org [mailto:dtrace-discuss-
> bounces at opensolaris.org] On Behalf Of Vladimir Kvashin
> Sent: Monday, December 29, 2008 10:35 AM
> To: dtrace-discuss at opensolaris.org
> Subject: [dtrace-discuss] Is there any way to trace malloc without
> using pidprovider?
> 
> Hi,
> 
> Is there any way to trace malloc without using pid provider?
> 
> The issue is that the program we need to trace is a short-living one
> and we don''t know its pid at the time dtrace is launched; but we
can
> get this pid some moment later.
> --
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

Nevermind...  pid provider...  get to have pid hardcoded, or at least as
a macro variable.  Dropped a brain cell, I guess.

What about taking some cues from Brendan''s scripts and imbed the D
script in a shell script.  But the problem of course is getting the D
script started in time.  Could you introduce a shell script, with the
same name as the program that is being called, that in turn calls the
real program using DTrace?

Chip
> -----Original Message-----
> From: dtrace-discuss-bounces at opensolaris.org [mailto:dtrace-discuss-
> bounces at opensolaris.org] On Behalf Of Chip Bennett
> Sent: Monday, December 29, 2008 10:45 AM
> To: Vladimir Kvashin; dtrace-discuss at opensolaris.org
> Subject: Re: [dtrace-discuss] Is there any way to trace malloc without
> usingpidprovider?
> 
> Malloc calls the brk system call to actually get new memory blocks
from
> the system, but it manages that memory itself, keeping a free list for
> future allocation.  So that may or may not be helpful.
> 
> Does the program have a unique enough execname, that you can check
that
> in the predicate rather than the pid?  Or is there a unique call at
the
> beginning, like an mmapped or opened file that you can use as a
> trigger?
> 
> Chip
> 
> > -----Original Message-----
> > From: dtrace-discuss-bounces at opensolaris.org
[mailto:dtrace-discuss-
> > bounces at opensolaris.org] On Behalf Of Vladimir Kvashin
> > Sent: Monday, December 29, 2008 10:35 AM
> > To: dtrace-discuss at opensolaris.org
> > Subject: [dtrace-discuss] Is there any way to trace malloc without
> > using pidprovider?
> >
> > Hi,
> >
> > Is there any way to trace malloc without using pid provider?
> >
> > The issue is that the program we need to trace is a short-living one
> > and we don''t know its pid at the time dtrace is launched; but
we can
> > get this pid some moment later.
> > --
> > This message posted from opensolaris.org
> > _______________________________________________
> > dtrace-discuss mailing list
> > dtrace-discuss at opensolaris.org
> 
> 
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

Thanks a lot for you prompt reply.

I guess the exename can be used as a filter. 

But even if I have a trigger that says me that the program gas started - how can
I trace malloc/free? I can''t use pid provider since it needs a
hardcoded (from after-preprocessor point of view) pid value; and I
don''t know other way to trace malloc/free...
-- 
This message posted from opensolaris.org

> But even if I have a trigger that says me that the program gas started -
> how can I trace malloc/free? I can''t use pid provider since it
needs a
> hardcoded (from after-preprocessor point of view) pid value; and I
don''t
> know other way to trace malloc/free...
Have you tried libumem?!?

Make sure these environment variables are set prior to your program''s
execution:

	LD_PRELOAD=libumem.so
	UMEM_DEBUG=default

it MAY find a lot of brokenness, however.  The default settings for libumem
are pretty brutal (it checks for use-of-freed-memory, e.g.).  Once your
program is running for a while, you can gcore or force it to coredump and use
mdb''s "::findleaks" macro to see what''s leaking.

Dan

On Mon, Dec 29, 2008 at 2:04 PM, Vladimir Kvashin
<vladimir.kvashin at sun.com> wrote:
> Thanks a lot for you prompt reply.
>
> I guess the exename can be used as a filter.
>
> But even if I have a trigger that says me that the program gas started -
how can I trace malloc/free? I can''t use pid provider since it needs a
hardcoded (from after-preprocessor point of view) pid value; and I
don''t know other way to trace malloc/free...
How intrusive do you want to be?  If you don''t mind stopping the
process briefly just after it gets exec''d, use two scripts.  The first
script uses the exec-success probe to catch a specified execname just
before it starts to run.  You can stop() the process, and
''pid'' will
contain what you want.  Then just use system() to run the second
script with the supplied pid.  The second script needs a BEGIN clause
that uses system() to prun the target process but you''re all set
otherwise.

Chad