Hi,
I found a way to make GNU Wget 1.7.1 (wget) crash with a segmentation
fault. Here are the details:
With my particular setup, wget crashes with an argument of 78 characters
or more. This can easily be replicated (on my machine) as such:
I. 78 'x's, could also use `perl -e "print 'x' x 78;"` if Perl is installed.
$ wget -d
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
DEBUG output created by Wget 1.7.1 on linux-gnu.
parseurl
("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx") ->
host xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ->
opath -> dir -> file -> ndir
newpath: /
Segmentation fault
II. Using 77 or fewer characters ('x's), wget works correctly:
$ wget -d
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
DEBUG output created by Wget 1.7.1 on linux-gnu.
parseurl
("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx") ->
host xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ->
opath -> dir -> file -> ndir
newpath: /
--19:15:38--
http://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
=> `index.html'
Connecting to
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:80...
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: Host
not found.
Using ddd and gdb I narrowed it down to the following stack trace:
src/http.c:1504 http_loop() -> src/log.c:388 logprintf() -> \
src/log.c:295 logvprintf() -> glibc6 vfprintf() -> glibc6 strlen()
Here's the actual 'where' output from gdb:
#0 0xfdf1504 in strlen () at soinit.c:59
#1 0xfdd5834 in vfprintf () at vfprintf.c:1565
#2 0xfde50d0 in _IO_vsnprintf (string=0x10042948 "--i�\017�i�", 'x' <repeats 70
times>, maxlen=129, format=0x10027cd8 "--%s-- %s\n %s => `%s'\n", args=0x7ffff478)
at vsnprintf.c:129
#3 0x10018558 in logvprintf ()
#4 0x100186c4 in logprintf ()
#5 0x1001442c in http_loop ()
#6 0x1001e740 in retrieve_url ()
#7 0x1001a054 in main ()
#8 0xfdb2754 in __libc_start_main () at ../sysdeps/powerpc/elf/libc-start.c:106
#9 0x0 in ?? ()
I tried to replicate the bug on a Debian (testing) GNU/Linux for x86
(486) without success. The glibc6 version (2.2.4) seems to be OK.
So it appears that the bug is probably actually in my version of glibc6
(2.1.3). I'm running Debian (stable) GNU/Linux for PowerPC (PPC).
Incidentally, using the -nv (no verbose) or -q (quiet) wget options seem
to workaround this bug:
(78 'x's)
$ wget -nv
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: Host
not found.
$ wget -q
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I don't know if there's much you can do about this bug but I thought I
would let you know the details in case you hear from others about it.
Once Debian releases version 3.0 (the next stable release), I'll
upgrade, recompile wget and hopefully this problem will be fixed.
Please let me know if you need any more detail or want me to beta test
any changes.
Thanks,
Matt
--
Matt Christian [EMAIL PROTECTED] Learn to love and love to learn.
http://www.visi.com/~mattc/ 0111 ftp://ftp.visi.com/users/mattc/
5468652073656372657420697320131b331b2e1b311b341b311b351b39110d0a
