Closed Bug 1406664 Opened 7 years ago Closed 7 years ago

Crash in nsContentUtils::FlushLayoutForTree

Categories

(Core :: Graphics: Canvas2D, defect, P3)

56 Branch
Unspecified
Windows 10
defect

Tracking

()

RESOLVED FIXED
mozilla58
Tracking Status
firefox-esr52 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- fixed

People

(Reporter: zxspectrum3579, Assigned: milan)

Details

(Whiteboard: [gfx-noted])

Crash Data

Attachments

(2 files)

This bug was filed from the Socorro interface and is 
report bp-4b865734-dce8-48ad-949f-723ab0171007.
=============================================================

WHAT WAS BEING DONE:

Clicked to show/unfold a new tweet in a Twitter tab (not TweetDeck, just regular Twitter page for an account).


WHAT HAPPENED:

1. The main non-GUI process has crashed, erasing the content of the currently opened tab with that Twitter page, as well its address bar and site's icon, showing a grey globe instead.

2. Then FireFox has started that tab process anew, and it grew a few gigabytes as it should, but the GUI was still useless -- when I tried to switch to a different tab it has also erased its content, address field and icon -- so after waiting for about ten minutes I had to kill the browser through task manager.


WHAT SHOULD HAVE HAPPENED:

1. Normal continues operation without the crash.

2. Even if a crash has happened the GUI should not die. An independent FireFox process should somehow being able not only restart the main non-GUI process, but also check if the GUI-process is able to connect with the newly restarted main tabs process, and restart it too, if necessary. So far FireFox version 56 can not do that. 

Is this ability planned for a future version of FireFox? If not, then how to request such architectural change?

It is by far not the first time when FireFox is practically unable to survive the death of its main non-GUI process and forces me to kill the browser manually. This should not happen, and yet it happens again and again with different types of crashes/signatures.
As you can see, whenever I tried to select a tab is just gets erased/cleared instead of being loaded/rendered. And the GUI is too slow during all of this time, it reacts to those clicks only after few minutes, despite I waited for a long time prior to trying to click on anything to make sure that the main tab process that was aromatically restarted fully loaded. And my attempt to close the GUI window, id est to exit the browser, has also failed, so I had to kill the browser through task manager.
Assignee: nobody → milan
Component: Graphics → Canvas: 2D
Priority: -- → P3
Whiteboard: [gfx-noted]
Comment on attachment 8917352 [details]
Bug 1406664: Wallpaper over doc shell GetChildAt returning a failure/null item.  Unclear when that would happen, but GetChildAt does have an error return, this handles it.  There are very few crashes with this signature, and this just stops the null point

https://reviewboard.mozilla.org/r/188354/#review193638

::: dom/base/nsContentUtils.cpp:6924
(Diff revision 1)
>    if (nsCOMPtr<nsIDocShell> docShell = aWindow->GetDocShell()) {
>      int32_t i = 0, i_end;
>      docShell->GetChildCount(&i_end);
>      for (; i < i_end; ++i) {
>        nsCOMPtr<nsIDocShellTreeItem> item;
> -      docShell->GetChildAt(i, getter_AddRefs(item));
> +      if (docShell->GetChildAt(i, getter_AddRefs(item)) == NS_OK && item) {

This seems fine as wallpaper but I'd prefer Catalin took a look.
Attachment #8917352 - Flags: review?(overholt)
I evidently don't know how to use MozReview. Can you ask :catalinb for a quick look there?
Flags: needinfo?(milan)
Flags: needinfo?(milan)
Attachment #8917352 - Flags: review?(catalin.badea392)
Comment on attachment 8917352 [details]
Bug 1406664: Wallpaper over doc shell GetChildAt returning a failure/null item.  Unclear when that would happen, but GetChildAt does have an error return, this handles it.  There are very few crashes with this signature, and this just stops the null point

https://reviewboard.mozilla.org/r/188354/#review194828

::: dom/base/nsContentUtils.cpp:6924
(Diff revision 1)
>    if (nsCOMPtr<nsIDocShell> docShell = aWindow->GetDocShell()) {
>      int32_t i = 0, i_end;
>      docShell->GetChildCount(&i_end);
>      for (; i < i_end; ++i) {
>        nsCOMPtr<nsIDocShellTreeItem> item;
> -      docShell->GetChildAt(i, getter_AddRefs(item));
> +      if (docShell->GetChildAt(i, getter_AddRefs(item)) == NS_OK && item) {

If the index is within bounds, why would GetChildAt fail?
Attachment #8917352 - Flags: review?(catalin.badea392) → review+
Pushed by msreckovic@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4ab57bf53b59
Wallpaper over doc shell GetChildAt returning a failure/null item.  Unclear when that would happen, but GetChildAt does have an error return, this handles it.  There are very few crashes with this signature, and this just stops the null pointer crash.  r=catalinb
https://hg.mozilla.org/mozilla-central/rev/4ab57bf53b59
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
Thank you, Sebastian.

But what about a more general question about the ability for FireFox to survive main tabs process crashes more consistently? As I mentioned before, autorestart of the main tabs process after a crash does not help in the cases like this as well as many others when you still end up having used the task manager to manually kill off FireFox processes. Maybe a fundamental solution for this is coming, but I am just unaware of it? Thanks in advance.
Flags: needinfo?(aryx.bugmail)
I am not aware of that. For issues not resolved by this bug in the next "Nightly" build available at https://www.mozilla.org/de/firefox/channel/desktop/#nightly (please try in 3 hours or later), file new bugs for them. Thank you.
Flags: needinfo?(aryx.bugmail)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: