delorie.com/archives/browse.cgi | search |
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.
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |