openjdk team mailing list archive

[tony mancill <tmancill@xxxxxxxxxx>]

On Mon, Sep 21, 2020 at 09:24:36PM +0100, Julian Gilbey wrote:
> On Mon, Sep 21, 2020 at 07:03:08AM -0700, tony mancill wrote:
> > On Mon, Sep 21, 2020 at 10:01:35AM +0100, Julian Gilbey wrote:
> > > On Sun, Sep 20, 2020 at 09:59:22PM -0700, tony mancill wrote:
> > > > Hi Tiago, hi Julian,
> > > > [...]
> > > > Julian, I applied the patch and built the package successfully, but
> > > > jlink still fails with the "expected hash" error.  It's (perhaps)
> > > > interesting that the expected hash does differ between the patched build
> > > > and the unpatched build.
> > > 
> > > That's really bizarre.  I checked running strip-nondeterminism on the
> > > resulting jmods and it seemed to be OK.  But if so, then I've clearly
> > > overlooked something.
> > 
> > I'm wondering if we just need more of it sprinkled about earlier in the
> > build.  I didn't believe it at first and so rebuilt (more than once) to
> > be sure.
> 
> Hi Tony,
> 
> Here are a couple more thoughts on exploring this:
> 
> * Search through the build log to check that strip-nondeterminism is
>   actually being called.  If it's not, perhaps the patch has
>   accidentally not been applied.

The patch is definitely being applied and run during the build.  I see
output like this for each of the jmods:

Executing: [strip-nondeterminism /<<PKGBUILDDIR>>/build/support/images/jmods/java.xml.jmod && /bin/mv /<<PKGBUILDDIR>>/build/support/images/jmods/java.xml.jmod /<<PKGBUILDDIR>>/build/images/jmods/java.xml.jmod]

> * Run the sha256sum command (protected with a '-' in case it fails!)
>   at several points in the build-arch and install targets to see when
>   the hashes change, if at all.

Good idea.  I am doing that now, and also building without parallelism,
since I'd like to see the build logs for a single jmod being built
without those being interspersed with others.  Specifically, I'd like to
see the order in which the jmods are built and the hashes recorded.
Somewhere along the line, we must be invoking jmod hash / --hash-modules
on a jmod before strip-nondeterminism was invoked. 

>From the jmod manpage:

> With the --hash-modules option or the jmod hash command, you can, in each module's descriptor, record hashes
> of the content of the modules that are allowed to depend upon it, thus "tying" together these modules.   This
> enables a package to be exported to one or more specifically-named modules and to no others through qualified
> exports.  The runtime verifies if the recorded hash of a module matches the one resolved at run time; if not,
> the runtime returns an error.

One other thing I wanted to mention is what I'm using for a test case:

  jlink --add-modules java.desktop --output test

This fails, complaining about the hash of java.xml recorded in
java.base.  But other invocations of jlink are successful with the
patched build.  For example, the following is fine:

  jlink --add-modules java.base --output test

As does java.compiler and 32 others.  So 34 are okay and 38 of them are
failing.  The "good" vs. "fail" modules are attached in case it sparks
inspiration for someone.  I will take a look at the output of the
non-parallelized build in the (GMT-7) morning.

So there are approximately 50/50 odds that your test case is working
(hence the confusion), because the strip-determinism patch is only be
causing problems for a subset of modules.

Thank you for the ideas.  I will keep working on it.

Cheers,
tony

java.base
java.compiler
java.desktop
java.management.rmi
java.naming
java.prefs
java.se
java.security.jgss
java.sql
java.sql.rowset
java.xml.crypto
jdk.accessibility
jdk.aot
jdk.crypto.cryptoki
jdk.editpad
jdk.hotspot.agent
jdk.incubator.jpackage
jdk.internal.vm.compiler
jdk.internal.vm.compiler.management
jdk.javadoc
jdk.jconsole
jdk.jdeps
jdk.jshell
jdk.jstatd
jdk.management
jdk.management.agent
jdk.naming.dns
jdk.naming.rmi
jdk.rmic
jdk.scripting.nashorn.shell
jdk.security.auth
jdk.security.jgss
jdk.unsupported.desktop
jdk.xml.dom

java.datatransfer
java.instrument
java.logging
java.management
java.net.http
java.rmi
java.scripting
java.security.sasl
java.smartcardio
java.transaction.xa
java.xml
jdk.attach
jdk.charsets
jdk.compiler
jdk.crypto.ec
jdk.dynalink
jdk.httpserver
jdk.incubator.foreign
jdk.internal.ed
jdk.internal.jvmstat
jdk.internal.le
jdk.internal.opt
jdk.internal.vm.ci
jdk.jartool
jdk.jcmd
jdk.jdi
jdk.jdwp.agent
jdk.jfr
jdk.jlink
jdk.jsobject
jdk.localedata
jdk.management.jfr
jdk.net
jdk.nio.mapmode
jdk.scripting.nashorn
jdk.sctp
jdk.unsupported
jdk.zipfs