(In reply to comment #0)

Are these worth our porting to Windows, as with the LADSPA repository?

Regardless, as we have too few Linux developers, can you post the call stack/back trace for the crash? Might be possible to figure it out on other platforms.

Created attachment 343 [details]
Port to Windows of some LADSPA BLOP plug-ins that crash without their data DLL's 

Vaughan,

There is a ready Windows port of some of these BLOP plug-ins: 
http://opensourcepack.blogspot.co.uk/p/ladspa-for-win32.html .

In the attachment I've included: 

pulse_1645.dll
sawtooth_1641.dll
square_1643.dll
triangle_1649.dll

which seem to be implicated in Steve's report.  

The pulse_1645 DLL produces three variable width pulse effects (FAPA. FAPC and FCPA) and the triangle_1649 DLL produces three variable slope effects (FASA, FASC and FCSA). Square_1649 and sawtooth_1641 are individual effects.  

The attachment also includes a "blop_files" folder containing parabola_1649_data.dll, sawtooth_1641_data.dll and square_1643_data.dll 

What I see in HEAD on Win 7 is that all eight plug-ins function if that "blop_files" folder is present in the Audacity Plug-ins folder. If the "blop_files" folder is missing or renamed then any of the plug-ins crash (it should be easy for you to reproduce).

I have downloaded but not compiled the plug-ins on Linux. I wonder if the plug-ins are being used correctly there? Do you need to install liblrdf so you get the plug-in metadata, or is there some other requirement the developer has not  
mentioned in the README?

(In reply to comment #2)
I had not noticed the generators (which I assume are the main purpose). They behave the same (they generate audio if the "blop_files" folder is present, otherwise they crash).

(In reply to comment #2)

Cannot replicate this on Windows 7. Whether I have "blop_fils" folder inside plug-ins or those dll's at top level of plug-ins folder, they do not load, so cannot test or debug on Windows. Sorry, this must be up to a Linux fix.

Release Note added.

(In reply to comment #0)
> (Side note: Most other LADSPA generate plug-ins also fail, typically either
> generating nothing, or generating a waveform at extreme low frequency).
So is this a separate, lesser bug as it sounds (no crash)? Is it bug 607 or more general than that (the plug-ins won't generate even into an audio selection)? 

Do these plug-ins generate correctly in other software? If so, are those other programs using DSSI GUI, or could there be some other reason? 

If there is anything in this comment that is bug 607 or is a separate Audacity bug, please comment in bug 607 or start a new issue as needed.

(In reply to comment #3)

I've replicated this on Windows now. It happens on the first call to BLOP's initiate() method, and appears it is returning an invalid handle. Seems it's a BLOP problem rather than Audacity's. I've contacted the developer to see if he's willing to help. 


Gale wrote: 
>I had not noticed the generators (which I assume are the main purpose). They
>behave the same (they generate audio if the "blop_files" folder is present,
>otherwise they crash).

I've replicated the crash without removing that folder. 

If I remove that folder, the crash happens later, so the real problem is still in BLOP initialize(), I think. Let's fix that first and see whether it fixes this problem.

(In reply to comment #6)

Hi. About a month since I contacted the blop developer and no response, so I'm demoting this. It's third party software, not part of Audacity, and it's their code that crashes. Don't think we can failsafe it.

Surely this is an issue for the plug-in developer and NOT for Audacity.

I thginks we could/should close this as NOTABUG

(In reply to Peter Sampson from comment #8)
If it were just that they didn't work in Audacity, then I'd be happy for this to be closed as "won't fix". 

The reason that I'm not happy about doing so, is that Audacity crashes, potentially loosing the user's work.

I've just checked with Audacity 2.3.2 alpha on Linux, and the crash still occurs. The crash is particularly nasty as it left my Desktop in an unstable state, preventing windows from being moved with the mouse and preventing logging out / shutting down the computer properly.

Downgrading this to P4 - we really do not need to clutter the Release Notes with listings of 3rd party plugins that fall to work or crash Audacity.

a) they are curated in Bugzilla via superbug Bug #665

b) they are listed in the Wiki on this page: https://wiki.audacityteam.org/wiki/Plug-ins_that_crash_Audacity_or_fail_to_work_properly_in_Audacity

c) that Wiki page is now linked to from the main Wiki>Plug-ins page
https://wiki.audacityteam.org/wiki/Plug-ins

d) the page in b) above is now linked to from each of the three platform pages for installing plug-ins:
https://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Windows
similarly for Mac and Linux

I think that is sufficient documentation of them without cluttering the Release Notes

(In reply to Peter Sampson from comment #10)
Peter wrote:
> a) they are curated in Bugzilla via superbug Bug #665

The bug summary for 665 only says "AUs and VSTs".
The "Bloop" plug-ins are LADSPA plug-ins.

Either bug 665 needs to be expanded to include other types of plug-in, or we need to curate LADSPA / LV2 plug-ins in another bug report.

I also note that bug 665 is only P5, which seems incredibly low for a crash bug.
(Crash bugs are usually P1).

(In reply to Steve Daulton from comment #11)
>Either bug 665 needs to be expanded to include other types of plug-in, 
>or we need to curate LADSPA / LV2 plug-ins in another bug report.

Bug #665 was long ago expanded to give a broader coverage but the bug title did not reflect that - I have generalized the bug title

It's set at P5 as it is just a summary bug - not a bug that can be "fixed"



>I also note that bug 665 is only P5, which seems incredibly low for a 
>crash bug. (Crash bugs are usually P1).

It states on this page in the Wiki: https://wiki.audacityteam.org/wiki/Bug_Lists
>These will include most reproducible crashes, most things that cause data loss
>and most regressions.  
>P1's would affect large numbers of users, if released.

This bug and it's close cousins listed in Bug #665 fall foul of the first criterion - but with regards to the 3rd criterion, they affect only a very small minority of our users.

And we certainly would not want them to P1 block a release (most of them have been around for many years and many releases).

(In reply to Peter Sampson from comment #12)
I don't agree that bug #665 only affects a small number of users. We quite frequently hear from users complaining that one plug-in or another crashes in Audacity.

I do agree that we would not want to block on this bug as there will probably always be some plug-in that will crash, and in some cases it will be due to bugs in the plug-ins. However, our support for VST effects is not good, and our support for LV2 is pretty bad.

Linux users in particular rely on LV2 (and the old LADSPA plug-ins) for effects that we don't ship, but many of the best known LV2 plug-ins (such as the excellent "Calf" plug-ins) frequently crash.

In my opinion, P2 would be appropriate for bug #665, which could then be lowered when we have reasonably good support for the plug-in types that we say Audacity supports.

(In reply to Steve Daulton from comment #13)
>In my opinion, P2 would be appropriate for bug #665, which could then be 
>lowered when we have reasonably good support for the plug-in types that 
>we say Audacity supports.

Agreed - I have raised Bug #665 to P2

From Leland:

What is happening is that when Audacity scans for LADSPA plugins, it just tries to load any “.so” file it finds in the ladspa lib directory.  That’s find and shouldn’t be changed.

The problem is that the .so files in “/usr/lib/ladspa/blop_files” (or wherever they are found) contain an “_init()” function that the glibc will execute after the library has been loaded and that _init() function references a symbol called “lookup”.

Well, he’s expecting to reference the “lookup” symbol defined in his own “.so” library.  But because of the way dynamic library binding in Linux works, he actually gets a reference to the “lookup” function defined in libnyquist (cmt/cmtcmd.c specifically).  When he tries to write to that location, it segfaults because functions are loaded into read-only memory.

There’s two options here.

The first (and the easiest) is to change the name of the “lookup” function in libnyquist to something else, like hash_lookup (see attached nyquist.patch).  Really, this is just a bandaid since any new libraries could run into the same issue with any symbols.  It just happened that libnyquist and blop used a common symbol name for two different types of data.  But, this does address the current segfault.

The second is to change the LadspaEffect.cpp file to call dlopen() directly using the RTLD_DEEPBIND flag (see man dlopen).  This is already being done in VSTEffect.cpp and could (should) be done for LadspaEffect.cpp.

This changes the way the loader looks for symbols during resolution.  Instead of the default of looking at already loaded/defined symbols first, it will look in the “.so” being loaded first and then the already defined fellas.  So, the blop libs will update their own data instead of trying to smash Audacity’s.

Created attachment 865 [details]
"bandaid" fix patch

This is the patch referred to in comment #15.
I have tested this patch with the blop "band limited square wave" plug-in and demonstrated that it works, though as indicated in comment #15, this is only a "bandaid" fix for the problem.

(In reply to Steve Daulton from comment #15)
Unfortunately it appears that this bug cannot be completely fixed by using the RTLD_DEEPBIND flag because 4 of the blop plug-ins hit the same problem with dlopen. The "Bandlimited" oscillators use separate "_data.so" (according to the release notes: "so that the data can be shared between multiple instances"), but don't specify RTLD_DEEPBIND, so they hit the same symbol name conflict with Nyquist.

As the old blop plug-ins are still widely used, we will still need to patch Nyquist to avoid this conflict (the "bandaid fix), even with the proper RTLD_DEEPBIND fix.

Leland has committed a fix for this https://github.com/audacity/audacity/commit/5955dbc75295997f273981224ffede70506bc185

I can't test this as the blop site reference step-s to reproduce does not appear to have pre-built plug-ins for download (just source code)

(In reply to Peter Sampson from comment #18)
There are 4 blop plug-ins for windows in the "Attachments" section of this bug report ("Port to Windows of some LADSPA BLOP plug-ins that crash without their data DLL's")

(In reply to Steve Daulton from comment #19)
Testing on W10 with audacity-2.3.3-alpha-352-98f495a4858b98198f66f4c956fb4730bf13a390

I tested with the four example Blop generators at the top level as referenced in Attachment #1 [details]:
>pulse_1645.dll
>sawtooth_1641.dll
>square_1643.dll
>triangle_1649.dll

a) I added all these to the plugins folder along with the  folder blop-win-ports (that contains a folder blop_files which in turn contaim the data files
>parabola_1649_data.dll
>sawtooth_1641_1649_data.dll
>square_1643_1649_data.dll

b) All were able to be added with Plug-in Manager when they had been added to the plugins folder.

c) None of then worked - they all popped a dialog - but then did nothing when the OK button was pressed

d) the null action was not added to the Undo stack

e) but importantly there was *no* crash


So given that the title of this bug is
>Win/Linux: Audacity crashes with LADSPA blop plug-ins

and there are *no* crashes with this testing - do we just want to close this bug - or do we want to keep it open as "Blop plug-ins don't work …"

The bug as described is fixed.  

I think 3rd Party plugin does not work would be a new bug, and might get closed WONT-FIX.  

Thanks for the fix (Leland and Steve) and testing (Peter)