Crash upon use of a certain VST plugin that does not occur in previous LMMS versions

[NewActiveXObject]

System Information

Windows 10 (x64), Intel Graphics HD 5000

LMMS Version(s)

1.3.0-alpha.1.813+9cb3ae7

Most Recent Working Version

1.3.0-alpha.1.690+gd703f3915

Bug Summary

Briefly: I upgraded LMMS by selecting a newer version and kept a handful of older projects with the AuraPlug VST effect Red Skull, which functioned wonderfully in the previous version reported. Now, the VST does not load at all, which is shown:

• Through reporting with a message box that "The following errors occurred while loading: the VST plugin RedSkull (x64).dll could not be loaded."
• The following (portion) of console output appears, taking a sample project as an example:

Unable to open default EUDC font: "C:\WINDOWS\FONTS\EUDC.TTE" Cannot load library C:\Program Files\LMMS\plugins\carlarack.dll: Impossibile trovare il modulo specificato. Cannot load library C:\Program Files\LMMS\plugins\carlapatchbay.dll: Impossibile trovare il modulo specificato. Cannot load library C:\Program Files\LMMS\plugins\carlabase.dll: Impossibile trovare il modulo specificato. [...] unique ID: afs1 RemotePlugin::DebugMessage: inputs: 2 output: 2 RemotePlugin::DebugMessage: creating editor Process error: QProcess::Crashed Remote plugin crashed remote plugin died! invalidating now. [...]

Expected Behaviour

Red Skull should load.

Steps To Reproduce

Download the plugin from any trusted repository and select it from any instrument.

Logs

Click to expand

Screenshots / Minimum Reproducible Project

No response

Please search the issue tracker for existing bug reports before submitting your own.

• [x] I have searched all existing issues and confirmed that this is not a duplicate.

[tresf]

@NewActiveXObject thanks for reporting this. I've reproduced and milestones this for the 1.3 release which we're working towards.

• The 32-bit VST effect seems to work fine.
• The 64-bit VST crashes and does NOT work.

For now, please switch to the 32-bit VST effect until we can find someone to debug this further and thank you for finding bugs with our nightly version, it's greatly appreciated! Please feel free to tag myself directly for more items that directly related to the nightly branch. If you're interested in getting formally involved with our testing team, feel free to ping me on Discord https://lmms.io/chat

[tresf]

VST instrument Synth1 beta seems to crash on the 64-bit VST as well. It loads up OK, but after sending a few notes, it crashes... 32-bit VST seems OK.

PS ~> Lv2 plugin SUMMARY: 0 of 0  loaded in 0 msecs.
unique ID: S1Vs
RemotePlugin::DebugMessage: inputs: 0  output: 2
RemotePlugin::DebugMessage: creating editor
RemotePlugin::DebugMessage: editor successfully created
RemotePlugin::DebugMessage: plugin name: Synth1 VSTi
Unknown embed method "none"
RemotePlugin::DebugMessage: initialization done
Process error:  QProcess::Crashed
Remote plugin crashed
remote plugin died! invalidating now.

[PhysSong]

Do 64-bit VSTs crash on both 64-bit MSVC and 64-bit MinGW builds?

[tresf]

Do 64-bit VSTs crash on both 64-bit MSVC and 64-bit MinGW builds?

If my memory serves correctly, yes

[Fastigium]

Is someone already working on this? If not, I may poke around a bit tomorrow

(also: hi, been a while, hasn't it? I'm in a similar situation as I was in 2016 and hoping that working on LMMS will do me good again. Not sure how much I'll be able to accomplish, but I'm willing to try 😌 )

[tresf]

Is someone already working on this? If not, I may poke around a bit tomorrow

(also: hi, been a while, hasn't it? I'm in a similar situation as I was in 2016 and hoping that working on LMMS will do me good again. Not sure how much I'll be able to accomplish, but I'm willing to try 😌 )

Welcome back! No one's jumped on this yet! Help is always welcome!

[Fastigium]

Currently poking around this issue. Can reproduce it at least, so that's a good start. I've assigned myself and plan to chip at it daily for a while. I think I'll use Discord for small progress updates and post any larger findings here 🙂

[tresf]

@Fastigium thanks again for volunteering.

The last time I encountered such and odd bug with VST host, it was fixed simply by providing -O0 as a build flag. Oddly, this flag was removed from the codebase at some point but that was going to be my first blind attempt, had I gotten around to working on it.

• #1757

A lot has changed in the codebase since, particularly the addition of the MSVC compiler, so I find it to be particularly unlikely this will be the fix, but wanted to provide my thoughts here just in case.

[tresf]

Posting an update here on behalf of @Fastigium / Discord:

• In mingw64 builds, there's a regression that causes certain 64-bit VSTs (e.g. Red Skull (effect), Synth1 (instrument)) to crash on Windows starting with commit https://github.com/LMMS/lmms/commit/36c1deae428f0dee95ec9ca190d6d52365abd713
• msvc builds seem to behave identically to post-regression mingw builds for some users and crash many more VSTs for others. The data we have so far suggests that differences between Windows 10 and 11 may play a role here, but more data and investigation is in order. The regression commit mentioned above does not change the behavior of msvc builds

[tresf]

Since this bug affects Linux (Wine) as well, I'd like to point out that an upstream conversation with WineHQ is occuring about how best to handle this there. In short, ASLR/DYNAMICBASE seems to be the focus and can be disabled via mingw and msvc (See #7976) but seems to be missing from our winegcc/wineg++ toolchain (See #7987).

[messmerd]

Fixed in #7976 and #7987.