cefsimple crashes on startup with debug builds of CEF on macOS

[tasuren]

Describe the bug
When using a debug build of CEF on macOS, the cefsimple example crashes on launch due to a DCHECK failure.

[39815:226336:0814/115923.756723:FATAL:chrome/common/chrome_paths_mac.mm:189] DCHECK failed: path.BaseName().value() == kChromeVersion (target vs. 139.0.7258.31)

I was wondering if this is a known issue. Alternatively, perhaps cef-rs does not yet officially support CEF debug builds. Could you please clarify if this is the expected behavior?

To Reproduce
Steps to reproduce the behavior:

1. Clone repository.
2. Download the CEF Standard Distribution from here that matches the CEF version used by cef-rs.
3. Manually create a cef directory, mimicking the structure that export-cef-dir command would generate.
   a. Move cmake, include, libcef_dll, and CMakeLists.txt files and directories into the new cef directory.
   b. From the downloaded CEF distribution, move Chromium Embedded Framework.framework from its Debug subfolder into the cef directory.
   c. Create an archive.json file inside the cef directory with the content {"type": "standard"}, mimicking archive.json that export-cef-dir would generate.
4. Set the CEF_PATH and DYLD_FALLBACK_LIBRARY_PATH environment variables to the absolute path of the cef directory you just created.
5. Bundle the cefsimple example using the command: cargo run --bin bundle_cefsimple.
6. Attempt to run the bundled application from your shell: ./target/debug/cefsimple.app/Contents/MacOS/cefsimple

Expected behavior
The cefsimple application should launch successfully and display its window without any crashes.

Additional context
I found that the initial startup crash can be worked around by setting LSUIElement to 0 at this line:

cef-rs/examples/cefsimple/src/mac/bundle_cefsimple.rs

Line 118 in d2292c9

ls_ui_element: "1".to_string(),

[wravery]

The short version is that this crate does not support running against the debug build of CEF.

The longer version is that I don't know precisely why it crashes here against a debug build of CEF. It could be that there are different function signatures or constant macros defined in the headers than what were used to generate the bindings. If setting ls_ui_element prevents the crash, I suspect that's an indication that the memory layout of that struct does not match, because the DCHECK seems to be complaining that the expected Chromium version is not in a path that it's looking at (apparently somewhere under target).

This doesn't stop you from using debug builds of this crate, though. It only makes it harder if you actually want to debug into the C/C++ implementation of CEF and/or Chromium itself.

[tasuren]

Thank you for your quick response and for clarifying that debug builds are not supported.

I did a bit more digging, and I believe I may have found the specific root cause of the crash. It seems to be related to a configuration difference in the Info.plist for the cefsimple example, rather than a fundamental incompatibility with debug builds.

The core of the issue appears to be the LSUIElement (ls_ui_element) setting.

• In the official CEF cefsimple example, LSUIElement is set to true (1) only for the helper app bundles. The main app bundle leaves this key unset, which defaults to false (0).
• In contrast, the cef-rs cefsimple example sets LSUIElement to true for all bundles, including the main application itself.

This difference causes the DCHECK failure in debug builds due to the logic in Chromium's GetFrameworkBundlePath function, as seen in the source code here.

The function checks base::apple::IsBackgroundOnlyProcess(), which returns true if LSUIElement is enabled. The code's logic assumes that if this is true, it is running as a helper process and calculates the framework path accordingly (the if block). If it's false (the expected case for a main app), it takes the else path, which correctly appends the version string (kChromeVersion).

By setting LSUIElement to true on the main app, it forces the code to incorrectly take the helper path. As a result, the version string is never appended to the path, causing the DCHECK_EQ(path.BaseName().value(), kChromeVersion) check to fail.
Additionally, this incorrect setting is also the reason why the cefsimple application icon does not appear in the Dock.

Based on this, I believe the solution is to align cef-rs's cefsimple example with the official CEF implementation: LSUIElement should be set to true only for the helper processes, and false (or unset) for the main application bundle.

This change would likely fix the cefsimple app icon not appearing in the Dock and also make the cefsimple example's configuration more consistent with CEF's standards.

If you agree with this approach, I can submit a Pull Request to resolve the issue.

[wravery]

Thanks for digging into this! Yes, a PR would be much appreciated. 👍🏼

[wravery]

I'll also take a look at adding a command line option to export-cef-dir to use the Debug CEF binaries since that DCHECK proved helpful. I don't know if they will always work with bindings generated with the C++ compiler release flags, but it might be useful again in future investigations.

[tasuren]

Thanks for digging into this! Yes, a PR would be much appreciated. 👍🏼

Thank you. I'll open it.

[tasuren]

Hi, checking in on this issue. My understanding is that the fix was merged in PR #184. Is there anything else needed, or can we close this issue? Thanks again!