|
Home > Archive > Unix Programming > May 2005 > Why cannot truss peek inside sendmsg()
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Why cannot truss peek inside sendmsg()
|
|
| sonyantony@hotmail.com 2005-04-27, 5:58 pm |
| 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
| |
| Bjorn Reese 2005-04-27, 5:58 pm |
| sonyantony@hotmail.com wrote:
> 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
| |
| sonyantony@hotmail.com 2005-04-27, 5:58 pm |
|
>
> 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
| |
| Jean-Louis Liagre 2005-04-27, 5:58 pm |
| sonyantony@hotmail.com wrote:
>
>
> 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 ?
| |
| rodrick.brown@gmail.com 2005-04-27, 5:58 pm |
| sounds like a job for dtrace 
- RB
| |
| Jonathan Adams 2005-04-27, 8:51 pm |
| In article <1114613013.526648.109930@l41g2000cwc.googlegroups.com>,
sonyantony@hotmail.com wrote:
> 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.
Cheers,
- jonathan
| |
| sonyantony@hotmail.com 2005-04-28, 2:49 am |
|
Jonathan Adams wrote:
> In article <1114613013.526648.109930@l41g2000cwc.googlegroups.com>,
> sonyantony@hotmail.com wrote:
>
new[vbcol=seagreen]
arguments )[vbcol=seagreen]
> Not really (besides using snoop and trying to line things up)
>
>
> This is doubtful; truss has a lot of under-the-covers knowledge.
>
>
> 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
>
> Cheers,
> - jonathan
| |
| Richard L. Hamilton 2005-05-01, 6:21 pm |
| In article <1114659765.003725.136730@z14g2000cwz.googlegroups.com>,
sonyantony@hotmail.com writes:
[...]
> 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.
--
mailto:rlhamil@smart.net http://www.smart.net/~rlhamil
Lasik/PRK theme music:
"In the Hall of the Mountain King", from "Peer Gynt"
| |
| Rich Teer 2005-05-01, 6:21 pm |
| On Thu, 28 Apr 2005, Richard L. Hamilton wrote:
> 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
| |
| Jonathan Adams 2005-05-01, 6:21 pm |
| In article <1114659765.003725.136730@z14g2000cwz.googlegroups.com>,
sonyantony@hotmail.com wrote:
> Jonathan Adams wrote:
>
> 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)
> 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.
> 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
| |
| Casper H.S. Dik 2005-05-01, 6:21 pm |
| Jonathan Adams <jwadams@gmail.com> writes:
>In article <1114659765.003725.136730@z14g2000cwz.googlegroups.com>,
> sonyantony@hotmail.com wrote:
[vbcol=seagreen]
>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.
| |
| Scott Howard 2005-05-01, 6:21 pm |
| In comp.unix.solaris Jonathan Adams <jwadams@gmail.com> wrote:
>
> 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
| |
| c0ntexB@gmail.com 2005-05-06, 7:48 am |
| 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
|
|
|
|
|