svc＃128在pthread_kill中意外闯入调试器？

Question

I'm seeing unexpected breaks in to the debugger in Xcode, related to the svc #128 ARM instruction from a call to pthread_kill to signal another thread. I've seen this for a number of StackOverflow questions related to this issue on iOS - but they weren't helpful for me. In this case, doing Debug->Continue (^⌘Y) repeatedly resolves the problem and execution continues without any apparent side effects. Also, if it's run outside of the debugger, then the app works fine. My goal is to understand why this is happening and avoid breaking in to the debugger except when intended.

Is there an Xcode setting that I might have accidentally set that breaks on these signals?

I'm using Google's Java to Objective-C Transpiler (j2objc), though other iOS devs have mentioned this issue unrelated to j2objc, so I don't believe that's the cause. It occurs when the j2objc Java Runtime Environment Emulation project is signaling other blocked threads. It consistently has 3 threads to signal. After doing Debug->Continue three times, then the program execution carries on without issue or apparent side effect. There are no breakpoints in the project.

The app spawns another thread at startup that uses the Java DatagramSocket class. The Java code works correctly. The transpiled Objective-C code also works correctly except for the annoying breaks in to the debugger.

This is the Stack Frame at interrupt:

main (1)Queue : com.apple.main-thread (serial)
#0  0x0000000195557270 in __pthread_kill ()
#1  0x00000001955f5228 in pthread_kill ()
// Java Runtime Environment Emulation
#2  0x00000001002f7898 in +[AsynchronousSocketCloseMonitor signalBlockedThreads:] ()
#3  0x00000001002f9754 in LibcoreIoIoBridge_closeSocketWithJavaIoFileDescriptor_ ()
#4  0x00000001001f4894 in -[JavaNetPlainDatagramSocketImpl close] ()
// My Code
#5  0x000000010016db88 in <my code>...

Local assembly in kernel pthread_kill method...

libsystem_kernel.dylib`__pthread_kill:
0x195557268:  movz   x16, #328
0x19555726c:  svc    #128
// The debugger lands on the following line but I think svc #128 is the cause
0x195557270:  b.cc   0x195557288               ; __pthread_kill + 32
0x195557274:  stp    fp, lr, [sp, #-16]!
0x195557278:  mov    fp, sp
0x19555727c:  bl     0x19553e59c               ; cerror_nocancel
0x195557280:  mov    sp, fp
0x195557284:  ldp    fp, lr, [sp], #16
0x195557288:  ret

The closest non-kernel function in the stack frame is signalBlockedThreads . When my code closes the socket, signalBlockedThreads iterates through all the threads, looking for those blocked against a specific file descriptor (I presume this corresponds to the port number that was just closed). For those relevant blocked threads, they're each signaled with pthread_kill. The method code is copied below.

For the file link, even though this is a Java file, it has embedded Objective-C code that is preserved by the j2objc transpiler:

https://github.com/google/j2objc/blob/765354b620b2c0248945b27062209620d4cf5e40/jre_emul/android/libcore/luni/src/main/java/libcore/io/AsynchronousCloseMonitor.java#L89

+ (void)signalBlockedThreads:(int)fd {
  pthread_mutex_lock(&blockedThreadListMutex);
  for (AsynchronousSocketCloseMonitor* it = blockedThreadList; it != NULL; it = it->mNext) {
    if (it->mFd == fd) {
      // MY ADDED COMMENT: BLOCKED_THREAD_SIGNAL == SIGUSR2 in this code
      pthread_kill(it->mThread, BLOCKED_THREAD_SIGNAL);
      // Keep going, because there may be more than one thread...
    }
  }
  pthread_mutex_unlock(&blockedThreadListMutex);
}

Debug attempts without success: * Add and remove "All Exceptions" breakpoint - nothing revealed by this * Remove closeSocket call - averts issue but obviously not a solution to leave socket open

Answer 1

There's a trick to asking Xcode to ignore the signals. I'm curious as to why Xcode is configured by default to interrupt on signals but there you go. Note that the method varies according to the language that you're using - I've edited it to extend the example to Swift:

Permanently configuring LLDB (in Xcode 4.3.2) not to stop on signals