Apache OpenOffice (AOO) Bugzilla – Issue 95496
loadComponentFromUrl() freezes
Last modified: 2013-08-07 15:31:14 UTC
On Linux (tested: Debian Etch with KDE), loadComponentFromUrl() sometimes causes OOo to freeze when there is not yet a visible OOo window. Opening an OOo window by other means (e.g. launching soffice) will unfreeze the frozen process. Sometimes switching between Windows seems to unfreeze it, too. I don't see the issue under Windows. Maybe it's a race condition related to some X11 window manager events? The issue is not present on any of the 2.x versions. Since our users usually open all their templates via a custom launcher that trips this bug, this issue is a showstopper for our upgrade to OOo 3.0 on Linux. The attached Java program demonstrates the issue: 1. Close all OOo Windows. Disable the quickstarter (if there is a working quickstarter for Linux in the first place) 2. Run java -jar LoadcomponentFromUrlForever.jar 3. The Java program continually starts OOo, opens a new document, then terminates OOo. Sooner or later it will freeze in the "Loading..." stage, meaning that loadComponentFromUrl() does not return. 4. OOo will wake up if you run "soffice" on another console. Sometimes switching windows also seems to wake it up. The programs main loop is this: while (true) { try { System.out.println("Init..."); init(Bootstrap.bootstrap().getServiceManager()); System.out.println("Loading..."); loadComponentFromURL("private:factory/swriter", true, MacroExecMode.ALWAYS_EXECUTE_NO_WARN, false); System.out.println("Waiting..."); System.out.println("Closing..."); desktop.terminate(); } catch (DisposedException x) {} } The complete source code is contained in the JAR file.
Created attachment 57499 [details] JAR application to demonstrate the issue
I can confirm this issue. This is really an important issue for us in munich and a regression since loadComponentFromURL works reliable in the OOo 2.x series. Our WollMux uses loadComponentFromURL to open the templates organized by WollMux. Now WollMux no longer opens templates reliable. As a result this issue forces us to use the OOo 2.x series instead of OOo 3.x. On the other side we so strongly require the new file-locking features provided by OOo 3. Our divisions (the "Referate") will not switch off their current MS-Office installations on about 14000 PCs until there is a satisfying file locking available with OOo. With OOo 2.x the file locking is not satisfying, but we hope with OOo 3.0.1. It would be a pity if file-locking was OK with OOo 3.0.1 but this regression still remains. So please take this issue serious and target it for 3.0.1 (if possible in any way).
This is an important issue, we should try to fix it ASAP. Depending on effort and risk even a target 3.0.1 seems plausible to me, but let's start with 3.1.
mux2005: I was able to reproduce the problem you described. The office was not freezed ... but the client side (means your Java code) was hanging inside a remote request ... where the office was restarted successfully ... waiting for new requests ... but client and office was not connected at that point any longer. So it's a problem related to our UNO bridge. In that area a lot of bugs was fixed and so I've tried a DEV300 m35 version of OOo. Doing so I was not able to reproduce the problem any longer (at least not within a long running test - running ~2 hours). Please check if such DEV300 m35 fix your problem and report here inside these issue. THX & Regards
m35 does indeed seem to fix our issue. Would it be possible to put the new bridge code into 3.0.1? As I've described, this issue is partially blocking our Windows->Linux migration. We'd like to get the fix as soon as possible.
as->sb: Please take over these task because you fixed the original problem for an OOo 3.1 version ... to see if its possible to get that fix for an OOo 3.0.1 too. THX.
@mux2005: Unfortunately, I do not have time to do this myself right now, but if you might want to try whether the four source files mentioned in issue 63110 (in sal and bridges) do fix your problem, we could consider back-porting that issue's fix.
I built the OOo 3.0.0 sources with the complete bridges/source/remove/urp directory from trunk (using just a subset of these files caused the compile to fail because of the renamed abort->abortThread method) plus sal/osl/unx/thread.c from trunk. Unfortunately this doesn't fix the problem. Any other candidates?
@mux2005: Sorry, no idea. Looking at svn log -c 261996 -v svn://svn.services.openoffice.org/ooo/trunk, I see no other integrations through CWS sb93 that appear relevant. (What you could do is go back through DEV300m34, DEV300m33, ..., to see which was the first milestone where your problems was fixed.)
I've now found out that the problem seems to affect only my own builds, not those downloaded from openoffice.org. This means that my comment that m35 fixes this issue was not correct, because I did that test with a downloaded m35. The test with the backported bridges code on the other hand was done (obviously) with my own build. So this issue does not actually seem to be related to the UNO bridge code itself, but seems to be a build issue. Now I'm trying to pinpoint the problem. I use the vanilla sources from openoffice.org, not ooo-build, however I do usually configure it with several --with-system-... switches. I'm currently doing a build without those so see if this is responsible but even if this turns out to be the case there's still the question which library is responsible. Are there any likely culprits? Are there other configure switches that could affect this issue? Is there documentation on how the official builds are done? @as: You say you were able to reproduce the problem. Was that with a build from openoffice.org or one of your own?
@mux2005: "Is there documentation on how the official builds are done?" The environment for Sun Hamburg builds is not set up via configure, but via a home-brewed "setsolar" tool (reading data from solenv/config/sooo300.ini, expecting a base line tool chain at a certain place); in general, it uses none of the corresponding configure --with-system features.
@as: please see mux2005's question at <#desc11> @mux2005: feel free to assign back to me once you know how your build affects the problem
as->mux2005: I've used an "in house" built here in Hamburg ... means at least an OOo build ... not vanilla ones.
I have now thoroughly examined this issue. The following summarizes my findings 1. The issue affects all builds with --enable-kde. It DOES affect builds downloaded from http://www.openoffice.org. I have only tested in a KDE environment, but I guess the issue will NOT occur in a non-KDE environment. Keep that in mind when reproducing the bug. 2. You can only see the issue if you have changed the icon set from "Automatic" to something else. That's the reason for my contraditory info on which versions are affected. In some tests I had a shared extension installed that preconfigures some OOo settings, including the icon set. 3. This issue is a duplicate of issue 65999. Apparently we made a mistake during our test to see if the issue was resolved and erroneously closed it. As a consequence we switched from patching our build to replace all icon sets with the classic icons to using the extension mentioned in 2. As that extension made it into our deb install sets we started seeing the issue again but didn't make the connection until now. So to repeat: This is not a new issue. This issue has been around since OOo 2.0.2 at least. It seems to have gotten a little milder in more recent versions, as issue 65999 says that OOo freezes for good, whereas now it can be revived by calling "soffice". Anyway, this renewed examination of the issue has had some good at least, since now we know that it is somehow KDE specific (see 1). Maybe that helps getting it fixed. Since this new issue contains all the current information and a ready-to-run JAR file for reproducing (the old issue had only source which confused the QA person involved), I suggest keeping this one open rather than reopening the old one and closing this one as dup. But adjusting the version down to 2.0.2 may be useful. 4. One interesting aspect that I think I haven't mentioned before is the following: If you call loadComponentFromUrl() and you hit the bug so that loadComponentFromUrl() hangs and then you wake up OOo by calling swriter, you end up with 2 unnamed documents. If you close the one created by loadComponentFromUrl(), the whole OOo will terminate, closing ALL open documents without user interaction, even if they have unsaved changes! So this issue can cause data loss.
@hdu,pl: any ideas? (the most relevant information is probably in the original description and <#desc15>, the exchange in between probably headed in a wrong direction)
@tz: can somebody from QA please try to reproduce this (I don't have a KDE environment handy to begin with...)
@tz: ping
Hi sb, TZ isn't the owner you think it is. It isn't me! I found this issue only, because I checked the last OOo 3.1 issues. Please ask SBA or the IT team to get a KDE system. We should have virtual machines for such a platform.
back to sb
@sba: please see <#desc17>
OOo 3.1 is released. Therefore the target of this issue is obsolete. Please recheck the issue and find a concrete target for this issue. Until this I set this issue to target 3.x.
This issue is still there with OOO320m19.
The reporter considered this one a duplicate. Setting as such. *** This issue has been marked as a duplicate of 65999 ***
Closing duplicate issue.
As I explained in my comment, issue 65999 was erroneously closed. As the analysis here is more detailed and has a ready to run testcase, I am reopening this issue here rather than 65999.
Reassigned to TM.