Question

我已经成功使用gdb了一段时间，但我最近升级了我的Ubuntu版本，现在看来如果我以root身份运行，我只能获得gdb才能成功运行我的程序。也就是说，

~ %  gdb -q sleep -ex 'run 60'
Reading symbols from /bin/sleep...(no debugging symbols found)...done.
Starting program: /bin/sleep 60
tcsh: Permission denied.
During startup program exited with code 1.
(gdb)

失败，而

~ %  sudo gdb -q sleep -ex 'run 60'
Reading symbols from /bin/sleep...(no debugging symbols found)...done.
Starting program: /bin/sleep 60
Running .tcshrc
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
^C
Program received signal SIGINT, Interrupt.
0x00007ffff7adada0 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:82
82  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb)

的工作原理。一个线索是，在第一种情况下，gdb启动不运行我的.tcshrc文件，而在第二种情况下它运行。

这似乎是一个简单的权限问题，我必须一次修复，因为在过去，我从来不需要以root身份运行gdb。然而，经过大量的谷歌搜索，我无法找到我可能做过的事情（如果我确实做了一些事情）。一个可能的解决方案 - 设置ptrace permissions - 似乎没有用。

是否需要执行某些操作才能允许gdb运行没有root权限的程序？我知道在OSX中，gdb必须经过编码。 Ubuntu / Linux有类似的东西吗？

Answer 1

这里有一些调试gdb问题的想法。评论对于这些事情并不可行，所以我把它们写进了答案。

尝试-n选项以确保没有加载init文件。

使用echo程序而不是sleep 60来简化调试（示例中的SIGINT事件可能特定于睡眠程序。

运行gdb -batch并将其余内容放入~/.gdbinit：

file /bin/echo
run

添加set verbose on。

完成后不要忘记清理~/.gdbinit。

Answer 2

这不是一个完整的答案，但事情变得越来越清晰。上面的提示非常有帮助。我创建了以下.gdbinit文件

show environment SHELL
file /bin/echo
run 'Goodbye'

结果很有意思。如果SHELL=/usr/tcsh，我收到权限错误，即

~ %  setenv SHELL /bin/tcsh
~ %  gdb -q -batch
SHELL = /bin/tcsh
tcsh: Permission denied.
/home/calhoun/.gdbinit:12: Error in sourced command file:
During startup program exited with code 1.

取消设置shell变量：

~ %  unsetenv SHELL
~ %  gdb -q -batch
Environment variable "SHELL" not defined.
Goodbye
[Inferior 1 (process 6992) exited normally]

在这种情况下，run使用/bin/sh扩展参数列表。将SHELL设置为/bin/bash或/bin/dash将使用这些shell扩展参数列表，例如

~ %  setenv SHELL /bin/bash
~ %  gdb -q -batch
SHELL = /bin/bash

warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
Goodbye
[Inferior 1 (process 7280) exited normally]

奇怪的是，＆＃34;无负载部分＆＃39;只有在显式设置shell变量时才会发生错误。另一个谜。

为什么/bin/tcsh无法正常工作仍然令人费解。就我而言，/bin/tcsh上的权限是

~ %  ls -lh /bin/tcsh
lrwxrwxrwx 1 root root 13 Oct 14  2011 /bin/tcsh -> /usr/bin/tcsh
~ %  ls -lh /usr/bin/tcsh
-rwxr-xr-x 1 root root 382K Oct 14  2011 /usr/bin/tcsh

我的.tcshrc文件中的问题也可能导致shell在此非交互模式下崩溃。

Answer 3

我将登录shell更改为bash，gdb不再需要root权限进行调试。这是最新的：

我的.gdbinit文件：

(bash) ~ % more .gdbinit
show environment SHELL
file /bin/echo
run 'running .gdbinit'
(bash) ~ %

以及运行gdb的结果：

(bash) ~ % gdb -q -batch
SHELL = /bin/bash
running .gdbinit
[Inferior 1 (process 3174) exited normally]
(bash) ~ %

我仍然不明白为什么tcsh没有工作，但我很想知道。因此，如果有人有可能的解释，请发表评论。

Answer 4

检查程序是否具有可执行权限。

ls -l .
-rw-r--r-- 1 opt opt 30010 Aug 16 16:13 test

调试时可能会导致类似“测试”的情况。

Answer 5

我通过LaunchCompleteCommand在launch.json文件中指定了 Linux ...

MS具有3种不同的方式来指定CPU ... Windows，Linux或OSx

来自https://code.visualstudio.com/docs/cpp/launch-json-reference

    "launchCompleteCommand": "exec-run",
      "linux": {
        "MIMode": "gdb",
        "miDebuggerPath": "/usr/bin/gdb"
      },

在我的launch.json文件中，将此LaunchCompleteCommand部分粘贴在setupCommands部分之后。

Answer 6

我遇到了同样的问题，原因是有人在gdb可执行文件中设置了粘滞位：

cruiz> ls -l /usr/bin/gdb

-rwsr-sr-x 1 root root 4190760 2010-05-05 07:55 /usr/bin/gdb*

我更改了它（chmod 755 /usr/bin/gdb），现在它可以正常工作。

在：

cruiz> gdb
...

(gdb) shell

csh: Permission denied.

改变之后：

cruiz> gdb

(gdb) shell

cruiz>

为什么gdb需要root权限才能调试用户程序？

6 个答案: