http://d.puremagic.com/issues/show_bug.cgi?id=4890

           Summary: GC.collect() deadlocks multithreaded program.
           Product: D
           Version: D2
          Platform: x86
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: tomash.brechko@gmail.com


--- Comment #0 from Tomash Brechko <tomash.brechko@gmail.com> 2010-09-18 14:31:41 PDT ---
The following program deadlocks with dmd 2.049 (all the time, though it may be
subject to a race):

import core.thread;
import core.memory;
import std.stdio;

class Job : Thread
{
  this()
  {
    super(&run);
  }

private:
  void run()
  {
    while (true)
      write("*");
  }
}

void
main()
{
  Job j = new Job;
  j.start();

  //j.sleep(1);

  GC.collect();

  while(true)
    write(".");
}

Uncommenting j.sleep(1); avoids the deadlock.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4890


Sean Kelly <sean@invisibleduck.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |sean@invisibleduck.org


--- Comment #1 from Sean Kelly <sean@invisibleduck.org> 2010-09-21 11:35:29 PDT ---
Fixed in druntime changeset 392.  Will be in DMD-2.050.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4890



--- Comment #2 from Sean Kelly <sean@invisibleduck.org> 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-introduce the deadlock, in which case it will be necessary to replace the isRunning flag with a state field that distinguishes starting from running.  A starting thread should be suspended/resumed but not scanned.  Or perhaps something else can be sorted out to deal with a thread being in the list that doesn't have its TLS section set, getThis() doesn't work, etc.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4890


dawg@dawgfoto.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dawg@dawgfoto.de


--- Comment #3 from dawg@dawgfoto.de 2011-01-21 15:12:13 PST ---
I've also stumbled over the racing condition in thread_processGCMarks() where a thread was already added to the global thread list but didn't had it's m_tls set yet. It seems fine to test for m_tls being null at that specific place.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4890


Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com


--- Comment #4 from Steven Schveighoffer <schveiguy@yahoo.com> 2011-01-24 06:03:14 PST ---
(In reply to comment #3)
> I've also stumbled over the racing condition in thread_processGCMarks() where a thread was already added to the global thread list but didn't had it's m_tls set yet. It seems fine to test for m_tls being null at that specific place.

That's something that I recently added.

Sean, can you confirm that if a thread's m_tls is not yet set, then it's actual TLS can not have been used yet?  It seems reasonable to check the tls block for null at that point.

(will have to start using github soon...)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4890


Jakob Bornecrantz <wallbraker@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wallbraker@gmail.com


--- Comment #5 from Jakob Bornecrantz <wallbraker@gmail.com> 2011-07-11 18:01:31 PDT ---
This looks fixed with 2.054 on MacOSX, at least I can repro this.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4890


Sean Kelly <sean@invisibleduck.org> changed:

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


--- Comment #6 from Sean Kelly <sean@invisibleduck.org> 2011-09-06 11:39:15 PDT ---
A thread will be added to the global thread list before its TLS range is set, but the range will be set before the thread ever actually uses TLS data.  I think this one can be closed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------