bugs - reporting Antelope problems
At BRTT, we want to hear about any problems you encounter with
Antelope software. Depending on the problem and the program(s)
involved, we may be able to suggest a solution or workaround
immediately. In other cases, we may need to provide a patch.
If a program dies with a segmentation fault, bus error, or floating
point error, we particularly want to hear about it. This should
not happen (except if you are deleting rows from a database table while
another program is using the same table).
To provide any support, however, we need to have a clear description
of the problem, so that we can reproduce it at our offices.
This man page makes some suggestions for problem solving and
reporting.
When you encounter a problem, first make sure it's a problem.
-
Make sure you have already installed all the available patches,
using antelope_update(1).
-
Be certain there is not some problem on your computer, like you're
out of memory or there's a disk full.
-
Check your environment. Turn off LD_LIBRARY_PATH if you have it set,
and any other environment variables which setup.csh complains about.
We need to be able to reproduce the problem
in order to find and fix it. Therefore,
we want to see at least all of the following:
-
Antelope version
This may be the single most important thing to include in any Antelope bug
report. BRTT only supports the most recent version of Antelope. Often, with
older versions, a particular problem has already been identified and fixed
in a more recent version. You can always go to http://www.brtt.com to see
which version number is the latest version. If you encounter a problem
with an older version, the first thing you should do is to upgrade to the
latest version and then see if the problem persists. If you report problems
with old versions of Antelope, BRTT will probably not respond.
-
host architecture
BRTT also will want to know exactly what type of computer host (i.e. SUN/Sparc,
PC/Linux, Mac/OSX) you were using when the problem appeared. Also needed is
the particular version of Operating System that was in use.
-
command line
The exact command line used.
-
program input
Any input files for the program
-
actions you took
If this program has a graphical user interface, what buttons, menus,
other actions led to the problem.
-
program output
The exact program output; if it's graphical, a screendump can be helpful.
-
core file
If there's a core file, we want to see it.
Sometimes it's difficult to collect all the right files. Antelope
includes a number of snapshot programs designed to collect a bunch
of information; these may help you report a bug. The programs are:
-
dbsnapshot
collects a snapshot of a database; options allow collecting
some waveform or response information.
-
dbloc_snapshot
collects a snapshot from a directory where dbloc2 is run. It should
run immediately after the failure occurs, so that the logs and other
files reflect the error.
-
rtsnapshot
collects a snapshot of a directory where rtexec runs. Again, it should
be run as soon as possible after an error occurs, so that the logs
show the error.
A snapshot is not by itself an error report. You still must tell
us
-
1)
What you did
-
2)
What happened
-
3)
What is wrong with what happened.
Once you've collected the information, and written a description of
what happened, send it to us at support@brtt.com. We'll respond
as quickly as we can.
Do not send problem reports to individual email addresses at
BRTT: they will not be answered. To receive a response, only
use support@brtt.com. Requests sent to support@brtt.com
are read by multiple people and will be responded to in a timely manner.
Here are some examples of what not to do:
-
<some-program> doesn't work.
Exactly how doesn't it work? What have you tried? What was the input and
output?
-
When I typed <...>, I got the following output:
<some output>
We periodically get these kinds of questions, where the first puzzle is
to figure out what the author thought was wrong. We often lack the context
that may make the problem obvious to you. In addition to showing us
the command and the output, please explain what's wrong
with the output, and send us the input data if you can, so that we
can reproduce the problem.
reporting(5)
http://catb.org/~esr/faqs/smart-questions.html
Writing bug reports is hard work.
Take the advice above and avoid the problems below.
Pilots fill out a form after every flight about any problems encountered.
Mechanics in turn inform the pilots what measures were taken.
Here are several reports, and the resulting actions.
-
Pilot:
Test flight ok. Landing with autopilot very hard.
-
Mechanic:
Landing with autopilot not installed in this
type of aircraft.
-
Pilot:
Something in the cockpit is loose.
-
Mechanic:
Retightened something in the cockpit.
-
Pilot:
Dead bugs on the windshield.
-
Mechanic:
Live bugs on back order.
-
Pilot:
In spite of maintain altitude setting, autopilot
initiates descent of 200 fpm.
-
Mechanic:
Unfortunately, we cannot recreate this problem
on the ground.
-
Pilot:
Notice of leak on the right hand side.
-
Mechanic:
Have removed notice.
-
Pilot:
Engine 3 missing.
-
Mechanic:
Located engine 3 after brief search on right wing
-
Pilot:
Plane flies funny.
-
Mechanic:
Admonished plane to be serious and fly properly.
-
Pilot:
Target radar hums.
-
Mechanic:
Reprogrammed target radar so that it now talks
Daniel Quinlan
Table of Contents
Antelope Release 4.10 Mac OS X 10.4.11 2008-06-17
Boulder Real Time Technologies, Inc
For more information, contact support@brtt.com