问题背景 #

你碰到的情况很典型：在Windows上的Ubuntu环境（比如WSL）里运行这段C程序时会触发Segmentation fault，但用GDB调试时这个错误却莫名消失了。接下来我们先定位代码里的核心bug，再解释调试时错误消失的原因，最后给出靠谱的修复方案。

完整补全后的原代码 #

/* $Id: count-words.c 858 2010-02-21 10:26:22Z tolpin $ */
#include <stdio.h>
#include <string.h>

/* return string "word" if the count is 1 or "words" otherwise */
char *words(int count) {
    char *words = "words";
    if(count==1)
        words[strlen(words)-1] = '\0';
    return words;
}

/* print a message reporting the number of words */
int print_word_count(char **argv) {
    int count = 0;
    char **a = argv;
    while(*(a++)) ++count; // 补全截断的代码逻辑
    printf("There are %d %s\n", count, words(count));
    return 0;
}

// 假设配套的main函数
int main(int argc, char **argv) {
    return print_word_count(argv);
}

核心Bug定位 #

问题完全出在words函数里：

• "words"是字符串字面量，它会被编译器存储在程序的只读数据段（.rodata）中，这个区域的内存是不允许程序进行写入操作的。
• 当count == 1时，代码尝试修改words[strlen(words)-1]（把最后一个s改成\0），这直接违反了只读内存的访问规则，触发了C语言中的未定义行为，在正常运行环境下就会导致Segmentation fault。

为什么GDB调试时段错误会消失？ #

这是未定义行为的典型表现：调试环境下，编译器通常会关闭优化，甚至可能临时把字符串字面量分配到可写内存区域（方便调试时修改变量）；同时GDB的内存监控机制也会改变程序的内存布局，导致原本会触发的段错误被暂时掩盖。但这只是表象，代码的本质问题依然存在。

修复方案 #

有两种简洁且安全的修复方式，优先推荐第二种：

方案1：使用可写静态缓冲区

把字符串复制到可写的静态内存区域再修改，彻底避免操作只读字面量：

char *words(int count) {
    static char word_buf[6]; // 足够容纳"words"和终止符
    strcpy(word_buf, "words");
    if(count == 1) {
        word_buf[strlen(word_buf)-1] = '\0';
    }
    return word_buf;
}

注意：静态缓冲区是全局共享的，多线程环境下需要考虑线程安全，或者可以让调用者传入自己的缓冲区来规避这个问题。

方案2：直接返回对应字符串字面量（更高效安全）

既然我们只需要返回"word"或"words"，直接返回两个不同的字符串字面量指针即可，完全避免任何写入操作：

char *words(int count) {
    return (count == 1) ? "word" : "words";
}

这种方式既高效又安全，因为我们只是返回只读字面量的指针，并没有尝试修改它，完全符合C语言的规范。

验证效果 #

修复后，无论是否用GDB调试，程序都能正常运行，不会再出现Segmentation fault，同时能正确输出单复数形式的单词描述。

内容的提问来源于stack exchange，提问作者tfreifeld