427889 - SIGPIPE from send() syscall, called from libpthread

Status: RESOLVED INVALID

(NSS :: Libraries, defect)

Description

[Fabien Tassin]

When restarting firefox after a crash, restoring a session with 15 tabs, it crashed before all tabs were loaded. I was running nss from 2008-04-07 00:03
so 3.12 RC1 + the next two commits.

Here is the trace.


[New Thread 0xabbc4b90 (LWP 7884)]

Program received signal SIGPIPE, Broken pipe.
[Switching to Thread 0xb5d31b90 (LWP 7859)]
0xb7fd7410 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fd7410 in __kernel_vsyscall ()
#1  0xb7fb5e38 in send () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb7c12f53 in pt_Send (fd=0xb1502000, buf=0xb152c830, amount=23, flags=0, timeout=4294967295) at ptio.c:1912
#3  0xb6fd2255 in ssl_DefSend (ss=0xb1529c28, buf=0xb152c830 "\025\003\001", len=23, flags=0) at ssldef.c:128
#4  0xb6fc2f4c in ssl3_SendRecord (ss=0xb1529c28, type=<value optimized out>, pIn=0xb5d3101a "\001", nIn=2, flags=0)
    at ssl3con.c:2041
#5  0xb6fc33be in SSL3_SendAlert (ss=0xb1529c28, level=alert_warning, desc=<value optimized out>) at ssl3con.c:2296
#6  0xb6fd5f62 in ssl_SecureClose (ss=0xb1529c28) at sslsecur.c:1015
#7  0xb6fda847 in ssl_Close (fd=0xb313c638) at sslsock.c:1405
#8  0xb7748121 in nsNSSSocketInfo::CloseSocketAndDestroy (this=0xb313c810) at nsNSSIOLayer.cpp:1398
#9  0xb773a262 in nsSSLThread::requestClose (si=0xb313c810) at nsSSLThread.cpp:423
#10 0xb7746c8f in nsSSLIOLayerClose (fd=0xb313c638) at nsNSSIOLayer.cpp:1383
#11 0xb7bf9131 in PR_Close (fd=0xb313c638) at priometh.c:136
#12 0xb71cd042 in nsSocketTransport::ReleaseFD_Locked (this=0xb313c0f8, fd=0xb313c638)
    at nsSocketTransport2.cpp:1367
#13 0xb71cec2c in nsSocketTransport::OnSocketDetached (this=0xb313c0f8, fd=0xb313c638)
    at nsSocketTransport2.cpp:1590
#14 0xb71d0c4b in nsSocketTransportService::DetachSocket (this=0x815e718, sock=0x815e740)
    at nsSocketTransportService2.cpp:179
#15 0xb71d14a0 in nsSocketTransportService::DoPollIteration (this=0x815e718, wait=1)
    at nsSocketTransportService2.cpp:681
#16 0xb71d151e in nsSocketTransportService::OnProcessNextEvent (this=0x815e718, thread=0x815e200, mayWait=1, 
    depth=1) at nsSocketTransportService2.cpp:523
#17 0xb793584e in nsThread::ProcessNextEvent (this=0x815e200, mayWait=1, result=0xb5d312b0) at nsThread.cpp:497
#18 0xb7904e97 in NS_ProcessNextEvent_P (thread=0xb5d30ed0, mayWait=1) at nsThreadUtils.cpp:227
#19 0xb71d18a6 in nsSocketTransportService::Run (this=0x815e718) at nsSocketTransportService2.cpp:565
#20 0xb79358aa in nsThread::ProcessNextEvent (this=0x815e200, mayWait=1, result=0xb5d31360) at nsThread.cpp:510
#21 0xb7904e97 in NS_ProcessNextEvent_P (thread=0xb5d30ed0, mayWait=1) at nsThreadUtils.cpp:227
#22 0xb7935c6b in nsThread::ThreadFunc (arg=0x815e200) at nsThread.cpp:254
#23 0xb7c157fa in _pt_root (arg=0x815ef80) at ptthread.c:221
#24 0xb7fae4fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#25 0xb7e08e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Comment 1

[timeless]

we should catch sigpipe and do something with it...

Comment 2

[Wan-Teh Chang]

NSPR installs a signal handler to ignore SIGPIPE:
http://lxr.mozilla.org/nspr/source/nsprpub/pr/src/md/unix/unix.c#2874

Since NSS uses NSPR, SIGPIPE should be ignored.  Fabien, could
you use the debugger to find out if the sigaction call I cited above is
executed successfully?

Comment 3

[Fabien Tassin]

I haven't been able to reproduce that crash since.
I've got it 2 or 3 times before.

Comment 4

[timeless]

reporter, were you running firefox in a debugger?

(gdb) handle SIGPIPE
Signal        Stop      Print   Pass to program Description
SIGPIPE       Yes       Yes     Yes             Broken pipe

by default gdb will stop at SIGPIPEs, however, this is not a crash. it's merely informing you of an event that it considers important.

you may either do:
(gdb) handle SIGPIPE nostop
Signal        Stop      Print   Pass to program Description
SIGPIPE       No        Yes     Yes             Broken pipe

or:
(gdb) handle SIGPIPE noprint
Signal        Stop      Print   Pass to program Description
SIGPIPE       No        No      Yes             Broken pipe

noprint implies nostop, so there is no need to do both. and you should only use nostop if you have some very strange reason for caring about SIGPIPEs, which average users do not.

Comment 5

[Fabien Tassin]

> were you running firefox in a debugger?

for the back trace above, yes but as I said, I cannot provide more info as it no longer crashes there.

Comment 6

[timeless]

ok. so, please don't take this the wrong way. this is basically a false positive. the program wasn't crashing on its own, gdb just gave you feedback which you misinterpreted as a crash. it's not your fault, most of the time gdb gets a signal, it is for a crash, this just isn't one of those times.

you can configure a .gdbrc or something to add a handle SIGPIPE nostop
http://www.mozilla.org/unix/debugging-faq.html has some examples of things to put into a gdbrc and some explanation of various bits.

http://www.mozilla.org/unix/debugging-faq.html#sig32 is fairly similar, and we probably could/should add an item that explains sigpipe and offers the same sort of suggestion (handle SIGPIPE nostop).

thanks for your time.