debian meson clang debug: spawn-oom test timed out in CI
Job #52256616 failed for c807028d:
20/51 dbus:dbus / spawn-oom TIMEOUT 30.02s
...
--- Listing only the last 100 lines from a long log. ---
# spawn_segfault: will fail malloc 33 and 1 that follow
# spawn_segfault: will fail malloc 32 and 1 that follow
...
# spawn_segfault: will fail malloc 1 and 2 that follow
# spawn_segfault: will fail malloc 0 and 2 that follow
ok 12 - spawn_segfault oom
# spawn_segfault oom test took 11 seconds
ok 13 - spawn_segfault oom did not leak memory
# Running test: spawn_exit oom
# Running "spawn_exit" once to count mallocs
# "spawn_exit" has about 28 mallocs in total
# testing "spawn_exit" with up to 4 consecutive malloc failures
# testing "spawn_exit" with 2 consecutive malloc failures
# spawn_exit: will fail malloc 38 and 0 that follow
# spawn_exit: will fail malloc 37 and 0 that follow
# spawn_exit: will fail malloc 36 and 0 that follow
# spawn_exit: will fail malloc 35 and 0 that follow
# spawn_exit: will fail malloc 34 and 0 that follow
# spawn_exit: will fail malloc 33 and 0 that follow
# spawn_exit: will fail malloc 32 and 0 that follow
# spawn_exit: will fail malloc 31 and 0 that follow
# spawn_exit: will fail malloc 30 and 0 that follow
# spawn_exit: will fail malloc 29 and 0 that follow
# spawn_exit: will fail malloc 28 and 0 that follow
# spawn_exit: will fail malloc 27 and 0 that follow
# spawn_exit: will fail malloc 26 and 0 that follow
# spawn_exit: will fail malloc 25 and 0 that follow
# spawn_exit: will fail malloc 24 and 0 that follow
# spawn_exit: will fail malloc 23 and 0 that follow
I think maybe this is just genuinely that slow, and might just need a longer timeout?
When it ran successfully in 0a90d295, it only needed 1.27s. However, in that commit, we were running it with DBUS_TEST_MALLOC_FAILURES=0
, which turns off this extra-slow checking.
In c807028d, it looks as though we're running it once with DBUS_TEST_MALLOC_FAILURES=0
, but then running it a second time as part of meson dist
; and that second time, it's building with full test coverage, etc. and we didn't use DBUS_TEST_MALLOC_FAILURES=0
for the tests.