[Top][All Lists]

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

Re: [Chicken-hackers] [PATCH] catch exceptions in finalizers, remove dyn

From: Jörg F . Wittenberger
Subject: Re: [Chicken-hackers] [PATCH] catch exceptions in finalizers, remove dynamic resizing of finalizer vector
Date: 19 Jun 2012 20:51:00 +0200

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:

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

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

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.


reply via email to

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