Apache OpenOffice (AOO) Bugzilla – Issue 101666
Anchor picture as character,check record and delete picture,uncheck show,UNDO several times,crashes OOo
Last modified: 2017-05-20 11:13:26 UTC
Can reproduce it in OOo310m11 on WinXP and on Fedora9 How to reproduce it 1 Create a new Writer doc 2 Insert - Picture - From Files, to insert a picture 3 Right_click on the picture and select Anchor - as Character on the Context menu 4 Edit - Changes - check Record, then set cursor at the right of the picture, Backspace to delete the picture 5 Edit - Changes - uncheck show 6 Undo several times Result OOo crashes Expectation OOo works well Regards Li Meiying
Edit summary and priority
The ID of the error report is r8nfqkc
@amy2008: as usually, very accurate bug report! Nice catch! Thank you! :) @MBA: Please have a look: crash in the undo/redlining area. Reproduced in 3.1rc2
Stack is > svlmi.dll!SfxItemSet::Get() + 0x5a bytes C++ swmi.dll!SwUndoInsLayFmt::Undo() + 0x1d bytes C++ swmi.dll!SwDoc::Undo() + 0xbd bytes C++ swmi.dll!SwEditShell::Undo() + 0x117 bytes C++ swmi.dll!SwWrtShell::Do() + 0x67 bytes C++ swmi.dll!SwBaseShell::ExecUndo() + 0x95 bytes C++ swmi.dll!SfxStubSwBaseShellExecUndo() + 0xe bytes C++ sfxmi.dll!SfxDispatcher::Call_Impl() + 0x433 bytes C++ sfxmi.dll!SfxDispatcher::_Execute() + 0x23b bytes C++ sfxmi.dll!SfxBindings::Execute_Impl() + 0x4d2 bytes C++ sfxmi.dll!SfxDispatchController_Impl::dispatch() + 0xbee bytes C++ sfxmi.dll!SfxOfficeDispatch::dispatch() + 0x123 bytes C++ svtmi.dll!svt::AsyncAccelExec::impl_ts_asyncCallback() + 0x35 bytes C++ svtmi.dll!svt::AsyncAccelExec::LinkStubimpl_ts_asyncCallback() + 0xe bytes C++ tlmi.dll!Link::Call() + 0x11 bytes C++ vclmi.dll!vcl::EventPoster::DoEvent_Impl() + 0x12 bytes C++ vclmi.dll!vcl::EventPoster::LinkStubDoEvent_Impl() + 0xe bytes C++ tlmi.dll!Link::Call() + 0x11 bytes C++ vclmi.dll!ImplHandleClose() + 0x156 bytes C++ vclmi.dll!ImplWindowFrameProc() + 0x2e2 bytes C++ vclmi.dll!SalFrame::CallCallback() + 0x16 bytes C++ vclmi.dll!ImplHandleSalObjSysCharMsg() + 0x504 bytes C++ vclmi.dll!SalFrameWndProc() + 0x748 bytes C++ vclmi.dll!SalFrameWndProcW() + 0x30 bytes C++ user32.dll!77d48709() [Frames below may be incorrect and/or missing, no symbols loaded for user32.dll] user32.dll!77d487eb() user32.dll!77d70494() user32.dll!77d493df() user32.dll!77d70494() user32.dll!77d489e8() vclmi.dll!ImplDispatchMessage() + 0x15 bytes C++ vclmi.dll!WinSalInstance::AcquireYieldMutex() + 0x36 bytes C++ vclmi.dll!ImplSalYield() + 0x47 bytes C++ vclmi.dll!WinSalInstance::Yield() + 0x9f bytes C++ vclmi.dll!Application::Yield() + 0x3d bytes C++ vclmi.dll!Application::Execute() + 0x24 bytes C++ sofficeapp.dll!desktop::Desktop::Main() + 0x10ce bytes C++ vclmi.dll!ImplSVMain() + 0x64 bytes C++ vclmi.dll!SVMain() + 0x1c bytes C++ sofficeapp.dll!_soffice_main() + 0x81 bytes C++ soffice.bin!_main() + 0x16 bytes C soffice.bin!_WinMain@16() + 0x15 bytes C soffice.bin!__tmainCRTStartup() Line 574 + 0x35 bytes C soffice.bin!WinMainCRTStartup() Line 399 C kernel32.dll!7c816d4f() kernel32.dll!7c8399f3()
Pretty grim, normally when the graphic is deleted without redlining ownership of the SwFrmFmt is effectively passed over to an undo record for the delete. On undo of the delete, back it goes into the document, and the insert undo record's pointer to that SwFrmFmt remains valid. In this circumstance, deleting the graphic creates a SwRedlineUndo record which describes the range that has been marked as deleted. When show is unticked, the SwFrmFmt is deleted (if show is then ticked a new one is created). And the insert undo's record points to the non-existing original SwFrmFmt.
Hmm, using MoveToSection/MoveFromSection in the redline stuff instead of CopyToSection/DelCopyOfSection would workaround this by transferring the SwFrmFmt around instead of making a copy of it and deleting this original, but causes other problems later. redlining is such a horror
Reset assigne to the default "issues@openoffice.apache.org".