|
From: Xin S. <sh...@gm...> - 2006-02-17 06:24:06
|
Looks like valgrind doesn't check if a variable in stack is initialized except passing into a system call. Even we define a variable inside main() function, the variable should exist in the stack, so if we pass this varible to the return of main(), the uninitialize= d error will be reported. Right? Xin Message: 1 > Date: Wed, 15 Feb 2006 17:14:49 -0800 > From: John Reiser <jreiser@BitWagon.com> > Organization: - > To: val...@li... > Subject: Re: [Valgrind-developers] missing unitialized error or > misunderstanding? > > Dave Nomura wrote: > > I was creating an example for a valgrind ppc demo and was surprised to > > see that a dereference of an uninitialized global data variable did not > > result in an error from valgrind, but when the same variable was > > propagated to exit() via the return value of main() the error was > > detected. Is this a bug or am I misunderstanding what should be > > happening? > > Global data is always initialized; it can never be uninitialized > except via explicit copying from some other uninitialized data. > > If the source code contains no explicit initialization: > int foo; /* at top level (file scope) */ > then as far as guaranteed values are concerned it is equivalent to: > int foo =3D 0; > The first case (no explicit initialization) resides in .bss > which is cleared to zero upon instantiation by the kernel or by > the runtime module loader ld-linux.so. The second case (explicit > initialization) resides in .data, except that some recent compiler > tools put explicit initialization to 0 into .bss because in many > cases it is an optimization (of space in the filesystem). However, > the behavior with respect to data caches at runtime might be different. > > -- > > > --__--__-- > > Message: 2 > Date: Thu, 16 Feb 2006 13:52:34 +1100 (EST) > From: Nicholas Nethercote <nj...@cs...> > To: John Reiser <jreiser@BitWagon.com> > cc: val...@li... > Subject: Re: [Valgrind-developers] missing unitialized error or > misunderstanding? > > On Wed, 15 Feb 2006, John Reiser wrote: > > >> I was creating an example for a valgrind ppc demo and was surprised to > >> see that a dereference of an uninitialized global data variable did no= t > >> result in an error from valgrind, but when the same variable was > >> propagated to exit() via the return value of main() the error was > >> detected. Is this a bug or am I misunderstanding what should be > >> happening? > > > > Global data is always initialized; it can never be uninitialized > > except via explicit copying from some other uninitialized data. > > John is right. Also, if the global variable became uninitialized somehow= , > it's possible that the dereference wasn't complained about because it > didn't > affect the program's behaviour -- ie. it wasn't used as a pointer, or as > input to a system call, or in a conditional branch. For example, just > copying around uninitialized data doesn't elicit complaints from Memcheck= . > See http://www.valgrind.org/docs/memcheck2005.pdf for details. > > Nick > > |
|
From: Julian S. <js...@ac...> - 2006-02-17 13:36:38
|
On Friday 17 February 2006 06:24, Xin Shen wrote: > Looks like valgrind doesn't check if a variable in stack is initialized > except passing into a system call. Even we define a variable inside main() > function, the variable should exist in the > stack, Not really. On ppc and other cpus with lots of registers, local variables often live in registers. So whether memcheck complains about them being undefined really depends on what the previous status of the register was. Fortunately gcc is good at pointing out local scalars which might be used uninitialised, so in practice this is not much of a problem. J > so if we pass this varible to the return of main(), the > uninitialized error will be reported. > > Right? > Xin > > > Message: 1 > > > Date: Wed, 15 Feb 2006 17:14:49 -0800 > > From: John Reiser <jreiser@BitWagon.com> > > Organization: - > > To: val...@li... > > Subject: Re: [Valgrind-developers] missing unitialized error or > > misunderstanding? > > > > Dave Nomura wrote: > > > I was creating an example for a valgrind ppc demo and was surprised to > > > see that a dereference of an uninitialized global data variable did not > > > result in an error from valgrind, but when the same variable was > > > propagated to exit() via the return value of main() the error was > > > detected. Is this a bug or am I misunderstanding what should be > > > happening? > > > > Global data is always initialized; it can never be uninitialized > > except via explicit copying from some other uninitialized data. > > > > If the source code contains no explicit initialization: > > int foo; /* at top level (file scope) */ > > then as far as guaranteed values are concerned it is equivalent to: > > int foo = 0; > > The first case (no explicit initialization) resides in .bss > > which is cleared to zero upon instantiation by the kernel or by > > the runtime module loader ld-linux.so. The second case (explicit > > initialization) resides in .data, except that some recent compiler > > tools put explicit initialization to 0 into .bss because in many > > cases it is an optimization (of space in the filesystem). However, > > the behavior with respect to data caches at runtime might be different. > > > > -- > > > > > > --__--__-- > > > > Message: 2 > > Date: Thu, 16 Feb 2006 13:52:34 +1100 (EST) > > From: Nicholas Nethercote <nj...@cs...> > > To: John Reiser <jreiser@BitWagon.com> > > cc: val...@li... > > Subject: Re: [Valgrind-developers] missing unitialized error or > > misunderstanding? > > > > On Wed, 15 Feb 2006, John Reiser wrote: > > >> I was creating an example for a valgrind ppc demo and was surprised to > > >> see that a dereference of an uninitialized global data variable did > > >> not result in an error from valgrind, but when the same variable was > > >> propagated to exit() via the return value of main() the error was > > >> detected. Is this a bug or am I misunderstanding what should be > > >> happening? > > > > > > Global data is always initialized; it can never be uninitialized > > > except via explicit copying from some other uninitialized data. > > > > John is right. Also, if the global variable became uninitialized > > somehow, it's possible that the dereference wasn't complained about > > because it didn't > > affect the program's behaviour -- ie. it wasn't used as a pointer, or as > > input to a system call, or in a conditional branch. For example, just > > copying around uninitialized data doesn't elicit complaints from > > Memcheck. See http://www.valgrind.org/docs/memcheck2005.pdf for details. > > > > Nick |
|
From: Xin S. <sh...@gm...> - 2006-02-18 01:29:07
|
Thanks, a thing I noticed is: if we define a local variable like: int x; if we do x++; // no error reported if we do printf( "%d", x ); // unitialized error reported If we would be able to track the status of a storage unit regardless a register or a memory, why the first case is not reported? Thanks, Xin On 2/17/06, Julian Seward <js...@ac...> wrote: > > On Friday 17 February 2006 06:24, Xin Shen wrote: > > Looks like valgrind doesn't check if a variable in stack is initialize= d > > except passing into a system call. Even we define a variable inside > main() > > function, the variable should exist in the > > stack, > > Not really. On ppc and other cpus with lots of registers, local variable= s > often live in registers. So whether memcheck complains about them being > undefined really depends on what the previous status of the register was. > Fortunately gcc is good at pointing out local scalars which might be used > uninitialised, so in practice this is not much of a problem. > > J > > > so if we pass this varible to the return of main(), the > > uninitialized error will be reported. > > > > Right? > > Xin > > > > > > Message: 1 > > > > > Date: Wed, 15 Feb 2006 17:14:49 -0800 > > > From: John Reiser <jreiser@BitWagon.com> > > > Organization: - > > > To: val...@li... > > > Subject: Re: [Valgrind-developers] missing unitialized error or > > > misunderstanding? > > > > > > Dave Nomura wrote: > > > > I was creating an example for a valgrind ppc demo and was surprised > to > > > > see that a dereference of an uninitialized global data variable did > not > > > > result in an error from valgrind, but when the same variable was > > > > propagated to exit() via the return value of main() the error was > > > > detected. Is this a bug or am I misunderstanding what should be > > > > happening? > > > > > > Global data is always initialized; it can never be uninitialized > > > except via explicit copying from some other uninitialized data. > > > > > > If the source code contains no explicit initialization: > > > int foo; /* at top level (file scope) */ > > > then as far as guaranteed values are concerned it is equivalent to: > > > int foo =3D 0; > > > The first case (no explicit initialization) resides in .bss > > > which is cleared to zero upon instantiation by the kernel or by > > > the runtime module loader ld-linux.so. The second case (explicit > > > initialization) resides in .data, except that some recent compiler > > > tools put explicit initialization to 0 into .bss because in many > > > cases it is an optimization (of space in the filesystem). However, > > > the behavior with respect to data caches at runtime might be > different. > > > > > > -- > > > > > > > > > --__--__-- > > > > > > Message: 2 > > > Date: Thu, 16 Feb 2006 13:52:34 +1100 (EST) > > > From: Nicholas Nethercote <nj...@cs...> > > > To: John Reiser <jreiser@BitWagon.com> > > > cc: val...@li... > > > Subject: Re: [Valgrind-developers] missing unitialized error or > > > misunderstanding? > > > > > > On Wed, 15 Feb 2006, John Reiser wrote: > > > >> I was creating an example for a valgrind ppc demo and was surprise= d > to > > > >> see that a dereference of an uninitialized global data variable di= d > > > >> not result in an error from valgrind, but when the same variable > was > > > >> propagated to exit() via the return value of main() the error was > > > >> detected. Is this a bug or am I misunderstanding what should be > > > >> happening? > > > > > > > > Global data is always initialized; it can never be uninitialized > > > > except via explicit copying from some other uninitialized data. > > > > > > John is right. Also, if the global variable became uninitialized > > > somehow, it's possible that the dereference wasn't complained about > > > because it didn't > > > affect the program's behaviour -- ie. it wasn't used as a pointer, or > as > > > input to a system call, or in a conditional branch. For example, jus= t > > > copying around uninitialized data doesn't elicit complaints from > > > Memcheck. See http://www.valgrind.org/docs/memcheck2005.pdf for > details. > > > > > > Nick > |
|
From: Xin S. <sh...@gm...> - 2006-02-20 05:53:19
|
Hi, Can somebody answer my following question? Or can you give me some clue= s on how I can check out from the code? Thanks a lot, Xin On 2/18/06, Xin Shen <sh...@gm...> wrote: > > Thanks, a thing I noticed is: > if we define a local variable like: > int x; > > if we do > x++; // no error reported > > if we do > printf( "%d", x ); // unitialized error reported > > If we would be able to track the status of a storage unit regardless a > register or > a memory, why the first case is not reported? > > Thanks, > Xin > > > On 2/17/06, Julian Seward <js...@ac...> wrote: > > > > On Friday 17 February 2006 06:24, Xin Shen wrote: > > > Looks like valgrind doesn't check if a variable in stack is > > initialized > > > except passing into a system call. Even we define a variable inside > > main() > > > function, the variable should exist in the > > > stack, > > > > Not really. On ppc and other cpus with lots of registers, local > > variables > > often live in registers. So whether memcheck complains about them bein= g > > undefined really depends on what the previous status of the register > > was. > > Fortunately gcc is good at pointing out local scalars which might be > > used > > uninitialised, so in practice this is not much of a problem. > > > > J > > > > > so if we pass this varible to the return of main(), the > > > uninitialized error will be reported. > > > > > > Right? > > > Xin > > > > > > > > > Message: 1 > > > > > > > Date: Wed, 15 Feb 2006 17:14:49 -0800 > > > > From: John Reiser <jreiser@BitWagon.com> > > > > Organization: - > > > > To: val...@li... > > > > Subject: Re: [Valgrind-developers] missing unitialized error or > > > > misunderstanding? > > > > > > > > Dave Nomura wrote: > > > > > I was creating an example for a valgrind ppc demo and was > > surprised to > > > > > see that a dereference of an uninitialized global data variable > > did not > > > > > result in an error from valgrind, but when the same variable was > > > > > propagated to exit() via the return value of main() the error was > > > > > detected. Is this a bug or am I misunderstanding what should be > > > > > happening? > > > > > > > > Global data is always initialized; it can never be uninitialized > > > > except via explicit copying from some other uninitialized data. > > > > > > > > If the source code contains no explicit initialization: > > > > int foo; /* at top level (file scope) */ > > > > then as far as guaranteed values are concerned it is equivalent to: > > > > int foo =3D 0; > > > > The first case (no explicit initialization) resides in .bss > > > > which is cleared to zero upon instantiation by the kernel or by > > > > the runtime module loader ld-linux.so. The second case (explicit > > > > initialization) resides in .data, except that some recent compiler > > > > tools put explicit initialization to 0 into .bss because in many > > > > cases it is an optimization (of space in the filesystem). However, > > > > the behavior with respect to data caches at runtime might be > > different. > > > > > > > > -- > > > > > > > > > > > > --__--__-- > > > > > > > > Message: 2 > > > > Date: Thu, 16 Feb 2006 13:52:34 +1100 (EST) > > > > From: Nicholas Nethercote < nj...@cs...> > > > > To: John Reiser <jreiser@BitWagon.com> > > > > cc: val...@li... > > > > Subject: Re: [Valgrind-developers] missing unitialized error or > > > > misunderstanding? > > > > > > > > On Wed, 15 Feb 2006, John Reiser wrote: > > > > >> I was creating an example for a valgrind ppc demo and was > > surprised to > > > > >> see that a dereference of an uninitialized global data variable > > did > > > > >> not result in an error from valgrind, but when the same variable > > was > > > > >> propagated to exit() via the return value of main() the error wa= s > > > > > > >> detected. Is this a bug or am I misunderstanding what should be > > > > >> happening? > > > > > > > > > > Global data is always initialized; it can never be uninitialized > > > > > except via explicit copying from some other uninitialized data. > > > > > > > > John is right. Also, if the global variable became uninitialized > > > > somehow, it's possible that the dereference wasn't complained about > > > > because it didn't > > > > affect the program's behaviour -- ie. it wasn't used as a pointer, > > or as > > > > input to a system call, or in a conditional branch. For example, > > just > > > > copying around uninitialized data doesn't elicit complaints from > > > > Memcheck. See http://www.valgrind.org/docs/memcheck2005.pdf for > > details. > > > > > > > > Nick > > > > |
|
From: Robert W. <rj...@du...> - 2006-02-20 07:11:07
|
> Hi, Can somebody answer my following question? Or can you give me
> some clues on
> how I can check out from the code?
This isn't reported because Valgrind doesn't report unitialized
memory until it's used to make a decision or it's passed to a system
call, etc. Please see section 3.3.2 of the documention:
http://www.valgrind.org/docs/manual/mc-manual.html#mc-
manual.uninitvals
Regards,
Robert.
|
|
From: Xin S. <sh...@gm...> - 2006-02-20 08:28:09
|
Thanks a lot, I got it. Xin On 2/20/06, Robert Walsh <rj...@du...> wrote: > > > Hi, Can somebody answer my following question? Or can you give me > > some clues on > > how I can check out from the code? > > This isn't reported because Valgrind doesn't report unitialized > memory until it's used to make a decision or it's passed to a system > call, etc. Please see section 3.3.2 of the documention: > > http://www.valgrind.org/docs/manual/mc-manual.html#mc- > manual.uninitvals > > Regards, > Robert. > |