Charles Campbell wrote: > >> I'm afraid that patch 866, which is flawed, will end up in 7.5. Could > >> this patch be backed out until its fixed, please? > > I'm not aware of a known problem. What is the flaw? > > > > Hello, Bram: > > With the latest batch of patches I can no longer compile vim without > patch#866, so I may be using an out-of-date version of vim for awhile. > > I ran pchk with the fully updated vim and got the usual hang: > > In the first gvim process: > (gdb) where > #0 0x0000003f4100efa0 in __nanosleep_nocancel () from > /lib64/libpthread.so.0 > #1 0x0000000000559b20 in mch_delay (msec=50, ignoreinput=1) at > os_unix.c:638 > #2 0x00000000005f3e99 in ui_delay (msec=50, ignoreinput=1) at ui.c:251 > #3 0x00000000004e7b2a in ServerWait (dpy=0x1fdd400, w=85983235, > endCond=0x4e8030 <WaitForReply>, endData=0x7fff0178f050, localLoop=0, > seconds=-1) at if_xcmdsrv.c:633 > #4 0x00000000004e80a6 in serverReadReply (dpy=0x1fdd400, win=85983235, > str=0x7fff0178f0b0, localLoop=0) at if_xcmdsrv.c:821 > #5 0x0000000000475dc8 in f_remote_read (argvars=0x7fff0178f200, > rettv=0x7fff0178f9e0) at eval.c:15857
Hmm, I don't think nanosleep() can be broken, can it? You can check if its argument got corrupted. I do spot a problem in serverReadReply(). But it's actually in part of the "if" that's not used: It sets "tv" once time before the loop and then repeatedly uses it. But some implementations of select() will subtract the waiting time from "tv". But then, maybe that is intended. Another possibility is that ServerWait() is called after a message has been put in the queue. It looks like f_remote_read() does not check the queue before calling serverReadReply(). You could use the debugger to check this, if there is a message in the queue already. Otherwise I would recommend adding some printf() statements that write lines in a log file, so that you can see what's happening without setting breakpoints (which messes up the asynchronous nature of all this). > I think that the second gvim process (the "remote" gvim process) is > probably ok, its just awaiting commands. > > It seems to be hung in a 50msec delay -- which lasts forever. FYI -- I > used gdb to attach to these two processes. A 50 msec delay should not take that long! -- Bare feet magnetize sharp metal objects so they point upward from the floor -- especially in the dark. /// Bram Moolenaar -- b...@moolenaar.net -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
