Mail Archives: djgpp/2002/01/27/01:46:46
Thanks for reply, I tried your suggestions and after some
experiments and about 15 reboots I found this strange behavior:
The crash of repeated "vim -c q" never occured when invoked via make, I
saw it only after running from bash. Strangely enough, if I call make,
grep or gawk (from bash, no arguments) before testing vim, the
crash would not occur. However, I would always get it if my test
script was the _first_ thing to run in bash.
I checked the source code of vim, indeed there are calls to int86()
and __dpmi_yield() in os_msdos.c. I tried to comment out the single
call to __dpmi_yield() and recompile, but it did not help.
I guess that leaves int86() as another option to check.
Eli Zaretskii (eliz AT is DOT elta DOT co DOT il) wrote:
> This rings a bell. Could you please try the following experiment:
> invoke vim from COMMAND.COM, but via Make, like this:
> c:\> make -f -
> all:
> vim -c q
> vim -c q
> vim -c q
> ^Z
> Every line after "all:" should begin with a TAB. The "^Z" at the end
> is the Ctrl-Z character: it ends the Makefile and starts the Make run.
> (It doesn't really matter what commands are in the `all:' rule, as
> long as they are similar to those which cause the system to freeze
> when you invoke vim from Bash. Also, I only put several identical
> lines in the above bacause you seemed to indicate that was a good way
> of reproducing the problem; if a single command is enough, please use
> just that single command.)
> The idea here is to see whether vim freezes when invoked from _any_
> DJGPP program, or just from Bash. You could also try other DJGPP
> programs which can invoke arbitrary programs, like Less or Info.
> If invocation from other DJGPP programs also cause the freezes, then
> the problem is likely to be the one described in section 6.1 of the
> DJGPP FAQ list: on some Windows systems, calling some functions of
> interrupt 2Fh has such a nasty effect, probably due to a bug in one of
> the Windows components. (The FAQ talks about function 1680h, but the
> problem is not limited to that function alone.) So you could ask the
> vim developers to check whether the DJGPP port either uses the library
> function __dpmi_yield, or invokes some other function of Int 2Fh via
> int86 (as opposed to __dpmi_int). If it does, this could be the
> cause of your problems.
- Raw text -