Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Crash in Impress | ||||||
---|---|---|---|---|---|---|---|
Product: | Impress | Reporter: | kendy | ||||
Component: | code | Assignee: | wolframgarten | ||||
Status: | CLOSED FIXED | QA Contact: | issues@graphics <issues> | ||||
Severity: | Trivial | ||||||
Priority: | P2 | CC: | caolanm, issues, jr, khirano, pavel | ||||
Version: | 680m116 | Keywords: | needmoreinfo, oooqa | ||||
Target Milestone: | OOo 2.0.1 | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Attachments: |
|
Description
kendy
2005-07-14 15:46:47 UTC
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. |