ci: run the unit tests under a 256 KiB stack - #2495
Conversation
Some code paths can overrun the default stack size, as reported in issue #2347. A dedicated Ubuntu leg now builds the Botan shared configuration and runs ctest after ulimit -s 256, so stack overruns fail loudly in CI rather than only on constrained deployments. The existing unrestricted legs are left unchanged.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2495 +/- ##
=======================================
Coverage 85.45% 85.45%
=======================================
Files 125 125
Lines 23042 23042
=======================================
Hits 19691 19691
Misses 3351 3351 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
ni4
left a comment
ni4
left a comment
There was a problem hiding this comment.
LGTM, but we seem to have segfault in CI.
The segfault of test_ffi_key_export_autocrypt under the 256 KiB stack is a stack overflow inside the regex implementation, not in library code: validating the multi-kilobyte base64 export with a regex makes the matcher recurse once per repetition of the character class, which libstdc++ does without any depth bound, and the recursion exhausts the limited stack. Replace the validation with a direct check that the value consists of base64 characters and carries at most two padding characters, which does not recurse. Also restore the workflow to its pre-debug form, now that the temporary gdb capture has served its purpose.
|
The segfault is root-caused, and it turns out to be good news for the library. The backtrace captured with gdb shows the crash is unbounded recursion inside the C++ standard library regex engine: the test validated the multi-kilobyte base64 export with The fix replaces the regex validation with a direct check that the exported value consists of base64 characters and carries at most two padding characters, which does not recurse. With the fix, the test and the other export tests pass locally under the same 256 KiB limit. The temporary gdb instrumentation has been removed and the workflow is back to its intended form. Thank you @ni4 for insisting on chasing this one down; the leg now does exactly what issue #2347 asked of it, failing loudly when the stack budget is exceeded and passing when the code respects it. |
The character-set scan passed the body length into the overload that limits the length of the alphabet, not the search range, which reads past the end of the alphabet literal on implementations that do not clamp it to the string length, as the AddressSanitizer run of the Windows sanitizer leg caught. Search a substring of the value instead, which needs no length bookkeeping.
2 participants
Summary
ulimit -s 256, as suggested by @ni4 in Add test runner with limited stack size. #2347.ctestserially so a stack fault is easy to attribute.Test plan