Mail Archives: djgpp-workers/1999/06/19/13:48:36
On Sat, 19 Jun 1999, Erik Berglund wrote:
>
> Andris Pavenis wrote:
>
> > As I said there seems to be some memory (corruption???) related problem.
> > I think it would be best to try to reproduce it in some test example
> > rather than studying interior of gcc.
>
> Hi Andris,
>
> Yesterday, I ran the supplied test program, but the error didn't show up.
> First, I ported the program from C++ to C, because my knowledge
> of C++ is minimal. The C-program uses malloc() and free(), hope this is ok.
There is one big problem for me to reproduce these crashes:
I don't have Win311 installed anywhere near me on a machine I
would be able to use for test
>
> In my humble opinion, it would be easiest to reproduce and track down
> the error, if we modify gcc-2.95 to catch any DPMI-errors and such.
> My idea is to try to catch the first error or anomaly when it happens,
> before the crash occurs.
I'm not sure that will help. If DPMI server is buggy than the problems
may not appear in return code from DPMI API calls. For example when I
tried to look with FSDB what happens in local descriptor table when a
program is freeing descriptor under Win95 it looked like descriptor
freeing is really broken. Perhaps that is reason why there is known
leak of descriptors when running long makes under Win95. Maybe something
more is broken in Win311 DPMI server.
One more thing my test example didn't test is running nested DPMI cleants
under Win311 (gcc is such, gcc.exe spawns ccp.exe, compiler itself, etc.,
also make and rhide is such).
> I read the source code to crt0.s (961006) from DJGPP 2.01
> (GCC 2.7.2.1), and produced the table below.
> In most cases, the CF-flag is not checked after a DPMI-call.
>
> Maybe the CF-flag should be checked after each DPMI-call, just to
> verify that Windows 3.11 DPMI really accepts each DPMI-request.
> There is a possibility that Windows for some odd reason, and
> in some rare cases, could reject a seemingly correct DPMI-request.
>
> Would it be possible for you to change crt0.s in this respect,
> and to build a new gcc-2.95, which I can download and test?
> All that is needed is a "jump if carry" to a little endless loop,
> on all CF-not-checked-places, then we would know for sure,
> that we had an unexpected DPMI error.
> Or, an error message could be printed, if that's possible.
>
> Here goes the CF-check table:
>
> line 90: int 31h, ax=0507h, CF not checked (not needed anyway)
> line 96: int 31h, ax=000ah, CF checked
> line 108: int 31h, ax=0009h, CF not checked
> line 116: int 31h, ax=0008h, CF not checked
> line 119: int 31h, ax=0008h, CF not checked
> line 122: int 31h, ax=0008h, CF not checked
> line 137: int 31h, ax=0100h, CF checked
> line 162: int 31h, ax=000bh, CF not checked
> line 170: int 31h, ax=0000h, CF not checked
> line 176: int 31h, ax=000ch, CF not checked
> line 188: int 31h, ax=0006h, CF not checked
> line 241: int 31h, ax=0000h, CF checked
> line 248: int 31h, ax=0008h, CF not checked
> line 292: int 31h, ax=0001h, CF not checked
> line 293: int 31h, ax=0001h, CF not checked
> line 298: int 31h, ax=0001h, CF not checked
> line 301: int 31h, ax=0101h, CF not checked
> line 328: int 31h, ax=0502h, CF not checked
> line 336: int 31h, ax=0001h, CF not checked
> line 360: int 31h, ax=0600h, CF not checked
> line 423: int 31h, ax=0900h, CF not checked (not needed, always 0)
> line 430: int 31h, ax=0900h, CF not checked (not needed, always 0)
> line 464: int 31h, ax=0501h, CF checked
> line 505: int 31h, ax=0008h, CF not checked
> line 511: int 31h, ax=0008h, CF not checked
> line 515: int 31h, ax=0008h, CF not checked
> line 521: int 31h, ax=0007h, CF not checked
>
- Raw text -