1491540 - Crash in IPCError-browser | ShutDownKill

Status: RESOLVED DUPLICATE of bug 1279293

(Core :: Layout, defect, P4)

Description

[Worcester12345]

This bug was filed from the Socorro interface and is
report bp-80cdfe65-496b-4ae0-9085-73b0b0180915.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll nsFrame::DidSetComputedStyle layout/generic/nsFrame.cpp:1114
1 xul.dll bool mozilla::RestyleManager::ProcessPostTraversal layout/base/RestyleManager.cpp:2838
2 xul.dll bool mozilla::RestyleManager::ProcessPostTraversal layout/base/RestyleManager.cpp:2833
3 xul.dll bool mozilla::RestyleManager::ProcessPostTraversal layout/base/RestyleManager.cpp:2833
4 xul.dll bool mozilla::RestyleManager::ProcessPostTraversal layout/base/RestyleManager.cpp:2833
5 xul.dll bool mozilla::RestyleManager::ProcessPostTraversal layout/base/RestyleManager.cpp:2833
6 xul.dll bool mozilla::RestyleManager::ProcessPostTraversal layout/base/RestyleManager.cpp:2833
7 xul.dll bool mozilla::RestyleManager::ProcessPostTraversal layout/base/RestyleManager.cpp:2833
8 xul.dll bool mozilla::RestyleManager::ProcessPostTraversal layout/base/RestyleManager.cpp:2833
9 xul.dll bool mozilla::RestyleManager::ProcessPostTraversal layout/base/RestyleManager.cpp:2833

=============================================================

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Is this reproducible? If so, how? Thanks!

Comment 2

[Wayne Mery (:wsmwk)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)
> Is this reproducible? If so, how? Thanks!

Reporter seems to be tongue tied, so perhaps https://mzl.la/2OWoOHs helps answer your question - 25 crash reports in 60 days.

Comment 3

[Wayne Mery (:wsmwk)]

philipp is familiar with several of them

Comment 4

[Worcester12345]

Not tongue tied, but thanks anyhow. Just don't spend every waking hour doing this stuff. I help out when I can. It does this on more than one computer also. All are Windows 7, most are 64 bit.

Comment 6

[[:philipp]]

@Worcester12345 the crash signature [@ IPCError-browser | ShutDownKill] is an artificial signature that was introduced with the multi-process architecture in firefox. web content of different tabs is running in different processes on your system. when you close a tab, and its corresponding process is still keeping on running 5sec after that, it will be force closed and such a crash report is triggered. in the utmost of cases normal users won't even notice that this is happening since there is no UI informing them of this problem, that's why those "crashes" have a rather low priority - we only automatically submit these reports on nightly anyway.

so why would the web content process still run 5 seconds after you've closed a corresponding tab? this might be due to several factors like the general hardware specs, state of health of your system and external software on the system (security software and other invasive tools) that might slow things down which are outside the control of firefox.
that's why filing these reports without providing any context about the circumstances they are happening in or perhaps even better reproducible steps isn't the most productive use of your time.

Comment 7

[Worcester12345]

In that case, maybe Firefox should stop flagging these as crashes. I don't know what the cause was until after the bug is submitted, and by then, it is about a second to tick off 2 items to log it.

Comment 8

[Wayne Mery (:wsmwk)]

(In reply to Worcester12345 from comment #7)
> In that case, maybe Firefox should stop flagging these as crashes. I don't
> know what the cause was until after the bug is submitted, and by then, it is
> about a second to tick off 2 items to log it.

I think he is saying if you cannot reliably reproduce with a set of specific steps that *always* cause a crash, then don't file a bug.

When a bug is not reproducible and actionable then not it's not just a waste of your time to file it, it's a waste of time for those who are triaging bugs.  You even filed 4-5 more crash bugs after philipp's comment.

One approach you might take is to wait for one of your earlier crash reports with the same crash signature to be fixed or closed with some conclusion, before filing any more new ones.

Comment 9

[Sean Voisen (:svoisen)]

Doesn't sound like this bug is actionable, but I'll leave it open for now in case we get more information in future reports.