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.
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?
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
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:
its a payed/legit plugin
It never crashed during rehearsal or gigfile building
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.
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.
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.
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.
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.
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