Fixing “virtual filesystem overlay file all-product-headers.yaml not found” error

In the last few days, I have seen an increasing number of developers facing a common problem while trying to use LLDB during a debugging session.

error: virtual filesystem overlay file '/Users/salla/Library/Developer/Xcode/DerivedData/XPTO-eevwsdjquyrbxhbnnxoqlnmyvpax/Build/Intermediates.noindex/ArchiveIntermediates/XPTO/IntermediateBuildFilesPath/XPTO.build/Release-iphonesimulator/XYPTO.build/all-product-headers.yaml' not found

error: couldn't IRGen expression. Please check the above error messages for possible root causes.

This error can be really annoying because it blocks the developer from using LLDB resources, such as po, to verify values or conditions during runtime.

The root cause

There is a known problem in the Swift community regarding how the compiler generates some artifacts used by LLDB to process the symbols during the debug session.

The generated DWARFs contain stored data in absolute paths, which means this data is bound to fixed paths on the machine that generated it.

When a developer tries to import these DWARFs, the absolute path, usually originating from the $HOME folder of the generating user, doesn’t exist on their machine, and LLDB emits an error indicating it couldn’t find the specified path in the DWARF.

Since this is a compilation problem, there is no easy way to fix it.

The situation gets worse because the symbolication tool searches everywhere on your machine for these DSYMs using Spotlight, an Apple tool that indexes all files to provide a faster and more accurate search.

The only solution is to remove the troublemakers from your machine: the DSYMs.

How to fix it

First, we need to identify which DSYM is causing the problem.

To do this, let’s get the image UUIDs that have been loaded during app execution.

Run the app, then place a breakpoint anywhere in your code. When the execution stops, run the following command in LLDB:

image list

LLDB will return a list containing all the loaded images with their UUIDs, as shown in the next image:

#blindPeople: the image shows the image list command after its execution, followed by a list of all the loaded images in the app.

Get the UUID of the image that is causing the error. For example, in the error below, we can see the framework that is causing the error is XYPTO:

error: virtual filesystem overlay file '/Users/salla/Library/Developer/Xcode/DerivedData/XPTO-eevwsdjquyrbxhbnnxoqlnmyvpax/Build/Intermediates.noindex/ArchiveIntermediates/XPTO/IntermediateBuildFilesPath/XPTO.build/Release-iphonesimulator/XYPTO.build/all-product-headers.yaml' not found

Looking for the framework in the image list, we find the following UUID:

blindPeople: the image shows a marked UUID, followed by its description, indicating that this UUID belongs to the framework called XYPTO.

Next, let’s run the command that will search for the broken DSYM and delete it:

mdfind -0 "com_apple_xcode_dsym_uuids == IMAGE-UUID-HERE" | xargs -0 rm -rf --

In our example, we will run the command as:

mdfind -0 "com_apple_xcode_dsym_uuids == 664A127D-C264-3415-8515-E0DB99B606C8" | xargs -0 rm -rf --

Next, let’s erase the DerivedData folder. It’s important to erase all the data contained in that folder because we may find some leftover references to the DSYM from previous compilations.

If your DerivedData folder is set as default, run the following command. Otherwise, locate the folder and erase it manually.

rm -rf $HOME/Library/Developer/Xcode/DerivedData

Finally, build and run your application again, and the LLDB commands like po will be available and working again.