Apache OpenOffice (AOO) Bugzilla – Issue 124392
CRASH when close particular document after having applied style
Last modified: 2017-05-20 10:35:44 UTC
Currently I suffer from a lot of crashes, always in the moment when I close a very simple DRAW document after several edits. Might be related to "Bug 123451 - CRASH when close complex drawing with many slides after many edits ", but that was only for very complex documents. Unfortunately I currently do not know how to make that reproducible.
Documents are similar to Attachment 82828 [details] for Bug 122417
No noticeable problem with attachment 82828 [details] AOO410m14(Build:9760) - Rev. 1573062 2014-03-01_04:11:01 - Rev. 1573123 Debian
Again a crash when I had finished Attachment 82835 [details] for Bug 124400. Crash might be related to 'File -> Properties -> Security -> open write protected'? Still no idea how to make that reproducible.
Created attachment 82836 [details] Sample Document Steps how to reproduce with "AOO 4.0.1 Release – German UI / German locale [AOO401m5(Build:9714) - Rev. 1524958 2013-09-20 11:40:29]" on German WIN7 Home Premium (64bit)", “historic” 4.0 User Profile used for all predecessor versions 1. From AOO Start Center open attached Sample document "SampleDocument002.odg", save under new name 2. Click 'Edit File' icon in Standard Toolar to finish read only mode 3. Double click Heading Text, selcet all text, apply Style "Title 1" Using Sidebar > Very large Title 4. Reduce size using bottom left and right control points of text box so that title fills a little more than sheet width (might be that you will have to remove checkmark 'Format -> Text -> Auto width' 5. Save document (disk Icon) 6. Reduce width of Title to text area 7. Menu 'File -> Properties -> Security -> Check "Open read only"' 8. Save document (disk Icon) 9. Close - X at top right AOO window corner > CRASH
Still Reproducible with server installation of "AOO 4.1.0-Beta – French UI / French locale - [AOO410m14(Build:9760) - Rev. 1573601 2014-03-03 17:47:48]" on German WIN7 Home Premium (64bit)", own separate user profile.
I also reproduce the crash with a more simple proceeding: 1. From AOO Start Center open attached Sample document "SampleDocument002.odg", save under new name 2. Click 'Edit File' icon in Standard Toolar to finish read only mode 3. Double click Heading Text, selcet all text, apply Style "Title 1" using Sidebar > Very large Title 4. Click into sheet outside title 5. Single click on title so that control points appear (but not text edit mode) 6. Menu 'File -> Properties -> Security -> Check "Open read only"' 7. Save document (disk Icon) 8. Close - X at top right AOO window corner > CRASH
Additional Info --------------- (a) Already Reproducible with server installation of "AOO 4.0.0 Final – German UI / German locale [AOO400m3(Build:9702) - Rev. 1503704 2013-07-16 14:54:56 (Di, 16 Jul 2013)]" on German German WIN7 Home Premium (64bit)", Common 4.0-dev User Profile (b) Was still ok with 3.4.1 (c) With 4.0.0 I only was able to reproduce the crash if I apply "Title 1" Style from Sidebar, no crash when I use <f11> - Styles pane (What would explain that there is no crash with 3.4.1)
@Rainer: Thanks for your effort to make this reproducible. It works (i.e. crashes) for me, too. First details: Crash is triggered in framework::Desktop::terminate() (framework/source/services/desktop.cxx:425) when the local list of termination listeners is released.
Some final remarks: Most simple way to reproduce for me: Open new Draw document from Start Center -> Text Box -> Type "y" -> <control+a> to select all textbox contents -> apply any style from Styles -> Save under new name -> Terminate. c): No longer reproducible for me that style from <f11> will not crash (d) Also character in rectangle and Smiley will crash, probably in all shapes
*** Issue 123451 has been marked as a duplicate of this issue. ***
I can reproduce the crash with the simple steps from comment 9. It crashes with the sidebar styles panel or the <F11> dialog. But it makes a difference whether I press <Ctrl-Q> (no crash) or press on the closer button in the window frame (crash). It also crashes in Impress.
I can reproduce the crash with even fewer steps: 1. Create new Draw document. 2. Select the "Styles and Formatting" panel in the sidebar. 3. Double click on any style. 4. Click on the closer in the window frame (Ctrl-Q does not work). -> Crash
(In reply to Andre from comment #12) > I can reproduce the crash with even fewer steps: > > 1. Create new Draw document. > 2. Select the "Styles and Formatting" panel in the sidebar. > 3. Double click on any style. > 4. Click on the closer in the window frame (Ctrl-Q does not work). > > -> Crash Confirmed with AOO410m14(Build:9760) - Rev. 1573601 2014-03-03 17:47:48 (Mo, 03 Mrz 2014) Win 7
@Edwin: We know about WIN7, can you contribute results with Linux?
I have traced the crash to the destruction of the sidebar: 1. Clicking on the closer results in a call to 2. framework::Desktop::terminate(), 3. that deletes all child windows, the SidebarChildWindow being one of them, 4. that leads to deletion of the SidebarDockingWindow and SidebarController and 5. to deletion of deck and panels. 6. When finally the SfxTemplatePanelControl (the implementing class of the 'Styles and Formattting' panel) is destroyed this somehow leads to a memory overwrite back in Desktop::terminate() I can not say whether the last is cause or symptom of the crash. Debugging the destruction of SfxTemplatePanelControl is made a bit inconvenient by the fact that the crash goes away when I compile the templdlg.cxx file (which contains the source code for SfxTemplatePanelControl) with debug information.
Looks like this is not a sidebar specific problem. Another way to trigger the crash: 1. Create new Draw document. 2. Press F11 to open the "Styles and Formatting" stand-alone dialog. 3. Assign style with double click. 4. Click on the closer of the document or of the application window. -> Crash
(In reply to Andre from comment #16) > Looks like this is not a sidebar specific problem. Another way to trigger > the crash: > > 1. Create new Draw document. > 2. Press F11 to open the "Styles and Formatting" stand-alone dialog. > 3. Assign style with double click. > 4. Click on the closer of the document or of the application window. > > -> Crash Confirmed with AOO410m14(Build:9760) - Rev. 1573601 2014-03-03 17:47:48 (Mo, 03 Mrz 2014) Win 7 PS no access to debian at the moment
Oliver (orw) has found the root cause (beware, this is not for the faint of heart): - A double click on of the styles is handled (eventually) by SfxCommonTemplateDialog_Impl::Execute_Impl(). - It executes a slot call of SID_STYLE_APPLY. - This call is made synchronously. - The same method is also used to handle, for instance, SID_STYLE_NEW (triggered by right mouse click in "Styles and Formatting" dialog, then context menu->New...). This opens a dialog that is model for the application window but not modal with respect to the "Styles and Formatting" dialog. That means that while the "Graphics Style..." dialog is open, and the SID_STYLE_NEW slot call is still pending (remember, it is made synchronously), the S&F dialog can be closed. - To handle the destruction of the SfxCommonTemplateDialog_Impl class (which implements the S&F dialog) right in the middle of one of its methods, somebody came up with the clever idea to introduce a class named Deleted. It contains a single boolean which is initialized to false and set to true in the destructor of SfxCommonTemplateDialog_Impl. This allows this (pseudo) code: Deleted aDeleted; make slot call that possibly deletes this if (aDeleted.IsDeleted()) return without touching any member variables - In order to allow the ~SfxCommonTemplateDialog_Impl to access the local Deleted object on the stack, its pointer is stored in the member pbDeleted. - In our case (processing the SID_STYLE_NEW slot) the pbDeleted member is set to the pointer of the a local variable on the stack but it is not reset when the method is left. - Therefore, when the closer is clicked, pbDeleted still holds a pointer. This pointer now points to some random memory on the stack. Accessing and modifying it leads to the crash.
I forgot to mention that related bug (bug 100110), that essentially had the same root cause, was already fixed in SfxCommonTemplateDialog_Impl::Execute_Impl(). Our special case, however, has not been addressed.
Created attachment 82847 [details] Avoid crash after when closing document after assigning style. Release pointer to local bool as soon as possible.
Created attachment 82848 [details] Add missing virtual keyword to some destructors. Added missing virtual keyword to some destructors. Added missing dispose call for some members.
Comment on attachment 82847 [details] Avoid crash after when closing document after assigning style. I am fine with this fix of this crude technique
"af" committed SVN revision 1576748 into trunk: 124392: Avoid crash on close after assigning style.
Fixed by applying both attached patches.
Requesting release blocker status: data loss, easy to reproduce (three clicks).
crashes means potentially data loss and this classifies this issue as showstopper
"af" committed SVN revision 1577162 into branches/AOO410: 124392: Avoid crash on close after assigning style. (merged from trunk)
The fix is now applied to both trunk and branch AOO410.
No crash following comment 12, comment 16 AOO410m14(Build:9760) - Rev. 1573062 2014-03-01_04:11:01 - Rev. 1573123 Debian
No crash following comment 12, comment 16 on branch AOO410 AOO410m15(Build:9761) - Rev. 1583666 2014-04-01 13:53:14 (Di, 01 Apr 2014) I will close this bug based on my verification on branch together with Edwin's verification on trunk(comment 29)