www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - ldc 1.12.0 garbage collector bails out with SEGENV

reply Pjotr Prins <pjotr.public12 thebird.nl> writes:
Facing a new segfault with ldc 1.12.0 on Linux. Does not happen 
with ldc 1.7.0. I'll also try 1.11.0.

https://github.com/biod/BioD/issues/44

Anyone an idea?
Oct 30 2018
next sibling parent reply kinke <noone nowhere.com> writes:
On Tuesday, 30 October 2018 at 16:27:01 UTC, Pjotr Prins wrote:
 Anyone an idea?
Not really, but the std.parallelism unittests are spuriously failing on Linux for LDC CI as well.
Oct 30 2018
parent reply Pjotr Prins <pjotr.public12 thebird.nl> writes:
On Tuesday, 30 October 2018 at 19:27:41 UTC, kinke wrote:
 On Tuesday, 30 October 2018 at 16:27:01 UTC, Pjotr Prins wrote:
 Anyone an idea?
Not really, but the std.parallelism unittests are spuriously failing on Linux for LDC CI as well.
ldc 1.10 is also working fine. It is a regression of sorts. The problem is reproducible with my setup.
Oct 31 2018
parent reply Pjotr Prins <pjotr.public12 thebird.nl> writes:
I suspect the D compiler itself because we also have a problem in 
DMD. Is there a bugzilla report on this already?
Oct 31 2018
next sibling parent reply kinke <kinke libero.it> writes:
On Wednesday, 31 October 2018 at 11:29:56 UTC, Pjotr Prins wrote:
 I suspect the D compiler itself because we also have a problem 
 in DMD. Is there a bugzilla report on this already?
I very much doubt that. It's much more likely that it's a druntime regression, if your code really isn't to blame.
Oct 31 2018
next sibling parent Pjotr Prins <pjotr.public12 thebird.nl> writes:
On Wednesday, 31 October 2018 at 11:33:14 UTC, kinke wrote:
 I very much doubt that. It's much more likely that it's a 
 druntime regression, if your code really isn't to blame.
Not sure our code is to blame. The code is pretty straightforward and works fine for years up to v1.12.0. It happens at cleanup time after running unit tests (which pass).
Oct 31 2018
prev sibling parent Pjotr Prins <pjotr.public12 thebird.nl> writes:
On Wednesday, 31 October 2018 at 11:33:14 UTC, kinke wrote:
 On Wednesday, 31 October 2018 at 11:29:56 UTC, Pjotr Prins 
 wrote:
 I suspect the D compiler itself because we also have a problem 
 in DMD. Is there a bugzilla report on this already?
I very much doubt that. It's much more likely that it's a druntime regression, if your code really isn't to blame.
It is fixed in ldc 1.14.0. Unit test pass again.
Mar 16
prev sibling parent Pjotr Prins <pjotr.public12 thebird.nl> writes:
On Wednesday, 31 October 2018 at 11:29:56 UTC, Pjotr Prins wrote:
 I suspect the D compiler itself because we also have a problem 
 in DMD. Is there a bugzilla report on this already?
Just confirmed that ldc 1.11.0 is also fine.
Oct 31 2018
prev sibling next sibling parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Tuesday, 30 October 2018 at 16:27:01 UTC, Pjotr Prins wrote:
 Facing a new segfault with ldc 1.12.0 on Linux. Does not happen 
 with ldc 1.7.0. I'll also try 1.11.0.

 https://github.com/biod/BioD/issues/44

 Anyone an idea?
From a quick glance at your code, std.parallelism, and the backtrace, smells like unordered destruction by GC, i.e. it already destroyed a Task before destroying one of your `Cache`s.
Oct 30 2018
prev sibling parent reply Kagamin <spam here.lot> writes:
On Tuesday, 30 October 2018 at 16:27:01 UTC, Pjotr Prins wrote:
 Facing a new segfault with ldc 1.12.0 on Linux. Does not happen 
 with ldc 1.7.0. I'll also try 1.11.0.

 https://github.com/biod/BioD/issues/44

 Anyone an idea?
Looks like the whole task is corrupted, but its destructor is buggy anyway: tries to use GC-allocated pool. Does it crash deterministically?
Nov 01 2018
parent reply Kagamin <spam here.lot> writes:
On Thursday, 1 November 2018 at 10:52:52 UTC, Kagamin wrote:
 Looks like the whole task is corrupted, but its destructor is 
 buggy anyway: tries to use GC-allocated pool. Does it crash 
 deterministically?
Oh, no, the destructor is supposed to work for a task on stack, but since this task is corrupted, it runs in GC finalization.
Nov 01 2018
parent reply Pjotr Prins <pjotr.public12 thebird.nl> writes:
On Thursday, 1 November 2018 at 11:17:00 UTC, Kagamin wrote:
 On Thursday, 1 November 2018 at 10:52:52 UTC, Kagamin wrote:
 Looks like the whole task is corrupted, but its destructor is 
 buggy anyway: tries to use GC-allocated pool. Does it crash 
 deterministically?
Yes.
 Oh, no, the destructor is supposed to work for a task on stack, 
 but since this task is corrupted, it runs in GC finalization.
Thanks. I'll try to bring it down to the smallest case. May take me a while.
Nov 02 2018
parent Kagamin <spam here.lot> writes:
On Friday, 2 November 2018 at 08:32:11 UTC, Pjotr Prins wrote:
 Thanks. I'll try to bring it down to the smallest case. May 
 take me a while.
You can call GC.collect at the end of a test to see if it fails.
Nov 02 2018