To reproduce: 1) Have 2 formulas on writer 2) Copy one formula and paste it on the other, replacing it 3) Click Undo 4) Click Redo At this point writer crashes.
Just noticed that you don't even have to overwrite another formula, so to reproduce 1) Have 1 formula on writer 2) Copy the formula and paste it somewhere 3) Click Undo 4) Click Redo At this point writer crashes.
I have just tested the crash scenario on my computer and I cannot confirm the crash. Could you please attach a test document where you can always reproduce the bug? Tested LibreOffice 3.3.2 PPA on Ubuntu 10.10/Gnome 32-Bit Intel
Created attachment 46140 [details] Example of Crash case Attached test case. Pick any of the formulas(there are 4) in the odt, it crashes with any one of them. LibreOffice 3.3.2 on Ubuntu 11.04 (natty) 64-bit. Help-About also says: OOO330m19(Build:202) tag libreoffice-3.3.2.2, Ubuntu package 1:3.3.2-1ubuntu4
Thank you Alexander for the attached example document. As you described, Writer crashes. Reproducible: Always Severity of bug changed to "critical" (additional remark: it crashes, if only the formula (with the green marking around) is selected. It does not crash if any blank or other letter is copied together with the formula) Tested LibreOffice 3.3.2 PPA on Ubuntu 10.10/Gnome 32-Bit Intel
I just tested this bug in LO 3.4rc1 and the problem is still there. Writer always crashes by performing these steps described in comment 1.
I uploaded the strace.log to this bug/crash. You can find it here: http://wiki.documentfoundation.org/QA/Bugzilla-Attachments#Bug_36631_-_Writer_crashes_when_using_undo-redo_on_formula
I have reproduced it with LO-3.4.0-rc1. It looks quite annoying => added to the 3.4 most annoying bugs.
It is accessing an already deleted object. The following seems to work that around: diff --git a/sw/source/core/layout/fly.cxx b/sw/source/core/layout/fly.cxx index 47cb131..4c30a91 100644 --- a/sw/source/core/layout/fly.cxx +++ b/sw/source/core/layout/fly.cxx @@ -547,8 +547,8 @@ void SwFlyFrm::FinitDrawObj() } GetVirtDrawObj()->SetUserCall( 0 ); //Ruft sonst Delete des ContactObj delete GetVirtDrawObj(); //Meldet sich selbst beim Master ab. - if ( pMyContact ) - delete pMyContact; //zerstoert den Master selbst. +// if ( pMyContact ) +// delete pMyContact; //zerstoert den Master selbst. } /************************************************************************* But it is not a fix - I suppose the pMyContact should instead get to the undo/redo stack, or something, instead of leaking that. I cannot continue on this one at the moment - if anybody can take over, I'd appreciate that! :-)
Hmm, my initial expectation, without looking into the code here yet, would be that the SdrObjects created by writer to integrate their own frames into the drawing layer would be torn down and recreated from scratch on undo/redo. So the entry of the contact SdrObject into the undo might be the real bug here.
lets cut off those entries into the drawing undo stack of operations on the connector drawing object when a SwFlyFrmFmt insert is triggered (used by these type of classic writer SwFlyFrmFmts to hook themselves into the drawing layer if I'm not horribly behind the current state-of-the-art) http://cgit.freedesktop.org/libreoffice/writer/commit/?id=c234df7779b0e43e4433e71933c22f9e703da735 As an aside: restoration of the title and description of the SwFlyFrmFmt is *already* missing on the insert->delete->undo non-crashing route, so insert->undo->redo remains equivalent to insert->delete->undo in lossage. Presumably the SwUndoInsLayFmt itself should be the one that saves/restores the title and description of the object.
This is a Writer issue, therefore changed 'Component' accordingly.