Re: [PATCH] bumps CSCOPE_MAX_CONNECTIONS from 8 to 42
Robert Bragg wrote: Hi, So it turns out, I'm the only one in the world that wants more than 8 cscope connections, but I really do :-) I track / work with the source for several GNOME projects, and have my own builds for various common GNOME and freedesktop.org libraries which I have indexed via cscope and ctags. Since I don't want to reindex them for each application that I might be working on I maintain separate cscope.out files for each library, and by using a text file that declares the dependencies of each application I'm working on I get vim to add each of the relevent cscope.out files. In some cases this is more than 8, but it's less than 42 :-) Testing the following patch worked for me so it would be great if someone could apply this or a similar tweak to trunk. kind regards, - Robert If there is a legitimate use for more than 8 cscope connections, then I'd vote for dynamically allocated data structures, as long as it's simple, so that: - we do not depend on an arbitrary magic max value (8 or 42). Someone else might need more than 42 connections. - we not waste memory. It may not be much, but the vast majority of users only use 0 or 1 cscope connection(s), so 42 is overkill for most users. Cheers -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] counter intuitive behavior of PageDown, PageUp, BS, 'G' with |more-prompt|
Bram Moolenaar wrote: Dominique Pelle wrote: ...snip... I'm not sure whether this current behavior for PageDown is intentional or whether it is a bug. It looks like a bug and I think it should behave like pressing 'f'. In any case, it not documented in :help more-prompt. On the other hand, if there are only a couple of lines of output, then it's perhaps more logical that the PageDown is taken as the next command, thus scrolls down the text of the window. ...snip... OK, I guess I just trained myself to use the wrong keys: PageDown and PageUp instead of 'f' and 'b' to browse through long command output page by page. It's time for me to change my old habits and start using 'f' and 'b' for this. But :help message.txt doesn't describe anywhere the subtle difference between PageDown and 'f'. That explains why I got into the bad habit of using PageDown and was confused. I suspect I must not be the only one, since pressing PageDown is probably more natural than pressing 'f'. I currently see in :help messages: = - Pressing 'j', 'd' or Down is ignored when messages scrolled off the top of the screen, 'compatible' is off and 'more' is on, to avoid that typing one 'j' too many causes the messages to disappear. = It should also say that pressing 'f' is also ignored in such case. See the source code in message.c: 978 else if (msg_scrolled Rows - 2 979(c == 'j' || c == K_DOWN || c == 'd' || c == 'f')) 980 c = K_IGNORE; How about attached patch to fix documentation? Regards -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- *** ../vim-runtime/doc/message.txt 2009-02-22 22:51:56.0 +0100 --- doc/message.txt 2009-04-19 18:36:53.0 +0200 *** *** 758,766 - Press 'k', Up, 'u', 'b' or 'g' to scroll back in the messages. This works the same way as at the |more-prompt|. Only works when 'compatible' is off and 'more' is on. ! - Pressing 'j', 'd' or Down is ignored when messages scrolled off the top !of the screen, 'compatible' is off and 'more' is on, to avoid that typing !one 'j' too many causes the messages to disappear. - Press C-Y to copy (yank) a modeless selection to the clipboard register. - Use a menu. The characters defined for Cmdline-mode are used. - When 'mouse' contains the 'r' flag, clicking the left mouse button works --- 758,766 - Press 'k', Up, 'u', 'b' or 'g' to scroll back in the messages. This works the same way as at the |more-prompt|. Only works when 'compatible' is off and 'more' is on. ! - Pressing 'j', 'f', 'd' or Down is ignored when messages scrolled off the !top of the screen, 'compatible' is off and 'more' is on, to avoid that !typing one 'j' too many causes the messages to disappear. - Press C-Y to copy (yank) a modeless selection to the clipboard register. - Use a menu. The characters defined for Cmdline-mode are used. - When 'mouse' contains the 'r' flag, clicking the left mouse button works
[patch] fixed memory leak in Ex command :fu[nction] /{pattern}
Hi
Valgrind memory checker detects the following memory leak in Vim-7.2.148:
==26113== 36 bytes in 1 blocks are definitely lost in loss record 23 of 41
==26113==at 0x402603E: malloc (vg_replace_malloc.c:207)
==26113==by 0x8113A62: lalloc (misc2.c:866)
==26113==by 0x8158375: vim_regcomp (regexp.c:1021)
==26113==by 0x808CE03: ex_function (eval.c:19765)
==26113==by 0x80A6807: do_one_cmd (ex_docmd.c:2622)
==26113==by 0x80A4087: do_cmdline (ex_docmd.c:1096)
==26113==by 0x8129E72: nv_colon (normal.c:5218)
==26113==by 0x81234D6: normal_cmd (normal.c:1189)
==26113==by 0x80E6655: main_loop (main.c:1180)
==26113==by 0x80E61A2: main (main.c:939)
Leak happens whenever typing Ex command :fu[nction] /{pattern}
which lists function names matching {pattern}.
For example, this will cause a memory leak:
$ vim -u NONE
:function! Foo
:endfunction
:function /F
Attached patch fixes it.
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: eval.c
===
RCS file: /cvsroot/vim/vim7/src/eval.c,v
retrieving revision 1.280
diff -c -r1.280 eval.c
*** eval.c 4 Feb 2009 15:27:06 - 1.280
--- eval.c 18 Apr 2009 07:30:06 -
***
*** 19780,19785
--- 19780,19786
list_func_head(fp, FALSE);
}
}
+ vim_free(regmatch.regprog);
}
}
if (*p == '/')
[patch] counter intuitive behavior of PageDown, PageUp, BS, 'G' with |more-prompt|
Hi
When output of a Vim commands spans multiple screens, it is
possible to press 'f', PageDown or Space to move down
page by page until the bottom of the output. But the keys
behave differently when reaching the bottom of the output:
- pressing 'f' will stop at the prompt Press ENTER or
type command to continue when reaching the bottom of the
output.
- pressing Space or PageDown will quit when reaching
the bottom of the output.
I often press PageUp, PageDown to scroll page by page
since it's the most intuitive keys for this purpose. But the
default behavior to quit when reaching the bottom is rather
counter intuitive and can be irritating (list is then lost).
Here is an example to illustrate it:
# Open many files in Vim...
$ cd vim7/src/ ; vim *.[ch]
# List all buffers and show output page by page...
:ls
(then press PageDown to go through the output of :ls
command page by page, notice that pressing PageDown
at the bottom quits from the output of command).
I'm not sure whether this current behavior for PageDown is
intentional or whether it is a bug. It looks like a bug and I
think it should behave like pressing 'f'. In any case, it not
documented in :help more-prompt.
But even more counter-intuitive:
- pressing PageUp moves page by page upward (good) when
pressed at the bottom (i.e. when seeing Press ENTER or
type command to continue), then pressing PageUp will
quit the output (!?)
- pressing BS moves one line up but when when pressed
at the bottom it causes to quit the output (counter-intuitive).
- pressing 'g' goes to the top and pressing 'G' goes to the
bottom. When when pressing 'G' while at the bottom, it
causes to quit the output (counter-intuitive).
Attached patch (from Vim-7.2.148) makes the following simple
changes:
- pressing PageDown, PageUp, BS, 'G' no longer exits
when pressed at the bottom of message output.
- updated documentation (doc/message.txt) to clarify expected
behavior which was unclear for those keys.
Patch makes those keys more user friendly in my opinion.
Let me know what you think of the patch.
Regards
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: src/message.c
===
RCS file: /cvsroot/vim/vim7/src/message.c,v
retrieving revision 1.70
diff -c -r1.70 message.c
*** src/message.c 24 Feb 2009 03:37:45 - 1.70
--- src/message.c 18 Apr 2009 17:08:33 -
***
*** 959,965
*/
if (p_more !p_cp)
{
! if (c == 'b' || c == 'k' || c == 'u' || c == 'g' || c == K_UP)
{
/* scroll back to show older messages */
do_more_prompt(c);
--- 959,966
*/
if (p_more !p_cp)
{
! if (c == 'b' || c == 'k' || c == 'u' || c == 'g'
! || c == K_BS || c == K_UP || c == K_PAGEUP)
{
/* scroll back to show older messages */
do_more_prompt(c);
***
*** 976,982
}
}
else if (msg_scrolled Rows - 2
! (c == 'j' || c == K_DOWN || c == 'd' || c == 'f'))
c = K_IGNORE;
}
} while ((had_got_int c == Ctrl_C)
--- 977,984
}
}
else if (msg_scrolled Rows - 2
! (c == 'j' || c == K_DOWN || c == K_PAGEDOWN
! || c == 'd' || c == 'f' || c == 'G'))
c = K_IGNORE;
}
} while ((had_got_int c == Ctrl_C)
*** ../vim-runtime/doc/message.txt 2009-02-22 22:51:56.0 +0100
--- doc/message.txt 2009-04-18 19:04:09.0 +0200
***
*** 755,766
- Press Enter or Space to redraw the screen and continue, without that
key being used otherwise.
- Press ':' or any other Normal mode command character to start that command.
! - Press 'k', Up, 'u', 'b' or 'g' to scroll back in the messages. This
!works the same way as at the |more-prompt|. Only works when 'compatible'
!is off and 'more' is on.
! - Pressing 'j', 'd' or Down is ignored when messages scrolled off the top
!of the screen, 'compatible' is off and 'more' is on, to avoid that typing
!one 'j' too many causes the messages to disappear.
- Press C-Y to copy (yank) a modeless selection to the clipboard register.
- Use a menu. The characters defined for Cmdline-mode are used.
- When 'mouse' contains the 'r' flag, clicking the left mouse button works
--- 755,766
- Press Enter or Space to redraw the screen and continue, without that
key being used otherwise.
- Press ':' or any other Normal mode command character to start that command.
! - Press 'k', BS, Up, PageUp, 'u', 'b' or 'g' to scroll back in the
!messages. This works the same way as at the |more-prompt|. Only works
!when 'compatible' is off and 'more' is on.
! - Pressing 'j', 'd', 'f', Down, PageDown or 'G' is ignored when messages
!scrolled
[patch] fixed access beyond end of string in search.c
Hi
I can reproduce the following error with Vim-7.2.148 using
Valgrind memory checker. The steps to reproduce the error
are too complicated to detail here. I have not found a
simple test case but I can reproduce the problem 100% of
the time.
==15886== Invalid read of size 1
==15886==at 0x81796E9: find_pattern_in_path (search.c:5117)
==15886==by 0x8069229: ins_compl_get_exp (edit.c:4015)
==15886==by 0x8069F0A: ins_compl_next (edit.c:4434)
==15886==by 0x806B19C: ins_complete (edit.c:5066)
==15886==by 0x8064FDA: edit (edit.c:1343)
==15886==by 0x812F640: invoke_edit (normal.c:)
==15886==by 0x812F5E6: nv_edit (normal.c:8861)
==15886==by 0x8122E06: normal_cmd (normal.c:1189)
==15886==by 0x80E62C1: main_loop (main.c:1180)
==15886==by 0x80E5E0E: main (main.c:939)
==15886== Address 0x61d1ad8 is 0 bytes after a block of size 4,096 alloc'd
==15886==at 0x402603E: malloc (vg_replace_malloc.c:207)
==15886==by 0x811366E: lalloc (misc2.c:866)
==15886==by 0x811358A: alloc (misc2.c:765)
==15886==by 0x80F351C: mf_alloc_bhdr (memfile.c:973)
==15886==by 0x80F2B3C: mf_new (memfile.c:395)
==15886==by 0x80F897D: ml_new_data (memline.c:3164)
==15886==by 0x80F3FBB: ml_open (memline.c:373)
==15886==by 0x8052C60: open_buffer (buffer.c:85)
==15886==by 0x8097AD3: do_ecmd (ex_cmds.c:3655)
==15886==by 0x80ADE5F: do_exedit (ex_docmd.c:7569)
==15886==by 0x80ADAB7: ex_open (ex_docmd.c:7454)
==15886==by 0x80A6527: do_one_cmd (ex_docmd.c:2622)
==15886==by 0x80A3DA7: do_cmdline (ex_docmd.c:1096)
==15886==by 0x80A32BA: do_exmode (ex_docmd.c:653)
==15886==by 0x81296C8: nv_exmode (normal.c:5176)
==15886==by 0x8122E06: normal_cmd (normal.c:1189)
==15886==by 0x80E62C1: main_loop (main.c:1180)
==15886==by 0x80E5E0E: main (main.c:939)
The code in search.c is as follows:
5117 if (def_regmatch.regprog == NULL
5118 #ifdef FEAT_INS_EXPAND
5119 action == ACTION_EXPAND
5120 !(compl_cont_status CONT_SOL)
5121 #endif
5122 *(p = startp + 1))
5123 goto search_line;
Adding some debug printf, I see that bug happens when
dereferencing 'startp + 1'. Pointer startp is already at
the end of the string, *startp is NUL, and *(startp + 1)
is thus 1 byte beyond the end of the string, causing
invalid memory access.
Before error is detected, startp was initialized at
line 4870:
4866else if (regmatch.regprog != NULL
4867 vim_regexec(regmatch, line, (colnr_T)(p - line)))
4868{
4869matched = TRUE;
4870startp = regmatch.startp[0];
Putting a printf() there, I could see that line had an empty
length [strlen(line) is 0] and 'p - line' is 0. *startp is NUL.
Attached patch fixes it (plus some typos). However,
function find_pattern_in_path() in quite complicated so
please review the fix.
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: search.c
===
RCS file: /cvsroot/vim/vim7/src/search.c,v
retrieving revision 1.68
diff -c -r1.68 search.c
*** search.c 18 Jul 2008 10:05:58 - 1.68
--- search.c 8 Apr 2009 19:45:49 -
***
*** 2327,2333
for (col = pos.col; check_prevcol(linep, col, '\\', col);)
bslcnt++;
}
! /* Only accept a match when 'M' is in 'cpo' or when ecaping is
* what we expect. */
if (cpo_bsl || (bslcnt 1) == match_escaped)
{
--- 2327,2333
for (col = pos.col; check_prevcol(linep, col, '\\', col);)
bslcnt++;
}
! /* Only accept a match when 'M' is in 'cpo' or when escaping is
* what we expect. */
if (cpo_bsl || (bslcnt 1) == match_escaped)
{
***
*** 4663,4669
msg_putchar('\n'); /* cursor below last one */
if (!got_int) /* don't display if 'q'
typed at --more--
! mesage */
{
msg_home_replace_hl(new_fname);
MSG_PUTS(_( (includes previously listed match)));
--- 4663,4669
msg_putchar('\n'); /* cursor below last one */
if (!got_int) /* don't display if 'q'
typed at --more--
! message */
{
msg_home_replace_hl(new_fname);
MSG_PUTS(_( (includes previously listed match)));
***
*** 4975,4981
|| IObuff[i-2] == '!'
IObuff[i++] = ' ';
}
! /* copy as much as posible of the new word */
if (p - aux = IOSIZE - i)
p = aux + IOSIZE - i - 1;
STRNCPY(IObuff + i, aux, p - aux);
--- 4975,4981
|| IObuff[i-2] == '!'
IObuff[i++] = ' ';
}
! /* copy as much as possible of the new word */
if (p - aux = IOSIZE - i)
p = aux +
[patch] fixed buglet in :history a
In :help :history, I see...
:his[tory] [{name}] [{first}][, [{last}]]
List the contents of history {name} which can be:
c[md]or : command-line history
s[earch] or / search string history
e[xpr] or = expression register history
i[nput] or @ input line history
d[ebug] ordebug command history
a[ll] all of the above
So according the the help file, :history a should behave
the same as :history all. But if I type :history a
instead of :history all, I get an error:
E488: Trailing characters
Attached patch fixes it.
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: ex_getln.c
===
RCS file: /cvsroot/vim/vim7/src/ex_getln.c,v
retrieving revision 1.98
diff -c -r1.98 ex_getln.c
*** ex_getln.c 18 Mar 2009 11:52:47 - 1.98
--- ex_getln.c 11 Apr 2009 19:56:13 -
***
*** 5686,5692
histype1 = get_histtype(arg);
if (histype1 == -1)
{
! if (STRICMP(arg, all) == 0)
{
histype1 = 0;
histype2 = HIST_COUNT-1;
--- 5686,5692
histype1 = get_histtype(arg);
if (histype1 == -1)
{
! if (STRNICMP(arg, all, STRLEN(arg)) == 0)
{
histype1 = 0;
histype2 = HIST_COUNT-1;
Re: [patch] Titles for quickfix / location list windows
Lech Lorens wrote: The attached patch makes the quickfix / location list window's title reflect the command that yielded the error list. Additionally, two commands have been added: :cse[ttitle] :lse[ttitle] Additional attached patch adds documentation of :csettitle and :lsettitle to doc/index.txt and doc/cmdline.txt. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- *** cmdline.txt.org 2009-03-25 08:21:21.0 +0100 --- cmdline.txt 2009-03-25 08:21:20.0 +0100 *** *** 498,503 --- 498,504 :bufdo :command :cscope + :csettitle :debug :folddoopen :folddoclosed *** *** 506,511 --- 507,513 :help :helpfind :lcscope + :lsettitle :make :normal :perl *** index.txt.org 2009-03-25 08:17:15.0 +0100 --- index.txt 2009-03-25 08:20:03.0 +0100 *** *** 1147,1152 --- 1147,1153 |:cquit| :cq[uit] quit Vim with an error code |:crewind| :cr[ewind] go to the specified error, default first one |:cscope| :cs[cope] execute cscope command + |:csettitle| :cse[ttitle] change the title of the quickfix window |:cstag| :cst[ag] use cscope to jump to a tag |:cunmap| :cu[nmap] like :unmap but for Command-line mode |:cunabbrev| :cuna[bbrev] like :unabbrev but for Command-line mode *** *** 1296,1301 --- 1297,1303 |:lpfile| :lpf[ile] go to last location in previous file |:lrewind| :lr[ewind] go to the specified location, default first one |:ls| :ls list all buffers + |:lsettitle| :lse[ttitle] like :csettitle but use the location list |:ltag| :lt[ag] jump to tag and add matching tags to the location list |:lunmap| :lu[nmap] like :unmap! but includes Lang-Arg mode
Re: Fwd: [wish] different statusline format for noncurrent statusline
Tony Mechelynck wrote:
On 19/03/09 13:08, Yakov Lerner wrote:
On Tue, Mar 17, 2009 at 12:41, Yakov Lerneriler...@gmail.com wrote:
We have separae highlighting, StatusLineNC, for non-current.
I wish I had different *format*, too, for noncurrent statusline. I do not
think differnt format for non-current statusline is supported.
Is it possible to put this request in todo. Thanks.
Found how to make it in current vim.
Sorry for the noise. Took me time to figure it, works fine.
letstatusline=Your favourite statusline
let g:Active_statusline=g:statusline
let g:NCstatusline = %%F non-current statusline
au WinEnter * letl:statusline = g:Active_statusline
au WinLeave * letl:statusline = g:NCstatusline
Yakov
Wow! Hadn't realized it was global-local. :thumbsup:
Best regards,
Tony.
Agreed, that's quite a nice tip.
I ended up using it to change the colors of the active vs inactive
statusline in my already fancy statusline settings:
Colors of active statusline
hi User1 guifg=#66ff66 guibg=#008000 gui=bold term=standout
cterm=bold ctermfg=lightgreen ctermbg=lightgreen
hi User2 guifg=#60 guibg=#008000 gui=bold term=none cterm=bold
ctermfg=yellow ctermbg=lightgreen
Colors or inactive statusline
hi User3 guifg=#66ff66 guibg=#008000 gui=bold term=standout
cterm=bold ctermfg=lightgreen ctermbg=lightgreen
hi User4 guifg=#66ff66 guibg=#008000 gui=bold term=none cterm=bold
ctermfg=lightgreen ctermbg=lightgreen
Function used to display syntax group.
function! SyntaxItem()
return synIDattr(synID(line(.),col(.),1),name)
endfunction
Function used to display utf-8 sequence.
function! ShowUtf8Sequence()
let p = getpos('.')
redir = utfseq
sil normal! g8
redir End
call setpos('.', p)
return substitute(matchstr(utfseq, '\x\+ .*\x'), '\\x', '0x', 'g')
endfunction
if has('statusline')
if version = 700
Fancy status line.
set statusline =
set statusline+=%#User1#highlighting
set statusline+=%-2.2n\ buffer number
set statusline+=%#User2#highlighting
set statusline+=%f\ file name
set statusline+=%#User1#highlighting
set statusline+=%h%m%r%w\ flags
set statusline+=%{(key==\\?\\:\encr,\)} encrypted?
set statusline+=%{strlen(ft)?ft:'none'}, file type
set statusline+=%{(fenc==\\?enc:fenc)},encoding
set statusline+=%{((exists(\+bomb\)\ \ bomb)?\B,\:\\)} BOM
set statusline+=%{fileformat}, file format
set statusline+=%{spelllang}, spell language
set statusline+=%{SyntaxItem()} syntax group under cursor
set statusline+=%= indent right
set statusline+=%#User2#highlighting
set statusline+=%{ShowUtf8Sequence()}\ utf-8 sequence
set statusline+=%#User1#highlighting
set statusline+=0x%B\ char under cursor
set statusline+=%-6.(%l,%c%V%)\ %%Pposition
Use different colors for statusline in current and non-current window.
let g:Active_statusline=g:statusline
let g:NCstatusline=substitute(
\substitute(g:Active_statusline,
\'User1', 'User3', 'g'),
\'User2', 'User4', 'g')
au WinEnter * letl:statusline = g:Active_statusline
au WinLeave * letl:statusline = g:NCstatusline
endif
endif
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
[patch] unitialized value returned by a couple of vim functions + doc fixes
1/ According to :help functions, function cursor() is meant
to return a value of type 'Number'. But function cursor()
(f_cursor() in eval.c) does not return anything. So doing
:echo cursor(1,1) prints an uninitialized value and valgrind
reports the following error:
==20458== Use of uninitialised value of size 4
==20458==at 0x4F9A7F6: (within /lib/tls/i686/cmov/libc-2.8.90.so)
==20458==by 0x4F9E398: vfprintf (in /lib/tls/i686/cmov/libc-2.8.90.so)
==20458==by 0x4FBE02B: vsprintf (in /lib/tls/i686/cmov/libc-2.8.90.so)
==20458==by 0x4FA5D3A: sprintf (in /lib/tls/i686/cmov/libc-2.8.90.so)
==20458==by 0x80932DE: get_tv_string_buf_chk (stdio2.h:34)
==20458==by 0x809334A: get_tv_string_buf (eval.c:18752)
==20458==by 0x8094A71: echo_string (eval.c:7290)
==20458==by 0x80AD37E: ex_echo (eval.c:19507)
==20458==by 0x80CCA86: do_one_cmd (ex_docmd.c:2622)
==20458==by 0x80CAD92: do_cmdline (ex_docmd.c:1096)
==20458==by 0x8142E0F: nv_colon (normal.c:5218)
==20458==by 0x8144EAF: normal_cmd (normal.c:1189)
==20458==by 0x81044D6: main_loop (main.c:1180)
==20458==by 0x81078B2: main (main.c:939)
Attached patch makes cursor() return 0 if success, -1 if failure.
2/ Function setpos() returns 'none' according to :help functions
but looking at the code, it actually returns 0 in case of success
and -1 in case of error.
Patch fixes documentation.
3/ Function complete() returns a String according to :help functions
but it may return something initialized in case of error.
:echo complete('', '') for example prints something uninitialized
and valgrind also reports an error.
Patch makes it return an empty string in case of error.
4/ Function feedkeys() always returns 0 according to :help feedkeys()
but it may return something uninitialized when doing:
:sandbox echo feedkeys('')
Attached patch makes it always return 0 as stated in documentation.
5/ The following functions do not return anything:
clearmatches()
garbagecollect()
winrestview()
So doing :echo garbagecollect() prints something uninitialized
and valgrind reports uninitialized memory access.
Making them return something is better I think. So
:echo garbagecollect() prints something deterministic.
Attached patch makes them always return 0, just like what
is already done for feedkeys().
Regards
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: src/eval.c
===
RCS file: /cvsroot/vim/vim7/src/eval.c,v
retrieving revision 1.280
diff -c -r1.280 eval.c
*** src/eval.c 4 Feb 2009 15:27:06 - 1.280
--- src/eval.c 21 Mar 2009 20:41:21 -
***
*** 1285,1291
--- 1285,1293
typval_T tv;
char_u *retval;
garray_T ga;
+ #ifdef FEAT_FLOAT
char_u numbuf[NUMBUFLEN];
+ #endif
if (eval0(arg, tv, nextcmd, TRUE) == FAIL)
retval = NULL;
***
*** 8859,8864
--- 8861,8867
typval_T *argvars;
typval_T *rettv;
{
+ rettv-vval.v_number = 0;
#ifdef FEAT_SEARCH_EXTRA
clear_matches(curwin);
#endif
***
*** 8929,8934
--- 8932,8940
{
int startcol;
+ rettv-v_type = VAR_STRING;
+ rettv-vval.v_string = NULL;
+
if ((State INSERT) == 0)
{
EMSG(_(E785: complete() can only be used in Insert mode));
***
*** 9189,9195
/*
* cursor(lnum, col) function
*
! * Moves the cursor to the specified line and column
*/
/*ARGSUSED*/
static void
--- 9195,9202
/*
* cursor(lnum, col) function
*
! * Moves the cursor to the specified line and column.
! * Returns 0 when the position could be set, -1 otherwise.
*/
/*ARGSUSED*/
static void
***
*** 9202,9207
--- 9209,9215
long coladd = 0;
#endif
+ rettv-vval.v_number = -1;
if (argvars[1].v_type == VAR_UNKNOWN)
{
pos_T pos;
***
*** 9246,9251
--- 9254,9260
#endif
curwin-w_set_curswant = TRUE;
+ rettv-vval.v_number = 0;
}
/*
***
*** 9727,9739
int typed = FALSE;
char_u *keys_esc;
/* This is not allowed in the sandbox. If the commands would still be
* executed in the sandbox it would be OK, but it probably happens later,
* when sandbox is no longer set. */
if (check_secure())
return;
- rettv-vval.v_number = 0;
keys = get_tv_string(argvars[0]);
if (*keys != NUL)
{
--- 9736,9749
int typed = FALSE;
char_u *keys_esc;
+ rettv-vval.v_number = 0;
+
/* This is not allowed in the sandbox. If the commands would still be
* executed in the sandbox it would be OK, but it probably happens later,
* when sandbox is no
[patch] completion for :scscope and :lcscope
Recent patch 7.2.143 introduced completion for the :cscope command.
Attached patch improves completion further to also add completion for
the :lcscope and :scscope commands:
:lcscope completion is identical to :cscope
:scscope completion restricts to subcommands which can run in split window.
Regards
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: if_cscope.c
===
RCS file: /cvsroot/vim/vim7/src/if_cscope.c,v
retrieving revision 1.35
diff -c -r1.35 if_cscope.c
*** if_cscope.c 18 Mar 2009 13:32:24 - 1.35
--- if_cscope.c 20 Mar 2009 23:00:56 -
***
*** 98,103
--- 98,104
static enum
{
EXP_CSCOPE_SUBCMD, /* expand :cscope sub-commands */
+ EXP_SCSCOPE_SUBCMD, /* expand :scscope sub-commands */
EXP_CSCOPE_FIND, /* expand :cscope find arguments */
EXP_CSCOPE_KILL /* expand :cscope kill arguments */
} expand_what;
***
*** 112,123
--- 113,135
expand_T *xp;
int idx;
{
+ int current_idx;
+ int i;
+
switch (expand_what)
{
case EXP_CSCOPE_SUBCMD:
/* Complete with sub-commands of :cscope:
* add, find, help, kill, reset, show */
return (char_u *)cs_cmds[idx].name;
+ case EXP_SCSCOPE_SUBCMD:
+ /* Complete with sub-commands of :scscope: same sub-commands as
+ * :cscope but skip commands which don't support split windows */
+ for (i = 0, current_idx = 0; cs_cmds[i].name != NULL; i++)
+ if (cs_cmds[i].cansplit)
+ if (current_idx++ == idx)
+ break;
+ return (char_u *)cs_cmds[i].name;
case EXP_CSCOPE_FIND:
{
const char *query_type[] =
***
*** 133,147
}
case EXP_CSCOPE_KILL:
{
- int i;
- int current_idx = 0;
static char_u connection[2];
/* :cscope kill accepts connection numbers or partial names of
* the pathname of the cscope database as argument. Only complete
* with connection numbers. -1 can also be used to kill all
* connections. */
! for (i = 0; i CSCOPE_MAX_CONNECTIONS; i++)
{
if (csinfo[i].fname == NULL)
continue;
--- 145,157
}
case EXP_CSCOPE_KILL:
{
static char_u connection[2];
/* :cscope kill accepts connection numbers or partial names of
* the pathname of the cscope database as argument. Only complete
* with connection numbers. -1 can also be used to kill all
* connections. */
! for (i = 0, current_idx = 0; i CSCOPE_MAX_CONNECTIONS; i++)
{
if (csinfo[i].fname == NULL)
continue;
***
*** 165,180
* Handle command line completion for :cscope command.
*/
void
! set_context_in_cscope_cmd(xp, arg)
expand_T *xp;
char_u *arg;
{
char_u *p;
/* Default: expand subcommands */
xp-xp_context = EXPAND_CSCOPE;
- expand_what = EXP_CSCOPE_SUBCMD;
xp-xp_pattern = arg;
/* (part of) subcommand already typed */
if (*arg != NUL)
--- 175,192
* Handle command line completion for :cscope command.
*/
void
! set_context_in_cscope_cmd(xp, arg, cmdidx)
expand_T *xp;
char_u *arg;
+ cmdidx_T cmdidx;
{
char_u *p;
/* Default: expand subcommands */
xp-xp_context = EXPAND_CSCOPE;
xp-xp_pattern = arg;
+ expand_what = (cmdidx == CMD_scscope)
+ ? EXP_SCSCOPE_SUBCMD : EXP_CSCOPE_SUBCMD;
/* (part of) subcommand already typed */
if (*arg != NUL)
Index: ex_docmd.c
===
RCS file: /cvsroot/vim/vim7/src/ex_docmd.c,v
retrieving revision 1.169
diff -c -r1.169 ex_docmd.c
*** ex_docmd.c 18 Mar 2009 11:52:27 - 1.169
--- ex_docmd.c 20 Mar 2009 23:01:01 -
***
*** 3685,3691
break;
#ifdef FEAT_CSCOPE
case CMD_cscope:
! set_context_in_cscope_cmd(xp, arg);
break;
#endif
#ifdef FEAT_LISTCMDS
--- 3685,3693
break;
#ifdef FEAT_CSCOPE
case CMD_cscope:
! case CMD_lcscope:
! case CMD_scscope:
! set_context_in_cscope_cmd(xp, arg, ea.cmdidx);
break;
#endif
#ifdef FEAT_LISTCMDS
Index: proto/if_cscope.pro
===
RCS file: /cvsroot/vim/vim7/src/proto/if_cscope.pro,v
retrieving revision 1.5
diff -c -r1.5 if_cscope.pro
*** proto/if_cscope.pro 18 Mar 2009 11:52:12 - 1.5
--- proto/if_cscope.pro 20 Mar 2009 23:01:01 -
***
*** 1,6
/* if_cscope.c */
char_u *get_cscope_name __ARGS((expand_T *xp, int idx));
! void set_context_in_cscope_cmd __ARGS((expand_T *xp, char_u *arg));
void do_cscope __ARGS((exarg_T *eap));
void do_scscope __ARGS((exarg_T *eap));
void
[patch] avoid useless source of colorscheme
Doing :set t_Co=256 causes to the color scheme to be
sourced. That's fine when value of t_Co changes, but if
value of t_Co is set to the same value as previous value, it
seems useless.
Sourcing color scheme script can be slow. Attached patch
avoids to re-source colorscheme if t_Co is set to the same
value as it was already.
I noticed this while tweaking my ~/.vimrc. When doing :so ~/.vimrc,
my color scheme was executed 3 times at each invocation of
:so ~/.vimrc:
- when doing :set t_Co=256
- when doing :syntax on
- and of course when doing :colorscheme foobar
Doing :unset g:colors_name at beginning of ~/.vimrc avoids
this. But I also think that the patch can have some value if
some script or user change t_Co.
Regards
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: option.c
===
RCS file: /cvsroot/vim/vim7/src/option.c,v
retrieving revision 1.148
diff -c -r1.148 option.c
*** option.c 4 Mar 2009 03:13:35 - 1.148
--- option.c 17 Mar 2009 21:29:57 -
***
*** 6022,6036
/* :set t_Co=0 and :set t_Co=1 do :set t_Co= */
if (varp == T_CCO)
{
! t_colors = atoi((char *)T_CCO);
! if (t_colors = 1)
{
! if (new_value_alloced)
! vim_free(T_CCO);
! T_CCO = empty_option;
}
- /* We now have a different color setup, initialize it again. */
- init_highlight(TRUE, FALSE);
}
ttest(FALSE);
if (varp == T_ME)
--- 6022,6044
/* :set t_Co=0 and :set t_Co=1 do :set t_Co= */
if (varp == T_CCO)
{
! int colors = atoi((char *)T_CCO);
!
! /* Only reinitialize colors if t_Co value has really changed
! * to avoid expensive reload of colorscheme if t_Co is set
! * to the same value multiple times. */
! if (colors != t_colors)
{
! t_colors = colors;
! if (t_colors = 1)
! {
! if (new_value_alloced)
! vim_free(T_CCO);
! T_CCO = empty_option;
! }
! /* We now have a different color setup, initialize it again. */
! init_highlight(TRUE, FALSE);
}
}
ttest(FALSE);
if (varp == T_ME)
[patch] fixed memory leak in command custom completion
Hi
Command custom completion (:help :command-completion-customlist)
is leaking memory when redefining completion for a command
multiple times. I see this bug in latest Vim-7.2.132.
The following script illustrates the problem: memory usage keeps
growing at each iteration when redefining a command completion:
:function! s:Foo()
:endfunction
:function! s:CompleteFoo(a, l, p)
:endfunction
:while 1
: Leak at each iteration
: command! -complete=customlist,s:CompleteFoo -nargs=1 Foo :call s:Foo()
:endwhile
Attached patch fixes the memory leak.
Regards
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: ex_docmd.c
===
RCS file: /cvsroot/vim/vim7/src/ex_docmd.c,v
retrieving revision 1.166
diff -c -r1.166 ex_docmd.c
*** ex_docmd.c 1 Mar 2009 01:45:15 - 1.166
--- ex_docmd.c 10 Mar 2009 19:24:08 -
***
*** 5148,5153
--- 5148,5157
cmd-uc_name = p;
}
+ #if defined(FEAT_EVAL) defined(FEAT_CMDL_COMPL)
+ else
+ vim_free(cmd-uc_compl_arg); /* free previous compl. arg if any */
+ #endif
cmd-uc_rep = rep_buf;
cmd-uc_argt = argt;
***
*** 5941,5947
for (;;)
{
p = cmd-uc_rep;/* source */
! q = buf; /* destinateion */
totlen = 0;
for (;;)
--- 5945,5951
for (;;)
{
p = cmd-uc_rep;/* source */
! q = buf; /* destination */
totlen = 0;
for (;;)
Re: [Bug] Crash when using virtualedit=all
James Vega wrote: On Sat, Mar 07, 2009 at 04:30:30PM -0500, James Vega wrote: There seems to be an edge case when positioning the cursor and 'virtualedit' is set to all that causes gvim to crash. This was introduced between 6.4 and 7.0b. It can be reproduced using the attached files as follows: gvim -u NONE -N -S crash.vim crash.txt Actually attached this time. -- James Thanks. I can reproduce it with Vim-7.2.132 (huge) GTK2-GNOME. I see that windgoto() is called with with a negative col (-2147483646). Call stack when it happens is: #4 0x08190cd9 in windgoto (row=14, col=-2147483646) at screen.c:7888 #5 0x0819125e in setcursor () at screen.c:8118 #6 0x08107c16 in main_loop (cmdwin=0, noexmode=0) at main.c:1143 #7 0x081077e3 in main (argc=11, argv=0xbfd32a14) at main.c:939 I don't know why yet (I'll try to find out when I have time) but in the mean time, attached patch works around it. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- Index: screen.c === RCS file: /cvsroot/vim/vim7/src/screen.c,v retrieving revision 1.114 diff -c -r1.114 screen.c *** screen.c 22 Feb 2009 20:13:34 - 1.114 --- screen.c 8 Mar 2009 09:43:30 - *** *** 7879,7884 --- 7879,7886 row = 0; if (row = screen_Rows) row = screen_Rows - 1; + if (col 0) /* why would this happen? */ + col = 0; if (col = screen_Columns) col = screen_Columns - 1;
Re: [patch] fixed access to free memory when using some autocommands
Bram Moolenaar wrote: Thanks for the patch. I thought of catching the problem at the cause, by disallowing the autocommands to do something that will cause trouble. However, it's very difficult to catch all situations. So I think we can do both: disallow autocommands to do things that are clearly wrong, and give an error if we notice side effects. That should be safe. Please have a look at the patch below. There might still be other autocommands that cause trouble. If you see one, please report. ...snip... I applied your patch to Vim-7.2.128. I still observe something wrong after patching (something which I did not think of testing earlier, so the problem I see in your patch was also in my patch). The bug I see only happens when opening a file in Vim which does not exist but for which there is a swap file. Steps to reproduce it: # Open a file foobar (which does not exist) in vim to create # swap file .foobar.swp $ rm -f ~/foobar $ vim ~/foobar # In another terminal... $ vim -u NONE :au! SwapExists * cd /tmp :e ~/foobar The following prompt shows up: Swap file ~/.foobar.swp already exists! [O]pen Read-Only, (E)dit anyway, (R)ecover, (Q)uit, (A)bort: Press e. Valgrind then outputs the following error ==17742== Invalid read of size 1 ==17742==at 0x810B4DA: get_past_head (misc1.c:4472) ==17742==by 0x810B428: gettail_sep (misc1.c:4419) ==17742==by 0x810B610: dir_of_file_exists (misc1.c:4582) ==17742==by 0x80C13CD: readfile (fileio.c:606) ==17742==by 0x8052D8E: open_buffer (buffer.c:130) ==17742==by 0x8097AC3: do_ecmd (ex_cmds.c:3655) ==17742==by 0x80ADE20: do_exedit (ex_docmd.c:7557) ==17742==by 0x80ADA97: ex_edit (ex_docmd.c:7452) ==17742==by 0x80A6517: do_one_cmd (ex_docmd.c:2622) ==17742==by 0x80A3D97: do_cmdline (ex_docmd.c:1096) ==17742==by 0x8129422: nv_colon (normal.c:5218) ==17742==by 0x8122A86: normal_cmd (normal.c:1189) ==17742==by 0x80E5F8D: main_loop (main.c:1180) ==17742==by 0x80E5ADA: main (main.c:939) ==17742== Address 0x4d34be0 is 0 bytes inside a block of size 15 free'd ==17742==at 0x4024E5A: free (vg_replace_malloc.c:323) ==17742==by 0x8113C72: vim_free (misc2.c:1631) ==17742==by 0x80C8E58: shorten_fnames (fileio.c:5743) ==17742==by 0x80AE6AA: ex_cd (ex_docmd.c:7939) ==17742==by 0x80A6517: do_one_cmd (ex_docmd.c:2622) ==17742==by 0x80A3D97: do_cmdline (ex_docmd.c:1096) ==17742==by 0x80CC9A5: apply_autocmds_group (fileio.c:8883) ==17742==by 0x80CC3A8: apply_autocmds (fileio.c:8494) ==17742==by 0x80F9592: do_swapexists (memline.c:3770) ==17742==by 0x80F9EAD: findswapname (memline.c:4130) ==17742==by 0x80F3FF8: ml_open_file (memline.c:553) ==17742==by 0x80F411E: check_need_swap (memline.c:605) ==17742==by 0x80C13BF: readfile (fileio.c:605) ==17742==by 0x8052D8E: open_buffer (buffer.c:130) ==17742==by 0x8097AC3: do_ecmd (ex_cmds.c:3655) ==17742==by 0x80ADE20: do_exedit (ex_docmd.c:7557) ==17742==by 0x80ADA97: ex_edit (ex_docmd.c:7452) ==17742==by 0x80A6517: do_one_cmd (ex_docmd.c:2622) ==17742==by 0x80A3D97: do_cmdline (ex_docmd.c:1096) ==17742==by 0x8129422: nv_colon (normal.c:5218) ==17742==by 0x8122A86: normal_cmd (normal.c:1189) ==17742==by 0x80E5F8D: main_loop (main.c:1180) ==17742==by 0x80E5ADA: main (main.c:939) (and several other errors follow) If I enter :messages I also do not see the error message E812 (I would expect to see this message). I do not see this issue when the file foobar already exists. This remaining issue happens because call to check_need_swap() in fileio.c:605 (or line 592 in pristine vim-7.2.128) may trigger an autocommand which can also invalidate fname. Attached patch (on top of your patch) fixes this remaining issue (and a typo). I will continue to test with this patch for a while but so far it looks OK. I can't see any further bugs so far with autocommands. Regards Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- *** fileio.c.old_patch 2009-03-01 10:08:48.0 +0100 --- fileio.c 2009-03-01 10:15:24.0 +0100 *** *** 298,304 #ifdef FEAT_AUTOCMD /* Remember the initial values of curbuf, curbuf-b_ffname and * curbuf-b_fname to detect whether they are altered as a result of ! * executing nasaty autocommands. Also check if fname and sfname * point to one of these values. */ buf_T *old_curbuf = curbuf; char_u *old_b_ffname = curbuf-b_ffname; --- 298,304 #ifdef FEAT_AUTOCMD /* Remember the initial values of curbuf, curbuf-b_ffname and * curbuf-b_fname to detect whether they are altered as a result of ! * executing nasty autocommands. Also check if fname and sfname * point to one of these values. */
[patch] fixed string [Command Line] not translated with gettext
Buffer name [Command Line] is not translated with gettext. This is the buffer name which shows up when doing q: Attached patch (from Vim-7.2.128) allows to translate it, for those who use Vim with non-English locales. Regards -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- Index: ex_getln.c === RCS file: /cvsroot/vim/vim7/src/ex_getln.c,v retrieving revision 1.95 diff -c -r1.95 ex_getln.c *** ex_getln.c 28 Nov 2008 10:00:44 - 1.95 --- ex_getln.c 1 Mar 2009 11:39:51 - *** *** 6053,6059 /* Create the command-line buffer empty. */ (void)do_ecmd(0, NULL, NULL, NULL, ECMD_ONE, ECMD_HIDE, NULL); ! (void)setfname(curbuf, (char_u *)[Command Line], NULL, TRUE); set_option_value((char_u *)bt, 0L, (char_u *)nofile, OPT_LOCAL); set_option_value((char_u *)swf, 0L, NULL, OPT_LOCAL); curbuf-b_p_ma = TRUE; --- 6053,6059 /* Create the command-line buffer empty. */ (void)do_ecmd(0, NULL, NULL, NULL, ECMD_ONE, ECMD_HIDE, NULL); ! (void)setfname(curbuf, (char_u *)_([Command Line]), NULL, TRUE); set_option_value((char_u *)bt, 0L, (char_u *)nofile, OPT_LOCAL); set_option_value((char_u *)swf, 0L, NULL, OPT_LOCAL); curbuf-b_p_ma = TRUE;
bug in omni completion popup menu when option 'splibelow' is set
Hi I observe a bug in Vim-7.2.128 with the omni-completion popup menu when the option 'splitbelow' is set (bug does not happen when 'splitbelow' is not set). When pressing the Down key in the omni-completion menu, I see 2 pum: one above the current line and another one below the current line. This video illustrates the bug: http://dominique.pelle.free.fr/vim/bug-splitbelow-pum.avi I use Vim-7.2.128, with the omnicppcomplete-0.41 plugin and my .vimrc file can be found at: http://dominique.pelle.free.fr/.vimrc Regards -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] fixed string [Command Line] not translated with gettext
Bram Moolenaar wrote: Dominique Pelle wrote: Buffer name [Command Line] is not translated with gettext. This is the buffer name which shows up when doing q: Attached patch (from Vim-7.2.128) allows to translate it, for those who use Vim with non-English locales. Not translating this is more or less intentional. One can use this name to find the buffer. I thought it was not much of a problem not translating this. OK, that's fine then. Some other special buffers such as [No Name], [Quickfix List], [Location List], [Preview], [Scratch] are translated with gettext though, which is a bit inconsistent if [Command Line] buffer is not translated. But it's only a nitpicking thing. Is the buffer name string the only way to identify what kind of special buffer it is? Regards -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] fixed race condition in suspend resume with CTRL-Z fg
Bram Moolenaar wrote: Dominique Pelle wrote: ...snip... Without marking the variable volatile, there is a risk I think, that some compilers might optimize making code incorrect sometimes by not seeing that the variable gets automagically updated asynchronously by a signal handler as explained here for example: http://www.linuxdevices.com/articles/AT5980346182.html These kind of bugs can be subtle and hard to reproduce. I also see other variables in Vim which are modified or read by signal handlers. They should in theory also be declared volatile: - do_resize (modified by signal handler sig_winch()) - got_int (modified by signal handler catch_sigint()) - sig_alarm_called (modified by signal handler sig_alarm()) - full_screen (modified by signal handler deathtrap()) - in_mch_delay (read by signal handler deathtrap()) - lc_active (read by signal handler deathtrap()) - sigcont_received (modified by signal handler sigcont_handler()) (maybe others) I hate this kind of blame the programmer solutions. It means compiler writers are lazy and put the burden of getting it right on the programmer. While the actual problem is that the compiler should do this correctly automatically. The compiler can see that the variable is used in a signal handler and act accordingly. Asynchronous things are hard to get right. In the case of static variables, the compiler could indeed in theory figure it out (no idea whether it actually does that). But at least in the case of global variables such as 'got_int' compiler has no way to know that 'got_int' is used in a signal handler in another object file. Anyway, compilers do work in this broken way, I suppose we should add these volatile keywords to avoid trouble. It's safer. Attached patch contains all changes made in previous patch and declares a few more 'volatile' variables used in signal handlers. Thanks -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- Index: os_unix.c === RCS file: /cvsroot/vim/vim7/src/os_unix.c,v retrieving revision 1.90 diff -c -r1.90 os_unix.c *** os_unix.c 22 Feb 2009 01:52:46 - 1.90 --- os_unix.c 24 Feb 2009 19:05:11 - *** *** 181,187 defined(FEAT_TITLE) !defined(FEAT_GUI_GTK) # define SET_SIG_ALARM static RETSIGTYPE sig_alarm __ARGS(SIGPROTOARG); ! static int sig_alarm_called; #endif static RETSIGTYPE deathtrap __ARGS(SIGPROTOARG); --- 181,188 defined(FEAT_TITLE) !defined(FEAT_GUI_GTK) # define SET_SIG_ALARM static RETSIGTYPE sig_alarm __ARGS(SIGPROTOARG); ! /* volatile, used in signal handler sig_alarm(). */ ! static volatile int sig_alarm_called; #endif static RETSIGTYPE deathtrap __ARGS(SIGPROTOARG); *** *** 201,213 # define SIG_ERR ((RETSIGTYPE (*)())-1) #endif ! static int do_resize = FALSE; #ifndef __EMX__ static char_u *extra_shell_arg = NULL; static int show_shell_mess = TRUE; #endif ! static int deadly_signal = 0; /* The signal we caught */ ! static int in_mch_delay = FALSE; /* sleeping in mch_delay() */ static int curr_tmode = TMODE_COOK; /* contains current terminal mode */ --- 202,217 # define SIG_ERR ((RETSIGTYPE (*)())-1) #endif ! /* volatile, used in signal handler sig_winch(). */ ! static volatile int do_resize = FALSE; #ifndef __EMX__ static char_u *extra_shell_arg = NULL; static int show_shell_mess = TRUE; #endif ! /* volatile, used in signal handler deathtrap(). */ ! static volatile int deadly_signal = 0; /* The signal we caught */ ! /* volatile, used in signal handler deathtrap(). */ ! static volatile int in_mch_delay = FALSE;/* sleeping in mch_delay() */ static int curr_tmode = TMODE_COOK; /* contains current terminal mode */ *** *** 802,808 #endif /* ! * We need correct potatotypes for a signal function, otherwise mean compilers * will barf when the second argument to signal() is ``wrong''. * Let me try it with a few tricky defines from my own osdef.h (jw). */ --- 806,812 #endif /* ! * We need correct prototypes for a signal function, otherwise mean compilers * will barf when the second argument to signal() is ``wrong''. * Let me try it with a few tricky defines from my own osdef.h (jw). */ *** *** 1068,1080 SIGRETURN; } ! #ifdef _REENTRANT /* * On Solaris with multi-threading, suspending might not work immediately. * Catch the SIGCONT signal, which will be used as an indication whether the * suspending has been done or not. */ ! static int sigcont_received; static RETSIGTYPE sigcont_handler __ARGS(SIGPROTOARG); /* --- 1072,1089 SIGRETURN; } ! #if defined(_REENTRANT) defined(SIGCONT
[patch] signs not freed when exiting with -DEXITFREE
Signs are not freed when exiting Vim as one would expect when
building with -DEXITFREE. Attached patch fixes it. This is a
minor problem. It's not a real memory leak. Fixing it only helps
to avoid seeing spurious leaks when searching for memory leaks.
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: misc2.c
===
RCS file: /cvsroot/vim/vim7/src/misc2.c,v
retrieving revision 1.78
diff -c -r1.78 misc2.c
*** misc2.c 22 Jan 2009 20:32:04 - 1.78
--- misc2.c 22 Feb 2009 09:42:02 -
***
*** 1034,1039
--- 1034,1042
free_regexp_stuff();
free_tag_stuff();
free_cd_dir();
+ # ifdef FEAT_SIGNS
+ free_signs();
+ # endif
# ifdef FEAT_EVAL
set_expr_line(NULL);
# endif
Index: ex_cmds.c
===
RCS file: /cvsroot/vim/vim7/src/ex_cmds.c,v
retrieving revision 1.120
diff -c -r1.120 ex_cmds.c
*** ex_cmds.c 11 Feb 2009 15:03:45 - 1.120
--- ex_cmds.c 22 Feb 2009 09:42:05 -
***
*** 6541,6546
--- 6541,6547
static int last_sign_typenr = MAX_TYPENR; /* is decremented */
static void sign_list_defined __ARGS((sign_T *sp));
+ static void sign_undefine __ARGS((sign_T *sp, sign_T *sp_prev));
/*
* :sign command
***
*** 6751,6771
else
{
/* :sign undefine {name} */
! vim_free(sp-sn_name);
! vim_free(sp-sn_icon);
! #ifdef FEAT_SIGN_ICONS
! if (sp-sn_image != NULL)
! {
! out_flush();
! gui_mch_destroy_sign(sp-sn_image);
! }
! #endif
! vim_free(sp-sn_text);
! if (sp_prev == NULL)
! first_sign = sp-sn_next;
! else
! sp_prev-sn_next = sp-sn_next;
! vim_free(sp);
}
}
}
--- 6752,6758
else
{
/* :sign undefine {name} */
! sign_undefine(sp, sp_prev);
}
}
}
***
*** 7015,7020
--- 7002,7032
}
/*
+ * Undefine a sign and free its memory.
+ */
+ static void
+ sign_undefine(sp, sp_prev)
+ sign_T *sp;
+ sign_T *sp_prev;
+ {
+ vim_free(sp-sn_name);
+ vim_free(sp-sn_icon);
+ #ifdef FEAT_SIGN_ICONS
+ if (sp-sn_image != NULL)
+ {
+ out_flush();
+ gui_mch_destroy_sign(sp-sn_image);
+ }
+ #endif
+ vim_free(sp-sn_text);
+ if (sp_prev == NULL)
+ first_sign = sp-sn_next;
+ else
+ sp_prev-sn_next = sp-sn_next;
+ vim_free(sp);
+ }
+
+ /*
* Get highlighting attribute for sign typenr.
* If line is TRUE: line highl, if FALSE: text highl.
*/
***
*** 7088,7093
--- 7100,7117
return (char_u *)_([Deleted]);
}
+ #if defined(EXITFREE) || defined(PROTO)
+ /*
+ * Undefine/free all signs.
+ */
+ void
+ free_signs()
+ {
+ while (first_sign != NULL)
+ sign_undefine(first_sign, NULL);
+ }
+ #endif
+
#endif
#if defined(FEAT_GUI) || defined(FEAT_CLIENTSERVER) || defined(PROTO)
Index: proto/ex_cmds.pro
===
RCS file: /cvsroot/vim/vim7/src/proto/ex_cmds.pro,v
retrieving revision 1.14
diff -c -r1.14 ex_cmds.pro
*** proto/ex_cmds.pro 15 Nov 2008 13:11:52 - 1.14
--- proto/ex_cmds.pro 22 Feb 2009 09:42:05 -
***
*** 40,45
--- 40,46
int read_viminfo_sub_string __ARGS((vir_T *virp, int force));
void write_viminfo_sub_string __ARGS((FILE *fp));
void free_old_sub __ARGS((void));
+ void free_signs __ARGS((void));
int prepare_tagpreview __ARGS((int undo_sync));
void ex_help __ARGS((exarg_T *eap));
char_u *check_help_lang __ARGS((char_u *arg));
[patch] fixed race condition in suspend resume with CTRL-Z fg
Hi
Attached patch fixes a race condition which causes Vim to hang
when resuming (with fg) after having suspended Vim with CTRL-Z.
Bug does not happen 100% of the time, but once in a while. I
can reproduce the bug with Vim-7.2.121 in a xterm on Linux x86
after doing
CTRL-Z
fg
CTRL-Z
fg
, etc, ... several times until Vim hangs.
Pressing CTRL-C is a workaround when it hangs.
See also Ubuntu bug https://bugs.launchpad.net/bugs/291373
Bug only happens when configure script defined -D_REENTRANT
which happens at least when I configure Vim as follows:
./configure --enable-tclinterp --enable-rubyinterp \
--enable-perlinterp --enable-pythoninterp \
--with-features=huge --enable-gui=gnome2
The problem happens I think because the following 2 lines
in os_unix.c in mch_suspect() have a race condition:
if (!sigcont_received)
pause();
If the signal is handled _after_ the test of sigcont_received
variable but _before_ pause() is executed, then pause() will
wait for ever since signal already happened.
Also I think that the variable sigcont_received should also be
declared volatile since it's modified by a signal handler.
Attached patch fixes the race condition by waiting until
sigcont_received is set without calling pause():
long wait;
for (wait = 0; !sigcont_received wait = 3L; wait++)
/* Loop is not entered most of the time */
mch_delay(wait, FALSE);
Note that most of the time the loop does not even need
to sleep() at all (sigcont_received is already set most of
the time before entering the loop). And when it it sleeps,
a sleep(0) seems always enough in practice. I've put
debug printf() after the loop that waits for sigcont_received
and I see this when doing several suspend (CTRL-Z, fg):
wait=0
wait=0
wait=0
wait=0
wait=0
wait=0
wait=0
wait=1
wait=0
wait=0
wait=0
wait=0
wait=0
wait=1
wait=0
wait=0
wait=0
wait=0
Notice that in 2 occasions, wait was 1 (meaning that the loop
iterated once with a sleep of 0 (yielding the CPU which is
enough to get the signal handled).
Regards
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: os_unix.c
===
RCS file: /cvsroot/vim/vim7/src/os_unix.c,v
retrieving revision 1.90
diff -c -r1.90 os_unix.c
*** os_unix.c 22 Feb 2009 01:52:46 - 1.90
--- os_unix.c 22 Feb 2009 19:05:29 -
***
*** 1068,1080
SIGRETURN;
}
! #ifdef _REENTRANT
/*
* On Solaris with multi-threading, suspending might not work immediately.
* Catch the SIGCONT signal, which will be used as an indication whether the
* suspending has been done or not.
*/
! static int sigcont_received;
static RETSIGTYPE sigcont_handler __ARGS(SIGPROTOARG);
/*
--- 1068,1086
SIGRETURN;
}
! #if defined(_REENTRANT) defined(SIGCONT)
/*
* On Solaris with multi-threading, suspending might not work immediately.
* Catch the SIGCONT signal, which will be used as an indication whether the
* suspending has been done or not.
+ *
+ * On Linux, signal is not always handled immediately either.
+ * See https://bugs.launchpad.net/bugs/291373
+ *
+ * sigcont_received is declared volatile to prevent compiler optimizations
+ * since this variable is changed in a signal handler.
*/
! static volatile int sigcont_received;
static RETSIGTYPE sigcont_handler __ARGS(SIGPROTOARG);
/*
***
*** 1118,1132
}
# endif
! # ifdef _REENTRANT
sigcont_received = FALSE;
# endif
kill(0, SIGTSTP); /* send ourselves a STOP signal */
! # ifdef _REENTRANT
! /* When we didn't suspend immediately in the kill(), do it now. Happens
! * on multi-threaded Solaris. */
! if (!sigcont_received)
! pause();
# endif
# ifdef FEAT_TITLE
--- 1124,1151
}
# endif
! # if defined(_REENTRANT) defined(SIGCONT)
sigcont_received = FALSE;
# endif
kill(0, SIGTSTP); /* send ourselves a STOP signal */
! # if defined(_REENTRANT) defined(SIGCONT)
! /*
! * Wait for the SIGCONT signal to be handled. It generally happens
! * immediately, but somehow not all the time. Do not call pause()
! * because there would be race condition which would hang Vim if
! * signal happened in between the test of sigcont_received and the
! * call to pause(). If signal is not yet received, call sleep(0)
! * to just yield CPU. Signal should then be received. If somehow
! * it's still not received, sleep 1, 2, 3 ms. Don't bother waiting
! * further if signal is not received after 1+2+3+4 ms (not expected
! * to happen).
! */
! {
! long wait;
! for (wait = 0;
Re: [patch] fixed race condition in suspend resume with CTRL-Z fg
Bram Moolenaar wrote: Dominique Pelle wrote: Attached patch fixes a race condition which causes Vim to hang when resuming (with fg) after having suspended Vim with CTRL-Z. Bug does not happen 100% of the time, but once in a while. I can reproduce the bug with Vim-7.2.121 in a xterm on Linux x86 after doing CTRL-Z fg CTRL-Z fg , etc, ... several times until Vim hangs. Pressing CTRL-C is a workaround when it hangs. See also Ubuntu bug https://bugs.launchpad.net/bugs/291373 Bug only happens when configure script defined -D_REENTRANT which happens at least when I configure Vim as follows: ./configure --enable-tclinterp --enable-rubyinterp \ --enable-perlinterp --enable-pythoninterp \ --with-features=huge --enable-gui=gnome2 The problem happens I think because the following 2 lines in os_unix.c in mch_suspect() have a race condition: if (!sigcont_received) pause(); If the signal is handled _after_ the test of sigcont_received variable but _before_ pause() is executed, then pause() will wait for ever since signal already happened. Also I think that the variable sigcont_received should also be declared volatile since it's modified by a signal handler. Attached patch fixes the race condition by waiting until sigcont_received is set without calling pause(): long wait; for (wait = 0; !sigcont_received wait = 3L; wait++) /* Loop is not entered most of the time */ mch_delay(wait, FALSE); Note that most of the time the loop does not even need to sleep() at all (sigcont_received is already set most of the time before entering the loop). And when it it sleeps, a sleep(0) seems always enough in practice. I've put debug printf() after the loop that waits for sigcont_received and I see this when doing several suspend (CTRL-Z, fg): wait=0 wait=0 wait=0 wait=0 wait=0 wait=0 wait=0 wait=1 wait=0 wait=0 wait=0 wait=0 wait=0 wait=1 wait=0 wait=0 wait=0 wait=0 Notice that in 2 occasions, wait was 1 (meaning that the loop iterated once with a sleep of 0 (yielding the CPU which is enough to get the signal handled). Makes sense. Perhaps pause() does some work that increases the change for the race condition to actually happen (e.g., a aquiring a lock). One problem: the Vim code doesn't use volatile yet. I don't think every C compiler supports it, thus this requires adding a configure check. AC_C_VOLATILE will do. OK. I'm no expert with configure scripts, but I assume that what you're asking is what the extra attached patch does. Without marking the variable volatile, there is a risk I think, that some compilers might optimize making code incorrect sometimes by not seeing that the variable gets automagically updated asynchronously by a signal handler as explained here for example: http://www.linuxdevices.com/articles/AT5980346182.html These kind of bugs can be subtle and hard to reproduce. I also see other variables in Vim which are modified or read by signal handlers. They should in theory also be declared volatile: - do_resize (modified by signal handler sig_winch()) - got_int (modified by signal handler catch_sigint()) - sig_alarm_called (modified by signal handler sig_alarm()) - full_screen (modified by signal handler deathtrap()) - in_mch_delay (read by signal handler deathtrap()) - lc_active (read by signal handler deathtrap()) - sigcont_received (modified by signal handler sigcont_handler()) (maybe others) Cheers -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- Index: configure.in === RCS file: /cvsroot/vim/vim7/src/configure.in,v retrieving revision 1.66 diff -c -r1.66 configure.in *** configure.in 20 Nov 2008 09:36:35 - 1.66 --- configure.in 22 Feb 2009 22:35:28 - *** *** 2148,2153 --- 2148,2154 dnl Checks for typedefs, structures, and compiler characteristics. AC_PROG_GCC_TRADITIONAL AC_C_CONST + AC_C_VOLATILE AC_TYPE_MODE_T AC_TYPE_OFF_T AC_TYPE_PID_T Index: config.h.in === RCS file: /cvsroot/vim/vim7/src/config.h.in,v retrieving revision 1.11 diff -c -r1.11 config.h.in *** config.h.in 24 Jun 2008 21:47:46 - 1.11 --- config.h.in 22 Feb 2009 22:35:28 - *** *** 50,55 --- 50,58 /* Define to empty if the keyword does not work. */ #undef const + /* Define to empty if the keyword does not work. */ + #undef volatile + /* Define to `int' if sys/types.h doesn't define. */ #undef mode_t
Re: PATCH: Completion for find and sfind arguments (todo.txt)
Nazri Ramliy wrote: On Fri, Feb 20, 2009 at 9:18 AM, Nazri ayieh...@gmail.com wrote: I'm refining the patch - fixing a memory leak (stupid me :), and improving the shortening of the matching paths to get the minimum unique length of each. This is much much better than the simple (and not necessarily correct all the time) relative to your working directory or home directory. The old method just won't work if your path setting does not include your home directory. The new method can produce sufficiently short paths to be comfortably seen on the wildmenu. Here's the improved patch. There's one major outstanding issue that I'm aware of - it does not skip symbolic links. This may result in infinite cycle if there exists a symbolic link that creates a cycle in the file system. I don't have access to a windows platform so I can't test the patch on windows. It may have problems with those different drive letters. nazri. Hi Nazri I'm trying your patch on Linux x86 (from Vim-7.2.108). I notice something broken. I do: $ mkdir foobar/ $ vim -u NONE set nocompatible set wildmode=longest,list set wildmenu set path=. If I type: :find footab I would expect to complete up to foobar/ (it does that without patch) but after patch it does not complete the directory name anymore. Cheers -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: New (?) compiler warning
björn wrote: Hi, For the last two weeks or so I've been getting this warning when compiling Vim (on Mac OS X): ex_docmd.c: In function 'do_one_cmd': ex_docmd.c:5937: warning: 'end' may be used uninitialized in this function ex_docmd.c: In function 'do_one_cmd': ex_docmd.c:5937: warning: 'end' may be used uninitialized in this function I searched the archives but found no mention of it, so perhaps this is only happening on OS X? Björn I have it too. Your line number is not consistent with the latest version of the source (7.2.108) by the way: line 5937 is a comment for me. I have this warning at line 5919: ex_docmd.c: In function ‘do_one_cmd’: ex_docmd.c:5919: warning: ‘end’ may be used uninitialized in this function ex_docmd.c:5919: note: ‘end’ was declared here We could fix it for the sake of not having compilation warnings. But the warning looks spurious anyway since 'end' is never used when 'start' is NULL. And 'end' is initialized when 'start' is not NULL. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] fixed access to invalid memory with autocmd VimResized
Bram Moolenaar wrote: Dominique Pelle wrote: Vim-7.2.108 can read and write beyond allocated memory when using autocmd VimResized. Bug happens if a shell command is used in VimResized autocmd such as... :au! VimResized * sil !echo -ne \033]12;green\007 With this autocmd, I observe the following error with valgrind when resizing the screen with the mouse: ...snip... Thanks. Not sure if the solution is OK, will have to check that. What if the autocommand relies on the screen already being allocated? This is tricky stuff. I think it's OK, but it's tricky as you say. An alternative way to fix it, is to check, after applying the autocmd, whether Rows or Columns have changed as a result of applying the autocmds, and if so (which is rare) then re-allocate the screen again before returning from screenalloc(). The new attached patch does just that. Of course, there might be a risk of endless loop if an autocmd changed Rows and Columns every time. So the patch puts a guard to avoid re-allocating screen more than 3 times. In practice, I observe that it's reallocating sometimes once, rarely twice and I do no see more than that. Both patches fix the errors that I see with valgrind. Regards -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- fix-VimResized-screen.c.patch2 Description: Binary data
Re: [patch] fixed access to free memory when using some autocommands
Bram Moolenaar wrote: Dominique Pelle wrote: Testing autocommands, I see that Vim-7.2.107 (and older) is using memory already freed when doing silly autocommands such as: $ touch foobar $ valgrind ./vim -u NONE -c 'au! BufReadPre * cd /tmp' \ -c 'e foobar' 2 vg.log In vg.log, I then see the following error: ==15058== Syscall param open(filename) points to unaddressable byte(s) ==15058== at 0x40007D2: (within /lib/ld-2.8.90.so) ==15058== by 0x805365E: open_buffer (buffer.c:130) ==15058== by 0x8098548: do_ecmd (ex_cmds.c:3655) ==15058== by 0x80AE8E9: do_exedit (ex_docmd.c:7557) ==15058== by 0x80AE560: ex_edit (ex_docmd.c:7452) ==15058== by 0x80A6FE7: do_one_cmd (ex_docmd.c:2622) ==15058== by 0x80A4867: do_cmdline (ex_docmd.c:1096) ==15058== by 0x80A3F00: do_cmdline_cmd (ex_docmd.c:702) ==15058== by 0x80E8A07: exe_commands (main.c:2693) ==15058== by 0x80E63A7: main (main.c:874) ==15058== Address 0x54312d4 is 4 bytes inside a block of size 11 free'd ==15058== at 0x4024E5A: free (vg_replace_malloc.c:323) ==15058== by 0x8114D5D: vim_free (misc2.c:1631) ==15058== by 0x80C97DF: shorten_fnames (fileio.c:5715) ==15058== by 0x80AF1A9: ex_cd (ex_docmd.c:7942) ==15058== by 0x80A6FE7: do_one_cmd (ex_docmd.c:2622) ==15058== by 0x80A4867: do_cmdline (ex_docmd.c:1096) ==15058== by 0x80CD35A: apply_autocmds_group (fileio.c:8853) ==15058== by 0x80CCD9B: apply_autocmds_exarg (fileio.c:8481) ==15058== by 0x80C2246: readfile (fileio.c:723) ==15058== by 0x805365E: open_buffer (buffer.c:130) ==15058== by 0x8098548: do_ecmd (ex_cmds.c:3655) ==15058== by 0x80AE8E9: do_exedit (ex_docmd.c:7557) [...snip...] Thanks. It's in the todo list. I found another case of an autocommand which also causes to use freed memory and the proposed patch in my previous email did not help to fix it. Here is how to reproduce it: # Open a file foobar in vim to create swap file .foobar.swp $ vim foobar # In another terminal... $ vim -u NONE :au! SwapExists * cd /tmp :e foobar ... and valgrind complains about use of freed memory: ==17226== Syscall param open(filename) points to unaddressable byte(s) ==17226==at 0x40007D2: (within /lib/ld-2.8.90.so) ==17226==by 0x805365E: open_buffer (buffer.c:130) ==17226==by 0x8098548: do_ecmd (ex_cmds.c:3655) ==17226==by 0x80AE8E9: do_exedit (ex_docmd.c:7557) ==17226==by 0x80AE560: ex_edit (ex_docmd.c:7452) ==17226==by 0x80A6FE7: do_one_cmd (ex_docmd.c:2622) ==17226==by 0x80A4867: do_cmdline (ex_docmd.c:1096) ==17226==by 0x812A4BC: nv_colon (normal.c:5233) ==17226==by 0x8123B40: normal_cmd (normal.c:1200) ==17226==by 0x80E6969: main_loop (main.c:1180) ==17226==by 0x80E64B6: main (main.c:939) ==17226== Address 0x543644c is 4 bytes inside a block of size 11 free'd ==17226==at 0x4024E5A: free (vg_replace_malloc.c:323) ==17226==by 0x8114D5D: vim_free (misc2.c:1631) ==17226==by 0x80C97DF: shorten_fnames (fileio.c:5715) ==17226==by 0x80AF1A9: ex_cd (ex_docmd.c:7942) ==17226==by 0x80A6FE7: do_one_cmd (ex_docmd.c:2622) ==17226==by 0x80A4867: do_cmdline (ex_docmd.c:1096) ==17226==by 0x80CD35A: apply_autocmds_group (fileio.c:8853) ==17226==by 0x80CCD5D: apply_autocmds (fileio.c:8464) ==17226==by 0x80FA022: do_swapexists (memline.c:3770) ==17226==by 0x80FA93D: findswapname (memline.c:4130) ==17226==by 0x80F4A88: ml_open_file (memline.c:553) ==17226==by 0x80F4BAE: check_need_swap (memline.c:605) ==17226==by 0x80C206F: readfile (fileio.c:670) ==17226==by 0x805365E: open_buffer (buffer.c:130) ==17226==by 0x8098548: do_ecmd (ex_cmds.c:3655) ==17226==by 0x80AE8E9: do_exedit (ex_docmd.c:7557) ==17226==by 0x80AE560: ex_edit (ex_docmd.c:7452) ==17226==by 0x80A6FE7: do_one_cmd (ex_docmd.c:2622) ==17226==by 0x80A4867: do_cmdline (ex_docmd.c:1096) ==17226==by 0x812A4BC: nv_colon (normal.c:5233) ==17226==by 0x8123B40: normal_cmd (normal.c:1200) ==17226==by 0x80E6969: main_loop (main.c:1180) ==17226==by 0x80E64B6: main (main.c:939) The problem happens here because readfile() in fileio.c calls check_need_swap(newfile); at line fileio.c:670 and this function can trigger an autocommand (SwapExists) which can potentially free or realloc curbuf-b_fname or curbuf-b_ffname. If parameters fname or sfname of readfile() are aliased to curbuf-b_fname or curbuf-b_ffname, then readfile() may read free memory after the autocommand has been executed. The new attached patch fixes this new problem and also fixes the 2 errors described in previous email. I'm not sure how clean the fix is. Please review it. At least it should help to understand what the problem is. Cheers -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php
[patch] fixed access to free memory when using some autocommands
Testing autocommands, I see that Vim-7.2.107 (and older) is using memory already freed when doing silly autocommands such as: $ touch foobar $ valgrind ./vim -u NONE -c 'au! BufReadPre * cd /tmp' \ -c 'e foobar' 2 vg.log In vg.log, I then see the following error: ==15058== Syscall param open(filename) points to unaddressable byte(s) ==15058==at 0x40007D2: (within /lib/ld-2.8.90.so) ==15058==by 0x805365E: open_buffer (buffer.c:130) ==15058==by 0x8098548: do_ecmd (ex_cmds.c:3655) ==15058==by 0x80AE8E9: do_exedit (ex_docmd.c:7557) ==15058==by 0x80AE560: ex_edit (ex_docmd.c:7452) ==15058==by 0x80A6FE7: do_one_cmd (ex_docmd.c:2622) ==15058==by 0x80A4867: do_cmdline (ex_docmd.c:1096) ==15058==by 0x80A3F00: do_cmdline_cmd (ex_docmd.c:702) ==15058==by 0x80E8A07: exe_commands (main.c:2693) ==15058==by 0x80E63A7: main (main.c:874) ==15058== Address 0x54312d4 is 4 bytes inside a block of size 11 free'd ==15058==at 0x4024E5A: free (vg_replace_malloc.c:323) ==15058==by 0x8114D5D: vim_free (misc2.c:1631) ==15058==by 0x80C97DF: shorten_fnames (fileio.c:5715) ==15058==by 0x80AF1A9: ex_cd (ex_docmd.c:7942) ==15058==by 0x80A6FE7: do_one_cmd (ex_docmd.c:2622) ==15058==by 0x80A4867: do_cmdline (ex_docmd.c:1096) ==15058==by 0x80CD35A: apply_autocmds_group (fileio.c:8853) ==15058==by 0x80CCD9B: apply_autocmds_exarg (fileio.c:8481) ==15058==by 0x80C2246: readfile (fileio.c:723) ==15058==by 0x805365E: open_buffer (buffer.c:130) ==15058==by 0x8098548: do_ecmd (ex_cmds.c:3655) ==15058==by 0x80AE8E9: do_exedit (ex_docmd.c:7557) The error is actually deeper inside readfile(...) (not sure why valgrind stops the stack trace at open_buffer (buffer.c:130). In readfile(), parameter fname may point to curbuf-b_ffname or curbuf-b_fname before running autocommands (near fileio.c:715). Some autocommands may change curbuf-b_ffname and curbuf-b_fname (freeing and reallocating them) so after executing autommand fname may then point to some invalid memory, and readfile() then uses freed memory when accessing fname. Attached patch fixes the bug by making readfile() fail when that happens. Probably an error should also be reported (see TODO comment in patch). Please review the patch. The same patch also fixes at least another error when doing another silly autocommand: $ touch foobar $ vim -u NONE :set autochdir :au! BufReadPre * e! :e foobar ==12943== Syscall param open(filename) points to unaddressable byte(s) ==12943==at 0x40007D2: (within /lib/ld-2.8.90.so) ==12943==by 0x805368E: open_buffer (buffer.c:130) ==12943==by 0x809856E: do_ecmd (ex_cmds.c:3650) ==12943==by 0x80AE90D: do_exedit (ex_docmd.c:7557) ==12943==by 0x80AE584: ex_edit (ex_docmd.c:7452) ==12943==by 0x80A700B: do_one_cmd (ex_docmd.c:2622) ==12943==by 0x80A488B: do_cmdline (ex_docmd.c:1096) ==12943==by 0x812A4F0: nv_colon (normal.c:5233) ==12943==by 0x8123B74: normal_cmd (normal.c:1200) ==12943==by 0x80E69B9: main_loop (main.c:1180) ==12943==by 0x80E6506: main (main.c:939) ==12943== Address 0x5d69824 is 4 bytes inside a block of size 11 free'd ==12943==at 0x4024E5A: free (vg_replace_malloc.c:323) ==12943==by 0x8114D91: vim_free (misc2.c:1631) ==12943==by 0x80C9803: shorten_fnames (fileio.c:5715) ==12943==by 0x805538B: do_autochdir (buffer.c:1476) ==12943==by 0x8098521: do_ecmd (ex_cmds.c:3631) ==12943==by 0x80AE90D: do_exedit (ex_docmd.c:7557) ==12943==by 0x80AE584: ex_edit (ex_docmd.c:7452) ==12943==by 0x80A700B: do_one_cmd (ex_docmd.c:2622) ==12943==by 0x80A488B: do_cmdline (ex_docmd.c:1096) ==12943==by 0x80CD3A9: apply_autocmds_group (fileio.c:8861) ==12943==by 0x80CCDEA: apply_autocmds_exarg (fileio.c:8489) ==12943==by 0x80C226A: readfile (fileio.c:723) ==12943==by 0x805368E: open_buffer (buffer.c:130) ==12943==by 0x809856E: do_ecmd (ex_cmds.c:3650) ==12943==by 0x80AE90D: do_exedit (ex_docmd.c:7557) ==12943==by 0x80AE584: ex_edit (ex_docmd.c:7452) ==12943==by 0x80A700B: do_one_cmd (ex_docmd.c:2622) ==12943==by 0x80A488B: do_cmdline (ex_docmd.c:1096) ==12943==by 0x812A4F0: nv_colon (normal.c:5233) ==12943==by 0x8123B74: normal_cmd (normal.c:1200) ==12943==by 0x80E69B9: main_loop (main.c:1180) ==12943==by 0x80E6506: main (main.c:939) (and many other errors follow) Regards -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- Index: fileio.c === RCS file: /cvsroot/vim/vim7/src/fileio.c,v retrieving revision 1.129 diff -c -r1.129 fileio.c *** fileio.c 31 Dec 2008 15:21:17 - 1.129 --- fileio.c 11 Feb 2009 21:46:59 - *** *** 69,75 static int au_find_group
[patches] fixed low priority issues: mostly pointers not freed when using EXITFREE
Attached are a couple of low priority patches.
In netbeans.c, there are 2 format mismatches (%d instead of %ld):
- fixed-format-netbeans.c.patch
In nbdebug.c, I see 2 functions [nbtrace() nbprt()] which are
defined but which are never called from anywhere (are they needed?):
- fixed-deadcode-nbdebug.c.patch
When compiled with -DEXITFREE, Vim is meant to free all blocks
before exiting. Following patches frees a few memory blocks which
were not being freed before exiting. Freeing them helps to remove
false alerts when trying to search for real memory leaks.
- fixed-exitfree-search.c.patch
Fixes memory not freed when doing:
:rightleft
:/foobar
:q!
- fixed-exitfree-tag.c.patch
Fixes memory not freed when doing:
:pts foo
:q!
- fixed-exitfree-misc2.c.patch
Fixes memory not free when doing
:set keymap=esperanto or any other keymap...
:q!
- fixed-exitfree-ex_docmd.c.patch
- fixed-exitfree-gui_gtk_x11.c.patch
Regards
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: tag.c
===
RCS file: /cvsroot/vim/vim7/src/tag.c,v
retrieving revision 1.46
diff -c -r1.46 tag.c
*** tag.c 13 Jan 2009 16:28:08 - 1.46
--- tag.c 7 Feb 2009 09:52:12 -
***
*** 2542,2547
--- 2542,2556
{
ga_clear_strings(tag_fnames);
do_tag(NULL, DT_FREE, 0, 0, 0);
+ tag_freematch();
+
+ # if defined(FEAT_WINDOWS) defined(FEAT_QUICKFIX)
+ if (ptag_entry.tagname)
+ {
+ vim_free(ptag_entry.tagname);
+ ptag_entry.tagname = NULL;
+ }
+ # endif
}
#endif
Index: ex_docmd.c
===
RCS file: /cvsroot/vim/vim7/src/ex_docmd.c,v
retrieving revision 1.164
diff -c -r1.164 ex_docmd.c
*** ex_docmd.c 28 Jan 2009 14:42:40 - 1.164
--- ex_docmd.c 7 Feb 2009 09:48:19 -
***
*** 7846,7851
--- 7846,7854
{
vim_free(prev_dir);
prev_dir = NULL;
+
+ vim_free(globaldir);
+ globaldir = NULL;
}
#endif
Index: search.c
===
RCS file: /cvsroot/vim/vim7/src/search.c,v
retrieving revision 1.68
diff -c -r1.68 search.c
*** search.c 18 Jul 2008 10:05:58 - 1.68
--- search.c 7 Feb 2009 09:46:30 -
***
*** 345,350
--- 345,359
{
vim_free(spats[0].pat);
vim_free(spats[1].pat);
+
+ # ifdef FEAT_RIGHTLEFT
+ if (mr_pattern_alloced)
+ {
+ vim_free(mr_pattern);
+ mr_pattern_alloced = FALSE;
+ mr_pattern = NULL;
+ }
+ # endif
}
#endif
Index: misc2.c
===
RCS file: /cvsroot/vim/vim7/src/misc2.c,v
retrieving revision 1.78
diff -c -r1.78 misc2.c
*** misc2.c 22 Jan 2009 20:32:04 - 1.78
--- misc2.c 7 Feb 2009 09:47:31 -
***
*** 1010,1015
--- 1010,1018
# if defined(FEAT_PROFILE)
do_cmdline_cmd((char_u *)profdel *);
# endif
+ # if defined(FEAT_KEYMAP)
+ do_cmdline_cmd((char_u *)set keymap=);
+ #endif
# ifdef FEAT_TITLE
free_titles();
Index: gui_gtk_x11.c
===
RCS file: /cvsroot/vim/vim7/src/gui_gtk_x11.c,v
retrieving revision 1.61
diff -c -r1.61 gui_gtk_x11.c
*** gui_gtk_x11.c 28 Nov 2008 20:28:56 - 1.61
--- gui_gtk_x11.c 7 Feb 2009 09:49:02 -
***
*** 412,417
--- 412,418
#endif
#if defined(FEAT_GUI_GNOME) defined(FEAT_SESSION)
static const char *restart_command = NULL;
+ static char *abs_restart_command = NULL;
#endif
static int found_iconic_arg = FALSE;
***
*** 449,456
char_u buf[MAXPATHL];
if (mch_FullName((char_u *)argv[0], buf, (int)sizeof(buf), TRUE) == OK)
! /* Tiny leak; doesn't matter, and usually we don't even get here */
! restart_command = (char *)vim_strsave(buf);
}
#endif
--- 450,456
char_u buf[MAXPATHL];
if (mch_FullName((char_u *)argv[0], buf, (int)sizeof(buf), TRUE) == OK)
! abs_restart_command = (char *)vim_strsave(buf);
}
#endif
***
*** 611,616
--- 611,619
gui_mch_free_all()
{
vim_free(gui_argv);
+ #if defined(FEAT_GUI_GNOME) defined(FEAT_SESSION)
+ vim_free(abs_restart_command);
+ #endif
}
#endif
***
*** 1678,1684
offshoot = dx dy ? dx : dy;
! /* Make a linearly declaying timer delay with a threshold of 5 at a
* distance of 127 pixels from the main window.
*
* One could think endlessly about the most ergonomic variant here.
--- 1681,1687
offshoot = dx dy ? dx : dy;
! /* Make a linearly decaying timer delay with a threshold of 5 at a
*
Re: Visual Block + cursorcolumn highlighting
Dominique Pelle wrote:
But the patch breaks something. See the 2 screenshots
before after patch (gvim-7.2.102 with/without patch):
http://dominique.pelle.free.fr/pic/visual-sel-before-patch.png
http://dominique.pelle.free.fr/pic/visual-sel-after-patch.png
After patch, the column in the visual selection where cursor
is located has the highlight of visual selection instead of
CursorColumn (good). However, notice that with the
patch, the cursorcolumn is no longer completely highlighted
outside the visual selection which is not right (before patch
was better in that regard). With patch, the cursor line becomes
only highlighted beyond the end of lines (not good).
This new attached patch fixes the problem but I described
with the original patch (patch broke highlighting of cuc outside
visual selection).
See new screenshot with latest patch:
http://dominique.pelle.free.fr/pic/visual-sel-after-new-patch.png
That looks better to me: notice on screenshot that cursor's
column is now properly highlighted outside the visual selection
(using CursorColumn highlight group) and inside the visual
selection the visual selection using Visual highlight group.
Now remains the question. Why the inconsistency: visual
selection disables the cursorline highlighting? Should this
also be fixed?
Cheers
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: screen.c
===
RCS file: /cvsroot/vim/vim7/src/screen.c,v
retrieving revision 1.109
diff -c -r1.109 screen.c
*** screen.c 2 Oct 2008 16:04:00 - 1.109
--- screen.c 7 Feb 2009 10:41:35 -
***
*** 4555,4569
#ifdef FEAT_SYN_HL
/* Highlight the cursor column if 'cursorcolumn' is set. But don't
* highlight the cursor position itself. */
- if (wp-w_p_cuc vcol == (long)wp-w_virtcol
- lnum != wp-w_cursor.lnum
- draw_state == WL_LINE)
{
! vcol_save_attr = char_attr;
! char_attr = hl_combine_attr(char_attr, hl_attr(HLF_CUC));
! }
! else
! vcol_save_attr = -1;
#endif
/*
--- 4555,4595
#ifdef FEAT_SYN_HL
/* Highlight the cursor column if 'cursorcolumn' is set. But don't
* highlight the cursor position itself. */
{
! int in_visual_range;
!
! if (VIsual_active)
! {
! int min_visual_lnum;
! int max_visual_lnum;
!
! if (wp-w_old_cursor_lnum wp-w_old_visual_lnum)
! {
! min_visual_lnum = wp-w_old_cursor_lnum;
! max_visual_lnum = wp-w_old_visual_lnum;
! }
! else
! {
! min_visual_lnum = wp-w_old_visual_lnum;
! max_visual_lnum = wp-w_old_cursor_lnum;
! }
! in_visual_range = lnum = min_visual_lnum
! lnum = max_visual_lnum;
! }
! else
! in_visual_range = 0;
!
! if (wp-w_p_cuc vcol == (long)wp-w_virtcol
! lnum != wp-w_cursor.lnum
! draw_state == WL_LINE
! !in_visual_range)
! {
! vcol_save_attr = char_attr;
! char_attr = hl_combine_attr(char_attr, hl_attr(HLF_CUC));
! }
! else
! vcol_save_attr = -1;
! }
#endif
/*
Re: :help prints broken-down-alphabets when the text file is encoded with cp949
Dewr wrote: oops. I have not attached any file. look at this - ftp://foobar.dnip.net:2121/upload/dewry/brokendownalphabets.bmp I don't know what the problem is. But your screenshot is very slow to download (~ 5.3 Mb) I reduced it to just 73 Kbytes by doing: $ convert -strip -depth 4 brokendownalphabets.bmp brokendownalphabets.png $ optipng brokendownalphabets.png You can find the smaller version (72 times smaller) at: http://dominique.pelle.free.fr/pic/brokendownalphabets.png -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: No break checks during shell operations in GUI mode?
björn wrote: Dominique: It is strange that my patch does not fix the problem for you...maybe fast_breakcheck() doesn't call gui_mch_update() often enough on your system (although that seems unlikely judging from the amount of times this loop iterates as I mentioned above)? It does take care of the problem on my machine (Mac OS X 10.5.6, Vim 7.2 patches 1-102, with MacVim GUI). Ah, I now notice that the patch does not work when I use gvim in a ssh session 'ssh -Y' (which is how I tested initially). But if I use gvim locally, then your patch works. Well, there is a bit of lag: when pressing ctrl-c it stops grep after maybe 2 seconds or so. Still better than not stopping it at all. In the terminal, pressing ctrl-c stops grep immediately. I'm using gvim-7.2.102 with GTK2 GUI on Linux x86. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: No break checks during shell operations in GUI mode?
2009/2/5 Andreas Bernauer andr...@lysium.de: björn wrote: 2009/2/4 Bram Moolenaar: So what's the problem you are trying to solve? The original problem was this: go to e.g. the vim src/ directory and enter :grep a *.c. During this operation it is impossible to halt Vim using ctrl-c. (I've tested on Mac OS X, and sc confirmed the problem on Linux). I can't confirm this behavior for vim 7.2.095 on Linux 2.6.24 (in either gui or console mode). :grep interrupts as soon as I press Ctrl-C. I can reproduce the problem with gvim on Linux x86 (GUI GTK2): pressing CTRL-C does not interrupt :grep a * in gvim. In terminal, CTRL-C interrupts :grep a * immediately (good). I tried the proposed patch, but it does not fix it for me: CTRL-C still does not interrupt :grep a * in the GUI. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Test 58 failure on solaris (64bit)
harpchad wrote:
Additional details:
VIM 7.2
Included patches: 1-88
Huge version without GUI.
Compilation: /opt/studio/SOS11/SUNWspro/bin/cc -c -I. -Iproto -
DHAVE_CONFIG_H -I/opt/csw/include -xO3 -xarch=v9 -I/opt/csw/include
Linking: /opt/studio/SOS11/SUNWspro/bin/cc -xarch=v9 -L/opt/csw/lib/
64 -R/opt/csw/lib/\\$ISALIST -R/opt/csw/lib/64 -o vim -lm -
lncurses -liconv -lintl -ldl
Can you try to reproduce it after recompiling everything with
the equivalent of gcc options -O0 -g (I don't remember what
these options are for the cc Sun compiler)
So debugger can then display the proper line numbers in the stack.
hash_init() seems to be called from spell_read_off() with an
address which is not 8-bytes aligned. So it's one of those
3 lines in spell.c:
5328 hash_init(aff-af_pref);
5329 hash_init(aff-af_suff);
5330 hash_init(aff-af_comp);
So if looks like aff itself it not aligned on 8 bytes (required alignement
since struct afffile_T contains pointers)
aff comes is initialized just above with:
5322 aff = (afffile_T *)getroom(spin, sizeof(afffile_T), TRUE);
The TRUE parameter means that it requests an address aligned
for pointers. So this bug should normally not happen.
But the value 0x100313ac4 given by debugger is not
aligned indeed on 8 bytes.
So the bug must be in getroom(...).
I see that getroom(...) has some logic for alignement:
7435 if (align bl != NULL)
7436 /* Round size up for alignment. On some systems
structures need to be
7437 * aligned to the size of a pointer (e.g., SPARC). */
7438 bl-sb_used = (bl-sb_used + sizeof(char *) - 1)
7439
~(sizeof(char *) - 1);
...
7453 p = bl-sb_data + bl-sb_used;
7454 bl-sb_used += (int)len;
7455
7456 return p;
7457 }
But it looks wrong. It only align bl-sb_used on 8 bytes
but not the return value p.
p depends on bl-sb_data (not aligned) and
bl-sb_used (which is 8-bytes aligned)
bl-sb_data is not 8-bytes aligned since struct of bl is:
4962 struct sblock_S
4963 {
4964 sblock_T*sb_next; /* next block in list */
4965 int sb_used;/* nr of bytes already in use */
4966 char_u sb_data[1]; /* data, actually longer */
4967 };
First field sb_next is a pointer, so aligned on 8 bytes.
Second field sb_used is thus also 8 bytes aligned.
But sizeof(int) is 4 (on most machines). So third field sb_data[1]
will be aligned on 4 bytes only (not 8).
One way to ensure alignment of sb_data on 8 bytes would be
to reorder fields in sblock_S as follows:
***
*** 4961,4968
typedef struct sblock_S sblock_T;
struct sblock_S
{
- sblock_T *sb_next; /* next block in list */
int sb_used;/* nr of bytes already in use */
char_usb_data[1]; /* data, actually longer */
};
--- 4961,4968
typedef struct sblock_S sblock_T;
struct sblock_S
{
int sb_used;/* nr of bytes already in use */
+ sblock_T *sb_next; /* next block in list */
char_usb_data[1]; /* data, actually longer, must be
aligned on 8 bytes */
};
Does this fix it? I don't have a 64-bit machine to test
PS: there is also a typo in spell.c
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Test 58 failure on solaris (64bit)
Dominique Pelle wrote
***
*** 4961,4968
typedef struct sblock_S sblock_T;
struct sblock_S
{
- sblock_T *sb_next; /* next block in list */
int sb_used;/* nr of bytes already in use */
char_usb_data[1]; /* data, actually longer */
};
--- 4961,4968
typedef struct sblock_S sblock_T;
struct sblock_S
{
int sb_used;/* nr of bytes already in use */
+ sblock_T *sb_next; /* next block in list */
char_usb_data[1]; /* data, actually longer, must be
aligned on 8 bytes */
};
Does this fix it? I don't have a 64-bit machine to test
PS: there is also a typo in spell.c
Attached patch for spell.c should fix:
- alignment bug on 64 bits machines
- infinite loop when pressing ]s (as reported by Ingo last week)
- typo in a comment
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: spell.c
===
RCS file: /cvsroot/vim/vim7/src/spell.c,v
retrieving revision 1.121
diff -c -r1.121 spell.c
*** spell.c 9 Dec 2008 21:34:19 - 1.121
--- spell.c 28 Jan 2009 20:32:04 -
***
*** 2335,2348
if (curline)
break; /* only check cursor line */
/* Advance to next line. */
if (dir == BACKWARD)
{
- /* If we are back at the starting line and searched it again there
- * is no match, give up. */
- if (lnum == wp-w_cursor.lnum wrapped)
- break;
-
if (lnum 1)
--lnum;
else if (!p_ws)
--- 2335,2348
if (curline)
break; /* only check cursor line */
+ /* If we are back at the starting line and searched it again there
+ * is no match, give up. */
+ if (lnum == wp-w_cursor.lnum wrapped)
+ break;
+
/* Advance to next line. */
if (dir == BACKWARD)
{
if (lnum 1)
--lnum;
else if (!p_ws)
***
*** 4961,4968
typedef struct sblock_S sblock_T;
struct sblock_S
{
- sblock_T *sb_next; /* next block in list */
int sb_used; /* nr of bytes already in use */
char_u sb_data[1]; /* data, actually longer */
};
--- 4961,4968
typedef struct sblock_S sblock_T;
struct sblock_S
{
int sb_used; /* nr of bytes already in use */
+ sblock_T *sb_next; /* next block in list */
char_u sb_data[1]; /* data, actually longer */
};
***
*** 15011,15017
case 0:
/*
! * Lenghts are equal, thus changes must result in same length: An
* insert is only possible in combination with a delete.
* 1: check if for identical strings
*/
--- 15011,15017
case 0:
/*
! * Lengths are equal, thus changes must result in same length: An
* insert is only possible in combination with a delete.
* 1: check if for identical strings
*/
[patch] test51 fails when locale is set to es_ES.UTF-8
Hi
I observe that test51 fails as follows when locale
is set to es_ES.UTF-8 (it succeeds for other locale,
well, I did not try all of them yet):
$ export LANGUAGE=es_ES.UTF-8
$ cd vim7/src
$ make test
Test results:
test51 FAILED
$ diff -c testdir/test51.{ok,failed}
*** testdir/test51.ok 2006-02-28 00:54:45.0 +0100
--- testdir/test51.failed 2009-01-28 21:44:07.0 +0100
***
*** 17,20
Group3 xxx cleared
! E475: term='asdf
--- 17,20
Group3 xxx cleared
! E475: term='asdf.
Attached patch (removal of dot in translated Spanish message)
fixes it. But maybe the test itself should be more robust.
Anyway, since the original English message for E475 did not
have the final dot, I don't think the Spanish test should have it
either.
Cheers
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: es.po
===
RCS file: /cvsroot/vim/vim7/src/po/es.po,v
retrieving revision 1.6
diff -c -r1.6 es.po
*** es.po 13 Jul 2008 17:28:53 - 1.6
--- es.po 28 Jan 2009 20:47:19 -
***
*** 5206,5212
#, c-format
msgid E475: Invalid argument: %s
! msgstr E475: Argumento no válido: %s.
#, c-format
msgid E15: Invalid expression: %s
--- 5206,5212
#, c-format
msgid E475: Invalid argument: %s
! msgstr E475: Argumento no válido: %s
#, c-format
msgid E15: Invalid expression: %s
Re: Test 58 failure on solaris (64bit)
Bram Moolenaar wrote: =[1] hash_init(0x100313ac4, 0x3b0, 0x1003139fc, 0x440, 0x90, 0x100313aec), at 0x1000bbd00 hash_init() only has one argument, I wonder what the numbers mean. I think that's because the debugger did not know how many arguments the function has (because Vim was compiled without debug option), so debugger just prints first n registers that the ABI uses to for passing arguments. 0x100313ac4 was the unique relevant parameter here. I see that debugger output when compiled with debug is a lot better: [9] hash_init(ht = 0x10044a7a4), line 72 in hashtab.c Cheers -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] fixed missing gettext translations in eval.c
Tony Mechelynck wrote: On 24/01/09 12:25, Bram Moolenaar wrote: Dominique Pelle wrote: [...] Notice also the FIXME comment in the attached patch: shouldn't E118 and E740 error message be the same error message? See how similar they are: E740: Too many arguments for function %s E118: Too many arguments for function: %s I then entered the following command to see whether they are other dupes in the translated messages and found the following: [...] Even though these messages have the same text, they are still different errors. In a try/catch you can use the error number to distinguish them. Also, their different error numbers refer to different places in the help, with more or less different explanations. Bram: If the Vim code tries to translate E123: Some error, will it try Some error if nothing starting E123 is found? If it does, we could use a single translate string for two or more error merssages, and the error number would still be there. Best regards, Tony. Gettext is not going to do smart things a such as trying to translate Some error if E123: Some error is not found. And that's fine since gettext is not part of Vim and it should not try to second guess (KISS principle). The explanation about catching different errors even though the text is identical made sense of course. I did not think about it earlier. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: BUG: Endless loop on ]s when no misspelled words
Ingo Karkat wrote:
Hello VIM developers,
I've encountered occasional endless loops when trying to jump to the next
misspelled word (via ]s) in HTML documents, in the case when there aren't any
misspellings. VIM then starts consuming all available CPU until the operation
is
aborted via CTRL-C. I was able to come up with a minimal test case to
reproduce
this problem:
cat test.html 'EOF'
html
body
p In here appears the bug. /p
/body
/html
EOF
vim -N -u NONE test.html
:syntax on
:setlocal spell
/here
:normal! ]s
VIM hangs; press CTRL-C to get out of the loop.
:normal! j]s
On any other line, VIM just correctly prints
search hit BOTTOM, continuing at TOP
The loop only occurs when the cursor is inside the p.../p. It seems that
VIM
then doesn't detect that the entire buffer has been searched and keeps on
searching forever; the bug doesn't manifest itself when 'wrapscan' is turned
off.
The syntax/html.vim script sets ':syn spell toplevel' and attaches @Spell to
some syntax clusters, but doesn't do anything strange or overly complex.
Probably, other filetypes can be affected by this, too.
I can reproduce this problem starting from VIM 7.0 up to VIM 7.2.84, on MS
Windows and Linux/x86.
-- regards, ingo
Confirmed here. I can also reproduce it with vim-7.2.88 on Linux x86
and gvim (GTK2 GUI).
Attached patch fixes it, but please review it.
When pressing ]s, I see search hit BOTTOM, continuing at TOP
and CPU usage climbs to 100%. In the terminal, I see the cursor
at the end of search hit BOTTOM, continuing at TOP which is quickly
flickering, so messagesearch hit BOTTOM, continuing at TOP is
probably being redisplayed many times in a loop.
Attaching with gdb, I sample a couple of stack traces when pressing
CTRL-C:
(gdb) bt
#0 0x0819bcca in syn_current_attr (syncing=0, displaying=1,
can_spell=0xbfa3cb4c, keep_state=0)
at syntax.c:1975
#1 0x0819b7e2 in get_syntax_attr (col=16, can_spell=0xbfa3cb4c,
keep_state=0) at syntax.c:1771
#2 0x081a30ca in syn_get_id (wp=0x8e08374, lnum=3, col=16, trans=0,
spellp=0xbfa3cb4c, keep_state=0)
at syntax.c:6134
#3 0x0817c8f8 in spell_move_to (wp=0x8e08374, dir=1, allwords=1,
curline=0, attrp=0x0) at spell.c:2284
#4 0x0812c01d in nv_brackets (cap=0xbfa3cca4) at normal.c:6563
#5 0x081231ed in normal_cmd (oap=0xbfa3cd50, toplevel=1) at normal.c:1200
#6 0x080e60ae in main_loop (cmdwin=0, noexmode=0) at main.c:1180
#7 0x080e5bfb in main (argc=5, argv=0xbfa3cf54) at main.c:939
(gdb) bt
#0 0x081a2c71 in in_id_list (cur_si=0x8e1e454, list=0x8e0e3a0,
ssp=0x8ec1958, contained=1)
at syntax.c:5927
#1 0x0819bd5a in syn_current_attr (syncing=0, displaying=1,
can_spell=0xbfa3cb4c, keep_state=0)
at syntax.c:1975
#2 0x0819b7e2 in get_syntax_attr (col=46, can_spell=0xbfa3cb4c,
keep_state=0) at syntax.c:1771
#3 0x081a30ca in syn_get_id (wp=0x8e08374, lnum=3, col=46, trans=0,
spellp=0xbfa3cb4c, keep_state=0)
at syntax.c:6134
#4 0x0817c8f8 in spell_move_to (wp=0x8e08374, dir=1, allwords=1,
curline=0, attrp=0x0) at spell.c:2284
#5 0x0812c01d in nv_brackets (cap=0xbfa3cca4) at normal.c:6563
#6 0x081231ed in normal_cmd (oap=0xbfa3cd50, toplevel=1) at normal.c:1200
#7 0x080e60ae in main_loop (cmdwin=0, noexmode=0) at main.c:1180
#8 0x080e5bfb in main (argc=5, argv=0xbfa3cf54) at main.c:939
If I put a debug fprintf(stderr, ...) before call to
spell_move_to(...) @ normal.c:6563
I see that the message printed only once. So spell_move_to() does not return.
I I put a debug fprintf(stderr, ...) before call to give_warning(...)
@ spell.c:2374
I see the message printed many times in a loop so give_warning(...) returns.
Vim is thus looping inside spell_move_to(...), calling
give_warning(...) multiple
times. This is inside the while (!got_int) loop at spell.c:2209.
If I put a printf(stderr, ...) inside this while loop before this line
in spell.c:
2211 line = ml_get_buf(wp-w_buffer, lnum, FALSE);
... then I see that ml_get_buf(...) is called for lines:
3, 4, 5, 1 2, 3, 4, 5, 1, 2, 3, 4, 5, 1, 2...
I see that we don't check for wrapping when looping forward, but
we do check for wrapping when looping backward.
Attached patch fixes it but please review it.
Regards
--
Dominique http://dominiko.livejournal.com
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: spell.c
===
RCS file: /cvsroot/vim/vim7/src/spell.c,v
retrieving revision 1.121
diff -c -r1.121 spell.c
*** spell.c 9 Dec 2008 21:34:19 - 1.121
--- spell.c 25 Jan 2009 20:34:24 -
***
*** 2335,2348
if (curline)
break; /* only check cursor line */
/* Advance to next line. */
if (dir == BACKWARD)
{
- /* If we are back at the starting line and
[patch] fixed missing gettext translations in eval.c
I noticed a few error messages which are not translated with gettext in eval.c.
For example, I do:
:lang fr_FR.UTF-8
:call filter(list)
I get an error message in English...
E116: Invalid arguments for function filter
... which I'd expect to be translated with gettext in French.
Attached patch fixes a couple of such error messages
which are not translated.
Notice also the FIXME comment in the attached patch: shouldn't
E118 and E740 error message be the same error message?
See how similar they are:
E740: Too many arguments for function %s
E118: Too many arguments for function: %s
I then entered the following command to see whether they
are other dupes in the translated messages and found
the following:
$ cd vim7/src/po
$ grep msgid fr.po | egrep 'E[0-9]+' |
sed s'/msgid E[0-9]*://' |
sort | uniq -c |
perl -ane 'print if ($F[0] 1)'
2 Cannot read from \%s\
2 Can't find file \%s\ in path
2 Can't open file \%s\
2 digit expected
2 Missing quote: %s
2 No such syntax cluster: %s
2 Unknown option: %s
3 Illegal argument: %s
3 Missing colon
3 Unknown function: %s
msgid E230: Cannot read from \%s\
msgid E282: Cannot read from \%s\
msgid E345: Can't find file \%s\ in path
msgid E447: Can't find file \%s\ in path
msgid E624: Can't open file \%s\
msgid E456: Can't open file \%s\
msgid E552: digit expected
msgid E548: digit expected
msgid E114: Missing quote: %s
msgid E115: Missing quote: %s
msgid E391: No such syntax cluster: %s
msgid E392: No such syntax cluster: %s
msgid E113: Unknown option: %s
msgid E355: Unknown option: %s
msgid E390: Illegal argument: %s
msgid E423: Illegal argument: %s
msgid E125: Illegal argument: %s
msgid E550: Missing colon
msgid E545: Missing colon
msgid E524: Missing colon
msgid E130: Unknown function: %s
msgid E117: Unknown function: %s
msgid E700: Unknown function: %s
There are some other messages that are almost identical:
msgid E152: Cannot open %s for writing
msgid E190: Cannot open \%s\ for writing
msgid E484: Can't open file %s
msgid E624: Can't open file \%s\
msgid E456: Can't open file \%s\
Cheers
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: eval.c
===
RCS file: /cvsroot/vim/vim7/src/eval.c,v
retrieving revision 1.278
diff -c -r1.278 eval.c
*** eval.c 23 Dec 2008 22:52:58 - 1.278
--- eval.c 24 Jan 2009 07:19:16 -
***
*** 7918,7926
else if (!aborting())
{
if (argcount == MAX_FUNC_ARGS)
! emsg_funcname(E740: Too many arguments for function %s, name);
else
! emsg_funcname(E116: Invalid arguments for function %s, name);
}
while (--argcount = 0)
--- 7918,7927
else if (!aborting())
{
if (argcount == MAX_FUNC_ARGS)
! /* FIXME: or should e_toomanyarg be used here? */
! emsg_funcname(N_(E740: Too many arguments for function %s), name);
else
! emsg_funcname(N_(E116: Invalid arguments for function %s), name);
}
while (--argcount = 0)
***
*** 19867,19873
}
}
else
! emsg_funcname(E123: Undefined function: %s, name);
}
goto ret_free;
}
--- 19868,19874
}
}
else
! emsg_funcname(N_(E123: Undefined function: %s), name);
}
goto ret_free;
}
***
*** 20183,20189
v = find_var(name, ht);
if (v != NULL v-di_tv.v_type == VAR_FUNC)
{
! emsg_funcname(E707: Function name conflicts with variable: %s,
name);
goto erret;
}
--- 20184,20190
v = find_var(name, ht);
if (v != NULL v-di_tv.v_type == VAR_FUNC)
{
! emsg_funcname(N_(E707: Function name conflicts with variable: %s),
name);
goto erret;
}
***
*** 20198,20204
}
if (fp-uf_calls 0)
{
! emsg_funcname(E127: Cannot redefine function %s: It is in use,
name);
goto erret;
}
--- 20199,20205
}
if (fp-uf_calls 0)
{
! emsg_funcname(N_(E127: Cannot redefine function %s: It is in use),
name);
goto erret;
}
***
*** 21477,21483
/*
* Return TRUE if items in fc do not have copyID. That means they are not
! * referenced from anywyere.
*/
static int
can_free_funccal(fc, copyID)
--- 21478,21484
/*
* Return TRUE if items in fc do not have copyID. That means they are not
! * referenced from anywhere.
*/
static int
can_free_funccal(fc, copyID)
[patch] URL with '~' character not highlighted properly with ft=doxygen
Hi URLs in doxygen syntax highlighting are not properly highlighted when they contain a tilde ~ character (which is a fairly frequent character in a URL). Attached trivial patch fixes it. Regards -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- fix-tilda-in-url-doxygen.vim Description: Binary data
Re: [patch] Dynamic folding in 2html.vim output
Benjamin Fritz wrote A patch is attached for the behavior discussed in these threads: http://groups.google.com/group/vim_use/browse_thread/thread/8532e7236f113ab7/0b508a50b767a1e1 http://groups.google.com/group/vim_dev/browse_thread/thread/56d5debad6f5f351/44cc7eb3b4787440 Also attached is an example of the output when used on the two attached patches. I used html_dynamic_folds on the 2html.vim patch, and additionally html_no_foldcolumn and html_hover_unfold on the syntax.txt patch. As discussed in the vim_dev thread above, it may be desirable to be able to do away with the foldcolumn in the html output, but it was hard to determine what to do to allow folds to open and close without it. Rather than making the javascript and markup needlessly complex, I just used CSS 2.0 :hover selection to open folds on hover if desired (though normally, only CSS 1.0 support is required, and a fallback is inserted for IE6). Please comment! -- Ben That's very nice and useful. Thanks. One minor comment. In syntax.txt, I read: If you use this option, it would not be possible to open the folds I think it should be... If you used this option, it would not be possible to open the folds :s/use/d/ -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] Dynamic folding in 2html.vim output
Benjamin Fritz: A patch is attached for the behavior discussed in these threads: http://groups.google.com/group/vim_use/browse_thread/thread/8532e7236f113ab7/0b508a50b767a1e1 http://groups.google.com/group/vim_dev/browse_thread/thread/56d5debad6f5f351/44cc7eb3b4787440 Also attached is an example of the output when used on the two attached patches. I used html_dynamic_folds on the 2html.vim patch, and additionally html_no_foldcolumn and html_hover_unfold on the syntax.txt patch. As discussed in the vim_dev thread above, it may be desirable to be able to do away with the foldcolumn in the html output, but it was hard to determine what to do to allow folds to open and close without it. Rather than making the javascript and markup needlessly complex, I just used CSS 2.0 :hover selection to open folds on hover if desired (though normally, only CSS 1.0 support is required, and a fallback is inserted for IE6). Please comment! -- Ben I can't apply the patch cleanly unfortunately. There are conflicts. 2html.vim.diff is a patch from a version last changed on 2008 Dec 03 But... 2html.vim in CVS was last changed on 2008 Jul 17 (too old) 2html.vim from ftp contains a version changed on 2009 Jan 13 (too new) Regards -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: gVim 7.2 hangs when issuing ':h shortmess' command
Valery Kondakoff wrote: Hi! If there is a 'set encoding=utf-8' line in my _vimrc gVim 7.2 hangs when issuing ':h shortmess' command consuming ~50% of CPU usage. Can anyone confirm this? The ':h shortmess' command works as expected when I'm commenting the 'set encoding=utf-8' line out and restarting gVim. On the other hand gVim hangs on ':h shortmess' when 'set encoding=utf-8' is the only one line in _vimrc. Is this a bug or am I doing smth wrong? I'm using gVim 7.2 in Win Vista HP SP1. Thanks. I can't reproduce this with Vim-7.2 neither on Linux, nor on Windows Vista SP1. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Dynamic folding in 2html.vim output
Ben Fritz wrote On Jan 17, 9:54 am, Ben Fritz fritzophre...@gmail.com wrote: I can't apply the patch cleanly unfortunately. There are conflicts. I could use SVN if the runtime files are up-to-date in there. It looks like the ones in CVS are not. I would probably prefer this method, actually. Thouh, I would need someone to tell me where to find the latest runtime files in the huge tree in the repository. I've tried browsing the SVN repo before, and it's a bit overwhelming for someone who's never worked in it before. Try: rsync -avzcP --delete --exclude=dos --exclude=spell ftp.nluug.nl::Vim/runtime/ . But I personally do that in another directory than my main vim directory because it not only pulls new files but also delete files. I don't know why runtime files are not updated in CVS like source files. It would be more convenient. Or maybe in a separate CVS module if runtime files are deemed too large. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
(patch) fixed cosmetic alignment bug in :cs help
Hi,
Attached patch fixes a low priority cosmetic bug.
When doing :cs help, messages are properly aligned
in English but are misaligned on some other languages
when using utf-8 encoding. So it looks ugly.
Misalignment buglet happens in languages which uses
non ASCII characters and happens at least for French
and Esperanto for example because of accentuated
characters.
The problem happens because cs_help() in if_cscope.c
uses %-30s format to align text but %-30s prints
strings on 30 *bytes* rather than 30 characters (or
30 screen cells to be more exact).
Attached patch fixes it.
See screenshot before fix (notice how strings are misaligned):
http://dominique.pelle.free.fr/pic/align-buglet-eo.png
And after fix (strings correctly aligned):
http://dominique.pelle.free.fr/pic/align-buglet-eo-fixed.png
Cheers
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: if_cscope.c
===
RCS file: /cvsroot/vim/vim7/src/if_cscope.c,v
retrieving revision 1.32
diff -c -r1.32 if_cscope.c
*** if_cscope.c 25 Aug 2008 02:35:59 - 1.32
--- if_cscope.c 17 Jan 2009 22:29:26 -
***
*** 1177,1184
(void)MSG_PUTS(_(cscope commands:\n));
while (cmdp-name != NULL)
{
! (void)smsg((char_u *)_(%-5s: %-30s (Usage: %s)),
! cmdp-name, _(cmdp-help), cmdp-usage);
if (strcmp(cmdp-name, find) == 0)
MSG_PUTS(_(\n
c: Find functions calling this function\n
--- 1177,1192
(void)MSG_PUTS(_(cscope commands:\n));
while (cmdp-name != NULL)
{
! char *help = _(cmdp-help);
! int sz = vim_strsize((char_u *)help);
! int space_cnt = 30 - sz;
! if (space_cnt 0)
! space_cnt = 0;
! /* Use %*s rather than %30s to ensure proper alignment in utf-8 */
! (void)smsg((char_u *)_(%-5s: %s%*s (Usage: %s)),
! cmdp-name,
! help, space_cnt, ,
! cmdp-usage);
if (strcmp(cmdp-name, find) == 0)
MSG_PUTS(_(\n
c: Find functions calling this function\n
Re: some multi-byte is treated as K_SPECIAL in command line
2009/1/14 Tony Mechelynck antoine.mechely...@gmail.com: On 14/01/09 07:16, Yasuhiro MATSUMOTO wrote: Oops. sorry. However, the problem happen with the script as your said. :-) Thanks. E486: Pattern not found means that there was no match. Are you sure you ran that script while the current file contained one or more 。 characters? When I do (manually) :%s/。/./g on the UTF-8 script I sent you, the result is 2 substitutions on 2 lines and the fullwidth fullstops are replaced by ASCII dots. I'm using gvim 7.2.84 (Huge version, with GTK2/Gnome GUI). Best regards, Tony. I confirm the bug. - Doing :%s/。/./g works (no error, and substitution happens). - But doing... :command! SubJapanesePeriodToDot %s/。/./g :SubJapanesePeriodToDot ... then I get the error message: E486: Pattern not found: e380feX82 I'm using Vim-7.2.84 on Linux, with a utf-8 locale. 。is Unicode character U+3002 (i.e. UTF-8 sequence 0xe3 0x80 0x82). -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
[patch] fixed bug in :diffget and :diffput
Hi When the argument of the commands :diffget or :diffput results in the same buffer as the current buffer, the command corrupts the content of the current buffer. Steps to reproduce: 1/ create 2 sample files $ echo foo file1 $ echo bar file2 2/ run vim in diff mode $ vim -u NONE -d file1 file2 3/ While in file1, run the command :diffget 1 Notice that argument 1 reffers buffer of file1 (i.e. current buffer) so I would expect diffget to do nothing. Instead I observe that if deletes the content of the diff chunk. Only diffget 2 would make sense here. In some more complex cases, it creates garbage in the current buffer. Valgrind memory checker also detects errors at step 3/ in the case of diffget command: ==11910== Conditional jump or move depends on uninitialised value(s) ==11910==at 0x80CC2A2: aucmd_restbuf (fileio.c:8405) ==11910==by 0x80626D9: ex_diffgetput (diff.c:2348) ==11910==by 0x80A679B: do_one_cmd (ex_docmd.c:2622) ==11910==by 0x80A401B: do_cmdline (ex_docmd.c:1096) ==11910==by 0x8129708: nv_colon (normal.c:5233) ==11910==by 0x8122D8C: normal_cmd (normal.c:1200) ==11910==by 0x80E5FD5: main_loop (main.c:1180) ==11910==by 0x80E5B22: main (main.c:939) ==11910== ==11910== Conditional jump or move depends on uninitialised value(s) ==11910==at 0x81BC35D: win_valid (window.c:1234) ==11910==by 0x80CC2B5: aucmd_restbuf (fileio.c:8409) ==11910==by 0x80626D9: ex_diffgetput (diff.c:2348) ==11910==by 0x80A679B: do_one_cmd (ex_docmd.c:2622) ==11910==by 0x80A401B: do_cmdline (ex_docmd.c:1096) ==11910==by 0x8129708: nv_colon (normal.c:5233) ==11910==by 0x8122D8C: normal_cmd (normal.c:1200) ==11910==by 0x80E5FD5: main_loop (main.c:1180) ==11910==by 0x80E5B22: main (main.c:939) ==11910== ==11910== Conditional jump or move depends on uninitialised value(s) ==11910==at 0x81BC378: win_valid (window.c:1237) ==11910==by 0x80CC2B5: aucmd_restbuf (fileio.c:8409) ==11910==by 0x80626D9: ex_diffgetput (diff.c:2348) ==11910==by 0x80A679B: do_one_cmd (ex_docmd.c:2622) ==11910==by 0x80A401B: do_cmdline (ex_docmd.c:1096) ==11910==by 0x8129708: nv_colon (normal.c:5233) ==11910==by 0x8122D8C: normal_cmd (normal.c:1200) ==11910==by 0x80E5FD5: main_loop (main.c:1180) ==11910==by 0x80E5B22: main (main.c:939) Attached patch (against vim-7.2.84) fixes it by making sure that :diffget or :diffput don't do anything when the argument specifies the same buffer as the current buffer. Maybe an error message could also be given but I don't think it's necessary. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- Index: diff.c === RCS file: /cvsroot/vim/vim7/src/diff.c,v retrieving revision 1.32 diff -c -r1.32 diff.c *** diff.c 30 Nov 2008 14:16:37 - 1.32 --- diff.c 13 Jan 2009 19:11:56 - *** *** 8,14 */ /* ! * diff.c: code for diff'ing two or three buffers. */ #include vim.h --- 8,14 */ /* ! * diff.c: code for diff'ing two, three or four buffers. */ #include vim.h *** *** 116,122 * Add a buffer to make diffs for. * Call this when a new buffer is being edited in the current window where * 'diff' is set. ! * Marks the current buffer as being part of the diff and requireing updating. * This must be done before any autocmd, because a command may use info * about the screen contents. */ --- 116,122 * Add a buffer to make diffs for. * Call this when a new buffer is being edited in the current window where * 'diff' is set. ! * Marks the current buffer as being part of the diff and requiring updating. * This must be done before any autocmd, because a command may use info * about the screen contents. */ *** *** 929,935 goto theend; #ifdef UNIX ! /* Temporaraly chdir to /tmp, to avoid patching files in the current * directory when the patch file contains more than one patch. When we * have our own temp dir use that instead, it will be cleaned up when we * exit (any .rej files created). Don't change directory if we can't --- 929,935 goto theend; #ifdef UNIX ! /* Temporarily chdir to /tmp, to avoid patching files in the current * directory when the patch file contains more than one patch. When we * have our own temp dir use that instead, it will be cleaned up when we * exit (any .rej files created). Don't change directory if we can't *** *** 2129,2134 --- 2129,2136 EMSG2(_(E102: Can't find buffer \%s\), eap-arg); return; } + if (buf == curbuf) + return; /* nothing to do */ idx_other = diff_buf_idx(buf); if (idx_other ==
Re: Vim SEGV
2008/12/27 Matt Wozniski wrote: I found a SEGV that I can reproduce reliably, but can't seem to track down. It SEGVs without gdb or valgrind, doesn't SEGV under valgrind, and SEGVs under gdb. The steps that I'm using to reproduce this are complicated, and possibly very specific to the version of the runtime files and such that I'm using, but I'm hoping that a log of the backtrace + valgrind log can help someone to track it down. GDB shows: Program received signal SIGSEGV, Segmentation fault. 0xb8063424 in __kernel_vsyscall () (gdb) bt #0 0xb8063424 in __kernel_vsyscall () #1 0xb7885956 in kill () from /lib/i686/cmov/libc.so.6 #2 0x08137c79 in may_core_dump () at os_unix.c:3070 #3 0x08137c10 in mch_exit (r=1) at os_unix.c:3035 #4 0x080db39c in getout (exitval=1) at main.c:1344 #5 0x08100ea0 in preserve_exit () at misc1.c:8371 #6 0x0813617c in deathtrap (sigarg=11) at os_unix.c:1057 #7 signal handler called #8 0x08079b32 in deref_func_name (name=0x90546a5 netrw#Explore(0,0,0+0,''), lenp=0xbf87d4ec) at eval.c:7833 #9 0x0808b2e5 in trans_function_name (pp=0xbf87d574, skip=0, flags=1, fdp=0xbf87d554) at eval.c:20395 #10 0x0807389e in ex_call (eap=0xbf87d608) at eval.c:3271 #11 0x080a0d5b in do_one_cmd (cmdlinep=0xbf87da44, sourcing=1, cstack=0xbf87d740, fgetline=0, cookie=0x0) at ex_docmd.c:2622 #12 0x0809e834 in do_cmdline (cmdline=0x9126bb0 call netrw#Explore(0,0,0+0,''), getline=0, cookie=0x0, flags=11) at ex_docmd.c:1096 #13 0x080a6562 in do_ucmd (eap=0xbf87db78) at ex_docmd.c:5989 #14 0x080a0d32 in do_one_cmd (cmdlinep=0xbf87dfb4, sourcing=1, cstack=0xbf87dcb0, fgetline=0, cookie=0x0) at ex_docmd.c:2613 #15 0x0809e834 in do_cmdline (cmdline=0x91165c6 E, getline=0, cookie=0x0, flags=11) at ex_docmd.c:1096 #16 0x0809e0f1 in do_cmdline_cmd (cmd=0x91165c6 E) at ex_docmd.c:702 #17 0x080997f0 in ex_debug (eap=0xbf87e0c8) at ex_cmds2.c:301 #18 0x080a0d5b in do_one_cmd (cmdlinep=0xbf87e504, sourcing=0, cstack=0xbf87e200, fgetline=0x80b4047 getexline, cookie=0x0) at ex_docmd.c:2622 #19 0x0809e834 in do_cmdline (cmdline=0x0, getline=0x80b4047 getexline, cookie=0x0, flags=0) at ex_docmd.c:1096 #20 0x081188af in nv_colon (cap=0xbf87e5f0) at normal.c:5233 #21 0x08111f9b in normal_cmd (oap=0xbf87e690, toplevel=1) at normal.c:1200 #22 0x080db0e3 in main_loop (cmdwin=0, noexmode=0) at main.c:1183 #23 0x080dac41 in main (argc=1, argv=0xbf87e894) at main.c:942 Valgrind gives: 1 errors in context 1 of 1: Invalid read of size 4 at 0x8088402: find_var_in_ht (eval.c:18815) by 0x8088277: find_var (eval.c:18769) by 0x8079B16: deref_func_name (eval.c:7831) by 0x808B2E4: trans_function_name (eval.c:20395) by 0x807389D: ex_call (eval.c:3271) by 0x80A0D5A: do_one_cmd (ex_docmd.c:2622) by 0x809E833: do_cmdline (ex_docmd.c:1096) by 0x80A6561: do_ucmd (ex_docmd.c:5989) by 0x80A0D31: do_one_cmd (ex_docmd.c:2613) by 0x809E833: do_cmdline (ex_docmd.c:1096) by 0x809E0F0: do_cmdline_cmd (ex_docmd.c:702) by 0x80997EF: ex_debug (ex_cmds2.c:301) Address 0x4d9ebbc is 916 bytes inside a block of size 2,048 free'd at 0x4022B8A: free (vg_replace_malloc.c:323) by 0x81037B6: vim_free (misc2.c:1625) by 0x80D7F8C: hash_may_resize (hashtab.c:467) by 0x80D7C5C: hash_add_item (hashtab.c:254) by 0x80D7BD4: hash_add (hashtab.c:227) by 0x8088E54: set_var (eval.c:19189) by 0x8072C7F: set_var_lval (eval.c:2787) by 0x80721B1: ex_let_one (eval.c:2403) by 0x80711B2: ex_let_vars (eval.c:1858) by 0x8071163: ex_let (eval.c:1823) by 0x80A0D5A: do_one_cmd (ex_docmd.c:2622) by 0x809E833: do_cmdline (ex_docmd.c:1096) I can give any more information anyone might need. I've been reproducing this by doing :debug Explore, stepping to line 300, then quitting from debug mode - but I would not be at all shocked if that doesn't work for others. I'll keep trying to track it down, but Dominique seems to really have a knack for finding these sorts of problems, so maybe he can shorten the bug-hunting time. :-) ~Matt From the stack trace, a pointer is dereferenced, and points to some invalid (freed) memory, as a result of a previous memory reallocation in hash_may_resize(). I tried to reproduce it but I could not. Which command(s) do you use to step to line 300? Also which version of Vim are you using? I'm asking because the line numbers in the valgrind stack trace are not consistent with the latest eval.c of vim-7.2.75. Maybe compiling with -O0 can help to get better debug information (if not already done?). Cheers -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim SEGV
Matt Wozniski wrote: I tried to reproduce it but I could not. Yeah, I'm not surprised... the fact that it seems tied to a hash table resizing makes me think that it's very much tied to the number of plugins I have loaded, the number of variables I have defined, and a whole bunch of other, less obvious factors Which command(s) do you use to step to line 300? at the :debug prompt, just pressing sCR and then CR repeatedly until I hit 300. I still have not been able to reproduce it. But as you said, there might be something subtle to trigger the memory reallocation. It'd be nice to have a an automated way to reproduce it. Does the following command for example reproduce the error? (it does not for me). $ yes | tr y s | valgrind vim -D -c ':Explore' 2 valgrind.log If you don't mind, maybe sharing your ~/.vimrc and a tar or your ~/.vim/ directory could help others to reproduce it. Cheers -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] bug in completion with i_CTRL-N using arabic or persian keymap
Richard Hartmann wrote: On Thu, Dec 25, 2008 at 18:52, Dominique Pelle dominique.pe...@gmail.com wrote: set completeopt=menuone,longest set tags=tags set keymap=arabic Are you actually seeing those in your daily work with Vim or do you run an automated test suite that set lots of options and does lots of stuff, etc? Richard Some bugs I observed using Vim regularly when I started testing Vim with Valgrind, but not anymore. It's getting quite difficult to find bugs in Vim using Valgrind, now that obvious bugs have been fixed. So I now try oddest things I can think of, automated or not automated, which may have been tested less. Of course Vim also has so many features, combined with so many different runtime settings and compilation time configurations, that I may only have scratched the surface of testing Vim with Valgrind. Cheers -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: fold-delete-marker SEGV fix
Dominique Pelle wrote: Lech Lorens skribis: Problem: The cursor position is not updated after deleting a fold based on markers. This results in an invalid memory reference in some scenarios. How to reproduce: In normal mode perform zRgg$zdaa while editing a file with the following contents: [[[ blah blah blah ]]] vim: fdm=marker fmr=[[[,]]] Fix: The attached patch seems to fix the problem. I can reproduce the bug that you describe with vim-7.2.69. Although it does not crash for me, just after typing 'zd' in 'zRgg$zdaa' valgrind reports the following error: ==15028== Invalid read of size 1 ==15028==at 0x813F67B: utf_head_off (mbyte.c:2498) ==15028==by 0x813FDF5: mb_adjustpos (mbyte.c:2791) ==15028==by 0x813FDA2: mb_adjust_cursor (mbyte.c:2771) ==15028==by 0x81439CB: normal_cmd (normal.c:1339) ==15028==by 0x8106A71: main_loop (main.c:1180) ==15028==by 0x81065BE: main (main.c:939) ==15028== Address 0x677bc71 is 1 bytes after a block of size 4,096 alloc'd ==15028==at 0x4025D2E: malloc (vg_replace_malloc.c:207) ==15028==by 0x8133F88: lalloc (misc2.c:859) ==15028==by 0x8133EA4: alloc (misc2.c:758) ==15028==by 0x8113D37: mf_alloc_bhdr (memfile.c:973) ==15028==by 0x8113357: mf_new (memfile.c:395) ==15028==by 0x8119235: ml_new_data (memline.c:3164) ==15028==by 0x811484B: ml_open (memline.c:373) ==15028==by 0x8073C80: open_buffer (buffer.c:85) ==15028==by 0x810863B: create_windows (main.c:2483) ==15028==by 0x8106351: main (main.c:798) I confirm that your patch fixes it. -- Dominique Actually, testing a bit further, although your patch fixes something (the valgrind error, and the crash for you), I still observe something wrong. I can reproduce the E38 error all the time. According to :help E38 it's an internal error (i.e. bug in Vim): === *E38* Null argument Something inside Vim went wrong and resulted in a NULL pointer. If you know how to reproduce this problem, please report it. |bugs| Steps to reproduce: 1/ use following test.txt sample file: $ cat test.txt [[[ blah blah blah ]]] vim: fdm=marker fmr=[[[,]]] 2/ start vim: $ vim test.txt 3/ In Normal command mode, type: ggA [[[esczdu After tying zd, I observe one folded line with nothing in it (which is already wrong). Then when pressing 'u' for undo, I get the E38 error. Also, the content of the file looks wrong after doing undo. Whenever, I move the cursor, I see E38. It happens with vim-7.2.69 with and without patch for fold.c -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug: E685, SEGV - a:000 garbage collected too early?
Bram Moolenaar skribis:
Matt Wozniski wrote:
function! ReturnArgs(...)
return a:000
endfunction
Seems to work fine?
echo ReturnArgs(1, 2, 3)
SEGV
echo string(ReturnArgs(1, 2, 3))
function! MakeArgsDict(...)
return { 'args': a:000 }
endfunction
E685 Internal Error
echo MakeArgsDict(1, 2, 3)
SEGV
echo string(MakeArgsDict(1, 2, 3))
For it crashes a while after trying these things. Most likely the
reference count for a:000 is wrong. Never thought of someone returning
it...
[...]
I have made a patch to fix this. It's complicated stuff, I hope I
thought of everything that could possibly go wrong, including memory
leaks.
Dominique, can you try including the patch and running valgrind? And
check for memory leaks?
It looks good to me. Patch fixes the bug and I can't see any error
or leak with valgrind memory checker. I tried all test cases reported
by Matt Wozniski, as well as make test (all tests passed).
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: fold-delete-marker SEGV fix
Lech Lorens skribis: Problem: The cursor position is not updated after deleting a fold based on markers. This results in an invalid memory reference in some scenarios. How to reproduce: In normal mode perform zRgg$zdaa while editing a file with the following contents: [[[ blah blah blah ]]] vim: fdm=marker fmr=[[[,]]] Fix: The attached patch seems to fix the problem. I can reproduce the bug that you describe with vim-7.2.69. Although it does not crash for me, just after typing 'zd' in 'zRgg$zdaa' valgrind reports the following error: ==15028== Invalid read of size 1 ==15028==at 0x813F67B: utf_head_off (mbyte.c:2498) ==15028==by 0x813FDF5: mb_adjustpos (mbyte.c:2791) ==15028==by 0x813FDA2: mb_adjust_cursor (mbyte.c:2771) ==15028==by 0x81439CB: normal_cmd (normal.c:1339) ==15028==by 0x8106A71: main_loop (main.c:1180) ==15028==by 0x81065BE: main (main.c:939) ==15028== Address 0x677bc71 is 1 bytes after a block of size 4,096 alloc'd ==15028==at 0x4025D2E: malloc (vg_replace_malloc.c:207) ==15028==by 0x8133F88: lalloc (misc2.c:859) ==15028==by 0x8133EA4: alloc (misc2.c:758) ==15028==by 0x8113D37: mf_alloc_bhdr (memfile.c:973) ==15028==by 0x8113357: mf_new (memfile.c:395) ==15028==by 0x8119235: ml_new_data (memline.c:3164) ==15028==by 0x811484B: ml_open (memline.c:373) ==15028==by 0x8073C80: open_buffer (buffer.c:85) ==15028==by 0x810863B: create_windows (main.c:2483) ==15028==by 0x8106351: main (main.c:798) I confirm that your patch fixes it. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug: E685, SEGV - a:000 garbage collected too early?
2008/12/16 Bram Moolenaar b...@moolenaar.net:
Matt Wozniski wrote:
function! ReturnArgs(...)
return a:000
endfunction
Seems to work fine?
echo ReturnArgs(1, 2, 3)
SEGV
echo string(ReturnArgs(1, 2, 3))
function! MakeArgsDict(...)
return { 'args': a:000 }
endfunction
E685 Internal Error
echo MakeArgsDict(1, 2, 3)
SEGV
echo string(MakeArgsDict(1, 2, 3))
For it crashes a while after trying these things. Most likely the
reference count for a:000 is wrong. Never thought of someone returning
it...
When I debugged, I found that v_list was pointing to an invalid address,
which had been set in call_user_func() to fc.l_varlist; This variable is
in the stack and was only valid while in call_user_func() and the functions it
may calls. Somehow, a list still refers to this address after returning from
call_user_func() so v_list points then to an invalid address.
Making variable fc static (in function call_user_func()) avoids using an
invalid address and thus avoids a crash, but it's still not the right way
to fix it.
Seems to work fine?
echo ReturnArgs(1, 2, 3)
Actually, even though this appears to work, valgrind memory checker
already sees a problem there:
==23275== Invalid read of size 4
==23275==at 0x809C577: echo_string (eval.c:7232)
==23275==by 0x80AD48C: ex_echo (eval.c:19481)
==23275==by 0x80C71C6: do_one_cmd (ex_docmd.c:2622)
==23275==by 0x80C4A46: do_cmdline (ex_docmd.c:1096)
==23275==by 0x8149D7A: nv_colon (normal.c:5233)
==23275==by 0x81433FE: normal_cmd (normal.c:1200)
==23275==by 0x810678D: main_loop (main.c:1180)
==23275==by 0x81062DA: main (main.c:939)
==23275== Address 0xbef5e280 is not stack'd, malloc'd or (recently) free'd
==23275==
==23275== Invalid write of size 4
==23275==at 0x809C59D: echo_string (eval.c:7239)
==23275==by 0x80AD48C: ex_echo (eval.c:19481)
==23275==by 0x80C71C6: do_one_cmd (ex_docmd.c:2622)
==23275==by 0x80C4A46: do_cmdline (ex_docmd.c:1096)
==23275==by 0x8149D7A: nv_colon (normal.c:5233)
==23275==by 0x81433FE: normal_cmd (normal.c:1200)
==23275==by 0x810678D: main_loop (main.c:1180)
==23275==by 0x81062DA: main (main.c:939)
==23275== Address 0xbef5e280 is not stack'd, malloc'd or (recently) free'd
(etc, more errors to follow)
Line eval.c:7232 is:
7232 else if (copyID != 0 tv-vval.v_list-lv_copyID == copyID)
7233 {
7234 *tofree = NULL;
7235 r = (char_u *)[...];
7236 }
'tv-vval.v_list' points to the invalid address which set as there
at line 21193:
21191 v-di_tv.v_type = VAR_LIST;
21192 v-di_tv.v_lock = VAR_FIXED;
21193 v-di_tv.vval.v_list = fc.l_varlist;
(fc being a local var in the stack)
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
[patch] fixed minor errors in vim help files
Attached patch fixes a few minor errors in vim help files.
Diff is against latest version available at ftp.nluug.nl::Vim/runtime/
Regards
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
*** /home/pel/sb/vim-runtime/doc/cmdline.txt 2008-12-01 21:32:36.0 +0100
--- runtime/doc/cmdline.txt 2008-12-17 01:42:26.0 +0100
***
*** 1020,1026
The command-line window cannot be used:
- when there already is a command-line window (no nesting)
! - for entering a encryption key or when using inputsecret()
- when Vim was not compiled with the +vertsplit feature
Some options are set when the command-line window is opened:
--- 1020,1026
The command-line window cannot be used:
- when there already is a command-line window (no nesting)
! - for entering an encryption key or when using inputsecret()
- when Vim was not compiled with the +vertsplit feature
Some options are set when the command-line window is opened:
*** /home/pel/sb/vim-runtime/doc/develop.txt 2008-08-11 20:47:18.0 +0200
--- runtime/doc/develop.txt 2008-12-08 21:17:44.0 +0100
***
*** 64,70
hard time finding and remembering them. Keep in mind that more commands and
options will be added later.
- A feature that people do not know about is a useless feature. Don't add
! obscure features, or at least add hints in documentation that they exists.
- Minimize using CTRL and other modifiers, they are more difficult to type.
- There are many first-time and inexperienced Vim users. Make it easy for
them to start using Vim and learn more over time.
--- 64,70
hard time finding and remembering them. Keep in mind that more commands and
options will be added later.
- A feature that people do not know about is a useless feature. Don't add
! obscure features, or at least add hints in documentation that they exist.
- Minimize using CTRL and other modifiers, they are more difficult to type.
- There are many first-time and inexperienced Vim users. Make it easy for
them to start using Vim and learn more over time.
***
*** 323,329
OK: var = a * 5;
In general: Use empty lines to group lines of code together. Put a comment
! just above the group of lines. This makes it more easy to quickly see what is
being done.
OK: /* Prepare for building the table. */
--- 323,329
OK: var = a * 5;
In general: Use empty lines to group lines of code together. Put a comment
! just above the group of lines. This makes it easier to quickly see what is
being done.
OK: /* Prepare for building the table. */
*** /home/pel/sb/vim-runtime/doc/eval.txt 2008-12-08 22:08:46.0 +0100
--- runtime/doc/eval.txt 2008-12-17 01:32:45.0 +0100
***
*** 3586,3592
above the first item a negative number is returned. When
clicking on the prompt one more than the length of {textlist}
is returned.
! Make sure {textlist} has less then 'lines' entries, otherwise
it won't work. It's a good idea to put the entry number at
the start of the string. And put a prompt in the first item.
Example:
--- 3586,3592
above the first item a negative number is returned. When
clicking on the prompt one more than the length of {textlist}
is returned.
! Make sure {textlist} has less than 'lines' entries, otherwise
it won't work. It's a good idea to put the entry number at
the start of the string. And put a prompt in the first item.
Example:
*** /home/pel/sb/vim-runtime/doc/os_390.txt 2008-08-11 20:47:37.0 +0200
--- runtime/doc/os_390.txt 2008-12-07 13:38:33.0 +0100
***
*** 282,288
5.6-390c:
I grepped through the source and examined every spot with a character
! involved in a operation (+-). I hope I now found all EBCDIC/ASCII
stuff, but
Fixed:
--- 282,288
5.6-390c:
I grepped through the source and examined every spot with a character
! involved in an operation (+-). I hope I now found all EBCDIC/ASCII
stuff, but
Fixed:
***
*** 311,317
- added special compiler and linker options if building with X11
- configure:
- after created via autoconf hand-edited it to make the test for
! ICEConnectionNumber work. This is a autoconf problem. OS/390 UNIX
needs -lX11 for this.
- Makefile
- Don't include the lib directories ('-L...') into the variable
--- 311,317
- added special compiler and linker options if building with X11
- configure:
- after created via autoconf hand-edited it to make the test for
! ICEConnectionNumber work. This is an autoconf problem. OS/390 UNIX
needs -lX11 for this.
- Makefile
- Don't
Re: Bug: E685, SEGV - a:000 garbage collected too early?
Matt Wozniski wrote:
function! ReturnArgs(...)
return a:000
endfunction
Seems to work fine?
echo ReturnArgs(1, 2, 3)
SEGV
echo string(ReturnArgs(1, 2, 3))
function! MakeArgsDict(...)
return { 'args': a:000 }
endfunction
E685 Internal Error
echo MakeArgsDict(1, 2, 3)
SEGV
echo string(MakeArgsDict(1, 2, 3))
~Matt
I can reproduce that with vim-7.2.69 on Linux.
Following patch seems to fix it, but I'm not sure whether
that's the correct fix or whether it's only a workaround:
$ cvs diff -c eval.c
Index: eval.c
===
RCS file: /cvsroot/vim/vim7/src/eval.c,v
retrieving revision 1.277
diff -c -r1.277 eval.c
*** eval.c 9 Dec 2008 09:57:49 - 1.277
--- eval.c 15 Dec 2008 19:39:37 -
***
*** 2,21117
char_u*save_sourcing_name;
linenr_T save_sourcing_lnum;
scid_Tsave_current_SID;
! funccall_Tfc;
int save_did_emsg;
static intdepth = 0;
dictitem_T*v;
--- 2,21117
char_u*save_sourcing_name;
linenr_T save_sourcing_lnum;
scid_Tsave_current_SID;
! static funccall_T fc;
int save_did_emsg;
static intdepth = 0;
dictitem_T*v;
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Vim complexity bug with joining lots of lines
Lee Naish wrote: The J command seems to have a complexity bug when given a large numeric argument, eg 10J ... ie, doubling the number of lines increased the runtime by a factor of 4 exactly - seems like there is a O(N^2) component to the algorithm. The = command also has O(n^2) complexity: Here are some timing using the following test case... $ for lines in 1000 2000 4000 8000 16000 32000 ; do echo === $lines yes | head -$lines yes-$lines.txt /usr/bin/time vim -u NONE -c 'normal =G' -c 'q!' yes-$lines.txt done #lines timing 1000 0.25user 0.01system 0:00.33elapsed 79%CPU 2000 0.78user 0.04system 0:00.86elapsed 96%CPU 4000 2.91user 0.06system 0:03.30elapsed 90%CPU 8000 11.26user 0.24system 0:12.33elapsed 93%CPU 16000 46.47user 0.86system 0:47.83elapsed 98%CPU 32000 182.99user 3.76system 3:07.84elapsed 99%CPU I.e. indenting 2*n lines is ~ 4x longer than indenting n lines. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Vim complexity bug with joining lots of lines
Bram Moolenaar wrote:
Lee Naish wrote:
The J command seems to have a complexity bug when given a large numeric
argument, eg 10J
eg:
% yes | head -10 vimtest
% time vim vimtest
Joined all lines using 9J
17.2u 0.0s 2:29.74 11.5% 0+0k 0+10232io 0pf+0w
% yes | head -20 vimtest
% time vim vimtest
Joined all lines using 19J
68.8u 0.4s 1:41.22 68.3% 0+0k 0+39648io 0pf+0w
ie, doubling the number of lines increased the runtime by a factor of 4
exactly - seems like there is a O(N^2) component to the algorithm.
This is a known problem. It works like doing J 10 times. So near
the end you are appending a short line to a very long line, copying
everything into newly allocated memory.
Allocating all the memory at once is a bit complicated. Perhaps an easy
solution would be to join two lines at a time.
I see at least 2 things that explain the O(n^2) complexity when
joining many lines:
1/ STRLEN() is called every time on the current line. As the current
line grows, STRLEN(..) becomes slow and has O(n^2) complexity
when joining n lines.
2/ For each join, a new line gets allocated, and the current line + next
line get copied into the new one. As the current line size increases,
copying has complexity O(n^2).
I have a patch which fixes at least 1/ (but not 2/). The speeds up
is quite noticeable, but complexity is still O(n^2) since I only
addressed 1 of the 2 issues.
It works by letting the caller of do_join(...) specify the length of the
current line (if it knows it), so that do_join(...) then does not need
to call STRLEN(...) for every line.
Here is the time it takes to join 100.000 lines on my laptop before
and after patch.
before patch: 28.228s
after patch: 21.518s
I measured several times with this test case:
$ yes | head -10 yes.tmp
$ time ./vim -u NONE -c '%join|q!' yes.tmp
To speed up much more (and to get rid of O(n^2) complexity),
we'd need to address the remaining point 2/. I don't understand
yet enough how memory is managed for lines, but I'd like to try
to look at it. Maybe we could realloc(...) the current line instead
of doing a new alloc + copy each time. realloc(...) will often just
increase the size of the block without actually copying anything
(when there is free memory after the block). Or maybe we need
to join all n lines at once rather than joining pairs of lines. Not
sure yet what's best/easiest.
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: ops.c
===
RCS file: /cvsroot/vim/vim7/src/ops.c,v
retrieving revision 1.68
diff -c -r1.68 ops.c
*** ops.c 3 Dec 2008 12:38:36 - 1.68
--- ops.c 10 Dec 2008 21:41:13 -
***
*** 1919,1925
);
curwin-w_cursor = curpos; /* restore curwin-w_cursor */
! (void)do_join(FALSE);
}
}
--- 1919,1925
);
curwin-w_cursor = curpos; /* restore curwin-w_cursor */
! (void)do_join(FALSE, NULL);
}
}
***
*** 4111,4116
--- 4111,4117
int insert_space;
{
colnr_T col = MAXCOL;
+ int len = -1; /* current line length not known yet */
if (u_save((linenr_T)(curwin-w_cursor.lnum - 1),
(linenr_T)(curwin-w_cursor.lnum + count)) == FAIL)
***
*** 4119,4125
while (--count 0)
{
line_breakcheck();
! if (got_int || do_join(insert_space) == FAIL)
{
beep_flush();
break;
--- 4120,4126
while (--count 0)
{
line_breakcheck();
! if (got_int || do_join(insert_space, len) == FAIL)
{
beep_flush();
break;
***
*** 4149,4156
* return FAIL for failure, OK otherwise
*/
int
! do_join(insert_space)
int insert_space;
{
char_u *curr;
char_u *next, *next_start;
--- 4150,4158
* return FAIL for failure, OK otherwise
*/
int
! do_join(insert_space, len)
int insert_space;
+ int *len;
{
char_u *curr;
char_u *next, *next_start;
***
*** 4165,4171
return FAIL; /* can't join on last line */
curr = ml_get_curline();
! currsize = (int)STRLEN(curr);
endcurr1 = endcurr2 = NUL;
if (insert_space currsize 0)
{
--- 4167,4176
return FAIL; /* can't join on last line */
curr = ml_get_curline();
!
! /* Calculate line size only if not provided by caller to avoid
! * O(n^2) complexity when joining many lines */
! currsize = (len == NULL || *len 0) ? (int)STRLEN(curr) : *len;
endcurr1 = endcurr2 = NUL;
if (insert_space currsize 0)
{
***
*** 4218,4223
--- 4223,4230
}
}
nextsize = (int)STRLEN(next);
+
Re: Vim complexity bug with joining lots of lines
Lee Naish wrote: The J command seems to have a complexity bug when given a large numeric argument, eg 10J eg: % yes | head -10 vimtest % time vim vimtest Joined all lines using 9J 17.2u 0.0s 2:29.74 11.5% 0+0k 0+10232io 0pf+0w % yes | head -20 vimtest % time vim vimtest Joined all lines using 19J 68.8u 0.4s 1:41.22 68.3% 0+0k 0+39648io 0pf+0w ie, doubling the number of lines increased the runtime by a factor of 4 exactly - seems like there is a O(N^2) component to the algorithm. Confirmed with vim-7.2.65 on Linux. Using the following script... $ for s in 1 2 4 6 8 10 12 14 16 do yes | head -$s /tmp/yes.tmp echo === joining $s lines... time vim -u NONE -c '%join|q!' /tmp/yes.tmp done ... I get the following timing for joining lines: #lines real time (sec) 1 0.417 2 1.355 4 4.686 6 10.391 8 18.110 10 28.377 12 40.394 14 54.943 16 71.499 Clearly timing does not increase linearly with the number of lines as one would expect. I've checked out a copy under SVN, found the O(N^2) code and hacked up a possible fix, but haven't been able to test it because I have some shared library problem - I can create vim7/src/vim but when I run it (even the original version) I get: ld.so.1: vim: fatal: libintl.so.3: open failed: No such file or directory Killed We have /local/solaris86/lib/libintl.so.3 but in /usr/lib there is no .3 version. We used to have good sysadmin support, but no longer... Do you suggest I a) Keep stuffing around here on my own (I could copy everything to my laptop running Ubuntu I guess). Any suggestions welcome... b) Post the (untested) code here (there isn't much and it needs some cleaning up and checking by someone more familiar with Vim anyway). lee I let you decide :-) Building vim on Ubuntu is simple: # Install the required packages to be able to build vim $ sudo apt-get build-dep vim-full # download the sources $ cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/vim checkout vim7 # then build $ cd vim7 $ ./configure --with-features=huge $ make $ sudo make install -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] fixed 2 compilation warnings in if_sniff.c
2008/12/6 Bram Moolenaar wrote: Dominique Pelle wrote: [...] I've never used SNiFF+, but I'm curious about it. I searched for it on Google. It seems that this product was taken over by Windriver, but there is nothing about SNiFF+ on Windriver's website. - Is SNiFF+ dead? - Is there any free version available? I would consider it dead. Some people might still be using it though. Also, I would also expect to get an error message when doing :sniff connect in gvim, since I don't have SNiFF+ installed. But gvim does not detect that the connection fails, and hangs after a few seconds (100% CPU usage and I need to kill -9 vim). Do you know where it hangs? Doing this with gvim-7.2.65 (huge, GTK2-GNOME GUI, Linux x86) is enough to cause 100% CPU usage: vim -f -g -u NONE -U NONE -c 'sniff connect' Attaching to the runaway process with gdb, I see the following stack traces when CPU usage is 100% (I tried several times): (gdb) bt #0 0xb80d7430 in __kernel_vsyscall () #1 0xb6f72f77 in poll () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7953c32 in ?? () from /usr/lib/libglib-2.0.so.0 #3 0xb7954060 in g_main_context_pending () from /usr/lib/libglib-2.0.so.0 #4 0xb7e2d271 in gtk_events_pending () from /usr/lib/libgtk-x11-2.0.so.0 #5 0x08237072 in gui_mch_update () at gui_gtk_x11.c:6383 #6 0x0810bfed in vgetorpeek (advance=1) at getchar.c:1984 #7 0x0810dbed in vgetc () at getchar.c:1571 #8 0x0810e05b in safe_vgetc () at getchar.c:1757 #9 0x08178310 in normal_cmd (oap=0xbfdd88dc, toplevel=1) at normal.c:653 #10 0x08123357 in main_loop (cmdwin=0, noexmode=0) at main.c:1180 #11 0x0812aa13 in main (argc=Cannot access memory at address 0x7 (gdb) bt #0 vgetc () at getchar.c:1571 #1 0x0810e05b in safe_vgetc () at getchar.c:1757 #2 0x08178310 in normal_cmd (oap=0xbfdd88dc, toplevel=1) at normal.c:653 #3 0x08123357 in main_loop (cmdwin=0, noexmode=0) at main.c:1180 #4 0x0812aa13 in main (argc=Cannot access memory at address 0x4c ) at main.c:939 Using vim-7.2.65 (huge) in a terminal, instead of gvim, i.e... vim -u NONE -c 'sniff connect' Vim then does not hog the CPU, but I see this on the terminal... ff9bsniff9bsniff9bsniff ,.. then whenever I press Esc more messages niff9bsniff9bsniff appear on the screen. And the only way to exit vim is the kill it. I will try to find time to investigate it later. But considering that it may only happen when using sniff while sniff is not installed, and that sniff is dead, it's a low priority bug. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
[patch] buffer name [Scratch] not translated with gettext.
Buffer name [Scratch] is currently not translated with gettext.
Attached patch fixes it.
[Scratch] is the name of the buffer that you can see by doing
this for example:
$ vim -u NONE -c 'set bt=nofile laststatus=2'
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: buffer.c
===
RCS file: /cvsroot/vim/vim7/src/buffer.c,v
retrieving revision 1.86
diff -c -r1.86 buffer.c
*** buffer.c 15 Nov 2008 15:05:47 - 1.86
--- buffer.c 2 Dec 2008 18:17:53 -
***
*** 5118,5124
{
if (buf-b_sfname != NULL)
return (char *)buf-b_sfname;
! return [Scratch];
}
#endif
if (buf-b_fname == NULL)
--- 5118,5124
{
if (buf-b_sfname != NULL)
return (char *)buf-b_sfname;
! return _([Scratch]);
}
#endif
if (buf-b_fname == NULL)
Regression introduced in patch 7.2.50: fwrite() failures incorrectly checked
Tests 58 and 59 fail when doing 'make test' with latest Vim-7.2.55 (huge version, tested on Linux). I tried older versions: - Vim-7.2.49 All tests pass - Vim-7.2.50 Tests 58 59 fail. Patch 7.2.50 introduces the regression: --- 8 --- cut here --- 8 --- cut here --- 8 --- Patch 7.2.050 Problem:Warnings for not checking return value of fwrite(). (Chip Campbell) Solution: Use the return value. Files: src/spell.c --- 8 --- cut here --- 8 --- cut here --- 8 --- Here is the mismatch in the test outcome: --- 8 --- cut here --- 8 --- cut here --- 8 --- $ diff -c test58.ok test58.failed *** test58.ok 2006-04-05 22:35:46.0 +0200 --- test58.failed 2008-11-29 08:07:28.0 +0100 *** *** 40,48 gebletegek kepereneven everles gesvets etele ! kbltykk ! kprnfn ! *fls kswts tl elekwent elequint elekwint --- 40,48 gebletegek kepereneven everles gesvets etele ! gebletegek ! kepereneven ! everles gesvets etele elekwent elequint elekwint $ diff -c test59.ok test59.failed *** test59.ok 2006-04-05 22:39:13.0 +0200 --- test59.failed 2008-11-29 08:07:29.0 +0100 *** *** 40,48 gebletegek kepereneven everles gesvets etele ! kbltykk ! kprnfn ! *fls kswts tl elekwent elequint elekwint --- 40,48 gebletegek kepereneven everles gesvets etele ! gebletegek ! kepereneven ! everles gesvets etele elekwent elequint --- 8 --- cut here --- 8 --- cut here --- 8 --- Looking at the official patch 7.2.50, I see that I/O errors are checked like this for example: int fwv = 1; /* collect return value of fwrite() to avoid warnings from picky compiler */ ...snip... fwv = fwrite(spin-si_sofofr, l, (size_t)1, fd); /* sofofrom */ ...snip... fwv = fwrite(spin-si_sofoto, l, (size_t)1, fd); /* sofoto */ ...snip... if (fwv != 1) retval = FAIL; if (retval == FAIL) EMSG(_(e_write)); This is an incorrect way of checking errors: fwrite() returns the number of items successfully written. So doing bit arithmetic on the return value can't possibly be correct. Correct would be to compare the return value of fwrite() with the number of items that is requested to be written: int error = 0; ... if (fwrite(spin-si_sofofr, l, (size_t)1, fd) != 1) /* sofofrom */ error = 1; -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Regression introduced in patch 7.2.50: fwrite() failures incorrectly checked
2008/11/29 Bram Moolenaar wrote: Dominique Pelle wrote: Tests 58 and 59 fail when doing 'make test' with latest Vim-7.2.55 (huge version, tested on Linux). I tried older versions: - Vim-7.2.49 All tests pass - Vim-7.2.50 Tests 58 59 fail. Patch 7.2.50 introduces the regression: [...snip...] All the fwrite() calls have a number of elements argument of 1. When fwrite succeeds it returns 1, when it fails it returns 0. So and-ing all the 1 values together gives 1. If there is one zero the and-ed value is zero. Perhaps frwrite() actually returns something different for you? Or there is a problem with the conversion of size_t to int? You can change the type of fwv to size_t and see if that makes a difference. Yes, you're right indeed, all the fwrite() here write only 1 element, so the patch looks OK at first sight. Yet, the patch does break tests 58 and 59. And reverting it definitely makes the tests pass. I added some printf(...) to debug, and I saw that at least in this line in spell.c... 8115 fwv = fwrite(p, l, (size_t)1, fd); ... fwrite(...) returns 0 for me in some cases. It happens because second argument l is 0, meaning that it's trying to write 1 element of length 0, which is either useless or is a bug (I don't understand the code well enough to say). In any case, it's a bit of an odd case. Man page of fwrite(...) does not say what fwrite() should return when writing 1 element of size 0. I suspect it's not portable (like malloc(0)), and for me it returns 0 (interpreted as an error) and for you it returns 1. The attached patch makes the tests 58 and 59 succeed, by doing the frwrite(...) only if l 0. But I'm not sure whether it should be considered as a workaround or whether it's the actual fix. Also, my patch adds only one if (l 0) which is enough to make all test pass, but there are a few other places where the same may be necessary. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- Index: spell.c === RCS file: /cvsroot/vim/vim7/src/spell.c,v retrieving revision 1.117 diff -c -r1.117 spell.c *** spell.c 28 Nov 2008 20:27:23 - 1.117 --- spell.c 29 Nov 2008 15:29:55 - *** *** 8112,8118 p = rr == 1 ? ftp-ft_from : ftp-ft_to; l = (int)STRLEN(p); putc(l, fd); ! fwv = fwrite(p, l, (size_t)1, fd); } } --- 8112,8119 p = rr == 1 ? ftp-ft_from : ftp-ft_to; l = (int)STRLEN(p); putc(l, fd); ! if (l 0) ! fwv = fwrite(p, l, (size_t)1, fd); } }
[patch] fixed compilation warnings in getchar.c
Hi
The attached patch fixes a compilation warning in vim-7.2.49:
getchar.c: In function 'makemap':
getchar.c:4705: warning: format not a string literal and no format arguments
getchar.c: In function 'put_escstr':
getchar.c:4804: warning: format not a string literal and no format arguments
This warning is not related to the flag -D_FORTIFY_SOURCE=1 (unlike
other compilation warnings discussed recently).
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: getchar.c
===
RCS file: /cvsroot/vim/vim7/src/getchar.c,v
retrieving revision 1.52
diff -c -r1.52 getchar.c
*** getchar.c 22 Jul 2008 16:58:23 - 1.52
--- getchar.c 21 Nov 2008 18:09:22 -
***
*** 4702,4708
return FAIL;
if (mp-m_noremap != REMAP_YES fprintf(fd, nore) 0)
return FAIL;
! if (fprintf(fd, cmd) 0)
return FAIL;
if (buf != NULL fputs( buffer, fd) 0)
return FAIL;
--- 4702,4708
return FAIL;
if (mp-m_noremap != REMAP_YES fprintf(fd, nore) 0)
return FAIL;
! if (fputs(cmd, fd) 0)
return FAIL;
if (buf != NULL fputs( buffer, fd) 0)
return FAIL;
***
*** 4801,4807
}
if (IS_SPECIAL(c) || modifiers) /* special key */
{
! if (fprintf(fd, (char *)get_special_key_name(c, modifiers)) 0)
return FAIL;
continue;
}
--- 4801,4807
}
if (IS_SPECIAL(c) || modifiers) /* special key */
{
! if (fputs((char *)get_special_key_name(c, modifiers), fd) 0)
return FAIL;
continue;
}
Re: Patch 7.2.048
2008/11/20 Charles Campbell [EMAIL PROTECTED]: Bram Moolenaar wrote: Patch 7.2.041-7.2.048 (not sure which one) Hello! I'm starting to get some warnings that I didn't used to get... gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -g -O2 -D_FORTIFY_SOURCE=1 -I/usr/include64 -D_REENTRANT -D_GNU_SOURCE -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -I/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE -I/usr/include/python2.4 -pthread-o objects/spell.o spell.c spell.c: In function 'write_vim_spell': spell.c:7958: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result spell.c:7969: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result spell.c:8019: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result spell.c:8030: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result spell.c:8116: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result spell.c:8134: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result spell.c:8138: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result spell.c:8163: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result spell.c:8179: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result spell.c:8235: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result spell.c:8238: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result spell.c:8262: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result spell.c: In function 'write_spell_prefcond': spell.c:9909: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result I tried preceding the calls to fwrite() with (void) casts, but that didn't remove the warnings. Putting int nfw; in the write_vim_spell() and write_spell_prefcond() functions and doing nfw= fwrite(...) did remove the warnings. Regards, Chip Campbell Ah, yes... This is actually related to adding -D_FORTIFY_SOURCE=1 in patch 7.2.44. If we put -D_FORTIFY_SOURCE=0, that gets rid of warnings, while still fixing the crash (which happened on Ubuntu because gcc on Ubuntu is modified to use -D_FORTIFY_SOURCE=2 by default and Vim does things that cause a crash with -D_FORTIFY_SOURCE=2). But by setting -D_FORTIFY_SOURCE=0 instead of 1, we miss some possibly useful error detections at compilation time or runtime. Ignoring return value of fwrite() is dangerous in my opinion. I/Os can fail. And if they can fail, they will fail. But if we want to shut the warning, I would prefer -D_FORTIFY_SOURCE=0 than storing the return value of fwrite() in a variable which gets ignored. So that: * code does not get cluttered with warning workarounds; * and developers can still override to use -D_FORTIFY_SOURCE=1 should they want to see those warnings (since those warnings are useful in my opinion). -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: crash when pasting clipboard from mouse
2008/11/18 Bram Moolenaar [EMAIL PROTECTED]: Dominique Pelle wrote: I observe a bug with the latest Vim-7.2.42 (huge) on Linux x86. It's not recently introduced since I can reproduce at least with Vim-7.1.314 which comes with Ubuntu-8.10. It only happens in a terminal (gvim does not seem affected). Steps to reproduce: 1/ start Vim in a terminal (xterm or gnome-terminal) with: vim -u NONE 2/ enter INSERT mode with:i 3/ select (into clipboard) a few lines of text with the mouse from another terminal 4/ paste those selected lines with the mouse into Vim (middle click) 5/ visual select all text with and reformat with: Esc1GVGgq 6/ delete everything with::%d 7/ enter insert mode again with:i 8/ paste same again text still in clipboard with the mouse (middle click) Observe that after pasting test in step 8/, Vim either crashes with: Vim: Caught deadly signal ABRT Vim: preserving files... .. or sometimes Vim just misbehaves (hangs or not longer accepts all keystrokes for example). Sometimes the text is not inserted at all when pasting the second time at step 8/. Running the same test with Valgrind, I see errors 100% of the times but so far I did not find how to fix them: ==11904== Conditional jump or move depends on uninitialised value(s) ==11904==at 0x47D8548: (within /usr/lib/libXt.so.6.0.0) ==11904==by 0x47D891A: (within /usr/lib/libXt.so.6.0.0) ==11904==by 0x47C23E4: XtDispatchEventToWidget (in /usr/lib/libXt.so.6.0.0) ==11904==by 0x47C2D87: (within /usr/lib/libXt.so.6.0.0) ==11904==by 0x47C1CF6: XtDispatchEvent (in /usr/lib/libXt.so.6.0.0) ==11904==by 0x81415D6: xterm_update (os_unix.c:6513) ==11904==by 0x813F8A1: RealWaitForChar (os_unix.c:4969) ==11904==by 0x813F50E: WaitForChar (os_unix.c:4640) ==11904==by 0x813B53B: mch_inchar (os_unix.c:366) ==11904==by 0x81A4706: ui_inchar (ui.c:193) ==11904==by 0x80D274A: inchar (getchar.c:2959) ==11904==by 0x80D237D: vgetorpeek (getchar.c:2735) ==11904==by 0x80D0919: vgetc (getchar.c:1552) ==11904==by 0x80D0E94: safe_vgetc (getchar.c:1757) ==11904==by 0x806368A: edit (edit.c:711) ==11904==by 0x81233CC: invoke_edit (normal.c:8885) ==11904==by 0x8123372: nv_edit (normal.c:8858) ==11904==by 0x8116C54: normal_cmd (normal.c:1184) ==11904==by 0x80DE8DA: main_loop (main.c:1180) ==11904==by 0x80DE427: main (main.c:939) (more errors after that) Does anybody else see that bug too? Perhaps you can trigger it earlier, when it's caused, by setting the 'writedelay' option to some value. Setting writedelay does not change anything. It just makes refreshing screen slower, but I see see the same problem. But I can simplify the way to reproduce it. It happens whenever I do a visual selection in between: - selecting text in clipboard with the mouse - and pasting with middle click. Example: 1/ start vim with valgrind: valgrind 2 valgrind.log vim -u NONE 2/ select some text with mouse outside vim (one line is enough) 3/ enter INSERT mode in vim and type some text: iThis is a testEsc 4/ visual select line typed in 3/ with: V 5/ click middle mouse to paste text selected in 2/ Observe errors in valgrind.log right after middle mouse click in step 5/ I see this with Vim-7.2.42 (normal or huge, GTK2) on Ubuntu-8.10 as well as Vim-7.1.314 (GTK2-GNOME) on Ubuntu-8.10 I tried on 2 other machines: - vim-7.2.42 (huge, GTK2 GUI) on openSUSE 10.3 : no bug observed, valgrind does not complain either (I tried several times) - vim-7.2.42 (huge, GTK2 GUI) on Ubuntu-7.04 : no apparent bug but valgrind reports errors as soon as I paste text in step 5/ ==12698== Syscall param write(buf) points to uninitialised byte(s) ==12698==at 0x40007F2: (within /lib/ld-2.5.so) ==12698==by 0x487A64E: _X11TransWrite (in /usr/lib/libX11.so.6.2.0) ==12698==by 0x4872526: (within /usr/lib/libX11.so.6.2.0) ==12698==by 0x48725FA: _XReply (in /usr/lib/libX11.so.6.2.0) ==12698==by 0x486C5C9: XSync (in /usr/lib/libX11.so.6.2.0) ==12698==by 0x465E211: (within /usr/lib/libXt.so.6.0.0) ==12698==by 0x46618A4: (within /usr/lib/libXt.so.6.0.0) ==12698==by 0x464B394: XtDispatchEventToWidget (in /usr/lib/libXt.so.6.0.0) ==12698==by 0x464BD37: (within /usr/lib/libXt.so.6.0.0) ==12698==by 0x464ACA6: XtDispatchEvent (in /usr/lib/libXt.so.6.0.0) ==12698==by 0x8151C38: xterm_update (os_unix.c:6513) ==12698==by 0x8150103: RealWaitForChar (os_unix.c:4969) ==12698==by 0x814FE7F: WaitForChar (os_unix.c:4642) ==12698==by 0x814BDFF: mch_inchar (os_unix.c:366) ==12698==by 0x81B85AF: ui_inchar (ui.c:193) ==12698==by 0x80D7DBD: inchar (getchar.c:2959) ==12698==by 0x80D79D1: vgetorpeek (getchar.c:2735) ==12698==by 0x80D5E73: vgetc (getchar.c:1552) ==12698==by 0x80D63EE: safe_vgetc (getchar.c:1757) ==12698==by 0x8064184: edit (edit.c:711) ==12698==by 0x81328AB
Re: automatic setting of encoding failure: bug in mbyte.c?
2008/11/18 Danek Duvall [EMAIL PROTECTED]: In enc_locale(), there's a for loop that looks like this: for (i = 0; s[i] != NUL s + i buf + sizeof(buf) - 1; ++i) but I can't figure out what the purpose is for that second test. If I'm reading it correctly, it's testing that the address of the character we're copying from the source is less than the address of the final character in the destination buffer, but that doesn't make much sense to me. I could understand if we were checking the source against the beginning of the destination -- a check for overlap, but it's not doing that. I ran into this because of a bug filed against the x86 build of vim for Solaris, where 'encoding' always gets set to 'latin1', regardless of your locale settings (unless, of course, you've set 'encoding' explicitly). Oddly, it works just fine on SPARC, but it appears that it's just due to the way the compiler's laid out memory on the two platforms. The problem is fixed if I simply remove the test. Is there any reason not to do that in the base? Thanks, Danek s and buf can be unrelated pointers so the comparison looks wrong indeed. I think the line... for (i = 0; s[i] != NUL s + i buf + sizeof(buf) - 1; ++i) ... should be... for (i = 0; s[i] != NUL i sizeof(buf) - 1; ++i) The test (i sizeof(buf) - 1) prevents overflow in buf[...], I would not remove it. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: crash when pasting clipboard from mouse
2008/11/19 Tony Mechelynck [EMAIL PROTECTED]: On 18/11/08 22:29, Dominique Pelle wrote: [...] But I can simplify the way to reproduce it. It happens whenever I do a visual selection in between: - selecting text in clipboard with the mouse - and pasting with middle click. Example: 1/ start vim with valgrind: valgrind 2 valgrind.log vim -u NONE 2/ select some text with mouse outside vim (one line is enough) 3/ enter INSERT mode in vim and type some text: iThis is a testEsc 4/ visual select line typed in 3/ with: V 5/ click middle mouse to paste text selected in 2/ Observe errors in valgrind.log right after middle mouse click in step 5/ I see this with Vim-7.2.42 (normal or huge, GTK2) on Ubuntu-8.10 as well as Vim-7.1.314 (GTK2-GNOME) on Ubuntu-8.10 I tried on 2 other machines: - vim-7.2.42 (huge, GTK2 GUI) on openSUSE 10.3 : no bug observed, valgrind does not complain either (I tried several times) - vim-7.2.42 (huge, GTK2 GUI) on Ubuntu-7.04 : no apparent bug but valgrind reports errors as soon as I paste text in step 5/ [...] What do you have 'clipboard' set to? (The default is autoselect, which will make Vim try to get ownership of the X11 selection at step 4). Best regards, Tony. 'clipboard was set to default, since I run vim -u NONE, which is... clipboard=autoselect,exclude:cons\|linux But if I do... set clipboard= ... then bug no longer happens. But more interestingly, I just found that it only happen with locale being set to eo_XX.UTF-8. It always works fine at least with locale being C or en_US.UTF-8 or fr_FR.UTF-8 for example. But as soon as I set locale to eo_XX.UTF-8, then I see the problem all the time. I tried several times to make sure it was really the case. Now I know why I'm the only one who could reproduce it. Maybe it's related to this http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/b759a75978bc890b The file /usr/share/X11/locale/locale.dir contains a comment which says # Esperato (eo) is not supported by the GNU C Library and neither the # EO nor XX territories exist in ISO 3166. # en_US.UTF-8/XLC_LOCALE: eo_EO.UTF-8 # en_US.UTF-8/XLC_LOCALE: eo_XX.UTF-8 Not sure why Esperanto (*Esperato* is a typo in the file by the way) is not supported by GNU C lib. I edited my file /usr/share/X11/locale/locale.dir as follows, just uncommented the lines about Esperanto, and now everything works fine in vim with eo_XX.UTF-8 locale [EMAIL PROTECTED]:/usr/share/X11/locale$ diff -c locale.dir.orig locale.dir *** locale.dir.orig 2008-11-19 08:03:48.0 +0100 --- locale.dir 2008-11-19 08:00:58.0 +0100 *** *** 353,360 en_US.UTF-8/XLC_LOCALEen_ZW.UTF-8 # Esperato (eo) is not supported by the GNU C Library and neither the # EO nor XX territories exist in ISO 3166. ! #en_US.UTF-8/XLC_LOCALE: eo_EO.UTF-8 ! #en_US.UTF-8/XLC_LOCALE: eo_XX.UTF-8 en_US.UTF-8/XLC_LOCALEes_AR.UTF-8 en_US.UTF-8/XLC_LOCALEes_BO.UTF-8 en_US.UTF-8/XLC_LOCALEes_CL.UTF-8 --- 353,360 en_US.UTF-8/XLC_LOCALEen_ZW.UTF-8 # Esperato (eo) is not supported by the GNU C Library and neither the # EO nor XX territories exist in ISO 3166. ! en_US.UTF-8/XLC_LOCALE: eo_EO.UTF-8 ! en_US.UTF-8/XLC_LOCALE: eo_XX.UTF-8 en_US.UTF-8/XLC_LOCALEes_AR.UTF-8 en_US.UTF-8/XLC_LOCALEes_BO.UTF-8 en_US.UTF-8/XLC_LOCALEes_CL.UTF-8 *** *** 846,853 en_US.UTF-8/XLC_LOCALE: en_ZW.UTF-8 # Esperato (eo) is not supported by the GNU C Library and neither the # EO nor XX territories exist in ISO 3166. ! #en_US.UTF-8/XLC_LOCALE: eo_EO.UTF-8 ! #en_US.UTF-8/XLC_LOCALE: eo_XX.UTF-8 en_US.UTF-8/XLC_LOCALE: es_AR.UTF-8 en_US.UTF-8/XLC_LOCALE: es_BO.UTF-8 en_US.UTF-8/XLC_LOCALE: es_CL.UTF-8 --- 846,853 en_US.UTF-8/XLC_LOCALE: en_ZW.UTF-8 # Esperato (eo) is not supported by the GNU C Library and neither the # EO nor XX territories exist in ISO 3166. ! en_US.UTF-8/XLC_LOCALE: eo_EO.UTF-8 ! en_US.UTF-8/XLC_LOCALE: eo_XX.UTF-8 en_US.UTF-8/XLC_LOCALE: es_AR.UTF-8 en_US.UTF-8/XLC_LOCALE: es_BO.UTF-8 en_US.UTF-8/XLC_LOCALE: es_CL.UTF-8 But why those lines were commented out in the first place is not clear? I'll report that as bug in Ubuntu or Debian. It's not vim's fault after all. In any case, issue is now solved for me. -- Dominique --~--~-~--~~~---~--~~ You received
Re: crash when pasting clipboard from mouse
2008/11/19 John Little [EMAIL PROTECTED]: Dominique When I follow this: 1/ start vim with valgrind: valgrind 2 valgrind.log vim -u NONE 2/ select some text with mouse outside vim (one line is enough) 3/ enter INSERT mode in vim and type some text: iThis is a testEsc 4/ visual select line typed in 3/ with: V 5/ click middle mouse to paste text selected in 2/ step 5 attempts to insert the text entered in step 3, but interprets most of it as commands in Visual mode, Th = back to the h, is = motion inner sentence, and so on, finally changing the selection with s to get a solitary t. So, following your first step 8, it was the text selected by step 5 that was being inserted at step 8. valgrind reports an error in getpwuid_r during vim's startup, but no further errors, other than various leaks reported on exit. Right, but bug also happens if I entered insert mode before pasting text. Anyway, I found the root cause and a fix. See my previous post: It only happened with locale being set to eo_XX.UTF-8, and a change in my /usr/share/X11/locale/locale.dir fixes it. I wonder what mouse support your build has; in principle not relevant unless one uses set mouse, but I was surprised that my vim build was silently affected by the presence of gpm. My :ver says +mouse +mouseshape +mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm -mouse_sysmouse +mouse_xterm For the record, It happened with: +arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent +clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +cryptv +cscope +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 +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 +postscript +printer +profile -python +quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title +toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset +xim -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
crash when pasting clipboard from mouse
Hi I observe a bug with the latest Vim-7.2.42 (huge) on Linux x86. It's not recently introduced since I can reproduce at least with Vim-7.1.314 which comes with Ubuntu-8.10. It only happens in a terminal (gvim does not seem affected). Steps to reproduce: 1/ start Vim in a terminal (xterm or gnome-terminal) with: vim -u NONE 2/ enter INSERT mode with:i 3/ select (into clipboard) a few lines of text with the mouse from another terminal 4/ paste those selected lines with the mouse into Vim (middle click) 5/ visual select all text with and reformat with: Esc1GVGgq 6/ delete everything with::%d 7/ enter insert mode again with:i 8/ paste same again text still in clipboard with the mouse (middle click) Observe that after pasting test in step 8/, Vim either crashes with: Vim: Caught deadly signal ABRT Vim: preserving files... .. or sometimes Vim just misbehaves (hangs or not longer accepts all keystrokes for example). Sometimes the text is not inserted at all when pasting the second time at step 8/. Running the same test with Valgrind, I see errors 100% of the times but so far I did not find how to fix them: ==11904== Conditional jump or move depends on uninitialised value(s) ==11904==at 0x47D8548: (within /usr/lib/libXt.so.6.0.0) ==11904==by 0x47D891A: (within /usr/lib/libXt.so.6.0.0) ==11904==by 0x47C23E4: XtDispatchEventToWidget (in /usr/lib/libXt.so.6.0.0) ==11904==by 0x47C2D87: (within /usr/lib/libXt.so.6.0.0) ==11904==by 0x47C1CF6: XtDispatchEvent (in /usr/lib/libXt.so.6.0.0) ==11904==by 0x81415D6: xterm_update (os_unix.c:6513) ==11904==by 0x813F8A1: RealWaitForChar (os_unix.c:4969) ==11904==by 0x813F50E: WaitForChar (os_unix.c:4640) ==11904==by 0x813B53B: mch_inchar (os_unix.c:366) ==11904==by 0x81A4706: ui_inchar (ui.c:193) ==11904==by 0x80D274A: inchar (getchar.c:2959) ==11904==by 0x80D237D: vgetorpeek (getchar.c:2735) ==11904==by 0x80D0919: vgetc (getchar.c:1552) ==11904==by 0x80D0E94: safe_vgetc (getchar.c:1757) ==11904==by 0x806368A: edit (edit.c:711) ==11904==by 0x81233CC: invoke_edit (normal.c:8885) ==11904==by 0x8123372: nv_edit (normal.c:8858) ==11904==by 0x8116C54: normal_cmd (normal.c:1184) ==11904==by 0x80DE8DA: main_loop (main.c:1180) ==11904==by 0x80DE427: main (main.c:939) (more errors after that) Does anybody else see that bug too? -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: crash when pasting clipboard from mouse
2008/11/17 Dominique Pelle [EMAIL PROTECTED]: Hi I observe a bug with the latest Vim-7.2.42 (huge) on Linux x86. It's not recently introduced since I can reproduce at least with Vim-7.1.314 which comes with Ubuntu-8.10. It only happens in a terminal (gvim does not seem affected). Steps to reproduce: 1/ start Vim in a terminal (xterm or gnome-terminal) with: vim -u NONE 2/ enter INSERT mode with:i 3/ select (into clipboard) a few lines of text with the mouse from another terminal 4/ paste those selected lines with the mouse into Vim (middle click) 5/ visual select all text with and reformat with: Esc1GVGgq 6/ delete everything with::%d 7/ enter insert mode again with:i 8/ paste same again text still in clipboard with the mouse (middle click) Observe that after pasting test in step 8/, Vim either crashes with: Vim: Caught deadly signal ABRT Vim: preserving files... .. or sometimes Vim just misbehaves (hangs or not longer accepts all keystrokes for example). Sometimes the text is not inserted at all when pasting the second time at step 8/. Running the same test with Valgrind, I see errors 100% of the times but so far I did not find how to fix them: ==11904== Conditional jump or move depends on uninitialised value(s) ==11904==at 0x47D8548: (within /usr/lib/libXt.so.6.0.0) ==11904==by 0x47D891A: (within /usr/lib/libXt.so.6.0.0) ==11904==by 0x47C23E4: XtDispatchEventToWidget (in /usr/lib/libXt.so.6.0.0) ==11904==by 0x47C2D87: (within /usr/lib/libXt.so.6.0.0) ==11904==by 0x47C1CF6: XtDispatchEvent (in /usr/lib/libXt.so.6.0.0) ==11904==by 0x81415D6: xterm_update (os_unix.c:6513) ==11904==by 0x813F8A1: RealWaitForChar (os_unix.c:4969) ==11904==by 0x813F50E: WaitForChar (os_unix.c:4640) ==11904==by 0x813B53B: mch_inchar (os_unix.c:366) ==11904==by 0x81A4706: ui_inchar (ui.c:193) ==11904==by 0x80D274A: inchar (getchar.c:2959) ==11904==by 0x80D237D: vgetorpeek (getchar.c:2735) ==11904==by 0x80D0919: vgetc (getchar.c:1552) ==11904==by 0x80D0E94: safe_vgetc (getchar.c:1757) ==11904==by 0x806368A: edit (edit.c:711) ==11904==by 0x81233CC: invoke_edit (normal.c:8885) ==11904==by 0x8123372: nv_edit (normal.c:8858) ==11904==by 0x8116C54: normal_cmd (normal.c:1184) ==11904==by 0x80DE8DA: main_loop (main.c:1180) ==11904==by 0x80DE427: main (main.c:939) (more errors after that) Does anybody else see that bug too? -- Dominique I see that: - vim 'small' is not affected by the bug - vim 'normal' has the bug. Tweaking feature.h manually, I got 2 version of them, which only differ by the FEAT_XCLIPBOARD feature: - the one with FEAT_XCLIPBOARD is affected by the bug - the one without FEAT_XCLIPBOARD is not affected by the bug. So +xterm_clipboard is the feature that is triggering the bug. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] fixed crash in vim-7.2.40 when compiling with gcc -O3
2008/11/16 Bram Moolenaar [EMAIL PROTECTED]: Apparently -fstack-protector is on by default. The inline-functions apparently does something to reveal the size of the destination to strcpy(). That's a bit unexpected though. Why not compile Vim with -fno-stack-protector ? Can you try with -O3 and that flag? It's not clear to me that this stack-protector function is what actually adds the check for the array size. Adding -fno-stack-protector does not help either (same warning + same crash). But reading through the man page of gcc, I stumbled upon this in the section about -O2: == NOTE: In Ubuntu 8.10 and later versions, -D_FORTIFY_SOURCE=2 is set by default, and is activated when -O is set to 2 or higher. This enables additional compile-time and run-time checks for several libc functions. To disable, specify either -U_FORTIFY_SOURCE or -D_FORTIFY_SOURCE=0. == So I tried adding compiling with -O3 -D_FORTIFY_SOURCE=0 and it makes it work! So far I don't observe anything wrong so fat with -O3 -D_FORTIFY_SOURCE=0. 'make test' succeeds in every tests. I'm not 100% sure whether adding -D_FORTIFY_SOURCE=0 silents a real bug, or whether it was reporting a spurious error (more likely from looking at vim code). But even if it silents a spurious bug in this case, adding -D_FORTIFY_SOURCE=0 may also silent other real bugs, which is a shame. I'll add the info to the gcc bug buzilla, but it was already and quickly marked as INVALID, so I don't expect much there. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] fixed crash in vim-7.2.40 when compiling with gcc -O3
2008/11/16 Dominique Pelle [EMAIL PROTECTED]:
2008/11/16 Bram Moolenaar [EMAIL PROTECTED]:
Apparently -fstack-protector is on by default. The inline-functions
apparently does something to reveal the size of the destination to
strcpy(). That's a bit unexpected though.
Why not compile Vim with -fno-stack-protector ? Can you try with -O3
and that flag? It's not clear to me that this stack-protector function
is what actually adds the check for the array size.
Adding -fno-stack-protector does not help either (same warning +
same crash). But reading through the man page of gcc, I stumbled
upon this in the section about -O2:
==
NOTE: In Ubuntu 8.10 and later versions, -D_FORTIFY_SOURCE=2
is set by default, and is activated when -O is set to 2 or higher.
This enables additional compile-time and run-time checks for several
libc functions. To disable, specify either -U_FORTIFY_SOURCE or
-D_FORTIFY_SOURCE=0.
==
So I tried adding compiling with -O3 -D_FORTIFY_SOURCE=0
and it makes it work!
So far I don't observe anything wrong so fat with
-O3 -D_FORTIFY_SOURCE=0. 'make test' succeeds
in every tests.
I'm not 100% sure whether adding -D_FORTIFY_SOURCE=0 silents
a real bug, or whether it was reporting a spurious error (more likely
from looking at vim code). But even if it silents a spurious bug in this
case, adding -D_FORTIFY_SOURCE=0 may also silent other real
bugs, which is a shame. I'll add the info to the gcc bug buzilla, but
it was already and quickly marked as INVALID, so I don't expect
much there.
-- Dominique
I should add that building with -O3 -D_FORTIFY_SOURCE=1 also
works which is better.
Reading about _FORTIFY_SOURCE in the following link, everything
makes sense now.
Snippet from http://mail-index.netbsd.org/tech-userlevel/2007/05/23/0001.html
===
The diffence between -D_FORTIFY_SOURCE=1 and -D_FORTIFY_SOURCE=2
is e.g. for
struct S { struct T { char buf[5]; int x; } t; char buf[20]; } var;
With -D_FORTIFY_SOURCE=1,
strcpy (var.t.buf[1], abcdefg);
is not considered an overflow (object is whole VAR), while
with -D_FORTIFY_SOURCE=2
strcpy (var.t.buf[1], abcdefg);
will be considered a buffer overflow.
===
This example is very close to what vim does. So it makes sense
that -D_FORTIFY_SOURCE=2 detects an overflow, while
-D_FORTIFY_SOURCE=1 does not.
Adding -D_FORTIFY_SOURCE=1 to Vim makefile sounds like
a good idea.
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
[patch] fixed crash in vim-7.2.40 when compiling with gcc -O3
Hi
I notice that Vim-7.2.40 (huge) crashes on start up when I
compile it with gcc 4.3.2 with -O3 (that's the default gcc
version from Ubuntu-8.10), but it works perfectly fine when
compiled with -O0, -O1 or -O2.
Here is the crash:
$ ./vim
*** buffer overflow detected ***: ./vim terminated
=== Backtrace: =
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7746558]
/lib/tls/i686/cmov/libc.so.6[0xb7744680]
/lib/tls/i686/cmov/libc.so.6(__strcpy_chk+0x44)[0xb7743944]
./vim[0x80817df]
./vim[0x8082ed1]
./vim[0x8089e2c]
./vim[0x8093ef1]
./vim[0x80b4438]
./vim[0x80b6b73]
./vim[0x80a6960]
./vim[0x80a7181]
./vim[0x80a3c14]
./vim[0x80a3d08]
./vim[0x80ffb7c]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7662685]
./vim[0x8052c41]
=== Memory map:
08048000-0823d000 r-xp 08:04 879094 /tmp/vim7/src/vim
0823d000-0823e000 r--p 001f4000 08:04 879094 /tmp/vim7/src/vim
0823e000-0824b000 rw-p 001f5000 08:04 879094 /tmp/vim7/src/vim
0824b000-08253000 rw-p 0824b000 00:00 0
... snip...
b7975000-b7976000 rw-p 0003c000 08:04 2180173
/usr/lib/libgobject-2.0.so.0.1800.2
b7976000-b79a1000 r-xp 08:04 2179260/usr/lib/libfontconfig.so.1.3.0
b79a1000-b79a2000 r--p 0002a000 08:04 2179260/usr/lib/libfontconfig.so.1.3.0
Vim: Caught deadly signal ABRT0 08:04 2179260/usr/lib/lib
Vim: Finished.
Aborted (core dumped)
Valgrind also detects the following problem (only when compiled with -O3):
$ valgrind ./vim
==7840== Memcheck, a memory error detector.
==7840== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==7840== Using LibVEX rev 1854, a library for dynamic binary translation.
==7840== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==7840== Using valgrind-3.3.1-Debian, a dynamic binary instrumentation
framework.
==7840== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==7840== For more details, rerun with: -v
==7840==
**7840** *** strcpy_chk: buffer overflow detected ***: program terminated
==7840==at 0x4027871: VALGRIND_PRINTF_BACKTRACE (valgrind.h:3695)
==7840==by 0x4027A37: __strcpy_chk (mc_replace_strmem.c:614)
==7840==by 0x80817DE: call_user_func (string3.h:106)
==7840==by 0x8082ED0: call_func (eval.c:8017)
==7840==by 0x8089E2B: get_func_tv (eval.c:7864)
==7840==by 0x8093EF0: ex_call (eval.c:3315)
==7840==by 0x80B4437: do_one_cmd (ex_docmd.c:2621)
==7840==by 0x80B6B72: do_cmdline (ex_docmd.c:1095)
==7840==by 0x80A695F: do_source (ex_cmds2.c:3114)
==7840==by 0x80A7180: source_callback (ex_cmds2.c:2558)
==7840==by 0x80A3C13: do_in_runtimepath (ex_cmds2.c:2652)
==7840==by 0x80A3D07: source_runtime (ex_cmds2.c:2572)
==7840==
==7840== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 103 from 1)
==7840== malloc/free: in use at exit: 1,699,551 bytes in 11,588 blocks.
==7840== malloc/free: 23,010 allocs, 11,422 frees, 3,331,612 bytes allocated.
==7840== For counts of detected errors, rerun with: -v
==7840== searching for pointers to 11,588 not-freed blocks.
==7840== checked 2,085,980 bytes.
==7840==
==7840== LEAK SUMMARY:
==7840==definitely lost: 0 bytes in 0 blocks.
==7840== possibly lost: 9,198 bytes in 323 blocks.
==7840==still reachable: 1,690,353 bytes in 11,265 blocks.
==7840== suppressed: 0 bytes in 0 blocks.
==7840== Rerun with --leak-check=full to see details of leaked memory.
(keep in mind that it's with -O3 so line numbers in stack
trace are not accurate)
Trying to narrow down further, I found that it's the -finline-functions
optimization option of gcc which triggers the crash. The option is
turned on with -O3 (among other optimizations). Compiling with
following options is enough to trigger the crash:
CFLAGS = -O2 -g -finline-functions
... whereas the following options works just fine
CFLAGS = -O2 -g
Adding some printf(), I see that Vim crashes at line 22154 in eval.c
in the STRCPY(...):
21153 v = fc.fixvar[fixvar_idx++].var;
21154 STRCPY(v-di_key, 000);
21155 v-di_flags = DI_FLAGS_RO | DI_FLAGS_FIX;
v is declared as: 'dictitem_T *v;' with:
struct dictitem_S
{
typval_Tdi_tv; /* type and value of the variable */
char_u di_flags; /* flags (only used for variable) */
char_u di_key[1]; /* key (actually longer!) */
};
typedef struct dictitem_S dictitem_T;
So copying 000 in 'char_u di_key[1]' is of course a bit special
but it's not a bug I think, it's a classic pattern described in:
http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Zero-Length.html#Zero-Length
There should in practice be no corruption since:
v = fc.fixvar[fixvar_idx++].var;
... with fixvar defined as:
227 struct /* fixed variables for arguments */
228 {
229 dictitem_T var;/* variable (without
room for name) */
230 char_u
test42 fails with latest vim-7.2.40, regression introduced by vim-7.2.33
Using latest vim-7.2.40 from CVS, I notice that 'make test' fails on test42. Looking at previous versions, I see that: - vim-7.2.33 fails test42 - vm-7.2.32 succeeds for every tests So regression is introduced by patch 7.2.33, which explicitly mentions that it touches test42: Problem:When detecting a little endian BOM ucs-2le is used, but the text might be utf-16le. Solution: Default to utf-16le, it also works for ucs-2le. (Jia Yanwei) Files: src/fileio.c, src/testdir/test42.ok Maybe file test42.ok is corrupted on CVS? It contains UTF-16, so it's a binary file. I remember this kind of corruptions happening a while ago with other binary files. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] fixed crash in vim-7.2.40 when compiling with gcc -O3
2008/11/15 Bram Moolenaar [EMAIL PROTECTED]:
Another solution is to use the trick what's done for self a few lines
higher:
v = fc.fixvar[fixvar_idx++].var;
name = v-di_key;
STRCPY(name, self);
So we can do the same for 000:
v = fc.fixvar[fixvar_idx++].var;
name = v-di_key;
STRCPY(name, 000);
Can you please verify this also fixes the crash?
No, the patch does not help. But I see now I that gave the
wrong location for the crash! Sorry about that. Crash
happens in the STRCPY(...) inside add_nr_var(...):
static void
add_nr_var(dp, v, name, nr)
dict_T *dp;
dictitem_T *v;
char*name;
varnumber_T nr;
{
STRCPY(v-di_key, name); /* Crash when compiled with -O3 */
Your patch tried to fixed this line as well anyway, but
it does not work (same crash).
The solution I proposed does work, but as you say, it requires
an ugly #ifdef __GNUC__
Maybe it's not worth trying to tweak the code, if it's a gcc
bug (not 100% sure yet). I will post it in the gcc mailing list,
and link to this thread.
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: fixed crash in vim-7.2.40 when compiling with gcc -O3
On Nov 15, 5:25 pm, Nico Weber [EMAIL PROTECTED] wrote: This code looks OK to me. Maybe it's a bug in gcc or maybe this construction is just not portable. I suspect it's a bug in gcc but I'm not 100% sure. Isn't it better to file this as a bug with gcc? Agreed. I just opened a gcc bug in bugzilla, and linked to this discussion. See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38136 I'll try to see if it's possible to simplify the gcc bug to a simpler test case. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] fixed crash in vim-7.2.40 when compiling with gcc -O3
2008/11/15 Tony Mechelynck [EMAIL PROTECTED]: On 15/11/08 11:12, Dominique Pelle wrote: Hi I notice that Vim-7.2.40 (huge) crashes on start up when I compile it with gcc 4.3.2 with -O3 (that's the default gcc version from Ubuntu-8.10), but it works perfectly fine when compiled with -O0, -O1 or -O2. [...] -O3 is a nondefault setting in Vim, isn't it? I didn't make any changes to how the Vim configure and make optimizes its compile, and I end up (for a Huge Gnome2 GUI, but also for a Tiny Console-only build) with -O2 -fno-strength-reduce -Wall gcc --version answers: gcc (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] followed by a copyright notice and liability disclaimer. Best regards, Tony. When I said this is the default, I meant gcc-4.3.2 is the default compiler of Ubuntu-8.10. I did not mean that -O3 is the default optimization level when compiling Vim. Maybe that was confusing. In any case, I would expect -O3 to work. One of the most important optimization brought by -O3 is inlining of functions. And this is precisely the optimization which somehow breaks vim. You can build with -O3 by editing src/makefile, or by doing... make CFLAGS=-O3 Doing a google search, I found afterwards that it's not a new issue. It was already reported here with the same suggested fix: http://www.mail-archive.com/[EMAIL PROTECTED]/msg03320.html However, the above thread mentions that -fstack-protector triggers it, whereas I observe it with -O3 or with -O2 -g -finline-functions. Cheers -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: [patch] fixed overlapping memcpy() in if_xcmdsrv.c
2008/11/9 Matt Wozniski [EMAIL PROTECTED]:
On Sat, Nov 8, 2008 at 11:18 PM, Tony Mechelynck wrote:
Configure is supposed to check whether one of the system provided
string-move operations handle overlap. Here's what I see in the logs and
files produced by configure on my system:
snip
So I suppose mch_memmove should be used everywhere for moves of byte
strings (overlapping or not), and it will be resolved by bcopy, memmove,
memcpy or the owncoded function according to what configure has found.
You're right up til this point, but mch_memmove() should only be used
where the bytes are overlapping, since it's so much less efficient
than just a normal memcpy() and that loss is only justified when its
extra feature is being used. memmove() should never be used in the
vim sources.
~Matt
Yes, memcpy() is more efficient then memmove() for copying
memory, and can/should be used when there we can guarantee
that there is such overlap. If there can be overlap, memmove()
must be used, but it does not exists on all systems, hence the
need for mch_memmove() for portability. See man pages of
memcpy() memmove().
In practice, memcpy() may actually work on some system,
or may not work depending on compiler, optimization options
or whether copy goes upward or downward, etc. In any case,
don't rely on it, it's not portable.
I just wrote a simple test case, to see how my system (linux x86)
behaves, it shows that memcpy() does not work in practice for
overlapping memory:
$ gcc -Wall -o test-memcpy-memmove test-memcpy-memmove.c
$ ./memcpy-memmove
testing descending memcpy() with overlapping mem...OK
testing ascending memcpy() with overlapping mem...FAIL
expected=[abcdeabcdeabcdepqrstuvwxyz]
actual =[abcdeabcdefghijpqrstuvwxyz]
testing descending memmove() with overlapping mem...OK
testing ascending memmove() with overlapping mem...OK
Interestingly, running the same test case under valgrind gives
different results:
$ valgrind ./test-memcpy-memmove 2 vg.log
testing descending memcpy() with overlapping mem...OK
testing ascending memcpy() with overlapping mem...OK
testing descending memmove() with overlapping mem...OK
testing ascending memmove() with overlapping mem...OK
Results may be different on other systems, but at least,
on Linux x86, using memcpy() for overlapping memory
does not give the correct results. So don't treat those
overlapping memory messages from valgrind as theoretical
bugs, but as real severe nasty bugs.
I attach the source code of my test case if you want to
run it on your system.
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
/*
* Test whether memcpy()/memmove() give the correct
* results when moving overlapping memory upward or
* backward. mempcy() is not guarantee to be correct
* when memory overlaps, memmove() should be correct.
*
* Results on my system (Linux x86):
*
* $ gcc -O2 -Wall -o test-memcpy-memmove test-memcpy-memmove.c
* $ ./test-memcpy-memmove
* testing descending memcpy() with overlapping mem...OK
* testing ascending memcpy() with overlapping mem...FAIL
* expected=[abcdeabcdefghijpqrstuvwxyz]
* actual =[abcdeabcdeabcdepqrstuvwxyz]
* testing descending memmove() with overlapping mem...OK
* testing ascending memmove() with overlapping mem...OK
*
* Dominique Pelle [EMAIL PROTECTED]
*/
#include string.h
#include stdio.h
#include stdlib.h
/* Compare expected and actual results, and print outcome */
static void compare(const char *expected, const char *actual)
{
if (strcmp(expected, actual) == 0) {
printf(OK\n);
} else {
printf(FAIL\n
expected=[%s]\n
actual =[%s]\n, expected, actual);
}
}
int main()
{
/* 0 1 2
* .01234567890123456789012345 */
const char *pristine_str = abcdefghijklmnopqrstuvwxyz;
char *str;
/* Expected results when copying 10 char by 5 positions (hence
* overlapping memory).
*
* When copying downward memmove(str, str + 5, 10)
* (.) for unchanged char (X) for changed char:
*
* pristine: abcdefghijklmnopqrstuvwxyx
* XX */
const const char *expected1 = fghijklmnoklmnopqrstuvwxyz;
/*
* When copying upward memmove(str + 5, str, 10)
* (.) for unchanged char (X) for changed char:
*
* pristine: abcdefghijklmnopqrstuvwxyx
* .XX... */
const const char *expected2 = abcdeabcdefghijpqrstuvwxyz;
printf(testing descending memcpy() with overlapping mem...);
str = strdup(pristine_str);
memcpy(str, str + 5, 10);
compare(str, expected1);
printf(testing ascending memcpy() with overlapping mem
Re: [patch] fixed overlapping memcpy() in if_xcmdsrv.c
2008/11/9 Dominique Pelle [EMAIL PROTECTED]:
$ gcc -Wall -o test-memcpy-memmove test-memcpy-memmove.c
$ ./memcpy-memmove
testing descending memcpy() with overlapping mem...OK
testing ascending memcpy() with overlapping mem...FAIL
expected=[abcdeabcdeabcdepqrstuvwxyz]
actual =[abcdeabcdefghijpqrstuvwxyz]
testing descending memmove() with overlapping mem...OK
testing ascending memmove() with overlapping mem...OK
Oops, small mistake, which does not change the conclusion,
output should have been:
$ ./memcpy-memmove
testing descending memcpy() with overlapping mem...OK
testing ascending memcpy() with overlapping mem...FAIL
expected=[abcdeabcdefghijpqrstuvwxyz]
actual =[abcdeabcdeabcdepqrstuvwxyz]
testing descending memmove() with overlapping mem...OK
testing ascending memmove() with overlapping mem...OK
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
/*
* Test whether memcpy()/memmove() give the correct
* results when moving overlapping memory upward or
* backward. mempcy() is not guarantee to be correct
* when memory overlaps, memmove() should be correct.
*
* Results on my system (Linux x86):
*
* $ gcc -O2 -Wall -o test-memcpy-memmove test-memcpy-memmove.c
* $ ./test-memcpy-memmove
* testing descending memcpy() with overlapping mem...OK
* testing ascending memcpy() with overlapping mem...FAIL
* expected=[abcdeabcdefghijpqrstuvwxyz]
* actual =[abcdeabcdeabcdepqrstuvwxyz]
* testing descending memmove() with overlapping mem...OK
* testing ascending memmove() with overlapping mem...OK
*
* Dominique Pelle [EMAIL PROTECTED]
*/
#include string.h
#include stdio.h
#include stdlib.h
/* Compare expected and actual results, and print outcome */
static void compare(const char *expected, const char *actual)
{
if (strcmp(expected, actual) == 0) {
printf(OK\n);
} else {
printf(FAIL\n
expected=[%s]\n
actual =[%s]\n, expected, actual);
}
}
int main()
{
/* 0 1 2
* .01234567890123456789012345 */
const char *pristine_str = abcdefghijklmnopqrstuvwxyz;
char *str;
/* Expected results when copying 10 char by 5 positions (hence
* overlapping memory).
*
* When copying downward memmove(str, str + 5, 10)
* (.) for unchanged char (X) for changed char:
*
* pristine: abcdefghijklmnopqrstuvwxyx
* XX */
const const char *expected1 = fghijklmnoklmnopqrstuvwxyz;
/*
* When copying upward memmove(str + 5, str, 10)
* (.) for unchanged char (X) for changed char:
*
* pristine: abcdefghijklmnopqrstuvwxyx
* .XX... */
const const char *expected2 = abcdeabcdefghijpqrstuvwxyz;
printf(testing descending memcpy() with overlapping mem...);
str = strdup(pristine_str);
memcpy(str, str + 5, 10);
compare(expected1, str);
printf(testing ascending memcpy() with overlapping mem...);
strcpy(str, pristine_str);
memcpy(str + 5, str, 10);
compare(expected2, str);
printf(testing descending memmove() with overlapping mem...);
strcpy(str, pristine_str);
memmove(str, str + 5, 10);
compare(expected1, str);
printf(testing ascending memmove() with overlapping mem...);
strcpy(str, pristine_str);
memmove(str + 5, str, 10);
compare(expected2, str);
free(str);
return 0;
}
Re: Patch 7.2.031
2008/11/9 Bram Moolenaar [EMAIL PROTECTED]:
Patch 7.2.031
Problem:Information in the viminfo file about previously edited files is
not available to the user. There is no way to get a complete list
of files edited in previous Vim sessions.
Patch 7.2.031 breaks build when compiling with -DEXITFREE:
eval.c: In function 'eval_clear':
eval.c:849: error: 'struct vimvar' has no member named 'vv_string'
eval.c:850: error: 'struct vimvar' has no member named 'vv_string'
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
-~--~~~~--~~--~--~---
Index: eval.c
===
RCS file: /cvsroot/vim/vim7/src/eval.c,v
retrieving revision 1.268
diff -c -r1.268 eval.c
*** eval.c 9 Nov 2008 12:46:09 - 1.268
--- eval.c 9 Nov 2008 14:29:35 -
***
*** 846,853
p = vimvars[i];
if (p-vv_di.di_tv.v_type == VAR_STRING)
{
! vim_free(p-vv_string);
! p-vv_string = NULL;
}
else if (p-vv_di.di_tv.v_type == VAR_LIST)
{
--- 846,853
p = vimvars[i];
if (p-vv_di.di_tv.v_type == VAR_STRING)
{
! vim_free(p-vv_di.di_tv.vval.v_string);
! p-vv_di.di_tv.vval.v_string = NULL;
}
else if (p-vv_di.di_tv.v_type == VAR_LIST)
{
[patch] fixed access to freed memory with -DEXITFREE (introduced by patch-7.2.31)
Hi
Using valgrind, I observe the following error with Vim-7.2.32 when
exiting Vim. It happens only when Vim is compiled with -DEXITFREE
so it's a minor bug, since Vim is normally not compiled with -DEXITFREE.
Doing vim -u NONE -c q is enough to trigger it.
It did not happen with Vim-7.2.30. So it's introduced
by Vim-7.2.{31,32}.
==30738== Invalid read of size 4
==30738==at 0x806E81A: set_ref_in_ht (eval.c:6592)
==30738==by 0x807D751: garbage_collect (eval.c:6536)
==30738==by 0x808A4A4: eval_clear (eval.c:874)
==30738==by 0x81006FD: free_all_mem (misc2.c:1131)
==30738==by 0x813174F: mch_exit (os_unix.c:3057)
==30738==by 0x809E690: ex_quit (ex_docmd.c:6228)
==30738==by 0x80A63CB: do_one_cmd (ex_docmd.c:2622)
==30738==by 0x80A77BE: do_cmdline (ex_docmd.c:1096)
==30738==by 0x811423E: nv_colon (normal.c:5217)
==30738==by 0x8116C53: normal_cmd (normal.c:1184)
==30738==by 0x80DA03F: main_loop (main.c:1180)
==30738==by 0x80DD637: main (main.c:939)
==30738== Address 0x4c18ae4 is 4 bytes inside a block of size 2,048 free'd
==30738==at 0x402268C: free (vg_replace_malloc.c:323)
==30738==by 0x808A42C: eval_clear (eval.c:858)
==30738==by 0x81006FD: free_all_mem (misc2.c:1131)
==30738==by 0x813174F: mch_exit (os_unix.c:3057)
==30738==by 0x809E690: ex_quit (ex_docmd.c:6228)
==30738==by 0x80A63CB: do_one_cmd (ex_docmd.c:2622)
==30738==by 0x80A77BE: do_cmdline (ex_docmd.c:1096)
==30738==by 0x811423E: nv_colon (normal.c:5217)
==30738==by 0x8116C53: normal_cmd (normal.c:1184)
==30738==by 0x80DA03F: main_loop (main.c:1180)
==30738==by 0x80DD637: main (main.c:939)
Line eval.c:6536 where error happens is introduced by patch 7.2.31.
I attach a patch which fixes it, but please double check
that it's correct: calling hash_init(vimvarht) after
hash_clear(vimvarht) is needed to prevent
garbage_collect() from using the freed hash later.
Groetjes
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: eval.c
===
RCS file: /cvsroot/vim/vim7/src/eval.c,v
retrieving revision 1.269
diff -c -r1.269 eval.c
*** eval.c 9 Nov 2008 16:22:01 - 1.269
--- eval.c 9 Nov 2008 20:56:39 -
***
*** 856,861
--- 856,862
}
}
hash_clear(vimvarht);
+ hash_init(vimvarht);
hash_clear(compat_hashtab);
/* script-local variables */
[patch] fixed double call to XCloseDisplay() when Vim is built with -DEXITFREE
Hi Attached patch fixes a bug with Vim-7.2.30 when built with GUI GTK with -DEXITFREE (configure --with-features=huge --enable-gui=gtk). It's a low priority bug since Vim is normally not built with -DEXITFREE. Only GTK GUI is affected (GTK2, athena, Motif are OK). From what I see, GTK takes care of calling XCloseDisplay() through atexit() so mch_free_mem() in os_unix.c should not call XCloseDisplay() before exit() is being called. Here is the error (among other errors) reported by valgrind memory checker: ==12828== Invalid read of size 4 ==12828==at 0x4431EE7: XCloseDisplay (in /usr/lib/libX11.so.6.2.0) ==12828==by 0x418F31E: (within /usr/lib/libgdk-1.2.so.0.9.1) ==12828==by 0x42F7083: exit (in /lib/tls/i686/cmov/libc-2.7.so) ==12828==by 0x8169EF0: mch_exit (os_unix.c:3060) ==12828==by 0x8104D20: getout (main.c:1340) ==12828==by 0x80CA8EE: ex_quit_all (ex_docmd.c:6281) ==12828==by 0x80C4994: do_one_cmd (ex_docmd.c:2621) ==12828==by 0x80C2215: do_cmdline (ex_docmd.c:1095) ==12828==by 0x8148D60: nv_colon (normal.c:5217) ==12828==by 0x8142301: normal_cmd (normal.c:1184) ==12828==by 0x8104A53: main_loop (main.c:1179) ==12828==by 0x810459B: main (main.c:938) ==12828== Address 0x45943b4 is 148 bytes inside a block of size 1,340 free'd ==12828==at 0x402268C: free (vg_replace_malloc.c:323) ==12828==by 0xF3E: _XFreeDisplayStructure (in /usr/lib/libX11.so.6.2.0) ==12828==by 0x4431FC5: XCloseDisplay (in /usr/lib/libX11.so.6.2.0) ==12828==by 0x8169D73: mch_free_mem (os_unix.c:2945) ==12828==by 0x813289B: free_all_mem (misc2.c:1122) ==12828==by 0x8169EE5: mch_exit (os_unix.c:3057) ==12828==by 0x8104D20: getout (main.c:1340) ==12828==by 0x80CA8EE: ex_quit_all (ex_docmd.c:6281) ==12828==by 0x80C4994: do_one_cmd (ex_docmd.c:2621) ==12828==by 0x80C2215: do_cmdline (ex_docmd.c:1095) ==12828==by 0x8148D60: nv_colon (normal.c:5217) ==12828==by 0x8142301: normal_cmd (normal.c:1184) ==12828==by 0x8104A53: main_loop (main.c:1179) ==12828==by 0x810459B: main (main.c:938) Attached patch fixes it. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- Index: os_unix.c === RCS file: /cvsroot/vim/vim7/src/os_unix.c,v retrieving revision 1.85 diff -c -r1.85 os_unix.c *** os_unix.c 6 Aug 2008 16:45:01 - 1.85 --- os_unix.c 7 Nov 2008 19:34:04 - *** *** 2937,2948 # endif # endif # ifdef FEAT_X11 if (x11_display != NULL ! # ifdef FEAT_XCLIPBOARD x11_display != xterm_dpy ! # endif ) XCloseDisplay(x11_display); # endif # if defined(HAVE_SIGALTSTACK) || defined(HAVE_SIGSTACK) vim_free(signal_stack); --- 2937,2952 # endif # endif # ifdef FEAT_X11 + /* Don't call XCloseDisplay() for GUI GTK without HAVE_GTK2, it + * already calls it in atexit() */ + # if !defined(FEAT_GUI_GTK) || defined(HAVE_GTK2) if (x11_display != NULL ! #ifdef FEAT_XCLIPBOARD x11_display != xterm_dpy ! #endif ) XCloseDisplay(x11_display); + # endif # endif # if defined(HAVE_SIGALTSTACK) || defined(HAVE_SIGSTACK) vim_free(signal_stack);
[patch] fixed overlapping memcpy() in if_xcmdsrv.c
Hi While using Vim-7.2.30 built with GUI GTK (huge), I stumbled upon this error with Valgrind memory checker: ==13326== Source and destination overlap in memcpy(0x4B5D8D8, 0x4B5D8E4, 13) ==13326==at 0x4024C92: memcpy (mc_replace_strmem.c:402) ==13326==by 0x8102E99: LookupName (if_xcmdsrv.c:1021) ==13326==by 0x810197E: DoRegisterName (if_xcmdsrv.c:303) ==13326==by 0x8101718: serverRegisterName (if_xcmdsrv.c:225) ==13326==by 0x81076D1: prepare_server (main.c:3379) ==13326==by 0x8104253: main (main.c:721) Attached patch fixes it by calling mch_memmove() instead of memcpy(). Looking at the code, I found another place where the same problem would also happen (also fixed in patch). Cheers -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- Index: if_xcmdsrv.c === RCS file: /cvsroot/vim/vim7/src/if_xcmdsrv.c,v retrieving revision 1.11 diff -c -r1.11 if_xcmdsrv.c *** if_xcmdsrv.c 6 Aug 2008 16:38:13 - 1.11 --- if_xcmdsrv.c 7 Nov 2008 19:47:32 - *** *** 1018,1024 p++; count = numItems - (p - regProp); if (count 0) ! memcpy(entry, p, count); XChangeProperty(dpy, RootWindow(dpy, 0), registryProperty, XA_STRING, 8, PropModeReplace, regProp, (int)(numItems - (p - entry))); --- 1018,1024 p++; count = numItems - (p - regProp); if (count 0) ! mch_memmove(entry, p, count); XChangeProperty(dpy, RootWindow(dpy, 0), registryProperty, XA_STRING, 8, PropModeReplace, regProp, (int)(numItems - (p - entry))); *** *** 1072,1078 p++; lastHalf = numItems - (p - regProp); if (lastHalf 0) ! memcpy(entry, p, lastHalf); numItems = (entry - regProp) + lastHalf; p = entry; continue; --- 1072,1078 p++; lastHalf = numItems - (p - regProp); if (lastHalf 0) ! mch_memmove(entry, p, lastHalf); numItems = (entry - regProp) + lastHalf; p = entry; continue;
[patch] fix mismatches between alloc()/free malloc()/vim_free
Hi Valgrind memory checker detects mismatches between malloc()/vim_free() and alloc()/free in vim-7.2.30: - If malloc() is used, then free() should be used, - if alloc() is used, then vim_free() should be used. It only really matters when compiling vim with '#define MEM_PROFILE', because MEMPROFILE adds one word before each allocated block so a mismatch results not only in an illegal free, but also gives incorrect memory profile results. Normally MEMPROFILE is not defined, so it's a minor bug. Here is an error reported by valgrind: ==9768== Invalid read of size 4 ==9768==at 0x8132623: mem_pre_free (misc2.c:687) ==9768==by 0x8133650: vim_free (misc2.c:1623) ==9768==by 0x816A210: mch_free_mem (os_unix.c:2948) ==9768==by 0x8132CF0: free_all_mem (misc2.c:1122) ==9768==by 0x816A375: mch_exit (os_unix.c:3057) ==9768==by 0x8104DEC: getout (main.c:1340) ==9768==by 0x80CA9AE: ex_quit_all (ex_docmd.c:6281) ==9768==by 0x80C4A54: do_one_cmd (ex_docmd.c:2621) ==9768==by 0x80C22D5: do_cmdline (ex_docmd.c:1095) ==9768==by 0x81491C0: nv_colon (normal.c:5217) ==9768==by 0x8142761: normal_cmd (normal.c:1184) ==9768==by 0x8104B1F: main_loop (main.c:1179) ==9768==by 0x8104667: main (main.c:938) ==9768== Address 0x454e6fc is 4 bytes before a block of size 8,192 alloc'd ==9768==at 0x4022AE8: malloc (vg_replace_malloc.c:207) ==9768==by 0x816A151: mch_early_init (os_unix.c:2908) ==9768==by 0x8103D86: main (main.c:181) ==9768== ==9768== Invalid free() / delete / delete[] ==9768== Invalid free() / delete / delete[] ==9768==at 0x402268C: free (vg_replace_malloc.c:323) ==9768==by 0x813365B: vim_free (misc2.c:1625) ==9768==by 0x816A210: mch_free_mem (os_unix.c:2948) ==9768==by 0x8132CF0: free_all_mem (misc2.c:1122) ==9768==by 0x816A375: mch_exit (os_unix.c:3057) ==9768==by 0x8104DEC: getout (main.c:1340) ==9768==by 0x80CA9AE: ex_quit_all (ex_docmd.c:6281) ==9768==by 0x80C4A54: do_one_cmd (ex_docmd.c:2621) ==9768==by 0x80C22D5: do_cmdline (ex_docmd.c:1095) ==9768==by 0x81491C0: nv_colon (normal.c:5217) ==9768==by 0x8142761: normal_cmd (normal.c:1184) ==9768==by 0x8104B1F: main_loop (main.c:1179) ==9768==by 0x8104667: main (main.c:938) ==9768== Address 0x454e6fc is 4 bytes before a block of size 8,192 alloc'd ==9768==at 0x4022AE8: malloc (vg_replace_malloc.c:207) ==9768==by 0x816A151: mch_early_init (os_unix.c:2908) ==9768==by 0x8103D86: main (main.c:181) Another mismatch: ==9768== Invalid free() / delete / delete[] ==9768==at 0x402268C: free (vg_replace_malloc.c:323) ==9768==by 0x813365B: vim_free (misc2.c:1625) ==9768==by 0x816E7FB: xsmp_close (os_unix.c:6817) ==9768==by 0x8132D0F: free_all_mem (misc2.c:1140) ==9768==by 0x816A375: mch_exit (os_unix.c:3057) ==9768==by 0x8104DEC: getout (main.c:1340) ==9768==by 0x80CA9AE: ex_quit_all (ex_docmd.c:6281) ==9768==by 0x80C4A54: do_one_cmd (ex_docmd.c:2621) ==9768==by 0x80C22D5: do_cmdline (ex_docmd.c:1095) ==9768==by 0x81491C0: nv_colon (normal.c:5217) ==9768==by 0x8142761: normal_cmd (normal.c:1184) ==9768==by 0x8104B1F: main_loop (main.c:1179) ==9768==by 0x8104667: main (main.c:938) ==9768== Address 0x458ad3c is 4 bytes before a block of size 38 alloc'd ==9768==at 0x4022AE8: malloc (vg_replace_malloc.c:207) ==9768==by 0x450A167: _SmcProcessMessage (in /usr/lib/libSM.so.6.0.0) ==9768==by 0x451DAB2: IceProcessMessages (in /usr/lib/libICE.so.6.3.0) ==9768==by 0x45065A2: SmcOpenConnection (in /usr/lib/libSM.so.6.0.0) ==9768==by 0x816E741: xsmp_init (os_unix.c:6769) ==9768==by 0x8103FE1: main (main.c:494) Here memory is allocated with malloc inside SmcOpenConnection(), so it should be freed by free() instead of vim_free(). Here is a memory profile before after fix, when doing vim -u NONE and quiting immediately. Before fix, notice that it reports 6 allocated blocks 8199, and only 4 of them are reported as freed when exiting. 2 of those large blocks are actually spurious and result from the mismatches. After fix, it reports 4 allocated blocks 8199 and all 4 of them are reported as freed. Before fix: [ 1 / 41-41 ] [ 2 / 12-12 ] [ 3 / 12-12 ] [ 4 / 37-37 ] [ 5 / 109-109 ] [ 6 / 79-79 ] [ 7 / 80-80 ] [ 8 / 125-125 ] [ 9 / 68-68 ] [ 10 / 74-74 ] [ 11 / 71-71 ] [ 12 / 18-18 ] [ 13 / 23-23 ] [ 15 /5-5 ] [ 16 /3-3 ] [ 17 /2-2 ] [ 19 /4-4 ] [ 20 /2-2 ] [ 21 /5-5 ] [ 23 /2-2 ] [ 24 /4-4 ] [ 25 /1-1 ] [ 27 /1-1 ] [ 28 /3-3 ] [ 29 /1-1 ] [ 30 /1-1 ] [ 32 /4-4 ] [ 36 /1-1 ] [ 40 /2-2 ] [ 42 /2-2 ] [ 44 /2-2 ] [ 51 /1-1 ] [ 54 /1-1 ] [ 80 /1-1 ] [ 100 /2-1 ] [ 121 /1-1 ] [ 129 /1-1 ] [ 144 /1-1 ] [ 168 /2-2 ] [ 246 /1-1 ] [ 268 /1-1 ] [ 276 /
Re: [patch] fix mismatches between alloc()/free malloc()/vim_free
2008/11/8 Dominique Pelle [EMAIL PROTECTED]:
Hi
Valgrind memory checker detects mismatches between malloc()/vim_free()
and alloc()/free in vim-7.2.30:
- If malloc() is used, then free() should be used,
- if alloc() is used, then vim_free() should be used.
It only really matters when compiling vim with '#define MEM_PROFILE',
because MEMPROFILE adds one word before each allocated block so
a mismatch results not only in an illegal free, but also gives incorrect
memory profile results. Normally MEMPROFILE is not defined, so it's a
minor bug.
I found a few more of this kind of errors. vim_realloc() should also be
called rather than realloc() when memory was previously allocated
with alloc().
Regards
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: mbyte.c
===
RCS file: /cvsroot/vim/vim7/src/mbyte.c,v
retrieving revision 1.70
diff -c -r1.70 mbyte.c
*** mbyte.c 6 Sep 2008 14:44:40 - 1.70
--- mbyte.c 8 Nov 2008 05:55:48 -
***
*** 5384,5390
draw_feedback = (char *)alloc(draw_data-chg_first
+ text-length);
else
! draw_feedback = realloc(draw_feedback,
draw_data-chg_first + text-length);
if (draw_feedback != NULL)
{
--- 5384,5390
draw_feedback = (char *)alloc(draw_data-chg_first
+ text-length);
else
! draw_feedback = vim_realloc(draw_feedback,
draw_data-chg_first + text-length);
if (draw_feedback != NULL)
{
Index: gui_w48.c
===
RCS file: /cvsroot/vim/vim7/src/gui_w48.c,v
retrieving revision 1.43
diff -c -r1.43 gui_w48.c
*** gui_w48.c 24 Jul 2008 18:50:23 - 1.43
--- gui_w48.c 8 Nov 2008 05:55:49 -
***
*** 3335,3341
/*
* Convert the string s to the proper format for a filter string by replacing
! * the \t and \n delimeters with \0.
* Returns the converted string in allocated memory.
*
* Keep in sync with convert_filterW() above!
--- 3335,3341
/*
* Convert the string s to the proper format for a filter string by replacing
! * the \t and \n delimiters with \0.
* Returns the converted string in allocated memory.
*
* Keep in sync with convert_filterW() above!
***
*** 3711,3717
/* The command line is copied to allocated memory, so that we can change
* it. Add the size of the string, the separating NUL and a terminating
* NUL. */
! newcmdline = malloc(STRLEN(cmdline) + STRLEN(progp) + 2);
if (newcmdline == NULL)
return 0;
--- 3711,3717
/* The command line is copied to allocated memory, so that we can change
* it. Add the size of the string, the separating NUL and a terminating
* NUL. */
! newcmdline = (char *)alloc(STRLEN(cmdline) + STRLEN(progp) + 2);
if (newcmdline == NULL)
return 0;
Index: os_vms.c
===
RCS file: /cvsroot/vim/vim7/src/os_vms.c,v
retrieving revision 1.10
diff -c -r1.10 os_vms.c
*** os_vms.c 6 Aug 2008 16:38:52 - 1.10
--- os_vms.c 8 Nov 2008 05:55:49 -
***
*** 381,387
if (--vms_match_free == 0) {
/* add more space to store matches */
vms_match_alloced += EXPL_ALLOC_INC;
! vms_fmatch = (char_u **)realloc(vms_fmatch,
sizeof(char **) * vms_match_alloced);
if (!vms_fmatch)
return 0;
--- 381,387
if (--vms_match_free == 0) {
/* add more space to store matches */
vms_match_alloced += EXPL_ALLOC_INC;
! vms_fmatch = (char_u **)vim_realloc(vms_fmatch,
sizeof(char **) * vms_match_alloced);
if (!vms_fmatch)
return 0;
***
*** 460,466
if (--files_free 1)
{
files_alloced += EXPL_ALLOC_INC;
! *file = (char_u **)realloc(*file,
sizeof(char_u **) * files_alloced);
if (*file == NULL)
{
--- 460,466
if (--files_free 1)
{
files_alloced += EXPL_ALLOC_INC;
! *file = (char_u **)vim_realloc(*file,
sizeof(char_u **) * files_alloced);
if (*file == NULL)
{
Index: misc2.c
===
RCS file: /cvsroot/vim/vim7/src/misc2.c,v
retrieving revision 1.75
diff -c -r1.75 misc2.c
*** misc2.c 6 Sep 2008 14:44:51 - 1.75
--- misc2.c 8 Nov 2008 05:55:52 -
***
*** 873,879
/* 3. check for available memory: call mch_avail_mem() */
if (mch_avail_mem(TRUE) KEEP_ROOM !releasing)
{
! vim_free((char *)p); /* System is low... no go! */
p = NULL;
}
else
--- 873,879
/* 3. check for available memory: call mch_avail_mem() */
if (mch_avail_mem(TRUE
[patch] fixed grammar mistake in help file message.txt
Hi
Attached is a patch to fix an obvious grammar mistake in :help E303
in vim-7.2.25.
Regards
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: message.txt
===
RCS file: /cvsroot/vim/vim7/runtime/doc/message.txt,v
retrieving revision 1.28
diff -c -r1.28 message.txt
*** message.txt 9 Aug 2008 17:39:30 - 1.28
--- message.txt 31 Oct 2008 19:59:30 -
***
*** 567,573
Unable to open swap file for {filename}, recovery impossible
Vim was not able to create a swap file. You can still edit the file, but if
! Vim unexpected exits the changes will be lost. And Vim may consume a lot of
memory when editing a big file. You may want to change the 'directory' option
to avoid this error. See |swap-file|.
--- 567,573
Unable to open swap file for {filename}, recovery impossible
Vim was not able to create a swap file. You can still edit the file, but if
! Vim unexpectedly exits the changes will be lost. And Vim may consume a lot of
memory when editing a big file. You may want to change the 'directory' option
to avoid this error. See |swap-file|.
[patch] fixed memory leak when deleting buffer with spell checking
Hi
The following vim script leaks memory at each iteration, using
latest Vim-7.2.25:
:set spell
:while 1
:copen
:bd
:endwhile
Run this script with 'vim -u NONE -S leak.vim' and watch memory
increasing steadily. Valgrind reports this leak:
$ valgrind --leak-check=yes --num-callers=20 vim -u NONE -S leak.vim
...
==14170== 124,288 bytes in 3,884 blocks are definitely lost in loss
record 65 of 65
==14170==at 0x4022AE8: malloc (vg_replace_malloc.c:207)
==14170==by 0x81127C4: lalloc (misc2.c:859)
==14170==by 0x81126FB: alloc_clear (misc2.c:770)
==14170==by 0x811370D: ga_grow (misc2.c:1981)
==14170==by 0x817E875: did_set_spelllang (spell.c:4261)
==14170==by 0x8097922: do_ecmd (ex_cmds.c:3704)
==14170==by 0x8152AC1: ex_copen (quickfix.c:2336)
==14170==by 0x80A61E1: do_one_cmd (ex_docmd.c:2621)
==14170==by 0x80A3A84: do_cmdline (ex_docmd.c:1095)
==14170==by 0x80A1D20: do_source (ex_cmds2.c:3114)
==14170==by 0x80A163B: cmd_source (ex_cmds2.c:2741)
==14170==by 0x80A158F: ex_source (ex_cmds2.c:2714)
==14170==by 0x80A61E1: do_one_cmd (ex_docmd.c:2621)
==14170==by 0x80A3A84: do_cmdline (ex_docmd.c:1095)
==14170==by 0x80A3124: do_cmdline_cmd (ex_docmd.c:701)
==14170==by 0x80E7600: exe_commands (main.c:2683)
==14170==by 0x80E500F: main (main.c:873)
The number of blocks leaked (3,884 here) is the number of
iterations in the loop before I hit Ctrl-C.
I'm using Vim-7.2.25, built with -O0 on Linux x86.
Attached patch fixes it (+ typos in comments).
Regards
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: buffer.c
===
RCS file: /cvsroot/vim/vim7/src/buffer.c,v
retrieving revision 1.83
diff -c -r1.83 buffer.c
*** buffer.c 1 Sep 2008 15:32:55 - 1.83
--- buffer.c 22 Oct 2008 01:55:20 -
***
*** 647,652
--- 647,655
vim_free(buf-b_start_fenc);
buf-b_start_fenc = NULL;
#endif
+ #ifdef FEAT_SPELL
+ ga_clear(buf-b_langp);
+ #endif
}
/*
***
*** 1880,1886
* buf if one exists */
if (swb_flags SWB_USEOPEN)
wp = buf_jump_open_win(buf);
! /* If 'switchbuf' contians usetab: jump to first window in any tab
* page containing buf if one exists */
if (wp == NULL (swb_flags SWB_USETAB))
wp = buf_jump_open_tab(buf);
--- 1883,1889
* buf if one exists */
if (swb_flags SWB_USEOPEN)
wp = buf_jump_open_win(buf);
! /* If 'switchbuf' contains usetab: jump to first window in any tab
* page containing buf if one exists */
if (wp == NULL (swb_flags SWB_USETAB))
wp = buf_jump_open_tab(buf);
***
*** 3964,3970
width = vim_strsize(out);
if (maxwidth 0 width maxwidth)
{
! /* Result is too long, must trunctate somewhere. */
l = 0;
if (itemcnt == 0)
s = out;
--- 3967,3973
width = vim_strsize(out);
if (maxwidth 0 width maxwidth)
{
! /* Result is too long, must truncate somewhere. */
l = 0;
if (itemcnt == 0)
s = out;
Re: [patch] fixed memory leak in do_sub() ex_cmds.c
On Sat, Sep 13, 2008 at 4:09 PM, Bram Moolenaar wrote: Dominique Pelle wrote: Valgrind memory checker finds a memory leak in Vim-7.2.15. The steps to reproduce are a bit too messy to describe here and I have not been able to find a simple way to reproduce it. However I can reproduce it 100% of the time: Perhaps this happens when undo is disabled? It happened when I did: :argdo %s/foo/bar/g The substitute command tried to modify a readonly file which triggered perforce plugin to ask to checkout the file, I pressed ctrl-c to interrupt. Then when exiting I found the leak. I could reproduce it all the time. Perhaps the argdo is not necessary, I won't have access to my development machine for a few weeks to try anything. But the bug is pretty clear from looking at the code anyway I think. A printf confirmed that leak happened when u_savesub(lnum) at line 4993 returned != OK and break statement at line 4994 caused the leak: 4993 if (u_savesub(lnum) != OK) !4994 break; -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
[patch] fixed memory leak in do_sub() ex_cmds.c
Hi
Valgrind memory checker finds a memory leak in Vim-7.2.15.
The steps to reproduce are a bit too messy to describe here
and I have not been able to find a simple way to reproduce it.
However I can reproduce it 100% of the time:
==1182== 150 bytes in 2 blocks are definitely lost in loss record 24 of 34
==1182==at 0x4C21FEB: malloc (vg_replace_malloc.c:207)
==1182==by 0x4D6927: lalloc (misc2.c:859)
==1182==by 0x4D689A: alloc_check (misc2.c:792)
==1182==by 0x457EC4: do_sub (ex_cmds.c:4822)
==1182==by 0x465561: do_one_cmd (ex_docmd.c:2621)
==1182==by 0x462D41: do_cmdline (ex_docmd.c:1095)
==1182==by 0x45FE46: ex_listdo (ex_cmds2.c:2374)
==1182==by 0x465561: do_one_cmd (ex_docmd.c:2621)
==1182==by 0x462D41: do_cmdline (ex_docmd.c:1095)
==1182==by 0x4EE779: nv_colon (normal.c:5214)
==1182==by 0x4E775D: normal_cmd (normal.c:1181)
==1182==by 0x4A79EF: main_loop (main.c:1179)
==1182==by 0x4A7535: main (main.c:938)
I see at least 2 'break' statements that would cause such
a leak at lines 4994 and line 5007 in ex_cmds.c:
4979 if (new_start != NULL)
4980 {
4981 /*
4982 * Copy the rest of the line, that didn't match.
4983 * matchcol has to be adjusted, we use
the end of
4984 * the line as reference, because the
substitute m
4985 * have changed the number of
characters. Same for
4986 * prev_matchcol.
4987 */
4988 STRCAT(new_start, sub_firstline + copycol);
4989 matchcol =
(colnr_T)STRLEN(sub_firstline) - matchc
4990 prev_matchcol = (colnr_T)STRLEN(sub_firstline)
4991 -
prev_match
4992
4993 if (u_savesub(lnum) != OK)
!4994 break;
4995 ml_replace(lnum, new_start, TRUE);
4996
4997 if (nmatch_tl 0)
4998 {
4999 /*
5000 * Matched lines have now been
substituted and
5001 * useless, delete them. The part
after the m
5002 * has been appended to new_start,
we don't ne
5003 * it in the buffer.
5004 */
5005 ++lnum;
5006 if (u_savedel(lnum, nmatch_tl) != OK)
!5007 break;
Attached patch fixes it.
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: ex_cmds.c
===
RCS file: /cvsroot/vim/vim7/src/ex_cmds.c,v
retrieving revision 1.113
diff -c -r1.113 ex_cmds.c
*** ex_cmds.c 6 Aug 2008 13:03:07 - 1.113
--- ex_cmds.c 11 Sep 2008 18:22:00 -
***
*** 5059,5064
--- 5059,5065
if (did_sub)
++sub_nlines;
+ vim_free(new_start);
vim_free(sub_firstline); /* free the copy of the original line */
sub_firstline = NULL;
}
Re: (patch) fix access to freed memory in if_getline.c
On Sun, Mar 16, 2008 at 2:21 PM, Bram Moolenaar [EMAIL PROTECTED] wrote: Dominique Pelle wrote: Valgrind memory checker detects the following bug in Vim-7.1.280: ==11795== Invalid read of size 1 ==11795==at 0x4023572: strncmp (mc_replace_strmem.c:318) ==11795==by 0x80B6653: getcmdline (ex_getln.c:556) ==11795==by 0x80B940B: getexline (ex_getln.c:2100) ==11795==by 0x80A2F3E: do_cmdline (ex_docmd.c:995) ==11795==by 0x8129B52: nv_colon (normal.c:5179) ==11795==by 0x812310E: normal_cmd (normal.c:1152) ==11795==by 0x80E5F41: main_loop (main.c:1181) ==11795==by 0x80E5A91: main (main.c:940) ==11795== Address 0x56484AA is 2 bytes inside a block of size 100 free'd ==11795==at 0x402237F: free (vg_replace_malloc.c:233) ==11795==by 0x8114251: vim_free (misc2.c:1580) ==11795==by 0x80B9D01: realloc_cmdbuff (ex_getln.c:2509) ==11795==by 0x80BA194: put_on_cmdline (ex_getln.c:2708) ==11795==by 0x80B8B8F: getcmdline (ex_getln.c:1679) ==11795==by 0x80B940B: getexline (ex_getln.c:2100) ==11795==by 0x80A2F3E: do_cmdline (ex_docmd.c:995) ==11795==by 0x8129B52: nv_colon (normal.c:5179) ==11795==by 0x812310E: normal_cmd (normal.c:1152) ==11795==by 0x80E5F41: main_loop (main.c:1181) ==11795==by 0x80E5A91: main (main.c:940) (more errors of this kind follow when it happens) Bug is unfortunately difficult to reproduce. I have not found a systematic way of reproducing it but I have encountered it a couple of times. From the above stack traces, it is easy enough to understand though: xpc.xp_pattern normally points to somewhere inside ccline.cmdbuff. But at line ex_getln.c:556, it points to freed memory according to valgrind, because a previous call to put_on_cmdline() has reallocated ccline.cmdbuff. Since xpc.xp_pattern was not updated, it then points to freed memory. Looking at the code, functions that can reallocate ccline.cmdbuff are: put_on_cmdline() .. because it may call realloc_cmdbuff() cmdline_paste_str() ... because it may call put_on_cmdline() cmdline_paste() ... because it may call cmdline_paste_str() Whenever any of these functions is called, we should take care of reinitializing xpc.xp_pattern appropriately. Function nextwild() also calls realloc_cmdbuff() but this one is OK since it internally reinitializes xpc.xp_pattern. I attach a patch which should fix the bug. -- Dominique I saw one additional similar issue even after my previous patch. ==7527== Invalid read of size 1 ==7527==at 0x4023572: strncmp (mc_replace_strmem.c:318) ==7527==by 0x80B6656: getcmdline (ex_getln.c:557) ==7527==by 0x80B94FF: getexline (ex_getln.c:2126) ==7527==by 0x80A2F3E: do_cmdline (ex_docmd.c:995) ==7527==by 0x8129C46: nv_colon (normal.c:5179) ==7527==by 0x8123202: normal_cmd (normal.c:1152) ==7527==by 0x80E6035: main_loop (main.c:1181) ==7527==by 0x80E5B85: main (main.c:940) ==7527== Address 0x55B1024 is 4 bytes inside a block of size 140 free'd ==7527==at 0x402237F: free (vg_replace_malloc.c:233) ==7527==by 0x8114345: vim_free (misc2.c:1580) ==7527==by 0x80C0061: ex_window (ex_getln.c:6143) ==7527==by 0x80B6BF8: getcmdline (ex_getln.c:734) ==7527==by 0x80B94FF: getexline (ex_getln.c:2126) ==7527==by 0x80A2F3E: do_cmdline (ex_docmd.c:995) ==7527==by 0x8129C46: nv_colon (normal.c:5179) ==7527==by 0x8123202: normal_cmd (normal.c:1152) ==7527==by 0x80E6035: main_loop (main.c:1181) ==7527==by 0x80E5B85: main (main.c:940) Function ex_window() may also free and reallocate ccline.cmdbuff hence invalidating xpc.xp_pattern. I attach an update of my previous patch which should also fix this issue. This is tricky, since xp_pattern is separate from the allocated command line. It's very easy to forget updating xp_pattern. One solution would be to change xp_pattern from a pointer into a byte index. But there are several places where the start of the command line are not known. Another solution would be to make expand_T part of struct cmdline_info. Then xp_pattern can be adjusted by the function reallocating the command line. Code only using the expand_T doesn't need to be changed then. I'll look further into this. Until now, I saw this bug a couple of times but never found a way to reproduce it easily. Well, I just found a way to reproduce this easily with vim-7.2.6 (also with gvim). 1/ start vim with: algrind vim -u NONE 2/ enter Ex command :set nocompatible wildmenu 3/ put at least one command in Ex history :echo foobar 4/ press Ex command :e - followed --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: (patch) fix access to freed memory in if_getline.c
On Sun, Aug 31, 2008 at 12:06 PM, Dominique Pelle [EMAIL PROTECTED] wrote: On Sun, Mar 16, 2008 at 2:21 PM, Bram Moolenaar [EMAIL PROTECTED] wrote: Dominique Pelle wrote: Valgrind memory checker detects the following bug in Vim-7.1.280: ==11795== Invalid read of size 1 ==11795==at 0x4023572: strncmp (mc_replace_strmem.c:318) ==11795==by 0x80B6653: getcmdline (ex_getln.c:556) ==11795==by 0x80B940B: getexline (ex_getln.c:2100) ==11795==by 0x80A2F3E: do_cmdline (ex_docmd.c:995) ==11795==by 0x8129B52: nv_colon (normal.c:5179) ==11795==by 0x812310E: normal_cmd (normal.c:1152) ==11795==by 0x80E5F41: main_loop (main.c:1181) ==11795==by 0x80E5A91: main (main.c:940) ==11795== Address 0x56484AA is 2 bytes inside a block of size 100 free'd ==11795==at 0x402237F: free (vg_replace_malloc.c:233) ==11795==by 0x8114251: vim_free (misc2.c:1580) ==11795==by 0x80B9D01: realloc_cmdbuff (ex_getln.c:2509) ==11795==by 0x80BA194: put_on_cmdline (ex_getln.c:2708) ==11795==by 0x80B8B8F: getcmdline (ex_getln.c:1679) ==11795==by 0x80B940B: getexline (ex_getln.c:2100) ==11795==by 0x80A2F3E: do_cmdline (ex_docmd.c:995) ==11795==by 0x8129B52: nv_colon (normal.c:5179) ==11795==by 0x812310E: normal_cmd (normal.c:1152) ==11795==by 0x80E5F41: main_loop (main.c:1181) ==11795==by 0x80E5A91: main (main.c:940) (more errors of this kind follow when it happens) Bug is unfortunately difficult to reproduce. I have not found a systematic way of reproducing it but I have encountered it a couple of times. From the above stack traces, it is easy enough to understand though: xpc.xp_pattern normally points to somewhere inside ccline.cmdbuff. But at line ex_getln.c:556, it points to freed memory according to valgrind, because a previous call to put_on_cmdline() has reallocated ccline.cmdbuff. Since xpc.xp_pattern was not updated, it then points to freed memory. Looking at the code, functions that can reallocate ccline.cmdbuff are: put_on_cmdline() .. because it may call realloc_cmdbuff() cmdline_paste_str() ... because it may call put_on_cmdline() cmdline_paste() ... because it may call cmdline_paste_str() Whenever any of these functions is called, we should take care of reinitializing xpc.xp_pattern appropriately. Function nextwild() also calls realloc_cmdbuff() but this one is OK since it internally reinitializes xpc.xp_pattern. I attach a patch which should fix the bug. -- Dominique I saw one additional similar issue even after my previous patch. ==7527== Invalid read of size 1 ==7527==at 0x4023572: strncmp (mc_replace_strmem.c:318) ==7527==by 0x80B6656: getcmdline (ex_getln.c:557) ==7527==by 0x80B94FF: getexline (ex_getln.c:2126) ==7527==by 0x80A2F3E: do_cmdline (ex_docmd.c:995) ==7527==by 0x8129C46: nv_colon (normal.c:5179) ==7527==by 0x8123202: normal_cmd (normal.c:1152) ==7527==by 0x80E6035: main_loop (main.c:1181) ==7527==by 0x80E5B85: main (main.c:940) ==7527== Address 0x55B1024 is 4 bytes inside a block of size 140 free'd ==7527==at 0x402237F: free (vg_replace_malloc.c:233) ==7527==by 0x8114345: vim_free (misc2.c:1580) ==7527==by 0x80C0061: ex_window (ex_getln.c:6143) ==7527==by 0x80B6BF8: getcmdline (ex_getln.c:734) ==7527==by 0x80B94FF: getexline (ex_getln.c:2126) ==7527==by 0x80A2F3E: do_cmdline (ex_docmd.c:995) ==7527==by 0x8129C46: nv_colon (normal.c:5179) ==7527==by 0x8123202: normal_cmd (normal.c:1152) ==7527==by 0x80E6035: main_loop (main.c:1181) ==7527==by 0x80E5B85: main (main.c:940) Function ex_window() may also free and reallocate ccline.cmdbuff hence invalidating xpc.xp_pattern. I attach an update of my previous patch which should also fix this issue. This is tricky, since xp_pattern is separate from the allocated command line. It's very easy to forget updating xp_pattern. One solution would be to change xp_pattern from a pointer into a byte index. But there are several places where the start of the command line are not known. Another solution would be to make expand_T part of struct cmdline_info. Then xp_pattern can be adjusted by the function reallocating the command line. Code only using the expand_T doesn't need to be changed then. I'll look further into this. Until now, I saw this bug a couple of times but never found a way to reproduce it easily. Well, I just found a way to reproduce this easily with vim-7.2.6 (also with gvim). My apologies: I started writing the previous message and it was sent before I finished editing it! Gmail has some odd/dangerous shortcuts to send email. Until now, I saw the bug described in this thread a couple of times but never I found a way to reproduce it easily. Well, I just found a way to reproduce it easily with vim-7.2.6 (also with gvim
[patch] missing parenthesis in runtime/doc/pattern.txt
Attached patch fixes a missing parenthesis in runtime/doc/pattern.txt in Vim-7.2. Cheers -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- Index: pattern.txt === RCS file: /cvsroot/vim/vim7/runtime/doc/pattern.txt,v retrieving revision 1.38 diff -c -r1.38 pattern.txt *** pattern.txt 9 Aug 2008 17:43:14 - 1.38 --- pattern.txt 26 Aug 2008 20:32:20 - *** *** 507,513 |/\Z| \Z \Z ignore differences in Unicode combining characters. Useful when searching voweled Hebrew or Arabic text. ! |/\%d| \%d \%d match specified decimal character (eg \%d123 |/\%x| \%x \%x match specified hex character (eg \%x2a) |/\%o| \%o \%o match specified octal character (eg \%o040) |/\%u| \%u \%u match specified multibyte character (eg \%u20ac) --- 507,513 |/\Z| \Z \Z ignore differences in Unicode combining characters. Useful when searching voweled Hebrew or Arabic text. ! |/\%d| \%d \%d match specified decimal character (eg \%d123) |/\%x| \%x \%x match specified hex character (eg \%x2a) |/\%o| \%o \%o match specified octal character (eg \%o040) |/\%u| \%u \%u match specified multibyte character (eg \%u20ac)
Re: Bug in clipboard handling on X11
On Fri, Aug 22, 2008 at 3:32 AM, Matt Wozniski wrote:
Not sure what's going on here, but I've found a crash that's easy to
reproduce. First, open two X11 enabled vim (not gvim) processes. In
the first, do:
:let @+ = repeat('a', 1024*1024)
in order to store 1MB of data to the clipboard. The exact amount is
irrelevant, but the larger the size, the more often it will lead to a
segfault.
Then, in the second vim instance, repeatedly do :reg + and see what
gets displayed. Depending upon the amount of data that you put on the
clipboard, as well as upon some other factor I'm not seeing, this will
either a) show a bunch of a's in register +, b) not show any
registers, as though register + didn't exist, or c) cause the vim in
which you copied to segfault, and the vim in which you're trying to
display the register to enter a tight loop wasting a lot of CPU and
only dying for kill -9. Just try the command 5 or so times and you
should see a segfault - as well as the missing-register behavior. If
you don't get the segfault at all, try upping the amount of data
stored to the clipboard. If you get the segfault, but not the
missing-register behavior, try lowering the amount of data stored to
the clipboard. And if you can't reproduce either, that might help to
pin down what exactly causes this.
I can reproduce this on both a vim linked with the GTK2-Gnome gui, and
one linked with the X11-Motif gui, so it doesn't seem to be something
gnome-specific, either. This is vim 7.2.
Let me know if we need more details.
~Matt
It does not seem easy to debug. I think there might
be 2 distinct issues.
1/ The first thing I notice and which seems to be 100% reproducible
on my machine):
In #1 instance of vim: :let @+ = repeat('a', 262033)
In #2 instance of vim::reg+(works fine all the time)
In #1 instance of vim: :let @+ = repeat('b', 262034)
In #2 instance of vim::reg+(fails all the time, it shows empty content)
clip_x11_request_selection_cb() fails in #2 instance of vim
because parameter value is NULL and parameter *length is null.
Somehow it happens when number of characters in clipboard
is = 262034 (close to 256K).
I change the letter ('a' - 'b') in the clipboard every time to make
sure :reg + does not show an old value of the clipboard (which
I have observed sometimes, see below)
2/ The second thing I notice, if I put far more characters in the
clipboard (say 100) then if fails differently:
In #1 instance of vim: :let @+ = repeat('c', 1000*1000)
In #2 instance of vim::reg+(fails, it shows some incorrect
content, something which I happened copy earlier 3?!)
So with such a big clipboard content, it fails differently:
In instance #2 of vim, function clip_x11_request_selection()
retries 5 times until it falls back to calling clip_yank_selection(),
but somehow that does not work either.
If both instances are gvim rather than vim, then I do not see
any problem.
I have not been able to come up with a fix yet.
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: ANNC: Relative Numbering plugin
On Mon, Aug 18, 2008 at 10:15 PM, Charles Campbell wrote: Hello! I've issued a new plugin on my website: http://mysite.verizon.net/astronaut/vim/index.html#RLTVNMBR . It uses the signs capability of huge vim to give relative numbering. After some comment period I expect to release it on vim.sf.net. I'd like to mention the relative numbering patch in my document -- would someone please tell me where that patch is again? And, as you may notice, I think I've now got a way to respond again to messages on the mailing list. Thank you, Chip Campbell That's quite nice! Thanks Chip. I noticed that the relative line numbering does not appear when resizing my terminal, until I move the cursor. Attached patch fixes it (not sure if it's the best way to fix it): $ diff -d -c RltvNmbr.vim.orig RltvNmbr.vim *** RltvNmbr.vim.orig 2008-08-19 02:50:00.0 +0200 --- RltvNmbr.vim2008-08-19 02:48:15.0 +0200 *** *** 135,140 --- 135,141 augroup RltvNmbrAutoCmd au! au CursorMoved * call SIDRltvNmbr(2) + au VimResized * call SIDRltvNmbr(1) au ColorScheme * call SIDColorschemeLoaded() augroup END --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
[patch] spelling mistakes not highlighted in all doxygen comments
Hi
I noticed that Vim's spelling checker highlight spelling mistakes
in some parts of doxygen comments, but not everywhere.
The following screenshot illustrates the problem (notice that
not all spelling mistakes are highlighted):
http://dominique.pelle.free.fr/doxygen-spelling.png
Attached patch fixes it.
-- Dominique
PS: to highlight spelling mistakes in doxygen comments,
you need the following settings:
syntax on
filetype on
filetype plugin on
set spell
let g:load_doxygen_syntax=1
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: doxygen.vim
===
RCS file: /cvsroot/vim/vim7/runtime/syntax/doxygen.vim,v
retrieving revision 1.5
diff -c -r1.5 doxygen.vim
*** doxygen.vim 5 May 2007 18:02:45 - 1.5
--- doxygen.vim 19 Jul 2008 06:53:39 -
***
*** 30,36
also be set to any highlight attribute. Alternatively, a highlight for doxygenCodeWord
can be used to override it.
! By default, highlighting is done assumng you have the JAVADOC_AUTOBRIEF
setting turned on in your Doxygen configuration. If you don't, you
can set the variable g:doxygen_javadoc_autobrief to 0 to have the
highlighting more accurately reflect the way Doxygen will interpret your
--- 30,36
also be set to any highlight attribute. Alternatively, a highlight for doxygenCodeWord
can be used to override it.
! By default, highlighting is done assuming you have the JAVADOC_AUTOBRIEF
setting turned on in your Doxygen configuration. If you don't, you
can set the variable g:doxygen_javadoc_autobrief to 0 to have the
highlighting more accurately reflect the way Doxygen will interpret your
***
*** 57,65
C/C++ Style line comments
syn region doxygenComment start=+/\*\(\*/\)[EMAIL PROTECTED] end=+\*/+ contains=doxygenSyncStart,doxygenStart,doxygenTODO keepend fold
! syn region doxygenCommentL start=+//[/!][EMAIL PROTECTED] end=+$+ contains=doxygenStartL keepend skipwhite skipnl nextgroup=doxygenComment2 fold
! syn region doxygenCommentL start=+//[/!]+me=e-2 end=+$+ contains=doxygenStartL keepend skipwhite skipnl fold
! syn region doxygenCommentL start=+//@\ze[{}]+ end=+$+ contains=doxygenGroupDefine,doxygenGroupDefineSpecial fold
Single line brief followed by multiline comment.
syn region doxygenComment2 start=+/\*\(\*/\)[EMAIL PROTECTED] end=+\*/+ contained contains=doxygenSyncStart2,doxygenStart2,doxygenTODO keepend fold
--- 57,65
C/C++ Style line comments
syn region doxygenComment start=+/\*\(\*/\)[EMAIL PROTECTED] end=+\*/+ contains=doxygenSyncStart,doxygenStart,doxygenTODO keepend fold
! syn region doxygenCommentL start=+//[/!][EMAIL PROTECTED] end=+$+ contains=doxygenStartL,@Spell keepend skipwhite skipnl nextgroup=doxygenComment2 fold
! syn region doxygenCommentL start=+//[/!]+me=e-2 end=+$+ contains=doxygenStartL,@Spell keepend skipwhite skipnl fold
! syn region doxygenCommentL start=+//@\ze[{}]+ end=+$+ contains=doxygenGroupDefine,doxygenGroupDefineSpecial,@Spell fold
Single line brief followed by multiline comment.
syn region doxygenComment2 start=+/\*\(\*/\)[EMAIL PROTECTED] end=+\*/+ contained contains=doxygenSyncStart2,doxygenStart2,doxygenTODO keepend fold
***
*** 98,104
This helps with sync-ing as for some reason, syncing behaves differently to a normal region, and the start pattern does not get matched.
syn match doxygenSyncStart +\ze[^*/]+ contained nextgroup=doxygenBrief,doxygenPrev,doxygenStartSpecial,doxygenFindBriefSpecial,doxygenStartSkip,doxygenPage skipwhite skipnl
! syn region doxygenBriefLine contained start=+\\k+ end=+\(\n\s*\*\=\s*\([EMAIL PROTECTED]([npcbea]\\|em\\|ref\\|link\\|f\$\|[$\\#]\)[EMAIL PROTECTED])\|\s*$\)[EMAIL PROTECTED] contains=doxygenContinueComment,doxygenFindBriefSpecial,doxygenSmallSpecial,@doxygenHtmlGroup,doxygenTODO,doxygenHyperLink,doxygenHashLink skipwhite keepend
Match a '' for applying a comment to the previous element.
syn match doxygenPrev ++ contained nextgroup=doxygenBrief,doxygenBody,doxygenSpecial,doxygenStartSkip skipwhite
--- 98,104
This helps with sync-ing as for some reason, syncing behaves differently to a normal region, and the start pattern does not get matched.
syn match doxygenSyncStart +\ze[^*/]+ contained nextgroup=doxygenBrief,doxygenPrev,doxygenStartSpecial,doxygenFindBriefSpecial,doxygenStartSkip,doxygenPage skipwhite skipnl
! syn region doxygenBriefLine contained start=+\\k+ end=+\(\n\s*\*\=\s*\([EMAIL PROTECTED]([npcbea]\\|em\\|ref\\|link\\|f\$\|[$\\#]\)[EMAIL PROTECTED])\|\s*$\)[EMAIL PROTECTED]
Re: Bug: Compilation error in Vim 7.2b.001
On Mon, Jul 14, 2008 at 9:48 PM, Bram Moolenaar wrote: Kana Natsuno wrote: I noticed that Vim 7.2b.001 still cannot be compiled with with multi-byte feature but without GUI or clipboard, because check_col() and check_row() are missing. The following is a patch to fix this problem: Darn, I thought my test covered most combinations of features. Apparently building with +multi_byte but without +rightleft was missing. I'll add it to my regular tests. Thanks for the patch. But to avoid including the functions when not needed FEAT_MBYTE should be added to the list, instead of deleting the #if completely. Are all combinations of configure options supposed to build? After trying some combinations, I see that Vim-7.2.b4 BETA fails to build with... $ ./configure --with-features=tiny --enable-perlinterp $ make ... objects/if_perl.o: In function `XS_VIM_Windows': /home/pel/sb/vim7/src/if_perl.xs:1002: undefined reference to `win_count' /home/pel/sb/vim7/src/if_perl.xs:1014: undefined reference to `win_find_nr' objects/if_perl.o: In function `XS_VIWIN_DESTROY': /home/pel/sb/vim7/src/if_perl.xs:1027: undefined reference to `win_valid' objects/if_perl.o: In function `XS_VIWIN_Buffer': /home/pel/sb/vim7/src/if_perl.xs:1035: undefined reference to `win_valid' objects/if_perl.o: In function `XS_VIWIN_SetHeight': /home/pel/sb/vim7/src/if_perl.xs:1050: undefined reference to `win_valid' objects/if_perl.o: In function `XS_VIWIN_Cursor': /home/pel/sb/vim7/src/if_perl.xs:1065: undefined reference to `win_valid' /home/pel/sb/vim7/src/if_perl.xs:1074: undefined reference to `win_valid' collect2: ld returned 1 exit status Is it worth fixing? Does anybody care about building Vim with such odd combination of features (tiny + perl)? -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
[patch] fixed access beyond end of string in tag.c
Hi, Valgrind memory checker finds the following bug in
Vim-7.2.b.4 BETA. It's not a new issue, since it
also happens at least in Vim-7.1.214 for example:
==17908== Conditional jump or move depends on uninitialised value(s)
==17908==at 0x578E51: get_tags (tag.c:3823)
==17908==by 0x4467DB: f_taglist (eval.c:16953)
==17908==by 0x43A0C7: call_func (eval.c:8023)
==17908==by 0x439BE8: get_func_tv (eval.c:7841)
==17908==by 0x435C81: eval7 (eval.c:4979)
==17908==by 0x43555D: eval6 (eval.c:4646)
==17908==by 0x435153: eval5 (eval.c:4462)
==17908==by 0x4346D7: eval4 (eval.c:4157)
==17908==by 0x43453C: eval3 (eval.c:4069)
==17908==by 0x4343C4: eval2 (eval.c:3998)
==17908==by 0x434205: eval1 (eval.c:3923)
==17908==by 0x434172: eval0 (eval.c:3880)
==17908==by 0x43049E: ex_let (eval.c:1794)
==17908==by 0x46525D: do_one_cmd (ex_docmd.c:2621)
==17908==by 0x462A3D: do_cmdline (ex_docmd.c:1095)
I observe the bug when typing 'this-' with C++ code
with the omnicppcomplete.txt plugin (which triggers
tag search and displays the pum). I does not happen
with all C++ source codes, and I don't know what
triggers it yet, but I have a 100% reproducible case.
Looking at the code, the bug is quite clear:
tag.c:
3822 for (p = tp.command_end + 3;
! 3823 *p != NUL *p != '\n' *p != '\r'; ++p)
3824 {
3825 if (...)
snip
3832 else if (!vim_iswhite(*p))
3833 {
3834 char_u *s, *n;
3835 int len;
3836
3837 /* Add extra field as a dict entry. Fields are
3838 * separated by Tabs. */
3839 n = p;
! 3840 while (*p != NUL *p = ' ' *p 127 *p != ':')
3841 ++p;
3842 len = (int)(p - n);
3843 if (*p == ':' len 0)
3844 {
3845 s = ++p;
! 3846 while (*p != NUL *p = ' ')
3847 ++p;
3848 n[len] = NUL;
3849 if (add_tag_field(dict, (char *)n, s, p) == FAIL)
3850 ret = FAIL;
3851 n[len] = ':';
3852 }
3853 else
3854 /* Skip field without colon. */
! 3855 while (*p != NUL *p = ' ')
3856 ++p;
3857 }
3858 }
The bug happens if 'while' loop at lines 3840 (or at line 3846 or
line 3855) ends when reaching end of string (*p == NUL). In that case,
'for' loop at line 3823 will:
- first do '++p' which will go one character beyond end of string, since
p was already at end of string)
- and then it will check condition '*p != NUL', hence accessing beyond
end of string, where memory not initialized.
After that, loop may continue to access several other characters
beyond end of string (depending on bytes values beyond EOS).
The attach patch fixes it.
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Index: tag.c
===
RCS file: /cvsroot/vim/vim7/src/tag.c,v
retrieving revision 1.43
diff -c -r1.43 tag.c
*** tag.c 13 Jul 2008 17:25:59 - 1.43
--- tag.c 15 Jul 2008 19:01:06 -
***
*** 3854,3859
--- 3854,3861
/* Skip field without colon. */
while (*p != NUL *p = ' ')
++p;
+ if (*p == NUL)
+ break;
}
}
}
Re: Vim version 7.2b ready for BETA testing
On Sun, Jul 13, 2008 at 8:16 PM, Bram Moolenaar wrote: Please report every problem you find! The time until a 7.2 release depends on how many problems are reported. Vim-7.2b.2 BETA builds and works flawlessly for me so far on Linux x86. I only noticed 2 typos in :help version-7.2. See attached patch. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- Index: version7.txt === RCS file: /cvsroot/vim/vim7/runtime/doc/version7.txt,v retrieving revision 1.218 diff -c -r1.218 version7.txt *** version7.txt 13 Jul 2008 17:38:57 - 1.218 --- version7.txt 14 Jul 2008 19:00:30 - *** *** 6847,6853 Solution: Don't use UTF_COMPOSINGLIKE() on an illegal byte. In msg_outtrans_len_attr() use char2cells() instead of ptr2cells(). In utf_ptr2char() don't check second byte when first byte is ! illega. (Dominique Pelle) Files: src/mbyte.c, src/message.c Patch 7.2a.011 --- 6847,6853 Solution: Don't use UTF_COMPOSINGLIKE() on an illegal byte. In msg_outtrans_len_attr() use char2cells() instead of ptr2cells(). In utf_ptr2char() don't check second byte when first byte is ! illegal. (Dominique Pelle) Files: src/mbyte.c, src/message.c Patch 7.2a.011 *** *** 6916,6922 STRMOVE() instead. (Ralf Wildenhues) Mac: On Leopard gvim, when using the mouse wheel nothing would happen until ! another event occures, such as moving the mouse. Then the recorded scrolling would take place all at once. (Eckehard Berns) Solution for cursor color not reflecting IM status for GTK 2. Add --- 6916,6922 STRMOVE() instead. (Ralf Wildenhues) Mac: On Leopard gvim, when using the mouse wheel nothing would happen until ! another event occurs, such as moving the mouse. Then the recorded scrolling would take place all at once. (Eckehard Berns) Solution for cursor color not reflecting IM status for GTK 2. Add
Re: (bug) omni completion popup not redrawn at correct location when using set nowrap
On Tue, Jul 8, 2008 at 9:32 PM, Dominique Pelle wrote: Hi, I observe a bug in the omni completion popup menu when doing omni completion at the end of a line which is longer than the terminal width and with set nowrap. The menu is not drawn at the correct location when pressing Down when trying to select an item in the popup menu. Bug happens in both Vim and gvim version 7.2a.19 BETA. Steps to reproduce: 1/ Install OmniCppComplete script located at: http://www.vim.org/scripts/script.php?script_id=1520 2/ Download the c++ sample source file bug-omni.cpp: $ wget http://dominique.pelle.free.fr/bug-omni.cpp 3/ Build a tag file with: $ ctags --language-force=c++ --c++-kinds=+p \ --fields=+iaS --extra=+f+q bug-omni.cpp 4/ Create a minimalistic simple_vimrc file: $ cat simple_vimrc filetype plugin on set nocompatible set columns=80 set nowrap set tags=tags 5/ Start vim with: $ vim -u simple.vimrc bug-omni.cpp 6/ Append s- at the end of line 10 (the line with a long comment). In Normal mode: 10GAs- After pressing - the omni menu should popup up (at correct location). 7/ Press Down to browse though items in menu and observe that menu is then re-drawn at incorrect location, at bottom of screen, corrupting the content of the screen) as shown in the following screen shot: http://dominique.pelle.free.fr/bug-omni.png I can try to debug it when I have time during the weekend but perhaps someone can reproduce it and fix it before that. -- Dominique The attached patch fixes the bug with the pum misplaced when doing omni completion on long lines with set nowrap. I remind that not only the pum was misplaced, but it could also cause a memory corruption with crash, which I observed when the pum had many entries. The problem was probably old: at least vim-7.1.138 and vim-7.2a.19 are affected. The problem was that depending on where curwin-w_wcol was set, its value was different. Functions validate_cursor_col() and curs_columns() set curwin-w_wcol differently: function curs_columns() removes curwin-w_leftcol while function validate_cursor_col() did not. When entering pum_display(), validate_virtcol() is called. If (curwin-w_valid VALID_WCOL) was false, then pum was displayed correctly, if (curwin-w_valid VALID_WCOL) was true, then curwin-w_wcol was not recalculted (which is OK) but if its value came from curs_column(), then it was inconsistent with the value which would have been set in validate_cursor_col(). I changed the code so that validate_cursor_col() now returns something consistent with curs_columns(). The pum is now placed correctly. I've tested with set wrap and set nowrap, set rightleft with scrolling horizonally (zl zh) and the pum was always currectly placed after patch. make test also passes all tests. What puzzles me a bit, is that the problem seemed to be known since function validate_cursor_col() has the following comment: Only correct when 'wrap' on! Please review the patch and test even further. -- Dominique --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- Index: popupmnu.c === RCS file: /cvsroot/vim/vim7/src/popupmnu.c,v retrieving revision 1.11 diff -c -r1.11 popupmnu.c *** popupmnu.c 24 Jun 2008 22:00:40 - 1.11 --- popupmnu.c 12 Jul 2008 14:02:20 - *** *** 183,193 /* Calculate column */ #ifdef FEAT_RIGHTLEFT if (curwin-w_p_rl) ! col = W_WINCOL(curwin) + W_WIDTH(curwin) - curwin-w_wcol - ! curwin-w_leftcol - 1; else #endif ! col = W_WINCOL(curwin) + curwin-w_wcol - curwin-w_leftcol; /* if there are more items than room we need a scrollbar */ if (pum_height size) --- 183,192 /* Calculate column */ #ifdef FEAT_RIGHTLEFT if (curwin-w_p_rl) ! col = W_WINCOL(curwin) + W_WIDTH(curwin) - curwin-w_wcol - 1; else #endif ! col = W_WINCOL(curwin) + curwin-w_wcol; /* if there are more items than room we need a scrollbar */ if (pum_height size) Index: move.c === RCS file: /cvsroot/vim/vim7/src/move.c,v retrieving revision 1.10 diff -c -r1.10 move.c *** move.c 5 May 2007 17:35:47 - 1.10 --- move.c 12 Jul 2008 14:02:21 - *** *** 876,882 } /* ! * validate w_wcol and w_virtcol only. Only correct when 'wrap' on! */ void validate_cursor_col() --- 876,882 } /* ! * validate w_wcol and w_virtcol only. */ void validate_cursor_col() *** *** 899,904 --- 899,907 col = col % (W_WIDTH(curwin) - off + curwin_col_off2()); } curwin-w_wcol = col; + if (curwin-w_wcol (int)curwin-w_leftcol) + curwin
Re: (bug) omni completion popup not redrawn at correct location when using set nowrap
On Tue, Jul 8, 2008 at 9:32 PM, Dominique Pelle wrote:
Hi,
I observe a bug in the omni completion popup menu when doing omni
completion at the end of a line which is longer than the terminal
width and with set nowrap. The menu is not drawn at the correct
location when pressing Down when trying to select an item in the
popup menu.
Bug happens in both Vim and gvim version 7.2a.19 BETA.
Steps to reproduce:
1/ Install OmniCppComplete script located at:
http://www.vim.org/scripts/script.php?script_id=1520
2/ Download the c++ sample source file bug-omni.cpp:
$ wget http://dominique.pelle.free.fr/bug-omni.cpp
3/ Build a tag file with:
$ ctags --language-force=c++ --c++-kinds=+p \
--fields=+iaS --extra=+f+q bug-omni.cpp
4/ Create a minimalistic simple_vimrc file:
$ cat simple_vimrc
filetype plugin on
set nocompatible
set columns=80
set nowrap
set tags=tags
5/ Start vim with:
$ vim -u simple.vimrc bug-omni.cpp
6/ Append s- at the end of line 10 (the line with a long comment).
In Normal mode:
10GAs-
After pressing - the omni menu should popup up (at correct location).
7/ Press Down to browse though items in menu and observe that menu is
then re-drawn at incorrect location, at bottom of screen, corrupting
the content of the screen) as shown in the following screen shot:
http://dominique.pelle.free.fr/bug-omni.png
I can try to debug it when I have time during the weekend but perhaps
someone can reproduce it and fix it before that.
-- Dominique
I investigated this bug a bit, but it's does not look simple.
I have a workaround though.
First of all, the pum is not only displayed at the wrong place,
but depending on the window size and length of the line,
bug can actually cause crash (seg fault).
The following change makes it work (but it's only a workaround):
===
RCS file: /cvsroot/vim/vim7/src/move.c,v
retrieving revision 1.10
diff -c -r1.10 move.c
*** move.c 5 May 2007 17:35:47 - 1.10
--- move.c 9 Jul 2008 19:39:10 -
***
*** 885,891
colnr_T col;
validate_virtcol();
! if (!(curwin-w_valid VALID_WCOL))
{
col = curwin-w_virtcol;
off = curwin_col_off();
--- 885,891
colnr_T col;
validate_virtcol();
! /*if (!(curwin-w_valid VALID_WCOL))*/
{
col = curwin-w_virtcol;
off = curwin_col_off();
It looks like curwin-w_valid is marked as valid, when it's not
valid. So the above changes forces to recompute curwin-w_wcol
regardless of the valid status. It's not the right way to fix it (it
might slow down vim) but it may help to debug further.
I came up with this because the value of curwin-w_wcol are
different in popupmnu.c:73 the first time pum_display() is called
(i.e. when pum is at correct place on screen) and the second
time it's called when selecting element in pum (and when pum
is no longer at correct place, corrupting the screen):
- The first time, curwin-w_wcol is marked invalid,
so validate_cursor_col() call at popupmnu.c calculates it
correctly.
- The second time pum_display() is called, curwin-w_wcol
is already marked as valid so call to validate_cursor_col() does
not recalculate it (but the value looks actually incorrect somehow,
hence pum displayed at wrong location). Forcing to recalculate
it works around the bug.
Interestingly, the comment of the function validate_cursor_col()
where I put the workaround says...
move.c:
878 /*
879 * validate w_wcol and w_virtcol only. Only correct when 'wrap' on!
880 */
881 void
882 validate_cursor_col()
883 {
Ah! This bug happens precisely when 'wrap' is off. The piece of
code is complex and I don't understand everything yet, but hopefully
the workaround can help to come up with a proper fix.
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
