ctranslate2 <=4.4.0 marks its native library's stack RWE; kernels that
refuse the request fail the dlopen, taking whisperx, faster-whisper and
Argos translation down. main learned to detect and fall back; this also
fixes the library: core.execstack clears the one ELF bit in place on
first probe (Linux-only, memoized, never raises), so the engines load
normally on hardened kernels. Argos's probe moves to
argostranslate.translate so it cannot advertise an engine whose every
request 500s, and the dub route returns one actionable 400.
Also: pytorch-whisper survives a CUDA OOM at transcribe time by
stepping the batch down (16->4->1, 8->2->1 with word timestamps) and
finishing on CPU rather than dropping the chunk.
Addresses the CodeRabbit 🟡 Minor nit on the empty-input branch added in
#2143: the explicit `if not raw: raise ValueError(...)` is fully shadowed
by the `re.fullmatch(r"[a-z]{2,3}", code)` check two lines below, which
raises the same message for any input that does not look like a language
code (including empty and whitespace-only after strip()). Removing the
shortcut is the smallest correct change — same caller-observable
behavior, one less branch.
The expanded docstring enumerates the alias shapes the function now
recognises, so future readers do not have to reverse-engineer the
behaviour from the alias dicts.
The test `test_argos_lang_code_rejects_invalid_inputs` is widened to
cover a non-empty but invalid shape (`"Chinese ("` — looks like a label,
fails the regex) alongside the original empty/whitespace cases, so it
asserts behavior unique to the regex branch rather than passing for the
wrong reason.
Greptile on #2109: a flat 600s default still undercuts the budget the job
was granted. generate_timeout_s adds 1s per 40 characters past a 1200-char
allowance and can be raised by env, so a long passage is granted more than
600s and a constant deadline only moves the cliff to longer inputs rather
than removing it. The comment on GENERATE_RECV_TIMEOUT_S claimed the inner
deadline "can never fire before the outer budget", which was not true for
those inputs.
_effective_recv_timeout_s(text) now takes the larger of the engine's own
value and the budget this specific request was granted, and generate()
uses it for both the first frame and the progress loop.
Only for engines that expressed no opinion. An override is a deliberate
statement about that model, and #2103 asks for "fast engines opt down" to
keep working, so a subclass that sets recv_timeout_s keeps exactly that
value — including a smaller one. Detected by walking __mro__ for a
recv_timeout_s in a subclass __dict__ rather than comparing values, so an
engine that happens to pick the same number as the floor is still honoured.
Budget probing is advisory: any failure falls back to the class floor
rather than turning a working generate into an error.
Tests: a long passage raises the deadline above the flat floor and tracks
generate_timeout_s; an opt-down engine keeps its value at any text length;
a failing probe falls back. Verified load-bearing by making the derivation
return the engine value unconditionally (the long-passage test fails on
600.0 > 600.0).
SubprocessBackend.recv_timeout_s defaulted to RECV_TIMEOUT_S (60s), the
budget for a health_check ping. Four engines never overrode it and so used
a ping's deadline as their generation deadline: confucius4-tts, dots-tts,
moss-tts-v15 and supertonic3. All four fall back to CPU off CUDA, where a
normal sentence does not finish in 60s, and the watchdog killed them
mid-synthesis.
That deadline sat 5-10x below the wall-clock budget the same job was
granted by model_manager.generate_timeout_s (300s accelerated, 600s CPU),
so the sidecar was reclaimed while its caller still considered it well
inside budget. Every engine that did override the hook chose 300s..900s,
at or above the accelerated budget; omnivoice_subprocess documents the
intent as "aligns the kill deadline with the generate budget". The 60s
default contradicted that intent for anyone who did not opt out of it.
which left the class default and the four silent engines untouched.
Default to GENERATE_RECV_TIMEOUT_S (600s, the CPU budget floor) so an
engine that expresses no opinion can no longer be cut off before its own
job budget. RECV_TIMEOUT_S stays 60s for health_check, where a ping must
stay fast. Overriding is still how an engine asks for more.
Second half: the watchdog logged "exceeded recv timeout; killing" but
generate() raised "sidecar closed pipe mid-generate", so the one fact that
explained the failure never left the backend log and reporters read it as
a crash. _last_recv_timed_out already distinguished the two for the spawn
handshake (#2026); use it here too and name the deadline, the elapsed
time and the sidecar's last stderr. Crash wording is unchanged.
Tests: a registry invariant that no SubprocessBackend can be dispatched
with a deadline under the accelerated budget, so a new engine cannot
inherit this by omission the way these four did; lockstep with
model_manager's budgets; and a wedging sidecar asserting the timeout
message. Verified fail-before/pass-after by reverting the default to 60s
(all 7 fail, naming exactly the four engines) and by forcing the crash
wording (the message test fails).
Fixes#2103
Palash Debnath