Issues with debugging GC-related crashes #2

Matthias Klumpp mak at debian.org
Fri Apr 20 19:32:24 UTC 2018


On Friday, 20 April 2018 at 18:30:30 UTC, Matthias Klumpp wrote:
> 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:
>>>> [...]
>>> [...]
>>
>> 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.

Turns out that was indeed the case! I created a small testcase 
which managed to very reliably reproduce the issue on all 
machines that I tested it on. After reordering the 
dispose/removeRange, the crashes went away completely.
I submitted a pull request to the containers library to fix this 
issue: https://github.com/dlang-community/containers/pull/107

I will also try to get the patch into the components in Debian 
and Ubuntu, so we can maybe have a chance of updating the 
software center metadata for Ubuntu before 18.04 LTS releases 
next week.
Since asgen uses HashMaps for pretty much everything, an most of 
the time with GC-managed elements, this should improve the 
stability of the application greatly.

Thanks a lot for the help in debugging this, I learned a lot 
about DRuntime internals in the process. Also, it is no 
exaggeration to say that the appstream-generator project would 
not be written in D (there was a Rust prototype once...) and I 
would probably not be using D as much (or at all) without the 
helpful community around it.
Thank you :-)



More information about the Digitalmars-d mailing list