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)
Tracking
()
RESOLVED
DUPLICATE
of bug 1155789
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...
Reporter | ||
Updated•9 years ago
|
tracking-e10s:
--- → ?
Component: General → DOM: Content Processes
Reporter | ||
Comment 1•9 years ago
|
||
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
Reporter | ||
Comment 2•9 years ago
|
||
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".
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.
Reporter | ||
Comment 5•9 years ago
|
||
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.
![]() |
||
Updated•9 years ago
|
Assignee: wmccloskey → jmathies
![]() |
||
Comment 6•9 years ago
|
||
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
Summary: Firefox nightly (e10s) crashes immediately after startup → Startup crash in mozilla::jsipc::JavaScriptShared::toVariant(JSContext*, JS::Handle<JS::Value>, mozilla::jsipc::JSVariant*)
![]() |
||
Updated•9 years ago
|
Assignee: jmathies → nobody
Reporter | ||
Comment 7•9 years ago
|
||
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 ;)
![]() |
||
Comment 8•9 years ago
|
||
(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.
Updated•9 years ago
|
Reporter | ||
Comment 9•8 years ago
|
||
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
Reporter | ||
Comment 10•8 years ago
|
||
I guess this maybe is just caused as the parent process died, right? Here are a few current crash IDs: https://crash-stats.mozilla.com/report/index/caf764be-d69b-484f-b4b6-950342150417 https://crash-stats.mozilla.com/report/index/42c47ad5-4e22-4c68-9456-942b42150417 https://crash-stats.mozilla.com/report/index/a0a76888-f259-4c0b-a0a9-e871d2150417 https://crash-stats.mozilla.com/report/index/4827d6fd-46e2-4970-9571-326d32150417 https://crash-stats.mozilla.com/report/index/15d6e76f-94a2-40f7-9a0f-4336c2150417 I cannot find them with the link in Comment 6 so did the crash change location?
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → mconley
This should have been fixed by bug 1155789, although it might just throw an exception instead.
Comment 12•8 years ago
|
||
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.
Description
•