[BUG] Additional info regarding ruby-talk:66239

ruby-talk
1

I have recently encountered similiar problem as described on that thread, i.e., rb_bug
triggered by the GC, as a result of RBasic->flags and RBasic->klass switching variables.

I’ve been working to produce a simple and trivial code that can trigger the bug easily. the
result is a small code snippet, the does the following:

Launches 120 threads with a block, that does some 20,000 regexp matching. before
the thread quits, it creates an additional thread with the same block

thread_block= Proc.new do
1.upto(20000) do
"Hello"=~/bla/
end
Thread.new &thread_block
end

1.upto(120) do
Thread.new &thread_block
end
Thread.stop

Under ruby-1.8.0(from debian’s sid) the bug will be always be triggered after a few
seconds of runtime.

I have set gdb to break at the following location at gc.c - obj_free():
1150 rb_bug(“gc_sweep(): unknown data type 0x%lx(%ld)”, obj,

(gdb) print ((RVALUE *)obj)->as->basic
$1 = {flags = 1074907300, klass = 5}

Which is the excpected anomaly.

Here is the relevant backtrace:

#0 obj_free (obj=1074716744) at gc.c:1150
#1 0x40045d59 in gc_sweep () at gc.c:939
#2 0x400463b0 in rb_gc () at gc.c:1299
#3 0x40044ebb in rb_newobj () at gc.c:335
#4 0x40085796 in str_alloc (klass=1074028782) at string.c:45
#5 0x40085973 in str_new3 (klass=1074907300, str=1074848760) at string.c:121
#6 0x40085a05 in rb_str_new3 (str=1074028782) at string.c:136
#7 0x4002ff6f in rb_eval (self=1074911840, n=0x400460ee) at eval.c:3341
#8 0x4002fef1 in rb_eval (self=1074911840, n=0x400460ee) at eval.c:2495
#9 0x40032128 in rb_yield_0 (val=6001, self=1074911840, klass=0, flags=0, avalue=0) at eval.c:4153
#10 0x400325e7 in rb_yield (val=6001) at eval.c:4222
#11 0x40058e50 in int_upto (from=3, to=20000) at numeric.c:1727
#12 0x4003fc76 in call_cfunc (func=0x40058e00 <int_upto>, recv=3, len=1074028782, argc=1, argv=0x4011c8a4) at eval.c:4767
#13 0x40033cb4 in rb_call0 (klass=1074891100, recv=3, id=4305, oid=1074028782, argc=1, argv=0xbfffca30, body=0x401188e4, nosuper=0) at eval.c:4904
#14 0x400344a5 in rb_call (klass=1074891100, recv=3, mid=4305, argc=1, argv=0xbfffca30, scope=0) at eval.c:5122
#15 0x4002f648 in rb_eval (self=1074911840, n=0x400460ee) at ruby.h:626
#16 0x4002e9db in rb_eval (self=1074911840, n=0x400460ee) at eval.c:2717
#17 0x40032128 in rb_yield_0 (val=1074779020, self=1074911840, klass=0, flags=2, avalue=2) at eval.c:4153
#18 0x4003e169 in rb_thread_yield (arg=1074779020, th=0x80adde8) at eval.c:9432
#19 0x4003e004 in rb_thread_start_0 (fn=0x4003e0d0 <rb_thread_yield>, arg=0x400fd38c, th_arg=0x400460ee) at eval.c:9349
#20 0x4003e24a in rb_thread_initialize (thread=1074779040, args=1074779020) at eval.c:9461
#21 0x4003fc76 in call_cfunc (func=0x4003e210 <rb_thread_initialize>, recv=1074779040, len=1074028782, argc=0, argv=0x4011c8a4) at eval.c:4767
#22 0x40033cb4 in rb_call0 (klass=1074894100, recv=1074779040, id=2961, oid=1074028782, argc=0, argv=0x0, body=0x401194b0, nosuper=0) at eval.c:4904
#23 0x400344a5 in rb_call (klass=1074894100, recv=1074779040, mid=2961, argc=0, argv=0x0, scope=1) at eval.c:5122
#24 0x40034828 in rb_funcall2 (recv=36, mid=2961, argc=0, argv=0x0) at ruby.h:626

Hopefully this piece of code will be useful for resolving the bug.

2

Hi,

···

In message “[BUG] Additional info regarding ruby-talk:66239” on 03/08/28, Idan Sofer idan@idanso.dyndns.org writes:

I have recently encountered similiar problem as described on that thread, i.e., rb_bug
triggered by the GC, as a result of RBasic->flags and RBasic->klass switching variables.

I’ve been working to produce a simple and trivial code that can trigger the bug easily. the
result is a small code snippet, the does the following:

Launches 120 threads with a block, that does some 20,000 regexp matching. before
the thread quits, it creates an additional thread with the same block

thread_block= Proc.new do
1.upto(20000) do
“Hello”=~/bla/
end
Thread.new &thread_block
end

1.upto(120) do
Thread.new &thread_block
end
Thread.stop

Under ruby-1.8.0(from debian’s sid) the bug will be always be triggered after a few
seconds of runtime.

It does not happen on the latest CVS. I’m not sure whether we already
fixed it or just by coincidence.

						matz.
3

Yukihiro Matsumoto wrote:

Under ruby-1.8.0(from debian’s sid) the bug will be always be triggered after a few
seconds of runtime.

It does not happen on the latest CVS. I’m not sure whether we already
fixed it or just by coincidence.

Negetive, I can still reproduce the problem from the latest CVS. It was
noted gcc version may play a role here(either it’s gcc bug, or gcc is
just exposing it):

gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.2/specs
Configured with: …/src/configure -v
–enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
–mandir=/usr/share/man --infodir=/usr/share/info
–with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared
–with-system-zlib --enable-nls --without-included-gettext
–enable-__cxa_atexit --enable-clocale=gnu --enable-debug
–enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.2 20030812 (Debian prerelease)

Idan.

4

Negetive, I can still reproduce the problem from the latest CVS. It was
noted gcc version may play a role here(either it's gcc bug, or gcc is
just exposing it):

Not really sure, but seems to be a bug in gcc : someone can test it with
another compiler ?

Guy Decoux

5

Not really sure, but seems to be a bug in gcc : someone can test it with
another compiler ?

When I was looking at this problem, I've found (I know it's stupid :-))

svg% cat b.rb
#!/usr/bin/ruby

def a
   ThreadGroup.instance_eval { remove_const :Default }
   nil
end
a()
GC.start

Thread.abort_on_exception = true
Thread.new do
   p Thread.current.group
end.join
svg%

svg% b.rb
./b.rb:12:in `p': method `inspect' called on terminated object (0x400a4d1c) (NotImplementedError)
        from ./b.rb:12
        from ./b.rb:11:in `initialize'
        from ./b.rb:11:in `new'
        from ./b.rb:11
svg%

perhaps best to protect thgroup (thgroup_default), no ?

Guy Decoux

6

Not really sure, but seems to be a bug in gcc : someone can test it with
another compiler ?

An example to see the problem (ruby-1.8.0, gcc 3.2 Redhat 8)

With this modification

svg% diff -u gc.c~ gc.c
--- gc.c~ 2003-08-02 08:45:57.000000000 +0200
+++ gc.c 2003-08-30 13:27:39.000000000 +0200
@@ -545,17 +545,21 @@
     return Qfalse;
}

+static int in_locations_array = 0;

···

+
static void
mark_locations_array(x, n)
     register VALUE *x;
     register long n;
{
+ in_locations_array = 1;
     while (n--) {
        if (is_pointer_to_heap((void *)*x)) {
            rb_gc_mark(*x);
        }
        x++;
     }
+ in_locations_array = 0;
}

void
@@ -624,6 +628,12 @@
     if (rb_special_const_p(ptr)) return; /* special const not marked */
     if (obj->as.basic.flags == 0) return; /* free cell */
     if (obj->as.basic.flags & FL_MARK) return; /* already marked */
+ if (!is_pointer_to_heap((void *)ptr)) {
+ fprintf(stderr, "error : in_locations_array %d -- ptr 0x%x -- heaps 0x%x\n",
+ in_locations_array, ptr, heaps);
+ exit(1);
+ }
+ in_locations_array = 0;
     obj->as.basic.flags |= FL_MARK;

     CHECK_STACK(ret);
svg%

svg% cat b.rb
#!/usr/bin/ruby
thread_block= Proc.new do
   1.upto(20000) do
      a = {1=>12}
   end
  Thread.new &thread_block
end

1.upto(120) do |i|
   Thread.new &thread_block
end
p "END"
Thread.stop
svg%

svg% ./ruby b.rb
error : in_locations_array 1 -- ptr 0x80e6898 -- heaps 0x80e6898
svg%

This mean that rb_gc_mark() is called from mark_locations_array() with the
value 0x80e6898. But mark_locations_array() can't call it with the value
0x80e6898 because is_pointer_to_heap() is false.

I see, actually, only one explanation :
   * is_pointer_to_heap() is called with the right value (in
     mark_locations_array())
   * a *modified* value is given to rb_gc_mark()

Now ruby will do

   obj->as.basic.flags |= FL_MARK;

this means that heaps[0] is modified, and at this step the GC can't work.

Guy Decoux

7

Can anyone tell me how to use ms visual c++ to create a *.so file? I can’t
seem to find a version of gcc on the internet that I can readily use with
windows 2000 proff.

Thanks

8

“Thomas A. Reilly” w3gat@bellsouth.net wrote in message news:4.3.2.7.2.20030830090252.0253fb00@mail.lig.bellsouth.net…

Can anyone tell me how to use ms visual c++ to create a *.so file? I can’t
seem to find a version of gcc on the internet that I can readily use with
windows 2000 proff.

Thanks

Hi, dunno about msVC, but if it’s GCC try Mingw: www.mingw.org, adding
Msys there would be wise, but that depends on your needs, docs and
info there.

Saludos!
puts stable.to_spanish => estable :wink:

9

Hi,

···

At Sat, 30 Aug 2003 23:03:10 +0900, Thomas A. Reilly wrote:

Can anyone tell me how to use ms visual c++ to create a *.so file? I can’t
seem to find a version of gcc on the internet that I can readily use with
windows 2000 proff.

*.so files used in ruby are just DLLs.

–
Nobu Nakada