Bug 921725

Summary: [abrt] cpio-2.11-17.fc19: process_copy_in: Process /usr/bin/cpio was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: Nicolas Mailhot <nicolas.mailhot>
Component: cpioAssignee: Pavel Raiskup <praiskup>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: kdudka, ovasik, praiskup, rjones
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:df3100bd690d61161879d96037bb4f4bf3a587e4
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-15 17:48:16 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: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: smolt_data
none
File: var_log_messages none

Description Nicolas Mailhot 2013-03-14 18:57:49 UTC
Version-Release number of selected component:
cpio-2.11-17.fc19

Additional info:
backtrace_rating: 4
cmdline:        /usr/bin/cpio -i -t -v
crash_function: process_copy_in
executable:     /usr/bin/cpio
kernel:         3.9.0-0.rc1.git2.1.fc19.x86_64
uid:            993

Truncated backtrace:
Thread no. 1 (1 frames)
 #1 process_copy_in

Comment 1 Nicolas Mailhot 2013-03-14 18:57:52 UTC
Created attachment 710162 [details]
File: backtrace

Comment 2 Nicolas Mailhot 2013-03-14 18:57:54 UTC
Created attachment 710163 [details]
File: cgroup

Comment 3 Nicolas Mailhot 2013-03-14 18:57:56 UTC
Created attachment 710164 [details]
File: core_backtrace

Comment 4 Nicolas Mailhot 2013-03-14 18:57:58 UTC
Created attachment 710165 [details]
File: dso_list

Comment 5 Nicolas Mailhot 2013-03-14 18:58:00 UTC
Created attachment 710166 [details]
File: environ

Comment 6 Nicolas Mailhot 2013-03-14 18:58:02 UTC
Created attachment 710167 [details]
File: limits

Comment 7 Nicolas Mailhot 2013-03-14 18:58:04 UTC
Created attachment 710168 [details]
File: maps

Comment 8 Nicolas Mailhot 2013-03-14 18:58:05 UTC
Created attachment 710169 [details]
File: open_fds

Comment 9 Nicolas Mailhot 2013-03-14 18:58:07 UTC
Created attachment 710170 [details]
File: proc_pid_status

Comment 10 Nicolas Mailhot 2013-03-14 18:58:09 UTC
Created attachment 710171 [details]
File: smolt_data

Comment 11 Nicolas Mailhot 2013-03-14 18:58:11 UTC
Created attachment 710172 [details]
File: var_log_messages

Comment 12 Pavel Raiskup 2013-03-15 09:41:56 UTC
(In reply to comment #0)
> Version-Release number of selected component:
> cpio-2.11-17.fc19
>
> Additional info:
> backtrace_rating: 4
> cmdline:        /usr/bin/cpio -i -t -v
> crash_function: process_copy_in
> executable:     /usr/bin/cpio
> kernel:         3.9.0-0.rc1.git2.1.fc19.x86_64
> uid:            993
>
> Truncated backtrace:
> Thread no. 1 (1 frames)
>  #1 process_copy_in

Hi Nicolas, thanks for posting this report.  This crash is definitely related
to #919454.  Even if I tend to revert these changes, I would like to give it a
little bit more investigation here.

Especially useful would be the list of files in extracted archive.  Or the
archive itself / or the circumstances under you were running the
'/usr/bin/cpio -i -t -v'.

Pavel

Comment 13 Nicolas Mailhot 2013-03-15 12:43:06 UTC
Unfortunately, gnome-abrt is so broken right now, I haven't the faintest idea what archive triggered this report. gnome-abrt does not seem to message on crash (I have to run it manually and it informs me crashes occurred in the past days) and clicking on any part of its UI except for next next next crashes gnome-abrt itself (it seems to be a GTK3 bug)

Did you see any specific file name in the crash data?  I could try to locate it on disk if it still exists

Comment 14 Pavel Raiskup 2013-03-15 13:19:06 UTC
> Did you see any specific file name in the crash data?  I could try to locate
> it on disk if it still exists

Unfortunately not, I don't see any name of archive (it was run in pipeline - so
the archive was read from standard input).  I also don't see any file name
contained inside the archive.

Well - as you are unable to find the source problem, the most reasonable thing
is reverting the not so important free() call.

If you would agree, I'll close this as a duplicate of the bz #919454 and
resolve this issue there.  Thanks a lot for posting this problem so early!

Pavel

Comment 15 Nicolas Mailhot 2013-03-15 16:38:19 UTC
No problem in closing this, I was paying my tester dues, as long as you've found the problem all ends well.

Comment 16 Pavel Raiskup 2013-03-15 17:48:16 UTC
Nicolas, thanks again for your work!  No need to make this duplicate I hope
now.  Just make it CLOSED CURRENTRELESE.  Re-applying of the patch may be done
possibly under the original memory leak bugreport.

Pavel