Node:Reporting Bugs, Next:Running Intro, Previous:Obtaining and Installing Guile, Up:Top
Any problems with the installation should be reported to bug-guile@gnu.org.
Whenever you have found a bug in Guile you are encouraged to report it to the Guile developers, so they can fix it. They may also be able to suggest workarounds when it is not possible for you to apply the bug-fix or install a new version of Guile yourself.
Before sending in bug reports, please check with the following list that you really have found a bug.
When you write a bug report, please make sure to include as much of the information described below in the report. If you can't figure out some of the items, it is not a problem, but the more information we get, the more likely we can diagnose and fix the bug.
You can get the version number by invoking the command
$ guile --version Guile 1.4.1 Copyright (c) 1995, 1996, 1997, 2000 Free Software Foundation Guile may be distributed under the terms of the GNU General Public License; certain other uses are permitted as well. For details, see the file `COPYING', which is included in the Guile distribution. There is no warranty, to the extent permitted by law.
uname
.
$ uname -a Linux tortoise 2.2.17 #1 Thu Dec 21 17:29:05 CET 2000 i586 unknown
configure
command when Guile was
installed. It's often useful to augment this with the output of the
command guile-config info
.
Be precise about these changes. A description in English is not enough--send a context diff for them.
Adding files of your own, or porting to another machine, is a modification of the source.
If you can tell us a way to cause the problem without loading any source files, please do so. This makes it much easier to debug. If you do need files, make sure you arrange for us to see their exact contents.
Of course, if the bug is that Guile gets a fatal signal, then one can't miss it. But if the bug is incorrect results, the maintainer might fail to notice what is wrong. Why leave it to chance?
If the manifestation of the bug is a Guile error message, it is important to report the precise text of the error message, and a backtrace showing how the Scheme program arrived at the error.
This can be done using the procedure backtrace
in the REPL.
.guile
file, set any variables that may affect the functioning of
Guile. Also, see whether the problem happens in a freshly started Guile
without loading your .guile
file (start Guile with the -q
switch to prevent loading the init file). If the problem does
not occur then, you must report the precise contents of any
programs that you must load into Guile in order to cause the problem to
occur.
The line numbers in the development sources might not match those in your sources. It would take extra work for the maintainers to determine what code is in your version at a given line number, and we could not be certain.
libguile
subdirectory in which Guile was compiled, then
do gdb guile
or gdb .libs/guile
(if using GNU Libtool).
However, you need to think when you collect the additional information if you want it to show what causes the bug.
For example, many people send just a backtrace, but that is not very useful by itself. A simple backtrace with arguments often conveys little about what is happening inside Guile, because most of the arguments listed in the backtrace are pointers to Scheme objects. The numeric values of these pointers have no significance whatever; all that matters is the contents of the objects they point to (and most of the contents are themselves pointers).