P3D not always creating window...

Kodbin

Hi all,

I've been using the processing core in an IntelliJ project for some time. However I've seen the same thing in the processing environment, so I don't think it is to do with my set up...

What I'm seeing is that P3D sketches sometimes work entirely normally, a window appears and graphics render in it.

But on other occasions the sketch will appear (as far as the debugger is concerned) to be running normally, but no window will appear.

At first I thought this was some sort of corruption, where it would work for a while after a reboot and then break, but it's more erratic than that, and sometimes it starts working again. This is a Windows 7 Enterprise machine, many cores, nVidia Quatro K5000 with twin monitors.

I thought it might be some sort of driver problem, but I don't generally see any graphics problems and there's nothing I can see in the system logs -- just some notes about NVWMI connecting to new processes, which seem the same whether the process works or not...

I realise this may be in part triggered by my exact set-up here, but any ideas?

Ian

kolban

I think we are seeing the same issue ... https://forum.processing.org/two/discussion/14447/display-window-very-slow-to-appear-on-dual-monitor-windows-10

Kodbin

I don't think that is exactly the same issue, as for me it only happens some of the time and when it does, however long I wait, the window never seems to appear...

It may be related, of course.

Interesting that you have that on a Windows 10 machine... My Windows 10 machine can't work with P3D at all and gives an exception with a message about not being able to create a framebuffer. I only looked very slightly into that and found quite a lot of other people with Windows 10 OpenGL problems.

Kodbin

OK, I'm wrong and you are right, I left a process running and it did open the window eventually, it just took 1/2 and hour...

So it looks like it is the same issue...

kolban

It is starting to sound like we need to create an issue ... a test we could try would be to disable one of the monitors and see if we can reduce the permutations of areas that could be at play. For example, if it starts immediately on a single monitor that would be a clue. What video card driver do you use ... I use nVidia.

kolban

I disabled my secondary monitor but no change in the symptoms.

SiriusCG

Just curious, but does the new fullScreen() function help at all? Ie, specify which monitor you want opened? fullScreen(P2D,2) for instance.

https://processing.org/reference/fullScreen_.html

Kodbin

Firstly, I'm not sure how this forum software is supposed to work, but it didn't mail me for either of kolban's more-recent replies above. It only notified me when Sirius replied...

An interesting test Sirius, I'll have to wait until tomorrow to test it because the problem only seems to happen the first time when I run a sketch after a long period of inactivity (and I'm past today's first...)

However I do know that the symptoms were the same using fullscreen without a monitor argument.

Regards,

Ian

kolban

I removed my call to size(800,600,P3D) and replaced it with a call to fullScreen(P3D). When I ran it, the exact same symptoms persisted. No display was shown for about 30-60 seconds and then a full screen display appeared. I tried the same by declaring a particular screen to appear on with fulleScreen(P3D, 1) ... but no change.

SiriusCG

Hmm, I'll have to hijack the wife's PC to test out a theory, she has dual monitors under Win7 64 bit. I have no Win10 box so ... I'll get back with whatever I find.

kolban

If there is value, I can capture any traces or logs that might be useful or supply someone a screen share to demonstrate the issue.

I have created issued #4239 for tracking.

Kodbin

I'm just trying this with fullscreen(P3D, 1) and it didn't open the window yet, but it is definitely taking a long time and so I suspect the behaviour is the same...

Incidentally my and kolban's symptoms are not exactly the same. If I understand correctly, he sees a 1.5 minute delay on random occasions, where I see more like half an hour, but only the first time I run a sketch each day.

I suspect mine is due to some drive being unloaded but needing 1/2 hour to do that seems very strange. Possibly something in processing is getting into (say) an unintended loop when the graphics system is in a particular state? Possibly this could point at a common cause for my and kolban's experiences, if with different hardware we are seeing different triggering events and different time-delays on the same underlying problem -- but I am completely guessing here :-)

I can also supply whatever logs might be useful, if I am told how to collect them...

Thanks,

Ian

koogs

imo the dual screens is a red herring.

next time it happens can you run netstat -a -n in another window? my theory is that there's a port that's blocked. (specifically the java debugger port. there's a bit in the code that has a suspend=true flag)

and a netstat -a -n when it works would be good too, so we can compare.

Kodbin

Ah, hmm, well I'm using a Java IDE when it happens. I don't have to be using the debugger for the problem to occur, but the IDE could be doing things to the port whether or not it is actually debugging...

Let me try your experiment, I get this from netstat:

I ran netstat twice about 30 seconds apart and saw some differences:

[ https://snipt.net/Bodkin/1st-ports/ ](1st netstat)

[ https://snipt.net/Bodkin/2nd-ports/ ](2nd netstat)

I hope that shows something relevant...

Thanks,

Ian

koogs

it's this bit i don't like:

https://github.com/processing/processing/blob/a83e4a5f81f4b1089a861127a831bbc0534678ab/java/src/processing/mode/java/runner/Runner.java

 public boolean launchVirtualMachine(boolean present, String[] args) {
    StringList vmParams = getMachineParams();
    StringList sketchParams = getSketchParams(present, args);
    int port = 8000 + (int) (Math.random() * 1000);
    String portStr = String.valueOf(port);
    String jdwpArg = "-agentlib:jdwp=transport=dt_socket,address=" + portStr + ",server=y,suspend=y";
...

it's using a random port between 8000 and 9000 and suspending until it gets a response. and i've seen skype, etc, sitting on random ports.

that said, there's nothing at all in that range in your logs. so i guess that's ruled that out... thanks.

Kodbin

If I break in with the debugger while it is pausing, the main thread stack looks like this:

"main@1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at java.io.FileOutputStream.close0(FileOutputStream.java:-1) at java.io.FileOutputStream.access$000(FileOutputStream.java:53) at java.io.FileOutputStream$1.close(FileOutputStream.java:356) at java.io.FileDescriptor.closeAll(FileDescriptor.java:216) - locked <0x4de> (a java.io.FileDescriptor) at java.io.FileOutputStream.close(FileOutputStream.java:354) at com.jogamp.common.util.IOUtil.fillExeTestFile(IOUtil.java:812) at com.jogamp.common.util.IOUtil.testDirExec(IOUtil.java:999) at com.jogamp.common.util.IOUtil.testDirImpl(IOUtil.java:1058) at com.jogamp.common.util.IOUtil.getSubTempDir(IOUtil.java:1118) at com.jogamp.common.util.IOUtil.getTempDir(IOUtil.java:1233) - locked <0x43e> (a java.lang.Class) at com.jogamp.common.util.cache.TempFileCache.(TempFileCache.java:81) - locked <0x4e8> (a java.io.PrintStream) at com.jogamp.common.util.cache.TempJarCache.initSingleton(TempJarCache.java:88) - locked <0x442> (a java.lang.Class) at com.jogamp.common.os.Platform$1.run(Platform.java:309) at java.security.AccessController.doPrivileged(AccessController.java:-1) at com.jogamp.common.os.Platform.(Platform.java:287) at com.jogamp.nativewindow.NativeWindowFactory$2.run(NativeWindowFactory.java:183) at java.security.AccessController.doPrivileged(AccessController.java:-1) at com.jogamp.nativewindow.NativeWindowFactory.(NativeWindowFactory.java:180) at com.jogamp.newt.NewtFactory$1.run(NewtFactory.java:68) at java.security.AccessController.doPrivileged(AccessController.java:-1) at com.jogamp.newt.NewtFactory.(NewtFactory.java:65) at processing.opengl.PSurfaceJOGL.initIcons(PSurfaceJOGL.java:510) at processing.opengl.PSurfaceJOGL.initFrame(PSurfaceJOGL.java:129) at processing.core.PApplet.initSurface(PApplet.java:10379) at processing.core.PApplet.runSketch(PApplet.java:10266) at processing.core.PApplet.main(PApplet.java:10029) at game.Main.main(Main.java:16)

I see reference to a jogamp temp folder there (to be clear: I don't really know what jogamp is...) but if I go searching for jogamp temp folders I find exes (in %TEMP% and also a "jogamp_0000" folder that seems to contain versioned DLLs of various names, including some OGL related ones...) So I am wondering whether the delay is caused by the need to fetch/regenerate these? Although that may not quite gel because (i) most of the dates in that folder are quite old and (ii) 1/2 hour seems very long, even for a file download, and (iii) I see the delay after I've not used processing for an hours or so, and you wouldn't expect to invalidate a cache/find new versions as often as that...

Not that it is clear this callstack is directly related, this could just be where this thread stalls waiting for something else...

Again thanks for any help...

Ian

koogs

jogamp is the standard java opengl library, formerly jogl.

IOUtil is here:

http://grepcode.com/file/repo1.maven.org/maven2/org.jogamp.gluegen/gluegen/2.3.1/com/jogamp/common/util/IOUtil.java

not obvious (to me) what it's doing let alone why.

getTempDir (which is where it is stopped) is trying lots of different locations looking for a temp directory. first it tries some Android util thing. then the property java.io.tmpdir for a location.

you can try defining jogamp.debug=true and seeing if that gives you more output.

Kodbin

Hmm, well this 10000 iteration loop looks like the sort of thing that could take half an hour... maybe if the permissions were such that none of the attempts could succeed and each took .1 of a second:

 private static File  [More ...] getSubTempDir(final File tmpRoot, final String tmpSubDirPrefix, final boolean executable, final String dbgMsg)
     throws SecurityException
 {
    File tmpBaseDir = null;
    if(null != testDirImpl(tmpRoot, true /** create */, executable, dbgMsg)) { // check tmpRoot first
       for(int i = 0; null == tmpBaseDir && i<=9999; i++) {
           final String tmpDirSuffix = String.format("_%04d", i); // 4 digits for iteration
           tmpBaseDir = testDirImpl(new File(tmpRoot, tmpSubDirPrefix+tmpDirSuffix), true /* create */, executable, dbgMsg);
       }
   }
   return tmpBaseDir;
}

Pure guesswork, of course, and doesn't explain how it takes 1/2 hour the first time but becomes fast the next.

I'm a newcomer to Java debugging. What sort of place would I set that debug variable?

Thanks,

Ian

koogs

What sort of place would I set that debug variable?

i don't know. i tried adding -Djogamp.debug=true to the processing3 start script but that did nothing.

Kodbin

Thanks, I'll do some research when I get some time...

koogs

there seem to be two different problems that are being lumped together - processing won't start and processing sketches are slow to start

the processing won't start thing might be network. someone has said that changing his proxy settings fixes the problem. other people say that the same laptop will work at home but not via the school wifi. it does do an update check when it starts and, according to the FAQ, does other things too:

https://github.com/processing/processing/wiki/FAQ#checking-for-updates-or-why-is-processing-connecting-to-the-network

and of that is the case then twiddling the updates flag in preferences (or disconnecting from network) might help confirm this.

this thread, however, appears to be the second type of error.

koogs

and the files in the jogamp000 directory are just copies of files extracted from the jars in the processing/core/library. if you look there you'll see bundles of files for mac, pc, linux, raspberry pi in assorted 32 and 64 bit versions.

but, yes, it has to find somewhere to put those files, hence the directory searching. the same is true of the console and error logfiles and the other temp files.

Kodbin

Hi again,

I am not seeing processing being slow to start, just the slow sketches...

I think the finding somewhere to put those files may be a red herring. I got distracted during debugging with the following effect:

1) I launched the sketch 2) when it hung, I broke into it with my IDE (showing the location I describe above) 3) then I got distracted and aborted the sketch 4) when I returned, some time later, the sketch ran without a bit pause...

(On other occasions, when I have aborted the program and immediately re-run it, I haven't seen it immediately become fast to start...)

So, if the speeding up can happen without the jogamp code even having to finish running, the implication is that it is something that happens outside the processing process. Which seems to point back to really slow driver loading...?

Ian