Bug 1039352

Summary: [abrt] coreutils-8.21-11.fc19: __mempcpy_sse2: Process /usr/bin/tr was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: George Sicherman <colonel>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: admiller, colonel, kdudka, kzak, ooprala, ovasik, p, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/f9d7d33639c0812e0a25015a0c7b28111c7afee3
Whiteboard: abrt_hash:2d9bc2404088ccc93ee7bade35258fa76a1021fb
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-09 12:27:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
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

Description George Sicherman 2013-12-08 16:40:25 UTC 
Version-Release number of selected component:
coreutils-8.21-11.fc19

Additional info:
reporter:       libreport-2.1.9
backtrace_rating: 4
cmdline:        tr '\\001' '\\012'
crash_function: __mempcpy_sse2
executable:     /usr/bin/tr
kernel:         3.11.9-200.fc19.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (4 frames)
 #0 __mempcpy_sse2 at ../sysdeps/x86_64/memcpy.S:272
 #1 _IO_default_xsputn at genops.c:464
 #2 _IO_new_file_xsputn at fileops.c:1348
 #3 fwrite_unlocked at iofwrite_u.c:46
Comment 1 George Sicherman 2013-12-08 16:40:30 UTC 
Created attachment 834086 [details]
File: backtrace
Comment 2 George Sicherman 2013-12-08 16:40:32 UTC 
Created attachment 834087 [details]
File: cgroup
Comment 3 George Sicherman 2013-12-08 16:40:33 UTC 
Created attachment 834088 [details]
File: core_backtrace
Comment 4 George Sicherman 2013-12-08 16:40:35 UTC 
Created attachment 834089 [details]
File: dso_list
Comment 5 George Sicherman 2013-12-08 16:40:36 UTC 
Created attachment 834090 [details]
File: environ
Comment 6 George Sicherman 2013-12-08 16:40:38 UTC 
Created attachment 834091 [details]
File: exploitable
Comment 7 George Sicherman 2013-12-08 16:40:40 UTC 
Created attachment 834092 [details]
File: limits
Comment 8 George Sicherman 2013-12-08 16:40:41 UTC 
Created attachment 834093 [details]
File: maps
Comment 9 George Sicherman 2013-12-08 16:40:43 UTC 
Created attachment 834094 [details]
File: open_fds
Comment 10 George Sicherman 2013-12-08 16:40:45 UTC 
Created attachment 834095 [details]
File: proc_pid_status
Comment 11 George Sicherman 2013-12-08 16:40:46 UTC 
Created attachment 834096 [details]
File: var_log_messages
Comment 12 Ondrej Vasik 2013-12-09 11:57:32 UTC 
Is that reproducible or it was just one time crash ? 
If reproducible, can we get full reproducer (input file for cat <foobar> | tr '\\001' '\\012' or something like that)? I'm not able to reproduce it with the part available in the traceback. It is strange to see fwrite segfaulting just in the middle of the 8192 long chunk.
Thanks in advance for the additional information.
Comment 13 George Sicherman 2014-06-09 12:27:52 UTC 
I think the disk partition was full.  There is probably nothing wrong with tr(1).
I am withdrawing this request.