Re: [PATCH] testsuite: Introduce gdb_watchdog (avoid unistd.h/alarm)

[Pedro Alves <pedro@palves.net>]

On 2025-08-10 04:28, Kevin Buettner wrote:
> Hi Pedro,

Hi!

> 
> On Fri,  8 Aug 2025 23:50:50 +0100
> This all sounds reasonble to me.
> 
> One possible nit, and it's *way* outside my wheelhouse, so feel free to
> ignore it...
> 
> [...]
>> +static VOID CALLBACK
>> +_gdb_watchdog_timer_routine (PVOID lpParam, BOOLEAN TimerOrWaitFired)
>> +{
>> +  fputs (_gdb_watchdog_msg, stderr);
>> +  fflush (stderr);
> 
> On POSIX, fputs and fflush are not async-signal-safe.  It's my
> understanding that they aren't on WIN32 either, but I don't know
> whether this is actually a signal handler.

There isn't actually a concept of async-signal-safety on Windows.  Signal
handlers don't run on the mainline code's preempted stack, like happen on POSIX.
Instead, Windows runs the signal handler on a system-created thread, concurrently
with mainline code.

In this case, we don't have a signal handler, but it's basically the same thing.
The timer runs on a separate thread (Windows thread-pool thread in this case).

So the concern here would be the same concern with any two threads calling
into fputs/fflush at the same time.  The stdio routines are thread safe, in
that they serialize access to FILE* streams with a per-stream internal lock,
so simultaneous fputs calls to the same stream from different threads won’t
corrupt the stream's buffer.

I think that the only case where a call to fputs/fflush here could block
indefinitely, is if they end up blocking inside the internal WriteFile
they do, say, because they are writing to a full pipe and the reading
end isn't consuming input.  But for that scenario, going directly to
WriteFile won't help either, it will block the same way.

This is exactly the same for the write call on the POSIX side, BTW.

I think the only way to avoid this would be if we tried to open the
handle with FILE_FLAG_OVERLAPPED and do async writes, but that adds
complexity and the watchdog thread must pump the overlapped completion
or timeout logic.  Similarly, on the POSIX side we'd have to make sure to
do an async write.

Or we could just not print anything.

abort() is a CRT function too, and it flushes streams (hmm, maybe I don't need
the fflush after all), and if we were to avoid fputs/fflush to avoid locks, then
I'd think that we would want to avoid abort too.  Maybe call
ExitProcess or TerminateProcess directly?

However, I was thinking that using abort() could be nice for leaving it open the possibility
making Windows generate a minidump or for hooking Windows's crash reporting mechanism with
cygwin's dumper to generate an ELF core dump if we wanted, or something of the sort.
I suppose we could still have that if we terminate the process with something at
the Win32 level that triggers the same mechanisms, like maybe raise an uncaught exception?

Dunno.  fputs + abort just seems appealing to me for being simple, and abort() being the
same that we do on the POSIX side.

And in the end I think it's like you say -- I doubt it matters much.

> 
> Regardless, the rest LGTM.  And even if fputs and fflush aren't
> async-signal-safe in this context, I doubt that it matters much.
> 
> So...
> 
> Approved-by: Kevin Buettner <kevinb@redhat.com>
>