Closed Bug 1736431 Opened 3 years ago Closed 3 years ago

Firefox unexpectedly closes with: Missing chrome or resource URL

Categories

(Toolkit :: Telemetry, defect)

Firefox 95
defect

Tracking

()

RESOLVED FIXED
95 Branch
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.

Summary: Firefox unexpectedly closes with: Missing chrome or resource UR → Firefox unexpectedly closes with: Missing chrome or resource URL

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.

Component: Untriaged → Telemetry
Product: Firefox → Toolkit

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.

Flags: needinfo?(lukas.bernhard)

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\"
Flags: needinfo?(lukas.bernhard)

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?

Flags: needinfo?(bholley)
See Also: → 1736623
Blocks: 1736524

(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.

So, the issue here is that the background task machinery looks in several places for the specified JSM:

https://searchfox.org/mozilla-central/rev/489e82dcc1e5afbe691ff3b1c982382914637e38/toolkit/components/backgroundtasks/BackgroundTasksManager.jsm#72

Gijs, thoughts on how we should square that with the machinery from bug 1721627?

Flags: needinfo?(bholley) → needinfo?(gijskruitbosch+bugs)
No longer blocks: 1736524

(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:

https://searchfox.org/mozilla-central/rev/489e82dcc1e5afbe691ff3b1c982382914637e38/toolkit/components/backgroundtasks/BackgroundTasksManager.jsm#72

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:

  1. 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
  2. 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.
  3. add a condition to the nsNetUtil.cpp code that creates an exception for these patterns of files.
  4. 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 to fetch 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.
  5. 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.

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(bholley)

Thanks, approach (3) sounds good. Attaching a patch.

Assignee: nobody → bholley
Flags: needinfo?(bholley)
Attachment #9247371 - Attachment description: Bug 1736431 - Allowlist URLs containing the string "backgroundtask". → Bug 1736431 - Allowlist URLs containing the string "backgroundtasks".
Pushed by bholley@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/14e8b7646d98
Allowlist URLs containing the string "backgroundtasks". r=Gijs
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 95 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: