59 bytes, text/x-review-board-request
This bug was filed from the Socorro interface and is report bp-732ced99-848f-4ba3-963f-219152161207. ============================================================= The container issues from bug 1317611 seem to have been fully fixed by bug 1315905, but we still get a few of them with a null load context. It's possible all of the crashes come from the same user. I suspect that this is because of an addon: (100.0% in signature vs 00.12% overall) Addon "Diccionario español México" = true (100.0% in signature vs 01.29% overall) Addon "Xmarks Sync" = true (100.0% in signature vs 02.41% overall) Addon "SQLite Manager" = true (83.33% in signature vs 00.04% overall) Addon "easy Xdebug (with moveable icon)" = true (83.33% in signature vs 00.35% overall) Addon "The easiest Xdebug" = true (83.33% in signature vs 00.57% overall) Addon "FavIcon Reloader up to FF 48 only" = true (83.33% in signature vs 01.44% overall) Addon "µBlock" = true
Top #2 of Nightly 20170611100318 on Linux, there are 21 reports from 6 installations in the past week.
Crash Signature: [@ mozilla::net::CrashWithReason] → [@ mozilla::net::CrashWithReason] [@ mozilla::net::NeckoParent::GetValidatedOriginAttributes]
Most of the comments mention clicking a link to open a PDF
What we need here is to identify the reason why the SerializedLoadContext is null. I intend to land a patch that changes HttpChannelChild to (diagnostic) assert that it is not null, thus crashing only the child process, and maybe it could get us a nice stack trace to find the culprit.
Assignee: nobody → valentin.gosu
Whiteboard: [necko-next] → [necko-active]
This is probably just one user that has the pref turned on for some reason, and is crashing. The patch should show us why he is crashing (likely an addon). However, this assertion will prove useful post-57 when we'll try to make the changes Jason suggested in bug 1306801 comment 4.
(In reply to Valentin Gosu [:valentin] from comment #6) > The patch should show us why he is crashing (likely an addon). However, this The built-in pdfium. I do not have all addons from comment 0. My webext-only addons: 1) IPvFoo 2) Redirector 3) uBlock Origin 4) uMatrix No plugins (as you can see in the prefs). how to get 1) 1. https://addons.mozilla.org/firefox/addon/chrome-store-foxified/ 2. save as xpi file: https://chrome.google.com/webstore/detail/ipvfoo/ecanpcehffngcegjmadlcijfolapggal (it's like IPvFox, but a webextension) and import from file into about:addons 2) https://addons.mozilla.org/firefox/addon/redirector/ how to get 3) I opened https://github.com/gorhill/uBlock/issues/2576 because uBlock Origin has the Legacy badge. "The webext version of uBO is a hybrid, a webext wrapped into a thin layer legacy one, necessary for a seamless transition." So I go to https://github.com/gorhill/uBlock/releases Ctrl+F: webext.xpi Download, unzip, go into the "webextension" folder, select all, zip, import into about:addons from file. 4) Same as 3, https://github.com/gorhill/uMatrix/releases
network.disable.ipc.security;false (default=true) https://gopherproxy.meulie.net/ygrex.ru/h/debian/firefox-security.html > Interprocess security checks (disabled by default per bug 820712): > network.disable.ipc.security=false I just thought that "disabling" "security" is needed for some old addons or plugins, so I set it to false. "Security checks" sounded good. (In reply to Valentin Gosu [:valentin] from comment #6) > useful post-57 when we'll try to make the changes Jason suggested in bug 1306801 comment 4. Then I will reset that pref for now. Thank you.
Comment on attachment 8877563 [details] Bug 1322610 - MOZ_DIAGNOSTIC_ASSERT that serialized load context is not null in HttpChannelChild https://reviewboard.mozilla.org/r/149046/#review154068 valentin, I'm ok with this if it will help move things forward.. but it sounds like you may have found a user to repro and don't need it?
Attachment #8877563 - Flags: review?(mcmanus) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/016bcae14073 MOZ_DIAGNOSTIC_ASSERT that serialized load context is not null in HttpChannelChild r=mcmanus
(In reply to Patrick McManus [:mcmanus] from comment #10) > Comment on attachment 8877563 [details] > Bug 1322610 - MOZ_DIAGNOSTIC_ASSERT that serialized load context is not null > in HttpChannelChild > > https://reviewboard.mozilla.org/r/149046/#review154068 > > valentin, I'm ok with this if it will help move things forward.. but it > sounds like you may have found a user to repro and don't need it? Thanks for the review. This will be useful when we land 1306801, to ensure we aren't missing load context in the child.
IIUC, this crash is Nightly-only? Also, should this bug have been closed? Looks like it was just a diagnostic patch that landed.
(In reply to Ryan VanderMeulen [:RyanVM] from comment #14) > IIUC, this crash is Nightly-only? Also, should this bug have been closed? > Looks like it was just a diagnostic patch that landed. comment 7 revealed that why this crash is happening. The patch we landed will prove useful once we try to remove the pref and have the default be to always enforce having a correct serializedLoadInfo. Since we can only get this crash by fiddling with these prefs, I think we can ignore the crash for now, and address these issues in bug 1306801 in fx57.
You need to log in before you can comment on or make changes to this bug.