Fatal kernel error prints a diagnostic, writes no output, and still exits 0
Summary
When banded execution is requested at the default threads-per-worker, wfa.affine.gpu prints
[!] ERROR: TODO: Less offsets than threads!!
(lib/sequence_alignment.cu:397), produces no output file, and returns exit status 0.
Reproduction:
bin/wfa.affine.gpu -i <any .seq> -g 4,6,2 -b 1000 -e <ceiling> -t 1024 -B auto -o out.txt
echo $? # 0
wc -l out.txt # empty, or absent
Observed on an RTX PRO 6000 Blackwell (188 SM) and on a MIG 1g.24gb slice of the same card, and on
GB10 (48 SM). Lowering -t to 512 or below avoids the condition.
Why this is worth a separate fix
The zero exit status is the problem rather than the unsupported configuration. Any script that
checks the return code concludes the run succeeded. If the output path is reused across runs — a
normal pattern in a benchmark loop — the previous run's file is still present, so downstream
analysis silently scores stale data as a successful result. There is no error to notice.
We hit this while measuring, and only caught it because an independent accuracy check produced
values that were impossible rather than merely wrong. A benchmark without such a check would have
published the previous configuration's numbers under this one's label.
Suggested fix
Two independent, small changes:
- Exit non-zero on this path (and on the other
[!] ERROR paths), so rc is meaningful.
- Remove or truncate any pre-existing output file before the kernel launch, so a failed run cannot
leave a stale file that looks like a result.
Either alone would have surfaced the failure; both together make it unmissable.
If -B auto genuinely cannot be supported at -t 1024, rejecting the combination in argument
parsing with a non-zero exit and a clear message would be clearer still than failing after launch.
Fatal kernel error prints a diagnostic, writes no output, and still exits 0
Summary
When banded execution is requested at the default threads-per-worker,
wfa.affine.gpuprints(
lib/sequence_alignment.cu:397), produces no output file, and returns exit status 0.Reproduction:
Observed on an RTX PRO 6000 Blackwell (188 SM) and on a MIG 1g.24gb slice of the same card, and on
GB10 (48 SM). Lowering
-tto 512 or below avoids the condition.Why this is worth a separate fix
The zero exit status is the problem rather than the unsupported configuration. Any script that
checks the return code concludes the run succeeded. If the output path is reused across runs — a
normal pattern in a benchmark loop — the previous run's file is still present, so downstream
analysis silently scores stale data as a successful result. There is no error to notice.
We hit this while measuring, and only caught it because an independent accuracy check produced
values that were impossible rather than merely wrong. A benchmark without such a check would have
published the previous configuration's numbers under this one's label.
Suggested fix
Two independent, small changes:
[!] ERRORpaths), sorcis meaningful.leave a stale file that looks like a result.
Either alone would have surfaced the failure; both together make it unmissable.
If
-B autogenuinely cannot be supported at-t 1024, rejecting the combination in argumentparsing with a non-zero exit and a clear message would be clearer still than failing after launch.