Thank you for reporting this bug.

Crash with Rev. 1489073 Win 7

ALG: Crash in EmbeddedObjectContainer::GetEmbeddedObject in comphelper, given ::rtl::OUString& rName looks bad.

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

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.

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?

Sorry, please ignore my last comment.  It was meant for another issue.

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.

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.

"af" committed SVN revision 1569241 into trunk:
122576: Reset the docking area acceptor in the destructor.

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.

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.

Note:
Providing corresponding issue data to reflect that this issue is fixed for the next release.

Created attachment 82706 [details]
aoo freeze when open the sample file

the build version:
Dev Snapshot Apache OpenOffice 4.1.0 - full installation sets

test on AOO410m1(build:9750) - rev:1566593

Shao Zhi, please use the latest build to check again, e.g. 1571492

verified on MacOS 

OO410m14(Build:9760)  -  Rev. 1582710
2014-03-28 11:34:22 (Fri, 28 Mar 2014)

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)