Version-Release number of selected component: colord-0.1.28-1.fc18 Additional info: backtrace_rating: 4 cmdline: /usr/libexec/colord core_backtrace: crash_function: standard_free executable: /usr/libexec/colord kernel: 3.8.1-201.fc18.i686 uid: 997 Truncated backtrace: Thread no. 1 (10 frames) #6 standard_free at gmem.c:98 #8 cd_inhibit_item_free at cd-inhibit.c:96 #9 g_ptr_array_remove_index at garray.c:1162 #10 g_ptr_array_remove at garray.c:1290 #11 cd_inhibit_remove at cd-inhibit.c:146 #12 cd_inhibit_name_vanished_cb at cd-inhibit.c:171 #13 actually_do_call at gdbusnamewatching.c:164 #14 do_call at gdbusnamewatching.c:216 #15 call_vanished_handler at gdbusnamewatching.c:242 #17 on_name_owner_changed at gdbusnamewatching.c:307
Created attachment 704614 [details] File: backtrace
Created attachment 704615 [details] File: build_ids
Created attachment 704616 [details] File: cgroup
Created attachment 704617 [details] File: dso_list
Created attachment 704618 [details] File: environ
Created attachment 704619 [details] File: limits
Created attachment 704620 [details] File: maps
Created attachment 704621 [details] File: open_fds
Created attachment 704622 [details] File: proc_pid_status
Created attachment 704623 [details] File: var_log_messages
I can't see how this crash is possible. Has it ever happened before? Is the hardware that this bug was generated on been tested for possible RAM problems?