[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] Re: crashes during return-from-callbacks

From: felix winkelmann
Subject: [Chicken-users] Re: crashes during return-from-callbacks
Date: Wed, 7 Sep 2005 22:30:31 +0200

On 9/7/05, Daniel B. Faken <address@hidden> wrote:
> Hi,
>   I've been working on this for a few days, but can't seem to make any
> progress...
>   I'm making callbacks via C_callback() into a closure created by eval'd
> code.  SOMETIMES when I return the value back to C, I get a crash in some
> subroutine called by C_do_apply() when the eval'd fn is returning...

First thing to make sure: are you _always_ invoking your callback via

>   Its been very hard to track down what is causing this; all I can say is
> that it is affected by calls to (print) in the called-back scheme
> function.  Specifically, if I print some of the parameters I'm passing via
> C_callback().  But the function doesn't crash during the printing -- only
> after it reaches the second-to-last statement (which generates output, so
> I know it is called).  The last statement just returns the value.
>   (This is after calling CHICKEN_run(C_toplevel) and after saving the
> input params via C_save()).

Second thing: are you messing with the temporary stack in some ways?
(i.e. use C_save()/C_restore())

> Any ideas?  I looked at the code in eval.scm, to no avail.. One thing I
> don't understand is which functions C_do_apply() call -- where are these
> 4/5/6/7/8/../126 -parameter functions defined for functions created in
> eval'd code?  (I presume there are generic versions that just make a
> list of the N parameters and pass these lists to (apply) or something).

These calls in C_do_apply() just invoke a normal closure, depending
on the number of arguments passed in the list. eval translates the 
s-expr's into a closure tree, and a closure is just a vector with a 
C function pointer and the free variables (or boxes of them).

> any help appreciated... I suspect its related to GC, but have no proof
> of this. :)

Usually, when really weird things happen, pointer to data end up in non-GC'd
memory and from then on corrupt data, or stale objects result in errors
in rather unsuspecting situations.

>   Are there any secret options for debugging the compiler/evaluator? :)
>   The next thing I can think of is just compiling the whole enchilada with
> -g... yikes.

Yes, that's what I would do in this case... Is your code big, does it have
a lot of external dependencies? Can you reduce the problem to something
I can try out myself?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]