在Windows下用cygwin编译的C程序可以运行，在Linux下会出现分段错误。 cygwin GCC“不好”吗？

Question

在我的编程 102 课程中，我们被要求提供在 Linux 下编译和运行的 C 代码。 我的硬盘上没有足够的空闲空间来安装 Linux 和 Windows，因此我使用 cygwin 来编译我的程序。

我必须提供的最新程序在 cygwin 下编译并运行良好。 它在 Linux 下编译得很好，但执行到一半时会产生分段错误。 我向给我们上课的研究生解释了这一点，他说 cygwin 版本的 GCC 允许编译和执行更草率的代码。

我通过谷歌找到的一些参考文献还不是结论性的。 我发现一个线程说Linux下seg错误的原因是内存泄漏。 为什么这不会影响 cygwin 版本？

我会使用大学的计算机，但我不能在它们上使用 Subversion，这会严重阻碍我的工作。 （我是编码新手，经常需要能够恢复到 X 版本之前的版本）。

cygwin 版本的 GCC 编译的代码真的更“宽松”吗？ 如果是这样，编码时是否有任何明显的问题需要注意？ 是否有其他方法可以编写在 Linux 下运行的代码？

编辑

感谢您的回复。 我在原来的帖子中不够明确：我的代码中存在一个错误对我来说几乎是理所当然的（我对编程很陌生，毕竟，当涉及到 C 时，我真的很绿）。 我的助教暗示 cygwin 的 GCC 是一种比 GNU/Linux 下的编译器更不可靠的编译器 - 允许运行更草率的代码。 我发现这很奇怪，因此在互联网上进行了搜索，但找不到任何与该事实相关的参考资料。

我不只是把责任归咎于编译器和我的代码，我还想知道程序在 Windows 下运行而在 Linux 下崩溃的原因是什么。 关于 Windows/Linux 下不同的内存管理器和堆/堆栈布局的答复在这方面进行了说明。

cygwin 的 GCC 与 GNU/Linux 一样“好”，并且我的有缺陷的程序在其中一个操作系统下运行而不是在另一个操作系统下运行是底层操作系统/纯粹是运气，这样的结论是否非常正确？

关于发布源代码，这是一项家庭作业，所以如果可能的话，我更愿意自己找到问题:)

编辑2

我已经接受了 jalf 的回答，因为它讨论了程序运行的原因在 Windows 下而不是在 Linux 下，这是我真正想知道的。 感谢所有其他贡献者，他们的回复都非常有趣且内容丰富。

当我发现问题并修复它时，我将上传一个包含此非工作版本的所有源代码的 zip 文件，以防有人好奇我到底做了什么:)

编辑 3

，我发现了问题，而且确实是由于指针造成的。 我试图从函数返回一个指针。 我试图返回的指针是在函数内部声明的，因此函数执行后就会被销毁。 有问题的代码在第 22-24 行被注释掉。

请随意嘲笑我的代码。

/**
*  Returns array of valid searches based on current coordinate
*/
void determine_searches(int row, int col, int last_row, int last_col, int *active_search){
    // define coordinate categories and related valid search directions
    int Library0[] = {2, 3, 4, -1};
    int Library1[] = {4, 5, 6, -1};
    int Library2[] = {2, 3, 4, 5, 6, -1};
    int Library3[] = {0, 1, 2, 3, 4, 5, 6, 7, -1};
    int Library4[] = {0, 1, 2, -1};
    int Library5[] = {0, 6, 7, -1};
    int Library6[] = {0, 1, 2, 6, 7, -1};
    int Library7[] = {0, 1, 2, 3, 4, -1};
    int Library8[] = {0, 4, 5, 6, 7, -1};

    int * Library[] = { 
        Library0, Library1, Library2,
        Library3, Library4, Library5,
        Library6, Library7, Library8,
    };

    // declare (and assign memory to) the array of valid search directions that will be returned
    //int *active_search;
    //active_search = (int *) malloc(SEARCH_DIRECTIONS * sizeof(int));


    // determine which is the correct array of search directions based on the current coordinate
    // top left corner
        int i = 0;
    if(row == 0 && col == 0){
        while(Library[0][i] != -1){
            active_search[i] = Library[0][i];
            i++;
        }
    }
    // top right corner
    else if(row == 0 && col == last_col){
        while(Library[1][i] != -1){
            active_search[i] = Library[1][i];
            i++;
        }
    }
    // non-edge columns of first row
    else if(row == 0 && (col != 0 || col != last_col)){
        while(Library[2][i] != -1){
            active_search[i] = Library[2][i];
            i++;
        }
    }
    // non-edge coordinates (no edge columns nor rows)
    else if(row != 0 && row != last_row && col != 0 && col != last_col){
        while(Library[3][i] != -1){
            active_search[i] = Library[3][i];
            i++;
        }
    }
    // bottom left corner
    else if(row == last_row && col == 0){
        while(Library[4][i] != -1){
            active_search[i] = Library[4][i];
            i++;
        }
    }
    // bottom right corner
    else if(row == last_row && col == last_col){
        while(Library[5][i] != -1){
            active_search[i] = Library[5][i];
            i++;
        }
    }
    // non-edge columns of last row
    else if(row == last_row && (col != 0 || col != last_col)){
        while(Library[6][i] != -1){
            active_search[i] = Library[6][i];
            i++;
        }
    }
    // non-edge rows of first column
    else if((row != 0 || row != last_row) && col == 0){
        while(Library[7][i] != -1){
            active_search[i] = Library[7][i];
            i++;
        }
    }
    // non-edge rows of last column
    else if((row != 0 || row != last_row) && col == last_col){
        while(Library[8][i] != -1){
            active_search[i] = Library[8][i];
            i++;
        }
    }
    active_search[i] = -1;
}

Answer 1

就像其他人所说的那样，您可能想在此处发布一些代码，即使这不是您问题的真正要点。 让这里的每个人都仔细检查您的代码并看看他们是否能找到导致段错误的原因，这可能仍然是一个很好的学习经历。

但是，问题是，影响 C 程序的因素有很多依赖于平台的因素，而且基本上是随机的。 虚拟内存意味着有时，访问未分配的内存似乎是有效的，因为您访问了先前某个点分配的页面的未使用部分。 其他时候，它会出现段错误，因为您访问的页面根本没有分配给您的进程。 这确实是无法预测的。 这取决于您的内存分配位置，是在页面的边缘还是在中间？ 这取决于操作系统和内存管理器，以及到目前为止已经分配了哪些页面，并且……您明白了。 不同的编译器、同一编译器的不同版本、不同的操作系统、系统上安装的不同软件、驱动程序或硬件，无论访问未分配的内存时是否出现段错误，任何事情都可能发生变化。

至于 TA 声称 cygwin 更“宽松”，那是一派胡言，原因很简单。
两个编译器都没有发现这个错误！ 如果“本机”GCC 编译器确实不那么宽松，它会在编译时给出错误。 段错误不是由编译器生成的。 编译器无法做太多事情来确保您得到段错误而不是看起来可以工作的程序。

Answer 2

我还没有听说过有关 Cygwin 下 GCC 怪异的任何具体信息，但就您而言，使用 gcc 的 -Wall 命令行选项来显示所有警告，看看它是否发现任何可能导致的问题可能是个好主意代码中的段错误。

Answer 3

你的代码中肯定有一个错误。 Windows 内存管理器可能比 Linux 内存管理器更宽松。 在 Windows 上，您可能会用内存做坏事（例如覆盖数组边界、内存泄漏、双重释放等），但它会让您逃脱惩罚。 与此相关的著名故事可以在 http://www.joelonsoftware.com/articles/APIWar.html （搜索“SimCity”（有点长） ） 文章）。

Answer 4

几乎可以肯定是指针错误或缓冲区溢出，可能是未初始化的变量。

未初始化的指针通常不会指向任何东西，但有时它会指向某些东西； 读取它或写入它通常会使程序崩溃，但也可能不会。

从释放的内存中进行写作或阅读是同一个故事； 你可能会侥幸逃脱，但也可能不会。

这些情况具体取决于堆栈、堆的布局方式以及运行时正在执行的操作。 很可能制作出一个在一个编译器/运行时组合上运行而不是在另一个编译器/运行时组合上运行的糟糕程序，仅仅是因为在一个编译器/运行时组合上它覆盖了一些无关紧要的东西（很多），或者未初始化的变量“碰巧”包含一个有效的变量。它所使用的上下文的值。

Answer 5

Cygwin 的 gcc 版本可能有其他默认标志和调整设置（例如 wchar_t 为 2 个字节），但我怀疑它的代码是否特别“宽松”，即便如此 - 你的代码不应该崩溃。 如果是这样，那么您的代码中很可能存在需要修复的错误。 例如，您的代码可能取决于 wchar_t 的特定大小，或者可能执行根本无法保证正常工作的代码，例如写入字符串文字。

如果你编写干净的代码，那么它也可以在 Linux 上运行。 我目前正在运行 Firefox 和 KDE 桌面，它们由数百万行 C++ 行组成，我没有看到这些应用程序崩溃:)

我建议您将代码粘贴到您的问题中，以便我们可以查看出了什么问题。

同时，您可以在 gdb 中运行您的程序，它是 Linux 的调试器。 您还可以在启用所有挡泥板检查和启用所有警告的情况下进行编译。 mudflaps 在运行时检查您的代码是否存在各种违规行为：

[js@HOST2 cpp]$ cat mudf.cpp
int main(void)
{
  int a[10];
  a[10] = 3;  // oops, off by one.
  return 0;
}
[js@HOST2 cpp]$ g++ -fmudflap -fstack-protector-all -lmudflap -Wall mudf.cpp
[js@HOST2 cpp]$ MUDFLAP_OPTIONS=-help ./a.out
  ... showing many options ...
[js@HOST2 cpp]$ ./a.out 
*******                 
mudflap violation 1 (check/write): time=1234225118.232529 ptr=0xbf98af84 size=44
pc=0xb7f6026d location=`mudf.cpp:4:12 (main)'                                   
      /usr/lib/libmudflap.so.0(__mf_check+0x3d) [0xb7f6026d]                    
      ./a.out(main+0xb9) [0x804892d]                                            
      /usr/lib/libmudflap.so.0(__wrap_main+0x4f) [0xb7f5fa5f]                   
Nearby object 1: checked region begins 0B into and ends 4B after                
mudflap object 0x9731f20: name=`mudf.cpp:3:11 (main) int a [10]'                
bounds=[0xbf98af84,0xbf98afab] size=40 area=stack check=0r/3w liveness=3        
alloc time=1234225118.232519 pc=0xb7f5f9fd                                      
number of nearby objects: 1                                                     
*** stack smashing detected ***: ./a.out terminated                             
======= Backtrace: =========
....

您可以执行许多 mudflap 检查，上面使用默认选项运行 a.out。 另一种有助于解决此类错误的工具是 valgrind，它也可以帮助您发现泄漏或通过一个错误来关闭，如上面所示。 将环境变量“MALLOC_CHECK_”设置为 1 也会打印违规消息。 有关该变量的其他可能值，请参阅 malloc 的联机帮助页。

要检查程序崩溃的位置，可以使用 gdb：

[js@HOST2 cpp]$ cat test.cpp
int main() {
    int *p = 0;
    *p = 0;
}
[js@HOST2 cpp]$ g++ -g3 -Wall test.cpp
[js@HOST2 cpp]$ gdb ./a.out
...
(gdb) r
Starting program: /home/js/cpp/a.out

Program received signal SIGSEGV, Segmentation fault.
0x080483df in main () at test.cpp:3
3           *p = 0;
(gdb) bt
#0  0x080483df in main () at test.cpp:3
(gdb)

使用 -g3 编译代码以包含许多调试信息，因此 gdb 可以帮助您找到程序崩溃的精确行。 所有上述技术同样适用于 C 和 C++。

Answer 6

GCC 的版本可能不是问题。 这更有可能是运行时库中的差异以及代码中的错误，而在针对 Windows 版本的运行时运行时，这些错误并未显现出来。 如果您想要更具体的答案，您可能需要发布段错误的代码和更多背景信息。

一般来说，最好在您将用于运行代码的环境下进行开发。

Answer 7

分段错误意味着您尝试访问无法访问的内存，这通常意味着您尝试取消引用空指针或双重删除内存或获得野指针。 有两个原因可能导致您在 cygwin 上表现良好，但在 Linux 上却表现不佳：要么是内存管理器的问题，要么您在其中一个方面比另一个更幸运。 几乎可以肯定您的代码有错误。

要解决此问题，请查看您的指针使用情况。 考虑用智能指针替换原始指针。 考虑搜索删除并立即将指针归零（尝试删除空指针是安全的）。 如果您可以破解 Linux，请尝试通过 gdb 获取堆栈跟踪，并查看发生的行是否有任何明显错误。 检查如何使用所有未初始化的指针。 如果您可以使用内存调试工具，请使用它。

Answer 8

您是否做出任何特定于平台的假设，例如数据类型的大小，struct 中的“http://en.wikipedia.org/wiki/Data_struction_alignment” rel="nofollow noreferrer">数据结构对齐，或 字节序？

Answer 9

一些提示：

1. 发布您的代码。 我敢打赌您会得到一些好的输入，使您成为更好的程序员。

2. 使用-wall选项打开警告并纠正报告的任何问题。 同样，它可以帮助您成为一名更好的程序员。

3. 使用调试器单步调试代码。 除了帮助您了解问题所在之外，它还将帮助您成为一名更好的程序员。

4. 继续使用 Subversion 或其他源代码控制系统。

5. 在确定已查明问题之前，切勿责怪编译器（或操作系统或硬件）。 即使如此，也要对自己的代码持怀疑态度。

---

Linux 上的 GCC 的源代码与 Cygwin 上的 GCC 相同。 由于 Cygwin POSIX 仿真层和底层 Windows API，平台之间存在差异。 额外的层可能比底层硬件更宽容，但这不能指望。

由于这是家庭作业，我认为发布代码是一个更好的主意。 还有什么比从专业程序员那里获取输入更好的学习方法呢？ 不过，我建议您在附近的评论中注明您实施的任何建议。

Answer 10

分段错误是访问不存在（或先前释放）地址的内存的结果。 我发现非常有趣的是，代码在 cygwin 下没有出现段错误。 这可能意味着您的程序使用了指向其他进程地址空间的野指针，并且实际上能够读取它（喘息），或者（更有可能）直到程序在 Linux 下运行时才到达实际导致段错误的代码。

我建议如下：

1. 粘贴您的代码，因为这是一个非常有趣的问题
2. 将其副本发送给 cygwin 开发人员
3. 如果您需要编写更多在 Linux 下运行的程序，请获取便宜的 Linux VPS，这将使您的生活变得更加美好更轻松。

一旦您在 Linux 下工作（即进入您的 VPS），请尝试使用以下程序：

• GDB
• Valgrind
• strace

另外，您可以尝试像 electric fence 这样的库来捕获程序运行时发生的此类事情。

最后，确保将 -Wall 传递给 gcc，您想要它传达的警告。

Answer 11

我不想听起来很粗鲁，但可能是你的代码不好，而不是编译器。 ;) 这样的问题实际上比您想象的更常见，因为不同的操作系统和编译器将采用不同的方式在堆栈和堆中组织应用程序的数据。 前者可能特别有问题，特别是如果您最终覆盖堆栈上的内存，或者引用系统决定用于其他用途的已释放内存。 所以基本上，有时你可能会侥幸逃脱，但有时你的应用程序会卡住并死掉。 无论哪种方式，如果它出现段错误，那是因为您试图引用不允许的内存，所以它在另一个系统/编译器下没有崩溃更像是一个“巧合”。

但实际上，段错误就是段错误，因此您应该调试代码以查找内存损坏，而不是调整编译器的配置来找出问题所在。

编辑：好的，我现在明白你的意思了...我以为你会带着“X 很糟糕，但 Y 工作得很好！”的想法来解决这个问题。 态度，但似乎是你的TA有这种态度。 ；）

无论如何，这里有一些调试问题的更多提示，例如：

• 寻找指针算术，引用/取消引用可能的“doh！” 错误。 任何添加/减去一个（也称为栅栏错误）的地方都特别值得怀疑。
• 注释掉问题区域周围对 malloc/free 的调用，以及使用这些指针的任何关联区域。 如果代码不再崩溃，那么您就朝着正确的方向前进了。
• 假设您至少已经确定了代码崩溃的一般区域，请在其中插入早期的 return 语句并找到代码不会崩溃的点。 这可以帮助找到该点和代码实际崩溃位置之间的某个区域。 请记住，像这样的段错误不一定直接发生在错误所在的代码行。
• 使用系统上可用的内存调试工具。
  • 在 Unix 上，请查看本关于在 Unix 上调试内存的指南，以及valgrind 分析器（@Sol，感谢提醒我这一点）
  • 在 Visual Studio/Windows 上，您的好伙伴CrtCheckMemory() 非常方便。 另外，请阅读 CRT 内存调试模式，因为它们是其中之一在 VS 中工作的更好的功能。 很多时候，一旦您记住了各种模式，只需在 VS 中打开一个内存选项卡就足以诊断此类错误。
  • 在 Mac OSX 中，您可以在 malloc_error_break（来自 gdb 或 Xcode）上设置断点，这会导致调试器在 malloc 检测到内存损坏时中断。 我不确定这是否在其他 UNIX 版本中可用，但快速谷歌搜索似乎表明它仅适用于 Mac。 另外，valgrind 似乎在 OSX 上存在，看起来相当“实验”。