Google Maps causes hang or "Assertion failure: newRange->lower() >= oldRange.lower()"

VERIFIED FIXED in Firefox 18

Status

()

Core
JavaScript Engine
--
critical
VERIFIED FIXED
5 years ago
3 years ago

People

(Reporter: Jesse Ruderman, Assigned: mjrosenb)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
mozilla19
x86_64
Mac OS X
assertion, dogfood, hang, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox17 unaffected, firefox18+ verified, firefox19 verified)

Details

(Whiteboard: [ion:p1], URL)

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Created attachment 669326 [details]
watch jesse and nicolas poke around in gdb

In Firefox Nightly,
1. Load Google Maps (non-WebGL version)
2. Mess around (e.g. zoom in and out) for ~30 seconds

Result:
  Opt -> hang
  Debug -> assert

Assertion failure: newRange->lower() >= oldRange.lower(), at /Users/jruderman/trees/mozilla-central/js/src/ion/RangeAnalysis.h:194

Might be related to bug 799163.
(Reporter)

Updated

5 years ago
Keywords: dogfood
(Reporter)

Updated

5 years ago
(Reporter)

Comment 1

5 years ago
Might be related to bug 799157 as well.
Whiteboard: [ion:p1]
Octane's Box2D benchmark also trips this assertion.
tracking-firefox18: --- → ?
Knowing that patches which have added the Range analysis have landed just before the merge to aurora, I am flagging this bug as affecting both 18 & 19.
status-firefox18: --- → affected
status-firefox19: --- → affected
(Assignee)

Comment 4

5 years ago
Created attachment 669508 [details] [diff] [review]
/home/mrosenberg/patches/dontAssert-r0.patch

I have no clue if this actually fixes the bug that jesse observed, but it fixes the identical sounding bug in box2d.js (Thank, Sean!)
Jesse, if you have a bit of time, can you apply this patch, and see if it fixes your bug?
Attachment #669508 - Flags: review?(jdemooij)

Updated

5 years ago
status-firefox17: --- → unaffected
tracking-firefox18: ? → +

Comment 5

5 years ago
Try run for 2366f5357c62 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=2366f5357c62
Results (out of 291 total builds):
    exception: 2
    success: 269
    warnings: 16
    failure: 4
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mrosenberg@mozilla.com-2366f5357c62
Comment on attachment 669508 [details] [diff] [review]
/home/mrosenberg/patches/dontAssert-r0.patch

Review of attachment 669508 [details] [diff] [review]:
-----------------------------------------------------------------

Nice.

::: js/src/ion/MIR.cpp
@@ +481,5 @@
>  {
>      if (type() != MIRType_Int32)
>          return false;
>  
> +    // Use RangeChangeCount rather than Range because it needs to

Nit: s/RangeChangeCount/RangeUpdater

@@ +502,1 @@
>              if (block()->isLoopHeader())

Nit: can merge with the if statement before this one.

::: js/src/ion/RangeAnalysis.cpp
@@ +297,5 @@
> +            r_.makeLowerInfinite();
> +    } else {
> +        r_.setLower(other->lower());
> +        lowerSet_ = true;
> +    }

The other unionWith method below does something very similar. It would be good to add private updateLower/updateUpper methods and call it here and below, something like

RangeUpdater::updateLower(const Range *other)
{
    if (lowerSet_) {
        r_.setLower(Min(r_.lower(), other->lower()));
    } else {
        r_.setLower(other->lower());
        lowerSet_ = true;
    }
    if (other->isLowerInfinite())
        r_.makeLowerInfinite();
}

@@ +319,5 @@
> +        // otherwise, initialize it.
> +        if (lowerSet_) {
> +            r_.setLower(Min(r_.lower(), other->oldRange.lower()));
> +        } else {
> +            lowerSet_ = 1;

Nit: s/1/true, and below.
Attachment #669508 - Flags: review?(jdemooij) → review+
Assignee: general → mrosenberg
Status: NEW → ASSIGNED
Zooming in and out of batchgeo maps also triggers this issue.
I'm getting a hang (OS X beachball of death) on

http://toronto.kijiji.ca/c-ViewMap?AdId=420291148

(Which has an embedded Google map)

Is that the same bug?
(Assignee)

Comment 10

5 years ago
I'd be tempted to say it is.  If you don't want to wait for tonight's nightly to see if I fixed it, the tbpl build from my commit is:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-macosx64/1349846943/firefox-19.0a1.en-US.mac.dmg
(Assignee)

Comment 11

5 years ago
Which also reminds me, I landed this on mi, but I have no clue if it actually fixes the issue reported.

https://hg.mozilla.org/integration/mozilla-inbound/rev/e16d4075ad64
https://hg.mozilla.org/integration/mozilla-inbound/rev/41c4510e6635
(In reply to Marty Rosenberg [:mjrosenb] from comment #10)
> I'd be tempted to say it is.  If you don't want to wait for tonight's
> nightly to see if I fixed it, the tbpl build from my commit is:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-
> inbound-macosx64/1349846943/firefox-19.0a1.en-US.mac.dmg

Marty, your build is good!

I can consistently reproduce this on Nightly but your build has no problems with that embedded Google map.

\o/
https://hg.mozilla.org/mozilla-central/rev/41c4510e6635
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19

Updated

5 years ago
status-firefox19: affected → ---
Duplicate of this bug: 799163
Duplicate of this bug: 800861
(Assignee)

Comment 16

5 years ago
Comment on attachment 669508 [details] [diff] [review]
/home/mrosenberg/patches/dontAssert-r0.patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 765119
User impact if declined: frequent LONG pauses (the processor will need to count from INT_MIN to 0 with lots of memory accesses)
Testing completed (on m-c, etc.): it has been on m-c, and seems stable.
Risk to taking this patch (and alternatives if risky): None that I know of
String or UUID changes made by this patch:
Attachment #669508 - Flags: approval-mozilla-aurora?
Duplicate of this bug: 800393

Updated

5 years ago
Blocks: 765119

Updated

5 years ago
Duplicate of this bug: 801600
Duplicate of this bug: 800485
Comment on attachment 669508 [details] [diff] [review]
/home/mrosenberg/patches/dontAssert-r0.patch

Approving for aurora as it is a low risk patch and has been verified fixed as per comment 12
Attachment #669508 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Comment 21

5 years ago
Aurora (18) still crash when trying to open/load planefinder.net website, which is a mashup of Google Maps. Please check.
(In reply to Robert DC. Reyes from comment #21)
> Aurora (18) still crash when trying to open/load planefinder.net website,
> which is a mashup of Google Maps. Please check.

This patch hasn't landed on Aurora yet. It will probably get landed in another day or two (the flag status-firefox18 will get set to "fixed"), and then it may take another day for it to get into the released build of Aurora.
(Assignee)

Comment 23

5 years ago
Landed on aurora: https://hg.mozilla.org/releases/mozilla-aurora/rev/b7c1e5b794ce
status-firefox18: affected → fixed
(Assignee)

Updated

5 years ago
Duplicate of this bug: 801825

Comment 25

5 years ago
Updated to 18.0a2 (2012-10-17) but planefinder.net still not does work! Cannot drag on the map.

Comment 26

5 years ago
(In reply to Robert DC. Reyes from comment #25)
> Updated to 18.0a2 (2012-10-17) but planefinder.net still not does work!
> Cannot drag on the map.
You reported hangs in bug 801600, not this issue. Please file a bug for the dragging issue.
(In reply to Robert DC. Reyes from comment #25)
> Updated to 18.0a2 (2012-10-17) but planefinder.net still not does work!
> Cannot drag on the map.

That site works fine for me both on Nightly and Aurora of 2012-10-17. I can drag, zoom, everything animates, etc.

I am on OS X 10.8.2

What OS are you on? May be related?

Comment 28

5 years ago
1. http://elgoog.im/underwater/
2. Assertion failure: def->range()->lower() <= def->range()->upper() occurs on Aurora/18. It was fixed on Nightly/19 by this bug.

The regression was initially introduced by bug 795803 on Nightly and merged into Aurora as a different assertion. The original assertion was fixed on Nightly but still left Assertion failure: def->range()->lower() <= def->range()->upper() which was fixed on Nightly by this bug.

It appears that https://hg.mozilla.org/integration/mozilla-inbound/rev/e16d4075ad64 was not landed on Aurora.
status-firefox18: fixed → affected

Updated

5 years ago
Blocks: 532972
https://hg.mozilla.org/releases/mozilla-aurora/rev/edf686a532b7
status-firefox18: affected → fixed
status-firefox19: --- → fixed
https://maps.google.com/ and http://elgoog.im/underwater/ freeze Nightly 2012-10-10, tested on Mac OS X 10.7, Win 7
Verified fixed FF 18b2.
status-firefox18: fixed → verified
Keywords: verifyme
QA Contact: paul.silaghi
(In reply to Paul Silaghi [QA] from comment #30)
> https://maps.google.com/ and http://elgoog.im/underwater/ freeze Nightly
> 2012-10-10, tested on Mac OS X 10.7, Win 7
> Verified fixed FF 18b2.
Verified fixed FF 19b3 Mac OS X 10.8.2
Status: RESOLVED → VERIFIED
status-firefox19: fixed → verified
Keywords: verifyme

Updated

3 years ago
Duplicate of this bug: 799804
You need to log in before you can comment on or make changes to this bug.