Understanding -nativepath and how it is applied

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Understanding -nativepath and how it is applied

David Holmes
I have a test that uses native code.

I specify "@run main/othervm/native" for the main test class

I invoke jtreg with -nativepath

My test exec's a second VM that needs to load the native library. This
is done using ProcessTools.executeTestJvm.

When I run the test locally it works fine and if I print out
java.library.path it shows that the "nativepath" value has been set in
that property.

But when I run the test via our testing system it fails because the
native library cannot be found! The jtr file shows -Dtest.nativepath
being set as expected, but the exec'd VM doesn't have its value in
java.library.path!

I can obviously fix this by explicitly adding -Djava.library.path=... as
an explicit arg to the exec'd VM, but I want to understand how this
works in the local case but not otherwise.

I'm also wondering whether this is something that should be
automatically handled at the ProcessTools level?

Thanks,
David
Reply | Threaded
Open this post in threaded view
|

Re: Understanding -nativepath and how it is applied

Jonathan Gibbons


On 02/17/2020 11:21 PM, David Holmes wrote:

> I have a test that uses native code.
>
> I specify "@run main/othervm/native" for the main test class
>
> I invoke jtreg with -nativepath
>
> My test exec's a second VM that needs to load the native library. This
> is done using ProcessTools.executeTestJvm.
>
> When I run the test locally it works fine and if I print out
> java.library.path it shows that the "nativepath" value has been set in
> that property.
>
> But when I run the test via our testing system it fails because the
> native library cannot be found! The jtr file shows -Dtest.nativepath
> being set as expected, but the exec'd VM doesn't have its value in
> java.library.path!
>
> I can obviously fix this by explicitly adding -Djava.library.path=...
> as an explicit arg to the exec'd VM, but I want to understand how this
> works in the local case but not otherwise.
>
> I'm also wondering whether this is something that should be
> automatically handled at the ProcessTools level?
>
> Thanks,
> David

David,

jtreg has no control over the VMs that a test might itself exec. That is
entirely up to the test code, and any library code (such as
ProcessTools) that may be involved. The most that jtreg can do is
provide the information (i.e. test.* properties) that may be required in
order for the test to do what is required in the specific context of the
test itself.

-- Jon
Reply | Threaded
Open this post in threaded view
|

Re: Understanding -nativepath and how it is applied

David Holmes
Hi Jon,

On 19/02/2020 5:33 am, Jonathan Gibbons wrote:

>
>
> On 02/17/2020 11:21 PM, David Holmes wrote:
>> I have a test that uses native code.
>>
>> I specify "@run main/othervm/native" for the main test class
>>
>> I invoke jtreg with -nativepath
>>
>> My test exec's a second VM that needs to load the native library. This
>> is done using ProcessTools.executeTestJvm.
>>
>> When I run the test locally it works fine and if I print out
>> java.library.path it shows that the "nativepath" value has been set in
>> that property.
>>
>> But when I run the test via our testing system it fails because the
>> native library cannot be found! The jtr file shows -Dtest.nativepath
>> being set as expected, but the exec'd VM doesn't have its value in
>> java.library.path!
>>
>> I can obviously fix this by explicitly adding -Djava.library.path=...
>> as an explicit arg to the exec'd VM, but I want to understand how this
>> works in the local case but not otherwise.
>>
>> I'm also wondering whether this is something that should be
>> automatically handled at the ProcessTools level?
>>
>> Thanks,
>> David
>
> David,
>
> jtreg has no control over the VMs that a test might itself exec. That is
> entirely up to the test code, and any library code (such as
> ProcessTools) that may be involved. The most that jtreg can do is
> provide the information (i.e. test.* properties) that may be required in
> order for the test to do what is required in the specific context of the
> test itself.

Okay but somehow we go from -nativepath to -Dtest.nativepath to
-Djava.library.path (or equivalent). And somehow when running jtreg
locally an exec'd VM gets the same java.library.vm as the VM exec'd by
jtreg; but when jtreg is run in other cases it doesn't. I'm trying to
understand how we can possibly see differences in behaviour here.

Thanks,
David

> -- Jon