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

Tue Jan 23 17:32:51 UTC 2018

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
> <jonathan.gibbons at oracle.com> 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
>>> <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"?
>> "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 <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!
>>