Issue 124760

Summary: crashes after moving merged shapes
Product: Draw Reporter: Martin <martinpeckhaus>
Component: formattingAssignee: Armin Le Grand <Armin.Le.Grand>
Status: CLOSED FIXED QA Contact:
Severity: Normal    
Priority: P3 CC: Armin.Le.Grand, awf.aoo, elish
Version: 3.3.0 or older (OOo)   
Target Milestone: 4.2.0   
Hardware: All   
OS: Windows 7   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
steps none

Description Martin 2014-04-28 08:50:48 UTC
Created attachment 83286 [details]
steps

i have more than one shape (e.g. a rectangle and an oval) which i want to merge.
after selecting the shapes and merging it, i only can move the new object 99 steps with the arrow keys (any directions). the 100th move causes a crash.

- this only happens if i don't release the new object once after merging
- this doesn't happen, when i release the new object after merging it. after selecting it again i can move it countless times without crashing
- this doesn't happen, when i release the new object after moving it between 0 and 99 movements. after selecting it again i can move it countless times without crashing
Comment 1 Andre 2014-04-28 09:16:35 UTC
I didn't count the number of steps but I can confirm the crash on trunk.
Comment 2 Oliver-Rainer Wittmann 2014-04-28 09:24:22 UTC
I reproduce the crash under Windows 7 with OOo 3.0.0 and OOo 3.3.0. I also did not count the moves - I just hold the arrow key
Comment 3 Armin Le Grand 2014-04-28 10:22:53 UTC
Yes, I can also reproduce this. What happens after 99 steps is that the oldest undo action gets deleted when the default of 100 undo steps is active. Could you please check in tools/options/memory if this is the case?
It should be, when I reduce to 10 steps it crashes after 10 steps. Strange is that it depends on reselections; I would guess that one of the objects before the merge operation is still used somewhere in the core (selection?) when it gets destroyed from the deletion of the oldes undo (which will reference these objects and thus destroy them)...
Comment 4 Martin 2014-04-28 10:43:37 UTC
I reduced the redo steps to 10 and it crashes now after 10 steps.
It also happens with Intersect and Subtract.
Comment 5 Oliver-Rainer Wittmann 2014-04-28 10:53:19 UTC
setting field Version back to 'OOo 3.3.0 or older' as the defect already occurs in former OpenOffice version.
Documentation for field Version is "Version - The oldest version of the software the issue can be found in."
Comment 6 Edwin Sharp 2014-04-28 11:43:54 UTC
Can not reproduce
AOO410m18(Build:9764)  -  Rev. 1589052
2014-04-22 12:11 - Linux x86_64
Debian
Comment 7 Armin Le Grand 2014-04-28 11:58:00 UTC
It only happens when not re-selecting the created shape, but directly start to move it (with cursor keys is fastest).
The undo stack gets quite sme actions for creating this (convert objects to polygon objects, merge, insert result object, delete source objects), but works well. Completely traveling through undo/redo works as intended.
Thus it must have to do with the undo stack deletion together with the selection. Looking deeper since the selection looks okay after the action; only one object is selected since the selection gets 'corrected' afterwards by excluding all objects which are not inserted to the model currently (see SdrMarkView::CheckMarked()).
Comment 8 Armin Le Grand 2014-04-28 15:39:49 UTC
Checked the whole object lifetime in the used undo stack, all okay, no error found. Added setting the selection to empty when selecting the new object, that makes it work. To find out the reason for the failure I digged into the selection correction stuff and found that there still is one part where three objctes are hold in the selection, it's the maAllMarkedObjects member of the sdr::ViewSelection. This is used in building the transitive hull of marked objects (see GetTransitiveHullOfMarkedObjects) to be able to handle all cases of ImpBroadcastEdgesOfMarkedNodes. It uses RTTI (here old ptr_cast) and that crashes on the correctly deleted objects. Not sure right now, but this can probably not even happen in aw080 anymore, sigh.

Update: Checked that, can indeed not happen, the handling of the connector stuff has completely changed/simplified, there is no sdr::ViewSelection anymore

To fix in the current code it is best to do what should have happened from the beginning: Set the correct selection in the operation. Adding that.
Comment 9 Armin Le Grand 2014-04-28 16:57:38 UTC
Okay, done.
Comment 10 SVN Robot 2014-04-28 17:10:22 UTC
"alg" committed SVN revision 1590709 into trunk:
i124760 ensure that only the created object is selected