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

Question

Hi can somebody please explain what this valgrind output means and how I should go about fixing this ?? The output I am posting currently is a part of the actual terminal output. The rest is also similar and mostly the same errors are listed.

This is for a C++ program using SDL2.

The relevant code is really long so I will add whatever is asked in comments.

Is this happening due to some SDL_Surface* s? But I made sure to free all of those before returning from main(). Also, my SDL_Window* is global. Can that cause a problem.

This output leads to a segfault that arises only in Ubuntu and not in Mac OSX!! I know that Xcode on MAC initializes uninitialized variables and proceeds but the same doesnt happen in Ubuntu. But the valgrind output doesn't show any uninit variables even with trace-origins = yes in memcheck tool.

Also, I don't have any functions named call_init or_dl_init or 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)

Answer 1

Without knowing the program, the Valgrind output is completely meaningless. For example, you can choose to allocate something globally and never delete it, not even on shutdown. It doesn't hurt in any way, but Valgrind will warn you about a leak, because that's what it is formally. None of this should cause any segfaults though and your interpretation that the output causes it is very questionable.

Now, concerning the dl_* functions, those are from the dynamic loader on Linux, so chances are that you didn't cause them. Probably they are something to ignore, which you could try to reproduce by stripping your program down to the point where you are sure that your code doesn't cause any issues.

Concerning the global, it doesn't matter either, because a raw pointer doesn't have any destructor. However, if you don't release the resource it represents, Valgrind will report that as error.