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
Created attachment 1070645 [details] File: backtrace
Created attachment 1070646 [details] File: cgroup
Created attachment 1070647 [details] File: core_backtrace
Created attachment 1070648 [details] File: dso_list
Created attachment 1070649 [details] File: environ
Created attachment 1070650 [details] File: limits
Created attachment 1070651 [details] File: maps
Created attachment 1070652 [details] File: mountinfo
Created attachment 1070653 [details] File: namespaces
Created attachment 1070654 [details] File: open_fds
Created attachment 1070655 [details] File: proc_pid_status
Created attachment 1070656 [details] File: var_log_messages
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)
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days