From jonathan.gibbons at oracle.com Mon Jan 8 18:30:07 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 08 Jan 2018 10:30:07 -0800 Subject: jtreg, asmtools 7.0 b02 Message-ID: <5A53B8AF.2020906@oracle.com> Heads up, jtreg builders, We need to update jtreg to use asmtools 7.0 b02. Although we don't normally recommend using early access versions of a release, it is necessary in this case to get support for recent new features required for testing JDK 11. I will push the change to jtreg tip soon, and in due course will have a new version tagged (and promoted internally). -- Jon From maurizio.cimadamore at oracle.com Tue Jan 9 13:55:55 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Jan 2018 13:55:55 +0000 Subject: CODETOOLS-7902093: IntelliJ plugin does not build against latest SDK Message-ID: <8a7ec40c-b6ce-c9f5-7c0f-d62946ee8091@oracle.com> Hi, please review the patch for fixing the jtreg build failures reported in this thread [1]. I also fixed few warnings, and took care of another build problem which has not been reported. Webrev here: http://cr.openjdk.java.net/~mcimadamore/7902093/ [1] - http://mail.openjdk.java.net/pipermail/jtreg-dev/2017-November/000497.html Thanks Maurizio From anna.kozlova at jetbrains.com Tue Jan 9 15:10:23 2018 From: anna.kozlova at jetbrains.com (Anna Kozlova) Date: Tue, 9 Jan 2018 16:10:23 +0100 Subject: CODETOOLS-7902093: IntelliJ plugin does not build against latest SDK In-Reply-To: <8a7ec40c-b6ce-c9f5-7c0f-d62946ee8091@oracle.com> References: <8a7ec40c-b6ce-c9f5-7c0f-d62946ee8091@oracle.com> Message-ID: Hi, looks good to me. Thanks, Anna (from IntelliJ team) On Tue, Jan 9, 2018 at 2:55 PM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Hi, > please review the patch for fixing the jtreg build failures reported in > this thread [1]. I also fixed few warnings, and took care of another build > problem which has not been reported. Webrev here: > > http://cr.openjdk.java.net/~mcimadamore/7902093/ > > [1] - http://mail.openjdk.java.net/pipermail/jtreg-dev/2017-Novemb > er/000497.html > > Thanks > Maurizio > > > From maurizio.cimadamore at oracle.com Tue Jan 9 15:13:31 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Jan 2018 15:13:31 +0000 Subject: CODETOOLS-7902093: IntelliJ plugin does not build against latest SDK In-Reply-To: References: <8a7ec40c-b6ce-c9f5-7c0f-d62946ee8091@oracle.com> Message-ID: <947dd727-2b75-4d82-cf48-ba3209f0bf9b@oracle.com> Thanks Anna (and also many thanks for giving me hints on how to fix these missing methods :-)) Maurizio On 09/01/18 15:10, Anna Kozlova wrote: > Hi, > > looks good to me. > > Thanks, > Anna (from IntelliJ team) > > On Tue, Jan 9, 2018 at 2:55 PM, Maurizio Cimadamore > > wrote: > > Hi, > please review the patch for fixing the jtreg build failures > reported in this thread [1]. I also fixed few warnings, and took > care of another build problem which has not been reported. Webrev > here: > > http://cr.openjdk.java.net/~mcimadamore/7902093/ > > > [1] - > http://mail.openjdk.java.net/pipermail/jtreg-dev/2017-November/000497.html > > > Thanks > Maurizio > > > From jonathan.gibbons at oracle.com Wed Jan 10 22:02:14 2018 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 10 Jan 2018 22:02:14 +0000 Subject: hg: code-tools/jtreg: 2 new changesets Message-ID: <201801102202.w0AM2EVp028620@aojmv0008.oracle.com> Changeset: 621cc34dec01 Author: jjg Date: 2017-12-22 12:44 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/621cc34dec01 Use the same javac for all compilations Contributed-by: erik.helin at oracle.com ! make/build-all.sh Changeset: 652902f7fb0e Author: jjg Date: 2018-01-10 13:57 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/652902f7fb0e Update to AsmTools 7.0 b02 ! make/Defs.gmk ! make/build-all.sh From zzambers at redhat.com Thu Jan 11 17:18:27 2018 From: zzambers at redhat.com (=?UTF-8?B?WmRlbsSbayDFvWFtYmVyc2vDvQ==?=) Date: Thu, 11 Jan 2018 18:18:27 +0100 Subject: Problem with jasm source files Message-ID: Hello, I had problem running jtreg tests, which use jasm sources (using @compile). It ended with error when trying to compile jasm sources and printed: result: Error. can't find jasm I looked into jtreg sources and it seems to came from: [1] Then I tried to add asmtools.jar to Class-Path in jtreg.jar's manifest and it fixed the issue. Shouldn't asmtools.jar be there? I used build ( jtreg-4.2-b11.tar.gz ) donloaded from addoptopenjdk.net [2]. And I used jtreg/bin/jtreg script to run it. [1] http://hg.openjdk.java.net/code-tools/jtreg/file/652902f7fb0e/src/share/classes/com/sun/javatest/regtest/exec/CompileAction.java#l421 [2] https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/ best regards, -- Zden?k ?ambersk? OpenJDK QE Red Hat From jonathan.gibbons at oracle.com Thu Jan 11 17:31:07 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 11 Jan 2018 09:31:07 -0800 Subject: Problem with jasm source files In-Reply-To: References: Message-ID: This is a known problem with that latest numbered version of the binaries available provided by the Adopt OpenJDK group. Use the latest (tip) version for now. -- Jon On 1/11/18 9:18 AM, Zden?k ?ambersk? wrote: > Hello, > > I had problem running jtreg tests, which use jasm sources (using > @compile). > It ended with error when trying to compile jasm sources and printed: > > result: Error. can't find jasm > > > I looked into jtreg sources and it seems to came from: [1] > > Then I tried to add asmtools.jar to Class-Path in jtreg.jar's manifest > and it fixed the issue. Shouldn't asmtools.jar be there? > > I used build ( jtreg-4.2-b11.tar.gz ) donloaded from addoptopenjdk.net > [2]. > And I used jtreg/bin/jtreg script to run it. > > > [1] > http://hg.openjdk.java.net/code-tools/jtreg/file/652902f7fb0e/src/share/classes/com/sun/javatest/regtest/exec/CompileAction.java#l421 > [2] https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/ > > > best regards, > From jonathan.gibbons at oracle.com Thu Jan 11 21:02:21 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 11 Jan 2018 13:02:21 -0800 Subject: Problem with jasm source files In-Reply-To: References: Message-ID: This is a known problem with that latest numbered version of the binaries available provided by the Adopt OpenJDK group. Use the latest (tip) version. -- Jon On 1/11/18 9:18 AM, Zden?k ?ambersk? wrote: > Hello, > > I had problem running jtreg tests, which use jasm sources (using > @compile). > It ended with error when trying to compile jasm sources and printed: > > result: Error. can't find jasm > > > I looked into jtreg sources and it seems to came from: [1] > > Then I tried to add asmtools.jar to Class-Path in jtreg.jar's manifest > and it fixed the issue. Shouldn't asmtools.jar be there? > > I used build ( jtreg-4.2-b11.tar.gz ) donloaded from addoptopenjdk.net > [2]. > And I used jtreg/bin/jtreg script to run it. > > > [1] > http://hg.openjdk.java.net/code-tools/jtreg/file/652902f7fb0e/src/share/classes/com/sun/javatest/regtest/exec/CompileAction.java#l421 > [2] https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/ > > > best regards, > From zzambers at redhat.com Fri Jan 12 14:48:10 2018 From: zzambers at redhat.com (=?UTF-8?B?WmRlbsSbayDFvWFtYmVyc2vDvQ==?=) Date: Fri, 12 Jan 2018 15:48:10 +0100 Subject: Problem with jasm source files In-Reply-To: References: Message-ID: <4c14b0e3-a6ad-06b2-8417-5ead6a281ec9@redhat.com> On 01/11/2018 06:31 PM, Jonathan Gibbons wrote: > This is a known problem with that latest numbered version of the > binaries available provided by the Adopt OpenJDK group. > > Use the latest (tip) version for now. Than you for your response. I'll try that later. > > -- Jon > > > On 1/11/18 9:18 AM, Zden?k ?ambersk? wrote: >> Hello, >> >> I had problem running jtreg tests, which use jasm sources (using >> @compile). >> It ended with error when trying to compile jasm sources and printed: >> >> result: Error. can't find jasm >> >> >> I looked into jtreg sources and it seems to came from: [1] >> >> Then I tried to add asmtools.jar to Class-Path in jtreg.jar's manifest >> and it fixed the issue. Shouldn't asmtools.jar be there? >> >> I used build ( jtreg-4.2-b11.tar.gz ) donloaded from >> addoptopenjdk.net [2]. >> And I used jtreg/bin/jtreg script to run it. >> >> >> [1] >> http://hg.openjdk.java.net/code-tools/jtreg/file/652902f7fb0e/src/share/classes/com/sun/javatest/regtest/exec/CompileAction.java#l421 >> [2] https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/ >> >> >> best regards, >> > -- Zden?k ?ambersk? OpenJDK QE Red Hat From zzambers at redhat.com Mon Jan 15 16:38:22 2018 From: zzambers at redhat.com (=?UTF-8?B?WmRlbsSbayDFvWFtYmVyc2vDvQ==?=) Date: Mon, 15 Jan 2018 17:38:22 +0100 Subject: Problem with jasm source files In-Reply-To: <4c14b0e3-a6ad-06b2-8417-5ead6a281ec9@redhat.com> References: <4c14b0e3-a6ad-06b2-8417-5ead6a281ec9@redhat.com> Message-ID: <35e03501-7b3b-e9f7-0134-cd0a005fc27e@redhat.com> On 01/12/2018 03:48 PM, Zden?k ?ambersk? wrote: > On 01/11/2018 06:31 PM, Jonathan Gibbons wrote: >> This is a known problem with that latest numbered version of the >> binaries available provided by the Adopt OpenJDK group. >> >> Use the latest (tip) version for now. > > Than you for your response. I'll try that later. > I tried to build latest version from source. And that one works. Good to know. Thank you. >> >> -- Jon >> >> >> On 1/11/18 9:18 AM, Zden?k ?ambersk? wrote: >>> Hello, >>> >>> I had problem running jtreg tests, which use jasm sources (using >>> @compile). >>> It ended with error when trying to compile jasm sources and printed: >>> >>> result: Error. can't find jasm >>> >>> >>> I looked into jtreg sources and it seems to came from: [1] >>> >>> Then I tried to add asmtools.jar to Class-Path in jtreg.jar's manifest >>> and it fixed the issue. Shouldn't asmtools.jar be there? >>> >>> I used build ( jtreg-4.2-b11.tar.gz ) donloaded from >>> addoptopenjdk.net [2]. >>> And I used jtreg/bin/jtreg script to run it. >>> >>> >>> [1] >>> http://hg.openjdk.java.net/code-tools/jtreg/file/652902f7fb0e/src/share/classes/com/sun/javatest/regtest/exec/CompileAction.java#l421 >>> [2] https://ci.adoptopenjdk.net/view/Dependencies/job/jtreg/ >>> >>> >>> best regards, >>> >> > -- Zden?k ?ambersk? OpenJDK QE Red Hat From volker.simonis at gmail.com Fri Jan 19 15:52:49 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 19 Jan 2018 16:52:49 +0100 Subject: CODETOOLS-7902102 jtharness crashes with StackOverflowError if called from 'jtreg -gui Message-ID: Hi, can somebody please have a look at the following issue, which prevents users who built jtreg/jtharness from source to run jtreg in gui mode. I can provide a trivial fix as sketched at the end of the problem description if that's desired? Thank you and best regards, Volker https://bugs.openjdk.java.net/browse/CODETOOLS-7902102 If you build jtreg and jtharness from source (e.g. with the new "make/buiild-all.sh" script from jtreg) and run 'jtreg -gui' jtharness will crash with the following StackOverflowError: Error: Unexpected exception occurred! java.lang.StackOverflowError java.lang.StackOverflowError at java.base/java.util.ResourceBundle$CacheKey.hashCode(ResourceBundle.java:724) at java.base/java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:946) at java.base/java.util.ResourceBundle.findBundleInCache(ResourceBundle.java:2066) at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1742) at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1654) at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1585) at java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:1276) at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:217) at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:215) at java.base/java.security.AccessController.doPrivileged(Native Method) at com.sun.javatest.ResourceLoader.getSBundle(ResourceLoader.java:214) at com.sun.javatest.ResourceLoader.getBundle(ResourceLoader.java:199) at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:121) at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:119) at java.base/java.security.AccessController.doPrivileged(Native Method) at com.sun.javatest.util.I18NResourceBundle.getObj(I18NResourceBundle.java:118) at com.sun.javatest.util.I18NResourceBundle.getOptionalString(I18NResourceBundle.java:104) at com.sun.javatest.tool.Startup.show(Startup.java:97) at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) at com.sun.javatest.tool.Startup.show(Startup.java:105) at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) at com.sun.javatest.tool.Startup.show(Startup.java:105) at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) ... This is because jtharness tries to load the splash screen image from "com/sun/javatest/tool/images/splash.gif" which doesn't exist and leeds to an infinite recursion. The splash screen image is defined in com/sun/javatest/tool/i18n.properties: startup.icon=com/sun/javatest/tool/images/splash.gif but com/sun/javatest/tool/images only contains: jticon.gif jtlogo.png selected.gif spl_412.gif spl_413.gif spl_421.gif spl_42.gif spl_43.gif spl_441.gif spl_44.gif jtlogo.gif partially.gif spl_412F.gif spl_413F.gif spl_421F.gif spl_42F.gif spl_43F.gif spl_441F.gif spl_44F.gif unselected.gif but no splash.gif. The trivial fix would be to either create a generic "splash.gif" or to define startup.icon to point to an existing image. The problem is that the splash screen gifs contain a string with the jtHarness version. So a more general solution would be to create such a gif as part of the build (e.g. from a generic template). I think this a "day-zero" problem (at lease from the day the jtHarness sources are in the OpenJDK Mercurial repositories) but has never been encountered because people usually used pre-built version of jtHarness from Oracle which contain a valid "splash.gif" icon. Now, with the new jtReg build script "make/buiild-all.sh" which makes it easy for everybody to build jtReg and all its dependencies (including jtHarness) from source this problem will affect everybody who does so! From volker.simonis at gmail.com Fri Jan 19 16:46:56 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 19 Jan 2018 17:46:56 +0100 Subject: CODETOOLS-7902102 jtharness crashes with StackOverflowError if called from 'jtreg -gui In-Reply-To: References: Message-ID: Looking more closely at this issue, I think the correct "quick fix" will be to add the following copy action to the "compile.resources" target in build/build.xml Just renaming the startup.icon to an existing icon wouldn't help because the icons names "spl_*.gif" are not copied over into the generated images. Creating a generic "splash.gif" would also help, because that one will be copied over into the generated images. Regards, Volker On Fri, Jan 19, 2018 at 4:52 PM, Volker Simonis wrote: > Hi, > > can somebody please have a look at the following issue, which prevents > users who built jtreg/jtharness from source to run jtreg in gui mode. > I can provide a trivial fix as sketched at the end of the problem > description if that's desired? > > Thank you and best regards, > Volker > > https://bugs.openjdk.java.net/browse/CODETOOLS-7902102 > > If you build jtreg and jtharness from source (e.g. with the new > "make/buiild-all.sh" script from jtreg) and run 'jtreg -gui' jtharness > will crash with the following StackOverflowError: > > Error: Unexpected exception occurred! java.lang.StackOverflowError > java.lang.StackOverflowError > at java.base/java.util.ResourceBundle$CacheKey.hashCode(ResourceBundle.java:724) > at java.base/java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:946) > at java.base/java.util.ResourceBundle.findBundleInCache(ResourceBundle.java:2066) > at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1742) > at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) > at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) > at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1654) > at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1585) > at java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:1276) > at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:217) > at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:215) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at com.sun.javatest.ResourceLoader.getSBundle(ResourceLoader.java:214) > at com.sun.javatest.ResourceLoader.getBundle(ResourceLoader.java:199) > at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:121) > at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:119) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at com.sun.javatest.util.I18NResourceBundle.getObj(I18NResourceBundle.java:118) > at com.sun.javatest.util.I18NResourceBundle.getOptionalString(I18NResourceBundle.java:104) > at com.sun.javatest.tool.Startup.show(Startup.java:97) > at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) > at com.sun.javatest.tool.Startup.show(Startup.java:105) > at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) > at com.sun.javatest.tool.Startup.show(Startup.java:105) > at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) > ... > > This is because jtharness tries to load the splash screen image from > "com/sun/javatest/tool/images/splash.gif" which doesn't exist and > leeds to an infinite recursion. > > The splash screen image is defined in com/sun/javatest/tool/i18n.properties: > > startup.icon=com/sun/javatest/tool/images/splash.gif > > but com/sun/javatest/tool/images only contains: > > jticon.gif jtlogo.png selected.gif spl_412.gif spl_413.gif spl_421.gif > spl_42.gif spl_43.gif spl_441.gif spl_44.gif > jtlogo.gif partially.gif spl_412F.gif spl_413F.gif spl_421F.gif > spl_42F.gif spl_43F.gif spl_441F.gif spl_44F.gif unselected.gif > > but no splash.gif. > > The trivial fix would be to either create a generic "splash.gif" or to > define startup.icon to point to an existing image. > > The problem is that the splash screen gifs contain a string with the > jtHarness version. So a more general solution would be to create such > a gif as part of the build (e.g. from a generic template). > > I think this a "day-zero" problem (at lease from the day the jtHarness > sources are in the OpenJDK Mercurial repositories) but has never been > encountered because people usually used pre-built version of jtHarness > from Oracle which contain a valid "splash.gif" icon. > > Now, with the new jtReg build script "make/buiild-all.sh" which makes > it easy for everybody to build jtReg and all its dependencies > (including jtHarness) from source this problem will affect everybody > who does so! From jonathan.gibbons at oracle.com Tue Jan 23 15:50:42 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 23 Jan 2018 07:50:42 -0800 Subject: CODETOOLS-7902102 jtharness crashes with StackOverflowError if called from 'jtreg -gui In-Reply-To: References: <57A9A4C9-0235-4FB6-9176-AABEFFA515C2@oracle.com> Message-ID: On 1/23/18 6:15 AM, Volker Simonis wrote: > Hi Alexey, > > your change looks fine. Thanks for fixing! > > On Tue, Jan 23, 2018 at 2:56 PM, Alexey Fedorchenko > wrote: >> Hello! >> >> Thank you for the report. >> >> The first patch was added to JTHarness repo (the current approach should be changed for 508 compliance). > What is "508 compliance"? "Section 508" refers to US regulations on accessibility. >> Now it should be possible to use JTReg build-all script to build JTReg and run it in gui mode. >> >> You need to change JTHarness mercurial tag in the build-all script (JTHARNESS_VERSION=fdf62f8d752f) to try it. >> > Who will be updating the build-all script ? Will you tag a new version > in JTHarness for this or will it be OK to use a change ID in > build-all.sh ? I would prefer that we don't update build-all.sh for every single bug fix in dependencies. In general, the standard build-all.sh script should refer to tested, tagged builds, although it is technically OK to update it temporarily to refer to change IDs. > > Finally, shouldn't you change the state of CODETOOLS-7902102 to closed > in JBS now that you've committed a fix? I'm actually surprised that > this doesn't happen automatically like in the JDK project. HG Updater only knows about JDK issues and JDK repos.? We have to track other bugs manually. > > Regards, > Volker > > PS: Will you also have the chance to look at the other bug I've opened :) > > CODETOOLS-7902103: Can't display test files if running with 'jtreg -gui' > https://bugs.openjdk.java.net/browse/CODETOOLS-7902103 This is on my list. -- Jon > >> Thank you. >> >> ?Alexey >> >>> On Jan 19, 2018, at 7:46 PM, Volker Simonis wrote: >>> >>> Looking more closely at this issue, I think the correct "quick fix" >>> will be to add the following copy action to the "compile.resources" >>> target in build/build.xml >>> >>> >> tofile="${build.classes}/com/sun/javatest/tool/images/splash.gif"/> >>> >>> Just renaming the startup.icon to an existing icon wouldn't help >>> because the icons names "spl_*.gif" are not copied over into the >>> generated images. >>> >>> Creating a generic "splash.gif" would also help, because that one will >>> be copied over into the generated images. >>> >>> Regards, >>> Volker >>> >>> >>> On Fri, Jan 19, 2018 at 4:52 PM, Volker Simonis >>> wrote: >>>> Hi, >>>> >>>> can somebody please have a look at the following issue, which prevents >>>> users who built jtreg/jtharness from source to run jtreg in gui mode. >>>> I can provide a trivial fix as sketched at the end of the problem >>>> description if that's desired? >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7902102 >>>> >>>> If you build jtreg and jtharness from source (e.g. with the new >>>> "make/buiild-all.sh" script from jtreg) and run 'jtreg -gui' jtharness >>>> will crash with the following StackOverflowError: >>>> >>>> Error: Unexpected exception occurred! java.lang.StackOverflowError >>>> java.lang.StackOverflowError >>>> at java.base/java.util.ResourceBundle$CacheKey.hashCode(ResourceBundle.java:724) >>>> at java.base/java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:946) >>>> at java.base/java.util.ResourceBundle.findBundleInCache(ResourceBundle.java:2066) >>>> at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1742) >>>> at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >>>> at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >>>> at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1654) >>>> at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1585) >>>> at java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:1276) >>>> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:217) >>>> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:215) >>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>> at com.sun.javatest.ResourceLoader.getSBundle(ResourceLoader.java:214) >>>> at com.sun.javatest.ResourceLoader.getBundle(ResourceLoader.java:199) >>>> at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:121) >>>> at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:119) >>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>> at com.sun.javatest.util.I18NResourceBundle.getObj(I18NResourceBundle.java:118) >>>> at com.sun.javatest.util.I18NResourceBundle.getOptionalString(I18NResourceBundle.java:104) >>>> at com.sun.javatest.tool.Startup.show(Startup.java:97) >>>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>>> at com.sun.javatest.tool.Startup.show(Startup.java:105) >>>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>>> at com.sun.javatest.tool.Startup.show(Startup.java:105) >>>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>>> ... >>>> >>>> This is because jtharness tries to load the splash screen image from >>>> "com/sun/javatest/tool/images/splash.gif" which doesn't exist and >>>> leeds to an infinite recursion. >>>> >>>> The splash screen image is defined in com/sun/javatest/tool/i18n.properties: >>>> >>>> startup.icon=com/sun/javatest/tool/images/splash.gif >>>> >>>> but com/sun/javatest/tool/images only contains: >>>> >>>> jticon.gif jtlogo.png selected.gif spl_412.gif spl_413.gif spl_421.gif >>>> spl_42.gif spl_43.gif spl_441.gif spl_44.gif >>>> jtlogo.gif partially.gif spl_412F.gif spl_413F.gif spl_421F.gif >>>> spl_42F.gif spl_43F.gif spl_441F.gif spl_44F.gif unselected.gif >>>> >>>> but no splash.gif. >>>> >>>> The trivial fix would be to either create a generic "splash.gif" or to >>>> define startup.icon to point to an existing image. >>>> >>>> The problem is that the splash screen gifs contain a string with the >>>> jtHarness version. So a more general solution would be to create such >>>> a gif as part of the build (e.g. from a generic template). >>>> >>>> I think this a "day-zero" problem (at lease from the day the jtHarness >>>> sources are in the OpenJDK Mercurial repositories) but has never been >>>> encountered because people usually used pre-built version of jtHarness >>>> from Oracle which contain a valid "splash.gif" icon. >>>> >>>> Now, with the new jtReg build script "make/buiild-all.sh" which makes >>>> it easy for everybody to build jtReg and all its dependencies >>>> (including jtHarness) from source this problem will affect everybody >>>> who does so! From alexey.fedorchenko at oracle.com Tue Jan 23 13:56:49 2018 From: alexey.fedorchenko at oracle.com (Alexey Fedorchenko) Date: Tue, 23 Jan 2018 16:56:49 +0300 Subject: CODETOOLS-7902102 jtharness crashes with StackOverflowError if called from 'jtreg -gui In-Reply-To: References: Message-ID: <57A9A4C9-0235-4FB6-9176-AABEFFA515C2@oracle.com> Hello! Thank you for the report. The first patch was added to JTHarness repo (the current approach should be changed for 508 compliance). Now it should be possible to use JTReg build-all script to build JTReg and run it in gui mode. You need to change JTHarness mercurial tag in the build-all script (JTHARNESS_VERSION=fdf62f8d752f) to try it. Thank you. ?Alexey > On Jan 19, 2018, at 7:46 PM, Volker Simonis wrote: > > Looking more closely at this issue, I think the correct "quick fix" > will be to add the following copy action to the "compile.resources" > target in build/build.xml > > tofile="${build.classes}/com/sun/javatest/tool/images/splash.gif"/> > > Just renaming the startup.icon to an existing icon wouldn't help > because the icons names "spl_*.gif" are not copied over into the > generated images. > > Creating a generic "splash.gif" would also help, because that one will > be copied over into the generated images. > > Regards, > Volker > > > On Fri, Jan 19, 2018 at 4:52 PM, Volker Simonis > wrote: >> Hi, >> >> can somebody please have a look at the following issue, which prevents >> users who built jtreg/jtharness from source to run jtreg in gui mode. >> I can provide a trivial fix as sketched at the end of the problem >> description if that's desired? >> >> Thank you and best regards, >> Volker >> >> https://bugs.openjdk.java.net/browse/CODETOOLS-7902102 >> >> If you build jtreg and jtharness from source (e.g. with the new >> "make/buiild-all.sh" script from jtreg) and run 'jtreg -gui' jtharness >> will crash with the following StackOverflowError: >> >> Error: Unexpected exception occurred! java.lang.StackOverflowError >> java.lang.StackOverflowError >> at java.base/java.util.ResourceBundle$CacheKey.hashCode(ResourceBundle.java:724) >> at java.base/java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:946) >> at java.base/java.util.ResourceBundle.findBundleInCache(ResourceBundle.java:2066) >> at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1742) >> at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >> at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >> at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1654) >> at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1585) >> at java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:1276) >> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:217) >> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:215) >> at java.base/java.security.AccessController.doPrivileged(Native Method) >> at com.sun.javatest.ResourceLoader.getSBundle(ResourceLoader.java:214) >> at com.sun.javatest.ResourceLoader.getBundle(ResourceLoader.java:199) >> at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:121) >> at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:119) >> at java.base/java.security.AccessController.doPrivileged(Native Method) >> at com.sun.javatest.util.I18NResourceBundle.getObj(I18NResourceBundle.java:118) >> at com.sun.javatest.util.I18NResourceBundle.getOptionalString(I18NResourceBundle.java:104) >> at com.sun.javatest.tool.Startup.show(Startup.java:97) >> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >> at com.sun.javatest.tool.Startup.show(Startup.java:105) >> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >> at com.sun.javatest.tool.Startup.show(Startup.java:105) >> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >> ... >> >> This is because jtharness tries to load the splash screen image from >> "com/sun/javatest/tool/images/splash.gif" which doesn't exist and >> leeds to an infinite recursion. >> >> The splash screen image is defined in com/sun/javatest/tool/i18n.properties: >> >> startup.icon=com/sun/javatest/tool/images/splash.gif >> >> but com/sun/javatest/tool/images only contains: >> >> jticon.gif jtlogo.png selected.gif spl_412.gif spl_413.gif spl_421.gif >> spl_42.gif spl_43.gif spl_441.gif spl_44.gif >> jtlogo.gif partially.gif spl_412F.gif spl_413F.gif spl_421F.gif >> spl_42F.gif spl_43F.gif spl_441F.gif spl_44F.gif unselected.gif >> >> but no splash.gif. >> >> The trivial fix would be to either create a generic "splash.gif" or to >> define startup.icon to point to an existing image. >> >> The problem is that the splash screen gifs contain a string with the >> jtHarness version. So a more general solution would be to create such >> a gif as part of the build (e.g. from a generic template). >> >> I think this a "day-zero" problem (at lease from the day the jtHarness >> sources are in the OpenJDK Mercurial repositories) but has never been >> encountered because people usually used pre-built version of jtHarness >> from Oracle which contain a valid "splash.gif" icon. >> >> Now, with the new jtReg build script "make/buiild-all.sh" which makes >> it easy for everybody to build jtReg and all its dependencies >> (including jtHarness) from source this problem will affect everybody >> who does so! From volker.simonis at gmail.com Tue Jan 23 14:15:59 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 23 Jan 2018 15:15:59 +0100 Subject: CODETOOLS-7902102 jtharness crashes with StackOverflowError if called from 'jtreg -gui In-Reply-To: <57A9A4C9-0235-4FB6-9176-AABEFFA515C2@oracle.com> References: <57A9A4C9-0235-4FB6-9176-AABEFFA515C2@oracle.com> Message-ID: Hi Alexey, your change looks fine. Thanks for fixing! On Tue, Jan 23, 2018 at 2:56 PM, Alexey Fedorchenko wrote: > Hello! > > Thank you for the report. > > The first patch was added to JTHarness repo (the current approach should be changed for 508 compliance). What is "508 compliance"? > Now it should be possible to use JTReg build-all script to build JTReg and run it in gui mode. > > You need to change JTHarness mercurial tag in the build-all script (JTHARNESS_VERSION=fdf62f8d752f) to try it. > Who will be updating the build-all script ? Will you tag a new version in JTHarness for this or will it be OK to use a change ID in build-all.sh ? Finally, shouldn't you change the state of CODETOOLS-7902102 to closed in JBS now that you've committed a fix? I'm actually surprised that this doesn't happen automatically like in the JDK project. Regards, Volker PS: Will you also have the chance to look at the other bug I've opened :) CODETOOLS-7902103: Can't display test files if running with 'jtreg -gui' https://bugs.openjdk.java.net/browse/CODETOOLS-7902103 > Thank you. > > ?Alexey > >> On Jan 19, 2018, at 7:46 PM, Volker Simonis wrote: >> >> Looking more closely at this issue, I think the correct "quick fix" >> will be to add the following copy action to the "compile.resources" >> target in build/build.xml >> >> > tofile="${build.classes}/com/sun/javatest/tool/images/splash.gif"/> >> >> Just renaming the startup.icon to an existing icon wouldn't help >> because the icons names "spl_*.gif" are not copied over into the >> generated images. >> >> Creating a generic "splash.gif" would also help, because that one will >> be copied over into the generated images. >> >> Regards, >> Volker >> >> >> On Fri, Jan 19, 2018 at 4:52 PM, Volker Simonis >> wrote: >>> Hi, >>> >>> can somebody please have a look at the following issue, which prevents >>> users who built jtreg/jtharness from source to run jtreg in gui mode. >>> I can provide a trivial fix as sketched at the end of the problem >>> description if that's desired? >>> >>> Thank you and best regards, >>> Volker >>> >>> https://bugs.openjdk.java.net/browse/CODETOOLS-7902102 >>> >>> If you build jtreg and jtharness from source (e.g. with the new >>> "make/buiild-all.sh" script from jtreg) and run 'jtreg -gui' jtharness >>> will crash with the following StackOverflowError: >>> >>> Error: Unexpected exception occurred! java.lang.StackOverflowError >>> java.lang.StackOverflowError >>> at java.base/java.util.ResourceBundle$CacheKey.hashCode(ResourceBundle.java:724) >>> at java.base/java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:946) >>> at java.base/java.util.ResourceBundle.findBundleInCache(ResourceBundle.java:2066) >>> at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1742) >>> at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >>> at java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >>> at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1654) >>> at java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1585) >>> at java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:1276) >>> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:217) >>> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:215) >>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>> at com.sun.javatest.ResourceLoader.getSBundle(ResourceLoader.java:214) >>> at com.sun.javatest.ResourceLoader.getBundle(ResourceLoader.java:199) >>> at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:121) >>> at com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:119) >>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>> at com.sun.javatest.util.I18NResourceBundle.getObj(I18NResourceBundle.java:118) >>> at com.sun.javatest.util.I18NResourceBundle.getOptionalString(I18NResourceBundle.java:104) >>> at com.sun.javatest.tool.Startup.show(Startup.java:97) >>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>> at com.sun.javatest.tool.Startup.show(Startup.java:105) >>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>> at com.sun.javatest.tool.Startup.show(Startup.java:105) >>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>> ... >>> >>> This is because jtharness tries to load the splash screen image from >>> "com/sun/javatest/tool/images/splash.gif" which doesn't exist and >>> leeds to an infinite recursion. >>> >>> The splash screen image is defined in com/sun/javatest/tool/i18n.properties: >>> >>> startup.icon=com/sun/javatest/tool/images/splash.gif >>> >>> but com/sun/javatest/tool/images only contains: >>> >>> jticon.gif jtlogo.png selected.gif spl_412.gif spl_413.gif spl_421.gif >>> spl_42.gif spl_43.gif spl_441.gif spl_44.gif >>> jtlogo.gif partially.gif spl_412F.gif spl_413F.gif spl_421F.gif >>> spl_42F.gif spl_43F.gif spl_441F.gif spl_44F.gif unselected.gif >>> >>> but no splash.gif. >>> >>> The trivial fix would be to either create a generic "splash.gif" or to >>> define startup.icon to point to an existing image. >>> >>> The problem is that the splash screen gifs contain a string with the >>> jtHarness version. So a more general solution would be to create such >>> a gif as part of the build (e.g. from a generic template). >>> >>> I think this a "day-zero" problem (at lease from the day the jtHarness >>> sources are in the OpenJDK Mercurial repositories) but has never been >>> encountered because people usually used pre-built version of jtHarness >>> from Oracle which contain a valid "splash.gif" icon. >>> >>> Now, with the new jtReg build script "make/buiild-all.sh" which makes >>> it easy for everybody to build jtReg and all its dependencies >>> (including jtHarness) from source this problem will affect everybody >>> who does so! > From volker.simonis at gmail.com Tue Jan 23 16:21:34 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 23 Jan 2018 17:21:34 +0100 Subject: CODETOOLS-7902102 jtharness crashes with StackOverflowError if called from 'jtreg -gui In-Reply-To: References: <57A9A4C9-0235-4FB6-9176-AABEFFA515C2@oracle.com> Message-ID: On Tue, Jan 23, 2018 at 4:50 PM, Jonathan Gibbons wrote: > > > On 1/23/18 6:15 AM, Volker Simonis wrote: >> >> Hi Alexey, >> >> your change looks fine. Thanks for fixing! >> >> On Tue, Jan 23, 2018 at 2:56 PM, Alexey Fedorchenko >> wrote: >>> >>> Hello! >>> >>> Thank you for the report. >>> >>> The first patch was added to JTHarness repo (the current approach >>> should be changed for 508 compliance). >> >> What is "508 compliance"? > > "Section 508" refers to US regulations on accessibility. I see - that's heavy stuff :) Thanks for the explanation. > >>> Now it should be possible to use JTReg build-all script to build JTReg >>> and run it in gui mode. >>> >>> You need to change JTHarness mercurial tag in the build-all script >>> (JTHARNESS_VERSION=fdf62f8d752f) to try it. >>> >> Who will be updating the build-all script ? Will you tag a new version >> in JTHarness for this or will it be OK to use a change ID in >> build-all.sh ? > > I would prefer that we don't update build-all.sh for every single bug fix in > dependencies. > In general, the standard build-all.sh script should refer to tested, tagged > builds, although > it is technically OK to update it temporarily to refer to change IDs. > I agree, but in this case it is a pretty major loss in functionality. At least in my opinion, although obviously nobody else has noticed it until now. We can wait until somebody else complains that "jterg -gui" doesn't work. >> >> Finally, shouldn't you change the state of CODETOOLS-7902102 to closed >> in JBS now that you've committed a fix? I'm actually surprised that >> this doesn't happen automatically like in the JDK project. > > HG Updater only knows about JDK issues and JDK repos. We have to track > other bugs manually. > >> >> Regards, >> Volker >> >> PS: Will you also have the chance to look at the other bug I've opened :) >> >> CODETOOLS-7902103: Can't display test files if running with 'jtreg -gui' >> https://bugs.openjdk.java.net/browse/CODETOOLS-7902103 > > This is on my list. > That's great - thanks! Volker > -- Jon > >> >>> Thank you. >>> >>> ?Alexey >>> >>>> On Jan 19, 2018, at 7:46 PM, Volker Simonis >>>> wrote: >>>> >>>> Looking more closely at this issue, I think the correct "quick fix" >>>> will be to add the following copy action to the "compile.resources" >>>> target in build/build.xml >>>> >>>> >>> >>>> tofile="${build.classes}/com/sun/javatest/tool/images/splash.gif"/> >>>> >>>> Just renaming the startup.icon to an existing icon wouldn't help >>>> because the icons names "spl_*.gif" are not copied over into the >>>> generated images. >>>> >>>> Creating a generic "splash.gif" would also help, because that one will >>>> be copied over into the generated images. >>>> >>>> Regards, >>>> Volker >>>> >>>> >>>> On Fri, Jan 19, 2018 at 4:52 PM, Volker Simonis >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> can somebody please have a look at the following issue, which prevents >>>>> users who built jtreg/jtharness from source to run jtreg in gui mode. >>>>> I can provide a trivial fix as sketched at the end of the problem >>>>> description if that's desired? >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7902102 >>>>> >>>>> If you build jtreg and jtharness from source (e.g. with the new >>>>> "make/buiild-all.sh" script from jtreg) and run 'jtreg -gui' jtharness >>>>> will crash with the following StackOverflowError: >>>>> >>>>> Error: Unexpected exception occurred! java.lang.StackOverflowError >>>>> java.lang.StackOverflowError >>>>> at >>>>> java.base/java.util.ResourceBundle$CacheKey.hashCode(ResourceBundle.java:724) >>>>> at >>>>> java.base/java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:946) >>>>> at >>>>> java.base/java.util.ResourceBundle.findBundleInCache(ResourceBundle.java:2066) >>>>> at >>>>> java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1742) >>>>> at >>>>> java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >>>>> at >>>>> java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >>>>> at >>>>> java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1654) >>>>> at >>>>> java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1585) >>>>> at >>>>> java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:1276) >>>>> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:217) >>>>> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:215) >>>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>>> at com.sun.javatest.ResourceLoader.getSBundle(ResourceLoader.java:214) >>>>> at com.sun.javatest.ResourceLoader.getBundle(ResourceLoader.java:199) >>>>> at >>>>> com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:121) >>>>> at >>>>> com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:119) >>>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>>> at >>>>> com.sun.javatest.util.I18NResourceBundle.getObj(I18NResourceBundle.java:118) >>>>> at >>>>> com.sun.javatest.util.I18NResourceBundle.getOptionalString(I18NResourceBundle.java:104) >>>>> at com.sun.javatest.tool.Startup.show(Startup.java:97) >>>>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>>>> at com.sun.javatest.tool.Startup.show(Startup.java:105) >>>>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>>>> at com.sun.javatest.tool.Startup.show(Startup.java:105) >>>>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>>>> ... >>>>> >>>>> This is because jtharness tries to load the splash screen image from >>>>> "com/sun/javatest/tool/images/splash.gif" which doesn't exist and >>>>> leeds to an infinite recursion. >>>>> >>>>> The splash screen image is defined in >>>>> com/sun/javatest/tool/i18n.properties: >>>>> >>>>> startup.icon=com/sun/javatest/tool/images/splash.gif >>>>> >>>>> but com/sun/javatest/tool/images only contains: >>>>> >>>>> jticon.gif jtlogo.png selected.gif spl_412.gif spl_413.gif spl_421.gif >>>>> spl_42.gif spl_43.gif spl_441.gif spl_44.gif >>>>> jtlogo.gif partially.gif spl_412F.gif spl_413F.gif spl_421F.gif >>>>> spl_42F.gif spl_43F.gif spl_441F.gif spl_44F.gif unselected.gif >>>>> >>>>> but no splash.gif. >>>>> >>>>> The trivial fix would be to either create a generic "splash.gif" or to >>>>> define startup.icon to point to an existing image. >>>>> >>>>> The problem is that the splash screen gifs contain a string with the >>>>> jtHarness version. So a more general solution would be to create such >>>>> a gif as part of the build (e.g. from a generic template). >>>>> >>>>> I think this a "day-zero" problem (at lease from the day the jtHarness >>>>> sources are in the OpenJDK Mercurial repositories) but has never been >>>>> encountered because people usually used pre-built version of jtHarness >>>>> from Oracle which contain a valid "splash.gif" icon. >>>>> >>>>> Now, with the new jtReg build script "make/buiild-all.sh" which makes >>>>> it easy for everybody to build jtReg and all its dependencies >>>>> (including jtHarness) from source this problem will affect everybody >>>>> who does so! > > From jonathan.gibbons at oracle.com Tue Jan 23 17:32:51 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 23 Jan 2018 09:32:51 -0800 Subject: CODETOOLS-7902102 jtharness crashes with StackOverflowError if called from 'jtreg -gui In-Reply-To: References: <57A9A4C9-0235-4FB6-9176-AABEFFA515C2@oracle.com> Message-ID: <3e1e06ab-8f41-ce4f-4a5e-8b1ebf5ff1a2@oracle.com> Volker, I think we should address these combined issues under the general heading of "make jtreg -gui work" and make that a focus upcoming jtreg work. -- Jon On 1/23/18 8:21 AM, Volker Simonis wrote: > On Tue, Jan 23, 2018 at 4:50 PM, Jonathan Gibbons > wrote: >> >> On 1/23/18 6:15 AM, Volker Simonis wrote: >>> Hi Alexey, >>> >>> your change looks fine. Thanks for fixing! >>> >>> On Tue, Jan 23, 2018 at 2:56 PM, Alexey Fedorchenko >>> wrote: >>>> Hello! >>>> >>>> Thank you for the report. >>>> >>>> The first patch was added to JTHarness repo (the current approach >>>> should be changed for 508 compliance). >>> What is "508 compliance"? >> "Section 508" refers to US regulations on accessibility. > I see - that's heavy stuff :) Thanks for the explanation. > >>>> Now it should be possible to use JTReg build-all script to build JTReg >>>> and run it in gui mode. >>>> >>>> You need to change JTHarness mercurial tag in the build-all script >>>> (JTHARNESS_VERSION=fdf62f8d752f) to try it. >>>> >>> Who will be updating the build-all script ? Will you tag a new version >>> in JTHarness for this or will it be OK to use a change ID in >>> build-all.sh ? >> I would prefer that we don't update build-all.sh for every single bug fix in >> dependencies. >> In general, the standard build-all.sh script should refer to tested, tagged >> builds, although >> it is technically OK to update it temporarily to refer to change IDs. >> > I agree, but in this case it is a pretty major loss in functionality. > At least in my opinion, although obviously nobody else has noticed it > until now. We can wait until somebody else complains that "jterg -gui" > doesn't work. > >>> Finally, shouldn't you change the state of CODETOOLS-7902102 to closed >>> in JBS now that you've committed a fix? I'm actually surprised that >>> this doesn't happen automatically like in the JDK project. >> HG Updater only knows about JDK issues and JDK repos. We have to track >> other bugs manually. >> >>> Regards, >>> Volker >>> >>> PS: Will you also have the chance to look at the other bug I've opened :) >>> >>> CODETOOLS-7902103: Can't display test files if running with 'jtreg -gui' >>> https://bugs.openjdk.java.net/browse/CODETOOLS-7902103 >> This is on my list. >> > That's great - thanks! > > Volker > >> -- Jon >> >>>> Thank you. >>>> >>>> ?Alexey >>>> >>>>> On Jan 19, 2018, at 7:46 PM, Volker Simonis >>>>> wrote: >>>>> >>>>> Looking more closely at this issue, I think the correct "quick fix" >>>>> will be to add the following copy action to the "compile.resources" >>>>> target in build/build.xml >>>>> >>>>> >>>> >>>>> tofile="${build.classes}/com/sun/javatest/tool/images/splash.gif"/> >>>>> >>>>> Just renaming the startup.icon to an existing icon wouldn't help >>>>> because the icons names "spl_*.gif" are not copied over into the >>>>> generated images. >>>>> >>>>> Creating a generic "splash.gif" would also help, because that one will >>>>> be copied over into the generated images. >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> >>>>> On Fri, Jan 19, 2018 at 4:52 PM, Volker Simonis >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> can somebody please have a look at the following issue, which prevents >>>>>> users who built jtreg/jtharness from source to run jtreg in gui mode. >>>>>> I can provide a trivial fix as sketched at the end of the problem >>>>>> description if that's desired? >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/CODETOOLS-7902102 >>>>>> >>>>>> If you build jtreg and jtharness from source (e.g. with the new >>>>>> "make/buiild-all.sh" script from jtreg) and run 'jtreg -gui' jtharness >>>>>> will crash with the following StackOverflowError: >>>>>> >>>>>> Error: Unexpected exception occurred! java.lang.StackOverflowError >>>>>> java.lang.StackOverflowError >>>>>> at >>>>>> java.base/java.util.ResourceBundle$CacheKey.hashCode(ResourceBundle.java:724) >>>>>> at >>>>>> java.base/java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:946) >>>>>> at >>>>>> java.base/java.util.ResourceBundle.findBundleInCache(ResourceBundle.java:2066) >>>>>> at >>>>>> java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1742) >>>>>> at >>>>>> java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >>>>>> at >>>>>> java.base/java.util.ResourceBundle.findBundle(ResourceBundle.java:1720) >>>>>> at >>>>>> java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1654) >>>>>> at >>>>>> java.base/java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1585) >>>>>> at >>>>>> java.base/java.util.ResourceBundle.getBundle(ResourceBundle.java:1276) >>>>>> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:217) >>>>>> at com.sun.javatest.ResourceLoader$2.run(ResourceLoader.java:215) >>>>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>>>> at com.sun.javatest.ResourceLoader.getSBundle(ResourceLoader.java:214) >>>>>> at com.sun.javatest.ResourceLoader.getBundle(ResourceLoader.java:199) >>>>>> at >>>>>> com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:121) >>>>>> at >>>>>> com.sun.javatest.util.I18NResourceBundle$1.run(I18NResourceBundle.java:119) >>>>>> at java.base/java.security.AccessController.doPrivileged(Native Method) >>>>>> at >>>>>> com.sun.javatest.util.I18NResourceBundle.getObj(I18NResourceBundle.java:118) >>>>>> at >>>>>> com.sun.javatest.util.I18NResourceBundle.getOptionalString(I18NResourceBundle.java:104) >>>>>> at com.sun.javatest.tool.Startup.show(Startup.java:97) >>>>>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>>>>> at com.sun.javatest.tool.Startup.show(Startup.java:105) >>>>>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>>>>> at com.sun.javatest.tool.Startup.show(Startup.java:105) >>>>>> at com.sun.javatest.tool.Startup.showDefault(Startup.java:93) >>>>>> ... >>>>>> >>>>>> This is because jtharness tries to load the splash screen image from >>>>>> "com/sun/javatest/tool/images/splash.gif" which doesn't exist and >>>>>> leeds to an infinite recursion. >>>>>> >>>>>> The splash screen image is defined in >>>>>> com/sun/javatest/tool/i18n.properties: >>>>>> >>>>>> startup.icon=com/sun/javatest/tool/images/splash.gif >>>>>> >>>>>> but com/sun/javatest/tool/images only contains: >>>>>> >>>>>> jticon.gif jtlogo.png selected.gif spl_412.gif spl_413.gif spl_421.gif >>>>>> spl_42.gif spl_43.gif spl_441.gif spl_44.gif >>>>>> jtlogo.gif partially.gif spl_412F.gif spl_413F.gif spl_421F.gif >>>>>> spl_42F.gif spl_43F.gif spl_441F.gif spl_44F.gif unselected.gif >>>>>> >>>>>> but no splash.gif. >>>>>> >>>>>> The trivial fix would be to either create a generic "splash.gif" or to >>>>>> define startup.icon to point to an existing image. >>>>>> >>>>>> The problem is that the splash screen gifs contain a string with the >>>>>> jtHarness version. So a more general solution would be to create such >>>>>> a gif as part of the build (e.g. from a generic template). >>>>>> >>>>>> I think this a "day-zero" problem (at lease from the day the jtHarness >>>>>> sources are in the OpenJDK Mercurial repositories) but has never been >>>>>> encountered because people usually used pre-built version of jtHarness >>>>>> from Oracle which contain a valid "splash.gif" icon. >>>>>> >>>>>> Now, with the new jtReg build script "make/buiild-all.sh" which makes >>>>>> it easy for everybody to build jtReg and all its dependencies >>>>>> (including jtHarness) from source this problem will affect everybody >>>>>> who does so! >> From jonathan.gibbons at oracle.com Fri Jan 26 22:40:16 2018 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 26 Jan 2018 22:40:16 +0000 Subject: hg: code-tools/jtreg: Added tag jtreg4.2-b12 for changeset 652902f7fb0e Message-ID: <201801262240.w0QMeG1R015358@aojmv0008.oracle.com> Changeset: 3074eb329915 Author: jjg Date: 2018-01-26 14:35 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/3074eb329915 Added tag jtreg4.2-b12 for changeset 652902f7fb0e ! .hgtags From jonathan.gibbons at oracle.com Wed Jan 31 21:48:29 2018 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 31 Jan 2018 21:48:29 +0000 Subject: hg: code-tools/jtreg: 7902113: Windows: multiple issues relativizing links in report directory to files in work directory Message-ID: <201801312148.w0VLmTgU018465@aojmv0008.oracle.com> Changeset: 5e98d67efa68 Author: jjg Date: 2018-01-31 13:44 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/5e98d67efa68 7902113: Windows: multiple issues relativizing links in report directory to files in work directory ! src/share/classes/com/sun/javatest/regtest/report/RegressionReporter.java + test/fixup/FixupTest.gmk + test/fixup/tests/a/TEST.ROOT + test/fixup/tests/a/dir!/Test.java + test/fixup/tests/b/TEST.ROOT + test/fixup/tests/b/d!r/Test.java ! test/multirun/MultiRunTest.gmk