[Gc] Re: Re[5]: GC_is_disabled returns false when GC_enable() is called too many times

Kjetil Matheussen k.s.matheussen at notam02.no
Sun Dec 9 15:14:05 PST 2012


On 09.12.2012 20:49, Ivan Maidanski wrote:
> Hi Kjetil,
>
> I see your reason.
> But our current API guarantees (and GC relies on this fact 
> internally)
> that GC_disable always disables any GC activity (unlike GC_enable
> which only enables GC in case it is not nested).

But if GC_dont_gc has the value -1, GC_disable will in fact
enable garbage collection, not disable it. :-) I think it does the
opposite of what the GC rely on.


> I've added an assertion for the underflow in GC_enable -
> https://github.com/ivmai/bdwgc/compare/72092ed8de...4c95005 [1]
>

Yes, that sounds good. Great.


> But you could use your own counter in the application and own
> enable/disable that increments/decrements the counter calling
> GC_enable/disable on crossing zero.
>

I'm checking the value of GC_dont_gc now.

I only stumbled upon this because my code was a bit messy though.
If I had taken the time to clean up my code, I wouldn't
have had this problem. I.e. I knew that gc_enable could be called 
several
times in a row, but that wouldn't have happened if I had cleaned up my 
code.
https://github.com/kmatheussen/radium/commit/5c3f9cf8fd462b7643d07e7a0d081ebd9cf8e6f8

What I didn't know though (which I should have checked), was that 
GC_enable may
disable the garbage collector. So the consequences (before the above 
fix)
was that the program froze for quite a while
since it decremented the GC_dont_gc variable in a while-loop (by 
calling GC_enable()),
starting from -1 and all the way to INT_MIN, flipping to INT_MAX, and 
continuing
decrementing down to 0, before the program could continue.



More information about the Gc mailing list