40029Re: Continuing problem with spell under WinXP
- Jun 30, 2005Dave Roberts wrote:
> A. J. Mechelynck wrote:The fact that non-debug builds fail and that debug builds don't, hints
>> Dave Roberts wrote:
>>> Hello all,
>>> I've been unable to use the spell feature of VIM7 for several builds
>>> now. When I run:
>>> gvim -u NONE -U NONE test.txt
>>> :setl spell spelllang=en
>>> on a file that has more than one line in it, Windows informs me that "Vi
>>> Improved - A Text Editor has encountered a problem and needs to close."
>> In other words, Windows has intercepted a hard crash. Rather than send
>> an incident report to Microsoft (who couldn't do anything with it
>> anyway), you can, when the crash happens, look at the report. Alas, the
>> text is often full of hex and not very human-readable; and IIRC it
>> cannot be copied to the clipboard.
>>> The build from CVS sources on 6/22 worked. The builds from CVS sources
>>> on 6/25, 6/29, and this morning all fail the above way.
>>> :version from this morning's build give: [...]
>> Attempting it with a debug build of gvim (i.e., gvimd.exe) might help
>> track down the error by providing some more human-readable info, even in
>> the crash report. If you don't have a debug build, you can either use
>> mine (compiled from a .zip snapshot of the sources, see
>> http://users.skynet.be/antoine.mechelynck/vim/#vim7 ), or compile your
>> own (usually with DEBUG=yes in the make command line).
>> Best regards,
> And, of course, when I compile using:
> nmake -f Make_mvc.mak GUI=yes DEBUG=yes
> then .\gvimd.exe works fine.
> I run vim/gvim from c:\pkg\vim and for each new version I rename the old
> directory to something like c:\pkg\vim.worked2 or c:\pkg\vim.failed1 and
> create a new c:\pkg\vim where I copy all the .EXE, .VIM, .TXT, .SPL, and
> TAGS files to. Since c:\pkg\vim is on the path I get the new one when I
> run vim/gvim from anywhere.
> When I copy all the files from todays build and run GVIM.EXE (built
> exactly as the above but without 'DEBUG=yes' - and I *always* do a CLEAN
> first) it fails. If I copy GVIMD.EXE to GVIM.EXE in that directory it
> works fine.
> BTW, vim.exe (not compiled for debug) also causes the Windows error and
> quites on that command.
> I'm going to continue to use that version for the rest of the day to see
> if anything happens (although I'm programming today so won't be using
> the spell feature).
> Any ideas on another way to debug this?
> - Dave
at a compiler code optimization problem (or possibly, but IMHO less
probably, a stack overflow problem caught by stack-checking code absent
from non-debug builds).
I don't know for sure how to debug this. Here are a few hints:
* Modify your makefile to reduce the optimization level on non-debug builds.
* Try compiling with a different compiler. (My builds are compiled with
cygwin gcc, with -mno-cygwin which IIUC uses a cygwin version of the
MinGW compiler in order to avoid runtime dependency on the Cygwin DLL.
You can see on my site which command-line options are used to compile
and link my 6.3 builds; AFAIK the optimization options are the same in
* Use gvimd or vimd -- you don't need to rename them; you can call them
as gvimd or vimd from the command-line. This means that you can let all
four builds (vim, vimd, gvim, gvimd) reside in the same directory in the
Or you might try to enlist Bram's (or somebody's) help now already,
telling them "When compiling Vim 7 with the makefile named <filename>
from the distribution and the compiler <name> <version>, I get a crash
with non-debug builds but not with debug builds when doing this-and-that".
- << Previous post in topic