https://issues.dlang.org/show_bug.cgi?id=11981
--- Comment #24 from github-bugzi...@puremagic.com ---
Commit pushed to 2.067 at https://github.com/D-Programming-Language/druntime
https://github.com/D-Programming-Language/druntime/commit/e8f6550709c42ef5f62d56bd92a36466fc3c3e3a
don't suspend
https://issues.dlang.org/show_bug.cgi?id=11981
--- Comment #23 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/D-Programming-Language/druntime
https://github.com/D-Programming-Language/druntime/commit/e8f6550709c42ef5f62d56bd92a36466fc3c3e3a
don't suspend
https://issues.dlang.org/show_bug.cgi?id=11981
Sean Kelly s...@invisibleduck.org changed:
What|Removed |Added
CC||s...@invisibleduck.org
https://d.puremagic.com/issues/show_bug.cgi?id=11981
--- Comment #21 from Martin Nowak c...@dawg.eu 2014-02-17 13:35:31 PST ---
*** Issue 11630 has been marked as a duplicate of this issue. ***
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are
https://d.puremagic.com/issues/show_bug.cgi?id=11981
Brad Roberts bra...@puremagic.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://d.puremagic.com/issues/show_bug.cgi?id=11981
--- Comment #19 from github-bugzi...@puremagic.com 2014-02-10 15:16:28 PST ---
Commits pushed to master at https://github.com/D-Programming-Language/druntime
https://d.puremagic.com/issues/show_bug.cgi?id=11981
Martin Nowak c...@dawg.eu changed:
What|Removed |Added
CC||c...@dawg.eu
--- Comment
https://d.puremagic.com/issues/show_bug.cgi?id=11981
--- Comment #16 from safety0ff.bugz safety0ff.b...@gmail.com 2014-02-09
03:13:27 PST ---
(In reply to comment #15)
Async-safe TLS access is scheduled for glibc 2.19 (upcoming
release.)
As I wrote on the pull request, a correct fix would
https://d.puremagic.com/issues/show_bug.cgi?id=11981
--- Comment #17 from Stanislav Blinov stanislav.bli...@gmail.com 2014-02-09
07:03:20 PST ---
I'm starting to wonder if it's really posix-specific. The issue only manifests
when using shared libraries (second malloc call is made from
https://d.puremagic.com/issues/show_bug.cgi?id=11981
--- Comment #18 from Martin Nowak c...@dawg.eu 2014-02-09 10:00:29 PST ---
(In reply to comment #17)
I'm starting to wonder if it's really posix-specific. The issue only manifests
when using shared libraries (second malloc call is made from
https://d.puremagic.com/issues/show_bug.cgi?id=11981
Stanislav Blinov stanislav.bli...@gmail.com changed:
What|Removed |Added
CC|
https://d.puremagic.com/issues/show_bug.cgi?id=11981
--- Comment #3 from safety0ff.bugz safety0ff.b...@gmail.com 2014-02-08
17:07:19 PST ---
That program deadlocks due to the writeln between thread_suspendAll and
thread_resumeAll (removing it removes the deadlock.)
A notable characteristic
https://d.puremagic.com/issues/show_bug.cgi?id=11981
--- Comment #4 from Stanislav Blinov stanislav.bli...@gmail.com 2014-02-08
17:16:28 PST ---
(In reply to comment #3)
That program deadlocks due to the writeln between thread_suspendAll and
thread_resumeAll (removing it removes the
https://d.puremagic.com/issues/show_bug.cgi?id=11981
--- Comment #5 from Stanislav Blinov stanislav.bli...@gmail.com 2014-02-08
18:07:14 PST ---
Ok, I've built druntime with -g -debug and built a modified host.c that runs
infinitely to eventually hit that deadlock:
--- host.c 2014-02-09
https://d.puremagic.com/issues/show_bug.cgi?id=11981
--- Comment #6 from Stanislav Blinov stanislav.bli...@gmail.com 2014-02-08
18:15:46 PST ---
Another run, this time replaced GC.collect() with
thread_suspendAll()/thread_resumeAll() in plugin.d:
--- plugin.d2014-02-09 01:52:48.944214965
https://d.puremagic.com/issues/show_bug.cgi?id=11981
--- Comment #7 from safety0ff.bugz safety0ff.b...@gmail.com 2014-02-08
18:24:18 PST ---
Here's the sequence of events I suspect causes this:
3 Threads:
Thread 2 acquires malloc internal lock
Thread 1 causes a GC collection and therefore
https://d.puremagic.com/issues/show_bug.cgi?id=11981
--- Comment #8 from Stanislav Blinov stanislav.bli...@gmail.com 2014-02-08
18:30:16 PST ---
(In reply to comment #7)
Here's the sequence of events I suspect causes this:
3 Threads:
But there are only 2, unless I am mistaken?
--
https://d.puremagic.com/issues/show_bug.cgi?id=11981
--- Comment #9 from safety0ff.bugz safety0ff.b...@gmail.com 2014-02-08
18:35:18 PST ---
(In reply to comment #8)
(In reply to comment #7)
Here's the sequence of events I suspect causes this:
3 Threads:
But there are only 2, unless I
https://d.puremagic.com/issues/show_bug.cgi?id=11981
--- Comment #10 from Stanislav Blinov stanislav.bli...@gmail.com 2014-02-08
18:40:06 PST ---
(In reply to comment #9)
I assumed there were other threads because the stacktraces were for Threads 1,
4 and 19.
There are only 2: main and one
https://d.puremagic.com/issues/show_bug.cgi?id=11981
--- Comment #11 from Stanislav Blinov stanislav.bli...@gmail.com 2014-02-08
19:09:56 PST ---
Oh, I see. SIGUSR1 is being sent to a thread while it's being constructed.
Either getStackBottom() or rt.tlsgc.init() call malloc(). When SIGUSR1
https://d.puremagic.com/issues/show_bug.cgi?id=11981
--- Comment #12 from Stanislav Blinov stanislav.bli...@gmail.com 2014-02-08
20:23:11 PST ---
So the failing sequence boils down to this:
Main: | t:
|
// t.start(): |
https://d.puremagic.com/issues/show_bug.cgi?id=11981
Stanislav Blinov stanislav.bli...@gmail.com changed:
What|Removed |Added
OS/Version|All |Linux
https://d.puremagic.com/issues/show_bug.cgi?id=11981
Stanislav Blinov stanislav.bli...@gmail.com changed:
What|Removed |Added
Keywords||pull
https://d.puremagic.com/issues/show_bug.cgi?id=11981
--- Comment #14 from safety0ff.bugz safety0ff.b...@gmail.com 2014-02-08
23:25:08 PST ---
(In reply to comment #13)
Not pretty, but possible solution:
The thread start up code looks very race-prone, I hadn't looked at it before.
--
https://d.puremagic.com/issues/show_bug.cgi?id=11981
safety0ff.bugz safety0ff.b...@gmail.com changed:
What|Removed |Added
CC|
25 matches
Mail list logo
