Mail Archives: djgpp/1997/02/17/13:55:36
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> 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
- Raw text -