Hey gga,

gga wrote:
 >>- 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

Interesting. Mine is pretty-much guaranteed to die between 100 and 200
iterations. Generally if it makes it that far, it's going to make it the
whole way.

For sake of comparison, what do you get on that same box for:

ruby -v
g++ -v
uname -a

 >>- 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.

I hope the use of an alternate alloca is merely an internal thing and
doesn't impose an external requirement on code using embedded Ruby.
Requiring that the host program not use alloca would be pretty harsh.
I generally don't use it (though I did for my example code), but I can't
guarantee the other libraries I am also using don't use it. As such, that
might be the limitation in common. I hope not...

 >>- 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

This was a really good idea, I was crossing my fingers and hoping it
would work.

Alas, it still fails at around the same spot with the limit set to
10240, 81920, 163840, and 655360. No major behavioral change. :(
Original was 10240.

Since I normally launch via tcsh, I issued a "limit" and got 10240
(same as bash). To be sure, I issued a "limit stacksize unlimited", and
gave it one last run. It doesn't help, still dies at 125. :(

It sounded feasible though. Stack-based errors, profiler information may
flood stack usage, and put in a large program- it could quite easily have
been the cause.

Thanks for giving things a whirl.

Current plan: Trying out a few different versions of Ruby to see the effect.
Hopefully I have some more information tomorrow.

Garth