Bram Moolenaar wrote:

> Dominique Pelle wrote:
>
>> >> I can reproduce a bug (use of freed memory) in Vim-7.2.284
>> >> on Linux x86 as follows:
>> >>
>> >> 1/ Start vim with valgrind:
>> >>
>> >>   $ cd vim7/src
>> >>   $ valgrind --leak-check=yes \
>> >>              --num-callers=50 ./vim --noplugin -u NONE 2> vg.log
>> >>
>> >> 2/ Enter the 2 following Ex commands:
>> >>
>> >>   :redir @"
>> >>   :reg
>> >>
>> >> 3/ Observe in vg.log the following errors as soon as :reg is being
>> >> executed:
>> >>
>> >> ==13408== Invalid read of size 1
>> >> ==13408==    at 0x40276F8: memmove (mc_replace_strmem.c:517)
>> >> ==13408==    by 0x813CDA1: str_to_reg (ops.c:6157)
>> >> ==13408==    by 0x813CB6F: write_reg_contents_ex (ops.c:6052)
>> >> ==13408==    by 0x813C9E1: write_reg_contents (ops.c:5981)
>> >> ==13408==    by 0x8104C0E: redir_write (message.c:3046)
>> >> ==13408==    by 0x8103034: msg_puts_attr_len (message.c:1803)
>> >> ==13408==    by 0x8102715: msg_outtrans_len_attr (message.c:1402)
>> >> ==13408==    by 0x810243D: msg_outtrans_len (message.c:1291)
>> >> ==13408==    by 0x81398A3: ex_display (ops.c:4013)
>> >> ==13408==    by 0x80A7548: do_one_cmd (ex_docmd.c:2627)
>> >> ==13408==    by 0x80A4D7F: do_cmdline (ex_docmd.c:1096)
>> >> ==13408==    by 0x8090CB8: call_user_func (eval.c:21292)
>> >> ==13408==    by 0x807CE17: call_func (eval.c:8123)
>> >> ==13408==    by 0x807CA5B: get_func_tv (eval.c:7969)
>> >> ==13408==    by 0x8078DF3: eval7 (eval.c:5021)
>> >> ==13408==    by 0x80786FC: eval6 (eval.c:4688)
>> >> ==13408==    by 0x80782E8: eval5 (eval.c:4504)
>> >> ==13408==    by 0x8077839: eval4 (eval.c:4199)
>> >> ==13408==    by 0x8077691: eval3 (eval.c:4111)
>> >> ==13408==    by 0x807751D: eval2 (eval.c:4040)
>> >> ==13408==    by 0x807734D: eval1 (eval.c:3965)
>> >> ==13408==    by 0x80772B4: eval0 (eval.c:3922)
>> >> ==13408==    by 0x8073AC5: ex_let (eval.c:1837)
>> >> ==13408==    by 0x80A7548: do_one_cmd (ex_docmd.c:2627)
>> >> ==13408==    by 0x80A4D7F: do_cmdline (ex_docmd.c:1096)
>> >> ==13408==    by 0x80A2FE3: do_source (ex_cmds2.c:3116)
>> >> ==13408==    by 0x80EA44D: source_startup_scripts (main.c:2778)
>> >> ==13408==    by 0x80E74DB: main (main.c:563)
>> >> ==13408==  Address 0x548108c is 4 bytes inside a block of size 32 free'd
>> >> ==13408==    at 0x4024E5A: free (vg_replace_malloc.c:323)
>> >> ==13408==    by 0x8116C67: vim_free (misc2.c:1639)
>> >> ==13408==    by 0x813CD7A: str_to_reg (ops.c:6155)
>> >> ==13408==    by 0x813CB6F: write_reg_contents_ex (ops.c:6052)
>> >> ==13408==    by 0x813C9E1: write_reg_contents (ops.c:5981)
>> >> ==13408==    by 0x8104C0E: redir_write (message.c:3046)
>> >> ==13408==    by 0x8103034: msg_puts_attr_len (message.c:1803)
>> >> ==13408==    by 0x8102715: msg_outtrans_len_attr (message.c:1402)
>> >> ==13408==    by 0x810243D: msg_outtrans_len (message.c:1291)
>> >> ==13408==    by 0x81398A3: ex_display (ops.c:4013)
>> >> ==13408==    by 0x80A7548: do_one_cmd (ex_docmd.c:2627)
>> >> ==13408==    by 0x80A4D7F: do_cmdline (ex_docmd.c:1096)
>> >> ==13408==    by 0x8090CB8: call_user_func (eval.c:21292)
>> >> ==13408==    by 0x807CE17: call_func (eval.c:8123)
>> >> ==13408==    by 0x807CA5B: get_func_tv (eval.c:7969)
>> >> ==13408==    by 0x8078DF3: eval7 (eval.c:5021)
>> >> ==13408==    by 0x80786FC: eval6 (eval.c:4688)
>> >> ==13408==    by 0x80782E8: eval5 (eval.c:4504)
>> >> ==13408==    by 0x8077839: eval4 (eval.c:4199)
>> >> ==13408==    by 0x8077691: eval3 (eval.c:4111)
>> >> ==13408==    by 0x807751D: eval2 (eval.c:4040)
>> >> ==13408==    by 0x807734D: eval1 (eval.c:3965)
>> >> ==13408==    by 0x80772B4: eval0 (eval.c:3922)
>> >> ==13408==    by 0x8073AC5: ex_let (eval.c:1837)
>> >> ==13408==    by 0x80A7548: do_one_cmd (ex_docmd.c:2627)
>> >> ==13408==    by 0x80A4D7F: do_cmdline (ex_docmd.c:1096)
>> >> ==13408==    by 0x80A2FE3: do_source (ex_cmds2.c:3116)
>> >> ==13408==    by 0x80EA44D: source_startup_scripts (main.c:2778)
>> >> ==13408==    by 0x80E74DB: main (main.c:563)
>> >> (several more errors follow after that)
>> >>
>> >> The bug happens because function ex_display() is printing
>> >> all registers and while doing so, a register can be modified
>> >> if output is redirected to register (causing access to freed
>> >> memory).
>> >>
>> >> Attached patch fixes it by making function ex_display()
>> >> output a copy of the register. Please review it.
>> >>
>> >> I noticed this issue when trying Tony's .vimrc available at:
>> >>   http://vim.wikia.com/wiki/User:Tonymec/vimrc
>> >>
>> >> The bug happens in function TestForX() in his vimrc file.
>> >
>> > The patch introduces quite a bit of new code, copies text around and
>> > allocates memory.
>> >
>> > How about this solution instead:
>> >
>> > *** ../vim-7.2.289/src/ops.c    2009-11-03 16:44:04.000000000 +0100
>> > --- src/ops.c   2009-11-11 16:13:33.000000000 +0100
>> > ***************
>> > *** 3990,3995 ****
>> > --- 3990,4001 ----
>> >        }
>> >        else
>> >            yb = &(y_regs[i]);
>> > +
>> > +       if (name == vim_tolower(redir_reg)
>> > +               || (redir_reg == '"' && yb == y_previous))
>> > +           continue;       /* do not list register being written to, the
>> > +                            * pointer can be freed */
>> > +
>> >        if (yb->y_array != NULL)
>> >        {
>> >            msg_putchar('\n');
>>
>>
>> Your patch is simpler (which is better) and I verified that it
>> also avoids access to freed memory.
>>
>> My patch and your patch have different outcomes though.
>>
>> Using the following script...
>>
>>   :let @a = "foobar"
>>   :redir @a
>>   :sil reg a
>>   :redir END
>>   :echo @a
>>
>> With your patch, the echo statements prints one line:
>>
>> --- Registers ---
>>
>> With my patch, the echo statement prints 2 lines:
>>
>> --- Registers ---
>> "a   ^J--- Registers ---
>>
>> I don't mind about the difference.  In fact not outputting
>> the redirected register (as in your patch) is better in my
>> opinion since content of register @a has already been
>> lost as soon as we do ":redir @a".
>
> Thanks for checking the patch.   Yes, the register written to is omitted
> from the list.  I think that's somewhat better than listing a partly
> filled register.  Definitely better than crashing.

Hi

I just realize that there is a problem with your proposed patch:
vim-tiny fails to compile.

ops.c: In function ‘ex_display’:
ops.c:3995: error: ‘redir_reg’ undeclared (first use in this function)

We need to add #ifdef FEAT_EVAL

RCS file: /cvsroot/vim/vim7/src/ops.c,v
retrieving revision 1.77
diff -c -r1.77 ops.c
*** src/ops.c   11 Nov 2009 16:22:28 -0000      1.77
--- src/ops.c   14 Nov 2009 19:51:22 -0000
***************
*** 3991,3996 ****
--- 3991,4004 ----
         }
         else
             yb = &(y_regs[i]);
+
+ #ifdef FEAT_EVAL
+        if (name == vim_tolower(redir_reg)
+                || (redir_reg == '"' && yb == y_previous))
+            continue;       /* do not list register being written to, the
+                             * pointer can be freed */
+ #endif
+
         if (yb->y_array != NULL)
         {
             msg_putchar('\n');

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Dominique Pelle wrote:

> I can reproduce a memory leak with Vim-7.2.293 (and older).
>
> Steps to reproduce:
>
> 1/ Create the following minimalistic script:
>
>   $ cat leak.vim
>
>   function Foo()
>     redraw!
>     return ''
>   endfunction
>
>   set hlsearch
>   set laststatus=2
>   set statusline=%{Foo()}
>
> 2/ Start Vim with Valgrind using:
>
>    $ cd vim7/src
>    $ valgrind --leak-check=yes ./vim \
>        --noplugin \
>        -u leak.vim buffer.c \
>        -c 'exe "normal /to\<CR>"' 2> vg.log
>
> 3/ Press   n   several times (press 3 times for example) to go to next
>    match several times.
>
> 4/ Quit Vim with:
>
>    :q!
>
> 5/ Observe in vg.log the following memory leaks:
>
> ==15737== 164 bytes in 4 blocks are definitely lost in loss record 100 of 113
> ==15737==    at 0x402603E: malloc (vg_replace_malloc.c:207)
> ==15737==    by 0x8115C72: lalloc (misc2.c:866)
> ==15737==    by 0x815AAF7: vim_regcomp (regexp.c:1021)
> ==15737==    by 0x81747EA: search_regcomp (search.c:216)
> ==15737==    by 0x817505C: last_pat_prog (search.c:501)
> ==15737==    by 0x816F71E: start_search_hl (screen.c:6590)
> ==15737==    by 0x816488C: update_screen (screen.c:505)
> ==15737==    by 0x80E7C97: main_loop (main.c:1121)
> ==15737==    by 0x80E792D: main (main.c:948)
>
> One block is leaked when doing the first search with  /to  then
> other blocks are leaked every time you press  n  to go to next
> match.  In above example I pressed  n  3 times so there was 1+3=4
> leaks in total.
>
> Attached patch fixes it.

Thanks!


--
ARTHUR: Old woman!
DENNIS: Man!
ARTHUR: Man.  I'm sorry.  Old man, What knight live in that castle over there?
DENNIS: I'm thirty-seven.
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// 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
-~----------~----~----~----~------~----~------~--~---

Hi

I can reproduce a memory leak with Vim-7.2.293 (and older).

Steps to reproduce:

1/ Create the following minimalistic script:

   $ cat leak.vim

   function Foo()
     redraw!
     return ''
   endfunction

   set hlsearch
   set laststatus=2
   set statusline=%{Foo()}

2/ Start Vim with Valgrind using:

    $ cd vim7/src
    $ valgrind --leak-check=yes ./vim \
        --noplugin \
        -u leak.vim buffer.c \
        -c 'exe "normal /to\<CR>"' 2> vg.log

3/ Press   n   several times (press 3 times for example) to go to next
    match several times.

4/ Quit Vim with:

    :q!

5/ Observe in vg.log the following memory leaks:

==15737== 164 bytes in 4 blocks are definitely lost in loss record 100 of 113
==15737==    at 0x402603E: malloc (vg_replace_malloc.c:207)
==15737==    by 0x8115C72: lalloc (misc2.c:866)
==15737==    by 0x815AAF7: vim_regcomp (regexp.c:1021)
==15737==    by 0x81747EA: search_regcomp (search.c:216)
==15737==    by 0x817505C: last_pat_prog (search.c:501)
==15737==    by 0x816F71E: start_search_hl (screen.c:6590)
==15737==    by 0x816488C: update_screen (screen.c:505)
==15737==    by 0x80E7C97: main_loop (main.c:1121)
==15737==    by 0x80E792D: main (main.c:948)

One block is leaked when doing the first search with  /to  then
other blocks are leaked every time you press  n  to go to next
match.  In above example I pressed  n  3 times so there was 1+3=4
leaks in total.

Attached patch fixes it.

Regards
-- Dominique

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On Fri, Nov 13, 2009 at 10:39:29PM +0100, Bram Moolenaar wrote:
>
>
> Tim Starling wrote:
>
> > GtkFileChooser is disabled in gvim, because gvim exits gtk_main() level
> > 1 every time an event is received, causing GTK to write to the disk
> > excessively.
> >
> > gtk_main() has always stored the clipboard on the same trigger, so it's
> > fair to say that exiting gtk_main() constantly is not the way the GTK
> > developers expected an application to work. People who know stuff about
> > GTK agree:
> >
> > http://mail.gnome.org/archives/gtk-list/2008-July/msg00131.html
> >
> > My interest in this started when I discovered that GtkFileChooser had
> > been disabled. I missed it:
> >
> > https://bugs.launchpad.net/ubuntu/+source/vim/+bug/365860
> >
> > It's been 7 months now since that plaintive cry, so I gave up waiting
> > and wrote a patch. This is my first GTK project but it looks pretty
> > straightforward. I read the source code for gtk_main() and some other
> > things.
> >
> > Emmanuele Bassi's advice was to create a separate GMainLoop:
> >
> > http://mail.gnome.org/archives/gtk-list/2008-July/msg00146.html
> >
> > That turns out to be unnecessary, since all GMainLoop does is calls
> > g_main_context_iteration() repeatedly, until it's time to exit. The
> > actual task of registering event sources and calling select() is done by
> > GMainContext, which exists whether or not a GMainLoop has been created.
> > Thus by calling g_main_context_iteration() at the relevant places, vim
> > can leave main_loop() unmodified.
> >
> > My patch does this, and removes all calls to gtk_main_quit() except the
> > ones in modal dialogs. Modal dialogs are now implemented by calling
> > gtk_main() once only, and allowing the button handlers to call
> > gtk_main_quit(), just like in a regular GTK application.
> >
> > We don't seem to be missing anything substantial by never calling
> > gtk_main(). You can register callbacks to be called when gtk_main()
> > exits, but luckily vim isn't doing that or else they'd be called on the
> > first keypress and then never again. Of course we miss out on that final
> > sync of recently-used.xbel, but it seems that it's already synced every
> > time it's changed, via the "changed" signal (see
> > gtk_recent_manager_changed() and its callers in gtk/gtkrecentmanager.c).
> >
> > I haven't done cross-version tests on this patch, but
> > g_main_context_iteration() exists back to at least GLib 1.3.9 (September
> > 2001).
> >
> > Attached and online at:
> > http://tstarling.com/stuff/fix-gtk-main.patch
>
> I'm very glad to see someone is picking up a GTK problem.  Hardly any
> work was done on GTK for a long time.
>
> I would appreciate it if a few people try this out and report any
> problems they notice.

The bug Tim fixed was something I had been planning on taking a look at, so
I'll definitely try out the patch soon and report back.

Thanks for the patch, Tim!

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@...>

Tim Starling wrote:

> GtkFileChooser is disabled in gvim, because gvim exits gtk_main() level
> 1 every time an event is received, causing GTK to write to the disk
> excessively.
>
> gtk_main() has always stored the clipboard on the same trigger, so it's
> fair to say that exiting gtk_main() constantly is not the way the GTK
> developers expected an application to work. People who know stuff about
> GTK agree:
>
> http://mail.gnome.org/archives/gtk-list/2008-July/msg00131.html
>
> My interest in this started when I discovered that GtkFileChooser had
> been disabled. I missed it:
>
> https://bugs.launchpad.net/ubuntu/+source/vim/+bug/365860
>
> It's been 7 months now since that plaintive cry, so I gave up waiting
> and wrote a patch. This is my first GTK project but it looks pretty
> straightforward. I read the source code for gtk_main() and some other
> things.
>
> Emmanuele Bassi's advice was to create a separate GMainLoop:
>
> http://mail.gnome.org/archives/gtk-list/2008-July/msg00146.html
>
> That turns out to be unnecessary, since all GMainLoop does is calls
> g_main_context_iteration() repeatedly, until it's time to exit. The
> actual task of registering event sources and calling select() is done by
> GMainContext, which exists whether or not a GMainLoop has been created.
> Thus by calling g_main_context_iteration() at the relevant places, vim
> can leave main_loop() unmodified.
>
> My patch does this, and removes all calls to gtk_main_quit() except the
> ones in modal dialogs. Modal dialogs are now implemented by calling
> gtk_main() once only, and allowing the button handlers to call
> gtk_main_quit(), just like in a regular GTK application.
>
> We don't seem to be missing anything substantial by never calling
> gtk_main(). You can register callbacks to be called when gtk_main()
> exits, but luckily vim isn't doing that or else they'd be called on the
> first keypress and then never again. Of course we miss out on that final
> sync of recently-used.xbel, but it seems that it's already synced every
> time it's changed, via the "changed" signal (see
> gtk_recent_manager_changed() and its callers in gtk/gtkrecentmanager.c).
>
> I haven't done cross-version tests on this patch, but
> g_main_context_iteration() exists back to at least GLib 1.3.9 (September
> 2001).
>
> Attached and online at:
> http://tstarling.com/stuff/fix-gtk-main.patch

I'm very glad to see someone is picking up a GTK problem.  Hardly any
work was done on GTK for a long time.

I would appreciate it if a few people try this out and report any
problems they notice.

--
I used to wonder about the meaning of life.  But I looked it
up in the dictionary under "L" and there it was - the meaning
of life.  It was less than I expected.              - Dogbert

  /// 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
-~----------~----~----~----~------~----~------~--~---

GtkFileChooser is disabled in gvim, because gvim exits gtk_main() level
1 every time an event is received, causing GTK to write to the disk
excessively.

gtk_main() has always stored the clipboard on the same trigger, so it's
fair to say that exiting gtk_main() constantly is not the way the GTK
developers expected an application to work. People who know stuff about
GTK agree:

http://mail.gnome.org/archives/gtk-list/2008-July/msg00131.html

My interest in this started when I discovered that GtkFileChooser had
been disabled. I missed it:

https://bugs.launchpad.net/ubuntu/+source/vim/+bug/365860

It's been 7 months now since that plaintive cry, so I gave up waiting
and wrote a patch. This is my first GTK project but it looks pretty
straightforward. I read the source code for gtk_main() and some other
things.

Emmanuele Bassi's advice was to create a separate GMainLoop:

http://mail.gnome.org/archives/gtk-list/2008-July/msg00146.html

That turns out to be unnecessary, since all GMainLoop does is calls
g_main_context_iteration() repeatedly, until it's time to exit. The
actual task of registering event sources and calling select() is done by
GMainContext, which exists whether or not a GMainLoop has been created.
Thus by calling g_main_context_iteration() at the relevant places, vim
can leave main_loop() unmodified.

My patch does this, and removes all calls to gtk_main_quit() except the
ones in modal dialogs. Modal dialogs are now implemented by calling
gtk_main() once only, and allowing the button handlers to call
gtk_main_quit(), just like in a regular GTK application.

We don't seem to be missing anything substantial by never calling
gtk_main(). You can register callbacks to be called when gtk_main()
exits, but luckily vim isn't doing that or else they'd be called on the
first keypress and then never again. Of course we miss out on that final
sync of recently-used.xbel, but it seems that it's already synced every
time it's changed, via the "changed" signal (see
gtk_recent_manager_changed() and its callers in gtk/gtkrecentmanager.c).

I haven't done cross-version tests on this patch, but
g_main_context_iteration() exists back to at least GLib 1.3.9 (September
2001).

Attached and online at:
http://tstarling.com/stuff/fix-gtk-main.patch

-- Tim Starling

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

gcc 4.5 unreleased contains a column number for the "In file included from"
gcc 4.4 did not.
errorformat does not skip over the first line.
/opt/gcc-4.5/bin/g++ -std=c++0x -fshow-column c.cpp
In file included from a.h:3:0,
from c.cpp:2:
b.h:3:1: error: ‘dscfsdjvcsdfvsdf’ does not name a type
c.cpp:9:17: error: ISO C++ forbids declaration of ‘Params’ with no type
c.cpp:9:24: error: expected ‘,’ or ‘...’ before ‘&’ token
c.cpp: In function ‘int main()’:
c.cpp:16:2: error: ‘Params’ was not declared in this scope
c.cpp:16:9: error: expected ‘;’ before ‘p’
c.cpp:17:7: error: ‘p’ was not declared in this scope


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Dominique Pelle wrote:

> Bram Moolenaar wrote:
>
> > Patch 7.2.286 (after 7.2.269)
> > Problem:    The "--startuptime=<file>" argument is not consistent with other
> >            arguments.
> > Solution:   Use "--startuptime <file>".  Added the +startuptime feature.
> > Files:      runtime/doc/eval.txt, runtime/doc/starting.txt,
> >            runtime/doc/various.txt, src/eval.c, src/main.c, src/version.c
> >
> ...
> > ***************
> > *** 3144,3149 ****
> > --- 3150,3158 ----
> >      main_msg(_("--serverlist\t\tList available Vim server names and
exit"));
> >      main_msg(_("--servername <name>\tSend to/become the Vim server
<name>"));
> >  #endif
> > + #ifdef STARTUPTIME
> > +     main_msg(_("--startuptime=<file>\tWrite startup timing messages to
<file>"));
> > + #endif
> >  #ifdef FEAT_VIMINFO
> >      main_msg(_("-i <viminfo>\t\tUse <viminfo> instead of .viminfo"));
> >  #endif
>
>
> Hi
>
> Above chunk in patch 7.2.286 still uses the equal sign
> after --startuptime whereas the rest of the patch replaced it
> with a space. Sorry for being nitpicky.

And being lazy too: you didn't include a patch!  :-)

--
ARTHUR: The swallow may fly south with the sun, or the house martin or the
         plover seek warmer hot lands in winter, yet these are not strangers to
         our land.
SOLDIER: Are you suggesting coconuts migrate?
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// 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 wrote:

> >> I can reproduce a bug (use of freed memory) in Vim-7.2.284
> >> on Linux x86 as follows:
> >>
> >> 1/ Start vim with valgrind:
> >>
> >>   $ cd vim7/src
> >>   $ valgrind --leak-check=yes \
> >>              --num-callers=50 ./vim --noplugin -u NONE 2> vg.log
> >>
> >> 2/ Enter the 2 following Ex commands:
> >>
> >>   :redir @"
> >>   :reg
> >>
> >> 3/ Observe in vg.log the following errors as soon as :reg is being
> >> executed:
> >>
> >> ==13408== Invalid read of size 1
> >> ==13408==    at 0x40276F8: memmove (mc_replace_strmem.c:517)
> >> ==13408==    by 0x813CDA1: str_to_reg (ops.c:6157)
> >> ==13408==    by 0x813CB6F: write_reg_contents_ex (ops.c:6052)
> >> ==13408==    by 0x813C9E1: write_reg_contents (ops.c:5981)
> >> ==13408==    by 0x8104C0E: redir_write (message.c:3046)
> >> ==13408==    by 0x8103034: msg_puts_attr_len (message.c:1803)
> >> ==13408==    by 0x8102715: msg_outtrans_len_attr (message.c:1402)
> >> ==13408==    by 0x810243D: msg_outtrans_len (message.c:1291)
> >> ==13408==    by 0x81398A3: ex_display (ops.c:4013)
> >> ==13408==    by 0x80A7548: do_one_cmd (ex_docmd.c:2627)
> >> ==13408==    by 0x80A4D7F: do_cmdline (ex_docmd.c:1096)
> >> ==13408==    by 0x8090CB8: call_user_func (eval.c:21292)
> >> ==13408==    by 0x807CE17: call_func (eval.c:8123)
> >> ==13408==    by 0x807CA5B: get_func_tv (eval.c:7969)
> >> ==13408==    by 0x8078DF3: eval7 (eval.c:5021)
> >> ==13408==    by 0x80786FC: eval6 (eval.c:4688)
> >> ==13408==    by 0x80782E8: eval5 (eval.c:4504)
> >> ==13408==    by 0x8077839: eval4 (eval.c:4199)
> >> ==13408==    by 0x8077691: eval3 (eval.c:4111)
> >> ==13408==    by 0x807751D: eval2 (eval.c:4040)
> >> ==13408==    by 0x807734D: eval1 (eval.c:3965)
> >> ==13408==    by 0x80772B4: eval0 (eval.c:3922)
> >> ==13408==    by 0x8073AC5: ex_let (eval.c:1837)
> >> ==13408==    by 0x80A7548: do_one_cmd (ex_docmd.c:2627)
> >> ==13408==    by 0x80A4D7F: do_cmdline (ex_docmd.c:1096)
> >> ==13408==    by 0x80A2FE3: do_source (ex_cmds2.c:3116)
> >> ==13408==    by 0x80EA44D: source_startup_scripts (main.c:2778)
> >> ==13408==    by 0x80E74DB: main (main.c:563)
> >> ==13408==  Address 0x548108c is 4 bytes inside a block of size 32 free'd
> >> ==13408==    at 0x4024E5A: free (vg_replace_malloc.c:323)
> >> ==13408==    by 0x8116C67: vim_free (misc2.c:1639)
> >> ==13408==    by 0x813CD7A: str_to_reg (ops.c:6155)
> >> ==13408==    by 0x813CB6F: write_reg_contents_ex (ops.c:6052)
> >> ==13408==    by 0x813C9E1: write_reg_contents (ops.c:5981)
> >> ==13408==    by 0x8104C0E: redir_write (message.c:3046)
> >> ==13408==    by 0x8103034: msg_puts_attr_len (message.c:1803)
> >> ==13408==    by 0x8102715: msg_outtrans_len_attr (message.c:1402)
> >> ==13408==    by 0x810243D: msg_outtrans_len (message.c:1291)
> >> ==13408==    by 0x81398A3: ex_display (ops.c:4013)
> >> ==13408==    by 0x80A7548: do_one_cmd (ex_docmd.c:2627)
> >> ==13408==    by 0x80A4D7F: do_cmdline (ex_docmd.c:1096)
> >> ==13408==    by 0x8090CB8: call_user_func (eval.c:21292)
> >> ==13408==    by 0x807CE17: call_func (eval.c:8123)
> >> ==13408==    by 0x807CA5B: get_func_tv (eval.c:7969)
> >> ==13408==    by 0x8078DF3: eval7 (eval.c:5021)
> >> ==13408==    by 0x80786FC: eval6 (eval.c:4688)
> >> ==13408==    by 0x80782E8: eval5 (eval.c:4504)
> >> ==13408==    by 0x8077839: eval4 (eval.c:4199)
> >> ==13408==    by 0x8077691: eval3 (eval.c:4111)
> >> ==13408==    by 0x807751D: eval2 (eval.c:4040)
> >> ==13408==    by 0x807734D: eval1 (eval.c:3965)
> >> ==13408==    by 0x80772B4: eval0 (eval.c:3922)
> >> ==13408==    by 0x8073AC5: ex_let (eval.c:1837)
> >> ==13408==    by 0x80A7548: do_one_cmd (ex_docmd.c:2627)
> >> ==13408==    by 0x80A4D7F: do_cmdline (ex_docmd.c:1096)
> >> ==13408==    by 0x80A2FE3: do_source (ex_cmds2.c:3116)
> >> ==13408==    by 0x80EA44D: source_startup_scripts (main.c:2778)
> >> ==13408==    by 0x80E74DB: main (main.c:563)
> >> (several more errors follow after that)
> >>
> >> The bug happens because function ex_display() is printing
> >> all registers and while doing so, a register can be modified
> >> if output is redirected to register (causing access to freed
> >> memory).
> >>
> >> Attached patch fixes it by making function ex_display()
> >> output a copy of the register. Please review it.
> >>
> >> I noticed this issue when trying Tony's .vimrc available at:
> >>   http://vim.wikia.com/wiki/User:Tonymec/vimrc
> >>
> >> The bug happens in function TestForX() in his vimrc file.
> >
> > The patch introduces quite a bit of new code, copies text around and
> > allocates memory.
> >
> > How about this solution instead:
> >
> > *** ../vim-7.2.289/src/ops.c    2009-11-03 16:44:04.000000000 +0100
> > --- src/ops.c   2009-11-11 16:13:33.000000000 +0100
> > ***************
> > *** 3990,3995 ****
> > --- 3990,4001 ----
> >        }
> >        else
> >            yb = &(y_regs[i]);
> > +
> > +       if (name == vim_tolower(redir_reg)
> > +               || (redir_reg == '"' && yb == y_previous))
> > +           continue;       /* do not list register being written to, the
> > +                            * pointer can be freed */
> > +
> >        if (yb->y_array != NULL)
> >        {
> >            msg_putchar('\n');
>
>
> Your patch is simpler (which is better) and I verified that it
> also avoids access to freed memory.
>
> My patch and your patch have different outcomes though.
>
> Using the following script...
>
>   :let @a = "foobar"
>   :redir @a
>   :sil reg a
>   :redir END
>   :echo @a
>
> With your patch, the echo statements prints one line:
>
> --- Registers ---
>
> With my patch, the echo statement prints 2 lines:
>
> --- Registers ---
> "a   ^J--- Registers ---
>
> I don't mind about the difference.  In fact not outputting
> the redirected register (as in your patch) is better in my
> opinion since content of register @a has already been
> lost as soon as we do ":redir @a".

Thanks for checking the patch.   Yes, the register written to is omitted
from the list.  I think that's somewhat better than listing a partly
filled register.  Definitely better than crashing.

--
SOLDIER: What? A swallow carrying a coconut?
ARTHUR:  It could grip it by the husk ...
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// 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
-~----------~----~----~----~------~----~------~--~---

Bram Moolenaar wrote:
>
> Dominique Pelle wrote:
>
>> I can reproduce a bug (use of freed memory) in Vim-7.2.284
>> on Linux x86 as follows:
>>
>> 1/ Start vim with valgrind:
>>
>>   $ cd vim7/src
>>   $ valgrind --leak-check=yes \
>>              --num-callers=50 ./vim --noplugin -u NONE 2> vg.log
>>
>> 2/ Enter the 2 following Ex commands:
>>
>>   :redir @"
>>   :reg
>>
>> 3/ Observe in vg.log the following errors as soon as :reg is being
>> executed:
>>
>> ==13408== Invalid read of size 1
>> ==13408==    at 0x40276F8: memmove (mc_replace_strmem.c:517)
>> ==13408==    by 0x813CDA1: str_to_reg (ops.c:6157)
>> ==13408==    by 0x813CB6F: write_reg_contents_ex (ops.c:6052)
>> ==13408==    by 0x813C9E1: write_reg_contents (ops.c:5981)
>> ==13408==    by 0x8104C0E: redir_write (message.c:3046)
>> ==13408==    by 0x8103034: msg_puts_attr_len (message.c:1803)
>> ==13408==    by 0x8102715: msg_outtrans_len_attr (message.c:1402)
>> ==13408==    by 0x810243D: msg_outtrans_len (message.c:1291)
>> ==13408==    by 0x81398A3: ex_display (ops.c:4013)
>> ==13408==    by 0x80A7548: do_one_cmd (ex_docmd.c:2627)
>> ==13408==    by 0x80A4D7F: do_cmdline (ex_docmd.c:1096)
>> ==13408==    by 0x8090CB8: call_user_func (eval.c:21292)
>> ==13408==    by 0x807CE17: call_func (eval.c:8123)
>> ==13408==    by 0x807CA5B: get_func_tv (eval.c:7969)
>> ==13408==    by 0x8078DF3: eval7 (eval.c:5021)
>> ==13408==    by 0x80786FC: eval6 (eval.c:4688)
>> ==13408==    by 0x80782E8: eval5 (eval.c:4504)
>> ==13408==    by 0x8077839: eval4 (eval.c:4199)
>> ==13408==    by 0x8077691: eval3 (eval.c:4111)
>> ==13408==    by 0x807751D: eval2 (eval.c:4040)
>> ==13408==    by 0x807734D: eval1 (eval.c:3965)
>> ==13408==    by 0x80772B4: eval0 (eval.c:3922)
>> ==13408==    by 0x8073AC5: ex_let (eval.c:1837)
>> ==13408==    by 0x80A7548: do_one_cmd (ex_docmd.c:2627)
>> ==13408==    by 0x80A4D7F: do_cmdline (ex_docmd.c:1096)
>> ==13408==    by 0x80A2FE3: do_source (ex_cmds2.c:3116)
>> ==13408==    by 0x80EA44D: source_startup_scripts (main.c:2778)
>> ==13408==    by 0x80E74DB: main (main.c:563)
>> ==13408==  Address 0x548108c is 4 bytes inside a block of size 32 free'd
>> ==13408==    at 0x4024E5A: free (vg_replace_malloc.c:323)
>> ==13408==    by 0x8116C67: vim_free (misc2.c:1639)
>> ==13408==    by 0x813CD7A: str_to_reg (ops.c:6155)
>> ==13408==    by 0x813CB6F: write_reg_contents_ex (ops.c:6052)
>> ==13408==    by 0x813C9E1: write_reg_contents (ops.c:5981)
>> ==13408==    by 0x8104C0E: redir_write (message.c:3046)
>> ==13408==    by 0x8103034: msg_puts_attr_len (message.c:1803)
>> ==13408==    by 0x8102715: msg_outtrans_len_attr (message.c:1402)
>> ==13408==    by 0x810243D: msg_outtrans_len (message.c:1291)
>> ==13408==    by 0x81398A3: ex_display (ops.c:4013)
>> ==13408==    by 0x80A7548: do_one_cmd (ex_docmd.c:2627)
>> ==13408==    by 0x80A4D7F: do_cmdline (ex_docmd.c:1096)
>> ==13408==    by 0x8090CB8: call_user_func (eval.c:21292)
>> ==13408==    by 0x807CE17: call_func (eval.c:8123)
>> ==13408==    by 0x807CA5B: get_func_tv (eval.c:7969)
>> ==13408==    by 0x8078DF3: eval7 (eval.c:5021)
>> ==13408==    by 0x80786FC: eval6 (eval.c:4688)
>> ==13408==    by 0x80782E8: eval5 (eval.c:4504)
>> ==13408==    by 0x8077839: eval4 (eval.c:4199)
>> ==13408==    by 0x8077691: eval3 (eval.c:4111)
>> ==13408==    by 0x807751D: eval2 (eval.c:4040)
>> ==13408==    by 0x807734D: eval1 (eval.c:3965)
>> ==13408==    by 0x80772B4: eval0 (eval.c:3922)
>> ==13408==    by 0x8073AC5: ex_let (eval.c:1837)
>> ==13408==    by 0x80A7548: do_one_cmd (ex_docmd.c:2627)
>> ==13408==    by 0x80A4D7F: do_cmdline (ex_docmd.c:1096)
>> ==13408==    by 0x80A2FE3: do_source (ex_cmds2.c:3116)
>> ==13408==    by 0x80EA44D: source_startup_scripts (main.c:2778)
>> ==13408==    by 0x80E74DB: main (main.c:563)
>> (several more errors follow after that)
>>
>> The bug happens because function ex_display() is printing
>> all registers and while doing so, a register can be modified
>> if output is redirected to register (causing access to freed
>> memory).
>>
>> Attached patch fixes it by making function ex_display()
>> output a copy of the register. Please review it.
>>
>> I noticed this issue when trying Tony's .vimrc available at:
>>   http://vim.wikia.com/wiki/User:Tonymec/vimrc
>>
>> The bug happens in function TestForX() in his vimrc file.
>
> The patch introduces quite a bit of new code, copies text around and
> allocates memory.
>
> How about this solution instead:
>
> *** ../vim-7.2.289/src/ops.c    2009-11-03 16:44:04.000000000 +0100
> --- src/ops.c   2009-11-11 16:13:33.000000000 +0100
> ***************
> *** 3990,3995 ****
> --- 3990,4001 ----
>        }
>        else
>            yb = &(y_regs[i]);
> +
> +       if (name == vim_tolower(redir_reg)
> +               || (redir_reg == '"' && yb == y_previous))
> +           continue;       /* do not list register being written to, the
> +                            * pointer can be freed */
> +
>        if (yb->y_array != NULL)
>        {
>            msg_putchar('\n');


Your patch is simpler (which is better) and I verified that it
also avoids access to freed memory.

My patch and your patch have different outcomes though.

Using the following script...

   :let @a = "foobar"
   :redir @a
   :sil reg a
   :redir END
   :echo @a

With your patch, the echo statements prints one line:

--- Registers ---

With my patch, the echo statement prints 2 lines:

--- Registers ---
"a   ^J--- Registers ---

I don't mind about the difference.  In fact not outputting
the redirected register (as in your patch) is better in my
opinion since content of register @a has already been
lost as soon as we do ":redir @a".

Cheers
-- Dominique

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Bram Moolenaar wrote:

> Patch 7.2.286 (after 7.2.269)
> Problem:    The "--startuptime=<file>" argument is not consistent with other
>            arguments.
> Solution:   Use "--startuptime <file>".  Added the +startuptime feature.
> Files:      runtime/doc/eval.txt, runtime/doc/starting.txt,
>            runtime/doc/various.txt, src/eval.c, src/main.c, src/version.c
>
...
> ***************
> *** 3144,3149 ****
> --- 3150,3158 ----
>      main_msg(_("--serverlist\t\tList available Vim server names and exit"));
>      main_msg(_("--servername <name>\tSend to/become the Vim server <name>"));
>  #endif
> + #ifdef STARTUPTIME
> +     main_msg(_("--startuptime=<file>\tWrite startup timing messages to
<file>"));
> + #endif
>  #ifdef FEAT_VIMINFO
>      main_msg(_("-i <viminfo>\t\tUse <viminfo> instead of .viminfo"));
>  #endif


Hi

Above chunk in patch 7.2.286 still uses the equal sign
after --startuptime whereas the rest of the patch replaced it
with a space. Sorry for being nitpicky.

Cheers
-- Dominique

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

On 11/11/09 17:30, Bram Moolenaar wrote:
>
>
> Patch 7.2.293
> Problem:    When setting 'comments' option it may be used in a wrong way.
> Solution:   Don't increment after skipping over digets. (Yukihiro Nakadaira)
> Files:     src/misc1.c

This one didn't make it yet to the ftp server so I'm using the list-mail
instead.

Best regards,
Tony.
--
A [golf] ball sliced or hooked into the rough shall be lifted and
placed in the fairway at a point equal to the distance it carried or
rolled into the rough.  Such veering right or left frequently results
from friction between the face of the club and the cover of the ball
and the player should not be penalized for the erratic behavior of the
ball resulting from such uncontrollable physical
phenomena.
		 -- Donald A. Metz

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Patch 7.2.293
Problem:    When setting 'comments' option it may be used in a wrong way.
Solution:   Don't increment after skipping over digets. (Yukihiro Nakadaira)
Files:     src/misc1.c


*** ../vim-7.2.292/src/misc1.c 2009-11-03 18:46:53.000000000 +0100
--- src/misc1.c 2009-11-11 17:27:38.000000000 +0100
***************
*** 1026,1037 ****
  		     int  c = 0;
  		     int  off = 0;

! 		    for (p = lead_flags; *p && *p != ':'; ++p)
  		     {
  			 if (*p == COM_RIGHT || *p == COM_LEFT)
! 			    c = *p;
  			 else if (VIM_ISDIGIT(*p) || *p == '-')
  			     off = getdigits(&p);
  		     }
  		     if (c == COM_RIGHT)    /* right adjusted leader */
  		     {
--- 1026,1039 ----
  		     int  c = 0;
  		     int  off = 0;

! 		    for (p = lead_flags; *p != NUL && *p != ':'; )
  		     {
  			 if (*p == COM_RIGHT || *p == COM_LEFT)
! 			    c = *p++;
  			 else if (VIM_ISDIGIT(*p) || *p == '-')
  			     off = getdigits(&p);
+ 		 else
+ 			    ++p;
  		     }
  		     if (c == COM_RIGHT)    /* right adjusted leader */
  		     {
*** ../vim-7.2.292/src/version.c 2009-11-11 17:22:30.000000000 +0100
--- src/version.c 2009-11-11 17:29:24.000000000 +0100
***************
*** 683,684 ****
--- 683,686 ----
   {   /* Add new patch number below this line */
+ /**/
+     293,
   /**/

--
SOLDIER: What?  Ridden on a horse?
ARTHUR:  Yes!
SOLDIER: You're using coconuts!
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// 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
-~----------~----~----~----~------~----~------~--~---

Patch 7.2.292
Problem:    Block right-shift doesn't work properly with multi-byte encoding
	     and 'list' set.
Solution:   Add the missing "else". (Lech Lorens)
Files:     src/ops.c


*** ../vim-7.2.291/src/ops.c 2009-11-03 16:44:04.000000000 +0100
--- src/ops.c 2009-11-11 17:15:04.000000000 +0100
***************
*** 422,429 ****
   #ifdef FEAT_MBYTE
  	     if (has_mbyte)
  		 bd.textstart += (*mb_ptr2len)(bd.textstart);
   #endif
! 	    ++bd.textstart;
  	 }
  	 for ( ; vim_iswhite(*bd.textstart); )
  	 {
--- 422,430 ----
   #ifdef FEAT_MBYTE
  	     if (has_mbyte)
  		 bd.textstart += (*mb_ptr2len)(bd.textstart);
+ 	    else
   #endif
! 	 ++bd.textstart;
  	 }
  	 for ( ; vim_iswhite(*bd.textstart); )
  	 {
*** ../vim-7.2.291/src/version.c 2009-11-11 17:07:25.000000000 +0100
--- src/version.c 2009-11-11 17:21:31.000000000 +0100
***************
*** 683,684 ****
--- 683,686 ----
   {   /* Add new patch number below this line */
+ /**/
+     292,
   /**/

--
Computers make very fast, very accurate, mistakes.

  /// 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
-~----------~----~----~----~------~----~------~--~---

Patch 7.2.291
Problem:    Reading uninitialised memory in arabic mode.
Solution:   Use utfc_ptr2char_len() rather than utfc_ptr2char().  (Dominique
	     Pelle)
Files:     src/screen.c


*** ../vim-7.2.290/src/screen.c 2009-11-03 17:36:09.000000000 +0100
--- src/screen.c 2009-11-11 17:04:53.000000000 +0100
***************
*** 6413,6419 ****
  		     }
  		     else
  		     {
! 		 nc = utfc_ptr2char(ptr + mbyte_blen, pcc);
  			 nc1 = pcc[0];
  		     }
  		     pc = prev_c;
--- 6413,6420 ----
  		     }
  		     else
  		     {
! 		 nc = utfc_ptr2char_len(ptr + mbyte_blen, pcc,
! 				      (int)((text + len) - ptr - mbyte_blen));
  			 nc1 = pcc[0];
  		     }
  		     pc = prev_c;
*** ../vim-7.2.290/src/version.c 2009-11-11 16:56:13.000000000 +0100
--- src/version.c 2009-11-11 17:06:48.000000000 +0100
***************
*** 683,684 ****
--- 683,686 ----
   {   /* Add new patch number below this line */
+ /**/
+     291,
   /**/

--
The problem with political jokes is that they get elected.

  /// 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
-~----------~----~----~----~------~----~------~--~---

Patch 7.2.290
Problem:    Not freeing memory from ":lmap", ":xmap" and ":menutranslate".
Solution:   Free the memory when exiting. (Dominique Pelle)
Files:     src/misc2.c


*** ../vim-7.2.289/src/misc2.c 2009-11-03 16:44:04.000000000 +0100
--- src/misc2.c 2009-11-11 16:49:13.000000000 +0100
***************
*** 1005,1013 ****
--- 1005,1018 ----
   # ifdef FEAT_MENU
       /* Clear menus. */
       do_cmdline_cmd((char_u *)"aunmenu *");
+ #  ifdef FEAT_MULTI_LANG
+     do_cmdline_cmd((char_u *)"menutranslate clear");
+ #  endif
   # endif

       /* Clear mappings, abbreviations, breakpoints. */
+     do_cmdline_cmd((char_u *)"lmapclear");
+     do_cmdline_cmd((char_u *)"xmapclear");
       do_cmdline_cmd((char_u *)"mapclear");
       do_cmdline_cmd((char_u *)"mapclear!");
       do_cmdline_cmd((char_u *)"abclear");
***************
*** 1282,1288 ****

   /*
    * Escape "string" for use as a shell argument with system().
!  * This uses single quotes, except when we know we need to use double qoutes
    * (MS-DOS and MS-Windows without 'shellslash' set).
    * Escape a newline, depending on the 'shell' option.
    * When "do_special" is TRUE also replace "!", "%", "#" and things starting
--- 1287,1293 ----

   /*
    * Escape "string" for use as a shell argument with system().
!  * This uses single quotes, except when we know we need to use double quotes
    * (MS-DOS and MS-Windows without 'shellslash' set).
    * Escape a newline, depending on the 'shell' option.
    * When "do_special" is TRUE also replace "!", "%", "#" and things starting
***************
*** 1537,1543 ****
   #if defined(FEAT_VISUALEXTRA) || defined(PROTO)
   /*
    * Copy a character a number of times.
!  * Does not work for multi-byte charactes!
    */
       void
   copy_chars(ptr, count, c)
--- 1542,1548 ----
   #if defined(FEAT_VISUALEXTRA) || defined(PROTO)
   /*
    * Copy a character a number of times.
!  * Does not work for multi-byte characters!
    */
       void
   copy_chars(ptr, count, c)
***************
*** 4260,4266 ****
  	  * or '**76' is transposed to '**N'( 'N' is ASCII value 76).
  	  * For EBCDIC you get different character values.
  	  * If no restrict is given after '**' the default is used.
! 	 * Due to this technic the path looks awful if you print it as a
  	  * string.
  	  */
  	 len = 0;
--- 4265,4271 ----
  	  * or '**76' is transposed to '**N'( 'N' is ASCII value 76).
  	  * For EBCDIC you get different character values.
  	  * If no restrict is given after '**' the default is used.
! 	 * Due to this technique the path looks awful if you print it as a
  	  * string.
  	  */
  	 len = 0;
***************
*** 4649,4655 ****
  				       && !mch_isdir(stackp->ffs_filearray[i]))
  			     continue;   /* not a directory */

! 		 /* prepare the filename to be checked for existance
  			  * below */
  			 STRCPY(file_path, stackp->ffs_filearray[i]);
  			 add_pathsep(file_path);
--- 4654,4660 ----
  				       && !mch_isdir(stackp->ffs_filearray[i]))
  			     continue;   /* not a directory */

! 		 /* prepare the filename to be checked for existence
  			  * below */
  			 STRCPY(file_path, stackp->ffs_filearray[i]);
  			 add_pathsep(file_path);
***************
*** 5438,5444 ****
   #if defined(MSWIN) || defined(MSDOS) || defined(OS2)
  	     /* handle "\tmp" as absolute path */
  	     || vim_ispathsep(ff_file_to_find[0])
! 	    /* handle "c:name" as absulute path */
  	     || (ff_file_to_find[0] != NUL && ff_file_to_find[1] == ':')
   #endif
   #ifdef AMIGA
--- 5443,5449 ----
   #if defined(MSWIN) || defined(MSDOS) || defined(OS2)
  	     /* handle "\tmp" as absolute path */
  	     || vim_ispathsep(ff_file_to_find[0])
! 	    /* handle "c:name" as absolute path */
  	     || (ff_file_to_find[0] != NUL && ff_file_to_find[1] == ':')
   #endif
   #ifdef AMIGA
***************
*** 5681,5687 ****
  		 p2 = (char_u *)base + (j + gap) * elm_size;
  		 if ((*cmp)((void *)p1, (void *)p2) <= 0)
  		     break;
! 	 /* Exchange the elemets. */
  		 mch_memmove(buf, p1, elm_size);
  		 mch_memmove(p1, p2, elm_size);
  		 mch_memmove(p2, buf, elm_size);
--- 5686,5692 ----
  		 p2 = (char_u *)base + (j + gap) * elm_size;
  		 if ((*cmp)((void *)p1, (void *)p2) <= 0)
  		     break;
! 	 /* Exchange the elements. */
  		 mch_memmove(buf, p1, elm_size);
  		 mch_memmove(p1, p2, elm_size);
  		 mch_memmove(p2, buf, elm_size);
*** ../vim-7.2.289/src/version.c 2009-11-11 16:23:37.000000000 +0100
--- src/version.c 2009-11-11 16:54:53.000000000 +0100
***************
*** 683,684 ****
--- 683,686 ----
   {   /* Add new patch number below this line */
+ /**/
+     290,
   /**/

--
ARTHUR: It is I, Arthur, son of Uther Pendragon, from the castle of Camelot.
         King of all Britons, defeator of the Saxons, sovereign of all England!
    [Pause]
SOLDIER: Get away!
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// 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 wrote:

> I can reproduce a bug (use of freed memory) in Vim-7.2.284
> on Linux x86 as follows:
>
> 1/ Start vim with valgrind:
>
>   $ cd vim7/src
>   $ valgrind --leak-check=yes \
>              --num-callers=50 ./vim --noplugin -u NONE 2> vg.log
>
> 2/ Enter the 2 following Ex commands:
>
>   :redir @"
>   :reg
>
> 3/ Observe in vg.log the following errors as soon as :reg is being
> executed:
>
> ==13408== Invalid read of size 1
> ==13408==    at 0x40276F8: memmove (mc_replace_strmem.c:517)
> ==13408==    by 0x813CDA1: str_to_reg (ops.c:6157)
> ==13408==    by 0x813CB6F: write_reg_contents_ex (ops.c:6052)
> ==13408==    by 0x813C9E1: write_reg_contents (ops.c:5981)
> ==13408==    by 0x8104C0E: redir_write (message.c:3046)
> ==13408==    by 0x8103034: msg_puts_attr_len (message.c:1803)
> ==13408==    by 0x8102715: msg_outtrans_len_attr (message.c:1402)
> ==13408==    by 0x810243D: msg_outtrans_len (message.c:1291)
> ==13408==    by 0x81398A3: ex_display (ops.c:4013)
> ==13408==    by 0x80A7548: do_one_cmd (ex_docmd.c:2627)
> ==13408==    by 0x80A4D7F: do_cmdline (ex_docmd.c:1096)
> ==13408==    by 0x8090CB8: call_user_func (eval.c:21292)
> ==13408==    by 0x807CE17: call_func (eval.c:8123)
> ==13408==    by 0x807CA5B: get_func_tv (eval.c:7969)
> ==13408==    by 0x8078DF3: eval7 (eval.c:5021)
> ==13408==    by 0x80786FC: eval6 (eval.c:4688)
> ==13408==    by 0x80782E8: eval5 (eval.c:4504)
> ==13408==    by 0x8077839: eval4 (eval.c:4199)
> ==13408==    by 0x8077691: eval3 (eval.c:4111)
> ==13408==    by 0x807751D: eval2 (eval.c:4040)
> ==13408==    by 0x807734D: eval1 (eval.c:3965)
> ==13408==    by 0x80772B4: eval0 (eval.c:3922)
> ==13408==    by 0x8073AC5: ex_let (eval.c:1837)
> ==13408==    by 0x80A7548: do_one_cmd (ex_docmd.c:2627)
> ==13408==    by 0x80A4D7F: do_cmdline (ex_docmd.c:1096)
> ==13408==    by 0x80A2FE3: do_source (ex_cmds2.c:3116)
> ==13408==    by 0x80EA44D: source_startup_scripts (main.c:2778)
> ==13408==    by 0x80E74DB: main (main.c:563)
> ==13408==  Address 0x548108c is 4 bytes inside a block of size 32 free'd
> ==13408==    at 0x4024E5A: free (vg_replace_malloc.c:323)
> ==13408==    by 0x8116C67: vim_free (misc2.c:1639)
> ==13408==    by 0x813CD7A: str_to_reg (ops.c:6155)
> ==13408==    by 0x813CB6F: write_reg_contents_ex (ops.c:6052)
> ==13408==    by 0x813C9E1: write_reg_contents (ops.c:5981)
> ==13408==    by 0x8104C0E: redir_write (message.c:3046)
> ==13408==    by 0x8103034: msg_puts_attr_len (message.c:1803)
> ==13408==    by 0x8102715: msg_outtrans_len_attr (message.c:1402)
> ==13408==    by 0x810243D: msg_outtrans_len (message.c:1291)
> ==13408==    by 0x81398A3: ex_display (ops.c:4013)
> ==13408==    by 0x80A7548: do_one_cmd (ex_docmd.c:2627)
> ==13408==    by 0x80A4D7F: do_cmdline (ex_docmd.c:1096)
> ==13408==    by 0x8090CB8: call_user_func (eval.c:21292)
> ==13408==    by 0x807CE17: call_func (eval.c:8123)
> ==13408==    by 0x807CA5B: get_func_tv (eval.c:7969)
> ==13408==    by 0x8078DF3: eval7 (eval.c:5021)
> ==13408==    by 0x80786FC: eval6 (eval.c:4688)
> ==13408==    by 0x80782E8: eval5 (eval.c:4504)
> ==13408==    by 0x8077839: eval4 (eval.c:4199)
> ==13408==    by 0x8077691: eval3 (eval.c:4111)
> ==13408==    by 0x807751D: eval2 (eval.c:4040)
> ==13408==    by 0x807734D: eval1 (eval.c:3965)
> ==13408==    by 0x80772B4: eval0 (eval.c:3922)
> ==13408==    by 0x8073AC5: ex_let (eval.c:1837)
> ==13408==    by 0x80A7548: do_one_cmd (ex_docmd.c:2627)
> ==13408==    by 0x80A4D7F: do_cmdline (ex_docmd.c:1096)
> ==13408==    by 0x80A2FE3: do_source (ex_cmds2.c:3116)
> ==13408==    by 0x80EA44D: source_startup_scripts (main.c:2778)
> ==13408==    by 0x80E74DB: main (main.c:563)
> (several more errors follow after that)
>
> The bug happens because function ex_display() is printing
> all registers and while doing so, a register can be modified
> if output is redirected to register (causing access to freed
> memory).
>
> Attached patch fixes it by making function ex_display()
> output a copy of the register. Please review it.
>
> I noticed this issue when trying Tony's .vimrc available at:
>   http://vim.wikia.com/wiki/User:Tonymec/vimrc
>
> The bug happens in function TestForX() in his vimrc file.

The patch introduces quite a bit of new code, copies text around and
allocates memory.

How about this solution instead:

*** ../vim-7.2.289/src/ops.c 2009-11-03 16:44:04.000000000 +0100
--- src/ops.c 2009-11-11 16:13:33.000000000 +0100
***************
*** 3990,3995 ****
--- 3990,4001 ----
  	 }
  	 else
  	     yb = &(y_regs[i]);
+
+  if (name == vim_tolower(redir_reg)
+ 	 || (redir_reg == '"' && yb == y_previous))
+ 	    continue;     /* do not list register being written to, the
+ 			     * pointer can be freed */
+
  	 if (yb->y_array != NULL)
  	 {
  	     msg_putchar('\n');


--
Mynd you, m00se bites Kan be pretty nasti ...
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// 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
-~----------~----~----~----~------~----~------~--~---

Patch 7.2.289
Problem:    Checking wrong struct member.
Solution:   Change tb_buf to tb_noremap. (Dominique Pelle)
Files:     src/getchar.c


*** ../vim-7.2.288/src/getchar.c 2009-09-30 15:15:33.000000000 +0200
--- src/getchar.c 2009-11-11 12:50:58.000000000 +0100
***************
*** 22,28 ****
    * These buffers are used for storing:
    * - stuffed characters: A command that is translated into another command.
    * - redo characters: will redo the last change.
!  * - recorded chracters: for the "q" command.
    *
    * The bytes are stored like in the typeahead buffer:
    * - K_SPECIAL introduces a special key (two more bytes follow).  A literal
--- 22,28 ----
    * These buffers are used for storing:
    * - stuffed characters: A command that is translated into another command.
    * - redo characters: will redo the last change.
!  * - recorded characters: for the "q" command.
    *
    * The bytes are stored like in the typeahead buffer:
    * - K_SPECIAL introduces a special key (two more bytes follow).  A literal
***************
*** 1283,1289 ****
  	 EMSG2(_(e_intern2), "Free typebuf 1");
       else
  	 vim_free(typebuf.tb_buf);
!     if (typebuf.tb_buf == noremapbuf_init)
  	 EMSG2(_(e_intern2), "Free typebuf 2");
       else
  	 vim_free(typebuf.tb_noremap);
--- 1283,1289 ----
  	 EMSG2(_(e_intern2), "Free typebuf 1");
       else
  	 vim_free(typebuf.tb_buf);
!     if (typebuf.tb_noremap == noremapbuf_init)
  	 EMSG2(_(e_intern2), "Free typebuf 2");
       else
  	 vim_free(typebuf.tb_noremap);
***************
*** 1516,1522 ****
    * wanted.
    * This translates escaped K_SPECIAL and CSI bytes to a K_SPECIAL or CSI byte.
    * Collects the bytes of a multibyte character into the whole character.
!  * Returns the modifers in the global "mod_mask".
    */
       int
   vgetc()
--- 1516,1522 ----
    * wanted.
    * This translates escaped K_SPECIAL and CSI bytes to a K_SPECIAL or CSI byte.
    * Collects the bytes of a multibyte character into the whole character.
!  * Returns the modifiers in the global "mod_mask".
    */
       int
   vgetc()
***************
*** 3320,3326 ****
  			     retval = 1;
  			     goto theend;
  			 }
! 	    /* An abbrevation cannot contain white space. */
  	     for (n = 0; n < len; ++n)
  		 if (vim_iswhite(keys[n]))
  		 {
--- 3320,3326 ----
  			     retval = 1;
  			     goto theend;
  			 }
! 	    /* An abbreviation cannot contain white space. */
  	     for (n = 0; n < len; ++n)
  		 if (vim_iswhite(keys[n]))
  		 {
***************
*** 4272,4278 ****

       /*
        * Check for word before the cursor: If it ends in a keyword char all
!      * chars before it must be al keyword chars or non-keyword chars, but not
        * white space. If it ends in a non-keyword char we accept any characters
        * before it except white space.
        */
--- 4272,4278 ----

       /*
        * Check for word before the cursor: If it ends in a keyword char all
!      * chars before it must be keyword chars or non-keyword chars, but not
        * white space. If it ends in a non-keyword char we accept any characters
        * before it except white space.
        */
*** ../vim-7.2.288/src/version.c 2009-11-11 15:06:59.000000000 +0100
--- src/version.c 2009-11-11 16:19:12.000000000 +0100
***************
*** 683,684 ****
--- 683,686 ----
   {   /* Add new patch number below this line */
+ /**/
+     289,
   /**/

--
A M00se once bit my sister ...
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// 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
-~----------~----~----~----~------~----~------~--~---

Patch 7.2.288
Problem:    Python 2.6 pyconfig.h redefines macros.
Solution:   Undefine the macros before including pyconfig.h.
Files:      src/if_python.c


*** ../vim-7.2.287/src/if_python.c 2009-11-03 11:43:05.000000000 +0100
--- src/if_python.c 2009-11-11 12:33:37.000000000 +0100
***************
*** 37,42 ****
--- 37,48 ----
   #ifdef HAVE_STDARG_H
   # undef HAVE_STDARG_H /* Python's config.h defines it as well. */
   #endif
+ #ifdef _POSIX_C_SOURCE
+ # undef _POSIX_C_SOURCE /* pyconfig.h defines it as well. */
+ #endif
+ #ifdef _XOPEN_SOURCE
+ # undef _XOPEN_SOURCE /* pyconfig.h defines it as well. */
+ #endif

   #define PY_SSIZE_T_CLEAN

*** ../vim-7.2.287/src/version.c 2009-11-11 14:45:36.000000000 +0100
--- src/version.c 2009-11-11 15:05:51.000000000 +0100
***************
*** 683,684 ****
--- 683,686 ----
   {   /* Add new patch number below this line */
+ /**/
+     288,
   /**/

--
I am always surprised in the Linux world how quickly solutions can be
obtained.  (Imagine sending an email to Bill Gates, asking why Windows
crashed, and how to fix it...  and then getting an answer that fixed the
problem... <0>_<0> !) 	              -- Mark Langdon

  /// 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
-~----------~----~----~----~------~----~------~--~---

Patch 7.2.287
Problem:    Warning from gcc 3.4 about uninitialized variable.
Solution:   Move assignment outside of #ifdef.
Files:     src/if_perl.xs


*** ../vim-7.2.286/src/if_perl.xs 2009-07-14 16:05:14.000000000 +0200
--- src/if_perl.xs 2009-11-11 12:29:32.000000000 +0100
***************
*** 720,727 ****
   #ifdef HAVE_SANDBOX
       if (sandbox)
       {
   # ifndef MAKE_TEST  /* avoid a warning for unreachable code */
!  if ((safe = perl_get_sv( "VIM::safe", FALSE )) == NULL || !SvTRUE(safe))
  	     EMSG(_("E299: Perl evaluation forbidden in sandbox without the Safe
module"));
  	 else
   # endif
--- 720,728 ----
   #ifdef HAVE_SANDBOX
       if (sandbox)
       {
+  safe = perl_get_sv( "VIM::safe", FALSE );
   # ifndef MAKE_TEST  /* avoid a warning for unreachable code */
!  if (safe == NULL || !SvTRUE(safe))
  	     EMSG(_("E299: Perl evaluation forbidden in sandbox without the Safe
module"));
  	 else
   # endif
*** ../vim-7.2.286/src/version.c 2009-11-11 14:21:48.000000000 +0100
--- src/version.c 2009-11-11 14:44:49.000000000 +0100
***************
*** 683,684 ****
--- 683,686 ----
   {   /* Add new patch number below this line */
+ /**/
+     287,
   /**/

--
The most powerful force in the universe is gossip.

  /// 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
-~----------~----~----~----~------~----~------~--~---

Patch 7.2.286 (after 7.2.269)
Problem:    The "--startuptime=<file>" argument is not consistent with other
	     arguments.
Solution:   Use "--startuptime <file>".  Added the +startuptime feature.
Files:     runtime/doc/eval.txt, runtime/doc/starting.txt,
	     runtime/doc/various.txt, src/eval.c, src/main.c, src/version.c


*** ../vim-7.2.285/runtime/doc/eval.txt 2009-04-22 12:53:31.000000000 +0200
--- runtime/doc/eval.txt 2009-11-11 13:01:58.000000000 +0100
***************
*** 5869,5874 ****
--- 5881,5887 ----
   signs 	 Compiled with |:sign| support.
   smartindent  Compiled with 'smartindent' support.
   sniff 	 Compiled with SNiFF interface support.
+ startuptime  Compiled with |--startuptime| support.
   statusline  Compiled with support for 'statusline', 'rulerformat'
  			 and special formats of 'titlestring' and 'iconstring'.
   sun_workshop  Compiled with support for Sun |workshop|.
*** ../vim-7.2.285/runtime/doc/starting.txt 2009-11-03 12:10:39.000000000 +0100
--- runtime/doc/starting.txt 2009-11-11 13:20:56.000000000 +0100
***************
*** 144,155 ****
  			 -u NORC 	 no 	    yes
  			 --noplugin  yes 	    no

! --startuptime={fname} 			 *--startuptime*
  		 During startup write timing messages to the file {fname}.
  		 This can be used to find out where time is spent while loading
! 	 your .vimrc and plugins.
  		 When {fname} already exists new messages are appended.
! 	 {only when compiled with this feature}

  							 *--literal*
   --literal Take file names literally, don't expand wildcards.  Not needed
--- 144,156 ----
  			 -u NORC 	 no 	    yes
  			 --noplugin  yes 	    no

! --startuptime {fname} 			 *--startuptime*
  		 During startup write timing messages to the file {fname}.
  		 This can be used to find out where time is spent while loading
! 	 your .vimrc, plugins and opening the first file.
  		 When {fname} already exists new messages are appended.
! 	 (Only available when compiled with the |+startuptime|
! 	 feature).

  							 *--literal*
   --literal Take file names literally, don't expand wildcards.  Not needed
*** ../vim-7.2.285/runtime/doc/various.txt 2009-07-09 15:55:34.000000000 +0200
--- runtime/doc/various.txt 2009-11-11 13:03:52.000000000 +0100
***************
*** 374,379 ****
--- 374,380 ----
   B  *+signs*  |:sign|
   N  *+smartindent* |'smartindent'|
   m  *+sniff*  SniFF interface |sniff|
+ N  *+startuptime* |--startuptime| argument
   N  *+statusline* Options 'statusline', 'rulerformat' and special
  			 formats of 'titlestring' and 'iconstring'
   m  *+sun_workshop* |workshop|
*** ../vim-7.2.285/src/eval.c 2009-11-03 14:26:29.000000000 +0100
--- src/eval.c 2009-11-11 12:59:53.000000000 +0100
***************
*** 11736,11741 ****
--- 11736,11744 ----
   #ifdef FEAT_SNIFF
  	 "sniff",
   #endif
+ #ifdef STARTUPTIME
+  "startuptime",
+ #endif
   #ifdef FEAT_STL_OPT
  	 "statusline",
   #endif
*** ../vim-7.2.285/src/main.c 2009-11-03 12:10:39.000000000 +0100
--- src/main.c 2009-11-08 12:57:46.000000000 +0100
***************
*** 204,212 ****
   #ifdef STARTUPTIME
       for (i = 1; i < argc; ++i)
       {
!  if (STRNICMP(argv[i], "--startuptime=", 14) == 0)
  	 {
! 	    time_fd = mch_fopen(argv[i] + 14, "a");
  	     TIME_MSG("--- VIM STARTING ---");
  	     break;
  	 }
--- 204,212 ----
   #ifdef STARTUPTIME
       for (i = 1; i < argc; ++i)
       {
!  if (STRICMP(argv[i], "--startuptime") == 0 && i + 1 < argc)
  	 {
! 	    time_fd = mch_fopen(argv[i + 1], "a");
  	     TIME_MSG("--- VIM STARTING ---");
  	     break;
  	 }
***************
*** 1726,1731 ****
--- 1726,1736 ----
  		     want_argument = TRUE;
  		     argv_idx += 3;
  		 }
+ 	 else if (STRNICMP(argv[0] + argv_idx, "startuptime", 11) == 0)
+ 	 {
+ 		    want_argument = TRUE;
+ 		    argv_idx += 11;
+ 	 }
   #ifdef FEAT_CLIENTSERVER
  		 else if (STRNICMP(argv[0] + argv_idx, "serverlist", 10) == 0)
  		     ; /* already processed -- no arg */
***************
*** 1761,1770 ****
  		     /* already processed, skip */
  		 }
   #endif
- 	 else if (STRNICMP(argv[0] + argv_idx, "startuptime", 11) == 0)
- 	 {
- 		    /* already processed, skip */
- 	 }
  		 else
  		 {
  		     if (argv[0][argv_idx])
--- 1766,1771 ----
***************
*** 2061,2067 ****
  		     mainerr(ME_GARBAGE, (char_u *)argv[0]);

  		 --argc;
! 	 if (argc < 1 && c != 'S')
  		     mainerr_arg_missing((char_u *)argv[0]);
  		 ++argv;
  		 argv_idx = -1;
--- 2062,2068 ----
  		     mainerr(ME_GARBAGE, (char_u *)argv[0]);

  		 --argc;
! 	 if (argc < 1 && c != 'S')  /* -S has an optional argument */
  		     mainerr_arg_missing((char_u *)argv[0]);
  		 ++argv;
  		 argv_idx = -1;
***************
*** 2102,2112 ****
  							     (char_u *)argv[0];
  		     break;

! 	 case '-': /* "--cmd {command}" execute command */
! 		    if (parmp->n_pre_commands >= MAX_ARG_CMDS)
! 		 mainerr(ME_EXTRA_CMD, NULL);
! 		    parmp->pre_commands[parmp->n_pre_commands++] =
  							     (char_u *)argv[0];
  		     break;

  	     /* case 'd':   -d {device} is handled in mch_check_win() for the
--- 2103,2118 ----
  							     (char_u *)argv[0];
  		     break;

! 	 case '-':
! 		    if (argv[-1][2] == 'c')
! 		    {
! 		 /* "--cmd {command}" execute command */
! 		 if (parmp->n_pre_commands >= MAX_ARG_CMDS)
! 			    mainerr(ME_EXTRA_CMD, NULL);
! 		 parmp->pre_commands[parmp->n_pre_commands++] =
  							     (char_u *)argv[0];
+ 		    }
+ 		    /* "--startuptime <file>" already handled */
  		     break;

  	     /* case 'd':   -d {device} is handled in mch_check_win() for the
***************
*** 3144,3149 ****
--- 3150,3158 ----
       main_msg(_("--serverlist\t\tList available Vim server names and exit"));
       main_msg(_("--servername <name>\tSend to/become the Vim server <name>"));
   #endif
+ #ifdef STARTUPTIME
+     main_msg(_("--startuptime=<file>\tWrite startup timing messages to
<file>"));
+ #endif
   #ifdef FEAT_VIMINFO
       main_msg(_("-i <viminfo>\t\tUse <viminfo> instead of .viminfo"));
   #endif
*** ../vim-7.2.285/src/version.c 2009-11-11 13:22:09.000000000 +0100
--- src/version.c 2009-11-11 14:17:28.000000000 +0100
***************
*** 494,499 ****
--- 494,504 ----
   #else
  	 "-sniff",
   #endif
+ #ifdef STARTUPTIME
+  "+startuptime",
+ #else
+  "-startuptime",
+ #endif
   #ifdef FEAT_STL_OPT
  	 "+statusline",
   #else
*** ../vim-7.2.285/src/version.c 2009-11-11 13:22:09.000000000 +0100
--- src/version.c 2009-11-11 14:17:28.000000000 +0100
***************
*** 678,679 ****
--- 683,686 ----
   {   /* Add new patch number below this line */
+ /**/
+     286,
   /**/

--
A fool must search for a greater fool to find admiration.

  /// 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
-~----------~----~----~----~------~----~------~--~---

Bram Moolenaar wrote:

> Dominique Pelle wrote:
...
>> 1279     void
>> 1280 free_typebuf()
>> 1281 {
>> 1282     if (typebuf.tb_buf == typebuf_init)
>> 1283         EMSG2(_(e_intern2), "Free typebuf 1");
>> 1284     else
>> 1285         vim_free(typebuf.tb_buf);
>> 1286     if (typebuf.tb_buf == noremapbuf_init)
>> 1287         EMSG2(_(e_intern2), "Free typebuf 2");
>> 1288     else
>> 1289         vim_free(typebuf.tb_noremap);
>> 1290 }
>>
>> Test at line 1286 is meant to test typebuf.tb_noremap
>> and not typebuf.tb_buf.  Attached patch fixes it.
>>
>> But the fix should just cause to have an error message
>> rather than trying to free something in .bss section.
>> So something else is wrong. Unfortunately, I have not
>> been to reproduce this error so it may be hard to track
>> down.  Perhaps someone can figure it out from the
>> above stack.
>
> Thanks for the fix.  But it indeed doesn't solve the problem you
> encountered.
>
> The stack shows:
>        a user defined Ex command: do_ucmd()
>        calling a user defined function: call_user_func()
>        invoking ":normal": ex_normal()
>
> Now there restoring typeahead fails.  Something in the ":normal" must
> have caused a problem, but we can't see what it was in the stack trace.
>
> I hope you find a way to reproduce the problem.


I'll add temporarily in my source tree (but not in CVS), at the
beginning of free_typebuf():

    assert(typebuf.tb_buf != typebuf_init);
    assert(typebuf.tb_noremap != noremapbuf_init);

... so that if it happens again, I'll have a core file to analyze with
gdb. Without asserts, it's too easy to not notice the errors.

Hopefully I'll then find a way to reproduce it.   Perhaps other
Vim developers can also put the asserts in case they manage
to reproduce it.

-- Dominique

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Patch 7.2.285 (after 7.2.169)
Problem:    CTRL-U in Insert mode also deletes indent. (Andrey Voropaev)
Solution:   Fix mistake made in patch 7.2.169.
Files:     src/edit.c


*** ../vim-7.2.284/src/edit.c 2009-07-09 18:15:19.000000000 +0200
--- src/edit.c 2009-11-05 20:25:15.000000000 +0100
***************
*** 8519,8525 ****
  	 {
  	     save_col = curwin->w_cursor.col;
  	     beginline(BL_WHITE);
! 	    if (curwin->w_cursor.col < (colnr_T)temp)
  		 mincol = curwin->w_cursor.col;
  	     curwin->w_cursor.col = save_col;
  	 }
--- 8519,8525 ----
  	 {
  	     save_col = curwin->w_cursor.col;
  	     beginline(BL_WHITE);
! 	    if (curwin->w_cursor.col < save_col)
  		 mincol = curwin->w_cursor.col;
  	     curwin->w_cursor.col = save_col;
  	 }
*** ../vim-7.2.284/src/version.c 2009-11-03 18:46:53.000000000 +0100
--- src/version.c 2009-11-11 13:21:25.000000000 +0100
***************
*** 678,679 ****
--- 683,686 ----
   {   /* Add new patch number below this line */
+ /**/
+     285,
   /**/

--
(letter from Mark to Mike, about the film's probable certificate)
       I would like to get back to the Censor and agree to lose the shits, take
       the odd Jesus Christ out and lose Oh fuck off, but to retain 'fart in
       your general direction', 'castanets of your testicles' and 'oral sex'
       and ask him for an 'A' rating on that basis.
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// 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 wrote:

> I saw the following error with Vim-7.2.284, which I can't reproduce
> unfortunately:
>
> ==31786== Invalid free() / delete / delete[]
> ==31786==    at 0x4024E5A: free (vg_replace_malloc.c:323)
> ==31786==    by 0x8116582: vim_free (misc2.c:1644)
> ==31786==    by 0x80D4E08: free_typebuf (getchar.c:1289)
> ==31786==    by 0x80D4FE6: restore_typeahead (getchar.c:1350)
> ==31786==    by 0x80B0DCA: ex_normal (ex_docmd.c:9103)
> ==31786==    by 0x80A6E60: do_one_cmd (ex_docmd.c:2629)
> ==31786==    by 0x80A4697: do_cmdline (ex_docmd.c:1098)
> ==31786==    by 0x80905D0: call_user_func (eval.c:21292)
> ==31786==    by 0x807C72F: call_func (eval.c:8123)
> ==31786==    by 0x807C373: get_func_tv (eval.c:7969)
> ==31786==    by 0x8075D74: ex_call (eval.c:3345)
> ==31786==    by 0x80A6E60: do_one_cmd (ex_docmd.c:2629)
> ==31786==    by 0x80A4697: do_cmdline (ex_docmd.c:1098)
> ==31786==    by 0x80AC7DA: do_ucmd (ex_docmd.c:6059)
> ==31786==    by 0x80A6E37: do_one_cmd (ex_docmd.c:2620)
> ==31786==    by 0x80A4697: do_cmdline (ex_docmd.c:1098)
> ==31786==    by 0x80A3BAA: do_exmode (ex_docmd.c:655)
> ==31786==    by 0x812BDF4: nv_exmode (normal.c:5182)
> ==31786==    by 0x8125554: normal_cmd (normal.c:1188)
> ==31786==    by 0x80E7A84: main_loop (main.c:1204)
> ==31786==    by 0x80E7577: main (main.c:948)
> ==31786==  Address 0x82223bc is in the BSS segment of
/home/pel/sb/vim7/src/vim
>
> Looking at code of free_typebuf() in getchar.c, I see
> something clearly wrong at line 1286:
>
> 1279     void
> 1280 free_typebuf()
> 1281 {
> 1282     if (typebuf.tb_buf == typebuf_init)
> 1283         EMSG2(_(e_intern2), "Free typebuf 1");
> 1284     else
> 1285         vim_free(typebuf.tb_buf);
> 1286     if (typebuf.tb_buf == noremapbuf_init)
> 1287         EMSG2(_(e_intern2), "Free typebuf 2");
> 1288     else
> 1289         vim_free(typebuf.tb_noremap);
> 1290 }
>
> Test at line 1286 is meant to test typebuf.tb_noremap
> and not typebuf.tb_buf.  Attached patch fixes it.
>
> But the fix should just cause to have an error message
> rather than trying to free something in .bss section.
> So something else is wrong. Unfortunately, I have not
> been to reproduce this error so it may be hard to track
> down.  Perhaps someone can figure it out from the
> above stack.

Thanks for the fix.  But it indeed doesn't solve the problem you
encountered.

The stack shows:
	 a user defined Ex command: do_ucmd()
	 calling a user defined function: call_user_func()
	 invoking ":normal": ex_normal()

Now there restoring typeahead fails.  Something in the ":normal" must
have caused a problem, but we can't see what it was in the stack trace.

I hope you find a way to reproduce the problem.

--
FATAL ERROR! SYSTEM HALTED! - Press any key to continue doing nothing.

  /// 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
-~----------~----~----~----~------~----~------~--~---

Dimitar Dimitrov wrote:

> I would like to report some unexpected behaviour:
>
> 1. :set path+=~/dev/**
> 2. :find test.c                         works
>
> 1. :set path+=~/dev
> 2. :find **/test.c                     doesn't work
>
> And yet, :h wildcard suggests that it should...
>
> Note: File in ~/dev/project/example/test.c

Where does it say that ":find **/test.c" should work?
It says ":n **/test.c" works, but that is not using 'path'.

Nevertheless, there is a todo item:

Patch for completion of ":find" arguments. (Nazri Ramliy, 2009 Feb 22, 26)
8   For ":find" and ":sfind" expand files found in 'path'.
Update 2009 Mar 28.

Perhaps that one makes it work as you expect.

--
(letter from Mark to Mike, about the film's probable certificate)
       For an 'A' we would have to: Lose as many shits as possible; Take Jesus
       Christ out, if possible; Loose "I fart in your general direction"; Lose
       "the oral sex"; Lose "oh, fuck off"; Lose "We make castanets out of your
       testicles"
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// 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
-~----------~----~----~----~------~----~------~--~---

Lech Lorens wrote:

> I would appreciate feedback on my modifications a lot and really hope
> for some comments. You might want to follow my test procedure:
>
> Enter the directory with Vim sources. Execute Vim:
> $ vim -p eval.c eval.c eval.c
> :tabdo set fdm=syntax fdc=5 number
> :normal 1gt
> :820
> :normal zO
>
> And then type the following (observe the fold column):
> Ofor (i =
>
> After inserting '(' with the official syntax highlighting file I need to
> wait a few seconds (sic!) before the screen is updated and "i ="
> appears.

On my machine, I had to wait 1 minute and 50 seconds (!) before I
could see "i = " (and Vim was using 100% of the CPU during that
time).  That's with Vim-7.2.284 built with -O0 on a Core-2, 1.7Ghz.


> With my modifications of c.vim Vim responds instantaneously
> (again: observe the difference in the fold column).

After applying your patch (c.vim.patch), I could see "i = "
instantaneously.

I normally don't use syntax folding, but if I did, I would most certainly
want to do it with your patch given the major speed up.


> This comes at a cost, however. While in case of the original syntax
> highlighting all the braces from the modification place to the end of
> the file would become highlighted as error, after my modifications only
> braces inside the current block get such highlighting. This is still
> quite visible if you open a parenthesis at line 820, but is not so any
> more if you do it at line 843.
>
> I am ready to accept such a trade-off as I rely very much on
> C-syntax-based folding and recently more and more often have been
> finding myself in situations where I input some code without getting any
> visual feedback from Vim (this happens on my new machine at work, even
> more on my old computer at home). I presume that there are others who
> are bothered by the same problem. Perhaps the behaviour I introduced to
> c.vim could be made into an option like c_no_curly_error or
> c_no_bracket_error.

I would also accept the trade-off, given the dramatic speed up.


> I would like also to describe the (erroneous in my opinion) behaviour of
> Vim I discovered while trying to improve c.vim. The version of c.vim
> that allows the problem to be reproduced can be obtained by applying the
> attached patch c.vim.patch.bad.

I did not check that yet.

Thanks
-- Dominique

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Hi

I saw the following error with Vim-7.2.284, which I can't reproduce
unfortunately:

==31786== Invalid free() / delete / delete[]
==31786==    at 0x4024E5A: free (vg_replace_malloc.c:323)
==31786==    by 0x8116582: vim_free (misc2.c:1644)
==31786==    by 0x80D4E08: free_typebuf (getchar.c:1289)
==31786==    by 0x80D4FE6: restore_typeahead (getchar.c:1350)
==31786==    by 0x80B0DCA: ex_normal (ex_docmd.c:9103)
==31786==    by 0x80A6E60: do_one_cmd (ex_docmd.c:2629)
==31786==    by 0x80A4697: do_cmdline (ex_docmd.c:1098)
==31786==    by 0x80905D0: call_user_func (eval.c:21292)
==31786==    by 0x807C72F: call_func (eval.c:8123)
==31786==    by 0x807C373: get_func_tv (eval.c:7969)
==31786==    by 0x8075D74: ex_call (eval.c:3345)
==31786==    by 0x80A6E60: do_one_cmd (ex_docmd.c:2629)
==31786==    by 0x80A4697: do_cmdline (ex_docmd.c:1098)
==31786==    by 0x80AC7DA: do_ucmd (ex_docmd.c:6059)
==31786==    by 0x80A6E37: do_one_cmd (ex_docmd.c:2620)
==31786==    by 0x80A4697: do_cmdline (ex_docmd.c:1098)
==31786==    by 0x80A3BAA: do_exmode (ex_docmd.c:655)
==31786==    by 0x812BDF4: nv_exmode (normal.c:5182)
==31786==    by 0x8125554: normal_cmd (normal.c:1188)
==31786==    by 0x80E7A84: main_loop (main.c:1204)
==31786==    by 0x80E7577: main (main.c:948)
==31786==  Address 0x82223bc is in the BSS segment of /home/pel/sb/vim7/src/vim

Looking at code of free_typebuf() in getchar.c, I see
something clearly wrong at line 1286:

1279     void
1280 free_typebuf()
1281 {
1282     if (typebuf.tb_buf == typebuf_init)
1283         EMSG2(_(e_intern2), "Free typebuf 1");
1284     else
1285         vim_free(typebuf.tb_buf);
1286     if (typebuf.tb_buf == noremapbuf_init)
1287         EMSG2(_(e_intern2), "Free typebuf 2");
1288     else
1289         vim_free(typebuf.tb_noremap);
1290 }

Test at line 1286 is meant to test typebuf.tb_noremap
and not typebuf.tb_buf.  Attached patch fixes it.

But the fix should just cause to have an error message
rather than trying to free something in .bss section.
So something else is wrong. Unfortunately, I have not
been to reproduce this error so it may be hard to track
down.  Perhaps someone can figure it out from the
above stack.

Cheers
-- Dominique

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Dominique Pelle wrote:

> While testing Vim-7.2.284 with arabic mode, I noticed the
> following error with Valgrind. Steps to reproduce are too
> complex to describe here, but I can reproduce all the time:
>
> ==31786== Conditional jump or move depends on uninitialised value(s)
> ==31786==    at 0x8120517: utfc_ptr2char (mbyte.c:1612)
> ==31786==    by 0x816EDFB: screen_puts_len (screen.c:6416)
> ==31786==    by 0x8103538: t_puts (message.c:2322)
> ==31786==    by 0x810305A: msg_puts_display (message.c:2079)
> ==31786==    by 0x81029CC: msg_puts_attr_len (message.c:1838)
> ==31786==    by 0x8102009: msg_outtrans_len_attr (message.c:1402)
> ==31786==    by 0x8101D31: msg_outtrans_len (message.c:1291)
> ==31786==    by 0x80BB20A: draw_cmdline (ex_getln.c:2677)
> ==31786==    by 0x80BBF64: redrawcmd (ex_getln.c:3163)
> ==31786==    by 0x80C1146: ex_window (ex_getln.c:6243)
> ==31786==    by 0x80B7EA3: getcmdline (ex_getln.c:736)
> ==31786==    by 0x812D672: nv_search (normal.c:6138)
> ==31786==    by 0x8125554: normal_cmd (normal.c:1188)
> ==31786==    by 0x80E7A84: main_loop (main.c:1204)
> ==31786==    by 0x80E7577: main (main.c:948)
>
> Attached patch fixes it by using utfc_ptr2char_len(...) rather
> than utfc_ptr2char(...)  (as was already done a few lines above
> in the same function).

Thanks!

--
"I love deadlines.  I especially like the whooshing sound they
make as they go flying by."
                          -- Douglas Adams

  /// 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
-~----------~----~----~----~------~----~------~--~---

Hi

While testing Vim-7.2.284 with arabic mode, I noticed the
following error with Valgrind. Steps to reproduce are too
complex to describe here, but I can reproduce all the time:

==31786== Conditional jump or move depends on uninitialised value(s)
==31786==    at 0x8120517: utfc_ptr2char (mbyte.c:1612)
==31786==    by 0x816EDFB: screen_puts_len (screen.c:6416)
==31786==    by 0x8103538: t_puts (message.c:2322)
==31786==    by 0x810305A: msg_puts_display (message.c:2079)
==31786==    by 0x81029CC: msg_puts_attr_len (message.c:1838)
==31786==    by 0x8102009: msg_outtrans_len_attr (message.c:1402)
==31786==    by 0x8101D31: msg_outtrans_len (message.c:1291)
==31786==    by 0x80BB20A: draw_cmdline (ex_getln.c:2677)
==31786==    by 0x80BBF64: redrawcmd (ex_getln.c:3163)
==31786==    by 0x80C1146: ex_window (ex_getln.c:6243)
==31786==    by 0x80B7EA3: getcmdline (ex_getln.c:736)
==31786==    by 0x812D672: nv_search (normal.c:6138)
==31786==    by 0x8125554: normal_cmd (normal.c:1188)
==31786==    by 0x80E7A84: main_loop (main.c:1204)
==31786==    by 0x80E7577: main (main.c:948)

Attached patch fixes it by using utfc_ptr2char_len(...) rather
than utfc_ptr2char(...)  (as was already done a few lines above
in the same function).

Cheers
-- Dominique

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---