GNU bug report logs - #14850
24.3; GDI Handles leak(Windows)

Previous Next

Full log

Message #8 received at 14850 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Akihiro KAYAMA <kayama <at> tiresia.org>
Cc: 14850 <at> debbugs.gnu.org
Subject: Re: bug#14850: 24.3; GDI Handles leak(Windows)
Date: Sat, 13 Jul 2013 15:55:35 +0300

> Date: Fri, 12 Jul 2013 18:49:48 +0900
> From: Akihiro KAYAMA <kayama <at> tiresia.org>
> 
> When using multiple emacs frames and shell buffer in Windows,
> Emacs process's GDI Handles increase constantly.
> 
> How to reproduce:
> 
>  - emacs.exe -Q
>  - M-x make-frame-command
>  - M-x shell
>  - ping 127.0.0.1 -t (continuous shell output)
>  - M-x find-file (open some mini buffer)
>  - inspect Emacs process's GDI Handles by Process Explorer(
> www.sysinternals.com)
> 
> As the increasing ratio is in proportion to number of frames, with a
> dozen frames Emacs process can easily reach Windows OS limit(=10000 handles)
> in a few minutes.

I don't think the number of frames is such an important factor here.
E.g., try evaluating this in "emacs -Q":

  (dotimes (i 30) (make-frame))

and compare the number of GDI objects before and after.  On my
machine, the difference is much smaller than 30, it's more like 10.

Anyway, I looked through the sources for the Windows API calls that
are documented to produce GDI objects.  All of them seem to have the
appropriate calls to DeleteObject or similar APIs that release these
resources.  So it doesn't seem like we are too sloppy about this, at
least not enough for me to find that.  Not that I know too much about
this issue.

Patches are welcome to make our usage of GDI objects smaller.
Pointers to places where we fail to release GDI objects are also
welcome.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.