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