Bug 973462

Summary: [abrt] gnome-abrt-0.2.12-2.fc18: ci_get_name: Process /usr/bin/python2.7 was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: Alan Schmidt <bucky>
Component: libreportAssignee: Jakub Filak <jfilak>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: abrt-devel-list, bucky, dvlasenk, jberan, jfilak, jmoskovc, mlichvar, mmilata, mtoman
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Unspecified   
Whiteboard: abrt_hash:2b6e0eea19a046556c273c216d8903e7269ee792
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-08 15:23:38 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

Description Alan Schmidt 2013-06-12 01:15:21 UTC 
Description of problem:
I was trying to convince abrt to report a problem with mythtv-frontend.

After about the 3rd attempt without relaunching abrt in between, abrt just up and died.

Version-Release number of selected component:
gnome-abrt-0.2.12-2.fc18

Additional info:
reporter:       libreport-2.1.4
backtrace_rating: 4
cmdline:        python /usr/bin/gnome-abrt
crash_function: ci_get_name
executable:     /usr/bin/python2.7
kernel:         3.9.4-200.fc18.i686.PAE
runlevel:       N 5
uid:            1001
var_log_messages: Jun 11 18:06:05 mythtv abrt[30307]: Saved core dump of pid 29452 (/usr/bin/python2.7) to /var/tmp/abrt/ccpp-2013-06-11-18:06:01-29452 (62263296 bytes)
xsession_errors: 

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 ci_get_name at config_item_info.c:77
 #1 ec_get_name at event_config.c:64
 #2 libreport_load_single_event_config_data_from_user_storage at secrets.c:1516
 #3 load_single_event_config_foreach at workflow_config_dialog.c:119
 #4 g_list_foreach at glist.c:942
 #5 load_events_foreach_workflow at workflow_config_dialog.c:124
 #6 g_hash_table_foreach at ghash.c:1524
 #7 load_workflow_config_data_from_user_storage at workflow_config_dialog.c:129
 #8 show_config_list_dialog at config_dialog.c:348
 #9 p_show_events_list_dialog at configure.c:31
Comment 1 Alan Schmidt 2013-06-12 01:15:24 UTC 
Created attachment 759897 [details]
File: backtrace
Comment 2 Alan Schmidt 2013-06-12 01:15:27 UTC 
Created attachment 759898 [details]
File: cgroup
Comment 3 Alan Schmidt 2013-06-12 01:15:29 UTC 
Created attachment 759899 [details]
File: core_backtrace
Comment 4 Alan Schmidt 2013-06-12 01:15:31 UTC 
Created attachment 759900 [details]
File: dso_list
Comment 5 Alan Schmidt 2013-06-12 01:15:33 UTC 
Created attachment 759901 [details]
File: environ
Comment 6 Alan Schmidt 2013-06-12 01:15:36 UTC 
Created attachment 759902 [details]
File: limits
Comment 7 Alan Schmidt 2013-06-12 01:15:38 UTC 
Created attachment 759903 [details]
File: maps
Comment 8 Alan Schmidt 2013-06-12 01:15:40 UTC 
Created attachment 759904 [details]
File: open_fds
Comment 9 Alan Schmidt 2013-06-12 01:15:43 UTC 
Created attachment 759905 [details]
File: proc_pid_status
Comment 10 Jakub Filak 2013-08-08 09:19:22 UTC 
Thank you for the bug report. Could you please attach coredump? The file should be placed in /var/tmp/abrt/ccpp-2013-06-11-18:06:01-29452
Comment 11 Alan Schmidt 2013-08-08 15:03:32 UTC 
At this point, all I have in that directory is "time", "uid", and a file called "not-reportable."

"time" and "uid" have the original timestamps, but "not-reportable" is timestamped August 6, which just so happens to match the install date of

abrt-2.1.6-2.fc19.i686
libreport-2.1.6-2.fc19.i686

("not-reportable" is only 15 minutes newer).

If it truly was "not-reportable," then maybe the core dump wouldn't have done any good, anyway. :-(

I'm okay with closing this because of insufficient data.
Comment 12 Jakub Filak 2013-08-08 15:23:38 UTC 
Thank you for your efforts in solving this bug.