584162 - Running SSL WebSocket test crashes Firefox on debug Windows only

Status: NEW

(Core :: General, defect)

Description

[Jonathan Griffin (:jgriffin)]

When you apply the patch https://bug573803.bugzilla.mozilla.org/attachment.cgi?id=462476 from bug 573803, which enables SSL WebSocket tests in mochitest, and run the test content/base/test/test_websocket_ssl_hello.html, Firefox will assert and terminate, but only if you're running a debug Windows build with --enable-libxul (the same config used by tinderbox).  This problem isn't seen on Mac or Linux, nor on Windows opt builds, nor on Windows debug builds without --enable-libxul.

The stack trace of the assert is:

KernelBase.dll!76fd22a1() 	
[Frames below may be incorrect and/or missing, no symbols loaded for KernelBase.dll]	
nspr4.dll!PR_Assert(const char * s=0x681f1c8c, const char * file=0x681f1cb0, int ln=322)  Line 563	C
nspr4.dll!_PR_MD_PR_POLL(PRPollDesc * pds=0x09bb7980, int npds=2, unsigned int timeout=65535000)  Line 322 + 0x1c bytes	C
nspr4.dll!PR_Poll(PRPollDesc * pds=0x09bb7980, int npds=2, unsigned int timeout=65535000)  Line 173 + 0x11 bytes	C
xul.dll!nsSocketTransportService::Poll(int wait=1, unsigned int * interval=0x0a01fc88)  Line 357 + 0x12 bytes	C++
xul.dll!nsSocketTransportService::DoPollIteration(int wait=1)  Line 668 + 0x10 bytes	C++
xul.dll!nsSocketTransportService::OnProcessNextEvent(nsIThreadInternal * thread=0x09c41058, int mayWait=1, unsigned int depth=1)  Line 547 + 0xd bytes	C++
xul.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0a01fd0c)  Line 519	C++
xul.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x09c41058, int mayWait=1)  Line 250 + 0x16 bytes	C++
xul.dll!nsSocketTransportService::Run()  Line 589 + 0xb bytes	C++
xul.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0a01fdac)  Line 547 + 0x19 bytes	C++
xul.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x09c41058, int mayWait=1)  Line 250 + 0x16 bytes	C++
xul.dll!nsThread::ThreadFunc(void * arg=0x09c41058)  Line 263 + 0xb bytes	C++
nspr4.dll!_PR_NativeRunThread(void * arg=0x00a46c28)  Line 426 + 0xf bytes	C
nspr4.dll!pr_root(void * arg=0x00a46c28)  Line 122 + 0xf bytes	C
msvcr80d.dll!_callthreadstartex()  Line 348 + 0xf bytes	C
msvcr80d.dll!_threadstartex(void * ptd=0x09bc8c38)  Line 331	C
kernel32.dll!76af3677() 	
ntdll.dll!77cf9d42() 	
ntdll.dll!77cf9d15() 	

The mozconfig I used to reproduce this is:

ac_add_options --enable-application=browser
ac_add_options --enable-jemalloc
ac_add_options --disable-optimize
ac_add_options --enable-debug
ac_add_options --enable-libxul
ac_add_options --enable-trace-malloc
ac_add_options --enable-tests

# For NSS symbols
export MOZ_DEBUG_SYMBOLS=1

# Needed to enable breakpad in application.ini
export MOZILLA_OFFICIAL=1

The assert seems to happen as soon as the WebSocket server returns HTTP 200 to the original HTTP CONNECT request:

CONNECT example.com:443 HTTP/1.1
Host: example.com:443

HTTP/1.1 200 Connected
Connection: keep-alive

The problem is not 100% reproducible on my machine, it seems to happen around 50% of the time.