Closed Bug 1106610 Opened 9 years ago Closed 8 years ago

Startup crash in mozilla::jsipc::JavaScriptShared::toVariant(JSContext*, JS::Handle<JS::Value>, mozilla::jsipc::JSVariant*)

Categories

(Core :: DOM: Content Processes, defect)

Product:
Core
Component:
DOM: Content Processes
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1155789
Tracking Flags:
Tracking Status
e10s m7+ ---

People

(Reporter: Manuel.Spam, Assigned: mconley)

Details

(Keywords: crash) 

Hello,

I tried to discuss this on the "Firefox development" mailing list, but moderation makes it extremely slow to get progress there.

Here are some of my "crash ids":
bp-2f180377-7ebc-4b78-bb59-f1f762141130    11/30/2014    04:52 PM
bp-77a41c0b-4c7a-40bd-aad4-20e5f2141130    11/30/2014    04:50 PM
bp-5d4a0889-c245-4651-a4e0-0d0692141130    11/30/2014    04:50 PM
bp-e69fc6e6-c74d-45a3-8584-5dfa12141130    11/30/2014    04:50 PM
bp-5dcdec00-6b4e-406b-848a-4e2052141130    11/30/2014    04:50 PM
bp-e15d9cb5-b437-41d2-9b43-901172141130    11/30/2014    04:48 PM
bp-ef1aaa76-b131-4ed9-85a9-9b1a52141125    11/25/2014    09:20 PM
bp-5abc486a-e9ba-4170-b201-69e832141125    11/25/2014    09:19 PM
bp-fff091ab-4942-4571-810f-c2c7e2141125    11/25/2014    09:15 PM
bp-9f42d817-802d-4144-a139-a639a2141125    11/25/2014    09:08 PM
bp-e28b8a53-32f4-4220-be6a-0cf1f2141125    11/25/2014    09:07 PM
bp-1bc1f1bf-7254-4b3e-8686-478252141125    11/25/2014    09:04 PM
bp-4590c5cd-cda3-4d6e-a9d2-117e42141125    11/25/2014    09:03 PM
bp-58c31494-eb1e-49a1-9320-6baed2141125    11/25/2014    09:02 PM
bp-6a85da97-33c1-46cb-aafe-e45b52141125    11/25/2014    09:02 PM 

I get them over and over again. Sometimes it helps to just kill "prefs.js" to at least get one successful startup but Firefox crashes again with the next browser restart...
tracking-e10s: --- → ?
Component: General → DOM: Content Processes
I'm almost sure that this is caused by my current development version of PrefBar. I currently try to find a way how code in PrefBar buttons can still access DOM on websites. This all worked well until the switch to "separate processes for each tab". You can see my first tries, to get e10s compatible, here:

http://git.tuxfamily.org/?p=prefbar/main.git;a=commitdiff;h=926e7c8
The following lines seem to cause the trouble:

http://git.tuxfamily.org/?p=prefbar/main.git;a=blob;f=content/goprefbar/main.js;h=2ac2eaa#l79

If I stop execution one step before this line, then I don't get the crash.

My "Include"-function is defined here:

http://git.tuxfamily.org/?p=prefbar/main.git;a=blob;f=components/goprefbar.js;h=98b026d#l50

So it seems like this is caused somewhere in the "subscript loader".
billm, sounds like a CPOW bug for you.
Flags: needinfo?(wmccloskey)
I'll take this in m4 since it's a startup crash. Hopefully it won't be too hard to fix. We can re-triage if it is.
Assignee: nobody → wmccloskey
tracking-e10s: ? → m4+
Flags: needinfo?(wmccloskey)
The crash seems to happen here:

http://git.tuxfamily.org/?p=prefbar/main.git;a=blob;f=content/prefbarOverlay.js;h=cfc5aa0#l824

The crash occurs as soon as I send my "asyncMessage" via the "browser message manager".

So there is a problem if someone uses "sendAsyncMessage" too early. I did so in the "load" event of the browser window, which seems to be too early. Maybe the browser isn't completely initialized at this point?

If I increase the timeout here:
http://git.tuxfamily.org/?p=prefbar/main.git;a=blob;f=content/prefbarOverlay.js;h=cfc5aa0#l148
from "zero" to "2000", then the crash is gone but it takes two seconds until the PrefBar buttons are placed to the toolbar.

This workaround helps me to finish my work with getting PrefBar e10s compatible and I hope it also helps you to track down the underlying problem.
Assignee: wmccloskey → jmathies
Severity: normal → critical
Keywords: crash
Over the past 7 days I see a total of two crashes in Nightly. Not sure why M4 is blocked by this?

https://crash-stats.mozilla.com/report/list?product=Firefox&signature=mozilla%3A%3Ajsipc%3A%3AJavaScriptShared%3A%3AtoVariant%28JSContext*%2C+JS%3A%3AHandle%3CJS%3A%3AValue%3E%2C+mozilla%3A%3Ajsipc%3A%3AJSVariant*%29
tracking-e10s: m4+ → ?
Summary: Firefox nightly (e10s) crashes immediately after startup → Startup crash in mozilla::jsipc::JavaScriptShared::toVariant(JSContext*, JS::Handle<JS::Value>, mozilla::jsipc::JSVariant*)
Assignee: jmathies → nobody
I think it is flagged as blocker because it is a reproducible crash bug? At least for me it is a show stopper as I can't get PrefBar to work on current Nightly builds...

But if it makes bugs more relevant if there are many crashes logged, then I'll keep trying every day now. Did so a few seconds ago. I tried for about ten times, just to be sure it realls still isn't fixed ;)
(In reply to Manuel Reimer from comment #7)
> I think it is flagged as blocker because it is a reproducible crash bug? At
> least for me it is a show stopper as I can't get PrefBar to work on current
> Nightly builds...
> 
> But if it makes bugs more relevant if there are many crashes logged, then
> I'll keep trying every day now. Did so a few seconds ago. I tried for about
> ten times, just to be sure it realls still isn't fixed ;)

Yes thanks, this sounds reasonable. Crashes that we can easily reproduce certainly should block. Whether or not this should block our internal m4 milestone is still questionable though.
I'm still trying to track this down... I've been trying to create a small extension, just triggering this error, for hours... For some reason it needs the full PrefBar code to trigger the bug.

If I ship PrefBar in the current form (with e10s-Support), then everyone, who uses nightly builds, will get those startup crashes.

Is it possible, that this isn't actually a "crash" but somehow internally triggered by intention?

On shell I can see:
[Child 5988] ###!!! ABORT: Aborting on channel error.: file /builds/slave/m-cen-l64-ntly-000000000000000/build/src/ipc/glue/MessageChannel.cpp, line 1621

And in this line I have:
http://mxr.mozilla.org/mozilla-central/source/ipc/glue/MessageChannel.cpp#1621
Assignee: nobody → mconley
This should have been fixed by bug 1155789, although it might just throw an exception instead.
Duping based on comment 11
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.