Open KottV opened 2 years ago
Hi KottV, thanks for reporting the crash!
I had forgotten about LV2's different strategy for handling different bus layouts. I'm not sure if it would make sense to revert the LV2 build to use the stereo-only behaviour, or if there's a different approach that might work? I'll do some research.
Hi!
I think there is sort of options.
Confirmed on Reaper in Arch.
Hi!
I think there is sort of options.
- As you may know JUCE 7 has LV2 support, I built AnalogTape with it and LV2 works here, except Ardour, but it was fixed recently in Ardour upstream branch. Though changing JUCE may not be a perfect for bugfix release.
- Just disable multichannel for LV2, could be a most compromise solution.
- Fix LV2 with JUCE6 LV2 fork. Most challenging and JUCE6 LV2 fork development seems to be stopped in the future.
Hmm... I feel like option 1 is the "right" option, but I agree that it might not make sense to make a tagged release for a fix that only affects the LV2 build. Would it be okay if we just do that change, merge that change to master
, and then tell folks building or packaging for LV2 to just build from master
rather than using a tagged release? Alternatively, we could make a temporary lv2
branch?
Btw, if you'd like to make a PR for your JUCE 7 update, please do!
Btw, if you'd like to make a PR for your JUCE 7 update, please do!
ok, it's easy but I'll do some tests prior PR
Also crashes Reaper x64 on Windows 10 for me with the VST3 x64 version.
2.10.0 works fine.
Also crashes Reaper x64 on Windows 10 for me with the VST3 x64 version.
2.10.0 works fine.
@kiwijam, this thread is specifically trying to solve the issue with the crashing LV2 build. Could you please file a separate bug report for the VST3 crashing behaviour on Reaper? I use the plugin in Reaper x64 on Windows 10 pretty reguarly, so I'd definitely like to get to the bottom of that. Thanks!
Hm, my JUCE 7 LV2 build now crashes the Ardour (only). Need more time to find the bug.
Not if that's the exact same as the OP
With 2.11.1 LV2 in Ardour and JALV:
I build it with these CXXFLAGS
: -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer
(the -D_GLIBCXX_ASSERTIONS
is probably the trigger).
I get this crash:
Thread 29 "jalv" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffd77fe640 (LWP 1436586)]
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
Downloading 0.00 MB source file /usr/src/debug/glibc-2.35-20.fc36.x86_64/nptl/pthread_kill.c
44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0;
(gdb) where
#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007ffff7c8ec73 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007ffff7c3e986 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3 0x00007ffff7c287f4 in __GI_abort () at abort.c:79
#4 0x00007ffff62d7da0 in std::__glibcxx_assert_fail (file=file@entry=0x7ffff69a3480 "/usr/include/c++/12/bits/stl_vector.h", line=line@entry=1123,
function=function@entry=0x7ffff69a6d28 "std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = juce::SmoothedValue<float, juce::ValueSmoothingTypes::Multiplicative>; _Alloc = std::allocator<juce::Smo"..., condition=condition@entry=0x7ffff69a6360 "__n < this->size()")
at ../../../../../libstdc++-v3/src/c++11/debug.cc:60
#5 0x00007ffff674266f in std::vector<juce::SmoothedValue<float, juce::ValueSmoothingTypes::Multiplicative>, std::allocator<juce::SmoothedValue<float, juce::ValueSmoothingTypes::Multiplicative> > >::operator[] (this=<optimized out>, __n=<optimized out>) at /usr/include/c++/12/bits/stl_vector.h:1123
#6 ToneStage::processBlock (this=0x55555588e158, buffer=...)
at /var/home/hub/source/flathub/org.freedesktop.LinuxAudio.Plugins.ChowTapeModel/ChowTapeModel.git/Plugin/Source/Processors/Hysteresis/ToneControl.cpp:60
#7 0x00007ffff66dc558 in ToneControl::processBlockIn (buffer=..., this=0x55555588e158)
at /var/home/hub/source/flathub/org.freedesktop.LinuxAudio.Plugins.ChowTapeModel/ChowTapeModel.git/Plugin/Source/Processors/Hysteresis/ToneControl.cpp:117
#8 ChowtapeModelAudioProcessor::processAudioBlock (this=<optimized out>, buffer=...)
at /var/home/hub/source/flathub/org.freedesktop.LinuxAudio.Plugins.ChowTapeModel/ChowTapeModel.git/Plugin/Source/PluginProcessor.cpp:168
#9 0x00007ffff67139c1 in chowdsp::PluginBase<ChowtapeModelAudioProcessor>::processBlock (this=<optimized out>, buffer=...)
at /var/home/hub/source/flathub/org.freedesktop.LinuxAudio.Plugins.ChowTapeModel/ChowTapeModel.git/Plugin/modules/chowdsp_utils/modules/plugin/chowdsp_plugin_base/PluginBase/chowdsp_PluginBase.h:199
#10 0x00007ffff66c29bb in JuceLv2Wrapper::lv2Run (this=0x555555807ea0, sampleCount=1024) at /usr/include/c++/12/bits/unique_ptr.h:191
#11 0x000055555555cc2f in lilv_instance_run (sample_count=1024, instance=<optimized out>) at /usr/include/lilv-0/lilv/lilv.h:1948
#12 jalv_run (nframes=<optimized out>, jalv=0x7fffffffd850) at ../src/jalv.c:610
#13 jack_process_cb (nframes=<optimized out>, data=0x7fffffffd850) at ../src/jack.c:203
#14 0x00007ffff7f308b6 in on_rtsocket_condition (data=0x555555808470, fd=<optimized out>, mask=<optimized out>) at ../pipewire-jack/src/pipewire-jack.c:1546
#15 0x00007ffff7b14347 in loop_iterate (object=<optimized out>, timeout=<optimized out>) at ../spa/plugins/support/loop.c:452
#16 0x00007ffff7b707c7 in do_loop (user_data=0x555555812e60) at ../src/pipewire/data-loop.c:81
#17 0x00007ffff7c8cded in start_thread (arg=<optimized out>) at pthread_create.c:442
#18 0x00007ffff7d12370 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
It actually catches an out of bound access to a vector.
void ToneStage::processBlock (AudioBuffer<float>& buffer)
{
const auto numChannels = buffer.getNumChannels();
const auto numSamples = buffer.getNumSamples();
for (size_t ch = 0; ch < (size_t) numChannels; ++ch)
{
auto* data = buffer.getWritePointer ((int) ch);
if (lowGain[ch].isSmoothing() || highGain[ch].isSmoothing() || tFreq[ch].isSmoothing())
{
Here, numChannels
is 36.
While lowGain.size()
is 2.
So the assert triggers.
it's a standard stereo channel, so numChannel should be 2
LV2 does not support dynamic changes of channel configuration; all input and output channels must be declared in the plugin's manifest (the .ttl
file). For version 2.11.1, the generated TTL contains 36 input and 36 output audio channels, as this is the largest configuration the plugin supports. Even if that configuration did not crash, that's probably not what anyone wants: the host will treat the plugin as having 36 inputs and 36 outputs, driving the channel configuration crazy.
The only way around this I know is to build separate mono, stereo, ... plugins. For many LV2 plugins there are separate mono/stereo versions.
I've build an LV2 plugin from v2.11.1
tag with a small change estricting supported bus configurations to AudioChannelSet::stereo()
in ChowtapeModelAudioProcessor::isBusesLayoutSupported
. The generated .ttl
for plugin built this way contains two input and two output audio channels, and the plugin works in Ardour 7.2.
Describe the bug 2.11.0 LV2 plugin crashes on load
To Reproduce
Expected behavior It shouldn't
Screenshots If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
Additional context It seems it crashes on creating audio busses: