820716 - Failing assertion MOZ_ASSERT(OOPInitialized()) at toolkit/crashreporter/nsExceptionHandler.cpp#1897

Status: RESOLVED WONTFIX

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

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I haven't been able to reproduce this but it might be due to a race condition during b2g/gaia startup.

Is there any thing that prevents the following from happening?

 (1) b2g "chrome" starts up, loads gaia system app
-- in parallel --
 (2a) System app or b2g chrome queries for crash reports
 (2b) System app launches first OOP app

The problem is that if (2a) happens before the app launched in (2b) has finished registering itself with the crash reporter, we can hit this bug (I think).

If so, then the directory service can accessed off the main thread, and as it's implemented in JS for b2g, that almost certainly going to make things blow up.

Comment 1

[[:fabrice] Fabrice Desré]

(2a) is done by chrome code in shell.js if I'm not mistaken, so this looks very plausible. Ccing Hub that knows the crash reporter best.

Comment 2

[Hubert Figuiere [:hub]]

Not sure if that's related, but I have seen several situation where b2g didn't start. ie I have only the b2g process, a black screen and no container processes.

Comment 3

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

It's baaaaaaaaaaaaack.

This is now happening when the b2g emulator crashes (m-c as of 2013/07/10), when running debug/noopt.

Comment 4

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Small change: Line number is now 1927.

Comment 5

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: ASSERTION failure in jb port of FFOS

We are also seeing same ASSERTION failure in jb port of FFOS.

F/MOZ_Assert( 1002): Assertion failure: OOPInitialized(), at ../../../../../../../../gecko/toolkit/crashreporter/nsExceptionHandler.cpp:1934
I/ServiceManager(  262): service 'media.resource_manager' died
I/ServiceManager(  262): service 'display.qservice' died
I/ServiceManager(  262): service 'media.audio_flinger' died
I/ServiceManager(  262): service 'media.player' died
I/ServiceManager(  262): service 'media.camera' died
I/ServiceManager(  262): service 'media.audio_policy' died
W/SRS_QDSP_Adapter( 1107): Not creating SRS DSP thread.

b2g fails to start randomly on jb port of FFOS

Comment 6

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Any update on this ?

Comment 7

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Steps to reproduce issue: 

1) Build JB port of FFOS with B2G_DEBUG=1 
2) Reboot device till you see this assertion failure again during boot. This assertion failure happens randomly during reboot. So we need to reboot multiple times to see this assertion failure. 

Use multi-core device to reproduce it. Single core device may not show this racing condition.

Comment 8

[bhavana bajaj [:bajaj]]

Ni :mwu to see if he has any idea what may be going on here.

Comment 9

[[:fabrice] Fabrice Desré]

I tried to reproduce on the helix with no luck. I have an item on my todo list to check shell.js for potential races though.

Comment 10

[Michael Wu [:mwu]]

I don't have any ideas off the top of my head.

Comment 11

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Fabrice Desré [:fabrice] from comment #9)
> I tried to reproduce on the helix with no luck. I have an item on my todo
> list to check shell.js for potential races though.

Hi, have you tried with B2G_DEBUG=1 and multicore device with FFOS 1.3 ? 
This issue has some kind of randomness and it see it more frequently with debug build of FFOS 1.3 gecko (B2G_DEBUG=1) on multicore device.

Thanks a lot for your help.

Comment 12

[Preeti Raghunath(:Preeti)]

Fabrice,

Can you please point out where we are with the bug?

Comment 13

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

I am not seeing this OOPInitialized ASSERTION failure any more in latest build. But I am not sure whether this is really fixed or some other delay is hiding this issue temporarily

Comment 14

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Hi fabrice,

can you please confirm whether any change has gone in gecko which has fixed OOPInitialized ASSERTION failure during boot or not. I am suspecting that additional delay can also hide this race .

Comment 15

[[:fabrice] Fabrice Desré]

Hi Tapas,

Nothing has been done specifically for this bug, but we had some startup regressions that may hide that. I have troubles getting a build on a multicore phone here but I'll check our startup phase closely and will provide a patch.

Comment 16

[[:fabrice] Fabrice Desré]

Ok, so I made some progress, and I can reproduce the would-be-assert on an opt build if I |kill -11 $B2G_PID| on a dual core.

I replaced the ASSERT by a KABOOM message, and here's what we get:

I/GeckoDump(  446): CCC shell.js reportCrash()
I/Gecko   (  446): CCC CrashReporter MoveToPending Parent init:no
I/Gecko   (  446): CCC CrashReporter GetPendingDir Parent init:no
I/Gecko   (  446): CCC CrashReporter KABOOM!! Parent init:no
I/Gecko   (  446): CCC GeckoChildProcessHost::PrepareLaunch()
I/Gecko   (  446): CCC CrashReporter OOPInit() Parent init:no
I/Gecko   (  446): CCC GeckoChildProcessHost::PrepareLaunch()
I/Gecko   (  446): CCC CrashReporter OOPInit() Parent init:yes
I/Gecko   (  446): CCC GeckoChildProcessHost::PrepareLaunch()
I/Gecko   (  446): CCC CrashReporter OOPInit() Parent init:yes

Clearly we try to MoveToPending() before GeckoChildProcessHost::PrepareLaunch() and this makes us fail.

The stack trace at this point is:

#0  GetPendingDir (dir=0xbee6b3ec) at /home/fabrice/dev/birch/toolkit/crashreporter/nsExceptionHandler.cpp:1948
#1  0x418e6942 in MoveToPending (dumpFile=0x4362a310, extraFile=0x4362a3a0) at /home/fabrice/dev/birch/toolkit/crashreporter/nsExceptionHandler.cpp:2171
#2  0x418e8542 in CrashReporter::CheckForLastRunCrash () at /home/fabrice/dev/birch/toolkit/crashreporter/nsExceptionHandler.cpp:2478
#3  0x418e85e8 in CrashReporter::GetLastRunCrashID (id=...) at /home/fabrice/dev/birch/toolkit/crashreporter/nsExceptionHandler.cpp:2490
#4  0x418df32c in nsXULAppInfo::GetLastRunCrashID (this=<value optimized out>, aLastRunCrashID=...) at /home/fabrice/dev/birch/toolkit/xre/nsAppRunner.cpp:849
#5  0x40e43706 in NS_InvokeByIndex (that=<value optimized out>, methodIndex=<value optimized out>, paramCount=<value optimized out>, params=<value optimized out>)
    at /home/fabrice/dev/birch/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_arm.cpp:164
#6  0x41341cf2 in CallMethodHelper::Invoke (ccx=<value optimized out>, mode=<value optimized out>)
    at /home/fabrice/dev/birch/js/xpconnect/src/XPCWrappedNative.cpp:2555


The call to nsXULAppInfo::GetLastRunCrashID() is triggered by https://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js#110

Tentative patch coming...

Comment 17

[[:fabrice] Fabrice Desré]

Attachment: crash-reports-race.patch

With this patch I got the crash reporter to work properly, including the banner claiming "Firefox OS crashed".

Tapas, I would appreciate if you could run your tests with this patch.

Comment 18

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

thanks for your help :) . I will test it today and let you know soon :)

Comment 19

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Comment on attachment 8339644 [details] [diff] [review]
crash-reports-race.patch

It runs fine in my test. Thanks a lot for your help. :)

Comment 20

[[:fabrice] Fabrice Desré]

Attachment: crash-reports-race.patch

Comment 21

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 8340872 [details] [diff] [review]
crash-reports-race.patch

It seems a bit weird to have twice the same observer with the difference that one start to reports the crashes when it is ready. Can we not simply have a stack, an proceed it when the oop reporter is ready ?

Also what about removing the observer once it is consumed ?

Comment 22

[[:fabrice] Fabrice Desré]

Attachment: crash-reports-race.patch v2

Vivien, I added the removeObserver() calls, even if we are guaranteed to have this fired only once. The reason I put the two observers is that we try to send the chrome crash report once we have loaded the system app, and sometimes the oop init of the crash reporter happens before, but I've seen cases where it happens after. I agree that the real proper solution would be to have an async function on the crash reporter to wait on its readiness but I have no time to do that for 1.3 (adding a Promise isReady() to https://mxr.mozilla.org/mozilla-central/source/xpcom/system/nsICrashReporter.idl#18 looks like the best long term solution).

Comment 23

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 8341221 [details] [diff] [review]
crash-reports-race.patch v2

r+ but please open a followup (maybe tagged as a good first bug) and add the bug number next to the calls. Thanks.

Comment 24

[(not currently active) Ted Mielczarek]

Comment on attachment 8340872 [details] [diff] [review]
crash-reports-race.patch

Review of attachment 8340872 [details] [diff] [review]:
-----------------------------------------------------------------

I wonder if it wouldn't be simpler to just force the startup codepaths to OOPInit() for B2G (and future Firefox e10s) right after init'ing the in-process crashreporter instead of adding notifications etc:
http://hg.mozilla.org/mozilla-central/annotate/4bf430d990e5/toolkit/xre/nsAppRunner.cpp#l2998

This is okay, just a little ugly.

Comment 25

[(not currently active) Ted Mielczarek]

Comment on attachment 8341221 [details] [diff] [review]
crash-reports-race.patch v2

Review of attachment 8341221 [details] [diff] [review]:
-----------------------------------------------------------------

That is, I'm okay with landing this patch, but I think just forcibly calling OOPInit during startup would be simpler and a smaller patch.

Comment 26

[[:fabrice] Fabrice Desré]

Attachment: race-crashreport.patch v3

Ted, here's a new patch based on your advice. I'd rather take that and not do the observer waiting in the frontend.

That looks to work fine for me, but I'll wait for Tapas endurance test anyway to land.

Comment 27

[(not currently active) Ted Mielczarek]

Comment on attachment 8342061 [details] [diff] [review]
race-crashreport.patch v3

Review of attachment 8342061 [details] [diff] [review]:
-----------------------------------------------------------------

This seems fine. I doubt it will have any noticeable impact anywhere. Nice and simple. :)

Comment 28

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Comment on attachment 8342061 [details] [diff] [review]
race-crashreport.patch v3

I can see b2g is crashing (during boot) as below with this patch in jb_gonk:

Program received signal SIGSEGV, Segmentation fault.
0xb5494f98 in CrashReporter::OOPInit () at ../../../../../../../../gecko/toolkit/crashreporter/nsExceptionHandler.cpp:2251
2251	../../../../../../../../gecko/toolkit/crashreporter/nsExceptionHandler.cpp: No such file or directory.
	in ../../../../../../../../gecko/toolkit/crashreporter/nsExceptionHandler.cpp
(gdb) bt
#0  0xb5494f98 in CrashReporter::OOPInit () at ../../../../../../../../gecko/toolkit/crashreporter/nsExceptionHandler.cpp:2251
#1  0xb5489242 in XREMain::XRE_mainInit (this=0xbea9e86c, aExitFlag=0xbea9e84b) at ../../../../../../../../gecko/toolkit/xre/nsAppRunner.cpp:3004
#2  0xb548b6b6 in XREMain::XRE_main (this=0xbea9e86c, argc=1, argv=<optimized out>, aAppData=0x23948) at ../../../../../../../../gecko/toolkit/xre/nsAppRunner.cpp:4031
#3  0xb548b898 in XRE_main (argc=1, argv=0xbeaa0a24, aAppData=0x23948, aFlags=<optimized out>) at ../../../../../../../../gecko/toolkit/xre/nsAppRunner.cpp:4259
#4  0x0000a45c in do_main (argv=0xbeaa0a24, argc=1) at ../../../../../../../../gecko/b2g/app/nsBrowserApp.cpp:163
#5  main (argc=<optimized out>, argv=<optimized out>) at ../../../../../../../../gecko/b2g/app/nsBrowserApp.cpp:256
(gdb)

Comment 29

[Kartikaya Gupta (email:[e-mail])]

The OOPinitialized assertion failure is causing a reboot loop for me. There's a pending crash report on the device and when B2G boots up it tries to process the pending crash report which then hits this assertion and causes the phone to reboot.

Comment 30

[[:fabrice] Fabrice Desré]

https://hg.mozilla.org/integration/b2g-inbound/rev/eb34b68e2f2a

Comment 31

[[:fabrice] Fabrice Desré]

backed out for test failures:
https://hg.mozilla.org/integration/b2g-inbound/rev/2fd951a90734

Ted, how could XREMain::XRE_mainInit() not be on the main thread?

Comment 32

[Carsten Book [:Tomcat]]

(In reply to Fabrice Desré [:fabrice] from comment #31)
> backed out for test failures:
> https://hg.mozilla.org/integration/b2g-inbound/rev/2fd951a90734
> 
> Ted, how could XREMain::XRE_mainInit() not be on the main thread?

yeah https://tbpl.mozilla.org/php/getParsedLog.php?id=31787982&tree=B2g-Inbound was btw one example of the failures tbpl reported

Comment 33

[(not currently active) Ted Mielczarek]

I don't know, I'm at a loss here. bsmedberg: do you have any idea? Have we simply not initialized things such that NS_IsMainThread works this early in startup?

Comment 34

[Benjamin Smedberg]

The "main thread" is whatever thread calls NS_InitXPCOM. Therefore there is no main thread until we start XPCOM: technically until nsThreadManager::Init is called, but that's very early in XPCOM startup.

Comment 35

[(not currently active) Ted Mielczarek]

Okay. In that case, r=me to just remove that MOZ_ASSERT, since we're explicitly calling that function from the main thread during startup, so we can't actually hit the failing case with this patch.

Comment 36

[[:fabrice] Fabrice Desré]

Try is still very unhappy:
https://tbpl.mozilla.org/?tree=Try&rev=30998a3b4cfc

Ted I'm not sure what's the best to move forward from here :(

Comment 37

[(not currently active) Ted Mielczarek]

Oh, in retrospect it's obvious. We haven't initialized XPCOM at this point, so the FindPendingDir part can't work. Try moving that line down to after XPCOM init, maybe at the beginning of XRE_mainRun:

http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#3735

(there's already an ifdef MOZ_CRASHREPORTER block in there you can piggyback on.)

Comment 38

[Preeti Raghunath(:Preeti)]

Ted,

Is comment 37 a potential solution? What is the ETA for the fix?

Comment 39

[(not currently active) Ted Mielczarek]

I believe it is, that's why I suggested it. I'm not intending to fix this, that comment was for Fabrice.

Comment 40

[[:fabrice] Fabrice Desré]

Yep, I'm still on it. My latest try didn't end up well either (https://tbpl.mozilla.org/?tree=Try&rev=037a466190a4)

Comment 41

[Preeti Raghunath(:Preeti)]

Fabrice,

Ping to make sure that this blocker is on your radar.

Comment 42

[Michael Vines [:m1] [:evilmachines]]

Well, so it seems we don't observe this issue anymore on v1.3.  Moving this to back to v1.3? for triage re-consideration.

Comment 43

[[:fabrice] Fabrice Desré]

Ted, I tried without success to add OOPInit() early enough while not breaking tests - no success so far (see also https://tbpl.mozilla.org/?tree=Try&rev=4c2087e60cef). Any idea how to fix that?

Comment 44

[Jason Smith [:jsmith]]

(In reply to Michael Vines [:m1] [:evilmachines] from comment #42)
> Well, so it seems we don't observe this issue anymore on v1.3.  Moving this
> to back to v1.3? for triage re-consideration.

Moving to blocking- then.

Comment 45

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

I saw this multiple times with debug builds on my keon today, on m-c, and I had to comment out the assertion locally as a workaround.  It seemed to be reliably reproducible.  I was running with profiling enabled, which may be relevant.

Comment 46

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

I also saw this many times on Nexus-4.

Comment 47

[Preeti Raghunath(:Preeti)]

Fabrice,

Please have this on your radar.

Can you request approval using approval flags?

Comment 48

[Andrea Marchesini [:baku]]

Attachment: patch for NS_IsMainThread

This patch fixes the MOZ_ASSERT(NS_IsMainThread()) when XPCOM is not initialized yet, but maybe... it's a bit... dirty... ?

Comment 49

[Andrea Marchesini [:baku]]

May patch works just for b2g. We need to find a better solution.

Comment 50

[[:fabrice] Fabrice Desré]

(In reply to Andrea Marchesini (:baku) from comment #49)
> May patch works just for b2g. We need to find a better solution.

Yep, I tried a number of variations too, and there was always a test failing here or there (damn JP tests!)

Comment 51

[[:fabrice] Fabrice Desré]

Comment on attachment 8370821 [details] [diff] [review]
patch for NS_IsMainThread

Review of attachment 8370821 [details] [diff] [review]:
-----------------------------------------------------------------

This is even scarier than mine!

Comment 53

[Dave Hylands [:dhylands]]

I see this on the latest master on my hamachi.

This patch: https://bugzilla.mozilla.org/attachment.cgi?id=8410708 (from bug 999864) will cause b2g to crash, which will then cause the crash reporter to ASSERT and go into a reboot loop.

Reproduces 100%

Comment 54

[Dave Hylands [:dhylands]]

And I mentioned this in bug 999280, removing /data/b2g/mozilla/Crash Reports/LastCrashFilename will cause the reboot loop to stop and the phone will continue to boot normally.

Comment 55

[(not currently active) Ted Mielczarek]

Attachment: Call OOPInit during startup

I hit this while testing some GMP tests, so I took a crack at fixing it. This seems to work fine. I reverted the change from bug 1039577 since calling this during startup should make further calls immaterial. (We should probably go through and remove other calls, I didn't do that.)

I know bsmedberg is on PTO for another week or so, but he should review this.

I don't have a B2G tree handy right now, so if someone could test this on B2G to see if it fixes the issue there that'd be great.

Comment 56

[Kartikaya Gupta (email:[e-mail])]

I haven't seen this crash on B2G in a while so I was unable to check if it fixes it. However I applied the patch and B2G started normally, for whatever that's worth.

Comment 57

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

My phone is currently stuck on a reboot loop hitting this assertion.  I'm testing the patch now.

Comment 58

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

And it starts up with this patch.

Comment 59

[(not currently active) Ted Mielczarek]

If you want to r+ it, feel free. :)

Comment 60

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

That would require me to read it.  Maybe tomorrow.

Comment 61

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Comment on attachment 8460947 [details] [diff] [review]
Call OOPInit during startup

Review of attachment 8460947 [details] [diff] [review]:
-----------------------------------------------------------------

r=me

Comment 62

[(not currently active) Ted Mielczarek]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8613370d058a

Comment 63

[Nathan Froyd [:froydnj]]

I backed this out on suspicion of breaking tests:

https://tbpl.mozilla.org/php/getParsedLog.php?id=44641874&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=44641875&tree=Mozilla-Inbound

Apologies if it's not the right patch to back out, but it looks plausible enough.

https://hg.mozilla.org/integration/mozilla-inbound/rev/8613370d058a

Comment 64

[Nathan Froyd [:froydnj]]

(I should also note that I'm too stupid to know how to trigger Linux debug builds on the original push, or I would have done so.)

Comment 65

[(not currently active) Ted Mielczarek]

That looks pretty likely. I don't think I ran the e10s tests on this. I suspect the problem here is that plugin-container doesn't run the OOPInit code, and we wind up with a nested child process running GMP tests in e10s.

Comment 66

[Mike Habicher [:mikeh] (high bugzilla latency)]

Just saw this on a recent pull of b2g-inbound for Flame w/ v123.

MOZ_Assert: Assertion failure: OOPInitialized(), at ../../../../../m-c/b2g-inbound/toolkit/crashreporter/nsExceptionHandler.cpp:2235

Comment 67

[Mike Habicher [:mikeh] (high bugzilla latency)]

Attachment: Assertion failure on Flame v123 b2g-inbound

Comment 68

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Yes, we know it still happens.  That's why this bug is not resolved.

Ted, can you pick this back up again?  This is really obnoxious.

Comment 69

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #65)
> and we wind up with a nested child process running GMP tests in e10s.

See also bug 641685, in which we will eventually stop having nested children, but I don't know what the schedule for it is.

Comment 70

[(not currently active) Ted Mielczarek]

This should be fixable without a huge hassle. There are two possible fixes:
1) Put an OOPInit call somewhere in XRE_InitChildProcess after initializing in-process crash reporting.
2) Remove the bit of this patch that forced OOPInit to call itself on the main thread when called from elsewhere.

#2 seems like the simpler option.

Comment 71

[Benjamin Smedberg]

For the time being, we should probably just disable crash reporting for sub-subprocesses. I'm sure we can't actually use the data correctly.

Comment 72

[sb00349044]

Attachment: Flashed images and connected to wifi and click on browser.

Flashed images and connected to wifi and click on browser. On click on browse button. It is crashing. Please check the below logs.

                08-20 10:18:22.484 I/Gecko   (26056): ############################### browserElementPanning.js loaded

08-20 10:18:22.492 I/Gecko   (26056): ++DOMWINDOW == 4 (0x495a4240) [pid = 26056] [serial = 4] [outer = 0x495a3ca0]

08-20 10:18:22.523 I/Gecko   (26056): ######################## BrowserElementChildPreload.js loaded

08-20 10:18:22.554 I/Gecko   (26056): *** UTM:SVC TimerManager:registerTimer - id: user-agent-updates-timer

08-20 10:18:22.554 E/GeckoConsole(26056): UTM:SVC TimerManager:registerTimer - id: user-agent-updates-timer

08-20 10:18:22.609 I/Gecko   (26056): -*- Webapps.jsm : getCSPByLocalId:1002

08-20 10:18:22.656 I/Gecko   (26056): ++DOMWINDOW == 5 (0x495a4420) [pid = 26056] [serial = 5] [outer = 0x495a3ca0]

08-20 10:18:22.687 F/MOZ_Assert(26056): Assertion failure: OOPInitialized(), at /home/techm/surya/suryabuild/27_feb_build/home/techm/marvell/gecko/toolkit/crashreporter/nsExceptionHandler.cpp:2179

08-20 10:18:23.156 D/AndroidRuntime(26523):   

I am unable to browse internet in browser.

Comment 73

[Dave Hylands [:dhylands]]

I'm seeing this on flame debug builds.

In this case its crashing in the main thread of the parent process, and not a child process.

Here's the backtrace:

> #0  CrashReporter::GetPendingDir (dir=0xbef5f438) at ../../../b2g-inbound/toolkit/crashreporter/nsExceptionHandler.cpp:2343
> #1  0xb5579e18 in CrashReporter::MoveToPending (dumpFile=0xafa6c110, extraFile=0xafa6c1a0) at ../../../b2g-inbound/toolkit/crashreporter/nsExceptionHandler.cpp:2562
> #2  0xb557a0c6 in CrashReporter::CheckForLastRunCrash () at ../../../b2g-inbound/toolkit/crashreporter/nsExceptionHandler.cpp:2890
> #3  0xb557a184 in CrashReporter::GetLastRunCrashID (id=...) at ../../../b2g-inbound/toolkit/crashreporter/nsExceptionHandler.cpp:2902
> #4  0xb556ea9a in nsXULAppInfo::GetLastRunCrashID (this=<optimized out>, aLastRunCrashID=<optimized out>) at ../../../b2g-inbound/toolkit/xre/nsAppRunner.cpp:882
> #5  0xb4447056 in NS_InvokeByIndex (that=<optimized out>, methodIndex=15, paramCount=<optimized out>, params=<optimized out>)
>     at ../../../../../../b2g-inbound/xpcom/reflect/xptcall/md/unix/xptcinvoke_arm.cpp:164
> #6  0xb4789bca in Invoke (this=0xbef5f5c0) at ../../../../b2g-inbound/js/xpconnect/src/XPCWrappedNative.cpp:2369
> #7  CallMethodHelper::Call (this=0xbef5f5c0) at ../../../../b2g-inbound/js/xpconnect/src/XPCWrappedNative.cpp:1730
> #8  0xb478a922 in XPCWrappedNative::CallMethod (ccx=..., mode=<optimized out>) at ../../../../b2g-inbound/js/xpconnect/src/XPCWrappedNative.cpp:1697
> #9  0xb478ac12 in GetAttribute (ccx=...) at ../../../../b2g-inbound/js/xpconnect/src/xpcprivate.h:2158
> #10 XPC_WN_GetterSetter (cx=0xb1a058a0, argc=<optimized out>, vp=<optimized out>) at ../../../../b2g-inbound/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1324
> #11 0xb5b2613c in js::CallJSNative (cx=0xb1a058a0, native=0xb478aabd <XPC_WN_GetterSetter(JSContext*, unsigned int, JS::Value*)>, args=...) at ../../../b2g-inbound/js/src/jscntxtinlines.h:231
> #12 0xb5b55236 in js::Invoke (cx=0xb1a058a0, args=..., construct=js::NO_CONSTRUCT) at ../../../b2g-inbound/js/src/vm/Interpreter.cpp:481
> #13 0xb5b55ac0 in js::Invoke (cx=0xb1a058a0, thisv=..., fval=..., argc=0, argv=0x0, rval=...) at ../../../b2g-inbound/js/src/vm/Interpreter.cpp:537
> #14 0xb5b55bee in js::InvokeGetterOrSetter (cx=<optimized out>, obj=0xb18bb560, fval=..., argc=0, argv=0x0, rval=...) at ../../../b2g-inbound/js/src/vm/Interpreter.cpp:609
> #15 0xb5acb498 in js::Shape::get (this=0xb1d8cc28, cx=0xb1a058a0, receiver=..., obj=<optimized out>, pobj=0xb18bb560, vp=...) at ../../../b2g-inbound/js/src/vm/Shape-inl.h:46
> #16 0xb5acb550 in NativeGetInline<(js::AllowGC)1> (cx=0xb1a058a0, obj=..., receiver=..., pobj=..., shape=..., vp=...) at ../../../b2g-inbound/js/src/jsobj.cpp:4833
> #17 0xb5ade2aa in GetPropertyHelperInline<(js::AllowGC)1> (cx=<optimized out>, obj=..., receiver=..., id=..., vp=...) at ../../../b2g-inbound/js/src/jsobj.cpp:5028
> #18 0xb5b4cf54 in GetPropertyOperation (vp=<optimized out>, lval=<optimized out>, pc=<optimized out>, script=<optimized out>, fp=<optimized out>, cx=<optimized out>)
>     at ../../../b2g-inbound/js/src/vm/Interpreter.cpp:251
> #19 Interpret (cx=0xb1a058a0, state=...) at ../../../b2g-inbound/js/src/vm/Interpreter.cpp:2397
> #20 0xb5b54a46 in js::RunScript (cx=0xb1a058a0, state=...) at ../../../b2g-inbound/js/src/vm/Interpreter.cpp:428
> #21 0xb5b551f0 in js::Invoke (cx=0xb1a058a0, args=..., construct=js::NO_CONSTRUCT) at ../../../b2g-inbound/js/src/vm/Interpreter.cpp:500
> #22 0xb5b55ac0 in js::Invoke (cx=0xb1a058a0, thisv=..., fval=..., argc=1, argv=0xbef608b8, rval=...) at ../../../b2g-inbound/js/src/vm/Interpreter.cpp:537
> #23 0xb5a90538 in JS::Call (cx=<optimized out>, thisv=..., fval=..., args=<optimized out>, rval=...) at ../../../b2g-inbound/js/src/jsapi.cpp:4994
> #24 0xb4ae09c8 in mozilla::dom::EventListener::HandleEvent (this=<optimized out>, cx=0xb1a058a0, aThisVal=<optimized out>, event=..., aRv=...) at EventListenerBinding.cpp:47
> #25 0xb4d5e34e in mozilla::dom::EventListener::HandleEvent<mozilla::dom::EventTarget*> (this=0xaf84bc00, thisObjPtr=<optimized out>, event=..., aRv=..., 
>     aExceptionHandling=mozilla::dom::CallbackObject::eReportExceptions) at ../../dist/include/mozilla/dom/EventListenerBinding.h:54
> #26 0xb4d5e418 in mozilla::EventListenerManager::HandleEventSubType (this=0xaf508ac0, aListener=<optimized out>, aDOMEvent=0xafa912c0, aCurrentTarget=0xaf6cb940)
>     at ../../../b2g-inbound/dom/events/EventListenerManager.cpp:945
> #27 0xb4d5e56e in mozilla::EventListenerManager::HandleEventInternal (this=0xaf508ac0, aPresContext=0xb1694000, aEvent=0xb010bd80, aDOMEvent=0xbef60bc4, aCurrentTarget=0xaf6cb940, 
>     aEventStatus=0xbef60bc8) at ../../../b2g-inbound/dom/events/EventListenerManager.cpp:1009
> #28 0xb4d5e746 in HandleEvent (aEventStatus=0xbef60bc8, aCurrentTarget=0xaf6cb940, aDOMEvent=0xbef60bc4, aEvent=<optimized out>, aPresContext=<optimized out>, this=<optimized out>)
>     at ../../dist/include/mozilla/EventListenerManager.h:329
> #29 mozilla::EventTargetChainItem::HandleEvent (this=<optimized out>, aVisitor=..., aCd=<optimized out>) at ../../../b2g-inbound/dom/events/EventDispatcher.cpp:203
> #30 0xb4d5e96a in mozilla::EventTargetChainItem::HandleEventTargetChain (aChain=..., aVisitor=..., aCallback=0x0, aCd=...) at ../../../b2g-inbound/dom/events/EventDispatcher.cpp:293
> #31 0xb4d5efb6 in mozilla::EventDispatcher::Dispatch (aTarget=<optimized out>, aPresContext=<optimized out>, aEvent=0xb010bd80, aDOMEvent=0xafa912c0, aEventStatus=0xbef60c74, aCallback=0x0, 
>     aTargets=0x0) at ../../../b2g-inbound/dom/events/EventDispatcher.cpp:607
> #32 0xb4d5f33a in mozilla::EventDispatcher::DispatchDOMEvent (aTarget=0xaf6cb940, aEvent=<optimized out>, aDOMEvent=0xafa912c0, aPresContext=0xb1694000, aEventStatus=0xbef60c74)
>     at ../../../b2g-inbound/dom/events/EventDispatcher.cpp:674
> #33 0xb4fed14e in nsINode::DispatchEvent (this=0xaf6cb940, aEvent=0xafa912c0, aRetVal=0xbef60c97) at ../../../../b2g-inbound/content/base/src/nsINode.cpp:1284
> #34 0xb4fe6da4 in mozilla::dom::EventTarget::DispatchEvent (this=<optimized out>, aEvent=<optimized out>, aRv=...) at ../../../../b2g-inbound/content/base/src/nsINode.cpp:2740
> #35 0xb4ac8d14 in dispatchEvent (args=..., self=0xaf6cb940, cx=0xb2893340, obj=<optimized out>) at EventTargetBinding.cpp:166
> #36 mozilla::dom::EventTargetBinding::dispatchEvent (cx=0xb2893340, obj=<optimized out>, self=0xaf6cb940, args=...) at EventTargetBinding.cpp:146
> #37 0xb4ad10f6 in mozilla::dom::EventTargetBinding::genericMethod (cx=0xb2893340, argc=<optimized out>, vp=<optimized out>) at EventTargetBinding.cpp:349
> #38 0xb5b2613c in js::CallJSNative (cx=0xb2893340, native=0xb4ad0f9d <mozilla::dom::EventTargetBinding::genericMethod(JSContext*, unsigned int, JS::Value*)>, args=...)
>     at ../../../b2g-inbound/js/src/jscntxtinlines.h:231
> #39 0xb5b55236 in js::Invoke (cx=0xb2893340, args=..., construct=js::NO_CONSTRUCT) at ../../../b2g-inbound/js/src/vm/Interpreter.cpp:481
> #40 0xb5b55ac0 in js::Invoke (cx=0xb2893340, thisv=..., fval=..., argc=1, argv=0xb29cb158, rval=...) at ../../../b2g-inbound/js/src/vm/Interpreter.cpp:537
> #41 0xb5ac681a in js::DirectProxyHandler::call (this=<optimized out>, cx=<optimized out>, proxy=<optimized out>, args=...) at ../../../b2g-inbound/js/src/jsproxy.cpp:473
> #42 0xb5ad9850 in js::CrossCompartmentWrapper::call (this=0xb6679568, cx=0xb2893340, wrapper=..., args=...) at ../../../b2g-inbound/js/src/jswrapper.cpp:431
> #43 0xb5add212 in js::Proxy::call (cx=<optimized out>, proxy=..., args=...) at ../../../b2g-inbound/js/src/jsproxy.cpp:2502
> #44 0xb5add2b0 in js::proxy_Call (cx=0xb2893340, argc=<optimized out>, vp=<optimized out>) at ../../../b2g-inbound/js/src/jsproxy.cpp:2897
> #45 0xb5b2613c in js::CallJSNative (cx=0xb2893340, native=0xb5add259 <js::proxy_Call(JSContext*, unsigned int, JS::Value*)>, args=...) at ../../../b2g-inbound/js/src/jscntxtinlines.h:231
> #46 0xb5b55300 in js::Invoke (cx=0xb2893340, args=..., construct=js::NO_CONSTRUCT) at ../../../b2g-inbound/js/src/vm/Interpreter.cpp:474
> #47 0xb5b52596 in Interpret (cx=0xb2893340, state=...) at ../../../b2g-inbound/js/src/vm/Interpreter.cpp:2563
> #48 0xb5b54a46 in js::RunScript (cx=0xb2893340, state=...) at ../../../b2g-inbound/js/src/vm/Interpreter.cpp:428
> #49 0xb5b551f0 in js::Invoke (cx=0xb2893340, args=..., construct=js::NO_CONSTRUCT) at ../../../b2g-inbound/js/src/vm/Interpreter.cpp:500
> ---Type <return> to continue, or q <return> to quit---
> #50 0xb5a9f68a in js_fun_apply (cx=0xb2893340, argc=<optimized out>, vp=0xb29cb058) at ../../../b2g-inbound/js/src/jsfun.cpp:1325
> #51 0xb5b2613c in js::CallJSNative (cx=0xb2893340, native=0xb5a9f549 <js_fun_apply(JSContext*, unsigned int, JS::Value*)>, args=...) at ../../../b2g-inbound/js/src/jscntxtinlines.h:231
> #52 0xb5b55236 in js::Invoke (cx=0xb2893340, args=..., construct=js::NO_CONSTRUCT) at ../../../b2g-inbound/js/src/vm/Interpreter.cpp:481
> #53 0xb5b52596 in Interpret (cx=0xb2893340, state=...) at ../../../b2g-inbound/js/src/vm/Interpreter.cpp:2563
> #54 0xb5b54a46 in js::RunScript (cx=0xb2893340, state=...) at ../../../b2g-inbound/js/src/vm/Interpreter.cpp:428
> #55 0xb5b551f0 in js::Invoke (cx=0xb2893340, args=..., construct=js::NO_CONSTRUCT) at ../../../b2g-inbound/js/src/vm/Interpreter.cpp:500
> #56 0xb5b55ac0 in js::Invoke (cx=0xb2893340, thisv=..., fval=..., argc=1, argv=0xbef63600, rval=...) at ../../../b2g-inbound/js/src/vm/Interpreter.cpp:537
> #57 0xb5a905e8 in JS_CallFunctionValue (cx=<optimized out>, obj=..., fval=..., args=<optimized out>, rval=...) at ../../../b2g-inbound/js/src/jsapi.cpp:4982
> #58 0xb4fd80e6 in nsFrameMessageManager::ReceiveMessage (this=0xaf508a60, aTarget=0xaf6cb940, aMessage=..., aIsSync=<optimized out>, aCloneData=0xbef636c0, aCpows=0xbef636cc, aPrincipal=0x0, 
>     aJSONRetVal=0x0) at ../../../../b2g-inbound/content/base/src/nsFrameMessageManager.cpp:1062
> #59 0xb4fd840a in nsSameProcessAsyncMessageBase::ReceiveMessage (this=0xafebdb0c, aTarget=0xaf6cb940, aManager=0xaf508a60) at ../../../../b2g-inbound/content/base/src/nsFrameMessageManager.cpp:1959
> #60 0xb4ff17c2 in Run (this=0xafebdb00) at ../../../../b2g-inbound/content/base/src/nsInProcessTabChildGlobal.cpp:77
> #61 nsAsyncMessageToParent::Run (this=0xafebdb00) at ../../../../b2g-inbound/content/base/src/nsInProcessTabChildGlobal.cpp:69
> #62 0xb4440370 in nsThread::ProcessNextEvent (this=0xb6a4a740, aMayWait=<optimized out>, aResult=0xbef6377f) at ../../../b2g-inbound/xpcom/threads/nsThread.cpp:823
> #63 0xb44548c0 in NS_ProcessNextEvent (aThread=0xb6a4a740, aMayWait=<optimized out>) at /home/work/B2G-flame/b2g-inbound/xpcom/glue/nsThreadUtils.cpp:265
> #64 0xb4606660 in mozilla::ipc::MessagePump::Run (this=0xb6a8a040, aDelegate=0xb6a7a1a0) at ../../../b2g-inbound/ipc/glue/MessagePump.cpp:99
> #65 0xb45f421e in MessageLoop::RunInternal (this=0xb6a7a1a0) at ../../../b2g-inbound/ipc/chromium/src/base/message_loop.cc:229
> #66 0xb45f4236 in RunHandler (this=0xb6a7a1a0) at ../../../b2g-inbound/ipc/chromium/src/base/message_loop.cc:222
> #67 MessageLoop::Run (this=0xb6a7a1a0) at ../../../b2g-inbound/ipc/chromium/src/base/message_loop.cc:196
> #68 0xb4f36cb2 in nsBaseAppShell::Run (this=0xb290d460) at ../../../b2g-inbound/widget/xpwidgets/nsBaseAppShell.cpp:164
> #69 0xb5556b9e in nsAppStartup::Run (this=0xb2945f10) at ../../../../b2g-inbound/toolkit/components/startup/nsAppStartup.cpp:280
> #70 0xb5573954 in XREMain::XRE_mainRun (this=0xbef6390c) at ../../../b2g-inbound/toolkit/xre/nsAppRunner.cpp:4101
> #71 0xb5573bbc in XREMain::XRE_main (this=0xbef6390c, argc=<optimized out>, argv=<optimized out>, aAppData=<optimized out>) at ../../../b2g-inbound/toolkit/xre/nsAppRunner.cpp:4172
> #72 0xb5573d30 in XRE_main (argc=1, argv=0xb6a3b188, aAppData=0x248f4, aFlags=<optimized out>) at ../../../b2g-inbound/toolkit/xre/nsAppRunner.cpp:4386
> #73 0x0000b382 in do_main (argc=1, argv=0xb6a3b188) at ../../../b2g-inbound/b2g/app/nsBrowserApp.cpp:165
> #74 0x0000b4aa in b2g_main (argc=1, argv=0xbef64b44) at ../../../b2g-inbound/b2g/app/nsBrowserApp.cpp:291
> #75 0x0000b216 in RunProcesses (argv=0xbef64b44, argc=1) at ../../../b2g-inbound/b2g/app/B2GLoader.cpp:221
> #76 main (argc=1, argv=0xbef64b44) at ../../../b2g-inbound/b2g/app/B2GLoader.cpp:247

Comment 74

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Since this bug has been open for nearly two years with no end in sight, I disabled the assertion.

https://hg.mozilla.org/integration/b2g-inbound/rev/5e25259d39e2

Comment 75

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/5e25259d39e2

Comment 76

[BMO Automation]

Firefox OS is not being worked on