Crash at GP 6.0.16

Since I started using GP Beta, GP crashes very often.
That’s obviously annoying. I can’t find any setting where GP performs an autosave at certain intervals.
When Logic crashes, it still saves the song before closing.
Is there a crash report I can send you to help you better understand the cause of the crash?

I’m testing a few scenarios and will add them here later:
* Could it be that GP doesn’t handle quickly switching between songs well (which I’m currently doing while programming)?
At the moment, I have 30 songs programmed. GP loads everything into memory (predictive loading is disabled) because it makes programming easier for me.

*The next theory would be that I have a programming error in my local GP ports. I’ve only been using them recently.

*The crashes occur more frequently when I switch to or from the new songs that use the Local GP Ports programming.
I manually switched between 10 songs and didn’t cause any crashes.
After that, I tried switching songs using the iPad (which worked fine before the crash issues started), and it immediately caused a crash.
Is it possible that the Program Change message sent by the iPad is creating some kind of loop that causes GP to crash?

There is no autosave - get into the habit of hitting Command-S

Crash reports can be found using the Console application. Definitely need to see crash reports

Yes – I’m now saving every 10 minutes.

In memory, there’s only an old crash (I think it was the first one) from two days ago.
I’ll send you that one. If I get a more recent crash report, I’ll send it later. Maybe because GP just froze, and I closed it right away using Command–Option–Esc. I won’t force-quit the next GP crash and will wait until a report appears.

The IPS report is a crash report from two days ago. The TXT file is a copy of the report that is sent to Apple. As I mentioned before, I left GP in the “frozen” state for 6 hours, and no crash report was generated. Therefore, I stopped the process and was able to send a report to Apple, which I have now also copied into the Fehler.TXT file.

The crash report is an IPS file. I can’t upload it, so I’ve renamed it to a TXT file.

GigPerformer6-2025-10-27-233751.txt (5.5 MB)

Fehler.txt (5.6 MB)

When I look a crash reports generated on MAC the look totally different
Where did you get it from?

I would still love to have a keyboard command to update rackspace. I do save often but I find its faster to update the rackspace im working on sometimes.

What do you mean by that?
Write back the changes of the active rackspace into the gig file?

Not a problem - looks like your SEM V2 plugin crashed

Thread 0 Crashed:: HotFudge Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x183550388 __pthread_kill + 8
1 libsystem_pthread.dylib 0x18358988c pthread_kill + 296
2 libsystem_c.dylib 0x183492c60 abort + 124
3 libc++abi.dylib 0x18353f39c abort_message + 132
4 libc++abi.dylib 0x18352dcf0 demangling_terminate_handler() + 316
5 libobjc.A.dylib 0x1831b4d84 _objc_terminate() + 172
6 libc++abi.dylib 0x18353e6b0 std::__terminate(void (*)()) + 16
7 libc++abi.dylib 0x18353e654 std::terminate() + 108
8 SEM V2 0xfbd4224b8 0xfbd000000 + 4334776
9 SEM V2 0xfbd2014a8 0xfbd000000 + 2102440

10 libsystem_c.dylib 0x183441944 __cxa_finalize_ranges + 480
11 libsystem_c.dylib 0x183441704 exit + 44
12 libdyld.dylib 0x183593dc8 dyld4::LibSystemHelpers::exit(int) const + 20
13 dyld 0x1831eac60 dyld4::LibSystemHelpersWrapper::exit(int) const + 172
14 dyld 0x1831eab7c start + 6048

yes, exactly that. At the moment there doesn’t seem a way to do it with just the keyboard.

The report named GigPerformer is from the Console (Crash Reports). The report named Fehler contains the text I copied before the error message about a program crash could be automatically sent to Apple.

Wow. Thanks for the info. I’ll remove the plugin from the rackspace and test how it behaves afterward. Then I’ll have to see whether a newer version of the SEM is more stable.
What I’ve noticed during the crashes is that the loading times when restarting GP (even with only one rackspace active in predictive loading) are very long. I currently have 30 songs, and the restart takes about 1.5 minutes (when predictive loading is disabled). That would mean about 7.5 minutes for 150 songs. Are there any possible solutions for this?
I’m leaving for vacation with my son today. I’ll take a look at it next week. Thanks again for the quick reply.

Your plugins may be trying to connect to their companys’ web servers for license checks and getting held up – depends on how your internet settings are configured.

Actually, the plugins never check online. I’ve activated all the licenses on the computer. During live performances, I don’t have internet access anyway. The loading times per song are definitely faster than in Logic. However, when Logic crashes, I only need to restart the current song, and I can play again. When GP crashes, though, it reloads everything — and that takes time. So it’s really worth considering setting up a parallel second system.

Because Logic only has 1 song or better project :wink:

Another argument to implement some kind of a sandboxing. “Design mode”.

That’s not a legitimate comparison.

Remember that Gig Performer has to load EVERYTHING you will need for your entire show – that’s a deliberate design decision – the point is to have everything preloaded so that there’s no risk of a plugin failing DURING your show due to a loading glitch.

Logic only has to load plugins for a single project (song)

Don’t be too sure - they may also be trying to check for updates and if you have no internet connection, some of them may still try to connect (depends on the competence of the developer!) and then time out on DNS failure (which is generally 9 seconds).

I’m back from vacation.

I created a GIG file without SEM2. GP is still freezing. I then tried a long series of tests, since the song that triggers the crash is the first time I’ve used the Opus plugin from EastWest Sounds. I found a thread that already addressed this problem. Opus makes GP to crash - #20 by dhj

I created a test file with only four songs. Two of them (36 and 35) contain SEM2 and Opus. The first time I dragged Opus into GP, it froze immediately. After restarting, I dragged Opus into Rackspace again. This time it imported without any problems (AU, VST, and VST3). I imported the third song (33) from my standard GIG file. I did the same with the fourth song (34). Interestingly, I left 15 minutes between songs using my iPad, and nothing happened. As soon as I play the note in song 33 that triggers the song part (verse) and then switch to song 34, GP freezes. However, if I switch songs manually on my computer, GP doesn’t freeze. I’ve come to this conclusion after five hours of troubleshooting. Unfortunately, this type of crash doesn’t generate an error report. Could it be that Opus is causing this freeze? (Because it also freezes when I drag in the plugin).

But why does GP always freeze when switching songs using my iPad and not manually, as you can see in the video?

I have to solve this problem because there’s nothing worse on stage than constantly having this error on your mind.

OK - I’m confused!

Which is it? Is GP crashing or is it freezing? Those issues have to be dealt with in completely different ways? If it’s freezing, I bet you have created an infinite loop somewhere.

I suspect the same is true. GP freezes – only freezes. As you can see in the video, but only in this specific setup with the iPad. From now on, I’ll program the new songs in a separate GIG file and then import them into my main GIG file later. Perhaps this will help me better understand any further freezes or crashes.

If anyone has any ideas, I would be very grateful.

By the way: I also did the test with GP 5. Exactly the same behavior.

8 posts were split to a new topic: Another complete crash