[Gc] Exciting recursive invocation of
bruce at hoult.org
Fri Jun 19 01:55:00 PDT 2009
2009/6/19 Ivan Maidanski <ivmai at mail.ru>:
> Bruce Hoult <bruce at hoult.org> wrote:
>> 2009/6/19 Ivan Maidanski <ivmai at mail.ru>:
>> > Hi!
>> > Bruce Hoult <bruce at hoult.org> wrote:
>> >> On Fri, Jun 19, 2009 at 7:15 AM, Talbot, George<Gtalbot at locuspharma.com> wrote:
>> >> > Attached is a nice zip file of a 264K text file showing a backtrace from my program. ?I've managed to find that one can cause an exciting crash if one allocates memory from a finalization function invoked by the collector.
>> >> There are many things you are not allowed to do in finalizer if you
>> >> have GC (any GC) set up to call finalizers synchronously from within a
>> >> GC (which means from within some random memory allocation attempt in
>> >> the calling program):
>> >> In particular you may not:
>> >> - allocate memory
>> >> - do anything that takes a lock
>> > Wrong assumptions (both). You are allowed to do it even from a finalizer notifier.
>> Allowed by whom? It is a quite serious program bug for a
>> synchronously-called finalizer to attempt to take a lock that is held
>> by the code that called the GC_malloc() that caused the GC that is
>> running the finalizer.
> Allowed by the GC implementation. If You know a place where we call finalizers (or notifier) holding alloc lock, please report.
In GC 6.8, all finalizers are called with the alloc lock held. I am
aware that this changed in 7.x but I know for a fact not everyone is
using that yet.
The changes in 7.x help with the alloc lock, but do not change the
situation with respect to any other lock that the calling code and
finalizer both use.
More information about the Gc