Random Freezes and Python Zombie Processes with cgroup v2 Setup

[bahnwaerter]

The current version of BenchExec (3.35-dev commit 5f507cc) exhibits sporadic freezes that are difficult to reproduce consistently when run with cgroups v2. During these freezes, multiple Python zombie processes appear, hindering progress. Despite the correct setup of cgroups v2 and proper subprocess handling in BenchExec, the underlying cause remains unclear.

Observations

• BenchExec exhibits sporadic and unpredictable freezes, that lack a clear pattern or reproducibility. The freezes can occur after a few benchmark tasks or even after thousands.
• When a freeze occurs, several Python zombie processes are observed, coinciding with the halt in progress:

  [...]
  
  115295 root      20   0       0      0      0 Z   0.0   0.0   0:00.00 [python3] <defunct>
  115392 root      20   0       0      0      0 Z   0.0   0.0   0:00.00 [python3] <defunct>
  115393 root      20   0       0      0      0 Z   0.0   0.0   0:00.00 [python3] <defunct>
  138277 root      20   0       0      0      0 Z   0.0   0.0   0:00.00 [python3] <defunct>
  
  [...]
  

• The implementation in BenchExec uses os.wait4(...) and similar calls for the subprocess handling, which seem to work correctly. It remains unknown how or why zombie processes persist.
• The cgroup v2 setup is properly configured and usable by BenchExec. The cleanup mechanisms (e.g., process termination in OOM scenarios) appear to operate as intended:

  [...]
  
  [244384.472902] Memory cgroup out of memory: Killed process 2316616 (java) total-vm:10681332kB, anon-rss:7773952kB, file-rss:18656kB, shmem-rss:0kB, UID:0 pgtables:15772kB oom_score_adj:0
  [244384.473313] Tasks in /lxc/802/ns/user.slice/user-0.slice/user@0.service/benchexec.slice/run-p115037-i6497282.scope/benchmark_0n5o4jto/delegate_b6gc73pn are going to be killed due to memory.oom.group set
  [244384.473333] Memory cgroup out of memory: Killed process 2316616 (java) total-vm:10681332kB, anon-rss:7773952kB, file-rss:18656kB, shmem-rss:0kB, UID:0 pgtables:15772kB oom_score_adj:0
  
  [...]
  

• Running BenchExec with --debug flag yields no additional warnings or errors.

Environment

• BenchExec runs inside an LXC container (Debian Trixie) on a Proxmox 9 (Debian Trixie) host
• Host has an AMD Ryzen Threadripper 3970X CPU with 128 GB of RAM allocated to the LXC container
• Linux kernel version: 6.17.13-2-pve
• cgroup v2 is enabled with nesting
• systemd version: 257.9
• Python version: 3.13.5

Cause

So far, it is unclear whether the underlying issue lies in the Linux kernel, LXC, or cgroup v2 layer, or even in the BenchExec implementation itself (e.g., due to a possible race condition in the subprocess handling or any other bugs).

Are there any known similar issues with BenchExec using cgroups v2 setups?
What additional debugging steps can be taken?

[PhilippWendler]

There is a known deadlock in libc that BenchExec can trigger, but we have a workaround for it and you should see warnings if it occurs: #656

In order to help further, I would need more information though.

Are you executing benchmarks in parallel? If yes, how many? And does the deadlock also occur without parallel execution of runs?

Is this a new issue, and if yes, what where recent changes that could trigger it? For example, did you successfully run previous BenchExec versions in the past?

Please provide logs of BenchExec and the syslog, and the tree of all involved processes. I am afraid we will likely need to get a stacktrace of the hanging processes in order to understand where it hangs.

As a side note: It looks as if you are running BenchExec as root in the container. I would recommend to use a regular user account instead. BenchExec's containers are intended as a safety mechanism and not a security boundary, and with root permissions containers sometimes behave slightly differently. BenchExec is only tested for use by a non-root user.

[danieldietsch]

Its a container-in-container setup: proxmox has an lxc container, in which benchexec runs. We use benchexec for quite some time, but just updated to Debian 13 and switched to cgroups v2.
We usually run 8 to 16 runs in parallel.
We did not try without parallel execution.
We usually run the latest benchmark from main, but we do not keep track of versions. When updating to Debian 13, we also updated benchexec.

@bahnwaerter and I can work together to provide you stack traces. Does py-spy work for benchexec?

[PhilippWendler]

Does py-spy work for benchexec?

I don't know this tool, so I cannot say unfortunately.

[bahnwaerter]

Thanks @PhilippWendler for the analysis and debugging hints.

Are you executing benchmarks in parallel? If yes, how many? And does the deadlock also occur without parallel execution of runs?

We executed 14 verification tasks in parallel. The issue arises only when parallel execution is enabled. When running sequentially (-N 1), the problem does not occur.

Please provide logs of BenchExec and the syslog, and the tree of all involved processes. I am afraid we will likely need to get a stacktrace of the hanging processes in order to understand where it hangs.

We used the py-spy tool to gather at least some information about the program state during the freeze. I've attached the stacktrace.log and processes.log with more information. Unfortunately, py-spy doesn't provide a detailed stacktrace of the native Python threads.

It is interesting to see that Thread-467 is in the execution of the _check_errno(...) function. It might be possible that the freeze is related to a problem with the C library. We will take a closer look at this part. By the way, the Debian system uses GNU C Library version 2.41-12.