JDK-5008166 : (process) Various improvements to Windows process creation code
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_95,windows_98
  • CPU: generic
  • Submitted: 2004-03-04
  • Updated: 2014-12-03
  • Resolved: 2013-07-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7u60Fixed
Related Reports
Relates :  
JDK-5005176 - (process) Can't run 16-bit DOS programs (.com files)
Description
src/windows/native/java/lang/ProcessImpl_md.c has a number of minor
deficiencies, especially in selectProcessFlags.

selectProcessFlag doesn't do enough error checking.  In particular,
the return code from SearchPath is not checked, and an open on an
uninitialized buffer is performed.  If you have very bad luck, this will
hang if the uninitialized buffer happens to contain the file name of a
named pipe without a writer, for example.

Instead of selecting a single process creation flag, the logic should
be more sophisticated; different actions should be taken for .com files.
There may also be a need to take different action for 64-bit windows
executables.

Even with the fix for 5005176, 16-bit console applications will appear to
produce no output when launched from detached Java processes on NT.
This should be fixed.
Comments
umbrella fix from JDK-8021245
31-07-2013
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang
14-06-2004
EVALUATION The kind of changes that need to be made are well-understood, but quite invasive and too risky for Tiger. Let's target them for Mustang. ###@###.### 2004-03-04
04-03-2004
SUGGESTED FIX Here is the start of a replacement for processFlags(), that actually performs error checking. jboolean win32Executable(JNIEnv *env, jstring cmd0) { char buf[MAX_PATH]; jboolean result = JNI_FALSE; char *exe, *name; unsigned char buffer[2]; long headerLoc; int fd = -1; if ((exe = (char *)JNU_GetStringPlatformChars(env, cmd0, 0)) == NULL) goto cleanup; if ((exe = extractExecutablePath(env, exe)) == NULL) goto cleanup; /* exe = JVM_NativePath(exe); */ { int ret; char *p = strrchr(exe, '\\'); char *q = strrchr(exe, '/'); if (p == NULL && q == NULL) ret = SearchPath(NULL, exe, ".exe", MAX_PATH, buf, &name); else { char *sep = (p == NULL) ? q : (q == NULL) ? p : (q > p) ? q : p; *sep = '\0'; ret = SearchPath(exe, sep+1, ".exe", MAX_PATH, buf, &name); } if (ret <= 0 || ret >= MAX_PATH) goto cleanup; } if ((fd = _open(buf, _O_RDONLY)) < 0) goto cleanup; if (_read(fd, buffer, 2) != 2) goto cleanup; if (! (buffer[0] == 'M' && buffer[1] == 'Z')) goto cleanup; if (_lseek(fd, 60L, SEEK_SET) < 0) goto cleanup; if (_read(fd, buffer, 2) != 2) goto cleanup; headerLoc = (long)buffer[1] << 8 | (long)buffer[0]; if (_lseek(fd, headerLoc, SEEK_SET) < 0) goto cleanup; if (_read(fd, buffer, 2) != 2) goto cleanup; if (buffer[0] == 'P' && buffer[1] == 'E') result = JNI_TRUE; cleanup: if (exe != NULL) JNU_ReleaseStringPlatformChars(env, cmd0, exe); if (fd >= 0) _close(fd); return result; } The techniques for running Windows applications portably are available in the Open Source community, for example tclWinPipe.c from the Tcl distribution. ###@###.### 2004-03-04
04-03-2004