October 01, 2014 [Issue 4890] GC.collect() deadlocks multithreaded program. | ||||
---|---|---|---|---|
| ||||
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. *** -- |
October 02, 2014 [Issue 4890] GC.collect() deadlocks multithreaded program. | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=4890 --- Comment #31 from Sobirari Muhomori <dfj1esp02@sneakemail.com> --- Hmm... stack trace in issue 11806 is quite different. -- |
October 04, 2014 [Issue 4890] GC.collect() deadlocks multithreaded program. | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=4890 --- Comment #32 from Martin Nowak <code@dawg.eu> --- Can we first confirm that this is a regression. -- |
October 05, 2014 [Issue 4890] GC.collect() deadlocks multithreaded program. | ||||
---|---|---|---|---|
| ||||
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? -- |
October 05, 2014 [Issue 4890] GC.collect() deadlocks multithreaded program. | ||||
---|---|---|---|---|
| ||||
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. | ||||
---|---|---|---|---|
| ||||
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. -- |
Copyright © 1999-2021 by the D Language Foundation