[GUIDE] Symbolicating Release Builds

Development
1

Since this is a very common question I’ve made a sample project to help getting started with symbol-less Release builds (while still keeping symbols to allow symbolicating user’s crashes later).

Hope it’ll be helpful. The README.md contains pretty much everything needed to get you up and running for macOS and Windows.

So here is the repo on github:

16 Likes
2

We use SYMSTORE on windows for our apps to save the symbols. I think it’d work fine with plugins too. Debugging with a minidump file is then super-easy (just install same version as crash and double click the DMP file):

5 Likes
3

Hi Ttg,

Is it possible, things have changed in XCode 11.5 running on OSX 10.15.5?

But firstly, let me thank you for your post.
I am having the exact same problem, as you describe. I want a plugin without exposing my symbols. And I still want to retain the dSym file, in order to symbolicate a crash.

I built your plugin using your build_macos.sh script. Building works fine. But the result is not as expected. The crash log does unfortunately still contain the symbols of the application.

Maybe things have changed in XCode 11.5 running on OSX 10.15.5 (Catalina)?
Maybe I need to add additional flags to Xcodebuild?

Here is what my crash log looks like, when running the stand-alone version of your project:
I am only showing the thread, which crashed:

#####################
Thread 4 Crashed:: MacBook Pro Speakers
0 com.yourcompany.SymbolFriendlyPlugIn 0x000000010f05ffe9 SymbolFriendlyPlugInAudioProcessor::processBlock(juce::AudioBuffer&, juce::MidiBuffer&) + 169 (PluginProcessor.cpp:135)
1 com.yourcompany.SymbolFriendlyPlugIn 0x000000010f08c58f juce::AudioProcessorPlayer::audioDeviceIOCallback(float const**, int, float**, int, int) + 1711 (juce_AudioProcessorPlayer.cpp:175)
2 com.yourcompany.SymbolFriendlyPlugIn 0x000000010f070305 juce::AudioDeviceManager::CallbackHandler::audioDeviceIOCallback(float const**, int, float**, int, int) + 853 (juce_AudioDeviceManager.cpp:54)
3 com.yourcompany.SymbolFriendlyPlugIn 0x000000010f069c30 juce::CoreAudioClasses::AudioIODeviceCombiner::run() + 2112 (juce_mac_CoreAudio.cpp:1614)
4 com.yourcompany.SymbolFriendlyPlugIn 0x000000010f0a8e8f juce::threadEntryProc(void*) + 527 (juce_posix_SharedCode.h:834)
5 libsystem_pthread.dylib 0x00007fff69bdc109 _pthread_start + 148
6 libsystem_pthread.dylib 0x00007fff69bd7b8b thread_start + 15
#####################

As you can see in this excerpt, there are still a lot of symbols listed. Any ideas how to get rid of them, while still keeping the dSYM file?

Full crash log is attached:
SymbolFriendlyPlugIn_2020-06-27-211115_Martins-MacBook-Pro.crash (74.8 KB)

4

Any updates on this for Mac with Xcode 12?

2 Likes
5

Thanks. I’ll update the example code.
My workplace is also expected to get some Apple Silicon machines so we’ll be able to do extra testing for it.

3 Likes
6

Does anyone know the process for doing this on Linux?

7

Anyone else seeing hundreds of warnings with Xcode 12.4 now saying:

"warning: could not find referenced DIE"

while Xcode is generating the dsym file?

In my (standalone app) project, I have the following “Custom Xcode Flags” in the Projucer:

LD_RUNPATH_SEARCH_PATHS="@loader_path/../Frameworks"
CONFIGURATION_BUILD_DIR="$(SRCROOT)/$(CONFIGURATION)"
DEBUG_INFORMATION_FORMAT=dwarf-with-dsym
GCC_GENERATE_DEBUGGING_SYMBOLS=YES
DEPLOYMENT_POSTPROCESSING=YES

I had macOS architecture set to “Standard 64-bit” and left the “Valid architectures” of the exporter to the defaults (all checked), so it was building both the x86_64 and the arm64 architectures, so I thought maybe that was the cause (used to build only x86_64), but also if I explicitly set only x86_64, I get the same warnings…

It only happens in a release build, not in a debug build…
I do have “Debug Mode” set to Disabled in the Projucer for the release build (it’s Enabled for debug build), but the flags are there for both builds.

I’ll keep trying things, but if anyone had this too?

1 Like
8

Yes, also getting those “warning: could not find referenced DIE” warnings.
Unfortunately I have not yet found out, what causes them.

1 Like
9

I just tried to (and could indeed) reproduce this with one of the standard JUCE example projects (AudioAppDemo):

  • opened the example project in the Projucer
  • for the Xcode exporters (Debug and Release), added this to the “Custom Xcode flags”:
    DEBUG_INFORMATION_FORMAT=dwarf-with-dsym, GCC_GENERATE_DEBUGGING_SYMBOLS=YES, DEPLOYMENT_POSTPROCESSING=YES
  • saved the project, opened it in Xcode and made sure that “Build Active Architecture Only” is also set to “No” for the Debug configuration
  • built the 2 configurations in Xcode (just “Product → Build” for the Debug build, and “Product → Build for → Profiling” for the Release build)

Result:

  • Debug builds fine without warnings
  • Release builds fine too, but has 1567 warnings saying:
    could not find referenced DIE
    (in the step: Generate AudioAppDemo.app.dSYM)

I then also tried only building the x86_64 architecture, thinking it might have something to do with the new additional ARM configuration, by doing this in the Projucer:

  • set “Valid Architectures” to only “x86_64” in the main Xcode exporter item
  • set “macOS Architecture” to “Standard 64-bit” (for both the Debug and Release configurations)

Result:

Exactly the same: no warnings for Debug, lots of warnings for Release.

This was done with Xcode 12.4 and JUCE 6.0.8 (master branch on 6 April 2021, 90e8da0cfb54ac593cdbed74c3d0c9b09bad3a9f).

I’ll see if it’s still the same on the very latest / current master branch.
Edit: yes, exactly the same with the latest / current master branch (after rebuilding the Projucer and re-saving the example project of course).

At this point, I think I’ll just have to ignore this, unless @ed95, @t0m or someone else has any ideas?

2 Likes
10

We’re seeing the same issues and would be happy to find a solution for these.

I just wanted to mention that it’s not strictly necessary to use Xcode for symbolication, as the Xcode flags just configure post-build steps.
The following non-xcode specific steps are necessary for achieving the same result:

  • Add the clang -g compiler flag to force generation of debug symbols, e.g.

    target_compile_options(plugin PUBLIC -g)

  • Add a post-build step to generate a .dsym: dsymutil plugin.vst3/Contents/MacOS/plugin -o plugin.vst3.dSYM, e.g.

    add_custom_command(TARGET plugin_VST3 POST_BUILD 
                   WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/plugin_artefacts/Release/VST3
                   COMMAND dsymutil plugin.vst3/Contents/MacOS/plugin -o plugin.vst3.dSYM)

  • Add a post-build step to strip the symbols using strip -x plugin.vst3/Contents/MacOS/plugin, e.g.

    add_custom_command(TARGET plugin_VST3 POST_BUILD 
                   WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/plugin_artefacts/Release/VST3
                   COMMAND strip -x plugin.vst3/Contents/MacOS/plugin)
5 Likes
11

btw, sadly due to other tasks I’m not getting this project update.

but if anyone ever updates the repo above, feel free to PR.
I do hope to update it and also add CMakeFiles, Linux (Ubuntu) and other steps currently not up-to-date.

12

Does anyone know what DIE stands for in could not find referenced DIE?

Having trouble searching for this warning / guessing exactly what is failing.

13

It’s a “Debug Info Entry”. I think it suggests that the linker is not finding some debug information that it expected to find.

1 Like
14

Thanks!