bugGNUstep - Bugs: bug #38980, NSConnection can cause thread...


bug #38980: NSConnection can cause thread deadlock

Submitter:  Michael Silva <msilvax28>
Submitted:  Mon 13 May 2013 04:59:35 PM UTC
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Wont Fix
Privacy:  Public Assigned to:  None
Open/Closed:  Closed

Discussion locked!

Sun 12 Dec 2021 06:39:40 AM UTC, comment #2: 

This "bug" appears to be theoretical.  Has there been an instance of this?  If so, open a bug on github for this.

Gregory John Casamento <gcasa>
Project Administrator
Thu 27 Jun 2013 06:56:08 AM UTC, comment #1: 

I wonder if there's any way to restructure locateLocalTarget to only hold one lock at a time?  As long as it's holding two locks, it's hard to see how to completely avoid the possibility of deadlock.

Richard Frith-Macdonald <CaS>
Project Member
Mon 13 May 2013 04:59:35 PM UTC, original submission:  

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


IRefGate for another NSConnection

In addition, the invalidate method locks objects in this order



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


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.

Michael Silva <msilvax28>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by gcasa (Posted a comment)
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by msilvax28 (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.




    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-12-12 gcasa StatusNone Wont Fix
        Open/ClosedOpen Closed
        Discussion LockUnlocked Locked

    Back to the top

    Powered by Savane 3.9