- edited description
-double and -quad breaks certain plugins
When I do:
git clone https://github.com/magnetophon/faustCompressors.git
cd faustCompressors
faust2lv2 -gui RMS_FBcompressor_peak_limiter.dsp
I get a working plugin.
When I do:
faust2lv2 -double -gui RMS_FBcompressor_peak_limiter.dsp
I get a plugin that segfaults both jalv.gtk and ardour.
-quad
also breaks it.
Another plugin from the same repo does work:
faust2lv2 -double -gui FFcompressor.dsp
Comments (20)
-
reporter -
repo owner Well, if you add
-double
then the plugin assumes that all sample buffers passed between host and plugin will be double. If the host passes single precision float buffers instead (which I assume both Ardour and Jalv do) then the plugin will try to access nonexistent memory.So don't do that. :) It's the responsibility of the plugin programmer to get that right. faust or faust2lv2 can't possibly know what your host's native sample format is.
-
repo owner Another plugin from the same repo does work:
Then that's just an accident. But the plugin will most likely write into memory that it's not supposed to mess with anyway.
-
repo owner Hmm, no, scratch that.
faust -double
only seems to have an effect on the sample data used internally, the callback interface usesFAUSTFLOAT
which isfloat
in either case by default. Will have to take a closer look with a fresh mind in the morning. -
reporter Great. Thanks for the quick response. I hope you'll find the issue tomorrow! :)
-
repo owner I didn't say which morning. ;-) The problem is that the gui part of the architecture was done by a student for his master thesis, so I don't know that part of the code as well as my own.
That said, I suspect that it's a float/double mismatch in the gui part somewhere, so I'd suggest that for the time being, as a work-around you just build the non-gui version and go with the generic host-provided GUI instead.
-
repo owner -
assigned issue to
-
assigned issue to
-
reporter OK, thanks. fwiw: Most of my plugins are fine when compiled with -double.
-
repo owner Do you have a gdb backtrace or a core dump of one of the plugins that crashes? That would be helpful.
-
repo owner Cool, thanks. Is that bt from the RMS_FBcompressor_peak_limiter.dsp plugin that you mentioned?
-
reporter Yes. It says so right in the second line. ;)
-
repo owner Well, it's been a hard week.
-
reporter No worries. I'm sure you remember my f***ups in these areas.
I just discovered another interesting thing: When I compile
drumDuxpander.dsp
from the same repo without-double
, it runs, but it seems to be in bypass.That is: I can not get it to do any gain reduction.
-
repo owner Does that also happen when you compile without
-gui
? -
reporter Yes, without
-gui
it's the same. As a matter of fact,faust2jaqt
has the problem too, so it's an upstream faust issue, and I'll report it there.Note: I'm talking just about the
drumDuxpander
bypass issue here. The original issue still stands. -
reporter -
reporter I tried to come up with a minimal example for the original issue, but I got stuck.
This is what I found out so far, using faust-2.5.21:
- It is only triggered with
faust2lv2
using-gui
plus-double
or-quad
. - It needs a certain amount of
declare
statements to trigger. - it only triggers with high amounts of elements: 2^16 to 2^18. depending on the surrounding code
- just the high number (even 2^25) for that parameter will not trigger it, it needs the above conditions.
- it also only triggers with
smooth(0.99)
inline. Oddly enough, when you use the function content instead of the call, it works.
first
wget https://github.com/magnetophon/faustCompressors/raw/master/slidingReduce.lib
declare name "test"; // comment out one of these lines and it runs: declare foo "i"; declare bar "j"; // this third declare is only needed to trigger a bug with: // _<:par(i,4,_+i:slidingSumN(s,2:pow(16)): si.smooth(0.99)):>_ // declare another "k"; import("slidingReduce.lib"); process= // runs: // slidingSumN(s,2:pow(18)) : (_*(1.0 - 0.99) : + ~ *(0.99)) // doesn't, even though it's equivalent: slidingSumN(s,2:pow(18)) : si.smooth(0.99) // runs, even though there are way more elements // slidingSumN(s,2:pow(25)) //runs: // _<:par(i,2,_+i:slidingSumN(s,2:pow(17))):>_ : si.smooth(0.99) // doesn't // _<:par(i,2,_+i:slidingSumN(s,2:pow(17)): si.smooth(0.99)):>_ // runs: // _<:par(i,2,_+i:slidingSumN(s,2:pow(16)): si.smooth(0.99)):>_ // doesn't run, but only if there's another declare // _<:par(i,4,_+i:slidingSumN(s,2:pow(16)): si.smooth(0.99)):>_ with { // runs: // s = int(1); // doesn't: s = int(param); param = hslider("param",0.1, 0.0001, 1, 0.001); };
I don't know how to troubleshoot further.
- It is only triggered with
-
repo owner Thanks. I can confirm that it crashes with jalv.qt when building with
faust2lv2 -qt4 -double
or-quad
:#0 0x00007fffd115344f in LV2PluginUI::init_meta() [clone .part.468] () at /home/ag/.lv2/test.lv2/testui.so #1 0x00007fffd115641c in instantiate(_LV2UI_Descriptor const*, char const*, char const*, void (*)(void*, unsigned int, unsigned int, unsigned int, void const*), void*, void**, _LV2_Feature const* const*) () at /home/ag/.lv2/test.lv2/testui.so #2 0x00007ffff7597400 in suil_instance_new () at /usr/lib/libsuil-0.so.0 #3 0x00000000004091ac in () #4 0x000000000040ab7c in () #5 0x00000000004055e9 in () #6 0x00007ffff5852f4a in __libc_start_main () at /usr/lib/libc.so.6 #7 0x0000000000405b39 in ()
It does crash there in
init_meta()
, so there's a relationship with meta data being used, but that's just a symptom I'd guess. The real culprit is probably some bad memory access earlier in the Qt GUI code.Anyway, thanks for the great example, that's something that I can go about investigating now. :)
-
reporter Any news on this?
-
repo owner Sorry, way too much more important stuff on my TODO list right now.
- Log in to comment