Issue 103116 - Impress crashes when moving picture by shift-dragging it.
Summary: Impress crashes when moving picture by shift-dragging it.
Alias: None
Product: Impress
Classification: Application
Component: editing (show other issues)
Version: OOo 3.1
Hardware: All Windows, all
: P2 Trivial (vote)
Target Milestone: OOo 3.1.1
Assignee: wolframgarten
QA Contact: issues@graphics
Keywords: crash, regression
Depends on:
Blocks: 101565
  Show dependency tree
Reported: 2009-06-26 07:36 UTC by kpalagin
Modified: 2009-07-21 12:20 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

sample file (333.85 KB, application/vnd.oasis.opendocument.presentation)
2009-06-26 07:38 UTC, kpalagin
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description kpalagin 2009-06-26 07:36:57 UTC
1. open attached .odp and click approx in the center of slide - you hit frame.
2. Hold Shift, hold left mouse button and drag the picture in the slide, 
release  mouse button, release Shift.
3. Keep repeating step 2. It can take from 2 to 10 repeats to crash Office.
Comment 1 kpalagin 2009-06-26 07:38:24 UTC
Created attachment 63219 [details]
sample file
Comment 2 kpalagin 2009-06-26 08:02:02 UTC
OO3.0 does not crash - regression.

I have sent several crash reports, specifying kpalagin@phxint and 
kpalagin@yahoo as contact addresses. Report IDs did not arrive yet (and 
probably never will).

Please consider fixing for 3.1.1.
Comment 3 kpalagin 2009-06-26 15:05:01 UTC
report ids are rdk8skc and rxv8skc.
Comment 4 kpalagin 2009-06-26 15:07:07 UTC
report ids are rdk8skc and rxv8skc.
Comment 5 stefan.baltzer 2009-06-29 11:58:49 UTC
Reproducible in DEV_300_m51 on Windows XP.
Comment 6 stefan.baltzer 2009-06-29 12:56:53 UTC
I did NOT manage to reproduce in OOO310_m11 on Linux (Suse).
Maybe Windows only.
Comment 7 jbf.faure 2009-06-29 20:23:13 UTC
No crash for me with OOo 3.1.0 FR/US under Ubuntu 8.04.
Comment 8 stefan.baltzer 2009-06-30 09:57:10 UTC
Could neither reproduce in DEV300_m50 on Solaris nor in DEV300_m51 on Max OS X
10.4. Set OS to "Windows, all" 
My crash in DEV300_m51 on Windows has stack ID 319176.

sba->aw: Please proceed, thx.
Comment 9 Armin Le Grand 2009-06-30 15:32:48 UTC
AW: Got the problem now. See the following stack:

 	svxmi.dll!SdrDragMethod::~SdrDragMethod()  Line 616	C++
 	svxmi.dll!SdrDragMove::`vector deleting destructor'()  + 0x7a bytes	C++
>	svxmi.dll!SdrDragView::EndDragObj(unsigned char bCopy=0)  Line 566 + 0x27
bytes	C++
 	sdmi.dll!sd::FuSelection::MouseButtonUp()  + 0x363 bytes	C++
 	sdmi.dll!sd::ViewShell::MouseButtonUp()  + 0x7c bytes	C++
 	sdmi.dll!sd::DrawViewShell::MouseButtonUp()  + 0x1b7 bytes	C++
 	sdmi.dll!sd::Window::MouseButtonUp()  + 0x1f bytes	C++
 	vclmi.dll!ImplHandleMouseEvent(Window * pWindow=0x05d3c3d0, unsigned short
nSVEvent=2, unsigned char bMouseLeave=0, long nX=828, long nY=625, unsigned long
nMsgTime=4107671, unsigned short nCode=8193, unsigned short nMode=7)  Line 829	C++
 	vclmi.dll!ImplHandleSalMouseButtonUp(Window * pWindow=0x05d3c3d0,
SalMouseEvent * pEvent=0x014be918)  Line 2088 + 0x48 bytes	C++
 	vclmi.dll!ImplWindowFrameProc(Window * pWindow=0x05d3c3d0, SalFrame *
__formal=0x05d3c690, unsigned short nEvent=4, const void * pEvent=0x014be918) 
Line 2417 + 0xd bytes	C++
 	vclmi.dll!ImplHandleMouseMsg(HWND__ * hWnd=0x000208c2, unsigned int nMsg=514,
unsigned int wParam=8, long lParam=40960828)  Line 3464 + 0x25 bytes	C++
 	vclmi.dll!SalFrameWndProc(HWND__ * hWnd=0x000208c2, unsigned int nMsg=514,
unsigned int wParam=8, long lParam=40960828, int & rDef=1)  Line 5892 + 0x15
bytes	C++
 	vclmi.dll!SalFrameWndProcW(HWND__ * hWnd=0x000208c2, unsigned int nMsg=514,
unsigned int wParam=8, long lParam=40960828)  Line 6324 + 0x19 bytes	C++
 	[Frames below may be incorrect and/or missing, no symbols loaded for user32.dll]	
 	vclmi.dll!ImplDispatchMessage(const tagMSG * lpMsg=0x014beb5c)  Line 189 +
0xa bytes	C++
 	vclmi.dll!ImplSalDispatchMessage(tagMSG * pMsg=0x014beb5c)  Line 705 + 0x9
bytes	C++
 	vclmi.dll!ImplSalYield(unsigned char bWait=0, unsigned char
bHandleAllCurrentEvents=0)  Line 723 + 0x9 bytes	C++
 	vclmi.dll!WinSalInstance::Yield(bool bWait=false, bool
bHandleAllCurrentEvents=false)  Line 780 + 0xf bytes	C++
 	vclmi.dll!Application::Reschedule(bool bAllEvents=false)  Line 481	C++
 	svxmi.dll!SvFileObject::GetData(com::sun::star::uno::Any & rData={...}, const
String & rMimeType={...}, unsigned char bGetSynchron='')  Line 189 + 0x8 bytes	C++
 	svxmi.dll!SdrGraphicLink::UpdateSynchron()  Line 175	C++
 	svxmi.dll!SdrGrafObj::ImpUpdateGraphicLink()  Line 574	C++
 Line 103	C++
sdr::contact::DisplayInfo & rDisplayInfo={...})  Line 254 + 0x8 bytes	C++
sdr::contact::DisplayInfo & rDisplayInfo={...})  Line 361 + 0x1a bytes	C++
& rDisplayInfo={...})  Line 402 + 0x13 bytes	C++
& rDragMethod={...})  Line 204 + 0x15 bytes	C++
 	svxmi.dll!SdrDragMethod::CreateOverlayGeometry(sdr::overlay::OverlayManager &
rOverlayManager={...})  Line 660 + 0x18 bytes	C++
 	svxmi.dll!SdrDragView::ShowDragObj()  Line 832	C++
 	svxmi.dll!SdrDragMethod::Show()  Line 622	C++
 	svxmi.dll!SdrDragMove::MoveSdrDrag(const Point & rNoSnapPnt_={...})  Line 1565	C++
 	svxmi.dll!SdrDragView::MovDragObj(const Point & rPnt={...})  Line 539	C++
 	svxmi.dll!SdrDragView::MovAction(const Point & rPnt={...})  Line 139	C++
 	svxmi.dll!SdrCreateView::MovAction(const Point & rPnt={...})  Line 269	C++

As can be seen, inside a MouseEvent (MoveAction) a reschedule is triggered which
executes the next event which is the MouseButtonUp event (the end drag event).
This deletes the DragStructures and data, so when returning, the MouseMove is
working on deleted data (this pointers of drag data). Is there no mechanism in
the applications that only one MouseEvent is handled at a time? Looking...
Comment 10 Armin Le Grand 2009-06-30 16:22:28 UTC
AW: The following circumstances have to be fulfilled to make this error happen:
- Linked graphic object with broken link
- FullDrag is on
- A qualifier has to be pressed during drag (SHIFT or e.g. CTRL)
- You need bad luck that the reschedule leads to a MouseButtonUp (in other
words: a MouseMove and a MouseButtonUp have to be directly lined up in the event

Loking for solutions is not easy. It seems that Application::Reschedule() in
SvFileObject::GetData is needed, but the developer who did this a decade ago
(jp) cannot be asked. Digging deeeper...
Comment 11 Armin Le Grand 2009-06-30 17:47:48 UTC
AW: It's theoretically not a regression, but an error in a new feature, the
FullDrag. The case with all the described circumstances did not yet happen.
Easiest way to solve this is to handle special the temporary full-drag object
for GraphicObjects with missing/broken link. When cloning that object, reset the
link. It's not needed for interaction; the current visualisation (by copying the
object itself) is sufficient. Sems to work well.
AW->SBA: Do You see this as 3.1.1? It's technically not a regression, but it
feels so from user's perspective. Switching off FullDrag is a workaround, too.
Comment 12 Armin Le Grand 2009-07-01 16:43:15 UTC
AW: Added to CWS aw074, committed patch, done.
Comment 13 kpalagin 2009-07-01 17:11:10 UTC
great job, thanks a ton!
We all love when issues are fixed this quick, but when developer also cares to 
document all his findings publicly it is terrific!
Comment 14 Armin Le Grand 2009-07-06 16:44:28 UTC
AW: Ckecked with build, works as expected.
Comment 15 Armin Le Grand 2009-07-07 09:56:25 UTC
AW->WG: Please review as described. Dragging around 5 times crashed in the old
Comment 16 wolframgarten 2009-07-09 09:19:26 UTC
Verified in CWS.
Comment 17 wolframgarten 2009-07-21 12:20:37 UTC
Tested in m52. Closed.