SIGPIPE on error: pubsub: already have connection to peer about go-textile

[sanderpick]

To clarify, that error pops up right after you resume from receiving the signal:

(lldb) process handle SIGPIPE -n false -p true -s false
NAME         PASS   STOP   NOTIFY
===========  =====  =====  ======
SIGPIPE      true   false  false

Adding a symbolic breakpoint in Xcode let's you temporarily get on with your day:

https://stackoverflow.com/questions/10431579/permanently-configuring-lldb-in-xcode-4-3-2-not-to-stop-on-signals

[sanderpick]

Android:

05-01 11:03:44.322 21148-21174/com.textilephotos I/System.out: [socket][36:-1] exception
05-01 11:03:44.328 21148-21236/com.textilephotos I/System.out: [socket][37:-1] exception
05-01 11:03:46.347 21148-21174/com.textilephotos I/System.out: [socket][38:-1] exception
05-01 11:03:46.353 21148-21238/com.textilephotos I/System.out: [socket][39:-1] exception
05-01 11:03:48.371 21148-21174/com.textilephotos I/System.out: [socket][40:-1] exception
05-01 11:03:48.377 21148-21243/com.textilephotos I/System.out: [socket][41:-1] exception
05-01 11:03:50.393 21148-21174/com.textilephotos I/System.out: [socket][42:-1] exception
05-01 11:03:50.399 21148-21245/com.textilephotos I/System.out: [socket][43:-1] exception

[sanderpick]

I think this is what we're seeing here:
https://go-review.googlesource.com/c/go/+/10010

Also related: "runtime: SIGPIPE is raised when using net.DialTimeout and timeout is reached"
golang/go#17393

...which is apparently a dup of: golang/go#17393

We're not crashing, just getting them stuck in lldb, you can ignore from then on with (lldb) process handle SIGPIPE -n false -p true -s false

Seems like some good fixed there if you're running a normal program, not sure how to deal with this is a gobind-ed lib. Anyway, not too worried for now

[sanderpick]

Closing this as the symbolic break point works fine