Closed Bug 601355 Opened 14 years ago Closed 14 years ago

firefox-4.0b7pre.en-US.win64-x86_64/20100902 crashes consistently at start-up except if JM is disabled or in safe mode

Categories

(Core :: JavaScript Engine, defect)

x86_64
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- -
status2.0 --- wanted

People

(Reporter: sascsi, Assigned: m_kato)

References

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b7pre) Gecko/20100930 Firefox/4.0b7pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b7pre) Gecko/20101002 Firefox/4.0b7pre

my english is not good.sorry.
firefox-4.0b7pre.en-US.win64-x86_64 20101002015448 286d3026ae20
startup crashed everytime.
create new Profile crashed everytime too.



Reproducible: Always
It can only display the "about:home" page.
As soon as you show a menu or enter a new URL, it crashes.

It happens with either a partial install or a complete one.

The Windows "Close the program" feature does not generate a dump.

The regression range is :
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dabe4204f1c1&tochange=286d3026ae20
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
it doesn't crash in safe mode however
disabling JM fixed the problem 100%

related topic: http://forums.mozillazine.org/viewtopic.php?f=23&t=2004827
According to the regression range, it could be bug 587707 or bug 601016 but both are about SpiderMonkey.
It can be also a Core Graphics issue that uses JM. Indeed, it does not crash in safe mode and it crashes with a new profile, the only difference is HW acceleration which is disabled in safe mode and enabled with a new profile.
Component: General → Graphics
Product: Firefox → Core
QA Contact: general → thebes
Summary: firefox-4.0b7pre.en-US.win64-x86_64 crashed → firefox-4.0b7pre.en-US.win64-x86_64/20100902 crashes consistently at start-up except if JM is disabled or in safe mode
even about:config crashes firefox. i bet its HW accelerated graphics
> even about:config crashes firefox. i bet its HW accelerated graphics
UI is accelerated with D2D. So it could have been that.
I tried with a new profile that has D2D/DW/D3D disabled and it still crashes.
So it is not a Core Graphics issue and you're right, it is 100% JM.

Does that means that in safe mode, JM and HW acceleration are disabled. It is not shown in the choice of the safe mode window.
Assignee: nobody → general
Component: Graphics → JavaScript Engine
QA Contact: thebes → general
Safe mode disables tracejit, last I checked.  Does it not disable methodjit?

Can you link to the breakpad incidents for the crashes here?
blocking2.0: --- → ?
now, with methodjit enabled, firefox doesnt start at all. and about:crashes doesnt work (did it ever?)
20101003030544 bb18e81ea0f8
still crashe.
turnoff javascript.options.methodjit.chrome still crashe.
javascript.options.methodjit.chrome false
javascript.options.methodjit.contenct false
no crashes for me
20101003030544 bb18e81ea0f8
javascript.options.methodjit.chrome false
javascript.options.methodjit.contenct false
can work.
(In reply to comment #8)
> Can you link to the breakpad incidents for the crashes here?

There is no Crash Reporter, or symbols on the symbols server, for x64 builds.
hi,

I delete all Firefox program and profile and reinstall the 4.0b2pre Minefield and it works.

I re update the 4.0b7pre version and it don't work again
I can confirm that running Minefield in safe mode will allow the browser to operate (and not cause Windows to close it). In normal mode, I can open about:config, but trying to toggle the mentioned Javascript options causes an instant crash, leading me to believe that is the source of the problem, as suggested. 

I had no problem with 4.0b7pre prior to yesterday's update (20101002015448), running Vista x64 HP. Running an update from the safe mode browser fails now, so I'm not sure if there is an issue with corruption somewhere along the line
https://bugzilla.mozilla.org/show_bug.cgi?id=601410 also seems to be a duplicate of this nasty bugger.
I only now took a peek at the patch for bug 535912 and noticed that it changed the size of a JS bytecode sequence but did not regenerate JSXDR_BYTECODE_VERSION. That seems like something that could cause this bug.

/be
(In reply to comment #21)
> I only now took a peek at the patch for bug 535912 and noticed that it changed
> the size of a JS bytecode sequence but did not regenerate
> JSXDR_BYTECODE_VERSION. That seems like something that could cause this bug.

The problem in this bug seems to stop happening when JM is disabled. Shouldn't the version number problem be independent of JM?
(In reply to comment #22)
> (In reply to comment #21)
> > I only now took a peek at the patch for bug 535912 and noticed that it changed
> > the size of a JS bytecode sequence but did not regenerate
> > JSXDR_BYTECODE_VERSION. That seems like something that could cause this bug.
> 
> The problem in this bug seems to stop happening when JM is disabled. Shouldn't
> the version number problem be independent of JM?

Not for sure -- if old bytecode is accepted by new JM code that misinterprets the old (shorter) opcode as new, while other places somehow fail softly.

But I could be wrong. Still, the lack of JSXDR_BYTECODE_VERSION generation is a bug we should fix, stat.

/be
Attached patch fix — — Splinter Review
Comment on attachment 480551 [details] [diff] [review]
fix

Bug 587707 was invalid merging for Win64.   Although Brian changed Win64 code, I didn't notice that he code has bug excepting to bugstage.
Attachment #480551 - Flags: review?(dvander)
Assignee: general → m_kato
Comment on attachment 480551 [details] [diff] [review]
fix

I saw bhackett on mail recently.

Are we stuck using magic numbers in assembly, or could we use the C pre-processor to share manifest constants?

/be
Attachment #480551 - Flags: review?(bhackett1024)
Attachment #480551 - Flags: review?(bhackett1024) → review+
20101003200423 e3fa26aab8a6

javascript.options.methodjit.chrome true
javascript.options.methodjit.contenct true

still startup crashe.
(In reply to comment #29)
> 20101003200423 e3fa26aab8a6
> 
> javascript.options.methodjit.chrome true
> javascript.options.methodjit.contenct true
> 
> still startup crashe.

The fix hasn't landed yet, not even in the tracemonkey repo. Watch for this bug to be resolved fixed before trying a nightly Minefield. If you see the status whiteboard sprout fixed-in-tracemonkey, you can try a tracemonkey hourly or nightly that pulls after the fix push.

/be
20101004030635 192c38466579

javascript.options.methodjit.chrome true
javascript.options.methodjit.contenct true

still startup crashe.
blocking2.0: ? → -
status2.0: --- → wanted
Comment on attachment 480551 [details] [diff] [review]
fix

Unfortunately this is outside C code, I'm not sure how powerful MASM's preprocessor/C++ integration is. It helps if we static assert these offsets in MethodJIT.cpp.

bug 552150 is the way to go, long-term.
Attachment #480551 - Flags: review?(dvander) → review+
Crashing persists in 04/10/2010 build.
(In reply to comment #32)
> Comment on attachment 480551 [details] [diff] [review]
> fix
> 
> Unfortunately this is outside C code, I'm not sure how powerful MASM's
> preprocessor/C++ integration is. It helps if we static assert these offsets in
> MethodJIT.cpp.

Make can be made to run CPP on .s files. ;-)

> bug 552150 is the way to go, long-term.

Cool, forgot about that bug.

(In reply to comment #33)
> Crashing persists in 04/10/2010 build.

You guys (sascsi@gmail.com too), please stop adding noise. The patch has not yet landed on tracemonkey, let alone mozilla-central. See comment 30.

/be
It does also work with Java on and "Load Images Automatically" Off.

Only crashes if BOTH Java and the Images are on
http://hg.mozilla.org/tracemonkey/rev/be563f9b1578

Since there is no TM nightly for Win64, so wait merging TM to MC, please!
Whiteboard: fixed-in-tracemonkey
Hey guys!

I've seen the patch, but it doesn't help me either. I see the commands, but I don't know how to use this patch. The problem might be that I don't know anything about programming or scripting. So could anybody please explain me what the problem is and what I need to do to get rid of the bug?

Thank you very much!
1. start firefox in safe mode by modifying a shortcut: "C:\Program Files\Firefox\firefox.exe" -safe-mode
2. open about:config
3. search methodjit, set both false
works! :-)

And what did I do by changing the value to false?

Thank you again ;-).
black-earth, you turnt off JM, which has the bug. crashes itself and crashes firefox in the process. please read commments next time. all info is there. also in the thread linked in comment 4.
I'll do so. I tried to understand the comments, but I didn't get them.
Thank you again for your support kancaras.
im glad you use 64bit version ;) have a great time using it further
This is what i got from Windows error reports:

This is from Windows error report:
  Problem Event Name:    APPCRASH
  Application Name:    firefox.exe
  Application Version:    2.0.0.3930
  Application Timestamp:    4caaf485
  Fault Module Name:    mozjs.dll
  Fault Module Version:    0.0.0.0
  Fault Module Timestamp:    4caae92b
  Exception Code:    c0000005
  Exception Offset:    00000000001ab60e
  OS Version:    6.1.7600.2.0.0.768.3
  Locale ID:    1026
  Additional Information 1:    ae61
  Additional Information 2:    ae61702521dd6121f7be0fc073032d6c
  Additional Information 3:    3aa5
  Additional Information 4:    3aa529f651f839c91e1402897a62c672


Typing abv.bg shows this:

Problem signature:
  Problem Event Name:    BEX64
  Application Name:    firefox.exe
  Application Version:    2.0.0.3930
  Application Timestamp:    4caaf485
  Fault Module Name:    StackHash_b4ee
  Fault Module Version:    0.0.0.0
  Fault Module Timestamp:    00000000
  Exception Offset:    0000000011b5c2f8
  Exception Code:    c0000005
  Exception Data:    0000000000000008
  OS Version:    6.1.7600.2.0.0.768.3
  Locale ID:    1026
  Additional Information 1:    b4ee
  Additional Information 2:    b4ee5de6a2322745523997a782b35692
  Additional Information 3:    277e
  Additional Information 4:    277e19c30fbd5f6bb531ec9e027c37c3
when this fix will be pushed to the latest trunk ?

/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-4.0b7pre.en-US.win64-x86_64.installer.exe
Could someone with a working build environment please create a test build with the fix in Tracemonkey? It has been awfully quiet around this bug over the last days. JS performance has been abysmal for me with the suggested config fix.
I made a build from the current tracemonkey here it is:
http://www.mediafire.com/?ucwbwpj0wtp5w24
Daily builds of tracemonkey are available at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-tracemonkey/ -- there's no need to build your own, or distribute them via mediafire.
there is no x64 of windows daily.
You...are quite right! I wonder why that is!
I wouldn't of downloaded the trial of visual studio to try to build and help out if there was a daily lol
I will try to do a mozilla central build with the fix
I note that there are 64-bit builds with today's date sitting in: ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/ 

I cannot test at the moment, but do these include this fix now that it is in tracemonkey?
The issue is still occurring in the nightly.
here is the mozilla central that I build from today with the patch applied locally.  http://www.mediafire.com/?9cat140e8870lg7
(In reply to comment #69)
> here is the mozilla central that I build from today with the patch applied
> locally.  http://www.mediafire.com/?9cat140e8870lg7

did not work on my copy od windows 7 X64
It works fine on my computer.  I just downloaded it from mediafire again and installed it.
It will not work if you don't have some MS DLL's installed (msvcr100.dll) which I can't find, and presumably come with the installation of the development tools. It's not a standalone build. Try building it statically?
I'm new to building firefox, how would I build statically?  If someone know's i'll build again later?
The issue is still occurring in the today's nightly.
Very annoying ... the fix is here for several days but not in x64 mozilla central build ... why ?
not enough priority given to x64 maybe (words of Moz Corp itself)
which is extremely stupid since Ffx 4 is the first browser ever to get win_x64 version and x64 use is growing worldwide
its getting alot more atention after 64bit flash was released. maybe mozilla company will reconsider its priorities soon. i wonder what ar the statistics of 64bit firefox usage. tried googling it but coulnt find anything. only firefox browser as a whole.
(In reply to comment #69)
> here is the mozilla central that I build from today with the patch applied
> locally.  http://www.mediafire.com/?9cat140e8870lg7

I installed visual studio trial and it got James version to work. Thanks for the tip on visual studio having to be istalled to use this. The fix works great i just hope we can get a statically built build of this soon with the fix so visual studio is not needed to run it.
Please,
If you want to have discussion about Firefox 4.0 64-bit, go to:
http://forums.mozillazine.org/viewtopic.php?f=23&t=1993643

For the remaining issues about 64-bit, see bug 471090 and bug 558448.
can someone inform us when this bug will be fixed in the latest mozilla nightly ?
(In reply to comment #80)
> can someone inform us when this bug will be fixed in the latest mozilla nightly
> ?

Tracemonkey is currently landing compartments--it won't merge to mozilla-central until that's done. Precise ETA unknown but hopefully within a week. Tracemonkey nightlies have the fix now.
I had this problem when I updated to 4.0b8pre. Kept crashing so I tried disabling JScript which worked for a few sites, but Facebook, Twitter and some other sites would always crash.

I used the version here http://www.mediafire.com/?9cat140e8870lg7 and Minefield seems to be working fine now.
(In reply to comment #82)
> I had this problem when I updated to 4.0b8pre. Kept crashing so I tried
> disabling JScript which worked for a few sites, but Facebook, Twitter and some
> other sites would always crash.
> 
> I used the version here http://www.mediafire.com/?9cat140e8870lg7 and Minefield
> seems to be working fine now.

I updated to the latest nightly build put out at 9am pacific time and it does not crash what so ever on twitter and facebook for me or anyother site.
(In reply to comment #83)
> I updated to the latest nightly build put out at 9am pacific time and it does
> not crash what so ever on twitter and facebook for me or anyother site.

Cannot confirm. Be sure to remove any fixes from your prefs.js file. Minefield keeps crashing on me when I revert the javascript options.
(In reply to comment #84)
> (In reply to comment #83)
> > I updated to the latest nightly build put out at 9am pacific time and it does
> > not crash what so ever on twitter and facebook for me or anyother site.
> 
> Cannot confirm. Be sure to remove any fixes from your prefs.js file. Minefield
> keeps crashing on me when I revert the javascript options.

I did not have any of the fixes setup. i did not turn anything off I had just not used any other build afte the first crash build until the one on mediafire. and i updated to ro rhw newest tday and it was fine with no crashing.
Latest 64bit nightly trunk still crashes with default settings.
BuildID=20101012063331
This is the build I have and it dont crash: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-tracemonkey/firefox-4.0b8pre.en-US.win64-x86_64.installer.exe

firefox-4.0b8pre.en-US.win64-x86_64.installer.exe	12-Oct-2010 09:04 	10M
Please,
Comments are used to determine the cause of a bug. Now the cause is well known and the bug is fixed in tracemonkey builds, every comments since comment 43 should have been in a forum thread in Mozillazine.
Stop adding noise, especially for users that first read this bug.
http://hg.mozilla.org/mozilla-central/rev/be563f9b1578
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
The latest nightly for x86_64 is dated Oct. 13 and still contains the issue, what's up? Did the fix break something in the building process?
See bug https://bugzilla.mozilla.org/show_bug.cgi?id=604323 breaks the build of x64 in mozilla central again.
Any idea when a new build will be available? It's almost been a week since this was supposedly fixed, and the tracemonkey builds seem to crash while loading gmail for some reason.
> Any idea when a new build will be available?
This bug is fixed in b8pre/20101015 build that does not exist because of bug 604323. That one is fixed in b8pre/20101019 build that does not exist for an unknown reason.
Please, file a new bug for x64 builds that are not generated.
(In reply to comment #95)
> Any idea when a new build will be available? It's almost been a week since this
> was supposedly fixed, and the tracemonkey builds seem to crash while loading
> gmail for some reason.

Watch http://tinderbox.mozilla.org/MozillaTest/ or use http://nightly.mozilla.org/js-preview.html.  Yesterday has infra problem.
It would be nice to have the latest-trunk with Win64 build again.
the js-preview works for me, but there are no updates.
(In reply to comment #101)
> What are the differences between this two versions of Minefield x64?
> 
> ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-4.0b8pre.en-US.win64-x86_64.installer.exe
> 
> ftp://ftp.mozilla.org/pub/firefox/nightly/latest-tracemonkey/firefox-4.0b8pre.en-US.win64-x86_64.installer.exe

They are basically two different branches that merge approximately weekly. Most JS changes land first on TM. Almost all non-JS changes land first on mozilla-central.
it still persists on current b12pre
You need to log in before you can comment on or make changes to this bug.