If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

crashes on [@ IPCError-browser | ShutDownKill ]

RESOLVED INCOMPLETE

Status

()

Core
DOM: Content Processes
--
critical
RESOLVED INCOMPLETE
11 months ago
6 months ago

People

(Reporter: mlambertz, Unassigned)

Tracking

(Blocks: 1 bug, {crash, dupeme})

51 Branch
x86_64
Windows 10
crash, dupeme
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 months ago
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20161017004013

Steps to reproduce:

keep receiving error messages
Identifiant du rapport
bp-cf0df8ae-156c-4032-933c-a14932161019
bp-6fa247a6-4331-4d9e-b8b1-9392d2161019
c7bda353-3933-4327-8049-cdda950569d3
36983d3b-41b5-41e4-af86-f541c6083b82


Actual results:

after opening session, I am told that the browser had crashed during last session but I haven t notice anything


Expected results:

don t understand the crash messages because everything seems to work well
(Reporter)

Updated

11 months ago
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Hi,

We'd use a bit more information in order to try to reproduce this and see exactly what the problem is.
Could you perhaps tell me:
Do you have any extensions installed? 
Have you noticed this crash recovery after a certain activity on browser? Or after update to Aurora?
Can you please check if you have any errors in the Browser Console?

Thanks.
Flags: needinfo?(mlambertz)
Keywords: crash, crashreportid
bp-cf0df8ae-156c-4032-933c-a14932161019
 0 	xul.dll	js::CrossCompartmentWrapper::get(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>)	js/src/proxy/CrossCompartmentWrapper.cpp:205
1 	xul.dll	js::Proxy::get(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>)	js/src/proxy/Proxy.cpp:310
2 	xul.dll	js::proxy_GetProperty(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>)	js/src/proxy/Proxy.cpp:583
3 	xul.dll	GetPropertyOperation	js/src/vm/Interpreter.cpp:191
Severity: normal → critical
Crash Signature: [@ IPCError-browser | ShutDownKill ]
Keywords: crashreportid

Updated

11 months ago
Component: Untriaged → IPC
Product: Firefox → Core
Summary: bp-cf0df8ae-156c-4032-933c-a14932161019 → crashes on [@ IPCError-browser | ShutDownKill ]

Comment 3

11 months ago
mconley, do we have instructions for profiling this, for people who see it consistently?
Component: IPC → DOM: Content Processes
Flags: needinfo?(mconley)
(In reply to Benjamin Smedberg [:bsmedberg] from comment #3)
> mconley, do we have instructions for profiling this, for people who see it
> consistently?

Hm, not really no. If we're in the midst of profiling, the content process knows to send a message up to the parent on exit with the final profile, but if the parent is intentionally killing the content process (as appears to be the case here), then the parent will never receive that profile.

As it stands, the two crash reports that are in comment 0 are all over the place when I put them in the multiple-minidump viewer (http://bsmedberg.github.io/socorro-toolbox/html/multiple-minidumps.html). For example:

http://bsmedberg.github.io/socorro-toolbox/html/multiple-minidumps.html?crashID=cf0df8ae-156c-4032-933c-a14932161019
^-- Here, the content process is busy sending an nsIObserver notification around, presumably to tell everybody that we're shutting down. Some JS is running, and we run out of time, and crash.

http://bsmedberg.github.io/socorro-toolbox/html/multiple-minidumps.html?crashID=6fa247a6-4331-4d9e-b8b1-9392d2161019
^-- Here, the content process is blocked waiting on a response to a sync message to the parent requesting screen dimensions (bug 1194751). As before, we run out of time and kill the content process.

I think these crash reports are currently our only tool for diagnosing what's going wrong here, and what's going wrong is that we're exceeding the content process shutdown timeout. I believe the way forward here is collecting these ShutdownKill crash reports, prioritizing them based on stacks, working our way down them trying to make shutdown quicker.

Anything else I miss here, jimm? I think you had some folks looking at ShutdownKill - was there anything else to add?
Flags: needinfo?(mconley) → needinfo?(jmathies)

Comment 5

10 months ago
(In reply to Mike Conley (:mconley) from comment #4)
> Anything else I miss here, jimm? I think you had some folks looking at
> ShutdownKill - was there anything else to add?

Don't think so, these reports tend to be all over the place since we catch the content process in random places on slow shutdown. We might find some signatures here that appear to be more common, which would be worth looking into. I believe KanRu's Taipei team was planning on looking into shutdown kill at some point. Not sure where that sits priority wise currently.
Flags: needinfo?(mlambertz)
Flags: needinfo?(jmathies)
I'm still looking at the shutdown kill issues but at a lower priority. I believe a some of the shutdown kills are contributed by short lived content processes. See bug 1293284.
Comment hidden (spam)
Dupe of https://bugzilla.mozilla.org/show_bug.cgi?id=1279293 ?
Keywords: dupeme
Comment hidden (spam)

Comment 10

9 months ago
In my case, the crash happens after the laptop goes into BSOD due to some Kernel issue. I remember an error similar to "VIDEO_DXG_KERNEL". The BSOD collects the dump and reboots the PC. Then I open FX and it restores the last session. Then it asks if I want to send a crash report. 

https://crash-stats.mozilla.com/report/index/1b507864-3776-43a2-b244-459442161214
https://crash-stats.mozilla.com/report/index/67824354-e80d-4c6b-a27e-9f3d02161207
https://crash-stats.mozilla.com/report/index/a32a7725-d5e0-41a5-a8e5-69c8d2161211

Intel i7-2670qm
NVIDIA 540M
Crucial C300 SSD
Windows 10.
Everything up to date.

I believe disabling the NVIDIA card from Device Manager is the reason why it hasn't crashed again. Today's crash took place while NVIDIA was enabled. Will need more time to figure this out.

Comment 11

9 months ago
In my clase when I simply close firefox.
Comment hidden (spam)
Comment hidden (spam)
Blocks: 1219672
Status: UNCONFIRMED → RESOLVED
Crash Signature: [@ IPCError-browser | ShutDownKill ]
Last Resolved: 6 months ago
Resolution: --- → INCOMPLETE

Comment 14

6 months ago
how resolved??
the crash is still here!!
Why did you close this bug? (Same for bug 1331929)
Flags: needinfo?(Virtual)
There is no need to create many duplicate bugs about the same issue, as they pollute related bugs in crashlog reports, making hard to speedy find anything in all that useless spam.

About this bug, I marked as INCOMPLETE, per no STR from OP.

Reproducible bugs are tracked in blocked bug #1219672.


tl;dr - I'm cleaning.
Flags: needinfo?(Virtual)
(In reply to Virtual_ManPL [:Virtual] - (ni? me) from comment #16)
> About this bug, I marked as INCOMPLETE, per no STR from OP.

In the future, please leave a comment in the bug when you do things like this explaining why you're doing it. I have often seen you make incorrect changes without any explanation that I then have to revert. While I appreciate the overall effect of "cleaning" does help us be more efficient, keep in mind that these bugs are often filed by people new to bugzilla and mozilla's workflow, so you need to be sensitive to their needs as well and be more verbose about why you're doing things, specially closing bugs.

(ni to make sure you read this, no response needed).
Flags: needinfo?(Virtual)
Comment hidden (spam)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #17)
> In the future, please leave a comment in the bug when you do things like
> this explaining why you're doing it.
> [...]
> While I appreciate the overall effect of "cleaning" does help us be more efficient,
> keep in mind that these bugs are often filed by people new to bugzilla and
> mozilla's workflow, so you need to be sensitive to their needs as well and
> be more verbose about why you're doing things, specially closing bugs.
> 
> (ni to make sure you read this, no response needed).

OK, I will keep in mind your advice and I will use it in the future, that there will be the best to explain myself after changes, but I didn't want to spam everyone bugmail.


(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #17)
> I have often seen you make incorrect changes
> without any explanation that I then have to revert.

This is kinda exaggeration in my view, because I'm not "often" make incorrect changes that you will need to revert. ;P
Flags: needinfo?(Virtual)
Maybe a little exaggeration, yeah. I don't see all the changes you make across all of Bugzilla so I probably have a biased view of your correct-to-incorrect ratio :) Anyway, thanks for being responsive to concerns!
Comment hidden (spam)
(In reply to Virtual_ManPL [:Virtual] - (ni? me) from comment #19)
> but I didn't want to spam everyone bugmail.
and for example this is what I meant ;) - see bug #1219672 comment #56
Comment hidden (offtopic)
Comment hidden (offtopic)
Comment hidden (offtopic)
Comment hidden (offtopic)
You need to log in before you can comment on or make changes to this bug.