Firefox Nightly 32-bit crashes on startup on Windows XP 64




4 years ago
4 years ago


(Reporter: sydpolk, Assigned: luke)



36 Branch
Windows XP

Firefox Tracking Flags

(Not tracked)


(crash signature)


(1 attachment)



4 years ago
Running Firefox Nightly on our Windows XP 64-bit VM (fully updated), it crashes. Here is the Crash Report details. Note that this is on first launch creating a new profile.

AdapterDeviceID: 0x0000
AdapterSubsysID: 00000000
AdapterVendorID: 0x0000
Add-ons: %7B972ce4c6-7e08-4474-a285-3208198ce6fd%7D:36.0a1
AvailablePageFile: 3707445248
AvailablePhysicalMemory: 1570312192
AvailableVirtualMemory: 3941904384
BIOS_Manufacturer: Phoenix Technologies LTD
BreakpadReserveAddress: 80674816
BreakpadReserveSize: 41943040
BuildID: 20141114030206
CrashTime: 1415996959
EMCheckCompatibility: true
FramePoisonBase: 00000000f0de0000
FramePoisonSize: 65536
InstallTime: 1415978658
Notes: AdapterVendorID: 0x0000, AdapterDeviceID: 0x0000, AdapterSubsysID: 00000000, AdapterDriverVersion: 
D3D11 Layers? D3D11 Layers- D3D9 Layers? D3D9 Layers- 
ProductID: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
ProductName: Firefox
ReleaseChannel: nightly
SecondsSinceLastCrash: 29
StartupTime: 1415996952
SystemMemoryUsePercentage: 26
Theme: classic/1.0
Throttleable: 1
TotalPageFile: 4156772352
TotalPhysicalMemory: 2146787328
TotalVirtualMemory: 4294836224
Vendor: Mozilla
Version: 36.0a1
Winsock_LSP: MSAFD Tcpip [TCP/IP] : 2 : 1 :  
 MSAFD Tcpip [UDP/IP] : 2 : 2 : %SystemRoot%\system32\mswsock.dll 
 MSAFD Tcpip [RAW/IP] : 2 : 3 :  
 RSVP UDP Service Provider : 6 : 2 : %SystemRoot%\system32\mswsock.dll 
 RSVP TCP Service Provider : 6 : 1 :  
 VMCI sockets DGRAM : 0 : 2 : %windir%\system32\vsocklib.dll 
 VMCI sockets STREAM : 0 : 1 : 
useragent_locale: en-US

This report also contains technical information about the state of the application when it crashed.

Comment 1

4 years ago
Exposed by platform WebRTC testing.

Comment 2

4 years ago
The first build that shows this behavior is this:

The 11/13 build launches fine.


4 years ago
Crash Signature: [@ js::InterruptRunningJitCode(JSRuntime*) ]
Keywords: crash

Comment 4

4 years ago
Luke, this is crashing in your patch. Do you have any light to shed on this?

#if defined(XP_WIN)
// On Windows, we can simply suspend the main thread and work directly on
// its context from this thread.
    HANDLE thread = (HANDLE)rt->ownerThreadNative();
    if (SuspendThread(thread) == -1)
        MOZ_CRASH("Failed to suspend main thread");
Flags: needinfo?(luke)

Comment 5

4 years ago
Hmm, I wonder if this is a WOW64 problem, in which case we should call Wow64SuspendThread (  By any chance can you modify your build to print GetLastError() before crashing?

dmajor: do you have any experience with WOW64?  If that is indeed the problem, is this a thing we can #ifdef or is there a dynamic WOW64 query?
Flags: needinfo?(luke) → needinfo?(dmajor)

Comment 6

4 years ago
I am not running out of a source tree; I am downloading nightly builds. Not likely I'll be able to get a useable build for this change in a timely manner.

Comment 7

4 years ago
Do you have Visual Studio installed?  If so, you could attach and then execute GetLastError() in the debug immediate window.

Comment 8

4 years ago
This crashes when running tests via launching via firefox.exe command-line on Windows XP 64 and on Win 8.1 64. It crashes when I double-click on Firefox on XP, but on 8.1, that works.

Comment 9

4 years ago
I do NOT have VS on my Windows XP 64-bit VM. It was a pain to build, and I was hoping to keep it as close to an end-user system as possible.

Comment 10

4 years ago
You can RDC into if you are on VPN. User name mozilla, password mozilla. Feel free to install whatever you want.

Comment 11

4 years ago
I cloned the VM reproducing the problem.

Comment 12

4 years ago
This SO answer ( would suggest that WOW64 isn't relevant.  OTOH, re-reading msdn docs ( shows that SuspendThread can spuriously fail if the target thread is making a kernel call (good chance it is).

We can depend on InterruptRunningJitCode being called again in 1s, so the simple fix is to just 'return;' instead of crashing.

Comment 14

4 years ago
Cancelling need-info, but feel free to weigh in.
Flags: needinfo?(dmajor)
I'm having what appears to be the same crash.  I say that because the symptoms are the same and this bug number has been attached to the crash report, like for example.  I'm on 64-bit Vista, running 32-bit Firefox 36 nightlies.  If there's anything I can do (that doesn't take a whole day), feel free to needinfo me.
Assignee: nobody → luke
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 36
Oops, I'm late to the party, but I'm still curious why it originally failed. I'll take a look at that RDC tomorrow. (WinDbg can GetLastError with "!gle")

Comment 18

4 years ago
(In reply to David Major [:dmajor] (UTC+13) from comment #17)
I'd be happy to hear what you see.  The msdn documentation says the SuspendThread call can fail if the thread is in a kernel syscall,
So this int 3 is actually folded together with a bunch of others. Given the register state, it couldn't have been the SuspendThread call. A debug build says: Hit MOZ_CRASH(Failed to get suspended thread context)

I couldn't get !gle working on this ancient OS :) but I re-pushed the parameters and ran GetThreadContext again.

0:010> !error c0000022
Error code: (NTSTATUS) 0xc0000022 (3221225506) - {Access Denied}  A process has requested access to an object, but has not been granted those access rights.
Flags: needinfo?(luke)
"WOW64:  The handle must also have THREAD_QUERY_INFORMATION access."

JSRuntime::init says:

Comment 21

4 years ago
Wow, nice find!  I can't believe I didn't pick that up in my multiple passes of those docs.  Do you by chance know if THREAD_QUERY_INFORMATION will succeed by default on these systems?
Flags: needinfo?(luke)
I don't have any direct experience with it, but I would imagine that if you're allowed to SET_CONTEXT then you should be allowed to QUERY_INFORMATION.
Blocks: 1091912

Comment 23

4 years ago
Created attachment 8524173 [details] [diff] [review]
Attachment #8524173 - Flags: review?(dmajor)
Comment on attachment 8524173 [details] [diff] [review]

I or'ed 0x40 into the stack value on the XP64 VM, and it works!
Attachment #8524173 - Flags: review?(dmajor) → review+
Oh and DXR says the other occurrences of THREAD_GET_CONTEXT in the codebase are fine.

Comment 26

4 years ago
Thanks again for digging in further.
Component: General → JavaScript Engine
Product: Firefox → Core
Target Milestone: Firefox 36 → ---
You need to log in before you can comment on or make changes to this bug.