Closed Bug 580248 Opened 14 years ago Closed 14 years ago

xul.dll - immediate crash when surfing http://html5test.com/ with x64 compiled firefox 4.0/b2pre

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 578215

People

(Reporter: abittner, Unassigned)

References

(
URL
)

Details

Attachments

(1 file)

windbg crash-output from debugsession
54.88 KB, text/plain
Details
User-Agent: Mozilla/5.0 (Windows; Windows NT 6.1; Win64; x64; en-US; rv:2.0b2pre) Gecko/20100714 Minefield/4.0b2pre Build Identifier: Mozilla/5.0 (Windows; Windows NT 6.1; Win64; x64; en-US; rv:2.0b2pre) Gecko/20100714 Minefield/4.0b2pre crashes the whole app (windows error reporting crash, as no crashreproter/breakpad (yet?), where do i call for action for at least having breakpad/crashreporter activated for native x64, and who is in charge of getting involved with microsoft for making use of the wer (windows error reporting) statistical technical data, getting wer account and so on). no content gets displayed at all when navigating to the site, bug immediate whole app crash (firefox.exe, x64 native build). all the crashes occur in xul.dll at least to the locally stored and displayed wer data (win7 activity center). Reproducible: Always Actual Results: being able to surf to the http://html5test.com/ normally, and see html5 capability score being computed. see my comment no. 10 in other x64 bugreport: #576247#c10 https://bugzilla.mozilla.org/show_bug.cgi?id=576247#c10
Description Faulting Application Path: C:\Program Files (x86)\Minefield\firefox.exe Problem signature Problem Event Name: APPCRASH Application Name: firefox.exe Application Version: 2.0.0.3846 Application Timestamp: 4c3dca57 Fault Module Name: xul.dll Fault Module Version: 2.0.0.3846 Fault Module Timestamp: 4c3dc993 Exception Code: c0000005 Exception Offset: 0000000000276928 OS Version: 6.1.7601.2.1.0.256.1 Locale ID: 1033 Additional Information 1: 25c0 Additional Information 2: 25c09b994a48fea9e9d21b3b8db14eb6 Additional Information 3: 613f Additional Information 4: 613f902109b04e71c13aa2112ec8251b Extra information about the problem Bucket ID: 19070399 ----------- will try to get some more information with windbg https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg
Summary: immediate crash when surfing http://html5test.com/ with x64 compiled firefox 4.0/b2pre → xul.dll - immediate crash when surfing http://html5test.com/ with x64 compiled firefox 4.0/b2pre
Please update.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
how do you know its the same stuff without crashreporter information on the x64 platform? was about to submit the windbg info.
windbg crash-output from debugsession
Attachment #458673 - Attachment mime type: application/octet-stream → text/plain
roughly, the stack matches. fwiw, you didn't manage to set up symbols correctly and since you're using the 32bit version of firefox (not a 64bit version), you should use the 32bit version of windbg (please ignore all documentation to the contrary, I just haven't gotten around to fixing it).
(In reply to comment #3) > how do you know its the same stuff without crashreporter information on the x64 > platform? > > was about to submit the windbg info. Because I knew that your build would crash on loading html5test.com due to bug 578215. It would be rather unlikely if you managed to crash even before that, on the same site.
32bit? uuuuhmmmm, no!?! hello!? who are you kidding? im not that much of a dumbfuck to deserve getting such a great review of my bug. you almost got me fooled, but better luck next time. i am talking x64 here all the time. sweet goodness..... ------------- pedump /b "\Program Files (x86)\Minefield\firefox.exe" Dump of file \PROGRAM FILES (X86)\MINEFIELD\FIREFOX.EXE File Header Machine: 8664 (unknown) Number of Sections: 0006 TimeDateStamp: 4C3DCA57 -> Wed Jul 14 16:31:51 2010 PointerToSymbolTable: 00000000 NumberOfSymbols: 00000000 SizeOfOptionalHeader: 00F0 Characteristics: 0022 EXECUTABLE_IMAGE Optional Header Magic 020B linker version 10.00 size of code 1000 size of initialized data 13000 size of uninitialized data 0 entrypoint RVA 188C base of code 1000 base of data 40000000 image base 1 section align 1000 file align 200 required OS version 5.02 image version 0.00 subsystem version 5.02 Win32 Version 0 size of image 18000 size of headers 400 checksum 0 Subsystem 0002 (Windows GUI) DLL flags 8140 stack reserve size 100000 stack commit size 0 heap reserve size 1000 heap commit size 0 RVAs & sizes 0 -------- in contrast to my other minefield installation which is x32 and also named that way (directory), but which i have not been debugging, also im not quite that retarded since it doesnt experience the crash we are talking about here on the html5.com page, its useless if i would be debugging that as it doesnt crash on me. duh..... # pedump /b "\Program Files (x86)\Minefield-x32\firefox.exe" | more Dump of file \PROGRAM FILES (X86)\MINEFIELD-X32\FIREFOX.EXE File Header Machine: 014C (i386) Number of Sections: 0005 TimeDateStamp: 4C4590BC -> Tue Jul 20 14:04:12 2010 PointerToSymbolTable: 00000000 NumberOfSymbols: 00000000 SizeOfOptionalHeader: 00E0 Characteristics: 0102 EXECUTABLE_IMAGE 32BIT_MACHINE Optional Header Magic 010B linker version 8.00 size of code 2000 size of initialized data 15000 size of uninitialized data 0 entrypoint RVA 1870 base of code 1000 base of data 3000 image base 400000 section align 1000 file align 1000 required OS version 4.00 image version 0.00 subsystem version 4.00 Win32 Version 0 size of image 18000 size of headers 1000 checksum 0 Subsystem 0002 (Windows GUI) DLL flags 0140 stack reserve size 100000 stack commit size 1000 heap reserve size 40000 heap commit size 1000 RVAs & sizes 10 ---------------- so after all, i am reporting native x64 here. get your facts straight. i am running x64 win7 and running x64 debugtools from msft and reporting this bug on behalf of the x64 build i am using. why would my logfile from windbg feature sourcode references such as this: 00000000`02e0f800 00000000`6f1b1e53 MSVCR100!_callthreadstartex(void)+0x17 [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\threadex.c @ 314] 00000000`02e0f830 00000000`77154f4d MSVCR100!_threadstartex(void * ptd = 0x00000000`020ce060)+0x7f [f:\dd\vctools\crt_bld\self_64_amd64\crt\src\threadex.c @ 292] in the first place if we were talking x86/x32/win32 api. jebuz. stop making me feel like a complete retard and try to take input from users seriously for a change. why thank you. about those missing symbols, i did pretty much exactly the stuff that was being said on the mozilla developers wiki. i dont know why it tells me about that it cant verify the checksums of the symbols :( ----------- 0:000> .sympath SRV*c:\symbols*http://symbols.mozilla.org/firefox Symbol search path is: SRV*c:\symbols*http://symbols.mozilla.org/firefox Expanded Symbol search path is: srv*c:\symbols*http://symbols.mozilla.org/firefox 0:000> .symfix+ c:\symbols 0:000> .reload /f Reloading current modules .......*** WARNING: Unable to verify checksum for firefox.exe *** ERROR: Module load completed but symbols could not be loaded for firefox.exe .*** WARNING: Unable to verify checksum for C:\Program Files (x86)\Minefield\xul.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files (x86)\Minefield\xul.dll - .*** WARNING: Unable to verify checksum for C:\Program Files (x86)\Minefield\nss3.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files (x86)\Minefield\nss3.dll - .*** WARNING: Unable to verify checksum for C:\Program Files (x86)\Minefield\nspr4.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files (x86)\Minefield\nspr4.dll - .*** WARNING: Unable to verify checksum for C:\Program Files (x86)\Minefield\mozjs.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files (x86)\Minefield\mozjs.dll - .*** WARNING: Unable to verify checksum for C:\Program Files (x86)\Minefield\mozsqlite3.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files (x86)\Minefield\mozsqlite3.dll - .*** WARNING: Unable to verify checksum for C:\Program Files (x86)\Minefield\ssl3.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files (x86)\Minefield\ssl3.dll - .*** WARNING: Unable to verify checksum for C:\Program Files (x86)\Minefield\mozalloc.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files (x86)\Minefield\mozalloc.dll - .*** WARNING: Unable to verify checksum for C:\Program Files (x86)\Minefield\xpcom.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files (x86)\Minefield\xpcom.dll - .*** WARNING: Unable to verify checksum for C:\Program Files (x86)\Minefield\plc4.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files (x86)\Minefield\plc4.dll - .*** WARNING: Unable to verify checksum for C:\Program Files (x86)\Minefield\plds4.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files (x86)\Minefield\plds4.dll - Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long. Run !sym noisy before .reload to track down problems loading symbols. .*** WARNING: Unable to verify checksum for C:\Program Files (x86)\Minefield\smime3.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files (x86)\Minefield\smime3.dll - .*** WARNING: Unable to verify checksum for C:\Program Files (x86)\Minefield\nssutil3.dll *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files (x86)\Minefield\nssutil3.dll - .......................
about the x64 issue, maybe you just had been confused as the install path ended up in programfiles(x86) instead of plain programfiles. this is due to win32 installer instead of native x64 one with proper system calls (nsis) see bug: https://bugzilla.mozilla.org/show_bug.cgi?id=568949 anyways, my whole bugreport was about the x64 build and its bug, so i have created and bughunted proper data and you were quickly to dismiss it as supposedly wrong stuff. be more careful before complaining the next time.
yes the fact that the installation was to the x86 directory confused me. if you knew it was wrong then you should have manually fixed it. you're clearly smart enough. please don't insult people. https://bugzilla.mozilla.org/page.cgi?id=etiquette.html your account will be terminated if you insult people again. Anyway. I'm not sure where you got your 64bit build, but please don't use builds w/o symbols, they waste my time.
why would it matter where i installed stuff? users can install mozilla software anywhere, there is no hard standards or situations where it wouldnt work if it wasnt installed in a standard location. otherwise the user wouldnt need the possibility to chose manually i guess. besides who knows the exact details about microsoft folder structures and their chaos with all the various virtualized and compatibility stuff. programfiles, programfilesx86 and so on, i am not using x64 windows systems as production machines, just as of recently for testing, and i wasnt really aware where the x64 firefox should go exactly. only at a later time did i have time to find out more details about these folders and what arrives in programfiles and what in programfilesx86. so anyways, as the installer is 32bit it gets blended into the x86 folder. firefox doesnt care where it was installed as far as i can tell. so its not my fault where it ends up, and i could have installed it anywhere else. you cannot accuse people of using wrong software when they bugreport stuff. so i am not insulting people but i felt insulted and misunderstood by your reply to my rather extensive bugreport. i wasnt just braindumping some crazy thoughts into a random bugreport to annoy people. i was trying to help and to give detailed information. i posted my about: and/or about:buildconfig information, and it was clearly visible there that i was talking x64 all the time. still you were calling me 32bit names ;) btw, about where i got this build/installer. if i am not mistaken i initially arrived at the x64 installer packages via armenzg blog or some of his pagesd where he was talking x64 firefox stuff (maybe https://wiki.mozilla.org/User:Armenzg), and i think it actually came from the latest-mozilla-central area. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/ probably one of the builds that land at: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/firefox-4.0b2pre.en-US.win64-x86_64.installer.exe i dont know about the symbol stuff, maybe i thought all the non-final releases, previews, nightlies feature some kind of debug information and bits built-in. is the trunk stuff better for windbg and with more debuginformation? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ maybe this: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-4.0b2pre.en-US.win64-x86_64.installer.exe regards.
you didn't post about:buildconfig. you did list a build identifier, and i happened to overlook it. sadly people have a tendency to file bugs about BrowserX using BrowserY, which means that when one reviews a crash report one generally only looks at the information in the most recent bit, as there's no guarantee that anything else is relevant, current, matches, etc. unfortunately it turns out that we aren't currently (as far as a build engineer who just got back from vacation is aware) packaging 64bit symbols, which means the builds we're providing are useless to everyone. I will chew armenzg out about providing these builds in private. in the interim, I respectfully request that you not use 64bit builds if you intend to file bugs with them (unless you build the yourself) until bug 580623. any such builds are merely going to waste *everyone's* time. I'm not sure about a bug for a 64bit installer. if there isn't one, there should be. Please feel free to look for one and file one if you can't find it.
Blocks: tracking_win64
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: