Re: [Chicken-users] Build Failure (maybe infinite recursion) on x86_64 Linux

[Taylor Venable]

On Mon, Mar 16, 2009 at 09:09:41PM +0100, felix winkelmann wrote:
> Well done, Taylor. Chicken coalesces all allocations inside a single
> generated C procedure and allocates it as one chunk. It seems here
> that the stack is already too small to hold the data, even after a minor
> GC was invoked. Can you reproduce the hang with larger settings for
> "-:s..."? If you add "-:d", you should see messages like
> 
> [debug] stack resized to XXXX bytes
> 
> If you can't reproduce the hang with higher settings, change the makefile
> (defaults.make or rules.make and pass "-:s<goodvalue>" to the "chicken-boot"
> invocations and look how far it gets (BTW, what does "./chicken-boot -:d" 
> show?)
> Then we probably have a precompiled bootstrapping compiler with a too
> low nursery setting, even though this used to work. It also may be something
> completely different.

Yes, now that I've tried these things I think that what I've run into
during the build process initially is different from the small stack
size that I've been using for this.  Or in other words I think there
may be two separate problems here, or at least I've figured out how to
get the program to hang in two different conditions.

First, here is the output with -:d for what proceeds normally.  Note
that with this build (done with "make PLATFORM=linux DEBUG_BUILD=yes
bootstrap") the original scenario works.

[debug] application startup...
[debug] heap resized to 500000 bytes
[debug] stack bottom is 0x7fffce663a60.
[debug] entering toplevel toplevel...
[debug] stack resized to 262144 bytes
[debug] entering toplevel library_toplevel...
[debug] entering toplevel eval_toplevel...
[debug] entering toplevel data_structures_toplevel...
[debug] entering toplevel ports_toplevel...
[debug] entering toplevel extras_toplevel...
[debug] entering toplevel srfi_69_toplevel...
[debug] entering toplevel srfi_1_toplevel...
[debug] entering toplevel match_toplevel...
[debug] entering toplevel srfi_4_toplevel...
[debug] entering toplevel utils_toplevel...
[debug] entering toplevel regex_toplevel...
[debug] entering toplevel files_toplevel...
[debug] entering toplevel support_toplevel...
[debug] resizing heap dynamically from 500k to 1040k ...
[debug] entering toplevel compiler_toplevel...
[debug] entering toplevel optimizer_toplevel...
[debug] entering toplevel driver_toplevel...
[debug] entering toplevel platform_toplevel...
[debug] entering toplevel backend_toplevel...
[debug] resizing heap dynamically from 1040k to 2081k ...
[debug] resizing heap dynamically from 2081k to 4163k ...
[debug] forcing finalizers...
[debug] resizing heap dynamically from 4163k to 2081k ...

Now, here's the output when I add -:s10k to that:

[debug] application startup...
[debug] heap resized to 500000 bytes
[debug] stack bottom is 0x7fff275a99d0.
[debug] entering toplevel toplevel...
[debug] entering toplevel library_toplevel...

The last line repeats forever until I kill it.  There is no marked
increase in memory consumption.

HOWEVER I did figure out how to reproduce it for higher values of -:s
using a script that just stepped through trying increasing values
until it hung.  There are several that I found; both -:s74k and
-:s262k trigger it.  The GDB output from the latter case is attached.
Note that the backtrace gets larger and larger the longer you let it
run, and it repeats (starting at frame #57 <-> #16).

The behaviour in this last case seems different than that of the
-:s10k case.  The former never grew the heap, but continually called
the GC process.  But the latter is constantly growing the heap and as
a result the memory usage balloons.  I couldn't say if they're both
reflections of the same problem or if they're different.

Since regex.c seems heavily involved in this last case, I've also put
it on my website at: http://real.metasyntax.net:2357/tmp/regex.c.gz

-- 
Taylor Christopher Venable
http://real.metasyntax.net:2357/

chicken-bigstack.txt
Description: Text document