Fwd: WIN32: Loading iof conv causes stack overflow

69 views
Skip to first unread message

Jiri Sedlak

unread,
Sep 12, 2012, 4:39:53 PM9/12/12
to vim...@vim.org
Hello,

I discovered stack overflow in WIN32 builds of VIm. Repeatability is 100%

Here is scenario:

1) start vim
2) set enc option to for example iso-8859-2.
3) vim crash


Attached os_win32.c.diff patch contains patch that fixes previously
mentioned stack overflow .This is caused by loading of iconv library.
Loading mechanism calls functions that utilises encoding conversion,
and these functions load iconv library again, because it is not loaded
yet.

Attached Make_mvc.mak.diff contains patch file that adds version of
nmake that is distributed with Visual studio 6 service pack 6.




Regards

Jiri Sedlak
os_win32.c.diff
Make_mvc.mak.diff

Ben Fritz

unread,
Sep 12, 2012, 5:53:46 PM9/12/12
to vim...@googlegroups.com, vim...@vim.org, jiri_...@users.sourceforge.net
On Wednesday, September 12, 2012 4:03:46 PM UTC-5, Jiri Sedlak wrote:
> Hello,
>
>
>
> I discovered stack overflow in WIN32 builds of VIm. Repeatability is 100%
>
>
>
> Here is scenario:
>
>
>
> 1) start vim
>
> 2) set enc option to for example iso-8859-2.
>
> 3) vim crash
>

Reproduced in 7.3.646, which I was doubtful of, because my .vimrc contains "set encoding=utf-8" and I've never seen a crash because of it. In the past I've also set the encoding to cp1252 and others without problems.

But setting it to iso-8859-2 causes Vim to terminate with no warning or dialog popping up on the very next keystroke (which in my case happened to be ':', because I was attempting to type ":set enc?").

I haven't tried the patch.

Jiri Sedlak

unread,
Sep 13, 2012, 2:05:14 AM9/13/12
to vim...@googlegroups.com
Hello,

Codepages are not re-coded by iconv but by MultiByteToWideChar
function. So if you set cp... the iconv library is not loaded.
SO was introduced in VIm7.3.034 so it is realy long time ago. But I
needed open file in iso-8859-2 coding on Monday, so I came across it.



Regards

JiriS
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php

ZyX

unread,
Sep 13, 2012, 10:51:24 AM9/13/12
to vim...@googlegroups.com, jiri_...@users.sourceforge.net
четверг, 13 сентября 2012 г., 10:05:16 UTC+4 пользователь Jiri Sedlak написал:
> Hello,
>
> Codepages are not re-coded by iconv but by MultiByteToWideChar
> function. So if you set cp... the iconv library is not loaded.
> SO was introduced in VIm7.3.034 so it is realy long time ago. But I
> needed open file in iso-8859-2 coding on Monday, so I came across it.

You must not be using this option for opening files with particular encoding, you corrupt any existing non-ASCII string already loaded in memory that way. There are enough pointers to a correct way of opening a file in “:h 'encoding'”.

Ben Fritz

unread,
Sep 13, 2012, 10:54:02 AM9/13/12
to vim...@googlegroups.com, jiri_...@users.sourceforge.net
Regardless, Vim should not crash. When I reproduced it, the "set encoding" command was the first thing done in a configuration-less Vim.

As for opening files "the right way", also see http://vim.wikia.com/wiki/Working_with_Unicode

Ben Fritz

unread,
Sep 13, 2012, 10:55:45 AM9/13/12
to vim...@googlegroups.com, jiri_...@users.sourceforge.net

Yukihiro Nakadaira

unread,
Sep 15, 2012, 7:12:29 PM9/15/12
to vim...@googlegroups.com
This patch doesn't work for unicode path.

> gvim -u NONE
:set enc=utf-8
:call mkdir("\u1234") " Create directory with unicode character
:cd <U+1234> " which is not contained current codepage.
:pwd
C:\Users\yukihiro\tmp\<U+1234>
:call libcall('a.dll', 'b', 'c') " No need existing dll for this test.
E364: Library call failed for "b()"
:pwd
C:\Users\yukihiro\tmp\vim\src " Directory is changed.


--
Yukihiro Nakadaira - yukihiro....@gmail.com

Ken Takata

unread,
Sep 15, 2012, 9:50:33 PM9/15/12
to vim...@googlegroups.com
Hi,

2012/09/16 Sun 8:12:34 UTC+9 Yukihiro Nakadaira:


> This patch doesn't work for unicode path.

I wrote a patch for that.

Additionally I found a mistake in a comment of os_win32.h.
_MAX_PATH is defined as 260 (not 256) on Windows.

Regards,
Ken Takata

os_win32.c.patch
os_win32.h.patch

Yukihiro Nakadaira

unread,
Sep 16, 2012, 4:30:57 AM9/16/12
to vim...@googlegroups.com
On Sun, Sep 16, 2012 at 10:50 AM, Ken Takata <ken...@csc.jp> wrote:
> 2012/09/16 Sun 8:12:34 UTC+9 Yukihiro Nakadaira:
>> This patch doesn't work for unicode path.
>
> I wrote a patch for that.

It works. Thank you.
Reply all
Reply to author
Forward
0 new messages