The default bug view has changed. See this FAQ.

crash nsLineBox::IndexOf

RESOLVED FIXED in mozilla11

Status

()

Core
Layout
--
critical
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: cjones, Assigned: jwir3)

Tracking

({crash, regression})

Trunk
mozilla11
crash, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(1 attachment)

This bug was filed from the Socorro interface and is 
report bp-77464faf-df98-4a05-9457-3b50f2111116 .
============================================================= 

STR
 (1) Load URL.  Crash.

This reproduced for me 2/2 and then I didn't want to try anymore ;).
(The crash is a null pointer deref, so not marking s-s.)

Comment 2

5 years ago
Also this site crashes on windows7 , but crash sig is not a same.

bp-e7c5222c-0528-41da-b83c-0fe252111116
[@ nsBlockInFlowLineIterator::nsBlockInFlowLineIterator(nsBlockFrame*, nsIFrame*, bool*)]

Regression window(m-c)
Works:
http://hg.mozilla.org/mozilla-central/rev/c60535115ea1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111110 Firefox/11.0a1 ID:20111110031403
Crashes:
http://hg.mozilla.org/mozilla-central/rev/9ce43912891b
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111110 Firefox/11.0a1 ID:20111110024128
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c60535115ea1&tochange=9ce43912891b


Regression window(m-i)
Works:
http://hg.mozilla.org/integration/mozilla-inbound/rev/f7ea68d2d546
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111109 Firefox/11.0a1 ID:20111109132229
Crashes:
http://hg.mozilla.org/integration/mozilla-inbound/rev/aef0684ac019
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111109 Firefox/11.0a1 ID:20111109142329
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f7ea68d2d546&tochange=aef0684ac019
Suspected: Bug 666446
Thanks!

Updated

5 years ago
Crash Signature: [@ nsLineBox::IndexOf] → [@ nsLineBox::IndexOf] [@ nsLineBox::IndexOf(nsIFrame*)] [@ nsBlockInFlowLineIterator::nsBlockInFlowLineIterator(nsBlockFrame*, nsIFrame*, bool*)]
Keywords: regressionwindow-wanted → crash, regression
OS: Linux → All
Hardware: x86_64 → All

Updated

5 years ago
Duplicate of this bug: 702998

Comment 5

5 years ago
Crashes with the nsLineBox::IndexOf(nsIFrame*) signature seem to have been around since at least 3.6.x judging from https://crash-stats.mozilla.com/report/list?signature=nsLineBox%3A%3AIndexOf%28nsIFrame*%29 but they have been rising on 11.0a1 trunk in yesterday's data.
Looks indeed like a regression from bug 666446, especially given the m-i regression range from comment 2.

The stack in comment 0's crash report has frame-destruction code calling into image code, which calls into more layout code (which possibly assumes our frames _aren't_ being destroyed, and triggers the crash as a result).

(Also: I reproduced this on the first attempt, using Nightly on Ubuntu Linux 11.10)
Blocks: 666446
(Assignee)

Updated

5 years ago
Assignee: nobody → sjohnson
(Assignee)

Comment 7

5 years ago
Created attachment 575631 [details] [diff] [review]
b702897 - Restore destruct functionality

I just restored the order of the mFrame = nsnull call in order to prevent a dangling pointer, which is causing this crash. I'm working on a crashtest, but the site's pretty complicated and I can't get it to reliably reproduce yet with a simple test case. 

Also, have an awesome birthday party, Roc!
Attachment #575631 - Flags: review?(roc)
Attachment #575631 - Flags: review?(roc) → review+

Comment 8

5 years ago
Mozilla/5.0 (X11; Linux x86_64; rv:11.0a1) Gecko/20111120 Firefox/11.0a1

I get the same Crash Signature if I visit this URL with a new, clean profile:
http://ridingpython.blogspot.com/2011/11/aws-sns-how-to-send-out-messages-to-e.html

bp-14075859-041f-4436-8075-ff9cc2111120
Yup, that looks like an instance of this bug.  Crash is within nsImageLoader::OnStopRequest, and the animation is the same, and the page source looks similar.

That site & the original URL here must be built with the same toolkit or something.

Comment 10

5 years ago
It seems the patch hasn't landed yet in m-c.

Comment 11

5 years ago
(In reply to Scoobidiver from comment #10)
> It seems the patch hasn't landed yet in m-c.

That's also why it isn't marked fixed yet.
(Assignee)

Comment 12

5 years ago
(In reply to Scoobidiver from comment #10)
> It seems the patch hasn't landed yet in m-c.

Yes, I was working on a crashtest to verify that this doesn't happen in the future, but the site's toolkit is taking too long for me to understand what's going on. So, I'll push this patch in a few minutes and write another bug to create a crashtest.
(Assignee)

Updated

5 years ago
Depends on: 704199
(Assignee)

Updated

5 years ago
No longer depends on: 704199
(Assignee)

Comment 13

5 years ago
Pushed to inbound:

https://hg.mozilla.org/integration/mozilla-inbound/rev/380444ff2108
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla11
https://hg.mozilla.org/mozilla-central/rev/380444ff2108
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.