Closed
Bug 481436
Opened 15 years ago
Closed 15 years ago
TM: Crash [@ FlushNativeStackFrame ] or [@ JS_XDRNewMem]
Categories
(Core :: JavaScript Engine, defect, P1)
Core
JavaScript Engine
Tracking
()
VERIFIED
DUPLICATE
of bug 481060
People
(Reporter: jmjjeffery, Unassigned)
References
()
Details
(4 keywords, Whiteboard: [sg:critical?])
Crash Data
Attachments
(3 files)
Visit the URL and note crash. Crash reports: http://crash-stats.mozilla.com/report/index/aba70561-fda3-4334-a29a-ad6d32090304?p=1 Also noted in the build forums: http://forums.mozillazine.org/viewtopic.php?p=5907525#p5907525 turning JIT.content prevents the crash. According to pushlogs there was a TM merge last evening. changset: http://hg.mozilla.org/mozilla-central/rev/e31c4f602541
Reporter | ||
Comment 1•15 years ago
|
||
While this is a TM crash, its not due to the latest merge, I still crash using changset: http://hg.mozilla.org/mozilla-central/rev/b0738a6a17fa hourly build: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090303 Minefield/3.2a1pre Firefox/3.0.4 ID:20090303091331 This changeset is prior to the landing of the TM merge... Help needed to find regress range ...
Reporter | ||
Comment 2•15 years ago
|
||
Regression range: No Crash: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090228 Minefield/3.2a1pre Crash: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090301 Minefield/3.2a1pre
OS: Windows Vista → All
Please make the following changes: - Importance: critical - Keywords: add crash
Flags: blocking1.9.1?
Comment 4•15 years ago
|
||
From Comment 2 Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090228 Minefield/3.2a1pre - http://hg.mozilla.org/mozilla-central/rev/f3d5f4a980a0 Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090301 Minefield/3.2a1pre - http://hg.mozilla.org/mozilla-central/rev/ad8d75516c5e http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f3d5f4a980a0&tochange=ad8d75516c5e
Comment 5•15 years ago
|
||
Crashed Shiretoko, too. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090304 Shiretoko/3.1b3pre Firefox/3.0.6 - Build ID: 20090304033811
Comment 6•15 years ago
|
||
Shiretoko Crash Report: http://crash-stats.mozilla.com/report/index/6e17d466-d0e5-4ef1-82c0-dd6322090304
Comment 7•15 years ago
|
||
I have a <500 line testcase reduced from one of the js files that URL calls - still reducing now.
Comment 8•15 years ago
|
||
(In reply to comment #7) > I have a <500 line testcase reduced from one of the js files that URL calls - > still reducing now. Turning this security-sensitive, 60-line testcase (reduced from URL source, about to be attached) crashes Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090304 Shiretoko/3.1b3pre at scary possibly exploitable location at 0xc0000000 at JS_XDRNewMem in Mac.
Group: core-security
Keywords: testcase
Comment 9•15 years ago
|
||
Comment 10•15 years ago
|
||
Crashes that opt nightly build of mine when javascript.options.jit.content is turned on, and doesn't when turned off. I think the 60-line testcase can still be reduced further.
Hardware: x86 → All
Summary: TM: Crash [@ FlushNativeStackFrame ] → TM: Crash [@ FlushNativeStackFrame ] or [@ JS_XDRNewMem]
Comment 11•15 years ago
|
||
Comment 12•15 years ago
|
||
This WFM in tracemonkey tip, but not in m-c tip. I discovered this *after* working with Gary for about 2 hours reducing the test case to: <script> function search(m, n) { if (m.name == n) return m; for (var i = 0; i < m.items.length; i++) if (m.items[i].type == 'M') search(m.items[i], n); } function test() { for (var i = 0; i < 2; i++) { var root = {name: 'root', type: 'M', items: [{}]}; search(root, 'x'); root.items.push({name: 'tim', type: 'M', items: []}); search(root, 'x'); search(root, 'x'); } } test(); </script>
Comment 13•15 years ago
|
||
The crash locations in this bug, FlushNativeStackFrame and JS_XDRNewMem, look amazingly like the ones in bug 452554.
Comment 14•15 years ago
|
||
The most likely check-in in the regression range is the TM merge. Most of those changes were by andreas, with a couple by jwalden. Looks like andreas's bugs also landed on 1.9.1, jwalden's bug 473256 hasn't. Does this crash 1.9.1? I don't know what bug this lines up with so I don't know if it landed on 1.9.1: "0fa1762eb00e Jeff Walden — guardElemOp relies on op_offset representing JSObjectOps.getProperty or JSObjectOps.setProperty, so it should assert it. r=lumpy, sr=jack" Who is "lumpy" and "jack"?
Comment 15•15 years ago
|
||
(In reply to comment #14) > Looks like andreas's bugs also landed on 1.9.1, jwalden's bug 473256 hasn't. > Does this crash 1.9.1? Yes. My build ID was Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090304 Shiretoko/3.1b3pre in comment #8.
Comment 16•15 years ago
|
||
(In reply to comment #14) > I don't know what bug this lines up with so I don't know if it landed on 1.9.1: > "0fa1762eb00e Jeff Walden — guardElemOp relies on op_offset representing > JSObjectOps.getProperty or JSObjectOps.setProperty, so it should assert it. > r=lumpy, sr=jack" > > Who is "lumpy" and "jack"? waterson's dogs, as I recall. There's nothing in that push that should have any relevance in terms of crashing, it's adding one assertion that's debug-only: http://hg.mozilla.org/mozilla-central/rev/0fa1762eb00e The other push I made in that range has since been backed out in TM and replaced with a different fix.
Updated•15 years ago
|
Whiteboard: [sg:critical?]
Updated•15 years ago
|
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P1
Reporter | ||
Comment 17•15 years ago
|
||
This site is no longer crashing using the latest hourly following the latest merge from TM. Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090310 Minefield/3.2a1pre Firefox/3.0.4 ID:20090310224714 <-hourly build vista HP SP2 RC
Updated•15 years ago
|
Flags: in-testsuite?
Comment 18•15 years ago
|
||
I can't reproduce this, either
Comment 19•15 years ago
|
||
The fix should thus have landed somewhere between these two builds: (In reply to comment #4) > Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; > rv:1.9.2a1pre) Gecko/20090301 Minefield/3.2a1pre > - http://hg.mozilla.org/mozilla-central/rev/ad8d75516c5e Crashes. (In reply to comment #17) > This site is no longer crashing using the latest hourly following the latest > merge from TM. > > Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090310 > Minefield/3.2a1pre Firefox/3.0.4 ID:20090310224714 <-hourly build No crash.
Comment 20•15 years ago
|
||
Let's use tracemonkey nightlies to get a narrower regression range here, but it's probably jorendorff's work.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 21•15 years ago
|
||
Updated•15 years ago
|
Flags: in-testsuite? → in-testsuite+
Comment 22•15 years ago
|
||
http://hg.mozilla.org/tracemonkey/rev/ad8d75516c5e Assertion failure: tree->root == tree fixed in http://hg.mozilla.org/tracemonkey/rev/7cd904a49d37 see bug 481060
Updated•15 years ago
|
Keywords: fixed1.9.1
Resolution: FIXED → DUPLICATE
Comment 24•15 years ago
|
||
v 1.9.1, 1.9.2
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
Updated•15 years ago
|
Group: core-security
Flags: wanted1.9.0.x-
Comment 25•15 years ago
|
||
http://hg.mozilla.org/tracemonkey/rev/ed5599dcf5e1 /cvsroot/mozilla/js/tests/js1_5/Regress/regress-481436.js,v <-- regress-481436.js initial revision: 1.1
Updated•13 years ago
|
Crash Signature: [@ FlushNativeStackFrame ]
[@ JS_XDRNewMem]
You need to log in
before you can comment on or make changes to this bug.
Description
•