From: frazer AT rtp DOT ericsson DOT se (Scott Frazer) Newsgroups: comp.os.msdos.djgpp Subject: Re: emacs 19.34 crashes immediately on win nt 4.0 Date: Mon, 17 Feb 1997 17:44:13 GMT Organization: Ericsson Data Services Americas Lines: 40 Message-ID: <3308959b.5475968@cnn.exu.ericsson.se> References: NNTP-Posting-Host: pc093.rtp.ericsson.se To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Eli Zaretskii wrote: >> I >> don't know how dangerous this is ... maybe some sort of subtle >> memory leak that will eventually kill the process. > >The call on dosfns.c can be easily rewritten to avoid calling that >function (it can just use the transfer buffer). It should have been >written that way in the first place, but I didn't want to change existing >code without a good reason, which I now have. > >As for w16select.c, as long as you don't use `C-w' or `M-w' on regions >larger than 16KB (the size of the transfer buffer), the code doesn't >allocate and doesn't free DOS memory at all. Once you kill or copy larger >regions, you will start losing DOS memory; without releasing it, after >some time you (1) won't be able to move data between Emacs and the Windows >clipboard; and (2) you won't be able to invoke subprocesses. However, >since 16KB is quite a large size (and it can be enlarged by stubediting >Emacs), I don't expect you to hit this except under very special >circumstances. And once I understand the reason for the problem, chances >are the code could be rewritten to work around the bug. Eli/Charles, I got your various email's suggesting things to try (they haven't shown up on my news server yet, so this post may be out of order), and I will try all of them ASAP ... which unfortunately is next week. I am in an off-site training seminar this week and didn't want you to think I had abandoned the effort. I actually had tried uncommenting the _go32_dpmi_blah_blah line in w16selec.c because the one in dosfns.c looked like it would be called only once. I figured that having a little unfreed memory around wouldn't be too bad, but there could be some major accumulation from kill/copy's. It did work for small kill/yank's, but when I killed a big chunk of code then tried to yank it back I got dumped to the DOS prompt. No signal explanation, no traceback, nothing ... just c:\ Scott