Issue 4236 - OpenOffice 641D is crashing spontaneously on AMD K6-2 systems
Summary: OpenOffice 641D is crashing spontaneously on AMD K6-2 systems
Status: CLOSED DUPLICATE of issue 4494
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 1.0.0
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: thorsten.martens
QA Contact: issues@framework
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-04-25 09:48 UTC by Unknown
Modified: 2002-10-16 14:14 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Unknown 2002-04-25 09:48:05 UTC
I really have no idea if framework/code is the proper component/subcomponent
for this, but whenever I'm running 641D on an up2date Red Hat Linux 7.2 system
using an AMD K6-2/400 MHz system, OpenOffice is crashing reproducably. The
same program works as expected on Intel Pentium III/700Mhz and Intel Pentium
II/366MHz. The installation was done via './setup -net' first, followed by
the user specific install. The AMD systems have 96 MB RAM.

Could it be, that the binaries have been compiled with i686 optimization/code
generation on? This will not work on such AMD CPUs.

FWIW, 641C worked without any problems on all my systems.
Comment 1 uhe 2002-04-26 09:22:27 UTC
Please give us more information. "OpenOffice is crashing 
reproducably" is not significant. When crashed the Office? When 
starting, opening document, closing a document, closing Office? A 
step by step guide would be helpful.
Comment 2 jens-heiner.rechtien 2002-04-26 12:02:34 UTC
reassign to hr@openoffice.org for evaluation
Comment 3 jens-heiner.rechtien 2002-04-26 12:30:59 UTC
Actually, we changed something with build SRC641D which might have an
effect on oode generation:

SRC641C has been build with gcc-3.0.1
SRC641D has been build with gcc-3.0.4

The compiler switch -mpentiumpro schedules the code instructions
preferably for the PentiumPro (PII, PIII, PIV, K7 etc.) architecture,
but does not generate instructions beyond the venerable i386
architecture. Thus code compiled with this switch might run slower on
a K6 but it should work. I never noticed any problems with this
switch, but there is a small chance that the gcc-3.0.4 code generation
is buggy. But then, the setup is compiled with the same optimizations
and it works.

Anyway, as Uwe mentioned, we need more information:
- when does the crash happen? (during startup?)
- are you able to create a backtrace (would be very helpful)
- if your guess is right you might see an "illegal instruction" on
stderr, have you seen anything like this?
Comment 4 Unknown 2002-04-28 11:20:30 UTC
Apologies for not being more specific, but I don't see any
"invalid instruction" or similar message, the program just
crashes. The crash is happening right after some initialization,
ie. when the program is asking the user if (s)he wants to
import any Netscape/Mozilla related stuff, that particular dialog
pops up and stays there, while the program window with the menu bar
sometimes shows up as well, but then disappears immediately.
Sometimes the program window doesn't even pop up. That's all I can
see. I'm not familiar with OpenOffice's internals, but if you
tell me what I can do to track this down (strace log etc.), I'll
do that.

On the compiler side, it was just my first guess, that the 641C/D
distributions may have been built using different/incompatible
flags. It turns out, that you have been using different compilers,
though. It would be interesting to see, if 641D built by using the
3.0.1 compiler would run any different on my machines. I was looking
at downloading the sources and building the stuff myself, but when
I realized what additional stuff I need to get and install on my
machines I gave up.

If you can build a 641D using the 3.0.1 compiler I would be happily
testing that on my machines.
Comment 5 Unknown 2002-05-01 00:51:28 UTC
Are you by chance running OO on a different machine than you're
running your X display?  I'm having problems with it crashing at the
same spot, and found bug 3723 that looks to be similar.
Comment 6 Unknown 2002-05-01 09:50:56 UTC
No, OO is running on the local display, ie. :0.0
Comment 7 Unknown 2002-05-01 09:55:36 UTC
Hmm, just looked at the report you mentioned
<http://www.openoffice.org/issues/show_bug.cgi?id=3723>, and it
appears to be very similar, indeed. However, I'm running on the local
display, and I'm not seeing any messages :-( Otherwise the described
behaviour is very the same as I see it here.
Comment 8 Unknown 2002-05-04 09:56:20 UTC
I have OO 1.0 installed on the systems now, and the behaviour didn't
change. I found out one thing, though, which doesn't seem obvious
to me. When I'm using the per-user symbolic link ~/OpenOffice/soffice
for starting the program, it'll crash in almost 99% of the attempts.
When I'm using the links from the Gnome menu, which are installed
under "Favourites->OpenOffice.org", e.g. swriter, it appears to be
working correctly -- just had two crashes so far. It seems that the
soffice shell script is setting some environment variables which
have bad effects.

One thing might help further, when the two crashes with 1.0 happened,
the main window had opened including the menu bar etc., the cursor
however wasn't visible when the program crashed. Starting the program
again, makes it work in almost all cases now.
Comment 9 jens-heiner.rechtien 2002-05-06 09:52:50 UTC
It's quite unlikely a compiler/optimization issue if OOo works at
least sometimes. 

It would be nice if we could get a stacktrace of the problem:
Please edit the "soffice" script. The 2nd to last line reads

exec "$sd_prog/$sd_binary" "$1" "$2" "$3" "$4" "$5" "$6" "$7" "$8" "$9"

please change into

gdb "$sd_prog/$sd_binary"

and restart. Note, executing OOo under debugger on a K6 with not
enough memory will be really slow. If it does crash eventually type
"ehere" on the debugger commandline and paste output to this issue.

Reassign back to Uwe for further evaluation.

Comment 10 jens-heiner.rechtien 2002-05-06 09:55:00 UTC
Sorry, did just note a typo in my last comment: the backtrace command
of gdb is:

"where" or "bt"
Comment 11 uhe 2002-05-06 11:30:24 UTC
Hi Manfred,

please be so kind and put a stack to us as Jens-Heiner described.

For further investigations reassigned to Thorsten.
Comment 12 Unknown 2002-05-06 19:11:37 UTC
Hmm, I ran gdb today as you advised, but I doubt that it'll be of
any use. The OO window popped up as usual, then it disappeared as
usual and gdb was waiting at the prompt. Here's the transcript of
that session:

$ ~/OpenOffice/soffice
GNU gdb Red Hat Linux (5.1-1)
Copyright 2001 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-redhat-linux"...
(gdb) r
Starting program: /opt/openoffice/program/soffice.bin
[New Thread 1024 (LWP 1570)]
[New Thread 2049 (LWP 1574)]
[New Thread 1026 (LWP 1575)]
[New Thread 2051 (LWP 1576)]
[New Thread 3076 (LWP 1577)]
[New Thread 4101 (LWP 1584)]
Cannot find user-level thread for LWP 1584: generic error
(gdb) i program
Cannot find thread 1024: generic error
(gdb) i r
No selected frame.
(gdb) where
Cannot find thread 1024: generic error
(gdb) i threads
Cannot find new threads: generic error
(gdb) c
Continuing.
Cannot find thread 1024: generic error
(gdb) k
Kill the program being debugged? (y or n) y
Cannot find thread 1024: generic error
(gdb) q
The program is running.  Exit anyway? (y or n) y
Cannot find thread 1024: generic error
(gdb) q
The program is running.  Exit anyway? (y or n) y
Cannot find thread 1024: generic error
(gdb)
The program is running.  Exit anyway? (y or n) y
Cannot find thread 1024: generic error
(gdb)

As you can see, gdb was rather confused at this stage; looking into
the process list using "ps -auxwwwwwww | fgrep soffice" revealed that
no soffice thread/process existed anymore - I had to manually kill
gdb from the command line.
Comment 13 chris 2002-05-14 15:16:49 UTC
You are using gnome; can you check the workaround I added to issue
4494 - it may be yours is a duplicate.  Have you tried using window
managers other than Sawfish?
Comment 14 Unknown 2002-05-15 11:16:50 UTC
I can confirm that unset'ing SESSION_MANAGER in the soffice script
fixes the problem, indeed! I haven't had any sudden crash since.

I've also marked this issue as duplicate of #4494.

Thanks for everyone's help!


*** This issue has been marked as a duplicate of 4494 ***
Comment 15 uhe 2002-10-16 14:14:50 UTC
Duplicate, therefore closed