Apache OpenOffice (AOO) Bugzilla – Issue 11220
OO1.0.1 crashes on startup on RedHat 7.3
Last modified: 2003-10-15 11:37:06 UTC
I have installed Open Office 1.0.1 (Spanish version) in a rather old computer (Pentium MMX at 166 MHz) with setup -net (from root) and then setup (from user). Installation went whitout any apparent problem. Then, when I try to start the program, the wellcome screen appears, after a while it dissapears, then I can see the frame of the main program (empty, transparent, I can see my desktop icons) for a couple of seconds and then, everything dies. Curiously, this does not happen hundred per cent of attemps. From time to time (perhaps 1 between 10 attempts), whithout any apparent reason, the program starts and works normally (why???). This also happens if I try to start any of the programs from the GNOME panel menu (writer, draw, calc, math) except if I start Impress. In this case, it opens the so-called "Auto-Pilot" and, after that, the program starts normally. Once Impress is opened, I can switch to Writer, Draw, etc. by simply selecting File -> New -> Text document (or drawing or whatever). By this indirect method, I am able to use every utility of Open Office. I have tried this many times and opening the program through Impress seems to never fail. (Posibly this is not the best solution, but at least I can use the programs in this way ...) I have installed OpenOffice in other two computers, both with 128MB of RAM (as my old 166 MHz) and RedHat 7.3 but with somewhat faster CPU's (300 and 600 MHz). In this case, the situation is the opposite: the program usually starts normally (more than 80% of the attempts) but in some cases, it also crashes. Again, the behaviour seems to be completely ramdom (or better, I cannot see the reason for crashing or not crashing). I have seen issues 6513 and 8055 with similar situations to this, but I am not sure if the problem is exactly the same. In these issues it is suggested to move out of the way the library libdb-3.2.so that the library provided by RedHat (package db3x) is used instead. In my case, changing this makes no difference. I have seen also in these issues that the error is traced in some way but I am just an user and do not understand how it has been done. In my opinion, it seems to me that the program tries to start a task before finishing the previous task. That could be the reason why there are less crashes in faster computers. That would explain also why the program can be run "via Impress". The screen with the "Auto Pilot" menu provides time for the offending process to finish before starting the main window (of course, this is just speculation made by a non-expert and it is perhaps pure nonsense). The apparent ramdom behaviour might be explained by the presence (or absence) of other processes taking time from the CPU.
I don't think that this is an database access issue ...
Hi Thorsten, I think it's your turn.
I have upgraded to 1.0.2 (Spanish version) and the problem remains but is less severe: the program crashes only about half of the startups. Nevertheless, a new and more severe problem has appeared on saving files: issue 12090
When using a mashine, which is a "little bit" faster, with more memory this "problem" is not reproducible. Please be sure to have OO installed as the same user as the one, who tries to work with it. When installing as root, only root can use this installation without problems ! Otherwise do a network/client installation.
I have installed as root with setup -net and then from normal user with setup. Is this what you mean by a network/client installation? By the way, the crashes also take place if I enter the program as root, I do not think it is a permissions issue. How faster is "a little bit faster"? With a Pentium 4 (1.7 GHz), I have not any problem at all. I am getting more and more convinced that the speed of the computer is a key factor in this problem. At least, it should be checked in another 166 MHz computer and, if the problem appears, state 200 MHz or whatever as the "minimum hardware requirements". I am reopening the issue. I do not think it should be marked as "invalid" at least till it has not been tested in a computer of the same speed (if can be found!). In any case, thanks for the atention.
Please try reproducing this with OpenOffice1.1beta. If you can't, then please let us know so we can close it. Alternately, please submit a symbolic stack traceback (see http://www.kegel.com/openoffice for how to start openoffice with gdb and get a backtrace).
Thanks for your reply. I have tried a tracebak. This is a copy of what I typed and all the messages that appeared in the screen (everything happens very very slowly): script crash.txt bin=/usr/local/OpenOffice.org1.0.2/program LD_LIBRARY_PATH=$bin gdb $bin/soffice.bin GNU gdb Red Hat Linux (5.1.90CVS-5) ... This GDB was configured as "i386-redhat-linux"... (gdb) run Starting program: /usr/local/OpenOffice.org1.0.2/program/soffice.bin [New Thread 1024 (LWP 2200)] [New Thread 2049 (LWP 2207)] [New Thread 1026 (LWP 2208)] [New Thread 2051 (LWP 2209)] (** At this moment, the wellcome screen of Open Office appeared **) [New Thread 3076 (LWP 2213)] [New Thread 4101 (LWP 2218)] (** At this moment, the crash happened: I can see for a couple of seconds the frame of the main program before it dies **) Cannot find user-level thread for LWP 2213: generic error (gdb) bt Cannot find thread 1024: generic error (gdb) quit The program is running. Exit anyway? (y or n) y Cannot find thread 1024: generic error (gdb) At this moment, it seems to me that gdb is also hanged and I cannot see a way to quit it. I open a new terminal window and type ps -A to see what processes are going on, I can see gdb running but there is not any process that seems to be related to Open Office. I then kill gdb (I do not know of anything better to do) and come back to the first terminal window where I can see: (gdb) Terminado (killed) exit The file crash.txt that has been created only contains the above messages that had previously appeared in the screen. I do not know if this gives any clue... When I find a little time, I will download 1.1beta and will inform about what happens.
Thanks for trying the backtrace! Those errors are strange. OpenOffice takes 40MB of RAM; you might see similar errors if you only have 64MB of RAM and 128MB of swap, and your system has lots of daemons running, I suppose. How much RAM do you have, and how big's your swap partition? I suppose it's also possible that your gdb can't handle multiple threads well. You might try installing gdb-5.3 from source and trying again, if you really want to pursue this. BTW I don't recommend using OpenOffice on machines slower than 450MHz. For them, AbiWord's about the best you can do...
The machine has 128 MB of memory and 240 MB of swap. I do not think this should be the problem. On the other hand, I have downloaded and installed 1.1beta. I have opened and closed the program a few times and the problem seems to have dissappeared. It takes a considerable amount of time (more than 1.0.2) to startup (as you say, OpenOffice is intended for fast machines) but at the end, I have the program running normally. Thanks for your help.
I have had this exact same issue with OpenOffice on my machine. I've had the same problem with OpenOffice for releases 1.0, 1.0.1, 1.0.2, and 1.0.3. The system has always been Debian testing or unstable; but the system itself is extremely stable. Before 1.0.2 OpenOffice would usually start half of the time. The other half, the main window would appear on the screen for a second or two and the program would crash silently. Since 1.0.2 it starts properly only 30% of the time or worse. I'm including the gdb trace. It looks like the exact same issue miguelquiros had. Thanks, mansoor. Script started on Tue Jun 3 17:50:19 2003 ~/OpenOffice.org1.0.2/program$ export bin=`pwd` ~/OpenOffice.org1.0.2/program$ echo $bin /home/mansoor/OpenOffice.org1.0.2/program ~/OpenOffice.org1.0.2/program$ LD_LIBRARY_PATH=$bin gdb /home/mansoor/OpenOffice.org1.0.2/program/soffice.bin GNU gdb 5.3-debian Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"... (gdb) run Starting program: /home/mansoor/OpenOffice.org1.0.2/program/soffice.bin [New Thread 16384 (LWP 23453)] [New Thread 32769 (LWP 23460)] [New Thread 16386 (LWP 23461)] [New Thread 32771 (LWP 23462)] <-- Splash screen appears [New Thread 49156 (LWP 23477)] [New Thread 65541 (LWP 23478)] Cannot find user-level thread for LWP 23477: generic error (gdb) where Cannot find thread 16384: generic error (gdb) l 1 stat64.c: No such file or directory. in stat64.c (gdb) A debugging session is active. Do you still want to close the debugger?(y or n) y warning: Cannot find thread 16384: generic error ~/OpenOffice.org1.0.2/program$
I forgot to mention my system does not have memory issues. I have 386MB or RAM and half a gig of swap. In case any of this helps, I have kernel 2.4.20, glibc 2.3.1 and Java SDK1.4.0 and the included JRE. But this is only my most recent software configuration. As I mentioned, I've been using OpenOffice for a while (and in spite of some frustrations, I love it :)
mR, Miguel says that 1.1beta fixes the problem for him. Does it also fix the problem for you?
To mR: You have found a bug in glibc 2.3.1. What I have found about: "Hi, everyone testing staroffice with the latest glibc (version 2.3.1) should be aware that there is a bug in the dynamic executable loader (ld.so) that leads to relocation errors when looking up symbols in libraries that export more then 215 symbols (which for example svx does). (see #107277#) - this bug is not present in glibc-2.2.5 I have notified the glibc maintainers about this bug and the fix should be included in the next release (hopefully - it's already in CVS). If you set the LD_BIND_NOW environment variable, you can work around this bug, in case you need to work with glibc-2.3.1 " Glibc 2.3.2 has a fix and is out now. To miguelquiros: We still can't reproduce. To keep it in mind, I set the target to 'Later'; OOo 1.1 doesn't seem to have the problem.
I'm so embarassed I didn't notice he was using glibc-2.3.1. This has got to be a big red flag... can we have OpenOffice display a warning if you try to install it on a glibc-2.3.1 system? mR, please upgrade to glibc-2.3.2 and see if that fixes it.
Well, I have glibc-2.2.5, that it is suppoused to be free of this bug.
I'm getting almost the precise behaviour described here with the standard 1.0.1 package install for Mac OS X (Jaguar). The application crashes after the splash screen and immediately after the main window and registration screen is rendered. So far I have had a successful startup 1 time in 3 tries.
Please check, if this problem still occurs in a more recent build like 1.1RC4. As far as these problems weren´t reproducible with a more recent build, this issue will be closed within 2 weeks.
According to the OpenOffice.org roadmap (http://tools.openoffice.org/releases) this issue was retargeted to OOo Later.
Closed because of being non reproducible and missing further information.
.