[ruby-talk:9977] Re: Windows bugs

On Sat, 27 Jan 2001, Christoph Rippel wrote:

> Running the following snippet
> 
> m = 100000
> # won't crash if set to 1000
> x = Array.new m
> x.collect! { |i|  rand(m).floor }
> 
> def nil.succ; 1 end
> def useless; end
> # won't crash if you comment
> # out the previous line
> mx={}
> x.each \
> { |i|   mx[i] = mx[i].succ }
> # won't crash if you replace this with
> # { |i|   mx[i] = 1 }
> 
> either crashes or hangs on cygwin and mingw32 W2K. I have 
> seen variations of this bug for all rubys versions 1.6.(0.1.2).
> This goes away with the patch for the new gc-scheme but I 
> find this bug pretty weird.

Hello Christoph,

I wrote just to note this crashes with

  ruby 1.6.2 (2000-12-25) [i686-linux]

but doesn't crash with

  ruby 1.7.0 (2001-01-23) [i686-linux]

So something nice has happened. It seems the program is parsed into
same tree (at least NodeDump output was identical), so it's about
interpreting the tree.

There's loads of change log entries regarding different nodes, but saw nothing directly related (but I'm half blind...).

The stack trace from core dump looks like this:

(gdb) bt
#0  0x80f9fb8 in ?? ()
#1  0x8050df6 in search_method (klass=1075545608, id=3961, origin=0xbfffdbb4)
    at eval.c:257
#2  0x8050e32 in rb_get_method_body (klassp=0xbfffdc00, idp=0xbfffdbe4, 
    noexp=0xbfffdbe8) at eval.c:275
#3  0x8059418 in rb_call (klass=1075545608, recv=4, mid=3961, argc=0, 
    argv=0x0, scope=0) at eval.c:4429
#4  0x8054e90 in rb_eval (self=1075600528, n=0x401b8748) at eval.c:2482
#5  0x8054a9e in rb_eval (self=1075600528, n=0x401b8720) at eval.c:2459
#6  0x8057755 in rb_yield_0 (val=148645, self=1075600528, klass=0, acheck=0)
    at eval.c:3534
#7  0x8057920 in rb_yield (val=148645) at eval.c:3588
#8  0x80a6abe in rb_ary_each (ary=1075545628) at array.c:629
#9  0x8058a53 in call_cfunc (func=0x80a6aa0 <rb_ary_each>, recv=1075545628, 
    len=0, argc=0, argv=0x0) at eval.c:4121
#10 0x8058df1 in rb_call0 (klass=1075576388, recv=1075545628, id=3553, argc=0, 
    argv=0x0, body=0x401bfa70, nosuper=1) at eval.c:4248
#11 0x8059521 in rb_call (klass=1075576388, recv=1075545628, mid=3553, argc=0, 
    argv=0x0, scope=0) at eval.c:4452
#12 0x8054e90 in rb_eval (self=1075600528, n=0x401b8838) at eval.c:2482
#13 0x80540b8 in rb_eval (self=1075600528, n=0x401b8ba8) at eval.c:2217
#14 0x8052027 in ruby_run () at eval.c:1166
#15 0x8050a5b in main (argc=2, argv=0xbffff724, envp=0xbffff730) at main.c:50
#16 0x4008cb65 in __libc_start_main (main=0x8050a3c <main>, argc=2, 
    ubp_av=0xbffff724, init=0x804ff18 <_init>, fini=0x80b01bc <_fini>, 
    rtld_fini=0x4000df24 <_dl_fini>, stack_end=0xbffff71c)
    at ../sysdeps/generic/libc-start.c:111

Since #1 seach_method is like this

static NODE*
search_method(klass, id, origin)
    VALUE klass, *origin;
    ID id;
{
    NODE *body;

    if (!klass) return 0;
    while (!st_lookup(RCLASS(klass)->m_tbl, id, &body)) {
	klass = RCLASS(klass)->super;
	if (!klass) return 0;
    }

    if (origin) *origin = klass;
    return body;
}

and line 257 where the illegal instruction is executed happens to be the line '}' closing the while block I wonder if this is one of the GCC bugs.

    - Aleksi