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.
