CODETOOLS-7902102 jtharness crashes with StackOverflowError if called from 'jtreg -gui

Volker Simonis volker.simonis at gmail.com
Tue Jan 23 14:15:59 UTC 2018


Hi Alexey,

your change looks fine. Thanks for fixing!

On Tue, Jan 23, 2018 at 2:56 PM, Alexey Fedorchenko
<alexey.fedorchenko at oracle.com> 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 <volker.simonis at gmail.com> 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
>>
>>         <copy file="${src.dir}/com/sun/javatest/tool/images/spl_44.gif"
>>              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
>> <volker.simonis at gmail.com> 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!
>


More information about the code-tools-dev mailing list