dtrace discuss - Mar 2007 - index 0 is out of range for syscall::open:entry args[ ]

Dear all,
  
     I''ve got a problem that confuses me.
     I ran below dtrace command on my U60 with Solaris 10 6/06 installed but got
errors.

------------------------------------------------------------------------------------------
# dtrace -qn ''syscall::open:entry,syscall::open64:entry{printf("%s
opened %s\n",execname,copyinstr(args[0]));}''
dtrace: invalid probe specifier
syscall::open:entry,syscall::open64:entry{printf("%s opened
%s\n",execname,copyinstr(args[0]));}: in action list: index 0 is out of
range for syscall::open:entry args[ ]
------------------------------------------------------------------------------------
      How come args[0] is invalid?
  
      Your help will be very appreciated.
 
      Thanks and regards.

Sam
 
 
This message posted from opensolaris.org

Sam Wan wrote:
> Dear all,
>   
>      I''ve got a problem that confuses me.
>      I ran below dtrace command on my U60 with Solaris 10 6/06 installed
but got errors.
> 
>
------------------------------------------------------------------------------------------
> # dtrace -qn
''syscall::open:entry,syscall::open64:entry{printf("%s opened
%s\n",execname,copyinstr(args[0]));}''
> dtrace: invalid probe specifier
syscall::open:entry,syscall::open64:entry{printf("%s opened
%s\n",execname,copyinstr(args[0]));}: in action list: index 0 is out of
range for syscall::open:entry args[ ]
>
------------------------------------------------------------------------------------
>       How come args[0] is invalid?
args[] isn''t defined for the syscall provider.  Use arg0...argN
instead.

I don''t really know why.

An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070322/cd47e4ad/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: left
Type: image/gif
Size: 2710 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070322/cd47e4ad/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bottom
Type: image/gif
Size: 1557 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20070322/cd47e4ad/attachment-0001.gif>

Sam Wan wrote:
> Hi Dan,
> 
>     Thanks for your reply but how could that be?
Did you try it, rather than simply disbelieve it?
>     Check page 67 of ''Solaris Dynamic Tracing Guide(
817?6223?11)'' for
> the description of args[]
> ---------------------------------------------------------
>        The typed arguments to the current probe, if
>        any. The args[] array is accessed using an
>        integer index, but each element is de?ned to
>        be the type corresponding to the given probe
>        argument. For example, if args[] is
>        referenced by a read(2) system call probe,
>        args[0] is of type int, args[1] is of type
>        void *, and args[2] is of type size_t.
> -------------------------------------------------------
> 
>     See the example takes read(2) syscall probe.
but it doesn''t say the syscall provider.  for an fbt::read:entry probe,
the
example is correct.
> Dan Mick ??:
>> Sam Wan wrote:
>>> Dear all,
>>>        I''ve got a problem that confuses me.
>>>      I ran below dtrace command on my U60 with Solaris 10 6/06 
>>> installed but got errors.
>>>
>>>
------------------------------------------------------------------------------------------
>>>
>>> # dtrace -qn
''syscall::open:entry,syscall::open64:entry{printf("%s
>>> opened %s\n",execname,copyinstr(args[0]));}''
>>> dtrace: invalid probe specifier 
>>> syscall::open:entry,syscall::open64:entry{printf("%s opened 
>>> %s\n",execname,copyinstr(args[0]));}: in action list: index 0
is out
>>> of range for syscall::open:entry args[ ]
>>>
------------------------------------------------------------------------------------
>>>
>>>       How come args[0] is invalid?
>>
>> args[] isn''t defined for the syscall provider.  Use
arg0...argN instead.
>>
>> I don''t really know why.
>> _______________________________________________
>> dtrace-discuss mailing list
>> dtrace-discuss at opensolaris.org
> 
> 
> -- 
> 
> <http://www.sun.com/>
> 
> 	
> 
> *Sam Wan** - System Support Engineer*
> * Sun Microsystems (China),Chengdu Office*
> Add: Suite C, 11/F, Chuan Xin Mansion, No.18 Sec.2  Ren Min S.Rd,  
> Chengdu,China. 610016
> Tel: 86-28-86199333 ext. 84243
> Fax: 86-28-86199333
> Mobile: 86-13980681947
> Email: wan.sam at sun.com <mailto:wan.sam at sun.com>
> MSN: wan_sam at hotmail.com <mailto:wan_sam at hotmail.com>
> BLOG:http://blogs.sun.com/swan
> 
> <http://www.sun.com/>
>

Dan Mick wrote:
> Sam Wan wrote:
>
>>     Check page 67 of ''Solaris Dynamic Tracing Guide(
817?6223?11)''
>> for the description of args[]
>> ---------------------------------------------------------
>>        The typed arguments to the current probe, if
>>        any. The args[] array is accessed using an
>>        integer index, but each element is de?ned to
>>        be the type corresponding to the given probe
>>        argument. For example, if args[] is
>>        referenced by a read(2) system call probe,
>>        args[0] is of type int, args[1] is of type
>>        void *, and args[2] is of type size_t.
>> -------------------------------------------------------
>>
>>     See the example takes read(2) syscall probe.
>
> but it doesn''t say the syscall provider.  for an fbt::read:entry 
> probe, the
> example is correct.
>
Hmmm....  The reference is to read(2), which means UNIX manual section 
2, system calls, and it also says "system call" probes.  Clearly the 
author meant the syscall provider.  IMHO, This is just an error in the 
manual.  Adam mentioned last year that it would be nice for the syscall 
provider to have mappings into the args array, but there''s no automatic
way to do that, like there is with fbt, and it would be a bunch of work 
for somebody to do them all.  Perhaps, when the manual was written, 
there was an intention to do that?  (mind-reading-mode ON)  ;-)

Chip

On Thu, Mar 22, 2007 at 01:13:27AM -0500, Chip Bennett
wrote:
> >>---------------------------------------------------------
> >>       The typed arguments to the current probe, if
> >>       any. The args[] array is accessed using an
> >>       integer index, but each element is de?ned to
> >>       be the type corresponding to the given probe
> >>       argument. For example, if args[] is
> >>       referenced by a read(2) system call probe,
> >>       args[0] is of type int, args[1] is of type
> >>       void *, and args[2] is of type size_t.
> >>-------------------------------------------------------
> >
> Hmmm....  The reference is to read(2), which means UNIX manual section 
> 2, system calls, and it also says "system call" probes.  Clearly
the
> author meant the syscall provider.  IMHO, This is just an error in the 
> manual.
That''s right. The syscall provider doesn''t have typed
arguments; we got
this wrong in the docs.

Adam

-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

Chip Bennett wrote:
> Dan Mick wrote:
>> Sam Wan wrote:
>>
>>>     Check page 67 of ''Solaris Dynamic Tracing Guide(
817?6223?11)''
>>> for the description of args[]
>>> ---------------------------------------------------------
>>>        The typed arguments to the current probe, if
>>>        any. The args[] array is accessed using an
>>>        integer index, but each element is de?ned to
>>>        be the type corresponding to the given probe
>>>        argument. For example, if args[] is
>>>        referenced by a read(2) system call probe,
>>>        args[0] is of type int, args[1] is of type
>>>        void *, and args[2] is of type size_t.
>>> -------------------------------------------------------
>>>
>>>     See the example takes read(2) syscall probe.
>>
>> but it doesn''t say the syscall provider.  for an
fbt::read:entry
>> probe, the
>> example is correct.
>>
> Hmmm....  The reference is to read(2), which means UNIX manual section 
> 2, system calls, and it also says "system call" probes.  Clearly
the
> author meant the syscall provider.
not at all clear to me, but it''s now in angels and pins territory.