Apache OpenOffice (AOO) Bugzilla – Issue 51969
Crash in Impress
Last modified: 2005-10-14 14:48:24 UTC
1) Start ./soffice -impress 2) Click "Create" to create a new empty presentation 3) In "Layouts", right-click on "Title slide" and choose "Insert slide" 4) Click "Click to add title" in the header and enter few letters 5) Repeat 3) and 4) until a crash (usually in 2-3 repeats, but may require more). This is the backtrace I got: (gdb) bt #0 0x00000050 in ?? () #1 0x5ce85671 in sd::ViewShell::GetMenuState (this=0x5d470340, rSet=@0x5eb4c1a0) at /local/ooo-build/ooo-build/build/src680-m114/sd/source/ui/view/viewshe3.cxx:1121 #2 0x5ce9f35b in sd::DrawViewShell::GetMenuState (this=0x5d470340, rSet=@0x5eb4c1a0) at /local/ooo-build/ooo-build/build/src680-m114/sd/source/ui/view/drviews7.cxx:236 #3 0x5cec61ba in SfxStubDrawViewShellGetMenuState (pShell=0x5d470340, rSet=@0x5eb4c1a0) at sdslots.hxx:1056 #4 0x5a04ffec in SfxDispatcher::_FillState () from ./libsfx680li.so #5 0x5a05a1a0 in SfxBindings::Update_Impl () from ./libsfx680li.so #6 0x5a05c9b9 in SfxBindings::NextJob_Impl () from ./libsfx680li.so #7 0x5a05c850 in SfxBindings::LinkStubNextJob_Impl () from ./libsfx680li.so #8 0x556d1fe1 in Timer::Timeout () from ./libvcl680li.so #9 0x556d1cc9 in ImplTimerCallbackProc () from ./libvcl680li.so #10 0x5805014c in SalData::Timeout () from ./libvclplug_gen680li.so #11 0x5804f775 in SalXLib::CheckTimeout () from ./libvclplug_gen680li.so #12 0x5804fa27 in SalXLib::Yield () from ./libvclplug_gen680li.so #13 0x58059e9f in X11SalInstance::Yield () from ./libvclplug_gen680li.so #14 0x556cb6a0 in Application::Yield () from ./libvcl680li.so #15 0x556cb5b5 in Application::Execute () from ./libvcl680li.so #16 0x0806eb2f in desktop::Desktop::Main () #17 0x556d1063 in SVMain () from ./libvcl680li.so #18 0x08068451 in sal_main () #19 0x080683ec in main () Setting priority to P2 because I think it is a crash in basic functionality.
kendy: I can't reproduce with my build of m117.
... but I reproduced with my Windows build of m117.
Cannot reproduce this on an internal m116. AFAIK there is no official m116 or m117 available, right? @kendy: Which OS do you use (I assume Linux)? Thanks in advance.
wg: Linux, yes. Sorry, I forgot to set OS; but as long as pjanik has reproduced it on Windows... ;) I have reproduced it also with the official m113 from www.openoffice.org.
Sorry, still not reproducible. If pjanik does not use the offical build to reproduce it does not help much. Which Linux do you use, any other infor for reproducing? Thanks.
I can reproduce it with Sun official build m113, Win XP, german The crash occurs only if I don´t leave the title text box (stay in editing mode) before I insert the next slide.
wg: I use SUSE 9.3, 32bit build on AMD64 machine. My suspection is that pUndoManager we get using ImpGetUndoManager() in ViewShell::GetMenuState( SfxItemSet &rSet ) (file sd/source/ui/view/viewshe3.cxx) is already destructed for some reason, but not set to NULL; then the check for non-NULL succeeds, but results in a crash. I have no idea about the 'sd' code, but I tried to add a destructor to class ActiveShellDescriptor (sd/source/ui/view/ObjectBarManager.cxx) that just sets mpShell to NULL; it did not help. As to the reproducibility: Sometimes I have to create 30-40 slides this way to see the crash. I repeat the steps quite quickly. I'll attach a stderr output I get when compiled with debug=true; no idea whether it could help, but... ;-)
Created attachment 28044 [details] Log until the crash.
"but results in a crash": I meant "but results in a crash later in if(pUndoManager->GetUndoActionCount() != 0)"
->AF: Can you have a look at the code if the crash is possible there? Thanks.
This is a known issue, but one that no developer around here at Sun has yet been able to reproduce. It is covered by the (internal) bug #122402#. There exists a potential fix by MBA based on guesses based on the stack traces. This is part of child work space fwk18. The observations stated above and the description of how to reproduce the crash are very valuable. I will try to reproduce this crash on my machine, just in case that the fix mentioned above does not work.
I'll extract fwk18 and I'll try here as well. Thank you!
I tried to reproduce it on an m118 Windows XP build but without success. So it would be really great if you, kendy, would try the (hopefully) fix. You just have to patch the file sfx2/source/control/dispatch.cxx to revision1.37.138.1.
Unfortunately, sfx2/source/control/dispatch.cxx, revision 1.37.138.1 did not help :-(
Thats bad news. I will take a closer look at this bug. Maybe your observations are the key to a fix. I set the target to OO 2.0.1
Issue 41306 is related to this one. It fixes a problem with the undo manager. I just do not know whether that issue is just another symptom of an underlying problem.
I have been able to reproduce this crash. Maybe there is more than one problem involved, though. The crash that I have observed is related to issue 48778. The fix for this is integrated in the m118 build. What happens is this: While the text edit mode is active the undo manager of the edit engine that handles this text editing is used. This is done by calling SetUndoManager() at the top level view shell. When the text editing ends this undo manager is destroyed together with the edit engine. To handle this in sd::View::EndTextEdit() the undo manager used by the top-level shell is replaced by that of the document. Unfortunately there is a place (ViewShellManager::Deactive()) where the EndTextEdit() method of one of the base classes is called. As one result the undo manager of the top-level shell is not replaced and an access to the now destroyed undo manager of the edit engine crashes the Office. This is covered and fixed by issue 48778. There still is a minor problem in sd::View::EndTextEdit(). First the edit engine is destroyed (by calling EndTextEdit() of the base class) and *after* that the undo manager used by the top-level shell is replaced. An access to the undo manager in that short time span may still lead to a crash. I will have to fix this for this issue. However, the stack trace shown above does not fit into this picture. It may indicated another error.
Fixed. Additionally to the fix for issue 48778 I made a small correction in sd::View::EndTextEdit(): the active undo manager now is now restored before the edit mode is left. This eliminates the short time in which the deleted undo manager is still registered as the active one. Affected file: /sd/source/ui/view/sdview.cxx rev. 1.41.60.1
Back to QA for verification. re-open issue and reassign to wg@openoffice.org
reassign to wg@openoffice.org
reset resolution to FIXED
Verified in CWS.
Tested in master m133. Closed.