Firefox unexpectedly closes with: Missing chrome or resource URL
Categories
(Toolkit :: Telemetry, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox95 | --- | fixed |
People
(Reporter: lukas.bernhard, Assigned: bholley)
References
Details
(Keywords: nightly-community)
Attachments
(1 file)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0
Steps to reproduce:
No special UI interaction as far as I can tell.
Actual results:
Nighly unexpectedly closed with the following message printed on the console:
*** You are running in background task mode. ***
*** You are running in headless mode.
Missing chrome or resource URL: resource:///modules/backgroundtasks/BackgroundTask_pingsender.jsm
console.log: "pingsender: sending /home/user/.mozilla/firefox/hfxdm2xt.default-nightly-1/saved-telemetry-pings/d7d1f257-64a4-446c-a820-2f7e5272fd29 to https://incoming.telemetry.mozilla.org/submit/telemetry/d7d1f257-64a4-446c-a820-2f7e5272fd29/event/Firefox/95.0a1/nightly-asan/20211018095159?v=4"
console.log: "pingsender: sending /home/user/.mozilla/firefox/hfxdm2xt.default-nightly-1/saved-telemetry-pings/d08f67ed-a498-40f1-9bee-cff42e742146 to https://incoming.telemetry.mozilla.org/submit/telemetry/d08f67ed-a498-40f1-9bee-cff42e742146/main/Firefox/95.0a1/nightly-asan/20211018095159?v=4"
console.log: "pingsender: read payload
This is followed by a really long json payload which I can upload if helpful.
Reporter | ||
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Toolkit::Telemetry' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 2•3 years ago
|
||
The big JSON is likely unnecessary (though the "type" of the ping in the payload could be interesting), good choice on snipping it. It'll be removed shortly (bug 1736524).
The log is self-inconsistent: the console.logs are [coming from the file the earlier logs say is missing]( Missing chrome or resource URL: resource:///modules/backgroundtasks/BackgroundTask_pingsender.jsm). But it could be that the log is independent of the unexpected close, because bug 1736524 has the logs coming from otherwise-successful CI runs.
Did the unexpected close come with a crash report? about:crashes
should have a list sorted by date.
Reporter | ||
Comment 3•3 years ago
|
||
about:crashes is not available because I'm using the asan-nightly build. AFAIK asan reports are also found in ~/.mozilla/firefox/myprofile.default-nightly-1/asan/ but there is no recent entry. From the JSON, I get the following type:
{\"type\":\"event\",\"id\":\"d7d1f257-64a4-446c-a820-2f7e5272fd29\"
Comment 4•3 years ago
|
||
Thanks for your help. If the mentioned logs are the cause, they'll be taken care of by bug 1736623. :bholley, any ideas about the " Missing chrome or resource URL: resource:///modules/backgroundtasks/BackgroundTask_pingsender.jsm" parts of the logspam?
Comment 5•3 years ago
|
||
(In reply to Chris H-C :chutten from comment #4)
Thanks for your help. If the mentioned logs are the cause, they'll be taken care of by bug 1736623. :bholley, any ideas about the " Missing chrome or resource URL: resource:///modules/backgroundtasks/BackgroundTask_pingsender.jsm" parts of the logspam?
This is logging from bug 1721627 - something is trying to load that URL, but the URL doesn't exist. It should only cause crashes when the build is being run in automated tests though - from just reading the comments on this bug it's not clear to me if that code is causing the crash/close, nor is it clear to me if the build being discussed is being run under automated tests or not.
Assignee | ||
Comment 6•3 years ago
|
||
So, the issue here is that the background task machinery looks in several places for the specified JSM:
Gijs, thoughts on how we should square that with the machinery from bug 1721627?
Comment 7•3 years ago
•
|
||
(In reply to Bobby Holley (:bholley) from comment #6)
So, the issue here is that the background task machinery looks in several places for the specified JSM:
Gijs, thoughts on how we should square that with the machinery from bug 1721627?
Any of the following (in no particular order) would work, I believe:
- add some kind of opt-in flag to
Cu.import
that signs up to "yes, I know this might not exist, I'll deal with it", somehow (handwaves) ensure that's accessible in nsNetUtil, and use that - do a
fetch
first, as there's an exception for those already with the assumption that callers will handle failure. I wouldn't really recommend this as it'd be fairly inefficient. - add a condition to the
nsNetUtil.cpp
code that creates an exception for these patterns of files. - replace the "try it and fall back" mechanism in the loading code, and instead enumerate the JSMs in the 3 directories on first use of
findBackgroundTaskModule
(probably easiest tofetch
the directory and bodge parsing the resulting output), and build a map of what modules exist where (based on the directories, I don't think modules get added/removed at runtime, right?), so you can immediately import the right thing. - stop importing from anything except toolkit and the testing modules when under test - afaict the tree has no modules under
resource://app/backgroundtasks/
anyway.
(3) is definitely the easiest, and I wouldn't mind that. I don't have enough context as to why the code does what it does, rather than just importing from toolkit, where AFAICT all the existing modules already live? So I don't know how objectionable/workable some of the other suggestions would be.
Assignee | ||
Comment 8•3 years ago
|
||
Thanks, approach (3) sounds good. Attaching a patch.
Assignee | ||
Comment 9•3 years ago
|
||
Updated•3 years ago
|
Comment 10•3 years ago
|
||
Comment 11•3 years ago
|
||
bugherder |
Description
•