Closed Bug 471424 Opened 11 years ago Closed 10 years ago
crash in ssl
_Free Socket() in Firefox 3 .0 .5 after upgrade to NSS 3 .12 .2?
crash in ssl_FreeSocket() in Firefox 3.0.5 after upgrade to NSS 3.12.2? david: you might start seeing these with tbird 220.127.116.11 with imap over ssl, if 18.104.22.168 also uses NSS 3.12.2 I did a search, and found two reports for 3.0.5 with ssl_FreeSocket: http://crash-stats.mozilla.com/report/index/4b93eaa0-38a7-42cf-b56e-cfbe12081223 http://crash-stats.mozilla.com/report/index/39a15cad-614c-4918-a059-576752081222 the stacks were both: 0 ssl3.dll ssl_FreeSocket mozilla/security/nss/lib/ssl/sslsock.c:451 1 ssl3.dll ssl_DefClose mozilla/security/nss/lib/ssl/ssldef.c:233 2 nspr4.dll PR_DestroyLock 3 xul.dll nsSSLIOLayerClose mozilla/security/manager/ssl/src/nsNSSIOLayer.cpp:1477 4 xul.dll nsSocketTransport::OnSocketDetached mozilla/netwerk/base/src/nsSocketTransport2.cpp:1590 5 xul.dll nsSocketTransportService::DetachSocket mozilla/netwerk/base/src/nsSocketTransportService2.cpp:179 6 xul.dll nsSocketTransportService::DoPollIteration mozilla/netwerk/base/src/nsSocketTransportService2.cpp:634 7 xul.dll XPCPerThreadData::GetDataImpl mozilla/js/src/xpconnect/src/xpcthreadcontext.cpp:601 8 xul.dll nsThread::ProcessNextEvent mozilla/xpcom/threads/nsThread.cpp:497 9 nspr4.dll PR_CallOnceWithArg
Unfortunately, that stack trace is bogus. I examined to source, to see if I could put together a stack that led from nsSocketTransport::OnSocketDetached down to ssl_FreeSocket, and I put together the following stack, which is quite different than the one given above: 0 ssl3.dll ssl_FreeSocket 1 ssl3.dll ssl_DefClose ssl_SecureClose ssl_Close nsNSSSocketInfo::CloseSocketAndDestroy nsSSLThread::requestClose 3 xul.dll nsSSLIOLayerClose PR_Close nsSocketTransport::ReleaseFD_Locked 4 xul.dll nsSocketTransport::OnSocketDetached That stack is sufficiently different than the one in comment 0 that I'm not at all confident that it is really the true stack. I have some more comments about that stack which I'll add in a subsequent bug comment.
Two more comments: 1. We made very few changes to libSSL between NSS 3.12.0 and 3.12.2 RC1. None of the changes seems relevant to this issue. There have been no changes to sslsock.c or ssldef.c (the two lib/ssl files cited in comment 0). There was a change to ssl_SecureClose in sslsecur.c, but it was cosmetic. 2. It's been years since I last saw a crash in ssl_FreeSocket. We used to see them from time to time. The cause was ALWAYS that some code closed an SSL socket twice. So, I'd guess that something has changed, since NSS 3.12.0, that is causing this crash, but IMO it's probably NOT in lib/SSL.
thanks for eyeballing this one, Nelson. my search on http://crash-stats.mozilla.com was only two weeks back. sam: is there a way to search back further than a couple weeks on http://crash-stats.mozilla.com? It might be that this isn't a new crash, but my search only found 3.0.5. For the record, another stack (not from Firefox 3.0.5) that might provide some clues (notice the bogus address of the sslSocketStr * ss param, 0x00000003) ntdll.dll!7c90e4f4() [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] ntdll.dll!7c90df3c() mswsock.dll!71a5402b() mswsock.dll!71a55f9f() mswsock.dll!71a55f9f() mswsock.dll!71a55f9f() mswsock.dll!71a55f9f() mswsock.dll!71a55f9f() msvcr90d.dll!102bd8f5() msvcr90d.dll!102d1ac9() msvcr90d.dll!102d09ef() msvcr90d.dll!102d8990() nspr4.dll!PR_Free(void * ptr=0x1681a2f0) Line 536 + 0xa bytes C nssutil3.dll!PORT_Free_Util(void * ptr=0x064ed702) Line 152 + 0xa bytes C > ssl3.dll!ssl_FreeSocket(sslSocketStr * ss=0x00000003) Line 478 + 0x9 bytes C xpcom_core.dll!nsAutoLockBase::nsAutoLockBase(void * addr=0x002d492e, nsAutoLockBase::nsAutoLockType type=eAutoLock) Line 325 + 0x13 bytes C++ 01e6fd60() necko.dll!nsSocketTransportService::OnProcessNextEvent(nsIThreadInternal * thread=0x00ea5a98, int mayWait=1, unsigned int depth=1) Line 523 + 0xd bytes C++ xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x01e6fe70) Line 500 C++ xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00ea5a98, int mayWait=1) Line 227 + 0x16 bytes C++ necko.dll!nsSocketTransportService::Run() Line 565 + 0xc bytes C++ xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x01e6ff08) Line 511 C++ xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00ea5a98, int mayWait=1) Line 227 + 0x16 bytes C++ xpcom_core.dll!nsThread::ThreadFunc(void * arg=0x00ea5a98) Line 254 + 0xb bytes C++ nspr4.dll!_PR_NativeRunThread(void * arg=0x00e412d8) Line 436 + 0xf bytes C nspr4.dll!pr_root(void * arg=0x00e412d8) Line 122 + 0xf bytes C msvcr90d.dll!1023dfd3() msvcr90d.dll!1023df69() kernel32.dll!7c80b713() mswsock.dll!71a55f9f()
So, ssl_FreeSOcket frees massive numbers of allocated memory blocks. If there's been any heap corruption by any software anywhere in the process under test, it is very likely to manifest itself as a problem when ssl_FreeSocket starts freeing all those data structures. This does not necessarily indicate a flaw in ssl_FreeSocket, or indeed in any lib/ssl code. :(
(In reply to comment #3) > sam: is there a way to search back further than a couple weeks on > http://crash-stats.mozilla.com? Not really at present, no. There are issues with searching back further than a couple of weeks because the db isn't optimized for those types of searches (but it's being worked on!). /me idly wonders who email@example.com is. :)
Since Nelson couldn't figure this out, and memory corruption seems like a plausible explanation for such a low-frequency crash, I'm marking this bug report as incomplete.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.