I recently tested compatibility between OpenOffice.org and Microsoft Office by checking whether OpenOffice could correctly display Microsoft Office documents. My unscientific impression is that Version 1.0.3 of OpenOffice.org scores about a 70 out of 100 on MS Office compatibility, and Version 1.1.0 scores about a 90. The new version is so good that many people won't notice any problems when exchanging documents with MS Office users.
However -- if you *do* notice problems, you face a choice. You could:
This page assumes you're already familiar with filing bug reports, and tries to show you how to help sort through other people's bug reports effectively.
Problem is, problem reports are coming in faster than they can be dealt with, because many of the problem reports are duplicates or system problems. The result is a backlog of over a thousand unexamined problem reports from users, and every day, another four new reports are added to the backlog. This backlog is both a shame, and a treasure trove. Many of the problem reports in the backlog contain enough information for developers to quickly find and solve the problem - but it takes time to sort through the reports.
That's where you come in. You can help the developers do what they do best. All you have to do is help sort through the incoming bug reports. This is called triage.
No matter what area you care about, you can probably come up with an IssueZilla query that pulls up bug reports about it. Below are a few example queries, enough for you to get started with.
Note: these example queries aren't perfect - they miss a few bugs, and pull up a few issues that aren't really what they were meant to find, so take them with a grain of salt. You can edit the queries by clicking on the "Edit Query" link on the bottom right of the query result page.
Here are a few canned queries for recently reported bugs:
Problems importing Microsoft Office documents are serious because many people simply can't use OpenOffice unless it handles all the documents their company uses. Below are example queries that look for .doc/.rtf/import problems.
Note: If you're looking for fresh reports to start triaging, click on the first query (UNCONFIRMED, triage not started yet). The other queries are useful for comparison, or if you're looking for bugs that have fallen through the cracks.
|Status||Resolution||triage started?||Query||Count on 17 May 2003||Count on 25 June 2003|
|CLOSED or RESOLVED||FIXED||[Run Query]||487||552|
|CLOSED or RESOLVED||WORKSFORME||[Run Query]||128||162|
|CLOSED or RESOLVED||DUPLICATE||[Run Query]||190||220|
|CLOSED or RESOLVED||INVALID||[Run Query]||103||119|
|CLOSED or RESOLVED||LATER||[Run Query]||22||23|
That last row is the grand total. I omitted some rows, so the rows shown might not add up to the total. Finding the missing rows is left as an exercise for the reader :-)Here are a couple other queries that might be of interest:
Crash bugs -- those that cause unrecoverable errors -- are the most serious. Here are a few example IssueZilla queries that try to pull up reports of crash bugs in various stages of life. (Even old crash bug reports can be valuable. While trolling through old crash bug reports, I found several reported against 1.0.2 that could be reproduced in 1.1beta1.)
|Status||Resolution||triage started?||Query||17 May 2003||25 June 2003||6 July 2003|
|CLOSED or RESOLVED||FIXED||[Run Query]||675||738||764|
|CLOSED or RESOLVED||WORKSFORME||[Run Query]||399||465||484|
|CLOSED or RESOLVED||DUPLICATE||[Run Query]||245||263||272|
|CLOSED or RESOLVED||INVALID||[Run Query]||167||192||197|
If you're using Linux or some other Unix, you should try to capture a symbolic stack dump for the crash, and attach it as a text file to the bug report. See Capturing Stack Dumps below for details. And if you can't reproduce a crash bug, you might try to get the person who originally reported it to capture a symbolic stack dump himself.
|Version||8 May 2003||25 June 2003|
|OOo 1.1 rc 5||-||-|
|OOo 1.1 rc 4||-||-|
|OOo 1.1 rc 3||-||-|
|OOo 1.1 rc 2||-||-|
|OOo 1.1 rc 1||-||-|
|OOo 1.1 beta 2||-||205|
|OOo 1.1 beta||193||180|
If you're using OpenOffice 1.1rc1 or later, and you don't see the gui crash logger pop up when you get a crash, your copy of OpenOffice is probably unable to pop up the gui crash logger. (Duh.) If you're on Linux, you can work around this by starting OpenOffice in a terminal window. When OpenOffice aborts, you can just copy and paste the crash log from the terminal window into an IssueZilla issue.
Before you file an issue, search IssueZilla for similar crash logs. Just pick a unique-looking word from near the top of the log, and search for it in IssuzeZilla. Often you'll find an issue with identical crash log; this usually means it's the same bug.
When you do file an issue, please do paste the stack dump into the body of the issue. (Alternately, paste just the juicy part, if you know what that is, and upload the rest of the stack dump as an attachment.) This will let other users search for matching crashes.
Also, if you were able to use the gui crash logger to send in the crash, be sure to mention the id it assigned and the email address you told it; that way Sun's engineers can associate the autologged crash with your issue.
Here's how to capture a stack dump on Linux:Create a file "go.sh" containing the lines
#!/bin/sh bin=/opt/OpenOffice.org1.1.0/program LD_LIBRARY_PATH=$bin gdb $bin/soffice.binThen give the command
script crash.txtThat should say "Script started, file is crash.txt." (Now anything that happens until the next time you type 'exit' will be recorded into crash.txt.) Then give the command
sh go.shThat will load gdb. Then give gdb the command
runThat should start OpenOffice inside gdb.
If the debugger says
Program received signal SIG32, Real-time event 32then you need to add the commands
handle SIGUSR1 nostop noprint handle SIG32 nostop noprintinto the file ~/.gdbinit and start over. (I had to do this on Red Hat 7.x and 8.0.)
If gdb says
---Type <return> to continue, or q <return> to quit---go ahead and press the enter key.
Openoffice should start up normally. (If it seems to hang, check the terminal window and see if gdb is asking you to press 'enter'.) Go ahead and do whatever you need to do to reproduce the bug in question.
Then when gdb breaks because of the crash, give the gdb commands
bt quitThat displays a symbolic stack backtrace, and exits gdb.
Then give the command
exitThat should terminate the subshell started by 'script', and leave a log in the file crash.txt. The log will have carriage returns at the end of each line; that's ok. You can strip them out with an editor if you like; I use the vi command :%s/.$// to remove them.
See e.g. the attachment to issue 14074.
Jens-Heiner Rechtien of Sun Microsystems recently spent some time fixing all the valgrind warnings in the development version of OpenOffice; you can read his writeup, valgrindingOOo.html, here. Julian Seward reports that build 680m17 of OpenOffice runs cleanly with valgrind cvs as of Dec 10, 2003.
You should use Valgrind when there's a hang or crash that's hard to reproduce in gdb, when you are trying to track down a particular bug that you think might be a memory corruption, or if you are running through automated regression tests and want to make darn sure there are no hidden bugs. If Valgrind is the only way to notice a problem, please add keyword 'valgrind' to the issue.
Here are canned queries that may be of interest:
tar -xjvf valgrind-2.0.0.tar.bz2 cd valgrind-2.0.0 ./configure make su make install
To run OpenOffice 1.1 under valgrind, give the command
bin=/opt/OpenOffice.org1.1.0/program LD_LIBRARY_PATH=$bin valgrind $bin/soffice.binThis will output warnings whenever it detects strange memory accesses. If you get too many "uninitialized memory" warnings, add the option --skin=addrcheck, e.g.
bin=/opt/OpenOffice.org1.1.0/program LD_LIBRARY_PATH=$bin valgrind --skin=addrcheck $bin/soffice.binaddrcheck doesn't check for uninitialized memory, and runs about twice as fast as the default setting.
Note: there are many minor bugs in the standard system libraries that only recently came to light thanks to tools like Valgrind, so Valgrind shows a fairly large number of false positives. For instance, closedir() in glibc contained an illegal call to pthread_mutext_destroy that was only fixed very recently (in glibc-2.3.2), so expect to see warnings of that sort if you're not using the latest glibc.
When valgrind logs an error, it saves only four lines of stack backtrace. You can increase this number with the commandline parameter --num-callers. You should increase this to 100 to get enough information for application developers to fix their problems.
#!/bin/sh XAUTHORITY=~/.Xauthority DISPLAY=127.0.0.1:0.0 /usr/X11R6/bin/xterm -e gdb "$@"Be sure to chmod +x ~/rungdb. The script is started without the normal environment variables, so you need to explicitly set any that are needed. The above is for Red Hat Linux 8.0. If the crash you're seeing happens to happen while the X display lock is held, you'll probably want to set DISPLAY to some other host's X display... that actually happened to me once.
#!/bin/sh bin=/opt/OpenOffice.org1.1.0/program LD_LIBRARY_PATH=$bin valgrind -v --skin=addrcheck \ --gdb-attach=yes --gdb-command=~/rungdb \ $bin/soffice.binThat will pop up an xterm with a gdb inside it every time you say 'yes' when valgrind asks whether to start gdb. Note that all you can do in that gdb is get a backtrace; you can't continue the program. You must quit gdb before valgrind will continue.