Aaron Burrow wrote: > I was recently hacking around X11 selections and I stumbled upon a > repeatable sequence of events that will make vim hang. > > [burrows@flx src]$ uname -a > Linux flx 3.18.6-1-ARCH #1 SMP PREEMPT Sat Feb 7 08:44:05 CET 2015 x86_64 > GNU/Linux > > [burrows@flx src]$ ./vim --version > VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Mar 8 2015 03:16:19) > Included patches: 1-622 > Compiled by burrows@flx > Huge version with GTK2 GUI. Features included (+) or not (-): [...] > > Follow these steps to hang vim. > 0. download + compile this file: > https://github.com/burrows-labs/clipboard/blob/master/src/owner.c > if you download the whole repository you can just do `make` > 1. Then start the owner program and vim. > 2. Now do :reg in vim > > vim should hang after a few seconds. Here is a backtrace from hanging vim > Program received signal SIGABRT, Aborted. > > 0x00007ffff489b4d0 in __poll_nocancel () from /usr/lib/libc.so.6 > > (gdb) bt > #0 0x00007ffff489b4d0 in __poll_nocancel () from /usr/lib/libc.so.6 > #1 0x00007ffff64b2c68 in _XtWaitForSomething () from /usr/lib/libXt.so.6 > #2 0x00007ffff64b40a7 in XtAppNextEvent () from /usr/lib/libXt.so.6 > #3 0x0000000000521191 in xterm_update () at os_unix.c:7101 > #4 0x00000000005248ec in RealWaitForChar (fd=0, msec=msec@entry=-1, > check_for_gpm=check_for_gpm@entry=0x7fffffffe31c) at os_unix.c:5469 [...] > > I think vim is having the same problem discussed here: > https://groups.google.com/forum/#!topic/comp.windows.x.motif/kD56Irjd8Tk > > ie, XtAppPending is returning with mask of XtIMTimer then XtAppNextEvent is > polling indefinitely because it's expecting mask XtIMXEvent. The patch at > the bottom of this email calls XtAppProcessEvent when we don't get > XtIMXEvent, otherwise it does everything the same way it's currently being > done. > > All of the tests seem to still be passing; `vim --servername serv > --remote-send ':reg<CR>'` also seems to work with this patch. > The gui version of vim is unaffected by this issue.
Hmm, strange. I had always thought, and the man page seems to suggest this as well, that when XtAppPending() returns non-zero, then XtAppNextEvent() will get the next event. The manual is unclear, but perhaps an XtIMTimer event is handled inside XtAppPending() and then it blocks on waiting for another event? After your change, wouldn't XtIMTimer events be sitting in the queue until a character is typed? -- What the word 'politics' means: 'Poli' in Latin meaning 'many' and 'tics' meaning 'bloodsucking creatures'. /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
