Mail Archives: djgpp-workers/2002/05/19/16:34:55
> > I don't know of a way to debug the 16-bit PM code called from DJGPP.
>
> > My debugging of these things was typically done under OS/2 - which did
> > an excellent job of printing out everything if a failure happened.
> > Since I haven't had a working OS/2 system in about 7 or 8 years ...
>
> Oh, I guess I'll have to do debugging in printf() spirit (do not take
> 'printf()' literally...)
That code's ugly since you are missing any decent way to even get to
video memory.
> And one probably stupid question - why that code has to be 16 bit
> anyway?
It actually doesn't. It could be 32-bit, but it has to live in the
DOS memory region. So you still have to far call to it, swap stacks, etc.
> > I'll try to write a little test program and see if I can make a simple
> > example fail under Win2K. If so, it will be much easier to debug. If
> > not, then we know it's something special emacs does.
>
> I had tried writing test program which calls sbrk just like emacs:
> ---8<---
> #include <crt0.h>
> #include <unistd.h>
>
> int _crt0_startup_flags = _CRT0_FLAG_UNIX_SBRK;
>
> int main(void)
> {
> sbrk(0);
> sbrk(36);
> sbrk(118664);
> return 0;
> }
> ---8<---
>
> Well, it does not fail. Maybe I've missed some flag or other piece of
> setup? But if I didn't, it means that it will be difficult to
> construct a test case.
Nope, it looks fine. Here's mine:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <crt0.h>
#include <sys/nearptr.h>
int _crt0_startup_flags = _CRT0_FLAG_UNIX_SBRK;
int main(int argc, char** argv) {
int i,j;
printf("My starting base address is 0x%8.8x\n",__djgpp_base_address);
for(i=1;i<argc;i++) {
j = 1024*atoi(argv[i]);
if(j > 0) {
printf("sbrk(%d)...(press a key)\n",j);
getkey();
j = (int)sbrk(j);
printf("returned 0x%8.8x, new base is 0x%8.8x\n",j,__djgpp_base_address);
}
}
return 0;
}
It shows that the base address is changing, so we have little windows
of potential badness. Now, it usually doesn't go away, but sometimes it
does...
C:\djgpp\tmp>sbt 100 1000 5000 10000 100
My starting base address is 0x01d50000
sbrk(102400)...(press a key)
returned 0x00094900, new base is 0x01df0000
sbrk(1024000)...(press a key)
returned 0x000ad900, new base is 0x01ea0000
sbrk(5120000)...(press a key)
returned 0x001a7900, new base is 0x02050000
sbrk(10240000)...(press a key)
C:\djgpp\tmp>
In this case I was pressing keys quickly, so a keystroke may have come in
while it was sbrk()'ing, causing the problem. It will even die with
slower key presses.
> There must be some randomness involved here, because I can reproduce
> aborts consistently only if running emacs under gdb. Also if I
> recompile emacs binary w/o any source change then the place of failure
> changes. In my opinion we are quite lucky that emacs has 90% chance of
> failing in the same place when running from gdb :)
The above program with the above big numbers seems to die fairly reliably
for me.
I've got to go take the kids to the pool.
- Raw text -