bug#14850: 24.3; GDI Handles leak(Windows)

bug#14850: 24.3; GDI Handles leak(Windows)

[Akihiro KAYAMA]

[-- Attachment #1: Type: text/plain, Size: 4088 bytes --]

This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgment at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

--
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.
--


If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
c:/Program Files (x86)/emacs-24.3/etc/DEBUG.


In GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601)
 of 2013-03-18 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'

Important settings:
  value of $LANG: JPN
  locale-coding-system: cp932
  default enable-multibyte-characters: t

Major mode: Shell

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
ESC x m a k e - f r <tab> - <tab> c o <tab> RET <switch-frame>
ESC x s h e l l RET p i n g SPC 1 2 7 . 0 . 0 . 1 SPC
- t RET ESC x f i n d - f i l e RET <down-mouse-1>
<mouse-movement> <mouse-1> C-g ESC x C-g C-g C-n C-n
ESC x r e p o r t - e m <tab> RET

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
You can run the command `make-frame-command' with C-x 5 2
Quit
completing-read-default: Command attempted to use minibuffer while in
minibuffer
Quit [2 times]

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils shell pcomplete comint ansi-color ring help-mode
easymenu time-date japan-util tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win
w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
w32 multi-tty emacs)

[-- Attachment #2: Type: text/html, Size: 4650 bytes --]

bug#14850: 24.3; GDI Handles leak(Windows)

[Eli Zaretskii]

> Date: Fri, 12 Jul 2013 18:49:48 +0900
> From: Akihiro KAYAMA <kayama@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.

bug#14850: 24.3; GDI Handles leak(Windows)

[Eli Zaretskii]

> Date: Sat, 13 Jul 2013 15:55:35 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 14850@debbugs.gnu.org
> 
> Patches are welcome to make our usage of GDI objects smaller.
> Pointers to places where we fail to release GDI objects are also
> welcome.

Found and plugged one place, although I'm not sure how frequently we
lose a handle due to that.

bug#14850: 24.3; GDI Handles leak(Windows)

[Akihiro KAYAMA]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

Thank you very much for your quick response.

I understand you can't reproduce GDI Handles leak. Just to make sure,
I mention again three requiremetns fot it.

 - multiple frames
 - continuous shell buffer output(maybe mode line updates)
 - mini buffer

And also, I have tested only on Japanese version Windows XP and Windows 7.
System fonts or locale or OS Input Method differencies may affect this.

-- kayama



2013/7/13 Eli Zaretskii <eliz@gnu.org>

> > Date: Sat, 13 Jul 2013 15:55:35 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 14850@debbugs.gnu.org
> >
> > Patches are welcome to make our usage of GDI objects smaller.
> > Pointers to places where we fail to release GDI objects are also
> > welcome.
>
> Found and plugged one place, although I'm not sure how frequently we
> lose a handle due to that.
>

[-- Attachment #2: Type: text/html, Size: 1324 bytes --]

bug#14850: 24.3; GDI Handles leak(Windows)

[Eli Zaretskii]

> Date: Sun, 14 Jul 2013 18:55:24 +0900
> From: Akihiro KAYAMA <kayama.akihiro@gmail.com>
> Cc: 14850@debbugs.gnu.org
> 
> I understand you can't reproduce GDI Handles leak. Just to make sure,
> I mention again three requiremetns fot it.
> 
>  - multiple frames
>  - continuous shell buffer output(maybe mode line updates)
>  - mini buffer

Actually, I think I did succeed to reproduce this.  Here's a much
easier method, for the record:

  emacs -Q
  M-x make-frame-command RET
  M-: (require 'time) RET
  M-: (setq display-time-interval 1) RET
  M-: (setq display-time-format "%H:%M:%S") RET
  M-x display-time RET
  C-x C-f

As long as Emacs sits at the minibuffer prompt, you'll have a GDI
handle leaked once every second, according to display-time-interval.
Type C-g to get out of the minibuffer, and the leak stops.

IOW, the conditions for this are:

 . more than 1 frame

 . active minibuffer prompt, and

 . continuous redisplay

According to my measurements, the change I made in revision 113415
completely stops GDI handle leak in this scenario, and also in your
original one.  So I will close this bug; feel free to reopen if you
can still come up with a scenario where GDI objects are leaked.

The changes I committed are below, for your convenience.

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2013-07-13 10:29:15 +0000
+++ src/ChangeLog	2013-07-13 14:21:01 +0000
@@ -1,5 +1,8 @@
 2013-07-13  Eli Zaretskii  <eliz@gnu.org>
 
+	* w32term.c (x_draw_hollow_cursor): Delete the brush object when
+	returning early.  (Bug#14850)
+
 	* coding.c (syms_of_coding): Set up inhibit-null-byte-detection
 	and inhibit-iso-escape-detection attributes of 'undecided'.
 	(Bug#14822)

=== modified file 'src/w32term.c'
--- src/w32term.c	2013-07-06 02:40:50 +0000
+++ src/w32term.c	2013-07-13 14:21:01 +0000
@@ -5174,7 +5174,10 @@ x_draw_hollow_cursor (struct window *w, 
      the current matrix is invalid or such, give up.  */
   cursor_glyph = get_phys_cursor_glyph (w);
   if (cursor_glyph == NULL)
-    return;
+    {
+      DeleteObject (hb);
+      return;
+    }
 
   /* Compute frame-relative coordinates for phys cursor.  */
   get_phys_cursor_geometry (w, row, cursor_glyph, &left, &top, &h);