JOGL 2.4 and Java 17 report

Have you tried providing

-Djava.io.tmpdir=/your/own/path

where the folder has exec rights enabled?

OR

chmod ug+wx /tmp/jogamp_0000/file_cache/

to enable write and exec rights on this cache folder for you and other users of your computer (I actually think it is useless since the IOUtil is creating this folder with exec rights enabled... but worth trying anyway)

Hi Martin,

I have tried setting tmp to my home dir on my Linux Mint installation

-Djava.io.tmpdir= /home/mabula/

Now we have the exact same error and

mabula@mabula-virtual-machine:~$ pwd
/home/mabula
mabula@mabula-virtual-machine:~$ tree jogamp_0000/
jogamp_0000/
└── file_cache
    ├── jln11693660724546214202
    │   ├── jln8598530866830701169
    │   └── jln8598530866830701169.tmp
    ├── jln11693660724546214202.lck
    └── jln11693660724546214202.tmp

3 directories, 3 files

Again without the libs in there... exactly the same error is thrown.

chmod ug+wx /tmp/jogamp_0000/file_cache/

changes nothing as well. And before the chmod command permissions on these folders were already that so the folders are created correctly.

Hi Mabula,

A side remark : I often had poor results running JOGL on virtual machines.

You may indeed end up using Mesa OpenGL implementation instead of your GPU driver. Not a big deal per se, but this is a different execution path where you are not relying on the OS-provided OpenGL. It may be slower than running on real hardware and you may have to modify timeouts through JOGL properties to avoid some JOGL exception. If not, you may get a slow rendering.

If you do this for the purpose of validating the compatibility of your software with one of your client OS, it won't be a realistic test. This is why I stoped running unit and integration tests on Github Actions VM and finally used self hosted nodes to run the automated tests (these nodes are all normal computers linked to Github Actions).

This being said, I don't think it would explain this IOException with error=13 code.

Hi,

Still trying to get information on this error=13 code. No real answer but few more insights.

Diving in JDK source yield to ProcessImpl.forkAndExec from which the IOException arise apparently. It is a native method so we should refer to the C counterpart .

The error is formatted here. As the "Permission denied" string does not appear in this file, and as almost all IOException thrown there have a message defined in plain text in this file, I would try to get information about the error code from your OS.

Hi Martin,

Thank you very much for investigating this.

Yes I agree, it might be a weird virtualisation issue somehow because the problem does not make a lot of sense to me at the moment.

I do think that the implementation of JOGL for loading the native libs could be made more error-proof by simply not needing to execute anything in tmp folders, but on the other hand... if it is a virtualisation issue, then JOGL is not to blame of course.

I will try to test on a real Linux Mint 20 host to exclude or confirm a virtualisation issue here ;-) I will report back later on this.

Mabula

Hi Martin & Julien,

I have good news for you.

After more testing and manipulating permissions of the files in my application, it turns out that the DEB packager that I used is to blame... apparently, the packager sets permissions in the files of my application in such a way that the error occurs. If I don't use the DEB packager, JOGL will run on Linux Mint 20 and also on Ubuntu 20 I can confirm with OpenJDK 17 (Temurin in my case).

So I think I need to report the issue to the DEB packager to solve this properly.

Would you have any idea which file or files are involved from the JRE when loading the native libs? I guess we need to find the issue there.

Thanks a lot for you help and work on JOGL !

Mabula

Hi Martin & Julien,

Okay, i have solved it now completely.

The DEB packager that I used did NOT set the correct permissions on the jre/lib/jspanwhelper. After installation the permissions were 644 (RW,R,R). A chmod 755 /jre/lib/jspanwhelper fixed the JOGL native lib loading issue completely.

Sorry to have bothered you with this ;-) At least it is again a valuable lesson learnt, at least for me.

So that fully explains the issue I was experiencing. The Java jspawnhelper packaged in my app simply was not allowed to execute the JOGL native libs script.

Mabula

Hello Mabula

Thank you for the feedback. What do you mean by "DEB packager"? I use my own tool JNDT which does NOT have this bug:
https://sourceforge.net/p/tuer/git/ci/master/tree/pre_beta/src/main/xml/jndt/antlib.xml#l593

Hi Julien,

I am using this maven enabled plugin to create installers for the users of my application:

https://github.com/fvarrui/JavaPackager

So that plugin was the problem. It did not create a correct Linux DEBIAN installer file which I called DEB for short.

Mabula

Hi Mabula

Thanks, I saw this issue, the bug is fixed in a branch, I just hope that deb support will be a bit more deeply tested.

Hi Julien,

Thank you, yes, it is fixed now and the DEB packager now works without issues ;-)

Mabula