Logic Pro X Audio Unit Reported a Problem

[oscwilde]

So does everyone exeriencing problems have an Apple Silicon machine?
If yes, can you run Logic in Rosetta mode for a couple of days and report back?

Just observing the "trend" of various symptoms/comments - this "appears" to be an AUHost process / memory leak thing that is not necessarily a partic. Logic version or partic. plug-in (or OS?) version-specific.....but DOES appear to be limited to AS native use.
So - slum it with Rosetta for a couple of days and we'll see where things land.

[scg]

16 hours ago, antonynbutcher said:

I've just checked and with MIDI 2.0 off, I unfortunately still get the same issue🙄

Same here. MIDI 2.0 on/off doesn't seem to have any effect for me.

13 hours ago, oscwilde said:

So does everyone exeriencing problems have an Apple Silicon machine?
If yes, can you run Logic in Rosetta mode for a couple of days and report back?

Yes, Silicon. It didn't happen with Intel+Ventura, but began happening with Silicon+Ventura. As noted, it can take an arbitrary number of hours to manifest, but I've never observed it when running in Rosetta (and I've let it run in Rosetta for quite a while).

[mmm42]

On Apple Silicon all Audio Units are loaded and managed directly by macOS and not by Logic Pro anymore. This improves security and stability of the system as a whole, as it avoids crashes of Logic Pro in case a single Audio Unit goes down.

Sadly there is currently a limitation in macOS: all Audio Units are loaded together into one block of memory and if one goes down, the host application (in this case Logic Pro) does not get informed _which_ Audio Unit crashed.

I am not aware that this mechanism has any relevant known bugs, but I know of Audio Units having problems running isolated. Another problem for them might be the following: because Audio Unit are loaded directly by macOS, they _have_ to be compatible to the version of macOS that is currently running. I have seen problems in this area.

[Owl Man]

I'm on a Mac M1 with the same issue on isolated songs. Running macOS 13.4 and Logic Pro X 10.7.8. I recently installed Native Instruments for my NI Komplete Kontrol MK S61 controller. That's had issues on its own so it's hard to know.

[mmm42]

Yes, with some users having hundreds of Audio Units in use at the same time _plus_ Logic Pro _plus_ macOS there is a lot of things that can go wrong. How can anybody guarantee that all these components play along nicely? I often see crashes of old Audio Units, which haven't updated in many years and either have unfixed bugs or are simply incompatible with recent versions of macOS.

For that reason does Logic Pro always run Audio Units out-of-process on Apple Silicon. It creates some new issues (which are fixable with updated Audio Units and all known issues have been documented to developers with tips on how to fix them), but it solved the issue that a single Audio Unit can crash Logic Pro. In the past 18 out of the top-20 crashes of Logic Pro were triggered directly by Audio Units. Now the number is _zero_ and Logic Pro can at least warn that an Audio Unit crashed. Still not perfect, but better.

[oscwilde]

On 5/30/2023 at 4:49 PM, mmm42 said:

On Apple Silicon all Audio Units are loaded and managed directly by macOS and not by Logic Pro anymore.

AUv3 plugs "can" run out of process if programmed to do so.
Not earlier AU version plugs, AFAIK.
 

[mmm42]

_All_ Audio Units (AUv2 and AUv3) are loaded out of process on all Apple Silicon hardware. AUv3 can do that on Intel as well.

[Cesar DM]

I tried a solution by @fisherking as stated in here

https://www.logicprohelp.com/forums/topic/147239-an-audio-unit-plug-in-reported-a-problem-which-might-cause-the-system-to-become-unstable/

Quote

alternately, quit logic. try deleting that plugin AU. then move the audio cache file (User>Home>Library>Caches>AudioUnitCache>com.apple.audiounits.cache)
to the desktop. then reinstall the problematic AU.

Tried this on friday, and Logic never showed the error until today at around 1pm CST. So it kinda solved it, but temporarily 

[mothershout]

I'm updating this because it's the most recent thread on the subject.

I recently had a rash of these happen as I started mixing a project. I could have tried a process of elimination, but I was a software engineer until I retired a couple of years ago, and I still know my way around a crash log. So here's how I isolated the offending plugins. This is offered in the hope that it'll be useful to anyone searching for a solution:

1. When the issue occurred, I quit Logic.
2. I started the mac Console app (built into MacOS), and in the left sidebar clicked on Crash Reports.
3. I found the most recent report from the AUHostingServiceXPC_arrow (look for anything beginning AUHostingService) - the time and date should correspond to when the issue occurred.
4. Double-click the crash report to open it in a new window.
5. Search (Command-F) for the word crashed. The first hit will generally be around halfway down the first page, often in a line that says something like Crashed Thread:        46  JUCE Timer (the 46 and JUCE Timer may well be different).
6. Move to the next result for the word crashed (Command-G, or click the arrow to the right of the search box).

Now you should see something roughly like this:

Thread 46 Crashed:: JUCE Timer
0   libsystem_pthread.dylib       	       0x18762a558 pthread_mutex_lock + 12
1   fast-compressor               	       0x3929106d8 0x392358000 + 5998296
2   fast-compressor               	       0x392912fe4 0x392358000 + 6008804
3   fast-compressor               	       0x3927c9230 0x392358000 + 4657712
4   libsystem_pthread.dylib       	       0x18762ffa8 _pthread_start + 148
5   libsystem_pthread.dylib       	       0x18762ada0 thread_start + 8

(Again, the 46 and the JUCE Timer may well be different in your log files).

This is a stack trace, giving you much more information than you need. What you're looking for is anything that identifies the plugin. In this case, it looks like it's happening inside the FASTCompressor plugin (from Focusrite/The Collective), which I use often as a quick way to set up compression.

I checked the last few crash reports and saw that most came from FASTCompressor, and two from Letimix's GainMatch.

In both cases, I found that there were updated versions of the plugins, which I've now installed, and I can now watch for the problem happening again. If it continues to happen, I'll check the logs again, and disable whichever plugin is causing the issue.

I've done this several times now, and noted that there are lot of plugins that crash in the JUCE framework's timer thread. It's not always easy to tell which plugins use are built with JUCE, but I'd suggest updating any that you know of, since it looks like there has been an issue with some version of JUCE.

 

 

[des99]

Yep - on Intel, we could look at the Logic crash reports for the crashed thread and any identified plugins. Under Apple silicon (natively), the plugins no longer run in Logic and don't crash it, so we need to look in the AUHostingService (the macOS service that now runs the plugins) crashlogs to identify third-party plugin crashes.

If it's a general JUCE thing, a framework a lot of plugins use, it will likely be fixed and plugin developers will update to newer framework versions and update their plugins over time. I know the Apple devs are active on the JUCE forums and have talked about this issue, and that they are advising and working with third-party plugin developers to make their plugins behave better when running isolated from the host, so hopefully things should improve/stabilise in this regard over time.

[kotrl]

That is very helpful. The plug-ins I found to be causing the issue are in my template, but disabled in most projects. RAUM came up several times, although not in reference to JUCE Timer

[FLH3]

Thank you very much for this information and method, Dess99

[JoshJ]

@mothershout this was super helpful, and relatively straight forward. thanks. 

[fisch723]

Interesting to see so many plugins as possible culprits. I'm seeing this behavior with Dune 3, or at least that's where I'm at at this point. I ran Logic with no plugins and there were no errors, then with other plugins, no errors. But when I run Dune 3, eventually I get the error.

And as others have noted, usually after Logic has been sitting idle for a while. In my tests, I left it idle each time for about an hour, but I see on this thread people have experienced it after longer time periods.

I went to the Synapse Audio website and it says the current version (3.550) is M1 compatible. I'm running an M2 Pro on Ventura.

[88keys]

I too have had similar problems with threads running JUCE Timer ( C++ JUCE Framework). That was a problem for me with Modartt Pianoteq for a long time and that dev confirmed that they build with JUCE. 

But lately (since 10.7.8 I recall) this has been happening even after I close a project and leave Logic running; and I can't identify a plugin/culprit specifically, although the full crash log certainly contains a data snapshot showing plugins that were loaded with the last opened project. I don't always have a crash log. But here is a recent one (just the crashed thread): 

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000

Termination Reason:    Namespace SIGNAL, Code 6 Abort trap: 6
Terminating Process:   AUHostingService [15457]

Application Specific Information:
abort() called


Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib                   0x185cad11c __pthread_kill + 8
1   libsystem_pthread.dylib                  0x185ce4cc0 pthread_kill + 288
2   libsystem_c.dylib                        0x185bf4a40 abort + 180
3   libc++abi.dylib                          0x185c9c6d8 abort_message + 132
4   libc++abi.dylib                          0x185c8c6a0 demangling_terminate_handler() + 52
5   libc++abi.dylib                          0x185c9ba9c std::__terminate(void (*)()) + 16
6   libc++abi.dylib                          0x185c9ba2c std::terminate() + 36
7   libsystem_c.dylib                        0x185ba4f98 __cxa_finalize_ranges + 476
8   libsystem_c.dylib                        0x185ba4d20 exit + 44
9   AudioToolboxCore                         0x188023818 std::__1::__function::__func<AUHostingService_exit_handler()::$_2, std::__1::allocator<AUHostingService_exit_handler()::$_2>, void ()>::operator()() + 20
10  AudioToolboxCore                         0x188023684 __30-[AUHostingService closeHost:]_block_invoke + 652
11  libdispatch.dylib                        0x185b35cb8 _dispatch_call_block_and_release + 32
12  libdispatch.dylib                        0x185b37910 _dispatch_client_callout + 20
13  libdispatch.dylib                        0x185b45fa8 _dispatch_main_queue_drain + 984
14  libdispatch.dylib                        0x185b45bc0 _dispatch_main_queue_callback_4CF + 44
15  CoreFoundation                           0x185e0315c __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
16  CoreFoundation                           0x185dc0a80 __CFRunLoopRun + 1996
17  CoreFoundation                           0x185dbfc5c CFRunLoopRunSpecific + 608
18  HIToolbox                                0x190339448 RunCurrentEventLoopInMode + 292
19  HIToolbox                                0x190339284 ReceiveNextEventCommon + 648
20  HIToolbox                                0x190338fdc _BlockUntilNextEventMatchingListInModeWithFilter + 76
21  AppKit                                   0x18959ac54 _DPSNextEvent + 660
22  AppKit                                   0x189d70ebc -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 716
23  ViewBridge                               0x18e3e0b50 __77-[NSViewServiceApplication vbNextEventMatchingMask:untilDate:inMode:dequeue:]_block_invoke + 136
24  ViewBridge                               0x18e3e08b0 -[NSViewServiceApplication _withToxicEventMonitorPerform:] + 152
25  ViewBridge                               0x18e3e0ab0 -[NSViewServiceApplication vbNextEventMatchingMask:untilDate:inMode:dequeue:] + 168
26  ViewBridge                               0x18e3cce74 -[NSViewServiceApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 100
27  AppKit                                   0x18958e100 -[NSApplication run] + 476
28  AppKit                                   0x1895653cc NSApplicationMain + 880
29  libxpc.dylib                             0x185a15cd4 _xpc_objc_main + 800
30  libxpc.dylib                             0x185a24904 _xpc_main + 324
31  libxpc.dylib                             0x185a1580c xpc_main + 64
32  ViewBridge                               0x18e3c7cc8 -[NSXPCSharedListener resume] + 32
33  ViewBridge                               0x18e3e3180 NSViewServiceMain + 360
34  AUHostingServiceXPC_arrow                0x100e923b8 0x100e8c000 + 25528
35  dyld                                     0x1859690e0 start + 2360

 

 

 

 

[des99]

Is this the crash log of Logic, or of AUHostingService?

(AUHostingServiceXPC_arrow is the full name)

I assume the latter, but there is not enough info in there to identify anything specific, as you've likely already seen...

Edited November 8, 2023 by des99

[88keys]

It is the indeed the AUHostingServiceXPC_arrow process. 

[Cory Rist]

I am also having this exact problem. Most of my 3rd party plugins have 'crashed' in the past couple of weeks according to my crash logs (thanks for explanation on how to read them in this thread everyone). Everything on my system is up to date, opening a new project and putting 1 random 3rd party plugin on a track and leaving it eventually runs into the issue. No issues with Native Logic plugins, no issues in Rosetta.

Are we any closer to a workable fix? (other than Rosetta, I have an M1 Mac for a reason)

Edited November 12, 2023 by Cory Rist

[oscwilde]

On 11/12/2023 at 2:33 PM, Cory Rist said:

Are we any closer to a workable fix? (other than Rosetta, I have an M1 Mac for a reason)

Sonoma?

[88keys]

It's no different for me in Sonoma. Fortunately, the ability to "recover" means that it's just a minor hiccup. And like I mentioned, it's not terribly frequent when I'm actually working on a session. It's more likely to occur when I leave Logic just sitting idle - I think simply because of the length of time involved. 

[Cory Rist]

3 hours ago, oscwilde said:

Sonoma?

Yep, still having the issue, its not happening frequently, just at random times, the last took 2 days to hit, it just means re-loading all plugins and often happens again quite soon after a crash.

[Cesar DM]

Just in case someone still has a problem with this, I found the solution.

You need to know which plugins are giving the error.

For that you will use an app from the AppStore called PluginInfo by thinkersnacks. Sort them by type (AudioUnit) and see which ones are optimized for M1 (Should say something like "Apple, Intel 64"), and uninstall the ones who are not Apple Optimized (Probably only say "Intel 64")
 
To uninstall them you can do it manually or use this tool called "Audio Plugin Uninstaller" by Wide Blue Sound (Currently free).

Once you uninstall the problematic plugin, Logic should not crash with the Audio Unit Reported a Problem error.

[des99]

Just now, Cesar DM said:

You need to know which plugins are giving the error.

Exactly.

Just now, Cesar DM said:

For that you will use an app from the AppStore called PluginInfo by thinkersnacks.

Pluginfo is a great tool yes, and recommended.

1 minute ago, Cesar DM said:

uninstall the ones who are not Apple Optimized (Probably only say "Intel 64")
 
Once you uninstall the problematic plugin, Logic should not crash with the Audio Unit Reported a Problem error.

Note that just because a plugin doesn't have an ARM binary doesn't mean it's automatically giving problems. I still have a few Intel-only plugins, and they all work just fine in the current version of Logic - in fact, Logic is architected specifically to allow you to mix both ARM-native, and Intel-only plugins on an ARM Mac running Logic natively.

The solution is to identify the plugin causing the problem, and uninstall/reinstall/fix it, and this is true whether the plugin is ARM native or not. *Any* plugin can misbehave, have bugs or get into a crashing state, and this is unrelated to whether the plugin is ARM-native or Intel-only - although of course, the older and more unsupported the plugin is, the higher the likelihood it might not be behaving well on modern systems.