Re: Help to reproduce the bug (Was: Re: State of Ruby)

[Aaron Schrab <aaron@schrab.com>]

At 13:17 +0300 02 Oct 2003, Dmitry Borodaenko <d.borodaenko@sam-solutions.net> wrote:
> Copying to debian-powerpc mailing list. (Please Cc: me and/or the bug as
> I'm not subscribed.)
> 
> Can anyone here help to reproduce this bug? Ruby 1.8 fails to build
> packages with "stack level too deep" error on Debian PowerPC build
> server (voltair), but works fine on Fumitoshi UKAI's Cube.
> 
> See more details below.
> 
> On Thu, Oct 02, 2003 at 01:50:37AM +0900, Fumitoshi UKAI wrote:
> > > There is also #212282 which is more difficult and more important,

> setup.rb:588: warning: parenthesize argument(s) for future version
> /usr/lib/ruby/1.8/powerpc-linux/rbconfig.rb:18: stack level too deep
> (SystemStackError)
> 	from setup.rb:17:in `require'
> 	from setup.rb:17
> make: *** [build-ruby1.8-stamp] Error 1

I've been seeing this happen occasionally when starting irb1.8 as well.
After some experimentation, I see that irb1.8 works (at least minimally)
when I'm in an ssh session, but not when in a local X terminal window.

The relevant difference in these cases is that the ssh session has a
soft limit on the stack size, but it's unlimited in the local session.
Setting the limit locally allows it to work there as well.  Example
shell session:

18)frell$ dpkg-architecture -qDEB_HOST_ARCH
powerpc
19)frell$ ulimit -s
unlimited
20)frell$ irb1.8
/usr/lib/ruby/1.8/irb/context.rb:77:in `attr_accessor': stack level too deep (SystemStackError)
        from /usr/lib/ruby/1.8/irb/context.rb:77
        from /usr/lib/ruby/1.8/irb.rb:14:in `require'
        from /usr/lib/ruby/1.8/irb.rb:14
        from /usr/bin/irb1.8:10:in `require'
        from /usr/bin/irb1.8:10
zsh: exit 1     irb1.8
21)frell$ ulimit -s 8192
22)frell$ irb1.8
irb(main):001:0>
23)frell$ echo $?
0


I may have time over the weekend to look for the actual cause of this
bug, but maybe this will provide enough of a pointer for someone with a
knowledge of ruby's memory management code to find the bug.  And if not,
it may provide a work around until the bug is fixed.

-- 
Aaron Schrab     aaron@schrab.com      http://www.schrab.com/aaron/