Hi all,
After some digging, here's what I found out. Even though dssi~ works fine if a plugin_lib:plugin_name is specified, anything other (including bogus names) crashes pd-extended 0.40.3. I tried 0.95 and 0.97 dssi~ external (latter compiled from source) and both exhibit this behavior. Closer inspection of the dssi~ code helped me identify the call that crashes Pd:
(line 1524) static const char* plugin_tilde_search_plugin (t_dssi_tilde *x, const char *name) { char* lib_name = NULL; void* user_data[2];
user_data[0] = (void*)(&lib_name);
user_data[1] = (void*)name;
lib_name = NULL;
LADSPAPluginSearch (dssi_tilde_search_plugin_callback,
(void*)user_data); //<--this call crashes Pd
/* The callback (allocates and) writes lib_name, if it finds the plugin
*/ return lib_name; }
When I comment LADSPAPluginSearch, recompile, and run the Pd, then the search for the plugin fails gracefully reporting failure to load plugin. But as soon as the function above is enabled Pd consistently crashes with the same error like the one I reported before:
Warning: no LADSPA_PATH and DSSI_PATH, assuming /usr/lib/ladspa:/usr/local/lib/ladspa:/usr/lib/dssi:/usr/local/lib/dssi no more csLADSPA plugins socket receive error: Connection reset by peer (104) Segmentation fault
This is running on Intrepid with the ladspa-sdk being 1.1 (latest) version. However, upon closer inspection of the search.c in the ladspa-sdk I noticed that there is no such LADSPAPluginSearch function that takes in two arguments, but rather one as follows:
void LADSPAPluginSearch(LADSPAPluginSearchCallbackFunction fCallbackFunction)
So, what gives? Am I missing something obvious? When compiled in debug mode, dssi~ still manages to list all plugins, followed by "no more csLADSPA plugins" and then crashes as described above. Could it be something with my LADSPA setup?
I guess the easiest thing is to comment this call for the time being and make the dssi~ gracefully fail unless you correctly specify a plugin. Still, I am curious what is making this thing fail.
Best wishes,
Ico
Hi Ico,
I'm pretty sure that the behaviour you are experiencing is down to a buggy plugin you have installed somewhere on your system. I just tried to reproduce the problem with pd-extended 0.40.3 on Ubuntu Intrepid with dssi~ 0.97, and I can't reproduce it.
Basically the plugin search function LADSPAPluginSearch() will open every file in your search path. If it is a library (of any sort) it will look for the symbols "ladspa_descriptor" or "dssi_descriptor" inside it. If one of these gets found, the callback function dssi_tilde_search_plugin_callback() is invoked. This iterates over the plugins in the library by repeatedly calling the Plugin's descriptor function until a match is found against the plugin search string provided as an argument to dssi~. A potential crash situation could occur if the symbol "dssi_descriptor" is exported by the plugin library, but the descriptor function doesn't return a pointer to a valid DSSI_Descriptor struct...
(see more below)
On Fri, 2008-12-12 at 21:05 -0500, Ivica Ico Bukvic wrote:
<snip> > This is running on Intrepid with the ladspa-sdk being 1.1 (latest) > version. However, upon closer inspection of the search.c in the > ladspa-sdk I noticed that there is no such LADSPAPluginSearch function > that takes in two arguments, but rather one as follows: > > void > LADSPAPluginSearch(LADSPAPluginSearchCallbackFunction > fCallbackFunction)
dssi~ uses a modified version of the ladspa-sdk search functions, which provides support for DSSI as well as LADSPA plugins. If you look in jsearch.c (with the dssi~ sources), you can find the modified LADSPAPluginSearch()
So, what gives? Am I missing something obvious? When compiled in debug mode, dssi~ still manages to list all plugins, followed by "no more csLADSPA plugins" and then crashes as described above. Could it be something with my LADSPA setup?
To take this further there are a couple of things you could try:
- Remove all LADSPA and DSSI plugins from your search path *except*
sine.so, and then try: [dssi~ sine_faaa]. Does it still crash? If not, I suspect a dodgy lib in your path. You could gradually add back your plugins to isolate the faulty one.
- Recompile dssi~ with the debugging symbols enabled -- comment out
LINXCFLAGS in the makefile, and uncomment the line under '# Debug'. Then run the pd-extended process under a debugger.
apt-get install gdb gdb pd-extended
Then when you get the crash, in the debugger console, type 'bt', and send me the results.
Jamie
P.S. Even if this is a bug in a plugin, dssi~ still shouldn't crash -- we need to handle the problem somehow...
Basically the plugin search function LADSPAPluginSearch() will open every file in your search path. If it is a library (of any sort) it will look for the symbols "ladspa_descriptor" or "dssi_descriptor" inside it. If one of these gets found, the callback function dssi_tilde_search_plugin_callback() is invoked. This iterates over the plugins in the library by repeatedly calling the Plugin's descriptor function until a match is found against the plugin search string provided as an argument to dssi~. A potential crash situation could occur if the symbol "dssi_descriptor" is exported by the plugin library, but the descriptor function doesn't return a pointer to a valid DSSI_Descriptor struct...
Many thanks for the info Jamie. One quick question before I embark on the search for the potentially problematic plugin: if I run listplugins command line tool that comes with ladspa sdk I get no segfaults or errors other than "no more csLADSPA plugins" at the end. Is this indicative of anything or is this orthogonal to the way how dssi~ objects cycles through plugins?
Anyways, I'll try tracking down the problem based on your instructions shortly.
Many thanks!
Best wishes,
Ico
On Sun, 2008-12-14 at 13:12 -0500, Ivica Ico Bukvic wrote:
Basically the plugin search function LADSPAPluginSearch() will open every file in your search path. If it is a library (of any sort) it will look for the symbols "ladspa_descriptor" or "dssi_descriptor" inside it. If one of these gets found, the callback function dssi_tilde_search_plugin_callback() is invoked. This iterates over the plugins in the library by repeatedly calling the Plugin's descriptor function until a match is found against the plugin search string provided as an argument to dssi~. A potential crash situation could occur if the symbol "dssi_descriptor" is exported by the plugin library, but the descriptor function doesn't return a pointer to a valid DSSI_Descriptor struct...
Many thanks for the info Jamie. One quick question before I embark on the search for the potentially problematic plugin: if I run listplugins command line tool that comes with ladspa sdk I get no segfaults or errors other than "no more csLADSPA plugins" at the end. Is this indicative of anything or is this orthogonal to the way how dssi~ objects cycles through plugins?
It could point the problem being in a DSSI plugin since the 'listplugins' CLI only lists LADSPAs.
What happens when you send the 'listplugins' message to [dssi~]. This passes a different callback to LADSPAPluginSearch(), so *might* yield a non-crash.
Jamie
OK, I traced it down to one plugin csladspa.so which is a csound ladspa plugin I never used before and I assume is a wrapper for csound code that can run in a form of a ladspa plugin or something along those lines. I uninstalled it since I currently have no need for it but as it stands right now, this thing reliably brings down dssi~ together with pd whenver it is within the ladspa search path.
Hope this helps in tracking this problem down. (btw this is still on Ubuntu 8.10 with pd-extended).
Best wishes,
Ico
On Mon, 2008-12-15 at 23:21 -0500, Ivica Ico Bukvic wrote:
OK, I traced it down to one plugin csladspa.so which is a csound ladspa plugin I never used before and I assume is a wrapper for csound code that can run in a form of a ladspa plugin or something along those lines. I uninstalled it since I currently have no need for it but as it stands right now, this thing reliably brings down dssi~ together with pd whenver it is within the ladspa search path.
Great! Thanks for your help with this. I'll now have a look into why csladspa is causing the crash -- I don't yet have it on my system, but as it happens it's something that I'm likely to use.
The net result will be that I'll either make a change to dssi~ or file an upstream bug report.
best,
Jamie
-
Ivica Ico Bukvic -
Jamie Bullock