From unknown Wed Jun 18 00:08:34 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#20220 <20220@debbugs.gnu.org> To: bug#20220 <20220@debbugs.gnu.org> Subject: Status: severe memory leak on emacs 24.4.1 Reply-To: bug#20220 <20220@debbugs.gnu.org> Date: Wed, 18 Jun 2025 07:08:34 +0000 retitle 20220 severe memory leak on emacs 24.4.1 reassign 20220 emacs submitter 20220 Mario Valencia severity 20220 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 28 19:39:56 2015 Received: (at submit) by debbugs.gnu.org; 28 Mar 2015 23:39:56 +0000 Received: from localhost ([127.0.0.1]:39177 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yc0KY-0006nB-Op for submit@debbugs.gnu.org; Sat, 28 Mar 2015 19:39:55 -0400 Received: from eggs.gnu.org ([208.118.235.92]:52691) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yc0KV-0006mv-V6 for submit@debbugs.gnu.org; Sat, 28 Mar 2015 19:39:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yc0KO-00032X-FD for submit@debbugs.gnu.org; Sat, 28 Mar 2015 19:39:46 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=AC_HTML_NONSENSE_TAGS, BAYES_50, FREEMAIL_FROM,HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:59136) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yc0KO-000328-CH for submit@debbugs.gnu.org; Sat, 28 Mar 2015 19:39:44 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yc0KM-0008P1-GB for bug-gnu-emacs@gnu.org; Sat, 28 Mar 2015 19:39:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yc0KK-0002pe-Iv for bug-gnu-emacs@gnu.org; Sat, 28 Mar 2015 19:39:42 -0400 Received: from mail-la0-x22e.google.com ([2a00:1450:4010:c03::22e]:33993) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yc0KK-0002l6-3d for bug-gnu-emacs@gnu.org; Sat, 28 Mar 2015 19:39:40 -0400 Received: by lagg8 with SMTP id g8so94212353lag.1 for ; Sat, 28 Mar 2015 16:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=1lAEdz12r8TqNW5dZLftiM7wK435TwatWgkZjcPpthE=; b=K48g1fv3rkT4JcgUt/6+IyQ+j3bkuOjS/ERkteHQ2xdzQjvDTaPB5pDf0KWE4xlqen tEU5p+rdwZW0LxedELqTvz2swjd34P3+KzoCPqzeVRnH6tPBB6Y+oRGjc2xxERfDZ/U6 DIWpbuFtyQBGsxXay0e7etIPNeE2eAPZbzfPGdm94ylpugyxN/WFxkv4sGWHa88Ln/hb zgu4gvlPk8Gaxsrv0/pTvikOBMD18diQadF9C++MkKqhDFcV/LEsb2hojf6NPXUybeOA tzpBbooRyJeW+Mzd5wAe4sZ5pYqp+bb3bBFoAwB+N1DI0FfrKqKSfZQfxYDpiA87tyL7 R8kw== MIME-Version: 1.0 X-Received: by 10.112.159.137 with SMTP id xc9mr929844lbb.87.1427585978167; Sat, 28 Mar 2015 16:39:38 -0700 (PDT) Received: by 10.112.170.130 with HTTP; Sat, 28 Mar 2015 16:39:38 -0700 (PDT) Date: Sat, 28 Mar 2015 17:39:38 -0600 Message-ID: Subject: severe memory leak on emacs 24.4.1 From: Mario Valencia To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary=001a11c3da0a1d7661051261c3d2 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) --001a11c3da0a1d7661051261c3d2 Content-Type: text/plain; charset=UTF-8 to reproduce it, i create a small emtpy html document. then i evaluate the following expression: (dotimes (i 100) (browse-url-of-file)) This causes emacs to start opening the file using google chrome. In the task manager, i can see emacs' memory usage go up by about 5 megabytes each time a tab is opened. When it opens about 30 tabs, emacs is using 138 megabytes of memory, and it gives the error below. the translation is something like this: "ShellExecute failed: Storage space insufficient to process this command" My harddrive has enough storage space btw. I was able to reproduce this bug 3 times. I ran emacs with -Q on windows 8. Im using emacs version: GNU Emacs 24.4.1 (i686-pc-mingw32) of 2014-10-24 on LEG570 Debugger entered--Lisp error: (error "ShellExecute failed: Espacio de almacenamiento insuficiente para procesar este comando.") w32-shell-execute("open" "file:///c:/Users/mario/Desktop/x.html") browse-url-default-windows-browser("file:///c:/Users/mario/Desktop/x.html" nil) apply(browse-url-default-windows-browser "file:///c:/Users/mario/Desktop/x.html" nil) browse-url-default-browser("file:///c:/Users/mario/Desktop/x.html" nil) apply(browse-url-default-browser "file:///c:/Users/mario/Desktop/x.html" nil) browse-url("file:///c:/Users/mario/Desktop/x.html") browse-url-of-file("c:/Users/mario/Desktop/x.html") browse-url-of-buffer() (while (< i --dotimes-limit--) (browse-url-of-buffer) (setq i (1+ i))) (let ((--dotimes-limit-- 100) (i 0)) (while (< i --dotimes-limit--) (browse-url-of-buffer) (setq i (1+ i)))) (dotimes (i 100) (browse-url-of-buffer)) eval((dotimes (i 100) (browse-url-of-buffer)) nil) eval-expression((dotimes (i 100) (browse-url-of-buffer)) nil) call-interactively(eval-expression nil nil) command-execute(eval-expression) In GNU Emacs 24.4.1 (i686-pc-mingw32) of 2014-10-24 on LEG570 Windowing system distributor `Microsoft Corp.', version 6.3.9600 Configured using: `configure --prefix=/c/usr' Important settings: value of $LANG: ESM locale-coding-system: cp1252 Major mode: Fundamental Minor modes in effect: tooltip-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: t line-number-mode: t transient-mark-mode: t Recent input: C-x C-f x . h m l t m l C-k C-k C-k C-k C-k C-k C-k C-k C-k C-k C-k C-x C-s M-: ( d o t i m e s - SPC ( i SPC 1 0 0 ) SPC ( b r o w s e - u r l b u f ) ) C-a M-w e i q C-h C-a C-c M-w M-w M-x r e p o r t - e m Recent messages: Wrote c:/Users/mario/Desktop/x.html user-error: Beginning of history; no preceding item Entering debugger... Mark set End of buffer [6 times] Saved text from "Debugger entered--Lisp error: (error "Sh" 30 (#o36, #x1e, ?\C-^) Back to top level. Mark set C-c M-w is undefined 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 help-fns mail-prsvr mail-utils mule-util help-mode easymenu debug browse-url sgml-mode time-date tooltip electric uniquify 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 prog-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 nadvice 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 w32notify w32 multi-tty emacs) Memory information: ((conses 8 82170 4244) (symbols 32 17933 0) (miscs 32 88 151) (strings 16 12976 3656) (string-bytes 1 327227) (vectors 8 10094) (vector-slots 4 391999 3862) (floats 8 61 285) (intervals 28 398 48) (buffers 508 15)) --001a11c3da0a1d7661051261c3d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
to reproduce it, i create a small emtpy html document. the= n i evaluate the following expression:

(dotimes (i 100) = (browse-url-of-file))

This causes emacs to start o= pening the file using google chrome. In the task manager, i can see emacs&#= 39; memory usage go up by about 5 megabytes each time a tab is opened. When= it opens about 30 tabs, emacs is using 138 megabytes of memory, and it giv= es the error below.
the translation is something like this: "= ;ShellExecute failed: Storage space insufficient to process this command&qu= ot;
My harddrive has enough storage space btw.
I was able to reproduce this bug 3 times. I ran emacs with -Q o= n windows 8.
Im using emacs version:
GNU Emacs 24.= 4.1 (i686-pc-mingw32)
=C2=A0of 2014-10-24 on LEG570

Debugger entered--Lisp error: (error "ShellExec= ute failed: Espacio de almacenamiento insuficiente para procesar este coman= do.")
=C2=A0 w32-shell-execute("open" "file:/= //c:/Users/mario/Desktop/x.html")
=C2=A0 browse-url-default-= windows-browser("file:///c:/Users/mario/Desktop/x.html" nil)
=C2=A0 apply(browse-url-default-windows-browser "file:///c:/User= s/mario/Desktop/x.html" nil)
=C2=A0 browse-url-default-brows= er("file:///c:/Users/mario/Desktop/x.html" nil)
=C2=A0 = apply(browse-url-default-browser "file:///c:/Users/mario/Desktop/x.htm= l" nil)
=C2=A0 browse-url("file:///c:/Users/mario/Deskt= op/x.html")
=C2=A0 browse-url-of-file("c:/Users/mario/D= esktop/x.html")
=C2=A0 browse-url-of-buffer()
=C2= =A0 (while (< i --dotimes-limit--) (browse-url-of-buffer) (setq i (1+ i)= ))
=C2=A0 (let ((--dotimes-limit-- 100) (i 0)) (while (< i --d= otimes-limit--) (browse-url-of-buffer) (setq i (1+ i))))
=C2=A0 (= dotimes (i 100) (browse-url-of-buffer))
=C2=A0 eval((dotimes (i 1= 00) (browse-url-of-buffer)) nil)
=C2=A0 eval-expression((dotimes = (i 100) (browse-url-of-buffer)) nil)
=C2=A0 call-interactively(ev= al-expression nil nil)
=C2=A0 command-execute(eval-expression)

In GNU Emacs 24.4.1 (i686-pc-mingw3= 2)
=C2=A0of 2014-10-24 on LEG570
Windowing system distr= ibutor `Microsoft Corp.', version 6.3.9600
Configured using:<= /div>
=C2=A0`configure --prefix=3D/c/usr'

= Important settings:
=C2=A0 value of $LANG: ESM
=C2=A0 l= ocale-coding-system: cp1252

Major mode: Fundamenta= l

Minor modes in effect:
=C2=A0 tooltip-= mode: t
=C2=A0 electric-indent-mode: t
=C2=A0 mouse-whe= el-mode: t
=C2=A0 tool-bar-mode: t
=C2=A0 menu-bar-mode= : t
=C2=A0 file-name-shadow-mode: t
=C2=A0 global-font-= lock-mode: t
=C2=A0 blink-cursor-mode: t
=C2=A0 auto-co= mposition-mode: t
=C2=A0 auto-encryption-mode: t
=C2=A0= auto-compression-mode: t
=C2=A0 buffer-read-only: t
= =C2=A0 line-number-mode: t
=C2=A0 transient-mark-mode: t

Recent input:
<help-echo> C-x C-f <back= space> <backspace> <backspace>=C2=A0
<backspace= > <backspace> <backspace> <backspace> <backspace>= ;=C2=A0
<backspace> <backspace> <backspace> <= ;backspace> <backspace>=C2=A0
<backspace> <back= space> x . h m l <backspace> <backspace>=C2=A0
t m= l <return> C-k C-k C-k C-k C-k C-k C-k C-k C-k=C2=A0
C-k C= -k C-x C-s M-: <up> ( d o t i m e s - <backspace>=C2=A0
SPC ( i SPC 1 0 0 ) SPC ( b r o w s e - u r l <tab>=C2=A0
<backspace> <backspace> <backspace> b u f <tab> )= )=C2=A0
<return> C-a <S-down> <S-down> <S-d= own> <S-down> <S-down>=C2=A0
<S-down> <S-= down> <S-down> <S-down> <S-down> <S-down>=C2=A0<= /div>
<S-down> <S-down> <S-down> <S-down> <S= -down> <S-down>=C2=A0
<S-down> <S-down> <= S-down> <S-down> <S-down> M-w <help-echo>=C2=A0
<= div>e i <return> <help-echo> <help-echo> <help-echo>= ; q=C2=A0
C-h C-a <down> <S-down> <S-down> C-c = <help-echo> <help-echo>=C2=A0
<help-echo> <h= elp-echo> <help-echo> M-w M-w <help-echo>=C2=A0
&l= t;help-echo> <help-echo> M-x r e p o r t - e m <tab>=C2=A0
<return>

Recent messages:
Wrote c:/Users/mario/Desktop/x.html
user-error: Beginning of his= tory; no preceding item
Entering debugger...
Mark set
End of buffer [6 times]
Saved text from "Debugger e= ntered--Lisp error: (error "Sh"
30 (#o36, #x1e, ?\C-^)<= /div>
Back to top level.
Mark set
C-c M-w is undefi= ned

Load-path shadows:
None found.
=

Features:
(shadow sort gnus-util mail-extr em= acsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies= mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sen= dmail rfc2047 rfc2045 ietf-drums mm-util
help-fns mail-prsvr mail= -utils mule-util help-mode easymenu debug
browse-url sgml-mode ti= me-date tooltip electric uniquify 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 prog-mode register page menu-bar
rfn-eshado= w timer select scroll-bar mouse jit-lock font-lock syntax
facemen= u font-core frame cham georgian utf-8-lang misc-lang vietnamese
t= ibetan 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 nadvice loaddefs button=
faces cus-face macroexp files text-properties overlay sha1 md5 b= ase64
format env code-pages mule custom widget hashtable-print-re= adable
backquote make-network-process w32notify w32 multi-tty ema= cs)

Memory information:
((conses 8 82170= 4244)
=C2=A0(symbols 32 17933 0)
=C2=A0(miscs 32 88 15= 1)
=C2=A0(strings 16 12976 3656)
=C2=A0(string-bytes 1 = 327227)
=C2=A0(vectors 8 10094)
=C2=A0(vector-slots 4 3= 91999 3862)
=C2=A0(floats 8 61 285)
=C2=A0(intervals 28= 398 48)
=C2=A0(buffers 508 15))

--001a11c3da0a1d7661051261c3d2-- From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 29 02:01:05 2015 Received: (at 20220) by debbugs.gnu.org; 29 Mar 2015 06:01:05 +0000 Received: from localhost ([127.0.0.1]:39272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yc6HQ-0000C9-MS for submit@debbugs.gnu.org; Sun, 29 Mar 2015 02:01:04 -0400 Received: from dancol.org ([96.126.100.184]:33269) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yc6HO-0000Bd-18 for 20220@debbugs.gnu.org; Sun, 29 Mar 2015 02:01:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=ECSDOLL7KcXtslFcNoFgAsbxPzVKIW3H7cwTXZFyfWk=; b=SYZeu6vyUQ5mlNbh/R8QAulijDNHuZTC0TgPSrlUnL5Dt6Z/muDBMLfh9hH1UxCy4vYgnhdtuLZbvxkjbcpfyJMplbISjZ97jCkkpIWcK9jkUDUmxbCEuWQ2CDh0pdwCq23DPXhLkskhmtz2zVltG0HHbWui+5ve3i6iyh06E91llaow8mAGEoHPOk6ReW297Y9Ttokewojg8cZTronKuzFQIUh821Njlqlva6TvX1LRqkvbEJuyvmvvC3Rv657uxYYjsn/VyvJxsggedcfy/OqbOLkpF8glMMstgDkA8yyq0BnpvoSrTComx2ZpfRX7gNXF9FGGvpvDhsFi7Ijsrg==; Received: from [2601:8:b240:1c1::2b1] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1Yc6HM-0005gu-Jv; Sat, 28 Mar 2015 23:01:00 -0700 Message-ID: <5517951C.9050204@dancol.org> Date: Sat, 28 Mar 2015 23:01:00 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mario Valencia , 20220@debbugs.gnu.org Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="R1AHd0APvgV2r7d6pfOMdhrCFbJcHJUqb" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20220 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --R1AHd0APvgV2r7d6pfOMdhrCFbJcHJUqb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/28/2015 04:39 PM, Mario Valencia wrote: > to reproduce it, i create a small emtpy html document. then i evaluate > the following expression: >=20 > (dotimes (i 100) (browse-url-of-file)) >=20 > This causes emacs to start opening the file using google chrome. In the= > task manager, i can see emacs' memory usage go up by about 5 megabytes > each time a tab is opened. When it opens about 30 tabs, emacs is using > 138 megabytes of memory, and it gives the error below. > the translation is something like this: "ShellExecute failed: Storage > space insufficient to process this command" > My harddrive has enough storage space btw. Do you happen to have any shell extensions installed? ShellExecute can run arbitrary third-party code through this extension mechanism. --R1AHd0APvgV2r7d6pfOMdhrCFbJcHJUqb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVF5UcAAoJEN4WImmbpWBlwXwP/1/jUbGcr9KizFmW6z2pITDO +k5FwCcuEp5+6VbtlMyWYTwBgW8qmsHdM10vlPwPT2eS6zGrBEce1MjdV16EzY8M InJsUhORWf3wERnGETws5vepgQWikupketaKNhFWlFZiS69rMp9IiY/EPc6clDT0 1YXX+SDChwBagJ7AVlWwcxNCu4QBofEikbEmcTEvzNYU4I054EUduMlzAftuSq6J 2nHY1+woB5R74eTtk4BA6MmCjukMV6OG/qgMnLHDP9NQyts2NTGLBXyBwRF1FlRQ isv30i7ikKrll2PLxDDHPBHH1nVPhhWnLaPTs+LnTQc/MPYnVFiNeZgRenjjOh+j G+jIBlFkILY/cHh1V2Yc68HHZdxfKQ57UxqW/0y/f+xLmbqxFTGgsgk1Q7B5TeOT nDtrTfSqvFYXyup25WL1WYTjUIX8L6j21f+9sI1hb18LKDGumNKKY2jlyqy0DhKW tbGwbg3gSElYA9uc+MLzKdUyQ/oDsMxF/3HsAvteJFKMnUkh5pxWFgvkt3+qlF9Y yOTe9DlPv8507l9VujuVvcvA70lCPf1WvXbKSvH7yEXPmm15f99yIky/vnAdRxS8 dUD3AF1A5pbZiWfeT+sRjoSSpM238KtEpG2ps6F2E448r9zdO21GO7DEZEWLCR6R 2V/qlrC4xUp9ifhxwV5a =AtYw -----END PGP SIGNATURE----- --R1AHd0APvgV2r7d6pfOMdhrCFbJcHJUqb-- From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 29 02:04:59 2015 Received: (at 20220) by debbugs.gnu.org; 29 Mar 2015 06:04:59 +0000 Received: from localhost ([127.0.0.1]:39276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yc6LD-0000IH-AC for submit@debbugs.gnu.org; Sun, 29 Mar 2015 02:04:59 -0400 Received: from mail-lb0-f174.google.com ([209.85.217.174]:36378) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yc6LB-0000I4-Oc for 20220@debbugs.gnu.org; Sun, 29 Mar 2015 02:04:58 -0400 Received: by lbbug6 with SMTP id ug6so87773888lbb.3 for <20220@debbugs.gnu.org>; Sat, 28 Mar 2015 23:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W7Kd3vIUNIckTC23L4yyw2UObF00q/QbNk64hRVm4Ck=; b=GF7E7YZ8NWztx6FdOLv9Ldu7nLHt9lnbQsEE26y8Zbo6pkAZrWmqsO3hmRMV+EwBQT m73W+rYYoNnJ/Mo7It1NMNrHo+aqIp2eWlAcOez85CxjE5+obDtiRi+7Nw9jQ0T1JH9p vwmGmfQJMX8ItvWcduEt6OneX2U0WAlfyhWm/2os8MvEPQBBcgFkEe0DF+6tm57QABQU UP+9UPNs+32Avb5Qlxy5GqM2QekgUhSGleHKxw3B7SoSa8+S6KsFa9ESeNCZLX1LEeef glTQ5IEg/YD3JdWwMVmGRAOrGviB9CxeHGjRZvNx6hhXNcDr9gTpAxmjZ6Myulo8XTW9 teVA== MIME-Version: 1.0 X-Received: by 10.112.26.209 with SMTP id n17mr23747521lbg.84.1427609091661; Sat, 28 Mar 2015 23:04:51 -0700 (PDT) Received: by 10.112.170.130 with HTTP; Sat, 28 Mar 2015 23:04:51 -0700 (PDT) In-Reply-To: <5517951C.9050204@dancol.org> References: <5517951C.9050204@dancol.org> Date: Sun, 29 Mar 2015 00:04:51 -0600 Message-ID: Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 From: Mario Valencia To: Daniel Colascione Content-Type: multipart/alternative; boundary=001a11336abac9643b05126724dd X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11336abac9643b05126724dd Content-Type: text/plain; charset=UTF-8 I have no idea my friend. How can I check? 2015-03-29 0:01 GMT-06:00 Daniel Colascione : > On 03/28/2015 04:39 PM, Mario Valencia wrote: > > to reproduce it, i create a small emtpy html document. then i evaluate > > the following expression: > > > > (dotimes (i 100) (browse-url-of-file)) > > > > This causes emacs to start opening the file using google chrome. In the > > task manager, i can see emacs' memory usage go up by about 5 megabytes > > each time a tab is opened. When it opens about 30 tabs, emacs is using > > 138 megabytes of memory, and it gives the error below. > > the translation is something like this: "ShellExecute failed: Storage > > space insufficient to process this command" > > My harddrive has enough storage space btw. > > Do you happen to have any shell extensions installed? ShellExecute can > run arbitrary third-party code through this extension mechanism. > > --001a11336abac9643b05126724dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have no idea my friend. How can I check?

2015-03-29 0:01 GMT-06:00 D= aniel Colascione <dancol@dancol.org>:
On 03/28/2015 04:39 PM, Mario Valencia wrote:
> to reproduce it, i create a small emtpy html document. then i evaluate=
> the following expression:
>
> (dotimes (i 100) (browse-url-of-file))
>
> This causes emacs to start opening the file using google chrome. In th= e
> task manager, i can see emacs' memory usage go up by about 5 megab= ytes
> each time a tab is opened. When it opens about 30 tabs, emacs is using=
> 138 megabytes of memory, and it gives the error below.
> the translation is something like this: "ShellExecute failed: Sto= rage
> space insufficient to process this command"
> My harddrive has enough storage space btw.

Do you happen to have any shell extensions installed?=C2=A0 ShellExecute ca= n
run arbitrary third-party code through this extension mechanism.


--001a11336abac9643b05126724dd-- From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 29 11:15:44 2015 Received: (at 20220) by debbugs.gnu.org; 29 Mar 2015 15:15:44 +0000 Received: from localhost ([127.0.0.1]:39739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YcEwB-0007vY-Vy for submit@debbugs.gnu.org; Sun, 29 Mar 2015 11:15:44 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:51946) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YcEw8-0007vH-R9 for 20220@debbugs.gnu.org; Sun, 29 Mar 2015 11:15:42 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NLZ00E00BOLZ600@a-mtaout22.012.net.il> for 20220@debbugs.gnu.org; Sun, 29 Mar 2015 18:15:34 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NLZ00ENPBPYQ290@a-mtaout22.012.net.il>; Sun, 29 Mar 2015 18:15:34 +0300 (IDT) Date: Sun, 29 Mar 2015 18:15:18 +0300 From: Eli Zaretskii Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 In-reply-to: X-012-Sender: halo1@inter.net.il To: Mario Valencia Message-id: <83oanbzvg9.fsf@gnu.org> References: <5517951C.9050204@dancol.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org, dancol@dancol.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sun, 29 Mar 2015 00:04:51 -0600 > From: Mario Valencia > Cc: 20220@debbugs.gnu.org > > I have no idea my friend. How can I check? One way is to install 'autoruns' from Sysinternals, it shows the extensions on the Explorer tab. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 29 11:36:08 2015 Received: (at 20220) by debbugs.gnu.org; 29 Mar 2015 15:36:08 +0000 Received: from localhost ([127.0.0.1]:39743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YcFFv-0008Of-Ri for submit@debbugs.gnu.org; Sun, 29 Mar 2015 11:36:08 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:35350) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YcFFs-0008O8-UR for 20220@debbugs.gnu.org; Sun, 29 Mar 2015 11:36:06 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NLZ00M00C9RYE00@mtaout24.012.net.il> for 20220@debbugs.gnu.org; Sun, 29 Mar 2015 18:27:38 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NLZ00KOBCA22B30@mtaout24.012.net.il>; Sun, 29 Mar 2015 18:27:38 +0300 (IDT) Date: Sun, 29 Mar 2015 18:35:42 +0300 From: Eli Zaretskii Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 In-reply-to: X-012-Sender: halo1@inter.net.il To: Mario Valencia Message-id: <83mw2vzui9.fsf@gnu.org> References: X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 28 Mar 2015 17:39:38 -0600 > From: Mario Valencia > > to reproduce it, i create a small emtpy html document. then i evaluate the > following expression: > > (dotimes (i 100) (browse-url-of-file)) > > This causes emacs to start opening the file using google chrome. In the task > manager, i can see emacs' memory usage go up by about 5 megabytes each time a > tab is opened. When it opens about 30 tabs, emacs is using 138 megabytes of > memory, and it gives the error below. > the translation is something like this: "ShellExecute failed: Storage space > insufficient to process this command" > My harddrive has enough storage space btw. (The error is not about disk storage, it's about reserving the address space in virtual memory.) FWIW, I don't see such a large memory increase when I reproduce this, I see something around 1MB, sometimes 1.5MB. But I didn't try on Windows 8. Anyway, Emacs doesn't allocate any memory when it calls the ShellExecute function, so I see no way we could leak something here. My guess would be that invoking ShellExecute causes Windows to start a thread in the context of the Emacs process, and reserve 8MB of stack space for that thread. (On one of 3 systems I tried your recipe, I actually saw a thread per invocation, each thread was running some function inside shlwapi.dll, the shared library which implements the ShellExecute API.) The memory actually used by that thread for its stack is much smaller than 8MB, of course, but Windows attempts to reserve 8MB of address space for its stack. The 8MB figure comes from the way we link Emacs: we need such a large stack due to regular expressions, stack-based Lisp objects, and GC which is deeply recursive. By default, each thread reserves the same stack space as the program to which it belongs. For threads we launch in Emacs, we override the default 8MB stack space by a much smaller value, but we have no such control on threads that Windows itself starts on behalf of the Emacs process. The error message and the failure to launch too many browser tabs are caused by the fact that Emacs itself reserves about 1.7GB of the address space for its memory management, leaving only a small portion of the 2GB address space that 32-bit programs can use on Windows. Start enough threads with 8MB stack reservation, and you will run out of address space. Emacs 25 uses a different memory allocation scheme for buffers and strings, which allows to avoid the large memory reservation, so at least the out-of-memory error should happen there only after many more ShellExecute invocations (because threads started by Windows on behalf of ShellExecute will still reserve 8MB of memory for their stack). If someone knows how to force threads started by Windows to reserve less memory, without also lowering the stack space available to Emacs itself (i.e. its main thread), please tell. Otherwise, I guess we will have to live with this limitation on Windows. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 30 22:07:39 2015 Received: (at 20220) by debbugs.gnu.org; 31 Mar 2015 02:07:39 +0000 Received: from localhost ([127.0.0.1]:40780 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yclac-0002vC-LA for submit@debbugs.gnu.org; Mon, 30 Mar 2015 22:07:39 -0400 Received: from mail-la0-f50.google.com ([209.85.215.50]:33926) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YclaZ-0002uy-Uf for 20220@debbugs.gnu.org; Mon, 30 Mar 2015 22:07:37 -0400 Received: by lagg8 with SMTP id g8so2246078lag.1 for <20220@debbugs.gnu.org>; Mon, 30 Mar 2015 19:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xxdk4riFkqfu4tPM5u9Cnjm76rgvr3h3mzSwL3XgliY=; b=sC6dwRxcFjkVUOzfiHE671xVH+aKRLox7wAqvUWc94tH49MapCSYla9ziT1u62K4W6 ZXD9OGcK6011a/me3v5nKWj1IUXviWqR/7vjZCSYDP0apm9Mcd5MLEH91FiAxzs8aSCk dvZpCpbzwhOfvrHPO6BseSltLFHTDr/HCkbAXv7ucsU1ACksh33adZ3dVEu0ul/kXvLn SFP1MOZH49PTJQcqMPLLyC66/8YmUPWIwEDCXqeGZzKKT5umkVLbHUKj2nM3lQxOWcFq FqYTSJxuSNMHUhBEkH9Lkd4Z5HIURkHLw7Sr8wnNlkOqyX74jN0a04QuT3JZBSmog1Av 5VKA== MIME-Version: 1.0 X-Received: by 10.152.22.104 with SMTP id c8mr28549149laf.87.1427767650022; Mon, 30 Mar 2015 19:07:30 -0700 (PDT) Received: by 10.112.170.130 with HTTP; Mon, 30 Mar 2015 19:07:29 -0700 (PDT) In-Reply-To: <83mw2vzui9.fsf@gnu.org> References: <83mw2vzui9.fsf@gnu.org> Date: Mon, 30 Mar 2015 20:07:29 -0600 Message-ID: Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 From: Mario Valencia To: Eli Zaretskii Content-Type: multipart/alternative; boundary=089e0158ab9099fcb305128c0fd6 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e0158ab9099fcb305128c0fd6 Content-Type: text/plain; charset=UTF-8 Then the shell execute function is worthless. I had used it for opening the browser and also for opening files with an external program, or to open them in the explorer, i guess i will have to remove all use of that function from my scripts. 2015-03-29 9:35 GMT-06:00 Eli Zaretskii : > > Date: Sat, 28 Mar 2015 17:39:38 -0600 > > From: Mario Valencia > > > > to reproduce it, i create a small emtpy html document. then i evaluate > the > > following expression: > > > > (dotimes (i 100) (browse-url-of-file)) > > > > This causes emacs to start opening the file using google chrome. In the > task > > manager, i can see emacs' memory usage go up by about 5 megabytes each > time a > > tab is opened. When it opens about 30 tabs, emacs is using 138 megabytes > of > > memory, and it gives the error below. > > the translation is something like this: "ShellExecute failed: Storage > space > > insufficient to process this command" > > My harddrive has enough storage space btw. > > (The error is not about disk storage, it's about reserving the address > space in virtual memory.) > > FWIW, I don't see such a large memory increase when I reproduce this, > I see something around 1MB, sometimes 1.5MB. But I didn't try on > Windows 8. > > Anyway, Emacs doesn't allocate any memory when it calls the > ShellExecute function, so I see no way we could leak something here. > > My guess would be that invoking ShellExecute causes Windows to start a > thread in the context of the Emacs process, and reserve 8MB of stack > space for that thread. (On one of 3 systems I tried your recipe, I > actually saw a thread per invocation, each thread was running some > function inside shlwapi.dll, the shared library which implements the > ShellExecute API.) The memory actually used by that thread for its > stack is much smaller than 8MB, of course, but Windows attempts to > reserve 8MB of address space for its stack. > > The 8MB figure comes from the way we link Emacs: we need such a large > stack due to regular expressions, stack-based Lisp objects, and GC > which is deeply recursive. By default, each thread reserves the same > stack space as the program to which it belongs. For threads we launch > in Emacs, we override the default 8MB stack space by a much smaller > value, but we have no such control on threads that Windows itself > starts on behalf of the Emacs process. > > The error message and the failure to launch too many browser tabs are > caused by the fact that Emacs itself reserves about 1.7GB of the > address space for its memory management, leaving only a small portion > of the 2GB address space that 32-bit programs can use on Windows. > Start enough threads with 8MB stack reservation, and you will run out > of address space. > > Emacs 25 uses a different memory allocation scheme for buffers and > strings, which allows to avoid the large memory reservation, so at > least the out-of-memory error should happen there only after many more > ShellExecute invocations (because threads started by Windows on behalf > of ShellExecute will still reserve 8MB of memory for their stack). > > If someone knows how to force threads started by Windows to reserve > less memory, without also lowering the stack space available to Emacs > itself (i.e. its main thread), please tell. Otherwise, I guess we > will have to live with this limitation on Windows. > > --089e0158ab9099fcb305128c0fd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Then the shell execute function is worthless. I had used i= t for opening the browser and also for opening files with an external progr= am, or to open them in the explorer, i guess i will have to remove all use = of that function from my scripts.

2015-03-29 9:35 GMT-06:00 Eli Zaretskii <eliz@gnu.org= >:
> Date: Sat, 28 Mar 2015 = 17:39:38 -0600
> From: Mario Valencia <mari= ovalspi@gmail.com>
>
> to reproduce it, i create a small emtpy html document= . then i evaluate the
> following expression:
>
> (dotimes (i 100) (browse-url-of-file))
>
> This causes emacs to start opening the file using google chrome. In th= e task
> manager, i can see emacs' memory usage go up by about 5 megabytes = each time a
> tab is opened. When it opens about 30 tabs, emacs is using 138 megabyt= es of
> memory, and it gives the error below.
> the translation is something like this: "ShellExecute failed: Sto= rage space
> insufficient to process this command"
> My harddrive has enough storage space btw.

(The error is not about disk storage, it's about reserving the a= ddress
space in virtual memory.)

FWIW, I don't see such a large memory increase when I reproduce this, I see something around 1MB, sometimes 1.5MB.=C2=A0 But I didn't try on<= br> Windows 8.

Anyway, Emacs doesn't allocate any memory when it calls the
ShellExecute function, so I see no way we could leak something here.

My guess would be that invoking ShellExecute causes Windows to start a
thread in the context of the Emacs process, and reserve 8MB of stack
space for that thread.=C2=A0 (On one of 3 systems I tried your recipe, I actually saw a thread per invocation, each thread was running some
function inside shlwapi.dll, the shared library which implements the
ShellExecute API.)=C2=A0 The memory actually used by that thread for its stack is much smaller than 8MB, of course, but Windows attempts to
reserve 8MB of address space for its stack.

The 8MB figure comes from the way we link Emacs: we need such a large
stack due to regular expressions, stack-based Lisp objects, and GC
which is deeply recursive.=C2=A0 By default, each thread reserves the same<= br> stack space as the program to which it belongs.=C2=A0 For threads we launch=
in Emacs, we override the default 8MB stack space by a much smaller
value, but we have no such control on threads that Windows itself
starts on behalf of the Emacs process.

The error message and the failure to launch too many browser tabs are
caused by the fact that Emacs itself reserves about 1.7GB of the
address space for its memory management, leaving only a small portion
of the 2GB address space that 32-bit programs can use on Windows.
Start enough threads with 8MB stack reservation, and you will run out
of address space.

Emacs 25 uses a different memory allocation scheme for buffers and
strings, which allows to avoid the large memory reservation, so at
least the out-of-memory error should happen there only after many more
ShellExecute invocations (because threads started by Windows on behalf
of ShellExecute will still reserve 8MB of memory for their stack).

If someone knows how to force threads started by Windows to reserve
less memory, without also lowering the stack space available to Emacs
itself (i.e. its main thread), please tell.=C2=A0 Otherwise, I guess we
will have to live with this limitation on Windows.


--089e0158ab9099fcb305128c0fd6-- From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 31 08:46:33 2015 Received: (at 20220) by debbugs.gnu.org; 31 Mar 2015 12:46:33 +0000 Received: from localhost ([127.0.0.1]:40982 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YcvYu-0002an-Hw for submit@debbugs.gnu.org; Tue, 31 Mar 2015 08:46:32 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:63538) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YcvYs-0002aZ-0g for 20220@debbugs.gnu.org; Tue, 31 Mar 2015 08:46:30 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NM200C00TZV3000@a-mtaout22.012.net.il> for 20220@debbugs.gnu.org; Tue, 31 Mar 2015 15:46:23 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NM200B3PU5BS170@a-mtaout22.012.net.il>; Tue, 31 Mar 2015 15:46:23 +0300 (IDT) Date: Tue, 31 Mar 2015 15:46:11 +0300 From: Eli Zaretskii Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 In-reply-to: X-012-Sender: halo1@inter.net.il To: Mario Valencia Message-id: <83fv8ltjvw.fsf@gnu.org> References: <83mw2vzui9.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Mon, 30 Mar 2015 20:07:29 -0600 > From: Mario Valencia > Cc: 20220@debbugs.gnu.org > > Then the shell execute function is worthless. I had used it for opening the > browser and also for opening files with an external program, or to open them in > the explorer, i guess i will have to remove all use of that function from my > scripts. Well, it's your decision, of course. However, I think that "worthless" is too extreme, and not using it at all is too radical, even if you can do nothing in terms of your system configuration to bring down the amount of resources consumed by each invocation. One thread and 8 MB of memory is not that large, unless you really invoke that command tens or times in a row. Moreover, after reproducing your recipe on several machine, I concluded that the actual consumption of resources does somehow depend on system configuration. Out of 4 systems I tried that on, only 1 showed a 8MB increase in the memory footprint and an additional thread per invocation of w32-shell-execute; all the other systems didn't start any additional threads and their memory footprint growth was much smaller. On Windows 8.1, I actually saw no memory growth at all. So perhaps reviewing your shell extensions, like Daniel suggested, and removing those you don't need, will fix this. It is also possible that if you leave Emacs running for a long enough time after closing the URL, the thread and its memory will be released; I didn't try to investigate that. From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 31 17:04:08 2015 Received: (at 20220) by debbugs.gnu.org; 31 Mar 2015 21:04:08 +0000 Received: from localhost ([127.0.0.1]:41450 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yd3KR-0007q1-Ut for submit@debbugs.gnu.org; Tue, 31 Mar 2015 17:04:08 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:53380) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yd3KO-0007pV-Qm for 20220@debbugs.gnu.org; Tue, 31 Mar 2015 17:04:05 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGvvdVRBbthL/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCws0EhQYDSSIE6IRjCEGPQkDAQKDPgMHDINdBKg7 X-IPAS-Result: AgUFAGvvdVRBbthL/2dsb2JhbAA3gVOhb4EIgXUBAQQBViMFCws0EhQYDSSIE6IRjCEGPQkDAQKDPgMHDINdBKg7 X-IronPort-AV: E=Sophos;i="5.01,1,1400040000"; d="scan'208";a="115083170" Received: from 65-110-216-75.cpe.pppoe.ca (HELO pastel.home) ([65.110.216.75]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Mar 2015 17:03:59 -0400 Received: by pastel.home (Postfix, from userid 20848) id CBD231054; Tue, 31 Mar 2015 17:03:58 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 Message-ID: References: <83mw2vzui9.fsf@gnu.org> <83fv8ltjvw.fsf@gnu.org> Date: Tue, 31 Mar 2015 17:03:58 -0400 In-Reply-To: <83fv8ltjvw.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 31 Mar 2015 15:46:11 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org, Mario Valencia X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > It is also possible that if you leave Emacs running for a long enough > time after closing the URL, the thread and its memory will be > released; I didn't try to investigate that. Right, the question is: if there's only 1 active "ShellExecute" process at the same time (but repeated in a loop), does the memory still keep growing? If it does, we definitely have a problem. [ I suspect this has already been answered, but I haven't read this thread with enough care to find out. ] Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 31 22:19:36 2015 Received: (at 20220) by debbugs.gnu.org; 1 Apr 2015 02:19:36 +0000 Received: from localhost ([127.0.0.1]:41552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yd8Fk-0006jT-BI for submit@debbugs.gnu.org; Tue, 31 Mar 2015 22:19:36 -0400 Received: from mail-lb0-f182.google.com ([209.85.217.182]:33480) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yd8Fg-0006jF-VR for 20220@debbugs.gnu.org; Tue, 31 Mar 2015 22:19:33 -0400 Received: by lbbzk7 with SMTP id zk7so9667066lbb.0 for <20220@debbugs.gnu.org>; Tue, 31 Mar 2015 19:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YfCV6zJLzl6PKDqSGIGV5g19DbTryRakiX5fKZv1nfY=; b=SC7teq6E1qrlM9iedNUKzsv5Yp3yDxXnAJy9wE84A/8GFUVSwGSVDQrl9D4JG8UBQR mXuRjzOtlKjKDHAYusB+VHYQt3NKRDbOOSv3GQMJ7AakbKczWomEArEN+R9wFt9szACp xzhk0St0XEYWrJ907xzXMPxYb+VCQEohzldxonEgBfqZiPDWHS4tYH6N+9nNqD5mR1d7 Aob02dWyhpY16Zk2BWR877OhCdY/68wcOD3Nofi+x+gBrMEL4XWskeNThR+FWK+jJgUX nK9n+BRj9lIbK+oyfFXlamPrb0iL82MOMCA4/VoXcGF/nMPEzUH6eHqaATNiKvHIQYUc 6fkg== MIME-Version: 1.0 X-Received: by 10.152.182.172 with SMTP id ef12mr14610817lac.109.1427854767249; Tue, 31 Mar 2015 19:19:27 -0700 (PDT) Received: by 10.112.170.130 with HTTP; Tue, 31 Mar 2015 19:19:27 -0700 (PDT) In-Reply-To: References: <83mw2vzui9.fsf@gnu.org> <83fv8ltjvw.fsf@gnu.org> Date: Tue, 31 Mar 2015 20:19:27 -0600 Message-ID: Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 From: Mario Valencia To: Stefan Monnier Content-Type: multipart/alternative; boundary=001a113496a0315f150512a05805 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a113496a0315f150512a05805 Content-Type: text/plain; charset=UTF-8 > However, I think that >"worthless" is too extreme, and not using it at all is too radical, >even if you can do nothing in terms of your system configuration to >bring down the amount of resources consumed by each invocation. One >thread and 8 MB of memory is not that large, unless you really invoke >that command tens or times in a row. You are wrong. Calling shellexecute tens of times is very common. Just consider when editing an html file, saving and viewing the file may happen more than once a minute, so in less than 30 minutes it will hit the bug. Or when opening files with an external application in dired, if you open more than 30 files with shellexecute, it will hit the bug, which is not unlikely. Afterwards, after quitting the debugger, a few more times of calling the function and emacs will hang permanently. --001a113496a0315f150512a05805 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> However, I think that
>"worth= less" is too extreme, and not using it at all is too radical,>even if you can do nothing in terms of your system configura= tion to
>bring down the amount of resources consumed = by each invocation.=C2=A0 One
>thread and 8 MB of mem= ory is not that large, unless you really invoke
>that= command tens or times in a row.

You are wrong= . Calling shellexecute tens of times is very common. Just consider when edi= ting an html file, saving and viewing the file may happen more than once a = minute, so in less than 30 minutes it will hit the bug. Or when opening fil= es with an external application in dired, if you open more than 30 files wi= th shellexecute, it will hit the bug, which is not unlikely. Afterwards, af= ter quitting the debugger, a few more times of calling the function and ema= cs will hang permanently.
--001a113496a0315f150512a05805-- From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 31 22:48:09 2015 Received: (at 20220) by debbugs.gnu.org; 1 Apr 2015 02:48:09 +0000 Received: from localhost ([127.0.0.1]:41564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yd8hM-0007QO-Sr for submit@debbugs.gnu.org; Tue, 31 Mar 2015 22:48:09 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:38710) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yd8hK-0007Pt-UH for 20220@debbugs.gnu.org; Tue, 31 Mar 2015 22:48:07 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NM300400WXLAT00@mtaout26.012.net.il> for 20220@debbugs.gnu.org; Wed, 01 Apr 2015 05:48:56 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NM3002VWX5KXW10@mtaout26.012.net.il>; Wed, 01 Apr 2015 05:48:56 +0300 (IDT) Date: Wed, 01 Apr 2015 05:47:39 +0300 From: Eli Zaretskii Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 In-reply-to: X-012-Sender: halo1@inter.net.il To: Mario Valencia Message-id: <83oan8sgxg.fsf@gnu.org> References: <83mw2vzui9.fsf@gnu.org> <83fv8ltjvw.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Tue, 31 Mar 2015 20:19:27 -0600 > From: Mario Valencia > Cc: Eli Zaretskii , 20220@debbugs.gnu.org > > > However, I think that > >"worthless" is too extreme, and not using it at all is too radical, > >even if you can do nothing in terms of your system configuration to > >bring down the amount of resources consumed by each invocation. One > >thread and 8 MB of memory is not that large, unless you really invoke > >that command tens or times in a row. > > You are wrong. Calling shellexecute tens of times is very common. Just consider > when editing an html file, saving and viewing the file may happen more than > once a minute, so in less than 30 minutes it will hit the bug. You can use the browser's "refresh" function instead, don't? That's what I'd do, regardless of this problem. > Or when opening files with an external application in dired, if you > open more than 30 files with shellexecute, it will hit the bug, > which is not unlikely. Afterwards, after quitting the debugger, a > few more times of calling the function and emacs will hang > permanently. Did you actually see this problem in real life, not with your recipe? Anyway, I still think you should look at your system's configuration, since I see nothing similar to this large memory consumption on all but 1 system where I tried this. So there are factors here at work that depend on the system. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 01 03:51:04 2015 Received: (at 20220) by debbugs.gnu.org; 1 Apr 2015 07:51:04 +0000 Received: from localhost ([127.0.0.1]:41629 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YdDQW-0006b6-7U for submit@debbugs.gnu.org; Wed, 01 Apr 2015 03:51:04 -0400 Received: from dancol.org ([96.126.100.184]:53440) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YdDQT-0006ag-J2 for 20220@debbugs.gnu.org; Wed, 01 Apr 2015 03:51:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=rAQKU89UcgpkM6TDUgVoy3hg2A25jaOjK+ENVwG5EYE=; b=SK0fQS8d0eGVBTHycrGp7nTa8ZmbZ8A74bFgJz6+z4KQy22Ra0lNAvi4O04EnPw3o4tIWqkUOYV6AElI2veB9BxUwPYW9CQSTNP/H0x12x0cvJDEPn6qsbYf8pFTsyuoCzIWhu9dMe9YrADy1VVuVEGsGtqFrlGvbjOSi/0VKnqc0u7oQydXVaODfiC8vR7BB9bgvKX4k+UO0THQiN3K3lZwwQX5RU+2HKDbA/zTha2KmGKR34BTfWH2uBP5vQN1X4K8H8Ju+Gt0e1Ls4wwSu1Ms01tliZpqQFiMgX+o/w8BS9LxKbAHyi+x9X5+qXQuVTaNzuDWEvfsuBFpsOeLMA==; Received: from [166.177.250.187] (helo=[192.168.1.206]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1YdDQS-0002Ww-25; Wed, 01 Apr 2015 00:51:00 -0700 Message-ID: <551BA358.2000404@dancol.org> Date: Wed, 01 Apr 2015 00:50:48 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Eli Zaretskii , Mario Valencia Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 References: <83mw2vzui9.fsf@gnu.org> In-Reply-To: <83mw2vzui9.fsf@gnu.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XtFdhFVd4wKg1JAK3eN8x8bB3sICBhgqp" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XtFdhFVd4wKg1JAK3eN8x8bB3sICBhgqp Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/29/2015 08:35 AM, Eli Zaretskii wrote: >> Date: Sat, 28 Mar 2015 17:39:38 -0600 >> From: Mario Valencia >> >> to reproduce it, i create a small emtpy html document. then i evaluate= the >> following expression: >> >> (dotimes (i 100) (browse-url-of-file)) >> >> This causes emacs to start opening the file using google chrome. In th= e task >> manager, i can see emacs' memory usage go up by about 5 megabytes each= time a >> tab is opened. When it opens about 30 tabs, emacs is using 138 megabyt= es of >> memory, and it gives the error below. >> the translation is something like this: "ShellExecute failed: Storage = space >> insufficient to process this command" >> My harddrive has enough storage space btw. >=20 > (The error is not about disk storage, it's about reserving the address > space in virtual memory.) >=20 > FWIW, I don't see such a large memory increase when I reproduce this, > I see something around 1MB, sometimes 1.5MB. But I didn't try on > Windows 8. >=20 > Anyway, Emacs doesn't allocate any memory when it calls the > ShellExecute function, so I see no way we could leak something here. >=20 > My guess would be that invoking ShellExecute causes Windows to start a > thread in the context of the Emacs process, and reserve 8MB of stack > space for that thread. (On one of 3 systems I tried your recipe, I > actually saw a thread per invocation, each thread was running some > function inside shlwapi.dll, the shared library which implements the > ShellExecute API.) The memory actually used by that thread for its > stack is much smaller than 8MB, of course, but Windows attempts to > reserve 8MB of address space for its stack. >=20 > The 8MB figure comes from the way we link Emacs: we need such a large > stack due to regular expressions, stack-based Lisp objects, and GC > which is deeply recursive. By default, each thread reserves the same > stack space as the program to which it belongs. For threads we launch > in Emacs, we override the default 8MB stack space by a much smaller > value, but we have no such control on threads that Windows itself > starts on behalf of the Emacs process. Do we need the lisp thread to be the main thread? What about calling CreateThread very early in initialization with a large dwStackSize, leaving other threads with default-sized stacks? --XtFdhFVd4wKg1JAK3eN8x8bB3sICBhgqp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVG6NYAAoJEN4WImmbpWBlKZcP+gPOWm5g774AE81jNAnOxH1n zaxUFnhiq64sbVBv4cVIeDB8pedprc9QiNDoFBVQo6ET45e2/iG/Sg4oJKWhWFNP mdO4vsYgwJCBi5Ea//bjz11979owywacTqdTB/cCDv9AnhtCa8AR81nFXIKeFZV6 oXUOCorT9woluyQHBT0C9m2098obOJ3ehGQemYwst6+36Jh2WCsvYZqFj2dN3mlv +1k2H05CJE89MIC8+ToUF212o+4dO3sCIJyoTE1nMvFzGfrHxmwyWcZ905XNWlok /8ijjuhMz4LGtOQIvbBbg5pDdlPp/KEmz+tdGzLhRJs6kpPOWDZ3WsakBIBz8QUV xDreqCnwQTXf4+bHKDSwfwYSRHXKWohHyOKlkhDVKkS8QHOyKhdCNn5Rwrc7aFF7 W7Z97p1n3NbS1FPaz6tpltAL2NVeZctUU3RtautPs4U/EZxCq9TjuoRNdkSq7A1z D0T9cP0cFgt/42uylHnUfQgSRbxQvu8wDqpPR6ZPsCVovf1TNuyEJrMx7lRDPZoB 0LSEUho5hnQsbgzndsmrFx7nERxsJT8Jz21WJfS/R+Ovct0K9wXMn7/VjNaZk3rd FoJMMnYP9o5uSsg79RPnhaGcBGNy8Xdov2CwmmbC5IyAJbdnQM9RQ8BFj6E/7bqg cicrM/Cu/guLpyPt00OG =GQH1 -----END PGP SIGNATURE----- --XtFdhFVd4wKg1JAK3eN8x8bB3sICBhgqp-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 01 03:54:19 2015 Received: (at 20220) by debbugs.gnu.org; 1 Apr 2015 07:54:19 +0000 Received: from localhost ([127.0.0.1]:41633 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YdDTe-0006fs-U1 for submit@debbugs.gnu.org; Wed, 01 Apr 2015 03:54:19 -0400 Received: from dancol.org ([96.126.100.184]:53444) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YdDTc-0006fj-K3 for 20220@debbugs.gnu.org; Wed, 01 Apr 2015 03:54:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=wFRBgfp5dS57w4PFtDKWc95ayzBKaX1WAQBRvx0aYfA=; b=fVMTUf1FBfHiEDyFfg7unpdV9kTGi7Qm+dUWXQylfxnV/TuhCUau9M9IAV8M3u92+d5vDWgIFZiANOTvLjETexy1xZV5HEhpapTisigj422Ju4aVJBmm877uO47jB1sXCJah1AbMjZ+EiM11W8nwHW9ECBpfYKnX/cPuZr4mrhETQqGgO1RK2vhXIITQDciyZS+ix+HK869NHrxFILxHQZrXymFKRyv5eSRR7SPVibnH4cIHkz3+NPZSfIqgb+E1Nfr9rq7CavaM1qC4vDq+qdd4Fvzw2IZ8coSLDs2/SPW6CgWQQFtrRkJnsd7a1OCkYLSAp46jE/ZcsgNYssYDSQ==; Received: from [166.177.250.187] (helo=[192.168.1.206]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1YdDTa-0002Y0-IJ; Wed, 01 Apr 2015 00:54:14 -0700 Message-ID: <551BA414.40209@dancol.org> Date: Wed, 01 Apr 2015 00:53:56 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Mario Valencia , Stefan Monnier Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 References: <83mw2vzui9.fsf@gnu.org> <83fv8ltjvw.fsf@gnu.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CUeKgBf9v6IoiCSVdIf1249IhjumbRsqr" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CUeKgBf9v6IoiCSVdIf1249IhjumbRsqr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/31/2015 07:19 PM, Mario Valencia wrote: >> However, I think that >>"worthless" is too extreme, and not using it at all is too radical, >>even if you can do nothing in terms of your system configuration to >>bring down the amount of resources consumed by each invocation. One >>thread and 8 MB of memory is not that large, unless you really invoke >>that command tens or times in a row. >=20 > You are wrong. Calling shellexecute tens of times is very common. Just > consider when editing an html file, saving and viewing the file may > happen more than once a minute, so in less than 30 minutes it will hit > the bug. Or when opening files with an external application in dired, i= f > you open more than 30 files with shellexecute, it will hit the bug, > which is not unlikely. Afterwards, after quitting the debugger, a few > more times of calling the function and emacs will hang permanently. Whatever bit of code is starting a thread (or otherwise permanently consuming resources) on ShellExecute is broken, not Emacs. I don't think I've seen that behavior myself. What's the thread start function on that new thread? What's on its stack? Anyway, you should be able to work around the problem by using cmd.exe's "start" builtin, which will run ShellExecute on your behalf. --CUeKgBf9v6IoiCSVdIf1249IhjumbRsqr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVG6QUAAoJEN4WImmbpWBlDo0P/1KoHlIcLgwFJQnNrObGwJDg /HGI5uiV2AUzbQBjddWNHnFzMo81/0yKn2naUTk7/v/FTM4YK1DmoA9l9cNRrliZ RPAS253Lwg/D3WrvDGEhERbiK+GvFQPRpyH2Ju+57vxWTJQPT3spKiihLrkGFJVR ulIJph2bZWpadDOOjtkRJJUclxxWcvpDg22KpGrv2muJ9i3i96s5qtApCvZ+W/+L S4faFkJ61bOn/fqR/49nAkQUEBmkHVYH5hTcvOncp/agObxCa2wzvGT7PH0dyxPG BZqxBgs+hIvGCjvyWOt62jRLfZ5tPP1CNncJ+N105b1qm6KOxnPCCSxBqrBa4iWe yCIqXMPYIJRFTjM8WZhfd+ifnAjxRZTLDJXkPrB4dWm7gJH+A8RDekTzGFYT+flt jf4MFEf/H5Ub1ztAqq0mQt0CVGXKm7G1pumRu57YYJyVn5RRWVodIQhKD8LHkYrL BlvPEL/RhV4VGcBtswdBubDSQ139+FKmWaUi8cXYRqVWfbYwa5Co8R21/44azwgi HUI3vS7E1DCXEsugB8crs+0j83/mRGj2oW5/QoBJvvrG2coXb2VJKzTLWvGsJ0Vk R14JO5TgwKgxLDk0TqH8kt+Td1vBrXn8jX0NjxA5un98hSItJVi80LkwQ+dUWAo0 Cw9/fyebp/l5fwTAINKx =Qkim -----END PGP SIGNATURE----- --CUeKgBf9v6IoiCSVdIf1249IhjumbRsqr-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 01 10:24:33 2015 Received: (at 20220) by debbugs.gnu.org; 1 Apr 2015 14:24:33 +0000 Received: from localhost ([127.0.0.1]:42573 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YdJZI-0001i5-Ro for submit@debbugs.gnu.org; Wed, 01 Apr 2015 10:24:33 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:40858) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YdJZG-0001hm-CL for 20220@debbugs.gnu.org; Wed, 01 Apr 2015 10:24:31 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NM400J00SYIXQ00@mtaout29.012.net.il> for 20220@debbugs.gnu.org; Wed, 01 Apr 2015 17:21:31 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NM400A7RT7VFOA0@mtaout29.012.net.il>; Wed, 01 Apr 2015 17:21:31 +0300 (IDT) Date: Wed, 01 Apr 2015 17:24:01 +0300 From: Eli Zaretskii Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 In-reply-to: <83oan8sgxg.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: mariovalspi@gmail.com Message-id: <83k2xwrkou.fsf@gnu.org> References: <83mw2vzui9.fsf@gnu.org> <83fv8ltjvw.fsf@gnu.org> <83oan8sgxg.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) I've looked a bit more into this problem. A noteworthy aspect of this is that invoking w32-shell-execute like this: (dotimes (i 100) (w32-shell-execute "open" "x:/path/to/empty.html")) doesn't start any new threads in the context of the Emacs process, doesn't increase its memory footprint, and therefore doesn't fail. However, if I do this instead: (dotimes (i 100) (w32-shell-execute "open" "file:///x:/path/to/empty.html")) then I do see the same phenomena as with browse-url-of-file. So the creation of extra threads is somehow triggered by using the file:// URL (which is what browse-url-of-file does). Do you see the same on your system? Once again, I only see all this on a single system out of 4 I tried; the other 3 don't show extra threads, don't enlarge the Emacs memory footprint in any significant way, and don't fail with your original recipe. So it appears the problem is caused by some relatively rare conditions. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 01 10:26:01 2015 Received: (at 20220) by debbugs.gnu.org; 1 Apr 2015 14:26:01 +0000 Received: from localhost ([127.0.0.1]:42577 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YdJai-0001kH-Mb for submit@debbugs.gnu.org; Wed, 01 Apr 2015 10:26:00 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:44579) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YdJag-0001k3-RC for 20220@debbugs.gnu.org; Wed, 01 Apr 2015 10:25:59 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NM400900T1E9I00@mtaout25.012.net.il> for 20220@debbugs.gnu.org; Wed, 01 Apr 2015 17:20:33 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NM4004UFT69RH40@mtaout25.012.net.il>; Wed, 01 Apr 2015 17:20:33 +0300 (IDT) Date: Wed, 01 Apr 2015 17:25:10 +0300 From: Eli Zaretskii Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 In-reply-to: <551BA358.2000404@dancol.org> X-012-Sender: halo1@inter.net.il To: Daniel Colascione Message-id: <83iodgrkmx.fsf@gnu.org> References: <83mw2vzui9.fsf@gnu.org> <551BA358.2000404@dancol.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org, mariovalspi@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 01 Apr 2015 00:50:48 -0700 > From: Daniel Colascione > CC: 20220@debbugs.gnu.org > > Do we need the lisp thread to be the main thread? What about calling > CreateThread very early in initialization with a large dwStackSize, > leaving other threads with default-sized stacks? Might be possible, I don't know. For example, does any of the code make any hidden assumptions that the Lisp thread is the main thread? And in any case, if threads are created for each invocation, and never die as long as Emacs runs, then sooner or later Emacs will run out of address space and/or handles (I see on that single system where I can reproduce the problem that each such thread consumes 2 handles, and I don't see it exit). So it sounds like trying to find and fix the reason(s) for this rare behavior, or find a workaround (other than not using the API) is a better alternative, at least at this point. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 01 10:27:12 2015 Received: (at 20220) by debbugs.gnu.org; 1 Apr 2015 14:27:12 +0000 Received: from localhost ([127.0.0.1]:42581 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YdJbs-0001mV-4P for submit@debbugs.gnu.org; Wed, 01 Apr 2015 10:27:12 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:48101) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YdJbq-0001mA-Gq for 20220@debbugs.gnu.org; Wed, 01 Apr 2015 10:27:11 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NM400L00T8R2800@a-mtaout20.012.net.il> for 20220@debbugs.gnu.org; Wed, 01 Apr 2015 17:27:04 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NM400LX2TH32J00@a-mtaout20.012.net.il>; Wed, 01 Apr 2015 17:27:04 +0300 (IDT) Date: Wed, 01 Apr 2015 17:26:55 +0300 From: Eli Zaretskii Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 In-reply-to: <551BA414.40209@dancol.org> X-012-Sender: halo1@inter.net.il To: Daniel Colascione Message-id: <83h9szsz4g.fsf@gnu.org> References: <83mw2vzui9.fsf@gnu.org> <83fv8ltjvw.fsf@gnu.org> <551BA414.40209@dancol.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org, monnier@iro.umontreal.ca, mariovalspi@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 01 Apr 2015 00:53:56 -0700 > From: Daniel Colascione > Cc: 20220@debbugs.gnu.org > > Whatever bit of code is starting a thread (or otherwise permanently > consuming resources) on ShellExecute is broken, not Emacs. I don't think > I've seen that behavior myself. As I wrote, I only see something similar on one particular system out of 4 I tried this on. And I'm not yet sure what I see there is what happens on Mario's system. > What's the thread start function on that new thread? SHWLAPI.dll!IUnknown_QueryService+0x87 on my system where I see this. > What's on its stack? This: wow64win.dll+0x3fe3a wow64win.dll+0x1aeac wow64.dll!Wow64SystemServiceEx+0xd7 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x2d wow64.dll!Wow64SystemServiceEx+0x1ce wow64.dll!Wow64LdrpInitialize+0x42a ntdll.dll!RtlIsDosDeviceName_U+0x23a27 ntdll.dll!LdrInitializeThunk+0xe USER32.dll!DispatchMessageW+0x5c SHLWAPI.dll!Ordinal173+0x287b ntdll.dll!RtlInitializeExceptionChain+0x63 ntdll.dll!RtlInitializeExceptionChain+0x36 Mario, can you tell if you see similar things on your system? I suggest you verify that you have the same issue, by installing the Process Explorer and looking in the Properties for the Emacs process, in the Threads tab. There you should see a new thread created each time w32-shell-execute is invoked, and also the symbolic Start Address of each such thread. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 01 12:01:21 2015 Received: (at 20220) by debbugs.gnu.org; 1 Apr 2015 16:01:22 +0000 Received: from localhost ([127.0.0.1]:42605 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YdL4z-00042T-9E for submit@debbugs.gnu.org; Wed, 01 Apr 2015 12:01:21 -0400 Received: from dancol.org ([96.126.100.184]:55726) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YdL4w-00042K-8T for 20220@debbugs.gnu.org; Wed, 01 Apr 2015 12:01:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=xJpj3+5SU2WzID3dqJFQRM+JTSTuKCXpYxvrOLbt8bk=; b=ggO/YF+tx/UzjqOlt6XjZW5UUlnzcDLr/5QZqukvI9tE/vTmMzSJYNOqjT8+suG4dxVFJWJMm8nIpbmFHj2KXM3tiPMnJpNPqgexwi+HYjolUa1wolr/CTd0thyjeu/eco1FaoD/u99vcpLS3Tcw5GXCayOqdDgEYzDg/JAy0JKcatdj3y5de0SNQ+1A+I867K16MSIYY72UeN4SsW/KTGUQJ9PaYYYgruShn+JgWM19dXW64AmmTOgTfBjSM4KEJORWkHB5lnUzwQXeK7DfSn24xumuX7VHdSorjiwJ6lzwdPQ6WbjuwlmQrAlU6Fz/Vjze6aDOc0dSeVpE779CLQ==; Received: from [2601:8:b240:1c1::2b1] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1YdL4t-00064d-G5; Wed, 01 Apr 2015 09:01:15 -0700 Message-ID: <551C1649.4050200@dancol.org> Date: Wed, 01 Apr 2015 09:01:13 -0700 From: Daniel Colascione User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Eli Zaretskii Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 References: <83mw2vzui9.fsf@gnu.org> <83fv8ltjvw.fsf@gnu.org> <551BA414.40209@dancol.org> <83h9szsz4g.fsf@gnu.org> In-Reply-To: <83h9szsz4g.fsf@gnu.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XUEllWTCnWJjIslRCM8JgL1IQiw7SrPRk" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org, monnier@iro.umontreal.ca, mariovalspi@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XUEllWTCnWJjIslRCM8JgL1IQiw7SrPRk Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 04/01/2015 07:26 AM, Eli Zaretskii wrote: >> Date: Wed, 01 Apr 2015 00:53:56 -0700 >> From: Daniel Colascione >> Cc: 20220@debbugs.gnu.org >> >> Whatever bit of code is starting a thread (or otherwise permanently >> consuming resources) on ShellExecute is broken, not Emacs. I don't thi= nk >> I've seen that behavior myself. >=20 > As I wrote, I only see something similar on one particular system out > of 4 I tried this on. And I'm not yet sure what I see there is what > happens on Mario's system. >=20 >> What's the thread start function on that new thread? >=20 > SHWLAPI.dll!IUnknown_QueryService+0x87 on my system where I see this. >=20 >> What's on its stack? >=20 > This: >=20 > wow64win.dll+0x3fe3a > wow64win.dll+0x1aeac > wow64.dll!Wow64SystemServiceEx+0xd7 > wow64cpu.dll!TurboDispatchJumpAddressEnd+0x2d > wow64.dll!Wow64SystemServiceEx+0x1ce > wow64.dll!Wow64LdrpInitialize+0x42a > ntdll.dll!RtlIsDosDeviceName_U+0x23a27 > ntdll.dll!LdrInitializeThunk+0xe > USER32.dll!DispatchMessageW+0x5c > SHLWAPI.dll!Ordinal173+0x287b > ntdll.dll!RtlInitializeExceptionChain+0x63 > ntdll.dll!RtlInitializeExceptionChain+0x36 >=20 > Mario, can you tell if you see similar things on your system? I > suggest you verify that you have the same issue, by installing the > Process Explorer and looking in the Properties for the Emacs process, > in the Threads tab. There you should see a new thread created each > time w32-shell-execute is invoked, and also the symbolic Start Address > of each such thread. On what OS version is that thread running? --XUEllWTCnWJjIslRCM8JgL1IQiw7SrPRk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJVHBZJAAoJEN4WImmbpWBlcZMP/j7wkrbe2JRV7lNyP7Arm0M9 ZvJeUuV5cW82JerKy1kOjZvOVYpMLHcCza9vUhkBfRxksFuflOv/ba7g8scVAsmT MQz7zMcT/G0eyn1eANhoY1PXSz5ixD7nAQRgMnfRFL7m2bNMDAZxWnXoKlZXTqXS v3z4lV512A1Ax9ZP+hHPlk5+E9+XHTpgeeBVglRqJJQJzJiNe5RHXfCsHL+uWJyc N2o8Ia+jHuQqDQ2X9ybMTQxCnj2ysJ0Me1Sv+G76tanZdLYYw882K9rxceyGARZt 32C4i62OFSfOgzKuwUB9pZA+wrSTdM38lFNdi9vPIvwAefZAA/03H+nfea5n0rH2 dHe+Nx7eqW/gQyMAhdTHvr2qq7iDJ8EarYjX1L47JNR9X/KEstwhOP4CPU2AMGfY jbSPy9ZFyGW/HKCiNIBwyus6YWZMcS78eONHbg3TN+vAL+EKG4nsyMF9uGxTkmic OlbOQ2gwEi0nho0Z03OOiB1vNTf9N5ZqVcjwBX4kDO5r2Nmcllw5NXjWz9ityH3i GafGLDaY/mSXdz5zJN73ubGMXRwOd0DMpfCwPgKhOrmmUPYyBFNyMTDEJiKn1y4V V3aLUIuZ2auEXBMifeyBp4cWbtfxw85HpF9Brr803+MGLqfqWJTX/zDsIAZUds5V rNKurdwnNXh5YF7IkGgN =sCeM -----END PGP SIGNATURE----- --XUEllWTCnWJjIslRCM8JgL1IQiw7SrPRk-- From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 01 12:06:45 2015 Received: (at 20220) by debbugs.gnu.org; 1 Apr 2015 16:06:45 +0000 Received: from localhost ([127.0.0.1]:42610 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YdLAC-0004Ah-AS for submit@debbugs.gnu.org; Wed, 01 Apr 2015 12:06:44 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]:49312) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YdLA9-0004AP-5w for 20220@debbugs.gnu.org; Wed, 01 Apr 2015 12:06:42 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NM400100Y0KBX00@a-mtaout22.012.net.il> for 20220@debbugs.gnu.org; Wed, 01 Apr 2015 19:06:02 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NM40004XY21XSB0@a-mtaout22.012.net.il>; Wed, 01 Apr 2015 19:06:02 +0300 (IDT) Date: Wed, 01 Apr 2015 19:05:53 +0300 From: Eli Zaretskii Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 In-reply-to: <551C1649.4050200@dancol.org> X-012-Sender: halo1@inter.net.il To: Daniel Colascione Message-id: <83sicjrfz2.fsf@gnu.org> References: <83mw2vzui9.fsf@gnu.org> <83fv8ltjvw.fsf@gnu.org> <551BA414.40209@dancol.org> <83h9szsz4g.fsf@gnu.org> <551C1649.4050200@dancol.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org, monnier@iro.umontreal.ca, mariovalspi@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Wed, 01 Apr 2015 09:01:13 -0700 > From: Daniel Colascione > CC: mariovalspi@gmail.com, monnier@iro.umontreal.ca, > 20220@debbugs.gnu.org > > > wow64win.dll+0x3fe3a > > wow64win.dll+0x1aeac > > wow64.dll!Wow64SystemServiceEx+0xd7 > > wow64cpu.dll!TurboDispatchJumpAddressEnd+0x2d > > wow64.dll!Wow64SystemServiceEx+0x1ce > > wow64.dll!Wow64LdrpInitialize+0x42a > > ntdll.dll!RtlIsDosDeviceName_U+0x23a27 > > ntdll.dll!LdrInitializeThunk+0xe > > USER32.dll!DispatchMessageW+0x5c > > SHLWAPI.dll!Ordinal173+0x287b > > ntdll.dll!RtlInitializeExceptionChain+0x63 > > ntdll.dll!RtlInitializeExceptionChain+0x36 > > > > Mario, can you tell if you see similar things on your system? I > > suggest you verify that you have the same issue, by installing the > > Process Explorer and looking in the Properties for the Emacs process, > > in the Threads tab. There you should see a new thread created each > > time w32-shell-execute is invoked, and also the symbolic Start Address > > of each such thread. > > On what OS version is that thread running? 64-bit Windows 7. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 04 16:24:19 2015 Received: (at 20220) by debbugs.gnu.org; 4 Apr 2015 20:24:19 +0000 Received: from localhost ([127.0.0.1]:44929 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YeUc3-0000e0-JM for submit@debbugs.gnu.org; Sat, 04 Apr 2015 16:24:19 -0400 Received: from mail-lb0-f182.google.com ([209.85.217.182]:35008) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YeUc1-0000dd-Q3 for 20220@debbugs.gnu.org; Sat, 04 Apr 2015 16:24:14 -0400 Received: by lbdc10 with SMTP id c10so737148lbd.2 for <20220@debbugs.gnu.org>; Sat, 04 Apr 2015 13:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ovqWhgd82wJku80MMnvUBtUD/NASNCmNl6DZswBP/tc=; b=0i37y8YX5bb5xuOadLxDglQkLiG3G5X1Q/NGk+7NNf02eLfZO2v9rF+I8bcztgEbQP o3O4ueDIKM2l2fgQK9cngenxZ/HEE+NFl557wzFQNwRy2w6Ck0RJWfSOgA4udBV1yFRH 8IZHeHimYoJp/XOV5mMIzunaxZRJzuf2Xq81e+de3mQpZ7kZySiLqS6Kpriv21DlqeXW BCkooGwTCp3T/CpX8bvkB4Sq+DAt6kP89l8wsH18h2vRNJxnnwIigDbsskYmPwajL+hk GYT4CQituR47ld/cRGj2bgCpYkAB9hU9ghm38HCYXHKoYeaLTbPgFjSkAUigxzq9LNZi tNoA== MIME-Version: 1.0 X-Received: by 10.112.42.16 with SMTP id j16mr3658505lbl.98.1428179048010; Sat, 04 Apr 2015 13:24:08 -0700 (PDT) Received: by 10.112.170.130 with HTTP; Sat, 4 Apr 2015 13:24:07 -0700 (PDT) In-Reply-To: <83sicjrfz2.fsf@gnu.org> References: <83mw2vzui9.fsf@gnu.org> <83fv8ltjvw.fsf@gnu.org> <551BA414.40209@dancol.org> <83h9szsz4g.fsf@gnu.org> <551C1649.4050200@dancol.org> <83sicjrfz2.fsf@gnu.org> Date: Sat, 4 Apr 2015 14:24:07 -0600 Message-ID: Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 From: Mario Valencia To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a11336dccd518f90512ebd8dd X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org, Daniel Colascione , Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11336dccd518f90512ebd8dd Content-Type: text/plain; charset=UTF-8 I think the thread created is this: SHCORE.DLL!Ordinal254+0x9a0 <- start address stack: wow64cpu.dll!TurboDispatchJumpAddressEnd+0x598 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x3e4 wow64.dll!Wow64LdrpInitialize+0x23a wow64.dll!Wow64LdrpInitialize+0x172 ntdll.dll!LdrInitializeThunk+0x12b ntdll.dll!LdrInitializeThunk+0xe ntdll.dll!ZwWaitForSingleObject+0xc KERNELBASE.dll!WaitForSingleObject+0x12 ashShell.dll!Release+0xa2c2 ashShell.dll!Release+0x936b ashShell.dll!Release+0x5ada2 ashShell.dll!Release+0x448e5 ashShell.dll!Release+0x394b3 ashShell.dll!Release+0x393f5 ntdll.dll!RtlInitializeCriticalSection+0x10e ntdll.dll!RtlInitializeCriticalSection+0x88 ntdll.dll!EtwEventWrite+0x67e ntdll.dll!EtwEventWrite+0x4fb ntdll.dll!RtlInterlockedPushEntrySList+0x192 ntdll.dll!LdrUnloadDll+0x40 KERNELBASE.dll!FreeLibrary+0x19 combase.dll!InternalFillLocalOXIDInfo+0xf1d combase.dll!InternalFillLocalOXIDInfo+0x1046 combase.dll!InternalFillLocalOXIDInfo+0xffc combase.dll!CoFreeUnusedLibrariesEx+0x941 combase.dll!CoFreeUnusedLibrariesEx+0x82f combase.dll!CoFreeUnusedLibrariesEx+0x1280 combase.dll!CoUninitialize+0xb2 SHCORE.DLL!Ordinal140+0x150 ntdll.dll!RtlInitializeExceptionChain+0x8f ntdll.dll!RtlInitializeExceptionChain+0x5a also this: ashShell.dll!Release+0x9d40 <-- start address stack: wow64cpu.dll!TurboDispatchJumpAddressEnd+0x598 wow64cpu.dll!TurboDispatchJumpAddressEnd+0x3e4 wow64.dll!Wow64LdrpInitialize+0x23a wow64.dll!Wow64LdrpInitialize+0x172 ntdll.dll!LdrInitializeThunk+0x12b ntdll.dll!LdrInitializeThunk+0xe ntdll.dll!ZwWaitForSingleObject+0xc ntdll.dll!RtlInterlockedPushEntrySList+0x32b ntdll.dll!RtlInterlockedPushEntrySList+0x355 ntdll.dll!RtlDestroyMemoryBlockLookaside+0x2aca ntdll.dll!RtlExitUserThread+0x4c ntdll.dll!RtlInitializeExceptionChain+0x8f ntdll.dll!RtlInitializeExceptionChain+0x5a --001a11336dccd518f90512ebd8dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the thread created is this:
SHCORE.= DLL!Ordinal254+0x9a0 <- start address

stack:
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x598
wow64cpu.d= ll!TurboDispatchJumpAddressEnd+0x3e4
wow64.dll!Wow64LdrpInitializ= e+0x23a
wow64.dll!Wow64LdrpInitialize+0x172
ntdll.dll!L= drInitializeThunk+0x12b
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwWaitForSingleObject+0xc
KERNELBASE.dll!WaitForSingl= eObject+0x12
ashShell.dll!Release+0xa2c2
ashShell.dll!R= elease+0x936b
ashShell.dll!Release+0x5ada2
ashShell.dll= !Release+0x448e5
ashShell.dll!Release+0x394b3
ashShell.= dll!Release+0x393f5
ntdll.dll!RtlInitializeCriticalSection+0x10e<= /div>
ntdll.dll!RtlInitializeCriticalSection+0x88
ntdll.dll!E= twEventWrite+0x67e
ntdll.dll!EtwEventWrite+0x4fb
ntdll.= dll!RtlInterlockedPushEntrySList+0x192
ntdll.dll!LdrUnloadDll+0x4= 0
KERNELBASE.dll!FreeLibrary+0x19
combase.dll!InternalF= illLocalOXIDInfo+0xf1d
combase.dll!InternalFillLocalOXIDInfo+0x10= 46
combase.dll!InternalFillLocalOXIDInfo+0xffc
combase.= dll!CoFreeUnusedLibrariesEx+0x941
combase.dll!CoFreeUnusedLibrari= esEx+0x82f
combase.dll!CoFreeUnusedLibrariesEx+0x1280
c= ombase.dll!CoUninitialize+0xb2
SHCORE.DLL!Ordinal140+0x150
<= div>ntdll.dll!RtlInitializeExceptionChain+0x8f
ntdll.dll!RtlIniti= alizeExceptionChain+0x5a

also this:
ashShell.dll!= Release+0x9d40 <-- start address
stack:
wow64cpu.dll!Tur= boDispatchJumpAddressEnd+0x598
wow64cpu.dll= !TurboDispatchJumpAddressEnd+0x3e4
wow64.dl= l!Wow64LdrpInitialize+0x23a
wow64.dll!Wow64= LdrpInitialize+0x172
ntdll.dll!LdrInitializ= eThunk+0x12b
ntdll.dll!LdrInitializeThunk+0= xe
ntdll.dll!ZwWaitForSingleObject+0xc
ntdll.dll!RtlInterlockedPushEntrySList+0x32b
ntdll.dll!RtlInterlockedPushEntrySList+0x355<= /div>
ntdll.dll!RtlDestroyMemoryBlockLookaside+0x= 2aca
ntdll.dll!RtlExitUserThread+0x4c
=
ntdll.dll!RtlInitializeExceptionChain+0x8f
=
ntdll.dll!RtlInitializeExceptionChain+0x5a
=

--001a11336dccd518f90512ebd8dd-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 04 17:19:15 2015 Received: (at 20220) by debbugs.gnu.org; 4 Apr 2015 21:19:15 +0000 Received: from localhost ([127.0.0.1]:44946 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YeVTG-0002pb-TL for submit@debbugs.gnu.org; Sat, 04 Apr 2015 17:19:15 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:35172) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YeVTE-0002pC-J1 for 20220@debbugs.gnu.org; Sat, 04 Apr 2015 17:19:13 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NMA00B00WC30D00@mtaout26.012.net.il> for 20220@debbugs.gnu.org; Sun, 05 Apr 2015 00:20:17 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NMA002GUWLT2K80@mtaout26.012.net.il>; Sun, 05 Apr 2015 00:20:17 +0300 (IDT) Date: Sun, 05 Apr 2015 00:19:07 +0300 From: Eli Zaretskii Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 In-reply-to: X-012-Sender: halo1@inter.net.il To: Mario Valencia Message-id: <83a8ynoalw.fsf@gnu.org> References: <83mw2vzui9.fsf@gnu.org> <83fv8ltjvw.fsf@gnu.org> <551BA414.40209@dancol.org> <83h9szsz4g.fsf@gnu.org> <551C1649.4050200@dancol.org> <83sicjrfz2.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org, dancol@dancol.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Sat, 4 Apr 2015 14:24:07 -0600 > From: Mario Valencia > Cc: Daniel Colascione , Stefan Monnier , 20220@debbugs.gnu.org > > I think the thread created is this: > SHCORE.DLL!Ordinal254+0x9a0 <- start address SHCORE.dll sounds like a Windows 8 version of shlwapi.dll, or maybe a part of it. So this looks very similar to what I saw on that single Windows 7 system. Do you also see that the problem happens only if w32-shell-execute is called with a file:/// URL, and does not happen if it is called with a normal Windows file name? From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 10 07:16:55 2015 Received: (at 20220) by debbugs.gnu.org; 10 Apr 2015 11:16:56 +0000 Received: from localhost ([127.0.0.1]:51873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgWvf-00028g-5e for submit@debbugs.gnu.org; Fri, 10 Apr 2015 07:16:55 -0400 Received: from mail-la0-f51.google.com ([209.85.215.51]:34468) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgWvc-00028F-U0 for 20220@debbugs.gnu.org; Fri, 10 Apr 2015 07:16:53 -0400 Received: by laat2 with SMTP id t2so10747249laa.1 for <20220@debbugs.gnu.org>; Fri, 10 Apr 2015 04:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w4oc1CrL3F7vnXXmtu0uPPkonPzYo/E1fM4wgTRJbdE=; b=w8tqFufDPTtm6Rxv0IdAi0ey5eG44tJw5ORrhMukP1FfYCoDjxHL+UH/qXDbsvWX1s T8pY8enYuctocNKN1sy9xzN9HlaINDx+rcHOaWr+/dCN0TbXOM51YoYzth2K8WFqestG S+RiGJ3h3LfImKaDBIKIGvrAaj0z4o9M2VVl1zTJo3NIsEIaPRv/BjbBRub6xifUwnHh g2oP3RcuIjKizTcDau3az4h3BxCulr5r2Mal8VzjhvI3WxR6RCLVv2s8DfIB9aD4hIfL b2x+EXvEGrcTA1U7cnmSIE0XnO6BR1LMgv8qtLJrqAtp6ywOMKKCAEBqc2h8wc1f8F8U IKOg== MIME-Version: 1.0 X-Received: by 10.152.21.8 with SMTP id r8mr957355lae.98.1428664607038; Fri, 10 Apr 2015 04:16:47 -0700 (PDT) Received: by 10.112.170.130 with HTTP; Fri, 10 Apr 2015 04:16:46 -0700 (PDT) In-Reply-To: <83a8ynoalw.fsf@gnu.org> References: <83mw2vzui9.fsf@gnu.org> <83fv8ltjvw.fsf@gnu.org> <551BA414.40209@dancol.org> <83h9szsz4g.fsf@gnu.org> <551C1649.4050200@dancol.org> <83sicjrfz2.fsf@gnu.org> <83a8ynoalw.fsf@gnu.org> Date: Fri, 10 Apr 2015 06:16:46 -0500 Message-ID: Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 From: Mario Valencia To: Eli Zaretskii Content-Type: multipart/alternative; boundary=089e0141a49867e03c05135ce66a X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org, Daniel Colascione , Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e0141a49867e03c05135ce66a Content-Type: text/plain; charset=UTF-8 You are correct; the problem only happens with a file:/// url. The following executes without problem and emacs memory stays constant: (dotimes (i 100) (w32-shell-execute "open" "c:/users/mario/desktop/x.html")) With a file:/// url it triggers the bug: (dotimes (i 100) (w32-shell-execute "open" "file:///c:/users/mario/desktop/x.html")) 2015-04-04 15:19 GMT-06:00 Eli Zaretskii : > > Date: Sat, 4 Apr 2015 14:24:07 -0600 > > From: Mario Valencia > > Cc: Daniel Colascione , Stefan Monnier < > monnier@iro.umontreal.ca>, 20220@debbugs.gnu.org > > > > I think the thread created is this: > > SHCORE.DLL!Ordinal254+0x9a0 <- start address > > SHCORE.dll sounds like a Windows 8 version of shlwapi.dll, or maybe a > part of it. So this looks very similar to what I saw on that single > Windows 7 system. > > Do you also see that the problem happens only if w32-shell-execute is > called with a file:/// URL, and does not happen if it is called with a > normal Windows file name? > --089e0141a49867e03c05135ce66a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You are correct; the problem only happens with a file= :/// url. The following executes without problem and emacs memory stays con= stant:
(dotimes (i 100) (w32-shell-execute "open" "c:/u= sers/mario/desktop/x.html"))
With a file:/// url it triggers the b= ug:
(dotimes (i 100) (w32-shell-execute "open" "fi= le:///c:/users/mario/desktop/x.html"))

2015-04-04 15:19 GMT-06:00 Eli Za= retskii <eliz@gnu.org>:
> Da= te: Sat, 4 Apr 2015 14:24:07 -0600
> From: Mario Valencia <mari= ovalspi@gmail.com>
> Cc: Daniel Colascione <dancol@= dancol.org>, Stefan Monnier <monnier@iro.umontreal.ca>, 20220@debbugs.gnu.org
>
> I think the thread created is this:
> SHCORE.DLL!Ordinal254+0x9a0 <- start address

SHCORE.dll sounds like a Windows 8 version of shlwapi.dll, or maybe = a
part of it.=C2=A0 So this looks very similar to what I saw on that single Windows 7 system.

Do you also see that the problem happens only if w32-shell-execute is
called with a file:/// URL, and does not happen if it is called with a
normal Windows file name?

--089e0141a49867e03c05135ce66a-- From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 10 07:24:27 2015 Received: (at 20220) by debbugs.gnu.org; 10 Apr 2015 11:24:27 +0000 Received: from localhost ([127.0.0.1]:51883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgX2w-0002La-PR for submit@debbugs.gnu.org; Fri, 10 Apr 2015 07:24:27 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:49868) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgX2u-0002LL-8A for 20220@debbugs.gnu.org; Fri, 10 Apr 2015 07:24:25 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NML00A00836RW00@mtaout27.012.net.il> for 20220@debbugs.gnu.org; Fri, 10 Apr 2015 14:19:13 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NML004QI8S0LW70@mtaout27.012.net.il>; Fri, 10 Apr 2015 14:19:13 +0300 (IDT) Date: Fri, 10 Apr 2015 14:24:18 +0300 From: Eli Zaretskii Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 In-reply-to: X-012-Sender: halo1@inter.net.il To: Mario Valencia Message-id: <83mw2gtee5.fsf@gnu.org> References: <83mw2vzui9.fsf@gnu.org> <83fv8ltjvw.fsf@gnu.org> <551BA414.40209@dancol.org> <83h9szsz4g.fsf@gnu.org> <551C1649.4050200@dancol.org> <83sicjrfz2.fsf@gnu.org> <83a8ynoalw.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org, dancol@dancol.org, monnier@iro.umontreal.ca X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 10 Apr 2015 06:16:46 -0500 > From: Mario Valencia > Cc: Daniel Colascione , Stefan Monnier , 20220@debbugs.gnu.org > > You are correct; the problem only happens with a file:/// url. The following > executes without problem and emacs memory stays constant: > (dotimes (i 100) (w32-shell-execute "open" "c:/users/mario/desktop/x.html")) > With a file:/// url it triggers the bug: > (dotimes (i 100) (w32-shell-execute "open" > "file:///c:/users/mario/desktop/x.html")) Thanks, that's good to know. So I think the solution is to change w32-shell-execute to convert file:/// URLs into the normal file-name format internally, and use that in the call to ShellExecute. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 10 07:30:02 2015 Received: (at 20220) by debbugs.gnu.org; 10 Apr 2015 11:30:03 +0000 Received: from localhost ([127.0.0.1]:51887 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgX8L-0002UT-B6 for submit@debbugs.gnu.org; Fri, 10 Apr 2015 07:30:02 -0400 Received: from mtaout24.012.net.il ([80.179.55.180]:58888) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgX8I-0002Ts-BZ for 20220@debbugs.gnu.org; Fri, 10 Apr 2015 07:29:59 -0400 Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NML00L008SQ8K00@mtaout24.012.net.il> for 20220@debbugs.gnu.org; Fri, 10 Apr 2015 14:21:19 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NML00L4Y8VJFX00@mtaout24.012.net.il>; Fri, 10 Apr 2015 14:21:19 +0300 (IDT) Date: Fri, 10 Apr 2015 14:29:52 +0300 From: Eli Zaretskii Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 In-reply-to: <83mw2gtee5.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: mariovalspi@gmail.com Message-id: <83lhi0te4v.fsf@gnu.org> References: <83mw2vzui9.fsf@gnu.org> <83fv8ltjvw.fsf@gnu.org> <551BA414.40209@dancol.org> <83h9szsz4g.fsf@gnu.org> <551C1649.4050200@dancol.org> <83sicjrfz2.fsf@gnu.org> <83a8ynoalw.fsf@gnu.org> <83mw2gtee5.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 10 Apr 2015 14:24:18 +0300 > From: Eli Zaretskii > Cc: 20220@debbugs.gnu.org > > So I think the solution is to change w32-shell-execute to convert > file:/// URLs into the normal file-name format internally, and use > that in the call to ShellExecute. Btw, until that change is made, you can make an equivalent change in browse-url.el, e.g. by providing a trivial wrapper for w32-shell-execute. Then you will have the problem solved in the same binary you already have. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 10 07:33:53 2015 Received: (at 20220) by debbugs.gnu.org; 10 Apr 2015 11:33:53 +0000 Received: from localhost ([127.0.0.1]:51891 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgXC4-00041b-Co for submit@debbugs.gnu.org; Fri, 10 Apr 2015 07:33:52 -0400 Received: from mail-lb0-f178.google.com ([209.85.217.178]:35872) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgXC2-00041N-6I for 20220@debbugs.gnu.org; Fri, 10 Apr 2015 07:33:50 -0400 Received: by lbbqq2 with SMTP id qq2so11311564lbb.3 for <20220@debbugs.gnu.org>; Fri, 10 Apr 2015 04:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KgVQ1gu665YdTDL18sYTy+LRWtsOfKwSNncm8Kzh2/4=; b=Egm6VTgNABRx+F9sxrjlLp+AvmEqNLFl3Ct+dD2ULg48LYkCFz9DDz/n14eN3V4/h9 HLX1DObljiMAvqUuBCGLBlYM9Df720m7O3G6Tj3bjzSqlq7A6btZLwDLSg/lXDopHZbo PDRbH1lG1+VDaYxHJwRDHzaQgO5ve1PT6A6evEoHmfJTuyUvc6Du8kk1XQy8ZqfNehjX 95DEKsI8FvSLvRs4h3zU9gtnU+brDl0wXrDjJVqp9NHfFBwatA3TrjTjOzgwwSsqjout OLFnkwZVEfObzwHvh6ydqJWmTjlQygDLSKMUiGX3StbrY0uMcptgjab+DbWZLVHNlh0o l7wQ== MIME-Version: 1.0 X-Received: by 10.112.8.101 with SMTP id q5mr1036689lba.19.1428665624264; Fri, 10 Apr 2015 04:33:44 -0700 (PDT) Received: by 10.112.170.130 with HTTP; Fri, 10 Apr 2015 04:33:44 -0700 (PDT) In-Reply-To: <83lhi0te4v.fsf@gnu.org> References: <83mw2vzui9.fsf@gnu.org> <83fv8ltjvw.fsf@gnu.org> <551BA414.40209@dancol.org> <83h9szsz4g.fsf@gnu.org> <551C1649.4050200@dancol.org> <83sicjrfz2.fsf@gnu.org> <83a8ynoalw.fsf@gnu.org> <83mw2gtee5.fsf@gnu.org> <83lhi0te4v.fsf@gnu.org> Date: Fri, 10 Apr 2015 06:33:44 -0500 Message-ID: Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 From: Mario Valencia To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a1134df9609858305135d2320 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a1134df9609858305135d2320 Content-Type: text/plain; charset=UTF-8 Thx, I will. It would also be nice to know what causes the bug, rather than just fixing it by workaround tho. 2015-04-10 6:29 GMT-05:00 Eli Zaretskii : > > Date: Fri, 10 Apr 2015 14:24:18 +0300 > > From: Eli Zaretskii > > Cc: 20220@debbugs.gnu.org > > > > So I think the solution is to change w32-shell-execute to convert > > file:/// URLs into the normal file-name format internally, and use > > that in the call to ShellExecute. > > Btw, until that change is made, you can make an equivalent change in > browse-url.el, e.g. by providing a trivial wrapper for > w32-shell-execute. Then you will have the problem solved in the same > binary you already have. > --001a1134df9609858305135d2320 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thx, I will. It would also be nice to know what causes the= bug, rather than just fixing it by workaround tho.=C2=A0

2015-04-10 6:29 GMT-05:00 E= li Zaretskii <eliz@gnu.org>:
= > Date: Fri, 10 Apr 2015 14:24:18 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 20220@debbugs.gnu.org=
>
> So I think the solution is to change w32-shell-execute to convert
> file:/// URLs into the normal file-name format internally, and use
> that in the call to ShellExecute.

Btw, until that change is made, you can make an equivalent change in=
browse-url.el, e.g. by providing a trivial wrapper for
w32-shell-execute.=C2=A0 Then you will have the problem solved in the same<= br> binary you already have.

--001a1134df9609858305135d2320-- From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 10 07:36:50 2015 Received: (at 20220) by debbugs.gnu.org; 10 Apr 2015 11:36:50 +0000 Received: from localhost ([127.0.0.1]:51896 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgXEv-00046J-93 for submit@debbugs.gnu.org; Fri, 10 Apr 2015 07:36:49 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:38405) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgXEs-000464-H9 for 20220@debbugs.gnu.org; Fri, 10 Apr 2015 07:36:47 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NML00N009ABGK00@mtaout26.012.net.il> for 20220@debbugs.gnu.org; Fri, 10 Apr 2015 14:37:59 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NML00N0M9NB0220@mtaout26.012.net.il>; Fri, 10 Apr 2015 14:37:59 +0300 (IDT) Date: Fri, 10 Apr 2015 14:36:40 +0300 From: Eli Zaretskii Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 In-reply-to: X-012-Sender: halo1@inter.net.il To: Mario Valencia Message-id: <83k2xktdtj.fsf@gnu.org> References: <83mw2vzui9.fsf@gnu.org> <83fv8ltjvw.fsf@gnu.org> <551BA414.40209@dancol.org> <83h9szsz4g.fsf@gnu.org> <551C1649.4050200@dancol.org> <83sicjrfz2.fsf@gnu.org> <83a8ynoalw.fsf@gnu.org> <83mw2gtee5.fsf@gnu.org> <83lhi0te4v.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 10 Apr 2015 06:33:44 -0500 > From: Mario Valencia > Cc: 20220@debbugs.gnu.org > > It would also be nice to know what causes the bug, rather than just > fixing it by workaround tho. I agree. I tried googling for similar issues, but everything that came up was either not relevant or described real memory leaks in other people's code. If you or someone else can find any documentation on this strange phenomenon, please tell. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 10 08:59:02 2015 Received: (at 20220) by debbugs.gnu.org; 10 Apr 2015 12:59:02 +0000 Received: from localhost ([127.0.0.1]:51935 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgYWT-0006Fb-Kv for submit@debbugs.gnu.org; Fri, 10 Apr 2015 08:59:01 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:43057) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgYWQ-0006FG-Gb for 20220@debbugs.gnu.org; Fri, 10 Apr 2015 08:58:59 -0400 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t3ACwuPv017403; Fri, 10 Apr 2015 08:58:56 -0400 Received: by pastel.home (Postfix, from userid 20848) id 11E961FC7; Fri, 10 Apr 2015 08:58:56 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 Message-ID: References: <83mw2vzui9.fsf@gnu.org> <83fv8ltjvw.fsf@gnu.org> <551BA414.40209@dancol.org> <83h9szsz4g.fsf@gnu.org> <551C1649.4050200@dancol.org> <83sicjrfz2.fsf@gnu.org> <83a8ynoalw.fsf@gnu.org> <83mw2gtee5.fsf@gnu.org> <83lhi0te4v.fsf@gnu.org> <83k2xktdtj.fsf@gnu.org> Date: Fri, 10 Apr 2015 08:58:56 -0400 In-Reply-To: <83k2xktdtj.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 10 Apr 2015 14:36:40 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5271=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5271> : inlines <2674> : streams <1420049> : uri <1903202> X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org, Mario Valencia X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > I agree. I tried googling for similar issues, but everything that > came up was either not relevant or described real memory leaks in > other people's code. Maybe posting a question to a forum/mailinglist could get us a better answer. Not sure what forum/mailinglist would have the right people, tho. Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 10 09:13:43 2015 Received: (at 20220) by debbugs.gnu.org; 10 Apr 2015 13:13:43 +0000 Received: from localhost ([127.0.0.1]:51941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgYkh-0006d9-Fj for submit@debbugs.gnu.org; Fri, 10 Apr 2015 09:13:43 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:47854) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YgYke-0006cr-DD for 20220@debbugs.gnu.org; Fri, 10 Apr 2015 09:13:41 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NML00G00DL4RV00@mtaout26.012.net.il> for 20220@debbugs.gnu.org; Fri, 10 Apr 2015 16:14:53 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NML009JRE4TRA80@mtaout26.012.net.il>; Fri, 10 Apr 2015 16:14:53 +0300 (IDT) Date: Fri, 10 Apr 2015 16:13:34 +0300 From: Eli Zaretskii Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83egnst9c1.fsf@gnu.org> References: <83mw2vzui9.fsf@gnu.org> <83fv8ltjvw.fsf@gnu.org> <551BA414.40209@dancol.org> <83h9szsz4g.fsf@gnu.org> <551C1649.4050200@dancol.org> <83sicjrfz2.fsf@gnu.org> <83a8ynoalw.fsf@gnu.org> <83mw2gtee5.fsf@gnu.org> <83lhi0te4v.fsf@gnu.org> <83k2xktdtj.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20220 Cc: 20220@debbugs.gnu.org, mariovalspi@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Not sure what forum/mailinglist would have the right people, tho. Neither am I. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 23 03:18:35 2015 Received: (at 20220-done) by debbugs.gnu.org; 23 Apr 2015 07:18:35 +0000 Received: from localhost ([127.0.0.1]:37063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlBP9-0001UX-6X for submit@debbugs.gnu.org; Thu, 23 Apr 2015 03:18:35 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:36794) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YlBP7-0001U2-1u for 20220-done@debbugs.gnu.org; Thu, 23 Apr 2015 03:18:34 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NN900D0000DYB00@a-mtaout20.012.net.il> for 20220-done@debbugs.gnu.org; Thu, 23 Apr 2015 10:18:26 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN900DMH0AQVU40@a-mtaout20.012.net.il>; Thu, 23 Apr 2015 10:18:26 +0300 (IDT) Date: Thu, 23 Apr 2015 10:18:27 +0300 From: Eli Zaretskii Subject: Re: bug#20220: severe memory leak on emacs 24.4.1 In-reply-to: <83mw2gtee5.fsf@gnu.org> X-012-Sender: halo1@inter.net.il To: mariovalspi@gmail.com Message-id: <834mo72tz0.fsf@gnu.org> References: <83mw2vzui9.fsf@gnu.org> <83fv8ltjvw.fsf@gnu.org> <551BA414.40209@dancol.org> <83h9szsz4g.fsf@gnu.org> <551C1649.4050200@dancol.org> <83sicjrfz2.fsf@gnu.org> <83a8ynoalw.fsf@gnu.org> <83mw2gtee5.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 20220-done Cc: 20220-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Fri, 10 Apr 2015 14:24:18 +0300 > From: Eli Zaretskii > Cc: 20220@debbugs.gnu.org > > > Date: Fri, 10 Apr 2015 06:16:46 -0500 > > From: Mario Valencia > > Cc: Daniel Colascione , Stefan Monnier , 20220@debbugs.gnu.org > > > > You are correct; the problem only happens with a file:/// url. The following > > executes without problem and emacs memory stays constant: > > (dotimes (i 100) (w32-shell-execute "open" "c:/users/mario/desktop/x.html")) > > With a file:/// url it triggers the bug: > > (dotimes (i 100) (w32-shell-execute "open" > > "file:///c:/users/mario/desktop/x.html")) > > Thanks, that's good to know. > > So I think the solution is to change w32-shell-execute to convert > file:/// URLs into the normal file-name format internally, and use > that in the call to ShellExecute. Now done in the development sources for Emacs 25.1 (commit f2e2cd5). I'm closing this bug. Feel free to reopen if some new information emerges about this. From unknown Wed Jun 18 00:08:34 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 21 May 2015 11:24:07 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator