|
From: Alex B. <ker...@be...> - 2006-07-11 13:47:44
|
Hi,
So it came to pass I started looking at a couple of the errors thrown up
by valgrind. This one made me blink:
==16647== Conditional jump or move depends on uninitialised value(s)
==16647== at 0x700F1C29: MyClass::branchI(long, ConditionCode, bool)
(MyClass.cc:1917)
Looking at the code it referenced:
// Decide if we're going to take the branch
bool takeBranch = sic->createIccCondition(cond);
if(takeBranch)
{
As I've got a lot of trust in valgrind these days I didn't dismiss it as
impossible. The reason of course is the un-initialised value is
propagating from sic->createIccCondition(cond). I've been going around
back down the line to places where the variables are set and adding:
if (a)
{
magicValgrindValue = 0;
} else {
magicValgrindValue = 1;
}
To try and figure out how the value became initialised. However this is
quite tedious work. Does valgrind know this information anayway? Is
there anyway to get it to tell me where the value was reset to its
initialised state from?
--
Alex, homepage: http://www.bennee.com/~alex/
A great nation is any mob of people which produces at least one honest
man a century.
|
|
From: Burlen L. <bur...@ki...> - 2008-12-11 22:22:11
|
Hi all,
Valgrind identifies uninitialized memory when it's used in a
conditional. It's very smart and can tell when one uninitialized value
is assigned to another. I'd like to be able to see is a trace of all of
those assignments that lead to the report starting from the reported
conditional. Can I?
In the following code for instance valgrind reports line 16. But could
it report lines 7,14,15 as well? That would be very useful! In real life
the flagged if statement can be far removed from the initial source of
the bug!
1 #include<iostream>
2 using std::cerr;
3 using std::endl;
4
5 int fun(int d)
6 {
7 return d+1;
8 }
9
10 int main(int argc, char **argv)
11 {
12 int r,q,j;
13
14 q=j;
15 r=fun(q);
16 if (r) { ++k; }
17 cerr << k << endl;
18
19 return 0;
20 }
--
Burlen Loring
Kitware, Inc.
R&D Engineer
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-371-3971 x137
|
|
From: tom f. <tf...@al...> - 2008-12-11 22:35:29
|
Burlen Loring <bur...@ki...> writes: > Hi all, Hi Burlen! Hope all is well. > Valgrind identifies uninitialized memory when it's used in a > conditional. It's very smart and can tell when one uninitialized > value is assigned to another. I'd like to be able to see is a trace > of all of those assignments that lead to the report starting from the > reported conditional. Can I? Try checking out the trunk and using --track-origins=yes. (Haven't personally tried it yet, just regurgitating info seen here.) -tom |
|
From: Julian S. <js...@ac...> - 2006-07-11 13:57:50
|
Two things. (1) Make sure you're using 3.2.0; that has the most accurate uninit-value tracking shipped so far; it's better than 3.1.1. (2) The fast easy way to chase down the source of uninitialised values is with the VALGRIND_CHECK_DEFINED macro. #include "valgrind.h" in your code (or is it memcheck.h, I can never remember) Add VALGRIND_CHECK_DEFINED(possibly_suspicious_variable); V will then croak if the var is undefined. See http://www.valgrind.org/docs/manual/manual-core.html#manual-core.clientreq and http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.clientreqs J On Tuesday 11 July 2006 14:47, Alex Bennee wrote: > Hi, > > So it came to pass I started looking at a couple of the errors thrown up > by valgrind. This one made me blink: > > ==16647== Conditional jump or move depends on uninitialised value(s) > ==16647== at 0x700F1C29: MyClass::branchI(long, ConditionCode, bool) > (MyClass.cc:1917) > > Looking at the code it referenced: > > // Decide if we're going to take the branch > bool takeBranch = sic->createIccCondition(cond); > if(takeBranch) > { > > As I've got a lot of trust in valgrind these days I didn't dismiss it as > impossible. The reason of course is the un-initialised value is > propagating from sic->createIccCondition(cond). I've been going around > back down the line to places where the variables are set and adding: > > if (a) > { > magicValgrindValue = 0; > } else { > magicValgrindValue = 1; > } > > To try and figure out how the value became initialised. However this is > quite tedious work. Does valgrind know this information anayway? Is > there anyway to get it to tell me where the value was reset to its > initialised state from? > > -- > Alex, homepage: http://www.bennee.com/~alex/ > A great nation is any mob of people which produces at least one honest > man a century. > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Alex B. <ker...@be...> - 2006-07-11 14:55:29
|
On Tue, 2006-07-11 at 14:57 +0100, Julian Seward wrote: > Two things. (1) Make sure you're using 3.2.0; that has the most > accurate uninit-value tracking shipped so far; it's better than 3.1.1. I live on the Subversion tree ;-) > (2) The fast easy way to chase down the source of uninitialised values > is with the VALGRIND_CHECK_DEFINED macro. > > #include "valgrind.h" in your code (or is it memcheck.h, I can > never remember) > > Add VALGRIND_CHECK_DEFINED(possibly_suspicious_variable); V will > then croak if the var is undefined. See > > http://www.valgrind.org/docs/manual/manual-core.html#manual-core.clientreq > and > http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.clientreqs > That's damn useful. I shall have to look at including that directly in our code (I can already see the allocator stuff very useful considering our use of Memory Pools). Now the problem with the current error is not that the variable has never been initialised. At some point in running it becomes uninitialised. I think this is probably because at some point we write a 32bit value to what is usually refereed to as a 64 bit one. Of course what I need to find is when that 32 bit was written (or whatever made that location uninitialised) - not when we next refer to it. -- Alex, homepage: http://www.bennee.com/~alex/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. |
|
From: Julian S. <js...@ac...> - 2006-07-13 13:31:32
|
> Now the problem with the current error is not that the variable has > never been initialised. At some point in running it becomes > uninitialised. I think this is probably because at some point we write a > 32bit value to what is usually refereed to as a 64 bit one. Of course > what I need to find is when that 32 bit was written (or whatever made > that location uninitialised) - not when we next refer to it. > Poll it frequently with VALGRIND_CHECK_DEFINED then? or Can you use a gdb hardware watchpoint to spot the erroneous 32-bit write to that location? J |