coverallsapp / coverage-reporter / 32307096556
95%

DEFAULT BRANCH: master
Ran
Jobs 1
Files 44
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 95.438% (+3.7%) from 91.778%
32307096556

push

github

web-flow 
fix: build with libevent event loop so binaries start in sandboxed runtimes (#213)

v0.6.19, v0.6.20 and v0.6.21 could not start at all in sandboxed container
runtimes -- gVisor and similar, which back Cloud Run, GKE Autopilot and several
CI providers. Even `coveralls --version` aborted:

    Unhandled exception: timerfd_settime: Invalid argument (RuntimeError)

Root cause: Crystal 1.19 switched timerfd_create() from CLOCK_MONOTONIC to
CLOCK_BOOTTIME (crystal-lang/crystal#16516). Those runtimes implement
timerfd_create() for CLOCK_REALTIME/CLOCK_MONOTONIC only and return EINVAL for
CLOCK_BOOTTIME. Crystal builds its event loop during startup, so the process
dies before main(). The error text is misleading: the call that fails is
timerfd_create(), but Crystal hardcodes "timerfd_settime" in the raise.

Crystal 1.21 hits the same wall one step earlier, during execution-context
bootstrap, and reports "Thread#execution_context cannot be nil" instead. That is
the same root cause as the v0.6.19 report -- NOT the SYSMON race fixed in #211,
which was a correct fix for a bug these users did not have.

This is deterministic, not intermittent: 100% of runs on an affected runtime and
0% everywhere else, which is why it never reproduced locally or in CI.

Fix: build with -Devloop=libevent, which does not use timerfd at all. That
sidesteps the problem rather than trading one clock for another, and keeps us on
Crystal 1.20.3 with no source changes.

Reproduced and verified with a seccomp profile that makes CLOCK_BOOTTIME
timerfds return EINVAL, on x86_64 and aarch64:

    v0.6.17  ok          v0.6.20  execution_context error
    v0.6.18  ok          v0.6.21  timerfd error
    v0.6.19  execution_context error       this build  ok

That profile is now checked in and wired into build.yml as a regression gate
running the real shipped binary, so this class of failure cannot ship again.
Ordinary CI cannot catch it: GitHub runners and Docker Desktop use a real kernel
where ... (continued)

1046 of 1096 relevant lines covered (95.44%)

2.22 hits per line

Jobs
ID Job ID Ran Files Coverage
1 32307096556.1 44
95.44
 GitHub Action Run
Source Files on build 32307096556