Closed Bug 1265062 Opened 8 years ago Closed 8 years ago

B2G_DEBUG=1 for pine/kanikani does not boot: Assertion failure: originAttrsLoadInfo.mInIsolatedMozBrowser == loadContextIsInBE

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: nhirata, Unassigned)

References

Details

(Whiteboard: fixed-in-pine)

Attachments

(6 files, 1 obsolete file)

logout.txt
896.39 KB, text/plain
Details
manualbuildlog.txt
114.07 KB, text/plain
Details
rr backtrace
6.07 KB, text/plain
Details
rr backtrace of matching channel
10.05 KB, text/plain
Details
segfault trying to print content of loadingNode
1.65 KB, text/plain
Details
gdb stacktrace current m-c merged on pine
25.11 KB, text/plain
Details
Attached file logout.txt — 
1. build with B2G_DEBUG=1 ./build.sh -j1
2. after compile, ./flash.sh

Expected: bootable OS
Actual: keeps looking like it reboots.

Gecko (pine) :	e97ee27bce20
Gaia ( kanikani ) :	13bf75f40aa8ac8285acbb715d5156f14a70b047
I think it might be due to the following assert?  I'm not sure:

04-15 10:11:52.390 I/Gecko   (  319): ++DOMWINDOW == 5 (0xa9930400) [pid = 319] [serial = 5] [outer = 0xac207c00]
04-15 10:11:52.610 F/MOZ_Assert(  319): Assertion failure: originAttrsLoadInfo.mInIsolatedMozBrowser == loadContextIsInBE (The value of InIsolatedMozBrowser in the loadContext and in the loadInfo are not the same!), at /Projects/B2G_Aries_pine/pine/netwerk/base/nsNetUtil.cpp:2418
04-15 10:11:52.610 W/google-breakpad(  319): ExceptionHandler::GenerateDump cloned child 
04-15 10:11:52.610 W/google-breakpad(  319): 1141nAttrsLoadInfo.mInIs
04-15 10:11:52.610 W/google-breakpad(  319): 
04-15 10:11:52.610 W/google-breakpad(  319): ExceptionHandler::SendContinueSignalToChild sent continue signal to child
04-15 10:11:52.610 W/google-breakpad( 1141): ExceptionHandler::WaitForContinueSignal waiting for continue signal...
04-15 10:11:53.010 I/ServiceManager(  286): service 'android.security.keystore' died
04-15 10:11:53.010 I/ServiceManager(  286): service 'SurfaceFlinger' died
04-15 10:11:53.010 I/ServiceManager(  286): service 'permission' died
04-15 10:11:53.010 I/ServiceManager(  286): service 'display.qservice' died
04-15 10:11:53.360 E/sensorsd( 1038): recvmsg failed: Connection reset by peer
04-15 10:11:53.360 I/ServiceManager(  286): service 'media.audio_flinger' died
04-15 10:11:53.360 I/ServiceManager(  286): service 'media.player' died
04-15 10:11:53.360 I/ServiceManager(  286): service 'media.camera' died
04-15 10:11:53.360 I/ServiceManager(  286): service 'listen.service' died
04-15 10:11:53.360 I/ServiceManager(  286): service 'media.audio_policy' died
Attached file manualbuildlog.txt — 
including build log.
Well I am starting to think this is the same root cause as bug 1262180 and bug 1264655 except I have no idea why for now :/
Summary: B2G_DEBUG=1 for pine/kanikani does not boot → B2G_DEBUG=1 for pine/kanikani does not boot: Assertion failure: originAttrsLoadInfo.mInIsolatedMozBrowser == loadContextIsInBE
Also reproduced on mulet with debug build. It is not loading at all anymore :/
Blocks: 1252143
Attached file rr backtrace — 

    
    

    
  
That check was introduced in bug 1125916
Depends on: 1125916

    
    

    
  
> (rr) print originAttrsLoadInfo
> $10 = {<mozilla::dom::OriginAttributesDictionary> = {<mozilla::dom::DictionaryBase> = {mIsAnyMemberPresent = false}, mAddonId = {<nsAString_internal> = {mData = 0x7f9f7b3b4f3c <gNullChar> u"", mLength = 0, mFlags = 1}, <No data fields>}, mAppId = 0, 
>     mInIsolatedMozBrowser = false, mSignedPkg = {<nsAString_internal> = {mData = 0x7f9f7b3b4f3c <gNullChar> u"", mLength = 0, mFlags = 1}, <No data fields>}, mUserContextId = 0}, <No data fields>}
> (rr) print loadContextIsInBE
> $11 = true
> (rr) print originAttrsLoadInfo.mInIsolatedMozBrowser 
> $12 = false

    
    

    
  
Christoph, I suspect there is something bad going on with the channels we are building/manipulating at some point, and this would result in inconsistent load info. Do you have any idea where I should check deeper/investigate? Thanks!
Flags: needinfo?(ckerschb)

    
    

    
  
Maybe Dragana would know more? Any help is welcome :)
Flags: needinfo?(dd.mozilla)

    
    

    
  
Disabling OOP does not help :/

    
    

    
  
I had a short look at this, I think this is going to hit all not just b2g.

    
    

    
  
(In reply to Dragana Damjanovic [:dragana] from comment #11)
> I had a short look at this, I think this is going to hit all not just b2g.

Hit every platform? Just to be clear, I don't think you are breaking anything but rather exposing earlier the issue we have in bug 1262180 and bug 1264655 :)

    
    

    
  
What you could do is the following: Find out where the channel is created and most importantly what arguments are used for NS_NewChannel. The best way to do this is print the URL of the channel (channel->GetURI(getter_Addrefs(tmpURI));) shortly before the assertion is triggered.

Once you have the URI of the channel you can set a breakpoint within nsIOService::NewChannelFromURIWithProxyFlagsInternal when that specific URI is created and work your way backwards scrolling through the stacktrace.

Once you have that you can compare the info in the loadContext and loadInfo and maybe we can find out where the code diverges. Does that make sense to you?

We have similar problems elsewhere, e.g. Bug 1264230 and also Bug 1264231. Once we have figured the problem for one of those bugs, most likely we can apply the same (or at least similar) fix to the other related bugs.
Flags: needinfo?(ckerschb)

    
    

    
  
Thanks, I'll look into this !

    
    

    
  
> nsIOService::NewChannelFromURIWithProxyFlagsInternal(): URI@0x7f8d6c8ed500 channel@0x7ffeb90a1ab0 aURI=file:///home/alex/codaz/Mozilla/b2g/gaia/profile/apps/system/style/system/initlogo.css
> nsIOService::NewChannelFromURIWithProxyFlagsInternal(): URI@0x7f8d65a43e00 channel@0x7ffeb90a1e10 aURI=chrome://gaia/content/system/style/system/initlogo.css
> NS_CompareLoadInfoAndLoadContext(): Will assert isolation for URI@0x7ffeb90a1fc8 aChannel@0x7f8d6e840250 aChannel: file:///home/alex/codaz/Mozilla/b2g/gaia/profile/apps/system/style/system/initlogo.css
> Assertion failure: originAttrsLoadInfo.mInIsolatedMozBrowser == loadContextIsInBE (The value of InIsolatedMozBrowser in the loadContext and in the loadInfo are not the same!), at /home/alex/codaz/Mozilla/gecko-cinnabar/netwerk/base/nsNetUtil.cpp:2424

So we are asserting when manipulating the channel of "file:///home/alex/codaz/Mozilla/b2g/gaia/profile/apps/system/style/system/initlogo.css"

    
    

    
      
  


  

    
    

    
      
  

    
    

    
  


  
Previous one was wrong

    
    

    
  
We are entering the creation of loadInfo with aLoadingPrincipal=0x7f8d90bfde20 aTriggeringPrincipal=0x7f8d90bfde20

And at the end of the LoadInfo constructor, we are inheritating the origin attributes: |InheritOriginAttributes(mLoadingPrincipal, mOriginAttributes);|

So does it makes sense we have the same principal as "loading" and "triggering" ? And could we be manipulating the wrong loading principal?

    
    

    
  
(In reply to Alexandre LISSY :gerard-majax from comment #21)
> So does it makes sense we have the same principal as "loading" and
> "triggering" ? And could we be manipulating the wrong loading principal?

Yes, it makes sense (actually most of the time) the loadingPrincipal and the TrigginerPrincipal are identical. Where do we call NS_NewChannel()? Can you post the whole stacktrace? Most likely the loadingPricnipal is the systemPricnipal so that might already provide a hint why the assertion is triggered.

    
    

    
  
Isn't the stack in attachment 8742304 [details] good?

    
    

    
  
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #22)
> (In reply to Alexandre LISSY :gerard-majax from comment #21)
> > So does it makes sense we have the same principal as "loading" and
> > "triggering" ? And could we be manipulating the wrong loading principal?
> 
> Yes, it makes sense (actually most of the time) the loadingPrincipal and the
> TrigginerPrincipal are identical. Where do we call NS_NewChannel()? Can you
> post the whole stacktrace? Most likely the loadingPricnipal is the
> systemPricnipal so that might already provide a hint why the assertion is
> triggered.

In the stack linked above, the call would come from https://dxr.mozilla.org/mozilla-central/rev/1da1937a9e03154ae7c60089f2dcf5ad9ee20fa3/layout/style/Loader.cpp#1636 |NS_NewChannelWithTriggeringPrincipal()|

    
    

    
  
So, after Christoph's suggestion, I checked the call path of LoadSheet(): if I add a call |NS_CompareLoadInfoAndLoadContext(channel);| right after the channel's creation, the assertion gets hit also.
Flags: needinfo?(jonas)

    
  
Blocks: 1266067

    
    

    
  
Marking as fixed-in-pine thanks to workaround in bug 1266064

    
  
Whiteboard: fixed-in-pine

    
    

    
  
I suggest working with Dragana to figure out why we hit these assertions. They are intended to catch real bugs so just removing them is not a great solution.

Dragana was quite good at tracking down the source of other places where we assert, so deferring to her.
Flags: needinfo?(jonas)

    
    

    
  
Might be fixed by bug 1266022, we'll know after m-c => pine merge

    
    

    
  


  
I am still hitting this ...
Flags: needinfo?(dd.mozilla)

    
  
Flags: needinfo?(dd.mozilla)

    
    

    
  
(In reply to Christoph Kerschbaumer [:ckerschb] from comment #22)
> (In reply to Alexandre LISSY :gerard-majax from comment #21)
> > So does it makes sense we have the same principal as "loading" and
> > "triggering" ? And could we be manipulating the wrong loading principal?
> 
> Yes, it makes sense (actually most of the time) the loadingPrincipal and the
> TrigginerPrincipal are identical. Where do we call NS_NewChannel()? Can you
> post the whole stacktrace? Most likely the loadingPricnipal is the
> systemPricnipal so that might already provide a hint why the assertion is
> triggered.

Yes, the loading principal is the system principal. The document creating the XHR is chrome://gaia/system/index.html. Like Alexandre said, we create the channel passing that document, and in the LoadInfo constructor we inherit the attributes from the system principal.

The loadContext seems to be correct. It's being created back when we create the system app frame here: https://dxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js#367-373

    
    

    
  
I'm mentioning XHR because in my tests the assertion is hit from web_manifest_helper.js trying to load https://m.facebook.com/manifest.webapp via XHR.

    
    

    
  
Bug 1264231 is about to land, we should check what it gives on a debug build
Depends on: 1264231

    
  
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Flags: needinfo?(dd.mozilla)

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: