Audacity Bug Summary
••• Introduction •••
••• Keywords •••
    Audacity 3.0.3 development began 19th April 2021

Audacity Bugzilla



Bug 979 - Yosemite or later: Moonphase crashes when saving projects/importing/exporting.
Yosemite or later: Moonphase crashes when saving projects/importing/exporting.
Status: CLOSED WORKSFORME
Product: Audacity
Classification: Unclassified
Component: User Interface
2.1.0
Mac macOS
: P2 MoonPhase
Assigned To: Default Assignee for New Bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-05-26 18:37 UTC by Gale Andrews
Modified: 2018-08-20 11:45 UTC (History)
8 users (show)

See Also:
Steps To Reproduce:
Release Note:
GROUP: Interface * (OS X Yosemite or later) '''Random occasional crashes may occur when importing or exporting files or when opening/saving projects.''' If you have found steps that almost always reproduce this crash, please write to [http://audacityteam.org/contact/#feedback our feedback address] with details and include the crash report from /Applications/Utilities/Console.app.
First Git SHA:
Group: ---
Workaround:
Closed: 2018-08-20 00:00:00
gale: Regression+


Attachments
Bug 979 example crash report (60.91 KB, text/plain)
2015-05-26 18:37 UTC, Gale Andrews
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gale Andrews 2015-05-26 18:37:18 UTC
Created attachment 595 [details]
Bug 979 example crash report

Whenever importing (usimg file dialogue or drag), exporting or opening/saving projects, Audacity on Yosemite displays rapid flickering of its menu bar for a second or two, accompanied by slower flickering of the controls of any combo boxes e.g. Device Toolbar, Selection Toolbar, Spectral Selection Toolbar. 

The commbo box controls have vivid blue colour on Yosemite so are obvious to see but they flicker rather than just becoming available again after closing a dialogue. Like the Menu bar, they combo controls flicker even when dragging in an audio file which does not involve a dialogue.

Moonphase crashes when importing/exporting/opening/saving have been reported in Audacity on Yosemite ever since Yosemite became available. Because of the prominent visual effect, users associate the crashes rightly or wrongly with the flickering. There is some evidence that crashes are more likely after opening a second project window but do not necessarily occur in the second window. 

Leland has looked at reports from these crashes before without being able to reproduce them, but as they are reported about once or twice per week they must be tracked. The crash trace (example attached) almost always cites wxAboutDialogCreditItemsListNode but having had that modal dialogue open does not help reproduce the crash. I have never seen these crashes on my Mac Mini on Yosemite, nor have I seen them reported on Mac Mini.  

Audacity on Mavericks does not display the flickering behaviour or file operation-related crashes.
Comment 1 Leland Lucius 2015-05-30 03:22:21 UTC
I've tracked down the flickering and believe it is an annoyance we'll have to deal with until we convert to wx3.  It's related to the progress dialog and the fact that all of the windows are disabled while the progress dialog is active (even it it isn't shown).  The disabling and enabling of the windows cause everything to be redrawn and that is what is causing the flicker.

That in itself isn't the cause of the crashes.  I believe these relate to events getting through while the progress dialog is active since it must yield to allow the dialog to update and accept events (like clicking the Cancel button).  

Unfortunately, I haven't found a solution that will allow the progress dialog to function without yielding.
Comment 2 James Crook 2015-05-30 04:58:15 UTC
is wxSafeYield relevant here?
Comment 3 Leland Lucius 2015-05-30 05:11:56 UTC
(In reply to James Crook from comment #2)
> is wxSafeYield relevant here?

Not really:

// Yield to other apps/messages and disable user input to all windows except
// the given one
bool wxSafeYield(wxWindow *win, bool onlyIfNeeded)
{
    wxWindowDisabler wd(win);

    bool rc;
    if (onlyIfNeeded)
        rc = wxYieldIfNeeded();
    else
        rc = wxYield();

    return rc;
}

In the progress dialog's case, we've already done the wxWindowDisabler and we call wxYieldIfNeeded, so we've basically done what wxSafeYield does.

The one thing I did recently try was to control the message loop directly, but odd things were still happening.

In ProgressDialog, we disable the application event handler on Windows only.  I'm starting to think that may be appropriate for all plats.
Comment 4 Leland Lucius 2015-05-30 05:16:15 UTC
There's also an application level FilterEvent() method that might be useful, but I'd rather not go there if we didn't have to since it would require picking and choosing which events to let through.  It might wind up being the best approach.

But, I'd like to postpone more research until after wx3 since a lot of things will be changing and this might not be a problem anymore.
Comment 5 Leland Lucius 2015-05-30 05:25:24 UTC
One of the medium priority tasks on the wxWidgets todo list:

Avoid calling the wxYield family of functions in internal code. wxYield causes problems in combination with pending events leading to all sorts of strange side-effects.
Comment 6 Gale Andrews 2015-08-04 16:44:06 UTC
Just some observations from user input on Audacity Forum.

* It's been reported that Audacity 2.1.1 (wx 2.8.12) on El Capitan Public Beta does not rapidly flash the screen, at least "on saving a new recording".

* The subject crashes may be more likely after Audacity has been running a while, especially if sitting idle. 

* There has been speculation about any part App Nap and "Idle Wakeups" may play in crashes. A recent console message at the time a crash occurred when saving/exporting said:

"l8/1/15 9:12:41.000 PM kernel[0]: process Audacity[465] caught causing excessive wakeups. Observed wakeups rate (per sec): 186; Maximum permitted wakeups rate (per sec): 150; Observation period: 300 seconds; Task lifetime number of wakeups: 414213"

If I understand it, Idle Wakeups are the number of times a timer fires in the app. There are a lot of Idle Wakeups when Audacity is not idle e.g. I get between 140 and 230 Idle Wakeups pre second when playing audio. 

That said there is no evidence that enabling "Prevent App Nap" for Audacity does much to prevent the type of crashes noted in this bug.
Comment 7 Leland Lucius 2015-08-16 05:13:21 UTC
I believe this to be corrected.  I no longer see it happening now that we're using wx3.
Comment 8 Gale Andrews 2015-09-08 13:29:15 UTC
(In reply to Leland Lucius from comment #7)
You're talking about the flicker, Leland, and not the crashes which you established are unrelated? 

Given I (mostly) don't get these crashes any resolution will have to wait for users who get the crashes often to get round to 2.1.2-alpha or release.   

Let me know, I could request some testing.
Comment 9 Leland Lucius 2015-09-08 14:07:52 UTC
(In reply to Gale Andrews from comment #8)
> (In reply to Leland Lucius from comment #7)
> You're talking about the flicker, Leland, and not the crashes which you
> established are unrelated? 
> 
> Given I (mostly) don't get these crashes any resolution will have to wait
> for users who get the crashes often to get round to 2.1.2-alpha or release. 
> 
> 
> Let me know, I could request some testing.


Correct, I was referring to the flicker.

I'm really not convinced the crashes were "related" to the flickering, but it would be really nice if you do have a willing tester available to see if they can reproduce the crashes they were experiencing before.
Comment 10 Gale Andrews 2015-10-08 01:55:15 UTC
Although there was a Yosemite user who had crashes while Audacity was idle between recordings who does not now get crashes, that improvement seems due to upgrade to El Capitan because 2.1.1 does not crash on El Capitan.

Another Yosemite user who had crashes more like the symptoms in this report still gets the identical spinlock crashes or freezes in HEAD after upgrading to El Capitan. 

So I've REOPENED this with the reference to "flicker" removed from the bug title.
Comment 11 Peter Sampson 2016-02-18 13:26:13 UTC
I know I've only been using the new Macbook Pro with El Capitan for a mere six days - but I have done an awful lot of testing ober that time involving saving/importing/exporting and I have not witnessed the reported behaviour.

I will keep an eye out for this
Comment 12 Gale Andrews 2016-06-24 15:57:41 UTC
Thanks, Peter.

(In reply to Gale Andrews from comment #10)
> Another Yosemite user who had crashes more like the symptoms in this report
> still gets the identical spinlock crashes or freezes in HEAD after upgrading 
> to El Capitan. 
That user hasn't seen any crashes in 2.1.2 release.

At least six users who had these symptoms in 2.1.1 whom I directed to 2.1.2 release either said the crashes stopped or stopped reporting problems.

I've been doing a lot of testing too around the symptoms of reusing projects for lengthy imports and exports and I don't see the problems. 

So I'm assuming wx3 fixed this and closing it WORKSFORME.