Mail Archives: djgpp-workers/1996/12/10/17:41:09
On Sun, 8 Dec 1996, Charles Sandmann wrote:
> NT does not support fat ds. The non-move sbrk() needs fat ds if the
> dpmi provider returns memory blocks below the original block.
Emacs uses Unixy sbrk, so this shouldn't be a problem. (Emacs links with
a relocating version of malloc, which should presumably alleviate some of
the adverse effects of constantly mallocing and freeing memory for its
buffers. At least with DJGPP, when our malloc is used, it indeed begins
paging after a while in any serious editing session. So I originally
thought it would be safer to use a Unixy sbrk in case it assumed something
about its behavior, and never got to testing whether it works with a
non-move sbrk. Based on what you say now, I'll probably never do that, at
least as long as we want to support NT.)
> Since SS shows up in the register trace correctly, it's being set OK.
> However, ESP isn't correct. This may not be the real problem since the
> debugger may cause grief in the consistency window. But it may be due to
> the fact that the sbrk'ed stack isn't legit. The next step should be move EAX
> to ESP, and EAX isn't right in the register listing compared to the eax
> listed above. There may be badness with the debugger under NT? Or is
> the register listing identical outside of the debugger?
Here's the stack dump printed when it crashed outside the debugger (as
that guy sent me in his original message):
Exiting due to signal SIGSEGV
General Protection Fault at eip=0000346b
eax=0000024f ebx=001dff30 ecx=00000000 edx=0000024f esi=001d00d7 edi=001dff6c
ebp=001d2f48 esp=00002f42 program=c:\appz\emacs\bin\EMACS.EXE
cs: sel=00c7 base=00110800 limit=00005ef0
ds: sel=00b7 base=000cc2b0 limit=0000ffff
es: sel=00d7 base=001166f0 limit=00005fff
fs: sel=01ef base=0000ac90 limit=0000ffff
gs: sel=0247 base=00000000 limit=7ffeffff
ss: sel=00b7 base=000cc2b0 limit=0000ffff
(I asked: there indeed was NO stack dump after the registers, which
probably is understandable since it crashes before the stack is set.)
Btw, the compiled Emacs binary is in v2gnu/em1934b.zip. If you have
enough time, you might just extract it and see for yourself what's going
on. Since it crashes so early, you don't need all the runtime support
that Emacs needs to start, just the .exe should be enough. Anyway,
thanks for any help.
- Raw text -