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.
