Issues with debugging GC-related crashes #2

[Matthias Klumpp]

On Friday, 20 April 2018 at 05:32:32 UTC, Dmitry Olshansky wrote:
> On Friday, 20 April 2018 at 00:11:25 UTC, Matthias Klumpp wrote:
>> On Thursday, 19 April 2018 at 18:45:41 UTC, kinke wrote:
>>> [...]
>>
>> Jup, I did that already, it just took a really long time to 
>> run because when I made the change to print errno I also 
>> enabled detailed GC profiling (via the PRINTF* debug options). 
>> Enabling the INVARIANT option for the GC is completely broken 
>> by the way, I enforced the compile to work by casting to 
>> shared, with the result of the GC locking up forever at the 
>> start of the program.
>>
>> [...]
>
> I think the order of operations is wrong, here is an example 
> from containers:
>
> allocator.dispose(buckets);
> static if (useGC)
> 	    GC.removeRange(buckets.ptr);
>
> If GC triggers between dispose and removeRange, it will likely 
> segfault.

Indeed! It's also the only place where this is shuffled around, 
all other parts of the containers library do this properly.
The thing I wonder about is though, that the crash usually 
appeared in an explicit GC.collect() call when the application 
was not running multiple threads. At that point, the GC - as far 
as I know - couldn't have triggered after the buckets were 
disposed of and the ranges were removed. But maybe I am wrong 
with that assumption.
This crash would be explained perfectly by that bug.