From: Christoph Rippel <crippel@...>
Date: 2001-01-28T09:36:18+09:00
Subject: [ruby-talk:9996] Re: Windows bugs

> -----Original Message-----
> From: ale@crimson.propagation.net [mailto:ale@crimson.propagation.net]
> Sent: Saturday, January 27, 2001 03:11 AM
> To: ruby-talk ML
> Subject: [ruby-talk:9977] Re: Windows bugs[]
[..]
> 
> 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]
[..]
This same is true for cygwin/mingw32 ruby 1.7.0. However this bug
was not fixed for windows in the stable cvs branch as of 2001-01-23
> 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.
maybe somebody with a ``non-gcc ruby'' should try to run this?
>     - Aleksi
> 
Christoph