1411228 - Crash in nsWebBrowser::GetDocument

Status: RESOLVED WORKSFORME

(Core :: Layout: Images, Video, and HTML Frames, defect, P3)

Description

[Calixte Denizet (:calixte)]

This bug was filed from the Socorro interface and is 
report bp-57d15232-356c-41c2-b30a-75cfd0171024.
=============================================================

There are 6 crashes in nightly 58 with buildid 20171023220222. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1409992.

[1] https://hg.mozilla.org/mozilla-central/rev?node=ce667ebd9b125a197a7452fd000ae3419b25c6d0

Comment 1

[Mike Taylor [:miketaylr]]

Maybe meaningful or not, but there are no reports in the past week using a build later than 20171023220222.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

So there appear to be two issues here.  One was a temporary crash on the NS_ENSURE_TRUE() call (which might or might not be a UAF/wildptr), which only appeared in one nightly and not since.

The other is a very-low-volume UAF/wildptr crash going back to at least 54, which in the crash I looked at happened on the line after the ENSURE.  Refocusing this on the long-term crash.

NI jet for triage

Comment 3

[Jet Villegas (inactive)]

(In reply to Calixte Denizet (:calixte) from comment #0)
> This bug was filed from the Socorro interface and is 
> report bp-57d15232-356c-41c2-b30a-75cfd0171024.
> =============================================================
> 
> There are 6 crashes in nightly 58 with buildid 20171023220222. In analyzing
> the backtrace, the regression may have been introduced by patch [1] to fix
> bug 1409992.
> 
> [1]
> https://hg.mozilla.org/mozilla-central/
> rev?node=ce667ebd9b125a197a7452fd000ae3419b25c6d0

Examining the patches for bug 1409992 don't indicate this. The spike from build 20171023220222 don't show any SVG in the stacks. I'll leave this in Layout:Images for now in case we get more reports with the same stacks.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

jet - at least want you to look at the older crashes here

Comment 5

[Jet Villegas (inactive)]

I had a look at the crashes for [@ nsWebBrowser::GetDocument ] and see a small spike around the time bug 1404181 landed. Those crashes disappeared after that, and I suspect they were fixed very quickly by subsequent Retained Display List fixes. Matt: can you confirm?

I don't think the other signatures are the same crash, and I don't see recent instances:
[@ nsCOMPtr_base::~nsCOMPtr_base | mozilla::dom::TabChildBase::GetDocument ]
[@ [thunk]:nsHTMLDocument::Release`adjustor{920}'' ]

Comment 6

[Matt Woodrow (:mattwoodrow)]

Seems unlikely to be retained-dl related, too far away from painting code.

I think it got fixed in this range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9056f2ee492fa481aa86146aba236c074628e9fd&tochange=a124f4901430f6db74cfc7fe3b07957a1c691b40

Bug 1407498 seems most likely to be what fixed it, since it changed code in nsImageLoadingContent::LoadImage, which is on the callstack.

The long standing crash is super low volume, doubt we're in a rush to do anything more here.

Comment 7

[Daniel Veditz [:dveditz]]

This was filed on the spike in 58.0a1, which has gone away.