1576262 - Crash in [@ mozilla::dom::BrowsingContext::CanAccess]

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect, P1)

Description

[Marcia Knous [:marcia]]

This bug is for crash report bp-99d112cf-956e-46ac-91bf-f5ee50190805.

Fairly small volume crash which started in 20190805095413: https://bit.ly/2KSJZL6.

Possible regression range based on build id: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=30a8df41ff6db0323d045bdc56cb5f0c95e92b9a&tochange=dba2c8019074a017293f708cec0292607c2e803c

Code was touched in Bug 1570207. ni on :kmag

Top 10 frames of crashing thread:

0 libxul.so mozilla::dom::BrowsingContext::CanAccess docshell/base/BrowsingContext.cpp:547
1 libxul.so nsDocShell::CanAccessItem docshell/base/nsDocShell.cpp:2858
2 libxul.so nsDocShell::DoFindItemWithName docshell/base/nsDocShell.cpp:2951
3 libxul.so nsDocShell::FindItemWithName docshell/base/nsDocShell.cpp:2891
4 libxul.so mozilla::dom::TabGroup::FindItemWithName dom/base/TabGroup.cpp:236
5 libxul.so nsDocShell::DoFindItemWithName docshell/base/nsDocShell.cpp:2996
6 libxul.so nsDocShell::FindItemWithName docshell/base/nsDocShell.cpp:2915
7 libxul.so nsDocShell::PerformRetargeting docshell/base/nsDocShell.cpp:8680
8 libxul.so nsDocShell::InternalLoad docshell/base/nsDocShell.cpp:9235
9 libxul.so nsDocShell::OnLinkClickSync docshell/base/nsDocShell.cpp:12841

Comment 1

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

Waiting to see how this looks in 70.0b3/4.

Comment 2

[Chris Peterson [:cpeterson]]

This crash affects both Fission and non-Fission users, but crash volume is very low. There has been only one crash report from a 72 Nightly user at this time:

https://crash-stats.mozilla.org/report/index/fcbf53b4-952f-4ef1-9fa6-d47830191031

Comment 3

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

Not high volume, happy to take a fix for 73 or 74 but I'm removing this from regression triage for now.

Comment 4

[[:philipp]]

[Tracking Requested - why for this release]:
this crash is spiking up in volume in the firefox 74 release - bug 1622312 contains some steps to reproduce. so far it doesn't seem to be present in 75.0b, so something might have fixed or shifted the signature in the meantime.

Comment 5

[Pascal Chevrel:pascalc]

Kris, could you investigate please? Thanks

Comment 6

[Claas Augner [:claas]]

We observe this (tab) crash occurs when users upload a file. (Sorry, I mixed up the crash reports.)

(I asked one of our affected users to open about:crashes and copy the crash URL and the corresponding Bugzilla tab lead me here.)

Update: The following crash report (linking here) correlates with an OS crash: https://crash-stats.mozilla.org/report/index/01aa015d-5e37-4e7b-b683-4d7d80200316

My guess would be that either FF causes the OS to crash (possibly due to faulty memory hardware, this laptop is due to be replaced, causing several OS crashes per day) or that the OS crashes and FF records a crash before the system restarts.

Comment 7

[Claas Augner [:claas]]

Now the same user observed the same crash report when uploading a file:
https://crash-stats.mozilla.org/report/index/f70efb17-50c0-4ab1-91aa-68e1a0200316

We have a web-based projectmanagement software that allows file uploads in different modules. At one particular location, the tab crashes for some users since Firefox 74 (where it didn't crash in Firefox 73). I will try and figure out what the difference is between this and other upload locations.

Another user has reported the following three crashes (when uploading a file at the same location):
https://crash-stats.mozilla.org/report/index/93592421-a033-439d-914c-69b080200316
https://crash-stats.mozilla.org/report/index/c2edc051-a585-4d0f-a64a-746100200316
https://crash-stats.mozilla.org/report/index/93592421-a033-439d-914c-69b080200316

Comment 8

[Claas Augner [:claas]]

I have been able to reproduce the crash locally in Firefox Portable 74.0 (64-Bit), whereas Firefox Nightly 76.0a1 (2020-03-15) (64-Bit) is not affected:
https://crash-stats.mozilla.org/report/index/88a999de-b80a-4b55-994e-12cd00200316
https://crash-stats.mozilla.org/report/index/bb594242-76f9-42aa-9c6a-1437e0200316

Comment 9

[Claas Augner [:claas]]

I have continued the investigation in (the more specific) Bug 1622312 and shared my insights there (comments 4 and 5).

Comment 10

[Ethan Tseng [:ethan]]

(In reply to Claas Augner [:claas] from comment #9)

I have continued the investigation in (the more specific) Bug 1622312 and shared my insights there (comments 4 and 5).

Can we merge these two bugs (1576262 and 1622312) into one, e.g. set one of them as resolved duplicate?

Comment 11

[Claas Augner [:claas]]

(In reply to Ethan Tseng [:ethan] from comment #10)

Can we merge these two bugs (1576262 and 1622312) into one, e.g. set one of them as resolved duplicate?

Even though these two bugs seem to exhibit the same crash signature, Bug 1622312 has only been observed since Firefox 74, whereas this bug has been first reported in Firefox 70. Therefore I'm not sure whether these bugs are really duplicates, i.e. fixing one will implicitly fix the other.

Maybe Bug 1622312 could be set as blocking this bug?

PS: The initial crash report bp-99d112cf-956e-46ac-91bf-f5ee50190805 from Marcia doesn't seem to load, at least for me.

Comment 12

[Ethan Tseng [:ethan]]

(In reply to Claas Augner [:claas] from comment #11)

Even though these two bugs seem to exhibit the same crash signature, Bug 1622312 has only been observed since Firefox 74, whereas this bug has been first reported in Firefox 70. Therefore I'm not sure whether these bugs are really duplicates, i.e. fixing one will implicitly fix the other.
Maybe Bug 1622312 could be set as blocking this bug?

Thanks for the clarification.

Chris, this is a P1 critical. Could you help check with Kris to see if we can make progress here?

Comment 13

[Chris Peterson [:cpeterson]]

(In reply to Ethan Tseng [:ethan] from comment #12)

Chris, this is a P1 critical. Could you help check with Kris to see if we can make progress here?

I spoke with Kris today. He says he will look at this crash later today.

Comment 14

[Chris Peterson [:cpeterson]]

Moving P1 M5 bugs to M5a milestone

Comment 15

[Pascal Chevrel:pascalc]

(In reply to Chris Peterson [:cpeterson] from comment #13)

(In reply to Ethan Tseng [:ethan] from comment #12)

Chris, this is a P1 critical. Could you help check with Kris to see if we can make progress here?

I spoke with Kris today. He says he will look at this crash later today.

What is the status update now? Thanks

Comment 17

[Kris Maglione [:kmag]]

Attachment: Bug 1576262: Handle ownership races during cross-process navigations. r=nika

Comment 18

[Chris Peterson [:cpeterson]]

75 Beta and 76 Nightly are affected. There are about 20 crash reports from 75 Beta and 76 Nightly so far.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/297e63bd2568
Handle ownership races during cross-process navigations. r=nika

Comment 20

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/297e63bd2568

Comment 21

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

The patch landed in nightly and beta is affected.
:kmag, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 22

[Julien Cristau [:jcristau]]

The crash volume on 75 beta is pretty low so I don't think we need to uplift this late in rc week.

Comment 23

[Ciprian Georgiu, Desktop QA]

Unfortunately, I was unable to reproduce this crash, using the steps from bug 1622312 comment 0. I've tried using an affected Nightly (2019-08-23) on different OSes: macOS, Win 10 x64 and Ubuntu 18.04 x64.

I'm going to remove the qe+ flag, since QA was unable to reproduce this crash. FWIW, it seems that the crash signature is not reported anymore on Mozilla Crash Stats.