[bug #39125] Thread deadlock due to combination of libobjc and NSUserDefaults

[Michael Silva]

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

                 Summary: Thread deadlock due to combination of libobjc and
NSUserDefaults
                 Project: GNUstep
            Submitted by: msilvax28
            Submitted on: Thu 30 May 2013 06:51:50 PM GMT
                Category: Backend
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

I'm running gnustep-based v1.24.4 w/ gcc v4.7.2 using gcc's libobjc runtime.

See the stack trace below.  It appears that libobjc4 has some internal lock
which it keeps when it calls an objects +initialize method.  If that
initialize method calls an object like NSUserDefault that has its own lock and
another thread does the oppose (calls NSUserDefault that then invokes
libobjc4) a thread deadlock can occur.

Not sure if this is something to be fixed in gnustep or libobjc4. I guess I
need some guidance.

(gdb) bt
#0  0xb77ca424 in __kernel_vsyscall ()
#1  0xb6cb9f02 in __lll_lock_wait () from
/lib/i386-linux-gnu/i686/cmov/libpthread.so.0
#2  0xb6cb539b in _L_lock_728 () from
/lib/i386-linux-gnu/i686/cmov/libpthread.so.0
#3  0xb6cb51c1 in pthread_mutex_lock () from
/lib/i386-linux-gnu/i686/cmov/libpthread.so.0
#4  0xb6d18a04 in objc_mutex_lock () from
/usr/lib/i386-linux-gnu/libobjc.so.4
#5  0xb6d173ff in objc_msg_lookup () from
/usr/lib/i386-linux-gnu/libobjc.so.4
#6  0xb6dab6f0 in -[GSMutableArray reverseObjectEnumerator] (self=0xa1dff6c,
_cmd=0xb7192148) at GSArray.m:855
#7  0xb6f6f1b2 in -[NSUserDefaults dictionaryRepresentation] (self=0xeab58bc,
_cmd=0xb7147d10) at NSUserDefaults.m:2016
#8  0xb6e6e9e8 in -[NSDictionary writeToFile:atomically:] (self=0xeb1875c,
_cmd=0x8082330, path=0xe7a6e7c, useAuxiliaryFile=1 '\001') at
NSDictionary.m:1101
#9  0x08053b6c in -[SVC init] (self=0x9d98e24, _cmd=0x80820e0) at svc.m:385
#10 0x0804a512 in main (argc=1, argv=0xbfe02e24) at svc.m:50
(gdb) thread 2
[Switching to thread 2 (Thread 0xb4b44b70 (LWP 6075))]
#0  0xb77ca424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb77ca424 in __kernel_vsyscall ()
#1  0xb6cb9f02 in __lll_lock_wait () from
/lib/i386-linux-gnu/i686/cmov/libpthread.so.0
#2  0xb6cb53a9 in _L_lock_819 () from
/lib/i386-linux-gnu/i686/cmov/libpthread.so.0
#3  0xb6cb523b in pthread_mutex_lock () from
/lib/i386-linux-gnu/i686/cmov/libpthread.so.0
#4  0xb6eb9459 in -[NSRecursiveLock lock] (self=0xeb2fb2c, _cmd=0xb7191eb0) at
NSLock.m:254
#5  0xb6f6d9e4 in -[NSUserDefaults objectForKey:] (self=0xeab58bc,
_cmd=0xb716a8d0, defaultName=0xb716a9a8) at NSUserDefaults.m:1338
#6  0xb6ee96c7 in +[NSPort initialize] (self=0xb716a9c0, _cmd=0xb719a088) at
NSPort.m:91
#7  0xb6d15b0f in ?? () from /usr/lib/i386-linux-gnu/libobjc.so.4
#8  0xb6d15c15 in ?? () from /usr/lib/i386-linux-gnu/libobjc.so.4
#9  0xb6d17413 in objc_msg_lookup () from
/usr/lib/i386-linux-gnu/libobjc.so.4
#10 0xb7671e6f in -[rpmStateSender stateSenderClientThread:] (self=0xeb06cac,
_cmd=0xb767c3b8, condLock=0xeb3a4f4) at rpmStateSender.m:340
#11 0xb6ed11bf in -[NSObject performSelector:withObject:] (self=0xeb06cac,
_cmd=0xb71815c0, aSelector=0xb767c3b8, anObject=0xeb3a4f4) at NSObject.m:2019
#12 0xb6f41fc8 in -[NSThread main] (self=0xb74e26c, _cmd=0xb71815c8) at
NSThread.m:743
#13 0xb6f425aa in nsthreadLauncher (thread=0xb74e26c) at NSThread.m:809
#14 0xb6cb2c39 in start_thread () from
/lib/i386-linux-gnu/i686/cmov/libpthread.so.0
#15 0xb6c1e78e in clone () from /lib/i386-linux-gnu/i686/cmov/libc.so.6




    _______________________________________________________

Reply to this item at:

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

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