Re: [Bug-wget] [bug #51029] Reproducible Segmentation Fault in 1.16, 1.18, 1.19

[Tim Rühsen]

On Montag, 15. Mai 2017 13:53:54 CEST Darshit Shah wrote:
> Follow-up Comment #1, bug #51029 (project wget):
> 
> Hi,
> 
> Thanks for the bug report!
> Could you please also share the entire logs for these runs if you have them
> available? Attaching them to the report will be the best way.
> 
> I tried running the command line you provided on my Arch Linux system
> against the latest git master and it completed successfully:
> 
> ```
> FINISHED --2017-05-15 19:42:29--
> Total wall clock time: 4m 31s
> Downloaded: 1183 files, 73M in 13s (5.64 MB/s)
> ```
> 
> Since I am unable to reproduce this issue locally, I'm going to need some
> help from your end. A --debug trace of when wget crashes will be useful.
> Even better would be if you could provide a stack trace by building wget
> locally with debug symbols and running it inside gdb. Once it segfauls, you
> can type "b" on the command line and get a stack trace.
> 
> Also, could you please test it with the latest git master? It may have been
> fixed in the meantime.
> 
> I'm unable to make a guess as to why this occurs. The first guess would be a
> race condition, but we don't have any threads in Wget, so that is out of
> the question.

Tag v1.19.1 has this problem (run with valgrind).

It looks like some HTTP/HTTPS URL issue with robots.txt.
- first https://coovia.fr/robots.txt is being loaded (it is redirected to 
https://coovia.fr/accueil/ which in fact is a HTML page).
- later, it looks like somehow http://coovia.fr/robots.txt is referenced 
(maybe implicitly by a link to http://coovia.fr). This becomes redirected to 
https://coovia.fr/robots.txt which is redirected to https://coovia.fr/
accueil/. 
And here it crashes in register_redirection(), I guess because 'file' var is 
NULL.

==6923== Invalid read of size 1
==6923==    at 0x4C2EDA2: strlen (in /usr/lib/valgrind/vgpreload_memcheck-
amd64-linux.so)
==6923==    by 0x170276: xstrdup (xmalloc.c:121)
==6923==    by 0x117C7F: register_redirection (convert.c:955)
==6923==    by 0x14703B: retrieve_url (retr.c:981)
==6923==    by 0x145531: res_retrieve_file (res.c:566)
==6923==    by 0x1440CE: download_child (recur.c:740)
==6923==    by 0x14376D: retrieve_tree (recur.c:470)
==6923==    by 0x13F54C: main (main.c:2075)
==6923==  Address 0x0 is not stack'd, malloc'd or (recently) free'd


It is unlikely to be fixed in latest git. But a test case to reproduce this 
shouldn't be too much work (tomorrow).

Regards, Tim

signature.asc
Description: This is a digitally signed message part.