Bugzilla – Bug 462
Some VST plug-ins crash 1.3.13 and later on launch, but not 1.3.12
Last modified: 2018-08-20 11:51:23 UTC
Created attachment 214 [details] Ensures a valid rate is set. The VSTs in this report enable additional floating point exceptions that are "normally" disabled (basically, all of them). With these additional exceptions enabled, Audacity will fail since SelectionBar::mRate has not yet been set to a non-zero value before the SelectionBar::Populate() function is called. The TimeTextCtrls created in Populate() required a non-zero rate as calculations are made based on that rate. This patch ensures a valid rate has been set.
I've committed Leyland's patch, which ensures that the controls on the toolbar are set to use the project default rate at start-up (before any projects are loaded), to avoid un-initialised rates causing problems down the line. I have no way of testing if this fixes the problem - hopefully someone can build for Windows and get the OP to test it.
I'm a little concerned about the wider implications of this, although I suspect there is nothing we can do about them. AS I read what Leyland has done on this, the (3rd-party) VST code is (at runtime) changing the exception mode for the whole of Audacity. WE then have a problem because our code is running in the "wrong" exception mode, even if the user never uses the plug-in. How many other plug-ins do this sort of thing, and what else could they be doing? Is this just an inevitable consequence of the (naive?) way that audio plug-in interfaces work, or could we (easily) be putting more isolation between VST plug-ins and our program (short of engineering a separate host linked by pipes etc). None of these are urgently important issues, but they may well explain some of the stability issues surrounding plug-ins, and I expect this to bite us again in the future. So what can we do about this? One suggestion would be to turn floating point exceptions up to max in all our debug builds on all platforms, which would have caught us this bug as soon as we introduced it. That approach assumes that exception modes is the only thing that VSTs can alter however, which I'm not very confident about. Virtual Dub has been here before and seems to have gone down the "force it back fixed" route: http://www.virtualdub.org/blog/pivot/entry.php?id=53 and the GIMP for windows people discovered that keyboard hook drivers could do the same thing https://bugzilla.gnome.org/show_bug.cgi?id=316645 and one on MSDN blogs which blames printer drivers http://blogs.msdn.com/b/oldnewthing/archive/2008/07/03/8682463.aspx This isn't inherently a Windows problem, because C99 provides a way to get/change floating point exception mode http://linux.die.net/man/3/fegetexceptflag which doesn't appear to have any documentation as to what the scope of the change is. We may be in a slightly better position to diagnose such cases however, because we could (very easily on Linux) put a handler on floating point exceptions which prints a message to the console. At least then if the user starts Audacity from a console they will get a message which tells us that the crash was caused by SIGFPE and we have some idea where to look. Not so good on Mac, which I suspect has the greater problem (because Linux LADSPA plug-ins are normally open and they don't have VST plug-ins).
(In reply to comment #2) > I've committed Leyland's patch... I have no way of testing if this fixes the > problem - hopefully someone can build for Windows and get the OP to test it. Thanks for committing. I'll test with the plug-in named in the report and offer the next Win "nightly" to the user.
(In reply to comment #3) > > None of these are urgently important issues, but they may well explain some of > the stability issues surrounding plug-ins, and I expect this to bite us again > in the future. So what can we do about this? One suggestion would be to turn > floating point exceptions up to max in all our debug builds on all platforms, > which would have caught us this bug as soon as we introduced it. That approach > assumes that exception modes is the only thing that VSTs can alter however, > which I'm not very confident about. Unfortunately, we can't. During analysis, I tried various exception settings and found the errors occur within wxWidgets code as well. :-( > > Virtual Dub has been here before and seems to have gone down the "force it back > fixed" route: > http://www.virtualdub.org/blog/pivot/entry.php?id=53 I wish I had found that one. That's exactly the problem with this particular plugin as it was built with the Borland compiler. Took me a while to figure it out, but it's very easy to simulate using the _controlfp() function. Leland
(In reply to comment #4) > I'll test with the plug-in named in the report and offer the next Win "nightly" > to the user. I and the user test OK with the Win "nightly" which has the patch, so moving to "RESOLVED - FIXED". The bug can always be reopened later if necessary.
