[Issue 15939] GC.collect causes deadlock in multi-threaded environment
via Digitalmars-d-bugs
digitalmars-d-bugs at puremagic.com
Wed Apr 27 18:43:01 PDT 2016
https://issues.dlang.org/show_bug.cgi?id=15939
--- Comment #10 from Aleksei Preobrazhenskii <apreobrazhensky at gmail.com> ---
(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 while
strace was running. And, unfortunately, I don't have original code running in
production anymore.
> I'm wondering if there are any other signal handler invocations in the
> "...application stack" part of your stack traces.
No, there was no signal related code in hidden parts of stack trace.
> I've seem a deadlock caused by an assert firing within the
> thread_suspendHandler, which deadlocks on the GC lock.
In my case that was a release build, so I assume no asserts.
> What should happen in this case is since the signal is masked upon signal
> handler invocation, the new suspend signal is marked as "pending" and run
> once thread_suspendHandler returns and the signal is unblocked.
Yeah, my reasoning was wrong. I did a quick test and saw that signals weren't
delivered, apparently, I forgot that pthread_kill is asynchronous, so signals
should've coalesced in my test.
> Their queuing and ordering guarantees should be irrelevant due to
> synchronization and signal masks.
Ideally, yeah, but as I said, I just changed SIGUSR1/SIGUSR2 to
SIGRTMIN/SIGRTMIN+1 and didn't see any deadlocks for a long time, and I saw
them pretty consistently before. So, either "irrelevant" part is wrong, or
there is something else which is different and relevant (and probably not
documented) for real-time signals. The other explanation is that bug is still
there and real-time signals just somehow reduced probability of it happening.
Also, I have no other explanation why stack traces look like that, the simplest
one is that signal wasn't delivered.
--
More information about the Digitalmars-d-bugs
mailing list