Firefox 24 crashes even after resetting it and no hardware acceleration
The latest version of Firefox is often crashing for our internal application. I reset Firefox to its factory settings and disabled hardware acceleration. I still find it is crashing.
Here are some of the crash reports:
1. bp-feda8b38-ca1a-481a-b304-e614d2130929 - This one is without hardware acceleration and after resetting Firefox
2. bp-65384ee3-9ace-441a-a325-977472130928
3. bp-ebb16c9b-d419-466e-b0b8-3d4462130927
4. bp-f0252801-3f27-4517-852a-8ceee2130927
5. bp-7227f930-af84-4c0c-8e60-057ef2130927
When viewing some of the reports, particularly the first one, it says that the report can't be located. This is making it more difficult to find the cause of the issue.
Why it is unable to locate the report?
由cor-el于
被采纳的解决方案
Finally we found that it was the memory leak in our internal web application which was causing the crash.
Thanks everyone for your help.
定位到答案原位置 👍 0所有回复 (19)
Hello kumar.ganesha, try to boot the computer in Windows Safe mode with network support (press F8 on the boot screen) and check firefox again.
thank you
Can you tell me how running Windows in safe mode help Firefox?
I did not observe this crash before the version 21. Once the version 21 was installed, it started crashing. This crashing is continuing in every new release of Firefox.
If works in Windows Safe mode maybe exist an issue with other software, like security software or maybe a system driver, that is running on your computer.
Did you try it ?
thank you
Unfortunately, the crash reports you furnished are either empty or unavailable. Note: There's a discussion about problems fetching crash reports in the contributors forum: /forums/contributors/709646
If Firefox runs without crashing in in Windows Safe Mode then it's likely a program or a driver that only runs in Windows normal mode is causing the crashes. (Malware that runs in Windows normal mode can cause Firefox crashes - see Troubleshoot Firefox issues caused by malware.)
For other troubleshooting suggestions see:
Thanks for your suggestion. I will try running Windows in Safe mode later.
I believe if I am able to generate the crash report, it will provide some clue. Looks like the the related bug is not fixed yet.
I got one crash id which has proper stacktrace
bp-1a944c92-9c96-4146-8275-e624e2131001
The crash signature for that report is
Firefox 24.0esr Crash Report [@ hang | ntdll.dll@0x2015d ]
That crash appears to be Flash-related since it shows:
Process type | plugin Shockwave Flash Version:11.8.800.168 Filename:NPSWF32_11_8_800_168.dll
You already have the latest Flash version 11.8.800.168 installed so try the troubleshooting suggestions here:
- Flash Plugin - Keep it up to date and troubleshoot problems
- http://kb.mozillazine.org/Flash#Troubleshooting
I would start by disabling hardware acceleration in Flash settings:
- Go to http://helpx.adobe.com/flash-player/kb/video-playback-issues.html#main_Solve_video_playback_issues
- Right-click on the Flash logo and click Settings… in the context menu. The Adobe Flash Player Settings screen will open.
- Click on the icon at the bottom-left of the Adobe Flash Player Settings window to open the Display panel.
- Remove the check mark from Enable hardware acceleration.
The image "fpSettings1.PNG" does not exist.
- Click {button Close} to close the Adobe Flash Player Settings Window.
- Restart Firefox.
P.S. Turning off hardware accleleration in Flash settings is only a temporary solution, if it stops the crashes, as explained here. See http://helpx.adobe.com/flash-player/kb/video-playback-issues.html#main_Solve_video_playback_issues for other suggestions.
I am yet to check with disabling Flash hardware acceleration.
I used WinDbg to get the stacktrace as the crash reporter of Firefox produces stacktrace with empty thread information.
I find that Firefox crashes with 'javascript: out of memory' error.
Here is the exception analysis:
FAULTING_IP: mozalloc!mozalloc_abort+2d [e:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\memory\mozalloc\mozalloc_abort.cpp @ 30] 715f119f c705000000007b000000 mov dword ptr ds:[0],7Bh EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff) .exr 0xffffffffffffffff ExceptionAddress: 00000000715f119f (mozalloc!mozalloc_abort+0x000000000000002d) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 0000000000000001 Parameter[1]: 0000000000000000 Attempt to write to address 0000000000000000 FAULTING_THREAD: 0000000000001194 PROCESS_NAME: firefox.exe ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_PARAMETER1: 0000000000000001 EXCEPTION_PARAMETER2: 0000000000000000 WRITE_ADDRESS: 0000000000000000 FOLLOWUP_IP: mozalloc!mozalloc_abort+2d [e:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\memory\mozalloc\mozalloc_abort.cpp @ 30] 715f119f c705000000007b000000 mov dword ptr ds:[0],7Bh APPLICATION_VERIFIER_FLAGS: 0
由cor-el于
based on what I could find with a search, my guess would be Bug 901346 - crash in mozalloc_abort(char const* const) | js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct)
. ... which was marked as a duplicate of
- Bug 767343 - crash in nsSupportsStringImpl::SetData with abort message: "###!!! ABORT: OOM: file e:\builds\moz2_slave\m-cen-w32-ntly\build\xpcom\string\src\nsTSubstring.cpp, line 348"
Hopefully someone better skilled in crash analysis will be along soon.
P.S. In the meantime, try running in Windows Safe Mode to see if the crashes stop, or try disabling Flash HW acceleration to see if it helps.
由AliceWyman于
Can any crash analysis export confirm that this is same as the one reported in Bug 901346 ?
由kumar.ganesha于
It could also be Bug 857054 - crash for unknown reason due to out of memory (OOM), hard to say.
If you have any new crash report IDs in about:crashes could you list them here?
You also mentioned a Firefox Reset didn't help and neither did disabling hardware acceleration in Firefox. To cover all bases, did you actually try to run in Firefox Safe Mode? See http://kb.mozillazine.org/Safe_Mode for details.
I did not run in Safe mode. But doesn't resetting Firefox have the same impact as running in Safe mode?
Also, running with Flash hardware acceleration disabled did not help.
The default crash reporter shows crash reports with Empty thread info most of the times. So I am running Firefox with WinDbg. The latest report with WinDbg shows a little different stacktrace:-
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 7200ec00 ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000008 Parameter[1]: 7200ec00 Attempt to execute non-executable address 7200ec00 FAULTING_THREAD: 00001ea8 PROCESS_NAME: firefox.exe ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_PARAMETER1: 00000008 EXCEPTION_PARAMETER2: 7200ec00 WRITE_ADDRESS: 7200ec00 FOLLOWUP_IP: mozjs!JSObject::nonNativeSetProperty+31 [e:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\js\src\jsobj.cpp @ 1664] 57d17e21 83c414 add esp,14h FAILED_INSTRUCTION_ADDRESS: +18 7200ec00 ?? ??? NTGLOBALFLAG: 70 APPLICATION_VERIFIER_FLAGS: 0 APP: firefox.exe IP_ON_HEAP: 7200ec00 The fault address in not in any loaded module, please check your build's rebase log at <releasedir>\bin\build_logs\timebuild\ntrebase.log for module which may contain the address if it were loaded. IP_IN_FREE_BLOCK: 7200ec00 BUGCHECK_STR: APPLICATION_FAULT_SOFTWARE_NX_FAULT_INVALID PRIMARY_PROBLEM_CLASS: SOFTWARE_NX_FAULT_INVALID DEFAULT_BUCKET_ID: SOFTWARE_NX_FAULT_INVALID LAST_CONTROL_TRANSFER: from 57d17e21 to 7200ec00 STACK_TEXT: WARNING: Frame IP not in any known module. Following frames may be wrong. 0026e594 57d17e21 09160690 0026e5d8 0026e5dc 0x7200ec00 0026e5b0 57d7c44a 0026e5d8 0026e5dc 0026e5e0 mozjs!JSObject::nonNativeSetProperty+0x31 0026e5e8 57d8f466 09160690 0026e638 06003058 mozjs!SetPropertyOperation+0xea 0026ed40 57d965ed 0026ef10 09160690 0026efd0 mozjs!Interpret+0x1b16 0026ee98 57da84fd 09160690 0026efd0 0026eed0 mozjs!js::Invoke+0x2bd 0026eedc 57dbc827 09160690 0026ef00 0026ef10 mozjs!js::CrossCompartmentWrapper::call+0xfd 0026ef1c 57d967c3 09160690 00000000 0026efc8 mozjs!proxy_Call+0x77 0026f080 57d61621 09160690 0026f0a8 0026f0c4 mozjs!js::Invoke+0x493 0026f0b4 506dd22e 09160690 6e4b5d90 e2787c40 mozjs!JS_CallFunctionValue+0x41 0026f180 508460ac 7abffd20 09160690 0026f1b4 xul!mozilla::dom::Function::Call+0xbe 0026f22c 508284a8 7abffd20 0026f270 0026f278 xul!mozilla::dom::Function::Call<nsCOMPtr<nsISupports> >+0x8c 0026f2f4 507f8fae 0916ad00 50844de0 19792280 xul!nsGlobalWindow::RunTimeoutHandler+0x108 0026f368 50844e11 0f91cc00 19792280 50844de0 xul!nsGlobalWindow::RunTimeout+0x2de 0026f380 507bc27a fbdff0c0 19792280 00000001 xul!nsGlobalWindow::TimerCallback+0x31 0026f41c 507a7bbf 00a0e980 0026f4cc 00a310e0 xul!nsTimerImpl::Fire+0xea 0026f48c 507c2f0e 00a17301 00000000 0026f4a8 xul!nsThread::ProcessNextEvent+0x38f 0026f4a0 50bd491b 00a17301 00000000 00a310e0 xul!NS_ProcessNextEvent+0x2e 0026f4cc 50c6319c 01a310e0 98cb0453 00a17340 xul!mozilla::ipc::MessagePump::Run+0x46 0026f504 50c63255 00a17400 00000001 0026f600 xul!MessageLoop::RunHandler+0x51 0026f524 505c4f8e 80000000 05964a40 5086b818 xul!MessageLoop::Run+0x19 0026f530 5086b818 00a17400 50b09cfa 00a17400 xul!nsBaseAppShell::Run+0x2c 0026f544 5061f7a0 05964a40 0026f65c 715f1087 xul!nsAppShell::Run+0x14 0026f61c 505da49c 0026f65c 0026f784 0026f65c xul!XREMain::XRE_mainRun+0x3a8 0026f63c 5085ec44 0026f65c 00000001 007172d8 xul!XREMain::XRE_main+0xe1 0026f754 012e16b9 00000001 007172d8 0026f784 xul!XRE_main+0x30 0026f8e8 012e197e 00000001 007172d8 00a170a0 firefox!do_main+0x283 0026f97c 012e1a89 00000001 007172d8 00000000 firefox!NS_internal_main+0x11d 0026f9b0 012e2357 00000000 00711ba0 00711c28 firefox!wmain+0xf0 0026f9f4 76a7336a fffde000 0026fa40 77669f72 firefox!__tmainCRTStartup+0x122 0026fa00 77669f72 fffde000 5c9a6cb0 00000000 kernel32!BaseThreadInitThunk+0xe 0026fa40 77669f45 012e2478 fffde000 00000000 ntdll!__RtlUserThreadStart+0x70 0026fa58 00000000 012e2478 fffde000 00000000 ntdll!_RtlUserThreadStart+0x1b FAULTING_SOURCE_LINE: e:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\js\src\jsobj.cpp FAULTING_SOURCE_FILE: e:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\js\src\jsobj.cpp FAULTING_SOURCE_LINE_NUMBER: 1664 FAULTING_SOURCE_CODE: No source found for 'e:\builds\moz2_slave\rel-m-rel-w32_bld-000000000000\build\js\src\jsobj.cpp' SYMBOL_STACK_INDEX: 1 SYMBOL_NAME: mozjs!JSObject::nonNativeSetProperty+31 FOLLOWUP_NAME: MachineOwner MODULE_NAME: mozjs IMAGE_NAME: mozjs.dll DEBUG_FLR_IMAGE_TIMESTAMP: 522fbca3 STACK_COMMAND: ~0s ; kb FAILURE_BUCKET_ID: SOFTWARE_NX_FAULT_INVALID_c0000005_mozjs.dll!JSObject::nonNativeSetProperty BUCKET_ID: APPLICATION_FAULT_SOFTWARE_NX_FAULT_INVALID_BAD_IP_mozjs!JSObject::nonNativeSetProperty+31
由cor-el于
You asked, doesn't resetting Firefox have the same impact as running in Safe mode?
Firefox Safe Mode temporarily disables all extensions while you are running in that mode, while a Firefox Reset removes extensions installed in the Firefox profile folder but not any globally-installed extensions may still be installed (you should be asked to enable them). Checking in "More System Details" it shows you only have one extension installed but it's disabled, so that shouldn't be an issue:
Name: IDS_SS_NAME Version: IDS_SS_VERSION Enabled: false ID: {D19CA586-DD6C-4a0a-96F8-14644F340D60}
Searching on that extension ID it looks to be a Firefox add-on installed by McAfee VirusScan (McAfee Script Scan?)
Firefox Safe Mode also temporarily disables the JavaScript Just-in-time (JIT) compiler, a detail that's mentioned in the mozillazine article I referenced before.
I see you added a comment in the possibly related bug 767343 so hopefully you'll get a response there.
I would still try running in Windows Safe Mode. It's possible that a program (or multiple programs) running in normal mode is causing the out-of-memory crashes in Firefox.
由AliceWyman于
In Firefox Safe mode these changes are effective:
- all extensions are disabled
- default theme is used (no persona)
- userChrome.css and userContent.css are ignored
- default toolbar layout is used (localstore-safe.rdf)
- Javascript JIT compilers are disabled (javascript.options.*jit)
- hardware acceleration is disabled
- plugins are not affected
- preferences are not affected
选择的解决方案
Finally we found that it was the memory leak in our internal web application which was causing the crash.
Thanks everyone for your help.
Hey, good to hear it. I'll mark your last post as the solution.
Thanks for posting back with the outcome.
You aren't telling me what to do to fix it, nor is it fix where it doesn't keep happening. Please let me know where to go so I can fix this myself or if you are going to fix this for us.
Thank You Gale M
The Firefox crashing with one of applications of our company. It was a bug of the application rather than Firefox.