Why cannot truss peek inside sendmsg()

Why cannot truss peek inside sendmsg()

Post by sonyant.. » Thu, 28 Apr 2005 23:43:33



I use truss for a variety of problems.
Recently when we upgraded one of our software, I realized that the new
version switched from using send()/recv() to sendmsg()/recvmsg() to
send data over the TCP socket.

Though these BSD calls are very similar in nature, truss for some
reason cannot show the data that goes/comes from the socket if
sendmsg()/recvmsg() is used. ( Even when I give -rall -wall arguments )

1. Is there any way out at all ( Already looked man truss )
2. Are there any other utilities out there that will work just like
truss on Solaris.
3. Is there any reason why truss cannot look at the data passing
through sendmsg()/recvmsg()

Thanks
--sony

 
 
 

Why cannot truss peek inside sendmsg()

Post by Bjorn Rees » Fri, 29 Apr 2005 03:24:02



> Though these BSD calls are very similar in nature, truss for some
> reason cannot show the data that goes/comes from the socket if
> sendmsg()/recvmsg() is used. ( Even when I give -rall -wall arguments )
[...]
> 2. Are there any other utilities out there that will work just like
> truss on Solaris.

Try tcpdump.

--
mail1dotstofanetdotdk

 
 
 

Why cannot truss peek inside sendmsg()

Post by sonyant.. » Fri, 29 Apr 2005 04:04:30


Quote:> > 2. Are there any other utilities out there that will work just like
> > truss on Solaris.

> Try tcpdump.

I did eventually use snoop ( just like tcpdump, except that it comes
with solaris )
But tcpdump/snoop is not meant to show the system calls a process
makes, and has no relation with truss. ( I was asking a utility like
tusc( HP-UX) or strace( Linux ) that will run on Solaris, and one that
is meant to show the system calls, with sendmsg()/recvmsg() arguments
shown in full )

Thanks
--sony

 
 
 

Why cannot truss peek inside sendmsg()

Post by Jean-Louis Liagr » Fri, 29 Apr 2005 06:27:58



>>>2. Are there any other utilities out there that will work just like
>>>truss on Solaris.

>>Try tcpdump.

> I did eventually use snoop ( just like tcpdump, except that it comes
> with solaris )
> But tcpdump/snoop is not meant to show the system calls a process
> makes, and has no relation with truss. ( I was asking a utility like
> tusc( HP-UX) or strace( Linux ) that will run on Solaris, and one that
> is meant to show the system calls, with sendmsg()/recvmsg() arguments
> shown in full )

What about dtrace ?
 
 
 

Why cannot truss peek inside sendmsg()

Post by rodrick.br.. » Fri, 29 Apr 2005 06:29:35


sounds like a job for dtrace :)

- RB

 
 
 

Why cannot truss peek inside sendmsg()

Post by Jonathan Adam » Fri, 29 Apr 2005 08:43:24




> I use truss for a variety of problems.
> Recently when we upgraded one of our software, I realized that the new
> version switched from using send()/recv() to sendmsg()/recvmsg() to
> send data over the TCP socket.

> Though these BSD calls are very similar in nature, truss for some
> reason cannot show the data that goes/comes from the socket if
> sendmsg()/recvmsg() is used. ( Even when I give -rall -wall arguments )

> 1. Is there any way out at all ( Already looked man truss )

Not really (besides using snoop and trying to line things up)

Quote:> 2. Are there any other utilities out there that will work just like
> truss on Solaris.

This is doubtful;  truss has a lot of under-the-covers knowledge.

Quote:> 3. Is there any reason why truss cannot look at the data passing
> through sendmsg()/recvmsg()

Not really; the code to do it was just never written.  I've filed

6262586 truss should print data written/read for sendmsg/recvmsg

to cover this.

Cheers,
- jonathan

 
 
 

Why cannot truss peek inside sendmsg()

Post by sonyant.. » Fri, 29 Apr 2005 12:42:45





> > I use truss for a variety of problems.
> > Recently when we upgraded one of our software, I realized that the
new
> > version switched from using send()/recv() to sendmsg()/recvmsg() to
> > send data over the TCP socket.

> > Though these BSD calls are very similar in nature, truss for some
> > reason cannot show the data that goes/comes from the socket if
> > sendmsg()/recvmsg() is used. ( Even when I give -rall -wall
arguments )

> > 1. Is there any way out at all ( Already looked man truss )
> Not really (besides using snoop and trying to line things up)

> > 2. Are there any other utilities out there that will work just like
> > truss on Solaris.

> This is doubtful;  truss has a lot of under-the-covers knowledge.

> > 3. Is there any reason why truss cannot look at the data passing
> > through sendmsg()/recvmsg()

> Not really; the code to do it was just never written.  I've filed

> 6262586 truss should print data written/read for sendmsg/recvmsg

> to cover this.

dtrace sounds promising. Is dtrace available on solaris 8 ?

Thanks a lot Jonathan.
I did make an attempt today by
1. use LD_PRELOAD env variable to load a shared object, that has 2
dummy functions defined namely sendmsg()/recvmsg(). These functions
take the exact type of arguments as the real sendmsg()/recvmsg() and
writess the data to /dev/null. It then calls the actual system calls by
using symbols on the previously dlopen() ed system library shared
object.
Since it is write() ing the data to the /dev/null, truss will show the
arguments ( I could have printed it to a file as well instead of
/dev/null ).
I have not completed this. One problem I can already see is its
inability to snoop at the data on a process that is already running (
like the case with truss -p <pid> ).

Jonathan
Do you know how long it will take for the patch release for 6262586

Thanks again

--sony

- Show quoted text -

Quote:

> Cheers,
> - jonathan

 
 
 

Why cannot truss peek inside sendmsg()

Post by Richard L. Hamilt » Sat, 30 Apr 2005 05:25:26




[...]
Quote:> Do you know how long it will take for the patch release for 6262586

[...]

He probably doesn't, but if you consider very limited resources, that the
lack of what you want isn't as bad as something actually broken, and the
slowness of Sun's typical testing cycle for code changes and patches (not
to mention that they go in the development version - the latest build -
and only sometimes and slowly get pushed back to older versions); well, it
could be months or years if not never for the Solaris version you have
now.  OTOH, if you're a paying customer with an expensive enough support
contract, they could probably slip you a copy that had the mod but hadn't
been through all the testing; that might happen whenever someone got
around to actually coding the mod, backporting to your version, and
building it; again, enough $$ on the support contract and lots of calls
might make that happen somewhat faster; but my guess is that that's
probably just going to cut more months to less months, not get it for you
in days or (perhaps barring being with a company with millions in play
and being a major pest) weeks.

There is an open-source rough equivalent to truss, and it supposedly even
supports Solaris (see the README-svr4 file within the source tarball),
although I haven't built it recently and don't know (or care) whether or
not it does what you want.  It's called "strace" (google for it; I'm on
strike today and don't do OP's research :-), not to be confused with the
existing strace(1m) which prints STREAMS trace (debugging) messages, but
has  nothing to do with system call tracing.

--

Lasik/PRK theme music:
    "In the Hall of the Mountain King", from "Peer Gynt"

 
 
 

Why cannot truss peek inside sendmsg()

Post by Rich Tee » Sat, 30 Apr 2005 07:41:36



> now.  OTOH, if you're a paying customer with an expensive enough support
> contract, they could probably slip you a copy that had the mod but hadn't
> been through all the testing; that might happen whenever someone got
> around to actually coding the mod, backporting to your version, and
> building it; again, enough $$ on the support contract and lots of calls
> might make that happen somewhat faster; but my guess is that that's
> probably just going to cut more months to less months, not get it for you
> in days or (perhaps barring being with a company with millions in play
> and being a major pest) weeks.

All good stuff and true.  Howvere, with the advent of OpenSolaris, people
will be able to fix their own bugs at their own pace.

--
Rich Teer, SCNA, SCSA, OpenSolaris CAB member

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich

 
 
 

Why cannot truss peek inside sendmsg()

Post by Jonathan Adam » Sun, 01 May 2005 07:53:40





> > Not really; the code to do it was just never written.  I've filed

> > 6262586 truss should print data written/read for sendmsg/recvmsg

> > to cover this.

> dtrace sounds promising. Is dtrace available on solaris 8 ?

Nope;  and it will never be available for Solaris 8 -- it relies on type
infrastructure that was introduced in Solaris 9.  (it's not likely to be
backported to S9, either)

Quote:> 1. use LD_PRELOAD env variable to load a shared object, that has 2
> dummy functions defined namely sendmsg()/recvmsg(). These functions
> take the exact type of arguments as the real sendmsg()/recvmsg() and
> writess the data to /dev/null. It then calls the actual system calls by
> using symbols on the previously dlopen() ed system library shared
> object.
> Since it is write() ing the data to the /dev/null, truss will show the
> arguments ( I could have printed it to a file as well instead of
> /dev/null ).
> I have not completed this. One problem I can already see is its
> inability to snoop at the data on a process that is already running (
> like the case with truss -p <pid> ).

This approach should work, but you are right about its limitations.

Quote:> Jonathan
> Do you know how long it will take for the patch release for 6262586

I'm sorry to say I don't know.  I deal mainly with the development
release.

Cheers,
- jonathan

 
 
 

Why cannot truss peek inside sendmsg()

Post by Casper H.S. Di » Sun, 01 May 2005 17:42:22






>> > Not really; the code to do it was just never written.  I've filed

>> > 6262586 truss should print data written/read for sendmsg/recvmsg

>> > to cover this.

>> dtrace sounds promising. Is dtrace available on solaris 8 ?
>Nope;  and it will never be available for Solaris 8 -- it relies on type
>infrastructure that was introduced in Solaris 9.  (it's not likely to be
>backported to S9, either)

Isn't it the case that it can't be made on sun4m CPUs either?
(Or only with great difficulty?)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

Why cannot truss peek inside sendmsg()

Post by Scott Howar » Sun, 01 May 2005 23:16:32



Quote:>> dtrace sounds promising. Is dtrace available on solaris 8 ?

> Nope;  and it will never be available for Solaris 8 -- it relies on type
> infrastructure that was introduced in Solaris 9.  (it's not likely to be
> backported to S9, either)

Of course, this doesn't stop you setting up a "test" instance of your
application on a Solaris 10 box, reproducing the problem there, and
then using Dtrace on it.

This may sound like a lot of effort, but in many cases it will be far
more efficient than trying to solve the same problem on Solaris 8/9
without Dtrace.

  Scott

 
 
 

Why cannot truss peek inside sendmsg()

Post by c0nt.. » Sat, 07 May 2005 17:23:07


Try using GDB by setting the correct breakpoint at each function /
syscall you want data to be visible. i.e, during the functions that
contain the sendmsg()/recvmsg().

regards

 
 
 

1. RPMs : Peeking Inside?

Howdy,

I'd like to gain access to the files inside
an RPM file, without actually installing the
RPM or changing my system configuration in
any way.  Kinda like "unzipping" the RPM
file ...

Can RPM do this?  It wasn't obvious from the
manpage.  Is another tool required?

Thanks for any tips!

Rich

2. HELP - Building spice3f4 for Linux

3. Peek inside a shared library

4. Games on Linux

5. peeking inside

6. Syslogd

7. Peek inside an object/lib file

8. XF86Config with Diamond Stealth VRAM and CTX CVP-5468NI monitor

9. Peeking inside binary files

10. Need help in understanding the mapping of user-space send, sendto, sendmsg to kernel-space sendmsg

11. truss and without truss

12. Why is the argument to sendmsg() typed this way?

13. sendmsg and recvmsg - Why the iovec limit?