[Issue 15939] GC.collect causes deadlock in multi-threaded environment

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #1 from Aleksei Preobrazhenskii <apreobrazhensky@gmail.com> --- I wasn't able to reproduce the issue using simpler code using GC operations only. I noticed that nanosleep is a syscall which should be interrupted by GC signal. So, probably there is something else involved aside from GC. I use standard library only and I have no custom signal-related code. --

https://issues.dlang.org/show_bug.cgi?id=15939 Илья Ярошенко <ilyayaroshenko@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ilyayaroshenko@gmail.com --- Comment #2 from Илья Ярошенко <ilyayaroshenko@gmail.com> --- +1 I had the same problems --

https://issues.dlang.org/show_bug.cgi?id=15939 Marco Leise <Marco.Leise@gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Marco.Leise@gmx.de --- Comment #3 from Marco Leise <Marco.Leise@gmx.de> --- This issue has a smell of https://issues.dlang.org/show_bug.cgi?id=10351 In absence of a repro case that works without the profiler I just kept it open for future reference. Not how the GC hangs in thread_suspendAll() in both cases. --

https://issues.dlang.org/show_bug.cgi?id=15939 Ivan Kazmenko <gassa@mail.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gassa@mail.ru --

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #4 from Sobirari Muhomori <dfj1esp02@sneakemail.com> --- (In reply to Aleksei Preobrazhenskii from comment #0) > dmd 2.071.0 with -O -release -inline -boundscheck=off Do these flags affect the hang? --

April 20, 2016

[Issue 15939] GC.collect causes deadlock in multi-threaded environment

Posted by Aleksei Preobrazhenskii

Permalink

Aleksei Preobrazhenskii

Permalink

https://issues.dlang.org/show_bug.cgi?id=15939

--- Comment #6 from Aleksei Preobrazhenskii <apreobrazhensky@gmail.com> ---
I think I saw the same behaviour in debug builds, I will try to verify it. As of 32-bit question, due to the nature of the program I can't test it in 32-bit environment.

After investigating problem a little further, I think that the issue might be in GC relying on traditional POSIX signals. One way to get such stack traces is if suspend signal (SIGUSR1 by default) wasn't delivered, which could happen for traditional POSIX signals if they occur in quick succession. Like, if thread_suspendAll happens while some threads are still in the thread_suspendHandler (already handled resume signal, but still didn't leave the suspend handler).

Real-time POSIX signals (SIGRTMIN .. SIGRTMAX) have stronger delivery
guarantees, I'm going to try the same code but with
thread_setGCSignals(SIGRTMIN, SIGRTMIN + 1).

--

https://issues.dlang.org/show_bug.cgi?id=15939 Aleksei Preobrazhenskii <apreobrazhensky@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://issues.dlang.org/sh | |ow_bug.cgi?id=10351 --

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #7 from Aleksei Preobrazhenskii <apreobrazhensky@gmail.com> --- I was running tests for past five days, I didn't see any deadlocks since I switched GC to using real-time POSIX signals (thread_setGCSignals(SIGRTMIN, SIGRTMIN + 1)). I would recommend to change default signals accordingly. --

https://issues.dlang.org/show_bug.cgi?id=15939 Vladimir Panteleev <thecybershadow@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |code@dawg.eu, | |thecybershadow@gmail.com --

Forums