A build error occurred after updating xcode, xcode-select ( macos )

[shove70]

Describe the bug

$ xcodebuild -version
Xcode 15.0
Build version 15A240d

$ xcode-select -version
xcode-select version 2397.

Reproduction Steps

$ cd /usr/local/v
$ git pull --ff-only upstream master
$ make

cd ./vc && git clean -xf && git pull --quiet
cd ./thirdparty/tcc && git clean -xf && git pull --quiet
cc  -std=gnu99 -w -o v1.exe ./vc/v.c -lm -lpthread
./v1.exe -no-parallel -o v2.exe  cmd/v
./v2.exe -nocache -o ./v  cmd/v
rm -rf v1.exe v2.exe
signal 11: segmentation fault
0   libsystem_platform.dylib            0x00007ff805bdd5ed _sigtramp + 29
1   ???                                 0x0000000000000000 0x0 + 0
2   v                                   0x000000010ed08eeb os__Process__spawn + 155
3   v                                   0x000000010ed08e13 os__Process_wait + 35
4   v                                   0x000000010f018354 v__builder__Builder_run_compiled_executable_and_exit + 3332
5   v                                   0x000000010f015c9c v__builder__compile + 124
6   v                                   0x000000010f021329 main__rebuild + 121
7   v                                   0x000000010f0204b8 main__main + 2376
8   v                                   0x000000010f025e50 main + 64
9   dyld                                0x00007ff80585641f start + 1903
make: *** [all] Error 139

Expected Behavior

no error.

Current Behavior

error.

Possible Solution

No response

Additional Information/Context

No response

V version

V 0.4.1 77219de

Environment details (OS name and version, etc.)

V full version: V 0.4.1 77219de
OS: macos, macOS, 13.5.2, 22G91
Processor: 8 cpus, 64bit, little endian, Intel(R) Core(TM) i7-8569U CPU @ 2.80GHz

getwd: /usr/local/v
vexe: /usr/local/v/v
vexe mtime: 2023-09-19 03:02:34

vroot: OK, value: /usr/local/v
VMODULES: OK, value: /Users/shove/.vmodules
VTMP: OK, value: /tmp/v_501

Git version: git version 2.39.3 (Apple Git-145)
Git vroot status: weekly.2023.37-35-g77219de1
.git/config present: true

CC version: Apple clang version 15.0.0 (clang-1500.0.40.1)
thirdparty/tcc status: thirdparty-macos-amd64 46662e20

[tedt10e]

same here too.

[jhuntos]

V 0.4.1 09006fa last v up working for me with "v run ./"
after that I can compile with "v ./" and run "./myapp" but same error as above when "v run ./"

[johann-koebbe-vericity]

Just an FYI. I ran into it, too. I've been interacting with @spytheman on Discord. I think they have an idea of what's going on and an idea for a work around. From our testing, it's only a problem with v run .. Compiling and running the resulting executable seems to be okay.

[shove70]

thanks

[larpon]

@spytheman added a workaround here: ed42341
If you use -use-os-system-to-run it should not crash. We are still not 100% sure why this suddenly has stopped working. It seems to originate from os.new_process.

[prantlf]

I can confirm that compiling produces a runnable binary, but otherwise compiling, running and testing fails. I tested on MacOS with 0.4.1 28234c7:

❯ v test src/basename_test.v
---- Testing... ----------------------------------------------------------------------------------------------
 FAIL   833.164 ms /Users/prantlf/Sources/github/v-bpath/src/basename_test.v
signal 11: segmentation fault
0   v                                   0x000000010731091b os__Process_wait + 299
1   v                                   0x000000010760d6db main__rebuild + 12027
2   v                                   0x00000001076139d2 main + 2194
3   dyld                                0x00007ff80b93941f start + 1903

--------------------------------------------------------------------------------------------------------------
Failed command 1:    '/usr/local/Cellar/vlang/0.4.1/libexec/v'   -o '/tmp/v_501/tsession_7ff84f36c700_225745575/basename_test' '/Users/prantlf/Sources/github/v-bpath/src/basename_test.v'
Summary for all V _test.v files: 1 failed, 1 total. Runtime: 834 ms, on 1 job.

❯ v run src/basename_test.v
signal 11: segmentation fault
0   v                                   0x0000000106b3991b os__Process_wait + 299
1   v                                   0x0000000106e366db main__rebuild + 12027
2   v                                   0x0000000106e3c9d2 main + 2194
3   dyld                                0x00007ff80b93941f start + 1903

❯ v src/basename_test.v
signal 11: segmentation fault
0   v                                   0x000000010914591b os__Process_wait + 299
1   v                                   0x00000001094426db main__rebuild + 12027
2   v                                   0x00000001094489d2 main + 2194
3   dyld                                0x00007ff80b93941f start + 1903

The magic wand -use-os-system-to-run helps:

❯ v -use-os-system-to-run test src/basename_test.v
---- Testing... ----------------------------------------------------------------------------------------------
 OK    1655.192 ms /Users/prantlf/Sources/github/v-bpath/src/basename_test.v
--------------------------------------------------------------------------------------------------------------
Summary for all V _test.v files: 1 passed, 1 total. Runtime: 1656 ms, on 1 job.

How about making -use-os-system-to-run default for the time being?

[johann-koebbe-vericity]

@prantlf You can put it in an environment variable to make it default for you until a proper resolution is found. See https://discord.com/channels/592103645835821068/592294828432424960/1154738139953385484.

[shove70]

solved via 053d2be