Crash in SetupAppContainerProfile when opening a specific website.

[Mellnik]

Describe the bug
A crash happens when opening a specific website.
https://webglsamples.org/aquarium/aquarium.html
The website provides WebGL examples. The crash only happens with the specific example in the link above.

To Reproduce
Steps to reproduce the behavior:

1. Open cefclient.exe
2. Go to https://webglsamples.org/aquarium/aquarium.html
3. Crash happens.

Expected behavior
No crash should happen. The website is a WebGL example.

Screenshots

Versions (please complete the following information):

• OS: Windows 11 23H2, 22631.4169
• CEF Version: 128.0.6613.120

Additional context
Reproducible with cefclient.exe and my embedded OSR application.
Not reproducible with Google Chrome.

The crash seems to happen by trying to add the capability "kLpacChromeInstallFiles" to so called "app container profile".

Full call stack:

>	[Inline Frame] libcef.dll!sandbox::policy::`anonymous namespace'::SetupAppContainerProfile(sandbox::AppContainer * container, const base::CommandLine & command_line, sandbox::mojom::Sandbox sandbox_type) Line 480	C++
 	libcef.dll!sandbox::policy::SandboxWin::AddAppContainerProfileToConfig(const base::CommandLine & command_line, sandbox::mojom::Sandbox sandbox_type, const std::__Cr::basic_string<char,std::__Cr::char_traits<char>,std::__Cr::allocator<char>> & appcontainer_id, sandbox::TargetConfig * config) Line 838	C++
 	[Inline Frame] libcef.dll!content::`anonymous namespace'::XrCompositingInitializeConfig(sandbox::TargetConfig * config, base::CommandLine & cmd_line, sandbox::mojom::Sandbox sandbox_type) Line 192	C++
 	libcef.dll!content::UtilitySandboxedProcessLauncherDelegate::InitializeConfig(sandbox::TargetConfig * config) Line 337	C++
 	[Inline Frame] libcef.dll!sandbox::policy::`anonymous namespace'::GenerateConfigForSandboxedProcess(const base::CommandLine & cmd_line, sandbox::policy::SandboxDelegate * delegate, sandbox::TargetConfig * config) Line 674	C++
 	libcef.dll!sandbox::policy::SandboxWin::GeneratePolicyForSandboxedProcess(const base::CommandLine & cmd_line, const std::__Cr::vector<void *,std::__Cr::allocator<void *>> & handles_to_inherit, sandbox::policy::SandboxDelegate * delegate, sandbox::TargetPolicy * policy) Line 959	C++
 	libcef.dll!sandbox::policy::SandboxWin::StartSandboxedProcess(const base::CommandLine & cmd_line, const std::__Cr::vector<void *,std::__Cr::allocator<void *>> & handles_to_inherit, sandbox::policy::SandboxDelegate * delegate, base::Process * process) Line 1003	C++
 	libcef.dll!content::StartSandboxedProcess(content::SandboxedProcessLauncherDelegate * delegate, const base::CommandLine & target_command_line, const std::__Cr::vector<void *,std::__Cr::allocator<void *>> & handles_to_inherit, base::Process * process) Line 47	C++
 	libcef.dll!content::internal::ChildProcessLauncherHelper::LaunchProcessOnLauncherThread(const base::LaunchOptions * options, std::__Cr::unique_ptr<std::__Cr::vector<void *,std::__Cr::allocator<void *>>,std::__Cr::default_delete<std::__Cr::vector<void *,std::__Cr::allocator<void *>>>> files_to_register, bool * is_synchronous_launch, int * launch_result) Line 160	C++
 	libcef.dll!content::internal::ChildProcessLauncherHelper::LaunchOnLauncherThread() Line 327	C++
 	[Inline Frame] libcef.dll!base::OnceCallback<void ()>::Run() Line 156	C++
 	libcef.dll!base::TaskAnnotator::RunTaskImpl(base::PendingTask & pending_task) Line 203	C++
 	[Inline Frame] libcef.dll!base::TaskAnnotator::RunTask(perfetto::StaticString event_name, base::PendingTask & pending_task, base::internal::TaskTracker::RunTaskImpl::<lambda_0> && args) Line 90	C++
 	[Inline Frame] libcef.dll!base::internal::TaskTracker::RunTaskImpl(base::internal::Task & task, const base::TaskTraits & traits, base::internal::TaskSource * task_source, const base::internal::SequenceToken & token) Line 679	C++
 	libcef.dll!base::internal::TaskTracker::RunBlockShutdown(base::internal::Task & task, const base::TaskTraits & traits, base::internal::TaskSource * task_source, const base::internal::SequenceToken & token) Line 672	C++
 	[Inline Frame] libcef.dll!base::internal::TaskTracker::RunTaskWithShutdownBehavior(base::internal::Task & task, const base::TaskTraits & traits, base::internal::TaskSource * task_source, const base::internal::SequenceToken & token) Line 697	C++
 	[Inline Frame] libcef.dll!base::internal::TaskTracker::RunTask(base::internal::Task task, base::internal::TaskSource * task_source, const base::TaskTraits & traits) Line 521	C++
 	libcef.dll!base::internal::TaskTracker::RunAndPopNextTask(base::internal::RegisteredTaskSource task_source) Line 416	C++
 	libcef.dll!base::internal::WorkerThread::RunWorker() Line 436	C++
 	libcef.dll!base::internal::WorkerThread::RunDedicatedWorker() Line 342	C++
 	libcef.dll!base::`anonymous namespace'::ThreadFunc(void * params) Line 131	C++

[magreenblatt]

OS: Windows 11 23H2, 22631.4169

@Mellnik have you tested any other Windows versions?

[Mellnik]

@magreenblatt
No, sorry. Which versions do you think would be worthwhile testing? I could setup a VM. This crash currently hinders me from upgrading so I will gladly do anything helping you fix it.

[magreenblatt]

I'm not able to reproduce this crash with cefclient 128.4.12+g1d7a1f9+chromium-128.0.6613.138 or 129.0.6+ga918aa7+chromium-129.0.6668.29 (64-bit builds). I have the same Windows 11 version.

[magreenblatt]

@Mellnik can you test if the crash reproduces for you on a different machine (different GPU/drivers)?

[Mellnik]

Alright I had it tested by a friend. He's running the same Windows version as me tho. (23H2, 22631.4169). NVIDIA driver version 552.22 with an RTX 3060 Laptop GPU.

My NVIDIA driver version: 561.09, GTX 1080 Ti

To confirm I've compiled a fresh 129.0.6+ga918aa7+chromium-129.0.6668.29 which results in the same crash.

I've also observed the same crash in another scenario last week. Unfortunately I don't have any more information on how to reproduce this other scenario.

From the stacktrace that I posted it looks like the pointer container is invalid. That is not the case, it actually crashes because of a NOTREACHED inside the function AddCapability as kLpacChromeInstallFiles is not found.

Do you have any more information on what to try? Thank you.

Edit: Using Visual Studio 2022 17.11.4 in case it matters.

[magreenblatt]

From the stacktrace that I posted it looks like the pointer container is invalid. That is not the case, it actually crashes because of a NOTREACHED inside the function AddCapability as kLpacChromeInstallFiles is not found.

Where in the code is this NOTREACHED that you're referring to?

NOTREACHED is fatal in Chromium starting with ~M127. See here for background.

[Mellnik]

Sorry for the delay. Here is more information about the NOTREACHED.

 	!logging::LogMessage::HandleFatal(unsigned __int64 stack_start, const std::string & str_newline) Line 1073	C++
 	[Inline Frame] !logging::LogMessage::Flush::<lambda_0>::operator()() Line 773	C++
 	[Inline Frame] !absl::cleanup_internal::Storage<`lambda at ..\..\base\logging.cc:771:40'>::InvokeCallback() Line 87	C++
 	[Inline Frame] !absl::Cleanup<absl::cleanup_internal::Tag,`lambda at ..\..\base\logging.cc:771:40'>::~Cleanup() Line 106	C++
 	!logging::LogMessage::Flush() Line 956	C++
 	!logging::LogMessage::~LogMessage() Line 728	C++
 	[Inline Frame] !logging::`anonymous namespace'::NotReachedLogMessage::~NotReachedLogMessage() Line 148	C++
 	!logging::`anonymous namespace'::NotReachedLogMessage::~NotReachedLogMessage() Line 143	C++
 	!logging::NotReachedNoreturnError::~NotReachedNoreturnError() Line 396	C++
 	!base::win::Sid::FromNamedCapability(const std::wstring & capability_name) Line 151	C++
>	!sandbox::AppContainerBase::AddCapability(const wchar_t * capability_name) Line 355	C++
 	[External Code]	

So it looks like kLpacChromeInstallFiles is an unknown capability.
If NOTREACHED was not fatal before M127 it means this error also happened for me before but without my attention.
Do you happen to know anything about this kLpacChromeInstallFiles? Not really sure why this is triggered for me but not for you.

[magreenblatt]

Thanks for the updated details. I'm not sure why this code path is triggering for you. However, the reason for this NOTREACHED is that we've explicitly removed boringssl dependencies from cef_sandbox.lib (the !BUILDFLAG(IS_CEF_SANDBOX_BUILD) part).

[magreenblatt]

@Mellnik Can you post the full call stack for this NOTREACHED? What module is this code running in? Presumably it's not running in libcef.dll or BUILDFLAG(IS_CEF_SANDBOX_BUILD) would be false.

[Mellnik]

The call stack from the original post is from cefclient.exe. The one I posted today is from my application that embeds CEF with OSR.
For some reason they are different. In cefclient.exe it doesn't show the NOTREACHED location.
You are right, the module of todays call stack is not libcef.dll, it's the module of my application that links against cef_sandbox.lib, if I am not mistaken.

[Mellnik]

Update: I've just downloaded 129.0.6+ga918aa7+chromium-129.0.6668.29 from https://cef-builds.spotifycdn.com/index.html, created the VS solution with CMake, built it and started it with the VS debugger.
Here is a call stack that contains the NOTREACHED as well.

 	cefclient.exe!logging::LogMessage::HandleFatal(unsigned __int64 stack_start, const std::string & str_newline) Line 1073	C++
 	cefclient.exe!logging::LogMessage::Flush::<lambda_0>::operator()() Line 775	C++
 	cefclient.exe!absl::cleanup_internal::Storage<`lambda at ..\..\base\logging.cc:771:40'>::InvokeCallback() Line 88	C++
 	cefclient.exe!absl::Cleanup<absl::cleanup_internal::Tag,`lambda at ..\..\base\logging.cc:771:40'>::~Cleanup() Line 106	C++
 	cefclient.exe!logging::LogMessage::Flush() Line 956	C++
 	cefclient.exe!logging::LogMessage::~LogMessage() Line 727	C++
 	cefclient.exe!logging::`anonymous namespace'::NotReachedLogMessage::~NotReachedLogMessage() Line 132	C++
 	cefclient.exe!logging::`anonymous namespace'::NotReachedLogMessage::~NotReachedLogMessage() Line 127	C++
 	[External Code]	
 	cefclient.exe!logging::NotReachedNoreturnError::~NotReachedNoreturnError() Line 380	C++
>	cefclient.exe!base::win::Sid::FromNamedCapability(const std::wstring & capability_name) Line 151	C++
 	cefclient.exe!sandbox::AppContainerBase::AddCapability(const wchar_t * capability_name) Line 355	C++
 	[External Code]	

You said boringssl was removed. I wonder how the capabilities, that are not well known capabilities, are supposed to be found if the code part is omitted. (The #if !BUILDFLAG(IS_CEF_SANDBOX_BUILD) part.)

I also wonder if anybody else is able to reproduce this.

[amaitland]

Testing with cef_binary_129.0.11+g57354b8+chromium-129.0.6668.90_windows64_client,

cefclient.exe
cefclient.exe --off-screen-rendering-enabled
cefclient.exe --multi-threaded-message-loop --off-screen-rendering-enabled --enable-gpu
cefclient.exe --multi-threaded-message-loop --use-alloy-style

Loaded https://webglsamples.org/aquarium/aquarium.html using the different command line options.

The webgl demo loaded, ran for a while without issues.

[magreenblatt]

@Mellnik Does the crash reproduce for you when using the pre-built "Sample Application" from https://cef-builds.spotifycdn.com/index.html ?

[Mellnik]

@amaitland Thank you for your testing.

@magreenblatt No, just tested and it does not crash with the pre-built binaries.
I suspect that something goes wrong when I build it myself. I will try to fully reinstall VS and see if that helps.
Let me know if I should try something else too. Thank you!