<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi,<br><br>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:<br><br>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 ...><br><br>And it never comes of the execution. I have to kill the process to stop the
execution.<br><br> So my questions are:<br><br> 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).<br> 2) If yes, whether it is stable or not?<br><br>Any help in this regard is appreciated.<br><br>Regards,<br>Manoj<br><br>--- On <b>Fri, 15/1/10, Anderson Lizardo <i><anderson.lizardo@gmail.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Anderson Lizardo <anderson.lizardo@gmail.com><br>Subject: Re: [Ltrace-devel] multi-thread support for ltrace<br>To: "Manoj Kora" <koramanoj@yahoo.com><br>Cc: ltrace-devel@lists.alioth.debian.org<br>Date: Friday, 15 January, 2010, 1:40 PM<br><br><div class="plainMail">On
Wed, Jan 13, 2010 at 3:11 AM, Manoj Kora <<a ymailto="mailto:koramanoj@yahoo.com" href="/mc/compose?to=koramanoj@yahoo.com">koramanoj@yahoo.com</a>> wrote:<br>> * So workaround is made for is by disabling the library call tracing using “-L†option.<br>><br>> * A good fix for this situation would require heavy changes to ltrace process model.<br>><br>> So by disabling the "-L" option they are disabling the display of library calls, which degrades the functionality of ltrace.<br><br>Yes, but note this from the original comments:<br><br>"on *some circunstances* the traced threads may segfault because of<br>unexpected breakpoints."<br><br>For intended usage at the time, there were not many of such cases, and<br>using -L would allow at least the tracing to work on ARM (strace not<br>not very usable at the time on ARM, but then we provided some patches<br>for that later).<br><br>The purpose of the implementation was to
allow ltrace to work at least<br>better with threads, instead of crashing every time.<br><br>> So is there any workaround for this patch to overcome these problems and have a permanent solution?<br><br>I believe there is no known workaround that would work in 100% cases,<br>at least using the implementation from the URL I sent you.<br><br>> 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.<br><br>strace has *much* less trouble with threads because it does not need<br>to work with breakpoints (and I believe it does not need to write to<br>the process memory). ltrace needs to basically implement what strace<br>does plus handle breakpoints (which requires write breakpoint<br>instructions to the process memory). Breakpoints (at least from
the<br>ptrace() syscall point of view) are hard to control in a multithreaded<br>application , where much (all?) of the executable memory is shared<br>between threads, so one thread keeps hitting breakpoints inserted by<br>another one.<br><br>If you really need reliability when tracing threads , I suggest you<br>take a look at some tool which uses the newer utrace/uprobes kernel<br>API. I don't know of any of such tools though, but you might find some<br>references at <a href="http://sourceware.org/systemtap/wiki/utrace" target="_blank">http://sourceware.org/systemtap/wiki/utrace</a><br><br>But, if you still want to play with ptrace() (the tracing system call<br>used by strace/ltrace/gdb), you might want also to take a look at<br>another tool available in Maemo which uses ptrace() to track resource<br>allocations, and works almost reliably with threads, but is a lot<br>slower and may consume a lot of memory with many threads:<br><br><a
href="http://repository.maemo.org/pool/fremantle/free/f/functracer/" target="_blank">http://repository.maemo.org/pool/fremantle/free/f/functracer/</a><br><br>It works on a similar way to ltrace (i.e. by inserting breakpoints),<br>but uses a different mechanism to manage breakpoint insertion (called<br>"single-step out of line" or SSOL, an idea borrowed from some<br>discussions on the utrace-devel mailing list a long time ago).<br><br>Hope that helps,<br>--<br>Anderson Lizardo<br>Instituto Nokia de Tecnologia (INdT)<br>Manaus - Brazil<br></div></blockquote></td></tr></table><br>
<!--1--><hr size=1></hr>
The INTERNET now has a personality. YOURS! <a href="http://in.rd.yahoo.com/tagline_yyi_1/*http://in.yahoo.com/" target="_blank">See your Yahoo! Homepage</a>.