8/4/2019 GDBiPhoneAdventures1

1/4

1

1 Debugging with GDB - XCode iPhone Adventures

Debugging with GDB - XCode iPhone Adventures

Episode 1: The tale of the broken traffic light

This article assumes the reader already knows their way around the XCode development environment, and knowshow to get to the GDB command window while debugging their iPhone app.

ISSUE:

A deadlock occurred in an iPhone app, causing its buttons to become unresponsive. One button was responsiblefor starting a routine, and the other was responsible for stopping the routine. The routine enters some criticalsections of code, and is guarded using mutex and condition variables. One rare occasion, when the stars align justright, a deadlock would occur in the app when trying to stop the routine.

DEBUGGING:

Looking at XCode's UI Debugger, it only listed the main UI thread:

Thread 1 (thread 10755):#0 0x31d47158 in mach_msg_trap ()#1 0x31d49ee0 in mach_msg ()#2 0x30254554 in CFRunLoopRunSpecific ()#3 0x3025416a in CFRunLoopRunInMode ()#4 0x320452a4 in GSEventRunModal ()#5 0x308f037c in -[UIApplication _run] ()#6 0x308eea94 in UIApplicationMain ()#7 0x000023cc in main (argc=3, argv=0x2ffff4cc) main.m:14

I'm sure there's a way to list all threads easily using XCode's UI; however, being used to WinDBG, GDB's commandline interface was more familiar - so I decided to navigate using the GDB command window.

To list a stacktrace for a specific thread:

thread apply backtrace

Example:

(gdb) thread apply 1 backtrace

Thread 1 (thread 10755):#0 0x31d47158 in mach_msg_trap ()#1 0x31d49ee0 in mach_msg ()#2 0x30254554 in CFRunLoopRunSpecific ()#3 0x3025416a in CFRunLoopRunInMode ()#4 0x320452a4 in GSEventRunModal ()#5 0x308f037c in -[UIApplication _run] ()#6 0x308eea94 in UIApplicationMain ()#7 0x000023cc in main (argc=3, argv=0x2ffff4cc) main.m:14

To list all threads for an overview:

(gdb) info threads

8/4/2019 GDBiPhoneAdventures1

2/4

2

2 Debugging with GDB - XCode iPhone Adventures

8 thread 12803 (Thread 0x632b: user=0.000000 system=0.000000 cpu=0sleep_time=0) 0x31dd6510 in __semwait_signal ()

7 thread 12547 (Thread 0x5c23: user=0.000000 system=0.000000 cpu=0sleep_time=0) 0x31d47158 in mach_msg_trap ()

6 thread 12291 (Thread 0x6b1f: user=1.610000 system=1.610000 cpu=0sleep_time=0) 0x31dd6510 in __semwait_signal ()

5 thread 12035 (Thread 0x5e03: user=0.000000 system=0.000000 cpu=0sleep_time=0) 0x31d47158 in mach_msg_trap ()

4 thread 11779 (Thread 0x590b: user=0.050000 system=0.050000 cpu=0sleep_time=0) 0x31d6b0e0 in select$DARWIN_EXTSN ()

3 thread 11267 (Thread 0x1103: user=0.000000 system=0.000000 cpu=0sleep_time=0) 0x31d47158 in mach_msg_trap ()* 1 thread 10755 (Thread 0x0207: user=31.900000 system=31.900000 cpu=0sleep_time=0) 0x31d47158 in mach_msg_trap ()

The * appears to identify the current thread context (need to verify)

Another way to dump stack for current thread:

(gdb) bt #0 0x31d47158 in mach_msg_trap ()#1 0x31d49ee0 in mach_msg ()#2 0x30254554 in CFRunLoopRunSpecific ()#3 0x3025416a in CFRunLoopRunInMode ()#4 0x320452a4 in GSEventRunModal ()#5 0x308f037c in -[UIApplication _run] ()#6 0x308eea94 in UIApplicationMain ()#7 0x000023cc in main (argc=3, argv=0x2ffff4cc) main.m:14

To dump stack for all threads:

(gdb) thread apply all backtrace

Thread 8 (thread 12803):#0 0x31dd6510 in __semwait_signal ()#1 0x31d49760 in nanosleep ()#2 0x31d496e2 in usleep ()#3 0x0000d706 in ButtonHandler (this=0x846c00, pThread=0x139800) atxxxxxxxx.h:xxx#4 0x0000a89a in -[DemoClassVIEW ButtonHandler] (self=0x11a330,_cmd=0x2935c)#5 0x30554068 in -[NSThread main] ()#6 0x305023f8 in __NSThread__main__ ()#7 0x31d705a8 in _pthread_body ()#8 0x00000000 in ?? ()

Thread 7 (thread 12547):#0 0x31d47158 in mach_msg_trap ()#1 0x31d49ee0 in mach_msg ()...#8 0x00000000 in ?? ()

Thread 6 (thread 12291):#0 0x31dd6510 in __semwait_signal ()#1 0x31d782d0 in _pthread_cond_wait () Thread placed in wait state #2 0x31d77a94 in pthread_cond_wait ()

8/4/2019 GDBiPhoneAdventures1

3/4

3

3 Debugging with GDB - XCode iPhone Adventures

...#22 0x30554068 in -[NSThread main] ()#23 0x305023f8 in __NSThread__main__ ()#24 0x31d705a8 in _pthread_body ()#25 0x00000000 in ?? ()

Thread 5 (thread 12035):#0 0x31d47158 in mach_msg_trap ()#1 0x31d49ee0 in mach_msg ()#2 0x30254554 in CFRunLoopRunSpecific ()#3 0x3020d25e in CFRunLoopRun ()#4 0x334531ec in DecodeNotificationThread::ThreadMain ()#5 0x3348d1b8 in CAPThread::Entry ()#6 0x31d705a8 in _pthread_body ()#7 0x00000000 in ?? ()

Thread 4 (thread 11779):#0 0x31d6b0e0 in select$DARWIN_EXTSN ()#1 0x3021dd24 in __CFSocketManager ()#2 0x31d705a8 in _pthread_body ()

#3 0x00000000 in ?? ()

Thread 3 (thread 11267):#0 0x31d47158 in mach_msg_trap ()#1 0x31d49ee0 in mach_msg ()#2 0x30254554 in CFRunLoopRunSpecific ()#3 0x3025416a in CFRunLoopRunInMode ()#4 0x3588dbd0 in RunWebThread ()#5 0x31d705a8 in _pthread_body ()#6 0x00000000 in ?? ()

Thread 1 (thread 10755):#0 0x31d47158 in mach_msg_trap ()#1 0x31d49ee0 in mach_msg ()#2 0x30254554 in CFRunLoopRunSpecific ()#3 0x3025416a in CFRunLoopRunInMode ()#4 0x320452a4 in GSEventRunModal ()#5 0x308f037c in -[UIApplication _run] ()#6 0x308eea94 in UIApplicationMain ()#7 0x000023cc in main (argc=3, argv=0x2ffff4cc) main.m:14

To protect the innocent, I had to snip some of the frames off a few threads - but the point is still achieved. We seethat thread # 6 os waiting on a condition variable, and we see that thread # 8 is waiting on a call to usleep(). Itmakes sense for the call to usleep() to wait... but the other thread (#6) seems to be waiting for a condition to besignaled.

Looking at the code around the wait (pseudo code shown below):

void SomeFunc(){

pthread_mutex_lock(&mutex); printf("Waiting on some event to be signaled!\n");pthread_cond_wait(&cond, &mutex);pthread_mutex_unlock(&mutex);

8/4/2019 GDBiPhoneAdventures1

4/4