C++ 解释C+的valgrind输出+/SDL2程序

嗨，有人能解释一下这个valgrind输出是什么意思吗？我应该如何着手解决这个问题？？我当前发布的输出是实际终端输出的一部分。其余的也类似，并且列出了大部分相同的错误

这是一个使用SDL2../P>的C++程序。 相关的代码非常长，所以我将在注释中添加任何问题

这是因为一些SDL_曲面引起的吗？但我确保在从main（）返回之前释放所有这些。此外，我的SDL_窗口*是全局的。这会引起问题吗

这个输出导致了一个segfault，它只在Ubuntu中出现，而不是在MacOSX中出现！！我知道MAC上的Xcode会初始化未初始化的变量并继续进行，但在Ubuntu中不会发生同样的情况。但是，即使在memcheck工具中trace origins=yes，valgrind输出也不会显示任何uninit变量

而且，我没有任何名为call_init、dl_init或dl_open_worker的函数

==17744== 402 bytes in 7 blocks are possibly lost in loss record 506 of 630
==17744==    at 0x4C2CC90: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17744==    by 0xD3A56A1: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==17744==    by 0xD3A5944: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==17744==    by 0xD3965C5: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==17744==    by 0xD152EAF: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==17744==    by 0x4010139: call_init.part.0 (dl-init.c:78)
==17744==    by 0x4010222: call_init (dl-init.c:36)
==17744==    by 0x4010222: _dl_init (dl-init.c:126)
==17744==    by 0x4014C6D: dl_open_worker (dl-open.c:577)
==17744==    by 0x400FFF3: _dl_catch_error (dl-error.c:187)
==17744==    by 0x40143AA: _dl_open (dl-open.c:661)
==17744==    by 0x601E02A: dlopen_doit (dlopen.c:66)
==17744==    by 0x400FFF3: _dl_catch_error (dl-error.c:187)
==17744== 512 bytes in 1 blocks are possibly lost in loss record 519 of 630
==17744==    at 0x4C2CC90: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17744==    by 0xD3D3689: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==17744==    by 0xD412E86: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==17744==    by 0xD3D1288: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
==17744==    by 0xB198E60: ??? (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0)
==17744==    by 0xB16D9D3: ??? (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0)
==17744==    by 0xB16A0BA: ??? (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0)
==17744==    by 0xB16A932: glXChooseVisual (in /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0)
==17744==    by 0x4EEDD9E: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==17744==    by 0x4EEDFD0: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==17744==    by 0x4EE2BE5: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==17744==    by 0x4EE477B: ??? (in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.2.0)
==17744== 

==17744== 
==17744== LEAK SUMMARY:
==17744==    definitely lost: 73,806 bytes in 8 blocks
==17744==    indirectly lost: 0 bytes in 0 blocks
==17744==      possibly lost: 1,962,378 bytes in 4,720 blocks
==17744==    still reachable: 2,908,902 bytes in 5,710 blocks
==17744==         suppressed: 0 bytes in 0 blocks
==17744== Reachable blocks (those to which a pointer was found) are not shown.
==17744== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==17744== 
==17744== For counts of detected and suppressed errors, rerun with: -v
==17744== ERROR SUMMARY: 194 errors from 186 contexts (suppressed: 5 from 1)

---

在不了解程序的情况下，Valgrind输出完全没有意义。例如，您可以选择全局分配某些内容，并且永远不会删除它，即使在关机时也不会。这不会造成任何伤害，但Valgrind会警告您泄漏，因为这是正式的。但是，所有这些都不应导致任何SEGFULTS，您对输出导致它的解释是非常值得怀疑的

现在，关于

dl.*

函数，它们来自Linux上的动态加载程序，所以很可能不是您造成的。可能它们是可以忽略的，您可以尝试通过剥离程序来复制它们，直到您确信代码不会导致任何问题

关于全局，这也无关紧要，因为原始指针没有任何析构函数。但是，如果您不释放它所代表的资源，Valgrind会将此报告为错误