I just tried valgrinding 7.4-cvs (compiled with valgrind support) on x86_x64 and get the following warnings when starting hilfe:
myst:7.4 $ ./bin/pike --valgrind=-q ==19948== Use of uninitialised value of size 8 ==19948== at 0x50168E: sub_node (las.c:439) ==19948== by 0x501881: debug_free_node (las.c:708) ==19948== by 0x50D152: dooptcode (las.c:5723) ==19948== by 0x422BC5: yyparse (language.yacc:864) ==19948== by 0x4D790E: run_pass2 (program.c:5864) ==19948== by 0x4D7C6D: compile (program.c:6081) ==19948== by 0x516F55: f_compile (builtin_functions.c:3331) ==19948== by 0x4ACBC0: get_master (object.c:552) ==19948== by 0x4ACE48: debug_master (object.c:598) ==19948== by 0x49E9DC: main (main.c:733) [repeated many times] --19948-- WARNING: unhandled syscall: 138 --19948-- You may be able to write your own handler. --19948-- Read the file README_MISSING_SYSCALL_OR_IOCTL. [repeated many times]
Anyone that can determine if the first is a valid error or not? The second warning appears to be setfsuid() which is rather uninteresting from a memory validity standpoint.
Perhaps node_hash.size isn't set? It is set in main.c only if you compiled with SHARED_NODES. fprintfing the values on individual lines gives shows which variable is to blame.
I recall hunting for this last time I used Valgrind but it was far more complex than that. I should perhaps add that when I say that the message was repeated many times, it's 8-10 times and not thousands so it's clearly not every single node object that fails.
Anyway, after many hours of debugging today my theory is that it's nodes created by debug_mkconstantsvaluenode() in las.c that are suspect, but I haven't been able to zero in on exactly why. It seems like the pike_type structure may be polluted by invalid bits, but whether that's harmless or not I don't know. (Maybe like type/subtype false positives in svalues a long time ago.)
I feel I'd better let Mast or Grubba venture on from here into the belly of the beast... :-)
pike-devel@lists.lysator.liu.se