Xref:	news2.mv.net comp.os.msdos.djgpp:6455
From:	Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: emacs problem under WfWG 3.11
Date:	Fri, 26 Jul 1996 08:51:09 CDT
Organization:	Rice University, Houston, Texas
Lines:	16
Message-ID:	<31f8cd4d.sandmann@clio.rice.edu>
References:	<collins DOT 838333538 AT aplcomm DOT jhuapl DOT edu>
Reply-To:	sandmann AT clio DOT rice DOT edu
NNTP-Posting-Host:	clio.rice.edu
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

> All I can tell is that something seems to go wrong at 0x13ce
> __djgpp_memory_handle_pointer+112 in crt0. 

Actually, it appears you are trying to step into "lcall sbrk16_api_ofs"
and you shouldn't do that.  It's in a different CS and 16-bit, and
none of the debuggers handle either one.  This is the call that 
implements the "unixy sbrk", and the arena may be moving on you.  It
could be that the debugger is broken (since this isn't the default anymore
it probably doesn't get tested as much), or that Windows with Win32s is
broken (the re-allocate dpmi call is not used by most other extenders so
dpmi providers tend to break it and not notice) or that the failure at
this point is an artifact of running under the debugger.  We really need
the register listing at the crash point to figure out what's going on.
It could also be that hooking a hardware interrupt (like the keyboard)
with the unixy sbrk() causes problems in this environment if the arena
moves on you.

- Raw text -