Weird truss output

[Vlad GALU]

On Wed, Dec 3, 2008 at 7:08 PM, Dan Nelson <dnelson at allantgroup.com> wrote:
> 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.

Now why didn't I think of that? :/ Thanks for the suggestion!

-- 
~/.signature: no such file or directory