Re: [Chicken-hackers] [PATCH] catch exceptions in finalizers, remove dynamic resizing of finalizer vector

[Jörg F . Wittenberger]

On Jun 19 2012, Felix wrote:

> The attached patch adds exception handling around the invocation of
> finalizers, which are shown as warnings (unless warnings are disabled)
> but do not otherwise trigger errors (similar to the way errors in
> separate threads are handled). I still experienced random crashes when
> running the stress test in #866. What helped was removing the dynamic

This maybe related, but maybe not at all.

To me it looks as a repeated occurrence of this problem:
http://lists.nongnu.org/archive/html/chicken-users/2008-09/msg00025.html

However my wild guess would be that the static array for finalizers
is a red herring.

It ran quite comfortable once finalizers where wraped by an exception
handler.

However I too see random crashes all day.

To me it looks more like a gc problem (wild guess work again).

I've been able to produce *some* binaries, usually just "minor" code
changes - that is minor wrt. Scheme - which would crash sooner or
later or exhibit another problem:

The same binary would start up different.  As early as during the
initialization of all modules it select one of two modi: (A): run
normal for minutes or hour until switch to (B) and (B): eat up
at least 512kB mutation stack, slow down to a grind and repeat
resizing the mutation stack.  (at this point my session freezes;
I never managed to be fast enough to stop and attach to the
process)


My most recent update to chicken trunk made this come up so frequetly
that I started these days to experiment with a workaround.

I introduced a mutation_stack_limit and forced a gc whenever
the mutation_stack has more than a constant (currently I'm using
1024) entries.

This made sure it never enters mode (B).  At the cost of:

# define C_stack_probe(p) (C_stress && ((C_word *)(p) < C_stack_limit) && 
!C_mutation_limit)

you see: binary incompatible, runtime.c exports yet another C_word*
and each C_stack_check involves yet another memory access.

(((I've been wondering: this C_mutation_limit is actually a boolean.
Maybe I could fold it into the LSB the the C_stack_limit to avoid
the extra memory access.)))

This cost is so far bearable, given that I can continue to run
my older code as it was.

Coming back to "maybe related": It also went to the benefit to reduce
the felt frequency of those nasty segfaults…

…if only I could say, that is killed them.  It did not.

That's what makes me believe the static array might be read herring.

Hope this helps.

/Jerry
.......