[bug #39092] NSLock deadlock even in trivial GSWeb application

[Graham Lee]

Follow-up Comment #2, bug #39092 (project gnustep):

I have a little more information about the other deadlock condition I've seen;
it doesn't help me understand it but hopefully it'll give you some clues :-).
I added a DirectAction class to the empty app, set the default handler to the
direct action handler, and now the app deadlocks when a browser connects to
the direct connect URL:

#0  0x00007fff8bc09c07 in -[NSLock lock] ()
#1  0x000000010002996a in -[WOApplication pageWithName:inContext:]
(self=0x101e14bd0, _cmd=<value temporarily unavailable, due to optimizations>,
aName=0x0, aContext=0x101882b10) at GSWApplication.m:1826
#2  0x000000010006da40 in -[GSWAction pageWithName:] (self=<value temporarily
unavailable, due to optimizations>, _cmd=<value temporarily unavailable, due
to optimizations>, pageName=<value temporarily unavailable, due to
optimizations>) at GSWAction.m:160
#3  0x000000010006e16a in -[WODirectAction defaultAction] (self=0x101e14db0,
_cmd=<value temporarily unavailable, due to optimizations>) at
GSWDirectAction.m:98
#4  0x000000010006e043 in -[WODirectAction performActionNamed:]
(self=0x101e1d660, _cmd=0x1000a1236, actionName=0x1000f2b80) at
GSWDirectAction.m:72
#5  0x0000000100071459 in -[GSWActionRequestHandler _handleRequest:]
(self=0x101866a20, _cmd=0x1000a145c, aRequest=0x101e1c910) at
GSWActionRequestHandler.m:363
#6  0x0000000100070afd in -[GSWActionRequestHandler handleRequest:]
(self=0x101866a20, _cmd=<value temporarily unavailable, due to optimizations>,
aRequest=0x101e1c910) at GSWActionRequestHandler.m:140
#7  0x000000010002a560 in -[WOApplication dispatchRequest:] (self=0x101e14bd0,
_cmd=<value temporarily unavailable, due to optimizations>,
aRequest=0x101e1c910) at GSWApplication.m:2210
#8  0x0000000100084252 in -[GSWWorkerThread runOnce] (self=0x101e18140,
_cmd=<value temporarily unavailable, due to optimizations>) at
GSWWorkerThread.m:183
#9  0x00007fff8bc4ccd2 in __NSThread__main__ ()
#10 0x00007fff965fd7a2 in _pthread_start ()
#11 0x00007fff965ea1e1 in thread_start ()
2013-05-29 07:43:15.807 EmptyApp[798:3707] *** -[NSLock lock]: deadlock
(<NSLock: 0x101e14db0> '(null)')

As I understand it, NSLock will deadlock when a thread tries to acquire a lock
that thread already has. I couldn't see in gdb where that was happening. I
tried to supply my own lock class that checked for the same-thread condition
in -lock and -tryLock, and while it still deadlocked my condition never
triggered.

Switching the NSLock for an NSRecursiveLock _does_ remove the deadlock, but I
don't know why it's occurring :-(

    _______________________________________________________

Reply to this item at:

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

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