From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10205192036.AA17719@clio.rice.edu>
Subject: Re: emacs under w2k
To: lauras AT softhome DOT net
Date: Sun, 19 May 2002 15:36:09 -0500 (CDT)
Cc: eliz AT is DOT elta DOT co DOT il (Eli Zaretskii), djgpp-workers AT delorie DOT com
In-Reply-To: <127279070542.20020519222322@softhome.net> from "Laurynas Biveinis" at May 19, 2002 10:23:22 PM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> > 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.