From: gga <GGarramuno@...>
Date: 2007-01-22T15:32:03+09:00
Subject: Re: Embedded Ruby crashing with profiling? (was Re: Ruby and E.V.E. Paradox)


>
> - Does the test code look okay? Did I make any mistakes? I'm only human, and
>    the crash test isn't trivial.

Nothing caught my eye at first glance, but I have not yet looked at it
deeply.

> - Does "./foo 3" also crash on your machine? Or is it just mine?

I cannot get it to crash on my box (64-bits, thou)... 750+ and counting

> - I use alloca to simulate calls to functions with different stack depth
>    requirements. If you object to alloca, please note that mode 2 of the
>    test program works perfectly fine- this is heavy alloca use without Ruby
>    calls. It crashes only when we add Ruby calls to the mix.

Use of alloca can be problematic if you are using latest SVN ruby
(according to a recent ChangeLog).  Ruby provides some ALLOCA macros
for the same behavior, called ALLOCA_N() and in the new ruby's
C_ALLOCA, I believe.  Also, these macros will invoke the gc in case of
lack of memory, which is also a good idea, anyway.

> - As noted, I think it only happens if profiling is enabled. I can't guarantee
>    it doesn't crash without, I just haven't seen it do so.

A simpler possibility for this is that ruby might be running out of
stack space in your process.
The current ruby interpreter is notoriously bad for the way it
allocates its stack frames.  If you end doing a lot of deep nested
calls, you can hit the limits.
As you are on linux, you can test this rather easily.

Try increasing the value of ulimit, from its default.
> ulimit -s
> ulimit -s XXXX  # like double your previous limit

See if the crash happens at the same place, or if it occurs somewhat
later (or not at all).
If that's what happens, I'm afraid you'll need to modify the process
stack depth for your application, or always run your code thru a bash
wrapper script that sets ulimit.