On Wed, Jan 13, 2010 at 3:11 AM, Manoj Kora <[email protected]> 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 _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/ltrace-devel
