Red Hat Bugzilla – Bug 164491
[sun java] writer wizards hang
Last modified: 2007-11-30 17:11:10 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6
Description of problem:
Launching the task 'Form wizard' from OOo base 1.9.117 opens writer but the wizard does not run. Also, the wizard for creating Forms is not present in the menu "File - Wizards" as in previous releases (i.e. 1.9.112).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Open OpenOffice.org base
2.Open a database
4.Go to the "Tasks" tab and click on the wizard for creating forms
if I install the 1.9.117-3 fc4 update on rawhide the form wizard appears on
running it from base, is this the version you have? 1.9.117-3.1.0.fc4. If so,
presumably this is a gcj/java problem in fc4 which doesn't appear in rawhide.
My openoffice.org installed version is 1.9.117-3.1.0.fc4 (Freshrpms).
if you run it from a console and attempt to start the wizard is there any output
on the terminal ?
runned "oobase" from a terminal --- no messages when I try to launch the
wizard... Writer opens and I can see a progress bar in the bottom as if the
wizard were running, but it halts in the middle and nothing happens.
Sounds a little like bug 161173, but the fix for that was included in 1.9.117-3
and it had backtrace output. Perhaps something similiar though. Do other wizards
run, e.g. writer file->wizards->letter ?
Also just to be sure, run the oobase wizard and go for a little walk for a few
minutes and see if it's just really really slow.
caolanm->tromey: working in rawhide with OOo from fc4 updates, but reportedly
not under fc4 itself. i.e. possible libgcj issue of some kind ?
file->wizards->letter runs OK.
The form wizard does not appear in the menu file->wizards as I said, the only
way to launch it is from "tasks" under "Forms" tab in oobase.
I did the little walk but nothing... also I noted that Writer was ready to
accept input exactly when the progress bar stops its advance, and when any
wizard is running it does not.
The wizard is not going to return to the toplevel wizards menu, this appears to
be the final decision on menu layout so the substantive issue is the failure of
the wizard to run correctly when launched from the "base" application.
There is now a testing update to 1.9.125 for fc4, I doubt that this will fix
this problem, I suspect there is some gcj issue here, but it's worth testing
1.9.125 to get data on this
The "query wizard" is failing also.
you mean both wizards fail in 1.9.125 fc4 update ?
I've upgraded to 1.9.125 and same behavior. Query wizard does not launch, form
wizard opens writer and the progress bar halts in the middle, exactly as 1.9.117
to confirm, under "tools->options->openoffice.org->java"
what JRE is selected ?
selected "Sun Microsystems Inc." 1.5.0_04
If you unselect "Sun Microsystems" JDK and select the "Free Software Inc" JDK
does it make a difference ?
I just don't have that choice so it's only appearing the Sun JRE option in the list.
> rpm -q libgcj
$ rpm -q libgcj
nuisance, ok if you have the patience to bear with me,
> mv ~/.openoffice.org2.0/user/config/javasettings_Linux_x86.xml
and see what's listed in tools->options->openoffice.org->java
if Free Software Inc is listed, select that and see if the hangs etc still happen
ok, I shutd down ooffice, save the javasettings file and restarted ooffice...
again Sun JDK is alone in the list. The newly created javasettings XML file is
nearly identical as the existing (the option "autoselect" now is "true" instead
Actually I just move the javasettings file to my home directory so ooffice
starts without it.
About comment #15 and comment #16 - I don't know about OO.o in particular,
but you may need java-gcj-compat to be installed for some apps to see
libgcj as a jvm.
OK. Installed java-1.4.2-gcj-compat and moved again the javasettings file. Now
the wizards WORK both, and all the rest as it seems. Now the Sun JRE does NOT
appear as an option in tools->options->openoffice.org->java
a) the gcj compiled java code works with gij as expected -> i.e. the wizards
work with redhat provided java solution, which is all we support directly really.
b) I might be missing a Requires, though OOo should only need to see libgcj and
/usr/bin/gij to recognize the gcj solution, which seems to work locally here
c) gcj compiled java stuff might not be working 100% with sun java 1.5.0 (which
isn't to prove there is a problem there)
d) both aren't being listed as available jvm's at the same time, perhaps because
of one clobbering ther other ala
*** Bug 167533 has been marked as a duplicate of this bug. ***
As I have openend the Bug 167533, which is marked as a duplicate for this one, I
will try to add some information here.
I am running openoffice.org 1.9.125 from Fedora Core 4. I have installed a jdk
1.5.0 packaged using the jpackage.org stuff, and after reading the bugreports
about this issue. I also installed
java-1.4.2-gcj-compat-188.8.131.52-40jpp_31rh.FC4.1 to get the FSF java 1.4.2 back.
Looking for my Java packages I see.
oa@fitheach ~ $ rpm -qa | grep gcj
oa@fitheach ~ $ rpm -qa | grep jpp
oa@fitheach ~ $
Sounds okay for me.
Now I have the Sun JDK/JRE and the FSF JRE listed in openoffice.org inside the
settings. The interesting part is, that when I select the FSF jdk I get "/usr"
displayed as "Speicherort" (sorry, I am using a german version) below the select
box. When I select the sun jdk I get the correct "Speicherort" displayed.
So, now to complicate the things a little more, I just selected the Sun 1.5 JDK
and everything works fine. It seems as the FSF jre is broken in my installation
and causes these problems. And my fault was not to change the setting to the sun
"Speicherort" -> Location, /usr is correct for the detected gcj jre. I'm not a
fan of having to install the sun jdk, but maybe be I will have to to see what
the conflicts are from OOo's perspective
Well, I tried the other direction. I removed everything except libgcj and
selected the sun jdk. Still everything is okay for me. The wizards just work
now. No problem at all. Maybe except the fact, that the wizards made me start to
think about abiword, koffice or OOo 1.1.x.
Okay, I am not sure if this is the right context, but now I even succeeded in
crashing OOo. :| I just the setup from above and started the "Webpage..."
wizard. The end was a window titled "OOo has crashed!" with the following content:
0x7adb8a: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x1db8a
0x7ae3d8: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x1e3d8
0x27f420: + 0x420 (__kernel_sigreturn + 0x0)
0x669888: /lib/libc.so.6 + 0x29888 (abort + 0xf8)
0xabd039e5: /usr/lib/jvm/java-1.5.0-sun-1.5.0.04/jre/lib/i386/client/libjvm.so +
0xabd8c994: /usr/lib/jvm/java-1.5.0-sun-1.5.0.04/jre/lib/i386/client/libjvm.so +
0xabd08134: /usr/lib/jvm/java-1.5.0-sun-1.5.0.04/jre/lib/i386/client/libjvm.so +
0x260134 (JVM_handle_linux_signal + 0x244)
0xabd05664: /usr/lib/jvm/java-1.5.0-sun-1.5.0.04/jre/lib/i386/client/libjvm.so +
0x27f440: + 0x440 (__kernel_rt_sigreturn + 0x0)
0x42a8055: /usr/lib/openoffice.org2.0/program/libsvt680li.so + 0x282055
(SvParser::RestoreState() + 0x75)
0x42a809d: /usr/lib/openoffice.org2.0/program/libsvt680li.so + 0x28209d
(SvParser::NewDataRead(SvParser*, void*) + 0x3d)
0x57dab08: /usr/lib/openoffice.org2.0/program/libsw680li.so + 0x1afb08
0x5acf432: /usr/lib/openoffice.org2.0/program/libsw680li.so + 0x4a4432
0x5acf444: /usr/lib/openoffice.org2.0/program/libsw680li.so + 0x4a4444
0x3316592: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x82592
0x346aa47: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x1d6a47
0x12bfe72: /usr/lib/openoffice.org2.0/program/libvclplug_gen680li.so + 0x1ee72
0x12e50cd: /usr/lib/openoffice.org2.0/program/libvclplug_gen680li.so + 0x440cd
(SalDisplay::DispatchInternalEvent() + 0xad)
0xf579d3: /usr/lib/openoffice.org2.0/program/libvclplug_gtk680li.so + 0xa9d3
0x4971650: /usr/lib/libglib-2.0.so.0 + 0x25650
0x496f3ee: /usr/lib/libglib-2.0.so.0 + 0x233ee (g_main_context_dispatch + 0x1dc)
0x49723f6: /usr/lib/libglib-2.0.so.0 + 0x263f6
0x49728d8: /usr/lib/libglib-2.0.so.0 + 0x268d8 (g_main_context_iteration + 0x66)
0xf575f9: /usr/lib/openoffice.org2.0/program/libvclplug_gtk680li.so + 0xa5f9
0x12e6d99: /usr/lib/openoffice.org2.0/program/libvclplug_gen680li.so + 0x45d99
(X11SalInstance::Yield(unsigned char) + 0x29)
0x331c8f4: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x888f4
(Application::Yield() + 0x50)
0x331c932: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x88932
(Application::Execute() + 0x26)
0x39c1254: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x29254
(desktop::Desktop::Main() + 0x149a)
0x3321d21: /usr/lib/openoffice.org2.0/program/libvcl680li.so + 0x8dd21 (SVMain()
0x39bc307: /usr/lib/openoffice.org2.0/program/libsoffice.so + 0x24307 (sal_main
0x654d5f: /lib/libc.so.6 + 0x14d5f (__libc_start_main + 0xdf)
0x80484e1: /usr/lib/openoffice.org2.0/program/swriter.bin + 0x4e1
Well, I now even tried a complete "reset". I had to reinstall my system last
night and skipped my sun java stuff as I am on vacation. :) Now I only have
installed the things provided by Fedora.
Result: None of the before mentioned Wizards work at all. The FSF java seems to
be in stalled correctly...
Just to add some more information here. If I wait long enough then the wizard
opens. And after that the other wizards open faster.... seems rather odd to me.
yeah, initial search for what java is installed and initial instantiation is a
bit slow, I should look into that. Otherwise the safest solution for now is to
lock our OOo into using the JVM's that I've tested it with and know work.
Just to leave a comment, I tried it once again. A fresh installation of FC4, all
updates applied and the wizards hang. I haven'T installed anything of my own or
from a 3rd party repos. So, I can't agree with you, that it works with what
Fedora delivers. Hopefully, this will get better in the upcoming RC or final,
but this way it is not useable in my eyes. I will personally switch to abiword
meanwhile, cause it satisfies my needs and it works snappy in its reponses