[Ecls-list] A fatally-looking bug.
Juan Jose Garcia-Ripoll
jjgarcia at users.sourceforge.net
Tue Apr 29 13:21:39 UTC 2008
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)
This function is responsible for pushing the argument list of a C
function into the interpreter stack. The value of args.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
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.
Facultad de Fisicas, Universidad Complutense,
Ciudad Universitaria s/n Madrid 28040 (Spain)
More information about the ecl-devel