覆盖文件后无法attach调试进程的问题

重现步骤:

1.安装nginx

2.启动nginx进程

3.卸载nginx,删除磁盘上的文件

4.安装nginx

5.导致无法gdb attach pid

1.查询进程启动时间

[[email protected]_JS_011_174 home]# ps -p 181300 -o lstart

STARTED

Wed Dec 10 12:42:52 2014

2.查询文件时间

[[email protected]_JS_011_174 home]# stat /usr/sbin/nginx

File: `/usr/sbin/nginx‘

Size: 1713256         Blocks: 3360 IO Block: 4096 regular file

Device: 802h/2050d        Inode: 27265 Links: 1

Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)

Access: 2015-01-27 16:42:42.000000000 +0800

Modify: 2014-12-09 13:26:43.000000000 +0800

Change: 2014-12-11 03:46:11.000000000 +0800

3.虽然是相同版本的nginx,进程启动后却覆盖了原先的文件,进程启动时间比磁盘文件最后修改时间早,导致进程/pro/pid/exe的软连接和磁盘文件已经对不上号了,无法直接gdb attach该进程

[[email protected]_JS_011_174 home]# gdb -p 181300

GNU gdb (GDB) Red Hat Enterprise Linux (7.2-64.el6_5.2)

Copyright (C) 2010 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law. Type "show copying"

and "show warranty" for details.

This GDB was configured as "x86_64-redhat-linux-gnu".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

Attaching to process 181300

/usr/sbin/nginx (deleted): No such file or directory.

(gdb) bt

#0 0x0050e7ea in ?? ()

Cannot access memory at address 0x8a70ff24

4.安装相应版本的debuginfo

5.用gdb /proc/181300/exe 181300可成功attach进程

时间: 2024-10-07 13:39:26

覆盖文件后无法attach调试进程的问题的相关文章

生成dll文件后,我们开始调试和使用.在系统运行栏输入cmd

命令行状态,我们要注册刚才生成的dll组件,注册方法是可以直接输入 regsvr32 e:\vbdll\aspdll.dll ,为了安装方便,你同时可以写个批处理 文件,这里不一一举例了...好,注册成功! 9.注册完dll组件后,我们针对刚才的组件,按照上面介绍过的方法编写一 个asp文件来调试.代码如下: <% set redll = server.createobject("aspdll.demo") redll.welcomeinfo response.write &qu

C# 中使用Image.FromFile(string path)后,提示该文件正在被另一进程使用XXX的问题

C# 中使用Image.FromFile(string path)后,提示该文件正在被另一进程使用XXX的问题,是因为对应的文件在一直调用 ,其生成的Image对象被Disponse()前都不会被解除锁定,这就造成了此问题,就是在这个图形被解锁前无法对图像进行操作(比如删除,修改等操作). 此问题可以使用下面三个方法解决问题. 方法1:在要进行文件操作前将Image对象销毁. System.Drawing.Image image = System.Drawing.Image.FromFile(f

GPU应用程序Attach调试记录

前期工作 工程路径确认 GPU项目共有6个工程,如图 1-1: 图 1-1  GPU项目工程 这6个工程建议放在同一目录下,否则可能调试时会出现奇怪的问题,比如放在IDE默认的workspace目录下,如图 1-2: 图 1-2  workspace工程目录 测试程序文件名确认 例如测试程序工程叫gpu_test,那么主程序所在的文件名必须是gpu_test.c,不然调试时会报出找不到gpu_test.c警告.示例如图 1-3: 图 1-3  确认测试程序主文件 GDB调试设置 新建调试项目 打

linux 删除文件后空间没有释放的解决办法

清空没用的文件,当我删除文件后,发现可用空间沒有变化 os:centos4.7 现象: 发现当前磁盘空间使用情况: [[email protected] ~]# df -hFilesystem            Size  Used Avail Use% Mounted on/dev/sda1             981M  203M  729M  22% /none                   16G     0   16G   0% /dev/shm/dev/sda9    

很详细、很移动的Linux makefile教程:介绍,总述,书写规则,书写命令,使用变量,使用条件推断,使用函数,Make 的运行,隐含规则 使用make更新函数库文件 后序

很详细.很移动的Linux makefile 教程 内容如下: Makefile 介绍 Makefile 总述 书写规则 书写命令 使用变量 使用条件推断 使用函数 make 的运行 隐含规则 使用make更新函数库文件 后序 近期在学习Linux下的C编程,买了一本叫<Linux环境下的C编程指南>读到makefile就越看越迷糊,可能是我的理解能不行. 于是google到了以下这篇文章.通俗易懂.然后把它贴出来,方便学习. 后记,看完发现这篇文章和<Linux环境下的C编程指南>

Mex文件在VS2010中调试方法

matlab里面无法单步调试mex函数,故需转到VS上面调试,这里采用VS2010. 参考网上很多人写的方法但都很乱,杂,试了多次都没有成功.今天终于解决了,现把方法记录下来. 1.VC中编写Mex函数 新建一个win32 dll 空项目. 2.添加源文件Test.cpp,编写MEX函数,MEX函数编写方法这里不赘述了. 3.配置项目属性. 打开项目属性配置页,C++ -> 附加包含目录 加入MATLAB安装目录下的 \extern\include 路径. 连接器 -> 附加库目录 加入MAT

FileStram文件正由另一进程使用,该进程无法访问该文件,解决方法

异常提示: “文件正由另一进程使用,该进程无法访问该文件”. 打开一个文件后,尝试重新打开一次该文件,或者打开该文件后想对该文件进行其他操作的时候,就容易出现这个错误提示. 通常造成该错误的原因是构造System.IO.FileStream时参数设置有问题. 一般习惯直接使用: FileStream fs = new FileStream(fileName, FileMode.Open) 这个方法打开文件的时候是以只读共享的方式打开的,但若此文件已被一个拥有写权限的进程打开的话,就无法读取了,

文件正由另一进程使用,该进程无法访问该文件,解决方法

异常提示: “文件正由另一进程使用,该进程无法访问该文件”. 打开一个文件后,尝试重新打开一次该文件,或者打开该文件后想对该文件进行其他操作的时候,就容易出现这个错误提示. 通常造成该错误的原因是构造System.IO.FileStream时参数设置有问题. 一般习惯直接使用: FileStream fs = new FileStream(fileName, FileMode.Open) 这个方法打开文件的时候是以只读共享的方式打开的,但若此文件已被一个拥有写权限的进程打开的话,就无法读取了,

删除文件后,磁盘空间没有释放的处理记录

问题说明: IDC里的一台服务器的/分区使用率爆满了!已达到100%!经查看发现有个文件过大(80G),于是在跟有关同事确认后rm -f果断删除该文件.但是发现删除该文件后,/分区的磁盘空间压根没有释放出来,使用率还是100%!这是为什么呢?? [[email protected] ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/VolGroup00-LogVol00 58G 7.8G 47G 100% / tmp