xcodebuild crash on intel VM

[alcroito]

Hi,

I filed an Apple feedback FB19614690 but I was told by people involved that I should also create an issue here.

TLDR:
I'm seeing that xcodebuild randomly crashes when building a simple project on multiple versions of Xcode and macOS, inside an intel VM on an Intel mac host. This happens across many hosts with the same kind of CPU, but doesn't happen on other kind of hosts.

Crash can be reproduced in about 50-200 xcodebuild calls.

Intel host info:
CPU: Intel(R) Core(TM) i7-8700B CPU @ 3.20GHz
macOS version: 13.6.9
Parallels version: 18.2.0-53488

Guest info:
macOS 15.6 or macOS 26 beta5
Xcode version 16.1, 16.4, latest 26.0 beta 5

Attaching a small reproducer that contains a default-created xcode project, that build a main.cpp, and a shell script that runs xcodebuild on that project until it fails.

Also attaching the latest ips file of the crash.

I was told this might have been fixed #728

So I tried building the main branch of swift-build (e3d484f02be25ca96d116706ddc4d4901c2456aa, which should contain the fix), and exported an XCBBUILDSERVICE_PATH variable pointing to the built SWBBuildServiceBundle file.

Unfortunately the crash still reproduces.

info2.txt

repro_and_crash_ips.zip

[jakepetroules]

Thanks for the report. I'm a little unclear on the crash logs though. The crash log you attached here is from xcodebuild:

Thread 3 Crashed:
0   libsystem_kernel.dylib        	    0x7ff80d4dd152 __abort_with_payload + 10
1   libsystem_kernel.dylib        	    0x7ff80d4fce9a abort_with_payload_wrapper_internal + 82
2   libsystem_kernel.dylib        	    0x7ff80d4fce48 abort_with_reason + 19
3   libobjc.A.dylib               	    0x7ff80d0fdc86 _objc_fatalv(unsigned long long, unsigned long long, char const*, __va_list_tag*) + 114
4   libobjc.A.dylib               	    0x7ff80d0fdc14 _objc_fatal(char const*, ...) + 152
5   libobjc.A.dylib               	    0x7ff80d0d4f90 _setThisThreadIsInitializingClass(objc_class*) + 238
6   libobjc.A.dylib               	    0x7ff80d0d4ceb initializeNonMetaClass + 424
7   libobjc.A.dylib               	    0x7ff80d0eaa58 initializeAndMaybeRelock(objc_class*, objc_object*, locker_mixin<lockdebug::lock_mixin<objc_lock_base_t>>&, bool) + 247
8   libobjc.A.dylib               	    0x7ff80d0d45fd lookUpImpOrForward + 227
9   libobjc.A.dylib               	    0x7ff80d0d3d1b _objc_msgSend_uncached + 75
10  libobjc.A.dylib               	    0x7ff80d0d5077 CALLING_SOME_+initialize_METHOD + 17
11  libobjc.A.dylib               	    0x7ff80d0d4d64 initializeNonMetaClass + 545
12  libobjc.A.dylib               	    0x7ff80d0eaa58 initializeAndMaybeRelock(objc_class*, objc_object*, locker_mixin<lockdebug::lock_mixin<objc_lock_base_t>>&, bool) + 247
13  libobjc.A.dylib               	    0x7ff80d0d45fd lookUpImpOrForward + 227
14  libobjc.A.dylib               	    0x7ff80d0d3d1b _objc_msgSend_uncached + 75

...but the issue fixed by #728 would have been a crash in SWBBuildService (the build service runs out-of-process from xcodebuild). Are you still seeing the crash in SWBBuildService, or separate crashes in both SWBBuildService and xcodebuild?

(Note that unlike SWBBuildService, xcodebuild is not Open Source and not part of the Swift project, so a crash in that tool is not something we can debug here on GitHub)

[alcroito]

There were two crashes of SWBBuildService, but the majority are xcodebuild. In the majority of the cases _setThisThreadIsInitializingClass is in the trace though.

Yes, i'm aware that xcodebuild is not open source, but I was asked to file it here as well, in case that helps. The same info was attached to FB19614690.