Valgrind analysis of [BUG] unknown node type 0

Hello list,

For a while now while developing a ruby application, I have occasionally seen
  [BUG] unknown node type 0
which I understand is gc related.

The exact, unpredictable symtoms have been described on the ruby-talk ML 
thread starting at
 <[e-mail]>

Yesterday, when it started happening again, I build the latest stable snapshot 
with CFLAGS='-g -O0' and ran Valgrind 2.2.0 on my ruby script (rubyx):
 valgrind --tool=memcheck ruby ./rubyx

I attach the full valgrind log, but in short, the result is some 28,000 hits 
in gc.c. While I am sure alot of the reports are false positives, the very 
first report does seem to indicate a simple uninitialized variable bug:

==28001== Conditional jump or move depends on uninitialised value(s)
==28001==    at 0x806FF18: is_pointer_to_heap (gc.c:591)
==28001==    by 0x806FEE1: mark_locations_array (gc.c:609)
==28001==    by 0x80710F8: rb_gc (gc.c:1328)
==28001==    by 0x806FBAC: rb_newobj (gc.c:376)

The global static variables lomem and himem in gc.c do not seem to be 
initialised before use:

$ grep -E \(lo\|hi\)mem gc.c
 static RVALUE *himem, *lomem;
     if (lomem == 0 || lomem > p) lomem = p;
     if (himem < pend) himem = pend;
     if (p < lomem || p > himem) return Qfalse;

I assume the fix would be
 static RVALUE *himem=0, *lomem=0;

I wonder if somebody familiar with gc.c might check my analysis, and perhaps 
also check the attached valgrind log for other potential problems?

Hope this is useful

Andrew Walrond