Closed Bug 1106610 Opened 10 years ago Closed 10 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: 10 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.