looking at the failing test, we have:
- overall run time: a bit more than 7 seconds - we have three tests that wait for 1 second (/T 1...) - we have two tests that wait for 2 seconds before sending the ctrl-c - so 3*1+2*2=7 which makes we believe that the ctrl-c in the two tests really work as expected
so it's likely the default handler which doesn't return the expected value or the process being killed before the default handler returns, rather than your MR being wrong
could you add this to your patch so we can test if this a hint of what goes wrong
``` diff --git a/dlls/kernelbase/console.c b/dlls/kernelbase/console.c index 97c5462c42f..3c87f36e0d9 100644 --- a/dlls/kernelbase/console.c +++ b/dlls/kernelbase/console.c @@ -75,7 +75,7 @@ static BOOL WINAPI default_ctrl_handler( DWORD type ) if (type == CTRL_C_EVENT || type == CTRL_BREAK_EVENT) RtlExitUserProcess( STATUS_CONTROL_C_EXIT ); else - RtlExitUserProcess( 0 ); + RtlExitUserProcess( 666 ); return TRUE; } diff --git a/server/thread.c b/server/thread.c index b3ce5d9ac95..ec68f3af078 100644 --- a/server/thread.c +++ b/server/thread.c @@ -1289,7 +1289,7 @@ void kill_thread( struct thread *thread, int violent_death ) /* if it is waiting on the socket, we don't need to send a SIGQUIT */ violent_death = 0; } - kill_console_processes( thread, 0 ); + kill_console_processes( thread, 667 ); abandon_mutexes( thread ); wake_up( &thread->obj, 0 ); if (violent_death) send_thread_signal( thread, SIGQUIT ); ```
If you get 666 or 667 as exit code, we could then know where to look at <g>.
If you get one of these, then the way to move forward on this MR is either to wait for the above to be correctly fixed, or mark the failing test as todo_wine (given that we only have two tests, marking it with todo_wine_if(exitcode != exitcode_expected) would be just fine)
also you could fix the spelling of STRING_PRESS_CRTLC into STRING_PRESS_CTRLC
I'll be AFK for the rest of the week.