1669382 - MOZ_CRASHREPORTER_DATA_DIRECTORY and other MOZ_CRASHREPORTER_* environment variables are overwritten on start on Windows 10

Status: UNCONFIRMED

(Toolkit :: Crash Reporting, defect)

Description

[a-n]

User Agent: Mozilla/5.0 (X11; U; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.120 Safari/537.36

Steps to reproduce:

1. run clean instance of Windows Sandbox and install latest version of Firefox
2. set system-wide environment variable MOZ_CRASHREPORTER_DATA_DIRECTORY to a custom directory (but behavior is the same when setting it for launching powershell instance only)
3. launch firefox
4. use procexp, Process Hacker or a similar tool to view environment block of the running process
5. open the default crash reporter data directory in %AppData%/Mozilla/Firefox/Crash Reports

Actual results:

Somewhere during startup, the custom environment variable is overwritten by the default path in the process environment block. Crash reports are written to the default directory, the new one is empty.

Both MOZ_CRASHREPORTER_EVENTS_DIRECTORY and MOZ_CRASHREPORTER_PING_DIRECTORY suffer from the same issue.

Reproduced on multiple Windows 10 systems, with both default and custom path to profile directory. Will update when I get results from a Linux system.

Interesting detail when searching Searchfox - it seems that the variable is not written anywhere, but the custom value is still consistently overwritten during startup: https://searchfox.org/mozilla-central/search?q=MOZ_CRASHREPORTER_DATA_DIRECTORY&path=&case=false&regexp=false

Expected results:

Environment variable MOZ_CRASHREPORTER_DATA_DIRECTORY should have the original configured value, and crash reports should be written to the custom directory.

Comment 1

[Andrei Purice]

Setting a component for this issue in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.

Comment 2

[Tom S. (please needinfo tschuster)]

This pretty clearly happens here: https://searchfox.org/mozilla-central/rev/c2e3ac11be4837718c2604e58085fbc8252b69dd/toolkit/crashreporter/nsExceptionHandler.cpp#2258

Comment 3

[Gabriele Svelto [:gsvelto]]

This is happening in this call. We set the env variable here. This is one of the environment variables we use internally for passing crash information from the crashed process to the crash reporter client; it's not meant to be set by the user.

Do you have a specific use-case for this? I guess we can make them configurable by the user but they weren't really designed for that.

Comment 4

[a-n]

(In reply to Gabriele Svelto [:gsvelto] from comment #3)

This is happening in this call. We set the env variable here. This is one of the environment variables we use internally for passing crash information from the crashed process to the crash reporter client; it's not meant to be set by the user.

Do you have a specific use-case for this? I guess we can make them configurable by the user but they weren't really designed for that.

I'm working on a Windows package manager which sets up all supported apps so that they only write to a local config directory - a bit similar to how UWP apps can only store data in their locked-down AppData folder, but more portable with support for win32 apps.

I can already tell firefox to store profile config in custom directory by setting PROFILE env var. I'd like to force Firefox to store all its files in a custom portable directory and not leave stuff in AppData. Currently, the crash reporter is hardcoded to use AppData.