[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "resource temporarily unavailable" errors on windows 7

From: Alex Harsanyi
Subject: Re: "resource temporarily unavailable" errors on windows 7
Date: Wed, 14 Mar 2012 12:27:31 +0800

2012/3/14 Eli Zaretskii <address@hidden>:

> So this can happen due to error either in one of the two calls to
> CreateEvent or in the call to CreateThread.  My crystal ball bets on
> the latter, but could you please verify that this is the problem?  If
> it is, please add a call to GetLastError there and see which error
> code is returned.

Indeed it fails on the CreateThread call, GetLastError returns 8: "Not
enough storage is available to process this command. "

> Assuming it's CreateThread that fails, the obvious suspicion would be
> that it fails because creating a thread reserves some memory for its
> stack.  The call above is careful to override the amount of stack
> memory that is actually _committed_ and sets it at a mere 1KB, but the
> memory _reserved_ for the stack is still 1MB, according to MSDN.
> Question: does the problem happen right when you invoke the first
> subprocess, or only after several subprocesses are already running,
> and you try to invoke another one?

It does not happen all the time, I'd say about 1 out of 4 tries for a
`M-x diff-backup RET' call.  In terms of running processes,
(process-list) returns:

    (#<process ielm> #<process cleartool> #<process edit-server>
#<process server>)

BTW, it also happens when I run "emacs -Q", but less often, although
when I tested the CreateThread failure, I run emacs -Q under gdb and
it failed on the third try.

> Also, can you use the VMMap utility (from Sysinternals) and tell what
> it shows in the "Private Data", "Thread Stack", and "Free" categories,
> when you run Emacs with the original code in allocate_heap, after you
> get the error message?  Can you spot, in particular, how much memory
> is reserved  and committed for Emacs and for the additional thread it
> starts in new_child?

I attached the VMMap for the Emacs processs, right after a failure.

On an "Emacs -Q" process, I have:

  Stack                49'152K  (224K commited)
  Private Data   1'796'128K  (2'136K commited)
  Free                142'528K

Each time I start a shell process "M-x shell" (I rename the buffers,
so I have multiple shells running), the stack reserved size grows by
about 8Mb, the commited size by about 12K and the free memory
decreases by 8Mb.  The Private Data commited size also changes by a
few KB.

When I start emacs normally (reading the init files), the Free section
has 47'224K and decreases by 8Mb for each shell process I start (Stack
increases accordingly).

I also noticed that spontaneously, the Stack reserved size grows by
about 10-12Mb (Free section decreases accordingly), than the memory is
released a few seconds later.  By spontaneous, I mean that I don't
interact with the Emacs session, I just hit refresh on the VMMap
application.  This happens also when I start emacs with "emacs -Q".


Attachment: emacs-vmmap.zip
Description: Zip archive

reply via email to

[Prev in Thread] Current Thread [Next in Thread]