Crash when running on very large projects due to too many file descriptors

[amorde]

Describe the bug
When run on a very large project (we have a monorepo with multiple apps and shared frameworks), the number of open files can reach a system limit causing a crash like below:

libc++abi: *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Failed to set posix_spawn_file_actions for fd 0 at index 0 with errno 9'
*** First throw call stack:
(
	0   CoreFoundation                      0x0000000183ff3ae0 __exceptionPreprocess + 176
	1   libobjc.A.dylib                     0x0000000183ab6b90 objc_exception_throw + 88
	2   Foundation                          0x00000001855bd798 -[NSConcreteTask launchWithDictionary:error:] + 4236
	3   periphery                           0x0000000104a6ab60 $sSo6NSTaskC15SwiftIndexStoreE4exec3bin9arguments3cwdSS6stdout_SS6stderrtSS_SaySSGSSSgtKFZ + 716
	4   periphery                           0x0000000104a68de4 $s15SwiftIndexStore03LibbC0C17macOSDeveloperDir018_014A4788F378C2FF0J13F548CA77A7DD9LL10Foundation3URLVyKFZ + 220
	5   periphery                           0x0000000104a68ac4 $s15SwiftIndexStore03LibbC0C4openACyKFZ + 388
	6   periphery                           0x00000001049dc89c $s7Indexer19SourceFileCollectorV7collectSDy0B5Graph0bC0CSayAA9IndexUnitVGGyKFSay13SystemPackage0C4PathV_05SwiftG5Store0gM0CAO0gmH0VSSSgtGANKcfU_ + 888
	7   periphery                           0x00000001049dcd40 $s7Indexer19SourceFileCollectorV7collectSDy0B5Graph0bC0CSayAA9IndexUnitVGGyKFSay13SystemPackage0C4PathV_05SwiftG5Store0gM0CAO0gmH0VSSSgtGANKcfU_TA + 32
	8   periphery                           0x00000001049dbac8 $s7Indexer7JobPoolV7flatMapySayqd__GAExKcKlFySiYbXEfU_ + 360
	9   periphery                           0x00000001049dbd18 $s7Indexer7JobPoolV7flatMapySayqd__GAExKcKlFySiYbXEfU_TA + 64
	10  libswiftDispatch.dylib              0x000000019b5e91c4 $sSiIgy_SiIegy_TRTA + 28
	11  libswiftDispatch.dylib              0x000000019b5e91f0 $sSiIegy_SiIyBy_TR + 32
	12  libdispatch.dylib                   0x0000000183cf9874 _dispatch_client_callout2 + 16
	13  libdispatch.dylib                   0x0000000183cf4610 _dispatch_apply_invoke3 + 336
	14  libdispatch.dylib                   0x0000000183cf985c _dispatch_client_callout + 16
	15  libdispatch.dylib                   0x0000000183ce2a28 _dispatch_once_callout + 32
	16  libdispatch.dylib                   0x0000000183cf3750 _dispatch_apply_invoke + 252
	17  libdispatch.dylib                   0x0000000183cf985c _dispatch_client_callout + 16
	18  libdispatch.dylib                   0x0000000183d16490 _dispatch_channel_invoke.cold.5 + 32
	19  libdispatch.dylib                   0x0000000183cf1fa4 _dispatch_root_queue_drain + 736
	20  libdispatch.dylib                   0x0000000183cf25d4 _dispatch_worker_thread2 + 156
	21  libsystem_pthread.dylib             0x0000000183e93de4 _pthread_wqthread + 232
	22  libsystem_pthread.dylib             0x0000000183e92b74 start_wqthread + 8

In our Bazel project the generated project_config.json ends up having over 7000 entries in the indexstores field. Since each indexstore has multiple files inside of it, and since the implementation keeps all indexstores open at the same time, this ends up hitting a limit and crashing. On my system (macOS Sequoia 15.7.1 MBP M3 Max) when it crashes it has 10,290 open file descriptors.

I attempted to work around this using various commands found online such as:

• ulimit -n NEW_LIMIT
• sudo sysctl -w kern.maxfilesperproc=NEW_LIMIT
• launchctl limit maxfiles NEW_LIMIT

But even with all of the above it still crashes.

Reproduction
Unfortunately this is difficult to repro unless you have a massive project like the one I'm working in, so I don't have an easy way to provide a reproduction sample. But I can repro the crash 100% of the time on the project I'm using.

Environment
periphery 3.1.0

[amorde]

Currently I am working around this by manually editing the generated project_config.json after running bazel run @periphery -- scan --bazel and replacing the large list of indexstores with bazel-out/_global_index_store, as we are using the swift.use_global_index_store feature of rules_swift.

I was thinking this might be something worth supporting officially in some way.