Description of problem: Closing a buffer+window after editing frequently results in very long wait or, more frequently, in a total hang of emacs. The only way I found to break such a hang is xkill. This is an old issue - google providing a confusingly large number of hits. With Mageia-6 this problem only happend rather unfrequently, on cauldron the frequency of such hangs has become quite annoying. Version-Release number of selected component (if applicable): see Source RPM How reproducible: Varying, more than about 1 out of 10 buffer close actions. There is no documented sequence of user actions that lead to a blocked situation. When such a hang happens, - it is always in consequence to a kill-buffer-and-window operation (and, I guess, similar operations) - it only happens if prior to killing the buffer a certain number of text zones had been deleted. Steps to Reproduce: 1. open a text buffer and do editing including sever actions the cut text strings 2. close the buffer with kill-buffer-and-window function (which is bound to Control-Backspace and the "Delete current buffer and window" item of the emacs "Windows" menu) Such a hang produces a tremendous amount of repetitive messages in .xession-errors, most of them being (xfce4-clipman:4939): Gdk-CRITICAL **: 15:09:45.606: gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed. Slightly more significant information can be obtained when emacs had been launched from command-line - see attachment
Created attachment 10557 [details] Output of emacs when error happens after command-line call of emacs
Assigning to the registered maintainer.
CC: (none) => marja11Assignee: bugsquad => thierry.vignaud
Observed something that might help a little bit: The problem arrives only, but than practically each time, when the mini-buffer has non-zero contents while closing the (main) text buffer.
Still valid in Beta-1 a workaround is suggested: append to the a user's .emacs.d/init.el (setq x-select-enable-clipboard-manager nil)