Closed Bug 689851 Opened 13 years ago Closed 3 years ago

Firefox 5+ x86 perpetually hangs on an IA64 system

Categories

(Core :: JavaScript Engine, defect)

Other
Windows Server 2003
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: nickenzi, Unassigned)

Details

(Keywords: 64bit, hang, Whiteboard: [has stacktrace ])

Attachments

(2 files, 2 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:9.0a1) Gecko/20110926 Firefox/9.0a1 Build ID: 20110926030901 Steps to reproduce: I opened Firefox on my Windows Server 2003 IA64 Machine. (IA64 as in Itanium. Not AMD64 as in x64.) Actual results: After about a second or two, the program hangs indefinitely using 25% of 4 CPUs and about 150MB RAM. This occurs on every version from 5 up to the latest Nightly (9). Expected results: Firefox should not have hung indefinitely, but should have operated normally as versions <=4.0.1 do.
Keywords: 64bit, hang
OS: Windows 7 → Windows Server 2003
Hardware: x86 → Other
Can you try it in the Firefox safemode ? http://support.mozilla.com/en-US/kb/Safe+Mode This disables all addons, the JS jit and the hardware acceleration.
I just tried it, and yes it does.
it's working in the FF safemode ? In that case start in the safemode and disable all addons in (alt key)/tools/addon/extensions. Try it in the normal mode again. If that doesn't work start again in the safemode and disable the hardware acceleration under tools/options/advanced/general. If that doesn't work open about:config, enter "jit" in the top filter bar and disable(false) the 2 methodjit and the 2 tracejit options
I'm sorry, that's my mistake. I should have been clearer. It still hangs, even in safe mode.
It's getting difficult now... We would need a stacktrace but i don't know if the symbols are on the symbol server and if there is a ia64 version of windbg.
It looks as if there is an ia64 version of the debugging tools. I have no programming/debugging experience, but since Firefox is running in the ia32 (x86) emulation layer, would the x86 debugging tools be a better choice? http://msdn.microsoft.com/en-us/windows/hardware/gg463009
Attached file Debug Log (obsolete) —
This is what I got from debugging. This time, the Nightly window didn't open; it hung beforehand, but not like it usually does. I don't know if it will still be useful.
I confirm I'm seeing the same problem here (and v3.6.25 runs fine) so it's not an isolated one-off incident.
does 32bit build also fail?
Wayne, i'm not sure what you're asking, since only 32 bit (x86) builds of Firefox were attempted to be run on an IA64 platform. As far as I know, an IA64 build has never been compiled nor attempted to have been compiled.
my bad. anyway, can you reproduce using current nightly, and get a stacktrace please. https://developer.mozilla.org/En/How_to_get_a_stacktrace_with_Windbg
Keywords: stackwanted
Attached file Nightly 2MAR2012 Debug (obsolete) —
Here is the debug log from The Nightly I downloaded this morning.
Attachment #563093 - Attachment is obsolete: true
Keywords: stackwanted
Whiteboard: [has stacktrace]
Whiteboard: [has stacktrace] → [has stacktrace ]
(In reply to nickenzi from comment #13) > Created attachment 602375 [details] > Nightly 2MAR2012 Debug > > Here is the debug log from The Nightly I downloaded this morning. nickenzi, could you attach x86 debugger instead of IA64 debugger? You seems to attach IA64 debugger, so stack trace isn't outputted well. (If using x86 binary, you have to use x86 debugger)
Here is the debug log as outputted from the x86 version WinDbg. I'm not sure that it liked being run in the ia32 emulation layer since it couldn't find symbols for ntdll.dll.
Here is the output of the ia64 debugger with today's nightly.
Attachment #602375 - Attachment is obsolete: true
(In reply to nickenzi from comment #15) > Created attachment 685175 [details] > Nightly 26NOV2012 Debug Log (x86 debugger) > > Here is the debug log as outputted from the x86 version WinDbg. I'm not > sure that it liked being run in the ia32 emulation layer since it couldn't > find symbols for ntdll.dll. thanks. If firefox.exe process hang, VitrualAlloc on gc thread doesn't seem to return from kernel api call. It is strange...
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
Assignee: general → nobody
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: