UAD Console Recall Plugin crashes Gig Performer 4

Sorry, I want to upload the crash logs, but I am not able to upload anything via the upload symbol here.

UAD native, GP native.

Can you ZIP it?

crash1 Kopie.zip (32.0 KB)
crash2 Kopie.zip (24.8 KB)

Thank you. Here we go. I could ZIP it.

1 Like

Why 2 different crash logs?

And did you make this manual steps mentioned?

This crash is happening in the UA plugin - it’s not a Gig Performer problem. Feel free to reach out to them and pass the info below to them. They’ll probably tell you they don’t support GP but it is a bug in their plugin as easily shown by the crash report below


Process:               AUHostingServiceXPC [7628]
Path:                  /System/Library/Frameworks/AudioToolbox.framework/XPCServices/AUHostingServiceXPC.xpc/Contents/MacOS/AUHostingServiceXPC
Identifier:            com.apple.audio.AUHostingService.x86-64
Version:               1.0 (1)
Build Info:            CoreAudioServices_AUHostingServiceXPC-1181072004000000~2
Code Type:             X86-64 (Translated)
Parent Process:        ??? [1]
Responsible:           GigPerformer4 [7614]
User ID:               501

Date/Time:             2022-05-07 13:16:16.826 +0200
OS Version:            macOS 11.6.5 (20G527)
Report Version:        12
Anonymous UUID:        48440E7C-03F7-FB3D-E5E7-1AE10DBE7DF1


Time Awake Since Boot: 10000 seconds

System Integrity Protection: enabled

Crashed Thread:        5  UALogWriter

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

Application Specific Information:
abort() called
terminating with uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument

.......

Thread 5 Crashed:: UALogWriter
0   ???                           	0x00007ffe9475e8f4 ???
1   libsystem_kernel.dylib        	0x00007fff2034f91e __pthread_kill + 10
2   libsystem_c.dylib             	0x00007fff202d3406 abort + 125
3   libc++abi.dylib               	0x00007fff20341ef2 abort_message + 241
4   libc++abi.dylib               	0x00007fff203335e5 demangling_terminate_handler() + 242
5   libobjc.A.dylib               	0x00007fff2022c3db _objc_terminate() + 104
6   libc++abi.dylib               	0x00007fff20341307 std::__terminate(void (*)()) + 8
7   libc++abi.dylib               	0x00007fff20343beb __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 27
8   libc++abi.dylib               	0x00007fff20343bb2 __cxa_throw + 116
9   libc++.1.dylib                	0x00007fff2031e7bb std::__1::__throw_system_error(int, char const*) + 77
10  libc++.1.dylib                	0x00007fff203153ed std::__1::mutex::lock() + 29
11  com.uaudio.effects.U3BU       	0x000000011082dbc8 UAThread::GetThreadName(_opaque_pthread_t*, char*, unsigned long) + 40
12  com.uaudio.effects.U3BU       	0x0000000110824e32 UALog::ProcessRecord(unsigned int&, unsigned int&) + 402
13  com.uaudio.effects.U3BU       	0x000000011081a81e UALog::ProcessRecords() + 206
14  com.uaudio.effects.U3BU       	0x000000011081be3d UALog::ThreadProc(bool volatile&) + 3341
15  com.uaudio.effects.U3BU       	0x000000011082d99a UAThread::ThreadProcInternal() + 170
16  com.uaudio.effects.U3BU       	0x000000011082defe void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (UAThread::*)(), UAThread*> >(void*) + 62
17  libsystem_pthread.dylib       	0x00007fff2037e8fc _pthread_start + 224
18  libsystem_pthread.dylib       	0x00007fff2037a443 thread_start + 15
1 Like

Also, from looking closely, that plugin is an Intel AU plugin which Apple automatically runs under Rosetta — all bets are off in that scenario as you’re now mixing native (GP) and Intel code. UA probably did enough testing to make sure it worked with Logic and that’s it.

You might try running the Intel version of Gig Performer so that everything is running under Rosetta and see if that works.

I just thought that 2 logs provide more info, anyway with regard to the manual steps I can say that I did all this or in other words all my UAD Plugins are running fine. The only problem I got is the recall plugin.

Thank you I will try. In that caseI hope that running GP under Rosetta will not cause other problems.

Dunno — users have reported that it seems to run fine but we’re not going to officially support GP under Rosetta since we do provide an Apple Silicon version and it is pretty certain that any issues will be caused by Rosetta. We had an Apple Silicon version available as soon as M1 machines became commercially available and I don’t know why the plugin developers didn’t do the same thing as M1 based developer machines were available a year or so before they were officially released. Plenty of time to port!

If we see a crash in GP (not in the plugin) that can be replicated on an Intel machine, then we’ll obviously take it seriously but if it only happens when running under Rosetta, then there’s really nothing we can do, we’re not going to debug Rosetta!

I’m still using an Intel machine for live performance and I won’t switch to an M1 until every plugin I need to use is also available in Apple Silicon.

2 Likes

Unbill now my issue is not resolved. I understand that this seems to be the responsibility of Universal Audio. So I posted my problem in their forum:
https://uadforum.com/community/index.php?threads/uad-console-recall-plugin-crashes-gig-performer.57630/#post-414694

This is the answer I got today from Universal Audio:
(I am still looking for a way to continue to use the Recall Plugin. Right now I have to restart my computer everytime I open a Gig File with the Recall Plugin in it.)

Thank you for contacting Universal Audio Customer Support; I hope you are safe and well!

Reading your description sounds like an incompatibility issue with Gig performer and the Console Recall plug-in.

Gigperformer is not a qualified application nor has it been tried or tested to function seamlessly without UAD Software.

Joachim, the unfortunate reality on this occasion is that our software teams will not investigate this issue until we hear from a more extensive cross-section of customers having similar problems with this Application.

I will certainly pass this on to the relevant teams, but to reiterate, due to Gig Performer being unsupported, it’s doubtful this issue will be investigated further by Universal Audio.

Sounds like pure ignorance.

1 Like

So Universal Audio doesn’t care at all about Gig Performer. Sad, but true. I just wonder why still all their Plugins run fine in Gig Performer and only the Recall Plugin is such a bad boy.
Is there nothing else I can do to make it work?
To be honest. I want to stay with Gig Performer in native mode because going back to Rosetta seems to have to much potential to get into other problems.

GP is very good at discovering issues early as it exercises much more of the plugin SDK than many other plugin hosts out there.

2 Likes

Thank you for taking this seriously and writing a tech note. The problem remains unsolved. It seems nobody else in this forum has this problem, so I can only pray for a wonder to happen that one day it might work again :wink:

Help yourself and the heaven will help you :grimacing: :innocent:

Workarounds to try will include Blue Cat’s Patchwork. Maybe using this as a wrapper for the UAD plugin will avoid crashes.

After updating to Gig Performer 4.5 the Console Recall Plugin works again :grinning:
I am using the Delayed Option in the Plugin Manager as well. I don’t know if that really can have also a positive effect on this Plugin, but anyway it seems to work. So I have one more reason to thank you for this great update. I also got the impression that complex Gig Files load a little bit faster now…?

1 Like

The Delayed mechanism is a great means to deal with plugins that don’t initialize themselves properly (of course, test your setup very thoroughly).

It can serve you as a “hacklet” to handle broken plugins.