Apache OpenOffice (AOO) Bugzilla – Issue 65999
loadComponent hangs in -nologo mode after changing the icon-style from "Automatic" to "Default"
Last modified: 2013-02-24 21:07:33 UTC
Changing the icon-style (Tools->Options->OOo->View->icon-Style) from "Automatic" to something different (e.g. "Default") seems to affect LoadComponentFromURL, when soffice.bin runs in -nologo mode. In This case LoadComponentFromURL hangs and my example java-code (see below) produces the following error-message: CE> Xlib: unexpected async reply (sequence 0x34b)! Here is how to reproduce: 0) The problem occurs on kubuntu and debian-linux, using the official OOo2.0.2 RPMs (converted to debian via alien). I think this problem would also occur on other linux-systems, but I didn't prove! It doesn't occur on windows! 1) open writer, create a simple textdocument and save it as .ott (template) to /tmp/mytemplate.ott 2) call "Tools->Options->OpenOffice.org->View" and change the icon-style from "Automatic" to "Default" 3) quit OOo and all OOo-Instances (to ensure call "killall soffice.bin" at the console). This is necessary to ensure that creating a new XComponentContext (via UnoRuntime.bootstrap()) starts soffice.bin in -nologo mode. 4) run the above java-code (which simply tries a LoadComponentFromURL("file:///tmp/mytemplate.ott", ...)) Now the program doesn't return, and OOo hangs. After about two seconds, the already showed error-message gets printed, but OOo still hangs and also doesn't react on actions like a simple call of "swriter". The only way to get OOo running again is to kill all soffice.bin-processes. Here is one of the hanging processes (showed via ps aux): christo 11751 5.1 3.7 131440 37584 ? S 09:34 0:03 /opt/openoffice.org2.0/program/soffice.bin -nologo -nodefault -norestore -nocrashreport -nolockcheck -accept=pipe,name=uno4716928793418704527;urp; The strange the conditions are, they occur continously in our regular workflow... Of course the java code works fine under "normal" conditions. Changing the icon-style back to "Automatic" is a possible workaround. Now running the code, OOo opens a new document from the template "/tmp/mytemplate.ott", like expected. Here is the simple example java-code: import com.sun.star.beans.PropertyValue; import com.sun.star.comp.helper.Bootstrap; import com.sun.star.comp.helper.BootstrapException; import com.sun.star.frame.FrameSearchFlag; import com.sun.star.frame.XComponentLoader; import com.sun.star.uno.Exception; import com.sun.star.uno.UnoRuntime; import com.sun.star.uno.XComponentContext; public class LoadCompoProblem { public static void main(String[] args) throws BootstrapException, Exception { XComponentContext ctx = Bootstrap.bootstrap(); Object desktop = ctx.getServiceManager().createInstanceWithContext("com.sun.star.frame.Desktop", ctx); XComponentLoader loader = (XComponentLoader) UnoRuntime.queryInterface(XComponentLoader.class, desktop); if (loader != null) { loader.loadComponentFromURL("file:///tmp/mytemplate.ott", "_blank", FrameSearchFlag.CREATE, new PropertyValue[] {}); } } }
jsc -> as: can you check this, it seems to be one for you
Can someone confirm this please?
clutz, how do I run that java prog (if possible, step by step description is very much appreciated)? Also, do you see this problem on Windows?
clutz, how do I run that java prog (if possible, step by step description is very much appreciated)?
Created attachment 44553 [details] the example code as a java-sourcefile to make it easier to reproduce the bug
@kpalagin: yes, a linux system is required to reproduce the bug. Here is the required supplement for compiling and starting the java-program: 4a) download the attached LoadCompoProblem.java (which is the same code as shown above in a .java-file) 4b) open a terminal and call # cd <path of LoadCompoProblem.java-file> # export CLASSPATH=./:/opt/openoffice.org2.0/program/classes/jurt.jar:/opt/openoffice.org2.0/program/classes/juh.jar:/opt/openoffice.org2.0/program/classes/unoil.jar:/opt/openoffice.org2.0/program/classes/ridl.jar # /opt/jdk1.5.0_06/bin/javac LoadCompoProblem.java # /opt/jdk1.5.0_06/bin/java LoadCompoProblem maybe you will have to adjust some paths to fit for your system... Bevore calling "java LoadCompoProblem", please ensure that you have created the template /tmp/mytemplate.ott as mentioned in 1) above. In order to write done these instructions, I had reprocude the bug again for myself. I did that on my home linux-system that differs completely from the system I used to report the bug for the first time. As the bug could also be reproduced on my home system, I think thats enough confirmation for confirming the ticket (which is done hereby). On my home system, I have OOo2.0.4 (default sun-version) installed. If you have got a newer version of OOo installed on your system, it would be fine if you could confirm the bug for the newer version also. thanks for triggering the issue again!
.
AS->clutz: ... mmmhhh ... seams that these task does not occure with an actual OOo 2.2 build. Can you confirm that ?
as->clutz: back to you. Please reopen if these task occure again on a new build.
unfortunately the problem still occurs with OO 2.2.1
set target 3.0
issue is no longer reproducible in OOo 3.0 RC 3
close the invalid issue
*** Issue 95496 has been marked as a duplicate of this issue. ***