Re: Potential bug in openjdk-11 on mips64el

On 2/15/21 1:40 AM, Olek Wojnar wrote:
> On Sat, Feb 13, 2021 at 2:21 PM <[email protected] <mailto:[email protected]>> wrote:
>     It selects the "Zero" VM, which I assume is the one used on mips64el.
>     https://openjdk.java.net/projects/zero/
> 
> Ah, thanks for the explanation! It helped me to appropriately adjust build-depends. Hmm, it looks 
> like Zero is not supported on MIPS at the moment, but perhaps that site is just out-of-date?

There only Zero on mips64el for all current OpenJDKs. Zero for mips64el should be supported since 
JDK 10, see JDK-8186313: https://bugs.openjdk.java.net/browse/JDK-8186313

...so openjdk-11 is supposed to work.

> On Sat, Feb 13, 2021 at 6:56 PM Tiago Daitx <[email protected] 
> <mailto:[email protected]>> wrote:
> 
> 
>     This seems to indicate that the isDirectory call [4] is getting wrong
>     file attributes. Following the trail, those file attributes come from
>     a fstatat call [5] which ultimately come from the native stack in
>     UnixNativeDispatcher.c [6]. The actual way that fstatat is called
>     depends on the build flags and defines from the arch, so somebody with
>     better knowledge might want to take a look at UnixNativeDispatcher.c
>     [6] and tell if OpenJDK is picking the right function to call for
>     mips64el.
> 
> 
> Thanks for the excellent analysis! So is this indeed a bug in OpenJDK on mips64el then? I'm happy to 
> file the bug, referencing all of the information in this thread, if that's the probable culprit here.

Thing is, there is hardly anyone who supports mips64el in OpenJDK upstream. I think Debian folks are 
the most heavy users of it :) So, while you can submit a bug upstream, I don't think there is a high 
chance anyone picks it up. You can try to ask here:
   https://mail.openjdk.java.net/mailman/listinfo/mips-port

It looks to me that Zero mips64el is another instance of SecureDirectoryStream bug tail:
   https://bugs.openjdk.java.net/issues/?jql=text%20~%20%22SecureDirectoryStream%22

If there is the mips64el machine where this reproduces, the next step would be trying the mainline 
JDK NIO tests, something like:

  $ git clone https://github.com/openjdk/jdk
  $ cd jdk
  $ wget https://builds.shipilev.net/jtreg/jtreg.zip
  $ unzip jtreg.zip
  $ ./configure --with-debug-level=fastdebug --with-jtreg=./jtreg
  $ make run-test TEST=java/nio

...and if that does not yield failures, then MCVE would be needed.