1579431 - Crash in [@ __cxa_rethrow]

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P1)

Description

[[:philipp]]

This bug is for crash report bp-8c5d1af3-8c17-4d33-b624-c11b50190906.

Top 10 frames of crashing thread:

0 XUL CrashReporter::TerminateHandler toolkit/crashreporter/nsExceptionHandler.cpp:1457
1 libc++abi.dylib std::__terminate 
2 libc++abi.dylib __cxa_rethrow 
3 libobjc.A.dylib _objc_rootTryRetain 
4 AppKit -[NSView _sendViewWillDrawAndRecurse:] 
5 AppKit -[NSView _layoutSublayersOfLayer:] 
6 QuartzCore -[CALayer layoutSublayers] 
7 AppKit _NSBackingLayerLayoutSublayers 
8 QuartzCore CA::Layer::layout_if_needed 
9 QuartzCore CA::Layer::layout_and_display_if_needed 

this macos content crash signature is showing up in greater volume in the 70 cycle, on 70.0b so far it's mostly affecting users of devedition and not the regular beta builds though.

could this be related to the work in bug 1491442?

Comment 1

[Markus Stange [:mstange]]

Yes, definitely related to CoreAnimation. In all of these crashes there is file picker code running on the main thread.

It's possible that we could reproduce the crash, just by opening and closing the file picker on 10.13 a lot.

As a workaround, we could try suspending "async CATransactions" (i.e. non-main-thread CATransactions) while the file picker is open.

Comment 2

[Liz Henry (:lizzard) (relman/hg->git project)]

Jessie can you help find someone to investigate this for 70? If we wait for Markus to come back it will likely be too late to fix in 70 before we ship.

Comment 3

[Jessie [:jbonisteel] pls NI]

Matt, do you have any suggestions for this?

Comment 4

[Jessie [:jbonisteel] pls NI]

Stephen, do you have any suggestions?

Comment 5

[Stephen A Pohl [:spohl]]

I don't have a 10.13 system readily available anymore. Maybe SoftVision does and can try to reproduce the bug?

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

Andrei, can you help find someone to give this a shot? Anyone with 10.13 installed? Thanks!

Comment 7

[Andrei Vaida [:avaida]]

(In reply to Liz Henry (:lizzard) from comment #6)

Andrei, can you help find someone to give this a shot? Anyone with 10.13 installed? Thanks!

Of course! Cristian will take a look and follow up with his findings.

Comment 8

[Cristian Baica [:cbaica], Release Desktop QA]

I have tried multiple scenarios without any success in re-creating the crash. I've used every scenario on multiple versions of devEdition (70.0b1, 70.0b2, 70.0b4, 70.0b6).
As suggested in comment 1, I've tried multiple scenarios involving the file picker functionality of firefox. Here are a couple of things that have been tested:

• the repeated open/close of file picker using the keyboard shortcut commands - cmd+o (while in a newtab, while videos are played on the existing tab)
• the repeated open/close of file picker from the hamburger menu
• the loading of different files(image, html, mp4) in a new-tab, over different content websites (videos playing in the background, email services)
• leaving the file picker open for more than 5 minutes on the browser
• opening multiple instances of Firefox and opening the file picker in every one

Let us know if there is anything that we overlooked (maybe other scenarios) that would require additional testing.

Comment 9

[Marcia Knous [:marcia]]

Adding [@ __cxxabiv1::failed_throw ] signature which is likely the 10.14 version of this crash: https://bit.ly/2kjOLGY

Some URLs from that signature:

*https://github.com/atmosphereiot/stratosphere/pull/3436
*https://favicomatic.com/
*https://deepart.io/hire/

Comment 10

[Steven Michaud [:smichaud] (Retired)]

Another bug that might benefit from an analysis using a HookCase hook library (https://github.com/steven-michaud/HookCase).

Comment 11

[Markus Stange [:mstange]]

(In reply to Cristian Baica [:cbaica], Release Desktop QA from comment #8)

• the repeated open/close of file picker using the keyboard shortcut commands - cmd+o (while in a newtab, while videos are played on the existing tab)
• the repeated open/close of file picker from the hamburger menu
• the loading of different files(image, html, mp4) in a new-tab, over different content websites (videos playing in the background, email services)
• leaving the file picker open for more than 5 minutes on the browser
• opening multiple instances of Firefox and opening the file picker in every one

Let us know if there is anything that we overlooked (maybe other scenarios) that would require additional testing.

These are great test scenarios. A few more ideas that are worth a try:

• Having an animation run at the same time. For example, open a tab with this URL so that you can get a permanent throbber animation in the UI: https://jwatt.org/tmp/load-never-finishes.php
• Multiple windows (with just one Firefox instance), where one of the windows has an animation and the file picker is opened in one of them
• In the file picker, try different view settings, for example the "in columns" view. Open and close the picker between view changes so that the different views can be in effect while the picker opens.

Comment 12

[Cristian Baica [:cbaica], Release Desktop QA]

I have added the new scenarios. Happy to report that I've managed to generate 2 crashes. Unfortunately they were quite random and was unable to re-create them with exact steps.

Here is the scenario under which the crashes occurred:

• 1 normal window open containing the following tabs: youtube with livesteam playing, about:support open
• 1 normal window with https://jwatt.org/tmp/load-never-finishes.php loading
• 1 private window where the open file dialogue window was opened multiple times

Please note that after the 2 crashes occurred, no other crashes were received in the normal or private window.

Here are the 2 crash signatures:

• https://crash-stats.mozilla.org/report/index/940d9aa1-0837-463d-a839-c97f90190916
• https://crash-stats.mozilla.org/report/index/2ddbdf46-fcdc-4c5b-b360-50f240190916

I have tried as instructed, with multiple normal windows of the same instance, but there were no crashes obtained.
Also, the manipulation of view settings doesn't seem to have any impact on whether a crash occurs or not.

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

Still willing to take a fix here for 70 - the crash volume is moderate but significant in beta.

Comment 14

[Markus Stange [:mstange]]

Thanks Christian! The two crashes are interesting but a bit different from the other crash reports. However, at least your first crash report seems to be a related issue. The second one seems entirely different.

I have an idea for a patch that might help with these crashes. I'll file a new bug for it because I'm not sure that it will actually fix them.

Comment 15

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

The priority flag is not set for this bug.
:jbonisteel, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 16

[Markus Stange [:mstange]]

See bug 1585523 comment 6: We think that there's a fairly high chance that bug 1585523 fixed this. We should watch out if there are any more crashes now that it landed.

Comment 17

[Markus Stange [:mstange]]

No crashes in 70.0b14 so far. Will keep monitoring.

Comment 18

[Liz Henry (:lizzard) (relman/hg->git project)]

Crash volume looks much better for b14 so I'll call this fix-optional for 70.

Comment 19

[Pascal Chevrel:pascalc]

No crashes in Nightly over the last 2 weeks, marking as fix-optional for 71 as well l to remove it from our regression triage meeting.

Comment 20

[Markus Stange [:mstange]]

This is still happening. We probably need to suspend off-main-thread compositing while the file picker is open.

Comment 21

[Gabriele Svelto [:gsvelto]]

Since we changed the crash signature I believe that the original crash here went into bug 1601985. Is that correct? If that's the case then I suggest we close this.

Comment 22

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

Closing because no crashes reported for 12 weeks.