No longer DBG printing in XCode 13.1 after migration to M1 with macOS 12.1

I migrated to a new Machine and now I see no longer debug output in the console of XCode 13.1. On my old machine it worked perfect (e.g. in Logic and LIVE), I am building plug-ins (VST3, AudioUnit an VST).

My old machine is a MacBook Pro with Intel Core i9 and macOS 11.6 and my new machine is a MacBook Pro with Apple M1 Pro and macOS 12.1.

Has someone a similar issue and maybe solved it?

You’re not alone. I’m also having multiple issues ever since migrating to M1: plugin not showing in hosts, Thread Sanitizer is failing , running auvaltool doesn’t work , attaching to debuggers not working or not printing DBG… Sometime I can fix an issue by switching to/from Rosetta but it will break something else and I can’t get a one-stop-shop that would make everything work like in the old machine.

However, building a project in 4 seconds after cleaning the build folder is not something I am ready to give up just yet… M1 is by far the fastest kid alive.

I can write here my testing results regarding different builds and targets - what’s working and what’s not. But I’m just trying different settings combinations with hopes to be done with it as fast as possible and go back to normal work.

It would be great if someone with actual knowledge would explain what’s so different about M1 architecture and what an audio developer need to know before/after migrating.

Not a one stop shop, but I’ve been on the M1 for a few months as one of my main dev machines, and here’s what I know:

  1. I’m building with CMake and mostly not using XCode, not sure if that matters.
  2. Hosts: Reaper-ARM, JUCE AudioPluginHost (that I built myself from source), and the new Ableton Live beta (with native M1 support) are the nicest to debug for me, along with standalone.

M1 Ableton Live requires a universal build to load the native M1 plugin for some reason (which I think is a bug on their end).

Logic is a pain and DBG isn’t working unless in Rosetta last time I checked. I’m trying to reduce the times I’m debugging on that host because of it.

  1. I think you need to disable SIP to debug in some hosts.

Thanks Eyal. This is good to know stuff.

From a commercial point of view, aren’t you worried about not debugging in Logic, considering it is so popular and known to have its own issues? I would gladly drop Logic from my list but I’m afraid to do so for this reason.

Of course, this is not ideal, but I still debug the plugins in Logic, I just do it using Rosetta, and then I test them later using Logic native.

It’s very, very rare that I’ll have bugs that only appear in Logic native, and don’t show up in either Logic/Rosetta, or other native hosts like Reaper, so usually I have some of way of debugging the issue after I observe it.

Well, I’m in a slightly different position:
If I build for native M1 and open native Logic - plugin will not show up. It will also fail to open in auvaltool.
If I build for Rosetta and open Logic/Rosetta - plugin is loaded correctly.
If I debug in Logic/Rosetta - breakpoints are auto disabled and no DBG printing occurs.

I disabled SIP but that didn’t seem to work. Also tried all the clean-cache/delete-folders/restart solutions known to mankind.

Any more of those tips are welcome.

There are perhaps a few different issues you’re experiencing here.

Plugin not showing up indicates you might have a configuration problem, which is probably the most serious problem you face.

What happens if you try another plugin, not by you?
For example, try cloning this:

and then run the following command:
cmake -G Xcode -B build
Then try going the build folder and build one of the demos using Xcode, like NewPluginTemplate. It should appear in (native) Logic and pass AU validation without any configuration issues. If it does and your own plugin doesn’t, maybe we need to look more closely at how you set it up.

Not getting breakpoints - Logic loads the AU plugins in a separate process, so when I do debug->attach to process
And then choose AUHostingServiceXPC_arrow, that allows to attach breakpoints (but not see DBG…).

Awesome! Thanks. Will try and report.

Your last statement, however, is directly related to the author’s main issue. Hopefully someone can come with a workaround.

Have you or @bebu tried the bit about attaching to the other AU hosting process (and not the Logic process) with no success?

Yep. I summed up all my failures here:

This DBG not showing up isn’t just a M1/Monterey problem, it seems using the “attach to” feature of XCode doesn’t pipe the output, as I can’t see DBG when debugging Bitwig on a 2019 Intel Mac Pro running Big Sur. Can hit breakpoints no problem after attaching to the plugin process, but sometimes DBG output is more helpful.

1 Like

Thanks for all your replies!

Here’s what I have tried so far:

Using Ableton Live 11.1 Beta I do see DBG output now (and that’s great!)
I just tried the official Live 11 version before and with it I do not see DBG.

Regarding Logic I tried:

  1. start Logic in Rosetta Mode => no DBG output

  2. disable System Integrity Protection as described in this link. Then attach to AUHostingServiceXPC or AUHostingServiceXPC_arrow => no DBG output

Ah, that’s great insight!
I get the same issue in CLion, so it might not even be Xcode that’s causing the problem, sounds more like a Mac thing.

As a temporary hack, you can use a file logger, something like:

//Needed to prevent a memory leak and and/or assert on quit.
struct MyFileLogger: juce::FileLogger, juce::DeletedAtShutdown
{
    using juce::FileLogger::FileLogger;
};

inline juce::File getLogFile()
{
    auto desktop =
        juce::File::getSpecialLocation(juce::File::userDesktopDirectory);
    return desktop.getChildFile("Log.txt");
}

inline juce::FileLogger& getFileLogger()
{
    static juce::FileLogger* logger;

    if (logger == nullptr)
        logger = new MyFileLogger(getLogFile(), "Starting Log");

    return *logger;
}

#undef DBG
#define DBG(text)                                                                   \
    JUCE_BLOCK_WITH_FORCED_SEMICOLON(juce::String tempDbgBuf; tempDbgBuf << (text); \
                                     getFileLogger().logMessage(tempDbgBuf);)

And then regular DBG message would go to that file.

While I’m here, @reuk and co: I think it would be great if DBG could be customized so a user could define a custom logger for it as well at runtime. What do you think about it?

3 Likes

You have the gold touch my friend! I don’t know if its something you put in your scripts or just a coincidence, but I built your project, did another clean-all-folders-and-cache session and I got back my plugin on native M1 (and also your plugin showed up). Then I attached to AUHostingServiceXPC_arrow and got my breakpoints in debug mode. Still no DBG prints though, but this is a great improvment.

1 Like