본문 바로가기

Programming

Debugging multi-threaded application with GDB attaching

GDB 에서 멀티쓰레드 application (QEMU 의 경우 기본 4쓰레드) 에 attach 를 하고 브포를 걸었을때 SIGTRAP 이 발생하면서 죽는경우가 있다. 관련된 문서들을 찾고 조사중...



> 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).

'Programming' 카테고리의 다른 글

Exception Handling in Linux g++  (0) 2014.05.27
C++ SEH Handling  (0) 2014.04.02
Linux DDD Debuger  (0) 2014.03.13
Intel PIN Tutorial  (1) 2014.03.06
Linux gdb ASLR disabling  (0) 2014.03.04