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

Re: vim crash

Expand Messages
  • Bram Moolenaar
    ... This solution is bogus. ... Looking through the code I found one situation where it would read ... However, the valgrind log looks different from what you
    Message 1 of 14 , Feb 1, 2011
    • 0 Attachment
      Christian Brabandt wrote:

      > Hi John!
      >
      > On Di, 25 Jan 2011, John Beckett wrote:
      >
      > > Hoss wrote:
      > > > $ find . -mindepth 1 -maxdepth 1 -name '*.pm' | xargs sh -c
      > > > '/usr/ local/bin/vim -p "$@" </dev/tty'
      > > >
      > > > The find command has 60 hits. Now, if I just run this
      > > > command, it works fine, and I get 10 tabpages. I want each in
      > > > their own tabpage, so I put this in my .vimrc file
      > > >
      > > > set tpm`
      > > >
      > > > With that change, when I run the command, I get the following:
      > > >
      > > > Vim: Caught deadly signal SEGV
      > > > Vim: Finished
      > > > Segmentation fault
      > >
      > > Please try a simpler test. Does the following lead to a crash?
      >
      > I can reproduce this. The problem here is a custom 'tabline' setting and
      > this results in a crash in the build_stl_str_hl() function. I have a
      > rather complicated tabline-setting, that I picked up in vim-use I guess.
      > I never need it though (and in fact tend to forget about it ;))
      >
      > Here is a possible fix, that at least prevents the crash, but also
      > prevents drawing the statusline and tabline label. I must admit, I
      > haven't had time to investigate the build_stl_str_hl function in detail,
      > so I don't know the proper fix:
      > diff --git a/src/buffer.c b/src/buffer.c
      > --- a/src/buffer.c
      > +++ b/src/buffer.c
      > @@ -3465,9 +3465,9 @@
      > /*
      > * Handle up to the next '%' or the end.
      > */
      > - while (*s != NUL && *s != '%' && p + 1 < out + outlen)
      > + while (*s != NUL && *s != '%' && p + 1 < out + outlen && *p != NUL)
      > *p++ = *s++;
      > - if (*s == NUL || p + 1 >= out + outlen)
      > + if (*s == NUL || p + 1 >= out + outlen || *p == NUL)
      > break;
      >
      > /*
      > diff --git a/src/screen.c b/src/screen.c
      > --- a/src/screen.c
      > +++ b/src/screen.c
      > @@ -6429,7 +6429,7 @@
      > int n;
      > int len;
      > int fillchar;
      > - char_u buf[MAXPATHL];
      > + char_u buf[MAXPATHL] = "";
      > char_u *stl;
      > char_u *p;
      > struct stl_hlrec hltab[STL_MAX_ITEM];

      This solution is bogus.

      > Attached is:
      > valgrind.log when running the vim -N -i NONE --cmd 'set tpme' -p
      > /tmp/vim-crash/* (a directory containing about 60 files)
      > tabline.vim My custom tabline setting

      Looking through the code I found one situation where it would read
      uninitialized memory:
      :set stl=%!'asdf%'

      However, the valgrind log looks different from what you show. I suspect
      there is another problem. Or the same problem in another situation.
      Can you check with patch 7.3.112 if you can still reproduce the valgrind
      warning?


      --
      hundred-and-one symptoms of being an internet addict:
      178. You look for an icon to double-click to open your bedroom window.

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ an exciting new programming language -- http://www.Zimbu.org ///
      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php
    • Christian Brabandt
      Hi Bram! ... Yes, and I can still reproduce the crash with this crash.vim file: #v+ $ mkdir -p /tmp/vim-crash $ cd /tmp/vim-crash $ touch {1..65} $ cat
      Message 2 of 14 , Feb 2, 2011
      • 0 Attachment
        Hi Bram!

        On Di, 01 Feb 2011, Bram Moolenaar wrote:

        > Looking through the code I found one situation where it would read
        > uninitialized memory:
        > :set stl=%!'asdf%'
        >
        > However, the valgrind log looks different from what you show. I suspect
        > there is another problem. Or the same problem in another situation.
        > Can you check with patch 7.3.112 if you can still reproduce the valgrind
        > warning?

        Yes, and I can still reproduce the crash with this crash.vim file:


        #v+
        $ mkdir -p /tmp/vim-crash
        $ cd /tmp/vim-crash
        $ touch {1..65}
        $ cat crash.vim
        function! MyTabLine()
        let s = ''
        for i in range(tabpagenr('$'))
        let s .= '%#TabLine#'
        let s .= ' %{MyTabLabel(' . (i + 1) . ')} '
        endfor
        return s
        endfunction

        function! MyTabLabel(n)
        return a:n
        endfunction

        set tabline=%!MyTabLine()
        $ vim -u crash.vim --noplugin
        $ vim -u crash.vim --noplugin -N -i NONE --cmd ':set tpm=65' -p
        /tmp/vim-crash/*
        Vim: Caught deadly signal SEGV
        Vim: Finished.
        zsh: segmentation fault (core dumped) ./vim -u crash.vim --noplugin -N -i NONE
        --cmd ':set tpm=65' -p
        $
        #v-

        When running under valgrind I get this result:

        ==16470== Parent PID: 14306
        ==16470==
        ==16470== Invalid write of size 1
        ==16470== at 0x8057AAF: build_stl_str_hl (buffer.c:3470)
        ==16470== by 0x816A96B: win_redr_custom (screen.c:6527)
        ==16470== by 0x816F5DF: draw_tabline (screen.c:9709)
        ==16470== by 0x81605F9: update_screen (screen.c:465)
        ==16470== by 0x80E53CE: main_loop (main.c:1161)
        ==16470== by 0x80E5020: main (main.c:961)
        ==16470== Address 0x4 is not stack'd, malloc'd or (recently) free'd
        ==16470==
        ==16470==
        ==16470== HEAP SUMMARY:
        ==16470== in use at exit: 1,531,154 bytes in 5,006 blocks
        ==16470== total heap usage: 11,375 allocs, 6,369 frees, 10,783,506 bytes alloc+ated
        ==16470==
        ==16470== LEAK SUMMARY:
        ==16470== definitely lost: 83,800 bytes in 121 blocks
        ==16470== indirectly lost: 1,491 bytes in 70 blocks
        ==16470== possibly lost: 315 bytes in 8 blocks
        ==16470== still reachable: 1,445,548 bytes in 4,807 blocks
        ==16470== suppressed: 0 bytes in 0 blocks
        ==16470== Rerun with --leak-check=full to see details of leaked memory


        Problem is this line in buffer.c:
        3466 /*
        3467 * Handle up to the next '%' or the end.
        3468 */
        3469 while (*s != NUL && *s != '%' && p + 1 < out + outlen)
        3470 *p++ = *s++;

        so p runs out of memory.


        regards,
        Christian
        --

        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php
      • sc
        ... feeling adventurous, i tried this exact thing on my (suse linux 11.2) box and no bomb for me, just 66 tab pages with numbers for labels my vim is Big,
        Message 3 of 14 , Feb 2, 2011
        • 0 Attachment
          On Wednesday 02 February 2011 15:35:33 Christian Brabandt wrote:

          > Hi Bram!

          > On Di, 01 Feb 2011, Bram Moolenaar wrote:
          > > Looking through the code I found one situation where it
          > > would read
          > >
          > > uninitialized memory:
          > > :set stl=%!'asdf%'
          > >
          > > However, the valgrind log looks different from what you
          > > show. I suspect there is another problem. Or the same
          > > problem in another situation. Can you check with patch
          > > 7.3.112 if you can still reproduce the valgrind warning?

          > Yes, and I can still reproduce the crash with this crash.vim
          > file:


          > #v+
          > $ mkdir -p /tmp/vim-crash
          > $ cd /tmp/vim-crash
          > $ touch {1..65}
          > $ cat crash.vim
          > function! MyTabLine()
          > let s = ''
          > for i in range(tabpagenr('$'))
          > let s .= '%#TabLine#'
          > let s .= ' %{MyTabLabel(' . (i + 1) . ')} '
          > endfor
          > return s
          > endfunction

          > function! MyTabLabel(n)
          > return a:n
          > endfunction

          > set tabline=%!MyTabLine()
          > $ vim -u crash.vim --noplugin
          > $ vim -u crash.vim --noplugin -N -i NONE --cmd ':set tpm=65'
          > -p /tmp/vim-crash/*
          > Vim: Caught deadly signal SEGV
          > Vim: Finished.
          > zsh: segmentation fault (core dumped) ./vim -u crash.vim
          > --noplugin -N -i NONE --cmd ':set tpm=65' -p
          > $
          > #v-

          feeling adventurous, i tried this exact thing on my (suse
          linux 11.2) box and no bomb for me, just 66 tab pages with
          numbers for labels

          my vim is Big, 7.3.112, with GTK2 gui

          sc

          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php
        • Bram Moolenaar
          ... Weird, the check for out + outlen should avoid that. I ll look into it later. Unless someone else can make a fix. -- What is the difference between a
          Message 4 of 14 , Feb 3, 2011
          • 0 Attachment
            Christian Brabandt wrote:

            > On Di, 01 Feb 2011, Bram Moolenaar wrote:
            >
            > > Looking through the code I found one situation where it would read
            > > uninitialized memory:
            > > :set stl=%!'asdf%'
            > >
            > > However, the valgrind log looks different from what you show. I suspect
            > > there is another problem. Or the same problem in another situation.
            > > Can you check with patch 7.3.112 if you can still reproduce the valgrind
            > > warning?
            >
            > Yes, and I can still reproduce the crash with this crash.vim file:
            >
            >
            > #v+
            > $ mkdir -p /tmp/vim-crash
            > $ cd /tmp/vim-crash
            > $ touch {1..65}
            > $ cat crash.vim
            > function! MyTabLine()
            > let s = ''
            > for i in range(tabpagenr('$'))
            > let s .= '%#TabLine#'
            > let s .= ' %{MyTabLabel(' . (i + 1) . ')} '
            > endfor
            > return s
            > endfunction
            >
            > function! MyTabLabel(n)
            > return a:n
            > endfunction
            >
            > set tabline=%!MyTabLine()
            > $ vim -u crash.vim --noplugin
            > $ vim -u crash.vim --noplugin -N -i NONE --cmd ':set tpm=65' -p
            > /tmp/vim-crash/*
            > Vim: Caught deadly signal SEGV
            > Vim: Finished.
            > zsh: segmentation fault (core dumped) ./vim -u crash.vim --noplugin -N -i NONE
            > --cmd ':set tpm=65' -p
            > $
            > #v-
            >
            > When running under valgrind I get this result:
            >
            > ==16470== Parent PID: 14306
            > ==16470==
            > ==16470== Invalid write of size 1
            > ==16470== at 0x8057AAF: build_stl_str_hl (buffer.c:3470)
            > ==16470== by 0x816A96B: win_redr_custom (screen.c:6527)
            > ==16470== by 0x816F5DF: draw_tabline (screen.c:9709)
            > ==16470== by 0x81605F9: update_screen (screen.c:465)
            > ==16470== by 0x80E53CE: main_loop (main.c:1161)
            > ==16470== by 0x80E5020: main (main.c:961)
            > ==16470== Address 0x4 is not stack'd, malloc'd or (recently) free'd
            > ==16470==
            > ==16470==
            > ==16470== HEAP SUMMARY:
            > ==16470== in use at exit: 1,531,154 bytes in 5,006 blocks
            > ==16470== total heap usage: 11,375 allocs, 6,369 frees, 10,783,506 bytes alloc+ated
            > ==16470==
            > ==16470== LEAK SUMMARY:
            > ==16470== definitely lost: 83,800 bytes in 121 blocks
            > ==16470== indirectly lost: 1,491 bytes in 70 blocks
            > ==16470== possibly lost: 315 bytes in 8 blocks
            > ==16470== still reachable: 1,445,548 bytes in 4,807 blocks
            > ==16470== suppressed: 0 bytes in 0 blocks
            > ==16470== Rerun with --leak-check=full to see details of leaked memory
            >
            >
            > Problem is this line in buffer.c:
            > 3466 /*
            > 3467 * Handle up to the next '%' or the end.
            > 3468 */
            > 3469 while (*s != NUL && *s != '%' && p + 1 < out + outlen)
            > 3470 *p++ = *s++;
            >
            > so p runs out of memory.

            Weird, the check for "out + outlen" should avoid that. I'll look into
            it later. Unless someone else can make a fix.

            --
            What is the difference between a professional and an amateur?
            The ark was built by an amateur; professionals gave us the Titanic.

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ an exciting new programming language -- http://www.Zimbu.org ///
            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php
          • Bram Moolenaar
            ... [bogus fix] ... I can t reproduce it. The MyTabLine() function is missing. Also, you need to start vim with -u NONE to exclude all kinds of other
            Message 5 of 14 , Feb 9, 2011
            • 0 Attachment
              Christian Brabandt wrote:

              > I can reproduce this. The problem here is a custom 'tabline' setting and
              > this results in a crash in the build_stl_str_hl() function. I have a
              > rather complicated tabline-setting, that I picked up in vim-use I guess.
              > I never need it though (and in fact tend to forget about it ;))
              >
              > Here is a possible fix, that at least prevents the crash, but also
              > prevents drawing the statusline and tabline label. I must admit, I
              > haven't had time to investigate the build_stl_str_hl function in detail,
              > so I don't know the proper fix:

              [bogus fix]

              > Attached is:
              > valgrind.log when running the vim -N -i NONE --cmd 'set tpm=65' -p
              > /tmp/vim-crash/* (a directory containing about 60 files)
              > tabline.vim My custom tabline setting

              I can't reproduce it. The MyTabLine() function is missing. Also, you
              need to start vim with "-u NONE" to exclude all kinds of other stuff.

              And make sure you run the latest Vim, including patch 7.3.112.
              The line numbers in your valgrind output don't match my source, please
              quote the actual source lines.

              I also tried the instructions in your other message, didn't work either.

              --
              hundred-and-one symptoms of being an internet addict:
              217. Your sex life has drastically improved...so what if it's only cyber-sex!

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ an exciting new programming language -- http://www.Zimbu.org ///
              \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php
            • Christian Brabandt
              Hi Bram! ... Sorry, I don t know what is wrong then. All I do, I described in Message-ID: ... VIM - Vi IMproved 7.3 (2010
              Message 6 of 14 , Feb 9, 2011
              • 0 Attachment
                Hi Bram!

                On Mi, 09 Feb 2011, Bram Moolenaar wrote:

                > I can't reproduce it. The MyTabLine() function is missing. Also, you
                > need to start vim with "-u NONE" to exclude all kinds of other stuff.
                >
                > And make sure you run the latest Vim, including patch 7.3.112.
                > The line numbers in your valgrind output don't match my source, please
                > quote the actual source lines.
                >
                > I also tried the instructions in your other message, didn't work either.

                Sorry, I don't know what is wrong then. All I do, I described in
                Message-ID: <20110202213533.GC8951@...>
                I don't know how to provide more useful information than that:

                :version
                VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Feb 9 2011 19:14:18)
                Included patches: 1-118
                Compiled by chrisbra@r500vm
                Huge version with GTK2 GUI. Features included (+) or not (-):
                +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent
                +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
                +conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con_gui +diff
                +digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi
                +file_in_path +find_in_path +float +folding -footer +fork() +gettext
                -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall
                +linebreak +lispindent +listcmds +localmap -lua +menu +mksession +modify_fname
                +mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm
                -mouse_sysmouse +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg
                -osfiletype +path_extra -perl +persistent_undo +postscript +printer +profile
                -python -python3 +quickfix +reltime +rightleft -ruby +scrollbind +signs
                +smartindent -sniff +startuptime +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_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: "/home/chrisbra/local/share/vim"
                Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/
                include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include
                /cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/pixm
                an-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I
                /usr/lib/glib-2.0/include -g -O2 -D_FORTIFY_SOURCE=1
                Linking: gcc -L/usr/local/lib -Wl,--as-needed -o vim -pthread -lgtk-x11-2.0
                -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lc
                airo -lgio-2.0 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -
                lgthread-2.0 -lrt -lglib-2.0 -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -l
                m -lncurses -lnsl -lselinux -lacl -lattr -lgpm

                System:
                Linux r500vm 2.6.32-5-686 #1 SMP Fri Dec 10 16:12:40 UTC 2010 i686 GNU/Linux
                (Debian Squeeze in a vmware)

                gcc (Debian 4.4.5-8) 4.4.5
                Copyright (C) 2010 Free Software Foundation, Inc.
                This is free software; see the source for copying conditions. There is NO
                warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

                nterestingly, I get two different results, when running from gdb:
                1) when compiling with DEBUG:
                (gdb) bt
                #0 0x08057ccf in build_stl_str_hl (wp=0x8219808,
                out=0xbfffd8e0 " 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 abLabel("..., outlen=4096,
                fmt=0x8270c98 "%!MyTabLine()", use_sandbox=0, fillchar=32, maxwidth=80,
                hltab=0xbfffeb60, tabtab=0xbfffe8e0) at buffer.c:3470
                #1 0x08158f2c in win_redr_custom (wp=0x0, draw_ruler=<value optimized out>)
                at screen.c:6531
                #2 0x0815a51e in draw_tabline () at screen.c:9713
                #3 0x08166615 in update_screen (type=40) at screen.c:465
                #4 0x080e49f5 in main_loop (cmdwin=0, noexmode=0) at main.c:1161
                #5 0x080e7d75 in main (argc=75, argv=0xbffff174) at main.c:961


                2) when compiling without DEBUG:
                Program received signal SIGSEGV, Segmentation fault.
                build_stl_str_hl (wp=0x821a808,
                out=0xbfffd8e0 " 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 "..., outlen=4096,
                fmt=0x8271c98 "%!MyTabLine()", use_sandbox=0, fillchar=32, maxwidth=80,
                ---Type <return> to continue, or q <return> to quit---
                hltab=0xbfffeb60, tabtab=0xbfffe8e0) at buffer.c:3461
                3461 for (s = usefmt; *s; )
                (gdb) bt
                #0 build_stl_str_hl (wp=0x821a808,
                out=0xbfffd8e0 " 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 "..., outlen=4096,
                fmt=0x8271c98 "%!MyTabLine()", use_sandbox=0, fillchar=32, maxwidth=80,
                hltab=0xbfffeb60, tabtab=0xbfffe8e0) at buffer.c:3461
                #1 0x081590cc in win_redr_custom (wp=0x0, draw_ruler=<value optimized out>)
                at screen.c:6531
                #2 0x0815a6be in draw_tabline () at screen.c:9713
                #3 0x081667b5 in update_screen (type=40) at screen.c:465
                #4 0x080e4b95 in main_loop (cmdwin=0, noexmode=0) at main.c:1161
                #5 0x080e7f15 in main (argc=75, argv=0xbffff174) at main.c:961
                (gdb)

                But then again, I just don't understand gdb too well.

                regards,
                Christian

                --
                You received this message from the "vim_dev" maillist.
                Do not top-post! Type your reply below the text you are replying to.
                For more information, visit http://www.vim.org/maillist.php
              • Bram Moolenaar
                ... It s certainly worth learning some gdb commands. Use the print command to find out the value of usefmt . It appears that s is invalid, goes over the
                Message 7 of 14 , Feb 9, 2011
                • 0 Attachment
                  Christian Brabandt wrote:

                  > On Mi, 09 Feb 2011, Bram Moolenaar wrote:
                  >
                  > > I can't reproduce it. The MyTabLine() function is missing. Also, you
                  > > need to start vim with "-u NONE" to exclude all kinds of other stuff.
                  > >
                  > > And make sure you run the latest Vim, including patch 7.3.112.
                  > > The line numbers in your valgrind output don't match my source, please
                  > > quote the actual source lines.
                  > >
                  > > I also tried the instructions in your other message, didn't work either.
                  >
                  > Sorry, I don't know what is wrong then. All I do, I described in
                  > Message-ID: <20110202213533.GC8951@...>
                  > I don't know how to provide more useful information than that:
                  >
                  > :version
                  > VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Feb 9 2011 19:14:18)
                  > Included patches: 1-118
                  > Compiled by chrisbra@r500vm
                  > Huge version with GTK2 GUI. Features included (+) or not (-):
                  > +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent
                  > +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
                  > +conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con_gui +diff
                  > +digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi
                  > +file_in_path +find_in_path +float +folding -footer +fork() +gettext
                  > -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall
                  > +linebreak +lispindent +listcmds +localmap -lua +menu +mksession +modify_fname
                  > +mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm
                  > -mouse_sysmouse +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg
                  > -osfiletype +path_extra -perl +persistent_undo +postscript +printer +profile
                  > -python -python3 +quickfix +reltime +rightleft -ruby +scrollbind +signs
                  > +smartindent -sniff +startuptime +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_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: "/home/chrisbra/local/share/vim"
                  > Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/
                  > include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include
                  > /cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/pixm
                  > an-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I
                  > /usr/lib/glib-2.0/include -g -O2 -D_FORTIFY_SOURCE=1
                  > Linking: gcc -L/usr/local/lib -Wl,--as-needed -o vim -pthread -lgtk-x11-2.0
                  > -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lc
                  > airo -lgio-2.0 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -
                  > lgthread-2.0 -lrt -lglib-2.0 -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -l
                  > m -lncurses -lnsl -lselinux -lacl -lattr -lgpm
                  >
                  > System:
                  > Linux r500vm 2.6.32-5-686 #1 SMP Fri Dec 10 16:12:40 UTC 2010 i686 GNU/Linux
                  > (Debian Squeeze in a vmware)
                  >
                  > gcc (Debian 4.4.5-8) 4.4.5
                  > Copyright (C) 2010 Free Software Foundation, Inc.
                  > This is free software; see the source for copying conditions. There is NO
                  > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
                  >
                  > nterestingly, I get two different results, when running from gdb:
                  > 1) when compiling with DEBUG:
                  > (gdb) bt
                  > #0 0x08057ccf in build_stl_str_hl (wp=0x8219808,
                  > out=0xbfffd8e0 " 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 abLabel("..., outlen=4096,
                  > fmt=0x8270c98 "%!MyTabLine()", use_sandbox=0, fillchar=32, maxwidth=80,
                  > hltab=0xbfffeb60, tabtab=0xbfffe8e0) at buffer.c:3470
                  > #1 0x08158f2c in win_redr_custom (wp=0x0, draw_ruler=<value optimized out>)
                  > at screen.c:6531
                  > #2 0x0815a51e in draw_tabline () at screen.c:9713
                  > #3 0x08166615 in update_screen (type=40) at screen.c:465
                  > #4 0x080e49f5 in main_loop (cmdwin=0, noexmode=0) at main.c:1161
                  > #5 0x080e7d75 in main (argc=75, argv=0xbffff174) at main.c:961
                  >
                  >
                  > 2) when compiling without DEBUG:
                  > Program received signal SIGSEGV, Segmentation fault.
                  > build_stl_str_hl (wp=0x821a808,
                  > out=0xbfffd8e0 " 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 "..., outlen=4096,
                  > fmt=0x8271c98 "%!MyTabLine()", use_sandbox=0, fillchar=32, maxwidth=80,
                  > ---Type <return> to continue, or q <return> to quit---
                  > hltab=0xbfffeb60, tabtab=0xbfffe8e0) at buffer.c:3461
                  > 3461 for (s = usefmt; *s; )
                  > (gdb) bt
                  > #0 build_stl_str_hl (wp=0x821a808,
                  > out=0xbfffd8e0 " 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 "..., outlen=4096,
                  > fmt=0x8271c98 "%!MyTabLine()", use_sandbox=0, fillchar=32, maxwidth=80,
                  > hltab=0xbfffeb60, tabtab=0xbfffe8e0) at buffer.c:3461
                  > #1 0x081590cc in win_redr_custom (wp=0x0, draw_ruler=<value optimized out>)
                  > at screen.c:6531
                  > #2 0x0815a6be in draw_tabline () at screen.c:9713
                  > #3 0x081667b5 in update_screen (type=40) at screen.c:465
                  > #4 0x080e4b95 in main_loop (cmdwin=0, noexmode=0) at main.c:1161
                  > #5 0x080e7f15 in main (argc=75, argv=0xbffff174) at main.c:961
                  > (gdb)
                  >
                  > But then again, I just don't understand gdb too well.

                  It's certainly worth learning some gdb commands.

                  Use the "print" command to find out the value of "usefmt". It appears
                  that "s" is invalid, goes over the end of the format.

                  You can also put a breakpoint in build_stl_str_hl() and step through it
                  to see what's going on. Use "next" to step over a function call.

                  --
                  Your fault: core dumped

                  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                  /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                  \\\ an exciting new programming language -- http://www.Zimbu.org ///
                  \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                  --
                  You received this message from the "vim_dev" maillist.
                  Do not top-post! Type your reply below the text you are replying to.
                  For more information, visit http://www.vim.org/maillist.php
                • Christian Brabandt
                  Hi Bram! ... That part, I already knew. But that are many steps, when stepping through it. Oh well, tomorrow evening I have some time to train my gdb skills ;)
                  Message 8 of 14 , Feb 9, 2011
                  • 0 Attachment
                    Hi Bram!

                    On Mi, 09 Feb 2011, Bram Moolenaar wrote:

                    >
                    > Christian Brabandt wrote:
                    >
                    > > On Mi, 09 Feb 2011, Bram Moolenaar wrote:
                    > >
                    > > > I can't reproduce it. The MyTabLine() function is missing. Also, you
                    > > > need to start vim with "-u NONE" to exclude all kinds of other stuff.
                    > > >
                    > > > And make sure you run the latest Vim, including patch 7.3.112.
                    > > > The line numbers in your valgrind output don't match my source, please
                    > > > quote the actual source lines.
                    > > >
                    > > > I also tried the instructions in your other message, didn't work either.
                    > >
                    > > Sorry, I don't know what is wrong then. All I do, I described in
                    > > Message-ID: <20110202213533.GC8951@...>
                    > > I don't know how to provide more useful information than that:
                    > >
                    > > :version
                    > > VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Feb 9 2011 19:14:18)
                    > > Included patches: 1-118
                    > > Compiled by chrisbra@r500vm
                    > > Huge version with GTK2 GUI. Features included (+) or not (-):
                    > > +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent
                    > > +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
                    > > +conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con_gui +diff
                    > > +digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi
                    > > +file_in_path +find_in_path +float +folding -footer +fork() +gettext
                    > > -hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall
                    > > +linebreak +lispindent +listcmds +localmap -lua +menu +mksession +modify_fname
                    > > +mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm
                    > > -mouse_sysmouse +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg
                    > > -osfiletype +path_extra -perl +persistent_undo +postscript +printer +profile
                    > > -python -python3 +quickfix +reltime +rightleft -ruby +scrollbind +signs
                    > > +smartindent -sniff +startuptime +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_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: "/home/chrisbra/local/share/vim"
                    > > Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/
                    > > include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include
                    > > /cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/pixm
                    > > an-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I
                    > > /usr/lib/glib-2.0/include -g -O2 -D_FORTIFY_SOURCE=1
                    > > Linking: gcc -L/usr/local/lib -Wl,--as-needed -o vim -pthread -lgtk-x11-2.0
                    > > -lgdk-x11-2.0 -latk-1.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lc
                    > > airo -lgio-2.0 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -
                    > > lgthread-2.0 -lrt -lglib-2.0 -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -l
                    > > m -lncurses -lnsl -lselinux -lacl -lattr -lgpm
                    > >
                    > > System:
                    > > Linux r500vm 2.6.32-5-686 #1 SMP Fri Dec 10 16:12:40 UTC 2010 i686 GNU/Linux
                    > > (Debian Squeeze in a vmware)
                    > >
                    > > gcc (Debian 4.4.5-8) 4.4.5
                    > > Copyright (C) 2010 Free Software Foundation, Inc.
                    > > This is free software; see the source for copying conditions. There is NO
                    > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
                    > >
                    > > nterestingly, I get two different results, when running from gdb:
                    > > 1) when compiling with DEBUG:
                    > > (gdb) bt
                    > > #0 0x08057ccf in build_stl_str_hl (wp=0x8219808,
                    > > out=0xbfffd8e0 " 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 abLabel("..., outlen=4096,
                    > > fmt=0x8270c98 "%!MyTabLine()", use_sandbox=0, fillchar=32, maxwidth=80,
                    > > hltab=0xbfffeb60, tabtab=0xbfffe8e0) at buffer.c:3470
                    > > #1 0x08158f2c in win_redr_custom (wp=0x0, draw_ruler=<value optimized out>)
                    > > at screen.c:6531
                    > > #2 0x0815a51e in draw_tabline () at screen.c:9713
                    > > #3 0x08166615 in update_screen (type=40) at screen.c:465
                    > > #4 0x080e49f5 in main_loop (cmdwin=0, noexmode=0) at main.c:1161
                    > > #5 0x080e7d75 in main (argc=75, argv=0xbffff174) at main.c:961
                    > >
                    > >
                    > > 2) when compiling without DEBUG:
                    > > Program received signal SIGSEGV, Segmentation fault.
                    > > build_stl_str_hl (wp=0x821a808,
                    > > out=0xbfffd8e0 " 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 "..., outlen=4096,
                    > > fmt=0x8271c98 "%!MyTabLine()", use_sandbox=0, fillchar=32, maxwidth=80,
                    > > ---Type <return> to continue, or q <return> to quit---
                    > > hltab=0xbfffeb60, tabtab=0xbfffe8e0) at buffer.c:3461
                    > > 3461 for (s = usefmt; *s; )
                    > > (gdb) bt
                    > > #0 build_stl_str_hl (wp=0x821a808,
                    > > out=0xbfffd8e0 " 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 "..., outlen=4096,
                    > > fmt=0x8271c98 "%!MyTabLine()", use_sandbox=0, fillchar=32, maxwidth=80,
                    > > hltab=0xbfffeb60, tabtab=0xbfffe8e0) at buffer.c:3461
                    > > #1 0x081590cc in win_redr_custom (wp=0x0, draw_ruler=<value optimized out>)
                    > > at screen.c:6531
                    > > #2 0x0815a6be in draw_tabline () at screen.c:9713
                    > > #3 0x081667b5 in update_screen (type=40) at screen.c:465
                    > > #4 0x080e4b95 in main_loop (cmdwin=0, noexmode=0) at main.c:1161
                    > > #5 0x080e7f15 in main (argc=75, argv=0xbffff174) at main.c:961
                    > > (gdb)
                    > >
                    > > But then again, I just don't understand gdb too well.
                    >
                    > It's certainly worth learning some gdb commands.
                    >
                    > Use the "print" command to find out the value of "usefmt". It appears
                    > that "s" is invalid, goes over the end of the format.
                    >
                    > You can also put a breakpoint in build_stl_str_hl() and step through it
                    > to see what's going on. Use "next" to step over a function call.

                    That part, I already knew. But that are many steps, when stepping
                    through it. Oh well, tomorrow evening I have some time to train my gdb
                    skills ;)

                    regards,
                    Christian
                    --
                    Alte Leute sind gefährlich: Sie haben keine Angst mehr vor der
                    Zukunft (o. es ist ihnen völlig egal, was aus der Welt wird).
                    -- George Bernhard Shaw

                    --
                    You received this message from the "vim_dev" maillist.
                    Do not top-post! Type your reply below the text you are replying to.
                    For more information, visit http://www.vim.org/maillist.php
                  Your message has been successfully submitted and would be delivered to recipients shortly.