Avoid some unexpected recursions because of yields to event loop...

... See code comments.

Not proved to be a cause of data loss bugs, but they caused surprises when
trying to step in the debugger.

src/ProjectAudioManager.cpp

@@ -910,6 +910,10 @@ void ProjectAudioManager::OnAudioIOStopRecording()
 
             history.ModifyState( true ); // this might fail and throw
 
+            // CallAfter so that we avoid any problems of yielding
+            // to the event loop while still inside the timer callback,
+            // entering StopStream() recursively
+            wxTheApp->CallAfter( [&] {
                ShowWarningDialog(&window, wxT("DropoutDetected"), XO("\
 Recorded audio was lost at the labeled locations. Possible causes:\n\
 \n\
@@ -920,6 +924,7 @@ You are saving directly to a slow external storage device\n\
                   ),
                   false,
                   XXO("Turn off dropout detection"));
+            });
          }
       }
    }

src/SqliteSampleBlock.cpp

@@ -268,6 +268,15 @@ SqliteSampleBlock::SqliteSampleBlock(
 
 SqliteSampleBlock::~SqliteSampleBlock()
 {
+   if (mBlockID == 0) {
+      // The block object was constructed but failed to Load() or Commit().
+      // Just let the stack unwind.  Don't violate the assertion in
+      // Delete(), which may do odd recursive things in debug builds when it
+      // yields to the UI to put up a dialog, but then dispatches timer
+      // events that try again to finish recording.
+      return;
+   }
+
    // See ProjectFileIO::Bypass() for a description of mIO.mBypass
    if (!mLocked && !Conn()->ShouldBypass())
    {