bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #38980] NSConnection can cause thread deadlock


From: Michael Silva
Subject: [bug #38980] NSConnection can cause thread deadlock
Date: Mon, 13 May 2013 16:59:37 +0000
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17

URL:
  <http://savannah.gnu.org/bugs/?38980>

                 Summary: NSConnection can cause thread deadlock
                 Project: GNUstep
            Submitted by: msilvax28
            Submitted on: Mon 13 May 2013 04:59:35 PM GMT
                Category: Base/Foundation
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

There are cases in NSConnection when the use of NSRecursiveLocks between
objects can lead to 2 threads deadlocking.

The case I have seen is in gnustep-base v1.24.4.

The NSConnection method locateLocalTarget: locks the following objects in this
order

IrefGate for self

connection_table_gate

IRefGate for another NSConnection


In addition, the invalidate method locks objects in this order

IrefGate

connection_table_gate


I have seen 1 lockup scenario, and fear for another occuring.

Scenario:

NSConnection 'A' has its locateLocalTarget: methods called.  It locks the
local IrefGate and proceeds into the method.  Later in the method it locks
connection_table_gate and begins to scan the members of the connection_table.

Another NSConnection 'B' has invalidate called on another thread.  It locks
the local IrefGate and proceeds into the method.  It later attempts to lock
connection_table_gate but cannot as the thread running NSConnection 'A' has
it.  The thread blocks.

Back on the thread for NSConnection 'A', while enumerating connection_table it
attempts to lock NSConnection 'B' IrefGate.  It cannot, because the thread
running NSConnection 'B' has it.  So it locks.

The threads running NSConnections A and B are now deadlocked.


I am also concerned that the same deadlock can happen if both Connection A and
B enter locateLocalTarget at the same time where one connection gets its local
IrefGate and connection_table_gate and the other gets only its local
IRefGate.

I don't have enough context on the software to recommend a solution, although
I have 'tinkered' with something that seems to help (still testing).

For information, in my test application it takes about 8-12 hours of
continuous run before this condition occurs.







    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?38980>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]