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

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

Expand Messages
  • ap
    Hi , I think I found a bug in the search() function. X marks the spot (cursor). X a c Y ... It seems that search() skips a character under this
    Message 1 of 15 , Feb 4, 2008
    • 0 Attachment
      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

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Andy Wokula
      ... Same (start at X, stop at Y) for ... -- Andy --~--~---------~--~----~------------~-------~--~----~ You received this message from the vim_dev maillist.
      Message 2 of 15 , Feb 4, 2008
      • 0 Attachment
        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

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Kazuo Teramoto
        ... For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
        Message 3 of 15 , Feb 4, 2008
        • 0 Attachment
          > 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 4 of 15 , Feb 4, 2008
          • 0 Attachment
            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 5 of 15 , Feb 5, 2008
            • 0 Attachment
              >> 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 6 of 15 , Feb 5, 2008
              • 0 Attachment
                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 7 of 15 , Feb 7, 2008
                • 0 Attachment
                  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 8 of 15 , Feb 7, 2008
                  • 0 Attachment
                    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 9 of 15 , Feb 8, 2008
                    • 0 Attachment
                      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 10 of 15 , Feb 8, 2008
                      • 0 Attachment
                        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 11 of 15 , Feb 8, 2008
                        • 0 Attachment
                          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 12 of 15 , Feb 11, 2008
                          • 0 Attachment
                            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 13 of 15 , Feb 11, 2008
                            • 0 Attachment
                              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 14 of 15 , Feb 12, 2008
                              • 0 Attachment
                                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 15 of 15 , Feb 12, 2008
                                • 0 Attachment
                                  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.