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
It's this code in las.c that defines alloc_node_s:
BLOCK_ALLOC_FILL_PAGES(node_s, 2)
This macro is defined in block_alloc.h.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-03-02 23:31: Subject: valgrinding Pike - some problems
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
/ Brevbäraren
Did you compile with --with-valgrind?
alloc_node_s is defined in line 382 in las.c
/ Martin Nilsson (saturator)
Previous text:
2004-03-02 23:31: Subject: valgrinding Pike - some problems
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
/ Brevbäraren
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
It looks like you compiled your Pike with debug. That code is not valgrind safe yet, though it would be a good thing if it was...
/ Martin Nilsson (saturator)
Previous text:
2004-03-02 23:31: Subject: valgrinding Pike - some problems
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
/ Brevbäraren
The "uninitialized value" issue is one that I can't seem to avoid. If anyone has a solution to that I'd be very happy. :)
/ David Hedbor
Previous text:
2004-03-02 23:31: Subject: valgrinding Pike - some problems
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
/ Brevbäraren
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:
2004-03-02 23:37: Subject: valgrinding Pike - some problems
The "uninitialized value" issue is one that I can't seem to avoid. If anyone has a solution to that I'd be very happy. :)
/ David Hedbor
In my case it's not specifically a Pike issue. I don't have a working test case right now although it would be interesting to look at some.
/ David Hedbor
Previous text:
2004-03-02 23:42: Subject: valgrinding Pike - some problems
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)
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:
2004-03-02 23:48: Subject: valgrinding Pike - some problems
In my case it's not specifically a Pike issue. I don't have a working test case right now although it would be interesting to look at some.
/ David Hedbor
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
The thing is, I get this error on memory that most definitely has been initialized (as far as I can tell). I.e I don't get why it says it's not.
/ David Hedbor
Previous text:
2004-03-03 00:07: Subject: Re: valgrinding Pike - some problems
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
/ Brevbäraren
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
Understood but I swear this isn't the case in some of the issues I see. If I can come up with a code example which triggers this I can perhaps post it.
/ David Hedbor
Previous text:
2004-03-03 00:48: Subject: Re: valgrinding Pike - some problems
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
/ Brevbäraren
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