c - 了解 gdb 中的这种不稳定行为

标签 c debugging gcc gdb

考虑以下代码:

#include <stdio.h>
#include <ctype.h>

char* Mstrupr(char* szCad); 

int main()
{
    char szCadena[] = "This string should print well.";
    printf("%s\n", Mstrupr(szCadena));
    printf("%s\n", Mstrupr("This string should fail."));
    return 0;
}

char* Mstrupr(char* szCad) 
{
    int i;
    for (i=0; szCad[i]; i++) 
        szCad[i] = toupper(szCad[i]);
    return szCad;
}

对 Mstrupr 的第二次调用无法在 Linux 上正确运行,因为它接收的字符串是文字(而不是字符数组)。当整个程序在 gdb 上运行时它也会失败,但是当一个断点被添加到 main 并且程序通过 gdb 的下一个命令运行时,第二个字符串被大写并打印出来。 为什么?我认为这不应该,但我的导师坚持认为这是 gdb 设计的一部分。

最佳答案

我不认为它是 gdb 设计的一部分。这似乎是一种意外的副作用; gdb 在设置断点时使代码段可写,因此覆盖文字的代码现在可以工作了

事实上,没有调试器设计者会故意让他们的调试器改变程序的行为;这使得调试变得非常困难

关于c - 了解 gdb 中的这种不稳定行为,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3806420/

相关文章:

c - C 函数中的汇编代码

linux - 如何获得二进制文本部分的偏移量和大小?

无法用c中的for循环写入文本文件

c - C 中的 POSIX 到 DOS 以及 DOS 到 POSIX 路径转换

c - 如果不同的进程有自己的内存空间,局部变量的地址怎么可能相同呢?

c - C中数组的问题

javascript - 未捕获的TypeError:无法读取未定义的属性'preventDefault'

linux - 什么是 linux 命令来获取正在运行的进程的堆栈而不必在调试器中附加它?

python - Stty 疯狂地使用 Python 子进程

c++ - 试图了解 GCC 错误