digitalmars.D.ldc - ldc 1.12.0 garbage collector bails out with SEGENV
- Pjotr Prins (4/4) Oct 30 2018 Facing a new segfault with ldc 1.12.0 on Linux. Does not happen
- kinke (3/4) Oct 30 2018 Not really, but the std.parallelism unittests are spuriously
- Pjotr Prins (3/7) Oct 31 2018 ldc 1.10 is also working fine. It is a regression of sorts. The
- Pjotr Prins (2/2) Oct 31 2018 I suspect the D compiler itself because we also have a problem in
- kinke (3/5) Oct 31 2018 I very much doubt that. It's much more likely that it's a
- Pjotr Prins (4/6) Oct 31 2018 Not sure our code is to blame. The code is pretty straightforward
- Pjotr Prins (2/8) Mar 16 2019 It is fixed in ldc 1.14.0. Unit test pass again.
- Pjotr Prins (2/4) Oct 31 2018 Just confirmed that ldc 1.11.0 is also fine.
- Stanislav Blinov (4/8) Oct 30 2018 From a quick glance at your code, std.parallelism, and the
- Kagamin (4/8) Nov 01 2018 Looks like the whole task is corrupted, but its destructor is
- Kagamin (3/6) Nov 01 2018 Oh, no, the destructor is supposed to work for a task on stack,
- Pjotr Prins (4/10) Nov 02 2018 Thanks. I'll try to bring it down to the smallest case. May take
- Kagamin (2/4) Nov 02 2018 You can call GC.collect at the end of a test to see if it fails.
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
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
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:ldc 1.10 is also working fine. It is a regression of sorts. The problem is reproducible with my setup.Anyone an idea?Not really, but the std.parallelism unittests are spuriously failing on Linux for LDC CI as well.
Oct 31 2018
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
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
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
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:It is fixed in ldc 1.14.0. Unit test pass again.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.
Mar 16 2019
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
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
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
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
On Thursday, 1 November 2018 at 11:17:00 UTC, Kagamin wrote:On Thursday, 1 November 2018 at 10:52:52 UTC, Kagamin wrote:Yes.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.Thanks. I'll try to bring it down to the smallest case. May take me a while.
Nov 02 2018
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