Code not being run in JTREG environment

[Jonathan Gibbons]

On 06/05/2015 08:26 AM, Pete Brunet wrote:
>
> On 6/5/15 10:14 AM, Jonathan Gibbons wrote:
>> Pete,
>>
>> As a matter of style, note that jtreg directives can span lines, and so
>>
>> # @run shell basic.sh
>> #
>> # Command-line usage: sh basic.sh /path/to/build
>>
>> is equivalent to
>>
>> # @run shell basic.sh Command-line usage: sh basic.sh /path/to/build
>>
>> because it is all in the same comment block.
>>
>> I'd recommend deleting the # character on the intervening line, so that
>> it reads
>>
>> # @run shell basic.sh
>>
>> # Command-line usage: sh basic.sh /path/to/build
> Thanks Jon, I deleted the # (and left it as a blank line).
>>
>> As for why your test might behave differently in a jtreg environment,
>> are you dependent on any environment variables? jtreg specifically
>> runs with a limited set of env vars set.  See the jtreg tag spec
>> and/or the command line help for more details (or ask here) if you
>> think this might be a factor.
> The test is not dependent on any environment variables.


If it were me, I would proceed with debug prints in your shell script 
(or use set -x, so that shell commands are echoed they are executed) and 
then have a debug print in the main program in your java class, so that 
you can confirm that the shell script is executing your class 
correctly.  After that, you're down to differential debugging -- what is 
different between you running the class manually and jtreg running the 
shell script that runs the class.  Primary environmental issues to 
investigate could be

* system properties
* env variables
* class loader
* threads and thread groups

>> -- Jon
>>
>> On 06/05/2015 05:57 AM, Pete Brunet wrote:
>>> On 6/5/15 1:06 AM, David Holmes wrote:
>>>> Hi Peter,
>>>>
>>>> On 5/06/2015 4:01 PM, Pete Brunet wrote:
>>>>> Hi, When I run java from the command line I can tell my code in
>>>>> java.awt.Toolkit.getDefaultToolkit is running but when I run in a
>>>>> JTREG
>>>>> environment I don't see any indication that the code is executing.
>>>>> The
>>>>> jtr log shows that my test java is being invoked and when I use
>>>>> -version
>>>>> the right version string appears in the log.
>>>>>
>>>>> Any ideas on what I might be doing wrong?
>>>> Need more info. How are you running jtreg? How is your test launched
>>>> ie othervm ? Is output from the test itself seen?
>>> Hi David, This is the invocation with the prompt at the client directory
>>> of the local repo:
>>>
>>> /cygdrive/c/Users/Pete/jtreg/bin/jtreg
>>> -jdk:./build/windows-x86_64-normal-server-release/images/jdk
>>> ./jdk/test/javax/accessibility/AccessibilityProvider/
>>>
>>> This is from the shell script:
>>>
>>> # @test
>>> # @bug 8055160
>>> # @summary Unit test for javax.accessibility.AccessibilitySPI
>>> #
>>> # @build Load FooProvider BarProvider UnusedProvider
>>> # @run shell basic.sh
>>> #
>>> # Command-line usage: sh basic.sh /path/to/build
>>>
>>> This is from the jtr file:
>>>
>>> Working Directory:
>>> /cygdrive/c/Users/Pete/JDK9/JDK-8055160/client/JTwork/scratch
>>> +
>>> C:/Users/Pete/JDK9/JDK-8055160/client/./build/windows-x86_64-normal-server-release/images/jdk/bin/java
>>>
>>> -Djavax.accessibility.assistive_technologies=FooProvider -cp
>>> 'C:/Users/Pete/JDK9/JDK-8055160/client/JTwork/classes/javax/accessibility/AccessibilityProvider;x.test'
>>>
>>> Load pass FooProvider
>>> Working Directory:
>>> C:\\Users\\Pete\\JDK9\\JDK-8055160\\client\\JTwork\\scratch
>>> Exception in thread "main" java.lang.RuntimeException: FooProvider was
>>> not activated
>>>    at Load.main(Load.java:78)
>>>
>>> I don't see any output from printlns (or existence of a debug file I
>>> create) in java.awt.Toolkit.getDefaultToolkit but I do see all output
>>> from my test.
>>>
>>> This might not be a show stopper for me.  I could call
>>> java.awt.Toolkit.getDefaultToolkit from my test but I want to understand
>>> why it's called when running my java.exe from the command line but not
>>> from within jtreg.  Maybe I am not using jtreg correctly.
>>>
>>> I added awt-dev list in case that group might know the answer.
>>>
>>> Later in the morning I'll put a Thread.dumpStack in getDefaultToolkit
>>> and maybe that will give me a hint as to why it is called in the
>>> non-jtreg case but not in the jtreg environment.
>>>
>>> Pete
>>>> David
>>>>
>>>>> Thanks, Pete
>>>>>