From: Sean Chittenden <sean@...>
Date: 2002-09-29T07:45:43+09:00
Subject: ruby bug in tight loops?  (was: Re: Matz, if you're reading, please scan this email)

> S> :-/ You could be right, but, the IO context is created when reading
> S> data from RAM, not from an actual IO socket. 
> 
>  Here the example

Good catch, I fixed this in the CVS version, however this is a
different problem than the one I am having.  Use test case xml_parser4
as it doesn't touch any of the IO routines (though if you update and
try again, you should get the same bug).  Check out the other post
about GeoIP crashing.  The stack traces look identical for both
Net::GeoIP and for libxml.  What's odd is that under normal loads,
Net::GeoIP never destructs, however if you really push it and toss
things into a tight loop, it combusts and leaves a nice core.  Using
Net::GeoIP, reproducing the bug is much easier and smaller than
tracking stuff through libxml, it just takes longer with Net::GeoIP.
I can reproduce this on 1.6 and 1.7.... in both cases, I have to
really push Ruby to have this show up.  Actually, to get this to show
up, I have to add the /etc/hosts entries otherwise the DNS is a
sufficient bottleneck (even on a 100Mbps network with the DNS cache
3ft from the server that's doing this test).

http://lists.ruby-support.com/pipermail/ruby-developers/2002-September/000044.html
http://lists.ruby-support.com/pipermail/ruby-developers/2002-September/000045.html

-sc


#0  0x28197e83 in kill () from /usr/lib/libc.so.5
#0  0x28197e83 in kill () from /usr/lib/libc.so.5
#1  0x281ea8ae in abort () from /usr/lib/libc.so.5
#2  0x280831d9 in rb_bug () at error.c:179
#3  0x280e2c12 in sigbus () at signal.c:402
#4  <signal handler called>
#5  0x2808ab51 in rb_eval (self=135302616, n=0x0) at ruby.h:618
#6  0x2808a95f in rb_eval (self=135302616, n=0x0) at eval.c:2725
#7  0x280896d8 in rb_eval (self=135302616, n=0x0) at eval.c:2303
#8  0x2809029a in rb_call0 (klass=135569056, recv=135302616, id=11361, oid=0, argc=0, argv=0x8343274,
    body=0x814acb0, nosuper=0) at eval.c:4640
#9  0x280965cc in method_call (argc=1, argv=0x8343270, method=135299216) at eval.c:6902
#10 0x28096e5c in bmcall (args=89546, method=0) at eval.c:7043
#11 0x2808dd9a in rb_yield_0 (val=134529664, self=134724204, klass=0, pcall=2) at eval.c:3802
#12 0x2809532b in proc_invoke (proc=135298656, args=134529424, pcall=2, self=6) at ruby.h:613
#13 0x280954b8 in proc_call (proc=0, args=0) at eval.c:6544
#14 0x2808f68c in call_cfunc (func=0x28095490 <proc_call>, recv=135298656, len=89546, argc=5, argv=0xbfbfb678)
    at eval.c:4386
#15 0x2808fdbd in rb_call0 (klass=134674044, recv=135298656, id=5665, oid=0, argc=1, argv=0xbfbfb678,
    body=0x806f618, nosuper=1) at eval.c:4514


-- 
Sean Chittenden