bug#24445: GNOME desktop session crash when re-arranging dock
bug#24445: GNOME desktop session crash when re-arranging dock
From: l...@gnu.org (Ludovic Courtès) Subject: Re: bug#24445: GNOME desktop session crash when re-arranging dock Date: Mon, 09 Oct 2017 11:51:14 +0200 > So I guess we have to go with /etc/profile as in your patch. > Can you push the patch (with a comment linking to this issue)? Alright, I'll finish this up with some comments as discussed. Thanks everybody! Thomas
bug#24445: GNOME desktop session crash when re-arranging dock
Hey Thomas, Thomas Danckaert skribis: > From: l...@gnu.org (Ludovic Courtès) > Subject: Re: bug#24445: GNOME desktop session crash when re-arranging > dock > Date: Sun, 08 Oct 2017 21:18:28 +0200 > >> I think we should set XCURSOR_PATH via >> ‘session-environment-service-type’ like in the patch I posted. I >> find >> it marginally nicer than setting it in /etc/profile because that way >> it >> remains close to ‘gnome-service-type’; we need to do the same in >> ‘xfce-service-type’ though. WDYT? > > Sure, I agree. My choice of /etc/profile was not really motivated: I > just looked for the first place I could set an environment variable, > and used that, thinking there would be someone to tell me if this was > a good place to put it, or not. Silly me: we cannot have $HOME/.guix-profile/share/icons and $HOME/.icons in ‘XCURSOR_PATH’ if we do it via ‘session-environment-service-type’. So I guess we have to go with /etc/profile as in your patch. Can you push the patch (with a comment linking to this issue)? >> Then, eventually, we can add XCURSOR_PATH as a search path >> definition of >> ‘libxcursor’, but due to bug 20255, it won’t be effective here; so >> that’ll be a mostly cosmetic change. > > Adding it as a “cosmetic change” is perhaps useful as a reminder that > we can improve this in the future. Also (bug 22138), I believe search > paths of dependencies are not propagated, so users would also have to > explicitly install libXcursor itself in a profile to have this take > effect? No strong opinion here :) Right. In the patch, I think you can add the extra ‘search-paths’ entry, comment it out, and add a TODO comment. > One less bug for the 0.14 release (come and switch back already, > Mohammed... :-) ) Definitely. :-) Ludo’.
bug#24445: GNOME desktop session crash when re-arranging dock
Hi, From: l...@gnu.org (Ludovic Courtès) Subject: Re: bug#24445: GNOME desktop session crash when re-arranging dock Date: Sun, 08 Oct 2017 21:18:28 +0200 I think we should set XCURSOR_PATH via ‘session-environment-service-type’ like in the patch I posted. I find it marginally nicer than setting it in /etc/profile because that way it remains close to ‘gnome-service-type’; we need to do the same in ‘xfce-service-type’ though. WDYT? Sure, I agree. My choice of /etc/profile was not really motivated: I just looked for the first place I could set an environment variable, and used that, thinking there would be someone to tell me if this was a good place to put it, or not. Then, eventually, we can add XCURSOR_PATH as a search path definition of ‘libxcursor’, but due to bug 20255, it won’t be effective here; so that’ll be a mostly cosmetic change. Adding it as a “cosmetic change” is perhaps useful as a reminder that we can improve this in the future. Also (bug 22138), I believe search paths of dependencies are not propagated, so users would also have to explicitly install libXcursor itself in a profile to have this take effect? No strong opinion here :) One less bug for the 0.14 release (come and switch back already, Mohammed... :-) ) Thomas
bug#24445: GNOME desktop session crash when re-arranging dock
Howdy! Thomas Danckaert skribis: > Ha, I was just going to reply the same (see attached patch). I've > tested it on my system as well, and it works. > > Indeed encoding the absolute file name of the icon theme seems hard, > unless we set the icon theme inside the system configuration? Not sure > how we want to handle icon themes installed in user profiles. Yeah, let’s just keep /run/current-system & co. > In my patch, I included both system and user profile, in case users want > to install icon themes in their profile, as well as the default ~/.icons > (which seems to be a kind of standard as well, so thought we could keep > it by default). Yes, it’s a good idea to include ~/.icons and ~/.guix-profile/share/icons (I thought that XCURSOR_PATH did not take override the default, which includes ~/.icons.) > Also, I'm not sure if we need to set both paths in /etc/profile, or if > we can just have icon theme packages prepend to the current XCURSOR_PATH > when installed into a user profile (I'm not familiar with the details of > http://bugs.gnu.org/20255)? I think we should set XCURSOR_PATH via ‘session-environment-service-type’ like in the patch I posted. I find it marginally nicer than setting it in /etc/profile because that way it remains close to ‘gnome-service-type’; we need to do the same in ‘xfce-service-type’ though. WDYT? Then, eventually, we can add XCURSOR_PATH as a search path definition of ‘libxcursor’, but due to bug 20255, it won’t be effective here; so that’ll be a mostly cosmetic change. Does that make sense? Anyway, glad we have a fix. :-) Ludo’.
bug#24445: GNOME desktop session crash when re-arranging dock
l...@gnu.org (Ludovic Courtès) writes: > I think that’d be OK. > > Though libXcursor contains a few ‘getenv’ calls, notably for > XCURSOR_PATH, which looks like it’s what we’re looking for. > > I tested the attached path in a VM and it seems to fix the bug: I can > drag a window in the overview area on the right and it no longer crashes > (*and* I get a hand-shaped cursor when hovering that area :-)). And we > don’t need to modify libXcursor. > > (We could do slightly better by using the absolute file name of the > actual icon theme instead of /run/current-system, but it’s complicated > because I guess it doesn’t have to be Adwaita.) > > Thoughts? Ha, I was just going to reply the same (see attached patch). I've tested it on my system as well, and it works. Indeed encoding the absolute file name of the icon theme seems hard, unless we set the icon theme inside the system configuration? Not sure how we want to handle icon themes installed in user profiles. In my patch, I included both system and user profile, in case users want to install icon themes in their profile, as well as the default ~/.icons (which seems to be a kind of standard as well, so thought we could keep it by default). Also, I'm not sure if we need to set both paths in /etc/profile, or if we can just have icon theme packages prepend to the current XCURSOR_PATH when installed into a user profile (I'm not familiar with the details of http://bugs.gnu.org/20255)? cheers! Thomas >From e6328f95f3c7dbec3f124f15a3cd50f95e4431d2 Mon Sep 17 00:00:00 2001 From: Thomas Danckaert Date: Sun, 8 Oct 2017 17:21:09 +0200 Subject: [PATCH] system: operating-system-etc-service: Set XCURSOR_PATH. * gnu/system.scm (operating-system-etc-service): Set XCURSOR_PATH environment variable so that libxcursor finds cursors in user and system profiles. --- gnu/system.scm | 1 + 1 file changed, 1 insertion(+) diff --git a/gnu/system.scm b/gnu/system.scm index 8ab4801b7..6e9aa0635 100644 --- a/gnu/system.scm +++ b/gnu/system.scm @@ -579,6 +579,7 @@ export MANPATH=$HOME/.guix-profile/share/man:/run/current-system/profile/share/m export INFOPATH=$HOME/.guix-profile/share/info:/run/current-system/profile/share/info export XDG_DATA_DIRS=$HOME/.guix-profile/share:/run/current-system/profile/share export XDG_CONFIG_DIRS=$HOME/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg +export XCURSOR_PATH=$HOME/.icons:$HOME/.guix-profile/share/icons:/run/current-system/profile/share/icons # Ignore the default value of 'PATH'. unset PATH -- 2.14.2
bug#24445: GNOME desktop session crash when re-arranging dock
Hello!
Thomas Danckaert skribis:
> libxcursor's configure script has an option "--with-cursorpath="
> to set a default search path for cursors. If no option is given (as is
> the case with our package), the default is
> DEF_CURSORPATH="~/.icons:${datadir}/icons:${datadir}/pixmaps", which is
> exactly the set of directories in the strace (${HOME}/.icons and
> ${INSTALLPREFIX}/share/icons).
>
> So I guess that adding relevant directories to the libxcursor search
> path would solve the problem. For Guix, it'd be useful to add
> /run/current-system/profile/share/icons, as well as
> ~/.guix-profile/share/icons (for users installing other icon themes in
> their profile). Would this be ok?
I think that’d be OK.
Though libXcursor contains a few ‘getenv’ calls, notably for
XCURSOR_PATH, which looks like it’s what we’re looking for.
I tested the attached path in a VM and it seems to fix the bug: I can
drag a window in the overview area on the right and it no longer crashes
(*and* I get a hand-shaped cursor when hovering that area :-)). And we
don’t need to modify libXcursor.
(We could do slightly better by using the absolute file name of the
actual icon theme instead of /run/current-system, but it’s complicated
because I guess it doesn’t have to be Adwaita.)
Thoughts?
Ludo’.
diff --git a/gnu/services/desktop.scm b/gnu/services/desktop.scm
index 527a3101c..4633f0fc6 100644
--- a/gnu/services/desktop.scm
+++ b/gnu/services/desktop.scm
@@ -791,7 +791,11 @@ accountsservice web site} for more information."
gnome-package))
(service-extension profile-service-type
(compose list
- gnome-package))
+ gnome-package))
+ (service-extension session-environment-service-type
+ (const
+ '(("XCURSOR_PATH"
+ . "/run/current-system/profile/share/icons"
(define* (gnome-desktop-service #:key (config (gnome-desktop-configuration)))
"Return a service that adds the @code{gnome} package to the system profile,
bug#24445: GNOME desktop session crash when re-arranging dock
Mark H Weaver writes:
> I can confirm that the problem does not occur on Debian, and I've not
> found reports of it happening on any other mainstream distro. I would
> guess that our unusual filesystem layout prevents GNOME Shell from
> finding something that it's looking for, and that the error handling in
> that case is deficient or non-existent.
Hi,
I think I understand what's going on, and I may even have a solution ;-)
What's happening is that gnome-shell wants certain cursors, but can't
find them. These cursors are provided by Adwaita icon theme, but
gnome-shell somehow isn't looking in Adwaita's location (unless you
symlink adwaita's icons into ${HOME}/.icons as I mentioned before).
I've attached an strace from gnome-shell, the relevant part is here:
open("/home/thomas/.icons/Adwaita/cursors/dnd-none", O_RDONLY) = -1 ENOENT (No
such file or directory)
open("/home/thomas/.icons/Adwaita/index.theme", O_RDONLY) = -1 ENOENT (No such
file or directory)
open("/gnu/store/14f4vh3y3wdf3rfpzkpqfqbl9i81hyw8-libxcursor-1.1.14/share/icons/Adwaita/cursors/dnd-none",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/gnu/store/14f4vh3y3wdf3rfpzkpqfqbl9i81hyw8-libxcursor-1.1.14/share/icons/Adwaita/index.theme",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/gnu/store/14f4vh3y3wdf3rfpzkpqfqbl9i81hyw8-libxcursor-1.1.14/share/pixmaps/Adwaita/cursors/dnd-none",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/gnu/store/14f4vh3y3wdf3rfpzkpqfqbl9i81hyw8-libxcursor-1.1.14/share/pixmaps/Adwaita/index.theme",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/thomas/.icons/default/cursors/dnd-none", O_RDONLY) = -1
ENOENT (No such file or directory)
[...]
--- SIGTRAP {si_signo=SIGTRAP, si_code=SI_KERNEL} ---
+++ killed by SIGTRAP +++
I've been looking through the sources, and
gtk+-3.22.15/gdk/x11/gdkcursor-x11.c makes me think that cursor lookup
in our case is ultimately done by libxcursor.
libxcursor's configure script has an option "--with-cursorpath="
to set a default search path for cursors. If no option is given (as is
the case with our package), the default is
DEF_CURSORPATH="~/.icons:${datadir}/icons:${datadir}/pixmaps", which is
exactly the set of directories in the strace (${HOME}/.icons and
${INSTALLPREFIX}/share/icons).
So I guess that adding relevant directories to the libxcursor search
path would solve the problem. For Guix, it'd be useful to add
/run/current-system/profile/share/icons, as well as
~/.guix-profile/share/icons (for users installing other icon themes in
their profile). Would this be ok?
I'll go and test this, but building everything from libxcursor up to
gnome-desktop
will probably take a while :).
Comments are welcome!
Thomas
gnomeshell.log
Description: strace from gnome-shell
bug#24445: GNOME desktop session crash when re-arranging dock
l...@gnu.org (Ludovic Courtès) writes: > Mohammed Sadiq skribis: > >> This crash appears to happen on dragging anything on gnome-shell. >> >> Eg: >> 1. If a window is dragged in shell overview >> 2. if a window in desktop list (in the right side) is dragged. >> 3. if some icon from Application list is dragged. >> >> Also, the immediately followed drag after the first failure results in a >> total >> crash losing all the open window and goes back to slim login. > > A serious problem. > >> So the bug severity may be increased if this is reproducible to some >> one. The same bug has been present in GNOME on GuixSD since the beginning of our GNOME support. I can confirm that it's 100% reproducible on my GuixSD system, and as I recall it's been confirmed by David Thompson and Andy Wingo at least. > Mohammed, do you think this could be Guix-specific? Intuitively I would > guess that this can only be an upstream bug, but you know GNOME better > than I do. :-) I can confirm that the problem does not occur on Debian, and I've not found reports of it happening on any other mainstream distro. I would guess that our unusual filesystem layout prevents GNOME Shell from finding something that it's looking for, and that the error handling in that case is deficient or non-existent. In case anyone missed it, Thomas Danckaert recently made a significant contribution to discovering the cause of this bug, and provided a workaround: https://bugs.gnu.org/24445#8 Given this, I suspect that it would not take long for a motivated developer to complete the investigation and fix this bug properly. Mark
bug#24445: GNOME desktop session crash when re-arranging dock
> On October 2, 2017 at 8:21 PM Ludovic Courtès wrote: > Mohammed, do you think this could be Guix-specific? Intuitively I would > guess that this can only be an upstream bug, but you know GNOME better > than I do. :-) But I don't know gnome-shell any better than you. :) This doesn't happen in Debian (GNOME shell version 3.22.x). And I haven't seen any body complaining about it (Though I have seen bug reports that gnome-shell when using mozjs52 crashes). >From the logs (dmesg) it seems like an issue with upstream code, but I believe it is because of the isolation guix enforces. Anyway I have moved back to Debian (at least until 0.14/0.15 guix release). So I may not be able to test the changes anymore. Thanks
bug#24445: GNOME desktop session crash when re-arranging dock
Mohammed Sadiq skribis: > This crash appears to happen on dragging anything on gnome-shell. > > Eg: > 1. If a window is dragged in shell overview > 2. if a window in desktop list (in the right side) is dragged. > 3. if some icon from Application list is dragged. > > Also, the immediately followed drag after the first failure results in a total > crash losing all the open window and goes back to slim login. A serious problem. > So the bug severity may be increased if this is reproducible to some one. Mohammed, do you think this could be Guix-specific? Intuitively I would guess that this can only be an upstream bug, but you know GNOME better than I do. :-) Thanks, Ludo’.
bug#24445: GNOME desktop session crash when re-arranging dock
Excuse the very late reply...
The cause of this bug is that GNOME can't find all the cursor icons
it needs. A workaround is to force use of the Adwaita cursor theme,
by creating the following symlink in your home directory:
${HOME}/.icons/default/cursors ->
/run/current-system/profile/share/icons/Adwaita/cursors/
This should solve the problem for you.
To close this bug, Guix should automatically take care of this cursor
business, but I don't know enough about desktop standards etc to fix
this myself at the moment.
Sincerely,
Thomas
bug#24445: GNOME desktop session crash when re-arranging dock
guix sd 0.11 guix pull on 15/9/2016 GNOME 3.20 Add launch programs to GNOME dash/dock. Now, try dragging and dropping to change the order of the launchers and observe the desktop crashes and recovers back but icons cannot be re-arranged. able to repro consistently
