JDK-4461673 : On win32, Runtime.exec with socket trnsprt fails if env. var. SystemRoot not set
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2001-05-22
  • Updated: 2002-02-22
  • Resolved: 2002-02-22
Related Reports
Relates :  
JDK-4742013 - Regtest-test com/sun/jdi/JITDebug.sh test fails on Windows 98
Relates :  
JDK-4522770 - Reg-test JITDebug.java Failing
Description
I have tried to execute (in Java) the process given by the following command line:
java -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n -cp . Simple

The process is correctly launched if Runtime.exec (String []) method is used.
However, if I try to pass some environment variables and thus I use Runtime.exec (String [], String []) method, then the process fails with this report:

FATAL ERROR in native method: No transport initialized
err:: No such file or directory
Error [2] in socket() call!
Socket transport failed to init.
Transport dt_socket failed to initialize, rc = -1

It seems that there are problems to find needed libraries in the second case. I emphasize, that my environmetal settings were the same in both cases. The only difference is in used exec method.

The problem can be reproduced using the attached files. ExecTest calls Runtime.exec with one paramether if no arguments are passed to it, otherwise it calls Runtime.exec with two parameters.

Note: The problem can be reproduced on JDK1.4, build b62 as well.
Comments
PUBLIC COMMENTS .
10-06-2004
EVALUATION I have been unable to reproduce the problem as described. It appears that something in the debugger is dependent on the user's environment. In the test case provided the second argument to the failing call to Runtime.exec(String [], String []) is non-null thus the user's environment is not used. This is possibly a duplicate of bug 4471696 which was recently fixed. Routing to the debugger team for their opinion. -- iag@sfbay 2001-10-17 The problem only occurs on windows. If the test code is changed to use transport dt_shmem instead of dt_socket, it works ok. If the test code is changed to pass "SystemRoot=d:\\winnt" in the environment along with "s=s", then it works ok. This means that the something in or related to dt_socket.dll needs the SystemRoot environment variable to be set. It remains to be seen if this dependence on SystemRoot is in the VM code or in some underlying windows code. ###@###.### 2001-10-18 This problem is in the underlying socket or other Windows code. SystemRoot must be set in your win32 environment for this socket operation to succeed. We have also seen failures when "SYSTEMROOT" (all upper case) was set instead of "SystemRoot" (mixed case). Refer to: http://groups.google.com/groups?q=SystemRoot+set+socket&hl=en&selm=Xns9048EC401rkrachtayenet%4024.7.143.118&rnum=6 http://groups.google.com/groups?q=SystemRoot+Java+set+socket&hl=en&selm=1Q0t4.753%24Xr4.11596%40news.swbell.net&rnum=1 http://groups.google.com/groups?q=SystemRoot+socket&hl=en&selm=3B01C712.843CE595%40mindspring.com&rnum=4 http://groups.google.com/groups?q=SystemRoot+socket&hl=en&selm=30FA88AA.7689%40tivoli.com&rnum=1 for more information. ###@###.### 2002-02-07 Closing as "will not fix" because the problem does not lie in J2SE. Undefined SystemRoot in a win32 environment causes the low-level O/S socket() call to fail with WSAEPROVIDERFAILEDINIT. ###@###.### 2002-02-22
22-02-2002
WORK AROUND 1. Use the dt_shmem transport instead of dt_socket 2. If you must use dt_socket, and you must pass an environment in Runtime.exec(...), be sure to include SystemRoot=<pathname of your winnt dir> in that environment. Note that this isn't needed on solaris but it won't hurt anything. Unfortunately, it might not be easy for java code to determine the correct value for SystemRoot. ###@###.### 2001-10-18
18-10-2001