thanks to Casper, Nickolai, Manesh and anyone I forgot who responded.
The answer to my post(at the bottom of this email), is that the read
syscall returns a pointer to the buffer when it fails, otherwise it returns
the actual text of what it is pointing to if it succeeds.
> I am doing a truss on an app.
> I will see a read system call amongst the output.
> I understand that there are normally 3 parameters to a read system call.
> the first is the file descriptor, the third is the number of bytes read.
> The middle one is supposed to be a pointer to a buffer that the read output
> goes to.
> This is according to a man -s2 read on a solaris 2.7 box.
> Yet sometimes the truss output will show the middle parameter of the read
> system call
> as being ascii text, and sometimes it'll be what looks to be a hex address.
> Could someone explain why sometimes the truss shows one
> type output(ascii text) and sometimes it'll show the
> other (hex address)?
> Here is the sample of the truss output.
> 689: read(27, 0xEFFFC850, 16) Err#11 EAGAIN
> 689: read(27, "\0\0\08A\0\0\003FFFFFFB9".., 16) = 16
> 689: read(27, " / h o m e / b r e t t s".., 122) = 122
> 689: read(27, "\0\0\010\0\0\004FFFFFFB8".., 16) = 16
> Also, would the hex address form of the middle parameter ever be of
> interest to
> me in troubleshooting an app that crashes?
U BEFORE POSTING please READ the FAQ located at
. and the list POLICY statement located at
A To submit questions/summaries to this list send your email message to:
A To unsubscribe from this list please send an email message to:
E and in the BODY type:
R unsubscribe sun-managers
. unsubscribe sun-managers firstname.lastname@example.org
L To view an archive of this list please visit:
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:11 CDT