Path: csiph.com!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod From: Olek Wojnar Newsgroups: linux.debian.maint.java,linux.debian.ports.mips Subject: Re: Potential bug in openjdk-11 on mips64el Date: Sun, 21 Feb 2021 21:20:01 +0100 Message-ID: References: X-Original-To: Ao Qi , Aleksey Shipilev X-Mailbox-Line: From debian-java-request@lists.debian.org Sun Feb 21 20:12:21 2021 Old-Return-Path: X-Amavis-Spam-Status: No, score=-4.398 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, FOURLA=0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=2, LDO_WHITELIST=-5, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001] autolearn=no autolearn_force=no X-Policyd-Weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 CL_IP_EQ_HELO_IP=-2 (check from: .gmail. - helo: .mail-qt1-f179.google. - helo-domain: .google.) FROM/MX_MATCHES_HELO(DOMAIN)=-2; rate: -5.5 X-Google-Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VL0bZ7lQMMJXpl/Qyfvrs/n1o39+AdJHMAZBgnVDhbU=; b=SR41jaIACjCISSP6J0yRBJByC+K5QQLvJ02cskkej02XYKyYLntCNrNAmB1t41887C S4SDotTpcBO792UvaTbMJRhS2uTDW9ReNuQFNmtnG+Kiw8jen+W8VZzs5jhsmGQAKJcH cq+AjhNXeqo66vmOJ+og6HIIn6W16AMt0gDghTxCRUBbycpnFczakazmCuEaVW17XWYj ddx/C/5kKFImjlfRAZM9DjjrvC/gjvTcIQP4uDXujgQRjbswVOWj1x6jRXilg0WP/zL4 ApEI4UjYqqbWWt/S6dGLG+AzMVTRWFoMGZV6W6TJFhBzCL3g8rh2fnEqq7mbniRmohS7 pjDw== X-Gm-Message-State: AOAM533jv9fXOqnpPGzIbQEC4hZhZ7CQ1qKBATMEUz34hApzSXLv89KE KPG/nE8t/mrASAtcQZmbJ0q2ljhCQtA= X-Google-SMTP-Source: ABdhPJwGpdkWKoZa/YWAIADoASULJ0GCtXtkQnf86ibpoYj3IrwG+2nsMjWmZ5BdxZgc7XaxGU1Iyg== X-Received: by 2002:ac8:110e:: with SMTP id c14mr16974844qtj.293.1613937394714; Sun, 21 Feb 2021 11:56:34 -0800 (PST) X-Received: by 2002:ad4:57ce:: with SMTP id y14mr10326262qvx.52.1613937394073; Sun, 21 Feb 2021 11:56:34 -0800 (PST) MIME-Version: 1.0 X-Gmail-Original-Message-ID: Content-Type: multipart/alternative; boundary="00000000000010461305bbde15cf" X-Mailing-List: archive/latest/22704 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/CAJj0crS5BtM3-qY7wdkDaNZuM-WqjBH386UG_N-OiRNUNnUmkA@mail.gmail.com Approved: robomod@news.nic.it Lines: 240 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Cc: openjdk-11@packages.debian.org, Debian Java List , "debian-mips@lists.debian.org" , Debian Bazel Packaging Team X-Original-Date: Sun, 21 Feb 2021 14:55:58 -0500 X-Original-Message-ID: X-Original-References: <22ba18ae-501b-3db3-47db-b3ac6f6fb1b6@debian.org> <7884a7bb-050c-7805-41ab-c0198bd0e039@redhat.com> Xref: csiph.com linux.debian.maint.java:12077 linux.debian.ports.mips:2898 --00000000000010461305bbde15cf Content-Type: text/plain; charset="UTF-8" Thanks for the ideas so far! On Sat, Feb 20, 2021 at 3:53 AM Ao Qi wrote: > 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? > When you say that you failed to reproduce the issue, do you mean that the bazel-bootstrap package was built correctly or that you experienced a different error? Regarding a simple example, this [1] is what causes the problem so adapting this snippet to delete a test directory should allow you to reproduce the problem. A guava dependency should allow you to satisfy this: `import com.google.common.io.MoreFiles`. But I'm not exactly a Java expert so I may be missing something here. Regarding the long build times, if you are able to build in a persistent environment that should speed up the build. Bazel only rebuilds changed code so reusing the same build environment should speed up subsequent builds. (I have done this when building software with Bazel but not with building Bazel itself because I always build Debian packages in a clean environment) Just FYI, we had a workaround for another issue. I don't know if it > has anything to do with this problem. > That looks like it may be related (from what I can tell)! I assume that workaround is not in the current mips64el OpenJDK in Debian? If you can confirm on your system that your workaround fixes the problem shown in [1] then it would be great to have that fix available in Debian! On Tue, Feb 16, 2021 at 12:29 AM Ao Qi wrote: > > > > On Mon, Feb 15, 2021 at 10:22 PM Aleksey Shipilev > wrote: > > > > > > On 2/15/21 1:40 AM, Olek Wojnar wrote: > > > > On Sat, Feb 13, 2021 at 2:21 PM raphael.jolly@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. > Ok, I made a mistake previously and only activated Zero for the bootstrap Bazel build and not for the main Bazel build. The latest version in experimental should have both enabled [2] but it is still failing with the same error. > > 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: > That's unfortunate. :( Would filing a bug in Debian make more sense then? That way, if we can figure out a fix, it can at least be applied to Debian. > > 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. > Thanks for the follow-up! It sounds like we may have a better idea of what's going on now. > > 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. > Does anyone here have easy access to a mips64el machine to try this? -Olek [1] https://salsa.debian.org/bazel-team/bazel-bootstrap/-/blob/master/src/java_tools/buildjar/java/com/google/devtools/build/buildjar/VanillaJavaBuilder.java#L374-383 [2] https://buildd.debian.org/status/fetch.php?pkg=bazel-bootstrap&arch=mips64el&ver=3.5.1%2Bds-3%7Eexp4&stamp=1613632868&raw=0 --00000000000010461305bbde15cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the ideas so far!

On Sat, Feb 20, 2021 at 3= :53 AM Ao Qi <aoqi@loongson.cn&g= t; wrote:
I trie= d 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?

W= hen you say that you failed to reproduce the issue, do you mean that the ba= zel-bootstrap package was built correctly or that you experienced a differe= nt error? Regarding a simple example, this [1] is what causes the problem s= o adapting this snippet to delete a test directory should allow you to repr= oduce the problem. A guava dependency should allow you to satisfy this: `import com.google.co= mmon.io.MoreFiles`. But I'm not exactly=C2=A0a Java expert so I may be = missing something here.

Regarding the long build times, if yo= u are able to build in a persistent environment that should speed up the bu= ild. Bazel only rebuilds changed code so reusing the same build environment= should speed up subsequent builds. (I have done this when building softwar= e with Bazel but not with building Bazel itself because I always build Debi= an packages in a clean environment)

Just FYI, we had a workaround for ano= ther issue. I don't know if it
has anything to do with this problem.

T= hat looks like it may be related (from what I can tell)! I assume=C2=A0that= workaround=C2=A0is not in the current mips64el OpenJDK in Debian? If you c= an confirm on your system that your workaround fixes the problem shown in [= 1] then it would be great to have that fix available in Debian!
<= br>
On Tue, Feb 16, = 2021 at 12:29 AM Ao Qi <aoqi@loongson.cn> wrote:
>
> On Mon, Feb 15, 2021 at 10:22 PM Aleksey Shipilev <shade@redhat.com> wrote:
> >
> > On 2/15/21 1:40 AM, Olek Wojnar wrote:
> > > On Sat, Feb 13, 2021 at 2:21 PM <raphael.jolly@free.fr <mailto:raphael.jolly@free.= fr>> wrote:
> > >=C2=A0 =C2=A0 =C2=A0It selects the "Zero" VM, which= I assume is the one used on mips64el.
> > >=C2=A0 =C2=A0 =C2=A0https://openjdk.java.net/pr= ojects/zero/
> > >
> > > Ah, thanks for the explanation! It helped me to appropriatel= y adjust build-depends. Hmm, it looks
> > > like Zero is not supported on MIPS at the moment, but perhap= s that site is just out-of-date?
> >
> > There only Zero on mips64el for all current OpenJDKs. Zero for mi= ps64el should be supported since
> > JDK 10, see JDK-8186313: https://bugs.open= jdk.java.net/browse/JDK-8186313
> >
> > ...so openjdk-11 is supposed to work.

Ok, I made a mistake previously and only activated Zero for the bo= otstrap Bazel build and not for the main Bazel build. The latest version in= experimental should have both enabled [2] but it is still failing with the= same error.

> > 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 upst= ream, I don't think there is a high
> > chance anyone picks it up. You can try to ask here:

That's unfortunate. :( Would filing a bug in Deb= ian make more sense then? That way, if we can figure out a fix, it can at l= east be applied to Debian.
=C2=A0
> I would like to pick it up. However, I am on v= acation 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.

Thanks for the follow-up! It sounds like we m= ay have a better idea of what's going on now.=C2=A0

> > It looks to me= that Zero mips64el is another instance of SecureDirectoryStream bug tail:<= br> > >=C2=A0 =C2=A0 https://bugs.openjdk.java.net/issues/?jql=3Dtext%20~%20%22SecureDirect= oryStream%22
> >
> > If there is the mips64el machine where this reproduces, the next = step would be trying the mainline
> > JDK NIO tests, something like:
> >
> >=C2=A0 =C2=A0$ git clone https://github.com/openjdk/jdk > >=C2=A0 =C2=A0$ cd jdk
> >=C2=A0 =C2=A0$ wget https://builds.shipilev.net/= jtreg/jtreg.zip
> >=C2=A0 =C2=A0$ unzip jtreg.zip
> >=C2=A0 =C2=A0$ ./configure --with-debug-level=3Dfastdebug --with-j= treg=3D./jtreg
> >=C2=A0 =C2=A0$ make run-test TEST=3Djava/nio
> >
> > ...and if that does not yield failures, then MCVE would be needed= .

Does anyone here have easy access to = a mips64el machine to try this?


-Ol= ek

--00000000000010461305bbde15cf--