Loading some Surge XT modules will cause the DAW to crash, REAPER v6.67, Cardinal VST3 (main) 23.02

[GBaige]

Through limited testing it seems only VCO modules are affected; the rest of the modules load without issues

[falkTX]

and only on vst3 format?

[nucklearproject]

Same problem here. I tested in Reaper(last version) VST3, Clap Bitwig(last version) VST and CLAP Also in standalone version.

I Tested change it ASIO drivers, ASIO, FL ASIO, WASAPI but it only happens with some Surge XT modules like Wavetable, Twist VCO, FM VCO... Etc..

Windows 11

[c-ham]

Same in Live 11.1.6 (Windows 11, VST3 format). All the VCOs + tuned delay crash the program.

[GBaige]

My bad, I forgot to mention I'm on Windows 11. Can't confirm whether it happens in other operating systems.

[bboxdave]

I also observed this issue on Windows 10, with Clap and VST3 versions, in Bitwig 4.3.10. Tried several Surge VCO modules and they caused crash; tried a few other Surge and non-Surge modules and they caused no issues. Didn't spend as much time on Cubase 11 with VST2 (also Windows 10), but quick attempt to load a few different Surge VCO modules produced crash there.

[cobra1101]

I was just having the same problem, and it seems to be just the surge vco modules. Others work fine. Reaper 6.76, windows 10, VST3

[offthesky]

also experiencing this with surge vco modules: ableton vst2 x64, win 11

[benaldhouse]

I've had this with Ardour.

[dromer]

@benaldhouse can you be a bit more explicit? which plugin format and OS?

[benaldhouse]

@dromer I'm on Windows 11 and I would have selected VST3 (is that what you mean by plugin format? I don't know what the difference is but it's got a higher number in it...). I'm afraid I have uninstalled 23.02 and reinstalled 22.12 because of these issues. I also have to say - even though I am sure I will grow to love the evolving remote control features - I am wary of Cardinal becoming open to the internet. I like Cardinal because of it not phoning home. I had a security scare last year and I'm keen to avoid another... Would it be actionable to have a separate version with remote connectivity perhaps?

[falkTX]

I am against any kind of internet connectivity myself. local network usage is different, it remains locally while still have the benefits of allowing remote control from a nearby device. I will make to get this into shape soon, and have it be opt-in. There is no need to enable it by default.

[benaldhouse]

Thanks Filipe. I love your work. Thank you for Cardinal.

On Mon, Mar 6, 2023 at 10:59 AM Filipe Coelho @.***> wrote:

I am against any kind of internet connectivity myself. local network usage is different, it remains locally while still have the benefits of allowing remote control from a nearby device. I will make to get this into shape soon, and have it be opt-in. There is no need to enable it by default.

— Reply to this email directly, view it on GitHub https://github.com/DISTRHO/Cardinal/issues/502#issuecomment-1455915314, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQIIO4VMB2X6RD74XXJ2KELW2W7QFANCNFSM6AAAAAAVLSV6BQ . You are receiving this because you were mentioned.Message ID: @.***>

[Vospi]

Adding to this.

Video demonstration: https://youtu.be/Xt5h-_8JZ3Q

Windows 10 x64, legit newest stable FL Studio 21, certain Surge XT modules don't load, there's a crash message, but the DAW doesn't go, the module just doesn't work. Pre-existing FL Studio presets with these modules also do not open.

Would LOVE the fix, because I LOVE both Cardinal and Surge. I use them on a day-to-day basis and in my teaching practice as well. I've currently just installed 22.12 back over without uninstalling. Seems to be working fine as of now.

[naprox1789]

I have had this same issue with a project using the Classic VCO. After, I updated my desktop and laptop to version 23.02, a project with the Classic VCO crashed Cardinal in standalone mode on both computers. If I loaded that file into a Cardinal instrument track in Cubase, it would immediately crash Cubase.

I rolled Cardinal back to the previous version on the desktop, and the file opens without a problem again. I deleted the Classic VCO and saved as a test file. The test file now opens fine on the laptop, which is still running version 23.02.

The patch also includes the Surge XT Filter and the Surge LFO x EG, but those don't seem to be causing problems.

I hope this get fixed. I love Cardinal, and Surge XT is my go-to brand for VCOs. Huge thanks to everyone involved in this project.

[hmturnbull]

I've been having the same problem. Whenever I try to add one of the affected Surge XT modules, it doesn't work. When I'm using the .vst2 version in my DAW (Studio One 6), I just get an error and the module doesn't get added. When I try to add an affected module in the standalone version of Cardinal, it crashes. I'd post a log file, but I couldn't find any info on where the crash log might be.

As has been said before, it seems to work fine in version 22.12.

Surge XT version: 23.02 OS: Windows 10

[shimaore]

CardinalJACK on Linux (x86_64), start Cardinal, add VCO Sine, segmentation fault.

gdb doesn't see the inside application, I'll have to build & debug without unzipfx.

[shimaore]

gdb's backtrace isn't really helpful since symbols are lacking in the executable extracted from CardinaJACK:

#0  0x0000555556bf02c4 in ?? ()
#1  0x0000555556bf8180 in ?? ()
#2  0x0000555556937a30 in ?? ()
#3  0x0000555556937fa9 in ?? ()
#4  0x000055555804f429 in ?? ()
#5  0x000055555804f429 in ?? ()
#6  0x000055555804f429 in ?? ()
#7  0x0000555555ed622a in ?? ()
#8  0x0000555555ed622a in ?? ()
#9  0x000055555690b5cf in ?? ()
#10 0x000055555804ebe2 in ?? ()
#11 0x0000555556906205 in ?? ()
#12 0x000055555804ebe2 in ?? ()
#13 0x000055555691aaa2 in ?? ()
#14 0x000055555806a42f in ?? ()
#15 0x00005555580a2e09 in ?? ()
#16 0x000055555805b3ec in ?? ()
#17 0x000055555806cb8d in ?? ()
#18 0x000055555806e868 in ?? ()
#19 0x00005555580b9d46 in ?? ()
#20 0x0000555555eb3c30 in ?? ()
#21 0x00007ffff7d0b18a in __libc_start_call_main (
    main=main@entry=0x555555eb3ad0, argc=argc@entry=1,
    argv=argv@entry=0x7fffffffde78)
    at ../sysdeps/nptl/libc_start_call_main.h:58
#22 0x00007ffff7d0b245 in __libc_start_main_impl (
    main=0x555555eb3ad0, argc=1, argv=0x7fffffffde78,
    init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fffffffde68)
    at ../csu/libc-start.c:381
#23 0x0000555555eb454e in ?? ()

I guess a full build with debug symbols is in order.

[shimaore]

fwiw I was hoping to save myself from having to run a full UI build, but the above is not reproducible on a 23.02 headless build: loading a VCV file containing only the plugin using the OSC /load command works fine. If I open the same VCV file from 23.02 CardinalJACK (using File/Open), it crashes.

So this seems related to the UI. Still need to run a full build locally to debug.

[shimaore]

Testing with a DEBUG=true build the process does not crash. I will build a regular image and see if it crashes.

[shimaore]

I cannot reproduce the crash with a locally-built version of Cardinal 23.02 (x86-64, Linux Debian), with the UI and no debugs. In other words, I cannot reproduce with any locally-built version I've tried. (I used plain make -j2 to build my latest version.)

I can reproduce with the x86_64 version from github releases every time.

[falkTX]

That sounds to me like is a missing resource. That would explain why I couldnt reproduce the crash on my linux local build, but weird then that macOS ends up being ok..

[shimaore]

I compared the output of unzip -v on Cardinal-JACK (as found on Github Releases) and in my local build and they are identical (i.e. no missing resource as far as that's concerned). I'll check what happens during execution.

[shimaore]

The only (recursive) difference in /tmp/Cardinal between the version published in Github Release and a locally built version of 23.02 is the binary executable.

I noticed (in the output of ldd /tmp/Cardinal/Cardinal) that the GH release uses librt and libdl which the local build doesn't, while the local build uses (Debian's) libbz2, liblo, libFLAC … which the GH release (presumably) incorporates? (I'm not even sure how this happens, since the workflow files don't mention STATIC_BUILD which I assume is what is used to achieve this.)

[bkt0031]

I'm also having issues with loading the Surge XT VCO modules crashing Reaper v6.78 win64 on a Window 10 Pro 21H2 19044.2728 system running Cardinal 23.02 as a VST3i plugin. I too have downgraded back to Cardinal 22.12 to get it working again.

[GBaige]

Issue fixed in latest build (a42ca2c), REAPER v6.78, Cardinal VST3 (main)

Thanks folks!

[falkTX]

err how come? I didnt change anything surge related..

[GBaige]

err how come? I didnt change anything surge related..

Well I suppose you'd know haha... maybe the main branch builds are built differently than the nightly builds? Maybe some sources are different? That would explain why some other modules (esp. by Valley) cause crashing on Windows.

All I know is that the issue isn't present in the latest nightly.

[bboxdave]

After seeing the previous comments, I also checked out the latest nightly (https://github.com/DISTRHO/Cardinal/commit/a42ca2c5df52f9d300f0e712465cf8082e46d133), on Windows 10 with Bitwig 5 Beta 3 (CLAP) and Cubase Pro 11 and 12 (VST3). In each case I was able to load up and play a patch with a Surge FM3 VCO module, and also load a few other Surge VCO modules, which I wasn't able to do before. Thanks!

[Vospi]

I would really appreciate if someone guided me to Nightly Builds for Windows, or told me that I definitely have to learn to build myself until another stable comes out. :)

[GBaige]

@Vospi you must be logged in (below is a gif with instructions, just in case it didn't load at first)

[offthesky]

win11, ableton 11 x64, VST2 (via a42ca2c) surge vcos's now seem to be magically working okay again without crashes on load or when reloading older projects that use these modules. rad :)

[falkTX]

Please try the latest build at https://github.com/DISTRHO/Cardinal/actions/runs/4731677171 The code is exactly the same, I only tweaked the build setup. often we turn on LTO for releases, but then turn it off for regular builds as it significantly increases the build time. I wonder if that is the reason for the issues, testing needed to confirm

[bboxdave]

Please try the latest build at https://github.com/DISTRHO/Cardinal/actions/runs/4731677171 The code is exactly the same, I only tweaked the build setup. often we turn on LTO for releases, but then turn it off for regular builds as it significantly increases the build time. I wonder if that is the reason for the issues, testing needed to confirm

I tried the build at https://github.com/DISTRHO/Cardinal/actions/runs/4731677171 (win64) on Windows 10, Bitwig 5 Beta 3 (CLAP) and Cubase Pro 12 (VST3) and the crashing problem returned in both cases.

[GBaige]

Please try the latest build at https://github.com/DISTRHO/Cardinal/actions/runs/4731677171 The code is exactly the same, I only tweaked the build setup. often we turn on LTO for releases, but then turn it off for regular builds as it significantly increases the build time. I wonder if that is the reason for the issues, testing needed to confirm

Can confirm it crashes, Cardinal VST3 (main), REAPER v6.78, Windows 11

[falkTX]

closing ticket as it was confirmed to be due to LTO, and release builds no longer make use of it.