hidetopbar
hidetopbar copied to clipboard
tuxor1337
Gnome shell crashes on log-out/reboot/shutdown
Hello,
Can you please verify that hidetopbar does not cause the crashes related to bug https://bugzilla.redhat.com/show_bug.cgi?id=2017067 ? At this moment hidetopbar is disabled due waiting for an update and the crashes for bug https://bugzilla.redhat.com/show_bug.cgi?id=2017067 do not appear...
Kind regards, Udo
The bug you are trying to refer to has been restricted for internal development. So I can't access it. Please explain your bug in detail here or close this issue.
I can simply view it. You only need a bugzilla account. No special rights. Gnome-shell crashes often, when 'idle'.
(gdb) bt
#0 0x00007eff2b7dca39 in st_theme_node_lookup_shadow
(node=node@entry=0x557dee42f220,
property_name=property_name@entry=0x7eff2b809e5e "box-shadow",
inherit=inherit@entry=0, shadow=shadow@entry=0x7ffcb5ee2ca0) at
../src/st/st-theme-node.c:3502
#1 0x00007eff2b7dcdb8 in st_theme_node_get_box_shadow (node=0x557dee42f220) at
../src/st/st-theme-node.c:3596
#2 st_theme_node_get_box_shadow (node=node@entry=0x557dee42f220) at
../src/st/st-theme-node.c:3586
#3 0x00007eff2b7dd562 in st_theme_node_get_paint_box (node=0x557dee42f220,
actor_box=actor_box@entry=0x7ffcb5ee2d80,
paint_box=paint_box@entry=0x7ffcb5ee2d20) at ../src/st/st-theme-node.c:4069
#4 0x00007eff2b7dd6f4 in st_theme_node_transition_get_paint_box
(transition=<optimized out>, allocation=0x7ffcb5ee2d80,
paint_box=0x7ffcb5ee2d70) at ../src/st/st-theme-node-transition.c:231
#5 0x00007eff2b7e8bf3 in st_widget_get_paint_volume (volume=0x557deb53c848,
self=0x557deb53c9a0) at ../src/st/st-widget.c:781
#6 st_widget_get_paint_volume (self=0x557deb53c9a0, volume=0x557deb53c848) at
../src/st/st-widget.c:763
#7 0x00007eff2bcf57e0 in _clutter_actor_get_paint_volume_real
(pv=0x557deb53c848, self=0x557deb53c9a0) at
../clutter/clutter/clutter-actor.c:15390
#8 _clutter_actor_get_paint_volume_mutable (self=0x557deb53c9a0) at
../clutter/clutter/clutter-actor.c:15512
#9 0x00007eff2bd40292 in clutter_actor_get_redraw_clip
(dst_new_pv=0x7ffcb5ee2ea0, dst_old_pv=0x7ffcb5ee2f10, self=0x557deb53c9a0) at
../clutter/clutter/clutter-actor.c:19594
#10 clutter_stage_maybe_finish_queue_redraws (stage=0x557deacf2760) at
../clutter/clutter/clutter-stage.c:2866
#11 0x00007eff2bd41e62 in handle_frame_clock_frame (frame_clock=0x557deb07a270,
frame_count=<optimized out>, time_us=<optimized out>, user_data=0x557dee2fa690)
at ../clutter/clutter/clutter-stage-view.c:1176
#12 0x00007eff2bd143da in clutter_frame_clock_dispatch (time_us=18003007056,
frame_clock=0x557deb07a270) at ../clutter/clutter/clutter-frame-clock.c:653
#13 frame_clock_source_dispatch (source=<optimized out>, callback=<optimized
out>, user_data=<optimized out>) at
../clutter/clutter/clutter-frame-clock.c:693
#14 0x00007eff2c7a205f in g_main_dispatch (context=0x557dead07b10) at
../glib/gmain.c:3381
#15 g_main_context_dispatch (context=0x557dead07b10) at ../glib/gmain.c:4099
#16 0x00007eff2c7f7298 in g_main_context_iterate.constprop.0
(context=0x557dead07b10, block=746565745, block@entry=1,
dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4138
#17 0x00007eff2c7a1773 in g_main_loop_run (loop=0x557ded2f7c70) at
../glib/gmain.c:4373
#18 0x00007eff2bb2e0f9 in meta_context_run_main_loop (context=<optimized out>,
error=0x7ffcb5ee32e0) at ../src/core/meta-context.c:433
#19 0x0000557dea049dd3 in main (argc=<optimized out>, argv=<optimized out>) at
../src/main.c:563
If that bug is special then try https://bugzilla.redhat.com/show_bug.cgi?id=1964004 which is my own bug about this issue and more.
Thanks for the link to the other bug!
I'm not convinced that this is related to Hide Top Bar though, as long as there are no clear instructions on how to reproduce.
As the bug explains: it happens (also) when gnome-shell is idle, i.e. when I am away from the keyboard. Simply let it sit.
OTOH HideTopBar does not work as advertised here. It does not disappear the top bar when I explicitly maximise firefox.
Those are not clear instructions on how to reproduce. I have been using Hide Top Bar on Fedora 34, and Firefox, on a daily basis, for years and still do so today, and can't confirm any of what you or the bug report say. So, crucial details about the setup that produces the issue must be missing.
If you think what you described then I thank you for your time. It is just that what I know about this gnome-shell crashing issue. Other users report other extensions being a factor none of which I use. The correlation I found lead me to this issue. We'll see how 'soon' the bug is fixed and then we can observe more.
Also: it is not about reproducing the bug but reviewing the code snippet in the backtrace and seeing if HideTopBar might cause issues there.
Setup: AMD 5700G on Gigabyte Aorus Pro with Fedora 25. Latest BIOS, updates, etc.
reviewing the code snippet in the backtrace and seeing if HideTopBar might cause issues there.
From the backtrace, I can't tell for sure. But it looks as if, even if Hide Top Bar is somehow involved in this, this can most probably be fixed upstream, not on our side. Without being able to reproduce it, this is pure speculation.
$ gnome-extensions list [email protected] just-perfection-desktop@just-perfection [email protected] [email protected] [email protected]
I disabled each extension, one by one. Normally gnome shell crashes multiple times per day:
$ ls -lth core* -rw------- 1 udo udo 788M 22 feb 14:04 core.400700 -rw------- 1 udo udo 797M 22 feb 08:50 core.253227 -rw------- 1 udo udo 804M 21 feb 23:31 core.238971 -rw------- 1 udo udo 799M 21 feb 20:07 core.220726 -rw------- 1 udo udo 797M 21 feb 11:23 core.206074 -rw------- 1 udo udo 991M 21 feb 08:31 core.61076 -rw------- 1 udo udo 800M 20 feb 19:12 core.3804 -rw------- 1 udo udo 686M 19 feb 21:27 core.1602852 -rw------- 1 udo udo 840M 19 feb 16:12 core.1589032 -rw------- 1 udo udo 757M 19 feb 11:35 core.1575289 -rw------- 1 udo udo 796M 18 feb 23:37 core.1433564 -rw------- 1 udo udo 812M 18 feb 17:34 core.1415279 -rw------- 1 udo udo 1,1G 18 feb 13:31 core.1380919 -rw------- 1 udo udo 816M 18 feb 09:18 core.1367440 -rw------- 1 udo udo 803M 18 feb 01:33 core.1225890 -rw------- 1 udo udo 805M 17 feb 20:48 core.1197709 -rw------- 1 udo udo 790M 17 feb 07:29 core.1182268 -rw------- 1 udo udo 819M 16 feb 19:00 core.933273 -rw------- 1 udo udo 1,1G 16 feb 13:32 core.915832 -rw------- 1 udo udo 1,1G 16 feb 05:59 core.773914 -rw------- 1 udo udo 1,1G 15 feb 21:00 core.755405
But now we ran for 24 hours without a coredump. So it appears that hidetopbar is triggering https://bugzilla.redhat.com/show_bug.cgi?id=1964004 / https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4851 / https://bugzilla.redhat.com/show_bug.cgi?id=2007817 None of the other extensions do this, as far as this short investigation can see. Nothing upstream as there is no protection in gnome-shell against this happening. It is like the multitasking in Windows for Workgroups 3.11. So please check again.
I don't know how it happened that I got a notification of this replay, but it got me interested. I went through the 1964004 bug and found no evidence of connection to any extension. Furthermore in one of your replays, you mention that you don't even need to log in or out, which means no extensions have been loaded, which excludes the possibility of connection to any extension. In the gnome issue, the developer says it should not be possible for an extension to break the session, so it should be a problem in gnome-shell. The piece of code you dug up seems to be C code, not JS. I was not able to reproduce the gnome issue either. Maybe because I run Gentoo and don't count on pre-compiled binaries, which I believe is the root of the issue. If you think hidetopbar is the culprit, there are other extensions that (claim to) do the same thing. Switch to one of them or disable it while you convince yourself it's not something else. Running 24 hour without a core dump can only prove there's no core dump, but can not reveal reason there isn't. There can be plenty of reasons. For example any other changes you made. At least enable it again and see if it the issue reproduces immediately.
Regards, Georgi
"the developer says it should not be possible for an extension to break the session" Where is that? He says 'This way' so not an absolute no crash. Still you trigger it thus that is of interest to the developer if that is not to be expected. "The piece of code you dug up seems to be C code, not JS." What would you expect from gdb? I could have gdb decode the other threads if that is helpful to you. Precompiled binaries? How would those cause this? "can not reveal reason there isn't." We disabled hide top bar. That is the only change. We can test a bit more...
In the very issue on gnome.org you linked above. Read the comments. In my opinion, an extension causing this is pure speculation and is not backed up by any evidence. Actually when I think about it again, any gdb output alone is not capable of proving such a connection. Someone must recognize that piece of code and also must know what it is doing and that should be related to running extensions. That is so because extensions are written in JS. Pre-built binaries can be incompatible. It's not uncommon or unseen with binary distributions. In anyway, this is the wrong place to look. Even if an extension is causing such an issue, it should be fixed upstream first.
Yes, you may want to get rid of this bug, but as I explained especially this bug is useful as it documents another trigger and the developer can help fix gnome-shell. JS is just that, another language.
@udovdh maybe, if the snippet is the relevant one, it it's more likely it will be recognized if you post it in the gnome bug, rather than here. Additional knowledge is required to link the two things, which apparently cannot be found here. That's what I'm trying to say.