Closed Bug 454872 Opened 11 years ago Closed 10 years ago

Crashes while scrolling [@ nsScrollPortView::IncrementalScroll()]

Categories

(Core :: Web Painting, defect, P2, critical)

defect

Tracking

()

VERIFIED FIXED
Tracking Status
status1.9.2 --- beta1-fixed
blocking1.9.1 --- .4+
status1.9.1 --- .4-fixed

People

(Reporter: db94127, Assigned: mats, NeedInfo)

References

Details

(Keywords: crash, fixed1.9.0.15, verified1.9.1, Whiteboard: [sg:critical?])

Crash Data

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1

Yesterday set preferences to "Use smooth scrolling" (unchecked "Use Autoscrolling). Today multiple crashes while attempting to scroll. Seems much worse when attempting to scroll while page is loading/reloading, but sometimes happens even when page is loaded.

Reset to "Use Autoscrolling"; now seems stable again.

Reproducible: Sometimes

Steps to Reproduce:
1.See above.
2.
3.
Actual Results:  
See above.


If I can help with any testing or provide additional info, please advise.
Daniel: I am not able to reproduce this using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1 or with the 3.0.2 candidate.

Which particular site were you scrolling? Can you type about:crashes and provide a crash URL?
I was not able to reproduce on a PPC machine either using 3.0.1.
Hi Marcia-

Yes, I was able to reproduce the problem by (as before) changing the Firefox scrolling preferences to "Use smooth scrolling" and unchecking "Use
Autoscrolling". Again, the problem seems to be associated with attempting to scroll while a page is loading or reloading.

The URL that I tested this time was: http://www.newsweek.com/id/158429?from=rss

The URL info after "www.newsweek.com/" is specific to a particular Newsweek article... The previous crashes occurred at the same Newsweek URL but with different specific articles.

To obtain more of a sampling, I also just tried a Washington Post newsarticle: 
http://www.washingtonpost.com/wp-dyn/content/article/2008/09/07/AR2008090702262.html?nav=rss_world

and I was able to crash at that site also.

Finally, I tried the same thing while reloading https://bugzilla.mozilla.org/show_bug.cgi?id=454872, but was not able to crash the browser.
Daniel, please submit the crash data and then give us its ID.  You can see
the IDs if you enter about:crashes in the url bar.  See:
http://support.mozilla.com/en-US/kb/Mozilla+Crash+Reporter#Viewing_crash_reports
OK, here are the last three, they all seem to be essentially identical:

75504d80-805f-11dd-88a4-0013211cbf8a

Signature	nsScrollPortView::IncrementalScroll()
UUID	75504d80-805f-11dd-88a4-0013211cbf8a
Time	2008-09-11 17:12:01-07
Uptime	765
Product	Firefox
Version	3.0.1
Build ID	2008070206
OS	Mac OS X
OS Version	10.4.10 8R218
CPU	ppc
CPU Info	
Crash Reason	EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE
Crash Address	0x2d477df8
Comments	



9e6ff26b-805d-11dd-8d41-001a4bd43ef6

Signature	nsScrollPortView::IncrementalScroll()
UUID	9e6ff26b-805d-11dd-8d41-001a4bd43ef6
Time	2008-09-11 16:58:52-07
Uptime	53
Product	Firefox
Version	3.0.1
Build ID	2008070206
OS	Mac OS X
OS Version	10.4.10 8R218
CPU	ppc
CPU Info	
Crash Reason	EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE
Crash Address	0x2d477df8
Comments	



e28da64c-8033-11dd-802e-001321b13766

Signature	nsScrollPortView::IncrementalScroll()
UUID	e28da64c-8033-11dd-802e-001321b13766
Time	2008-09-11 12:00:10-07
Uptime	1048
Product	Firefox
Version	3.0.1
Build ID	2008070206
OS	Mac OS X
OS Version	10.4.10 8R218
CPU	ppc
CPU Info	
Crash Reason	EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE
Crash Address	0x2d477df8
Comments
Thanks for trying to figure this out!

db
For what it may be worth, here are all of the similar reports that I was able to find:

263609 (Windows)

385100 (Windows)

433365 (Mac)
Possibly fixed in Firefox 3.0.2 by bug 435422.  You can try with the
release candidates here (which includes the fix):
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.0.2-candidates/
or you can wait until it's officially released (currently planned for
Tuesday 16th but it might be later).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
Summary: Crashes while scrolling → Crashes while scrolling [@ nsScrollPortView::IncrementalScroll()]
Thanks for the info.  Since it doesn't crash unless I change the scrolling preferences it's not a big deal. I think that I'll wait for the official rollout.
FYI, Firefox 3.0.2 is available now.
Mats- thanks a lot for keeping on top of this. I'll let you know how things work out after I download 3.0.2
Looks like you folks have nailed it. 3.0.2 seems to work just fine as far as the scrolling preferences are concerned.

Thanks to all.
Ok, good to hear it's working for you.  I'll leave the bug open for now
since I can't query crash statistics at the moment (bug 444749) and
I want to verify it's really gone in 3.0.2.
Assignee: nobody → mats.palmgren
Depends on: 444749
There are still some crash reports for 3.0.2 and 3.0.3 I'm afraid.
No longer depends on: 444749
Depends on: 465360
There were 72 crashes in the last week at nsScrollPortView::IncrementalScroll.  All OSes are represented, but Mac is especially heavy.  Both active releases of Firefox, 3.0.x and 3.5.x, are represented.

http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=startswith&query=nsScrollPortView%3A%3AIncrementalScroll%28%29&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsScrollPortView%3A%3AIncrementalScroll%28%29
Looking at the code I'm guessing the nsScrollPortView is dead by the time
we execute line 726:
http://hg.mozilla.org/releases/mozilla-1.9.1/annotate/345e7a83db64/view/src/nsScrollPortView.cpp#l726
Assuming nsScrollPortView::ScrollToImpl() can execute arbitrary stuff like
deleting the 'this' nsScrollPortView we're currently using.
OS: Mac OS X → All
Hardware: PowerPC → All
Whiteboard: [sg:critical?]
Group: core-security
Attached patch Patch rev. 1Splinter Review
Should fix it if my assumption is right.
Attachment #395330 - Flags: review?(mstange)
nsScrollPortView::ScrollToImpl calls
  nsScrollPortView::Scroll calls
    nearestWidget->Scroll

There's an analysis of widget methods that reach nsChildView::DispatchEvent
(which executes arbitrary stuff) in bug 402505.
nsChildView::Scroll is in that list.  Seems like a good idea to audit
nsScrollPortView for calls reaching anything on that list.
... although the list could be out-dated by now of course ...
The patch looks good to me, but I'm not a peer of this code.
Sorry, I assumed you were...
Attachment #395330 - Flags: review?(mstange) → review?(roc)
http://hg.mozilla.org/mozilla-central/rev/15c3a72d8aac
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: wanted-firefox3.5?
Flags: blocking1.9.0.14?
Flags: blocking-firefox3.6?
Resolution: --- → FIXED
Attachment #395330 - Flags: approval1.9.2?
Pushing out Mats' request to 1.9.0.15 since we're basically code frozen for 1.9.0.14.
blocking1.9.1: --- → ?
Flags: blocking1.9.0.14? → blocking1.9.0.15?
Component: General → Layout: View Rendering
Flags: wanted-firefox3.5?
Flags: blocking-firefox3.6?
Product: Firefox → Core
QA Contact: general → layout.view-rendering
Flags: blocking1.9.2?
blocking1.9.1: ? → .4+
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.15?
Flags: blocking1.9.0.15+
Keywords: testcase-wanted
Mats: When this lands on 1.9.2, please request approval1.9.0.15 and approval1.9.1.4 on it (or if it doesn't apply, please attach a patch that does).
ok
Attached patch for 1.9.0Splinter Review
Attachment #395330 - Flags: approval1.9.2? → approval1.9.2+
Attachment #395330 - Flags: approval1.9.1.4?
Attachment #396338 - Flags: approval1.9.0.15?
Comment on attachment 395330 [details] [diff] [review]
Patch rev. 1

As a security bug, per our new policy, this patch needs explicit superview from a second person. It should *not* have landed on trunk or 1.9.2 without that superview. Please be mindful of that in the future.

http://www.mozilla.org/hacking/reviewers.html

Tagging dbaron for superview.
Attachment #395330 - Flags: superreview?(dbaron)
Whiteboard: [sg:critical?] → [sg:critical?][needs sr=dbaron]
That's a bad policy, as I've said before.
There are many bad policies, but it *is* a policy and we'll keep enforcing it until it's no longer a policy.
(In reply to comment #28)
Sorry I missed that!
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P2
Comment on attachment 395330 [details] [diff] [review]
Patch rev. 1

sr=dveditz
Attachment #395330 - Flags: superreview?(dbaron) → superreview+
Whiteboard: [sg:critical?][needs sr=dbaron] → [sg:critical?]
Comment on attachment 395330 [details] [diff] [review]
Patch rev. 1

Approved for 1.9.1.4. a=ss for release-drivers
Attachment #395330 - Flags: approval1.9.1.4? → approval1.9.1.4+
Attachment #396338 - Flags: approval1.9.0.15? → approval1.9.0.15+
Comment on attachment 396338 [details] [diff] [review]
for 1.9.0

Approved for 1.9.0.15. a=ss for release-drivers
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b3536c557f1e

On CVS HEAD:
mozilla/view/src/nsScrollPortView.cpp 	3.91
I can't reproduce this issue with Firefox 3.5.3 on OS X 10.6.
I can't reproduce this issues with Firefox 3.0.14 on OS X 10.6 either.
verified with: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20090930 Minefield/3.7a1pre and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20091001 Shiretoko/3.5.4pre
Status: RESOLVED → VERIFIED
Keywords: verified1.9.1
Group: core-security
Crash Signature: [@ nsScrollPortView::IncrementalScroll()]
Thanks for sharing this information.
http://tattoosboygirl.com/viking-tattoos/
Flags: needinfo?(tbg137)
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.