Closed Bug 423257 Opened 18 years ago Closed 17 years ago

Browser crashes after periods of inactivity, with multiple tabs open

Categories

(Core Graveyard :: Plug-ins, defect)

1.9.0 Branch
x86
Windows Vista
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: peterjsimpson, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4 Left computer inactive for a period of 1-2 hours with a few non-refreshing tabs open of an online store (Techbuy.com.au), Vista had long since turned off the monitor but it was definately not in a state of hibernation or sleep mode. Upon returning to the computer, found Firefox had crashed. Reproducible: Didn't try Steps to Reproduce: 1. Open 5+ tabs 2. Wait Aero theme active Problem signature: Problem Event Name: APPCRASH Application Name: firefox.exe Application Version: 1.9.0.2988 Application Timestamp: 47d1d2c5 Fault Module Name: StackHash_a950 Fault Module Version: 0.0.0.0 Fault Module Timestamp: 00000000 Exception Code: c0000005 Exception Offset: 4d58ca02 OS Version: 6.0.6000.2.0.0.256.1 Locale ID: 3081 Additional Information 1: a950 Additional Information 2: c07297ba8acc6462e9fe86ee369f49b9 Additional Information 3: 9501 Additional Information 4: f069aaa3136bbfb1e2039a6dd3b7c8c8 about:buildconfig Build platform target i686-pc-mingw32 Build tools Compiler Version Compiler flags cl 14.00.50727 -GL -wd4624 -wd4952 -TC -nologo -W3 -Gy -Fd$(PDBFILE) cl 14.00.50727 -GR- -GL -wd4624 -wd4952 -TP -nologo -Zc:wchar_t- -W3 -Gy -Fd$(PDBFILE) Configure arguments --enable-application=browser --enable-update-channel=beta --enable-optimize --disable-debug --disable-tests --enable-update-packaging --enable-official-branding --enable-jemalloc
Please provide the crash id from about:crashes
about:crashes says no crash reports have been submitted. I'm not sure if that's just from the way Vista handles them or because I didn't do a custom install or what. Is there anything else that I can provide?
>Fault Module Name: StackHash_a950 I don't know what module that is, it's no Firefox module. Is that DEP ?
i'd guess stackhash is a magic cookie from the compiler, there are lots of hits for it but i can't find any explanations. please try following the steps in: http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg
I am also experiencing this bug. The Firefox bug reporting mechanism does *not* get executed. There is only the Windows message "Firefox has stopped working". Firefox 3.0 Vista 64-bit Ultimate SP1 Windows Application Crash Info: Problem signature: Problem Event Name: APPCRASH Application Name: firefox.exe Application Version: 1.9.0.3071 Application Timestamp: 483ebafb Fault Module Name: xul.dll Fault Module Version: 1.9.0.3071 Fault Module Timestamp: 483ebb91 Exception Code: c0000005 Exception Offset: 000bf6e0 OS Version: 6.0.6001.2.1.0.256.1 Locale ID: 1033 Additional Information 1: fd00 Additional Information 2: ea6f5fe8924aaa756324d57f87834160 Additional Information 3: fd00 Additional Information 4: ea6f5fe8924aaa756324d57f87834160
Brad:No, you don't experience THIS bug. Did you compare the windows crash log (which itself doesn't help to fix this bug) ? File a new bug report, with a comment that you also crash in the safemode and attach a stacktrace generated with the instructions from comment #4 or replace Flash9 with Flash10beta (which doesn't break our crash reporter) marking incomplete because we need a stacktrace.
Hi Mattias, Thanks for your suggestions. Just FYI, I followed your instructions, and still am not having any luck. I installed the Flash 10 beta 2, and also am now running FF in safe mode all the time. However, I just got an even worse crash: FF.exe stopped working, no crash reporter appeared, and the application lock-up was so severe that I could only close it down by killing the actual process. I'll try the WinDbg method from comment #4 next.. ~brad
Hi Mattias, I have FF running now under WinDbg, but unfortunately the program symbols aren't being found :( I don't understand why not, b/c the symbol path seems to be ok, and I can see the firefox.pdb in the symbols folder. I'm running the public release FF 3.0 Here are the first few lines of the WinDbg session: >> CommandLine: "C:\Program Files (x86)\Mozilla Firefox\firefox.exe" -safe-mode Starting directory: C:\Program Files (x86)\Mozilla Firefox Symbol search path is: SRV*c:\symbols*http://symbols.mozilla.org/firefox;SRV*c:\symbols*http://msdl.microsoft.com/download/symbols << Here is the crash info: >> (ccc.1574): Guard page violation - code 80000001 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\SysWOW64\Macromed\Flash\NPSWF32.dll - NPSWF32!native_ShockwaveFlash_TCallLabel+0xb0653: 00000000`6b87298a 881e mov byte ptr [esi],bl ds:002b:00000000`10110000=00 0:000:x86> kb ChildEBP RetAddr Args to Child WARNING: Stack unwind information not available. Following frames may be wrong. 004be598 6b872c1d 00000010 00000003 004be7f8 NPSWF32!native_ShockwaveFlash_TCallLabel+0xb0653 00000000 00000000 00000000 00000000 00000000 NPSWF32!native_ShockwaveFlash_TCallLabel+0xb08e6 << Any suggestions appreciated, Thanks, Brad
You are crashing because of the flash plugin... I would ask Adobe :-)
Hi Matthias, Yes, thank you, I see that it's the Flash plug-in.. ;) However, I don't think Adobe will be able to help me with WinDbg not being able to find the FF symbols. And if I'm not mistaken, it's FF who calla Flash, not the other way around. So I believe you guys still need to trace out where that call is being made, right? Brad
It seems it found the symbols, the error about the missing symbols is coming from the flash plugin and we have of course no symbols for the plugin. We can not know why it's crashing, only Adobe can debug that.
Hi Mattias, Sorry if I'm a little slow in understanding this.. When FF stops responding, even if it's due to a problem in the Flash plug-in, I should be able to "break" in the debugger and see what's going on, right? After all, FF is the parent process. But when I break, and then I try to get a stack trace, the symbols are still not found. So if as you're saying, all the FF symbols are fine, why wouldn't we see at least a partial stack trace? Shouldn't we see the trace starting at the top with Windows and going down through FF code to the code that goes out to Flash? After that level, I agree, since we don't have the Flash symbols, there's no further info. But it looks here like we're only seeing the DLL entry point into Flash, right...? Brad
Did it stop responding (hang/freeze) or did it crash ? You get symbol loading errors from Windbg if it's missing the symbols from a dll and I can see only an error about the flash plugin in your example. If the symbols are missing then Windbg shows it without symbols (see your flash example). You can not see the whole application startup to that point because Firefox is multithreaded and the plugin runs in it's own threat. If you got a hang and you break into the debugger you will only see the stack trace from the current (?)thread. Use "!analyze -v -hang" in that case. but marking incomplete because you should not morph this bug into your bug and you don't have the same problem as the reporter of this bug.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INCOMPLETE
brad: if adobe needed information, they could ask you for a .dmp, and then they could debug from there.
Component: General → Plug-ins
Product: Firefox → Core
Version: unspecified → 1.9.0 Branch
Are the bug repro steps still as described in comment #0, or what are they? Please provide specific URLs. Thank you!
Hi Mattias, Thanks for your comments in #13. Point well taken -- if you feel this bug doesn't describe my problem, I promise not to morph this thread into my own story! ;) Please take a look at the new bug report I created, #444261 thanks, brad
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.