Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1020056
  • 博文数量: 87
  • 博客积分: 3324
  • 博客等级: 中校
  • 技术积分: 1003
  • 用 户 组: 普通用户
  • 注册时间: 2006-05-17 11:37
文章分类

全部博文(87)

文章存档

2014年(3)

2013年(5)

2012年(21)

2011年(13)

2010年(7)

2009年(9)

2008年(4)

2007年(14)

2006年(11)

分类: C/C++

2011-12-10 22:52:43

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

//下面是原地址,怕删除掉,在这里再存一份吧
http://lists.alioth.debian.org/pipermail/ltrace-devel/2006-April/000036.html
阅读(5550) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~