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