1295011 - Assertion failure: originAttrsLoadInfo.mInIsolatedMozBrowser == loadContextIsInBE (The value of InIsolatedMozBrowser in the loadContext and in the loadInfo are not the same!), at /home/jovan/B2G/gecko/netwerk/base/nsNetUtil.cpp:2484

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect, P1)

Description

[Jovan Gerodetti]

Attachment: crash report for /system/b2g/b2g

Gecko constantly crashes with this error.

Comment 1

[[:fabrice] Fabrice Desré]

Ouch, that's pretty bad... Do you have the crash id submitted by the crash reporter? Or if not, can you get a backtrace yourself?

Comment 2

[Jovan Gerodetti]

well it always says "Crash Reported: disabled at build time" so I guess not? How can I get the backtrace?

Comment 3

[[:fabrice] Fabrice Desré]

Start b2g with ./run-gdb.sh and set a breakpoint at nsNetUtil.cpp:2484

And yep, we should re-enable the crash reporter...

Comment 4

[Jovan Gerodetti]

Attachment: backtrace

Comment 5

[Jovan Gerodetti]

Attachment: backtrace

Comment 6

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

Hi Jovan
Could you print the JS stack as well?
(gdb)js
or
(gdb)call DumpJSStack()

And also could you print the value of 'loadInfoUsePB' and 'loadContextUsePB'?
and ((nsDocShell*)loadContext)->ItemType()

Thanks

Comment 7

[Jovan Gerodetti]

Attachment: JS stack

Comment 8

[[:fabrice] Fabrice Desré]

Yoshi, so it looks like a chrome document loaded in a <iframe mozbrowser> fails to load an https:// uri. Any idea why?

Comment 9

[Jovan Gerodetti]

> (gdb) print loadInfoUsePB
> $1 = false
> 
> (gdb) print loadContextUsePB
> $2 = false
> 
> (gdb) print ((nsDocShell*)loadContext)->ItemType()
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0xa0bee8f6 in ?? ()
> The program being debugged was signaled while in a function called from GDB.
> GDB remains in the frame where the signal was received.
> To change this behavior use "set unwindonsignal on".
> Evaluation of the expression containing the function
> (non-virtual thunk to mozilla::docshell::POfflineCacheUpdateParent::RegisterID(mozilla::ipc::IProtocol*, int)) will be abandoned.
> When the function is done executing, GDB will silently stop.

Comment 10

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

Oops, from the attached stack trace 

MOZ_ASSERT(loadInfoUsePB == loadContextUsePB,

it was asserted in PrivateBrowsing, but the bug title says "originAttrsLoadInfo.mInIsolatedMozBrowser == loadContextIsInBE"

Is it asserted in PrivateBrowsing or mozbrowser?

Comment 11

[[:fabrice] Fabrice Desré]

It's not in private browsing mode, just mozbrowser. And I'm pretty sure that the ItemType of the loading docShell is "content" (1).

Comment 12

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

If it is asserted in mozbrowser value mismatch, so I guess the problem is the the XHR uses SystemPrincipal 
https://github.com/mozilla-b2g/gaia/blob/master/shared/js/web_manifest_helper.js#L17
(I assume the stacktrace is still correct, because I saw it was called by XHR)

and SystemPrincipal doesn't have origin attributes.

However the loadInfo uses the principal from the content, which has the isIsolatedMozBrowser flag set
(so from the gdb, the loadContextIsInBE should be false, and originAttrsLoadInfo.mInIsolatedMozBrowser should be true)

If my assumption is true, my suggestions is to apply the bug 1244340 part 2
https://bugzilla.mozilla.org/attachment.cgi?id=8777291&action=diff

and in your JS code, add a line 
xhr.setOriginAttributes({inIsolatedMozBrowser: true}) between xhr.open and xhr.send.


if you want to do 
xhr.channel.originAttributes = {inIsolatedMozBrowser: true}; 
this should also work, but it's hacky and is not recommended. 
see https://bugzilla.mozilla.org/show_bug.cgi?id=1244340#c20

Comment 13

[[:fabrice] Fabrice Desré]

(In reply to Yoshi Huang[:allstars.chh] from comment #12)
> If it is asserted in mozbrowser value mismatch, so I guess the problem is
> the the XHR uses SystemPrincipal 
> https://github.com/mozilla-b2g/gaia/blob/master/shared/js/
> web_manifest_helper.js#L17
> (I assume the stacktrace is still correct, because I saw it was called by
> XHR)
> 
> and SystemPrincipal doesn't have origin attributes.
> 
> However the loadInfo uses the principal from the content, which has the
> isIsolatedMozBrowser flag set
> (so from the gdb, the loadContextIsInBE should be false, and
> originAttrsLoadInfo.mInIsolatedMozBrowser should be true)
> 
> If my assumption is true, my suggestions is to apply the bug 1244340 part 2
> https://bugzilla.mozilla.org/attachment.cgi?id=8777291&action=diff
> 
> and in your JS code, add a line 
> xhr.setOriginAttributes({inIsolatedMozBrowser: true}) between xhr.open and
> xhr.send.
> 
> 
> if you want to do 
> xhr.channel.originAttributes = {inIsolatedMozBrowser: true}; 
> this should also work, but it's hacky and is not recommended. 
> see https://bugzilla.mozilla.org/show_bug.cgi?id=1244340#c20

I don't think that will work, because the load context is not recognized as being chrome, even though it has a system principal. Looks like we are in a unplanned configuration.

Comment 14

[Jovan Gerodetti]

Any thoughts on how we can fix this?

Comment 15

[[:fabrice] Fabrice Desré]

Not yet, I had no time to dig deeper. Yoshi, do you have insights on how I can track where/when we assign these flags to frames? Is that all in the TabContext or in the FrameLoader?

Comment 16

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

I still think my comment 12 is valid, loadContext comes from content docshell, which will have mozBrwoser flag,  whereas loadInfo use OriginAttributes from SystemPrincipal (loadinfo's loadingPrincipal), which won't have mozbrowser flag.

In short loadInfo doesn't have correct information, in which case docShell is correct, then it doesn't relate to TabChild nor FrameLoader.

If you think docShell is wrong, then I think it might be related to bigger security problem, which I don't have glue, either.

Comment 17

[Jovan Gerodetti]

so how do we fix this? I can try to help, but I have no idea what to do.

Comment 18

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

(In reply to Jovan Gerodetti from comment #17)
> so how do we fix this? I can try to help, but I have no idea what to do.

Hi Jovan

print loadContext
print loadContextIsInBE
print originAttrsLoadInfo.mInIsolatedMozBrowser
print loadInfo->LoadingPrincipal()

might help

Thanks

Comment 19

[Jovan Gerodetti]

(gdb) print loadContext
$1 = {mRawPtr = 0xaf569928}

(gdb) print loadContextIsInBE
$2 = true

(gdb) print originAttrsLoadInfo.mInIsolatedMozBrowser
$3 = false


print loadInfo->LoadingPrincipal()

doesn't output anything

Comment 20

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

try to add 
xhr.setOriginAttributes({inIsolatedMozBrowser: true}) 
after xhr.open and before xhr.send.
for example, put it after xhr.open, https://github.com/mozilla-b2g/gaia/blob/master/shared/js/web_manifest_helper.js#L19

Comment 21

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

(In reply to Yoshi Huang[:allstars.chh] from comment #20)
> try to add 
> xhr.setOriginAttributes({inIsolatedMozBrowser: true}) 
> after xhr.open and before xhr.send.
> for example, put it after xhr.open,
> https://github.com/mozilla-b2g/gaia/blob/master/shared/js/
> web_manifest_helper.js#L19

note that you have to apply bug 1244340 part 2 patch first if you are not using m-c

Comment 22

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

This should be duplicated to Bug 1265062.