[BUG] unknown node type 0


(HAL 9000) #1

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. :slight_smile:

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) #2

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


(Ben Giddings) #3

Hal Fulton wrote:

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


(Marek Janukowicz) #4

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.

···

On Thu, 4 Sep 2003 01:57:38 +0900, Hal Fulton wrote:

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. :slight_smile:

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.


Marek Janukowicz


(Florian Frank) #5

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. :slight_smile:

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…

···

On 2003-09-04 01:57:38 +0900, Hal Fulton wrote:


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


(Mike Stok) #6

In article 3F561D89.5030101@hypermetrics.com,

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

···

Hal Fulton hal9000@hypermetrics.com wrote:

mike@stok.co.uk | The “`Stok’ disclaimers” apply.
http://www.stok.co.uk/~mike/ | GPG PGP Key 1024D/059913DA
mike@exegenix.com | Fingerprint 0570 71CD 6790 7C28 3D60
http://www.exegenix.com/ | 75D2 9EC4 C1C0 0599 13DA


(HAL 9000) #7

ts wrote:

“H” == Hal Fulton hal9000@hypermetrics.com writes:

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


(Samuel Tesla) #8

ts decoux@moulon.inra.fr writes:

Who else has seen this error?

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

I would get that while working on RERSS which is written (at the
moment) in pure Ruby with no C extensions.


(Steven Jenkins) #9

Marek Janukowicz wrote:

···

On Thu, 4 Sep 2003 01:57:38 +0900, Hal Fulton wrote:

[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. :slight_smile:

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) #10

b.rb:
require 'test/unit'

I can't reproduce the bug.

Guy Decoux


(ts) #11

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.

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

Guy Decoux


(Paul Brannan) #12

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

···

On Fri, Sep 05, 2003 at 05:19:53PM +0900, ts wrote:

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.

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


(ts) #13

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?

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

···

Thu Sep 4 00:06:14 2003 Yukihiro Matsumoto <matz@ruby-lang.org>

  * 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) #14

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)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;
    }
    }
···

On Mon, Feb 09, 2004 at 02:39:35AM +0900, ts wrote:

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

Thu Sep 4 00:06:14 2003 Yukihiro Matsumoto matz@ruby-lang.org

  • 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


(ts) #15

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