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
Created attachment 973225 [details] File: backtrace
Created attachment 973226 [details] File: cgroup
Created attachment 973237 [details] File: core_backtrace
Created attachment 973238 [details] File: dso_list
Created attachment 973239 [details] File: environ
Created attachment 973240 [details] File: exploitable
Created attachment 973241 [details] File: limits
Created attachment 973242 [details] File: maps
Created attachment 973243 [details] File: open_fds
Created attachment 973244 [details] File: proc_pid_status
Created attachment 973245 [details] File: var_log_messages
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.
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.
Oh, no, sorry - it was just bad luck stack overflow happened in malloc. *** This bug has been marked as a duplicate of bug 1115890 ***
(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.