libsystem_kernel.dylib`mach_msg_trap:

 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