Closed Bug 1411228 Opened 2 years ago Closed 2 years ago

Crash in nsWebBrowser::GetDocument

Categories

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

58 Branch
Unspecified
Windows 10
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox-esr52 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- wontfix

People

(Reporter: calixte, Unassigned)

References

(Blocks 1 open bug)

Details

(4 keywords, Whiteboard: [clouseau])

Crash Data

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
Flags: needinfo?(cam)
Crash Signature: [@ nsWebBrowser::GetDocument] → [@ nsWebBrowser::GetDocument] [@ nsCOMPtr_base::~nsCOMPtr_base | mozilla::dom::TabChildBase::GetDocument]
Crash Signature: [@ nsWebBrowser::GetDocument] [@ nsCOMPtr_base::~nsCOMPtr_base | mozilla::dom::TabChildBase::GetDocument] → [@ nsWebBrowser::GetDocument] [@ nsCOMPtr_base::~nsCOMPtr_base | mozilla::dom::TabChildBase::GetDocument] [@ [thunk]:nsHTMLDocument::Release`adjustor{920}'' ]
Maybe meaningful or not, but there are no reports in the past week using a build later than 20171023220222.
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
(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.
Component: SVG → Layout: Images
Flags: needinfo?(cam)
Flags: needinfo?(bugs)
Priority: -- → P3
Group: core-security → layout-core-security
jet - at least want you to look at the older crashes here
Flags: needinfo?(bugs)
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}'' ]
Flags: needinfo?(bugs) → needinfo?(matt.woodrow)
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.
Flags: needinfo?(matt.woodrow)
This was filed on the spike in 58.0a1, which has gone away.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
Product: Core Graveyard → Core
Group: layout-core-security
You need to log in before you can comment on or make changes to this bug.