[Issue 4890] GC.collect() deadlocks multithreaded program. (page 3)

https://issues.dlang.org/show_bug.cgi?id=4890 badlink <andrea.9940@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |christoph@nerdtools.de --- Comment #30 from badlink <andrea.9940@gmail.com> --- *** Issue 11806 has been marked as a duplicate of this issue. *** --

https://issues.dlang.org/show_bug.cgi?id=4890 --- Comment #33 from Sean Kelly <sean@invisibleduck.org> --- The GC was in use for probably 5 years without a reported deadlock. Though history isn't exactly proof. I don't suppose someone wants to regress this and find the offending release? Isn't there a D tool for this? Or would we be stuck with git bisect? --

https://issues.dlang.org/show_bug.cgi?id=4890 --- Comment #34 from badlink <andrea.9940@gmail.com> --- (In reply to Sean Kelly from comment #33) > The GC was in use for probably 5 years without a reported deadlock. Though history isn't exactly proof. I don't suppose someone wants to regress this and find the offending release? Isn't there a D tool for this? Or would we be stuck with git bisect? I just have tried a few old versions: - 2.054 (self-compiled) deadlocks - 2.042 (self-compiled) deadlocks - 1.076 (http://dlang.org/download.html) fullCollect never returns - 1.030 (http://dlang.org/download.html) fullCollect never returns code used for D1: http://pastebin.com/wu9guHA6 stacktrace (DMDv1.030): http://pastebin.com/CfNStRvm Does anyone else have this issue ? Right now I'm on Arch Linux 3.14.19-1-lts x86_64, GNU libc 2.20. --

October 06, 2014

[Issue 4890] GC.collect() deadlocks multithreaded program.

Posted by badlink

Permalink

badlink

Permalink

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

badlink <andrea.9940@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #35 from badlink <andrea.9940@gmail.com> ---
I took my time and started digging trough the druntime source to find the
problem. I discovered that core.thread.suspend() sends SIGUSR1 to the thread to
suspend so I launched GDB and tried to catch the signal but GDB never caught
it. I couldn't explain that behavior so I googled "linux sigusr1 not sent" and
Bam! --> https://bbs.archlinux.org/viewtopic.php?id=181142
The people on there already figured that it's a bug in the Gnome Display
Manager which blocks SIGUSR1 for all child applications !
The bug is present in the current package gdm-3.12.2-1 which I am using and is
causing this nasty deadlock in the D garbage collector.
As a quick test I tried to run the testcase in a tty and it worked as expected.
Hopefully the problem will solve itself in the next gdm update.

--

Forums