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

[Taylor Venable]

On Sun, Mar 15, 2009 at 12:31:21PM +0100, felix winkelmann wrote:
> On Wed, Mar 11, 2009 at 7:25 PM, Taylor Venable <address@hidden> wrote:
> >
> > Well I was able to trigger a hang in my build with the debugging
> > symbols by setting the nursery stack size to 10k. ?Debug log from GDB
> > is attached. ?The three entries here were taken from allowing the
> > program to run for varying periods of time. ?The behaviour I got
> > spiked the CPU but the memory usage did not increase visibly. ?Hope
> > this sheds a little more light; if not let me know and I can go back
> > at it. ?(I notice here that the proc parameter to C_reclaim is the
> > null pointer, don't know if that's meaningful or not...)
> 
> The proc being 0 is ok. Apparently the GC looping: it might be that
> some sort of stack-limit check is constantly failing which results in
> one GC after the other. It would be cool, if you could step out of
> the GC (reclaim) and follow the execution - does it trigger a new
> GC right away?

My testing has all been done using Chicken 3.4.7 so line numbers
reference source code from that devel release.

Usually when it hangs, I end up sending it ^C when it's inside mark().
So if I step out to C_reclaim() I can step through from line 2802 (or
sometimes 2805; in runtime.c) to line 3016.  This I do in GDB using
the "next" command.  When I hit line 3016 which is

    C_longjmp(C_restart, 1);

the program hangs again.  If I send it ^C again I'm back in that same
region of code again inside C_reclaim.  This happens infinitely, as
far as I can tell.

And tracing a bit further, it looks like C_library_toplevel() is
continuously calling C_reclaim().  The code that looks like (library.c
line 6616):

    if(!C_demand(931)){
    C_save(t1);
    C_reclaim((void*)toplevel_trampoline,NULL);}

keeps getting run; this is what's calling the C_reclaim() over and
over again.  In fact, it seems that execution never makes it out of
this loop; just these three lines ad infinitum.

I found that the result of C_demand is based on C_stack_pointer and
C_stack_limit.  I was unable to determine the former using GDB, but in
this case C_stack_limit is always 0x7FFF83326C30.

Hope this helps.  I've put my library.c on my website, since it seems
to be generated code: http://real.metasyntax.net:2357/tmp/library.c.gz

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