You are not logged in.
- Topics: Active | Unanswered
#1 2023-04-09 01:35:54
- mavrent
- Member
- Registered: 2019-12-26
- Posts: 18
Looking to diagnose xfce4-panel crash
Can anyone think of why I might be getting crashes like this when I access the panel and mouse over certain entries? Steam is one easy way to reproduce this crash.
Apr 07 22:13:06 desktop kernel: xfce4-panel[62421] segfault at 1 ip 00007f30cf248e7c sp 00007ffd5e4fcd60 error 4 in libtasklist.so[7f30cf246000+c000] likely on CPU 10 (core 2, socket 0)
Apr 07 22:13:06 desktop kernel: Code: 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 90 83 7d 00 01 74 35 4c 8b 6d 60 4d 85 ed 0f 84 9d 01 00 00 ff 15 3f 3d 01 00 48 89 c6 <49> 8b 45 00 48 85 c0 74 05 48 39 30 74 11 4c 89 ef ff 15 25 3e 01
Apr 07 22:13:06 desktop systemd[1]: Started Process Core Dump (PID 63463/UID 0).
Apr 07 22:13:06 desktop systemd-coredump[63464]: Process 62421 (xfce4-panel) of user 1000 dumped core.
Stack trace of thread 62421:
#0 0x00007f30cf248e7c n/a (libtasklist.so + 0x8e7c)
#1 0x00007f30d0bb2f25 n/a (libglib-2.0.so.0 + 0x7af25)
#2 0x00007f30cf24f714 n/a (libtasklist.so + 0xf714)
#3 0x00007f30d0c95ca6 g_cclosure_marshal_VOID__OBJECTv (libgobject-2.0.so.0 + 0x12ca6)
#4 0x00007f30d0cb523c g_signal_emit_valist (libgobject-2.0.so.0 + 0x3223c)
#5 0x00007f30d0cb5324 g_signal_emit (libgobject-2.0.so.0 + 0x32324)
#6 0x00007f30d1977abc n/a (libwnck-3.so.0 + 0x18abc)
#7 0x00007f30d1978888 n/a (libwnck-3.so.0 + 0x19888)
#8 0x00007f30d0b9253b g_main_context_dispatch (libglib-2.0.so.0 + 0x5a53b)
#9 0x00007f30d0bef219 n/a (libglib-2.0.so.0 + 0xb7219)
#10 0x00007f30d0b91c7f g_main_loop_run (libglib-2.0.so.0 + 0x59c7f)
#11 0x00007f30d11d8e4f gtk_main (libgtk-3.so.0 + 0x1d8e4f)
#12 0x000055c5cb7743a5 main (xfce4-panel + 0x123a5)
#13 0x00007f30d0749790 n/a (libc.so.6 + 0x23790)
#14 0x00007f30d074984a __libc_start_main (libc.so.6 + 0x2384a)
#15 0x000055c5cb774905 _start (xfce4-panel + 0x12905)
Stack trace of thread 62432:
#0 0x00007f30d08260dd syscall (libc.so.6 + 0x1000dd)
#1 0x00007f30d0be87b5 g_cond_wait (libglib-2.0.so.0 + 0xb07b5)
#2 0x00007f30d0b5cfb4 n/a (libglib-2.0.so.0 + 0x24fb4)
#3 0x00007f30d0bc3f9e n/a (libglib-2.0.so.0 + 0x8bf9e)
#4 0x00007f30d0bbf315 n/a (libglib-2.0.so.0 + 0x87315)
#5 0x00007f30d07abbb5 n/a (libc.so.6 + 0x85bb5)
#6 0x00007f30d082dd90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 62433:
#0 0x00007f30d08209df __poll (libc.so.6 + 0xfa9df)
#1 0x00007f30d0bef17f n/a (libglib-2.0.so.0 + 0xb717f)
#2 0x00007f30d0b911a2 g_main_context_iteration (libglib-2.0.so.0 + 0x591a2)
#3 0x00007f30d0b911f2 n/a (libglib-2.0.so.0 + 0x591f2)
#4 0x00007f30d0bbf315 n/a (libglib-2.0.so.0 + 0x87315)
#5 0x00007f30d07abbb5 n/a (libc.so.6 + 0x85bb5)
#6 0x00007f30d082dd90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 62434:
#0 0x00007f30d08209df __poll (libc.so.6 + 0xfa9df)
#1 0x00007f30d0bef17f n/a (libglib-2.0.so.0 + 0xb717f)
#2 0x00007f30d0b91c7f g_main_loop_run (libglib-2.0.so.0 + 0x59c7f)
#3 0x00007f30d0df2d5c n/a (libgio-2.0.so.0 + 0x10ed5c)
#4 0x00007f30d0bbf315 n/a (libglib-2.0.so.0 + 0x87315)
#5 0x00007f30d07abbb5 n/a (libc.so.6 + 0x85bb5)
#6 0x00007f30d082dd90 n/a (libc.so.6 + 0x107d90)
ELF object binary architecture: AMD x86-64
Apr 07 22:13:06 desktop systemd[1]: systemd-coredump@13-63463-0.service: Deactivated successfully.Apr 08 21:30:33 desktop kernel: xfce4-panel[63470] segfault at 80 ip 00007f9cfa137706 sp 00007ffd0e388d80 error 4 in libgtk-3.so.0.2405.32[7f9cf9e84000+382000] likely on CPU 14 (core 6, socket 0)
Apr 08 21:30:33 desktop kernel: Code: d2 5b 89 d0 c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 53 48 85 ff 74 36 48 89 fb 67 e8 7d 04 ff ff 48 89 c6 <48> 8b 03 48 85 c0 74 05 48 39 30 74 0d 48 89 df ff 15 4c 2f 48 00
Apr 08 21:30:33 desktop systemd[1]: Started Process Core Dump (PID 81509/UID 0).
Apr 08 21:30:34 desktop systemd-coredump[81510]: Process 63470 (xfce4-panel) of user 1000 dumped core.
Stack trace of thread 63470:
#0 0x00007f9cfa137706 gtk_widget_get_visible (libgtk-3.so.0 + 0x337706)
#1 0x00007f9cf61b3d36 n/a (libtasklist.so + 0xed36)
#2 0x00007f9cf99b3210 g_closure_invoke (libgobject-2.0.so.0 + 0x14210)
#3 0x00007f9cf99e12f8 n/a (libgobject-2.0.so.0 + 0x422f8)
#4 0x00007f9cf99d1095 g_signal_emit_valist (libgobject-2.0.so.0 + 0x32095)
#5 0x00007f9cf99d1324 g_signal_emit (libgobject-2.0.so.0 + 0x32324)
#6 0x00007f9cfa13d66e n/a (libgtk-3.so.0 + 0x33d66e)
#7 0x00007f9cf99c1531 g_object_run_dispose (libgobject-2.0.so.0 + 0x22531)
#8 0x00007f9cf61af683 n/a (libtasklist.so + 0xa683)
#9 0x00007f9cf99b1ca6 g_cclosure_marshal_VOID__OBJECTv (libgobject-2.0.so.0 + 0x12ca6)
#10 0x00007f9cf99d123c g_signal_emit_valist (libgobject-2.0.so.0 + 0x3223c)
#11 0x00007f9cf99d1324 g_signal_emit (libgobject-2.0.so.0 + 0x32324)
#12 0x00007f9cfa693b12 n/a (libwnck-3.so.0 + 0x18b12)
#13 0x00007f9cfa694888 n/a (libwnck-3.so.0 + 0x19888)
#14 0x00007f9cf98ae53b g_main_context_dispatch (libglib-2.0.so.0 + 0x5a53b)
#15 0x00007f9cf990b219 n/a (libglib-2.0.so.0 + 0xb7219)
#16 0x00007f9cf98adc7f g_main_loop_run (libglib-2.0.so.0 + 0x59c7f)
#17 0x00007f9cf9fd8e4f gtk_main (libgtk-3.so.0 + 0x1d8e4f)
#18 0x00005618fb3d63a5 main (xfce4-panel + 0x123a5)
#19 0x00007f9cf9465790 n/a (libc.so.6 + 0x23790)
#20 0x00007f9cf946584a __libc_start_main (libc.so.6 + 0x2384a)
#21 0x00005618fb3d6905 _start (xfce4-panel + 0x12905)
Stack trace of thread 63475:
#0 0x00007f9cf95420dd syscall (libc.so.6 + 0x1000dd)
#1 0x00007f9cf99047b5 g_cond_wait (libglib-2.0.so.0 + 0xb07b5)
#2 0x00007f9cf9878fb4 n/a (libglib-2.0.so.0 + 0x24fb4)
#3 0x00007f9cf98dff9e n/a (libglib-2.0.so.0 + 0x8bf9e)
#4 0x00007f9cf98db315 n/a (libglib-2.0.so.0 + 0x87315)
#5 0x00007f9cf94c7bb5 n/a (libc.so.6 + 0x85bb5)
#6 0x00007f9cf9549d90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 63476:
#0 0x00007f9cf953c9df __poll (libc.so.6 + 0xfa9df)
#1 0x00007f9cf990b17f n/a (libglib-2.0.so.0 + 0xb717f)
#2 0x00007f9cf98ad1a2 g_main_context_iteration (libglib-2.0.so.0 + 0x591a2)
#3 0x00007f9cf98ad1f2 n/a (libglib-2.0.so.0 + 0x591f2)
#4 0x00007f9cf98db315 n/a (libglib-2.0.so.0 + 0x87315)
#5 0x00007f9cf94c7bb5 n/a (libc.so.6 + 0x85bb5)
#6 0x00007f9cf9549d90 n/a (libc.so.6 + 0x107d90)
Stack trace of thread 63477:
#0 0x00007f9cf953c9df __poll (libc.so.6 + 0xfa9df)
#1 0x00007f9cf990b17f n/a (libglib-2.0.so.0 + 0xb717f)
#2 0x00007f9cf98adc7f g_main_loop_run (libglib-2.0.so.0 + 0x59c7f)
#3 0x00007f9cf9b0ed5c n/a (libgio-2.0.so.0 + 0x10ed5c)
#4 0x00007f9cf98db315 n/a (libglib-2.0.so.0 + 0x87315)
#5 0x00007f9cf94c7bb5 n/a (libc.so.6 + 0x85bb5)
#6 0x00007f9cf9549d90 n/a (libc.so.6 + 0x107d90)
ELF object binary architecture: AMD x86-64
Apr 08 21:30:34 desktop systemd[1]: systemd-coredump@14-81509-0.service: Deactivated successfully. Offline
#2 2023-04-09 06:12:24
- mavrent
- Member
- Registered: 2019-12-26
- Posts: 18
Re: Looking to diagnose xfce4-panel crash
I have this fixed by rolling back libwnck3 to 43.0-2. The crash can be reproduced by mousing over the friends list in steam.
Offline
#3 2023-04-09 16:45:30
- lambdarch
- Member
- Registered: 2021-01-10
- Posts: 79
Re: Looking to diagnose xfce4-panel crash
It would be nice if you could provide full backtraces: see
https://wiki.archlinux.org/title/Core_d … _core_dump
https://wiki.archlinux.org/title/Debugg … Debuginfod
See also these links, maybe it's the same issue:
https://forum.xfce.org/viewtopic.php?id=16622
https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/730
aka Tamaranch: https://gitlab.xfce.org/Tamaranch
Offline
#4 2023-04-09 18:37:05
- seth
- Member
- Registered: 2012-09-03
- Posts: 58,717
Re: Looking to diagnose xfce4-panel crash
One more victim of the glib2 update?
(Try to downgrade to glib2 2.74.6-1)
Offline
#5 2023-04-13 01:22:36
- mavrent
- Member
- Registered: 2019-12-26
- Posts: 18
Re: Looking to diagnose xfce4-panel crash
One more victim of the glib2 update?
(Try to downgrade to glib2 2.74.6-1)
Is there a way to do this and simultaneously downgrade all it's dependencies? It seems downgrading just glib2 breaks many things.
Offline
#6 2023-04-13 05:59:30
- seth
- Member
- Registered: 2012-09-03
- Posts: 58,717
Re: Looking to diagnose xfce4-panel crash
https://wiki.archlinux.org/title/Arch_L … cific_date
However:
It seems downgrading just glib2 breaks many things.
Does it? Which and how exactly?
Offline
#7 2023-04-13 07:54:07
- lambdarch
- Member
- Registered: 2021-01-10
- Posts: 79
Re: Looking to diagnose xfce4-panel crash
Maybe tracker3 as in https://forum.xfce.org/viewtopic.php?pid=71588#p71588
If so please try to downgrade also tracker3 to 3.4.2.
Also, as said above, full backtraces would be much appreciated (especially for the first crash).
aka Tamaranch: https://gitlab.xfce.org/Tamaranch
Offline
#8 2023-04-15 04:01:20
- mavrent
- Member
- Registered: 2019-12-26
- Posts: 18
Re: Looking to diagnose xfce4-panel crash
Here's the last 5 coredump files saved from xfce4-panel.
https://mega.nz/file/XRE0XIAJ#SSJ-QbBauI46tR1WWfzfkjbCPos_0yksOH6d5LC0cLs
https://mega.nz/file/rY8HyRba#kd7sw5_1gE3EUaXRhUaDYBBkWP9fusRDMLq7mG_xsm8
https://mega.nz/file/LAkTgBJK#axMd4JAIfv4wHZKb8GXy5ZHErFFi-wkvyealE1oqLYA
https://mega.nz/file/KEdjxJ6D#tgofzCbzynOq9BCznQrq_jtbRYsDPWnZTFYuFjBXo5s
https://mega.nz/file/TB0w2YxA#uUfSmXLkGmvAVSzectqRFfNC_uUtQ6m_T3rhes2xA3EOffline
#9 2023-04-15 14:41:14
- lambdarch
- Member
- Registered: 2021-01-10
- Posts: 79
Re: Looking to diagnose xfce4-panel crash
The first four coredumps correspond to the second trace above and to the one already reported in the Xfce forum:
Core was generated by `xfce4-panel --display :0.0 --sm-client-id 2efa10307-33c5-47c5-95e9-4bdc880c5a6e'.
Program terminated with signal SIGSEGV, Segmentation fault.
warning: Section `.reg-xstate/61042' in core file too small.
#0 0x00007fcb56d37706 in gtk_widget_get_visible (widget=0x80) at ../gtk/gtk/gtkwidget.c:9126
9126 g_return_val_if_fail (GTK_IS_WIDGET (widget), FALSE);
[Current thread is 1 (Thread 0x7fcb55008600 (LWP 61042))]
(gdb) bt
#0 0x00007fcb56d37706 in gtk_widget_get_visible (widget=0x80) at ../gtk/gtk/gtkwidget.c:9126
#1 0x00007fcb52e96d36 in xfce_tasklist_group_button_child_visible_changed (group_child=0x5566ed541370) at /usr/src/debug/xfce4-panel/xfce4-panel-4.18.3/plugins/tasklist/tasklist-widget.c:4399
#2 0x00007fcb566ac210 in g_closure_invoke (closure=0x5566ed7a1de0, return_value=0x0, n_param_values=1, param_values=0x7fff54db7d30, invocation_hint=0x7fff54db7cb0) at ../glib/gobject/gclosure.c:832
#3 0x00007fcb566da2f8 in signal_emit_unlocked_R.isra.0
(node=node@entry=0x5566ed507270, detail=detail@entry=0, instance=instance@entry=0x5566ed447d80, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fff54db7d30)
at ../glib/gobject/gsignal.c:3802
#4 0x00007fcb566ca095 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fff54db7ed0) at ../glib/gobject/gsignal.c:3555
#5 0x00007fcb566ca324 in g_signal_emit (instance=instance@entry=0x5566ed447d80, signal_id=<optimized out>, detail=detail@entry=0) at ../glib/gobject/gsignal.c:3612
#6 0x00007fcb56d3d66e in gtk_widget_dispose (object=0x5566ed447d80) at ../gtk/gtk/gtkwidget.c:12166
#7 0x00007fcb566ba531 in g_object_run_dispose (object=0x5566ed447d80) at ../glib/gobject/gobject.c:1448
#8 0x00007fcb56d2d38a in gtk_widget_destroy (widget=<optimized out>) at ../gtk/gtk/gtkwidget.c:4780
#9 0x00007fcb52e92683 in xfce_tasklist_window_removed (screen=<optimized out>, window=0x5566ed48ba70, tasklist=0x5566ed6aabc0)
at /usr/src/debug/xfce4-panel/xfce4-panel-4.18.3/plugins/tasklist/tasklist-widget.c:1995
#10 0x00007fcb566aaca6 in g_cclosure_marshal_VOID__OBJECTv
(closure=0x5566ed6ac7b0, return_value=<optimized out>, instance=0x5566ed56c470, args=<optimized out>, marshal_data=<optimized out>, n_params=<optimized out>, param_types=0x5566ed54b1b0)
at ../glib/gobject/gmarshal.c:1910
#11 0x00007fcb566ca23c in _g_closure_invoke_va (param_types=0x5566ed54b1b0, n_params=<optimized out>, args=0x7fff54db8200, instance=0x5566ed56c470, return_value=0x0, closure=0x5566ed6ac7b0)
at ../glib/gobject/gclosure.c:895
#12 g_signal_emit_valist (instance=0x5566ed56c470, signal_id=244, detail=<optimized out>, var_args=var_args@entry=0x7fff54db8200) at ../glib/gobject/gsignal.c:3462
#13 0x00007fcb566ca324 in g_signal_emit (instance=<optimized out>, signal_id=signal_id@entry=244, detail=detail@entry=0) at ../glib/gobject/gsignal.c:3612
#14 0x00007fcb5739bb12 in emit_window_closed (window=0x5566ed48ba70, screen=0x5566ed56c470) at ../libwnck/libwnck/screen.c:2218
#15 update_client_list (screen=0x5566ed56c470) at ../libwnck/libwnck/screen.c:1561
#16 do_update_now (screen=0x5566ed56c470) at ../libwnck/libwnck/screen.c:2133
#17 0x00007fcb5739c888 in update_idle (data=<optimized out>) at ../libwnck/libwnck/screen.c:2156
#18 0x00007fcb565a753b in g_main_dispatch (context=0x5566ed401ea0) at ../glib/glib/gmain.c:3460
#19 g_main_context_dispatch (context=0x5566ed401ea0) at ../glib/glib/gmain.c:4200
#20 0x00007fcb56604219 in g_main_context_iterate.constprop.0 (context=0x5566ed401ea0, block=1, dispatch=1, self=<optimized out>) at ../glib/glib/gmain.c:4276
#21 0x00007fcb565a6c7f in g_main_loop_run (loop=0x5566ed50ddb0) at ../glib/glib/gmain.c:4479
#22 0x00007fcb56bd8e4f in gtk_main () at ../gtk/gtk/gtkmain.c:1329
#23 0x00005566ec4c33a5 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/xfce4-panel/xfce4-panel-4.18.3/panel/main.c:382The fifth one corresponds to the first trace above, and it also appears in the Xfce thread without debug symbols:
Core was generated by `xfce4-panel --display :0.0 --sm-client-id 2efa10307-33c5-47c5-95e9-4bdc880c5a6e'.
Program terminated with signal SIGSEGV, Segmentation fault.
warning: Section `.reg-xstate/108304' in core file too small.
#0 0x00007fda01cdd155 in wnck_window_set_icon_geometry (window=0x10, x=328, y=1050, width=200, height=30) at ../libwnck/libwnck/window.c:2430
2430 g_return_if_fail (WNCK_IS_WINDOW (window));
[Current thread is 1 (Thread 0x7fd9ffa3c600 (LWP 108304))]
(gdb) bt
#0 0x00007fda01cdd155 in wnck_window_set_icon_geometry (window=0x10, x=328, y=1050, width=200, height=30) at ../libwnck/libwnck/window.c:2430
#1 0x00007fd9fd7c9b56 in xfce_tasklist_update_icon_geometries (data=0x5596d44c3f80) at /usr/src/debug/xfce4-panel/xfce4-panel-4.18.3/plugins/tasklist/tasklist-widget.c:2109
#2 0x00007fda00eae53b in g_main_dispatch (context=0x5596d42e7dc0) at ../glib/glib/gmain.c:3460
#3 g_main_context_dispatch (context=0x5596d42e7dc0) at ../glib/glib/gmain.c:4200
#4 0x00007fda00f0b219 in g_main_context_iterate.constprop.0 (context=0x5596d42e7dc0, block=1, dispatch=1, self=<optimized out>) at ../glib/glib/gmain.c:4276
#5 0x00007fda00eadc7f in g_main_loop_run (loop=0x5596d43e4210) at ../glib/glib/gmain.c:4479
#6 0x00007fda015d8e4f in gtk_main () at ../gtk/gtk/gtkmain.c:1329
#7 0x00005596d22aa3a5 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/xfce4-panel/xfce4-panel-4.18.3/panel/main.c:382At least we now have complete backtraces in both cases, but that doesn't advance us much more unfortunately. There is in this second trace as in the first one a dangling pointer which should not be (window=0x10), and as for the first one I don't know what is the cause 
(and I still can't reproduce the problem)
Last edited by lambdarch (2023-04-15 14:53:33)
aka Tamaranch: https://gitlab.xfce.org/Tamaranch
Offline
#10 2023-04-15 15:16:12
- seth
- Member
- Registered: 2012-09-03
- Posts: 58,717
Re: Looking to diagnose xfce4-panel crash
https://gitlab.xfce.org/xfce/xfce4-pane … et.c#L1965
loops over tasklist->windows and frees some button widget, https://gitlab.xfce.org/xfce/xfce4-pane … et.c#L1995
That triggers a signal and invokes https://gitlab.xfce.org/xfce/xfce4-pane … et.c#L4381 which loops over group_child->windows in https://gitlab.xfce.org/xfce/xfce4-pane … et.c#L4396 and https://gitlab.xfce.org/xfce/xfce4-pane … et.c#L4429 and tests the exact same button widget which has just been free'd, https://gitlab.xfce.org/xfce/xfce4-pane … et.c#L4399 & https://gitlab.xfce.org/xfce/xfce4-pane … et.c#L4432
This worked because previous versions of glib2 did not immediately free the memory but current ones do and you got an access after free.
The address doesn't "change", 0x2b is bogus and effectively a nullptr.
There might even be a second entrace via xfce_tasklist_group_button_child_destroyed
You can possibly
GtkWidget *dead_widget = child->button;
child->button = nullptr;
gtk_widget_destroy(dead_widget); and then test the "child->button == nullptr" and shortcut xfce_tasklist_group_button_child_visible_changed.
Or you unlink the signal(s) before destroying the button.
Offline
#11 2023-04-15 15:47:10
- lambdarch
- Member
- Registered: 2021-01-10
- Posts: 79
Re: Looking to diagnose xfce4-panel crash
No, I don't think so. It's safe to do this on GtkWidget::destroy signal. Calling gtk_widget_destroy() does not free the widget. It calls g_object_run_dispose() https://gitlab.gnome.org/GNOME/gtk/-/bl … et.c#L4780, and it's typically when the object is disposed that we reset pointers, via g_object_weak_ref() (or gtk_widget_destroyed() for widgets).
Besides, if it came from there the problem would be easily reproducible.
Also there is no second entry via xfce_tasklist_group_button_child_destroyed(), it is this callback that is called.
Last edited by lambdarch (2023-04-15 15:52:19)
aka Tamaranch: https://gitlab.xfce.org/Tamaranch
Offline
#12 2023-04-15 16:06:46
- seth
- Member
- Registered: 2012-09-03
- Posts: 58,717
Re: Looking to diagnose xfce4-panel crash
It runs that, that triggers a signal that is linked to the visible_changed slot and that does without any doubt try to access a child->button object that has been deleted.
You may unref pointers afterwards (signal handling order) but too late.
Whether or not the child_destroyed signal gets fired and runs into the same problem, you don't know (from that backtrace) because the execution terminates before.
Reproducibility might be down to taskbutton grouping and utilization by the present windows.
If this is reproducible for anyone, they could log the pointer address of the parenting "child" objects to see whether the dangling button is the one whos destruction triggered the slot.
Offline
#13 2023-04-15 16:53:37
- lambdarch
- Member
- Registered: 2021-01-10
- Posts: 79
Re: Looking to diagnose xfce4-panel crash
It is the "destroy" signal that is emitted, not "notify::visible": https://gitlab.gnome.org/GNOME/gtk/-/bl … t.c#L12166
And the only callbak connected to this signal is xfce_tasklist_group_button_child_destroyed(). I don't know why this call is missing in the trace, but I think that the call to xfce_tasklist_group_button_child_visible_changed() takes place via xfce_tasklist_group_button_child_destroyed() (because the test `child->button == child_button` fails above).
Also:
#3 0x00007fcb566da2f8 in signal_emit_unlocked_R.isra.0
(node=node@entry=0x5566ed507270, detail=detail@entry=0, instance=instance@entry=0x5566ed447d80, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fff54db7d30)
at ../glib/gobject/gsignal.c:3802It could not be `detail=detail@entry=0` if it was the "notify::visible" signal that was emitted.
I could be wrong of course, but I think that child->button has not been deleted as you say. I think it's a more twisted memory corruption than that.
Last edited by lambdarch (2023-04-15 17:07:29)
aka Tamaranch: https://gitlab.xfce.org/Tamaranch
Offline
#14 2023-04-15 21:26:12
- seth
- Member
- Registered: 2012-09-03
- Posts: 58,717
Re: Looking to diagnose xfce4-panel crash
I don't know why this call is missing in the trace, but I think that the call to xfce_tasklist_group_button_child_visible_changed() takes place via xfce_tasklist_group_button_child_destroyed() (because the test `child->button == child_button` fails above).
There might even be a second entrace via xfce_tasklist_group_button_child_destroyed
https://gitlab.xfce.org/xfce/xfce4-pane … et.c#L4474
Though I'd also expect that function to sho up in the backtrace, but maybe gtk inlines it (I've little experience w/ the toolkit and no in-depth knowledge)
The object pointer is invalid - this is not dangling or random memory, the object has been deleted.
https://gitlab.xfce.org/xfce/xfce4-pane … et.c#L4467 looks like it could be a problem.
You're currently iterating that list and depending on how g_slist_delete_link operates, the return value (!) might be a copy of thre previous list, but I don't see how this would consistenly lead to bad pointers in xfce_tasklist_group_button_child_visible_changed (you'd rather see lnext and the next child fall bad)
Every other crash due to the glib2 update has been due to list alterations during the traversal.
The other crash has an intact button, but a bogus window - i don't think this is related.
https://docs.gtk.org/gtk3/method.Widget.destroy.html
It’s important to notice that gtk_widget_destroy() will only cause the widget to be finalized if no additional references, acquired using g_object_ref(), are held on it. In case additional references are in place, the widget will be in an “inert” state after calling this function; widget will still point to valid memory, allowing you to release the references you hold, but you may not query the widget’s own state.
Offline
#15 2023-04-16 11:22:47
- lambdarch
- Member
- Registered: 2021-01-10
- Posts: 79
Re: Looking to diagnose xfce4-panel crash
https://gitlab.xfce.org/xfce/xfce4-pane … et.c#L4467 looks like it could be a problem.
You're currently iterating that list and depending on how g_slist_delete_link operates, the return value (!) might be a copy of thre previous list, but I don't see how this would consistenly lead to bad pointers in xfce_tasklist_group_button_child_visible_changed (you'd rather see lnext and the next child fall bad)
This is the way recommended in the doc (introductory section), and it is used in many other places in Xfce and elsewhere, so I don't think that's where the problem comes from.
The other crash has an intact button, but a bogus window - i don't think this is related.
It is also reported in the Xfce forum thread though: https://forum.xfce.org/viewtopic.php?pid=71574#p71574
Last edited by lambdarch (2023-04-16 11:24:33)
aka Tamaranch: https://gitlab.xfce.org/Tamaranch
Offline
#16 2023-04-16 13:10:24
- seth
- Member
- Registered: 2012-09-03
- Posts: 58,717
Re: Looking to diagnose xfce4-panel crash
I'd debug this by inserting a lot of printf's to track whether xfce_tasklist_group_button_child_visible_changed is invoked directly or via xfce_tasklist_group_button_child_destroyed, as well as the "child" for the (fatally) tested child->button (and whether it's the same as the one that just got its button destroyed)
The overall crash pattern is too consistent for this to be some random stack corruption.
Offline
#17 2023-04-16 16:17:00
- lambdarch
- Member
- Registered: 2021-01-10
- Posts: 79
Re: Looking to diagnose xfce4-panel crash
Finally solved thanks to Valgrind: https://gitlab.xfce.org/xfce/xfce4-pane … note_69718
I should have thought about it earlier, and the irony is that just before I launched Valgrind I was able to reproduce the bug for the first time!
So it wasn't child->button that was freed, but child.
And also the other backtrace came from there too: it was not child->window that was freed, but child.
Thanks to all for your help 
Last edited by lambdarch (2023-04-16 16:18:18)
aka Tamaranch: https://gitlab.xfce.org/Tamaranch
Offline