stop reason = signal SIGPIPE
问题描述
模拟器或者真机调试时,客户端切换到不同的开发站点或者链接不上socket,会导致应用程序进入一种无法离开的debug状态
libsystem_kernel.dylib`mach_msg_trap:
0x210ce8bc <+0>: mov r12, sp
0x210ce8c0 <+4>: push {r4, r5, r6, r8}
0x210ce8c4 <+8>: ldm r12, {r4, r5, r6}
0x210ce8c8 <+12>: mvn r12, #30
0x210ce8cc <+16>: svc #0x80
-> 0x210ce8d0 <+20>: pop {r4, r5, r6, r8}
0x210ce8d4 <+24>: bx lr
(lldb) bt
* thread #1: tid = 0x7ec58, 0x210ce8d0 libsystem_kernel.dylib`mach_msg_trap + 20, queue = 'com.apple.main-thread', stop reason = signal SIGPIPE
* frame #0: 0x210ce8d0 libsystem_kernel.dylib`mach_msg_trap + 20
frame #1: 0x210ce6d4 libsystem_kernel.dylib`mach_msg + 40
frame #2: 0x21419ac4 CoreFoundation`__CFRunLoopServiceMachPort + 136
frame #3: 0x21417e4c CoreFoundation`__CFRunLoopRun + 1036
frame #4: 0x21367228 CoreFoundation`CFRunLoopRunSpecific + 520
frame #5: 0x21367014 CoreFoundation`CFRunLoopRunInMode + 108
frame #6: 0x22957ac8 GraphicsServices`GSEventRunModal + 160
frame #7: 0x25a3b188 UIKit`UIApplicationMain + 144
frame #8: 0x000c5f00 InfowarelabIOSClient`main(argc=1, argv=0x01b72a5c) + 164 at main.m:17
frame #9: 0x2100f872 libdyld.dylib`start + 2
问题原因:
在iOS手机client请求到Server端试图建立TCP连接时,往往需要多次请求,中间会有失败的请求,所以服务器会经常去close一个连接,在TCP连接中,client会收到
一个RST响应。之前如果client已发出的数据,系统会发出SIGPIPE信号给client进程,告诉进程这个连接已经失效,不要再去写数据了。若根据默认规则,应用程
序进程会被terminate,client的进程会退出。根据测试的现象来看,ios应用程序并没有直接退出,看来是做了SIGPIPE信号屏蔽处理,屏蔽处理让app收到SIGPIPE
信号之后不会crash。但是会在进行debug调试时触发debug中断,正如上述现象。
参考解决方案
要从根本上解决这个问题,需要服务端与客户端协同进行修改处理。但是在客户端别人提供了个临时解决的办法,就是在调试入口设置断点,让debug console进入
gdb或是lldb状态。我们IOS开发使用的是LLVM,所以使用process handle SIGPIPE -s false。
gdb
handle SIGPIPE nostop
lldb
process handle SIGPIPE -s false
断点设置如下:
之后形成断点如下:
转自:http://blog.csdn.net/lizitao/article/details/39476845