Apparently, pUndoDoc must be reset before calling DeleteSdrUndoAction

...in ~ScUndoDeleteContents, otherwise (implicitly) resetting pUndoDoc only at
the end of ~ScUndoDeleteContents could cause a stack of calls into ~ScDocument,
~ScTable, ~ScColumn, ~ScPostIt that operates on stale pointers, as an
SdrCaptionObj is already destroyed while the ScPostIt still points to it.  See
the failing JunitTest_sc_unoapi_2 under ASan+UBSan at the end of
<http://ci.libreoffice.org/job/lo_ubsan/41/console>.

Regression introduced with ee9b3c1f1cb7445f0a7e76736e32fe81878f8d00 "Return the
std::unique_ptr itself here, not a raw pointer."

Change-Id: I5e1c6c3e46cb46388d186b63ce23b00fd298a32b

1 files changed, 1 insertions, 0 deletions

diff --git a/sc/source/ui/undo/undoblk3.cxx b/sc/source/ui/undo/undoblk3.cxx
index 5ebdd63da6bd..27fd815e32cc 100644
--- a/sc/source/ui/undo/undoblk3.cxx
+++ b/sc/source/ui/undo/undoblk3.cxx
@@ -102,6 +102,7 @@ ScUndoDeleteContents::ScUndoDeleteContents(
 
 ScUndoDeleteContents::~ScUndoDeleteContents()
 {
+    pUndoDoc.reset();
     DeleteSdrUndoAction( pDrawUndo );
 }