[Ltrace-devel] multi-thread support for ltrace

[Manoj Kora]

Hi,

I have checkout the latest ltrace source ltrace-0.5.3 in which thread support is better compared to ltrace-0.5.1. But the thing is that when i use ltrace to trace an executable containing multi threads on ARM architecture it seems to be working fine. But the same thing breaks on the MIPS architecture with the following output:

pthread_create(0x7f8efca0, 0, 0x400870, 0, 0 <unfinished ...>  pthread_create(0x7f8efca0, 0, 0x400870, 0, 0 <unfinished ...>  pthread_create(0x7f8efca0, 0, 0x400870, 0, 0 <unfinished ...>  pthread_create(0x7f8efca0, 0, 0x400870, 0, 0 <unfinished ...>  pthread_create(0x7f8efca0, 0, 0x400870, 0, 0 <unfinished ...>  pthread_create(0x7f8efca0, 0, 0x400870, 0, 0 <unfinished ...>

And it never comes of the execution. I have to kill the process to stop the execution.

 So my questions are:

             1) Whether MIPS architecture is supported by ltrace-0.5.3 soruce? (Not in terms of cross compiling but in terms of working of ltrace on MIPS for multi thread).
             2) If yes, whether it is stable or not?

Any help in this regard is appreciated.

Regards,
Manoj

--- On Fri, 15/1/10, Anderson Lizardo <anderson.lizardo at gmail.com> wrote:

From: Anderson Lizardo <anderson.lizardo at gmail.com>
Subject: Re: [Ltrace-devel] multi-thread support for ltrace
To: "Manoj Kora" <koramanoj at yahoo.com>
Cc: ltrace-devel at lists.alioth.debian.org
Date: Friday, 15 January, 2010, 1:40 PM

On Wed, Jan 13, 2010 at 3:11 AM, Manoj Kora <koramanoj at yahoo.com> wrote:
> * So workaround is made for is by disabling the library call tracing  using “-L” option.
>
> * A good fix for this situation would require heavy changes to ltrace  process model.
>
> So by disabling the "-L" option they are disabling the display of library calls, which degrades the functionality of ltrace.

Yes, but note this from the original comments:

"on *some circunstances* the traced threads may segfault because of
unexpected breakpoints."

For intended usage at the time, there were not many of such cases, and
using -L would allow at least the tracing to work on ARM (strace not
not very usable at the time on ARM, but then we provided some patches
for that later).

The purpose of the implementation was to allow ltrace to work at least
better with threads, instead of crashing every time.

> So is there any workaround for this patch to overcome these problems and have a permanent solution?

I believe there is no known workaround that would work in 100% cases,
at least using the implementation from the URL I sent you.

> Since it has been mentioned in the patch that, a good fix for this situation would require heavy changes for ltrace process model. So i thought of parallely going through the strace code to get an idea how to handle threads and implement the same for ltrace.

strace has *much* less trouble with threads because it does not need
to work with breakpoints (and I believe it does not need to write to
the process memory). ltrace needs to basically implement what strace
does plus handle breakpoints (which requires write breakpoint
instructions to the process memory). Breakpoints (at least from the
ptrace() syscall point of view) are hard to control in a multithreaded
application , where much (all?) of the executable memory is shared
between threads, so one thread keeps hitting breakpoints inserted by
another one.

If you really need reliability when tracing threads , I suggest you
take a look at some tool which uses the newer utrace/uprobes kernel
API. I don't know of any of such tools though, but you might find some
references at http://sourceware.org/systemtap/wiki/utrace

But, if you still want to play with ptrace() (the tracing system call
used by strace/ltrace/gdb), you might want also to take a look at
another tool available in Maemo which uses ptrace() to track resource
allocations, and works almost reliably with threads, but is a lot
slower and may consume a lot of memory with many threads:

http://repository.maemo.org/pool/fremantle/free/f/functracer/

It works on a similar way to ltrace (i.e. by inserting breakpoints),
but uses a different mechanism to manage breakpoint insertion (called
"single-step out of line" or SSOL, an idea borrowed from some
discussions on the utrace-devel mailing list a long time ago).

Hope that helps,
--
Anderson Lizardo
Instituto Nokia de Tecnologia (INdT)
Manaus - Brazil



      Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/ltrace-devel/attachments/20100209/eeed4100/attachment.htm>