! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Input randomly blocked
Status:
RESOLVED: FIXED

Comments

Description Adam Purkrt 2018-08-18 17:47:15 CEST
I experience more or less random lock-ups when using xfwm4 4.13.1. Especially with firefox, after 2-3 minutes of using it. The mouse cursor is still moving, but all the apps as well as xfce panels becomes unresponsive to input for roughly a minute. Also experienced this lock-up in hexchat.

Reverting to 4.13.0 fixes this issue.
Comment 1 Benny Siegert 2018-11-10 17:14:40 CET
+1. 

In pkgsrc (the NetBSD package collection), we recently updated xfwm4 to 4.13.1 and see the same thing. As I wrote in http://gnats.netbsd.org/53718:

"I see similar issues actually. As far as I can tell, xfwm4 wedges
itself at some point when you move a window -- the first time works,
then it somehow hangs. You may notice that in this situation,
right-click on a title bar does not bring up a context menu.

In this situation, you can still "pkill xfwm4", at which point
xfce4-session will relaunch it and it will work again for a while."
Comment 2 Martin Husemann 2018-11-13 22:26:23 CET
I did a build with --enable-debug=full and get this log (assuming this is the part where I tried to drag a window and it did not move):

TRACE[frame.c:133] frameBottom(): client "martin:/usr/pkgobj/wm/xfce4-wm/work/xfwm4-4.13.1/src " (0x1600002)
TRACE[mypixmap.c:1049] xfwmPixmapFree(): pixmap 0x7f7fffffdd70
TRACE[mypixmap.c:1049] xfwmPixmapFree(): pixmap 0x7f7fffffde00
TRACE[mypixmap.c:1049] xfwmPixmapFree(): pixmap 0x7f7fffffde30
TRACE[mypixmap.c:1049] xfwmPixmapFree(): pixmap 0x7f7fffffdda0
TRACE[mypixmap.c:1049] xfwmPixmapFree(): pixmap 0x7f7fffffddd0
TRACE[events.c:2332] xfwm4_event_filter(): entering
TRACE[events.c:2201] handleEvent(): entering
TRACE[events.c:1313] handleConfigureNotify(): entering
TRACE[compositor.c:3977] compositorHandleEvent(): event type 22
TRACE[compositor.c:3406] compositorHandleConfigureNotify(): window 0xe001eb
TRACE[compositor.c:176] find_cwindow_in_display(): window 0xe001eb
TRACE[compositor.c:156] find_cwindow_in_screen(): window 0xe001eb
TRACE[events.c:2334] xfwm4_event_filter(): leaving
TRACE[events.c:2332] xfwm4_event_filter(): entering
TRACE[events.c:2201] handleEvent(): entering
TRACE[events.c:293] handleMotionNotify(): entering
TRACE[compositor.c:3977] compositorHandleEvent(): event type 6
TRACE[events.c:2334] xfwm4_event_filter(): leaving
TRACE[event_filter.c:48] default_event_filter(): unhandled XFWM_EVENT_MOTION event
TRACE[events.c:2332] xfwm4_event_filter(): entering
TRACE[events.c:2201] handleEvent(): entering
TRACE[events.c:293] handleMotionNotify(): entering
TRACE[compositor.c:3977] compositorHandleEvent(): event type 6
TRACE[events.c:2334] xfwm4_event_filter(): leaving
TRACE[event_filter.c:48] default_event_filter(): unhandled XFWM_EVENT_MOTION event
TRACE[events.c:2332] xfwm4_event_filter(): entering
TRACE[events.c:2201] handleEvent(): entering
TRACE[events.c:293] handleMotionNotify(): entering
TRACE[compositor.c:3977] compositorHandleEvent(): event type 6
TRACE[events.c:2334] xfwm4_event_filter(): leaving

I can examine more details with gdb if someone points me at a good breakpoint setting. I can also make the full log available or do a new one.
Comment 3 Adam Purkrt 2019-05-25 12:34:05 CEST
Seems like this is fixed in 4.13.2

Bug #14611

Reported by:
Adam Purkrt
Reported on: 2018-08-18
Last modified on: 2019-10-12

People

Assignee:
Olivier Fourdan
CC List:
2 users

Version

Version:
4.13.1

Attachments

Additional information