Bug 884953

Summary: [abrt] baobab-3.4.1-2.fc17: node_set_visible: Process /usr/bin/baobab was killed by signal 6 (SIGABRT)
Product: [Fedora] Fedora Reporter: Jeff Raber <jeff.raber>
Component: baobabAssignee: Rui Matos <tiagomatos>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: tiagomatos
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:c296cec6d2efb7c7035e96627b526b0c36c6375c
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-01 12:33:04 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: core_backtrace
none
File: environ
none
File: limits
none
File: backtrace
none
File: cgroup
none
File: smolt_data
none
File: executable
none
File: maps
none
File: dso_list
none
File: proc_pid_status
none
File: var_log_messages
none
File: open_fds none

Description Jeff Raber 2012-12-07 07:07:37 UTC 
Description of problem:
Started the scan of a directory then alomst immediately switched to a different open window.
The directory structure I was scanning has many thousands of hardlinks (don't know if that matters).

It is also possible that the directory contents were changing (because the execution of a scheduled job) while the scan was running.


Version-Release number of selected component:
baobab-3.4.1-2.fc17

Additional info:
libreport version: 2.0.18
abrt_version:   2.0.18
backtrace_rating: 4
cmdline:        baobab
crash_function: node_set_visible
kernel:         3.6.7-4.fc17.x86_64

truncated backtrace:
:Thread no. 1 (10 frames)
: #4 node_set_visible at gtkfilesystemmodel.c:328
: #5 remove_file at gtkfilesystemmodel.c:1775
: #6 gtk_file_system_model_monitor_change at gtkfilesystemmodel.c:1187
: #7 ffi_call_unix64 at ../src/x86/unix64.S:75
: #8 ffi_call at ../src/x86/ffi64.c:486
: #9 g_cclosure_marshal_generic_va at gclosure.c:1550
: #10 _g_closure_invoke_va at gclosure.c:840
: #13 emit_cb at gfilemonitor.c:390
: #17 g_main_context_iteration at gmain.c:3207
: #18 gtk_main_iteration at gtkmain.c:1261
Comment 1 Jeff Raber 2012-12-07 07:07:55 UTC 
Created attachment 659215 [details]
File: core_backtrace
Comment 2 Jeff Raber 2012-12-07 07:07:57 UTC 
Created attachment 659216 [details]
File: environ
Comment 3 Jeff Raber 2012-12-07 07:07:58 UTC 
Created attachment 659217 [details]
File: limits
Comment 4 Jeff Raber 2012-12-07 07:08:00 UTC 
Created attachment 659218 [details]
File: backtrace
Comment 5 Jeff Raber 2012-12-07 07:08:01 UTC 
Created attachment 659219 [details]
File: cgroup
Comment 6 Jeff Raber 2012-12-07 07:08:03 UTC 
Created attachment 659220 [details]
File: smolt_data
Comment 7 Jeff Raber 2012-12-07 07:08:04 UTC 
Created attachment 659221 [details]
File: executable
Comment 8 Jeff Raber 2012-12-07 07:08:06 UTC 
Created attachment 659222 [details]
File: maps
Comment 9 Jeff Raber 2012-12-07 07:08:07 UTC 
Created attachment 659223 [details]
File: dso_list
Comment 10 Jeff Raber 2012-12-07 07:08:09 UTC 
Created attachment 659224 [details]
File: proc_pid_status
Comment 11 Jeff Raber 2012-12-07 07:08:10 UTC 
Created attachment 659225 [details]
File: var_log_messages
Comment 12 Jeff Raber 2012-12-07 07:08:12 UTC 
Created attachment 659226 [details]
File: open_fds
Comment 13 Jeff Raber 2012-12-07 07:15:05 UTC 
Scanning a directory while the contents of the directory are being modified by a backup script (cron job).

backtrace_rating: 4
Package: baobab-3.4.1-2.fc17
OS Release: Fedora release 17 (Beefy Miracle)
Comment 14 Jeff Raber 2012-12-07 07:15:55 UTC 
It seems that I am able to reproduce the crash by running the scan at the same time that my scheduled backup job is running.

The backup script moves and deletes directories before creating the new backup data.  I can provide a copy of the script if it is needed.
Comment 15 Fedora End Of Life 2013-07-04 04:03:16 UTC 
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 16 Fedora End Of Life 2013-08-01 12:33:09 UTC 
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.