Closed Bug 1233873 Opened 10 years ago Closed 10 years ago

crash in nsHTMLDocument::MozExitPointerLock

Categories

(Core :: DOM: Core & HTML, defect)

x86
Windows NT
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox46 + ---

People

(Reporter: dbaron, Unassigned)

Details

(Keywords: crash, regression, topcrash)

Crash Data

This bug was filed from the Socorro interface and is report bp-04b19000-b71b-4497-8389-83ac92151218. ============================================================= A new topcrash has appeared starting in today's nightly. It doesn't seem to have appeared on any channels other than nightly, so it looks like a code regression. A query for all of the crashes on the nightly channel is: https://crash-stats.mozilla.com/signature/?product=Firefox&release_channel=nightly&date=%3E2015-08-01&signature=nsHTMLDocument%3A%3AMozExitPointerLock&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&page=1 That said, the regression range between the last nightly in which the crash wasn't present and the first in which it was present is: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0711218a018d&tochange=66fb852962c0 which makes me rather suspicious. So it's not clear to me what's going on here. The crash might be a small-ish number of users, but it's clearly at least 3 separate users hitting it.
hg.mozilla.org is timing out here when trying to show the annotation to nsDocument.cpp, so hard to analyze those stack traces :/
[Tracking Requested - why for this release]: new topcrash
The crash stack looks weird. nsHTMLDocument::MozExitPointerLock() seems to be a simple redirector which shouldn't crash itself, but there is no further stack info presents... nsHTMLDocument::MozExitPointerLock then nsDocument::MozExitPointerLock then nsIDocument::MozExitPointerLock, are all simple redirector which may be inlined by the compiler, and the real stuff happens in nsDocument::UnlockPointer(). But there doesn't seem to be any recent change to this function.
Tracking for 43, though this doesn't seem to be a topcrash (not in the top 50 crash signatures for 46.0a1).
It hasn't shown up in any builds other than 20151218030232.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Version: unspecified → Trunk
You need to log in before you can comment on or make changes to this bug.