[BUG] unknown node type 0

[Hal Fulton]

Hello, all.

Who else has seen this error?

[BUG] unknown node type 0
ruby 1.8.0 (2003-08-04) [i686-linux-gnu]

Aborted (core dumped)

I'm on a quest to reproduce it reliably. Programmers often
have trouble reproducing.

It's a strange and subtle bug. The slightest change in an
unrelated part of the source code will make it go away.

Adding a (truly irrelevant) blank line or a commented line
will make it go away.

It's only happened to me (naturally) in multi-file apps of
several hundred lines of source which I don't really want
anyone to see yet.

Though I can show the snippet where it fails for me.

You will complain that it's impossible to see what's
happening from this snippet. Quite right. I'm just
illustrating how confusing the bug is.

Without ALL of the context of this program, it wouldn't
fail for you anyway.

all = bestcat.randomize! + best.randomize! + norm.randomize!
# If a blank line follows this one, the bug does not happen.
=begin
puts " Best: #{best.size}"
best.each do |x|
puts x
end
=end

pages = []

Anyway, just curious about this. If I find a way to reproduce
it in under a hundred lines, I will submit the code.

Thanks,
Hal

 

[ts]

H> Who else has seen this error?

Generally this means that the GC has a problem.

If you use an extension (written in C) : first verify this extension


Guy Decoux

 

[Hal Fulton]

H> Who else has seen this error?

Generally this means that the GC has a problem.

If you use an extension (written in C) : first verify this extension

Nothing but dbm.

Hal

 

[Ben Giddings]

Who else has seen this error?

[BUG] unknown node type 0
ruby 1.8.0 (2003-08-04) [i686-linux-gnu]

Aborted (core dumped)

I've never seen it, but it looks to me like a parser bug. The first
clue is the name of the bug "unknown node type", which sounds like part
of a parse tree. The fact that it depends on otherwise irrelevant stuff
really says that's what it is. I would guess that only Matz or people
who really know the Ruby innards will be able to diagnose this one.

On the bright side, parser bugs are often easy to work around. If you
simply change your source to make it simpler to parse, you can probably
dodge this one. What happens if you add parentheses to the line with
"all = ..."? What happens if you break it into 3 lines?

Ben

 

[Florian Frank]

Who else has seen this error?

[BUG] unknown node type 0
ruby 1.8.0 (2003-08-04) [i686-linux-gnu]

Aborted (core dumped)

I have seen it. I could reduce the problem to the following two files:

a.rb:

class A

end

b.rb:
require 'test/unit'

class TC_A < Test::Unit::TestCase

require 'a'

def setup
@a = A.new
end

end

If I run b.rb, ruby dumps core. Here is the stacktrace:

#0 0x4009d7d1 in kill () from /lib/libc.so.6
(gdb) bt
#0 0x4009d7d1 in kill () from /lib/libc.so.6
#1 0x4009d58d in raise () from /lib/libc.so.6
#2 0x4009e994 in abort () from /lib/libc.so.6
#3 0x080cfcf3 in rb_bug (fmt=0x0) at error.c:197
#4 0x080594cd in rb_eval (self=1075979268, n=0x0) at eval.c:3623
#5 0x0805c2cc in rb_call0 (klass=1075978968, recv=1075979268, id=11721,
oid=0, argc=1, argv=0xbfffb4d8, body=0x4019c008, nosuper=0) at
eval.c:5037
#6 0x0805c8a1 in rb_call (klass=1075978968, recv=1075979268, mid=11721,
argc=1, argv=0xbfffb4d8, scope=1) at eval.c:5130
#7 0x08057ab6 in rb_eval (self=1075979268, n=0x0) at eval.c:2965
#8 0x0805744c in rb_eval (self=1075979268, n=0x0) at eval.c:3164
#9 0x0805c2cc in rb_call0 (klass=1075978968, recv=1075979268, id=11689,
oid=0, argc=0, argv=0x0, body=0x4019c3a0, nosuper=0) at eval.c:5037
#10 0x0805c8a1 in rb_call (klass=1075978968, recv=1075979268, mid=11689,
argc=0, argv=0x0, scope=2) at eval.c:5130
#11 0x08057ab6 in rb_eval (self=1075979268, n=0x0) at eval.c:2965
#12 0x0805c2cc in rb_call0 (klass=1075978968, recv=1075979268, id=5017,
oid=0,
argc=0, argv=0x0, body=0x4019c634, nosuper=0) at eval.c:5037
#13 0x0805c8a1 in rb_call (klass=1075978968, recv=1075979268, mid=5017,
argc=0, argv=0x0, scope=0) at eval.c:5130
#14 0x08057ab6 in rb_eval (self=1075978968, n=0x0) at eval.c:2965
#15 0x0805813e in rb_eval (self=1075978968, n=0x0) at eval.c:2913
#16 0x0805c2cc in rb_call0 (klass=1075978948, recv=1075978968, id=5097,
oid=0,
argc=0, argv=0xbfffd49c, body=0x4019cc4c, nosuper=0) at eval.c:5037
#17 0x0805c8a1 in rb_call (klass=1075978948, recv=1075978968, mid=5097,
argc=1, argv=0xbfffd498, scope=0) at eval.c:5130
#18 0x08057ab6 in rb_eval (self=1075624544, n=0x0) at eval.c:2965
#19 0x08057986 in rb_eval (self=1075624544, n=0x0) at eval.c:2958
#20 0x080573ef in rb_eval (self=1075624544, n=0x0) at eval.c:3154
#21 0x0805a5cf in rb_yield_0 (val=1075436344, self=1075624544, klass=2,
flags=1, avalue=2) at eval.c:4166
#22 0x0806106b in proc_invoke (proc=1075436244, args=1075436104, self=6,
klass=2) at ruby.h:627
#23 0x08061148 in proc_call (proc=0, args=0) at eval.c:7066
#24 0x08067cc2 in call_cfunc (func=0x8061120 <proc_call>,
recv=1075436244,
len=1075416704, argc=6, argv=0x2) at eval.c:4772
#25 0x0805c002 in rb_call0 (klass=1075566544, recv=1075436244, id=5201,
oid=0,
argc=1, argv=0xbfffe9f8, body=0x401bd744, nosuper=0) at eval.c:4909
#26 0x0805c8a1 in rb_call (klass=1075566544, recv=1075436244, mid=5201,
argc=1, argv=0xbfffe9f8, scope=0) at eval.c:5130
#27 0x08057ab6 in rb_eval (self=1075624544, n=0x0) at eval.c:2965
#28 0x0805a5cf in rb_yield_0 (val=1075437644, self=1075624544, klass=0,
flags=0, avalue=2) at eval.c:4166
#29 0x0806106b in proc_invoke (proc=1075463024, args=1075437644, self=6,
klass=2) at ruby.h:627
#30 0x0805f637 in call_end_proc (data=0) at eval.c:6429
#31 0x0805f98e in rb_exec_end_proc () at eval.c:6466
#32 0x08053ce0 in ruby_finalize_0 (exp=0xbffff740) at eval.c:1309
#33 0x08053e31 in ruby_cleanup (ex=0) at eval.c:1345
#34 0x08053f31 in ruby_stop (ex=0) at eval.c:1372
#35 0x08053f73 in ruby_run () at eval.c:1384
#36 0x08052153 in main (argc=0, argv=0x0, envp=0xbffff7d0) at main.c:50
#37 0x4008a707 in __libc_start_main () from /lib/libc.so.6

I'm on a quest to reproduce it reliably. Programmers often
have trouble reproducing.

Yes, I have seen this bug before, but wanted to continue programming.
Later when I tried to find out what had happend, I couldn't reproduce
the bug.

It's a strange and subtle bug. The slightest change in an
unrelated part of the source code will make it go away.

Adding a (truly irrelevant) blank line or a commented line
will make it go away.

Yes, exactly. If the blank line between "class A" and "end" in
a.rb is deleted, ruby doesn't crash anymore. It's really weird...

--
Were it left to me to decide whether we should have government without
newspapers or newspapers without government, I should not hesitate for a
moment to prefer the latter. But I should mean that every man should
receive those papers and be capable of reading them.
-- Thomas Jefferson

 

[Steven Jenkins]

[BUG] unknown node type 0
ruby 1.8.0 (2003-08-04) [i686-linux-gnu]

Aborted (core dumped)

I'm on a quest to reproduce it reliably. Programmers often
have trouble reproducing.

It's a strange and subtle bug. The slightest change in an
unrelated part of the source code will make it go away.

Adding a (truly irrelevant) blank line or a commented line
will make it go away.

I've seen this error several times. I also had a problem reproducing it.
I can confirm all the symptoms you reported (including the workaround by
adding blank line). The only difference is that I was using Ruby 1.6.8
then. After upgrading to 1.8.0 I've never seen the bug again.

I've also seen the problem and this workaround in 1.6.8. Haven't done
much with 1.8.0 yet. I *might* be able to reproduce it by digging
through CVS and looking for a snapshot of my code that had the problem
until I added a specific comment line. I'll do that if someone really
needs an example.

Steve

 

[ts]

F> b.rb:
F> require 'test/unit'

I can't reproduce the bug.


Guy Decoux

 

[Mike Stok]

Who else has seen this error?

[BUG] unknown node type 0
ruby 1.8.0 (2003-08-04) [i686-linux-gnu]

Aborted (core dumped)

I hage with a simple script (75 lines) which uses REXML to mangle some
XML. A change in the data file it was processing caused the problem to
appear (though I didn't get the core dump, as far as I recall)

Upgrading from a 2003-08-28 CVS snapshot (which exhibited the problem)
to a 2003-09-04 CVS snapshot *appears* to fix the problem. Of course it
could just have moved to a place where it isn't tickled.

Mike

 

[ts]

M> Upgrading from a 2003-08-28 CVS snapshot (which exhibited the problem)
M> to a 2003-09-04 CVS snapshot *appears* to fix the problem. Of course it
M> could just have moved to a place where it isn't tickled.

well, a bug was found in ruby which can completely explain the error given
in [ruby-talk:80435]


Guy Decoux

 

[Paul Brannan]

M> Upgrading from a 2003-08-28 CVS snapshot (which exhibited the problem)
M> to a 2003-09-04 CVS snapshot *appears* to fix the problem. Of course it
M> could just have moved to a place where it isn't tickled.

well, a bug was found in ruby which can completely explain the error given
in [ruby-talk:80435]

I see this problem occur from time to time on ruby 1.6.8. Is there a
patch for this bug available for 1.6.x?

Paul

 

[ts]

P> I see this problem occur from time to time on ruby 1.6.8. Is there a
P> patch for this bug available for 1.6.x?

Well, if it's the same problem the modification is

Thu Sep 4 00:06:14 2003 Yukihiro Matsumoto <[email protected]>

* eval.c (mark_frame_adj): need to adjust argv pointer if using
system's alloca. [ruby-core:01503]

Compare thread_mark() in 1.6 and 1.8.1


Guy Decoux

 

[Paul Brannan]

Well, if it's the same problem the modification is

Thu Sep 4 00:06:14 2003 Yukihiro Matsumoto <[email protected]>

* eval.c (mark_frame_adj): need to adjust argv pointer if using
system's alloca. [ruby-core:01503]

Compare thread_mark() in 1.6 and 1.8.1

Does that mean there is no patch? Is the following the right patch? (I
had to make a change to mark_frame_adj, since there is no node member in
FRAME in 1.6).

--- ruby-1.6.8/eval.c Mon Dec 16 02:34:22 2002
+++ ruby-1.6.8-pb1/eval.c Mon Feb 9 13:55:38 2004
@@ -7299,6 +7299,25 @@

#define STACK(addr) (th->stk_pos<(VALUE*)(addr) && (VALUE*)(addr)<th->stk_pos+th->stk_len)
#define ADJ(addr) (void*)(STACK(addr)?(((VALUE*)(addr)-th->stk_pos)+th->stk_ptr)VALUE*)(addr))
+#ifdef C_ALLOCA
+# define MARK_FRAME_ADJ(f) rb_gc_mark_frame(f)
+#else
+# define MARK_FRAME_ADJ(f) mark_frame_adj(f, th)
+static void
+mark_frame_adj(frame, th)
+ struct FRAME *frame;
+ rb_thread_t th;
+{
+ if (frame->flags & FRAME_MALLOC) {
+ rb_gc_mark_locations(frame->argv, frame->argv+frame->argc);
+ }
+ else {
+ VALUE *start = ADJ(frame->argv);
+ rb_gc_mark_locations(start, start+frame->argc);
+ }
+ rb_gc_mark((VALUE)frame->cbase);
+}
+#endif

static void
thread_mark(th)
@@ -7335,13 +7354,13 @@
frame = th->frame;
while (frame && frame != top_frame) {
frame = ADJ(frame);
- rb_gc_mark_frame(frame);
+ MARK_FRAME_ADJ(frame);
if (frame->tmp) {
struct FRAME *tmp = frame->tmp;

while (tmp && tmp != top_frame) {
tmp = ADJ(tmp);
- rb_gc_mark_frame(tmp);
+ MARK_FRAME_ADJ(tmp);
tmp = tmp->prev;
}
}
@@ -7350,7 +7369,7 @@
block = th->block;
while (block) {
block = ADJ(block);
- rb_gc_mark_frame(&block->frame);
+ MARK_FRAME_ADJ(&block->frame);
block = block->prev;
}
}

 

[ts]

P> Does that mean there is no patch?

Well, it was found with 1.8.0. Probably matz has a patch for 1.8.0 but not
for for 1.6


Guy Decoux