Upgrading this to P1 - we really should not get crashes in Audacity - and we should not potentially lose users' data like this.

Paul, can you take a look this?  The exception wasn't "moved" and sOutstandingMessages is being decremented too soon, so the dialog doesn't appear.  Eventually we crash accessing freed memory (I think).

MessageBoxException::~MessageBoxException()
{
   if (!moved)
      // If exceptions are used properly, you should never reach this,
      // because moved should become true earlier in the object's lifetime.
      wxAtomicDec( sOutstandingMessages );
}

(In reply to Leland Lucius from comment #2)

So we certainly did construct and throw an exception.

Do you know the stack where the throw happens?  It might not be the same place in my retrial.

There should normally be one destruction of an exception object just before the throw happens, and another destruction of a copy of the exception object when we catch and handle it.

Did you take a stack trace for this destructor call?

(In reply to Paul L from comment #3)

Peter, is the problem known to happen on all OSs?

Leland, I tried to make an exception happen while mixing and rendering, and on my Mac (debug build) it worked as expected without a crash.

To understand what code puts up the message box when things work normally:  the thrown exception is caught in AudacityApp::OnExceptionInMainLoop, which captures the exception in a lambda.

The handler returns to the event loop, and lambda is executed at next idle time.

It invokes the virtual function DelayedHandlerAction() which puts up the message box and then the copied MessageBoxException is at last destroyed.

This sequence of steps looks all right so far on my Mac build.

But maybe it has stopped working on Windows or Linux builds with a change in the wxWidgets version.

(In reply to Peter Sampson from comment #0)

Leland, maybe a separate issue for you:

The error message Peter describes for Mac is from your commit bd04315 involving the changes in single instance checking.

So Peter has not yet confirmed it really happens on all platforms, that was only assumed.  But I failed to confirm for Mac when I tweaked code to simulate exceptions yet my temp directory does have enough space that I can start up.

But this may really be Windows only.

(In reply to Paul L from comment #5)
>But this may really be Windows only.

Sounds unlikely (though I still can't test on Mac yet - I'll try again tomorrow)

It seems more likely the if you run out of disk space (in an untrapped non-graceful manner) then it's likely to be a problem on all platforms.

That was certainly the case for the running out of disk space when recording that we (you that is Paul) plugged a while back.

(In reply to Peter Sampson from comment #6)

I'm overruling your guess.  I think this looks like a non-problem on Windows.  I have given details at comment 4.

We rely on C++ exception handling and it is plausible to me that there may be differences between platforms in how that is done and interacts with the wxWidgets toolkit.

(In reply to Paul L from comment #7)

I meant that on Mac it seems to be not a problem.

(In reply to Paul L from comment #7)
> (In reply to Peter Sampson from comment #6)
> 
> I'm overruling your guess.  I think this looks like a non-problem on
> Windows.  I have given details at comment 4.
> 
> We rely on C++ exception handling and it is plausible to me that there may
> be differences between platforms in how that is done and interacts with the
> wxWidgets toolkit.

It wasn't a guess.  I traced the from the first thrown here:

      bool bSuccess = WriteSimpleBlockFile(sampleData, sampleLen, format, NULL);
      if (!bSuccess)
         throw FileException{
            FileException::Cause::Write, GetFileName().name };

All the way to the crash here:

>	wxbase313ud_vc_custom.dll!std::_Container_base12::_Orphan_all() Line 1207	C++

And the dialog here was never displayed:

         ::AudacityMessageBox(
            ErrorMessage(),
            (caption.empty() ? AudacityMessageBoxCaptionStr() : caption),
            wxICON_ERROR
         );

And that was because the code here was executed and according to your own comments, this isn't supposed to happen:

      // If exceptions are used properly, you should never reach this,
      // because moved should become true earlier in the object's lifetime.
      wxAtomicDec( sOutstandingMessages );

Please feel free to fix this bug if my analysis is incorrect.  I have other bugs to guess about.

(In reply to Paul L from comment #4)
>But maybe it has stopped working on Windows or Linux builds with a change 
>in the wxWidgets version.

Are you implying that running out of disk space when importing is handled by the same code that you produced for running out of disk space while recording?

And if so, are you suggesting the the earlier fix for running out of disk space on Windows (and Linux?) could be now possibly be broken?  And that somehow Mac magically ducks this issue ?

-------------------------------------------------


I tried testing the import overflow again on Mac again today - but Audacity/Mac would not let me use a USB stick for my temp directory.  It lets me set the temp directory to be on the USB stick and creates a "Session Data" folder as it should.  But when I relaunch I get the error message:
>Audacity Startup Failure
>An unrecoverable error has occurred during startup

Fortunately there is an easy workaround - dismount/remove the USB stick and then restart Audacity which then launches and reverts automagically to the default temp files directory location.

I'm not sure if this is a fresh bug I should be logging ?
It really doesn't make sense to use a removable USB stick as you permanent temp files location.


I could, I suppose, test the out-of-disk-space by setting up a very long recording and filling by SSD drive - but I am nor prepared to potentially corrupt my Mac like that.

Re comment 10:

>Audacity Startup Failure
>An unrecoverable error has occurred during startup

Please log as a new bug.
We should be able to use a USB key or a USB spinning-platters drive with Audacity.

(In reply to Peter Sampson from comment #10)
>And if so, are you suggesting the the earlier fix for running out of disk space
>on Windows (and Linux?) could be now possibly be broken?  

So this led me to retest on Windows 
1) Save project to an almost full USB stick (I had 8.84MB fee)
2) Record
3) Observe: after 31 seconds alarmingly it does fail with a silent crash

4) examine diskspace with Windows explorer
5) Observe disk (almost) full (753kb free)

And it fails with a silent crash - so I will be logging this as a fresh P1
and noting it's possible relation to this bug.



>And that somehow Mac magically ducks this issue 
Well yes it seems to - but not as elegantly as previously

1) Save project to the same almost full USB stick (I had 8.84MB fee)
2) Record
3) Observe: after 31 seconds recording pauses

4) Observe after a little while a warning message
>Recorded audio was lost at the labelled locations.  Possible causes
>Other Applications are competing with Audacity for processor time
>You are saving directly to a slow external storage device.

5) Press OK
6) Observe: File Error message
>Audacity failed to write to a file
>Perhaps /Volumes/NO NAME/zzzzzzz_data/ is not
>writable or the disk is full

7) Save project
8) close Audacity
9) relaunch Audacity
10) Open the project
11) Observe it opens OK - 24 seconds of recording captured


It's a while since I tested the disk full on recording - but I don't recall ever seeing the step 4 message when I was testing that on Mac.

Though testing on 2.3.3 and 2.3.1 (the furthest I can go back in regression testing) also shows the step 4 warning.

(In reply to James Crook from comment #11)
>Re comment 10:
>
>>Audacity Startup Failure
>>An unrecoverable error has occurred during startup
>
>Please log as a new bug.
>We should be able to use a USB key or a USB spinning-platters drive with >Audacity.

Ok, will do - and I'm assuming P1

(In reply to Peter Sampson from comment #13)
Logged as P1 Bug #2462

(In reply to Peter Sampson from comment #12)
Logged as P1 Bug #2463

(In reply to Leland Lucius from comment #9)

Apologies Leland, I meant that Peter was guessing that this was on all operating systems but I believed this was not so on Mac.

Testing on macOS 10,15.5 with Audacity 2.4.2 8e6c5c0

Paul is correct - this does not crash on Mac

Once Leland had shown me that the reason I could not test before was because I was using a FAT frmatted USB stick - Once I reformatted it to "Mac OS Extended filesystem" I was able to use it as a Temporary files location and test this bug.
See: Bug #2462 
>Mac: cannot use a FAT or exFAT formatted USB stick or disk for 
>temporary files directory

At Step $ I get the error message
>File Error
>Audacity failed to write to a file.
>Perhaps Volumes/Untitled/SessionData/ is not
>writable or the disk is full

Accordingly I have marked this as Windows only 
(but note care that I have no ability to test this on Linux).

Linux, Audacity 2.4.1 and 2.4.2:

When running out of space when recording, I initially saw the dropout warning message. On closing that error message the out of space "File error" then appeared. There was no crash.

When running out of space on import, the out of space warning appears as expected. There was no crash.

(In reply to Paul L from comment #16)
> (In reply to Leland Lucius from comment #9)
> 
> Apologies Leland, I meant that Peter was guessing that this was on all
> operating systems but I believed this was not so on Mac.

Nope, it is me that must apologize.  After reading this I went back and saw that you were responding to Peter, not me.  So this was entirely my bad.

I'm having trouble getting CMake to build latest head on my Windows box, and hope to figure it out with Leland's help.

But I did manage to build 2.4.0 using VS2019 and the old VS solutions in win/, and reproduced the problem and found a fix.

Please verify with the CMake build.

https://github.com/audacity/audacity/commit/278b40c50d077bd84bc56762c9efc417d836c484

Tested okay on Win10, Catalina, and Ubuntu 20.

On Win10, the crash has gone and the correct message dialog appears.

On Catalina, the message dialog is displayed without the long delay.

On Linux, still good as before.

(In reply to Paul L from comment #20)
Tested on W10 with Audacity 2.4.2 278b40c

This now works properly again with no crash, Audacity stopped the import and the informative error message displayed

(In reply to Paul L from comment #20)
Tested on macOS 10.15.5 with Audacity 2.4.2 278b40c

Works fine on Mac as well, with the import stopped and the informative error message displayed