Closed Bug 820716 Opened 8 years ago Closed 3 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: cjones, Assigned: ted)

References

Details

(Keywords: leave-open)

Attachments

(4 files, 5 obsolete files)

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.
(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.
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.
It's baaaaaaaaaaaaack.

This is now happening when the b2g emulator crashes (m-c as of 2013/07/10), when running debug/noopt.
Small change: Line number is now 1927.
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
OS: Linux → Gonk (Firefox OS)
Priority: -- → P1
Hardware: x86_64 → ARM
Severity: normal → critical
Any update on this ?
Flags: needinfo?(fabrice)
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.
Ni :mwu to see if he has any idea what may be going on here.
Flags: needinfo?(mwu)
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.
Flags: needinfo?(fabrice)
I don't have any ideas off the top of my head.
Flags: needinfo?(mwu)
(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.
Flags: needinfo?(fabrice)
Fabrice,

Can you please point out where we are with the bug?
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
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 .
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.
Flags: needinfo?(fabrice)
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...
Attached patch crash-reports-race.patch (obsolete) — Splinter Review
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.
Assignee: nobody → fabrice
Attachment #8339644 - Flags: feedback?(tkundu)
thanks for your help :) . I will test it today and let you know soon :)
Comment on attachment 8339644 [details] [diff] [review]
crash-reports-race.patch

It runs fine in my test. Thanks a lot for your help. :)
Attachment #8339644 - Flags: feedback+
blocking-b2g: --- → 1.3?
Attachment #8339644 - Flags: feedback?(tkundu)
Attachment #8339644 - Flags: feedback?
Attachment #8339644 - Flags: feedback+
blocking-b2g: 1.3? → 1.3+
Attached patch crash-reports-race.patch (obsolete) — Splinter Review
Attachment #8339644 - Attachment is obsolete: true
Attachment #8339644 - Flags: feedback?
Attachment #8340872 - Flags: review?(ted)
Attachment #8340872 - Flags: review?(21)
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 ?
Attachment #8340872 - Flags: review?(21)
Attached patch crash-reports-race.patch v2 (obsolete) — Splinter Review
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).
Attachment #8340872 - Attachment is obsolete: true
Attachment #8340872 - Flags: review?(ted)
Attachment #8341221 - Flags: review?(ted)
Attachment #8341221 - Flags: review?(21)
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.
Attachment #8341221 - Flags: review?(21) → review+
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.
Attachment #8340872 - Attachment is obsolete: false
Attachment #8340872 - Attachment is obsolete: true
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.
Attachment #8341221 - Flags: review?(ted) → review+
Attached patch race-crashreport.patch v3 (obsolete) — Splinter Review
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.
Attachment #8341221 - Attachment is obsolete: true
Attachment #8342061 - Flags: review?(ted)
Flags: needinfo?(tkundu)
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. :)
Attachment #8342061 - Flags: review?(ted) → review+
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)
Attachment #8342061 - Flags: review+ → review-
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.
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?
Flags: needinfo?(ted)
(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
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?
Flags: needinfo?(ted) → needinfo?(benjamin)
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.
Flags: needinfo?(benjamin)
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.
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 :(
Flags: needinfo?(ted)
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.)
Flags: needinfo?(ted)
Ted,

Is comment 37 a potential solution? What is the ETA for the fix?
Flags: needinfo?(ted)
I believe it is, that's why I suggested it. I'm not intending to fix this, that comment was for Fabrice.
Flags: needinfo?(ted)
Yep, I'm still on it. My latest try didn't end up well either (https://tbpl.mozilla.org/?tree=Try&rev=037a466190a4)
Fabrice,

Ping to make sure that this blocker is on your radar.
Flags: needinfo?(fabrice)
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.
blocking-b2g: 1.3+ → 1.3?
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?
Flags: needinfo?(fabrice)
(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.
blocking-b2g: 1.3? → -
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.
I also saw this many times on Nexus-4.
blocking-b2g: - → 1.3?
Fabrice,

Please have this on your radar.

Can you request approval using approval flags?
Flags: needinfo?(fabrice)
blocking-b2g: 1.3? → ---
Attached patch patch for NS_IsMainThread (obsolete) — Splinter Review
This patch fixes the MOZ_ASSERT(NS_IsMainThread()) when XPCOM is not initialized yet, but maybe... it's a bit... dirty... ?
Attachment #8370821 - Flags: feedback?(fabrice)
May patch works just for b2g. We need to find a better solution.
(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!)
Flags: needinfo?(fabrice)
Comment on attachment 8370821 [details] [diff] [review]
patch for NS_IsMainThread

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

This is even scarier than mine!
Attachment #8370821 - Flags: feedback?(fabrice) → feedback-
Blocks: 975867
Duplicate of this bug: 999280
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%
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.
Blocks: 1019088
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.
Attachment #8460947 - Flags: review?(benjamin)
Assignee: fabrice → ted
Status: NEW → ASSIGNED
Attachment #8342061 - Attachment is obsolete: true
Attachment #8370821 - Attachment is obsolete: true
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.
My phone is currently stuck on a reboot loop hitting this assertion.  I'm testing the patch now.
Blocks: 1038262
If you want to r+ it, feel free. :)
That would require me to read it.  Maybe tomorrow.
Comment on attachment 8460947 [details] [diff] [review]
Call OOPInit during startup

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

r=me
Attachment #8460947 - Flags: review?(benjamin) → review+
(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.)
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.
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
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.
Flags: needinfo?(ted)
(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.
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.
Flags: needinfo?(ted)
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.
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
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
Keywords: leave-open
Firefox OS is not being worked on
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.