Issue 122576 - Attempting to delete an Ole object crashes
Summary: Attempting to delete an Ole object crashes
Alias: None
Product: Writer
Classification: Application
Component: editing (show other issues)
Version: 3.4.0
Hardware: PC Windows, all
: P3 Major (vote)
Target Milestone: 4.1.0
Assignee: Andre
QA Contact:
Keywords: crash, regression
Depends on:
Reported: 2013-06-24 03:53 UTC by John Wright
Modified: 2017-05-20 10:35 UTC (History)
8 users (show)

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

Webpage clip featuring Alan Greenspan (26.54 KB, application/vnd.oasis.opendocument.text)
2013-06-24 03:53 UTC, John Wright
no flags Details
aoo freeze when open the sample file (115.10 KB, image/png)
2014-02-26 01:52 UTC, zhaoshzh
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description John Wright 2013-06-24 03:53:45 UTC
Created attachment 80903 [details]
Webpage clip featuring Alan Greenspan

I copied and pasted from a web page into OpenOffice Writer.

Pressing F5 to bring up the Navigator and then attempting to delete either of the Ole objects causes a crash.

I'm running MS Vista and OpenOffice 3.4.1

Thanks for looking into this.
Comment 1 Edwin Sharp 2013-06-24 09:53:16 UTC
Thank you for reporting this bug.

Crash with Rev. 1489073 Win 7
Comment 2 Armin Le Grand 2013-06-26 16:03:42 UTC
ALG: Crash in EmbeddedObjectContainer::GetEmbeddedObject in comphelper, given ::rtl::OUString& rName looks bad.
Comment 3 Rainer Bielefeld 2013-09-01 17:26:26 UTC
CRASH still  Reproducible with  "AOO 4.1.0-Dev – English  UI / German locale - [AOO410m1(Build:9750)  -  Rev. 1516435  2013-08-24]" on German WIN7 Home
Premium (64bit)", own separate user profile.

Already CRASH with 3.4.0, was OK with OOo 3.3.0, so REGRESSION
Comment 4 Andre 2014-02-14 15:34:32 UTC
A LayoutManager (for this document four are created) is destroyed and then called (as WindowEvent listener).  This post-mortem callback accesses resources that are no longer available (in my case a mutex that has been set to NULL in the meantime).

It should be enough to unregister the listener in ~LayoutManager.  I also have to look at why the LayoutManager is destroyed, ie what does it manage.
Comment 5 Andre 2014-02-17 14:57:59 UTC
I updated my local source tree to revision 1567914 and now I am not able to reproduce this bug anymore.  Does anybody else still see the crash?
Comment 6 Andre 2014-02-17 14:59:03 UTC
Sorry, please ignore my last comment.  It was meant for another issue.
Comment 7 Andre 2014-02-17 15:46:40 UTC
When I return from the WindowEventListener when I detect the called object has been deleted then there is no crash.  So it looks like the event callback of the dead layout manager is the main (and hopefully) only problem.

Deleting the OLE object seems to activate the OLE object first.  This in turn creates a couple of new layout managers.  I find that a bit unexpected.

I still have to figure out how to best keep track of the many registered window listeners.
Comment 8 Andre 2014-02-17 16:00:47 UTC
I really don't want to sound too negative, but the management of the window listeners really is a mess.  And that is not the only bad thing.  I can only hope that nobody uses the layout manager to create a docking window.  In method LayoutManager::createElement(), the section for handling element type "dockingwindow" not only registers itself as window listener at the newly created window (via impl_addWindowListeners()), it also calls
    m_pPanelManager->addDockingWindow( aName, xUIElement );
The problem with this line is that m_pPanelManger is a private member that is never initialized to a non-null value (and LayoutManager has no friends which would do that for it).  And really, whenever createElement() is called, m_pPanelManger is NULL.  It is so good, that the "dockingwindow" section is never activated.
Comment 9 SVN Robot 2014-02-18 09:21:56 UTC
"af" committed SVN revision 1569241 into trunk:
122576: Reset the docking area acceptor in the destructor.
Comment 10 Andre 2014-02-18 09:27:33 UTC
Just when I wanted to check in my changes I discovered that bug 124096 describes a very similar problem and had just been fixed with almost the identical solution (calling setDockingAreaAcceptor(NULL) from within disposing() when the frame is disposed).
To be on the safe side I added a similar call to the destructor of LayoutManager.

Calling setDockingAreaAcceptor(NULL) unregisters the window listeners.  But it has to be done before the frame is disposed or otherwise setDockingAreaAcceptor() leaves without doing anything.  For this reason the call in the destructor usually does nothing.  I added it just in case the frame is not disposed or disposed after the layoutmanager.  I think the later should be the case but then again LayoutManager itself is never disposed, so it looks like the destruction sequence is not so well defined.
Comment 11 Oliver-Rainer Wittmann 2014-02-18 10:14:04 UTC
Yes, this is more or less the same problem as bug 124096.
@Andre: I would like to have a further discussion on both solutions in the next days. I will get in contact with you.

Providing corresponding issue data to reflect that this issue is fixed for the next release.
Comment 12 zhaoshzh 2014-02-26 01:52:34 UTC
Created attachment 82706 [details]
aoo freeze when open the sample file
Comment 13 zhaoshzh 2014-02-26 02:08:38 UTC
the build version:
Dev Snapshot Apache OpenOffice 4.1.0 - full installation sets
Comment 14 zhaoshzh 2014-02-27 03:00:25 UTC
test on AOO410m1(build:9750) - rev:1566593
Comment 15 fanyuzhen 2014-02-27 14:01:09 UTC
Shao Zhi, please use the latest build to check again, e.g. 1571492
Comment 16 jsc 2014-04-01 09:46:25 UTC
verified on MacOS 

OO410m14(Build:9760)  -  Rev. 1582710
2014-03-28 11:34:22 (Fri, 28 Mar 2014)
Comment 17 jsc 2014-04-02 14:51:16 UTC
verified with AOO 4.1.0 RC on MacOS and Windows

AOO410m15(Build:9761)  -  Rev. 1583666
2014-04-01 13:46:49 (Tue, 01 Apr 2014)