- Windows 10 - jdk 1.8_60 +++ I tested in other 2 computers and works in one pc and dosent in another. Both are windows 10 and jdk 1.8_60. I observe that, when works, the folder jogamp_0000 is created in C:\Users\USR\AppData\Local\Temp, and the folder is not created the other case. +++ Bug is related to Bug 1108 +++ Warning: Caught Exception while retrieving executable temp base directory: java.io.IOException: Could not determine a temporary executable directory at com.jogamp.common.util.IOUtil.getTempDir(IOUtil.java:1158) at com.jogamp.common.util.cache.TempFileCache.<clinit>(TempFileCache.java:80) at com.jogamp.common.util.cache.TempJarCache.initSingleton(TempJarCache.java:88) at com.jogamp.common.os.Platform$1.run(Platform.java:309) at java.security.AccessController.doPrivileged(Native Method) at com.jogamp.common.os.Platform.<clinit>(Platform.java:287) +++ <http://forum.jogamp.org/Caught-Exception-while-retrieving-executable-temp-base-directory-td4035267.html>
Question: Has the non working Windows 10 box a virus scanner running?
I could not reproduce this issue on my 'Windows 10 Home' installation. - Windows Firewall: ON - Windows Defender: ON (up to date) - SmartScreen: ON and OFF
Tested w/ <http://jogamp.org/deployment/archive/master/gluegen_888-joal_614-jogl_1438-jocl_1083-signed/jogl-applet-runner-newt-gears-normal-napplet.html>
Hence .. I need more input here, otherwise I have to close this bug for release 2.3.2 (soon'ish) !
Call for help, i.e. testing: <http://forum.jogamp.org/Test-Experience-Jogamp-on-Windows-10-td4035326.html>
Created attachment 734 [details] Test debug log I running in eclipse ide (Mars), windows 10 64 bits oracle jre/sdk 1.8.0_25. And in another pc with windows 7 64 bits oracle jre/sdk 1.8.0_60. In both i tested with running antivirus and not running. windows firewall On and windows defender on. OBS: in all linux pcs is working in another windows pcs is working (in this case: windows 10 64 bits oracle jre/sdk 1.8.0_60)
(In reply to spenna from comment #6) > Created attachment 734 [details] > Test debug log So it seems that you 'simply' have not even one temporary folder available which is able to execute a file: Further below, the direct dll loading is attempted .. but for some reason the dll could not be resolved, see java.lang.UnsatisfiedLinkError. +++ AssetURLContext.resolve: type 2: url <jar:file:/C:/Users/USER/Downloads/jogamp-all-platforms/jar/gluegen-rt.jar!/com/jogamp/common/util/bin/exe-windows-i586-268b.bin>, conn <sun.net.www.protocol.jar.JarURLConnection:jar:file:/C:/Users/USER/Downloads/jogamp-all-platforms/jar/gluegen-rt.jar!/com/jogamp/common/util/bin/exe-windows-i586-268b.bin>, connURL <jar:file:/C:/Users/USER/Downloads/jogamp-all-platforms/jar/gluegen-rt.jar!/com/jogamp/common/util/bin/exe-windows-i586-268b.bin> IOUtil: found <bin/exe-windows-i586-268b.bin> within class package <com/jogamp/common/util/> of given class <com.jogamp.common.util.IOUtil>: true IOUtil.testDirExec(): <C:\Users\USER\AppData\Local\Temp>: res 1 -> false IOUtil.testDirExec(): total 21631ms, create 285ms, execute 21346ms IOUtil.testDirImpl(tempX1): <C:\Users\USER\AppData\Local\Temp>, create true, exec true: false IOUtil.testDirExec(): <C:\Users\USER>: res 1 -> false IOUtil.testDirExec(): total 7800ms, create 4ms, execute 7796ms IOUtil.testDirImpl(tempX4): <C:\Users\USER>, create true, exec true: false IOUtil.testDirImpl(temp01): <C:\Users\USER\AppData\Local\Temp>, create true, exec false: true IOUtil.testDirImpl(temp01): <C:\Users\USER\AppData\Local\Temp\jogamp_0000>, create true, exec false: true IOUtil.getTempRoot(): temp dirs: exec: null, noexec: C:\Users\USER\AppData\Local\Temp\jogamp_0000 Warning: Caught Exception while retrieving executable temp base directory: java.io.IOException: Could not determine a temporary executable directory at com.jogamp.common.util.IOUtil.getTempDir(IOUtil.java:1168) .... TempFileCache: Static Initialization ---------------------------------------------- OK: false TempFileCache: Thread: main, CL 0x55f96302, tempBaseDir null ------------------------------------------------------------------ OK: false TempJarCache.initSingleton(): ok false, null ... +++ JNILibLoaderBase: System.load(C:\Users\USER\Downloads\jogamp-all-platforms\natives\windows-amd64\\gluegen-rt.dll) - mode 4 n/a - Can't load library: C:\Users\USER\Downloads\jogamp-all-platforms\natives\windows-amd64\\gluegen-rt.dll java.lang.UnsatisfiedLinkError: Can't load library: C:\Users\USER\Downloads\jogamp-all-platforms\natives\windows-amd64\\gluegen-rt.dll ... Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: C:\Users\USER\Downloads\jogamp-all-platforms\natives\windows-amd64\\gluegen-rt.dll at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1817) +++ > > > > I running in eclipse ide (Mars), windows 10 64 bits oracle jre/sdk 1.8.0_25. > And in another pc with windows 7 64 bits oracle jre/sdk 1.8.0_60. > > In both i tested with running antivirus and not running. windows firewall On > and windows defender on. > > > OBS: in all linux pcs is working > in another windows pcs is working (in this case: windows 10 64 bits > oracle jre/sdk 1.8.0_60)
Bug 1015 Comment 2: Describes how-to setup a no-exec folder.
(In reply to spenna from comment #6) > Created attachment 734 [details] > Test debug log > > > > I running in eclipse ide (Mars), windows 10 64 bits oracle jre/sdk 1.8.0_25. > And in another pc with windows 7 64 bits oracle jre/sdk 1.8.0_60. > > In both i tested with running antivirus and not running. windows firewall On > and windows defender on. > > > OBS: in all linux pcs is working > in another windows pcs is working (in this case: windows 10 64 bits > oracle jre/sdk 1.8.0_60) See comment 7. [1] Hence, can you enable execution in one of the following folders? C:\Users\USER\AppData\Local\Temp C:\Users\USER [2] Can you check why the file produces a java.lang.UnsatisfiedLinkError? C:\Users\USER\Downloads\jogamp-all-platforms\natives\windows-amd64\\gluegen-rt.dll Thank you!
(In reply to Sven Gothel from comment #9) > > [2] Can you check why the file produces a java.lang.UnsatisfiedLinkError? > > C:\Users\USER\Downloads\jogamp-all-platforms\natives\windows-amd64\\gluegen- > rt.dll maybe its the same reason, i.e. non-exec folder! > > Thank you!
When i execute the application, in C:\Users\USER\AppData\Local\Temp is created a .exe file (jogamp_exe_tst4245805114602579007) but this file freezes. I mean, starts the execution but suddenly stops and freezes. In order to generate the exception (or test debug log), i have to kill the process in task manager. When i do this, none .dll is created in jogamp_0000 folder. I think the file produces java.lang.UnsatisfiedLinkError because there's none gluegen-rt.dll in joamp_000 folder.
(In reply to spenna from comment #11) > When i execute the application, in C:\Users\USER\AppData\Local\Temp is > created a .exe file (jogamp_exe_tst4245805114602579007) but this file > freezes. > > I mean, starts the execution but suddenly stops and freezes. Maybe we can continue analyzing this behavior. [1] Copy some .exe file to that folder and try executing it [2] Analyze why our 'jogamp_exe_tst4245805114602579007' file doesn't work. Hint: Its in the jar files: unzip -l jogamp-fat.jar | grep \.bin 0 2015-09-15 17:05 com/jogamp/common/util/bin/ 268 2015-09-15 07:59 com/jogamp/common/util/bin/exe-windows-i586-268b.bin i.e. we must learn why your Windows 10 installation refuses executing this most minimal exe file. Thank you!
I used windows 7(64bits) in these test. I ran three different exe files in C:\Users\USER\AppData\Local\Temp: 1st: A non java application and went well; 2nd: A java application that uses graphics 2d and went well; 3rd: A java application that uses jogl_1.1.1 version and went well. But, again, when i tried a java application with jogl2 didn't work.
(In reply to spenna from comment #13) > > > I used windows 7(64bits) in these test. So this issue is not even related to Windows 10? i.e. happens on Windows 7 as well? > > I ran three different exe files in C:\Users\USER\AppData\Local\Temp: > > 1st: A non java application and went well; A normal exe for the CPU as requested file I assume? Please try to run a 32bit exe file. Also: [1.1] please extract 'com/jogamp/common/util/bin/exe-windows-i586-268b.bin' from the fat-jar or all-jar [1.2] and copy it to the above temp folder. [1.3] try to execute it > 2nd: A java application that uses graphics 2d and went well; > 3rd: A java application that uses jogl_1.1.1 version and went well. > > > But, again, when i tried a java application with jogl2 didn't work. Can you imagine some setup / config / service you have installed .. hindering access to that folder or disabling execution of that 32bit file? Please check your virus scanner log file.
(In reply to Sven Gothel from comment #14) > (In reply to spenna from comment #13) > > > > > > I used windows 7(64bits) in these test. > So this issue is not even related to Windows 10? > i.e. happens on Windows 7 as well? > > > > > I ran three different exe files in C:\Users\USER\AppData\Local\Temp: > > > > 1st: A non java application and went well; > > A normal exe for the CPU as requested file I assume? > Please try to run a 32bit exe file. > > Also: > [1.1] please extract 'com/jogamp/common/util/bin/exe-windows-i586-268b.bin' > from the fat-jar or all-jar > [1.2] and copy it to the above temp folder. and rename it to exe-windows-i586-268b.exe, if necessary > [1.3] try to execute it
This issue happens on Windows 7, 8.1 and 10 (all 64bits). Until now, dosen't happen on 32 bits system. However, the problem is random. In some pcs work in other doesn't. When i executed the last tests, i was running the exe as administrator, so no restriction. I tested a 32 bits exe (non java application) and went well. In all tests, i tried with my virus scanner enable and disable.
Changed description due to comment 16 .. This seems to become a nightmare issue. If there is a way to determine the ability of - 'Execute File' - 'Load DLL' from one folder in a different manner, I would love to hear from it!
Please note: This random issue has _not_ been reported by any other user yet!
I don't know if i understood your request, but i usually load .dll and .so (native libraries in general) without using a OS Temp_Folder. Please, excuse me if i'm saying something stupid or wrong. In my application i usually set .dll from a .bat file. In my case is like this: In my "main" class i have a method to set jre and libraries. This method is: //************************************************************************* public static void settingLibraryPath() { System.out.println(); System.out.println("JAVA SYSTEM INFORMATION PROGRAM"); System.out.println(); System.out.println("Java Runtime Information."); System.out.println(System.getProperty("java.runtime.name") + " version " + System.getProperty("java.runtime.version") + System.getProperty("java.vm.version") + " by " + System.getProperty("java.vm.vendor")); System.out.println(System.getProperty("sun.arch.data.model")); System.out.println(System.getProperty("java.home")); System.out.println("Execution Directory: " + System.getProperty("user.dir")); System.out.println(); System.out.println("OS / Platform Information."); System.out.println("OS appears to be: " + System.getProperty("os.name") + " Version " + System.getProperty("os.version") + " on " + System.getProperty("os.arch") + " architechture"); System.out.println("Number of (Logical) CPUs available: " + Runtime.getRuntime().availableProcessors()); System.out.println(); System.out.println("User Information."); System.out.println("User: " + System.getProperty("user.name") + " has a home directory at: " + System.getProperty("user.home")); System.out.println("Desktop environment appears to be: " + System.getProperty("sun.desktop")); File[] roots = File.listRoots(); System.out.println("Filesystem Information."); System.out.println("Temp directory is: " + System.getProperty("java.io.tmpdir")); System.out.println(); for (File root : roots) { System.out.println("File system root path: " + root.getAbsolutePath()); System.out.println("Total space (Megabytes): " + root.getTotalSpace() / 1048576); System.out.println("Usable space (Megabytes): " + root.getUsableSpace() / 1048576); System.out.println(); } System.out.println(System.getProperty("java.library.path")); System.out.println(System.getProperty("java.class.path")); System.out.println(System.getProperty("os.arch")); System.out.println(System.getProperty("os.name")); try { Class<ClassLoader> clazz = ClassLoader.class; Field field = clazz.getDeclaredField("sys_paths"); boolean accessible = field.isAccessible(); if (!accessible) { field.setAccessible(true); } Object original = field.get(clazz); field.set(clazz, null); try { System.setProperty("java.library.path", System.getProperty("java.library.path") + ";" + new File("").getAbsolutePath() + File.separator + "lib"); System.setProperty("java.class.path", new File("").getAbsolutePath() + File.separator + "jre8" + File.separator + "bin"); System.setProperty("java.home", new File("").getAbsolutePath() + File.separator + "jre8"); System.out.println (System.getProperty ("java.library.path")); System.out.println(System.getProperty("java.class.path")); System.out.println(System.getProperty("java.home")); // i have to choose which OS System.loadLibrary("jogl_desktop");//for windows 64 bits } finally { field.set(clazz, original); field.setAccessible(accessible); } } catch (SecurityException e) { e.printStackTrace(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalArgumentException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } } //************************************************************************* After that i build a jar file and create a .bat file(or .sh on linux). This .bat is: set PATH=jre8\bin; set JAVA_OPTS=-Xmx4g start javaw -jar insane-t3238.jar just to set jre and heap space. In the same folder of the jar file, i have a "lib" folder containing .dll (or .so). In this case i don't have to unpack .dll on a temp folder.
(In reply to spenna from comment #13) ... > 3rd: A java application that uses jogl_1.1.1 version and went well. > > > But, again, when i tried a java application with jogl2 didn't work. (In reply to spenna from comment #19) > I don't know if i understood your request, but i usually load .dll and .so > (native libraries in general) without using a OS Temp_Folder. > > Please, excuse me if i'm saying something stupid or wrong. > > In my application i usually set .dll from a .bat file. In my case is like > this: > > In my "main" class i have a method to set jre and libraries. This method is: > > > //************************************************************************* > > public static void settingLibraryPath() { ... > System.setProperty("java.library.path", > System.getProperty("java.library.path") + ";" + new > File("").getAbsolutePath() + File.separator + "lib"); ... > // i have to choose which OS > System.loadLibrary("jogl_desktop");//for windows 64 bits ... > just to set jre and heap space. > > In the same folder of the jar file, i have a "lib" folder containing .dll > (or .so). > > In this case i don't have to unpack .dll on a temp folder. You mention in comment 13 that you have jogl 1.1.1 installed on the same system, and in comment 19 you mention that you use a custom library loader. System.loadLibrary in your custom loader may then pick up the jogl 1.1.1 stored inside the JRE when you try to run jogl2 and this will not work.
No, i don't have jogl 1.1.1 installed, in my applications i always use library loader. To run the application, i use a dedicate jre. In each case i have diferents jre and jogl lib. If you want to see the application there's an experimental version in: http://www.insane.dees.ufmg.br/drupal/sites/default/files/Outros/INSANE_BETA_64bits_Windows.zip unpack and run .bat file.
(In reply to spenna from comment #19) > I don't know if i understood your request, but i usually load .dll and .so > (native libraries in general) without using a OS Temp_Folder. > > Please, excuse me if i'm saying something stupid or wrong. > > In my application i usually set .dll from a .bat file. In my case is like > this: Just to confirm, can you produce this issue w/ our JOGL standalone test cases, e.g. <https://jogamp.org/wiki/index.php/Jogamp_Versioning_and_Releases#Runtime_Debug_Logs> Also see: <https://jogamp.org/wiki/index.php/Jogl_FAQ#Bugreports_.26_Testing> OR is this issue only visible when you use your application? +++ Further more, you have not answered my comment 15, i.e. whether you have tried executing that specific file.
(In reply to spenna from comment #21) > No, i don't have jogl 1.1.1 installed, in my applications i always use > library loader. > > To run the application, i use a dedicate jre. In each case i have diferents > jre and jogl lib. > What happens when you use our automated native library loading instead of your loader? We're responsible for the former but not for the latter. I tested under Windows 10 and I don't reproduce your bug. If you want to handle the native libraries by yourself, please disable the automated native library loading by using -Djogamp.gluegen.UseTempJarCache=false. In my humble opinion, you shouldn't both load the native libraries and use the automated native library loading. I tested both the applets and my application packaged with the help of JNDT (self-contained native application bundles, dedicated JREs) under Windows 10 two months ago.
Hi spenna, if you tell us which are your steps I can check to see if I can replicate the bug on my machines
How can I checkout the sourcecode to the project? Your websvn unfortunally do not reveal an url that I can use to checkout the INSANE svn src tree https://www.insane.dees.ufmg.br/websvn/listing.php?repname=insane
the following command allows me to checkout your project, and run all of its junit tests svn checkout https://www.insane.dees.ufmg.br/svn/insane/trunk/ insane cd insane mvn isntall
The source code still uses JOGL 1.1.1. Spenna, please can you commit the source code compatible with JOGL 2.3.2 so that we have a chance to reproduce your bug? Do you use Maven to create your "experimental" version? Is there an experimental branch anywhere?
the sources i checked out sues jogamp jogl 2.3.2-rc when i run the main class br.ufmg.dees.insane.ui.rich.full.Insane from inside eclipse using m2e then i do hit an exception that the maven reposity hosted by the insane project do not include the jogamp natives such as gluegen-rt-2.3.2-rc-natives-linux-amd64.jar Thus the only issue i can see is how the insane project manages its maven repository. jogamp jogl have a maven repository that you can use: http://jogamp.org/wiki/index.php/Maven#The_jogamp.org_test_repository_.28optional.29 http://jogamp.org/deployment/maven/ you can try use this version: 2.3.2-rc-20150812
(In reply to Sven Gothel from comment #22) > (In reply to spenna from comment #19) > > I don't know if i understood your request, but i usually load .dll and .so > > (native libraries in general) without using a OS Temp_Folder. > > > > Please, excuse me if i'm saying something stupid or wrong. > > > > In my application i usually set .dll from a .bat file. In my case is like > > this: > > Just to confirm, can you produce this issue w/ our JOGL standalone > test cases, e.g. > > <https://jogamp.org/wiki/index.php/ > Jogamp_Versioning_and_Releases#Runtime_Debug_Logs> > > Also see: > <https://jogamp.org/wiki/index.php/Jogl_FAQ#Bugreports_.26_Testing> > > OR is this issue only visible when you use your > application? > > +++ > > Further more, you have not answered my comment 15, > i.e. whether you have tried executing that specific file. This issue happens w/ your tests.
(In reply to Sven Gothel from comment #22) > (In reply to spenna from comment #19) > > I don't know if i understood your request, but i usually load .dll and .so > > (native libraries in general) without using a OS Temp_Folder. > > > > Please, excuse me if i'm saying something stupid or wrong. > > > > In my application i usually set .dll from a .bat file. In my case is like > > this: > > Just to confirm, can you produce this issue w/ our JOGL standalone > test cases, e.g. > > <https://jogamp.org/wiki/index.php/ > Jogamp_Versioning_and_Releases#Runtime_Debug_Logs> > > Also see: > <https://jogamp.org/wiki/index.php/Jogl_FAQ#Bugreports_.26_Testing> > > OR is this issue only visible when you use your > application? > > +++ > > Further more, you have not answered my comment 15, > i.e. whether you have tried executing that specific file. Sorry! I have when i try to execute that specific files the issue happens. I mean the execution freeze and i have to kill the process. After that nothing happens.
(In reply to Xerxes Rånby from comment #26) > the following command allows me to checkout your project, and run all of its > junit tests > > svn checkout https://www.insane.dees.ufmg.br/svn/insane/trunk/ insane > cd insane > mvn isntall Yes, you can checkout in https://www.insane.dees.ufmg.br/svn. It's an open source all in java and some native libraries.
(In reply to Julien Gouesse from comment #27) > The source code still uses JOGL 1.1.1. Spenna, please can you commit the > source code compatible with JOGL 2.3.2 so that we have a chance to reproduce > your bug? Do you use Maven to create your "experimental" version? Is there > an experimental branch anywhere? No the current version uses jogl 2.3.2. In all versions you can use maven. There's no branch for the experimental version. But there's a revision i have to check the the number.
(In reply to Julien Gouesse from comment #23) > (In reply to spenna from comment #21) > > No, i don't have jogl 1.1.1 installed, in my applications i always use > > library loader. > > > > To run the application, i use a dedicate jre. In each case i have diferents > > jre and jogl lib. > > > What happens when you use our automated native library loading instead of > your loader? We're responsible for the former but not for the latter. I > tested under Windows 10 and I don't reproduce your bug. If you want to > handle the native libraries by yourself, please disable the automated native > library loading by using -Djogamp.gluegen.UseTempJarCache=false. > > In my humble opinion, you shouldn't both load the native libraries and use > the automated native library loading. > > I tested both the applets and my application packaged with the help of JNDT > (self-contained native application bundles, dedicated JREs) under Windows 10 > two months ago. I'll try disable the automated native library loading!
(In reply to Xerxes Rånby from comment #28) > the sources i checked out sues jogamp jogl 2.3.2-rc > when i run the main class > br.ufmg.dees.insane.ui.rich.full.Insane > from inside eclipse using m2e > then i do hit an exception that the maven reposity hosted by the insane > project do not include the jogamp natives such as > gluegen-rt-2.3.2-rc-natives-linux-amd64.jar > > Thus the only issue i can see is how the insane project manages its maven > repository. > > jogamp jogl have a maven repository that you can use: > http://jogamp.org/wiki/index.php/Maven#The_jogamp.org_test_repository_. > 28optional.29 > > http://jogamp.org/deployment/maven/ > > you can try use this version: > 2.3.2-rc-20150812 Yes, i know! Actually, i use your maven repository. But i had to change in order to test jogl 2.3.2 rc. In my server i have a local maven repository.
(In reply to Xerxes Rånby from comment #28) > the sources i checked out sues jogamp jogl 2.3.2-rc > when i run the main class > br.ufmg.dees.insane.ui.rich.full.Insane > from inside eclipse using m2e > then i do hit an exception that the maven reposity hosted by the insane > project do not include the jogamp natives such as > gluegen-rt-2.3.2-rc-natives-linux-amd64.jar > > Thus the only issue i can see is how the insane project manages its maven > repository. > > jogamp jogl have a maven repository that you can use: > http://jogamp.org/wiki/index.php/Maven#The_jogamp.org_test_repository_. > 28optional.29 > > http://jogamp.org/deployment/maven/ > > you can try use this version: > 2.3.2-rc-20150812 I'll changes the dependencies to jogl 2.3.2-rc-20150812.
(In reply to spenna from comment #32) > (In reply to Julien Gouesse from comment #27) > > The source code still uses JOGL 1.1.1. Spenna, please can you commit the > > source code compatible with JOGL 2.3.2 so that we have a chance to reproduce > > your bug? Do you use Maven to create your "experimental" version? Is there > > an experimental branch anywhere? > > No the current version uses jogl 2.3.2. > In all versions you can use maven. There's no branch for the experimental > version. But there's a revision i have to check the the number. Sorry, I used an old revision :s It seems to be correct.
I do not know if it's good news but, when I disable the automatic loading of the library, my native application runs. However, when I run the application using the temporary folder the problem remains. I updated the code, now with your maven repository.
(In reply to spenna from comment #30) > (In reply to Sven Gothel from comment #22) > > (In reply to spenna from comment #19) > > > I don't know if i understood your request, but i usually load .dll and .so > > > (native libraries in general) without using a OS Temp_Folder. > > > > > > Please, excuse me if i'm saying something stupid or wrong. > > > > > > In my application i usually set .dll from a .bat file. In my case is like > > > this: > > > > Just to confirm, can you produce this issue w/ our JOGL standalone > > test cases, e.g. > > > > <https://jogamp.org/wiki/index.php/ > > Jogamp_Versioning_and_Releases#Runtime_Debug_Logs> > > > > Also see: > > <https://jogamp.org/wiki/index.php/Jogl_FAQ#Bugreports_.26_Testing> > > > > OR is this issue only visible when you use your > > application? > > > > +++ > > > > Further more, you have not answered my comment 15, > > i.e. whether you have tried executing that specific file. > > > Sorry! I have when i try to execute that specific files the issue happens. > I mean the execution freeze and i have to kill the process. After that > nothing happens. So this means this bug entry is unrelated to your app INSANE, and you can reproduce the issue just w/ our JogAmp builds. Further .. the culprit is that minimal PE executable on your machine, i.e. it freezes the process. Hence .. we need to find an alternative test :-/
Considering the way i use jogl in my app, disabling the automated native library loading solved the problem. But, any other jogl app still having problems in some pcs. For example, the demos doesn't work properly.
0ebc5398fa20d23214a37dc4930a1fa1617293c7: Replacing the tiny 268 byte sized 'exe-windows-i586-268b.bin' PE file w/ a regular 2048 byte sized PE file 'exe-windows-i386-2048b.bin'. File is produced via: c:\mingw\bin\gcc -nodefaultlibs -nostdlib -s -Os -o tiny.exe tiny.c Adding the 305 byte sized gzipped version 'exe-windows-i386-2048b.bin.305b.gz' to the gluegen-rt jar file to reduce the payload for non Windows platforms. Adding special property 'jogamp.debug.IOUtil.Exe' to debug testing the exe file, enable via '-Djogamp.debug.IOUtil.Exe'. Passes here on all Windows machines, however, the prev. one worked here as well. See <http://jogamp.org/git/?p=gluegen.git;a=commit;h=0ebc5398fa20d23214a37dc4930a1fa1617293c7> @Spenna: Pls test - auto builds in progress ..
(In reply to spenna from comment #39) > Considering the way i use jogl in my app, disabling the automated native > library loading solved the problem. But, any other jogl app still having > problems in some pcs. For example, the demos doesn't work properly. Ofc we have to fix this issue - and thank you for your help, since you seem to be the only one able to reproduce it. Pls stay w/ us and test the attempts to fix this issue, see comment 40. If you have any idea how to trigger this issue or configure Windows in such way, please let us know. Thank you!
(In reply to Sven Gothel from comment #40) > > See > <http://jogamp.org/git/?p=gluegen.git;a=commit; > h=0ebc5398fa20d23214a37dc4930a1fa1617293c7> > > @Spenna: Pls test - auto builds in progress .. <http://jogamp.org/deployment/archive/master/gluegen_890-joal_616-jogl_1441-jocl_1086-signed/>
Ok! I will test the autobuild in progress. I have a pc thats works fine and I triyng to reproduce the bug in it. No success by now.
(In reply to spenna from comment #43) > Ok! I will test the autobuild in progress. > I have a pc thats works fine and I triyng to reproduce the bug in it. > No success by now. That means you cannot reproduce the bug w/ the latest build on a machine which was able to reproduce the bug w/ a previous build? You have tested w/ and w/o any debug properties? Well .. that is great then! ++ The change contains two deltas: [1] explicit sync on generated file [2] using a 2048 byte sized PE If you can build GlueGen .. you could digest the changes a bit, i.e. test only with one of the two changes w/o debug properties. [
I tried run my app w/ the auto build but no success. I got the same exception: Warning: Caught Exception while retrieving executable temp base directory: java.io.IOException: Could not determine a temporary executable directory at com.jogamp.common.util.IOUtil.getTempDir(IOUtil.java:1195) at com.jogamp.common.util.cache.TempFileCache.<clinit>(TempFileCache.java:81) at com.jogamp.common.util.cache.TempJarCache.initSingleton(TempJarCache.java:88) at com.jogamp.common.os.Platform$1.run(Platform.java:309) at java.security.AccessController.doPrivileged(Native Method) at com.jogamp.common.os.Platform.<clinit>(Platform.java:287) at com.jogamp.opengl.GLProfile.<clinit>(GLProfile.java:147) at br.ufmg.dees.insane.ui.rich.geo.view.GeoJOGLView.<init>(GeoJOGLView.java:52) at br.ufmg.dees.insane.ui.rich.geo.PlaneInternalInterfaceGeo.<init>(PlaneInternalInterfaceGeo.java:152) at br.ufmg.dees.insane.ui.rich.full.OpenNewPlaneGeoModelCommand.execute(OpenNewPlaneGeoModelCommand.java:104) at br.ufmg.dees.insane.commons.view.Interface.actionPerformed(Interface.java:220) at javax.swing.AbstractButton.fireActionPerformed(Unknown Source) at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source) at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source) at javax.swing.DefaultButtonModel.setPressed(Unknown Source) at javax.swing.AbstractButton.doClick(Unknown Source) at javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unknown Source) at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(Unknown Source) at java.awt.Component.processMouseEvent(Unknown Source) at javax.swing.JComponent.processMouseEvent(Unknown Source) at java.awt.Component.processEvent(Unknown Source) at java.awt.Container.processEvent(Unknown Source) at java.awt.Component.dispatchEventImpl(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) at java.awt.Container.dispatchEventImpl(Unknown Source) at java.awt.Window.dispatchEventImpl(Unknown Source) at java.awt.Component.dispatchEvent(Unknown Source) at java.awt.EventQueue.dispatchEventImpl(Unknown Source) at java.awt.EventQueue.access$500(Unknown Source) at java.awt.EventQueue$3.run(Unknown Source) at java.awt.EventQueue$3.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source) at java.awt.EventQueue$4.run(Unknown Source) at java.awt.EventQueue$4.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source)(In reply to Sven Gothel from comment #44) > (In reply to spenna from comment #43) > > Ok! I will test the autobuild in progress. > > I have a pc thats works fine and I triyng to reproduce the bug in it. > > No success by now. > > That means you cannot reproduce the bug w/ the latest build > on a machine which was able to reproduce the bug w/ a previous build? > You have tested w/ and w/o any debug properties? > > Well .. that is great then! > > ++ > > The change contains two deltas: > [1] explicit sync on generated file > [2] using a 2048 byte sized PE > > If you can build GlueGen .. you could digest the changes a bit, > i.e. test only with one of the two changes w/o debug properties. > [
(In reply to Sven Gothel from comment #44) > (In reply to spenna from comment #43) > > Ok! I will test the autobuild in progress. > > I have a pc thats works fine and I triyng to reproduce the bug in it. > > No success by now. > That means you cannot reproduce the bug w/ the latest build > on a machine which was able to reproduce the bug w/ a previous build? > You have tested w/ and w/o any debug properties? > > Well .. that is great then! what I meant was: in pcs that worked with the new build still working. I tried on these same pcs generate the bug but could not. In PCs that did not work, they continue to generate the bug. > > ++ > > The change contains two deltas: > [1] explicit sync on generated file > [2] using a 2048 byte sized PE > > If you can build GlueGen .. you could digest the changes a bit, > i.e. test only with one of the two changes w/o debug properties. > [
I created a windows dump file of the jogamp_exe process. But it's too big to send as attachment. I don't know if this file helps. If it help i can send by e-mail.
(In reply to spenna from comment #47) > I created a windows dump file of the jogamp_exe process. But it's too big to > send as attachment. I don't know if this file helps. If it help i can send > by e-mail. what would help is if you can test JOGL w/ etc\test_dbg.bat, but change the debug flag as follows. - set D_ARGS="-Djogamp.debug=all" "-Dnativewindow.debug=all" "-Djogl.debug=all" "-Dnewt.debug=all" + set D_ARGS="-Djogamp.debug.IOUtil.Exe" i.e. test w/ property 'jogamp.debug.IOUtil.Exe' set. If anyhow possible, _not_ with your application to remove any side effects. +++ Further .. maybe a detailed spec of your Windows test machine - OS version - is it updated? - CPU - .. Can you reproduce this issue within a virtual machine? If so .. maybe you could lend me that diskimage for a while? Another way would be to setup an ssh account so I am able to test on one of your machines? See <http://jogamp.org/git/?p=jogamp-scripting.git;a=tree;f=jenkins-server-slave-setup/cygwin-sshd;h=43950cf6c6c499dbd7aab137c827c158e0f81ba0;hb=HEAD> - the 'user process' setup would be required +++ I know .. this is quite a bit I am asking for .. so thank you for supporting this task.
(In reply to Sven Gothel from comment #48) > (In reply to spenna from comment #47) > > I created a windows dump file of the jogamp_exe process. But it's too big to > > send as attachment. I don't know if this file helps. If it help i can send > > by e-mail. > > what would help is if you can test JOGL > w/ etc\test_dbg.bat, but change the debug flag as follows. > > - set D_ARGS="-Djogamp.debug=all" "-Dnativewindow.debug=all" > "-Djogl.debug=all" "-Dnewt.debug=all" > + set D_ARGS="-Djogamp.debug.IOUtil.Exe" > > i.e. test w/ property 'jogamp.debug.IOUtil.Exe' set. > > If anyhow possible, _not_ with your application to remove any side effects. > Besides debug output, this property launches a new Thread reading the stdout and stderr stream of the launched process and dumps it to stderr. One reason the process hangs could be that its stdout/stderr buffers are very small and hence the process blocks. Even though the test-exe does not produce any output .. Hence .. that test would allow us to see whether the generated output, if any .. and whether this is the culprit.
Created attachment 738 [details] test debug log
(In reply to Sven Gothel from comment #48) > (In reply to spenna from comment #47) > > I created a windows dump file of the jogamp_exe process. But it's too big to > > send as attachment. I don't know if this file helps. If it help i can send > > by e-mail. > > what would help is if you can test JOGL > w/ etc\test_dbg.bat, but change the debug flag as follows. > > - set D_ARGS="-Djogamp.debug=all" "-Dnativewindow.debug=all" > "-Djogl.debug=all" "-Dnewt.debug=all" > + set D_ARGS="-Djogamp.debug.IOUtil.Exe" > > i.e. test w/ property 'jogamp.debug.IOUtil.Exe' set. > > If anyhow possible, _not_ with your application to remove any side effects. > > +++ > > Further .. maybe a detailed spec of your Windows test machine > - OS version > - is it updated? > - CPU > - .. Windows 7 Ultimate version 6.1.7600 (no updated) 2009 arch: "amd64" Java version: 1.8.0_60, vendor: Oracle Corporation cpu: corei i7 860 2.8GHz ram:8GB video: radeon HD 5700 > Can you reproduce this issue within a virtual machine? > If so .. maybe you could lend me that diskimage for a while? I never used a virtual machine. > Another way would be to setup an ssh account so I am able to test > on one of your machines? > See > <http://jogamp.org/git/?p=jogamp-scripting.git;a=tree;f=jenkins-server-slave- > setup/cygwin-sshd;h=43950cf6c6c499dbd7aab137c827c158e0f81ba0;hb=HEAD> > - the 'user process' setup would be required > > +++ > > I know .. this is quite a bit I am asking for .. > so thank you for supporting this task. I don't know exactly how to do that!
(In reply to spenna from comment #50) > Created attachment 738 [details] > test debug log Thank you! Your log shows that the test executable was launched, but its return/exit code didn't match: expected: 0, you: 1 commit a8db919494e934f768ee8adb0d0bad75fa390e62 attempts to tackle this. It also contains a few more debugging options to analyze the situation a bit further (manually). Some have to be removed after completion! Please test again w/ latest build: <http://jogamp.org/deployment/archive/master/gluegen_892-joal_618-jogl_1443-jocl_1088/> +++ <http://jogamp.org/git/?p=gluegen.git;a=commit;h=a8db919494e934f768ee8adb0d0bad75fa390e62>. IOUtil.testDirExe: Satisfactory when executed, more debug options - Satisfactory when executed Failure to execute produce an IOException right at ProcessBuilder.start(). Hence we can allow an unexpected process exit value, since we only want to learn whether executable files are allowed. - More debug options DEBUG_EXE: 'jogamp.debug.IOUtil.Exe' DEBUG_EXE_NOSTREAM: 'jogamp.debug.IOUtil.Exe.NoStream' - if DEBUG_EXE - a pre-existing 'jogamp_exe_tst'+<SUFFIX> will be used as-is. - the test-exe will not be deleted - StreamMonitor is being used to dump stdout/stderr if !DEBUG_EXE_NOSTREAM. +++
commit b17ba1462cc4bb96be52f378dedafb50a3bc13f1: Use Win32 API for test PE exe, not console Previous test PE exe, commit 0ebc5398fa20d23214a37dc4930a1fa1617293c7, was a console exe. A console exe opens a new console window if not being launched from one. New test PE exe is produced w/ '-mwindows', i.e. for Win32 API w/o a console. +++ commit a8db919494e934f768ee8adb0d0bad75fa390e62 See comment 52 +++ commit 6c45f1dbeb875790056aef424b91b54440790a2b Fix IOUtil.StreamMonitor EOS handling - Make StreamMonitor a daemon thread, i.e. not hindering VM from exit - Earmark each InputStream's EOS state and only attempt to readByte if !eos - End loop and hence the thread if all InputStream have reached EOS. - Don't close the InputStream. Closing the InputStream is expected to be done by the owner, otherwise no EOS could even be reached! - Flush the output PrintStream at thread exit
commit 0f08d051974d840ca898d7d0b888a679e4dee248 IOUtil.testDirExe: Disable 'existingExe' DEBUG_EXE feature by hardcoded 'DEBUG_EXE_EXISTING_FILE = false' This is required for security, i.e. not allowing to execute any pre-existing files! In case we need to manually debug this issue, we can re-enable it manually and locally, but not in public builds!
Created attachment 740 [details] test debug log
Something diferent happened. When I ran the test, the jogamp_tst.exe process appeared in the task manager and I had to kill him. Nothing different, except that the debug test run and generate an extensive log.
(In reply to spenna from comment #55) > Created attachment 740 [details] > test debug log This log shows that: - test-exe returned 1, whatever that means - test-exe hence was launched - test-exe java Process returned, otherwise we would not continue - we assume the directory is capable of handling executables - the test worked, i.e. dll files were loaded from tested folder +++ IOUtil.testDirExec(): test-exe <..>, existingFile false, returned 1 IOUtil.testDirExec(): abs-path <..>: res 0 -> true IOUtil.testDirExec(): total 14415ms, create 515ms, execute 13900ms IOUtil.testDirImpl(tempX1): <..>, create true, exec true: true IOUtil.testDirExec(): test-exe <.., existingFile false, returned 1 IOUtil.testDirExec(): abs-path <..>: res 0 -> true IOUtil.testDirExec(): total 8640ms, create 0ms, execute 8640ms IOUtil.testDirImpl(tempX1): <..>, create true, exec true: true +++
(In reply to spenna from comment #56) > Something diferent happened. > When I ran the test, the jogamp_tst.exe process appeared in the task manager > and I had to kill him. > Nothing different, except that the debug test run and generate an extensive > log. so the remaining issues here are: [1] Why does the test-exe remains in your task manager? [1.1] I assume it remains there even after the while java test has finished? [2] Why does the java Process for test-exe claims an exit code of 1 Note: The java Process instance references/covers the java thread/process started for the actual native executable, here test-exe. We learn that while the covering java Process itself ends, the actual launched native test-exe remains.
(In reply to spenna from comment #55) > Created attachment 740 [details] > test debug log Can you please edit etc\test_dbg.bat and make sure the property 'jogamp.debug.IOUtil.Exe' is set? I.e. the one line setting D_ARGS should look like this: set D_ARGS="-Djogamp.debug=all" "-Dnativewindow.debug=all" "-Djogl.debug=all" "-Dnewt.debug=all" "-Djogamp.debug.IOUtil.Exe" delete any old test_dbg.log and re-run the test please. figuring out why the test-exe hangs .. weird
<http://jogamp.org/git/?p=gluegen.git;a=commit;h=be9614d73e69159fbba5b458a4450b5df3a6613b> commit be9614d73e69159fbba5b458a4450b5df3a6613b: IOUtil.testDirExe: Issue Process.destroy() in finalize block to ensure launched native exe process terminates. See Bug 1219 comment 58: It seems that on some Windows platforms the launched native process using our test-exe keeps running even though we issued Process.waitFor(). Hence we issue Process.destroy() in the finalize block to at least attempt to terminate it. Note: The Process implementation is platform specific and may vary. +++
Created attachment 741 [details] test debug log
(In reply to spenna from comment #61) > Created attachment 741 [details] > test debug log The behavior was the same already observed.
(In reply to spenna from comment #62) > (In reply to spenna from comment #61) > > Created attachment 741 [details] > > test debug log > > The behavior was the same already observed. <http://jogamp.org/deployment/archive/master/gluegen_894-joal_620-jogl_1446-jocl_1090/> .. containing fix as described in comment 60
(In reply to spenna from comment #62) > (In reply to spenna from comment #61) > > Created attachment 741 [details] > > test debug log > > The behavior was the same already observed. thank you, pls re-test .. see comment 63
(In reply to spenna from comment #62) > (In reply to spenna from comment #61) > > Created attachment 741 [details] > > test debug log > > The behavior was the same already observed. which means: - test-exe keeps running (TaskManager) - test itself succeeded
(In reply to Sven Gothel from comment #63) > (In reply to spenna from comment #62) > > (In reply to spenna from comment #61) > > > Created attachment 741 [details] > > > test debug log > > > > The behavior was the same already observed. > > <http://jogamp.org/deployment/archive/master/gluegen_894-joal_620-jogl_1446- > jocl_1090/> > > .. containing fix as described in comment 60 this is sort of our last resort, i.e. we cannot do anything anymore here. if the Process impl. keeps the native exec running even after attempting to terminate it it seems that the issue is w/ the particular Windows version and the JRE implementation. Despite the remaining test-exe .. the application shall work. But it would be great to know whether comment 60 was able to kill the test-exe process.
Created attachment 745 [details] test debug log 1st Test debug log is attached. In this case the standard test debug was executed. The same behavior was observed.
Created attachment 746 [details] test debug log 2nd Test debug log. This second test uses: set D_ARGS="-Djogamp.debug=all" "-Dnativewindow.debug=all" "-Djogl.debug=all" "-Dnewt.debug=all" "-Djogamp.debug.IOUtil.Exe" The same behavior was observed.
(In reply to spenna from comment #68) > Created attachment 746 [details] > test debug log > > > 2nd Test debug log. > > This second test uses: > > set D_ARGS="-Djogamp.debug=all" "-Dnativewindow.debug=all" > "-Djogl.debug=all" "-Dnewt.debug=all" "-Djogamp.debug.IOUtil.Exe" > > > The same behavior was observed. Meaning, the test [1] test-exe keeps running (TaskManager) [2] test-exe exit code is '1' [3] test itself succeeded ? At least [2] and [3] is confirmed by your log files. Any other artifacts observed? +++ One last thing would be that you perform a Window Update, to see whether this is an issue of Windows itself .. well, that would be a moonshot. So nothing we can do about that here anymore, I am afraid. So we can close this bug as FIXED, since the exe directory could be determined. We shall add a new bug entry stating that the test-exe is still running! However, we may not be able to fix this. Agreed?
Remaining issue of remaining jogamp_exe_tst process is handled in Bug 1231. The 'executable temp base directory' could be determined.
If this tiny executable causes too much trouble, why not using the reflection API if the Java version is greater than or equal to 1.7 in order to call some methods of the NIO2 file API? java.nio.files.Files.getPosixFilePermissions()? The executable would be useful as a fallback with Java 1.6 and earlier versions.
Although this is closed for quite a while I like to add my experience, maybe for others to help with this case. I'm also running Win 10. When I have -Djogamp.gluegen.UseTempJarCache=true enabled my virus scanner (avira) complains about it the moment the executable is being generated (virus HEUR/APC (Cloud)) which I guess is some kind of heuristic that guesses this to be a virus and the application could not be started. Disabling the scanner solved the problem. I now have an extra rule for jogl in the avira configuration to ignore executables named jogamp*exe.
(In reply to Robert Spillner from comment #72) > Although this is closed for quite a while I like to add my experience, maybe > for others to help with this case. > > I'm also running Win 10. When I have -Djogamp.gluegen.UseTempJarCache=true > enabled my virus scanner (avira) complains about it the moment the > executable is being generated (virus HEUR/APC (Cloud)) which I guess is some > kind of heuristic that guesses this to be a virus and the application could > not be started. > > Disabling the scanner solved the problem. I now have an extra rule for jogl > in the avira configuration to ignore executables named jogamp*exe. Thank you for the feedback. It's a false positive, it's not a virus. We should contact Avira to solve this problem.