Thank you for the reproduction program. I think the problem is that the Xcode debugger stops on a SIGPIPE, making it look like your app crashed. If I run your app, provoke the SIGPIPE and then select Debug > Continue, your test app continues without crashing. The same happens if I run your test directly from a device without the Xcode debugger attached.
The CL that fixed issue 17393, https://go-review.googlesource.com/c/go/+/35960, made sure SIGPIPEs from Go itself was properly handled, but it didn't suppress SIGPIPE. There's is a socket option for that, SO_NOSIGPIPE, but unfortunately that's only available on Darwin so it isn't used. - elias On Tuesday, February 13, 2018 at 7:54:09 AM UTC+1, [email protected] wrote: > > I managed to get a small reproducible test case. The issue is easy to > reproduce. Basically if you spawn some http requests immediately after the > application comes back from background you get SIGPIPE. > Step by step: > 1. Open ios remote.xcodeproj in XCode > 2. Run the application on a real device. > 3. Put the application in background (press the "stand by/lock-in" button) > 4. Get it out of background (i.e. unlock the phone) > 5. You get SIGPIPE > > https://github.com/themihai/testios > > > gomobile version > gomobile version +5704e18 Mon Jan 22 17:02:51 2018 +0000 (android,ios); > androidSDK= > > Mihai. > > > > On Tuesday, February 6, 2018 at 12:53:06 AM UTC+2, Elias Naur wrote: >> >> It's hard to know what's causing the SIGPIPE without more information. >> Ideally, a standalone recipe to reproduce the problem. >> >> Make sure you have the latest version of gomobile as well. >> >> - elias >> >> On Monday, February 5, 2018 at 10:53:09 PM UTC+1, [email protected] wrote: >>> >>> I'm trying to develop a gomobile application using a http server serving >>> html and a swift client serving the content from localhost through a >>> WKWebView. All the work happens inside the http handlers(i.e. http requests >>> to external API servers). >>> The issue is that after several requests the application crashes with >>> SIGPIPE. I've searched through issues and it seems this was a known issue >>> and apparently was fixed in [0]. How can I debug this further or is there >>> any known fix? >>> >>> >>> libsystem_kernel.dylib`mach_msg_trap: >>> >>> 0x180c5b560 <+0>: mov x16, #-0x1f >>> >>> 0x180c5b564 <+4>: svc #0x80 >>> >>> -> 0x180c5b568 <+8>: ret >>> >>> >>> >>> >>> $ go version >>> go version go1.9.2 darwin/amd64 >>> >>> >>> https://github.com/golang/go/issues/17393 >>> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
