James McCoy wrote:
> On Thu, Sep 13, 2018 at 01:11:44PM +0200, Christian Brabandt wrote: > > > > On Do, 13 Sep 2018, 'Jonathon Fernyhough' via vim_use wrote: > > > > > On 13/09/2018 10:14, Christian Brabandt wrote: > > > > Are you sure this version includes the patch for 8.1.349? I am a bit > > > > confused because of the version number: > > > > vim_2%3A8.1.0349+really.v8.1.0369-0 > > > > > > Yes, it's really version 8.1.369. > > > > > > This specific package is built using Launchpad's Recipes feature [1] > > > which combines the debian/ packaging files from one git repo [2] with > > > the upstream sources from another [3]. This feature triggers automatic > > > builds when there's a change. > > > > > > The Recipes feature only allows certain values to be used in the > > > generated version number [4], one of which is the Git tag, but because > > > tags start with a "v" I have to hack the versioning slightly. The last > > > version I refreshed the packaging files for was 8.1.349 so that forms > > > the version number "root", the upstream tag provides the "really" > > > version number (with leading "v"). > > > > > > It's essentially a CI system for packaging which is quite handy for > > > Vim's release model. > > > > > > J > > > > > > > > > [1] https://code.launchpad.net/~jonathonf/+recipe/vim-daily > > > [2] https://code.launchpad.net/~jonathonf/+git/vim-packaging/+ref/master > > > [3] > > > https://code.launchpad.net/~jonathonf/vim/+git/vim-upstream/+ref/master > > > [4] > > > https://help.launchpad.net/Packaging/SourceBuilds/Recipes#Version_numbers_and_substitution_variables > > > > That is interesting. It might actually be a bug that Vim is handling the > > callback command when it should not. However to fix that, it would be > > great to have it reproducible. > > I've been running into the same crash, both in the CI for Debian's Vim > packaging[0] and when I run the build locally in sbuild. > > It seems to oscillate between an ml_get() error or a SEGV with a > backtrace like this: > > (gdb) bt -46 > #5 0x0000562880d202ac in deathtrap (sigarg=11) at os_unix.c:1191 > #6 <signal handler called> > #7 0x0000562880e6d1c5 in mf_get (mfp=0x1011, nr=1, page_count=1) at > memfile.c:418 > #8 0x0000562880cbb22c in ml_find_line (buf=0x562881a0d910, lnum=1, > action=19) at memline.c:3699 > #9 0x0000562880cb8cac in ml_get_buf (buf=0x562881a0d910, lnum=1, > will_change=0) at memline.c:2528 > #10 0x0000562880cc677b in plines_win_nofold (wp=0x562881a4db40, lnum=1) at > misc1.c:2174 > #11 0x0000562880cc6725 in plines_win_nofill (wp=0x562881a4db40, lnum=1, > winheight=1) at misc1.c:2157 > #12 0x0000562880cdf380 in curs_rows (wp=0x562881a4db40) at move.c:752 > #13 0x0000562880cdfa4e in curs_columns (may_scroll=1) at move.c:967 > #14 0x0000562880bfacf6 in edit (cmdchar=111, startln=1, count=1) at edit.c:501 > #15 0x0000562880cfa990 in invoke_edit (cap=0x7ffcf871a3b0, repl=0, cmd=111, > startln=1) at normal.c:9238 > #16 0x0000562880cf9654 in n_opencmd (cap=0x7ffcf871a3b0) at normal.c:8524 > #17 0x0000562880cfb406 in nv_open (cap=0x7ffcf871a3b0) at normal.c:9599 > #18 0x0000562880ceb6f9 in normal_cmd (oap=0x7ffcf871a430, toplevel=1) at > normal.c:1121 > #19 0x0000562880c6563f in exec_normal (was_typed=1, use_vpeekc=0, > may_use_terminal_loop=1) at ex_docmd.c:10509 > #20 0x0000562880c24b6b in f_feedkeys (argvars=0x7ffcf871a8c0, > rettv=0x7ffcf871aaa0) at evalfunc.c:3648 > #21 0x0000562880c1ff68 in call_internal_func (name=0x562881a0d4a0 "feedkeys", > argcount=2, argvars=0x7ffcf871a8c0, rettv=0x7ffcf871aaa0) at evalfunc.c:1084 > #22 0x0000562880deb7cd in call_func (funcname=0x5628819fb1e0 "feedkeys", > len=8, rettv=0x7ffcf871aaa0, argcount_in=2, argvars_in=0x7ffcf871a8c0, > argv_func=0x0, firstline=1, lastline=1, doesrange=0x7ffcf871aa68, > evaluate=1, partial=0x0, selfdict_in=0x0) at userfunc.c:1507 > #23 0x0000562880de940d in get_func_tv (name=0x5628819fb1e0 "feedkeys", len=8, > rettv=0x7ffcf871aaa0, arg=0x7ffcf871aa70, firstline=1, lastline=1, > doesrange=0x7ffcf871aa68, evaluate=1, partial=0x0, selfdict=0x0) > at userfunc.c:455 > #24 0x0000562880def8ab in ex_call (eap=0x7ffcf871ab90) at userfunc.c:3171 > #25 0x0000562880c565ad in do_one_cmd (cmdlinep=0x7ffcf871add0, sourcing=1, > cstack=0x7ffcf871aec0, fgetline=0x562880defd19 <get_func_line>, > cookie=0x5628819fecc0) at ex_docmd.c:2525 > #26 0x0000562880c53a18 in do_cmdline (cmdline=0x0, fgetline=0x562880defd19 > <get_func_line>, cookie=0x5628819fecc0, flags=7) at ex_docmd.c:1036 > #27 0x0000562880dea709 in call_user_func (fp=0x562881a3f3a0, argcount=0, > argvars=0x7ffcf871ba40, rettv=0x7ffcf871bc20, firstline=1, lastline=1, > selfdict=0x0) at userfunc.c:954 > #28 0x0000562880deb733 in call_func (funcname=0x562881a03500 > "Test_exit_cb_wipes_buf", len=22, rettv=0x7ffcf871bc20, argcount_in=0, > argvars_in=0x7ffcf871ba40, argv_func=0x0, firstline=1, lastline=1, > doesrange=0x7ffcf871bbe8, evaluate=1, partial=0x0, selfdict_in=0x0) at > userfunc.c:1488 > #29 0x0000562880de940d in get_func_tv (name=0x562881a03500 > "Test_exit_cb_wipes_buf", len=22, rettv=0x7ffcf871bc20, arg=0x7ffcf871bbf0, > firstline=1, lastline=1, doesrange=0x7ffcf871bbe8, evaluate=1, partial=0x0, > selfdict=0x0) at userfunc.c:455 > #30 0x0000562880def8ab in ex_call (eap=0x7ffcf871bd10) at userfunc.c:3171 > #31 0x0000562880c565ad in do_one_cmd (cmdlinep=0x7ffcf871bf50, sourcing=1, > cstack=0x7ffcf871c040, fgetline=0x562880defd19 <get_func_line>, > cookie=0x5628819e1aa0) at ex_docmd.c:2525 > #32 0x0000562880c53a18 in do_cmdline (cmdline=0x5628819f9db0 "call > Test_exit_cb_wipes_buf()", fgetline=0x562880defd19 <get_func_line>, > cookie=0x5628819e1aa0, flags=3) at ex_docmd.c:1036 > #33 0x0000562880c1b316 in ex_execute (eap=0x7ffcf871c600) at eval.c:8183 > #34 0x0000562880c565ad in do_one_cmd (cmdlinep=0x7ffcf871c840, sourcing=1, > cstack=0x7ffcf871c930, fgetline=0x562880defd19 <get_func_line>, > cookie=0x5628819e1aa0) at ex_docmd.c:2525 > #35 0x0000562880c53a18 in do_cmdline (cmdline=0x0, fgetline=0x562880defd19 > <get_func_line>, cookie=0x5628819e1aa0, flags=7) at ex_docmd.c:1036 > #36 0x0000562880dea709 in call_user_func (fp=0x5628819e8c60, argcount=1, > argvars=0x7ffcf871d4b0, rettv=0x7ffcf871d690, firstline=1, lastline=1, > selfdict=0x0) at userfunc.c:954 > #37 0x0000562880deb733 in call_func (funcname=0x562881a4b980 "RunTheTest", > len=10, rettv=0x7ffcf871d690, argcount_in=1, argvars_in=0x7ffcf871d4b0, > argv_func=0x0, firstline=1, lastline=1, > doesrange=0x7ffcf871d658, evaluate=1, partial=0x0, selfdict_in=0x0) at > userfunc.c:1488 > #38 0x0000562880de940d in get_func_tv (name=0x562881a4b980 "RunTheTest", > len=10, rettv=0x7ffcf871d690, arg=0x7ffcf871d660, firstline=1, lastline=1, > doesrange=0x7ffcf871d658, evaluate=1, partial=0x0, > selfdict=0x0) at userfunc.c:455 > #39 0x0000562880def8ab in ex_call (eap=0x7ffcf871d780) at userfunc.c:3171 > #40 0x0000562880c565ad in do_one_cmd (cmdlinep=0x7ffcf871d9c0, sourcing=1, > cstack=0x7ffcf871dab0, fgetline=0x562880c54612 <get_loop_line>, > cookie=0x7ffcf871da50) at ex_docmd.c:2525 > #41 0x0000562880c53a18 in do_cmdline (cmdline=0x5628819bf900 "\" This script > is sourced while editing the .vim file with the tests.", > fgetline=0x562880c5198e <getsourceline>, cookie=0x7ffcf871e020, flags=7) > at ex_docmd.c:1036 > #42 0x0000562880c51550 in do_source (fname=0x5628819e3dd3 "runtest.vim", > check_other=0, is_vimrc=0) at ex_cmds2.c:4615 > #43 0x0000562880c50afd in cmd_source (fname=0x5628819e3dd3 "runtest.vim", > eap=0x7ffcf871e210) at ex_cmds2.c:4229 > #44 0x0000562880c50a45 in ex_source (eap=0x7ffcf871e210) at ex_cmds2.c:4204 > #45 0x0000562880c565ad in do_one_cmd (cmdlinep=0x7ffcf871e450, sourcing=1, > cstack=0x7ffcf871e540, fgetline=0x0, cookie=0x0) at ex_docmd.c:2525 > #46 0x0000562880c53a18 in do_cmdline (cmdline=0x5628819e5ef0 "so > runtest.vim", fgetline=0x0, cookie=0x0, flags=11) at ex_docmd.c:1036 > #47 0x0000562880c53016 in do_cmdline_cmd (cmd=0x5628819e5ef0 "so > runtest.vim") at ex_docmd.c:637 > #48 0x0000562880e6a627 in exe_commands (parmp=0x562880f1e580 <params>) at > main.c:2964 > #49 0x0000562880e6734e in vim_main2 () at main.c:814 > #50 0x0000562880e66bc0 in main (argc=13, argv=0x7ffcf871ebc8) at main.c:441 > > In ml_get_buf(), the memory pointed to by buf is already junk: > (gdb) p buf->b_ml > $14 = {ml_line_count = 64, ml_mfp = 0x41, ml_flags = -2120272080, ml_stack = > 0x4a4a526a562d6d69, ml_stack_top = 1769353075, ml_stack_size = 775433581, > ml_line_lnum = 8299908937590779441, > ml_line_ptr = 0x672d6d69762f6372 <error: Cannot access memory at address > 0x672d6d69762f6372>, ml_locked = 0x747365742f336b74, ml_locked_low = 7498084, > ml_locked_high = 4049, ml_locked_lineadd = -1843846480, > ml_chunksize = 0x562881a4ebc0, ml_numchunks = -2119898176, ml_usedchunks = > 22056} > > If we go up a few frames to curs_column(), then curwin is valid: > > (gdb) f 13 > #13 0x0000562880cdfa4e in curs_columns (may_scroll=1) at move.c:967 > 967 curs_rows(curwin); > (gdb) p curwin->w_id > $20 = 1000 > (gdb) p curwin > $24 = (win_T *) 0x5628819de9c0 > > However, the next frame down wp isn't pointing at the same memory and > has garbage: > > (gdb) down > #12 0x0000562880cdf380 in curs_rows (wp=0x562881a4db40) at move.c:752 > 752 wp->w_cline_row += plines_win_nofill(wp, lnum++, > TRUE) > (gdb) p wp > $27 = (win_T *) 0x562881a4db40 > (gdb) p wp->w_id > $28 = -2119882880 > > [0]: https://salsa.debian.org/vim-team/vim/-/jobs/84811 Hmm, so it's some kind of memory corruption. There are to many stack frames to guess what is happening. Can you run this with ASAN, so that it should fail the moment the memory corruption happens? -- 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 -- [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.
