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 _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
