User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0.1 Build ID: 20120615233552 Steps to reproduce: Browsing a website Actual results: I am not sure what happened and this error is not consistently reproducible. I was browing a website and on a button submit, firefox crashes. After that, I ran firefox inside GDB and obtained the stacktrace. It took sometime to crash. Program received signal SIGPIPE, Broken pipe. [Switching to Thread 0x7fffe96ff700 (LWP 6970)] 0x00007ffff7bcd767 in send () from /lib/libpthread.so.0 (gdb) bt #0 0x00007ffff7bcd767 in send () from /lib/libpthread.so.0 #1 0x00007ffff1afe36b in ?? () from /usr/lib/libnspr4.so #2 0x00007ffff411a74b in ssl_DefSend () from /usr/lib/libssl3.so #3 0x00007ffff410c210 in ssl3_SendRecord () from /usr/lib/libssl3.so #4 0x00007ffff410e29f in SSL3_SendAlert () from /usr/lib/libssl3.so #5 0x00007ffff411f4a3 in ssl_SecureClose () from /usr/lib/libssl3.so #6 0x00007ffff590f807 in ?? () from /usr/lib/firefox/libxul.so #7 0x00007ffff590f869 in ?? () from /usr/lib/firefox/libxul.so #8 0x00007ffff5011af2 in ?? () from /usr/lib/firefox/libxul.so #9 0x00007ffff50123d8 in ?? () from /usr/lib/firefox/libxul.so #10 0x00007ffff501384d in ?? () from /usr/lib/firefox/libxul.so #11 0x00007ffff50141be in ?? () from /usr/lib/firefox/libxul.so #12 0x00007ffff501434c in ?? () from /usr/lib/firefox/libxul.so #13 0x00007ffff5b74bd7 in ?? () from /usr/lib/firefox/libxul.so #14 0x00007ffff5b41859 in ?? () from /usr/lib/firefox/libxul.so #15 0x00007ffff5b753dd in ?? () from /usr/lib/firefox/libxul.so #16 0x00007ffff1b013c3 in ?? () from /usr/lib/libnspr4.so #17 0x00007ffff7bc6e0e in start_thread () from /lib/libpthread.so.0 #18 0x00007ffff73fa1ed in clone () from /lib/libc.so.6 WARNING: pipe error (3): Connection reset by peer: file /build/src/mozilla-release/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 419 Expected results: It should not have crashed

We need a stacktrace with debug symbols

same experience since version 21 and reported as security issue until now(25) it's not fixed yet --- #0 0x00007f188b2aec9b in send () from /lib64/libpthread.so.0 #1 0x00007f188a26c698 in pt_Send (fd=0x600800ac10d0, buf=0x6084001cc200, amount=0x25, flags=0x0, timeout=0xffffffff) at /tmp/mozilla-release/nsprpub/pr/src/pthreads/ptio.c:1914 #2 0x00007f1888fd5acd in ssl_DefSend (ss=ss@entry=0x607a001ddd00, buf=0x6084001cc200 "\025\003\001", len=0x25, flags=0x0) at ssldef.c:94 #3 0x00007f1888faba1b in ssl3_SendRecord (ss=ss@entry=0x607a001ddd00, epoch=epoch@entry=0x0, type=type@entry=content_alert, pIn=0x7f1872834282 "\203r\030\177", pIn@entry=0x7f1872834280 "\001", nIn=0x0, nIn@entry=0x2, flags=flags@entry=0x0) at ssl3con.c:2891 #4 0x00007f1888fac791 in SSL3_SendAlert (ss=ss@entry=0x607a001ddd00, level=level@entry=alert_warning, desc=desc@entry=close_notify) at ssl3con.c:3182 #5 0x00007f1888fe3db7 in ssl_SecureClose (ss=0x607a001ddd00) at sslsecur.c:1060 #6 0x00007f1880f3c834 in nsNSSSocketInfo::CloseSocketAndDestroy (this=this@entry=0x6028002fe3c0) at /tmp/mozilla-release/security/manager/ssl/src/nsNSSIOLayer.cpp:838 #7 0x00007f1880f3c9f0 in nsSSLIOLayerClose (fd=<optimized out>) at /tmp/mozilla-release/security/manager/ssl/src/nsNSSIOLayer.cpp:816 #8 0x00007f187ee3a6a1 in nsSocketTransport::ReleaseFD_Locked (this=0x603000173e40, fd=<optimized out>) at /tmp/mozilla-release/netwerk/base/src/nsSocketTransport2.cpp:1458 #9 0x00007f187ee40f04 in nsSocketTransport::OnSocketDetached (this=0x603000173e40, fd=<optimized out>) at /tmp/mozilla-release/netwerk/base/src/nsSocketTransport2.cpp:1705 #10 0x00007f187ee49e45 in nsSocketTransportService::DetachSocket (this=this@entry=0x60240001cc40, listHead=0x605e000be580, sock=0x605e000be610) at /tmp/mozilla-release/netwerk/base/src/nsSocketTransportService2.cpp:182 #11 0x00007f187ee4ae1c in nsSocketTransportService::DoPollIteration (this=this@entry=0x60240001cc40, wait=<optimized out>) at /tmp/mozilla-release/netwerk/base/src/nsSocketTransportService2.cpp:823 #12 0x00007f187ee4b500 in nsSocketTransportService::Run (this=0x60240001cc40) at /tmp/mozilla-release/netwerk/base/src/nsSocketTransportService2.cpp:645 #13 0x00007f1881fc2826 in nsThread::ProcessNextEvent (this=0x60220001cc60, mayWait=<optimized out>, result=<optimized out>) at /tmp/mozilla-release/xpcom/threads/nsThread.cpp:622 #14 0x00007f1881f13174 in NS_ProcessNextEvent (thread=<optimized out>, thread@entry=0x60220001cc60, mayWait=mayWait@entry=0x1) at /tmp/mozilla-release/obj/xpcom/build/nsThreadUtils.cpp:238 #15 0x00007f1881fc532b in nsThread::ThreadFunc (arg=0x60220001cc60) at /tmp/mozilla-release/xpcom/threads/nsThread.cpp:250 #16 0x00007f188a2757c5 in _pt_root (arg=0x60260000e8a0) at /tmp/mozilla-release/nsprpub/pr/src/pthreads/ptthread.c:204 #17 0x00007f188b4d5b28 in ?? () from /usr/lib64/libasan.so.0 #18 0x00007f188b2a7ce2 in start_thread () from /lib64/libpthread.so.0 #19 0x00007f188a5b2abd in clone () from /lib64/libc.so.6 ---

We ignore SIGPIPE by default (http://mxr.mozilla.org/mozilla-central/source/nsprpub/pr/src/md/unix/unix.c#2872) so I don't understand why this would be fatal at all.

Ignore SIGPIPE means anti race condition ?

No, it means that pipe failure is a normal operating condition and so we ignore pipe signals.

https://bugzilla.mozilla.org/show_bug.cgi?id=886166 may be a duplicate.