Files
rustdesk/libs
Mariano Abad a62c93fc0d drm: fix the ABI cross-check's path, and stop panicking on a failed spawn
The ABI cross-check added in the previous commit could never run: both callers
of stage_libdrmtap_into_deb chdir into flutter/ first, and the check opened
drmtap_dl.rs by a path relative to the cwd, so every --drm packaging run died
with FileNotFoundError. CI caught it. It is anchored on __file__ now, and read
through a context manager.

Worth naming why the test missed it: the check was exercised from the repository
root, which is the one directory where the bug is invisible. A control that does
not reproduce the call site's conditions is not a control.

Three more, all the same class the previous commit was already fixing - a
hazard closed at one site and left at its siblings:

- `std::thread::spawn` panics when the thread cannot be created, and the panic
  unwinds into whoever called it. The two hardened workers used Builder; the
  five remaining DRM threads did not. The startup ones now log and degrade (a
  lost pre-warm costs one cold probe, a lost udev listener costs the mid-session
  push, a lost warm costs the first session), and the two per-session ones live
  in functions that already return ResultType, so they fail that one connection
  cleanly instead of unwinding through the handler.
- The wire descriptor's `num_planes` was clamped to 1..=4 here while
  `drm_render::convert` rejects an out-of-range count on purpose, so that the
  count the C reads is the count this side validated. Clamping made that reject
  unreachable: a descriptor claiming 7 planes arrived as 4 and passed. The two
  guards were added by different review rounds and had been quietly cancelling
  each other. The raw value is passed through now, leaving one validation site,
  next to the code that dereferences it.
- A SAFETY comment claimed the cursor is released only on success. It is
  released on every path after a successful get_cursor; only a failed get_cursor
  returns without releasing, because then there is nothing to release. The
  release protocol is the reason that block is unsafe, so the comment describing
  it has to be right.
2026-07-31 12:30:31 -03:00
..
2026-07-07 14:54:22 +08:00
2026-07-06 18:00:39 +08:00