Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ZamDelay VST 3.12 crashes in Radium, not accepted by JUCE host, crashes in Renoise, and shows assertion messages in Ardour. #80

Open
kmatheussen opened this issue May 27, 2020 · 34 comments
Open

ZamDelay VST 3.12 crashes in Radium, not accepted by JUCE host, crashes in Renoise, and shows assertion messages in Ardour. #80

kmatheussen opened this issue May 27, 2020 · 34 comments

Comments

@kmatheussen
Copy link

kmatheussen commented May 27, 2020 •
edited

Hi, the plugin scanner for Radium reports that this plugin crashes:

kjetil@localhost radium]$ bin/radium_plugin_scanner L2hvbWUva2pldGlsL3phbS1wbHVnaW5zL2Jpbi9aYW1EZWxheS12c3Quc28= L3RtcC9kZXNjci50eHQ=
JUCE v5.4.7
Launched: -/home/kjetil/zam-plugins/bin/ZamDelay-vst.so- -/tmp/descr.txt-
JUCE Assertion failure in juce_MessageListener.cpp:38
Attempting to load VST: /home/kjetil/zam-plugins/bin/ZamDelay-vst.so
Creating VST instance: ZamDelay-vst
Initialising VST: ZamDelay-vst (3.12.0.0)
assertion failure: "obj->plugin == nullptr" in file ../../dpf/distrho/src/DistrhoPluginVST.cpp, line 1251
assertion failure: "obj->plugin == nullptr" in file ../../dpf/distrho/src/DistrhoPluginVST.cpp, line 1251
Segmentation fault (core dumped)

To compile i just wrote "make", but "make" crashed too (!):

Generate ttl data for './ZamDelay_dsp.so', basename: 'ZamDelay_dsp'
Writing manifest.ttl... done!
Writing ZamDelay_dsp.ttl.../home/kjetil/zam-plugins/dpf/utils/generate-ttl.sh: line 28: 28913 Segmentation fault      (core dumped) "$GEN" "./$FILE"
make: *** [Makefile:23: gen] Error 139
[kjetil@localhost zam-plugins]$

Don't know if this crash is related to the VST plugin crashing...
@kmatheussen
Copy link
Author

Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff60ab0dc in free () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff60ab0dc in free () from /lib64/libc.so.6
#1  0x00007ffff547e33c in DISTRHO::String::~String (this=0xbbeae0, __in_chrg=<optimized out>) at ../../dpf/distrho/src/../extra/String.hpp:223
#2  0x00007ffff547e9de in DISTRHO::Parameter::~Parameter (this=0xbbeaa8, __in_chrg=<optimized out>) at ../../dpf/distrho/src/../DistrhoPlugin.hpp:375
#3  0x00007ffff547eaef in DISTRHO::Plugin::PrivateData::~PrivateData (this=0xbbe5a0, __in_chrg=<optimized out>) at ../../dpf/distrho/src/DistrhoPluginInternal.hpp:137
#4  0x00007ffff547fbb3 in DISTRHO::Plugin::~Plugin (this=0x7ffff32c3010, __in_chrg=<optimized out>) at ../../dpf/distrho/src/DistrhoPlugin.cpp:75
#5  0x00007ffff547abe2 in DISTRHO::ZamDelayPlugin::~ZamDelayPlugin (this=0x7ffff32c3010, __in_chrg=<optimized out>) at ZamDelayPlugin.hpp:31
#6  0x00007ffff547abfe in DISTRHO::ZamDelayPlugin::~ZamDelayPlugin (this=0x7ffff32c3010, __in_chrg=<optimized out>) at ZamDelayPlugin.hpp:31
#7  0x00007ffff547ee03 in DISTRHO::PluginExporter::~PluginExporter (this=0xbbe4f8, __in_chrg=<optimized out>) at ../../dpf/distrho/src/DistrhoPluginInternal.hpp:222
#8  0x00007ffff5481294 in DISTRHO::PluginVst::~PluginVst (this=0xbbe4e0, __in_chrg=<optimized out>) at ../../dpf/distrho/src/DistrhoPluginVST.cpp:441
#9  0x00007ffff54812bc in DISTRHO::PluginVst::~PluginVst (this=0xbbe4e0, __in_chrg=<optimized out>) at ../../dpf/distrho/src/DistrhoPluginVST.cpp:451
#10 0x00007ffff548280e in DISTRHO::vst_dispatcherCallback (effect=0xbbe430, opcode=1, index=0, value=0, ptr=0x0, opt=0) at ../../dpf/distrho/src/DistrhoPluginVST.cpp:1274
#11 0x0000000000434185 in juce::ModuleHandle::closeEffect (this=0xbb84d0, eff=0xbbe430) at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:711
#12 0x00000000004357a1 in juce::VSTPluginInstance::cleanup (this=0xbbefa0) at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:1154
#13 0x00000000004354d0 in juce::VSTPluginInstance::~VSTPluginInstance (this=0xbbefa0, __in_chrg=<optimized out>)
    at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:1129
#14 0x00000000004356da in juce::VSTPluginInstance::~VSTPluginInstance (this=0xbbefa0, __in_chrg=<optimized out>)
    at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:1138
#15 0x00000000004575f4 in std::default_delete<juce::VSTPluginInstance>::operator() (this=0x7fffffffd8a8, __ptr=0xbbefa0) at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/unique_ptr.h:84
#16 0x000000000044aa62 in std::unique_ptr<juce::VSTPluginInstance, std::default_delete<juce::VSTPluginInstance> >::~unique_ptr (this=0x7fffffffd8a8, __in_chrg=<optimized out>)
    at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/unique_ptr.h:360
#17 0x0000000000418d14 in juce::VSTPluginFormat::findAllTypesForFile (this=0x7fffffffd960, results=..., fileOrIdentifier=...)
    at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:3569
#18 0x00000000004099a5 in add_descriptions_from_plugin_file (descriptions=..., description_filename=...) at ../../../audio/Juce_plugin_scanner.cpp:68
#19 0x0000000000409a2e in write_container_descriptions_to_cache_on_disk (container_filename=..., description_filename=...) at ../../../audio/Juce_plugin_scanner.cpp:85
#20 0x000000000040a281 in main (argc=3, argv=0x7fffffffdce8) at ../../../audio/Juce_plugin_scanner.cpp:230

@kmatheussen
Copy link
Author

If I comment out the call to 'std:free' for the above crash, ZamDelay is accepted by the scanner. However, when I try to load the plugin into Radium, I get this crash:

(gdb) bt
#0  0x00007fffeceda36a in strlen () from /lib64/libc.so.6
#1  0x00007ffff725016d in __interceptor_strlen (s=0x0) at ../../.././libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:368
#2  0x00007fff6365b742 in DISTRHO::strncpy (dst=0x7fffdc4fd8b0 "", src=0x0, size=8) at ../../dpf/distrho/src/DistrhoPluginVST.cpp:76
#3  0x00007fff6365d87c in DISTRHO::vst_dispatcherCallback (effect=0x60c00009ee00, opcode=6, index=0, value=0, ptr=0x7fffdc4fd8b0, opt=0) at ../../dpf/distrho/src/DistrhoPluginVST.cpp:1294
#4  0x0000000004371042 in juce::VSTPluginInstance::dispatch (this=0x61b00003f780, opcode=6, index=0, value=0, ptr=0x7fffdc4fd8b0, opt=0)
    at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:1753
#5  0x0000000004371d23 in juce::VSTPluginInstance::getTextForOpcode (this=0x61b00003f780, index=0, opcode=opcode@entry=6)
    at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:2533
#6  0x0000000004371dd5 in juce::VSTPluginInstance::VSTParameter::getLabel (this=<optimized out>) at ../../JuceLibraryCode/modules/juce_audio_processors/processors/juce_AudioProcessorParameter.h:202
#7  0x00000000042b99d4 in operator() (__closure=0x604000a0dad0) at ../../../audio/Juce_plugins.cpp:1676
#8  std::__invoke_impl<void, get_display_value_string(SoundPlugin*, int, char*, int)::<lambda()>&> (__f=...) at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/invoke.h:60
#9  std::__invoke_r<void, get_display_value_string(SoundPlugin*, int, char*, int)::<lambda()>&> (__fn=...) at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/invoke.h:153
#10 std::_Function_handler<void(), get_display_value_string(SoundPlugin*, int, char*, int)::<lambda()> >::_M_invoke(const std::_Any_data &) (__functor=...)
    at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/std_function.h:291
#11 0x00000000042b6bbe in std::function<void ()>::operator()() const (this=<optimized out>) at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/std_function.h:248
#12 (anonymous namespace)::run_callback (arg=<optimized out>) at ../../../audio/Juce_plugins.cpp:177
#13 0x00000000044390a1 in juce::AsyncFunctionCallback::messageCallback (this=0x60d0003811e0) at ../../JuceLibraryCode/modules/juce_events/messages/juce_MessageManager.cpp:153
#14 0x0000000004439e4a in juce::InternalMessageQueue::InternalMessageQueue()::{lambda(int)#1}::operator()(int) const (fd=6, __closure=0x61200000ff48)
    at ../../JuceLibraryCode/modules/juce_events/native/juce_linux_Messaging.cpp:43
#15 std::__invoke_impl<void, juce::InternalMessageQueue::InternalMessageQueue()::{lambda(int)#1}&, int>(std::__invoke_other, juce::InternalMessageQueue::InternalMessageQueue()::{lambda(int)#1}&, int&&) (
    __f=...) at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/invoke.h:60
#16 std::__invoke_r<void, juce::InternalMessageQueue::InternalMessageQueue()::{lambda(int)#1}&, int>(std::__is_invocable&&, (juce::InternalMessageQueue::InternalMessageQueue()::{lambda(int)#1}&)...) (__fn=...)
    at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/invoke.h:153
#17 std::_Function_handler<void (int), juce::InternalMessageQueue::InternalMessageQueue()::{lambda(int)#1}>::_M_invoke(std::_Any_data const&, int&&) (__functor=..., __args#0=<optimized out>)
    at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/std_function.h:291
#18 0x0000000004437acf in std::function<void (int)>::operator()(int) const (__args#0=6, this=0x61200000ff48) at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/std_function.h:248
#19 juce::InternalRunLoop::dispatchPendingEvents (this=0x608000004020) at ../../JuceLibraryCode/modules/juce_events/native/juce_linux_Messaging.cpp:169
#20 juce::MessageManager::dispatchNextMessageOnSystemQueue (returnIfNoPendingMessages=<optimized out>) at ../../JuceLibraryCode/modules/juce_events/native/juce_linux_Messaging.cpp:260
#21 juce::MessageManager::runDispatchLoop (this=<optimized out>) at ../../JuceLibraryCode/modules/juce_events/messages/juce_MessageManager.cpp:128
#22 0x00000000042b71db in (anonymous namespace)::JuceThread::run (this=0x613000000200) at ../../../audio/Juce_plugins.cpp:1258
#23 0x00000000043f57ed in juce::Thread::threadEntryPoint (this=0x613000000200) at ../../JuceLibraryCode/modules/juce_core/threads/juce_Thread.cpp:96
#24 0x00000000043f59f9 in juce::juce_threadEntryPoint (userData=<optimized out>) at ../../JuceLibraryCode/modules/juce_core/threads/juce_Thread.cpp:118
#25 juce::threadEntryProc (userData=<optimized out>) at ../../JuceLibraryCode/modules/juce_core/native/juce_posix_SharedCode.h:834
#26 0x00007ffff2af2ee5 in start_thread () from /lib64/libpthread.so.0
#27 0x00007fffecf48d1d in clone () from /lib64/libc.so.6

@kmatheussen kmatheussen changed the title ZamDelay VST 3.12.0.0 crashes when loaded into Radium ZamDelay VST 3.12.0.0 crashes May 29, 2020
@kmatheussen
Copy link
Author

See also discussion here: https://users.notam02.no/~kjetism/radium/forum/viewtopic.php?f=7&t=279

@zamaudio
Copy link
Owner

@kmatheussen do you also get crashes with the rest of zam-plugins? and what about other DPF-based plugins? That would be an interesting test. I'm sorry but I don't know anything about Radium.

@zamaudio zamaudio changed the title ZamDelay VST 3.12.0.0 crashes ZamDelay VST 3.12.0.0 crashes in Radium May 30, 2020
@zamaudio zamaudio changed the title ZamDelay VST 3.12.0.0 crashes in Radium ZamDelay VST 3.12 crashes in Radium May 30, 2020
@zamaudio
Copy link
Owner

zamaudio commented May 30, 2020 •
edited

@kmatheussen from that backtrace, it looks like the host, Radium, is calling the deconstructor twice, so tries to double free the plugin. ~VSTPluginInstance() see # 13 and # 14 of the first backtrace, (somehow # 5 and # 6 are both called which are the same destructor for my plugin).

@zamaudio
Copy link
Owner

zamaudio commented May 30, 2020 •
edited

To compile i just wrote "make", but "make" crashed too (!):

It looks like the ttl generation failed for you, can you please post your git hash that you were on when you ran that command?

@kmatheussen
Copy link
Author

do you also get crashes with the rest of zam-plugins?

No, just this one. Tried all the others.

That would be an interesting test. I'm sorry but I don't know anything about Radium.

Radium uses JUCE to host VST plugins. (Radium is probably also the oldest DAW on Linux being active developed, just so you know. :-)). Reportedly, there is currently a bug in JUCE where effOpen is called twice during init, but as far as I can see all plugins seems to manage this.

from that backtrace, it looks like the host, Radium, is calling the deconstructor twice, so tries to double free the plugin. ~VSTPluginInstance() see # 13 and # 14 of the first backtrace, (somehow # 5 and # 6 are both called which are the same destructor for my plugin).

Yes, that's really strange. It's called from DISTHRO though. Maybe @falkTX understands what happening here? It looks like DISTRHO::PluginVst::fStateChunk points to another DISTHRO::PluginVst instance. Guess there is a memory corruption happening somewhere. Have you ran the plugin with ASAN?

To compile i just wrote "make", but "make" crashed too (!):

It looks like the ttl generation failed for you, can you please post your git hash that you were on when you ran that command?

852fb0d

@kmatheussen
Copy link
Author

Yes, that's really strange.

Oh, yes, you said, the same thing happens in frame 13 and 14 too. And that's in JUCE. This looks really strange. The destructor calls itself, with the same "this" value. And the exact same thing happens in a completely different (?) class inside DISTHRO as well. Weird.

@kmatheussen
Copy link
Author

Hmm, I think frame 13 and 14 may be legit. It's some weird JUCE code that schedules deletion of the vst instance to happen in the message thread, and then waits for it to finish before exiting the scheduler. This causes the destructor to be called twice.

@kmatheussen
Copy link
Author

This causes the destructor to be called twice.

No, that doesn't make sense. I guess the destructor is only called once, but the method name in the bactrace is incomplete. Frame 13 is actually called inside a "VSTDeleter" inner class inside the destructor. So I'm pretty sure there's nothing wrong with frame 13 and 14.

@zamaudio
Copy link
Owner

https://github.com/kmatheussen/radium/blob/cced67bbe92f53e38556b63c0e8c86f425a32d0f/pluginhost/JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp#L1129

Also when it hits line 1138, it calls the destructor again ?

@kmatheussen
Copy link
Author

Also when it hits line 1138, it calls the destructor again ?

Good point. I have no idea.

@kmatheussen
Copy link
Author

I tried to add a call to abort() in DISTRHO::PluginVst::~PluginVst, and the ZaMaximV2, to provoke bactrace on a plugin that apparently works fine, and both the same double calls to constructrs are there as well:

(gdb) bt
#0  0x00007ffff5494877 in raise () from /lib64/libc.so.6
#1  0x00007ffff5495f68 in abort () from /lib64/libc.so.6
#2  0x00007ffff1d92281 in DISTRHO::PluginVst::~PluginVst (this=0x60c000000280, __in_chrg=<optimized out>) at ../../dpf/distrho/src/DistrhoPluginVST.cpp:442
#3  0x00007ffff1d9229a in DISTRHO::PluginVst::~PluginVst (this=0x60c000000280, __in_chrg=<optimized out>) at ../../dpf/distrho/src/DistrhoPluginVST.cpp:452
#4  0x00007ffff1d9435d in DISTRHO::vst_dispatcherCallback (effect=0x60c0000001c0, opcode=1, index=0, value=0, ptr=0x0, opt=0) at ../../dpf/distrho/src/DistrhoPluginVST.cpp:1275
#5  0x0000000000434185 in juce::ModuleHandle::closeEffect (this=0x6070000001e0, eff=0x60c0000001c0)
    at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:711
#6  0x00000000004357a1 in juce::VSTPluginInstance::cleanup (this=0x61b000000080) at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:1154
#7  0x00000000004354d0 in juce::VSTPluginInstance::~VSTPluginInstance (this=0x61b000000080, __in_chrg=<optimized out>)
    at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:1129
#8  0x00000000004356da in juce::VSTPluginInstance::~VSTPluginInstance (this=0x61b000000080, __in_chrg=<optimized out>)
    at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:1138
#9  0x00000000004575f4 in std::default_delete<juce::VSTPluginInstance>::operator() (this=0x7fffffffd7a8, __ptr=0x61b000000080)
    at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/unique_ptr.h:84
#10 0x000000000044aa62 in std::unique_ptr<juce::VSTPluginInstance, std::default_delete<juce::VSTPluginInstance> >::~unique_ptr (this=0x7fffffffd7a8, __in_chrg=<optimized out>)
    at /home/kjetil/site_gcc1010/include/c++/10.1.0/bits/unique_ptr.h:360
#11 0x0000000000418d14 in juce::VSTPluginFormat::findAllTypesForFile (this=0x7fffffffd860, results=..., fileOrIdentifier=...)
    at ../../JuceLibraryCode/modules/juce_audio_processors/format_types/juce_VSTPluginFormat.cpp:3569
#12 0x00000000004099a5 in add_descriptions_from_plugin_file (descriptions=..., description_filename=...) at ../../../audio/Juce_plugin_scanner.cpp:68
#13 0x0000000000409a2e in write_container_descriptions_to_cache_on_disk (container_filename=..., description_filename=...) at ../../../audio/Juce_plugin_scanner.cpp:85
#14 0x000000000040a281 in main (argc=3, argv=0x7fffffffdbe8) at ../../../audio/Juce_plugin_scanner.cpp:230

I guess backtrace in frame 13 and 14 could be fine, and that it's just bug in the backtrace. This might be the case for frame 5 and 6 as well.

@kmatheussen
Copy link
Author

Anyway, I've marked ZamDelay as unstable in Radium, so the case is closed on my end. Please let me know if you need more help.

@kmatheussen
Copy link
Author

In the JUCE AudioPluginHost program, none of the ZAM vst plugins are accepted by the scanner (it's not the same scanner that is used in Radium).

In Renoise, the scanner accepted ZamDelay, but ZamDelay crashes when trying to load it.

In Ardour, ZamDelay is both accepted by the scanner, and it even runs, but I get these assertion messages when deleting the plugin:

assertion failure: "fBuffer != nullptr" in file ../../dpf/distrho/src/../extra/String.hpp, line 218
assertion failure: "fBuffer != nullptr" in file ../../dpf/distrho/src/../extra/String.hpp, line 218
assertion failure: "fBuffer != nullptr" in file ../../dpf/distrho/src/../extra/String.hpp, line 218
assertion failure: "fBuffer != nullptr" in file ../../dpf/distrho/src/../extra/String.hpp, line 218
assertion failure: "fBuffer != nullptr" in file ../../dpf/distrho/src/../extra/String.hpp, line 218
assertion failure: "fBuffer != nullptr" in file ../../dpf/distrho/src/../extra/String.hpp, line 218

@kmatheussen kmatheussen changed the title ZamDelay VST 3.12 crashes in Radium ZamDelay VST 3.12 crashes in Radium, not accepted JUCE hosts, crashes in Renoise, and misbehaves in Ardour. May 30, 2020
@kmatheussen kmatheussen changed the title ZamDelay VST 3.12 crashes in Radium, not accepted JUCE hosts, crashes in Renoise, and misbehaves in Ardour. ZamDelay VST 3.12 crashes in Radium, not accepted by JUCE host, crashes in Renoise, and misbehaves in Ardour. May 30, 2020
@kmatheussen kmatheussen changed the title ZamDelay VST 3.12 crashes in Radium, not accepted by JUCE host, crashes in Renoise, and misbehaves in Ardour. ZamDelay VST 3.12 crashes in Radium, not accepted by JUCE host, crashes in Renoise, and shows assertion messages in Ardour. May 30, 2020
@zamaudio
Copy link
Owner

I cannot reproduce any of these assertion messages on Ardour 5.12 or Ardour 6.0 (compiled from source) on Fedora 30. Can you point me to the official JUCE test program that I can use to reproduce?

@kmatheussen
Copy link
Author 

wget https://github.com/juce-framework/JUCE/archive/5.4.7.tar.gz
tar xvzf 5.4.7.tar.gz
cd JUCE-5.4.7/extras/AudioPluginHost/Builds/LinuxMakefile/
make -j3
./build/AudioPluginHost

@zamaudio
Copy link
Owner

Thanks

@zamaudio
Copy link
Owner

zamaudio commented May 30, 2020 •
edited

I got this against every VST plugin in zam-plugins

assertion failure: "obj->plugin == nullptr" in file ../../dpf/distrho/src/DistrhoPluginVST.cpp, line 1251

But they all load in AudioPluginHost and delete fine.

@zamaudio
Copy link
Owner

That assertion is expected, because some hosts call effOpen twice, some don't .

@zamaudio
Copy link
Owner

image

@zamaudio
Copy link
Owner

@kmatheussen not sure what is going wrong on your end... seems all good here.

@kmatheussen
Copy link
Author

kmatheussen commented May 30, 2020 via email

@kmatheussen
Copy link
Author

I'm compiling the plugins like this though:

[kjetil@localhost dpf]$ git diff
diff --git a/Makefile.base.mk b/Makefile.base.mk
index d8623e6..15c42f3 100644
--- a/Makefile.base.mk
+++ b/Makefile.base.mk
@@ -146,7 +146,7 @@ else
 # Common linker flags
 LINK_OPTS  = -fdata-sections -ffunction-sections -Wl,--gc-sections -Wl,-O1 -Wl,--as-needed
 ifneq ($(SKIP_STRIPPING),true)
-LINK_OPTS += -Wl,--strip-all
+#LINK_OPTS += -Wl,--strip-all
 endif
 endif
 
diff --git a/Makefile.plugins.mk b/Makefile.plugins.mk
index 7c1e554..79a8e7e 100644
--- a/Makefile.plugins.mk
+++ b/Makefile.plugins.mk
@@ -21,8 +21,8 @@ include $(DPF_PATH)/Makefile.base.mk
 TARGET_DIR = ../../bin
 BUILD_DIR = ../../build/$(NAME)
 
-BUILD_C_FLAGS   += -I.
-BUILD_CXX_FLAGS += -I. -I$(DPF_PATH)/distrho -I$(DPF_PATH)/dgl
+BUILD_C_FLAGS   += -I. -g -O0
+BUILD_CXX_FLAGS += -I. -I$(DPF_PATH)/distrho -I$(DPF_PATH)/dgl  -g -O0 #-fsanitize=address
 
 ifeq ($(HAVE_CAIRO),true)
 DGL_FLAGS += -DHAVE_CAIRO

@kmatheussen
Copy link
Author

And in your code, calling "effOpen" is taken care of by DISTHRO, so that shouldn't explain the assertions.

Above it should say: "calling "effOpen" twice".

@zamaudio
Copy link
Owner

With -fsanitize=address commented out as above, I don't get any difference.
When I compile with that flag and install libasan, however I get this:

==510==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
make: *** [Makefile:23: gen] Error 1

@zamaudio
Copy link
Owner

LD_PRELOAD=/usr/lib64/libasan.so.5 AudioPluginHost seems to run the plugins fine...

@kmatheussen
Copy link
Author

I was testing ardour/renoise/juce with the call to std::free commented out, as I wrote above. When I reinserted that line, the scanner in Ardour doesn't accept ZamDelay either. Could it be gcc version? I've tried both gcc 9 and gcc 10 now.

(-fsanitize=address doesn't change whether it crashes or not)

@zamaudio
Copy link
Owner 

$ gcc --version
gcc (GCC) 9.2.1 20190827 (Red Hat 9.2.1-1)

@zamaudio
Copy link
Owner

Could it be something simple like make install failing to install the version you think you just compiled due to the make failing, so you might not even have the correct plugins...

@kmatheussen
Copy link
Author

kmatheussen commented May 30, 2020 via email

@zamaudio
Copy link
Owner

@kmatheussen I updated the dpf submodule and fixed some uninitialised values. Please try again on master.

@zamaudio
Copy link
Owner

@kmatheussen can you please test again using zam-plugins 4.1, I think the bug should be gone.

@zamaudio
Copy link
Owner

@kmatheussen bump? Is the bug gone in 4.2?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@kmatheussen @zamaudio