Re: Problem with patch#866
Charles E Campbell wrote: > > Hello: > > > > Back to the patch#866 problem I'm having. I'm using vim 7.4.1416: > > > > * using efence: links fine, but won't run (runs out of memory) > > * using valgrind: works > > * using valgrind --leak-check=full: works > > > > As can be seen from the trace below, the program hangs in a call to > > nanosleep > > in mch_delay(). The parameters to the nanosleep call seem to me to be > > correct. > > > > I put in the following code in mch_delay to force HAVE_USLEEP at line 632: > > > > #undef HAVE_NANOSLEEP > > #ifndef HAVE_USLEEP > > # define HAVE_USLEEP > > #endif > > > > This, too, "fixes" the problem. I wrote a small program which exercises > > nanosleep with the same time delay (5ms) and it doesn't hang. So, its > > not clear to me whether there's a vim source bug, a compiler bug, or o/s > > bug. > > > > So: is there a configure option to disable HAVE_NANOSLEEP? > > > Sigh -- seems that this isn't the whole story. vim no longer hangs, but > gvim does, even with usleep instead of nanosleep. > With valgrind+gvim, no valgrind problems but it still hangs. This points in the direction of a race condition... -- BRIDGEKEEPER: What is your favorite colour? LAUNCELOT:Blue. BRIDGEKEEPER: Right. Off you go. "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// 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.
Re: Problem with patch#866
Charles E Campbell wrote: > Hello: > > Back to the patch#866 problem I'm having. I'm using vim 7.4.1416: > > * using efence: links fine, but won't run (runs out of memory) > * using valgrind: works > * using valgrind --leak-check=full: works > > As can be seen from the trace below, the program hangs in a call to > nanosleep > in mch_delay(). The parameters to the nanosleep call seem to me to be > correct. > > I put in the following code in mch_delay to force HAVE_USLEEP at line 632: > > #undef HAVE_NANOSLEEP > #ifndef HAVE_USLEEP > # define HAVE_USLEEP > #endif > > This, too, "fixes" the problem. I wrote a small program which exercises > nanosleep with the same time delay (5ms) and it doesn't hang. So, its > not clear to me whether there's a vim source bug, a compiler bug, or o/s > bug. > > So: is there a configure option to disable HAVE_NANOSLEEP? > Sigh -- seems that this isn't the whole story. vim no longer hangs, but gvim does, even with usleep instead of nanosleep. With valgrind+gvim, no valgrind problems but it still hangs. New trace, not the same as before: (gdb) where #0 0x0038a36df0d8 in poll () from /lib64/libc.so.6 #1 0x0038a4e449f9 in ?? () from /lib64/libglib-2.0.so.0 #2 0x0038a4e44e4c in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #3 0x00620ed3 in gui_mch_wait_for_chars (wtime=-1) at gui_gtk_x11.c:6553 #4 0x006108ee in gui_wait_for_chars (wtime=-1) at gui.c:2925 #5 0x005f5d0c in ui_inchar (buf=0x8e6a52 "", maxlen=82, wtime=-1, tb_change_cnt=19) at ui.c:186 #6 0x004dbb9c in inchar (buf=0x8e6a52 "", maxlen=246, wait_time=-1, tb_change_cnt=19) at getchar.c:3056 #7 0x004db7b8 in vgetorpeek (advance=1) at getchar.c:2832 #8 0x004d97dd in vgetc () at getchar.c:1605 #9 0x004d9d11 in safe_vgetc () at getchar.c:1801 #10 0x00529fb6 in normal_cmd (oap=0x7fff7958c510, toplevel=1) at normal.c:637 #11 0x00647a18 in main_loop (cmdwin=0, noexmode=0) at main.c:1345 #12 0x00647358 in main (argc=2, argv=0x7fff7958c828) at main.c:1044 (gdb) up 2 #2 0x0038a4e44e4c in g_main_context_iteration () from /lib64/libglib-2.0.so.0 (gdb) up #3 0x00620ed3 in gui_mch_wait_for_chars (wtime=-1) at gui_gtk_x11.c:6553 6553g_main_context_iteration(NULL, TRUE); Regards, Chip Campbell -- -- 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.
Problem with patch#866
Hello: Back to the patch#866 problem I'm having. I'm using vim 7.4.1416: * using efence: links fine, but won't run (runs out of memory) * using valgrind: works * using valgrind --leak-check=full: works As can be seen from the trace below, the program hangs in a call to nanosleep in mch_delay(). The parameters to the nanosleep call seem to me to be correct. I put in the following code in mch_delay to force HAVE_USLEEP at line 632: #undef HAVE_NANOSLEEP #ifndef HAVE_USLEEP # define HAVE_USLEEP #endif This, too, "fixes" the problem. I wrote a small program which exercises nanosleep with the same time delay (5ms) and it doesn't hang. So, its not clear to me whether there's a vim source bug, a compiler bug, or o/s bug. So: is there a configure option to disable HAVE_NANOSLEEP? Regards, Chip Campbell gdb Debugging Trace - (gdb) where #0 0x0038a3e0eff0 in __nanosleep_nocancel () from /lib64/libpthread.so.0 #1 0x0055b5b0 in mch_delay (msec=50, ignoreinput=1) at os_unix.c:638 #2 0x005f5e61 in ui_delay (msec=50, ignoreinput=1) at ui.c:251 #3 0x004ea8c6 in ServerWait (dpy=0xd38600, w=98566147, endCond=0x4eadcc , endData=0x7fff004deb10, localLoop=0, seconds=-1) at if_xcmdsrv.c:633 #4 0x004eae42 in serverReadReply (dpy=0xd38600, win=98566147, str=0x7fff004deb70, localLoop=0) at if_xcmdsrv.c:821 #5 0x00478620 in f_remote_read (argvars=0x7fff004decc0, rettv=0x7fff004df4a0) at eval.c:17009 #6 0x0046b0d2 in call_func (funcname=0x1050b50 "remote_read(serverid)", len=11, rettv=0x7fff004df4a0, argcount=1, argvars=0x7fff004decc0, firstline=5, lastline=5, doesrange=0x7fff004dee9c, evaluate=1, selfdict=0x0) at eval.c:8913 #7 0x0046ab2e in get_func_tv (name=0x1050b50 "remote_read(serverid)", len=11, rettv=0x7fff004df4a0, arg= 0x7fff004df450, firstline=5, lastline=5, doesrange=0x7fff004dee9c, evaluate=1, selfdict=0x0) at eval.c:8712 #8 0x00465ba0 in eval7 (arg=0x7fff004df450, rettv=0x7fff004df4a0, evaluate=1, want_string=0) at eval.c:5245 #9 0x004653eb in eval6 (arg=0x7fff004df450, rettv=0x7fff004df4a0, evaluate=1, want_string=0) at eval.c:4896 #10 0x00464f9a in eval5 (arg=0x7fff004df450, rettv=0x7fff004df4a0, evaluate=1) at eval.c:4712 #11 0x00464507 in eval4 (arg=0x7fff004df450, rettv=0x7fff004df4a0, evaluate=1) at eval.c:4407 #12 0x00464357 in eval3 (arg=0x7fff004df450, rettv=0x7fff004df4a0, evaluate=1) at eval.c:4322 #13 0x004641ca in eval2 (arg=0x7fff004df450, rettv=0x7fff004df4a0, evaluate=1) at eval.c:4254 #14 0x00463ffd in eval1 (arg=0x7fff004df450, rettv=0x7fff004df4a0, evaluate=1) at eval.c:4182 #15 0x00463f58 in eval0 (arg=0x1050b50 "remote_read(serverid)", rettv=0x7fff004df4a0, nextcmd=0x7fff004df568, evaluate=1) at eval.c:4142 #16 0x0045fa00 in ex_let (eap=0x7fff004df560) at eval.c:1957 #17 0x004a36ef in do_one_cmd (cmdlinep=0x7fff004dfbf8, sourcing=1, cstack=0x7fff004df750, fgetline= 0x4a0fd4 , cookie=0x7fff004df6c0) at ex_docmd.c:2930 #18 0x004a0439 in do_cmdline (cmdline=0x0, fgetline=0x488468 , cookie=0x1061d40, flags=7) at ex_docmd.c:1116 #19 0x004879ab in call_user_func (fp=0x1041ac0, argcount=1, argvars=0x7fff004e0140, rettv=0x7fff004e0310, firstline= 5, lastline=5, selfdict=0x0) at eval.c:25127 #20 0x0046af93 in call_func (funcname=0x1021ef0 "pchk#PChk", len=9, rettv=0x7fff004e0310, argcount=1, argvars= 0x7fff004e0140, firstline=5, lastline=5, doesrange=0x7fff004e030c, evaluate=1, selfdict=0x0) at eval.c:8883 #21 0x0046ab2e in get_func_tv (name=0x1021ef0 "pchk#PChk", len=9, rettv=0x7fff004e0310, arg=0x7fff004e0330, firstline=5, lastline=5, doesrange=0x7fff004e030c, evaluate=1, selfdict=0x0) at eval.c:8712 #22 0x00462cfb in ex_call (eap=0x7fff004e0410) at eval.c:3533 #23 0x004a36ef in do_one_cmd (cmdlinep=0x7fff004e0aa8, sourcing=1, cstack=0x7fff004e0600, fgetline= 0x4ba15b , cookie=0x0) at ex_docmd.c:2930 #24 0x004a0439 in do_cmdline (cmdline=0x1061aa0 "call pchk#PChk(s:Check,)", fgetline=0x4ba15b , cookie= 0x0, flags=11) at ex_docmd.c:1116 ---Type to continue, or q to quit--- #25 0x004aa70f in do_ucmd (eap=0x7fff004e0c70) at ex_docmd.c:6742 #26 0x004a36c3 in do_one_cmd (cmdlinep=0x7fff004e1308, sourcing=0, cstack=0x7fff004e0e60, fgetline= 0x4ba15b , cookie=0x0) at ex_docmd.c:2921 #27 0x004a0439 in do_cmdline (cmdline=0x0, fgetline=0x4ba15b , cookie=0x0, flags=0) at ex_docmd.c:1116 #28 0x0053286b in nv_colon (cap=0x7fff004e1430) at normal.c:5335 #29 0x0052b0b7 in normal_cmd (oap=0x7fff004e1510, toplevel=1) at normal.c:1159 #30 0x00647a74 in main_loop (cmdwin=0, noexmode=0) at main.c:1345 #31 0x006473
