Service exited due to signal: Broken pipe

Hi,


I'm developing an ios voip application and am facing a app crash on device when application enters foreground after being in background for quite some time. I cannot see any app crash logs in the device. The only logs i can see are the console logs :


Jul 25 17:29:51 iPhone b[1235] <Warning>: Will enter foreground
Jul 25 17:29:51 iPhone SpringBoard[58] <Warning>: UNNotificationSchedulerConnectionListener connection invalidated
Jul 25 17:29:51 iPhone SpringBoard[58] <Warning>: HW kbd: Failed to set (null) as keyboard focus
Jul 25 17:29:51 iPhone SpringBoard[58] <Warning>: UNNotificationRegistrarConnectionListener connection invalidated
Jul 25 17:29:51 iPhone com.apple.xpc.launchd[1] (UIKitApplication:com.a.b[0x9342][1235]) <Notice>: Service exited due to signal: Broken pipe: 13
Jul 25 17:29:51 iPhone SpringBoard[58] <Warning>: Application 'UIKitApplication:com.a.b[0x9342]' exited abnormally via signal.
Jul 25 17:29:52 iPhone backboardd[60] <Warning>: Unable to bootstrap_look_up port with name com.a.b.gsEvents: unknown error code (1102)
Jul 25 17:29:52 iPhone UserEventAgent[26] <Warning>: 1861940979410: id=com.a.b pid=1235, state=0
Jul 25 17:29:52 iPhone SpringBoard[58] <Error>:  SecTrustEvaluate  [leaf IssuerCommonName SubjectCommonName]
Jul 25 17:29:52 iPhone kernel[0] <Notice>: xpcproxy[1238] Container: /private/var/mobile/Containers/Data/Application/12FD6069-827F-4D63-9F1C-0C449104FF83 (sandbox)
Jul 25 17:29:52 iPhone com.apple.xpc.launchd[1] <Error>: assertion failed: 13G34: launchd + 116796 [9F6284CF-8A17-36CC-9DB5-85D510A21F14]: 0x3
Jul 25 17:29:52 iPhone b[1238] <Warning>: App Did Finish Launching: (null)


I'm using socket.io-swift client for backend socket communication. When app enters background, i call it's disconnect method and when app enters foreground i call on its connect method. I have searched a lot for similar issues but haven't yet come across a satisfactory solution.


Thanks for any help!

Up vote post of kkaul Down vote post of kkaul
4.1k views
Posted by
kkaul
Reply
Add a Comment

Replies

SIGPIPE
is generated by the BSD Sockets implementation when you write to a socket that’s been disconnected. The default disposition of 
SIGPIPE
is to kill your process. Our crash reporting infrastructure does not generate a crash report when your app gets terminated in this way. There’s a long-standing bug on file to get this fixed (r. 13921630).

The best way to avoid this problem is to use 

setsockopt
to set 
SO_NOSIGPIPE
on every socket you create. If you use high-level APIs (CFSocketStream, or anything based on that) to create the socket, those APIs do this for you. If you create your own sockets, you have to do it yourself. Once 
SO_NOSIGPIPE
, this situation will result in an easy-to-handle error ( 
EPIPE
) rather than a signal.

While 

SIGPIPE
is a concern whenever you use BSD Sockets, it’s likely that this specific failure is related to your attempts to do networking in the background. The general rules for this are covered in Technote 2277 Networking and Multitasking. Specifically, the socket resource reclaim that’s described in that technote will leave the socket in a state such that writing to it will generate a 
SIGPIPE
.

As to what you should do, that really depends on what VoIP architecture you’re using:

  • If you’re using the new VoIP architecture, based on PushKit, your app should never get suspended in the background while it’s doing networking. If you have a voice call active, the audio session associated with that voice call will keep you from being suspended. And if you don’t have a voice call active, you rely on push notifications to give you ring indication and UIApplication background tasks to keep your app from being suspended in the background for the short time it takes you to respond to those notifications.

  • OTOH, if you’re using the legacy VoIP architecture, well, things get complex. Frankly, now is the time to move on to the new architecture

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

Thanks eskimo for the error context. I must also add that i'm using pushkit notifications in my app. I have tested this scenario in ipad mini, iphone 4s, both being ios 9+, and i cannot reproduce this issue. I can reproduce this issue only in iphone 6. I use https://github.com/socketio/socket.io-client-swift socket.io ios client for backend communication when app is in foreground. when app goes in background, i disconnect this connection. And when app comes in foreground, i re-connect. This issue always happens when app comes to foreground after spending 5-10 mins in background.

Posted by
kkaul
Up vote reply of kkaul Down vote reply of kkaul
Add a Comment

You should set 

SO_NOSIGPIPE
on each of the sockets you’re dealing with directly. My guess is that this will turn this crash into a 
EPIPE
error, at which point you can debug that.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

Follow-up comment on this

Quinn said: "If you use high-level APIs (CFSocketStream, or anything based on that) to create the socket, those APIs do this (set SO_NOSIGPIPE) for you."

We're seeing a SIGPIPE when an external process dies, where our process is writing to a fileHandleForWriting from an (NS)Pipe that the external process is reading from.

Given the above comment, I would not have expected to receive the signal.

Is this the expected behaviour?

Posted by
mild
Up vote reply of mild Down vote reply of mild
Add a Comment

Yeah, I was mainly talking about networking APIs and hadn’t considered NSPipe.

Unfortunately NSPipe is based on a pipe, not a socket, and thus can’t use SO_NOSIGPIPE. However, looking at the pipe man page it seems that there’s an equivalent for pipes, namely F_SETNOSIGPIPE. You should set that.

I also recommend that you file a bug requesting that NSPipe set this automatically. I’m not sure if it’d be possible for us to change this — because of binary compatibility concerns — but it doesn’t hurt to ask.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment