GigPerformer crashes when I try to create a new Gig or open different one

[jbridguk]

I am having a problem that when I click ‘New Gig’ GigPerformer crashes, after I say ‘No’ to saving changes.

This is happening on Mojave after a fresh boot.

I tried waiting until the memory usage for GP stopped increasing, but made no difference.

If I try to load another Gig it also crashes.

Is there a way to start without loading the last Gig?

Please help as this is a big problem.

Best regards,
John Bridgwater

[jpt]

Sorry to hear you’re having problems. Are you getting any crash reports?

[jbridguk]

I found out that by holding down Alt when starting disables scripting and this then allowed me to create a new Gig.

If it helps, here is some of the crash info:
Process: GigPerformer3 [608]
Path: /Applications/GigPerformer3.app/Contents/MacOS/GigPerformer3
Identifier: GigPerformer3
Version: 3.8.0 (3.8.0)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: GigPerformer3 [608]
User ID: 502

Date/Time: 2020-09-28 23:08:15.894 +0100
OS Version: Mac OS X 10.14.6 (18G103)
Report Version: 12
Anonymous UUID: 37D3C8BA-9854-1720-C2A8-004131E3B14E

Time Awake Since Boot: 180 seconds

System Integrity Protection: enabled

Crashed Thread: 3 ScriptCallbackScheduler

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT
Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [608]

Thread 0:: JUCE Message Thread Dispatch queue: com.apple.main-thread

Thread 3 crashed with X86 Thread State (64-bit):
rax: 0x1000000000001000 rbx: 0x000070000afa2cf8 rcx: 0x000070000afa2d50 rdx: 0x0000000000000000
rdi: 0x00007fa2113dd7a0 rsi: 0x0000000000000000 rbp: 0x000070000afa2dc0 rsp: 0x000070000afa2ce0
r8: 0x0000000000002c23 r9: 0xffffffff00000000 r10: 0x000070000afa2d48 r11: 0x0000000000000202
r12: 0x00007fa204520568 r13: 0x00007fa2113dd7a0 r14: 0x000070000afa2e70 r15: 0x00007fa204520598
rip: 0x0000000102f90a47 rfl: 0x0000000000010202 cr2: 0x0000000106fc4000

Logical CPU: 4
Error Code: 0x00000000
Trap Number: 13

External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 62
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 40161
thread_create: 0
thread_set_state: 0

Model: MacBookPro11,2, BootROM 156.0.0.0.0, 4 processors, Intel Core i7, 2.2 GHz, 16 GB, SMC 2.18f15
Graphics: kHW_IntelIrisProItem, Intel Iris Pro, spdisplays_builtin
Memory Module: BANK 0/DIMM0, 8 GB, DDR3, 1600 MHz, 0x80AD, 0x484D54343147533641465238412D50422020
Memory Module: BANK 1/DIMM0, 8 GB, DDR3, 1600 MHz, 0x80AD, 0x484D54343147533641465238412D50422020
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x134), Broadcom BCM43xx 1.0 (7.77.61.2 AirPortDriverBrcmNIC-1305.8)
Bluetooth: Version 6.0.14d3, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
Serial ATA Device: APPLE SSD SM0512G, 500.28 GB
USB Device: USB 3.0 Bus
USB Device: 4-Port USB 3.0 Hub
USB Device: 4-Port USB 3.0 Hub
USB Device: Apple Internal Keyboard / Trackpad
USB Device: BRCM20702 Hub
USB Device: Bluetooth USB Host Controller
USB Device: 4-Port USB 2.0 Hub
USB Device: 4-Port USB 2.0 Hub
USB Device: FreeAgent
USB Device: Hub
USB Device: Iomega HDD
USB Device: Scarlett 2i2 USB
USB Device: SL STUDIO
USB Device: microKEY2
USB Device: nanoKONTROL Studio
Thunderbolt Bus: MacBook Pro, Apple Inc., 17.1

[jpt]

Great…this should help the moderators.

[jpt]

Are you able to upload a copy of your scripting in this gig…or even upload this gig file?

[dhj]

@jbridguk

Thread 3 crashed with X86 Thread State (64-bit):

Unfortunately, you didn’t include the actual stack traces so there’s no stack trace for Thread 3, making it impossible to know exactly what happened other than it has something to do with scripting.

[pianopaul]

Tried to reproduce with 3.8.0, but could not.
But I noticed, that I was not asked to save - even when I changed widgets - before creating a new gig.

Load the gig
Move the Widgets
Create a new gig, normally you should be asked if the current gig should be saved.
But this question dialog does not come up.

Maybe this helps to find the issue.
Script_Crash.gig (5.6 KB)

[David-san]

I cannot reproduce the crash on my Win 8.1 test laptop. However, I get this warning in the log window:

Rackspace_1: 0.3655000
Rackspace_1: 1.0000000
The widget 'GREY' is declared in a script but does not exist in the rackspace called 'Rackspace_1

This should be a clue as the GREY widget handle is perfectly defined in the Rackspace_1!

And when I remove the GREY knob, while the GPScript is running, I get twice the same message:

The widget 'GREY' is declared in a script but does not exist in the rackspace called 'Rackspace_1'
The widget 'GREY' is declared in a script but does not exist in the rackspace called 'Rackspace_1'

If I remove only the GREY handle and not the widget, I get the message only one time:

The widget 'GREY' is declared in a script but does not exist in the rackspace called 'Rackspace_1'

And once the widget or the handle are removed, no more message even if open a New Gig…

[dhj]

Thanks – that is how it was originally designed but I’m suspecting that, depending on what’s in the script, if we continue executing after that warning, that could be the issue

[jbridguk]

Hi, there was not enough room to include everything, sorry if I missed the crucial bit.

I will reproduce and send you the info and also attach the gig file.

Last change I made was to add widgets that opened the plugins on the front panel, if that is any clue.

[jbridguk]

GigPerformer Crash Dump.txt (136.3 KB)
Worship Rig C7 Lead(8).gig (715.5 KB)

Hi Here is the dump and gig file.

I hope this helps.

[keyman]

Why do you have SIP disabled?

[keyman]

Think I found a way to correct and it does not crash anymore:

Simply just delete the lines of Autodeclare and compile

edit:
ohhh, if you save and re open it goes to the previous behaviour…
must be something else in the script.

[dhj]

@jbridguk

Hi Here is the dump and gig file.

I hope this helps.

What are the precise steps needed to reproduce this crash?

[keyman]

Another look and its exactly the open/close Plugin window thats not correct.

@jbridguk

Last change I made was to add widgets that opened the plugins on the front panel, if that is any clue.

If you / comment / that whole section out, gig file does not crash anymore!!

Here is a post with implementing Open/close Plugin window script.

Make a button to open/close the VST window

Fresh nube in GP here, no experience in scripting at all. I’m trying to create a simple rack button that show/hide the VST. What I’ve done so far, is tried to copy the working script from one of the factory presets that does that, but has two assigned VST’s, and I need that for five VST’s. So I tried to copy the var and the // Called when a widget value has changed parts of the script by adding 5 times for each plugin with the names as described on the buttons I’ve placed, and failed misera…

Related…
This post has a rackspace with script Open/close Plugin window example

5 VST keyboard split/layer with scripting

As a new member of the GP community, I’d like to share my very first rackspace that I hope to put it through it’s pace as soon as possible. Script was provided and compiled by @schamass, and I was helped by several other members of the community. General features of the rack: Very basic rackspace for 5 instrument VST’s, intended to be used as a keyboard split where the VST 1 has a set split point from C-2 to B2, while VST 2 to 5 start from C3 to G8, which also and can be layered if desired. Yo…

[jbridguk]

Try to close the gig or open another

[jbridguk]

Sorry, but I don’t see what is wrong with the code…it is the same as the example that you showed.

In fact I followed the pattern that was mentioned by one of the admins when I asked how to open plugins from the front panel.

This should not crash gigperformer even if the code is wrong.

In fact it was David-san who gave the example to me:

Hi @tmart, welcome to the comunity. Here is a gigfile with a widget button which opens a plugin window: Plugin_button.gig (8.7 KB)

It is based on this script:

//$
// DO NOT EDIT THIS SECTION MANUALLY
Var
PLUGIN : PluginBlock
PLUGIN_BUTTON : Widget
//$

// Called when a widget value has changed

On WidgetValueChanged(newValue : double) from PLUGIN_BUTTON

If (newValue > 0.5)
Then
OpenPlugin(PLUGIN);
Else
ClosePlugin(PLUGIN)
End
End

[keyman]

@jbridguk

Sorry, but I don’t see what is wrong with the code

I think this is causing GP to crash:
(when I click ‘New Gig’ GigPerformer crashes, after I say ‘No’ to saving change)

On WidgetValueChanged(newValue : double) from PianoPluginBtn
      if (newValue > 0.5) then
        OpenPlugin(WorshipGrandeurPlugin);
      end
      SetWidgetValue(PianoPluginBtn, 0);
    End

This is most commonly used for open/close plugin window

On WidgetValueChanged (newValue : double) from PianoPluginBtn
   If newValue > 0.5
    then OpenPlugin(WorshipGrandeurPlugin)
    Else ClosePlugin(WorshipGrandeurPlugin)
End
End

Minimum gig to reproduce:
open plugin window-crash.gig (4.9 KB)

@David-san care to comment? test the above gig file?
Thanks

[David-san]

This GPScript converts the LED button into a momentary button. It can be dangerous to modify the state of a widget within the widget callback itself. Here it creates an infinite loop!

You can modify the GPscript this way to do the same while avoiding the infinite loop:

On WidgetValueChanged(newValue : double) from PianoPluginBtn
  if (newValue > 0.5)
  then
    OpenPlugin(WorshipGrandeurPlugin);
  end
  if PianoPluginBtn.GetWidgetValue() != 0
  then
    SetWidgetValue(PianoPluginBtn, 0);
  end
end

[dhj]

Why would you not write

On WidgetValueChanged(newValue : double) from PianoPluginBtn
  if (newValue > 0.5)
     then
        OpenPlugin(WorshipGrandeurPlugin);
        SetWidgetValue(PianoPluginBtn, 0);
  end
end

In other words, why do you need a separate test for the widget value since, you already know it’s not zero if the callback was triggered.