You are welcome to submit bug reports via the GNU Wget bug tracker (see https://savannah.gnu.org/bugs/?func=additem&group=wget) or to our mailing list [email protected].
Visit https://lists.gnu.org/mailman/listinfo/bug-wget to get more info (how to subscribe, list archives, ...).
Before actually submitting a bug report, please try to follow a few simple guidelines.
Try to repeat the bug in as simple circumstances as possible. E.g. if
Wget crashes while downloading ‘
wget -rl0 -kKE -t5 --no-proxy http://example.com -o /tmp/log’, you should try to see if the crash is
repeatable, and if will occur with a simpler set of options. You might
even try to start the download at the page where the crash occurred to
see if that page somehow triggered the crash.
Also, while I will probably be interested to know the contents of your
.wgetrc file, just dumping it into the debug message is probably
a bad idea. Instead, you should first try to see if the bug repeats
.wgetrc moved out of the way. Only if it turns out that
.wgetrc settings affect the bug, mail me the relevant parts of
Please start Wget with ‘
-d’ option and send us the resulting
output (or relevant parts thereof). If Wget was compiled without
debug support, recompile it—it is much easier to trace bugs
with debug support on.
Note: please make sure to remove any potentially sensitive information
from the debug log before sending it to the bug address. The
-d won’t go out of its way to collect sensitive information,
but the log will contain a fairly complete transcript of Wget’s
communication with the server, which may include passwords and pieces
of downloaded data. Since the bug address is publically archived, you
may assume that all bug reports are visible to the public.
gdb `which wget` coreand type
whereto get the backtrace. This may not work if the system administrator has disabled core files, but it is safe to try.