GNU bug report logs -
#20220
severe memory leak on emacs 24.4.1
Previous Next
Full log
Message #35 received at 20220 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 03/29/2015 08:35 AM, Eli Zaretskii wrote:
>> Date: Sat, 28 Mar 2015 17:39:38 -0600
>> From: Mario Valencia <mariovalspi <at> 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 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.
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?
[signature.asc (application/pgp-signature, attachment)]
This bug report was last modified 10 years and 29 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.