[Issue 17037] std.concurrency has random segfaults
https://issues.dlang.org/show_bug.cgi?id=17037 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Dlang Bot --- dlang/phobos pull request #5004 "Fix issue 17037 - std.concurrency has random segfaults" was merged into master: - 2c6051da1023f535544de5f575c013803286f62c by WalterW: Fix issue 17037 - std.concurrency has random segfaults https://github.com/dlang/phobos/pull/5004 --
[Issue 17037] std.concurrency has random segfaults
https://issues.dlang.org/show_bug.cgi?id=17037 --- Comment #9 from Dlang Bot --- @WalterWaldron updated dlang/phobos pull request #5004 "Fix issue 17037 - std.concurrency has random segfaults" fixing this issue: - Fix issue 17037 - std.concurrency has random segfaults https://github.com/dlang/phobos/pull/5004 --
[Issue 17037] std.concurrency has random segfaults
https://issues.dlang.org/show_bug.cgi?id=17037 Walter Bright changed: What|Removed |Added Severity|normal |major --
[Issue 17037] std.concurrency has random segfaults
https://issues.dlang.org/show_bug.cgi?id=17037 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #8 from Walter Bright --- Still seeing it in FreeBSD running the Phobos test suite: FreeBSD 11.4 x64, DMD (bootstrap) Failing after 11m — Task Summary make[1]: *** [posix.mak:412: unittest/std/concurrency.run] Segmentation fault (core dumped) --
[Issue 17037] std.concurrency has random segfaults
https://issues.dlang.org/show_bug.cgi?id=17037 Berni44 changed: What|Removed |Added CC||bugzi...@bernis-buecher.de --- Comment #7 from Berni44 --- Running "make -f posix.mak -j3 style" on my local computer I got this today: double free or corruption (out) Error: program killed by signal 6 make: *** [posix.mak:651: std/concurrency.publictests] Fehler 1 --
[Issue 17037] std.concurrency has random segfaults
https://issues.dlang.org/show_bug.cgi?id=17037 berni44 changed: What|Removed |Added CC||bugzi...@d-ecke.de --- Comment #6 from berni44 --- In the last two months I havn't seen this in the results of the test suite. Is it still there? --
[Issue 17037] std.concurrency has random segfaults
https://issues.dlang.org/show_bug.cgi?id=17037 --- Comment #5 from safety0ff.bugz--- New PR: https://github.com/dlang/phobos/pull/5004 --
[Issue 17037] std.concurrency has random segfaults
https://issues.dlang.org/show_bug.cgi?id=17037 safety0ff.bugzchanged: What|Removed |Added Keywords||pull --- Comment #4 from safety0ff.bugz --- https://github.com/dlang/phobos/pull/5003 --
[Issue 17037] std.concurrency has random segfaults
https://issues.dlang.org/show_bug.cgi?id=17037 safety0ff.bugzchanged: What|Removed |Added Hardware|x86_64 |All OS|Linux |All --- Comment #3 from safety0ff.bugz --- Seems to be a race involving the global scheduler: __gshared Scheduler scheduler; @property ref ThreadInfo thisInfo() nothrow { 1:if ( scheduler is null ) 2:return ThreadInfo.thisInfo; 3:return scheduler.thisInfo; } If a thread sets scheduler to null after another has evaluated line 1 to false but hasn't run line 3, then the other thread tries to run scheduler.thisInfo with a null scheduler. I'm not sure what the design is for the global scheduler is with regard to concurrent access. I.e. I'm wondering if all the `scheduler is null` checks be changed to: auto lscheduler = atomicLoad(scheduler); if (lscheduler is null) return ...; lscheduler. ... // --
[Issue 17037] std.concurrency has random segfaults
https://issues.dlang.org/show_bug.cgi?id=17037 --- Comment #2 from greenify--- (In reply to safety0ff.bugz from comment #1) > I've only seen this in the stable branch, it is possible it was fixed in > master by: https://github.com/dlang/phobos/pull/4191 ? Just spotted it here: https://github.com/dlang/phobos/pull/5001 (sorry for forgetting to include this exact link) --
[Issue 17037] std.concurrency has random segfaults
https://issues.dlang.org/show_bug.cgi?id=17037 safety0ff.bugzchanged: What|Removed |Added CC||safety0ff.b...@gmail.com --- Comment #1 from safety0ff.bugz --- I've only seen this in the stable branch, it is possible it was fixed in master by: https://github.com/dlang/phobos/pull/4191 ? --