Description of problem: Recursive download of the cpluplus.com/reference page with % wget --tries=inf --timestamping --recursive --level=inf --convert-links --page-requisites --no-parent "http://www.cplusplus.com/reference/" Version-Release number of selected component: wget-1.14-12.fc20 Additional info: reporter: libreport-2.2.0 backtrace_rating: 4 cmdline: wget --tries=inf --timestamping --recursive --level=inf --convert-links --page-requisites --no-parent http://www.cplusplus.com/reference/ crash_function: memchr executable: /usr/bin/wget kernel: 3.13.6-200.fc20.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (4 frames) #0 memchr at ../sysdeps/x86_64/memchr.S:39 #1 map_html_tags at html-parse.c:872 #2 get_urls_html at html-url.c:731 #3 retrieve_tree at recur.c:369 Potential duplicate: bug 817654
Created attachment 875453 [details] File: backtrace
Created attachment 875454 [details] File: cgroup
Created attachment 875455 [details] File: core_backtrace
Created attachment 875456 [details] File: dso_list
Created attachment 875457 [details] File: environ
Created attachment 875458 [details] File: exploitable
Created attachment 875459 [details] File: limits
Created attachment 875460 [details] File: maps
Created attachment 875461 [details] File: open_fds
Created attachment 875462 [details] File: proc_pid_status
Created attachment 875463 [details] File: var_log_messages
Hi. This looks familiar. Have you been running multiple instances of wget simultaneously in the same directory when this happened?
(In reply to Tomas Hozza from comment #12) > Hi. > > This looks familiar. Have you been running multiple instances of wget > simultaneously in the same directory when this happened? Hi. No, I have been running just one instance. After it crashed I tried it again with the same result.
Would it be possible to attach the full coredump and tarball with the directory created by wget when downloading (on which you are able to reproduce this issue)? So if you didn't run multiple instances of wget, did something unusual happen prior to the issue (ex. you canceled the the same download before finishing and after that wget crashed, or any other non-standard situation)? I'm not able to find any clue from attached logs/backtraces. Thanks in advance.
Created attachment 877506 [details] Tarball with directory created by wget
(In reply to Tomas Hozza from comment #14) > Would it be possible to attach the full coredump and tarball with the > directory > created by wget when downloading (on which you are able to reproduce this > issue)? > > So if you didn't run multiple instances of wget, did something unusual happen > prior to the issue (ex. you canceled the the same download before finishing > and > after that wget crashed, or any other non-standard situation)? > > I'm not able to find any clue from attached logs/backtraces. > > Thanks in advance. I've uploaded the tarball with the downloaded data, but I can't find the coredump anywhere. About the unusual use, I have run it before and cancelled the program with ctrl+c, then I removed the downloaded folder and run it again with slightly another parameters (the version before was without link conversion and timestamping I think).
I tried the same action again now and it seems it gone all well except for ending with error code 8. If it would be of any help. Have a nice weekend.
I'm not able to reproduce the crash nor the error code 8. From the backtrace it looks really the same as Bug #817654. I'm closing this Bug as INSUFFICIENT_DATA. Feel free to reopen with coredump and archive containing the folder you've been downloading.