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

A fatal error about regex in version 6.3

Expand Messages
  • slimzhao
    ***1*** ***2*** ... As you see, what I want to do is to transform the above 3 lines to 1,2,3. Course, there s more than one way to do it in vim. But the above
    Message 1 of 7 , Nov 18, 2004
    • 0 Attachment
      ***1***
      ***2***
      ***3***

      :%s/\_[^0-9]*/,/g


      As you see, what I want to do is to transform the above 3 lines to
      1,2,3. Course, there's more than one way to do it in vim. But the above
      solution leads to a fatal error:
      ====================
      vim: gvim 6.3
      OS: win2000 simplified chinese
      Result: memory access violate, click OK will close gvim
      ====================

      ====================
      vim: vim 6.3
      OS: Linux(RH 9.0)
      Result:
      Vim: Caught deadly signal SEGV
      Vim: preserving files...
      terminal then freezed. <C-D> <C-Q> <C-\> <C-Z> all result in no reponse.
      ====================
    • Walter Briscoe
      In message of Fri, 19 Nov 2004 15:44:24 in , slimzhao writes ... My reading of help _ suggests
      Message 2 of 7 , Nov 19, 2004
      • 0 Attachment
        In message <004701c4ce0b$98fe9600$ab00a8c0@zhao> of Fri, 19 Nov 2004
        15:44:24 in , slimzhao <slimzhao2004@...> writes
        >***1***
        >***2***
        >***3***
        >
        >:%s/\_[^0-9]*/,/g
        >
        >
        >As you see, what I want to do is to transform the above 3 lines to
        >1,2,3. Course, there's more than one way to do it in vim. But the above
        >solution leads to a fatal error:

        My reading of "help \_" suggests your regular expression is badly
        formed. I find "any of the characters above" ambiguous in:
        \_x Where "x" is any of the characters above: The character class with
        end-of-line added
        I think "x" should include bracket expressions ([list]).

        However, I thing the following is legal and has the same problem
        :%s/\_D*/,/g as it matches an infinite number of times.
        The problem also happens with an empty buffer.

        :%s/\_D\{1,\}/,/g results in ,1,2,3, which is nearly what you intend.

        I ran in a debug version built with Visual C++ on W2K.
        The failure was due to a dynamic memory corruption detected by free() in
        do_sub(). I imagine Bram should easily be able to complete the analysis
        and comment on what I say above.
        --
        Walter Briscoe
      • Bram Moolenaar
        ... I can t reproduce this. Do you perhaps have encoding set to something? -- Q: How does a UNIX Guru pick up a girl? A: look; grep; which; eval; nice;
        Message 3 of 7 , Nov 19, 2004
        • 0 Attachment
          slimzhao wrote:

          > ***1***
          > ***2***
          > ***3***
          >
          > :%s/\_[^0-9]*/,/g
          >
          >
          > As you see, what I want to do is to transform the above 3 lines to
          > 1,2,3. Course, there's more than one way to do it in vim. But the above
          > solution leads to a fatal error:
          > ====================
          > vim: gvim 6.3
          > OS: win2000 simplified chinese
          > Result: memory access violate, click OK will close gvim
          > ====================
          >
          > ====================
          > vim: vim 6.3
          > OS: Linux(RH 9.0)
          > Result:
          > Vim: Caught deadly signal SEGV
          > Vim: preserving files...
          > terminal then freezed. <C-D> <C-Q> <C-\> <C-Z> all result in no reponse.
          > ====================

          I can't reproduce this. Do you perhaps have 'encoding' set to
          something?

          --
          Q: How does a UNIX Guru pick up a girl?
          A: look; grep; which; eval; nice; uname; talk; date;

          /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
          /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
          \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
          \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
        • Tofer Chagnon
          ... [snip] ... Using a slightly different regex I can see something going on, but the behavior seems to depend very much on the program state. I m using Win32
          Message 4 of 7 , Nov 19, 2004
          • 0 Attachment
            On Fri, 19 Nov 2004 10:37:50 +0100, Bram Moolenaar <bram@...> wrote:
            >
            > slimzhao wrote:
            >
            > > ***1***
            > > ***2***
            > > ***3***
            > >
            > > :%s/\_[^0-9]*/,/g

            [snip]

            >
            > I can't reproduce this. Do you perhaps have 'encoding' set to
            > something?
            >

            Using a slightly different regex I can see something going on, but the
            behavior seems to depend very much on the program state.

            I'm using Win32 Gvim 6.3 on WinXP, as compiled by you on 6/7/2004.

            I'm using a test buffer containing just what shimzhao wrote.

            My :s/// command is :%s/\_D*/,/g

            Exact results seem to depend not just on settings, but what I've done
            in the session prior to the :s/// command, (eg cursor location). I've
            seen all of the following:

            - E341: Internal error: lalloc(0, )
            - E342: Out of memory! (allocating 4294967xxx bytes)
            - Immediate crash

            In an attempt to get an exact repro, I created a test file, and used
            the following in a Run box:

            gvim -u NONE -U NONE +"%s/\_D*/,/g" c:\temp\regextest.txt

            This consistently gives the E342.

            HTH,

            Tofer
          • William Natter
            ... I reproduced this on Linux RH 8.0 as well: wnatter 1681) vim -u NONE -U NONE + %s/ _D*/,/g ~/tmp/check Vim: Caught deadly signal SEGV Vim: Finished.
            Message 5 of 7 , Nov 19, 2004
            • 0 Attachment
              Tofer Chagnon wrote:

              >On Fri, 19 Nov 2004 10:37:50 +0100, Bram Moolenaar <bram@...> wrote:
              >
              >
              >>slimzhao wrote:
              >>
              >>
              >>
              >>>***1***
              >>>***2***
              >>>***3***
              >>>
              >>>:%s/\_[^0-9]*/,/g
              >>>
              >>>
              >
              >[snip]
              >
              >
              >
              >>I can't reproduce this. Do you perhaps have 'encoding' set to
              >>something?
              >>
              >>
              >>
              >
              >Using a slightly different regex I can see something going on, but the
              >behavior seems to depend very much on the program state.
              >
              >I'm using Win32 Gvim 6.3 on WinXP, as compiled by you on 6/7/2004.
              >
              >I'm using a test buffer containing just what shimzhao wrote.
              >
              >My :s/// command is :%s/\_D*/,/g
              >
              >Exact results seem to depend not just on settings, but what I've done
              >in the session prior to the :s/// command, (eg cursor location). I've
              >seen all of the following:
              >
              >- E341: Internal error: lalloc(0, )
              >- E342: Out of memory! (allocating 4294967xxx bytes)
              >- Immediate crash
              >
              >In an attempt to get an exact repro, I created a test file, and used
              >the following in a Run box:
              >
              >gvim -u NONE -U NONE +"%s/\_D*/,/g" c:\temp\regextest.txt
              >
              >This consistently gives the E342.
              >
              >HTH,
              >
              >Tofer
              >
              >
              >
              >
              I reproduced this on Linux RH 8.0 as well:

              wnatter 1681) vim -u NONE -U NONE +'%s/\_D*/,/g' ~/tmp/check
              Vim: Caught deadly signal SEGV

              Vim: Finished.
              Segmentation fault (core dumped)

              wnatter 1683) gdb vim core.16099
              GNU gdb Red Hat Linux (5.2.1-4)
              Copyright 2002 Free Software Foundation, Inc.
              ...
              (gdb) bt
              #0 0x42028cc1 in kill () from /lib/i686/libc.so.6
              #1 0x080f5cd5 in mch_exit ()
              #2 0x080f5c7f in mch_exit ()
              #3 0x080d17d6 in preserve_exit ()
              #4 0x080f4679 in mch_didjmp ()
              #5 <signal handler called>
              #6 0x42073b0c in _int_malloc () from /lib/i686/libc.so.6
              #7 0x42073155 in malloc () from /lib/i686/libc.so.6
              #8 0x080d2b89 in lalloc ()
              #9 0x080d2b08 in alloc_check ()
              #10 0x080882d0 in do_sub ()
              #11 0x08093b86 in getline_cookie ()
              #12 0x080921c7 in do_cmdline ()
              #13 0x08091dfc in do_cmdline_cmd ()
              #14 0x080b77c9 in main ()
              #15 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
              ...

              wnatter 1684) vim --version
              VIM - Vi IMproved 6.3 (2004 June 7, compiled Oct 19 2004 12:29:39)
              Included patches: 1-7
              Compiled by wnatter@...
              Normal version with GTK 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 +dialog_con_gui +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 +netbeans_intg
              -osfiletype
              +path_extra -perl +postscript +printer -python +quickfix -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 +vimshell
              +virtualedit
              +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows
              +writebackup +X11 -xfontset +xim +xsmp_interact +xterm_clipboard
              -xterm_save
              system vimrc file: "$VIM/vimrc"
              user vimrc file: "$HOME/.vimrc"
              user exrc file: "$HOME/.exrc"
              system gvimrc file: "$VIM/gvimrc"
              user gvimrc file: "$HOME/.gvimrc"
              system menu file: "$VIMRUNTIME/menu.vim"
              fall-back for $VIM: "/localdisk/data/vim/share/vim"
              Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK
              -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include
              -I/usr/X11R6/include -g -O2 -fno-strength-reduce
              -I/usr/X11R6/include
              Linking: gcc -L/usr/X11R6/lib -L/usr/local/lib -o vim -L/usr/lib
              -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -lXi -lXext -lm
              -lXt -lncurses -lacl -lgpm -lutil

              wnatter 1685) uname -a
              Linux wcary1h5.ca.nortel.com 2.4.20-24.8 #1 Mon Dec 1 13:38:19 EST 2003
              i686 i686 i386 GNU/Linux

              William
            • Bram Moolenaar
              ... I tried this on my FreeBSD system, using efence, but didn t see the problem. I do see it on Win32 with Vim 6.3. But running Vim 7.0aa in a debugger
              Message 6 of 7 , Nov 19, 2004
              • 0 Attachment
                Tofer Chagnon wrote:

                > On Fri, 19 Nov 2004 10:37:50 +0100, Bram Moolenaar <bram@...> wrote:
                > >
                > > slimzhao wrote:
                > >
                > > > ***1***
                > > > ***2***
                > > > ***3***
                > > >
                > > > :%s/\_[^0-9]*/,/g
                >
                > [snip]
                >
                > > I can't reproduce this. Do you perhaps have 'encoding' set to
                > > something?
                >
                > Using a slightly different regex I can see something going on, but the
                > behavior seems to depend very much on the program state.
                >
                > I'm using Win32 Gvim 6.3 on WinXP, as compiled by you on 6/7/2004.
                >
                > I'm using a test buffer containing just what shimzhao wrote.
                >
                > My :s/// command is :%s/\_D*/,/g
                >
                > Exact results seem to depend not just on settings, but what I've done
                > in the session prior to the :s/// command, (eg cursor location). I've
                > seen all of the following:
                >
                > - E341: Internal error: lalloc(0, )
                > - E342: Out of memory! (allocating 4294967xxx bytes)
                > - Immediate crash

                I tried this on my FreeBSD system, using efence, but didn't see the
                problem. I do see it on Win32 with Vim 6.3. But running Vim 7.0aa in a
                debugger doesn't...

                I'm quite sure patch 6.3.012 already solves this problem.

                --
                f y cn rd ths thn y cn hv grt jb n cmptr prgrmmng

                /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
              • Tofer Chagnon
                ... My apologies for not trying it with a more patched version. Everything does seem hunky-dory with my 6.3.31 Win32 build. -- whr cn i gt ths jb?
                Message 7 of 7 , Nov 19, 2004
                • 0 Attachment
                  On Fri, 19 Nov 2004 18:48:16 +0100, Bram Moolenaar <bram@...> wrote:
                  >
                  > Tofer Chagnon wrote:
                  >
                  > >
                  > > Exact results seem to depend not just on settings, but what I've done
                  > > in the session prior to the :s/// command, (eg cursor location). I've
                  > > seen all of the following:
                  > >
                  > > - E341: Internal error: lalloc(0, )
                  > > - E342: Out of memory! (allocating 4294967xxx bytes)
                  > > - Immediate crash
                  >
                  > I tried this on my FreeBSD system, using efence, but didn't see the
                  > problem. I do see it on Win32 with Vim 6.3. But running Vim 7.0aa in a
                  > debugger doesn't...
                  >
                  > I'm quite sure patch 6.3.012 already solves this problem.
                  >
                  > --
                  > f y cn rd ths thn y cn hv grt jb n cmptr prgrmmng
                  >

                  My apologies for not trying it with a more patched version.
                  Everything does seem hunky-dory with my 6.3.31 Win32 build.

                  --
                  whr cn i gt ths jb?
                Your message has been successfully submitted and would be delivered to recipients shortly.