Here is a new webrev:
http://cr.openjdk.java.net/~erikj/8204564/webrev.02/
/Erik
On 2019-01-30 08:52, Erik Joelsson wrote:
Hello,
On 2019-01-30 01:51, Magnus Ihse Bursie wrote:
On 2019-01-30 02:18, Erik Joelsson wrote:
Hello,
Some recent build failures reminded me of this issue and increased
the need to fix it ASAP to be able to diagnose them.
GenerateLinkOptData.gmk runs a java tool to generate data which is
later used to optimize the JDK image with jlink. The problem here is
that the tool needs to print some of that data on stdout, which the
build captures as one build artifact, and will print some "garbage"
on stderr if things go well. So currently we just hide all that
output from the build log. Because of this, if something goes wrong,
we won't see the error.
This patch tries to capture the stderr output and only print it
(along with stdout) if the java command fails.
Bug: https://bugs.openjdk.java.net/browse/JDK-8204564
Webrev: http://cr.openjdk.java.net/~erikj/8204564/webrev.01/
Good idea, but could you please include some more information in the
case of failure? The classlist data generation gets a lot of blame
when the real cause is that the JDK is stillborn.
Something like:
|| ( exitcode=$$? && $(ECHO) "ERROR: Classlist file
generation failed. This is typically a sign that the newly built JDK
is broken, and not of an error in the Classlist generation." &&
$(ECHO) "Classlist stderr: " &&
$(CAT) $(LINK_OPT_DIR)/stderr && $(ECHO) "Classlist trace file:" &&
$(CAT) $(JLI_TRACE_FILE) \
&& exit $$exitcode )
but with better line breaks :)
Sure, but please note that this is not the first time we are running
the newly built JVM in the build. To run the classlist generation, we
must first create a couple of jmods and jlink them together into the
interim image, so the newly built JVM/JDK cannot be completely broken
for this to happen.
/Erik
/Magnus
/Erik
