unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
* bug#24445: GNOME desktop session crash when re-arranging dock
@ 2016-09-15 13:45 Ravishankar S
  2017-09-27  7:48 ` Thomas Danckaert
  2017-09-30  5:51 ` bug#24445: [No Subject] Mohammed Sadiq
  0 siblings, 2 replies; 14+ messages in thread
From: Ravishankar S @ 2016-09-15 13:45 UTC (permalink / raw)
  To: 24445

[-- Attachment #1: Type: text/plain, Size: 266 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 332 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#24445: GNOME desktop session crash when re-arranging dock
  2016-09-15 13:45 bug#24445: GNOME desktop session crash when re-arranging dock Ravishankar S
@ 2017-09-27  7:48 ` Thomas Danckaert
  2017-09-30  5:51 ` bug#24445: [No Subject] Mohammed Sadiq
  1 sibling, 0 replies; 14+ messages in thread
From: Thomas Danckaert @ 2017-09-27  7:48 UTC (permalink / raw)
  To: Ravishankar S; +Cc: 24445

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#24445: [No Subject]
  2016-09-15 13:45 bug#24445: GNOME desktop session crash when re-arranging dock Ravishankar S
  2017-09-27  7:48 ` Thomas Danckaert
@ 2017-09-30  5:51 ` Mohammed Sadiq
  2017-10-02 14:51   ` bug#24445: GNOME desktop session crash when re-arranging dock Ludovic Courtès
  1 sibling, 1 reply; 14+ messages in thread
From: Mohammed Sadiq @ 2017-09-30  5:51 UTC (permalink / raw)
  To: 24445

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.

So the bug severity may be increased if this is reproducible to some one.

Thanks

^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#24445: GNOME desktop session crash when re-arranging dock
  2017-09-30  5:51 ` bug#24445: [No Subject] Mohammed Sadiq
@ 2017-10-02 14:51   ` Ludovic Courtès
  2017-10-02 18:01     ` Mohammed Sadiq
  2017-10-02 18:34     ` Mark H Weaver
  0 siblings, 2 replies; 14+ messages in thread
From: Ludovic Courtès @ 2017-10-02 14:51 UTC (permalink / raw)
  To: Mohammed Sadiq; +Cc: 24445

Mohammed Sadiq <sadiq@sadiqpk.org> 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’.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#24445: GNOME desktop session crash when re-arranging dock
  2017-10-02 14:51   ` bug#24445: GNOME desktop session crash when re-arranging dock Ludovic Courtès
@ 2017-10-02 18:01     ` Mohammed Sadiq
  2017-10-02 18:34     ` Mark H Weaver
  1 sibling, 0 replies; 14+ messages in thread
From: Mohammed Sadiq @ 2017-10-02 18:01 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: 24445


> On October 2, 2017 at 8:21 PM Ludovic Courtès <ludo@gnu.org> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#24445: GNOME desktop session crash when re-arranging dock
  2017-10-02 14:51   ` bug#24445: GNOME desktop session crash when re-arranging dock Ludovic Courtès
  2017-10-02 18:01     ` Mohammed Sadiq
@ 2017-10-02 18:34     ` Mark H Weaver
  2017-10-08 13:50       ` Thomas Danckaert
  1 sibling, 1 reply; 14+ messages in thread
From: Mark H Weaver @ 2017-10-02 18:34 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Mohammed Sadiq, 24445

ludo@gnu.org (Ludovic Courtès) writes:

> Mohammed Sadiq <sadiq@sadiqpk.org> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#24445: GNOME desktop session crash when re-arranging dock
  2017-10-02 18:34     ` Mark H Weaver
@ 2017-10-08 13:50       ` Thomas Danckaert
  2017-10-08 15:08         ` Ludovic Courtès
  0 siblings, 1 reply; 14+ messages in thread
From: Thomas Danckaert @ 2017-10-08 13:50 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: 24445, Mohammed Sadiq

[-- Attachment #1: Type: text/plain, Size: 2759 bytes --]

Mark H Weaver <mhw@netris.org> 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=<paths>"
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


[-- Attachment #2: strace from gnome-shell --]
[-- Type: application/octet-stream, Size: 9926 bytes --]

futex(0x7fce88461468, FUTEX_WAKE_PRIVATE, 2147483647) = 0
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)
open("/home/thomas/.icons/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/gnu/store/14f4vh3y3wdf3rfpzkpqfqbl9i81hyw8-libxcursor-1.1.14/share/icons/default/cursors/dnd-none", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/gnu/store/14f4vh3y3wdf3rfpzkpqfqbl9i81hyw8-libxcursor-1.1.14/share/icons/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/gnu/store/14f4vh3y3wdf3rfpzkpqfqbl9i81hyw8-libxcursor-1.1.14/share/pixmaps/default/cursors/dnd-none", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/gnu/store/14f4vh3y3wdf3rfpzkpqfqbl9i81hyw8-libxcursor-1.1.14/share/pixmaps/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
poll([{fd=5, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=5, revents=POLLOUT}])
writev(5, [{iov_base="\2\0\4\0\20\0\240\0\0@\0\0\0\0\0\0", iov_len=16}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 16
recvmsg(5, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
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)
open("/home/thomas/.icons/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/gnu/store/14f4vh3y3wdf3rfpzkpqfqbl9i81hyw8-libxcursor-1.1.14/share/icons/default/cursors/dnd-none", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/gnu/store/14f4vh3y3wdf3rfpzkpqfqbl9i81hyw8-libxcursor-1.1.14/share/icons/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/gnu/store/14f4vh3y3wdf3rfpzkpqfqbl9i81hyw8-libxcursor-1.1.14/share/pixmaps/default/cursors/dnd-none", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/gnu/store/14f4vh3y3wdf3rfpzkpqfqbl9i81hyw8-libxcursor-1.1.14/share/pixmaps/default/index.theme", O_RDONLY) = -1 ENOENT (No such file or directory)
poll([{fd=12, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=12, revents=POLLOUT}])
writev(12, [{iov_base="\2\31\4\0\4\1\0\0\0@\0\0\0\0\0\0", iov_len=16}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 16
recvmsg(12, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
ioctl(6, DRM_IOCTL_I915_GEM_BUSY, 0x7fff1ce5c030) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fff1ce5bfa0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_BUSY, 0x7fff1ce5c090) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fff1ce5c000) = 0
ioctl(6, DRM_IOCTL_I915_GEM_CREATE, 0x7fff1ce5a600) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SET_TILING, 0x7fff1ce5a590) = 0
ioctl(6, DRM_IOCTL_I915_GEM_CREATE, 0x7fff1ce5a600) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SET_TILING, 0x7fff1ce5a590) = 0
ioctl(6, DRM_IOCTL_I915_GEM_CREATE, 0x7fff1ce5a610) = 0
ioctl(6, DRM_IOCTL_I915_GEM_CREATE, 0x7fff1ce5a750) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SET_TILING, 0x7fff1ce5a6e0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_CREATE, 0x7fff1ce5a6f0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SET_TILING, 0x7fff1ce5a680) = 0
ioctl(6, DRM_IOCTL_I915_GEM_CREATE, 0x7fff1ce5a610) = 0
ioctl(6, DRM_IOCTL_I915_GEM_CREATE, 0x7fff1ce5a750) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SET_TILING, 0x7fff1ce5a6e0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_CREATE, 0x7fff1ce5a6f0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SET_TILING, 0x7fff1ce5a680) = 0
ioctl(6, DRM_IOCTL_I915_GEM_BUSY, 0x7fff1ce5bf30) = 0
ioctl(6, DRM_IOCTL_I915_GEM_MADVISE, 0x7fff1ce5bf30) = 0
ioctl(6, DRM_IOCTL_I915_GEM_BUSY, 0x7fff1ce5c030) = 0
ioctl(6, DRM_IOCTL_I915_GEM_MMAP, 0x7fff1ce5bfe0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fff1ce5bfa0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_BUSY, 0x7fff1ce5c1e0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fff1ce5c150) = 0
ioctl(6, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7fff1ce5bf80) = 0
ioctl(6, DRM_IOCTL_I915_GEM_BUSY, 0x7fff1ce5bea0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_MADVISE, 0x7fff1ce5bea0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fff1ce5be90) = 0
ioctl(6, DRM_IOCTL_I915_GEM_BUSY, 0x7fff1ce5bdf0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_MADVISE, 0x7fff1ce5bdf0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fff1ce5bde0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_BUSY, 0x7fff1ce5f2d0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fff1ce5f240) = 0
ioctl(6, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0x7fff1ce5f490) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fff1ce5f430) = 0
ioctl(6, DRM_IOCTL_I915_GEM_MADVISE, 0x7fff1ce5f400) = 0
ioctl(6, DRM_IOCTL_I915_GEM_MADVISE, 0x7fff1ce5f400) = 0
ioctl(6, DRM_IOCTL_I915_GEM_BUSY, 0x7fff1ce5f3b0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_MADVISE, 0x7fff1ce5f3b0) = 0
ioctl(6, DRM_IOCTL_I915_GEM_SET_DOMAIN, 0x7fff1ce5f3a0) = 0
poll([{fd=5, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=5, revents=POLLIN|POLLOUT}])
recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="#\203\377\34\32\0\0\0\6\0\2\0O\234\217\0\0\0\0\0\4\1\0\0\20\0\240\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 264
writev(5, [{iov_base="_\0\2\0\0\0\0\0", iov_len=8}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 8
poll([{fd=5, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=5, revents=POLLOUT}])
writev(5, [{iov_base="\223\1\22\0\20\0\240\0%\0\240\0\372\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=72}], 1) = 72
poll([{fd=5, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=5, revents=POLLIN|POLLOUT}])
recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\6\0\35\0\0\0\0\0\0_\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
writev(5, [{iov_base="\223\2\n\0\20\0\240\0\373\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=40}], 1) = 40
poll([{fd=5, events=POLLIN}], 1, -1)    = 1 ([{fd=5, revents=POLLIN}])
recvmsg(5, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="#\223\2\35\2\0\0\0\1\0\1\0$\0\240\0\20\0\240\0\373\6\0\0h\253\3720\2\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 40
recvmsg(5, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=12, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=12, revents=POLLIN|POLLOUT}])
recvmsg(12, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="W\0\254)\4\1\0\0\234\0\0\0M\234\217\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 64
writev(12, [{iov_base="_\31\2\0\0\0\0\0", iov_len=8}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 8
recvmsg(12, {msg_namelen=0}, 0)         = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}, {fd=13, events=POLLIN}, {fd=21, events=POLLIN}, {fd=22, events=POLLIN}, {fd=23, events=POLLIN}, {fd=24, events=POLLIN}, {fd=26, events=POLLIN}, {fd=27, events=POLLIN}, {fd=34, events=POLLIN}, {fd=35, events=POLLIN}], 13, 0) = 2 ([{fd=4, revents=POLLIN}, {fd=12, revents=POLLIN}])
read(4, "\1\0\0\0\0\0\0\0", 16)         = 8
write(4, "\1\0\0\0\0\0\0\0", 8)         = 8
recvmsg(5, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=12, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=12, revents=POLLIN|POLLOUT}])
recvmsg(12, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0\6\256)\0\0\0\0\0\0_\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
writev(12, [{iov_base="\211\31\1\0", iov_len=4}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 4
poll([{fd=12, events=POLLIN}], 1, -1)   = 1 ([{fd=12, revents=POLLIN}])
recvmsg(12, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\0\257)\0\1\0\0*\0|\1\20\0\20\0\7\0\7\0\1\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 1056
open("/gnu/store/np05q8mf1y9y4bk5y4ssj99m0dss2b1q-libx11-1.6.5/share/X11/XErrorDB", O_RDONLY) = 28
fstat(28, {st_mode=S_IFREG|0444, st_size=42077, ...}) = 0
read(28, "!\n! Copyright 1993, 1995, 1998  "..., 42077) = 42077
close(28)                               = 0
ioctl(2, TCGETS, {B38400 opost isig icanon echo ...}) = 0
getpid()                                = 6291
write(2, "\n(.gnome-shell-real:6291): Gdk-\33"..., 653) = 653
--- SIGTRAP {si_signo=SIGTRAP, si_code=SI_KERNEL} ---
+++ killed by SIGTRAP +++

^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#24445: GNOME desktop session crash when re-arranging dock
  2017-10-08 13:50       ` Thomas Danckaert
@ 2017-10-08 15:08         ` Ludovic Courtès
  2017-10-08 15:38           ` Thomas Danckaert
  0 siblings, 1 reply; 14+ messages in thread
From: Ludovic Courtès @ 2017-10-08 15:08 UTC (permalink / raw)
  To: Thomas Danckaert; +Cc: Mohammed Sadiq, 24445

[-- Attachment #1: Type: text/plain, Size: 1385 bytes --]

Hello!

Thomas Danckaert <post@thomasdanckaert.be> skribis:

> libxcursor's configure script has an option "--with-cursorpath=<paths>"
> 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’.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 890 bytes --]

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,

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* bug#24445: GNOME desktop session crash when re-arranging dock
  2017-10-08 15:08         ` Ludovic Courtès
@ 2017-10-08 15:38           ` Thomas Danckaert
  2017-10-08 19:18             ` Ludovic Courtès
  0 siblings, 1 reply; 14+ messages in thread
From: Thomas Danckaert @ 2017-10-08 15:38 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: Mohammed Sadiq, 24445

[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]

ludo@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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-system-operating-system-etc-service-Set-XCURSOR_PATH.patch --]
[-- Type: text/x-patch, Size: 1094 bytes --]

From e6328f95f3c7dbec3f124f15a3cd50f95e4431d2 Mon Sep 17 00:00:00 2001
From: Thomas Danckaert <thomas.danckaert@gmail.com>
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


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* bug#24445: GNOME desktop session crash when re-arranging dock
  2017-10-08 15:38           ` Thomas Danckaert
@ 2017-10-08 19:18             ` Ludovic Courtès
  2017-10-09  8:58               ` Thomas Danckaert
  0 siblings, 1 reply; 14+ messages in thread
From: Ludovic Courtès @ 2017-10-08 19:18 UTC (permalink / raw)
  To: Thomas Danckaert; +Cc: Mohammed Sadiq, 24445

Howdy!

Thomas Danckaert <post@thomasdanckaert.be> 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’.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#24445: GNOME desktop session crash when re-arranging dock
  2017-10-08 19:18             ` Ludovic Courtès
@ 2017-10-09  8:58               ` Thomas Danckaert
  2017-10-09  9:51                 ` Ludovic Courtès
  0 siblings, 1 reply; 14+ messages in thread
From: Thomas Danckaert @ 2017-10-09  8:58 UTC (permalink / raw)
  To: ludo; +Cc: sadiq, 24445

Hi,

From: ludo@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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#24445: GNOME desktop session crash when re-arranging dock
  2017-10-09  8:58               ` Thomas Danckaert
@ 2017-10-09  9:51                 ` Ludovic Courtès
  2017-10-09 10:47                   ` Thomas Danckaert
  2017-10-10  8:29                   ` Thomas Danckaert
  0 siblings, 2 replies; 14+ messages in thread
From: Ludovic Courtès @ 2017-10-09  9:51 UTC (permalink / raw)
  To: Thomas Danckaert; +Cc: sadiq, 24445

Hey Thomas,

Thomas Danckaert <post@thomasdanckaert.be> skribis:

> From: ludo@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’.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#24445: GNOME desktop session crash when re-arranging dock
  2017-10-09  9:51                 ` Ludovic Courtès
@ 2017-10-09 10:47                   ` Thomas Danckaert
  2017-10-10  8:29                   ` Thomas Danckaert
  1 sibling, 0 replies; 14+ messages in thread
From: Thomas Danckaert @ 2017-10-09 10:47 UTC (permalink / raw)
  To: ludo; +Cc: sadiq, 24445

From: ludo@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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#24445: GNOME desktop session crash when re-arranging dock
  2017-10-09  9:51                 ` Ludovic Courtès
  2017-10-09 10:47                   ` Thomas Danckaert
@ 2017-10-10  8:29                   ` Thomas Danckaert
  1 sibling, 0 replies; 14+ messages in thread
From: Thomas Danckaert @ 2017-10-10  8:29 UTC (permalink / raw)
  To: 24445-done



^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2017-10-10  8:30 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-15 13:45 bug#24445: GNOME desktop session crash when re-arranging dock Ravishankar S
2017-09-27  7:48 ` Thomas Danckaert
2017-09-30  5:51 ` bug#24445: [No Subject] Mohammed Sadiq
2017-10-02 14:51   ` bug#24445: GNOME desktop session crash when re-arranging dock Ludovic Courtès
2017-10-02 18:01     ` Mohammed Sadiq
2017-10-02 18:34     ` Mark H Weaver
2017-10-08 13:50       ` Thomas Danckaert
2017-10-08 15:08         ` Ludovic Courtès
2017-10-08 15:38           ` Thomas Danckaert
2017-10-08 19:18             ` Ludovic Courtès
2017-10-09  8:58               ` Thomas Danckaert
2017-10-09  9:51                 ` Ludovic Courtès
2017-10-09 10:47                   ` Thomas Danckaert
2017-10-10  8:29                   ` Thomas Danckaert

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).