Here is the crash report: nbagentgdb-2023-03-20-062118.ips

I also compiled with address sanitization, and I get ==64348==ERROR: AddressSanitizer: SEGV on unknown address 0x02ae4e000079 (pc 0x7ff803997d22 bp 0x70000aecbfc0 sp 0x70000aecbf40 T626) ==64348==The signal is caused by a READ memory access. #0 0x7ff803997d22 in popen+0x1de (libsystem_c.dylib:x86_64+0x53d22) #1 0x10d5d78f6 in wrap_popen+0x306 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x418f6) #2 0x10cc2cefa in executeDNS executeDNS.c:235 #3 0x10cbc01fd in executeTest utilities.c:910 #4 0x7ff803a79513 in _pthread_start+0x7c (libsystem_pthread.dylib:x86_64+0x6513) #5 0x7ff803a7502e in thread_start+0xe (libsystem_pthread.dylib:x86_64+0x202e) ==64348==Register values: rax = 0x0000000000000000 rbx = 0x000002ae4e000069 rcx = 0x0000625000827900 rdx = 0x0000000000000005 rdi = 0x0000000118e98060 rsi = 0x0000000118e980e0 rbp = 0x000070000aecbfc0 rsp = 0x000070000aecbf40 r8 = 0x0000000000001048 r9 = 0x0000000000000000 r10 = 0x00000fffffffffff r11 = 0x0000000000000000 r12 = 0x000070000aecbf58 r13 = 0x00000000ffffffff r14 = 0x000000010cf11000 r15 = 0x00007ff84528f8f0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (libsystem_c.dylib:x86_64+0x53d22) in popen+0x1de Thread T626 created by T0 here: #0 0x10d5d867c in wrap_pthread_create+0x5c (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x4267c) #1 0x10cba0f33 in main nbagent_main.c:635 #2 0x11239c4fd in start+0x1cd (dyld:x86_64+0x54fd) ==64348==ABORTING I don't know if this adds any more information, other than it crashes at popen(). Can you point me to the best popen() implementation I could use to test what you suggested?

It's failing here SLIST_FOREACH(p, &pidlist, next) (void)posix_spawn_file_actions_addclose(&file_actions, p->fd);

By looking at the implementation it looks like popen() should be thread safe (e.g. __isthreaded), but locking is not applied on all list manipulations. I see that there is protection for SLIST_INSERT_HEAD THREAD_LOCK(); SLIST_INSERT_HEAD(&pidlist, cur, next); THREAD_UNLOCK(); But there is no locking for SLIST_FOREACH (where in my case the crash happened). Shouldn't the list be locked when iterating through it? If during parsing, a new element is inserted, there might be memory corruption.

By the way, here is the popen.c I used https://github.com/apple-oss-distributions/Libc/blob/Libc-1506.40.4/gen/FreeBSD/popen.c

This change does it for me, it looks like: THREAD_LOCK(); SLIST_FOREACH(p, &pidlist, next) (void)posix_spawn_file_actions_addclose(&file_actions, p->fd); THREAD_UNLOCK();

I submitted the bug and I believe the bug number is FB12144217 Also submitted a PR with the fix https://github.com/apple-oss-distributions/Libc/pull/2

How about a file in "myapp.app/Contents/Resources/" that needs to be modified during runtime? I noticed that when that for a notarized app, once a file in "Resources" is modified, the notarization breaks? Is it possible to save and modify runtime custom files in "Resources" without breaking the notarization or is it the case the "Resources" is not the right place for those kind of files?