Hi,
Just attempted to valgrind recent version (from CVS), immediately got thousands of errors like this: ==7875== Conditional jump or move depends on uninitialised value(s) ==7875== at 0x81B5AF7: debug_check_node_hash (las.c:830) ==7875== by 0x81506F1: optimize_binary (operators.c:1712) ==7875== by 0x81C8A04: optimize (treeopt.h:3289) ==7875== by 0x81CCCF3: optimize_node (las.c:5363)
Where is the catch? It seems that entire structure is initialized correctly upon allocation (there is a call to MEMSET)... What makes me curious, though - is - where alloc_node_s() is defined? Grepping all files in src/ gives single match - call to this function, object file symbol table says that alloc_node_s() is defined in las.c, but...
Regards, /Al
On Tue, Mar 02, 2004 at 11:40:05PM +0100, Martin Nilsson (saturator) @ Pike (-) developers forum wrote:
Did you compile with --with-valgrind?
No, without. As I read somewhere on this list, this option is not necessary to run Pike under valgrind (and I don't use machine-code, so it is not really necessary for Pike to communicate with valgrind).
First I got this problem when copt was on, so I recompiled it without copt (after make distclean, to be sure). Nothing changed - the problem is still there...
Regards, /Al
You should try compiling without optimizations and see if it goes away. Things like if(foo.type==T_INT && foo.subtype==NUMBER_NUMBER) is sometimes optimized into one expression which _include_ uninitialized bits, but doesn't depend on them.
/ Martin Nilsson (saturator)
Previous text:
Now I found grubbas example:
if ((s->type == T_FUNCTION) && (s->subtype == FUNCTION_BUILTIN))
can be optimized to
if (((INT32 *)(&s->type))[0] == ((T_FUNCTION<<16)|FUNCTION_BUILTIN))
which if e.g. s->type is T_FLOAT and s->subtype is uninitialized triggers a valgrind warning, though it really is bogus.
/ Martin Nilsson (saturator)
Previous text:
On Wed, Mar 03, 2004 at 12:15:02AM +0100, Martin Nilsson (saturator) @ Pike (-) developers forum wrote:
which if e.g. s->type is T_FLOAT and s->subtype is uninitialized triggers a valgrind warning, though it really is bogus.
Well... Im my case, I figured out that n->hash is the trigger, in several other places, also errors like:
==26504== Use of uninitialised value of size 4 ==26504== at 0x81B5191: sub_node (las.c:442) ==26504== by 0x81B5642: debug_free_node (las.c:711) ==26504== by 0x81BFA3E: optimize (las.c:5335) ==26504== by 0x81CCCF3: optimize_node (las.c:5363)
I upgraded valgrind to 2.1 (latest available), and still see this error... so I guess this is not valgrind's problem...
But it is strange - hash is initialized to 0 upon allocation, so it _might_ happen that it is assigned from another uninitialized variable/location (somewhere) - valgrind's tracking depth sometimes scares me...
Regards, /Al
On Tue, Mar 02, 2004 at 11:40:06PM +0100, David Hedbor @ Pike developers forum wrote:
The "uninitialized value" issue is one that I can't seem to avoid.
Why it is difficult to avoid? Simple explicit initialization of anything (which is allocated) won't do the trick?
Sure, there are some cases when initialization is not necessary (upon allocation), but for objects which produce such warnings it might be a solution...
What I can't understand in this specific case (looked in gdb) - everything (which is referenced) seems to be initialized (n->tree_info)...
But it could be that the bug is in valgrind, though :)
Regards, /Al
On Wed, Mar 03, 2004 at 12:35:02AM +0100, David Hedbor @ Pike developers forum wrote:
The thing is, I get this error on memory that most definitely has been initialized (as far as I can tell).
As I said in my previous message - it might be far away from first initialization.
I.e., say, you have:
int a, f = 0; // You sure that f is initialized...
// blabla... if (condition) f = a; // a is still garbage
if (f) // ...so this will trigger the error ....; Well... I hope you got the idea :) Regards, /Al
pike-devel@lists.lysator.liu.se
-
Alexander Demenshin -
David Hedbor ＠ Pike developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Nilsson (saturator) ＠ Pike (-) developers forum