<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>If this filter is doing filename remapping, then one thing worth
trying is to run with the system property
jdk.net.unixdomain.tmpdir set to some alternate location. This
specifies the location of the directory where we create the socket
files for "automatically" bound sockets for ServerSocketChannel
(ie when binding with a null address). This is what the NIO
PipeImpl does when creating its loopback socket.<br>
</p>
<p>Alternatively, you could try asking your customer to run a simple
test of UNIX domain sockets on an affected machine and see what
happens. Eg. the following snippet:</p>
<div style="background-color:#ffffff;color:#080808;font-family:'JetBrains
Mono',monospace;font-size:9.8pt;">
<div style="background-color:#ffffff;color:#080808;font-family:'JetBrains
Mono',monospace;font-size:9.8pt;">
<pre><span style="color:#0033b3;">var </span><span style="color:#000000;">server </span>= <span style="color:#000000;">ServerSocketChannel</span>.<span style="font-style:italic;">open</span>(<span style="color:#000000;">StandardProtocolFamily</span>.<span style="color:#871094;font-style:italic;">UNIX</span>);
<span style="color:#0033b3;">var </span><span style="color:#000000;">name </span>= <span style="color:#000000;">Path</span>.<span style="font-style:italic;">of</span>(<span style="color:#067d17;">"foo.sock"</span>);
<span style="color:#000000;">Files</span>.<span style="font-style:italic;">deleteIfExists</span>(<span style="color:#000000;">name</span>);
<span style="color:#000000;">server</span>.bind(<span style="color:#000000;">UnixDomainSocketAddress</span>.<span style="font-style:italic;">of</span>(<span style="color:#000000;">name</span>));
<span style="color:#0033b3;">var </span><span style="color:#000000;">client </span>= <span style="color:#000000;">SocketChannel</span>.<span style="font-style:italic;">open</span>(<span style="color:#000000;">server</span>.getLocalAddress());
<span style="color:#0033b3;">var </span><span style="color:#000000;">s1 </span>= <span style="color:#000000;">server</span>.accept();
<span style="color:#000000;">System</span>.<span style="color:#871094;font-style:italic;">out</span>.printf(<span style="color:#067d17;">"client: %s, server connection: %s</span><span style="color:#0037a6;">\n</span><span style="color:#067d17;">"</span>, <span style="color:#000000;">client</span>.toString(), <span style="color:#000000;">s1</span>.toString());
</pre>
</div>
<pre></pre>
</div>
<div class="moz-cite-prefix">- Michael</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 08/03/2023 10:14, Mike Hearn wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAGv+2bOPuE2v92BmNqi=hGjiUuCoTEs7OX31yRa-N=ZZ8-X0JQ@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">Unfortunately I need to resurrect this thread. Although in November we
worked around the issue by patching the JVM we ship with our
applications, now the apps being shipped by one of our customers are
hitting the exact same thing. Obviously telling them to make their own
JVM builds with patches is not a workable solution here, nor really
for anyone else.
Here's what we know:
1. The problem occurs only on some machines but not others (but the
machines affected are affected reliably).
2. For unclear reasons on those machines the problem only occurs if
the app is installed using an MSIX package (the type used by the
Windows Store). If the app is run from an ordinary zip, network
connections function correctly. This is probably why you find it hard
to reproduce. I can supply such an app if it would help with testing.
3. We don't think it's security software related because the affected
machines don't use any beyond the built-in Windows Defender (or put
another way, if it is related, then that's the same as it being a
Windows bug).
Here's my guess as to what might be happening. Apps that are installed
via the Windows Store or MSIX outside the store run using a
lightweight form of file system virtualization. This is how Windows
links files created in %APPDATA% to the app that created them,
ensuring they get cleaned up correctly at uninstall time.
<a class="moz-txt-link-freetext" href="https://urldefense.com/v3/__https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes__;!!ACWV5N9M2RV99hQ!LjA2A-_P6j5L4VE77_w_iMpceuHJIhdeVkj2dv2mTJgFEc_y3FPOOTfOTLAa8LkAODbJlqd5nHhfcAiJm_29sB6uMb8B$">https://urldefense.com/v3/__https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes__;!!ACWV5N9M2RV99hQ!LjA2A-_P6j5L4VE77_w_iMpceuHJIhdeVkj2dv2mTJgFEc_y3FPOOTfOTLAa8LkAODbJlqd5nHhfcAiJm_29sB6uMb8B$</a>
The implementation involves a kernel driver called bindflt. In theory
this virtualization doesn't affect temporary directories, but the
combination of UNIX domain sockets+bindflt is probably not very common
at the moment, and it may be the case that the Windows team have
shipped a regression in some versions. Now if that theory is correct,
it doesn't really explain why some machines are affected and others
aren't when they all appear to be running the same OS version. That is
mysterious and I can't explain it, which counts against the bindflt
theory. An alternative possibility is that it's another race in
winsock; you previously had to do rollbacks due to the discovery of
such races which implies there might be more. But then we face the
question of why the packaging type appears to change the outcome on
the machines that do experience the bug.
Regardless of the cause the result is the same: new Javas can't be
used for apps distributed in this way. The best workaround would be to
detect that this codepath is failing with the stack trace in the first
email in this thread and fall back to the old TCP codepath. Is there
any chance you'd consider such a change? Also if anyone at Oracle has
contacts on the Windows team, it'd be great to ask them to investigate
the issue. I don't have any such contacts :(
thanks,
-mike
</pre>
</blockquote>
</body>
</html>