Bug 1219

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.