On Thu, 2017-12-14 at 11:00 -0600, Michael Cronenworth wrote: > Hi all, > > Has anyone on the desktop team given much attention to a crasher I see daily (often > multiple times) and my inbox fills with new comments every other day? > > https://bugzilla.redhat.com/show_bug.cgi?id=1510059 > > If not I will push it upstream. I think this is another case of false duping. If you look at the "dupes" - especially I find it useful to look at the somewhat-wrongly- named var_log_messages log, which is actually a record of system log messages (whether actually from /var/log/messages or from the journal) around the time of the crash - you'll see that they really have nothing in common. What I think is going on in several bugs like this is that there are many ways to produce a very similar traceback, because of this `_g_log_abort` function in glib. What that basically is - I went and looked at it - is a sort of 'special' logging function which, when called, is intended to log a message and then terminate the app. I think in many cases the same 3 or 4 frames appear in the trace around the `_g_log_abort` call - in this case it's these frames that seem to appear in all the tracebacks: #0 raise at ../sysdeps/unix/sysv/linux/raise.c:51 #1 dump_gjs_stack_on_signal_handler at ../src/main.c:372 #3 _g_log_abort at gmessages.c:554 but after that, the traces may differ. There appear to be a few patterns for the next two frames, like: #4 g_log_default_handler at gmessages.c:3051 #5 default_log_handler at ../src/main.c:315 or: #4 g_log_writer_default at gmessages.c:2628 #5 g_log_structured_array at gmessages.c:1941 but we're still basically just in "log something" codepaths. Once you follow the traces back past the "log something" frames to the frames which indicate what was actually *going on*, they're often different. So in your report we have: #9 xkl_process_error at xklavier_evt.c:541 #14 XPending at Pending.c:55 #15 gdk_check_xpending at gdkeventsource.c:269 #16 gdk_event_source_check at gdkeventsource.c:306 (xklavier is to do with keyboards, IIRC). But in the first few "dupes", we see: #8 clutter_box_layout_allocate at clutter-box-layout.c:1010 #9 st_widget_allocate at ../src/st/st-widget.c:426 #10 st_box_layout_allocate at ../src/st/st-box-layout.c:288 #11 clutter_actor_allocate_internal at clutter-actor.c:9972 #12 clutter_actor_set_animatable_property at clutter-actor.c:14986 #8 x_io_error at wayland/meta-xwayland.c:418 #10 _XReadEvents at xcb_io.c:400 #11 XIfEvent at IfEvent.c:68 #12 meta_display_get_current_time_roundtrip at core/display.c:1332 #13 meta_wayland_surface_destroy_window at wayland/meta-wayland- surface.c:430 #8 x_io_error at wayland/meta-xwayland.c:418 #11 XPending at Pending.c:55 #12 gdk_check_xpending at gdkeventsource.c:269 #13 gdk_event_source_prepare at gdkeventsource.c:287 #14 g_main_context_prepare at gmain.c:3450 #8 object_instance_finalize at gi/object.cpp:1490 #9 js::Class::doFinalize at /usr/src/debug/mozjs52-52.4.0- 1.fc27.x86_64/dist/include/js/Class.h:816 #10 JSObject::finalize at /usr/src/debug/mozjs52-52.4.0- 1.fc27.x86_64/jsobjinlines.h:87 #11 js::gc::Arena::finalize<JSObject> at /usr/src/debug/mozjs52- 52.4.0-1.fc27.x86_64/jsgc.cpp:457 #12 FinalizeTypedArenas<JSObject>(js::FreeOp *, js::gc::Arena **, js::gc::SortedArenaList &, enum class AllocKind, SliceBudget &, js::gc::ArenaLists::KeepArenasEnum) at /usr/src/debug/mozjs52-52.4.0- 1.fc27.x86_64/jsgc.cpp:515 #8 g_malloc0 at gmem.c:129 #9 blur_pixels at ../src/st/st-private.c:280 #10 _st_create_shadow_pipeline at ../src/st/st-private.c:372 #11 _st_create_shadow_pipeline_from_actor at ../src/st/st- private.c:434 #12 st_icon_update_shadow_pipeline at ../src/st/st-icon.c:278 #8 clutter_box_layout_allocate at clutter-box-layout.c:1010 #9 st_widget_allocate at ../src/st/st-widget.c:426 #10 st_box_layout_allocate at ../src/st/st-box-layout.c:288 #11 clutter_actor_allocate_internal at clutter-actor.c:9972 #12 clutter_actor_set_animatable_property at clutter-actor.c:14986 #8 x_io_error at wayland/meta-xwayland.c:418 #11 XPending at Pending.c:55 #12 gdk_check_xpending at gdkeventsource.c:269 #13 gdk_event_source_prepare at gdkeventsource.c:287 #14 g_main_context_prepare at gmain.c:3450 #8 g_malloc0 at gmem.c:129 #9 blur_pixels at ../src/st/st-private.c:280 #10 _st_create_shadow_pipeline at ../src/st/st-private.c:372 #11 _st_create_shadow_pipeline_from_actor at ../src/st/st- private.c:434 #12 st_icon_update_shadow_pipeline at ../src/st/st-icon.c:278 #8 x_io_error at wayland/meta-xwayland.c:418 #10 _XReadEvents at xcb_io.c:400 #11 XIfEvent at IfEvent.c:68 #12 meta_display_get_current_time_roundtrip at core/display.c:1332 #13 meta_wayland_surface_destroy_window at wayland/meta-wayland-surface.c:430 There are a few cases there which look like dupes of each other, but there are at least 6 very *different* cases in there. They really don't look like they're dupes of each other at all. It would probably be a good idea to get some abrt/libreport and glib folks together to figure out how abrt/libreport can handle these `_g_log_abort` cases (and any other similar cases) better. For now, I'll try and go through all the "dupes" of this bug and clean them up. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
