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
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.
Assignee: nobody → wtc
Component: Libraries → NSPR
Product: NSS → NSPR
QA Contact: libraries → nspr
Version: trunk → 4.8
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.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.