GP-2265 - Fixed printing of buffer exception when closing program; added

code for exception being printed in rare timing condition in tables

Ghidra/Features/DecompilerDependent/src/main/java/ghidra/app/extension/datatype/finder/DecompilerDataTypeReferenceFinder.java

@@ -90,7 +90,9 @@ public class DecompilerDataTypeReferenceFinder implements DataTypeReferenceFinde
 		}
 		catch (InterruptedException e) {
 			Thread.currentThread().interrupt(); // reset the flag
-			Msg.debug(this, "Interrupted while decompiling functions");
+			if (!monitor.isCancelled()) {
+				Msg.debug(this, "Interrupted while decompiling functions");
+			}
 		}
 		catch (Exception e) {
 			Msg.error(this, "Encountered an exception decompiling functions", e);

Ghidra/Framework/DB/src/main/java/db/buffers/BufferMgr.java

@@ -1038,6 +1038,12 @@ public class BufferMgr {
 	 */
 	private void handleCorruptionException(Exception exception, String errorText)
 			throws IOException {
+
+		if (exception instanceof ClosedException) {
+			// not a corruption exception, but rather it can happen when closing the database
+			throw (IOException) exception;
+		}
+
 		Msg.error(this, errorText, exception);
 		corruptedState = true;
 		if (exception instanceof IOException) {
@@ -1651,8 +1657,7 @@ public class BufferMgr {
 				monitor.checkCanceled();
 				if (index >= origIndexCount) {
 					// Newly allocated free buffer
-					BufferNode node =
+					BufferNode node = createNewBufferNode(index, currentCheckpointHead, null);
-						createNewBufferNode(index, currentCheckpointHead, null);
 					node.isDirty = true;
 					node.modified = true;
 					node.empty = true;

Ghidra/Framework/Docking/src/main/java/docking/widgets/table/threaded/IncrementalLoadJob.java

@@ -61,9 +61,8 @@ public class IncrementalLoadJob<ROW_OBJECT> extends Job implements ThreadedTable
 			doExecute(monitor);
 		}
 		catch (Exception e) {
-
 			// InterruptedException handled via notification below
-			if (!hasCause(e, InterruptedException.class)) {
+			if (!hasCause(e, InterruptedException.class) && !monitor.isCancelled()) {
 				// TODO: is there a better way to handle exceptions?  If we don't grab it and show
 				// it here, then it will be handled by the Worker, which just prints it to the
 				// console. Plus, handling it here gives us a chance to notify that the process is
@@ -136,8 +135,7 @@ public class IncrementalLoadJob<ROW_OBJECT> extends Job implements ThreadedTable
 			// -A block on jobDone() can now complete as we release the lock
 			// -jobDone() will notify listeners in an invokeLater(), which puts it behind ours
 			//
-			Swing.runLater(
+			Swing.runLater(() -> updateManager.addThreadedTableListener(IncrementalLoadJob.this));
-				() -> updateManager.addThreadedTableListener(IncrementalLoadJob.this));
 		}
 	}
 
@@ -192,12 +190,23 @@ public class IncrementalLoadJob<ROW_OBJECT> extends Job implements ThreadedTable
 	private class IncrementalUpdatingAccumulator extends SynchronizedListAccumulator<ROW_OBJECT> {
 		private volatile boolean cancelledOrDone;
 		private Runnable runnable = () -> {
+
 			if (cancelledOrDone) {
 				// this handles the case where a cancel request came in off the Swing
 				// thread whilst we were already posted
 				return;
 			}
-			updateManager.reloadSpecificData(asList());
+			try {
+				updateManager.reloadSpecificData(asList());
+			}
+			catch (Exception e) {
+
+				// note: check for cancelled again, as it may have been called after the initial
+				//       check above if the cancel call was requested off the Swing thread.
+				if (!cancelledOrDone) {
+					Msg.error(this, "Exception incrementally loading table data", e);
+				}
+			}
 		};
 
 		private SwingUpdateManager swingUpdateManager =