解释 C++/SDL2 程序的 valgrind 输出 [英] Interpreting valgrind output for a C++/SDL2 program

查看:50
本文介绍了解释 C++/SDL2 程序的 valgrind 输出的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

有人可以解释一下这个 valgrind 输出的含义以及我应该如何解决这个问题吗??我目前发布的输出是实际终端输出的一部分.其余的也类似,并且列出了大部分相同的错误.

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.

这是用于使用 SDL2 的 C++ 程序.

This is for a C++ program using SDL2.

相关代码真的很长,所以我会在评论中添加任何要求.

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

这是由于某些 SDL_Surface* 导致的吗?但我确保在从 main() 返回之前释放所有这些.另外,我的 SDL_Window* 是全局的.这会导致问题吗.

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.

此输出导致段错误仅在 Ubuntu 中出现,而不在 Mac OSX 中出现!!我知道 MAC 上的 Xcode 会初始化未初始化的变量并继续进行,但在 Ubuntu 中不会发生同样的情况.但是即使在 memcheck 工具中使用 trace-origins = yes ,valgrind 输出也不会显示任何 uninit 变量.

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.

另外,我没有任何名为 call_init 或_dl_init 或 dl_open_worker 的函数!!

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)

推荐答案

在不了解程序的情况下,Valgrind 的输出完全没有意义.例如,您可以选择全局分配某些内容并且从不删除它,甚至在关机时也不删除.它不会以任何方式受到伤害,但 Valgrind 会警告您泄漏,因为这是正式的.不过,这些都不应该导致任何段错误,而且您对输出导致它的解释非常值得怀疑.

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.

现在,关于 dl_* 函数,它们来自 Linux 上的动态加载器,所以很可能不是您造成的.可能它们是可以忽略的东西,您可以尝试通过将程序剥离到您确定代码不会导致任何问题的程度来重现它们.

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.

关于全局,也没有关系,因为原始指针没有任何析构函数.但是,如果您不释放它所代表的资源,Valgrind 将报告错误.

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.

这篇关于解释 C++/SDL2 程序的 valgrind 输出的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆