Live - why do you keep dying

I’m having the most horrendous time trying to track down a problem in one of my plugins. A very small number of users ( < 2 ) have reported that Live crashes when scanning the plugin in Windows. Of course I tried all the Windows machines I have access to and I couldn’t recreate the issue. Then I started creating Windows VMs to recreate the issue. Still no joy. Finally I was able to create the issue with a Windows Home VM and Ableton Live Lite 10. And yup, every time the plugin is scanned, it takes down Live.

  • No other hosts show any problem, Renoise, FL Studio, Reaper, Waveform, Cubase, etc. All run fine.
  • All tests pass PluginVal on the strictest level - that’s right level 10!!!
  • I’ve removed all but a handful warnings, in my release build. The ones left are mostly in the JUCE code base
  • I’ve ran the code through cppcheck just to make sure there is nothing suspect in the release build and have addressed most of the issues it presented me
  • I’m using JUCE 5.4.7, but I also tried with the very latest master branch and it still brings live down.
  • I’ve installed the latest C++ redistributables in the VM image.

I’m at a loss. The Live crash dmp doesn’t give me anything to go with. Does anyone have any suggestions for how I might go about debugging this. I’m afraid that as soon as I install dev tools in the VM it will start working fine again. Are there some compilation flags / Projucer settings I can try? I’m really clutching at straws.

1 Like

Just a shot into the dark. We also received crash reports of a LIVE 10 user with the VST2 version on OS X. There is a very small chance that the problem exists on windows and OS X.

It crashes here:

juce::AudioProcessor::applyBusLayouts(juce::AudioProcessor::BusesLayout…

Maybe change some things with the bus helps…, but i didn’t have a closer look at it so far.

It seems there is no thread sanitiser on windows out of the box, but maybe there are similar tools around?

Google for static analyzer concurrency c++ windows…

Good luck

Few notes:

  • The title is quite extreme :slight_smile: . all hosts got quirks and sometimes you waste few days discovering they misbehave.

  • Visual Studio got one huge advantage over Xcode. you can remote debug easily VS IDE itself. so if you have a nice enough user that would agree to install remote debug tools you might be able to catch this better. (lldb remote is possible but has no decent integration to Xcode).

  • It seems there is no thread sanitiser on windows out of the box, but maybe there are similar tools around?

Well! since this is October 2020 finally VS got in shape. there’s tsan/asan integrated in latest VS2019 and finally it even able to do 64bit (oddly it was 32bit at first).

4 Likes

Thanks everyone.

Clearly tongue in cheek, I couldn’t resist!

Thanks, this might be an option!

I’m just looking into this now.

I have received no reports of any issues on OSX. So I’m going to assume that everything works fine there.

Thanks again everyone. I will not rest until I get to the bottom of this! Actually, I’m probably going to leave it for now and take a new shot at it tomorrow :laughing:

1 Like

The remote debugging option looks promising. I just have to jump through some hoops to get it working with my Windows VM. Thanks for this.

p.s. I changed the title, I don’t really want Live dead :wink:

3 Likes

I managed to get a remote debugging setup working with a VM running on the same machine. I’m through the looking glass now, and I see that there is an issue with a 3rd party lib I’m using :roll_eyes:

Why do I always assume I’m the problem :man_shrugging:

But yeah, this remote debugging thing is really great. Thanks for pointing me towards it @ttg

2 Likes

What library out of interest?

Csound.

Thankfully it’s open source and I’ve already found the problem :wink:

2 Likes