On Thu, May 10, 2007 at 04:51:18PM +0900, Nobuyoshi Nakada wrote:
> Thank you, does this patch fix it?

After a little more experiment, it does seem to fix the reported
problem, but now valgrind is giving me this when I call disasm:

==10863== Conditional jump or move depends on uninitialised value(s)
==10863==    at 0x808CC1C: rb_id2str (parse.y:8484)
==10863==    by 0x808CCF7: rb_id2name (parse.y:8508)
==10863==    by 0x80D9C7D: ruby_iseq_disasm (iseq.c:762)
==10863==    by 0x80E29E5: call_cfunc (call_cfunc.ci:27)
==10863==    by 0x80DF937: th_eval (insns.def:1279)
==10863==    by 0x80E1E35: th_eval_body (vm.c:1620)
==10863==    by 0x80E25C9: rb_thread_eval (vm.c:1826)
==10863==    by 0x80E4861: yarvcore_eval_iseq (yarvcore.c:97)
==10863==    by 0x80E4931: yarvcore_eval_parsed (yarvcore.c:129)
==10863==    by 0x805968D: ruby_exec_internal (eval.c:210)
==10863==    by 0x80596C4: ruby_exec (eval.c:223)
==10863==    by 0x80596FE: ruby_run (eval.c:242)

for this program:

is = VM::InstructionSequence.compile('1 + 1')
puts is.disasm
a = is.to_a
is2 = VM::InstructionSequence.load(a)
puts is2.disasm

and the output from the two disasm statements don't match:

== disasm: <ISeq:<main>@<compiled>>=====================================
0000 trace            1                                               (   1)
0002 putobject        1
0004 putobject        1
0006 opt_plus         
0007 leave            
== disasm: <ISeq:<main>@<compiled>>=====================================
local table (size: 1, argc: 0 [opts: 0, rest: -1, block: -1] c)
[ 1] ?          
0000 trace            1
0002 putobject        1
0004 putobject        1
0006 opt_plus         
0007 leave            

is this a problem?

I'm using this suppressions file for valgrind:

http://rubystuff.org/ruby.supp

Paul