OpenOffice.org Needs YOU!

Note: an updated and simplified version of this document is online at http://wiki.services.openoffice.org/wiki/Documentation/OpenOffice.org_needs_YOU.

Contents

Introduction

OpenOffice.org is a free, Microsoft Office-compatible office suite which is becoming increasingly popular. Individuals, schools, governments, and companies are evaluating OpenOffice.org as an effective and inexpensive alternative to Microsoft Office.

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:

  1. do nothing, and wait for someone else to notice and fix the problems,
  2. file bug reports for the problems you see, or
  3. file bug reports for problems you see, and help the team sort through bug reports filed by others
The more you help, the more likely the problems you care about will be solved in the next release. I personally have helped sort through a number of bug reports, and have been very happy to discover that my efforts made a big difference - the crash bugs I sent on to the developers are getting fixed rapidly.

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.

The Problem Report Backlog

OpenOffice.org is good software, but like all software, it has imperfections. Lately, so many people are using the OpenOffice.org office suite that they're actually running into even fairly hard-to-trigger problems. Many of these users are helpfully filing problem reports in IssueZilla, and the OpenOffice.org developers are working on resolving the issues as they press on towards the release of version 1.1.1.

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.

Triage

Triage is what medics do when wounded soldiers arrive at a field hospital so fast they can't all be helped. They decide one of three things about each arriving patient, namely: he/she is either Similarly, triage is also what QA people do when bug reports come in too fast for developers to handle by themselves. They look at each incoming bug report, and decide whether it: That lets the developers focus on fixing problems in the code.

How to help

Here's how to get started:
  1. Register as a member of OpenOffice.org
  2. Request to be a member of the QA project by clicking the "Join This Project" link at the upper right hand of qa.openoffice.org
  3. Review qa.openoffice.org/helping.html and qa.openoffice.org/priorities.html
  4. Join the dev@qa.openoffice.org mailing list
  5. Request the ability to set issue status by emailing dev@qa.openoffice.org with subject line "Volunteer Privileges - <OOo.org userid>". Mention your OOo.org userid again in the message body, and while you're at it, introduce yourself to the group - it's nice to know who we're working with. After your request is granted, you should be able to add the oooqa keyword and modify all fields in an issue.
Then pick an unconfirmed bug report (or issue, as the OpenOffice team calls them), and help triage it as follows: That's all there is to it! If you asked for more information from the original submitter, and you remembered to put your OpenOffice.org email address in the CC: field in the upper right, you'll get email when they reply to your question. When you get the reply, go to the bug's page in IssueZilla, and finish triaging the bug if you can. (If you forgot to add your email address, you can still check for replies; see below.)

Workflow

A helpful diagram of the life cycle of a bug report is online at qa.openoffice.org/issue_handling/taskhandling_workflow_issuetracker_confirm.html.

Priorities, Priorities

There are so many bug reports that it's vital to tackle the ones with the highest potential payoff first. This is a matter of taste. Some people might want to look just at fresh bugs, others might care more about crash bugs, others might care more about Microsoft Office compatibility.

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.

Bugs you've already commented on, but which are still open

If you've already started triaging some bugs, you should periodically check on their status to make sure they don't fall through the cracks. Easiest way to do that is to enter your @OpenOffice.org email address in this box and press ENTER:

Recently Reported Bugs

Recently reported bugs are important to check because a user is waiting for help, and is probably willing to provide additional information or testcases if you need them to reproduce the bug.

Here are a few canned queries for recently reported bugs:

Microsoft Office Compatibility 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
UNCONFIRMED no [Run Query] 216 164
UNCONFIRMED yes [Run Query] 31 45
NEW [Run Query] 32 45
STARTED [Run Query] 55 76
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
any any [Run Query] 1335 1484

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

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
UNCONFIRMED no [Run Query] 173 129 98
UNCONFIRMED yes [Run Query] 47 62 80
NEW [Run Query] 55 70 69
STARTED [Run Query] 55 58 59
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
any any [Run Query] 1906 2072 2123

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.

Bugs with Votes

Issuezilla allows users to vote for the bugs they care about. Votes show up on three pages: Here's a couple example queries to find the bugs with the most votes, broken down by what state the bug is in: And here are the same queries, but for features/enhancements rather than defects: (Note: on the Query Results page, there is a link to the Change Columns page. To see Votes displayed by default when you do Issuezilla queries, you have to go to that page and check the "Votes" checkbox. This sets a cookie with name "COLUMNLIST" in your browser, so it only works with cookies enabled. Then on the Query Results page, you can sort by # of votes by clicking on the Vote column title. However, if you do a query which is sorted by number of votes, the Votes column will show up regardless of whether you have Votes checked in the "Change Columns" page! So if you're using my canned queries above, you don't need to know this bit of arcana.)

Bugs reported against particular versions

If by some miracle, there are no unconfirmed bug reports for crashes or less than 7 days old, or if you just want to go fishing, you can look through the older backlog. Click on the lines below to search Issuezilla for unconfirmed, untriaged bug reports against particular versions. (It looks like the only versions with increasing untriaged backlogs as of June 25, 2003 were 1.0.3 and 1.1beta2, which was as expected, as those were the current stable and development versions.)
Version8 May 200325 June 2003
OOo 1.1 --
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 193180
"current" 4040
644m11 94
644 8146
643C 8444
643 5440
OOo 1.0.3 104161
OOo 1.0.2 343192
OOo 1.0.1 453294
OOo 1.0.0 150108

Capturing Stack Dumps

Programmers *love* it when you attach symbolic stack dumps to reports of crash bugs. OpenOffice 1.1 has a built-in crash logger, which is a *wonderful* feature. It has two modes: gui (where a window pops up offering to send in the crash for you), and non-gui (where the crash report is simply dumped to stdout).

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.

Alternative ways to capture stack dumps

If you're running Linux or some other Unix clone, and OpenOffice's built-in crash logger isn't working (or you just want more info than it gives), you can use gdb instead.

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.bin
Then give the command 
script crash.txt
That 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.sh
That will load gdb. Then give gdb the command 
run
That should start OpenOffice inside gdb.

If the debugger says

Program received signal SIG32, Real-time event 32
then you need to add the commands 
handle SIGUSR1 nostop noprint
handle SIG32 nostop noprint
into 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
quit
That displays a symbolic stack backtrace, and exits gdb.

Then give the command 

exit
That 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.

Running OpenOffice with Valgrind

The free tool Valgrind (like the commercial tool Purify) runs programs in a special way that is twenty times slower, but catches wild pointer and uninitialized memory bugs before they can do any damage. It's really a wonderful tool for anyone trying to find that kind of bug in a complex program. Its main drawbacks are slowness and limited platform support (it only runs on x86 linux). Julian Seward, the author of Valgrind, has a nice presentation about it; it's online at ooo.ximian.com/valgrind/valgrind.html

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:

Installing Valgrind

To install Valgrind, download the sources to the latest version (at the moment, that's valgrind-2.0.0 from valgrind.kde.org and do the usual 
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.bin
This 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.bin
addrcheck 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.

Making OpenOffice More Valgrindable

Valgrind works fine on unmodified executables, but if you're building OpenOffice from source, there are three things you can do to make an OpenOffice executable that's more Valgrind-friendly:

Using gdb with Valgrind

You can have valgrind launch gdb when it runs into an error; then you can do all the backtracing and printing of variabls you like. To do this, add the option --gdb-attach=yes. This doesn't work quite right, since OpenOffice appears to close stdin. Here's one way to work around that:
  1. Create a little script named ~/rungdb containing 
    #!/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.
Then run OpenOffice with the command 
#!/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.bin
That 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.

Other Links

Last update: 11 Jan 2005
Copyright 2003-2005, Dan Kegel
[Return to kegel.com]