diff options
author | Nat Goodspeed <nat@lindenlab.com> | 2024-05-16 13:30:14 -0400 |
---|---|---|
committer | Nat Goodspeed <nat@lindenlab.com> | 2024-05-16 13:30:14 -0400 |
commit | 1b6e2ef62cec9608d160ea25d99080f0e2964ee5 (patch) | |
tree | e8ad6e077301e6d9d36fc74f74303d18278eb790 /.github | |
parent | da469588244d490673ec08d186526d8832dcbd62 (diff) |
On Windows, defend test.cpp against structured exceptions too.
Since August 2023, we've seen occasional GitHub Windows build test runs
terminate with 0xC00000FD: stack overflow. We've usually responded by bumping
up the default coroutine stack size.
On closer examination, it's always llleap_test.cpp that blows up that way --
and llleap_test.cpp doesn't appear to use coroutines at all. So apparently
we've been consuming more address space for ALL viewer coroutines without
actually addressing the problem.
Reset the default coroutine stack size to where it was before we started
bumping it up in response to these llleap_test.cpp stack overflow failures.
Note that LLCoros already catches and reports Windows structured exceptions,
underscoring that the observed stack overflow is not from within a coroutine.
While at it, restore the Windows llleap_test.cpp data volume to match Posix.
We think the problem that led to reducing that data volume was an APR bug,
which we hope has been fixed.
Equip test.cpp, the test driver program for all our TUT unit and integration
tests, with a Windows structured exception handler. Try to treat a Windows
structured exception as a test failure -- instead of silently terminating with
0xC00000FD. Moreover, when a structured exception occurs, output a stack trace
so we can try to track it down.
Diffstat (limited to '.github')
0 files changed, 0 insertions, 0 deletions