Korg plugin crash - Help needed

Hello

yesterday night, during a show, when changing song part/rackspace, GP crashed.

It’s a very annoying situation because I have to stop playing for about 3 minutes (the time needed to restart GP an load my gigfile again) while the band keeps playing.

I am uploading the crash report hoping that someone can help me understand what happened and why it happened, so that I can prevent it in the future.

Thank you all for your help

Salomao

GigPerformer5-2025-05-11-145915.ips.zip (11.7 KB)

Halion 7 crashed –

Many have reported problems with that plugin - and it appears to be a codesigning issue

Sounds like they’re using some funky license protection that’s changing the actual code, thereby causing macOS to kill it. Did that not happen while you were rehearsing?

Or did you download a new version at the last minute?


Exception Type: EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid))
Exception Codes: UNKNOWN_0x32 at 0x0000000140f93d3c
Exception Codes: 0x0000000000000032, 0x0000000140f93d3c

Termination Reason: Namespace CODESIGNING, Code 2 Invalid Page

VM Region Info: 0x140f93d3c is in 0x140f44000-0x141198000; bytes after start: 326972 bytes before end: 2114243
REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
MALLOC_LARGE 13e430000-13fa34000 [ 22.0M] rw-/rwx SM=COW
GAP OF 0x1510000 BYTES
—> __TEXT 140f44000-141198000 [ 2384K] r-x/rwx SM=COW /Library/Application Support/Steinberg//license-engine-access.bundle/Contents/MacOS/license-engine-access
__DATA_CONST 141198000-1411bc000 [ 144K] r–/rwx SM=COW /Library/Application Support/Steinberg/
/license-engine-access.bundle/Contents/MacOS/license-engine-access

Kernel Triage:
VM - (arg = 0x0) A memory corruption was found in executable text


Thread 0:: HotFudge Dispatch queue: com.apple.main-thread
0 libsystem_platform.dylib 0x195040194 _platform_strlen + 52
1 HALion 7 0x179b6ac58 0x1787b8000 + 20655192
2 HALion 7 0x179b6b3c4 0x1787b8000 + 20657092
3 HALion 7 0x17a4b5d7c 0x1787b8000 + 30399868
4 HALion 7 0x17a4b5370 0x1787b8000 + 30397296
5 HALion 7 0x17a4aa894 0x1787b8000 + 30353556
6 HALion 7 0x17a4aaaa0 0x1787b8000 + 30354080
7 HALion 7 0x17a3322b4 0x1787b8000 + 28811956
8 HALion 7 0x17a325638 0x1787b8000 + 28759608
9 HALion 7 0x17a3246b4 0x1787b8000 + 28755636
10 HALion 7 0x178e3c570 0x1787b8000 + 6833520
11 HALion 7 0x178e3d148 0x1787b8000 + 6836552
12 HALion 7 0x178e3ebbc 0x1787b8000 + 6843324
13 HALion 7 0x1787bd2a4 0x1787b8000 + 21156
14 GigPerformer5 0x102af66d0 0x102334000 + 8136400
15 GigPerformer5 0x102af1a40 0x102334000 + 8116800
16 GigPerformer5 0x1029e45a8 0x102334000 + 7013800
17 GigPerformer5 0x1028f4104 0x102334000 + 6029572
18 GigPerformer5 0x1028f7d28 0x102334000 + 6044968
19 GigPerformer5 0x1029d448c 0x102334000 + 6947980
20 GigPerformer5 0x1029d02f0 0x102334000 + 6931184
21 GigPerformer5 0x102cb46d0 0x102334000 + 9963216
22 GigPerformer5 0x102cb4c38 0x102334000 + 9964600
23 GigPerformer5 0x102a215a4 0x102334000 + 7263652
24 GigPerformer5 0x102a2a6d0 0x102334000 + 7300816
25 GigPerformer5 0x1026ff8cc 0x102334000 + 3979468
26 GigPerformer5 0x102b7fa24 0x102334000 + 8698404
27 GigPerformer5 0x102b7f8e0 0x102334000 + 8698080
28 CoreFoundation 0x1950f48a4 CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28
29 CoreFoundation 0x1950f4838 __CFRunLoopDoSource0 + 176
30 CoreFoundation 0x1950f459c __CFRunLoopDoSources0 + 244
31 CoreFoundation 0x1950f3138 __CFRunLoopRun + 840
32 CoreFoundation 0x1950f2734 CFRunLoopRunSpecific + 588
33 HIToolbox 0x1a0661530 RunCurrentEventLoopInMode + 292
34 HIToolbox 0x1a0667348 ReceiveNextEventCommon + 676
35 HIToolbox 0x1a0667508 _BlockUntilNextEventMatchingListInModeWithFilter + 76
36 AppKit 0x198c6a848 _DPSNextEvent + 660
37 AppKit 0x1995d0c24 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688
38 AppKit 0x198c5d874 -[NSApplication run] + 480
39 GigPerformer5 0x1029f8994 0x102334000 + 7096724
40 dyld 0x194c8c274 start + 2840

I am so sorry, it seems I send the wrong crashlog.

Please consider the newest file attached now.

For what it seems, it looks like the crash was caused by Triton Extreme.

If thats the case, its totally unexpected because:

  1. its a payed/legit plugin
  2. It never crashed during rehearsal or gigfile building
  3. I couldn’t reproduce it again. I have been making the same song part change several times to see if GP crashes again but it didn’t (I hope it will never crash again)

If the cash was really TE culprit, I must understand WHY.

Thank you
GigPerformer5-2025-05-10-235319.ips.zip (97.7 KB)

Only the developer of the plugin can investigate why the plugin crashed.

Well, it’s definitely the TRITON_Extreme and looking at the stack trace it looks like it is crashing because it’s trying to load a new preset - did you send a program change message to it or something?

This, by the way, is precisely why we tell people to avoid using program change messages for plugins - there is just no guarantee that the plugin will (a) handle it or (b) be ready when you try to play something.

That said, you should report the problem to Korg and let us know what they say.

OK - but I’d still like to know why the code signature crash happened.

Thread 0:: HotFudge Dispatch queue: com.apple.main-thread
0   libsystem_malloc.dylib        	       0x18666bda0 nanov2_malloc_type + 272
1   libc++abi.dylib               	       0x1867fa36c operator new(unsigned long) + 52
2   libc++.1.dylib                	       0x186767e84 std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::__init_copy_ctor_external(char const*, unsigned long) + 92
3   libc++.1.dylib                	       0x18676dfc8 std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::basic_string(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&) + 64
4   TRITON_Extreme                	       0x3186b2bac korg::triton::TritonLibrary::prepareCombiCache_() + 240
5   TRITON_Extreme                	       0x3186ae484 korg::triton::TritonLibrary::getCombiParameter(unsigned long) + 188
6   TRITON_Extreme                	       0x3186b88a8 korg::triton::TritonLibrary::processSwitch_(unsigned long, korg::triton::Mode, bool) + 224
7   TRITON_Extreme                	       0x3186c2be0 korg::triton::TritonLibrary::setCurCombiNo(unsigned char, unsigned char) + 2684
8   TRITON_Extreme                	       0x318416bd0 ProgramManager::loadProgram(Program const*) + 280
9   TRITON_Extreme                	       0x31841b258 ProgramManager::triggerProgramChange(int) + 400
10  TRITON_Extreme                	       0x3184b3f78 juce::MessageQueue::runLoopCallback() + 64
11  CoreFoundation                	       0x1869288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
12  CoreFoundation                	       0x186928838 __CFRunLoopDoSource0 + 176
13  CoreFoundation                	       0x186928600 __CFRunLoopDoSources0 + 344
14  CoreFoundation                	       0x186927138 __CFRunLoopRun + 840
15  CoreFoundation                	       0x186926734 CFRunLoopRunSpecific + 588
16  HIToolbox                     	       0x191e95530 RunCurrentEventLoopInMode + 292
17  HIToolbox                     	       0x191e9b348 ReceiveNextEventCommon + 676
18  HIToolbox                     	       0x191e9b508 _BlockUntilNextEventMatchingListInModeWithFilter + 76
19  AppKit                        	       0x18a49e848 _DPSNextEvent + 660
20  AppKit                        	       0x18ae04c24 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688
21  AppKit                        	       0x18a491874 -[NSApplication run] + 480
22  GigPerformer5                 	       0x104a3c994 0x104378000 + 7096724
23  dyld                          	       0x1864c0274 start + 2840

That’s the way I use Triton Extreme and thats how I allways did.

As I use TE in most of my songs/rackspaces, I placed it in Global Rackspace and use a script to change it’s program or combination on rackspase/song or songpart change.

Considering all the time spent on building my gigfile, my countless hours of practice, band rehearsal and live performances, I have done that hundreds or thousands of times, and never had this kind of crash.

If it happend because the plugn couldn’t handle the program change command (for the first time that I can remember) then the final outcome should be “no sound” from the plugin and not a GP total crash.

I am worried because at the next concert I’ll always be afraid that GP will crash again.

GP isn’t crashing…the plugin is crashing the GP process. Your plugin is just a library running in the same process space as Gig Performer and that’s why it’s bringing down GP.

It is up to the plugin developer to handle issues that occur inside the plugin. I don’t know what the plugin was trying to do when it was asked to load another program but it is 100% a plugin bug. You should report it to Korg.

I repeat that this is precisely why we strongly discourage the use of program changes and it is why we developed the whole rackspace model in the first place.

If you want to protect GP from future failures of that plugin, then I suppose you could run it in a separate GP instance (i.e, a separate process( and use GP Relayer for audio/MIDI communication, then if it crashes, it will just bring down that process and not impact GP.

2 Likes

I agree 100% but it’s up to the plugin to do that!

I’m a little baffled as to why the stack trace for the Triton includes the function names. Normally those would not appear in a stack trace unless a debug version of the plugin was being used that retained symbol names.

I think this is worth sending to Korg — I will forward the crash report to my contact there.

1 Like

I reported this crash to KORG. Here is their answer:

Hello, Salomão.

Thank you for contacting us, and thank you for sharing the bug report.
We have also received a similar request from David Jameson, developer of the Gig Performer.
Our team will investigate the crash and hopefully have it fix in the next update.

We will keep you informed by here. Meanwhile, feel free to ask any question or add any relevant details.

Thank you in advance for your cooperation.

Best regards,

KORG App Team

So, thank you very much @dhj . That’s one of the reasons GP is a brilliant piece of software.

5 Likes

Last Friday, during a live concert, I had another gig performer crash.

It was the same system, setup and gig file, although the crash occurred when I was changing a different song part/rackspace from the one in which the previous crash had occurred.

I need help to try to understand/confirm whether the crash was caused again by the Triton Extreme plugin and for the same reasons so that, if confirmed, I can report/insist again with KORG.

Thank you very much for your help.

Edited: I properly compressed your file – look at the size difference

GigPerformer5-2025-06-13-191747.ips.zip (94.7 KB)

It looks like you just added “.zip” to the end of the IPS file.

Please don’t do that. This ends up loading a 2Mb file into our server. You need to actually COMPRESS the IPS file. Then the file is less than 100k

And yes, it is the Triton Extreme.

Send the report (compressing it PROPERLY first) to Korg

Thread 13 Crashed:: com.apple.audio.IOThread.client
0   TRITON_Extreme                	       0x340dcbbb4 korg::triton::TritonSynth::LFO_Advance(int, int) + 80
1   TRITON_Extreme                	       0x340dd7ce8 korg::triton::TritonLibrary::OnFsConvProcessReplacingSafe(float**, float**, unsigned int) + 4660
2   TRITON_Extreme                	       0x340dd6a70 korg::triton::TritonLibrary::OnFsConvProcessReplacing(float**, float**, unsigned int) + 92
3   TRITON_Extreme                	       0x340df3fec korg::triton::TritonLibrary::processReplacing(float**, float**, unsigned long) + 824
4   TRITON_Extreme                	       0x340b3c48c TritonPluginAudioProcessor::processBlock(juce::AudioBuffer<float>&, juce::MidiBuffer&) + 416
5   TRITON_Extreme                	       0x340d06a68 void juce::JuceVST3Component::processAudio<float>(Steinberg::Vst::ProcessData&, juce::Array<float*, juce::DummyCriticalSection, 0>&) + 2352
6   TRITON_Extreme                	       0x340d01720 juce::JuceVST3Component::process(Steinberg::Vst::ProcessData&) + 548
7   GigPerformer5                 	       0x105177f50 0x1049a8000 + 8191824
8   GigPerformer5                 	       0x10516f898 0x1049a8000 + 8157336
9   GigPerformer5                 	       0x10514d4fc 0x1049a8000 + 8017148
10  GigPerformer5                 	       0x1051487a8 0x1049a8000 + 7997352
11  GigPerformer5                 	       0x1051a2028 0x1049a8000 + 8364072
12  GigPerformer5                 	       0x1050d4674 0x1049a8000 + 7521908
13  GigPerformer5                 	       0x1050d0a54 0x1049a8000 + 7506516
14  CoreAudio                     	       0x18f445b50 HALC_ProxyIOContext::IOWorkLoop() + 11068
15  CoreAudio                     	       0x18f442898 invocation function for block in HALC_ProxyIOContext::HALC_ProxyIOContext(unsigned int, unsigned int) + 176
16  CoreAudio                     	       0x18f5f3760 HALC_IOThread::Entry(void*) + 88
17  libsystem_pthread.dylib       	       0x18c9082e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18c9030fc thread_start + 8
3 Likes