Re: [PATCH v2 7/7] t/helper/simple-ipc: convert test-simple-ipc to use start_bg_command
From: Jeff Hostetler <hidden>
Date: 2021-11-08 14:58:03
On 11/4/21 3:46 PM, Adam Dinwoodie wrote:
On Monday 20 September 2021 at 03:36 pm +0000, Jeff Hostetler via GitGitGadget wrote:quoted
From: Jeff Hostetler <redacted> Convert test helper to use `start_bg_command()` when spawning a server daemon in the background rather than blocks of platform-specific code. Also, while here, remove _() translation around error messages since this is a test helper and not Git code.As part of testing the v2.34.0-rc0 release candidate on Cygwin, I've found this commit -- 05881a6fc9 (t/helper/simple-ipc: convert test-simple-ipc to use start_bg_command, 2021-09-20), according to my bisecting -- is causing t0052.1 to fail on 32-bit Cygwin. Somehow this is only affecting the 32-bit Cygwin build; the 64-bit build is working as expected. Specifically, the failure I'm seeing is as below:$ GIT_TRACE=1 sh t0052-simple-ipc.sh -vix trace: built-in: git init '/cygdrive/d/git-32/t/trash directory.t0052-simple-ipc' Initialized empty Git repository in /cygdrive/d/git-32/t/trash directory.t0052-simple-ipc/.git/ expecting success of 0052.1 'start simple command server': test_atexit stop_simple_IPC_server && test-tool simple-ipc start-daemon --threads=8 && test-tool simple-ipc is-active ++ test_atexit stop_simple_IPC_server ++ test 0 = 0 ++ test_atexit_cleanup='{ stop_simple_IPC_server } && (exit "$eval_ret"); eval_ret=$?; :' ++ test-tool simple-ipc start-daemon --threads=8 trace: run_command: test-tool simple-ipc run-daemon --name=ipc-test --threads=8 error: daemon failed to start error: last command exited with $?=1 not ok 1 - start simple command server # # test_atexit stop_simple_IPC_server && # test-tool simple-ipc start-daemon --threads=8 && # test-tool simple-ipc is-active # ++ stop_simple_IPC_server ++ test-tool simple-ipc stop-daemon ++ exit 1 ++ eval_ret=1 ++ :I've had a look at the code changes, and cannot work out what might be being handled differently in 32-bit and 64-bit Cygwin environments. Given the Cygwin project is considering dropping support for 32-bit Cygwin anyway, it might not be worth doing anything about this. But I thought it worth reporting in case there's something obvious to folk more familiar with this code.
How odd! Thanks for the report. I'll investigate. Jeff