I tried to dpkg-buildpackage bazel-bootstrap, but I failed to
reproduce the issue. It seems a long time is needed. Is there a
simpler way to reproduce the problem?
Just FYI, we had a workaround for another issue. I don't know if it
has anything to do with this problem.
diff -r 86de6cbb5d97 -r 0cde37559d27
src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c
--- a/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c Thu
May 30 15:01:09 2019 +0800
+++ b/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c Thu
Jun 06 17:51:54 2019 +0800
@@ -568,7 +568,15 @@
JNU_ThrowInternalError(env, "should not reach here");
return;
}
+
+#ifdef __mips__
+ // __NR_newfstatat is incorrect on some OS
+ // workaround it using glibc's fstatat64
+ RESTARTABLE(fstatat64((int)dfd, path, &buf, (int)flag), err);
+#else
RESTARTABLE((*my_fstatat64_func)((int)dfd, path, &buf, (int)flag), err);
+#endif
+
if (err == -1) {
throwUnixException(env, errno);
} else {
Cheers,
Ao Qi
On Tue, Feb 16, 2021 at 12:29 AM Ao Qi <a...@loongson.cn> wrote:
>
> On Mon, Feb 15, 2021 at 10:22 PM Aleksey Shipilev <sh...@redhat.com> wrote:
> >
> > On 2/15/21 1:40 AM, Olek Wojnar wrote:
> > > On Sat, Feb 13, 2021 at 2:21 PM <raphael.jo...@free.fr
> > > <mailto:raphael.jo...@free.fr>> 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 <tiago.da...@canonical.com
> > > <mailto:tiago.da...@canonical.com>> 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
>
> I would like to pick it up. However, I am on vacation at the moment
> and did not have a mips64el machine on hand. If time permits, I will
> return to the company in three days to follow up on this issue.
>
> Cheers,
> Ao Qi
>
> >
> > 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.
> >
> > --
> > Thanks,
> > -Aleksey
