Bug 1177363

Summary: [abrt] tar killed by SIGSEGV (segfault in malloc)
Product: [Fedora] Fedora Reporter: Rick <rracicot>
Component: tarAssignee: Pavel Raiskup <praiskup>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: arjun, codonell, jakub, kdudka, law, ovasik, pfrankli, praiskup, spoyarek
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/dc7ffb8aacba989aa62877bd36723633ac267658
Whiteboard: abrt_hash:24a603326cd0381789105739d0d584567757dff1
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-12-29 15:01:20 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

Description Rick 2014-12-26 17:32:35 UTC 
Version-Release number of selected component:
tar-1.26-31.fc20

Additional info:
reporter:       libreport-2.2.3
backtrace_rating: 4
cmdline:        tar cfz /run/user/1000/gvfs/smb-share:server=ls-xleca,share=bumbler14_backup/Backup-full_backup-2014-12-25_13-00.tar.gz -S -h / '/tmp/rpm - Package list - tmp5jvWTp.txt'
crash_function: xmalloc
executable:     /usr/bin/tar
kernel:         3.17.7-200.fc20.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #1 xmalloc at xmalloc.c:45
 #2 xmemdup at xmalloc.c:109
 #3 xstrdup at xmalloc.c:117
 #4 assign_string at misc.c:41
 #5 dump_file0 at create.c:1653
 #6 dump_file at create.c:1959
 #7 dump_dir0 at create.c:1219
 #8 dump_dir at create.c:1312
 #9 dump_file0 at create.c:1756
 #10 dump_file at create.c:1959
Comment 1 Rick 2014-12-26 17:33:14 UTC 
Created attachment 973225 [details]
File: backtrace
Comment 2 Rick 2014-12-26 17:33:15 UTC 
Created attachment 973226 [details]
File: cgroup
Comment 3 Rick 2014-12-26 17:35:05 UTC 
Created attachment 973237 [details]
File: core_backtrace
Comment 4 Rick 2014-12-26 17:35:06 UTC 
Created attachment 973238 [details]
File: dso_list
Comment 5 Rick 2014-12-26 17:35:07 UTC 
Created attachment 973239 [details]
File: environ
Comment 6 Rick 2014-12-26 17:35:08 UTC 
Created attachment 973240 [details]
File: exploitable
Comment 7 Rick 2014-12-26 17:35:09 UTC 
Created attachment 973241 [details]
File: limits
Comment 8 Rick 2014-12-26 17:35:10 UTC 
Created attachment 973242 [details]
File: maps
Comment 9 Rick 2014-12-26 17:35:12 UTC 
Created attachment 973243 [details]
File: open_fds
Comment 10 Rick 2014-12-26 17:35:13 UTC 
Created attachment 973244 [details]
File: proc_pid_status
Comment 11 Rick 2014-12-26 17:35:14 UTC 
Created attachment 973245 [details]
File: var_log_messages
Comment 12 Ondrej Vasik 2014-12-26 18:33:42 UTC 
Hmmmms, based on the backtrace it looks like "/proc/self/task/18425/fd/4/proc/self/task/18425..." are cross symlinks - causing infinite filename value(which later causes xstrdup failure). Assigning to Pavel - as he is probably aware whether this was already fixed or not in rawhide/f21.
Comment 13 Pavel Raiskup 2014-12-29 14:57:34 UTC 
Yes, the problem causing this segfault is duplicate of (not yet fixed) bug
1115890.  However, I'm not sure whether glibc's malloc should ever SEGFAULT,
this should rather end up with 'memory exhausted' tar's error after not
successfull xmalloc().

Re-assigning against glibc.
Comment 14 Pavel Raiskup 2014-12-29 15:01:20 UTC 
Oh, no, sorry - it was just bad luck stack overflow happened in malloc.

*** This bug has been marked as a duplicate of bug 1115890 ***
Comment 15 Carlos O'Donell 2014-12-29 15:36:22 UTC 
(In reply to Pavel Raiskup from comment #13)
> Yes, the problem causing this segfault is duplicate of (not yet fixed) bug
> 1115890.  However, I'm not sure whether glibc's malloc should ever SEGFAULT,
> this should rather end up with 'memory exhausted' tar's error after not
> successfull xmalloc().
> 
> Re-assigning against glibc.

I know the bug is closed and it has been acknowledged to be a stack overflow in tar, but I wanted to comment briefly on the question of "Should malloc ever SEGFAULT?" The answer to that question is "Yes it might SEGFAULT and we can't guarantee, and don't want to guarantee, that it never SEGFAULT." The reason is that corruption of the block accounting data is possible in such a way that would cause malloc to crash. Preventing such a crash would have steep performance costs that an average-case allocator should not need to pay. Anything that might cause undefined behaviour in your program, for example a stack overflow, can cause any core glibc function to do anything, including crash. We're looking at adding an "ultra safe" allocator in glibc to use as a fallback while the application is shutting down from a detected corruption, which should make it easier to shutdown gracefully from abort, but it won't help you unless you can detect the problem. Unfortunately failure detection is often 9/10th of the problem. Hopefully that answers your question.