Hi all,
the SDK will hang whenever I try to create a new package. It doesn’t even redraw itself anymore.
No error messages or anything.
Is there anything I can do to pinpoint the problem better?
Have you checked the IDE logs?
Mostly these freezing issues are coming from lwjgl failing one way or the other. I suppose you have the latest graphics driver installed?
It’s a Linux box, so all the drivers auto-update. Using the proprietary nVidia driver. It says it’s version 304.88-0ubuntu, this kind of numbering scheme usually means it’s version 304.88 from Nvidia.
Found the log files. They confirm something failed with LWJGL, but they’re less than informative:
[java]SEVERE [com.jme3.gde.core.scene.SceneApplication]: An OpenGL error has occured!
org.lwjgl.opengl.OpenGLException: Invalid operation (1282)
at org.lwjgl.opengl.Util.checkGLError(Util.java:59)
[catch] at com.jme3.system.lwjgl.LwjglOffscreenBuffer.checkGLError(LwjglOffscreenBuffer.java:98)
at com.jme3.system.lwjgl.LwjglOffscreenBuffer.runLoop(LwjglOffscreenBuffer.java:126)
at com.jme3.system.lwjgl.LwjglOffscreenBuffer.run(LwjglOffscreenBuffer.java:151)
at java.lang.Thread.run(Thread.java:679)[/java]
I find this surprising because
a) I don’t have any OpenGL view or window open
b) the workflow to create a new Java package doesn’t use (well, shouldn’t use) OpenGL at all.
I just started up the SDK again, opened the IDE log tab, and tried to copy from it for pasting. That triggered the crash, too.
After that, I gleaned the log from the log file and pasted it here: http://pastebin.com/fZULWRC7
Seems like it’s having threading issues at line 472 ff.
The backbuffer renderer is always started because thats the “worker thread” for the SDK scene-related operations (rendering previews etc). I suppose this is RC2? The current / release version should have much less issues in the AWT integration (and hopefully even more so when we finally move to JOGL). Can’t say for sure where the events occur that are dispatched from the wrong thread but I don’t see any of the SDK packages in the trace.
Yes, RC2.
I guess I’ll try a reinstall, then maybe start debugging on the SDK (is this even sensible to attempt?)
@toolforger said: Yes, RC2. I guess I'll try a reinstall, then maybe start debugging on the SDK (is this even sensible to attempt?)
If you want to see how ugly lwjgls AWT implementation really is… 
Can you use the OpenGL window at all? If not your graphics card / lwjgl combination probably doesn’t yield usable backbuffer support, you could try fiddling with the GL settings as per https://wiki.jmonkeyengine.org/legacy/doku.php/sdk:troubleshooting
I debugged into it a while ago, so nothing new there 
The OpenGL window does indeed not display. I had it visible earlier so I doubt it’s the true cause… though okay the LWJGL update may have broken things.
Testing… okay, switching to the heavyweight canvas made the wait cursor go away, but now it fails even before opening the creation dialog.
Something is really fishy here. I indulged a bit on plugins, next I’ll try a clean reinstall.
If the gl thread cannot start the SDK is bound to have issues, its worker thread is basically disabled then. Plus if you have issues with lwjgl it probably also means you have issues with your graphics card/ its driver in general.
It DID work a while ago, so I doubt it’s the driver.
EDIT: My own 3D software, built with the JME engine, runs without a hitch, both with Canvas and in windowed mode. This doesn’t totally exclude LWJGL problems, but it does move them down on the list of likely suspects.
I just completed a reinstall (including a settings directory wipe, as described on the troubleshooting page). The issue reappeared, with no output in the IDE log window (I haven’t checked the log file yet, maybe that has more).
My best bet is that the LWJGL update is causing issues. How this can affect the workings of the SDK if no 3D action is running at all is currently beyond me though. I copied that the render loop is running anyway, but that still shouldn’t cause lockups when opening package creation dialogs. Surprisingly, the text fields would be unresponsive (never accept focus), but redraw and the Cancel button would work.
I’ll try to reproduce with the 3D window open and closed, and see whether that causes any differences.
Is there a way to start with a raw Netbeans install and add the jme plugins piece after piece? That might help pinpointing the cause.
lwjgl update? RC2 has had the same version of lwjgl since its release. And currently you also can’t upgrade to nightly which has the newer lwjgl version but is probably incompatible with RC2 due to the different platform.
No matter why, lwjgl fails to start and lwjgl basically only uses gl and awt stuff, so the problem is most definitely around there. Linux isn’t exactly holistic in that respect either, especially with java in the mix.
So I suggest making sure all problem sources are eliminated, as described in the troubleshooting page:
- Install the latest graphics driver from nvidia/ati, not from the package manager
- Use oracles JDK
- Use the normal java LAF, not the system one
- Disable Compitz
Then when that still fails:
- Try the heavyweight canvas to avoid problems with backbuffer support
- Try OpenGL1 mode
If all those fail you will have to wait and hope that the latest lwjgl will solve your problems with 3.0 Stable. Or try it by building the SDK yourself:
[java]svn co ht tp://jmonkeyengine.googlecode.com/svn/trunk jme3
cd jme3
ant run[/java]
If that works make your own SDK build using
[java]ant zip[/java]
And as I explained earlier, when an application cannot use its worker thread then theres surely going to be issues. And the GL thread is the worker thread in the SDK. Furthermore swing/awt is traditionally the interface where java platform independence fails and exhibits strangeness and even freezes. Even without throwng GL into the mix. If you haven’t experienced that yet you are certainly lucky
I’m not too happy with the prospect of replacing the video driver with a more current one. In the past this usually created more problems than it solved.
Add in that getting rid of a flaky driver can be difficult (Nvidia doesn’t properly integrate with the usual package manager infrastructures), and that a broken driver can render the system unusable, that’s quite a risky approach.
So I’ll exhaust other possibilities before trying that.
- Oracle JDK - check, already using that.
- Java LAF - I’ll have to try that. (That SHOULD not influence things but well.)
- Compiz - I’ll have to check how to disable that. If it’s enabled at all, I’m generally frugal with desktop effects. However, switching off Compize does have it’s ramifications so that’s getting lower on the list of things to try.
- Heavyweight canvas - tried this on the previous install, didn’t change anything. May be worth trying again as a last resort.
- OpenGL1 - wouldn’t that disable shaders and stuff? The shadernode editor is about the one reason I’m putting up with the SDK at all. I could try that just to add another data point about what might help, but would it really help me get a usable SDK?
Building the SDK by myself might indeed be the easiest route. Well, the one with
(Gah. I was wondering what these “ht” and “tp” flags might be before I noticed that something or somebody broke up a http:// prefix…)
Is there a way to check whether the GL thread is running? I’d want to establish that things are really GL-related before I start experiments that might end in system breakage. I can repair most breakage, but it’s taking lots of time that I’d rather spend differently.
bump
How do I find out whether the GL thread is running?
BTW somebody else is having the same problem, uses the same Linux as me.
http://hub.jmonkeyengine.org/forum/topic/cant-create-a-new-project/
More info… after looking around, I found that JVisualVM can confirm which threads are alive and which aren’t.
Turns out the render loop thread is alive and well, changing between active and wait.
However, the AWT event loop is in “Monitor” state, which essentially means it’s waiting for some lock to become available and that’s simply not happening. I guess I really need to run the SDK in a debugger to find out more.
Just found out that JVisualVM can not only tell me what threads there are, but also what state they are in, what locks they hold, and their current stack trace.
Results:
There are two AWT-EventQueue threads, one of them holding the TreeLock and not releasing it, the other waiting for that lock. Both threads are related to HTML, one is trying to do layout with an HTML window and the other is trying to fill it with content.
I’m not sure what’s happening here. What I find most strange is that I’m having two AWT-EventQueue threads here, is this normal?
Okay… I got around to building a nightly, and it worked right out of the box.
I’m chalking this up to either updates in JME itself or (more likely) not having installed some rogue plugin that destabilized my previous install.
@toolforger said: Okay... I got around to building a nightly, and it worked right out of the box. I'm chalking this up to either updates in JME itself or (more likely) not having installed some rogue plugin that destabilized my previous install.
More likely the new lwjgl than anything else… :roll: But why listen to me when you can “research” right? ^^
Btw, did you try updating your graphics driver? Or will you break your system with that? xD
Why should I listen to you if the best you have is a “more likely” guess?
Not that I don’t recognize your experience, mind you, but given that neither stack traces nor exceptions point anywhere near LWJGL, the connection is indirect, and it could be anything. I mean - have you SEEN double AWT event loop threads in the SDK? Caused by LWJGL problems? That information would be of more help.
I didn’t upgrade the graphics driver. I didn’t see that as the first thing to try because I didn’t see any OpenGL exceptions in most of the logs that I checked.
The list of available drivers has 304 (currently installed) and 310 (not installed, it says it’s an “unstable beta driver, intended for testers and early adopters, and not recommended for production hardware”).
@toolforger said: Why should I listen to you if the best you have is a "more likely" guess? Not that I don't recognize your experience, mind you, but given that neither stack traces nor exceptions point anywhere near LWJGL, the connection is indirect, and it could be anything. I mean - have you SEEN double AWT event loop threads in the SDK? Caused by LWJGL problems? That information would be of more help.I didn’t upgrade the graphics driver. I didn’t see that as the first thing to try because I didn’t see any OpenGL exceptions in most of the logs that I checked.
The list of available drivers has 304 (currently installed) and 310 (not installed, it says it’s an “unstable beta driver, intended for testers and early adopters, and not recommended for production hardware”).
I havent seen that you got any wiser from your wealth of information either. But I am not really interested in theorizing software failures.