Closed Bug 1311297 Opened 8 years ago Closed 7 years ago

crashes on [@ IPCError-browser | ShutDownKill ]

Categories

(Core :: DOM: Content Processes, defect)

Product:
Core
Component:
DOM: Content Processes
Version:
51 Branch
Platform:
x86_64
Windows 10
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: mlambertz, Unassigned)

References

Details

(Keywords: crash, dupeme) 

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
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
Component: Untriaged → IPC
Product: Firefox → Core
Summary: bp-cf0df8ae-156c-4032-933c-a14932161019 → crashes on [@ IPCError-browser | ShutDownKill ]
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)
(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.
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.
In my clase when I simply close firefox.
Blocks: shutdownkill
Status: UNCONFIRMED → RESOLVED
Crash Signature: [@ IPCError-browser | ShutDownKill ]
Closed: 7 years ago
Resolution: --- → INCOMPLETE
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)
(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!
(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
You need to log in before you can comment on or make changes to this bug.