__static_initialization_and_destruction_0 seg fault

Question

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

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

我最终编译了这个程序，但现在它给了我一个seg错误。我的程序所做的第一件事是将Starting...打印到屏幕上，但这个segfault发生时从未打印过，所以它让我相信这个错误与链接器有关。(即使在make命令失败时，在我修复它之前，它也告诉我存在链接器错误(

以下是valgrind所说的：

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版本11.2.0。

Answer 1

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

链接器不参与程序的运行，因此它不可能是"链接器相关"；。

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

在任何情况下，崩溃都是因为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，还是它已经存在，但无论哪种方式，它都有缺陷。

第页。S.初始化__debug的正确方法可以是：

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

第页。附言：避免使用前缀为__的标识符(如__debug(——它们是保留的。