[Chicken-users] Need help to understand C_mutate better.

[Jörg F . Wittenberger]

Hi all,

this goes to both chicken-users and chicken-hackers.
I feel it's more appropriate to chicken-hackers,
but recently I bothered the users with help requests on the
issue - maybe it's useful to learn where this ends up.

The problem I ran into:

Much depending on optimisation being done or not there is
a probability of a rather complex chicken application to
run into a mode (usually right within the initialisation process,
but sometimes later too) where it would eat all memory.

Until today no way to derive a test case.  (Which makes me
look stupid, having spent 20 days on it.)

Using glibc's mtrace function I've been able to see that
a "good" run, where the programm would work for 16718 lines
in the trace file and 4 heap resize operation did need two
reallocations in C_mutate.

A bad run of approximately the same "size" (16636 lines in the
mtrace report) shows exactly the same pattern of heap resize
operations.

However instead of two entries from C_mutate I get 852.

Towards the end of the log there is almost only C_mutate
growing it's mutation stack more and more.


I wonder if something like this has ever been observed before.

Is there any know pitfall how one could create such a condition?

So far I've been able to reproduce this problem on Ubuntu
gcc 4.5.2 .  Strangely the debian system with gcc 4.4.5 is
not effected.  Neither is the Sheeva Plug.

Thanks for every hint

/Jörg