28 Jul
2009
28 Jul
'09
9:42 a.m.
Hi,
I've been having problems with a few LADSPA plugins recently, so I've
written a little test app that loads all LADSPA plugins, connects the
ports and runs them for one cycle. (I've attached it here.)
I've run it on the plugin packages I have installed, using valgrind, and
the results are:
amb crashes
blop memory errors (patches sent for some of the errors)
calf memory errors in Flanger & MultiChorus plugins
caps memory errors in 3 plugins
cmt memory errors (patches sent)
fil OK
ladspa memory errors in Sine plugin (mismatched free/deletes)
mcp OK
rev OK
swh crashes
tap memory errors in 5 plugins
vco OK
Note that not all memory errors are bugs, but most are. (There's also a
chance that my test app is buggy, rather than the plugins.)
I've sent a few patches for cmt and blop, and will probably try to track
down the bugs in a few other packages. If others want to help
(especially the owners of the above packages!) that would be good.
Damon
28 Jul
28 Jul
10:06 a.m.
[Damon Chaplin]
I've been having problems with a few LADSPA plugins
recently, so I've
written a little test app that loads all LADSPA plugins, connects the
ports and runs them for one cycle. (I've attached it here.)
If you're using libraries like glib, it would be very kind of you to
supply a proper makefile or gcc invocation.
Thanks, Tim
10:10 a.m.
On Tue, Jul 28, 2009 at 02:06:33PM +0200, Tim Goetze wrote:
See line 5 in test-ladspa.c, it's probably all you need.
HTH
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
I've been
having problems with a few LADSPA plugins recently, so I've
written a little test app that loads all LADSPA plugins, connects the
ports and runs them for one cycle. (I've attached it here.)
If you're using
libraries like glib, it would be very kind of you to
supply a proper makefile or gcc invocation.
10:44 a.m.
[Damon Chaplin]
caps memory errors in 3 plugins
Thanks for pointing out the make invocation. I haven't used valgrind
before so my cluelessness may show again in what follows.
Anyway, when running this:
$ valgrind --tool=memcheck --leak-check=full --show-reachable=yes
./test-ladspa -p caps
I see this in the final summary:
==12021== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 33 from
2)
followed by a lot of what I suppose are call traces - are they?
If they are, they all involving the g_malloc interface. However, this
interface isn't used by caps at all.
I do see valgrind complaining about the use of an unitialised variable
in some of the plugins (not entirely impossible), but given the memory
leak summary I fail to see which plugins if any are affected.
Cheers, Tim
11:04 a.m.
On Tue, 2009-07-28 at 14:44 +0200, Tim Goetze wrote:
[Damon Chaplin]
Yes, using uninitialized values is the only problem in CAPS. Not as bad
as invalid writes or reads, but often still a bug:
Testing 2589: C* ToneStack - Tone stack emulation (caps.so)
==9992== Conditional jump or move depends on uninitialised value(s)
==9992== at 0x4129F9F: DSP::ToneStack::start_cycle(float**, int)
(ToneStack.h:103)
==9992== by 0x414432D: void ToneStack::one_cycle<&(store_func(float*,
int, float, float))>(int) (ToneStack.cc:80)
==9992== by 0x41443BF: ToneStack::run(int) (ToneStack.h:56)
caps memory errors in 3 plugins
Thanks for pointing out the make invocation. I haven't used valgrind
before so my cluelessness may show again in what follows.
Anyway, when running this:
$ valgrind --tool=memcheck --leak-check=full --show-reachable=yes
./test-ladspa -p caps
I see this in the final summary:
==12021== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 33 from
2)
followed by a lot of what I suppose are call traces - are they?
If they are, they all involving the g_malloc interface. However, this
interface isn't used by caps at all.
I do see valgrind complaining about the use of an unitialised variable
in some of the plugins (not entirely impossible), but given the memory
leak summary I fail to see which plugins if any are affected. From looking at the source I'd guess that the
"model" variable hasn't
been initialised (in dsp/ToneStack.h:103).
That may or not matter.
Though it's best to initialise it just to avoid the warnings.
Testing 2587: C* AmpV - Tube amp (caps.so)
==9992==
==9992== Conditional jump or move depends on uninitialised value(s)
==9992== at 0x412BA10: void AmpV::one_cycle<&(store_func(float*, int,
float, float)), 8>(int) (Amp.cc:349)
==9992== by 0x412BF13: AmpV::run(int) (Amp.h:317)
Maybe "tone" hasn't been initialised here (Amp.cc:349). Again that might
or might not matter.
Testing 2592: C* AmpVTS - Tube amp + Tone stack (caps.so)
==9992==
==9992== Conditional jump or move depends on uninitialised value(s)
==9992== at 0x4129F9F: DSP::ToneStack::start_cycle(float**, int)
(ToneStack.h:103)
==9992== by 0x412A622: void AmpVTS::one_cycle<&(store_func(float*,
int, float, float)), 8>(int) (Amp.cc:508)
==9992== by 0x412AA0F: AmpVTS::run(int) (Amp.h:366)
This seems to be the same as the first one.
Damon
11:40 a.m.
On Tue, 2009-07-28 at 14:02 +0100, Damon Chaplin wrote:
Testing 2589: C* ToneStack - Tone stack emulation
(caps.so)
==9992== Conditional jump or move depends on uninitialised value(s)
==9992== at 0x4129F9F: DSP::ToneStack::start_cycle(float**, int)
(ToneStack.h:103)
==9992== by 0x414432D: void ToneStack::one_cycle<&(store_func(float*,
int, float, float))>(int) (ToneStack.cc:80)
==9992== by 0x41443BF: ToneStack::run(int) (ToneStack.h:56)
I can confirm that initializing the "model" and "tone" variables does
fix the problems in CAPS. Though I'm not sure what they should be
initialized to, so I'll leave that to you!
Damon
From looking at the source I'd guess that the
"model" variable hasn't
been initialised (in dsp/ToneStack.h:103).
That may or not matter.
Though it's best to initialise it just to avoid the warnings.
Testing 2587: C* AmpV - Tube amp (caps.so)
==9992==
==9992== Conditional jump or move depends on uninitialised value(s)
==9992== at 0x412BA10: void AmpV::one_cycle<&(store_func(float*, int,
float, float)), 8>(int) (Amp.cc:349)
==9992== by 0x412BF13: AmpV::run(int) (Amp.h:317)
Maybe "tone" hasn't been initialised here (Amp.cc:349). Again that might
or might not matter.
12:13 p.m.
[Damon Chaplin]
I can confirm that initializing the "model"
and "tone" variables does
fix the problems in CAPS. Though I'm not sure what they should be
initialized to, so I'll leave that to you!
Thanks, that is rather helpful, and the issue may have been the cause
of real problems for some users.
There are a few other issues with caps and more recent g++ versions
that have been standing for too long now. Hope I can fix them in the
near future and release a fixed version.
Thanks again, Tim
12:34 p.m.
On Tue, 2009-07-28 at 12:39 +0100, Damon Chaplin wrote:
Hi,
I've been having problems with a few LADSPA plugins recently, so I've
written a little test app that loads all LADSPA plugins, connects the
ports and runs them for one cycle. (I've attached it here.)
I've run it on the plugin packages I have installed, using valgrind, and
the results are:
amb crashes
blop memory errors (patches sent for some of the errors)
calf memory errors in Flanger & MultiChorus plugins
caps memory errors in 3 plugins
cmt memory errors (patches sent)
fil OK
ladspa memory errors in Sine plugin (mismatched free/deletes)
mcp OK
rev OK
swh crashes
tap memory errors in 5 plugins
vco OK
I've just discovered that the crashes in the amb and swh packages are
caused by activating certain plugins before connecting the ports (which
I think is allowed by the LADSPA spec).
If the ports are connected first, the amb package is OK, but the swh
package has memory errors in 3 plugins.
Damon
1:56 p.m.
A quick update - fixes have been found for blop, caps & cmt, and the
ladspa Sine plugin problem is fixed in the latest version.
So the current status is:
amb OK
blop OK
calf memory errors in 2 plugins
caps OK
cmt OK
fil OK
ladspa OK
mcp OK
rev OK
swh memory errors in 3 plugins
tap memory errors in 5 plugins
vco OK
Damon
2:20 p.m.
On Tue, Jul 28, 2009 at 11:54 AM, Damon
Chaplin<damon(a)karuna.eclipse.co.uk> wrote:
A quick update - fixes have been found for blop, caps & cmt, and the
ladspa Sine plugin problem is fixed in the latest version.
Damon - fantastic work. really great stuff.
I'd just like to remind LADSPA (and LV2) plugin authors that use of
init() for module-level initialization has been deprecated for some
time. Plugins should mark the module-level init function with
__attribute__((constructor))
and the cleanup function formerly known as fini() as
__attribute__((destructor))
failure to do this pretty much guarantees plugin crashes on OS X and
other platforms that dropped init+fini support years ago.
--p
3:27 p.m.
On Tue, Jul 28, 2009 at 12:20:44PM -0400, Paul Davis wrote:
I'd just like to remind LADSPA (and LV2) plugin
authors that use of
init() for module-level initialization has been deprecated for some
time. Plugins should mark the module-level init function with
__attribute__((constructor))
and the cleanup function formerly known as fini() as
__attribute__((destructor))
failure to do this pretty much guarantees plugin crashes on OS X and
other platforms that dropped init+fini support years ago.
Or make sure you don't need any module level init().
At least for LADSPA, all required structs can easily
be defined statically. It's done like that in all my
plugins, none of them have an init() or equivalent.
Regarding calling activate() before the port pointers
are valid, it indeed seems like the LADSPA spec does
allow this. The AMB set will be modified accordingly.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
3:29 p.m.
[Paul Davis]
[...]
and the cleanup function formerly known as fini() as
__attribute__((destructor))
failure to do this pretty much guarantees plugin crashes on OS X and
other platforms that dropped init+fini support years ago.
I've added these attributes to _init() and _fini() sometime ago but
hopeful users of caps on OSX tell me linking the .so fails:
$ g++ -nostartfiles -O2 -ffast-math -funroll-loops -Wall -fPIC -DPIC
-shared -o caps.so [list of object files]
is answered with
ld: could not find entry point "start" (perhaps missing crt1.o)
Since you brought OSX up, I thought you might be able to tell me how
to resolve this?
Thanks, Tim
3:33 p.m.
On Tue, Jul 28, 2009 at 1:29 PM, Tim Goetze<tim(a)quitte.de> wrote:
[Paul Davis]
[...]
why are you using -nostartfiles? i know what your intent is, but its
unwise, i think.
and the cleanup function formerly known as fini()
as
__attribute__((destructor))
failure to do this pretty much guarantees plugin crashes on OS X and
other platforms that dropped init+fini support years ago.
I've added these attributes to _init() and _fini() sometime ago but
hopeful users of caps on OSX tell me linking the .so fails:
$ g++ -nostartfiles -O2 -ffast-math -funroll-loops -Wall -fPIC -DPIC
-shared -o caps.so [list of object files]
3:36 p.m.
[Paul Davis]
So will it link on OSX if I remove -nostartfiles?
Thanks, Tim
I've added
these attributes to _init() and _fini() sometime ago but
hopeful users of caps on OSX tell me linking the .so fails:
$ g++ -nostartfiles -O2 -ffast-math -funroll-loops -Wall -fPIC -DPIC
-shared -o caps.so [list of object files]
why are you using -nostartfiles? i know what your intent is, but its
unwise, i think.
3:38 p.m.
On Tue, Jul 28, 2009 at 1:36 PM, Tim Goetze<tim(a)quitte.de> wrote:
[Paul Davis]
So will it link on OSX if I remove -nostartfiles?
i'd suggest copying what swh's makefile does, which is something like this:
gcc -flat_namespace -undefined suppress -o .libs/ringmod_1188.so
-bundle .libs/ringmod_1188.o -lm -march=i686 -nostartfiles
clearly, i was talking out of my rear end about -nostartfiles
I've
added these attributes to _init() and _fini() sometime ago but
hopeful users of caps on OSX tell me linking the .so fails:
$ g++ -nostartfiles -O2 -ffast-math -funroll-loops -Wall -fPIC -DPIC
-shared -o caps.so [list of object files]
why are you using -nostartfiles? i know what your intent is, but its
unwise, i think.
4:04 p.m.
[Paul Davis]
Thanks, unfortunately I don't feel much wiser now. The
developer.apple.com copy of the OSX ld man page simply says
-bundle Produce a mach-o bundle that has file type MH_BUNDLE.
That isn't entirely helpful, and I don't want to blindly use ld
options I do not understand in the vague hope of it working out
alright.
So, sorry for the OSX users but they'll have to sort this out for
themselves.
Thanks again,
Tim
So will it
link on OSX if I remove -nostartfiles?
i'd suggest copying what swh's makefile does, which is something like this:
gcc -flat_namespace -undefined suppress -o .libs/ringmod_1188.so
-bundle .libs/ringmod_1188.o -lm -march=i686 -nostartfiles
clearly, i was talking out of my rear end about -nostartfiles 
29 Jul
29 Jul
12:35 p.m.
On 28 Jul 2009, at 19:04, Tim Goetze wrote:
[Paul Davis]
Thanks, unfortunately I don't feel much wiser now. The
developer.apple.com copy of the OSX ld man page simply says
-bundle Produce a mach-o bundle that has file type MH_BUNDLE.
It's a looong time ago I figured out those options, but if I remember
correctly it's required to let you build real .so files.
Because of the way the Mach kernel loads libraries, OSX libraries are
not generally Mach-O bundles (.so-s), which are what you need to
dynamically load objects. They're usually .dylib files - some other
sort or Mach object.
- Steve
So will
it link on OSX if I remove -nostartfiles?
i'd suggest copying what swh's makefile does, which is something
like this:
gcc -flat_namespace -undefined suppress -o .libs/ringmod_1188.so
-bundle .libs/ringmod_1188.o -lm -march=i686 -nostartfiles
clearly, i was talking out of my rear end about -nostartfiles 
28 Jul
28 Jul
3:08 p.m.
On Tue, 28 Jul 2009 16:54:23 +0100
Damon Chaplin <damon(a)karuna.eclipse.co.uk> wrote:
A quick update - fixes have been found for blop, caps & cmt, and the
ladspa Sine plugin problem is fixed in the latest version.
So the current status is:
amb OK
blop OK
calf memory errors in 2 plugins
caps OK
cmt OK
fil OK
ladspa OK
mcp OK
rev OK
swh memory errors in 3 plugins
tap memory errors in 5 plugins
vco OK
Damon
Hi Damon, thanks for your efforts.
How does your test compare to the ladspa demolition thing?
Are you sure you use the latest version of each? Ultimately the authors
should test themselves, but..
Some ladspas you missed:
acweight
autotalent
invada-studio-plugins
njl
vcf
Regards,
Philipp
7:35 p.m.
On Tue, 2009-07-28 at 19:08 +0200, hollunder(a)gmx.at wrote:
Hi Damon, thanks for your efforts.
How does your test compare to the ladspa demolition thing?
They're pretty similar actually. Unfortunately I hadn't heard of
demolition - maybe it should be mentioned on ladspa.org or go in the
SDK. It looks like it does a bit more testing of the plugin interface
than my simple test app.
I hope plugin maintainers run that on their plugins as well.
Are you sure you use the latest version of each?
Ultimately the authors
should test themselves, but..
I think I have the latest versions. I've built most of them from source
now to get the debugging info.
Some ladspas you missed:
acweight
autotalent
invada-studio-plugins
njl
vcf
acweight is OK
autotalent 0.1 is OK
invada 0.3.1 is OK
vcf is OK
njl 0.2.1 has an Invalid Write.
in "Continuous Risset Scales" instantiate:122
It looks like:
float *tbl = malloc(sizeof(float) * TBL_SIZE + 1);
should be:
float *tbl = malloc(sizeof(float) * (TBL_SIZE + 1));
Damon
30 Jul
30 Jul
7:36 a.m.
Hi,
I've tracked down all the issues spotted by my test app and emailed all
the maintainers. So hopefully they'll get fixed.
I've tried the demolition test app as well. The output isn't too clear
so I've summarised the major issues spotted:
Demolition Findings
CALF
34049 "Calf MultiChorus LADSPA" all input controls FLOAT MAX: Watchdog
timeout
33924 "Calf Phaser LADSPA" all input controls FLOAT MIN: Segfault
33918 "Calf Reverb LADSPA" all input controls FLOAT MAX: Assertion
failure
CMT
1226 "Phase Modulated Voice" all input controls FLOAT MAX: Watchdog
timeout
1849 "Logistic Map Control Generator" all input controls FLOAT MIN:
Watchdog timeout
1221 "Analogue Voice" all input controls FLOAT MAX: Watchdog timeout
SWH
1605 "Reverse Delay (5s max)" all input controls FLOAT MAX: Segfault
1208 "Retro Flanger" all input controls +Inf: Watchdog timeout
1905 "VyNil (Vinyl Effect)" all input controls zero: Watchdog timeout
1211 "Tape Delay Simulation" all input controls +Inf: Watchdog timeout
1904 "GLAME Butterworth Highpass" instantiate/cleanup: Segfault
1903 "GLAME Butterworth Lowpass" instantiate/cleanup: Segfault
1902 "Glame Butterworth X-over Filter" instantiate/cleanup: Segfault
1894 "Mag's Notch Filter" instantiate/cleanup: Segfault
1890 "Glame Highpass Filter" instantiate/cleanup: Segfault
1891 "Glame Lowpass Filter" instantiate/cleanup: Segfault
1892 "Glame Bandpass Filter" instantiate/cleanup: Segfault
1893 "Glame Bandpass Analog Filter" instantiate/cleanup: Segfault
"Watchdog timeout" means the run function takes too long - maybe an
infinite loop.
"instantiate/cleanup" means the plugin's instantiate function was called
and then the cleanup function, with nothing else. That sort of thing can
happen with modular synths.
I'm not sure we should worry about problems with controls set to "Inf",
but all normal values should probably be handled OK.
Damon
8 a.m.
On Thu, 30 Jul 2009 11:49:42 +0200
Grammostola Rosea <rosea.grammostola(a)gmail.com> wrote:
Damon Chaplin wrote:
Definitely. There currently are a number of problems with ladspa and
lv2 plugins. I did I test where I only loaded each of them in ardour
which caused lots of crashes. It can be found in form of two or the
bugreports in the ardour tracker. The problem with that test was that
it was hard to tell whether it was ardours or the plugins fault (or
both).
Now having some QA on the plugin side helps quite a bit.
Philipp
Hi,
I've tracked down all the issues spotted by my test app and emailed
all the maintainers. So hopefully they'll get fixed.
Great work! We need good
plugins! :)
Regards.
\r 
8:27 a.m.
New subject: LV2 test apps?
On 30/7/2009, "Damon Chaplin" <damon(a)karuna.eclipse.co.uk> wrote:
Hi,
I've tracked down all the issues spotted by my test app and emailed all
the maintainers. So hopefully they'll get fixed.
I've tried the demolition test app as well. The output isn't too clear
so I've summarised the major issues spotted:
Are there any similar testing tools for LV2 plugins?
Although I'm familiar with gdb and valgrind, I don't know how to go
about using these with plugins, and I guess/assume a simple host
(perhaps one specifically designed for testing) would be best for doing
this? Are there any existing tools?
James.
1:07 p.m.
New subject: LV2 test apps?
On Thu, 2009-07-30 at 11:27 +0100, james morris wrote:
Are there any similar testing tools for LV2 plugins?
Although I'm familiar with gdb and valgrind, I don't know how to go
about using these with plugins, and I guess/assume a simple host
(perhaps one specifically designed for testing) would be best for doing
this? Are there any existing tools?
I've done a quick port of my little test app to LV2. I've attached it.
We could add the various control port input tests from demolition later.
My first test results:
calf - memory errors in 2 of the small plugins.
(plus the organ had an unknown port type so was skipped)
ll - OK, except 3 of the plugins couldn't be instantiated.
2 seem to have incorrect URLs in the cpp files.
Not sure about the other one.
swh - crashes (a known bug actually).
Damon
1:37 p.m.
New subject: LV2 test apps?
On Thu, 2009-07-30 at 11:27 +0100, james morris wrote:
On 30/7/2009, "Damon Chaplin"
<damon(a)karuna.eclipse.co.uk> wrote:
lv2_inspect and lv2_jack_host in the slv2 distribution may be useful for
this
Cheers,
-dr
Hi,
I've tracked down all the issues spotted by my test app and emailed all
the maintainers. So hopefully they'll get fixed.
I've tried the demolition test app as well. The output isn't too clear
so I've summarised the major issues spotted:
Are there any similar testing tools for LV2 plugins?
Although I'm familiar with gdb and valgrind, I don't know how to go
about using these with plugins, and I guess/assume a simple host
(perhaps one specifically designed for testing) would be best for doing
this? Are there any existing tools?
8:48 a.m.
On 30 Jul 2009, at 10:34, Damon Chaplin wrote:
CMT
1226 "Phase Modulated Voice" all input controls FLOAT MAX: Watchdog
timeout
1849 "Logistic Map Control Generator" all input controls FLOAT MIN:
Watchdog timeout
1221 "Analogue Voice" all input controls FLOAT MAX: Watchdog timeout
SWH
1605 "Reverse Delay (5s max)" all input controls FLOAT MAX: Segfault
1208 "Retro Flanger" all input controls +Inf: Watchdog
timeout
1905 "VyNil (Vinyl Effect)" all input controls zero: Watchdog
timeout
1211 "Tape Delay Simulation" all input controls +Inf: Watchdog
timeout
I'll look at those.
1904 "GLAME Butterworth Highpass"
instantiate/cleanup: Segfault
1903 "GLAME Butterworth Lowpass" instantiate/cleanup: Segfault
1902 "Glame Butterworth X-over Filter" instantiate/cleanup: Segfault
1894 "Mag's Notch Filter" instantiate/cleanup: Segfault
1890 "Glame Highpass Filter" instantiate/cleanup: Segfault
1891 "Glame Lowpass Filter" instantiate/cleanup: Segfault
1892 "Glame Bandpass Filter" instantiate/cleanup: Segfault
1893 "Glame Bandpass Analog Filter" instantiate/cleanup: Segfault
Those are difficult to fix. They were ported from a different plugin
system with different rules.
I'm not sure we should worry about problems with
controls set to
"Inf",
but all normal values should probably be handled OK.
According to the specs, you're supposed to handle that case. It would
see a bit antisocial on the part of hosts though.
- Steve
31 Jul
31 Jul
1:21 p.m.
2009/7/30 Steve Harris <steve(a)plugin.org.uk>uk>:
On 30 Jul 2009, at 10:34, Damon Chaplin wrote:
I think I already contacted you on these... yeah, here's what I wrote
you some time ago:
If you instantiate and then cleanup, cleanupBandpass_iir() calls
free_iirf_t() with two NULLs as parameters, which are then derefenced
by the last function.
HTH,
Stefano
1904 "GLAME Butterworth Highpass"
instantiate/cleanup: Segfault
1903 "GLAME Butterworth Lowpass" instantiate/cleanup: Segfault
1902 "Glame Butterworth X-over Filter" instantiate/cleanup: Segfault
1894 "Mag's Notch Filter" instantiate/cleanup: Segfault
1890 "Glame Highpass Filter" instantiate/cleanup: Segfault
1891 "Glame Lowpass Filter" instantiate/cleanup: Segfault
1892 "Glame Bandpass Filter" instantiate/cleanup: Segfault
1893 "Glame Bandpass Analog Filter" instantiate/cleanup: Segfault
Those are difficult to fix. They were ported from a different plugin
system with different rules. 
28 Jul
28 Jul
5:12 p.m.
Hi Damon,
On Tue, 28 Jul 2009, Damon Chaplin wrote:
A quick update - fixes have been found for blop, caps
& cmt, and the
ladspa Sine plugin problem is fixed in the latest version.
Great job! Did you update your test program? Could you please post it to
the list?
Thanks,
Gabriel
6:33 p.m.
On Tue, 2009-07-28 at 14:12 -0500, Gabriel M. Beddingfield wrote:
Hi Damon,
On Tue, 28 Jul 2009, Damon Chaplin wrote:
I've only reordered it so it connects the ports before calling activate,
to avoid the crashes with the amb and swh plugins.
I've attached the new version.
Damon
A quick update - fixes have been found for blop,
caps & cmt, and the
ladspa Sine plugin problem is fixed in the latest version.
Great job! Did you update your test program? Could you please post it to
the list?
1 Aug
1 Aug
8:10 a.m.
On Tue, 28 Jul 2009 21:31:42 +0100
Damon Chaplin <damon(a)karuna.eclipse.co.uk> wrote:
On Tue, 2009-07-28 at 14:12 -0500, Gabriel M. Beddingfield wrote:
One more that could use testing:
guitarix (when you build the application it also builds ladspa plugins)
Philipp
Hi Damon,
On Tue, 28 Jul 2009, Damon Chaplin wrote:
I've only reordered it so it connects the ports before calling
activate, to avoid the crashes with the amb and swh plugins.
I've attached the new version.
Damon A quick update - fixes have been found for blop,
caps & cmt, and
the ladspa Sine plugin problem is fixed in the latest version.
Great job! Did you update your test program? Could you please
post it to the list? 
6:16 p.m.
Damon Chaplin schrieb:
Hi,
I've been having problems with a few LADSPA plugins recently, so I've
written a little test app that loads all LADSPA plugins, connects the
ports and runs them for one cycle. (I've attached it here.)
I've run it on the plugin packages I have installed, using valgrind, and
the results are:
amb crashes
blop memory errors (patches sent for some of the errors)
calf memory errors in Flanger & MultiChorus plugins
caps memory errors in 3 plugins
cmt memory errors (patches sent)
fil OK
ladspa memory errors in Sine plugin (mismatched free/deletes)
mcp OK
rev OK
swh crashes
tap memory errors in 5 plugins
vco OK
Note that not all memory errors are bugs, but most are. (There's also a
chance that my test app is buggy, rather than the plugins.)
I've sent a few patches for cmt and blop, and will probably try to track
down the bugs in a few other packages. If others want to help
(especially the owners of the above packages!) that would be good.
Damon
This testing is great stuff. It would be cool to have a buildbot
(http://buildbot.net) and run this regularly. Ideally test-tools would be part
of ladspa/lv2 sdk and the plugin-packages add running the test tools as part of
make check. Bonus points for rerunning tests on success under valgrind memcheck
once again.
Stefan
7:18 p.m.
On Sat, 2009-08-01 at 23:16 +0300, Stefan Kost wrote:
Damon Chaplin schrieb:
++
-dr
Hi,
I've been having problems with a few LADSPA plugins recently, so I've
written a little test app that loads all LADSPA plugins, connects the
ports and runs them for one cycle. (I've attached it here.)
I've run it on the plugin packages I have installed, using valgrind, and
the results are:
amb crashes
blop memory errors (patches sent for some of the errors)
calf memory errors in Flanger & MultiChorus plugins
caps memory errors in 3 plugins
cmt memory errors (patches sent)
fil OK
ladspa memory errors in Sine plugin (mismatched free/deletes)
mcp OK
rev OK
swh crashes
tap memory errors in 5 plugins
vco OK
Note that not all memory errors are bugs, but most are. (There's also a
chance that my test app is buggy, rather than the plugins.)
I've sent a few patches for cmt and blop, and will probably try to track
down the bugs in a few other packages. If others want to help
(especially the owners of the above packages!) that would be good.
Damon
This testing is great stuff. It would be cool to have a buildbot
(http://buildbot.net) and run this regularly. Ideally test-tools would be part
of ladspa/lv2 sdk and the plugin-packages add running the test tools as part of
make check. Bonus points for rerunning tests on success under valgrind memcheck
once again.
4 Aug
4 Aug
10 a.m.
On Sat, 2009-08-01 at 23:16 +0300, Stefan Kost wrote:
This testing is great stuff. It would be cool to have
a buildbot
(http://buildbot.net) and run this regularly. Ideally test-tools would be part
of ladspa/lv2 sdk and the plugin-packages add running the test tools as part of
make check. Bonus points for rerunning tests on success under valgrind memcheck
once again.
Here's my latest test apps for LADSPA and LV2. I've ported most of the
demolition tests over to both of them.
If people want to put them in the LADSPA/LV2 SDKs and add extra tests
etc. that would be fine.
Damon
12:07 p.m.
On Tue, 2009-08-04 at 12:59 +0100, Damon Chaplin wrote:
On Sat, 2009-08-01 at 23:16 +0300, Stefan Kost wrote:
I'd be happy to include the LV2 one in SLV2 if you'd like and there's
nowhere better for it to go... (there's no LV2 SDK)
Cheers,
-dr
This testing is great stuff. It would be cool to
have a buildbot
(http://buildbot.net) and run this regularly. Ideally test-tools would be part
of ladspa/lv2 sdk and the plugin-packages add running the test tools as part of
make check. Bonus points for rerunning tests on success under valgrind memcheck
once again.
Here's my latest test apps for LADSPA and LV2. I've ported most of the
demolition tests over to both of them.
If people want to put them in the LADSPA/LV2 SDKs and add extra tests
etc. that would be fine.
5 Aug
5 Aug
8:01 a.m.
On Tue, 2009-08-04 at 10:07 -0400, David Robillard wrote:
On Tue, 2009-08-04 at 12:59 +0100, Damon Chaplin
wrote:
Yep, that sounds good.
Damon
On Sat, 2009-08-01 at 23:16 +0300, Stefan Kost
wrote:
I'd be happy to include the LV2 one in SLV2 if you'd like and there's
nowhere better for it to go... (there's no LV2 SDK) This testing is great stuff. It would be cool to
have a buildbot
(http://buildbot.net) and run this regularly. Ideally test-tools would be part
of ladspa/lv2 sdk and the plugin-packages add running the test tools as part of
make check. Bonus points for rerunning tests on success under valgrind memcheck
once again.
Here's my latest test apps for LADSPA and LV2. I've ported most of the
demolition tests over to both of them.
If people want to put them in the LADSPA/LV2 SDKs and add extra tests
etc. that would be fine.
5622
days inactive
5630
days old
linux-audio-dev@lists.linuxaudio.org
34 comments
13 participants
participants (13)
-
adi＠drcomp.erfurt.thur.de -
Damon Chaplin -
David Robillard -
Fons Adriaensen -
Gabriel M. Beddingfield -
Grammostola Rosea -
hollunder＠gmx.at -
james morris -
Paul Davis -
Stefan Kost -
Stefano D'Angelo -
Steve Harris -
Tim Goetze