bug#13546: 24.2.92; Error(s) when sending emails

[Eli Zaretskii]

> From: "Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com>
> Cc: Sebastien Vauban <wxhgmqzgwmuf@spammotel.com>,  13546@debbugs.gnu.org
> Date: Fri, 15 Feb 2013 16:15:01 +0100
> 
> - What about that magical `C-v' character?  Any idea?

No idea.  It doesn't seem to be related to the problem, though.

> - Now that you know what the problem was, can you confirm that Emacs 23 did
>   behave well for my use case?  Maybe Emacs 24.0 as well?

Emacs 23 concealed the problem: it would let you continue invoking
subprocesses, but with every Locate subprocesses launched by Helm,
Emacs would leak 2 handles.  After some time (longer than the 2-3
hours you got with 24.2.9x), too many handles would have been lost,
and Emacs would become unusable.  Moreover, since the OS cannot reuse
a process ID of a process which still has some handle open on it, the
entire system would become unusable, because it could no longer launch
processes.

In v24.2.91, this handle leakage was plumbed, but doing so exhibited
another problem (which was already fixed on the trunk, btw), which
manifested itself in what you described.  Note that this problem only
rears its ugly head whenever an async subprocess is launched and then
killed without letting it exit in an orderly manner.  That is why no
one else reported the problem: I guess there are no more Helm users on
Windows who track the v24.3 pretests.

> - Is the current problem only happening on Windows (or due to my shell
>   setting)?

It is specific to Windows, but is not related to any shell settings.
It happens every time an async subprocess is killed by calling
delete-process on it.

> - Is it only with heavy process-creator users like me (by using Helm as my
>   almost only way to switch between buffers and files)?

See above: delete-process is the main trigger.  It prevents a slot
from being released in the array which Emacs on Windows uses to manage
subprocesses and network/serial connections.  When all the 32 slots
are used up in this way, Emacs can no longer launch subprocesses or
open network connections.

The code I added looks for these "lost" slots and releases them, so
that they can be reused.  On the trunk, the problem is avoided
altogether, but that requires deeper changes in the related code, and
I'd rather not make them at this late stage of the pretest.

> - Can you confirm the GDB command had to be "p *cp" and not "b *cp"?

Yes, of course.  Sorry.