Loading ...
Sorry, an error occurred while loading the content.
 

Re: bug in search() + 'e'-flag +

Expand Messages
  • Kazuo Teramoto
    ... For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
    Message 1 of 15 , Feb 4, 2008
      > Same (start at X, stop at Y) for
      > :call search("^", "e")
      > :call search("^", "ce")

      Ouch, for me this is a little more serious, if I try this calls my vim
      always segfault (I don't need a test file and using -u NONE -U none),
      I don't know what need to be posted but the :version is

      VIM - Vi IMproved 7.0 (2006 May 7, compiled Aug 29 2007 10:59:43)
      Included patches: 1-122, 234-235, 39
      Big version without GUI. Features included (+) or not (-):
      +arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset
      +cindent -clientserver -clipboard +cmdline_compl +cmdline_hist
      +cmdline_info +comments +cryptv +cscope +cursorshape +dialog_con +diff
      +digraphs -dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search
      +farsi +file_in_path +find_in_path +folding -footer +fork() +gettext
      -hangul_input +iconv +insert_expand +jumplist +keymap +langmap
      +libcall
      +linebreak +lispindent +listcmds +localmap +menu +mksession
      +modify_fname +mouse -mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm
      +mouse_netterm +mouse_xterm +multi_byte +multi_lang -mzscheme
      -netbeans_intg
      -osfiletype +path_extra -perl +postscript +printer -profile -python
      +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent
      -sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static
      -tag_any_white -tcl +terminfo +termresponse +textobjects +title
      -toolbar +user_commands +vertsplit +virtualedit +visual +visualextra
      +viminfo +vreplace +wildignore +wildmenu +windows +writebackup -X11
      -xfontset -xim -xsmp -xterm_clipboard -xterm_save
      system vimrc file: "$VIM/vimrc"
      user vimrc file: "$HOME/.vimrc"
      user exrc file: "$HOME/.exrc"
      fall-back for $VIM: "/usr/share/vim"
      Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -g -Wall
      Linking: gcc -L/usr/local/lib -o vim -lncurses -lacl -lgpm

      --
      «Dans la vie, rien n'est à craindre, tout est à comprendre»
      Marie Sklodowska Curie.

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Tony Mechelynck
      ... ??? with patch 39 applied twice ??? none of 123-233 (a hundred and eleven missing patches) ??? and no compiled-by line ??? Oh, and it s a 7.0 anyway.
      Message 2 of 15 , Feb 4, 2008
        Kazuo Teramoto wrote:
        >> Same (start at X, stop at Y) for
        >> :call search("^", "e")
        >> :call search("^", "ce")
        >
        > Ouch, for me this is a little more serious, if I try this calls my vim
        > always segfault (I don't need a test file and using -u NONE -U none),
        > I don't know what need to be posted but the :version is
        >
        > VIM - Vi IMproved 7.0 (2006 May 7, compiled Aug 29 2007 10:59:43)
        > Included patches: 1-122, 234-235, 39
        > Big version without GUI. Features included (+) or not (-):

        ??? with patch 39 applied twice ??? none of 123-233 (a hundred and eleven
        missing patches) ??? and no "compiled-by" line ??? Oh, and it's a 7.0 anyway.
        Maybe you ought to install a 7.1 version (of which the current patchlevel is
        7.1.242)? See my "HowTo" page,
        http://users.skynet.be/antoine.mechelynck/vim/compunix.htm


        Best regards,
        Tony.
        --
        "I'd love to go out with you, but the last time I went out, I never
        came back."

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Ben Schmidt
        ... I bet some of those are 7.0 patches and some are 7.1 patches... What a mess! Definitely recompiling is in order! Ben. Send instant messages to your online
        Message 3 of 15 , Feb 5, 2008
          >> VIM - Vi IMproved 7.0 (2006 May 7, compiled Aug 29 2007 10:59:43)
          >> Included patches: 1-122, 234-235, 39
          >> Big version without GUI. Features included (+) or not (-):
          >
          > ??? with patch 39 applied twice ??? none of 123-233 (a hundred and eleven
          > missing patches) ??? and no "compiled-by" line ??? Oh, and it's a 7.0 anyway.
          > Maybe you ought to install a 7.1 version (of which the current patchlevel is
          > 7.1.242)? See my "HowTo" page,
          > http://users.skynet.be/antoine.mechelynck/vim/compunix.htm

          I bet some of those are 7.0 patches and some are 7.1 patches...

          What a mess! Definitely recompiling is in order!

          Ben.




          Send instant messages to your online friends http://au.messenger.yahoo.com


          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • ap
          ... *************** *** 833,842 **** continue; } ! if (options & SEARCH_END && !(options & SEARCH_NOOF)) { pos- lnum = lnum + endpos.lnum; ! pos- col
          Message 4 of 15 , Feb 5, 2008
            On Feb 4, 6:19 pm, Andy Wokula <anw...@...> wrote:
            > ap schrieb:
            >
            >
            >
            > > Hi ,
            >
            > > I think I found a bug in the search() function.
            > > X marks the spot (cursor).
            >
            > > X a
            > > c Y
            >
            > > :call search('\_s*a\_s*','e')
            >
            > > It seems that search() skips a character under this circumstances,
            > > or sets the end at the wrong place. The cursor will be positioned
            > > at the last col in line2 (Y) which is wrong, because the pattern
            > > can't possibly match a 'c'. I have a strong feeling this has
            > > something to do with the newline atom :-).
            >
            > > -ap
            >
            > Same (start at X, stop at Y) for
            > :call search("^", "e")
            > :call search("^", "ce")
            >
            > --
            > Andy

            *** ../../clean/vim7/src/search.c 2008-01-26 21:15:46.000000000 +0100
            --- search.c 2008-02-05 13:38:47.570525616 +0100
            ***************
            *** 833,842 ****
            continue;
            }

            ! if (options & SEARCH_END && !(options & SEARCH_NOOF))
            {
            pos->lnum = lnum + endpos.lnum;
            ! pos->col = endpos.col - 1;
            #ifdef FEAT_MBYTE
            if (has_mbyte)
            {
            --- 833,853 ----
            continue;
            }

            ! /* Don't do this for zerowidth matches. */
            ! if (options & SEARCH_END && !(options & SEARCH_NOOF)
            ! && !(matchpos.lnum == endpos.lnum && matchpos.col ==
            endpos.col))
            {
            + /* If the match ends in the 1st col, set it
            + * to the last one in the previous line.
            + * */
            pos->lnum = lnum + endpos.lnum;
            ! if ( endpos.col == 0 )
            ! {
            ! --pos->lnum;
            ! pos->col = (colnr_T)STRLEN(ml_get_buf(buf, pos->lnum,
            FALSE));
            ! }
            ! else
            ! pos->col = endpos.col - 1;
            #ifdef FEAT_MBYTE
            if (has_mbyte)
            {


            endpos->col will be 0 in this scenarios. Substract 1 and it will
            become a huge number,
            because col is an unsigned int. The correct value for pos would be the
            last col of
            the previous line. However I am not certain this is the right way to
            do this.

            There is another problem :

            --------------
            a
            a
            -------------

            call search('a\_s*','ew')
            will never wrap in this case.

            -ap

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_dev" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Andy Wokula
            Related (?): gVim7.1.233 crashes with 2 or more lines of text: foo bar ... ggd/ n/e -- Andy --~--~---------~--~----~------------~-------~--~----~ You received
            Message 5 of 15 , Feb 7, 2008
              Related (?):

              gVim7.1.233 crashes with 2 or more lines of text:

              foo
              bar

              and typing these commands:

              :set ve=all
              ggd/\n/e

              --
              Andy


              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_dev" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Bram Moolenaar
              ... I can reproduce it. One more for the todo list. -- hundred-and-one symptoms of being an internet addict: 5. You find yourself brainstorming for new
              Message 6 of 15 , Feb 7, 2008
                Andy Wokula wrote:

                > Related (?):
                >
                > gVim7.1.233 crashes with 2 or more lines of text:
                >
                > foo
                > bar
                >
                > and typing these commands:
                >
                > :set ve=all
                > ggd/\n/e

                I can reproduce it. One more for the todo list.

                --
                hundred-and-one symptoms of being an internet addict:
                5. You find yourself brainstorming for new subjects to search.

                /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                \\\ download, build and distribute -- http://www.A-A-P.org ///
                \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_dev" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • ap
                ... Yes, it s the same problem. -ap --~--~---------~--~----~------------~-------~--~----~ You received this message from the vim_dev maillist. For more
                Message 7 of 15 , Feb 8, 2008
                  On Feb 7, 1:19 pm, Andy Wokula <anw...@...> wrote:
                  > Related (?):
                  >
                  >

                  Yes, it's the same problem.

                  -ap
                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_dev" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • A.Politz
                  ... This one as well. They all work as expected in the patched version. Subject:odd behaviour with zs and multiline matches ===================== ... Yes,
                  Message 8 of 15 , Feb 8, 2008
                    ap wrote:
                    >
                    >
                    > On Feb 7, 1:19 pm, Andy Wokula <anw...@...> wrote:
                    >
                    >>Related (?):
                    >>
                    >>
                    >
                    >
                    > Yes, it's the same problem.
                    >
                    > -ap
                    > >
                    >

                    This one as well. They all work as expected in the patched version.

                    Subject:odd behaviour with '\zs' and multiline matches
                    =====================
                    A. Politz wrote:


                    >> ---buffer---
                    >> abcdefg
                    >> 1234567
                    >> ------------
                    >>
                    >> +
                    >>
                    >> :1s/g\n\zs1//
                    >>
                    >> =
                    >>
                    >> ---buffer---
                    >> 234567
                    >> ------------
                    >>
                    >>
                    >> Is it supposed to be this way ? I don't think so.
                    >> Or maybe someone will enlighten me.


                    Yes, that looks like a bug. Try :s/defg\n1\zs2// and only the "a" is
                    kept. One more for the todo list...
                    ======================

                    -ap

                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_dev" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • A.Politz
                    ... No wait, this was already fixed in 7.1.214. -ap --~--~---------~--~----~------------~-------~--~----~ You received this message from the vim_dev
                    Message 9 of 15 , Feb 8, 2008
                      A.Politz wrote:
                      > ap wrote:
                      >
                      >>
                      >>On Feb 7, 1:19 pm, Andy Wokula <anw...@...> wrote:
                      >>
                      >>
                      >>>Related (?):

                      >
                      > This one as well. They all work as expected in the patched version.
                      >
                      > Subject:odd behaviour with '\zs' and multiline matches
                      > =====================

                      >
                      >
                      No wait, this was already fixed in 7.1.214.

                      -ap

                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_dev" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • Dominique Pelle
                      ... I have a normal installation of vim-7.1.242 (all patches) and it s crashing for me as well. I have the same version of vim on 2 machines (one linux x66
                      Message 10 of 15 , Feb 11, 2008
                        On Feb 5, 2008 8:40 AM, Tony Mechelynck <antoine.mechelynck@...> wrote:
                        >
                        > Kazuo Teramoto wrote:
                        > >> Same (start at X, stop at Y) for
                        > >> :call search("^", "e")
                        > >> :call search("^", "ce")
                        > >
                        > > Ouch, for me this is a little more serious, if I try this calls my vim
                        > > always segfault (I don't need a test file and using -u NONE -U none),
                        > > I don't know what need to be posted but the :version is
                        > >
                        > > VIM - Vi IMproved 7.0 (2006 May 7, compiled Aug 29 2007 10:59:43)
                        > > Included patches: 1-122, 234-235, 39
                        > > Big version without GUI. Features included (+) or not (-):
                        >
                        > ??? with patch 39 applied twice ??? none of 123-233 (a hundred and eleven
                        > missing patches) ??? and no "compiled-by" line ??? Oh, and it's a 7.0 anyway.
                        > Maybe you ought to install a 7.1 version (of which the current patchlevel is
                        > 7.1.242)? See my "HowTo" page,
                        > http://users.skynet.be/antoine.mechelynck/vim/compunix.htm


                        I have a normal installation of vim-7.1.242 (all patches) and it's
                        crashing for me as well. I have the same version of vim on
                        2 machines (one linux x66 and one linux x86_64) and it's only
                        crashing on the the x86_64 machine only.

                        As soon as I type ":call search('\_s*a\_s*','e')" I get a core dump
                        on the x86_64 machine:

                        $ ./vim
                        Vim: Caught deadly signal SEGV
                        Vim: preserving files...
                        Vim: Finished.
                        Segmentation fault (core dumped)

                        $ gdb ./vim core
                        ...
                        Core was generated by `./vim'.
                        Program terminated with signal 11, Segmentation fault.
                        #0 0x00002b71866ebe47 in kill () from /lib64/libc.so.6
                        (gdb) bt
                        #0 0x00002b71866ebe47 in kill () from /lib64/libc.so.6
                        #1 0x000000000050e38d in may_core_dump () at os_unix.c:2950
                        #2 0x000000000050e328 in mch_exit (r=1) at os_unix.c:2915
                        #3 0x00000000004a5eb3 in getout (exitval=1) at main.c:1342
                        #4 0x00000000004d2128 in preserve_exit () at misc1.c:8355
                        #5 0x000000000050c73d in deathtrap (sigarg=11) at os_unix.c:1030
                        #6 <signal handler called>
                        #7 0x00000000004e0b33 in utf_head_off (base=0x9251c4 "c Y",
                        p=0x1009251c3 <Address 0x1009251c3 out of bounds>) at mbyte.c:2480
                        #8 0x0000000000539235 in searchit (win=0x831b90, buf=0x8333f0,
                        pos=0x7fff2690fa00, dir=1, pat=0x947c80 "\\_s*a\\_s*", count=1,
                        options=1088, pat_use=0, stop_lnum=0, tm=0x7fff2690f9e0) at search.c:848
                        #9 0x00000000004420e7 in search_cmn (argvars=0x7fff2690fbc0, match_pos=0x0,
                        flagsp=0x7fff2690fa8c) at eval.c:14077
                        #10 0x00000000004421cc in f_search (argvars=0x7fff2690fbc0,
                        rettv=0x7fff2690fd80) at eval.c:14120
                        #11 0x0000000000439522 in call_func (name=0x986920 "search", len=6,
                        rettv=0x7fff2690fd80, argcount=2, argvars=0x7fff2690fbc0, firstline=1,
                        lastline=1, doesrange=0x7fff2690fd7c, evaluate=1, selfdict=0x0)
                        at eval.c:7632
                        #12 0x0000000000439043 in get_func_tv (name=0x986920 "search", len=6,
                        rettv=0x7fff2690fd80, arg=0x7fff2690fda0, firstline=1, lastline=1,
                        doesrange=0x7fff2690fd7c, evaluate=1, selfdict=0x0) at eval.c:7450
                        #13 0x0000000000432c73 in ex_call (eap=0x7fff2690fe80) at eval.c:3215
                        #14 0x0000000000463c6b in do_one_cmd (cmdlinep=0x7fff26910528, sourcing=0,
                        cstack=0x7fff26910080, fgetline=0x47821a <getexline>, cookie=0x0)
                        at ex_docmd.c:2623
                        #15 0x000000000046146a in do_cmdline (cmdline=0x0,
                        getline=0x47821a <getexline>, cookie=0x0, flags=0) at ex_docmd.c:1099
                        #16 0x00000000004ebdd2 in nv_colon (cap=0x7fff26910670) at normal.c:5179
                        #17 0x00000000004e4dd8 in normal_cmd (oap=0x7fff26910730, toplevel=1)
                        at normal.c:1152
                        #18 0x00000000004a5be2 in main_loop (cmdwin=0, noexmode=0) at main.c:1181
                        #19 0x00000000004a572e in main (argc=1, argv=0x7fff26910a28) at main.c:940

                        (gdb) up
                        #1 0x000000000050e38d in may_core_dump () at os_unix.c:2950
                        2950 kill(getpid(), deadly_signal); /* Die using the
                        signal we caught */
                        (gdb)
                        #2 0x000000000050e328 in mch_exit (r=1) at os_unix.c:2915
                        2915 may_core_dump();
                        (gdb)
                        #3 0x00000000004a5eb3 in getout (exitval=1) at main.c:1342
                        1342 mch_exit(exitval);
                        (gdb)
                        #4 0x00000000004d2128 in preserve_exit () at misc1.c:8355
                        8355 getout(1);
                        (gdb)
                        #5 0x000000000050c73d in deathtrap (sigarg=11) at os_unix.c:1030
                        1030 preserve_exit(); /* preserve files and exit */
                        (gdb)
                        #6 <signal handler called>
                        (gdb)
                        #7 0x00000000004e0b33 in utf_head_off (base=0x9251c4 "c Y",
                        p=0x1009251c3 <Address 0x1009251c3 out of bounds>) at mbyte.c:2480
                        2480 if (*p < 0x80) /* be quick for ASCII */
                        (gdb) p p
                        $1 = (char_u *) 0x1009251c3 <Address 0x1009251c3 out of bounds>

                        -> pointer 'p' is invalid

                        Valgrind memory checker also detects a problem when
                        doing ":call search('\_s*a\_s*','e')" at the same location
                        on the x86_64 machine (no problem detected on the
                        x86 machine):

                        ==13671== Invalid read of size 1
                        ==13671== at 0x4E0B33: utf_head_off (mbyte.c:2480)
                        ==13671== by 0x539234: searchit (search.c:848)
                        ==13671== by 0x4420E6: search_cmn (eval.c:14077)
                        ==13671== by 0x4421CB: f_search (eval.c:14120)
                        ==13671== by 0x439521: call_func (eval.c:7632)
                        ==13671== by 0x439042: get_func_tv (eval.c:7450)
                        ==13671== by 0x432C72: ex_call (eval.c:3215)
                        ==13671== by 0x463C6A: do_one_cmd (ex_docmd.c:2623)
                        ==13671== by 0x461469: do_cmdline (ex_docmd.c:1099)
                        ==13671== by 0x4EBDD1: nv_colon (normal.c:5179)
                        ==13671== by 0x4E4DD7: normal_cmd (normal.c:1152)
                        ==13671== by 0x4A5BE1: main_loop (main.c:1181)
                        ==13671== by 0x4A572D: main (main.c:940)
                        ==13671== Address 0x10b5e697f is not stack'd, malloc'd or (recently) free'd

                        I can reproduce it 100% of the time.

                        -- Dominique

                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_dev" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      • Bram Moolenaar
                        ... What is the text you are searching in? I assume your encoding is set to utf-8 ? If you want to do a little digging, check out the code before calling
                        Message 11 of 15 , Feb 11, 2008
                          Dominique Pelle wrote:

                          > On Feb 5, 2008 8:40 AM, Tony Mechelynck <antoine.mechelynck@...> wrote:
                          > >
                          > > Kazuo Teramoto wrote:
                          > > >> Same (start at X, stop at Y) for
                          > > >> :call search("^", "e")
                          > > >> :call search("^", "ce")
                          > > >
                          > > > Ouch, for me this is a little more serious, if I try this calls my vim
                          > > > always segfault (I don't need a test file and using -u NONE -U none),
                          > > > I don't know what need to be posted but the :version is
                          > > >
                          > > > VIM - Vi IMproved 7.0 (2006 May 7, compiled Aug 29 2007 10:59:43)
                          > > > Included patches: 1-122, 234-235, 39
                          > > > Big version without GUI. Features included (+) or not (-):
                          > >
                          > > ??? with patch 39 applied twice ??? none of 123-233 (a hundred and eleven
                          > > missing patches) ??? and no "compiled-by" line ??? Oh, and it's a 7.0 anyway.
                          > > Maybe you ought to install a 7.1 version (of which the current patchlevel is
                          > > 7.1.242)? See my "HowTo" page,
                          > > http://users.skynet.be/antoine.mechelynck/vim/compunix.htm
                          >
                          >
                          > I have a normal installation of vim-7.1.242 (all patches) and it's
                          > crashing for me as well. I have the same version of vim on
                          > 2 machines (one linux x66 and one linux x86_64) and it's only
                          > crashing on the the x86_64 machine only.
                          >
                          > As soon as I type ":call search('\_s*a\_s*','e')" I get a core dump
                          > on the x86_64 machine:
                          >
                          > $ ./vim
                          > Vim: Caught deadly signal SEGV
                          > Vim: preserving files...
                          > Vim: Finished.
                          > Segmentation fault (core dumped)
                          >
                          > $ gdb ./vim core
                          > ...
                          > Core was generated by `./vim'.
                          > Program terminated with signal 11, Segmentation fault.
                          > #0 0x00002b71866ebe47 in kill () from /lib64/libc.so.6
                          > (gdb) bt
                          > #0 0x00002b71866ebe47 in kill () from /lib64/libc.so.6
                          > #1 0x000000000050e38d in may_core_dump () at os_unix.c:2950
                          > #2 0x000000000050e328 in mch_exit (r=1) at os_unix.c:2915
                          > #3 0x00000000004a5eb3 in getout (exitval=1) at main.c:1342
                          > #4 0x00000000004d2128 in preserve_exit () at misc1.c:8355
                          > #5 0x000000000050c73d in deathtrap (sigarg=11) at os_unix.c:1030
                          > #6 <signal handler called>
                          > #7 0x00000000004e0b33 in utf_head_off (base=0x9251c4 "c Y",
                          > p=0x1009251c3 <Address 0x1009251c3 out of bounds>) at mbyte.c:2480
                          > #8 0x0000000000539235 in searchit (win=0x831b90, buf=0x8333f0,
                          > pos=0x7fff2690fa00, dir=1, pat=0x947c80 "\\_s*a\\_s*", count=1,
                          > options=1088, pat_use=0, stop_lnum=0, tm=0x7fff2690f9e0) at search.c:848
                          > #9 0x00000000004420e7 in search_cmn (argvars=0x7fff2690fbc0, match_pos=0x0,
                          > flagsp=0x7fff2690fa8c) at eval.c:14077
                          > #10 0x00000000004421cc in f_search (argvars=0x7fff2690fbc0,
                          > rettv=0x7fff2690fd80) at eval.c:14120
                          > #11 0x0000000000439522 in call_func (name=0x986920 "search", len=6,
                          > rettv=0x7fff2690fd80, argcount=2, argvars=0x7fff2690fbc0, firstline=1,
                          > lastline=1, doesrange=0x7fff2690fd7c, evaluate=1, selfdict=0x0)
                          > at eval.c:7632
                          > #12 0x0000000000439043 in get_func_tv (name=0x986920 "search", len=6,
                          > rettv=0x7fff2690fd80, arg=0x7fff2690fda0, firstline=1, lastline=1,
                          > doesrange=0x7fff2690fd7c, evaluate=1, selfdict=0x0) at eval.c:7450
                          > #13 0x0000000000432c73 in ex_call (eap=0x7fff2690fe80) at eval.c:3215
                          > #14 0x0000000000463c6b in do_one_cmd (cmdlinep=0x7fff26910528, sourcing=0,
                          > cstack=0x7fff26910080, fgetline=0x47821a <getexline>, cookie=0x0)
                          > at ex_docmd.c:2623
                          > #15 0x000000000046146a in do_cmdline (cmdline=0x0,
                          > getline=0x47821a <getexline>, cookie=0x0, flags=0) at ex_docmd.c:1099
                          > #16 0x00000000004ebdd2 in nv_colon (cap=0x7fff26910670) at normal.c:5179
                          > #17 0x00000000004e4dd8 in normal_cmd (oap=0x7fff26910730, toplevel=1)
                          > at normal.c:1152
                          > #18 0x00000000004a5be2 in main_loop (cmdwin=0, noexmode=0) at main.c:1181
                          > #19 0x00000000004a572e in main (argc=1, argv=0x7fff26910a28) at main.c:940
                          >
                          > (gdb) up
                          > #1 0x000000000050e38d in may_core_dump () at os_unix.c:2950
                          > 2950 kill(getpid(), deadly_signal); /* Die using the
                          > signal we caught */
                          > (gdb)
                          > #2 0x000000000050e328 in mch_exit (r=1) at os_unix.c:2915
                          > 2915 may_core_dump();
                          > (gdb)
                          > #3 0x00000000004a5eb3 in getout (exitval=1) at main.c:1342
                          > 1342 mch_exit(exitval);
                          > (gdb)
                          > #4 0x00000000004d2128 in preserve_exit () at misc1.c:8355
                          > 8355 getout(1);
                          > (gdb)
                          > #5 0x000000000050c73d in deathtrap (sigarg=11) at os_unix.c:1030
                          > 1030 preserve_exit(); /* preserve files and exit */
                          > (gdb)
                          > #6 <signal handler called>
                          > (gdb)
                          > #7 0x00000000004e0b33 in utf_head_off (base=0x9251c4 "c Y",
                          > p=0x1009251c3 <Address 0x1009251c3 out of bounds>) at mbyte.c:2480
                          > 2480 if (*p < 0x80) /* be quick for ASCII */
                          > (gdb) p p
                          > $1 = (char_u *) 0x1009251c3 <Address 0x1009251c3 out of bounds>
                          >
                          > -> pointer 'p' is invalid
                          >
                          > Valgrind memory checker also detects a problem when
                          > doing ":call search('\_s*a\_s*','e')" at the same location
                          > on the x86_64 machine (no problem detected on the
                          > x86 machine):
                          >
                          > ==13671== Invalid read of size 1
                          > ==13671== at 0x4E0B33: utf_head_off (mbyte.c:2480)
                          > ==13671== by 0x539234: searchit (search.c:848)
                          > ==13671== by 0x4420E6: search_cmn (eval.c:14077)
                          > ==13671== by 0x4421CB: f_search (eval.c:14120)
                          > ==13671== by 0x439521: call_func (eval.c:7632)
                          > ==13671== by 0x439042: get_func_tv (eval.c:7450)
                          > ==13671== by 0x432C72: ex_call (eval.c:3215)
                          > ==13671== by 0x463C6A: do_one_cmd (ex_docmd.c:2623)
                          > ==13671== by 0x461469: do_cmdline (ex_docmd.c:1099)
                          > ==13671== by 0x4EBDD1: nv_colon (normal.c:5179)
                          > ==13671== by 0x4E4DD7: normal_cmd (normal.c:1152)
                          > ==13671== by 0x4A5BE1: main_loop (main.c:1181)
                          > ==13671== by 0x4A572D: main (main.c:940)
                          > ==13671== Address 0x10b5e697f is not stack'd, malloc'd or (recently) free'd
                          >
                          > I can reproduce it 100% of the time.

                          What is the text you are searching in? I assume your 'encoding' is set
                          to "utf-8"?

                          If you want to do a little digging, check out the code before calling
                          mb_head_off(), line 848 in search.c. Especially the value of "endpos"
                          compared to what's in the text.

                          --
                          hundred-and-one symptoms of being an internet addict:
                          18. Your wife drapes a blond wig over your monitor to remind you of what she
                          looks like.

                          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                          /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                          \\\ download, build and distribute -- http://www.A-A-P.org ///
                          \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                          --~--~---------~--~----~------------~-------~--~----~
                          You received this message from the "vim_dev" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                          -~----------~----~----~----~------~----~------~--~---
                        • Dominique Pelle
                          ... I m doing the exact same thing as described in the first email of this thread, i.e. the buffer contains only 2 lines, the cursor is on first character X: X
                          Message 12 of 15 , Feb 12, 2008
                            On Feb 11, 2008 10:28 PM, Bram Moolenaar <Bram@...> wrote:
                            >
                            >
                            > Dominique Pelle wrote:
                            >
                            > > On Feb 5, 2008 8:40 AM, Tony Mechelynck <antoine.mechelynck@...> wrote:
                            > > >
                            > > > Kazuo Teramoto wrote:
                            > > > >> Same (start at X, stop at Y) for
                            > > > >> :call search("^", "e")
                            > > > >> :call search("^", "ce")
                            > > > >
                            > > > > Ouch, for me this is a little more serious, if I try this calls my vim
                            > > > > always segfault (I don't need a test file and using -u NONE -U none),
                            > > > > I don't know what need to be posted but the :version is
                            > > > >
                            > > > > VIM - Vi IMproved 7.0 (2006 May 7, compiled Aug 29 2007 10:59:43)
                            > > > > Included patches: 1-122, 234-235, 39
                            > > > > Big version without GUI. Features included (+) or not (-):
                            > > >
                            > > > ??? with patch 39 applied twice ??? none of 123-233 (a hundred and eleven
                            > > > missing patches) ??? and no "compiled-by" line ??? Oh, and it's a 7.0 anyway.
                            > > > Maybe you ought to install a 7.1 version (of which the current patchlevel is
                            > > > 7.1.242)? See my "HowTo" page,
                            > > > http://users.skynet.be/antoine.mechelynck/vim/compunix.htm
                            > >
                            > >
                            > > I have a normal installation of vim-7.1.242 (all patches) and it's
                            > > crashing for me as well. I have the same version of vim on
                            > > 2 machines (one linux x66 and one linux x86_64) and it's only
                            > > crashing on the the x86_64 machine only.
                            > >
                            > > As soon as I type ":call search('\_s*a\_s*','e')" I get a core dump
                            > > on the x86_64 machine:
                            > >
                            > > $ ./vim
                            > > Vim: Caught deadly signal SEGV
                            > > Vim: preserving files...
                            > > Vim: Finished.
                            > > Segmentation fault (core dumped)
                            > >
                            > > $ gdb ./vim core
                            > > ...
                            > > Core was generated by `./vim'.
                            > > Program terminated with signal 11, Segmentation fault.
                            > > #0 0x00002b71866ebe47 in kill () from /lib64/libc.so.6
                            > > (gdb) bt
                            > > #0 0x00002b71866ebe47 in kill () from /lib64/libc.so.6
                            > > #1 0x000000000050e38d in may_core_dump () at os_unix.c:2950
                            > > #2 0x000000000050e328 in mch_exit (r=1) at os_unix.c:2915
                            > > #3 0x00000000004a5eb3 in getout (exitval=1) at main.c:1342
                            > > #4 0x00000000004d2128 in preserve_exit () at misc1.c:8355
                            > > #5 0x000000000050c73d in deathtrap (sigarg=11) at os_unix.c:1030
                            > > #6 <signal handler called>
                            > > #7 0x00000000004e0b33 in utf_head_off (base=0x9251c4 "c Y",
                            > > p=0x1009251c3 <Address 0x1009251c3 out of bounds>) at mbyte.c:2480
                            > > #8 0x0000000000539235 in searchit (win=0x831b90, buf=0x8333f0,
                            > > pos=0x7fff2690fa00, dir=1, pat=0x947c80 "\\_s*a\\_s*", count=1,
                            > > options=1088, pat_use=0, stop_lnum=0, tm=0x7fff2690f9e0) at search.c:848
                            > > #9 0x00000000004420e7 in search_cmn (argvars=0x7fff2690fbc0, match_pos=0x0,
                            > > flagsp=0x7fff2690fa8c) at eval.c:14077
                            > > #10 0x00000000004421cc in f_search (argvars=0x7fff2690fbc0,
                            > > rettv=0x7fff2690fd80) at eval.c:14120
                            > > #11 0x0000000000439522 in call_func (name=0x986920 "search", len=6,
                            > > rettv=0x7fff2690fd80, argcount=2, argvars=0x7fff2690fbc0, firstline=1,
                            > > lastline=1, doesrange=0x7fff2690fd7c, evaluate=1, selfdict=0x0)
                            > > at eval.c:7632
                            > > #12 0x0000000000439043 in get_func_tv (name=0x986920 "search", len=6,
                            > > rettv=0x7fff2690fd80, arg=0x7fff2690fda0, firstline=1, lastline=1,
                            > > doesrange=0x7fff2690fd7c, evaluate=1, selfdict=0x0) at eval.c:7450
                            > > #13 0x0000000000432c73 in ex_call (eap=0x7fff2690fe80) at eval.c:3215
                            > > #14 0x0000000000463c6b in do_one_cmd (cmdlinep=0x7fff26910528, sourcing=0,
                            > > cstack=0x7fff26910080, fgetline=0x47821a <getexline>, cookie=0x0)
                            > > at ex_docmd.c:2623
                            > > #15 0x000000000046146a in do_cmdline (cmdline=0x0,
                            > > getline=0x47821a <getexline>, cookie=0x0, flags=0) at ex_docmd.c:1099
                            > > #16 0x00000000004ebdd2 in nv_colon (cap=0x7fff26910670) at normal.c:5179
                            > > #17 0x00000000004e4dd8 in normal_cmd (oap=0x7fff26910730, toplevel=1)
                            > > at normal.c:1152
                            > > #18 0x00000000004a5be2 in main_loop (cmdwin=0, noexmode=0) at main.c:1181
                            > > #19 0x00000000004a572e in main (argc=1, argv=0x7fff26910a28) at main.c:940
                            > >
                            > > (gdb) up
                            > > #1 0x000000000050e38d in may_core_dump () at os_unix.c:2950
                            > > 2950 kill(getpid(), deadly_signal); /* Die using the
                            > > signal we caught */
                            > > (gdb)
                            > > #2 0x000000000050e328 in mch_exit (r=1) at os_unix.c:2915
                            > > 2915 may_core_dump();
                            > > (gdb)
                            > > #3 0x00000000004a5eb3 in getout (exitval=1) at main.c:1342
                            > > 1342 mch_exit(exitval);
                            > > (gdb)
                            > > #4 0x00000000004d2128 in preserve_exit () at misc1.c:8355
                            > > 8355 getout(1);
                            > > (gdb)
                            > > #5 0x000000000050c73d in deathtrap (sigarg=11) at os_unix.c:1030
                            > > 1030 preserve_exit(); /* preserve files and exit */
                            > > (gdb)
                            > > #6 <signal handler called>
                            > > (gdb)
                            > > #7 0x00000000004e0b33 in utf_head_off (base=0x9251c4 "c Y",
                            > > p=0x1009251c3 <Address 0x1009251c3 out of bounds>) at mbyte.c:2480
                            > > 2480 if (*p < 0x80) /* be quick for ASCII */
                            > > (gdb) p p
                            > > $1 = (char_u *) 0x1009251c3 <Address 0x1009251c3 out of bounds>
                            > >
                            > > -> pointer 'p' is invalid
                            > >
                            > > Valgrind memory checker also detects a problem when
                            > > doing ":call search('\_s*a\_s*','e')" at the same location
                            > > on the x86_64 machine (no problem detected on the
                            > > x86 machine):
                            > >
                            > > ==13671== Invalid read of size 1
                            > > ==13671== at 0x4E0B33: utf_head_off (mbyte.c:2480)
                            > > ==13671== by 0x539234: searchit (search.c:848)
                            > > ==13671== by 0x4420E6: search_cmn (eval.c:14077)
                            > > ==13671== by 0x4421CB: f_search (eval.c:14120)
                            > > ==13671== by 0x439521: call_func (eval.c:7632)
                            > > ==13671== by 0x439042: get_func_tv (eval.c:7450)
                            > > ==13671== by 0x432C72: ex_call (eval.c:3215)
                            > > ==13671== by 0x463C6A: do_one_cmd (ex_docmd.c:2623)
                            > > ==13671== by 0x461469: do_cmdline (ex_docmd.c:1099)
                            > > ==13671== by 0x4EBDD1: nv_colon (normal.c:5179)
                            > > ==13671== by 0x4E4DD7: normal_cmd (normal.c:1152)
                            > > ==13671== by 0x4A5BE1: main_loop (main.c:1181)
                            > > ==13671== by 0x4A572D: main (main.c:940)
                            > > ==13671== Address 0x10b5e697f is not stack'd, malloc'd or (recently) free'd
                            > >
                            > > I can reproduce it 100% of the time.
                            >
                            > What is the text you are searching in? I assume your 'encoding' is set
                            > to "utf-8"?


                            I'm doing the exact same thing as described in the first email
                            of this thread, i.e. the buffer contains only 2 lines, the cursor
                            is on first character X:

                            X a
                            c Y

                            Then I call...

                            :call search('\_s*a\_s*','e')

                            ... and it crashes as described on one machine (x86_64).
                            On the other machine (x86), it does not crash but cursor
                            moves to Y (which is not right either from initial bug submitter).

                            Encoding is utf-8 on both machines.

                            I've updated to latest vim-7.1.245 on both hosts with
                            same results (one works, the other one crashes).


                            > If you want to do a little digging, check out the code before calling
                            > mb_head_off(), line 848 in search.c. Especially the value of "endpos"
                            > compared to what's in the text.

                            I've put the following debug fprintf(stderr, ...) on line 848 before
                            call to (*mb_head_off)(...) (without changing line numbers in original
                            code):

                            fprintf(stderr, "%s:%d options=0x%x lnum=%ld endpos.lnum=%ld
                            endpos.col=%d pos->lnum=%ld pos->col=%d buf=%p
                            buf->b_ml.ml_line_count=%ld ptr=%p *ptr=%d\n", __FILE__, __LINE__,
                            options, lnum, endpos.lnum, endpos.col, pos->lnum, pos->col, buf,
                            buf->b_ml.ml_line_count, ptr, *ptr);

                            ... and the following fprintf(stderr, ...) in mbyte.c before
                            dereferencing p pointer at line mbyte.c:2480:

                            fprintf(stderr, "%s:%d p=%p\n", __FILE__, __LINE__, p);


                            On host where it does not crash I see:

                            search.c:848 options=0x440 lnum=1 endpos.lnum=1 endpos.col=0
                            pos->lnum=2 pos->col=-1 buf=0x81f3110 buf->b_ml.ml_line_count=2
                            ptr=0x82feca8 *ptr=99

                            mbyte.c:2479 p=0x82feca7


                            On host where it crashes, I see:

                            search.c:848 options=0x440 lnum=1 endpos.lnum=1 endpos.col=0
                            pos->lnum=2 pos->col=-1 buf=0x8333f0 buf->b_ml.ml_line_count=2
                            ptr=0x919a88 *ptr=99

                            mbyte.c:2479 p=0x100919a87


                            Ahh! I get it. Notice that pos->col is -1. When doing the pointer
                            arithmetics at line search.c:848 (ptr + pos->col) something goes terribly
                            wrong:

                            0x82feca8 + (-1) -> p=0x82feca7 ... and no crash (that's on the 32 bits Linux)
                            0x919a88 + (-1) -> 0x100919a87 ... and crash (that's on the 64 bits Linux)

                            It actually adds 4294967295 to the pointer, instead of removing -1.

                            type pos pos is:

                            typedef struct
                            {
                            linenr_T lnum; /* line number */
                            colnr_T col; /* column number */
                            } lpos_T;

                            and type of colnr_T is

                            typedef unsigned colnr_T;


                            Notice that it's unsigned. So that explains why it adds a large value to the
                            pointer instead of -1. On the 32 bits host, it works because pointer
                            wraps around 32 bits. On the 64 bits, pointer does not wrap on 32 bits
                            hence crash.

                            I can fix the crash by adding a cast as follows, but I think it's probably
                            wrong to have column 0 and remove 1 to it in the first place. This cast
                            is only masking the root cause of the problems:

                            diff -c -r1.64 search.c
                            *** search.c 26 Jan 2008 20:15:46 -0000 1.64
                            --- search.c 12 Feb 2008 09:13:21 -0000
                            ***************
                            *** 845,851 ****
                            ptr = (char_u *)"";
                            else
                            ptr = ml_get_buf(buf, pos->lnum, FALSE);
                            ! pos->col -= (*mb_head_off)(ptr, ptr + pos->col);
                            }
                            #endif
                            }
                            --- 845,851 ----
                            ptr = (char_u *)"";
                            else
                            ptr = ml_get_buf(buf, pos->lnum, FALSE);
                            ! pos->col -= (*mb_head_off)(ptr, ptr +
                            (int)pos->col);
                            }
                            #endif
                            }


                            -- Dominique

                            --~--~---------~--~----~------------~-------~--~----~
                            You received this message from the "vim_dev" maillist.
                            For more information, visit http://www.vim.org/maillist.php
                            -~----------~----~----~----~------~----~------~--~---
                          • Bram Moolenaar
                            ... Thanks for figuring this out. We probably need to avoid that pos- col is decremented below zero. I ll look into it. ... It s probably OK for the end
                            Message 13 of 15 , Feb 12, 2008
                              Dominique Pelle wrote:

                              > On Feb 11, 2008 10:28 PM, Bram Moolenaar <Bram@...> wrote:
                              > >
                              > > Dominique Pelle wrote:
                              > >
                              > > > On Feb 5, 2008 8:40 AM, Tony Mechelynck <antoine.mechelynck@...> wrote:
                              > > > >
                              > > > > Kazuo Teramoto wrote:
                              > > > > >> Same (start at X, stop at Y) for
                              > > > > >> :call search("^", "e")
                              > > > > >> :call search("^", "ce")
                              > > > > >
                              > > > > > Ouch, for me this is a little more serious, if I try this calls my vim
                              > > > > > always segfault (I don't need a test file and using -u NONE -U none),
                              > > > > > I don't know what need to be posted but the :version is
                              > > > > >
                              > > > > > VIM - Vi IMproved 7.0 (2006 May 7, compiled Aug 29 2007 10:59:43)
                              > > > > > Included patches: 1-122, 234-235, 39
                              > > > > > Big version without GUI. Features included (+) or not (-):
                              > > > >
                              > > > > ??? with patch 39 applied twice ??? none of 123-233 (a hundred and eleven
                              > > > > missing patches) ??? and no "compiled-by" line ??? Oh, and it's a 7.0 anyway.
                              > > > > Maybe you ought to install a 7.1 version (of which the current patchlevel is
                              > > > > 7.1.242)? See my "HowTo" page,
                              > > > > http://users.skynet.be/antoine.mechelynck/vim/compunix.htm
                              > > >
                              > > >
                              > > > I have a normal installation of vim-7.1.242 (all patches) and it's
                              > > > crashing for me as well. I have the same version of vim on
                              > > > 2 machines (one linux x66 and one linux x86_64) and it's only
                              > > > crashing on the the x86_64 machine only.
                              > > >
                              > > > As soon as I type ":call search('\_s*a\_s*','e')" I get a core dump
                              > > > on the x86_64 machine:
                              > > >
                              > > > $ ./vim
                              > > > Vim: Caught deadly signal SEGV
                              > > > Vim: preserving files...
                              > > > Vim: Finished.
                              > > > Segmentation fault (core dumped)
                              > > >
                              > > > $ gdb ./vim core
                              > > > ...
                              > > > Core was generated by `./vim'.
                              > > > Program terminated with signal 11, Segmentation fault.
                              > > > #0 0x00002b71866ebe47 in kill () from /lib64/libc.so.6
                              > > > (gdb) bt
                              > > > #0 0x00002b71866ebe47 in kill () from /lib64/libc.so.6
                              > > > #1 0x000000000050e38d in may_core_dump () at os_unix.c:2950
                              > > > #2 0x000000000050e328 in mch_exit (r=1) at os_unix.c:2915
                              > > > #3 0x00000000004a5eb3 in getout (exitval=1) at main.c:1342
                              > > > #4 0x00000000004d2128 in preserve_exit () at misc1.c:8355
                              > > > #5 0x000000000050c73d in deathtrap (sigarg=11) at os_unix.c:1030
                              > > > #6 <signal handler called>
                              > > > #7 0x00000000004e0b33 in utf_head_off (base=0x9251c4 "c Y",
                              > > > p=0x1009251c3 <Address 0x1009251c3 out of bounds>) at mbyte.c:2480
                              > > > #8 0x0000000000539235 in searchit (win=0x831b90, buf=0x8333f0,
                              > > > pos=0x7fff2690fa00, dir=1, pat=0x947c80 "\\_s*a\\_s*", count=1,
                              > > > options=1088, pat_use=0, stop_lnum=0, tm=0x7fff2690f9e0) at search.c:848
                              > > > #9 0x00000000004420e7 in search_cmn (argvars=0x7fff2690fbc0, match_pos=0x0,
                              > > > flagsp=0x7fff2690fa8c) at eval.c:14077
                              > > > #10 0x00000000004421cc in f_search (argvars=0x7fff2690fbc0,
                              > > > rettv=0x7fff2690fd80) at eval.c:14120
                              > > > #11 0x0000000000439522 in call_func (name=0x986920 "search", len=6,
                              > > > rettv=0x7fff2690fd80, argcount=2, argvars=0x7fff2690fbc0, firstline=1,
                              > > > lastline=1, doesrange=0x7fff2690fd7c, evaluate=1, selfdict=0x0)
                              > > > at eval.c:7632
                              > > > #12 0x0000000000439043 in get_func_tv (name=0x986920 "search", len=6,
                              > > > rettv=0x7fff2690fd80, arg=0x7fff2690fda0, firstline=1, lastline=1,
                              > > > doesrange=0x7fff2690fd7c, evaluate=1, selfdict=0x0) at eval.c:7450
                              > > > #13 0x0000000000432c73 in ex_call (eap=0x7fff2690fe80) at eval.c:3215
                              > > > #14 0x0000000000463c6b in do_one_cmd (cmdlinep=0x7fff26910528, sourcing=0,
                              > > > cstack=0x7fff26910080, fgetline=0x47821a <getexline>, cookie=0x0)
                              > > > at ex_docmd.c:2623
                              > > > #15 0x000000000046146a in do_cmdline (cmdline=0x0,
                              > > > getline=0x47821a <getexline>, cookie=0x0, flags=0) at ex_docmd.c:1099
                              > > > #16 0x00000000004ebdd2 in nv_colon (cap=0x7fff26910670) at normal.c:5179
                              > > > #17 0x00000000004e4dd8 in normal_cmd (oap=0x7fff26910730, toplevel=1)
                              > > > at normal.c:1152
                              > > > #18 0x00000000004a5be2 in main_loop (cmdwin=0, noexmode=0) at main.c:1181
                              > > > #19 0x00000000004a572e in main (argc=1, argv=0x7fff26910a28) at main.c:940
                              > > >
                              > > > (gdb) up
                              > > > #1 0x000000000050e38d in may_core_dump () at os_unix.c:2950
                              > > > 2950 kill(getpid(), deadly_signal); /* Die using the
                              > > > signal we caught */
                              > > > (gdb)
                              > > > #2 0x000000000050e328 in mch_exit (r=1) at os_unix.c:2915
                              > > > 2915 may_core_dump();
                              > > > (gdb)
                              > > > #3 0x00000000004a5eb3 in getout (exitval=1) at main.c:1342
                              > > > 1342 mch_exit(exitval);
                              > > > (gdb)
                              > > > #4 0x00000000004d2128 in preserve_exit () at misc1.c:8355
                              > > > 8355 getout(1);
                              > > > (gdb)
                              > > > #5 0x000000000050c73d in deathtrap (sigarg=11) at os_unix.c:1030
                              > > > 1030 preserve_exit(); /* preserve files and exit */
                              > > > (gdb)
                              > > > #6 <signal handler called>
                              > > > (gdb)
                              > > > #7 0x00000000004e0b33 in utf_head_off (base=0x9251c4 "c Y",
                              > > > p=0x1009251c3 <Address 0x1009251c3 out of bounds>) at mbyte.c:2480
                              > > > 2480 if (*p < 0x80) /* be quick for ASCII */
                              > > > (gdb) p p
                              > > > $1 = (char_u *) 0x1009251c3 <Address 0x1009251c3 out of bounds>
                              > > >
                              > > > -> pointer 'p' is invalid
                              > > >
                              > > > Valgrind memory checker also detects a problem when
                              > > > doing ":call search('\_s*a\_s*','e')" at the same location
                              > > > on the x86_64 machine (no problem detected on the
                              > > > x86 machine):
                              > > >
                              > > > ==13671== Invalid read of size 1
                              > > > ==13671== at 0x4E0B33: utf_head_off (mbyte.c:2480)
                              > > > ==13671== by 0x539234: searchit (search.c:848)
                              > > > ==13671== by 0x4420E6: search_cmn (eval.c:14077)
                              > > > ==13671== by 0x4421CB: f_search (eval.c:14120)
                              > > > ==13671== by 0x439521: call_func (eval.c:7632)
                              > > > ==13671== by 0x439042: get_func_tv (eval.c:7450)
                              > > > ==13671== by 0x432C72: ex_call (eval.c:3215)
                              > > > ==13671== by 0x463C6A: do_one_cmd (ex_docmd.c:2623)
                              > > > ==13671== by 0x461469: do_cmdline (ex_docmd.c:1099)
                              > > > ==13671== by 0x4EBDD1: nv_colon (normal.c:5179)
                              > > > ==13671== by 0x4E4DD7: normal_cmd (normal.c:1152)
                              > > > ==13671== by 0x4A5BE1: main_loop (main.c:1181)
                              > > > ==13671== by 0x4A572D: main (main.c:940)
                              > > > ==13671== Address 0x10b5e697f is not stack'd, malloc'd or (recently) free'd
                              > > >
                              > > > I can reproduce it 100% of the time.
                              > >
                              > > What is the text you are searching in? I assume your 'encoding' is set
                              > > to "utf-8"?
                              >
                              >
                              > I'm doing the exact same thing as described in the first email
                              > of this thread, i.e. the buffer contains only 2 lines, the cursor
                              > is on first character X:
                              >
                              > X a
                              > c Y
                              >
                              > Then I call...
                              >
                              > :call search('\_s*a\_s*','e')
                              >
                              > ... and it crashes as described on one machine (x86_64).
                              > On the other machine (x86), it does not crash but cursor
                              > moves to Y (which is not right either from initial bug submitter).
                              >
                              > Encoding is utf-8 on both machines.
                              >
                              > I've updated to latest vim-7.1.245 on both hosts with
                              > same results (one works, the other one crashes).
                              >
                              >
                              > > If you want to do a little digging, check out the code before calling
                              > > mb_head_off(), line 848 in search.c. Especially the value of "endpos"
                              > > compared to what's in the text.
                              >
                              > I've put the following debug fprintf(stderr, ...) on line 848 before
                              > call to (*mb_head_off)(...) (without changing line numbers in original
                              > code):
                              >
                              > fprintf(stderr, "%s:%d options=0x%x lnum=%ld endpos.lnum=%ld
                              > endpos.col=%d pos->lnum=%ld pos->col=%d buf=%p
                              > buf->b_ml.ml_line_count=%ld ptr=%p *ptr=%d\n", __FILE__, __LINE__,
                              > options, lnum, endpos.lnum, endpos.col, pos->lnum, pos->col, buf,
                              > buf->b_ml.ml_line_count, ptr, *ptr);
                              >
                              > ... and the following fprintf(stderr, ...) in mbyte.c before
                              > dereferencing p pointer at line mbyte.c:2480:
                              >
                              > fprintf(stderr, "%s:%d p=%p\n", __FILE__, __LINE__, p);
                              >
                              >
                              > On host where it does not crash I see:
                              >
                              > search.c:848 options=0x440 lnum=1 endpos.lnum=1 endpos.col=0
                              > pos->lnum=2 pos->col=-1 buf=0x81f3110 buf->b_ml.ml_line_count=2
                              > ptr=0x82feca8 *ptr=99
                              >
                              > mbyte.c:2479 p=0x82feca7
                              >
                              >
                              > On host where it crashes, I see:
                              >
                              > search.c:848 options=0x440 lnum=1 endpos.lnum=1 endpos.col=0
                              > pos->lnum=2 pos->col=-1 buf=0x8333f0 buf->b_ml.ml_line_count=2
                              > ptr=0x919a88 *ptr=99
                              >
                              > mbyte.c:2479 p=0x100919a87
                              >
                              >
                              > Ahh! I get it. Notice that pos->col is -1. When doing the pointer
                              > arithmetics at line search.c:848 (ptr + pos->col) something goes terribly
                              > wrong:
                              >
                              > 0x82feca8 + (-1) -> p=0x82feca7 ... and no crash (that's on the 32 bits Linux)
                              > 0x919a88 + (-1) -> 0x100919a87 ... and crash (that's on the 64 bits Linux)
                              >
                              > It actually adds 4294967295 to the pointer, instead of removing -1.
                              >
                              > type pos pos is:
                              >
                              > typedef struct
                              > {
                              > linenr_T lnum; /* line number */
                              > colnr_T col; /* column number */
                              > } lpos_T;
                              >
                              > and type of colnr_T is
                              >
                              > typedef unsigned colnr_T;
                              >
                              >
                              > Notice that it's unsigned. So that explains why it adds a large value to the
                              > pointer instead of -1. On the 32 bits host, it works because pointer
                              > wraps around 32 bits. On the 64 bits, pointer does not wrap on 32 bits
                              > hence crash.
                              >
                              > I can fix the crash by adding a cast as follows, but I think it's probably
                              > wrong to have column 0 and remove 1 to it in the first place. This cast
                              > is only masking the root cause of the problems:
                              >
                              > diff -c -r1.64 search.c
                              > *** search.c 26 Jan 2008 20:15:46 -0000 1.64
                              > --- search.c 12 Feb 2008 09:13:21 -0000
                              > ***************
                              > *** 845,851 ****
                              > ptr = (char_u *)"";
                              > else
                              > ptr = ml_get_buf(buf, pos->lnum, FALSE);
                              > ! pos->col -= (*mb_head_off)(ptr, ptr + pos->col);
                              > }
                              > #endif
                              > }
                              > --- 845,851 ----
                              > ptr = (char_u *)"";
                              > else
                              > ptr = ml_get_buf(buf, pos->lnum, FALSE);
                              > ! pos->col -= (*mb_head_off)(ptr, ptr +
                              > (int)pos->col);
                              > }
                              > #endif
                              > }
                              >
                              >
                              > -- Dominique

                              Thanks for figuring this out. We probably need to avoid that pos->col
                              is decremented below zero. I'll look into it.

                              > I should add that the endpos value was set at line search.c:623
                              > After line search.c:623, we have:
                              >
                              > matchpos=0,1 (line 0, col 1)
                              > endpos=1,0 (line 1, col 0).
                              >
                              > I don't think it's right to have col=0, is it?
                              >
                              > If so, that would mean it's a bug in vim_regexec_multi(...).

                              It's probably OK for the end position to be in column zero. It means
                              the match ends before the first column. Looks like this isn't handled
                              properly, since "col - 1" will be negative.

                              --
                              hundred-and-one symptoms of being an internet addict:
                              26. You check your mail. It says "no new messages." So you check it again.

                              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                              \\\ download, build and distribute -- http://www.A-A-P.org ///
                              \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                              --~--~---------~--~----~------------~-------~--~----~
                              You received this message from the "vim_dev" maillist.
                              For more information, visit http://www.vim.org/maillist.php
                              -~----------~----~----~----~------~----~------~--~---
                            Your message has been successfully submitted and would be delivered to recipients shortly.