First push with null patch, to get current gitlab runner result in [pipeline #42287](https://gitlab.winehq.org/bernhardu/wine/-/pipelines/42287). Unfortunately, did not fail this time.
Older examples are: - [job #157583](https://gitlab.winehq.org/wine/wine/-/jobs/157583#L2282) - [job #157314](https://gitlab.winehq.org/wine/wine/-/jobs/157314#L1957) - [job #157131](https://gitlab.winehq.org/wine/wine/-/jobs/157131#L2052) - [job #157068](https://gitlab.winehq.org/wine/wine/-/jobs/157068#L1955) - [job #157032](https://gitlab.winehq.org/wine/wine/-/jobs/157032#L2150) - [job #156785](https://gitlab.winehq.org/wine/wine/-/jobs/156785#L2112) - [job #156713](https://gitlab.winehq.org/wine/wine/-/jobs/156713#L2048) - [job 156677#](https://gitlab.winehq.org/wine/wine/-/jobs/156677#L2030)
So happens just a few times per day.
The value -1073741510 in `timeout.exe:timeout:06b4 done (-1073741510) in 5s 177B` equals to 0xC000013A, STATUS_CONTROL_C_EXIT. Therefore the assumption the ctrl-c from the test reaches sometimes the parent process.
With the patch activated, this [pipeline #42291](https://gitlab.winehq.org/bernhardu/wine/-/pipelines/42291).
-- v4: timeout/tests: Move the ctrl-c test below a intermediate process.
From: Bernhard Übelacker bernhardu@mailbox.org
Currently the parent process returns a STATUS_CONTROL_C_EXIT instead of the child process. --- programs/timeout/tests/timeout.c | 30 +++++++++++++++++++++++++++++- 1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/programs/timeout/tests/timeout.c b/programs/timeout/tests/timeout.c index bd99eb9e5e1..d6ee6c92357 100644 --- a/programs/timeout/tests/timeout.c +++ b/programs/timeout/tests/timeout.c @@ -136,9 +136,37 @@ static void test_ctrlc(void) run_timeout_ctrlc("/nobreak", 1); }
+static void test_ctrlc_intermediate(int argc, char** argv) +{ + char path_name[MAX_PATH]; + STARTUPINFOA startup; + PROCESS_INFORMATION info; + + memset(&startup, 0, sizeof(startup)); + startup.cb = sizeof(startup); + sprintf(path_name, "%s %s %s", argv[0], argv[1], "ctrlc_intermediate"); + ok(CreateProcessA(NULL, path_name, NULL, NULL, FALSE, + CREATE_NEW_PROCESS_GROUP | CREATE_NEW_CONSOLE, + NULL, NULL, &startup, &info), + "CreateProcess failed.\n"); + wait_child_process(info.hProcess); + CloseHandle(info.hProcess); + CloseHandle(info.hThread); +} + START_TEST(timeout) { + int argc; + char** argv; BOOL ret; + + argc = winetest_get_mainargs(&argv); + if(argc == 3 && !strcmp(argv[2], "ctrlc_intermediate")) + { + test_ctrlc(); + return; + } + /* always run on a separate console, so that: * - we're sure to have a valid console input handle (no Wine unix console...) * - we can send ctrl-c events without interfering with parent (winetest...) @@ -158,5 +186,5 @@ START_TEST(timeout) }
test_basic(); - test_ctrlc(); + test_ctrlc_intermediate(argc, argv); }
On Thu May 15 13:26:35 2025 +0000, Bernhard Übelacker wrote:
changed this line in [version 4 of the diff](/wine/wine/-/merge_requests/8051/diffs?diff_id=178062&start_sha=b50d4702bcd9641f98bd3e04a7ee59bc1cccb709#03c5b6b4bf937e2b59be644b061f67b0fe537b58_144_137)
Sorry, I had not completely read the test an failed to see the parent is already using SetConsoleCtrlC.
I pushed another version which I hope gets near your second option. But with it I get also sometimes two of these lines: `061c:0628:fixme:console:default_ctrl_handler Terminating process 61c on event 0` with a failure from _run_timeout_ctrlc/"Expected exitcode %ld, got %lx\n" with exitcode_expected=1.
On Thu May 15 14:05:20 2025 +0000, Bernhard Übelacker wrote:
Sorry, I had not completely read the test an failed to see the parent is already using SetConsoleCtrlC. I pushed another version which I hope gets near your second option. But with it I get also sometimes two of these lines: `061c:0628:fixme:console:default_ctrl_handler Terminating process 61c on event 0` with a failure from _run_timeout_ctrlc/"Expected exitcode %ld, got %lx\n" with exitcode_expected=1.
didn't try it (and my first post wasn't 100% clear, sorry about that), but I think we need an intermediate process for each one of the two tests... basically we don't control when the ctrl-c event is dispatched, so as soon as GenerateConsoleCtrlEvent is called, re-enabling ctrl-c opens a window of risk if the event isn't dispatched soon enough
in the error you see, did you discriminate which process is 0x61c?
-
Bernhard Übelacker -
Bernhard Übelacker (＠bernhardu)
-
eric pouech (＠epo)