lynx-dev
[Top][All Lists]
Advanced

[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.
;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]