Pádraig Brady <[email protected]> writes:

> On 01/12/2025 22:14, Bruno Haible via GNU coreutils General Discussion wrote:
>> Hi,
>> On Ubuntu 24.04, the unit test that was added in commit
>> d0a51c614def6cf4f39fafe8ca7dcef925c4a503 fails when clang with ASAN and UBSAN
>> is used: The file timeout.status is expected to contain the number 125,
>> but it contains the number 124.
>> How to reproduce:
>> 1. Set the environment variables
>> CC="$CLANG_INST_DIR/bin/clang -Wl,-rpath,$CLANG_INST_DIR/lib"
>> CC="$CC
>> -fsanitize=address,undefined,signed-integer-overflow,shift,integer-divide-by-zero
>> -fno-sanitize-recover=undefined"; export CC
>> CFLAGS="-O0 -fno-omit-frame-pointer -ggdb"; export CFLAGS
>> ASAN_OPTIONS="detect_leaks=0 abort_on_error=1
>> allocator_may_return_null=1"
>> export ASAN_OPTIONS
>> 2. Configure and build coreutils.
>> 3.
>> $ cd src
>> $ { ./timeout -v .1 sleep 10 2>&1; echo $? >timeout.status; } | :
>> $ cat timeout.status
>> 124
>
>
> Ah right, the close_out() atexit handlerdoesn't call fclose(stderr) if 
> SANITIZE_ADDRESS is defined,
> "as sanitizers may report to stderr after this function returns".
>
> Otherwise timeout(1) would have noticed the EPIPE error
> trying to write to stderr, and exit with 125 rather than 124.
>
> The attached updates timeout(1) to exit with status 124 in either case,
> as it would be generally bad for 125 to hide the fact that we
> have actually timed out the command.
>
> I'll apply the attached a little later.

Ah, I saw that standard error wasn't closed when ASAN was enabled. But
for some reason I didn't think that close_stdout() would behave
differently when ASAN was enabled.

Exiting with 124 seems more correct in this case, since we want to know
the program timed out.

Thanks,
Collin

Reply via email to