Mail Archives: djgpp-workers/1998/06/04/16:42:40
* No solutions or ideas just a case *
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
> Some of you might have read the thread about Bash hanging on Windows 95
> after the first time it runs a DJGPP program in an interactive session.
> One of the users who reported this was able to trace it to the call to
> __dpmi_yield which apparently doesn't return.
>
> I couldn't reproduce this on the machines I usually work on. Now I found
> a machine where this happens as well, so I'm asking you to help solving
> it, if you can take a couple of moments to reflect on this.
>
> Here's what I know: any DJGPP program that runs another DJGPP program, and
> after the child returns issues a call to __dpmi_yield, will hang on the
> machines which are affected by this. I saw the same behavior with Bash,
> Emacs, Less, and the latest port of Info.
>
> When they hang, only Ctrl-Alt-Del can help you. Even Ctrl-BREAK has
> no effect. Bash is different in this last respect: Ctrl-BREAK aborts it,
> but the traceback shows DS=0 and SS that's invalid, and the DOS box is
> hung after Bash aborts anyway. I suppose Bash is different because it
> pulls DPMI-specific tricks when running programs, to work around bugs in
> Windows.
>
> It doesn't matter how do you run the subsidiary program: via `spawn', via
> `system', or even shell to COMMAND.COM and run it from the command line
> (the parent hangs when you type EXIT). Non-DJGPP programs can be run
> with no visible problems.
Wow! so I'm not crazy after all ;-). I was experimenting it with my editor and
the last RHIDE in one of the machines at work. It start happening from one day
to another (at least I have this impression I could be wrong).
I saw it while using my editor and calling grep or compiling from the last
version of the IDE. It doesn't happend with RHIDE 1.4 and 1.4.1. The behavior
is like this:
1) The program runs 100%
2) If you call another djgpp program (using system or making a shell) the
calling program dies just a fraction of second after repainting the screen.
I was wondering what a hell changed in TVision (I was wrong) from RHIDE 1.4 to
RHIDE 1.4.5. And now after it I found the answer: I added a call to
__dpmi_yield() in the idle loop of my editor and tell to Robert to do the same.
Now checking the programs I can see that RHIDE 1.4/1.4.1.2 eats 100% of the CPU
(according to W95, it isn't true, but the meassure program says it) but RHIDE
1.4.5 or my editor consumes 0%.
The programs just hang in the first call to the idle loop after repainting so
it looks like the problem is the same Eli describes.
I can reproduce it in this machine but not in other with the same windows
version (installed from the same CD!).
> I have no idea why some systems are afflicted by this while others (most
> of them, actually) aren't.
Yes is VERY strange because isn't the OS version.
> It seems like some snafu with nested DPMI programs, probably a bug in
> Windows 95's DPMI, but that doesn't help you if you have such a system.
I can reproduce it with the following program:
#include <dpmi.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
printf("Hello!!\n");
system("command.com");
printf("Now I call it\n");
__dpmi_yield();
printf("All ok\n");
return 0;
}
If I call a djgpp program during the shell I never see the "All ok" message.
The program hangs and eats 100% of the CPU, looks like a very small infinite
loop (could be any other thing too ;-).
So Eli don't worry if you have access for only one week, I can run any
experiment here ;-))
SET
------------------------------------ 0 --------------------------------
Visit my home page: http://set-soft.home.ml.org/
or
http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org
ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013
- Raw text -