Jogamp-fat.jar not deploying on a Windows 7 64bits machine ?

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

Jogamp-fat.jar not deploying on a Windows 7 64bits machine ?

Mabula Haverkamp
Dear all,

A customer of mine that uses my software has an odd problem when he starts my application on his windows 7 system.

My application, currently uses the Jogamp-fat.jar and when the application starts, the native libraries are normally deployed in the OS temp folder.

In this case, the jogamp_exe_xxxxxxxxx.exe does not complete it's job, preventing application start-up.

I strongly suspect that some security feature/application on the customer's computer is blocking the jogamp_exe_xxxxxxxxx.exe proces, but we don't see any warning in the installed security software...(trend micro).

Is this issue known to occur, or does it not ring a bell ?

Would you think that this most likely is an issue specific to the customers windows 7 installation?

Thank you,

Mabula Haverkamp
Aries Productions
Reply | Threaded
Open this post in threaded view
|

Re: Jogamp-fat.jar not deploying on a Windows 7 64bits machine ?

gouessej
Administrator
Hello

A paranoid virus scanner prevents it from doing its job. Please try to disable the automated native library loading and manage the Java library path as indicated in the JOGL user's guide.

I proposed to replace this mechanism by a call to a Java API available only in Java >= 1.8 but if the virus scanner still prevents the loading of the extracted native libraries (DLL under Microsoft Windows), the only way to solve this problem will consist in disabling the virus scanner and on the long term to report this false positive to the software publisher of this virus scanner.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Jogamp-fat.jar not deploying on a Windows 7 64bits machine ?

hharrison
Do you still have a link to your proposed API change to use the > 1.8 API, I can't recall that discussion anymore.

Harvey
Reply | Threaded
Open this post in threaded view
|

Re: Jogamp-fat.jar not deploying on a Windows 7 64bits machine ?

hharrison
In reply to this post by gouessej
Do you still have a link to your proposed API change to use the > 1.8 API, I can't recall that discussion anymore.

Harvey
Reply | Threaded
Open this post in threaded view
|

Re: Jogamp-fat.jar not deploying on a Windows 7 64bits machine ?

gouessej
Administrator
The pitfall with File.canExecute() (available since Java 1.6) is that it might tell that a file is executable whereas its permissions indicate that it isn't :s whereas Files.isExecutable(Path) (available since Java 1.8) should work. java.nio.files.Files.getPosixFilePermissions() would work too:
https://jogamp.org/bugzilla/show_bug.cgi?id=1219#c71

Do you want me to provide a patch?
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Jogamp-fat.jar not deploying on a Windows 7 64bits machine ?

Sven Gothel
Administrator
Yes, to make sure that the user is capable to execute files on a given path
one sadly to test today.
(execute == native lib loading)

The filesystem's executable mount option or advanced attributes differs from
out old 'directory is executable' to simply enter/read the directories content.

> Files.isExecutable(Path) (available since Java 1.8) should work.
> java.nio.files.Files.getPosixFilePermissions()

If the above can replace the 'intrusive' exe-test on all platforms,
we simply can use it where available via reflection.
If so .. great stuff.

+++

Here is a commit in one branch, which I will merge to master w/ the javafx
branch, disabling the exe test altogether. This of course will render
the whole automatic library loading void.

https://jogamp.org/git/?p=gluegen.git;a=commit;h=e7ac6b284eb3515f552cba491c43efe75f0a4eba

On 3/22/19 10:39 AM, gouessej [via jogamp] wrote:

> The pitfall with File.canExecute() (available since Java 1.6) is that it might
> tell that a file is executable whereas its permissions indicate that it isn't
> :s whereas Files.isExecutable(Path) (available since Java 1.8) should work.
> java.nio.files.Files.getPosixFilePermissions() would work too:
> https://jogamp.org/bugzilla/show_bug.cgi?id=1219#c71
>
> Do you want me to provide a patch?
> Julien Gouesse | Personal blog <http://gouessej.wordpress.com> | Website
> <http://tuer.sourceforge.net>
>
Reply | Threaded
Open this post in threaded view
|

Re: Jogamp-fat.jar not deploying on a Windows 7 64bits machine ?

Sven Gothel
Administrator
I glanced over the implementation of OpenJDK 8's
'java.nio.file.Files.isExecutable(Path)',
which eventually issues java.nio.file.spi.FileSystemProvider.checkAccess(..)
and on 'Unix' it will test the files via:
"
NAME
       access, faccessat - check user's permissions for a file

SYNOPSIS
       #include <unistd.h>

       int access(const char *pathname, int mode);
"

This should be sufficient for the executable test, as we do nothing else :)

However, the problem arises that we need to bootstrap this test with a file
in the first place. This task of extracting and placing the file
in said folder potentially causes the virus scanner to freeze the process.

On all platforms but Windows, we use a simple empty file to test.
We (?)may find time to test with same empty file on Windows.
This test requires one to set the ACL permissions to non executable,
on GNU/Linux you would need to mount the temp folder non-executable or also
use said ACLs if supported.

Cheers, Sven

On 3/22/19 10:57 AM, Sven Gothel [via jogamp] wrote:

> Yes, to make sure that the user is capable to execute files on a given path
> one sadly to test today.
> (execute == native lib loading)
>
> The filesystem's executable mount option or advanced attributes differs from
> out old 'directory is executable' to simply enter/read the directories content.
>
>> Files.isExecutable(Path) (available since Java 1.8) should work.
>> java.nio.files.Files.getPosixFilePermissions()
>
> If the above can replace the 'intrusive' exe-test on all platforms,
> we simply can use it where available via reflection.
> If so .. great stuff.
>
> +++
>
> Here is a commit in one branch, which I will merge to master w/ the javafx
> branch, disabling the exe test altogether. This of course will render
> the whole automatic library loading void.
>
> https://jogamp.org/git/?p=gluegen.git;a=commit;h=e7ac6b284eb3515f552cba491c43efe75f0a4eba
>
> On 3/22/19 10:39 AM, gouessej [via jogamp] wrote:
>
>> The pitfall with File.canExecute() (available since Java 1.6) is that it might
>> tell that a file is executable whereas its permissions indicate that it isn't
>> :s whereas Files.isExecutable(Path) (available since Java 1.8) should work.
>> java.nio.files.Files.getPosixFilePermissions() would work too:
>> https://jogamp.org/bugzilla/show_bug.cgi?id=1219#c71
>>
>> Do you want me to provide a patch?
>> Julien Gouesse | Personal blog <http://gouessej.wordpress.com> | Website
>> <http://tuer.sourceforge.net>
>>
>
>
> ------------------------------------------------------------------------------
> If you reply to this email, your message will be added to the discussion below:
> http://forum.jogamp.org/Jogamp-fat-jar-not-deploying-on-a-Windows-7-64bits-machine-tp4039604p4039643.html
Reply | Threaded
Open this post in threaded view
|

Re: Jogamp-fat.jar not deploying on a Windows 7 64bits machine ?

Sven Gothel
Administrator
we may try this patch here ..

https://jogamp.org/git/?p=gluegen.git;a=commit;h=4375d2824ac6ff656df184ea0c19ab781e3524e8

"
Bug 1219, Bug 1231: Avoid deflating test-exe on Windows using
java.nio.file.Files.isExecutable(Path)

Attempt to resolved virus scanner false positive detection on Windows
while deflating the native code test-exe file in the temporary folder.

As Julien Gouesse suggested, using Java 1.7's
java.nio.file.Files.isExecutable(Path)
_may_ resolve the issue, this has to be thorougly tested.

This patch favors the nio's isExecutable file's ACL test
over the more intrusive execution itself using a simple shell script file w/
set executable flag.

Mind that previous tests allowed the shell script's execution,
even if the temp folder did not allow execution of native code.

We have to see how our testing results will be on this attempt.
"

On 3/22/19 12:35 PM, Sven Gothel [via jogamp] wrote:

> I glanced over the implementation of OpenJDK 8's
> 'java.nio.file.Files.isExecutable(Path)',
> which eventually issues java.nio.file.spi.FileSystemProvider.checkAccess(..)
> and on 'Unix' it will test the files via:
> "
> NAME
>        access, faccessat - check user's permissions for a file
>
> SYNOPSIS
>        #include <unistd.h>
>
>        int access(const char *pathname, int mode);
> "
>
> This should be sufficient for the executable test, as we do nothing else :)
>
> However, the problem arises that we need to bootstrap this test with a file
> in the first place. This task of extracting and placing the file
> in said folder potentially causes the virus scanner to freeze the process.
>
> On all platforms but Windows, we use a simple empty file to test.
> We (?)may find time to test with same empty file on Windows.
> This test requires one to set the ACL permissions to non executable,
> on GNU/Linux you would need to mount the temp folder non-executable or also
> use said ACLs if supported.
>
> Cheers, Sven
>
> On 3/22/19 10:57 AM, Sven Gothel [via jogamp] wrote:
>
>> Yes, to make sure that the user is capable to execute files on a given path
>> one sadly to test today.
>> (execute == native lib loading)
>>
>> The filesystem's executable mount option or advanced attributes differs from
>> out old 'directory is executable' to simply enter/read the directories content.
>>
>>> Files.isExecutable(Path) (available since Java 1.8) should work.
>>> java.nio.files.Files.getPosixFilePermissions()
>>
>> If the above can replace the 'intrusive' exe-test on all platforms,
>> we simply can use it where available via reflection.
>> If so .. great stuff.
>>
>> +++
>>
>> Here is a commit in one branch, which I will merge to master w/ the javafx
>> branch, disabling the exe test altogether. This of course will render
>> the whole automatic library loading void.
>>
>>
> https://jogamp.org/git/?p=gluegen.git;a=commit;h=e7ac6b284eb3515f552cba491c43efe75f0a4eba
>>
>> On 3/22/19 10:39 AM, gouessej [via jogamp] wrote:
>>
>>> The pitfall with File.canExecute() (available since Java 1.6) is that it might
>>> tell that a file is executable whereas its permissions indicate that it isn't
>>> :s whereas Files.isExecutable(Path) (available since Java 1.8) should work.
>>> java.nio.files.Files.getPosixFilePermissions() would work too:
>>> https://jogamp.org/bugzilla/show_bug.cgi?id=1219#c71
>>>
>>> Do you want me to provide a patch?
>>> Julien Gouesse | Personal blog <http://gouessej.wordpress.com> | Website
>>> <http://tuer.sourceforge.net>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> If you reply to this email, your message will be added to the discussion below:
>>
> http://forum.jogamp.org/Jogamp-fat-jar-not-deploying-on-a-Windows-7-64bits-machine-tp4039604p4039643.html
>
>
> ------------------------------------------------------------------------------
> If you reply to this email, your message will be added to the discussion below:
> http://forum.jogamp.org/Jogamp-fat-jar-not-deploying-on-a-Windows-7-64bits-machine-tp4039604p4039644.html
>
> To start a new topic under jogl, email [hidden email]
> To unsubscribe from jogl, click here
> <
> NAML
> <
http://forum.jogamp.org/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>


--
health & wealth
mailto:[hidden email] ; http://jausoft.com
land : +49 (471) 4707742 ; fax : +49 (471) 4707741
Timezone CET: PST+9, EST+6, UTC+1
Reply | Threaded
Open this post in threaded view
|

Re: Jogamp-fat.jar not deploying on a Windows 7 64bits machine ?

gouessej
Administrator
Excellent job, sorry for the delay. You can reproduce this issue with the virus scanner Avira as far as I remember. Note that there is a "free" version.
Julien Gouesse | Personal blog | Website
Reply | Threaded
Open this post in threaded view
|

Re: Jogamp-fat.jar not deploying on a Windows 7 64bits machine ?

Sven Gothel
Administrator
In reply to this post by Sven Gothel
following patch concludes this 'journey' for now,
tested on GNU/Linux and Windows:

https://jogamp.org/git/?p=gluegen.git;a=commit;h=0c567321c6d594ec11edfd3aa848a0a634c544ef

"
Bug 1219, Bug 1231: Re-add executable test by execution

Re-adding executable test by execution is required for 'blocker technology'
like Windows's 'Software Restriction Policies (SRP)',
which only gets activated by the actual execution attempt.
Merely testing the file's (ACL) execution flags via NIO's isExecutable is not
sufficient.

Implementation first tests the file's (ACL) execution flags via NIO's
isExecutable.
If the NIO test was successful or not available, the actual execution test is
performed.

To mitigate the virus scanner's false positive, we use an executable shell script
per default now, which may be overriden by the new environment
'jogamp.gluegen.UseNativeExeFile=true'

Tested on GNU/Linux with one temp folder having mount options 'noexec'
and on Windows using Software Restriction Policies (SRP) disallowing one temp
folder.
Both temp folder were first in line via environment 'java.io.tmpdir'.
"

On 3/24/19 3:34 AM, Sven Gothel [via jogamp] wrote:

> we may try this patch here ..
>
> https://jogamp.org/git/?p=gluegen.git;a=commit;h=4375d2824ac6ff656df184ea0c19ab781e3524e8
>
> "
> Bug 1219, Bug 1231: Avoid deflating test-exe on Windows using
> java.nio.file.Files.isExecutable(Path)
>
> Attempt to resolved virus scanner false positive detection on Windows
> while deflating the native code test-exe file in the temporary folder.
>
> As Julien Gouesse suggested, using Java 1.7's
> java.nio.file.Files.isExecutable(Path)
> _may_ resolve the issue, this has to be thorougly tested.
>
> This patch favors the nio's isExecutable file's ACL test
> over the more intrusive execution itself using a simple shell script file w/
> set executable flag.
>
> Mind that previous tests allowed the shell script's execution,
> even if the temp folder did not allow execution of native code.
>
> We have to see how our testing results will be on this attempt.
> "
>
> On 3/22/19 12:35 PM, Sven Gothel [via jogamp] wrote:
>
>> I glanced over the implementation of OpenJDK 8's
>> 'java.nio.file.Files.isExecutable(Path)',
>> which eventually issues java.nio.file.spi.FileSystemProvider.checkAccess(..)
>> and on 'Unix' it will test the files via:
>> "
>> NAME
>>        access, faccessat - check user's permissions for a file
>>
>> SYNOPSIS
>>        #include <unistd.h>
>>
>>        int access(const char *pathname, int mode);
>> "
>>
>> This should be sufficient for the executable test, as we do nothing else :)
>>
>> However, the problem arises that we need to bootstrap this test with a file
>> in the first place. This task of extracting and placing the file
>> in said folder potentially causes the virus scanner to freeze the process.
>>
>> On all platforms but Windows, we use a simple empty file to test.
>> We (?)may find time to test with same empty file on Windows.
>> This test requires one to set the ACL permissions to non executable,
>> on GNU/Linux you would need to mount the temp folder non-executable or also
>> use said ACLs if supported.
>>
>> Cheers, Sven
>>
>> On 3/22/19 10:57 AM, Sven Gothel [via jogamp] wrote:
>>
>>> Yes, to make sure that the user is capable to execute files on a given path
>>> one sadly to test today.
>>> (execute == native lib loading)
>>>
>>> The filesystem's executable mount option or advanced attributes differs from
>>> out old 'directory is executable' to simply enter/read the directories
> content.
>>>
>>>> Files.isExecutable(Path) (available since Java 1.8) should work.
>>>> java.nio.files.Files.getPosixFilePermissions()
>>>
>>> If the above can replace the 'intrusive' exe-test on all platforms,
>>> we simply can use it where available via reflection.
>>> If so .. great stuff.
>>>
>>> +++
>>>
>>> Here is a commit in one branch, which I will merge to master w/ the javafx
>>> branch, disabling the exe test altogether. This of course will render
>>> the whole automatic library loading void.
>>>
>>>
>>
> https://jogamp.org/git/?p=gluegen.git;a=commit;h=e7ac6b284eb3515f552cba491c43efe75f0a4eba
>>>
>>> On 3/22/19 10:39 AM, gouessej [via jogamp] wrote:
>>>
>>>> The pitfall with File.canExecute() (available since Java 1.6) is that it
> might
>>>> tell that a file is executable whereas its permissions indicate that it isn't
>>>> :s whereas Files.isExecutable(Path) (available since Java 1.8) should work.
>>>> java.nio.files.Files.getPosixFilePermissions() would work too:
>>>> https://jogamp.org/bugzilla/show_bug.cgi?id=1219#c71
>>>>
>>>> Do you want me to provide a patch?
>>>> Julien Gouesse | Personal blog <http://gouessej.wordpress.com> | Website
>>>> <http://tuer.sourceforge.net>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Jogamp-fat.jar not deploying on a Windows 7 64bits machine ?

gouessej
Administrator
Good job. I hope that only a few end users have Software Restriction Policies enabled on their operating system.
Julien Gouesse | Personal blog | Website