www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 4890] New: GC.collect() deadlocks multithreaded program.

reply d-bugmail puremagic.com writes:
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



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: -------
Sep 18 2010
next sibling parent d-bugmail puremagic.com writes:
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



---
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: -------
Sep 21 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4890




---
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: -------
Jan 04 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4890


dawg dawgfoto.de changed:

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



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: -------
Jan 21 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4890


Steven Schveighoffer <schveiguy yahoo.com> changed:

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



06:03:14 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.


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: -------
Jan 24 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4890


Jakob Bornecrantz <wallbraker gmail.com> changed:

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



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: -------
Jul 11 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4890


Sean Kelly <sean invisibleduck.org> changed:

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



---
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: -------
Sep 06 2011