[Desktop] crash when updating a setting that requires restart when an update is waiting

[LaurenWags]

Description

If you have an update waiting and you change a preference that requires a restart, when you restart Brave crashes. Sometimes this results in tab/window loss, but not always (still trying to narrow down that part).

Steps to Reproduce

1. Download a previous version (ex. 1.12.103 on Beta).
2. Launch, navigate to brave://settings/help to trigger update check.
3. Once update is fully downloaded, navigate to brave://settings.
4. Change a setting that requires restart (I've used either chromecast or crash report)
5. Click Restart button for the setting you changed.

Actual result:

When Brave goes to restart there is a crash. My personal profile lost all tabs/windows however my test profiles did not (crash report was still generated though).

Example crash reports:
37180000-45d5-d704-0000-000000000000 (changed crash report setting to trigger need for restart, only produced one crash report)

2e180000-45d5-d704-0000-000000000000, 3b180000-45d5-d704-0000-000000000000 (changed chromecast setting to trigger need for restart, produced two crash reports)

d8120000-45d5-d704-0000-000000000000 (changed chrome cast setting to trigger need for restart, produced one crash report, this was for my personal profile where I lost all tabs/windows)

Expected result:

No crash.

Reproduces how often:

easily

Brave version (brave://version info)

see below for versions used

Version/Channel Information:

• Can you reproduce this issue with the current release? yes 1.11.101 --> 1.11.104 upgrade
• Can you reproduce this issue with the beta channel? yes 1.12.103 --> 1.13.54 upgrade
• Can you reproduce this issue with the nightly channel? yes 1.14.6 --> 1.14.10 upgrade

Other Additional Information:

• Does the issue resolve itself when disabling Brave Shields?
• Does the issue resolve itself when disabling Brave Rewards?
• Is the issue reproducible on the latest version of Chrome?

Miscellaneous Information:

cc @bsclifton

[kjozwiak]

Nice catch @LaurenWags 👍 Doesn't seem to be a high rate crash as we've only seen ~12 crashes as per the following:

https://brave.sp.backtrace.io/p/brave/explore?time=all&aggregations=((callstack%2Chead))&fingerprint=53d60d102e44ec2284abf4fac366b47c1215e606e060c8edf27aa6b2f9384e05

[iefremov]

Reproduced, this is actually super frequent crash, it just has slightly different fingerprints.
Many thanks for repro @LaurenWags !!!

see #12248

[iefremov]

stack

[ 02 ] LoadLocalState_ChromiumImpl(ChromeFeatureListCreator*, bool)
[ 03 ] LoadLocalState(ChromeFeatureListCreator*, bool)
[ 04 ] ChromeMainDelegate::PostEarlyInitialization(bool)
[ 05 ] content::ContentMainRunnerImpl::RunServiceManager(content::MainFunctionParams&, bool)
[ 06 ] content::ContentMainRunnerImpl::Run(bool)
[ 07 ] service_manager::Main(service_manager::MainParams const&)
[ 08 ] content::ContentMain(content::ContentMainParams const&)

https://brave.sp.backtrace.io/p/brave/debug?filters=((callstack%2Ccontains%2CLoadLocalState))&debug=(b75917,0,2)

[rebron]

@iefremov and @LaurenWags can we close this as a dupe? #12248 (comment)

[LaurenWags]

@rebron looks like 12248 is closed?

[atuchin-m]

I've checked windows backtraces crashes.
The crash reason is CHECK failure here:

It happens because the browser fails to determine the used locale (that's unlikely there is always a fallback) or fails to load the matching locale.pak file.

[atuchin-m]

Removing locale.pak results in the exact crash we see:

mv "/Users/mikhail/work/brave-browser/src/out/Static_arm64/Brave Browser Development.app/Contents/Frameworks/Brave Browser Development Framework.framework/Versions/126.1.69.15/Resources/en.lproj/locale.pak" /tmp/locale.pak
..
15172:259:0625/181426.338480:FATAL:chrome_resource_bundle_helper.cc(107)] Check failed: !actual_locale.empty(). Locale could not be found for 
0   Brave Browser Development Framework 0x0000000124935dc0 base::debug::CollectStackTrace(void const**, unsigned long) + 28
1   Brave Browser Development Framework 0x000000012492a1c8 base::debug::StackTrace::StackTrace() + 80
2   Brave Browser Development Framework 0x0000000124897b78 logging::LogMessage::Flush() + 152
3   Brave Browser Development Framework 0x0000000124897a6c logging::LogMessage::~LogMessage() + 36
4   Brave Browser Development Framework 0x0000000124883a4c logging::(anonymous namespace)::CheckLogMessage::~CheckLogMessage() + 124
5   Brave Browser Development Framework 0x0000000124883a9c logging::(anonymous namespace)::CheckLogMessage::~CheckLogMessage() + 12
6   Brave Browser Development Framework 0x00000001248837f0 logging::CheckError::~CheckError() + 44
7   Brave Browser Development Framework 0x0000000124883838 logging::CheckError::~CheckError() + 12
8   Brave Browser Development Framework 0x000000012437ac20 LoadLocalState_ChromiumImpl(ChromeFeatureListCreator*, bool) + 728
9   Brave Browser Development Framework 0x000000012437acac LoadLocalState(ChromeFeatureListCreator*, bool) + 24
10  Brave Browser Development Framework 0x00000001201ee138 ChromeMainDelegate::PostEarlyInitialization(absl::variant<content::ContentMainDelegate::InvokedInBrowserProcess, content::ContentMainDelegate::InvokedInChildProcess>) + 492

Taking into account that it happens when the browser is updatingm it's likely to be an updater's failure.

[atuchin-m]

Note: backtrace also shows another crash signature, but in fact there are the same crashes (when you evaluates the raw dumps in Visual Studio):

[rebron]

cc: @mherrmann

[mherrmann]

Hopefully this will go away once we've migrated to the new upstream-native auto-update implementation (Omaha 4).

[atuchin-m]

We have few different issues here:

1. MacOS-related. The steps in the description is 100% reproducible on MacOS and related to sparkle update. We're relaunching the old binary with a new framework (see the screenshot) Also we have issues with cookies. @mherrmann is it hard to fix it
   It's about stability, so I'm not sure it's a good idea to wait until omaha 4 release.

2. Win-related. The same steps can't be reproduced for win. Also the updater is different. Probable, it's another issue with the updater, because the crash spikes match to the day we publish new releases.

[mherrmann]

@atuchin-m I suspect it's not terribly hard to fix. Still, I personally would prefer to continue with my work on O4. I keep getting side-tracked and it is very difficult to make progress on a big project this way.

[mherrmann]

I've begun looking into the Sparkle-related crash.

[mherrmann]

From my perspective, the Sparkle-related crash should be fixed by brave/brave-core#25248.

[mherrmann]

@iefremov @LaurenWags @atuchin-m is this still an issue on Windows? I am not able to reproduce it there.

1. Uninstall Brave.
2. Install a public version of Brave that is not the latest one. I installed 1.70.123.
3. Start Brave.
4. Go to brave://settings/help.
5. Wait until the update has been installed.
6. Go to brave://settings/system.
7. Toggle Use graphics acceleration when available.
8. Click the Relaunch button next to it.

Brave restarts as expected. I do not see any crash.

[atuchin-m]

I'm okay to close this task, especially when we have the associated PR merged.
I also can't reproduce the issue on win.

We need to make a dedicated issue to track backtrace issues with InitializeICU or LoadLocalState_ChromiumImpl that are still presented.

[iefremov]

Macos issue fixed in brave/brave-core#25248

[atuchin-m]

An issue to track backtrace crashes: #41642