[Ecls-list] A fatally-looking bug.

[Juan Jose Garcia-Ripoll]

On Tue, Apr 29, 2008 at 3:10 PM, Samium Gromoff
<_deepfire at feelingofgreen.ru> wrote:
> At Tue, 29 Apr 2008 09:35:25 +0200,
>
> Juan Jose Garcia-Ripoll wrote:
>  > >  What would be your suggestion for me to proceed with the situation?
>  >
>  > You can run ECL in the debugger, GDB with something like "gdb run" and
>  > then proceed as in a normal lisp image. At some point you will get a
>  > SIGSEGV and enter the debugger again. Producing a backtrace with "bt"
>  > should give you an idea of what functions were called last.
>
>  That's what I get (seems to be reliable across runs):
>
>  Program received signal SIGSEGV, Segmentation fault.
>  GC_allochblk_nth (sz=425985, kind=0, flags=1 '\001', n=60

Memory allocation failed. Your program ran out of memory...

>  #5  0xb7e5f05f in cl_stack_set_size (new_size=425984) at /home/deepfire/source/ecl/src/c/interpreter.d:42

Because the interpreter asked for more than 400 thousand entries in
the lisp stack!

The reason for this might have to do with

#7  0xb7e5f2ec in cl_stack_push_va_list (args=0xbfa5e454)
   at /home/deepfire/source/ecl/src/c/interpreter.d:137

This function is responsible for pushing the argument list of a C
function into the interpreter stack. The value of args[0].narg should
be smaller than the limit of the implementation (somewhere around
65000) but in this case, following this

#8  0xb7e5e7d8 in cl_funcall (narg=3, function=0x8c70078) at
/home/deepfire/source/ecl/src/c/eval.d:212

it should be precisely 3. I wonder whether the local variable args[]
got corrupted somehow. It would be helpful if you could debug the call
to cl_stack_push_va_list(), figuring out whether the stack was already
large before this function call or not.

If the stack was already large, then it is probably a signature that a
very deep recursion was achieved in some part of your code or in ASDF
(if this is the conflicting library).

One way to debug this problem is to add a breakpoint to cl_grow(), or
add some printf() statement to the routines that grow the stack
(cl_stack_set_size()) to see when the stack size is increased.

Regards,

Juanjo

-- 
Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
http://juanjose.garciaripoll.googlepages.com