522235 - SIGPIPE on SSL/NSS close in debug build

Status: RESOLVED INVALID

(NSPR :: NSPR, defect)

Description

[Matthew Cline]

On an i586 Linux debug build from source pulled around Oct 14 5:20 AM PDT from mozilla-central, I get a SIGPIPE crash if I open up enough copies of the given URL in multiple tabs.  Oddly, the non-debug nightly has no problems (though it did hang with no CPU consumption on the same page), and also oddly there doesn't seem to be any https content in the page.

The stack trace:

#0  0xffffe430 in __kernel_vsyscall ()
#1  0xb80900e8 in send () from /lib/i686/libpthread.so.0
#2  0xb7a2216e in pt_Send (fd=0xc08ee60, buf=0xbe20750, amount=23, flags=0,
    timeout=0) at ptio.c:1931
#3  0xb4dd5859 in ssl_DefSend (ss=0xdf13000, buf=0xbe20750 "\025\003\001",
    len=23, flags=0) at ssldef.c:128
#4  0xb4dbe54d in ssl3_SendRecord (ss=0xdf13000, type=content_alert,
    pIn=0xb3b22f48 "", nIn=0, flags=0) at ssl3con.c:2061       
#5  0xb4dbedb3 in SSL3_SendAlert (ss=0xdf13000, level=alert_warning,
    desc=close_notify) at ssl3con.c:2316       
#6  0xb4ddc5e0 in ssl_SecureClose (ss=0xdf13000) at sslsecur.c:1039
#7  0xb4de33fc in ssl_Close (fd=0xb277248) at sslsock.c:1406
#8  0xb4e5b944 in nsNSSSocketInfo::CloseSocketAndDestroy (this=0xc42b568)
    at nsNSSIOLayer.cpp:1739  
#9  0xb4e4016d in nsSSLThread::requestClose (si=0xc42b568)
    at nsSSLThread.cpp:437
#10 0xb4e58ee3 in nsSSLIOLayerClose (fd=0xb277248) at nsNSSIOLayer.cpp:1724
#11 0xb7a02a31 in PR_Close (fd=0xb277248) at priometh.c:136
#12 0xb5cfe294 in nsSocketTransport::ReleaseFD_Locked (this=0xbb300f0,
    fd=0xb277248) at nsSocketTransport2.cpp:1388
#13 0xb5cfec34 in nsSocketTransport::OnSocketDetached (this=0xbb300f0,
    fd=0xb277248) at nsSocketTransport2.cpp:1611
#14 0xb5d031bc in nsSocketTransportService::DetachSocket (this=0x85443f8,
    sock=0x8544710) at nsSocketTransportService2.cpp:185
#15 0xb5d03730 in nsSocketTransportService::DoPollIteration (this=0x85443f8,
    wait=0) at nsSocketTransportService2.cpp:650
#16 0xb5d038ae in nsSocketTransportService::OnProcessNextEvent (
    this=0x85443f8, thread=0x85550e0, mayWait=0, depth=1)
    at nsSocketTransportService2.cpp:535
#17 0xb7ac43d4 in nsThread::ProcessNextEvent (this=0x85550e0, mayWait=0,
    result=0xb3b23258) at nsThread.cpp:508
#18 0xb7a6d877 in NS_ProcessPendingEvents_P (thread=0x85550e0,
    timeout=4294967295) at nsThreadUtils.cpp:180
#19 0xb5d03359 in nsSocketTransportService::Run (this=0x85443f8)
    at nsSocketTransportService2.cpp:571
#20 0xb7ac4471 in nsThread::ProcessNextEvent (this=0x85550e0, mayWait=1,
    result=0xb3b23330) at nsThread.cpp:527
#21 0xb7a6d7a2 in NS_ProcessNextEvent_P (thread=0xb3b22e10, mayWait=1)
    at nsThreadUtils.cpp:230
#22 0xb7ac4d19 in nsThread::ThreadFunc (arg=0x85550e0) at nsThread.cpp:253
#23 0xb7a256fc in _pt_root (arg=0x8554c48) at ptthread.c:228
#24 0xb8089315 in start_thread () from /lib/i686/libpthread.so.0
#25 0xb6eeb25e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

This is not an NSS problem, by definition, because NSS does not directly
use any sockets.  NSPR manages the sockets.  So, initially, I will make 
this an NSPR bug.    

But NSPR sets a process wide signal action during initialization to ignore
all SIGPIPEs.  See
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/nsprpub/pr/src/md/unix/unix.c&rev=3.57&mark=2870#2870

So, if you're seeing SIGPIPE crashes, I gather that some other code, somewhere else in your process, must be setting some different signal action for that 
signal, and is not handling it correctly.  Consequently, I think this is 
really a bug elsewhere than in NSPR.  But it is definitely not an NSS bug,
by definition.

The next step is for you, the bug reporter, to see if you can reproduce this 
in a "clean" profile without any plugins or extensions.  If not, then this 
problem is caused by a plugin or extension, and the next step is for you 
to identify which one by taking them out one by one and re-testing until 
the behavior changes.

Comment 2

[Wan-Teh Chang]

Matthew, thanks for the bug report.  If you get what looks
like a SIGPIPE crash only when running inside gdb, please
follow the instructions in these web pages to tell gdb to
not stop and not print when it receives the SIGPIPE signal:
http://betterexplained.com/articles/debugging-with-gdb/
http://developer.apple.com/mac/library/documentation/DeveloperTools/gdb/gdb/gdb_6.html

It is normal for a network application to receive the
SIGPIPE signal.

If you get an actual SIGPIPE crash when running without gdb
attached, I'll reopen this bug.