Closed Bug 1175975 Opened 7 years ago Closed 7 years ago
crash in mozilla::Base
Auto Lock<T>::Base Auto Lock<T>(mozilla::Mutex&)
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?
This is the e10s hang monitor, which I *think* is billm.
Flags: needinfo?(aklotz) → needinfo?(wmccloskey)
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
Attachment #8624444 - Flags: review?(jmathies)
Comment on attachment 8624444 [details] [diff] [review] patch Nice, thanks.
Attachment #8624444 - Flags: review?(jmathies) → review+
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?
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. :)
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.