Closed Bug 1175975 Opened 9 years ago Closed 9 years ago

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

Categories

(Core :: XPCOM, defect)

41 Branch
All
Windows NT
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla41
Tracking Status
firefox41 - fixed

People

(Reporter: tracy, Assigned: billm)

Details

(Keywords: crash, topcrash-win)

Crash Data

Attachments

(1 file)

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)
Attached patch patchSplinter Review
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 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
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
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.
(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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: