emacs-bug-tracker
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#14850: closed (24.3; GDI Handles leak(Windows))

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#14850: closed (24.3; GDI Handles leak(Windows))
Date: Sun, 14 Jul 2013 16:07:01 +0000 
Your message dated Sun, 14 Jul 2013 19:06:47 +0300
with message-id <address@hidden>
and subject line Re: bug#14850: 24.3; GDI Handles leak(Windows)
has caused the debbugs.gnu.org bug report #14850,
regarding 24.3; GDI Handles leak(Windows)
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
14850: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14850
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 24.3; GDI Handles leak(Windows) Date: Fri, 12 Jul 2013 18:49:48 +0900
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)


--- End Message ---
--- Begin Message --- Subject: Re: bug#14850: 24.3; GDI Handles leak(Windows) Date: Sun, 14 Jul 2013 19:06:47 +0300 
> Date: Sun, 14 Jul 2013 18:55:24 +0900
> From: Akihiro KAYAMA <address@hidden>
> Cc: address@hidden
> 
> 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  <address@hidden>
 
+       * 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);

--- End Message ---
reply via email to
[Prev in Thread] Current Thread [Next in Thread]