crash in mozilla::BaseAutoLock<T>::BaseAutoLock<T>(mozilla::Mutex&)

RESOLVED FIXED in Firefox 41

Status

()

Core
XPCOM
--
critical
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: tracy, Assigned: billm)

Tracking

({crash, topcrash-win})

41 Branch
mozilla41
All
Windows NT
crash, topcrash-win
Points:
---

Firefox Tracking Flags

(firefox41- fixed)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
This bug was filed from the Socorro interface and is 
report bp-b3272b1c-053d-4388-b02c-b68f42150617.
=============================================================

https://crash-stats.mozilla.com/report/list?product=Firefox&range_value=7&range_unit=days&date=2015-06-18&signature=mozilla%3A%3ABaseAutoLock%3CT%3E%3A%3ABaseAutoLock%3CT%3E%28mozilla%3A%3AMutex%26%29&version=Firefox%3A41.0a1#tab-sigsummary

[Tracking Requested - why for this release]:

This appears to have regressed with builds of 2015061203. It is currently #8 on the Nightly topcrash list with 67 crashes in the past 5 days.

100% amd64
Looks like this is coming from ProcessHangMonitor.cpp, trying to clean up plugin hangs.  Aaron, is this in your area?
Flags: needinfo?(aklotz)
This is the e10s hang monitor, which I *think* is billm.
Flags: needinfo?(aklotz) → needinfo?(wmccloskey)
Created attachment 8624444 [details] [diff] [review]
patch

This regressed with bug 1160142. If the content process shuts down, we call Clear on the nsIHangReport, which nulls out mActor. Therefore we need to null check whenever we use mActor.

I also added some code to delete any unused minidumps in the HangMonitorParent destructor. By that time the content process is dead and so we don't have any way of using those browser minidumps. This way we won't leak minidumps if the content process exits without the user reacting to the hang UI.

Also, I simplified some parameter passing.
Assignee: nobody → wmccloskey
Status: NEW → ASSIGNED
Flags: needinfo?(wmccloskey)
Attachment #8624444 - Flags: review?(jmathies)

Comment 4

3 years ago
Comment on attachment 8624444 [details] [diff] [review]
patch

Nice, thanks.
Attachment #8624444 - Flags: review?(jmathies) → review+
https://hg.mozilla.org/mozilla-central/rev/06bac3891a82
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox41: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41

Comment 7

3 years ago
KaiRo: I looked at the crash-stats page and we still seem to be hitting this crash on 41.0a1. Does that mean this patch didn't fix all the scenarios where users run into it? Do we need to re-open it?
Flags: needinfo?(kairo)
I don't see any crashes with a build ID after 6/22.

Comment 9

3 years ago
(In reply to Ritu Kothari (:ritu) from comment #7)
> KaiRo: I looked at the crash-stats page and we still seem to be hitting this
> crash on 41.0a1.

41.0a1 is not current any more, those are people using old Nightly builds. 42.0a2 and 41.0a2 are not showing the crash at all, so all looks good even before looking into build IDs, which Bill has done and confirms we're fine. :)
Flags: needinfo?(kairo)
Based on KaiRo's reply, I do not see a reason to track this bug for FF41 given that it was resolved fixed 2-ish weeks back.
tracking-firefox41: ? → -
You need to log in before you can comment on or make changes to this bug.