Bug 1077171

Summary: [abrt] wget: memchr(): wget killed by SIGBUS
Product: [Fedora] Fedora Reporter: fr.haifler
Component: wgetAssignee: Tomáš Hozza <thozza>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: fr.haifler, micah, thozza
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/881f8c5c10f9a3fdd3f8e9f5c91baa68ddf97cb5
Whiteboard: abrt_hash:ec899a6bc3cd0b083dff5bf42e99aa3929fd344f
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-12-16 17:07:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: exploitable
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages
none
Tarball with directory created by wget none

Description fr.haifler 2014-03-17 11:51:44 UTC 
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
Comment 1 fr.haifler 2014-03-17 11:51:49 UTC 
Created attachment 875453 [details]
File: backtrace
Comment 2 fr.haifler 2014-03-17 11:51:51 UTC 
Created attachment 875454 [details]
File: cgroup
Comment 3 fr.haifler 2014-03-17 11:51:53 UTC 
Created attachment 875455 [details]
File: core_backtrace
Comment 4 fr.haifler 2014-03-17 11:51:55 UTC 
Created attachment 875456 [details]
File: dso_list
Comment 5 fr.haifler 2014-03-17 11:51:57 UTC 
Created attachment 875457 [details]
File: environ
Comment 6 fr.haifler 2014-03-17 11:51:59 UTC 
Created attachment 875458 [details]
File: exploitable
Comment 7 fr.haifler 2014-03-17 11:52:01 UTC 
Created attachment 875459 [details]
File: limits
Comment 8 fr.haifler 2014-03-17 11:52:05 UTC 
Created attachment 875460 [details]
File: maps
Comment 9 fr.haifler 2014-03-17 11:52:07 UTC 
Created attachment 875461 [details]
File: open_fds
Comment 10 fr.haifler 2014-03-17 11:52:09 UTC 
Created attachment 875462 [details]
File: proc_pid_status
Comment 11 fr.haifler 2014-03-17 11:52:11 UTC 
Created attachment 875463 [details]
File: var_log_messages
Comment 12 Tomáš Hozza 2014-03-17 14:52:14 UTC 
Hi.

This looks familiar. Have you been running multiple instances of wget 
simultaneously in the same directory when this happened?
Comment 13 fr.haifler 2014-03-18 09:27:24 UTC 
(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.
Comment 14 Tomáš Hozza 2014-03-21 11:55:03 UTC 
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.
Comment 15 fr.haifler 2014-03-21 21:13:55 UTC 
Created attachment 877506 [details]
Tarball with directory created by wget
Comment 16 fr.haifler 2014-03-21 21:19:25 UTC 
(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).
Comment 17 fr.haifler 2014-03-21 21:24:17 UTC 
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.
Comment 18 Tomáš Hozza 2014-12-16 17:07:11 UTC 
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.