481436 - TM: Crash [@ FlushNativeStackFrame ] or [@ JS_XDRNewMem]

Status: VERIFIED DUPLICATE of bug 481060

(Core :: JavaScript Engine, defect, P1)

Description

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

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

Comment 1

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

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 ...

Comment 2

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

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

Comment 3

[IU]

Please make the following changes:

- Importance: critical
- Keywords: add crash

Comment 4

[Steve England [:stevee]]

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

[WildcatRay]

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

[WildcatRay]

Shiretoko Crash Report:

http://crash-stats.mozilla.com/report/index/6e17d466-d0e5-4ef1-82c0-dd6322090304

Comment 7

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

I have a <500 line testcase reduced from one of the js files that URL calls - still reducing now.

Comment 8

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(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.

Comment 9

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: testcase

Comment 10

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

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.

Comment 11

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: crashlog.txt

Comment 12

[Jason Orendorff [:jorendorff]]

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

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

The crash locations in this bug, FlushNativeStackFrame and JS_XDRNewMem, look amazingly like the ones in bug 452554.

Comment 14

[Daniel Veditz [:dveditz]]

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

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(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

[Jeff Walden [:Waldo]]

(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.

Comment 17

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

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

Comment 18

[Robert Sayre]

I can't reproduce this, either

Comment 19

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

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

[Robert Sayre]

Let's use tracemonkey nightlies to get a narrower regression range here, but it's probably jorendorff's work.

Comment 21

[Bob Clary [:bc] (inactive)]

Attachment: js1_5/Regress/regress-481436.js

Comment 22

[Bob Clary [:bc] (inactive)]

http://hg.mozilla.org/tracemonkey/rev/ad8d75516c5e
Assertion failure: tree->root == tree

fixed in http://hg.mozilla.org/tracemonkey/rev/7cd904a49d37
see bug 481060

Comment 24

[Bob Clary [:bc] (inactive)]

v 1.9.1, 1.9.2

Comment 25

[Bob Clary [:bc] (inactive)]

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