CEF 142 Unzipper subprocess crashes with “stack smashing detected” on Ubuntu 24.04

General
1

I’m seeing a CEF-related crash with CasparCG 2.5 on Ubuntu 24.04 and wanted to check whether this is a known issue.

CasparCG version:

2.5.0 3cac160 Dev

The crash report shows that it is not the main CasparCG process, but this CEF utility subprocess:

/usr/bin/casparcg-server-beta --type=utility --utility-sub-type=unzip.mojom.Unzipper

The process terminates with SIGABRT and:

*** stack smashing detected ***: terminated

The relevant part of the stack trace is:

CefExecuteProcess()
__stack_chk_fail()
__fortify_fail("stack smashing detected")

At the time of the crash, Chromium had downloaded a component into component_crx_cache. The component ID was:

hfnkpimlhhgieaddgfemjhofmfblmnib

This appears to be Chromium’s CRLSet component, so it looks like the crash happens when CEF’s component updater starts the Unzipper utility process.

The main CasparCG process continues running, the AMCP connection remains available, and all playout channels continue responding. Therefore, it seems isolated to the CEF utility subprocess, although Ubuntu still reports it as a CasparCG crash because the subprocess uses the CasparCG executable.

I found a very similar report involving JetBrains’ CEF implementation on Linux. It has the same unzip.mojom.Unzipper process and almost the same CefExecuteProcess → __stack_chk_fail stack trace, so this may not be CasparCG-specific.

Chromium’s source also mentions that changing the stack canary after fork() requires all relevant functions on the return path to be built without stack protection. Otherwise, it can cause this exact type of failure. Chromium provides:

--change-stack-guard-on-fork=disable

as a workaround.

I tried starting CasparCG with --disable-component-update, but the flag does not appear in the CEF child process command lines, so it looks like those extra Chromium flags are not being propagated to CEF.

A few questions:

  1. Have you seen this with the CEF 142 integration in CasparCG 2.5?

  2. Is there currently an intended way to pass Chromium command-line switches to all CEF subprocesses?

  3. Would adding --change-stack-guard-on-fork=disable through CEF’s command-line handling be a reasonable workaround?

  4. Would it make sense for CasparCG to disable Chromium component updates by default, given that it is normally used as an embedded playout renderer?

2

I would recommend looking through the issues on github and adding this information there. I have encountered stack smashing errors on ubuntu but it looks like you have characterized the problem more.

3

I think this might be relevant for @Julusian, as I’ve seen many stack smashing errors in my logs, and this might be a way to deal with them.