Weird truss output

Dan Nelson dnelson at allantgroup.com
Wed Dec 3 09:09:00 PST 2008


In the last episode (Dec 03), Vlad GALU said:
> On Wed, Dec 3, 2008 at 5:23 PM, Dan Nelson <dnelson at allantgroup.com> wrote:
> > In the last episode (Dec 03), Vlad GALU said:
> >> I'm running a statically linked binary, which I've built inside a
> >> jail. The jail's libc & co are in sync with the host's. Truss then
> >> shows this:
> >>
> >> -- cut here --
> >> -- UNKNOWN SYSCALL 1048532 --
> >> -- UNKNOWN SYSCALL 1048532 --
> >
> > Is this a threaded app that you attached truss to after it was
> > started? The method that truss uses to catch syscall enter/exit
> > events doesn't indicate whether the event is an enter or an exit,
> > so if you attach while a syscall is active, truss handles the exit
> > event as if it were a syscall entry event, and never gets back in
> > synch.  It gets worse with threaded apps because each thread is
> > another chance to get out of synch.  Try this patch:
> 
> You were right, this application was indeed threaded. The messages
> still occur, although at a slightly lower rate. One other thing
> that's not particularly helpful is this:
> 
> -- cut here--
>  read(1074283119,"\M-Ry\^A\0",7356800)            = 4 (0x4)
> -- and here --
> 
> I obviously don't have that many descriptors in my process. I can
> live with the malformed message, but it's a PITA not to know which fd
> the read was actually made from :(

It looks like there's some other problem where truss either drops a
syscall event, or puts some status fields into the wrong thread's
structure.  It seems to happen when two threads call blocking syscalls,
and when they return, truss gets confused as to which thread called
which syscall.  The read syscall is probably still pending, and you're
getting the arguments of the syscall that returned, printed as if it
was the read syscall.  When the read call completes, you'll probably
get an --UNKNOWN SYSCALL-- line, or another mismatched syscall output
line.

An alternative it to use ktrace/kdump to trace the process; it's more
cumbersome to use, but doesn't have problems with threaded processes.

-- 
	Dan Nelson
	dnelson at allantgroup.com


More information about the freebsd-stable mailing list