Mail Archives: djgpp-workers/2000/04/25/04:29:43
On Mon, 24 Apr 2000, Martin Str|mberg wrote:
Just a few comments, in the hope of giving some ideas for digging into
this.
> Totalt under 1 M 654 336 198 512 455 824
>
> Största exekverbara programstorlek: 455 312 (445K)
This is quite a small amount of free RAM; expect problems with deeply
nested invocations. (They shouldn't crash, but you could see "No DOS
memory" messages.)
> Testbed:
> DJDEV203.ZIP and trying compiling the src directory from DJLSR203.ZIP
> using COMMAND.COM.
The library build does use deep nesting.
> I've had several hangs and even a reboot. Alas I upgraded binutils and
> gcc as well so I wasn't sure it was a CWSDPMI problem.
You could repeat the run with CWSDOMI r4, can't you?
> But finally something very strange happened and I had still some
> prompt functionality and it seems (to me) to be something strange with
> CWSDPMI. Error message was "Swap disk full!", but "dir c:\" says
[snip]
> 47 855 616 byte lediga"
47MB might not be enough, since you have a memory-starved machine
which pages a lot in nested jobs. Can you free some more disk space?
> For the Swedish unknowledgable "47 855 616 byte lediga" means "47 855
> 616 bytes free". And note the CWSDPMI.SWP file is here, so it's using
> this disk for swapping.
The size of CWSDPMI.SWP might not be accurate, since you have just
crashed. Does CHKDSK report any problems on that drive?
Also, the "Swap disk full" message might have happened inside some
nested job, and when that job was aborted, CWSDPMI shrunk the swap
file due to the fact that some client(s) exited and freed their
memory. If that's true, you won't be able to see the real size of the
swap file when it filled the disk.
> KEYB 6 944 (7K) 6 944 (7K) 0 (0K)
> /djgpp/b 17 248 (17K) 17 248 (17K) 0 (0K)
> DOSKEY 4 144 (4K) 4 144 (4K) 0 (0K)
> TCPTSR 76 784 (75K) 76 784 (75K) 0 (0K)
> TINYRFC 18 288 (18K) 18 288 (18K) 0 (0K)
> NMTSR 6 160 (6K) 6 160 (6K) 0 (0K)
> BASIC 13 760 (13K) 13 760 (13K) 0 (0K)
> /djgpp/b 17 328 (17K) 17 328 (17K) 0 (0K)
> /djgpp/b 17 328 (17K) 17 328 (17K) 0 (0K)
> CWSDPMI 41 040 (40K) 41 040 (40K) 0 (0K)
> bin/gcc 17 328 (17K) 17 328 (17K) 0 (0K)
> /djgpp/l 17 760 (17K) 17 760 (17K) 0 (0K)
> Ledigt 327 792 (320K) 327 792 (320K) 0 (0K)
I'm guessing that the first 3 DJGPP programs are make.exe,
makemake.exe, and another make.exe, while the other two are gcc.exe
and either cpp.exe or cc1.exe. The 17KB they take up in conventional
RAM is the normal case (16KB of transfer buffer plus some
client-specific data).
In other words, I don't see anything strange in this MEM report,
except that I don't understand how did you get a DOS prompt in that
situation.
- Raw text -