__static_initialization_and_destruction_0断层

Question

我正在开发一个C++程序，一切都很好。然后，当我编程时，我运行make并像往常一样运行我的程序。但在这一切的执行过程中，我的电脑崩溃并关闭了自己。我重新打开我的电脑，再次运行make，但这次它给了我一堆错误。

一切似乎都关闭了，好像我的整个电脑都坏了。但是，除了与我的程序相关的内容之外，我的操作系统中所有的东西都是按预期运行的。我试过做一个新的c++项目，它运行得很好。我试着删除这个项目，并从github重新编译它，但没有结果。

我最终成功地编译了这个程序，但现在它给了我一个seg错误。我的程序做的第一件事就是将Starting...打印到屏幕上，但是这个分段错误没有打印出来，所以我相信这个错误与链接器有关。(即使make命令失败了，在我修复它之前，它也告诉我有一个链接器错误)

下面是瓦兰的话：

turgut@turgut-N56VZ:~/Desktop/CppProjects/videoo-render$ valgrind bin/Renderer
==7521== Memcheck, a memory error detector
==7521== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==7521== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==7521== Command: bin/Renderer
==7521== 
==7521== Invalid read of size 1
==7521==    at 0x484FBD4: strcmp (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==7521==    by 0x121377: __static_initialization_and_destruction_0 (OpenGLRenderer.cpp:111)
==7521==    by 0x121377: _GLOBAL__sub_I__ZN6OpenGL7Texture5max_zE (OpenGLRenderer.cpp:197)
==7521==    by 0x659FEBA: call_init (libc-start.c:145)
==7521==    by 0x659FEBA: __libc_start_main@@GLIBC_2.34 (libc-start.c:379)
==7521==    by 0x1216A4: (below main) (in /home/turgut/Desktop/CppProjects/videoo-render/bin/Renderer)
==7521==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==7521== 
==7521== 
==7521== Process terminating with default action of signal 11 (SIGSEGV)
==7521==  Access not within mapped region at address 0x0
==7521==    at 0x484FBD4: strcmp (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==7521==    by 0x121377: __static_initialization_and_destruction_0 (OpenGLRenderer.cpp:111)
==7521==    by 0x121377: _GLOBAL__sub_I__ZN6OpenGL7Texture5max_zE (OpenGLRenderer.cpp:197)
==7521==    by 0x659FEBA: call_init (libc-start.c:145)
==7521==    by 0x659FEBA: __libc_start_main@@GLIBC_2.34 (libc-start.c:379)
==7521==    by 0x1216A4: (below main) (in /home/turgut/Desktop/CppProjects/videoo-render/bin/Renderer)
==7521==  If you believe this happened as a result of a stack
==7521==  overflow in your program's main thread (unlikely but
==7521==  possible), you can try to increase the size of the
==7521==  main thread stack using the --main-stacksize= flag.
==7521==  The main thread stack size used in this run was 8388608.
==7521== 
==7521== HEAP SUMMARY:
==7521==     in use at exit: 72,741 bytes in 3 blocks
==7521==   total heap usage: 3 allocs, 0 frees, 72,741 bytes allocated
==7521== 
==7521== LEAK SUMMARY:
==7521==    definitely lost: 0 bytes in 0 blocks
==7521==    indirectly lost: 0 bytes in 0 blocks
==7521==      possibly lost: 0 bytes in 0 blocks
==7521==    still reachable: 72,741 bytes in 3 blocks
==7521==         suppressed: 0 bytes in 0 blocks
==7521== Rerun with --leak-check=full to see details of leaked memory
==7521== 
==7521== For lists of detected and suppressed errors, rerun with: -s
==7521== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)
turgut@turgut-N56VZ:~/Desktop/Cpp

OpenGLRenderer.cpp:197只是文件的末尾，下面是OpenGLRenderer.cpp:111中所写的内容

static bool __debug = strcmp(getenv("DEBUG"), "true") == 0;

它说strcmp有一个错误，但是我尝试在不同的项目上使用这个函数，它运行得很好。

这是什么原因？我上的是ubuntu 22.04，gcc Verison11.2.0。

Answer 1

这个分段错误是在没有打印的情况下发生的，所以它使我相信这个错误与链接器有关。

链接器不涉及您的程序运行，所以它不可能是“链接器相关”。

这里有一个动态加载程序(如果您的程序使用共享库)，所以也许这就是您的意思。

在任何情况下，崩溃的发生都是因为OpenGLRenderer.cpp:111 (可能在libGL.so中)调用strcmp()，其中一个参数是NULL (这不是一件有效的事情)。这确实发生在main之前。

这一行：

static bool __debug = strcmp(getenv("DEBUG"), "true") == 0;

是错误:当环境中没有设置DEBUG时，它会崩溃(在这种情况下，getenv("DEBUG")将返回NULL )。

作为解决办法，您可以在运行程序之前运行export DEBUG=off，然后崩溃就会消失。

目前还不清楚您是否亲自将这一行插入OpenGLRenderer.cpp，或者它是否已经存在，但无论是哪种方式，它都是错误的。

初始化__debug的正确方法可以是：

static const char *debug_str = getenv("DEBUG");
static const bool debug = strcmp(debug_str == NULL ? "off" : debug_str, "true") == 0;

避免使用以__ (如__debug)为前缀的标识符--它们是预留。