https://issues.dlang.org/show_bug.cgi?id=4890
badlink changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #34 from badlink ---
(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 offen
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #33 from Sean Kelly ---
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?
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #32 from Martin Nowak ---
Can we first confirm that this is a regression.
--
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #31 from Sobirari Muhomori ---
Hmm... stack trace in issue 11806 is quite different.
--
https://issues.dlang.org/show_bug.cgi?id=4890
badlink changed:
What|Removed |Added
CC||christ...@nerdtools.de
--- Comment #30 from badlink
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #29 from badlink ---
Also present in DMD 2.067.0-b1.
Stacktrace of the sample program in comment 10: http://pastebin.com/4mudSeEX
--
https://issues.dlang.org/show_bug.cgi?id=4890
Brad Roberts changed:
What|Removed |Added
CC||bra...@puremagic.com
--- Comment #28 from Brad
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #27 from Sean Kelly ---
Earlier than that.
--
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #26 from safety0ff.bugz ---
(In reply to Sean Kelly from comment #25)
>
> I think I'll have to roll back thread.d to find my original comments and see
> how it used to be implemented. Something was clearly changed here, but
> there's no l
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #25 from Sean Kelly ---
Hrm... at one point thread_entryPoint called Thread.add to add itself, but I
think the add was moved to Thread.start at some point to deal with a race. I
had a comment in Thread.start explaining the rationale, but
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #24 from Tomash Brechko ---
Now I see that I was wrong about double removal, please ignore that part.
--
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #23 from Tomash Brechko ---
I think the order of events is such that pthread_create() is followed by
pthread_kill() from main thread before the new thread had any chance to run.
In this case there are reports that the new thread may miss
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #22 from Sean Kelly ---
Yes I misspoke somewhat. The GC acquires the lock to the global thread list
while collecting to ensure that everything remains in a consistent state while
the collection takes place. In this case the GC already ho
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #21 from Sobirari Muhomori ---
This mutex protects various global data like the list of threads in
core.thread, not GC.
--
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #20 from Sean Kelly ---
It should. Not doing so seems pretty broken. But it this particular kernel it
seems like maybe signals are ignored in this situation.
What's happening specifically is that the one thread is blocked on the mutex
p
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #19 from Sobirari Muhomori ---
(In reply to badlink from comment #17)
> stack trace
Hmm... if a thread hangs on a mutex, does it handle signals?
--
https://issues.dlang.org/show_bug.cgi?id=4890
Marco Leise changed:
What|Removed |Added
CC||marco.le...@gmx.de
--- Comment #18 from Marco L
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #17 from badlink ---
Created attachment 1416
--> https://issues.dlang.org/attachment.cgi?id=1416&action=edit
stack trace
--
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #16 from badlink ---
(In reply to Sean Kelly from comment #15)
> Okay, I can't reproduce this using the provided code on Oracle Linux 64-bit.
> If someone has a reliable repro, please let me know.
My Linux machine is using Arch Linux, 3.1
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #15 from Sean Kelly ---
Okay, I can't reproduce this using the provided code on Oracle Linux 64-bit.
If someone has a reliable repro, please let me know.
--
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #14 from Sean Kelly ---
It's likely as I said. The way GC collections work is different on different
platforms. Both Windows and OSX use a kernel call to suspend threads and
inspect their stacks. On other Unix platforms (like Linux), th
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #13 from andrea.9...@gmail.com ---
Just tested, the bug is not present on Windows (DMD 2.066)
--
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #12 from Sean Kelly ---
Um... I may be wrong in what I just said. It looks like someone added a
delegate call within the signal handler for coordinating collections on Linux.
There's a decent chance that a dynamic stack frame is being al
https://issues.dlang.org/show_bug.cgi?id=4890
--- Comment #11 from Sean Kelly ---
My initial guess is that this has something to do with the changes for critical
regions, as the algorithm for collection before that seemed quite solid. I'll
try for a repro on my end though. What would be really
https://issues.dlang.org/show_bug.cgi?id=4890
andrea.9...@gmail.com changed:
What|Removed |Added
Keywords||industry
Status|RESOLVED
https://d.puremagic.com/issues/show_bug.cgi?id=4890
--- Comment #9 from Stanislav Blinov 2014-02-08
15:09:32 PST ---
(In reply to comment #8)
> Does the code in the first post deadlock for you?
No it doesn't.
> If not then issues #11981 / #10351 also look relevant.
>
> For #11981 / #10351,
https://d.puremagic.com/issues/show_bug.cgi?id=4890
safety0ff.bugz changed:
What|Removed |Added
CC||safety0ff.b...@gmail.com
--- Comment
https://d.puremagic.com/issues/show_bug.cgi?id=4890
Stanislav Blinov changed:
What|Removed |Added
CC||stanislav.bli...@gmail.com
http://d.puremagic.com/issues/show_bug.cgi?id=4890
Sean Kelly changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://d.puremagic.com/issues/show_bug.cgi?id=4890
Jakob Bornecrantz changed:
What|Removed |Added
CC||wallbra...@gmail.com
--- Comment #
http://d.puremagic.com/issues/show_bug.cgi?id=4890
Steven Schveighoffer changed:
What|Removed |Added
CC||schvei...@yahoo.com
--- Comment
http://d.puremagic.com/issues/show_bug.cgi?id=4890
d...@dawgfoto.de changed:
What|Removed |Added
CC||d...@dawgfoto.de
--- Comment #3 from
http://d.puremagic.com/issues/show_bug.cgi?id=4890
--- Comment #2 from Sean Kelly 2011-01-04 13:41:41 PST
---
It turns out that the fix I applied produces a race condition with the GC.
I'll have to re-wrap Thread.start() in a synchronized block as per the code
prior to rev 392. This may re-i
http://d.puremagic.com/issues/show_bug.cgi?id=4890
Sean Kelly changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
35 matches
Mail list logo
