Bug 1219 - Sporadic failure to determine 'executable temp base directory' on Windows by launching an executable file
Summary: Sporadic failure to determine 'executable temp base directory' on Windows by ...
Status: RESOLVED FIXED
Alias: None
Product: Gluegen
Classification: JogAmp
Component: core (show other bugs)
Version: 2.3.2
Hardware: All windows
: P1 blocker
Assignee: Sven Gothel
URL:
Depends on: 1108
Blocks: 1231 1365 1367
  Show dependency treegraph
 
Reported: 2015-09-16 18:13 CEST by Sven Gothel
Modified: 2019-04-03 00:57 CEST (History)
5 users (show)

See Also:
Type: DEFECT
SCM Refs:
0ebc5398fa20d23214a37dc4930a1fa1617293c7 b17ba1462cc4bb96be52f378dedafb50a3bc13f1 a8db919494e934f768ee8adb0d0bad75fa390e62 6c45f1dbeb875790056aef424b91b54440790a2b 0f08d051974d840ca898d7d0b888a679e4dee248 be9614d73e69159fbba5b458a4450b5df3a6613b
Workaround: ---


Attachments
Test debug log (12.25 KB, text/plain)
2015-09-16 22:18 CEST, spenna
Details
test debug log (15.07 KB, text/plain)
2015-09-19 21:42 CEST, spenna
Details
test debug log (176.57 KB, application/zip)
2015-09-23 01:22 CEST, spenna
Details
test debug log (176.70 KB, application/zip)
2015-09-23 12:34 CEST, spenna
Details
test debug log (176.75 KB, application/zip)
2015-09-23 23:09 CEST, spenna
Details
test debug log (353.32 KB, application/zip)
2015-09-23 23:11 CEST, spenna
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2015-09-16 18:13:38 CEST
- 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>
Comment 1 Sven Gothel 2015-09-16 18:16:39 CEST
Question: Has the non working Windows 10 box a virus scanner running?
Comment 2 Sven Gothel 2015-09-16 21:46:08 CEST
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
Comment 4 Sven Gothel 2015-09-16 21:48:56 CEST
Hence .. I need more input here,
otherwise I have to close this bug for release 2.3.2 (soon'ish) !
Comment 5 Sven Gothel 2015-09-16 21:54:52 CEST
Call for help, i.e. testing:
  <http://forum.jogamp.org/Test-Experience-Jogamp-on-Windows-10-td4035326.html>
Comment 6 spenna 2015-09-16 22:18:14 CEST
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)
Comment 7 Sven Gothel 2015-09-16 22:38:45 CEST
(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)
Comment 8 Sven Gothel 2015-09-16 22:47:36 CEST
Bug 1015 Comment 2: Describes how-to setup a no-exec folder.
Comment 9 Sven Gothel 2015-09-16 22:50:32 CEST
(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!
Comment 10 Sven Gothel 2015-09-16 22:52:46 CEST
(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!
Comment 11 spenna 2015-09-17 01:15:04 CEST
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.
Comment 12 Sven Gothel 2015-09-17 01:46:56 CEST
(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!
Comment 13 spenna 2015-09-17 02:59:59 CEST


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.
Comment 14 Sven Gothel 2015-09-17 03:41:10 CEST
(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.
Comment 15 Sven Gothel 2015-09-17 03:42:02 CEST
(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
Comment 16 spenna 2015-09-17 14:23:48 CEST

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.
Comment 17 Sven Gothel 2015-09-17 23:08:51 CEST
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!
Comment 18 Sven Gothel 2015-09-17 23:09:51 CEST
Please note: This random issue has _not_ been reported by any other user yet!
Comment 19 spenna 2015-09-18 00:22:14 CEST
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.
Comment 20 Xerxes Rånby 2015-09-18 01:00:59 CEST
(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.
Comment 21 spenna 2015-09-18 01:24:29 CEST
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.
Comment 22 Sven Gothel 2015-09-18 09:25:23 CEST
(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.
Comment 23 Julien Gouesse 2015-09-18 10:16:33 CEST
(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.
Comment 24 Giuseppe Barbieri 2015-09-18 10:22:23 CEST
Hi spenna,

if you tell us which are your steps I can check to see if I can replicate the bug on my machines
Comment 25 Xerxes Rånby 2015-09-18 10:31:33 CEST
    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
Comment 26 Xerxes Rånby 2015-09-18 10:49:01 CEST
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
Comment 27 Julien Gouesse 2015-09-18 11:38:20 CEST
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?
Comment 28 Xerxes Rånby 2015-09-18 11:51:58 CEST
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
Comment 29 spenna 2015-09-18 12:29:31 CEST
(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.
Comment 30 spenna 2015-09-18 12:32:01 CEST
(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.
Comment 31 spenna 2015-09-18 12:34:09 CEST
(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.
Comment 32 spenna 2015-09-18 12:38:10 CEST
(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.
Comment 33 spenna 2015-09-18 12:40:30 CEST
(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!
Comment 34 spenna 2015-09-18 12:43:53 CEST
(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.
Comment 35 spenna 2015-09-18 12:45:31 CEST
(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.
Comment 36 Julien Gouesse 2015-09-18 13:46:43 CEST
(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.
Comment 37 spenna 2015-09-18 18:50:21 CEST
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.
Comment 38 Sven Gothel 2015-09-18 20:17:11 CEST
(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 :-/
Comment 39 spenna 2015-09-18 21:08:26 CEST
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.
Comment 40 Sven Gothel 2015-09-19 05:59:18 CEST
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 ..
Comment 41 Sven Gothel 2015-09-19 06:01:24 CEST
(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!
Comment 42 Sven Gothel 2015-09-19 08:13:19 CEST
(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/>
Comment 43 spenna 2015-09-19 13:10:03 CEST
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.
Comment 44 Sven Gothel 2015-09-19 15:00:30 CEST
(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.
  [
Comment 45 spenna 2015-09-19 15:53:10 CEST
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.
>   [
Comment 46 spenna 2015-09-19 15:59:27 CEST
(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.
>   [
Comment 47 spenna 2015-09-19 16:46:48 CEST
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.
Comment 48 Sven Gothel 2015-09-19 19:55:16 CEST
(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.
Comment 49 Sven Gothel 2015-09-19 20:07:39 CEST
(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.
Comment 50 spenna 2015-09-19 21:42:40 CEST
Created attachment 738 [details]
test debug log
Comment 51 spenna 2015-09-19 21:45:58 CEST

(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!
Comment 52 Sven Gothel 2015-09-22 00:22:23 CEST
(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.


+++
Comment 53 Sven Gothel 2015-09-22 00:25:00 CEST
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
Comment 54 Sven Gothel 2015-09-22 00:55:42 CEST
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!
Comment 55 spenna 2015-09-23 01:22:14 CEST
Created attachment 740 [details]
test debug log
Comment 56 spenna 2015-09-23 01:23:10 CEST
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.
Comment 57 Sven Gothel 2015-09-23 05:39:41 CEST
(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
+++
Comment 58 Sven Gothel 2015-09-23 05:44:03 CEST
(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.
Comment 59 Sven Gothel 2015-09-23 05:59:35 CEST
(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
Comment 60 Sven Gothel 2015-09-23 06:45:06 CEST
<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.

+++
Comment 61 spenna 2015-09-23 12:34:17 CEST
Created attachment 741 [details]
test debug log
Comment 62 spenna 2015-09-23 12:35:48 CEST
(In reply to spenna from comment #61)
> Created attachment 741 [details]
> test debug log

The behavior was the same already observed.
Comment 63 Sven Gothel 2015-09-23 15:56:16 CEST
(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
Comment 64 Sven Gothel 2015-09-23 15:56:59 CEST
(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
Comment 65 Sven Gothel 2015-09-23 16:05:03 CEST
(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
Comment 66 Sven Gothel 2015-09-23 16:08:40 CEST
(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.
Comment 67 spenna 2015-09-23 23:09:24 CEST
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.
Comment 68 spenna 2015-09-23 23:11:05 CEST
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.
Comment 69 Sven Gothel 2015-09-24 06:22:26 CEST
(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?
Comment 70 Sven Gothel 2015-09-24 07:03:47 CEST
Remaining issue of remaining jogamp_exe_tst process
is handled in Bug 1231.

The 'executable temp base directory' could be determined.
Comment 71 Julien Gouesse 2015-09-24 11:58:50 CEST
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.
Comment 72 Robert Spillner 2015-11-13 22:49:56 CET
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.
Comment 73 Julien Gouesse 2015-11-14 00:45:18 CET
(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.