1732567 - ASAN Nightly complains hourly about a missing BackgroundTask_backgroundupdate.jsm

Status: NEW

(Core :: Sanitizers, defect, P2)

Description

[Randell Jesup [:jesup] (needinfo me)]

Attachment: index.png

Every hour, ASAN Nightly pops a shell for a few seconds, and if you screenshot it at just the right time, you can see that it's complaining about a missing file:
BackgroundTask_backgroundupdate.jsm

It's also annoying that it pops the shell; I thought I had some sort of malware until I was able to screenshot it (I knew it appeared at X:37 every hour).

Comment 1

[Gabriele Svelto [:gsvelto]]

Molly, Kirk, do you know what might be happening here? It seems like the updater's background task was invoked but was somehow missing the source. What I find odd is that the console usually pops up like this when one launches a process with nsIProcess and fails to hide it properly; I thought that all background tasks handled that correctly but I'm not 100% familiar with the code so I may be wrong.

Comment 2

[Robin Steuber (she/her) [:bytesized]]

Hmm. I'm not really sure how this could happen, either with regards to the erroneous terminal window or to the missing jsm. Maybe :nalexander has ideas?

Comment 3

[Nick Alexander :nalexander [he/him]]

These ASAN builds must be debug builds, so that they invoke with a console on Windows. The scheduled background update task is running (although I'm not sure why every hour; it defaults to every 7 hours) and that'll pop the console in this configuration.

I'm not sure what the desired outcome is. Since the background update task is firefox.exe, there's no reasonable way to change the console behaviour just for the background task -- that's controlled at compile time by compilation flags that tell Windows how to invoke the process.

Should we not be scheduling background updates for ASAN builds at all? If we should not, we could check for ASAN (at runtime or at build time) and change behaviour accordingly.

(No need to involve Molly.)

Comment 4

[Nick Alexander :nalexander [he/him]]

Oh, and the missing JSM is just a warning: the apparatus looks in several places, expecting and accommodating failure in earlier places; subsequent code changes produce console warnings for those expected errors.

Comment 5

[Molly Howell (she/her) (mostly inactive)]

I haven't tried this, but it might be possible to force the console window to close during runtime, perhaps by calling FreeConsole, or failing that, just sending the window a close message. But I'm not immediately sure what conditions we should actually do that under; I don't think we want to do that for all background tasks in debug builds, and I'm not even sure we want to in just all ASAN builds. What else could we check for that would select only the cases where this is a problem?