chicken-hackers
[Top][All Lists]
Advanced

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

[Chicken-hackers] [PATCH] Fix for extremely obscure error in lolevel-tes


From: Peter Bex
Subject: [Chicken-hackers] [PATCH] Fix for extremely obscure error in lolevel-tests
Date: Wed, 16 Apr 2014 15:50:18 +0200
User-agent: Mutt/1.4.2.3i

Hi all,

Mario discovered an obscure problem that we initially dismissed as a
GCC bug:
http://paste.call-cc.org/paste?id=fa2e0e8658c19ba639ae587128e6e1b1c58c6dd5

We discovered that this was a bug in CHICKEN after all, probably another
incarnation of this one: http://bugs.call-cc.org/ticket/916

Felix found out that the reason it's failing is because the lolevel-tests
call object-evict and then object-release on an object which is bound to
a global variable ev-tstvec.  This global variable points to *freed memory*
after object-release has been called.  Then, when a GC happens that memory
gets pulled into the new heap, and the data there seems to get
reinterpreted on the next GC.  This wreaks havoc with the tests, but only
if the stars are aligned just so that malloc returns memory in this
fashion and the stack size is just so, etc etc.  That's why it only
happens on some Linuxen with some versions of GCC.

This is a fundamental problem with object-release; there is currently no
way to ensure there are no local variables still holding references to
the freed memory.  Because this has been broken since the beginning and
because changing this would probably involve a small overhaul of the GC,
I think it's best to apply the attached patch by Felix which at least
suppresses the problematic behaviour of the test, and go ahead with
making a release candidate.  This should then be fixed by 4.10.0
(or 5.0.0?).

Cheers,
Peter
-- 
http://www.more-magic.net

Attachment: 0001-Make-sure-ev-tstvec-does-not-hold-on-to-a-released-o.patch
Description: Text document


reply via email to

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