1631328 - Crash in [@ IPCError-browser | ShutDownKill | nsFrame::DestroyFrom]

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P3)

Description

[Gabriele Svelto [:gsvelto] (PTO)]

This bug is for crash report bp-bcb572f9-6304-453f-b34e-5454d0200419.

Top 10 frames of crashing thread:

0 xul.dll nsFrame::DestroyFrom layout/generic/nsFrame.cpp:881
1 xul.dll static nsLineBox::DeleteLineList layout/generic/nsLineBox.cpp:387
2 xul.dll nsBlockFrame::DestroyFrom layout/generic/nsBlockFrame.cpp:442
3 xul.dll static nsLineBox::DeleteLineList layout/generic/nsLineBox.cpp:387
4 xul.dll nsBlockFrame::DestroyFrom layout/generic/nsBlockFrame.cpp:442
5 xul.dll nsBlockFrame::DestroyFrom layout/generic/nsBlockFrame.cpp:439
6 xul.dll static nsLineBox::DeleteLineList layout/generic/nsLineBox.cpp:387
7 xul.dll nsBlockFrame::DestroyFrom layout/generic/nsBlockFrame.cpp:442
8 xul.dll static nsLineBox::DeleteLineList layout/generic/nsLineBox.cpp:387
9 xul.dll nsBlockFrame::DestroyFrom layout/generic/nsBlockFrame.cpp:442

These content processes have received a DestroyBrowser IPC message which was followed by a Shutdown one. None of them have the IPCShutdownState annotation state which means they didn't get to act on the shutdown message yet. Many but not all of the reports seem to be stuck here. I wonder if this is just this operation being very slow and preventing the content process from proceeding with shutdown.

Comment 1

[Mats Palmgren (inactive)]

Interestingly, this signature almost exclusively occur in Nightly builds and not on other channels:

72.0a1	192	21.3%
73.0a1	177	19.6%
74.0a1	173	19.2%
76.0a1	140	15.5%
75.0a1	128	14.2%
77.0a1	57	6.3%
71.0a1	15	1.7%
70.0a1	7	0.8%
68.0a1	4	0.4%
65.0a1	3	0.3%
64.0a1	2	0.2%
69.0a1	2	0.2%
59.0	1	0.1%
61.0	1	0.1%
61.0a1	1	0.1%

Comment 2

[Mats Palmgren (inactive)]

I wonder if deleting a large number of frames is slow because of the associated RecordFree churn. Hashtables tends to be slow...

In any case, I feel that we can probably remove the RecordAlloc/RecordFree stuff now that style data isn't allocated in the shell arena any more. I don't think it adds much value over the checks we already have that all objects are deleted in the arena when the pres shell is destroyed + the checks we get from ASAN builds. Thoughts?

Comment 3

[Emilio Cobos Álvarez (:emilio)]

It may be worth to make those DEBUG only, or maybe remove them entirely, yeah... At the very least RecordFree can trivially reduce the number of hash table operations by half, it's doing two lookups where it can just use one :)

Comment 4

[Mats Palmgren (inactive)]

I tend to think we should just remove them tbh. The cost doesn't really motivate the little value they have. DEBUG builds are already so slow that I personally have stopped using them for most development work, fwiw.

Comment 5

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Mats Palmgren (:mats) from comment #1)

Interestingly, this signature almost exclusively occur in Nightly builds and not on other channels:

ShutDownKill reports are only enabled on nightly to detect content processes that are taking too long to shut down (or are stuck).

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:dholbert, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.