broken posix/process function under Windows 7 (MingW)

[Karl_H]

The posix/process function does not return from calls under Windows 7 (Windows Vista seems to work; 32 and 64 bit are inflicted). This problem occures in compiled programms and in the interpreter.

Interestingly the process* function doesn't share this malfunction and I was able to write the following simple workarround:

;; after loading the posix unit
(set! process (lambda (#!rest rest)

(receive (a b c d) (apply process* rest)

(values a b c))))

An example for an egg that uses the functionality is the pstk or the tk egg and both seem to work with the above workaround.

CHICKEN
(c)2008-2011 The Chicken Team
(c)2000-2007 Felix L. Winkelmann
Version 4.7.0.4-st
windows-mingw32-x86 [ manyargs dload ptables ]
compiled 24.12.2011 on Karl_H-Notebook (MinGW)

[sjamaan]

The docs for ​CreateProcess and ​STARTUPINFO seem to hint that either STARTF_USESTDHANDLES is set and all three of StdIn?, StdOut? and StdErr? must be set and must be valid FDs, or STARTF_USESTDHANDLES is not set and the handles are ignored.

"The caller is responsible for ensuring that the standard handle fields in STARTUPINFO contain valid handle values. These fields are copied unchanged to the child process without validation, even when the dwFlags member specifies STARTF_USESTDHANDLES. Incorrect values can cause the child process to misbehave or crash. Use the Application Verifier runtime verification tool to detect invalid handles"

I wonder if that "Application Verifier" program indeed points out that Chicken is doing something wrong? Might be a good idea to run it anyway, and see what it comes up with. Perhaps this can help us find other annoying Windows bugs.

[megane]

​GetStdHandle returns INVALID_HANDLE_VALUE when it fails. In posixwin.scm:820 the values from GetStdHandle? calls are used if the child process is supposed to inherit a handle from the parent. But the values are used as is, and there's no check if they are INVALID_HANDLE_VALUE.

[megane]

The bInheritHandle flag for the ​DuplicateHandle call at posixwin:820 is set to FALSE although the documentation suggests it should be TRUE:

A variable that indicates whether the handle is inheritable. If TRUE, the duplicate handle can be
 inherited by new processes created by the target process. If FALSE, the new handle cannot be
 inherited.

I tried switching it to TRUE some time ago, but it didn't make a difference.

[sjamaan]

Let's add this one to the 4.9.0 list as well; might fix everyhing in one go

[sjamaan]

Turned out to be caused by the duplication of file handles and then marking them as inheritable. This is disallowed by Windows 7 on handles duplicated from file handles from the parent process. Patch sent to -hackers.

[sjamaan]

Fixed by 2477220de9c5663417f1d2626b34a3f71fc68992