451986 - TM: Crash [@ nanojit::LIns::isop(nanojit::LOpcode) ] with JIT chrome enabled when opening Bookmark Organizer

Status: RESOLVED DUPLICATE of bug 453563

(Core :: JavaScript Engine, defect)

Description

[Jim Jeffery not reading bug-mail 1/2/11]

Enable in about:config JIT Chrome setting = set to true
Open the Bookmarks Organizer - note Crash! with No Breakpad Report

Comment 1

[Jean-Marc Desperrier]

I myself got a breakpad report :
http://crash-stats.mozilla.com/report/index/b09f7ad7-721c-11dd-b8e0-0013211cbf8a?p=1

Signature	nanojit::LIns::isop(nanojit::LOpcode)

Comment 2

[David Anderson [:dvander] - inactive, e-mail if emergency]

tracemonkey tip, asserting here:

Assertion failure: (traceMonitor->globalSlots->data()[n]) < (uint32)(globalObj)->dslots[-1], at /Users/dvander/mozilla/debugmonkey/js/src/jstracer.cpp:1380

(gdb) bt 5
#0  JS_Assert (s=0x32f5ac "(traceMonitor->globalSlots->data()[n]) < (uint32)(globalObj)->dslots[-1]", file=0x32ef8c "/Users/dvander/mozilla/debugmonkey/js/src/jstracer.cpp", ln=1380) at /Users/dvander/mozilla/debugmonkey/js/src/jsutil.cpp:63
#1  0x002c2997 in TraceRecorder::snapshot (this=0x165f6d30, exitType=nanojit::MISMATCH_EXIT) at /Users/dvander/mozilla/debugmonkey/js/src/jstracer.cpp:1373
#2  0x002c31b4 in TraceRecorder::guard (this=0x165f6d30, expected=false, cond=0x1532b714, exitType=nanojit::MISMATCH_EXIT) at /Users/dvander/mozilla/debugmonkey/js/src/jstracer.cpp:1391

Comment 4

[Jim Jeffery not reading bug-mail 1/2/11]

No longer crashing with today's nightly after the latest 'tracemonkey' -> 'm-c' merge on 9/2/2008

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080903034741 Minefield/3.1b1pre Firefox/3.0 ID:20080903034741

Comment 5

[Jim Jeffery not reading bug-mail 1/2/11]

Sorry for the spam, closing / restarting the browser is apparently needed to enable the JIT Chrome change, still crashing opening the Organizer/Library.

Comment 6

[Hermann Schwab]

jit.chrome enabled, looking at history, crashes on opening 'All History'

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080903034741 Minefield/3.1b1pre

http://crash-stats.mozilla.com/report/index/16f44287-742e-11dd-aef3-001a4bd43e5c
http://crash-stats.mozilla.com/report/index/858a1dcf-7409-11dd-9290-001a4bd43e5c

Comment 7

[IU]

Please change the "Platform" to include Win XP.  Also, change "Importance" to critical, since this crashes the browser.

Additionally, clicking a history entry in the History sidebar also crashes the browser.

Comment 8

[Andreas Gal :gal]

Enabling the JIT for Chrome is currently not recommended. I will make a separate dependent bug to track chrome regressions and we will prioritize those if a decision is made to aim for JIT on for Chrome for any of of the betas.

Comment 9

[Jean-Marc Desperrier]

I fully understand prioritizing content over chrome, but is there something that proves that content will never exercise the kind of code that produces this crash ?

I tend to think all crash and functional bugs (the same js code does not give the same execution result after tracing) should be major bugs for TraceMonkey.

Comment 10

[Brendan Eich [:brendan]]

Jean-Marc, you are right: there's no doubt this bug must be fixed unless we can prove it can't happen from content. Marking critical for now.

/be

Comment 11

[RFLazaro]

Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080908091724 Minefield/3.1b1pre

No crashes on the following:
Bookmarks -> Organize Bookmarks
History -> Show All history
View -> Sidebar -> History, click a history entry

Comment 12

[Alfred Kayser]

No, in that build it still crashes. Just be sure to turn on JIT for both content as well as chrome, and then try to open the Bookmarks Manager.

Comment 13

[RFLazaro]

I do have both JIT options enabled.

This is weird it now crashes =(

Crash with no reporter: Bookmarks -> Organize Bookmarks
Crash with reporter: History -> Show All history
Works: View -> Sidebar -> History, click a history entry

Comment 14

[RFLazaro]

Works again with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080909032504 Minefield/3.1b1pre

Note: I deleted the XUL.mfl and XPC.mfl; I think those were causing the crashes

Comment 15

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to comment #14)
> Works again with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre)
> Gecko/20080909032504 Minefield/3.1b1pre
> 
> Note: I deleted the XUL.mfl and XPC.mfl; I think those were causing the crashes

Makes no difference here, still instant crash:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080909072059 Minefield/3.1b1pre Firefox/3.0 ID:20080909072059

http://crash-stats.mozilla.com/report/index/7f09e602-7edb-11dd-96ac-001cc45a2ce4

Comment 16

[IU]

Same here. Deleting XUL.mfl and XPC.mfl makes no difference -- even when deleted from a brand-spanking new profile, after enable JIT chrome and exiting the browser.

Let's face it.  This IS a bug that requires a patch.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080909032504 Firefox/2.0.0.11 ID:20080909032504

Comment 17

[Alfred Kayser]

Please don't report here that "now it works for me". As long as there is no patch submitted or other physical proof that something has been fixed, any occurances of firefox not happening to crash on it is not real proof that it is fixed. As long as others can reproduce this crash, complete with crash reports, this crash is really there and really needs to be fixed (as it is really a serious issue somewhere in the TraceMonkey engine).

Comment 18

[RFLazaro]

(In reply to comment #17)
> Please don't report here that "now it works for me". As long as there is no
> patch submitted or other physical proof that something has been fixed, any
> occurances of firefox not happening to crash on it is not real proof that it is
> fixed. As long as others can reproduce this crash, complete with crash reports,
> this crash is really there and really needs to be fixed (as it is really a
> serious issue somewhere in the TraceMonkey engine).

I was trying to help isolate the issue.

If I can only show you a video showing that all those three crashes are working correctly in my Firefox version I would.

Comment 19

[IU]

@rflazaro: what happens when you do the same as your Comment #14 using a brand new (unmodified, except per your Comment #14, and obviously enabling both JITs and restarting) profile?  Also, what is your CPU?

Comment 20

[RFLazaro]

It now crashes =( 

CPU? I'm on a Pentium 4

Comment 21

[David Anderson [:dvander] - inactive, e-mail if emergency]

Will continue to look into this, looks like the global object's shape is changing while recording.  This is causing guards to assert as dslots[-1] is shrinking.  It's the same global object though so it doesn't seem the same bug as 454512 (despite having the same assertion).

Comment 22

[Gabriel Chadwick]

Getting crash with Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1b1pre) Gecko/20080910043000 Minefield/3.1b1pre

Crash report http://crash-stats.mozilla.com/report/index/de6fd2ee-8077-11dd-88c1-001cc45a2c28?p=1

Comment 23

[IU]

This is now WFM, probably because of the check-in for Bug 454744

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080911212530 Firefox/2.0.0.16 ID:20080911212530

Comment 24

[Alfred Kayser]

Yeah!

Confirmed FIXED by bug 454744:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080911105329 Minefield/3.1b1pre

Comment 25

[Jim Jeffery not reading bug-mail 1/2/11]

Verified Fixed using hourly build:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080912024835 Minefield/3.1b1pre Firefox/3.0 ID:20080912024835

Comment 27

[David Anderson [:dvander] - inactive, e-mail if emergency]

Hrm -- I don't think this was really fixed.  I'm still getting a bad assertion in debug mode (comments 2, 21).  If you're using the tinderbox builds you probably aren't seeing this, though it definitely looks crash prone.  Re-opening unless someone wants me to file a different bug.

Comment 28

[David Anderson [:dvander] - inactive, e-mail if emergency]

Okay my apologies, I was misleading myself -- this was actually fixed in bug 453563 (not 454744) and I was pulling from the wrong repository yesterday.