[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LYNX-DEV Gathering debug info
From: |
David Woolley |
Subject: |
Re: LYNX-DEV Gathering debug info |
Date: |
Fri, 18 Jul 1997 01:08:46 +0100 (BST) |
>
> David, perhaps it would be useful to gather up all the steps that someone
> can follow to report a problem and submit it as a section of the lynx
> help files?
> --
> Larry W. Virden INET: address@hidden
There already is some information on bug reporting on the web site, which
includes:
lynx -version
and
uname -a
The main ones I would add (for Unix, and subject to some common sense
about likely causes - e.g. if the bug has been diagnosed in the source
code, most of this is unneeded) would be:
* if you are using Linux, indicate who compiled the Linux distribution,
and which version (this information is generally available from
uname -a for commercial systems, but Linux kernel versions don't
fully characterise a Linux system);
* if the command ldd exists, run it against the Lynx executable and report
the results (this gives versions of shared libraries used);
* if you are competent to rebuild Lynx, recompile it with debugging
enabled and avoid stripping the binary (details omitted on the
assumption that those able to take this step will be able to determine
them themselves);
* if the command gdb exists and a core file was produced (this should
happen if you get a message about a Signal, or a segmentation violation,
unless you don't have enough rights in the current directory, or ulimit
forbids it), run it with the lynx executable as the first parameter
and the core file as the second, then issue "info stack" and "quit"
and include the results;
* if there is a native symbolic debugger and you know how to use it,
include the stack trace information it produces;
* if gdb is not available and you don't have a symbolic debugger, but adb
is available (try /etc/_fst on SCO Unix), run it, as for gdb, but with
the commands "$c" and "$q";
* if you compiled Lynx yourself (or otherwise know this information) the
version of the compiler and libraries may be useful if there is any
possibility of incorrect code or bad libraries.
The above really applies to any program. Reporting a segmentation
violation or signal, without providing a backtrace is one of the most
infuriating sorts of bug report, as people assume that the error message
is very precise, when it is actually very generic.
;
; To UNSUBSCRIBE: Send a mail message to address@hidden
; with "unsubscribe lynx-dev" (without the
; quotation marks) on a line by itself.
;