ltrace killed by SIGTRAP

[Ltrace-devel] ltrace stucks with pthreads

Heiko Carstens heiko.carstens at de.ibm.com
Fri Apr 14 11:14:42 UTC 2006


> What am I doing wrong? Is there a hidden secret to use ltrace with threads? Any
> additional parameter to pass. Or any specific compilation switch to use?

You're doing nothing wrong, but came across a limitation of ltrace. ltrace is not able to trace threaded processes: If a process generates a thread
that shares the same address space (that is calling the "clone" system call with
parameters CLONE_VM, CLONE_THREAD) the traced process will die with SIGILL
(s390/s390x) or SIGTRAP (i386). The reason for this is that ltrace inserts breakpoints (illegal instructions)
into the traced thread's address space. This address space is shared between all
threads, but ltrace gets only notified for breakpoints of the first thread's
breakpoints. If the second thread reaches such a breakpoint the kernel notices
that this particular thread of the process is not traced and therefore sends it
a SIGILL signal (if a signal handler is present) or terminates it because of the
illegal instruction. Fixing ltrace to be able to trace threaded processes ain't easy. Additionaly
the follow-fork option of ltrace is also anything but perfect:
It attaches to the child when it is already running (or worst case: the child
already terminated). This could be fixed by using ptrace's PTRACE_SETOPTIONS
together with PTRACE_O_TRACEFORK. The only difficult thing would be to make
the changes in a way that ltrace still runs on older kernels that don't
support this ptrace interface (btw.: the latest man page release finally
documents all the different ptrace requests). 升级到
[root@localhost ~]# ltrace -V
ltrace version 0.5.
Copyright (C) 1997-2006 Juan Cespedes <cespedes@debian.org>.
This is free software; see the GNU General Public Licence
version 2 or later for copying conditions. There is NO warranty.
上一篇:php 数组 添加元素、删除元素


下一篇:js数组依据下标删除元素