From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.bugs Subject: bug#20220: severe memory leak on emacs 24.4.1 Date: Wed, 01 Apr 2015 00:50:48 -0700 Message-ID: <551BA358.2000404@dancol.org> References: <83mw2vzui9.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XtFdhFVd4wKg1JAK3eN8x8bB3sICBhgqp" X-Trace: ger.gmane.org 1427874760 543 80.91.229.3 (1 Apr 2015 07:52:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Apr 2015 07:52:40 +0000 (UTC) Cc: 20220@debbugs.gnu.org To: Eli Zaretskii , Mario Valencia Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Apr 01 09:52:25 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YdDRj-0006Zf-Mu for geb-bug-gnu-emacs@m.gmane.org; Wed, 01 Apr 2015 09:52:20 +0200 Original-Received: from localhost ([::1]:41968 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdDRe-0004pK-4I for geb-bug-gnu-emacs@m.gmane.org; Wed, 01 Apr 2015 03:52:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59959) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdDRa-0004o2-39 for bug-gnu-emacs@gnu.org; Wed, 01 Apr 2015 03:52:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdDRS-0002Az-Mi for bug-gnu-emacs@gnu.org; Wed, 01 Apr 2015 03:52:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51853) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdDRS-0002AF-FM for bug-gnu-emacs@gnu.org; Wed, 01 Apr 2015 03:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YdDRS-0006cP-01 for bug-gnu-emacs@gnu.org; Wed, 01 Apr 2015 03:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Apr 2015 07:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20220 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20220-submit@debbugs.gnu.org id=B20220.142787466425368 (code B ref 20220); Wed, 01 Apr 2015 07:52:01 +0000 Original-Received: (at 20220) by debbugs.gnu.org; 1 Apr 2015 07:51:04 +0000 Original-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 Original-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==; Original-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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 In-Reply-To: <83mw2vzui9.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:101103 Archived-At: 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--