dtrace discuss - Aug 2008 - pid$target::malloc:entry does not work

In Solaris 10 6/06, etc. I used to do things like

   pid$target::malloc:entry
   {
         ustack();
   }

and got stack traces from my application calling malloc as expected. In 
Solaris 10 8/07 I only see stack traces from functions inside libc 
calling a function called lmalloc() but not my malloc calls:

               ld.so.1`lmalloc
               ld.so.1`tsort+0xb4
               ld.so.1`load_completion+0x7c
               ld.so.1`elf_bndr+0x3d8
               ld.so.1`elf_rtbndr+0x10
               libc.so.1`0xff36f30c
               libc.so.1`_ndoprnt+0x32c
               libc.so.1`printf+0xf4
               memleak`fun1+0x94
               memleak`main+0x4
               memleak`_start+0x5c

If I change the probe specification to

   pid$target:libc:malloc:entry	# specify the module: libc

it works again. Is this another bug? It''s at least confusing and
unexpected.

That''s a bug and a rather odd one at that. Please submit it on
bugs.opensolaris.org. We''ll take a look.

Adam

On Wed, Aug 06, 2008 at 06:57:57PM +0200, Michael Mueller
wrote:
> In Solaris 10 6/06, etc. I used to do things like
> 
>    pid$target::malloc:entry
>    {
>          ustack();
>    }
> 
> and got stack traces from my application calling malloc as expected. In 
> Solaris 10 8/07 I only see stack traces from functions inside libc 
> calling a function called lmalloc() but not my malloc calls:
> 
>                ld.so.1`lmalloc
>                ld.so.1`tsort+0xb4
>                ld.so.1`load_completion+0x7c
>                ld.so.1`elf_bndr+0x3d8
>                ld.so.1`elf_rtbndr+0x10
>                libc.so.1`0xff36f30c
>                libc.so.1`_ndoprnt+0x32c
>                libc.so.1`printf+0xf4
>                memleak`fun1+0x94
>                memleak`main+0x4
>                memleak`_start+0x5c
> 
> If I change the probe specification to
> 
>    pid$target:libc:malloc:entry	# specify the module: libc
> 
> it works again. Is this another bug? It''s at least confusing and
unexpected.
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
Adam Leventhal, Fishworks                     http://blogs.sun.com/ahl