|
From: jon <jon...@gm...> - 2012-01-31 07:40:52
|
Valgrind is reporting a handful of 'uninitialized data' errors in my c++ application. When I use --track-origins=yes it says the uninitialized data came from a heap allocation from a 'new someclass()' expression. I am confused by this because
a) if I step through the code in gdb I can clearly see the pieces of data being initialized by the constructor
b) manual inspection of the code leads me to the same belief
There are no other errors that valgrind reports besides this uninitialized data error so I do not think its some random memory corruption. Is there a chance that valgrind is somehow confused about data initialized in a class constructor?
FWIW the class hierarchy is A -> B -> C, meaning B derives from A and C derives from B. The object being instantiated is C. The A class's constructor is the one initializing the variable that valgrind ultimately reports is uninitialized.
I am unable to produce a small test case that reproduces this behavior (I tried..) nor am I able to reduce my application to a small test case (it is fairly large and complex). To try to debug this problem further I put printf statements immediately after the creation of the object. valgrind does not complain about uninitialized data at that point, only some time much later. That is..
C * c = new C();
printf("%d\n", c->getX()); // valgrind doesn't report any violations here
.. much later, in a completely different part of the code ..
printf("%d\n", c->getX()); // valgrind reports a violation here
I even checked that the two c pointers had the same value so if the object wasn't uninitialized at the start, how could it be uninitialized later on?
|
|
From: jon <jon...@gm...> - 2012-01-31 08:16:43
|
Well I think I found the issue.. there is one obvious way to make the code at the bottom behave like so, just set the variable in question to garbage between printfs.
C * c = new C();
printf("%d\n", c->getX()); // initialized variable ok
int garbage;
c->setX(garbage);
printf("%d\n", c->getX()); // uninitialized, error
I realized that the object had an update() method which did 'x += velocityX' and I had forgotten to initialize the velocityX variable in the constructor of C. I have learned my lesson both in terms of always initializing all variables and in how to read valgrinds error reports, but it would have been super helpful if valgrind was able to point exactly to 'velocityX' as the place where the original uninitialized data came from, instead of just saying 'heap allocation'.
On 01/31/2012 12:40 AM, jon wrote:
> Valgrind is reporting a handful of 'uninitialized data' errors in my c++ application. When I use --track-origins=yes it says the uninitialized data came from a heap allocation from a 'new someclass()' expression. I am confused by this because
>
> a) if I step through the code in gdb I can clearly see the pieces of data being initialized by the constructor
> b) manual inspection of the code leads me to the same belief
>
> There are no other errors that valgrind reports besides this uninitialized data error so I do not think its some random memory corruption. Is there a chance that valgrind is somehow confused about data initialized in a class constructor?
>
> FWIW the class hierarchy is A -> B -> C, meaning B derives from A and C derives from B. The object being instantiated is C. The A class's constructor is the one initializing the variable that valgrind ultimately reports is uninitialized.
>
> I am unable to produce a small test case that reproduces this behavior (I tried..) nor am I able to reduce my application to a small test case (it is fairly large and complex). To try to debug this problem further I put printf statements immediately after the creation of the object. valgrind does not complain about uninitialized data at that point, only some time much later. That is..
>
> C * c = new C();
> printf("%d\n", c->getX()); // valgrind doesn't report any violations here
> .. much later, in a completely different part of the code ..
> printf("%d\n", c->getX()); // valgrind reports a violation here
>
> I even checked that the two c pointers had the same value so if the object wasn't uninitialized at the start, how could it be uninitialized later on?
|