I checked AOO3.4(r1327774, on windows 7 64bit), it is OK.
So mark it as 3.4.1_release_blocker.

Can't reproduce with AOO341 r1369110 on Windows 7 64bit.

I have reproduce the defect. Essential is to delete the user installation directory before trying to insert a slide.

I reproduced the defect on local build of AOO34 branch, rev. 1354891, on AOO 3.4.1 developer snapshot, rev. 1369110 and on local build of trunk, rev. 1367858.

After the defect once occurred it did not occur again. Thus, after I killed the hanging AOO process and restarted AOO I can insert slides in presentation documents.

Taking over.

The problem seems to be related to the inclusion of the presenter console extension.  Without this extension I can not reproduce the problem.

(In reply to comment #4)
> Taking over.
> 
> The problem seems to be related to the inclusion of the presenter console
> extension.  Without this extension I can not reproduce the problem.

There is a deadlock also when you "Click to add text" in the title:

* simply click to add text, 
* then leave the title by clicking somewhere else with the mouse, 
* there is a deadlock

Remove the user profile
Remove the Presenter Console extension OXT file from /opt/openoffice.org3/share/extensions/install/

No more deadlock

set release blocker flag 3.4.1

@Ariel: that is what we have noticed as well, seems to be a general problem that can potentially be triggered by any extension.

My current hypothesis is this:

Office runs in process 1, presenter console runs in process 2.
Office makes some call that results in notification of listener that lives in process 2.  That listener forwards the notification and calls back into process 1.
The bridge code seems to use two threads (in process 1), one for writing (or sending calls to process 2) and one for reading (or receiving calls from process 2).  That means that the forwarded notification ends back in process 1 but in a different thread from the original broadcast.  Any combination of two mutexes could easily lead to a deadlock.

I am currently working on verifying this hypothesis.  That is not as much fun as it may sound like.

Created attachment 78872 [details]
Use timeout when waiting on condition JobQueue::m_cndWait

I have not yet verified my hypothesis but have a possible fix (which would be consistent with it):

Use a timeout of 100ms when waiting on the m_cndWait condition in JobQueue::enter (main/cppu/source/threadpool/jobqueue.cxx).  When the osl_waitCondition() call that waits for m_cndWait to be set returns, then check whether there is at least one job waiting to be processed.  I not then continue with the loop and wait again on the condition.
This is essentially a semi-busy loop that polls every 100ms the state of the job queue.

The fix itself looks quite OK, however I am can not explain what exactly causes the deadlock.  It is possible that there are more elegant ways to fix it.

With the fix there is a crash at closing the office.  On Windows I see a message about a heap overflow.

That leaves us with these options for fixing this bug:

1. Fix the crash/heap overflow.

Did not try to fix this yet.  Probably a lengthy process.


2. Install the presenter extension (and the minimizer) differently.  Not as bundled extension like the dictionaries but as preregistered extension.

I tried this and failed.  When I change the functions add_bundled_extension_blobs() and add_bundled_prereg_extensions() in main/solenv/bin/modules/installer/scriptitems.pm so that the presenter is installed by add_bundled_prereg_extensions() then the office exits on first start without showing any application window.


3. Do not start a second (or n-th process) for extensions on first start.  Just install them and activate them on second start.

Tried this and failed.  When I change method BackendImpl::ComponentPackageImpl::processPackage_() in main/desktop/source/deployment/registry/component/dp_component.cxx to not call raise_uno_process() then the presenter is not correctly installed.


4. Do not ship with the presenter extension.

At the moment this looks like the only safe solution that does not take days to do.

Created attachment 78881 [details]
Install locally build extensions pre-registered.

Explored option 2 some more with the help of hdu and jsc.  Together we got this to work.  It turns out that the office shuts down in the middle of its initialization by design.  That is a preparation to restart itself, with the pre-registered extensions running in the main process.  I did not see this because in the debugger I start soffice.bin not soffice.exe.  This prevents the restart.

The attached patch causes all extensions that are specified via file:// URLs (in main/extensions.lst this is the case for the minimizer and the presenter extension) pre-registered, ie the extensions are unzipped and extensions databases are updated when the install set is build, not on first start.

"af" committed SVN revision 1371068 into branches/AOO34:
#i120476# Install locally built extensions (minimizer,presenter)

Fixed as explained above.

"af" committed SVN revision 1371679 into trunk:
#i120476# Install locally built extensions (minimizer,presenter)

Verify pass on Windows 7 and Redhat with AOO3.4.1 r1372282.

Steps:
1)Delete AOO user installation directory
2)Start OpenOffice.org , new a presentation.
3)Click Insert->Slide from main menu to insert a new slide.

Results:
1)There is no Freeze.
2)There are no oxts about Presentation in OpenOffice.org 3\share\extensions\install
3)There are oxt unzip files about Presenttion in OpenOffice.org 3\share\prereg\bundled