Handle leak in sb-ext:run-program on Windows

[Eitaro Fukamachi]

Calling sb-ext:run-program creates a new handle and keeps it even after the process exited on Windows.

## Reproducible Flow

1. Create a file run-wmic.lisp

;; run-wmic.lisp
(loop
 (sb-ext:run-program "C:\\Windows\\System32\\Wbem\\WMIC.exe"
                     '("Path" "Win32_Battery" "Get" "EstimatedChargeRemaining"))
 (princ ".") (force-output)
 (sleep 1))

2. Load it with SBCL
$ sbcl --load run-wmic.lisp

3. Check the number of handles with Task Manager

## Environment

SBCL 1.3.15
Windows 10 Home
*features*
(:QUICKLISP :QUICKLISP-SUPPORT-HTTPS :ASDF-PACKAGE-SYSTEM :ASDF3.1 :ASDF3
 :ASDF2 :ASDF :OS-WINDOWS :NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :ROS.INIT
 :64-BIT :64-BIT-REGISTERS :ALIEN-CALLBACKS :ANSI-CL :ASH-RIGHT-VOPS
 :C-STACK-IS-CONTROL-STACK :COMMON-LISP :COMPARE-AND-SWAP-VOPS
 :COMPLEX-FLOAT-VOPS :CYCLE-COUNTER :FLOAT-EQL-VOPS :FP-AND-PC-STANDARD-SAVE
 :GENCGC :IEEE-FLOATING-POINT :INLINE-CONSTANTS :INTEGER-EQL-VOP :LINKAGE-TABLE
 :LITTLE-ENDIAN :MEMORY-BARRIER-VOPS :MULTIPLY-HIGH-VOPS :OS-PROVIDES-DLOPEN
 :OS-PROVIDES-PUTWC :PACKAGE-LOCAL-NICKNAMES :PRECISE-ARG-COUNT-ERROR
 :RAW-INSTANCE-INIT-VOPS :RAW-SIGNED-WORD :SB-DOC :SB-DYNAMIC-CORE :SB-EVAL
 :SB-FUTEX :SB-LDB :SB-PACKAGE-LOCKS :SB-QSHOW :SB-SAFEPOINT
 :SB-SAFEPOINT-STRICTLY :SB-SIMD-PACK :SB-SOURCE-LOCATIONS :SB-THREAD
 :SB-THRUPTION :SB-TRACEROOT :SB-UNICODE :SB-WTIMER :SBCL
 :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-FIXED-OBJECTS
 :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-VECTORS
 :STACK-GROWS-DOWNWARD-NOT-UPWARD :SYMBOL-INFO-VOPS :UNBIND-N-VOP
 :UNDEFINED-FUN-RESTARTS :UNWIND-TO-FRAME-AND-CALL-VOP :WIN32 :X86-64)

[Tomas Hlavaty (tomas-hlavaty)]

On Wed 18 Oct 2017 at 07:38, Eitaro Fukamachi <email address hidden> wrote:
> Calling sb-ext:run-program creates a new handle and keeps it even after
> the process exited on Windows.

Can confirm.

We found this in
id:<email address hidden>
but I mistakenly thought it was a FD_SETSIZE problem.

After realising, that it was a leak, this workaround worked for our
specific use-case:

;; :error *error-output* leaks file descriptors on windows
:error #+(or mswindows windows) :output
       #-(or mswindows windows) *error-output*

[Stas Boukarev (stassats)]

Fixed in 71a2e512b637463c5d486ce421aacaa7b74c56ee.
Though, it's not automatically closed, but as long as you call PROCESS-EXIT-CODE or PROCESS-EXIT-STATUS after the process has finished it'll be closed.
There's also PROCESS-CLOSE which was supposed to close the handle, but it was crashing on windows, I fixed that as well and it can be used to close the handle at any time.

And whenever PROCESS-EXIT-CODE/STATUS are called on any finished process all other finished processes' handles will be also closed.

[Tomas Hlavaty (tomas-hlavaty)]

thanks a lot!

[Eitaro Fukamachi (fukamachi)]

I appreciate the quick response and fix!

[Eitaro Fukamachi (fukamachi)]

I confirmed the exited process handle are released after calling sb-ext:process-status with SBCL 1.4.1.

Well, now I have a suggestion about the behaviour.
The result process object from "sb-ext:run-program :wait t" would always be exited, however, the process handle won't be closed until getting its status.
I think it's cool if the handles will be closed automatically.

[Stas Boukarev (stassats)]

Done as a part of ce7eec29a758686a773273676fa390f4a8a1ecd2