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

https://issues.dlang.org/show_bug.cgi?id=15939 Iain Buclaw changed: What|Removed |Added CC||bra...@puremagic.com --- Comment #31 from

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #30 from Iain Buclaw --- *** Issue 10351 has been marked as a duplicate of this issue. *** --

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

https://issues.dlang.org/show_bug.cgi?id=15939 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED CC|

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

https://issues.dlang.org/show_bug.cgi?id=15939 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #28 from Dlang Bot --- @hatf0

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

https://issues.dlang.org/show_bug.cgi?id=15939 Илья Ярошенко changed: What|Removed |Added Assignee|ilyayaroshe...@gmail.com|nob...@puremagic.com --

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

https://issues.dlang.org/show_bug.cgi?id=15939 safety0ff.bugz changed: What|Removed |Added See Also|

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #27 from Martin Nowak --- (In reply to Илья Ярошенко from comment #26) > Probably related issue > http://forum.dlang.org/post/igqwbqawrtxnigplg...@forum.dlang.org No, looks like an unrelated crash in a finalizer. --

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #26 from Илья Ярошенко --- Probably related issue http://forum.dlang.org/post/igqwbqawrtxnigplg...@forum.dlang.org --

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #25 from Martin Nowak --- (In reply to Aleksei Preobrazhenskii from comment #24) > Since I changed signals to real-time and migrated to recent kernel I haven't > seen that issue in the release builds, however, I tried

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #24 from Aleksei Preobrazhenskii --- (In reply to Martin Nowak from comment #23) > Anyone still experiencing this issue? Can't seem to fix it w/o reproducing > it. Since I changed signals to real-time and

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #23 from Martin Nowak --- Anyone still experiencing this issue? Can't seem to fix it w/o reproducing it. --

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #22 from Илья Ярошенко --- (In reply to Martin Nowak from comment #21) > Nope, that doesn't seem to be the problem. > All the thread exit code synchronizes on Thread.slock_nothrow. > It shouldn't even be

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #21 from Martin Nowak --- Nope, that doesn't seem to be the problem. All the thread exit code synchronizes on Thread.slock_nothrow. It shouldn't even be possible to send a signal to an exiting thread, b/c they get removed

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #20 from Илья Ярошенко --- I have not access to the source code anymore :/ --

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #19 from Martin Nowak --- (In reply to Илья Ярошенко from comment #17) > > https://github.com/dlang/druntime/pull/1110, that would affect dmd >= > > 2.070.0. > > Could someone test their code with 2.069.2? > > Yes, the bug

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #17 from Илья Ярошенко --- (In reply to Martin Nowak from comment #16) > (In reply to Aleksei Preobrazhenskii from comment #13) > > All suspending signals were delivered, but it seems that number of calls to > >

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #16 from Martin Nowak --- (In reply to Aleksei Preobrazhenskii from comment #13) > All suspending signals were delivered, but it seems that number of calls to > sem_wait was different than number of calls to sem_post (or

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

https://issues.dlang.org/show_bug.cgi?id=15939 Artem Tarasov changed: What|Removed |Added CC||lomerei...@gmail.com

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #14 from safety0ff.bugz --- (In reply to Aleksei Preobrazhenskii from comment #13) > > All suspending signals were delivered, but it seems that number of calls to > sem_wait was different than number of calls

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #13 from Aleksei Preobrazhenskii --- I saw new deadlock with different symptoms today. Stack trace of collecting thread: Thread XX (Thread 0x7fda6700 (LWP 32383)): #0 sem_wait () at

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #12 from Aleksei Preobrazhenskii --- (In reply to Martin Nowak from comment #11) > Did you have gdb attached while the signal was send? That sometime causes > issues w/ signal delivery. No, I didn't. I

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #11 from Martin Nowak --- Having the main thread hang while waiting for semaphore posts in the thread_suspendAll is a good indication that the signal was lost. Did you have gdb attached while the signal was send? That

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

https://issues.dlang.org/show_bug.cgi?id=15939 Илья Ярошенко changed: What|Removed |Added Assignee|nob...@puremagic.com

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #10 from Aleksei Preobrazhenskii --- (In reply to safety0ff.bugz from comment #9) > Could you run strace to get a log of the signal usage? I did it before to catch the deadlock, but I wasn't able to do that

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

https://issues.dlang.org/show_bug.cgi?id=15939 safety0ff.bugz changed: What|Removed |Added CC|

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

https://issues.dlang.org/show_bug.cgi?id=15939 Walter Bright changed: What|Removed |Added CC|

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

https://issues.dlang.org/show_bug.cgi?id=15939 Vladimir Panteleev changed: What|Removed |Added CC||c...@dawg.eu,

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #7 from Aleksei Preobrazhenskii --- 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

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

https://issues.dlang.org/show_bug.cgi?id=15939 Aleksei Preobrazhenskii changed: What|Removed |Added See Also|

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #6 from Aleksei Preobrazhenskii --- 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.

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #5 from Sobirari Muhomori --- Also what about 32-bit mode? --

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

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

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

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

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

https://issues.dlang.org/show_bug.cgi?id=15939 Marco Leise changed: What|Removed |Added CC||marco.le...@gmx.de ---

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

https://issues.dlang.org/show_bug.cgi?id=15939 Илья Ярошенко changed: What|Removed |Added CC|

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

https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #1 from Aleksei Preobrazhenskii --- 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