Odd dyld crash: '/usr/lib/libc++.1.dylib' (no such file, no dyld cache)

That is indeed a weird error. The correct install name for the C++ standard library is indeed /usr/lib/libc++.1.dylib.

What version of Xcode is this?

If you run the following against your app, what does it report?

% otool -L Test764824.app/Test764824.debug.dylib 
Test764824.app/Test764824.debug.dylib:
    …
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1800.101.0)
    …

IMPORTANT This assumes that your app was built with the new preview support enabled. If it wasn’t, the path for otool would be simply Test764824.app/Test764824.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks for the quick reply!

We are using Xcode Version 15.1 (15C65), but we've seen the issue with 15.4 as well. In addition, the crash is occurring on devices with 17.6.1 and 18.0.

The output of otool -L is attached! :D

Thanks for the otool output. I wanted to check that the /usr/lib/libc++.1.dylib path was correct, it is, and that the version numbers are reason, and they are.

Re-reading your first post it seems that these are test devices that you control. Is that right?

If so:

• Does any given device consistently work or fail? Or do you see intermittent failures or a device that generally works?

• Does restarting the device help?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thank you for checking!

We are seeing consistent failure on all devices that our developers are using, and restarting the device does not resolve the issue.

I spent a fair amount of time performing a git bisect to narrow down the issue, but strangely enough, we begin seeing intermittent failures the farther we go back in history making it difficult to track down the exact commit that may have introduced an issue.

For example, starting the app ~40 times results in a handful of failures where as it consistently fails today.

Our RELEASE builds currently work correctly. The issue appears to only occur when installing from Xcode from what we can tell.

Well, that’s weird.

You should definitely file a bug about this. I’m thinking something along the lines of:

1. Roll the source code forward to the latest version, the one that reproduces the problem all the time.

2. Build and run the app from Xcode, reproducing the issue.

3. Trigger a sysdiagnose log on the device.

4. Choose Product > Show Build Folder in Finder, fine your app, and zip it up.

5. Add the sysdiagnose log and your app to the bug report.

Please post your bug number, just for the record.

Oh, one other thing: Once you reproduce this problem with your main app, try create a small test app that uses some C++ (and hence links with the library, per otool) and see if that has the problem. I suspect it won’t, but if it did that’d be most interesting.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Weird and painful indeed!

I have submitted the feedback report (large attachments are being uploaded still). The feedback identifier is: FB15350098.

EDIT: The standalone app with C++ worked as expected, I suspect it has something to do with the corpulent nature of our app.

Thanks for filing FB15350098.

I suspect it has something to do with the corpulent nature of our app.

Right. And I’ve seen similarly weird things in this space, for example, with Mach-O images that important with more than 250-ish libraries. However, you’re not close to that limit.

I’m out of ideas right now, so I’m going to defer to your bug report here.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"