Christian J. Robinson <[email protected]> wrote: > One of the recent patches must have introduced some kind of bug, because on > Windows Vim keeps telling me my channel has closed when it shouldn't. > > To reproduce this, put both of the attached files in the same directory and > source channelclose.vim. It can take several seconds and/or some cursor > movements, but sooner or later Vim will run the close callback defined, even > though the server should still be up and running. > > Additionally, after this happens Vim becomes very unstable and is liable to > crash. > > - Christian
Hi Christian I can reproduce a use of free memory 100% of the time with Vim-7.4.1721 on Linux x86_64 using your script if I do: $ valgrind --num-callers=50 \ ./vim -u NONE -c 'so channelclose.vim' 2> valgrind.log Vim shows: Message from server: Server got: test message ... then after a few seconds: Channel closed ... then wait a few seconds and I type: :so channelclose.vim ... and valgrind complains with this error: ==11881== Memcheck, a memory error detector ==11881== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==11881== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==11881== Command: ./vim -u NONE -c so\ channelclose.vim ==11881== alarm after 10 seconds ==11881== Invalid read of size 4 ==11881== at 0x56A73C: channel_unref (channel.c:428) ==11881== by 0x4313B2: clear_tv (eval.c:22275) ==11881== by 0x43D716: set_var (eval.c:22991) ==11881== by 0x43D963: set_var_lval (eval.c:2986) ==11881== by 0x43F19D: ex_let_one (eval.c:2549) ==11881== by 0x43F25C: ex_let_vars (eval.c:2015) ==11881== by 0x440A71: ex_let (eval.c:1980) ==11881== by 0x460B56: do_one_cmd (ex_docmd.c:2921) ==11881== by 0x460B56: do_cmdline (ex_docmd.c:1107) ==11881== by 0x454618: do_source (ex_cmds2.c:3906) ==11881== by 0x454BC9: cmd_source (ex_cmds2.c:3519) ==11881== by 0x454C15: ex_source (ex_cmds2.c:3494) ==11881== by 0x460B56: do_one_cmd (ex_docmd.c:2921) ==11881== by 0x460B56: do_cmdline (ex_docmd.c:1107) ==11881== by 0x4BEFBF: nv_colon (normal.c:5319) ==11881== by 0x4C801D: normal_cmd (normal.c:1149) ==11881== by 0x5719F1: main_loop (main.c:1359) ==11881== by 0x574986: main (main.c:1051) ==11881== Address 0x76b6a3c is 828 bytes inside a block of size 840 free'd ==11881== at 0x4C2BDEC: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==11881== by 0x4B0F67: vim_free (misc2.c:1695) ==11881== by 0x568AB6: channel_free_channel (channel.c:390) ==11881== by 0x569684: free_unused_channels (channel.c:463) ==11881== by 0x4325C0: free_unref_items (eval.c:7136) ==11881== by 0x4325C0: garbage_collect (eval.c:7016) ==11881== by 0x482263: before_blocking (getchar.c:1526) ==11881== by 0x4E3E92: mch_inchar (os_unix.c:435) ==11881== by 0x553CD3: ui_inchar (ui.c:195) ==11881== by 0x482568: inchar (getchar.c:3056) ==11881== by 0x484426: vgetorpeek (getchar.c:2832) ==11881== by 0x484B4E: vgetc (getchar.c:1605) ==11881== by 0x484BA1: safe_vgetc (getchar.c:1801) ==11881== by 0x4C74FB: normal_cmd (normal.c:627) ==11881== by 0x5719F1: main_loop (main.c:1359) ==11881== by 0x574986: main (main.c:1051) (and more errors after that) Given that memory was freed by garbage_collect(), I suppose that the bug was introduced by patch 7.4.1719. Regards Dominique -- -- 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.
