servers: drop duplicate (and interacting) ctrl handlers on Windows, add exit message by vszakats · Pull Request #22487 · curl/curl

vszakats · 2026-08-05T07:59:36Z

On Windows, the init code calls SetConsoleCtrlHandler(), and before
this patch also set handlers for all Unixy signals. Of these, SIGBREAK
(used on Windows-only), SIGINT, SIGABRT and SIGTERM were also
setting up a SetConsoleCtrlHandler(), in addition to the call made
directly. (The rest, SIGHUP, SIGPIPE, SIGALRM are either missing
the macros, or ignored by signal() on Windows.)

As per WINE sources, SetConsolCtrlHandler(<h>, TRUE) calls are
additive, which means the test server set up two console ctrl handlers.

Then the ctrl handler set directly (ctrl_event_handler()), was
triggering the other signal handler via raise(), for the 'initiate
exit' logic, which in turn triggered exiting a wait within select_ws()
and other loops. The Windows window handler also made use of the
SIGTERM event to initiate exit via raise() and the second signal
handler.

To simplify, de-duplicate the ctrl handlers by dropping signal() calls
and keeping the direct Win32 call with ctrl_event_handler() doing all
the signal handling on Windows. Break out the 'initiate exit' logic into
a function and call it from both Unix and Windows signal/ctrl/window
handlers. Also drop calling raise() on exit, because it's a no-op
without a signal() pair.

Also:

drop logging the actual ctrl type number, replace with just logging
whether we handled the event, in ctrl_event_handler(). To avoid
using non-signal-safe functions (e.g. fprintf()) from the handler.
also replace logmsg() with WriteFile() to prevent regressions.
Ref: servers: drop CRT and curlx calls from main_window_loop() (Windows) #22045
replace logmsg() with WriteFile() in main_window_proc().
fix to forward ctrl handling to the OS in the rare case of failed
exit_event initialization on startup. To swap a possible hang
(within WaitForMultipleObjectsEx()) with an ungraceful shutdown.
add support for an 'exit message' string, set by signal/ctrl handlers,
and log it on app exit. To avoid the need to deal with logging within
the handlers, yet have a static trace message about the event.
Complementing the already logged signal number.
drop stderr trace message from exit_signal_handler() in favor of an
exit message. runtests triggers it frequantly, which added much noise
to stderr. As a bonus, this also allows dropping the compiler warning
suppression.
Reported-by: Stefan Eissing
Bug: servers: drop duplicate (and interacting) ctrl handlers on Windows, add exit message #22487 (comment)
Follow-up to 3aae64e servers: drop complex and redundant signal handler output #22507

Refs:
https://learn.microsoft.com/windows/console/setconsolectrlhandler
https://learn.microsoft.com/windows/console/registering-a-control-handler-function
https://learn.microsoft.com/cpp/c-runtime-library/reference/raise
https://learn.microsoft.com/cpp/c-runtime-library/reference/signal
https://gitlab.winehq.org/wine/wine/-/blob/wine-11.14/dlls/kernelbase/console.c#L1517-1526
https://github.com/huangqinjin/ucrt/blob/d6e817a4cc90f6f1fe54f8a0aa4af4fff0bb647d/misc/signal.cpp#L286-L348

Follow-up to fe28fcf 7dc8a98 0e05877 #5260

figure out/test/double-check how the WM_CLOSE codepath works.
It should work now like it did before, but without going through a raise/catch custom SIGTERM
cycle, and instead doing the same job directly. I suppose this should be enough without doing any
explicit things, such as generating a CTRL_BREAK_EVENT with GenerateConsoleCtrlEvent(),
or some other things from the window handler?
→ Works fine in local tests, above tricks not needed. The closing raise(SIGTERM) is rundant, no-op.
to relay messages from handlers, they may assign it to a string buffer which can be logged on exit from the main thread. (the signal number is already relayed this way). Perhaps centralize this instead of repeating for each server.
with this completed, and signal() use limited to non-Windows, it
becomes an option to drop legacy signal() support in favor of sigaction() + SA_RESTART,
to simplify the source, and drop detection from the build systems.
Not so fast, libcurl code also uses signal(), making the benefits minimal. [SKIP]
perhaps also to revise if the guard for each macro use is still necessary? [AFAICS, the actual signals are implementation-dependent, and not specified by POSIX, so better keep them.]
after this, we may give another change to reindtroduce graceful taskkills in runtests.
OR, if we don't bother, the window handler code can be dropped.
The graceful shutdown is indeed better because server.exe cleans up after
itself, deletes PID file and so on. → [contemplating options at servers: add option to build without window handler (Windows) #22496]

Copilot

Pull request overview

This PR simplifies Windows test-server termination handling by removing duplicate/overlapping signal-based control-handler registration, relying on a single SetConsoleCtrlHandler() path and consolidating “exit event” signaling behavior.

Changes:

Removes Windows signal() registrations that indirectly add extra console CTRL handlers.
Moves/centralizes Windows exit-event signaling logic into ctrl_event_handler().
Refactors install_signal_handlers() / restore_signal_handlers() to split Windows vs non-Windows behavior more cleanly.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Windows code no longer installs any SIGTERM/SIGINT handlers, but the hidden-window WM_CLOSE path still calls raise(signum) (util.c:459-462). Without a handler, raise(SIGTERM) will use the default action and can terminate the process immediately, skipping the normal got_exit_signal/exit_event-driven shutdown and cleanup that the test servers rely on." curl#22487 (comment)

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

tests/server/util.c:661

exit_event is created on Windows regardless of CURL_WINDOWS_UWP, but it is only closed inside the #ifndef CURL_WINDOWS_UWP block. When CURL_WINDOWS_UWP is defined this leaks the handle and leaves exit_event non-NULL for the remainder of the process lifetime. Close exit_event outside the CURL_WINDOWS_UWP guard (the guard should only apply to the hidden-window thread logic).

  if(exit_event && CloseHandle(exit_event))
    exit_event = NULL;
#endif

vszakats · 2026-08-05T10:38:21Z

The usual news, yes, this also does not fix "broken fork" CI errors (hangs):

sh: fork: retry: Resource temporarily unavailable
3004638 [main] sh 27837 dofork: child -1 - forked process 1272 died unexpectedly, retry 0, exit code 0xC0000142, errno 11
sh: fork: retry: Resource temporarily unavailable

https://github.com/curl/curl/actions/runs/30996302837/job/92274126158?pr=22487

Also: shorten code. Reported by Copilot Bug: #22487 (review) Closes #22489

Windows code no longer installs any SIGTERM/SIGINT handlers, but the hidden-window WM_CLOSE path still calls raise(signum) (util.c:459-462). Without a handler, raise(SIGTERM) will use the default action and can terminate the process immediately, skipping the normal got_exit_signal/exit_event-driven shutdown and cleanup that the test servers rely on." curl#22487 (comment)

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

tests/server/util.c:663

In restore_signal_handlers() on Windows, exit_event is closed twice in the non-UWP build (once inside the !CURL_WINDOWS_UWP block and again immediately after). This is redundant and makes the control flow harder to follow (and will retry CloseHandle() only on failure of the first call). Close the handle in a single place outside the !CURL_WINDOWS_UWP block.

  if(exit_event && CloseHandle(exit_event))
    exit_event = NULL;
#endif
  if(exit_event && CloseHandle(exit_event))
    exit_event = NULL;

Windows code no longer installs any SIGTERM/SIGINT handlers, but the hidden-window WM_CLOSE path still calls raise(signum) (util.c:459-462). Without a handler, raise(SIGTERM) will use the default action and can terminate the process immediately, skipping the normal got_exit_signal/exit_event-driven shutdown and cleanup that the test servers rely on." curl#22487 (comment)

Copilot

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

tests/server/util.c:396

exit_signal_handler() is documented as only calling async-signal-safe functions, but this error path calls strlen(serverlogfile), which is not async-signal-safe per POSIX and can lead to undefined behavior when invoked from a signal handler. Avoid strlen here by writing the path with a simple byte loop.

      static const char msg[] = "exit_signal_handler: failed opening ";
      (void)write(STDERR_FILENO, msg, CURL_CSTRLEN(msg));
      (void)write(STDERR_FILENO, serverlogfile, strlen(serverlogfile));
      (void)write(STDERR_FILENO, "\n", 1);

`strlen()` is only guaranteed to be signal-safe since POSIX.1-2008. Ref: https://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html#tag_02_04_03 Reported by Copilot Bug: #22487 (review) Follow-up to e95f509 #16852 Closes #22491

These `SIG*` macro are provided by all supported Windows toolchains. Cherry-picked from #22487 Closes #22493

Windows code no longer installs any SIGTERM/SIGINT handlers, but the hidden-window WM_CLOSE path still calls raise(signum) (util.c:459-462). Without a handler, raise(SIGTERM) will use the default action and can terminate the process immediately, skipping the normal got_exit_signal/exit_event-driven shutdown and cleanup that the test servers rely on." curl#22487 (comment)

Windows code no longer calls `signal()`, therefore the `raise()` call is now a no-op.

This reverts commit 084c48b.

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (2)

tests/server/first.c:62

exit_msg strings being assigned include a trailing \n (e.g. in the Windows ctrl/window handlers and exit_signal_handler()), but first.c later logs them via logmsg("... %s", exit_msg), which will embed a newline into the formatted log line and break the log format (double/newline-split lines). Consider stripping a trailing newline before logging (or store messages without newlines).

  if(serverlogfile && exit_msg)
    logmsg("========> exit message: %s", exit_msg);

tests/server/util.c:488

main_window_proc() calls initiate_exit(SIGTERM) but ignores its return value. If exit_event failed to initialize (rare but explicitly handled in ctrl_event_handler()), initiate_exit() returns FALSE and the server may keep blocking in WaitForMultipleObjectsEx()/select_ws() after WM_CLOSE. Consider adding a fallback to an ungraceful shutdown here too (consistent with the ctrl handler’s “avoid hang” behavior).

                             &dwWritten, NULL);
      exit_msg = msg;
      initiate_exit(SIGTERM);
      break;

vszakats · 2026-08-06T11:29:41Z

Suppressed comments (2)
tests/server/first.c:62

exit_msg strings being assigned include a trailing \n (e.g. in the Windows ctrl/window handlers and exit_signal_handler()), but first.c later logs them via logmsg("... %s", exit_msg), which will embed a newline into the formatted log line and break the log format (double/newline-split lines). Consider stripping a trailing newline before logging (or store messages without newlines).
  if(serverlogfile && exit_msg)
    logmsg("========> exit message: %s", exit_msg);

I'm aware. I don't think this deserve spending more effort on. There will be an extra newline there.
Anyone feel free to fix it, if bad.

tests/server/util.c:488

main_window_proc() calls initiate_exit(SIGTERM) but ignores its return value. If exit_event failed to initialize (rare but explicitly handled in ctrl_event_handler()), initiate_exit() returns FALSE and the server may keep blocking in WaitForMultipleObjectsEx()/select_ws() after WM_CLOSE. Consider adding a fallback to an ungraceful shutdown here too (consistent with the ctrl handler’s “avoid hang” behavior).
                             &dwWritten, NULL);
      exit_msg = msg;
      initiate_exit(SIGTERM);
      break;

I'm also aware, but no idea what to do here as a fallback. If you do, please shout!

icing · 2026-08-06T11:32:26Z

I get now a terminal full scroll of these exit messages since your previous change at the end of test runs before the summary result.

vszakats · 2026-08-06T11:38:50Z

I get now a terminal full scroll of these exit messages since your previous change at the end of test runs before the summary result.

Thanks, I think I got it, runtests always signals the server, so after each server shutdown there is one.
It's a good reason to just delete that stderr message.

vszakats · 2026-08-06T11:43:33Z

I'll add it to this PR, to avoid reversing order of two conflicting patches. This one adds an exit_msg, and makes the stderr output redundant anyway.

vszakats · 2026-08-06T11:45:30Z

...and dang, this also did not fix the 2304 flaky fail: https://github.com/curl/curl/actions/runs/31097520068/job/92602997991?pr=22487

Copilot

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (5)

tests/server/util.c:443

exit_msg is overwritten on every CTRL event (including during shutdown), while exit_signal is only captured on the first event. This can lead to confusing/mismatched exit logs. Consider only setting exit_msg once (first event wins).

    WriteFile(out, msgU, CURL_CSTRLEN(msgU), &dwWritten, NULL);
    exit_msg = msgU;
    return FALSE;
  }
  if(!initiate_exit(signum)) {

tests/server/util.c:475

In the WM_CLOSE path, the message stored in exit_msg includes a trailing newline (which will create embedded newlines when later logged via logmsg()), and it can also overwrite a previously recorded exit message. Store the message without \n and set it only if it hasn't already been set.

      static const char msg[] = "main_window_proc(): WM_CLOSE -> SIGTERM\n";
      DWORD dwWritten;
      WriteFile(GetStdHandle(STD_ERROR_HANDLE), msg, CURL_CSTRLEN(msg),
                             &dwWritten, NULL);
      exit_msg = msg;

tests/server/util.c:424

The strings assigned to exit_msg in the Windows handlers include a trailing \n. Since first.c later logs exit_msg via logmsg() (which appends its own newline), this will produce embedded newlines and break log line formatting. Prefer storing messages without trailing newlines (you can still include newlines in the direct WriteFile() output if desired).

  static const char msgU[] = "ctrl_event_handler(): unhandled\n";
  static const char msgH[] = "ctrl_event_handler(): handled\n";
  static const char msgF[] = "ctrl_event_handler(): failed to handle\n";

tests/server/util.c:374

exit_signal_handler() sets exit_msg unconditionally even though exit_signal is only captured once. To keep the exit message consistent with the first terminating signal (and avoid later signals overwriting it), only set exit_msg when it hasn't already been set.

This issue also appears in the following locations of the same file:

line 439
line 471

  exit_msg = "exit_signal_handler(): triggered";
  (void)initiate_exit(signum);

tests/server/util.c:344

The MSVC <= 1700 workaround for SIG_ERR was removed. Older MSVC defines SIG_ERR in a way that can trigger warning C4306 when assigning to SIGHANDLER_T, which can break builds that treat warnings as errors. Consider restoring the guarded redefinition for those compilers.

typedef void (*SIGHANDLER_T)(int);

To simplify and to avoid the chance of potential interference or thread-safety issues. If one these 3 Win32 API calls fail, there is likely a serious problem, out of the code's control. Knowing `GetLastError()` is unlikely to help. Refs: https://learn.microsoft.com/windows/win32/api/winuser/nc-winuser-wndproc https://learn.microsoft.com/previous-versions/windows/desktop/legacy/ms686736(v=vs.85) https://learn.microsoft.com/windows/win32/api/winuser/nf-winuser-getmessage https://learn.microsoft.com/windows/win32/api/winuser/nf-winuser-createwindowexa https://learn.microsoft.com/windows/win32/api/winuser/nf-winuser-registerclassa Ref: 9ea4881 #22487 Ref: 1c49f2f #18451 Follow-up to ac1e206 Closes #22045

vszakats · 2026-08-07T17:47:54Z

Noting that after this patch, in one particular Windows CI job that
went on timeout, this output appeared, which is the result of this
patch compared to the lack of these lines before. If this becomes
an issue, the WriteFile() (introduced by this commit) can be
dropped in favor of the log entry with this same line.

Thu, 06 Aug 2026 23:50:56 GMT test 3221 [HTTP Digest with CRLF in username]
Thu, 06 Aug 2026 23:50:56 GMT --pd---em-- OK (1934 out of 1951, remaining: 00:01, took 0.217s, duration: 03:06)
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT test 3218 [FTP with CR control characterTerminate batch job (Y/N)? 
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:33 GMT ctrl_event_handler(): handled
Thu, 06 Aug 2026 23:55:38 GMT Error: The operation was canceled.

Ref: https://github.com/curl/curl/actions/runs/31132202463/job/92723553053#step:14:4002

vszakats added tests Windows Windows-specific labels Aug 5, 2026

vszakats changed the title ~~servers: drop duplicate ctrl handlers on Windows~~ servers: drop duplicate (and interacting) ctrl handlers on Windows Aug 5, 2026

vszakats requested a lite review from Copilot August 5, 2026 08:53

Copilot started reviewing on behalf of vszakats August 5, 2026 08:53 View session

Copilot AI reviewed Aug 5, 2026

View reviewed changes

Comment thread tests/server/util.c

Comment thread tests/server/util.c Outdated

vszakats marked this pull request as draft August 5, 2026 09:39

vszakats requested a lite review from Copilot August 5, 2026 10:16

Copilot started reviewing on behalf of vszakats August 5, 2026 10:16 View session

Copilot AI reviewed Aug 5, 2026

View reviewed changes

Comment thread tests/server/util.c

vszakats mentioned this pull request Aug 5, 2026

servers: fix HANDLE leak in UWP builds #22489

Closed

vszakats added a commit that referenced this pull request Aug 5, 2026

servers: fix HANDLE leak in UWP builds

7babac8

Also: shorten code. Reported by Copilot Bug: #22487 (review) Closes #22489

vszakats force-pushed the t-w-dupe-ctrl-handler branch from ada5abf to d44d763 Compare August 5, 2026 11:10

vszakats requested a lite review from Copilot August 5, 2026 11:11

Copilot started reviewing on behalf of vszakats August 5, 2026 11:12 View session

Copilot AI reviewed Aug 5, 2026

View reviewed changes

vszakats force-pushed the t-w-dupe-ctrl-handler branch from d44d763 to 1de8739 Compare August 5, 2026 11:22

vszakats marked this pull request as ready for review August 5, 2026 11:23

vszakats requested a lite review from Copilot August 5, 2026 11:38

Copilot started reviewing on behalf of vszakats August 5, 2026 11:38 View session

Copilot AI reviewed Aug 5, 2026

View reviewed changes

This was referenced Aug 5, 2026

servers: fix to avoid a non-signal-safe call in signal handler #22491

Closed

servers: drop redundant guards on Windows #22493

Closed

vszakats added a commit that referenced this pull request Aug 5, 2026

servers: drop redundant guards on Windows

947ae0e

These `SIG*` macro are provided by all supported Windows toolchains. Cherry-picked from #22487 Closes #22493

vszakats added 8 commits August 6, 2026 12:53

show if tried to handle but failed

2932d75

show if tried to handle but failed f

6eb21cc

dedupe strings, output at begin/end

4fa8f1b

replace wndproc msg with WriteFile

1ddc729

first.c raise() is a no-op on Windows now, exclude for clarity

c117817

Windows code no longer calls `signal()`, therefore the `raise()` call is now a no-op.

Revert "dedupe strings, output at begin/end"

a825930

This reverts commit 084c48b.

support and set an exit_msg

f43c87b

fixup

0633bea

vszakats force-pushed the t-w-dupe-ctrl-handler branch from c9ea16c to 0633bea Compare August 6, 2026 11:07

vszakats changed the title ~~servers: drop duplicate (and interacting) ctrl handlers on Windows~~ servers: drop duplicate (and interacting) ctrl handlers on Windows, add exit message Aug 6, 2026

vszakats requested a lite review from Copilot August 6, 2026 11:15

Copilot started reviewing on behalf of vszakats August 6, 2026 11:15 View session

cleanup

6ee27c9

Copilot AI reviewed Aug 6, 2026

View reviewed changes

expand comments

715a926

drop stderr output from exit_signal_handler()

54f16b0

vszakats requested a lite review from Copilot August 6, 2026 11:53

Copilot started reviewing on behalf of vszakats August 6, 2026 11:54 View session

Copilot AI reviewed Aug 6, 2026

View reviewed changes

vszakats closed this in 9ea4881 Aug 6, 2026

vszakats deleted the t-w-dupe-ctrl-handler branch August 6, 2026 12:04

vszakats mentioned this pull request Aug 6, 2026

servers: drop CRT and curlx calls from main_window_loop() (Windows) #22045

Closed

1 task

Uh oh!

Uh oh!

Conversation

vszakats commented Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

vszakats commented Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

vszakats commented Aug 6, 2026

Uh oh!

icing commented Aug 6, 2026

Uh oh!

vszakats commented Aug 6, 2026

Uh oh!

vszakats commented Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vszakats commented Aug 6, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

vszakats commented Aug 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

vszakats commented Aug 5, 2026 •

edited

Loading

vszakats commented Aug 5, 2026 •

edited

Loading

vszakats commented Aug 6, 2026 •

edited

Loading