我是否应该担心“有条件的跳跃或移动取决于未初始化的值"? [英] Should I worry about "Conditional jump or move depends on uninitialised value(s)"?
问题描述
如果您使用过(来自Valgrind的Memcheck)，您可能会熟悉此消息...
If you've used Memcheck (from Valgrind) you'll probably be familiar with this message...
有条件的跳跃或移动取决于未初始化的值
Conditional jump or move depends on uninitialized value(s)
我已经阅读过有关此内容的信息，当您使用未初始化的值时，它就会发生.
I've read about this and it simply occurs when you use an uninitialized value.
MyClass s;
s.DoStuff();
这将起作用，因为s是自动初始化的...因此，如果确实如此，那么为什么Memcheck告诉我它尚未初始化?应该忽略该消息吗?
This will work because s is automatically initialized... So if this is the case, and it works, why does Memcheck tell me that it's uninitialized? Should the message be ignored?
也许我误解了错误将我引导到哪里.根据Valgrind手册，实际错误的代码段是...
Perhaps I misunderstood where the error was directing me. From the Valgrind manual, the actual erroneous snippet is...
int main()
{
int x;
printf ("x = %d\n", x);
}
但是，在我的代码中，我看不到任何类似的东西.但是，我注意到堆栈跟踪Memcheck顶部的函数向我显示了一个虚函数.这可能与它有关吗?
However, in my code, I can't see anything like that. I have noticed however that the function at the top of the stack trace Memcheck shows me is a virtual function; could this be something to do with it?
==14446== Conditional jump or move depends on uninitialised value(s)
==14446== at 0x414164: vimrid::glut::GlutApplication::FinishRender() (GlutApplication.cpp:120)
==14446== by 0x422434: vimrid::demos::filterdemos::FilterDemo3::Render() (FilterDemo3.cpp:260)
==14446== by 0x412D3D: vimrid::VimridApplication::UpdateAndRender() (VimridApplication.cpp:93)
==14446== by 0x4144BA: vimrid::glut::GlutApplication::glutHandleDisplay() (GlutApplication.cpp:201)
==14446== by 0x41486A: vimrid::glut::GlutApplication::glutCallbackDisplay() (GlutApplication.cpp:277)
==14446== by 0x54D9FAA: (within /usr/lib64/libglut.so.3.8.0)
==14446== by 0x54DDA4A: fgEnumWindows (in /usr/lib64/libglut.so.3.8.0)
==14446== by 0x54DA4A3: glutMainLoopEvent (in /usr/lib64/libglut.so.3.8.0)
==14446== by 0x54DAEB5: glutMainLoop (in /usr/lib64/libglut.so.3.8.0)
==14446== by 0x413FF8: vimrid::glut::GlutApplication::Run() (GlutApplication.cpp:112)
==14446== by 0x41249D: vimrid::Launcher::runDemo(vimrid::VimridSettings&) (Launcher.cpp:150)
==14446== by 0x412767: vimrid::Launcher::Launch(int, char**) (Launcher.cpp:62)
更新1:
我看了看GlutApplication.cpp:120，看起来未初始化的变量正在传递给该行上的函数.简单！
Update 1:
I took a look at GlutApplication.cpp:120, and it looks like the uninitialized variable was being passed in to a function on that line. Simple!
推荐答案
您可以发布更完整的示例吗?如果没有某种形式的goto或流程更改语句，很难看到该特定错误.
Can you post a more complete sample? It's hard to see how there would be that particular error with out some form of goto or flow changing statement.
我最常见的是在类似以下代码中看到此错误
I most commonly see this error in code like the following
MyClass s1;
...
if ( someCondition ) {
goto Foo:
}
MyClass s2;
Foo:
cout << s2.GetName();
此代码从根本上来说是不正确的.原因是，即使s2具有构造函数，但如果someCondition为true也不会执行该构造函数. goto语句将跳过初始化，并且在程序s2的最后一行将未初始化，并且实际上指向垃圾.
This code is fundamentally incorrect. The reason why is that even though s2 has a constructor, it's not executed if someCondition is true. The goto statement will jump over the initialization and at the last line of the program s2 will be uninitialized and essentially point to garbage.
编辑
您可能还想查看此页面，该页面提供了有关如何解译此特定valgrind错误的提示
You may also want to check out this page which gives hints on how to decipher this particular valgrind error
https://computing.llnl.gov/code/memcheck/#deciphering4
附录
我发现的另一个常见原因是当您将一些整数常量传递给可变参数函数时，该函数以int的形式放在堆栈中，但是当被调用方获取的字符串很长时，您就遇到了问题在64位计算机上.
Another common cause for this I've just found is when you pass over some integer constants to a variadic function, which are put on the stack as ints, but when the callee gets it as longs, you've got a problem on 64-bit machines.
我几乎要放弃，只是认为valgrind是愚蠢的，然后我意识到只需将其强制转换为长期修复程序即可.
I was almost about to give up and just consider valgrind being stupid, then I've realised that simply casting it to long fixes it.
所以我的结果是:认真对待这些信息.
So my upshot is: take this messages seriously.
这篇关于我是否应该担心“有条件的跳跃或移动取决于未初始化的值"?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
