URN Logo
UNIX Resources » Linux » China Linux Forum » C/C++编程版 » 25 » ptrace跟踪多线程程序的问题
announcement 声明: 本页内容为中国Linux论坛的内容镜像,文章的版权以及其他所有的相关权利属于中国Linux论坛和相应文章的作者,如果转载,请注明文章来源及相关版权信息。
Resources
China Linux Forum(finished)
Linux Forum(finished)
FreeBSD China(finished)
linuxforum.net
  业界新闻与评论
  自由软件杂谈
  IT 人生
  Linux软件快递
  翻译作坊
  Linux图书与评论
  GNU Emacs/XEmacs
  Linux 中文环境和中文化
  Linux桌面与办公软件
  Linux 多媒体与娱乐版
  自由之窗Mozilla
  笔记本电脑上的Linux
  Gentoo
  Debian 一族
  网络管理技术
  Linux 安装与入门
  WEB服务器和FTP服务器
  域名服务器和邮件服务器
  Linux防火墙和代理服务器应用
  文件及打印服务器
  技术培训与认证
  Linux内核技术
  Linux 嵌入技术
  Linux设备驱动程序
  Linux 集群技术
  LINUX平台数据库
  系统和网络安全
  CPU 与 编译器
  系统计算研究所专栏
  Linux下的GUI软件开发
  C/C++编程版
  PHP 技 术
  Java&jsp技术
  Shell编程技术
  Perl 编 程
  Python 编 程
  XML/Web Service 技术
  永远的Unix
  FreeBSD世界
   
ptrace跟踪多线程程序的问题
ptrace跟踪多线程程序的问题 - jiukekou [2005-09-22 12:54 | 646 byte(s)]
 
Re: ptrace跟踪多线程程序的问题 - jiukekou [2005-09-22 15:08 | 197 byte(s)]
 
Subject: ptrace跟踪多线程程序的问题
Author: jiukekou    Posted: 2005-09-22 12:54    Length: 646 byte(s)
[Original] [Print] [Top]
现有一个多线程程序A,在其中用pthread_create创建一个线程B,之后打印一条语句;另一个程序C,在其中fork一个进程,然后在子进程中exec程序A,当然在exec之前调用ptrace的PTRACE_TRACEME选项.在程序C中使用PTRACE_CONT让A执行起来,当A创建了B之后,B的执行正常;但是A在创建B之后的打印语句不能够执行,用waitpid观察,发现A状态是stopped,相关信号是32.这时候,我想应该是由于A被ptrace了所以在它收到任何信号时候就会被阻塞,而发送给它的信号实际上传给了跟踪他的父进程C,不知道我的离解是否正确?接下来我试图恢复A的执行,先使用了PTRACE_CONT,发现还是没有打印语句执行;后来在C中使用kill向A发送信号32,还是没有能够恢复A的执行,到底问题出在哪里呢?是不是应该这样实现对于一个多线程程序的跟踪呢?谢谢!
[Original] [Print] [Top]
Subject: Re: ptrace跟踪多线程程序的问题
Author: jiukekou    Posted: 2005-09-22 15:08    Length: 197 byte(s)
[Original] [Print] [Top]
发现ptrace用错了,应该在进程C中使用PTRACE_CONT来给中断的进程A发信号而不是kill.
接着问问题,应该如何获得进程A中线程B的跟踪信息呢?每个线程的getpid返回值都不同,不过应该如何在进程C中得到呢?谢谢!
[Original] [Print] [Top]
« Previous thread
linux中有类似于进入临界区的函数吗?
C/C++编程版
25
Next thread »
关于read函数
     

Copyright © 2007 UNIX Resources Network, All Rights Reserved.      About URN | Privacy & Legal | Help | Contact us
备案序号: 京ICP备05006143    webmaster: webmaster@unixresources.net
This page created on 2008-07-17 03:52:36, cost 0.042066097259521 ms.