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
Created attachment 710162 [details] File: backtrace
Created attachment 710163 [details] File: cgroup
Created attachment 710164 [details] File: core_backtrace
Created attachment 710165 [details] File: dso_list
Created attachment 710166 [details] File: environ
Created attachment 710167 [details] File: limits
Created attachment 710168 [details] File: maps
Created attachment 710169 [details] File: open_fds
Created attachment 710170 [details] File: proc_pid_status
Created attachment 710171 [details] File: smolt_data
Created attachment 710172 [details] File: var_log_messages
(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
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
> 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
No problem in closing this, I was paying my tester dues, as long as you've found the problem all ends well.
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