Bug 1260350

Summary: [abrt] gimp: gimp_id_table_remove(): gimp-2.8 killed by SIGSEGV
Product: [Fedora] Fedora Reporter: Brandon Amaro <omega13a>
Component: gimpAssignee: Nils Philippsen <nphilipp>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 22CC: nphilipp, omega13a, phracek
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/e735394a7e8a7beb51a1bb2a7ccf8f973e33433e
Whiteboard: abrt_hash:866414a78faffd72be38adf7691a05d6fa1273cf
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-06-03 11:55:55 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: mountinfo
none
File: namespaces
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Brandon Amaro 2015-09-06 06:38:08 UTC 
Version-Release number of selected component:
gimp-2.8.14-3.fc22

Additional info:
reporter:       libreport-2.6.2
backtrace_rating: 4
cmdline:        gimp-2.8 /run/user/1000/gvfs/smb-share:server=peeves.local,share=www/fedtrek.com/web/staff/omega13a/15-08-29_photos_A380/P8290180.JPG
crash_function: gimp_id_table_remove
executable:     /usr/bin/gimp-2.8
global_pid:     6018
kernel:         4.1.6-200.fc22.x86_64
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (6 frames)
 #0 gimp_id_table_remove at gimpidtable.c:231
 #1 gimp_item_finalize at gimpitem.c:343
 #3 g_datalist_clear at gdataset.c:273
 #5 gtk_drag_source_info_destroy at gtkdnd.c:3961
 #6 gtk_drag_anim_timeout at gtkdnd.c:3856
 #13 app_run at app.c:263
Comment 1 Brandon Amaro 2015-09-06 06:38:12 UTC 
Created attachment 1070645 [details]
File: backtrace
Comment 2 Brandon Amaro 2015-09-06 06:38:13 UTC 
Created attachment 1070646 [details]
File: cgroup
Comment 3 Brandon Amaro 2015-09-06 06:38:13 UTC 
Created attachment 1070647 [details]
File: core_backtrace
Comment 4 Brandon Amaro 2015-09-06 06:38:15 UTC 
Created attachment 1070648 [details]
File: dso_list
Comment 5 Brandon Amaro 2015-09-06 06:38:16 UTC 
Created attachment 1070649 [details]
File: environ
Comment 6 Brandon Amaro 2015-09-06 06:38:16 UTC 
Created attachment 1070650 [details]
File: limits
Comment 7 Brandon Amaro 2015-09-06 06:38:21 UTC 
Created attachment 1070651 [details]
File: maps
Comment 8 Brandon Amaro 2015-09-06 06:38:23 UTC 
Created attachment 1070652 [details]
File: mountinfo
Comment 9 Brandon Amaro 2015-09-06 06:38:25 UTC 
Created attachment 1070653 [details]
File: namespaces
Comment 10 Brandon Amaro 2015-09-06 06:38:27 UTC 
Created attachment 1070654 [details]
File: open_fds
Comment 11 Brandon Amaro 2015-09-06 06:38:30 UTC 
Created attachment 1070655 [details]
File: proc_pid_status
Comment 12 Brandon Amaro 2015-09-06 06:38:35 UTC 
Created attachment 1070656 [details]
File: var_log_messages
Comment 13 Nils Philippsen 2015-09-16 12:16:06 UTC 
What did you do when this crash happened? Can you reproduce it?

Note to self:

The id_table pointer in this function call looks very suspicious (2^33, "8 Giga").

Thread 1 (Thread 0x7fa2448c6980 (LWP 6018)):
#0  0x00005644acf04065 in gimp_id_table_remove (id_table=0x200000000, id=152) at gimpidtable.c:231
        __inst = 0x200000000
        __t = 94852996996928
        __r = <optimized out>
        __func__ = "gimp_id_table_remove"

The affected gimp->item_table member is only ever written directly in two places:

app/core/gimp.c:226:  gimp->item_table          = gimp_id_table_new ();

app/core/gimp.c:419:      g_object_unref (gimp->item_table);
app/core/gimp.c:420:      gimp->item_table = NULL;

So it's probably one of these, but it's nigh impossible to debug without being able to reproduce it:

- something overwrites the struct member through bad boundary checking or whatever
- one bit flipped in memory (HW fault)
Comment 14 Red Hat Bugzilla 2023-09-14 03:04:54 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days