471424 - crash in ssl_FreeSocket() in Firefox 3.0.5 after upgrade to NSS 3.12.2?

Status: RESOLVED INCOMPLETE

(Firefox :: Security, defect)

Description

[Seth Spitzer]

crash in ssl_FreeSocket() in Firefox 3.0.5 after upgrade to NSS 3.12.2?

david:  you might start seeing these with tbird 2.0.0.20 with imap over ssl, if 2.0.0.20 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

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 3

[bugzillaw54]

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()

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

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. :(

Comment 5

[Samuel Sidler (old account; do not CC)]

(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 [e-mail] is. :)

Comment 6

[Jesse Ruderman on Windows]

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.