Assertion failure: aPrincipalToInherit || (!aTriggeringPrincipal || aTriggeringPrincipal->GetIsNullPrincipal() || (aFlags & INTERNAL_LOAD_FLAGS_INHERIT_PRINCIPAL)), at nsDocShell.

RESOLVED DUPLICATE of bug 1308889

Status

()

P2
normal
RESOLVED DUPLICATE of bug 1308889
2 years ago
2 years ago

People

(Reporter: cbook, Unassigned)

Tracking

(Blocks: 1 bug, {assertion, regression, regressionwindow-wanted})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
Created attachment 8801699 [details]
stack

found via bughunter and reproduced on latest m-c tinderbox windows debug build.

Steps to reproduce:
-> Load http://www.cebbank.com/
---> Assertion 

Assertion failure: aPrincipalToInherit || (!aTriggeringPrincipal || aTriggeringPrincipal->GetIsNullPrincipal() || (aFlags & INTERNAL_LOAD_FLAGS_INHERIT_PRINCIPAL)), at c:/builds/moz2_slave/m-cen-w32-d-000000000000000000/build/src/docshell/base/nsDocShell.cpp:9753
I am on it, will provide some debug information a little later tonight.
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #1)
> I am on it, will provide some debug information a little later tonight.

Seems Windows specific, can't reproduce on Linux.
Kamil, I don't have a windows machine handy, any chance you could provide a more detailed stacktrace? All you would have to do is:
a) Get a Nightly on Windows
b) Navigate to http://www.cebbank.com/
c) Paste stacktrace here

Thanks!
Flags: needinfo?(kjozwiak)
Chris, I tried loading the website you mentioned using several different Win machines but couldn't reproduce the issue. Is there anything else I can try?

Tested using the following builds:

* fx52.0a1, buildId: 20161017030209, changeset: 94b0fddf96b4
** https://archive.mozilla.org/pub/firefox/nightly/2016/10/2016-10-17-03-02-09-mozilla-central/
* fx52.0a1, buildId: 20161017113943, changeset: 7c8216f48c38 central/tip

Tested using the following platforms:

* Win 10 x64 - couldn't reproduce
* Win 8.1 x64 VM - couldn't reproduce
* Win 7 x64 VM - couldn't reproduce

Test Cases Used:

- Opened the website several times using both e10s and non-e10s
- Opened the website several times using PB mode
- allowed pop-ups from http://www.cebbank.com/ (nightly was blocking the pop-up by default)
- restored the browser several times with about 15 instances of http://www.cebbank.com/ opened
- opened several links using "Open Link in New Tab" via the right context menu
- navigated through portions of the website

I also tried reproducing the issue using the following asan build under Ubuntu 16.04:
* https://index.taskcluster.net/v1/task/gecko.v2.mozilla-central.latest.firefox.linux64-asan-opt/artifacts/public/build/target.tar.bz2
Flags: needinfo?(kjozwiak)
(In reply to Kamil Jozwiak [:kjozwiak] from comment #4)
> Chris, I tried loading the website you mentioned using several different Win
> machines but couldn't reproduce the issue. Is there anything else I can try?

Thanks Kamil for testing.

@Carsten, can you still repro the problem? Any chance you could provide a detailed stakctrace?
Flags: needinfo?(cbook)
> Seems Windows specific, can't reproduce on Linux.

I can reproduce this in my local Linux64 debug build.
I suspect it's a (very) recent regression -- last few days or so.
Keywords: regression
Created attachment 8802353 [details]
Linux stack
BTW, it happens on startup for me, while restoring the (dozen or so) tabs.
(Reporter)

Comment 9

2 years ago
can't reproduce anymore, but from mats comment this seems to be a regression
Flags: needinfo?(cbook)
Neither can I, fwiw.
Still crashed on startup on today's tip <http://hg.mozilla.org/mozilla-central/rev/c845bfd0accb>.  The stack is the same as Mats.
I guess it's caused by restoring https sessions.  There was a tab connected to https://www.netflix.com/browse .
(In reply to Hiroyuki Ikezoe (:hiro) from comment #12)
> I guess it's caused by restoring https sessions.  There was a tab connected
> to https://www.netflix.com/browse.

I tried seeing if I could reproduce the crash using the above case under Windows/Ubuntu but didn't have any luck :/

:hiro, can you reproduce the crash consistently when restoring https sessions or is it intermittent?

Platforms/Builds Used:

* Win 10 Pro x64 - couldn't reproduce
** build used: fx52.0a1, buildId: 20161025004513, changeset: c845bfd0accb central/tip

* Ubuntu 16.04.1 LTS x64 VM - couldn't reproduce
** build used: fx52.0a1, buildId: 20161025102719, changeset: c6ccd71126ff central/tip

Test Cases Used:

* login into netflix (https://www.netflix.com/browse)
* restore the tab via the "restore previous session" under about:home
* restore the tab using "Show my windows and tabs from last time" under about:preferences#general
(In reply to Kamil Jozwiak [:kjozwiak] from comment #13)
> (In reply to Hiroyuki Ikezoe (:hiro) from comment #12)
> > I guess it's caused by restoring https sessions.  There was a tab connected
> > to https://www.netflix.com/browse.
> 
> I tried seeing if I could reproduce the crash using the above case under
> Windows/Ubuntu but didn't have any luck :/
> 
> :hiro, can you reproduce the crash consistently when restoring https
> sessions or is it intermittent?

Yes, it's intermittent.  But once it happened, crashes repeatedly until I remove the tab by stable firefox (49).

One more note that the profile which I used yesterday is a profile for testing I've been using.  I've never logged-in netflix with this profile, and had never seen this crash until I logged in netflix.
(In reply to Hiroyuki Ikezoe (:hiro) from comment #14)

> One more note that the profile which I used yesterday is a profile for
> testing I've been using.  I've never logged-in netflix with this profile,
> and had never seen this crash until I logged in netflix.

I *had* never logged-in netflix and had never seen the crash.

Updated

2 years ago
Keywords: regressionwindow-wanted
FWIW, most likely Bug 1308889 will remove that assertion. Let's wait what we decide within Bug 1308889 and then I'll follow up in this bug.
Depends on: 1308889
P2, mirroring priority of bug 1308889
Priority: -- → P2
The assertion in question was added by Bug 1303943, which landed in FF52. Bug 1308889 removed that assertion (also within FF52). Hence marking this bug as resolved.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1308889
You need to log in before you can comment on or make changes to this bug.