I'm suspicious of the: svdundo.cxx /SdrUndoInsertObj::Undo/ method - I
imagine it is removing a different object than the one it is intended to
do (which explains why the main text box in the body disappears, instead
of the header on undo ;-) - an off-by-one as it were. With this
debugging patch:

--- a/svx/source/svdraw/svdundo.cxx
+++ b/svx/source/svdraw/svdundo.cxx
@@ -759,17 +759,17 @@ void SdrUndoInsertObj::Undo()
     // Trigger PageChangeCall
     ImpShowPageOfThisObject();
 
-    DBG_ASSERT(pObj->IsInserted(),"UndoInsertObj: pObj is not inserted.");
     if (pObj->IsInserted())
     {
         ImplUnmarkObject( pObj );
 
-#ifdef DBG_UTIL
         SdrObject* pChkObj=
-#endif
         pObjList->RemoveObject(nOrdNum);
-        DBG_ASSERT(pChkObj==pObj,"UndoInsertObj: RemoveObjNum!=pObj");
-    }
+
+        fprintf (stderr, "UndoInsertObj: RemoveObjNum %p == pObj %p ordinal %d 
vs %d\n",
+                 pChkObj, pObj, (int)nOrdNum, (int)pObj->GetOrdNum());
+    } else
+        fprintf (stderr, "not inserted !\n");
 }
 
 void SdrUndoInsertObj::Redo()

I get:

UndoInsertObj: RemoveObjNum 0x969d9d8 == pObj 0x9d47390 ordinal 2 vs 0

Which explains the bad behaviour.

Quite -how- this undo list is supposed to keep it's nOrdNum synchronised
with whatever is going on in the sdpage is -totally- opaque to me; the
whole thing looks crazy from a lifecycle perspective.

It's deeply unclear to me that all this referencing by ordinal is at all
sensible - particularly vs. having a reference-counted object handle to
an immutable object.

It'd be great to have a translation of GetOrdNum vs. GetOrdNumDirect in
svx/inc/svx/svdobj.hxx - to try to grok what's going on there - if there
is a German speaker around.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/785518

Title:
  [Upstream] soffice.bin crashed with SIGSEGV in SdrEndTextEdit()

To manage notifications about this bug go to:
https://bugs.launchpad.net/df-libreoffice/+bug/785518/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to