SDK Lockup when scrolling through shaders, icon related?

[jmonkeyengine]

SDK Lockup when scrolling through shaders, icon related?

[MeFisto94]

I took a look into it but couldn't reproduce that bug just with this file (and a few other shaders).
First: It is usual that the Shaders themselves (.frag, .vert) have the White Sheet whereas the .j3md's have the palette with the gear (Materials only have the palette).

What I could imagine is that some Exception happens when trying to process those files (.j3md's could be interpreted as Shader Nodes and it could try to find the referenced .frag/.vert's).

The Exception alone shouldn't lead to a lockup but an Exception could lead to a Stack Overflow for example (For this, try to set the Logging Level to FINE. You can do that by clicking on that monkey with that blueish something or even better: Compile the SDK from Source and Launch it in Netbeans.
It will capture all output (even made to STDOUT instead of the Logger))

[phr00t]

I changed the logging level to fine, but nothing prints out in the output window when the lockup occurs. It seems to lockup before anything has a chance to respond. Hopefully you can reproduce it with more files:

SimpleLight.j3md:

MaterialDef SimpleLight {

    MaterialParameters {
        Vector2 Alpha
        Texture2D Texture
        Texture2D NoiseTexture
        Color Color (Color)

        // For VR instancing
        Matrix4 RightEyeViewProjectionMatrix
    }

    Technique PreNormalPass15 {

          VertexShader GLSL150 :   jmevr/shaders/normal.vert
          FragmentShader GLSL150 : jmevr/shaders/normal.frag

          WorldParameters {
            ViewProjectionMatrix // needed for VR instancing
            WorldViewProjectionMatrix
            WorldViewMatrix
            NormalMatrix
            ViewMatrix
          }

          Defines {
            INSTANCING : RightEyeViewProjectionMatrix // For VR instancing
            NUM_BONES : NumberOfBones
          }
   }

    Technique PreNormalPass {

          VertexShader GLSL100 :   jmevr/shaders/normal.vert
          FragmentShader GLSL100 : jmevr/shaders/normal.frag

          WorldParameters {
            ViewProjectionMatrix // needed for VR instancing
            WorldViewProjectionMatrix
            WorldViewMatrix
            NormalMatrix
            ViewMatrix
          }

          Defines {
              INSTANCING : RightEyeViewProjectionMatrix // For VR instancing
              NUM_BONES : NumberOfBones
          }
   }

    Technique {
        VertexShader GLSL150:   Shaders/SimpleLight.vert
        FragmentShader GLSL150: Shaders/SimpleLight.frag

        WorldParameters {
            ViewProjectionMatrix // needed for VR instancing
            WorldViewProjectionMatrix
            WorldMatrixInverseTranspose
        }

        Defines {
            INSTANCING : RightEyeViewProjectionMatrix // For VR instancing
            HAS_NOISETEXTURE : NoiseTexture
            HAS_ALPHA : Alpha
            HAS_TEXTURE : Texture
            HAS_COLOR : Color
        }
    }

    Technique {
        VertexShader GLSL100:   Shaders/SimpleLight.vert
        FragmentShader GLSL100: Shaders/SimpleLight.frag

        WorldParameters {
            ViewProjectionMatrix // needed for VR instancing
            WorldViewProjectionMatrix
            WorldMatrixInverseTranspose
        }

        Defines {
            INSTANCING : RightEyeViewProjectionMatrix // For VR instancing
            HAS_NOISETEXTURE : NoiseTexture
            HAS_ALPHA : Alpha
            HAS_TEXTURE : Texture
            HAS_COLOR : Color
        }
    }

}

SimpleLight.vert:

#define VERTEX_SHADER
#import "Common/ShaderLib/GLSLCompat.glsllib"

// import the following for VR instancing
#import "jmevr/shaders/InstanceVR.glsllib"

uniform mat3 g_WorldMatrixInverseTranspose;

attribute vec3 inPosition;
attribute vec3 inNormal;

varying vec3 vNormal;
varying float zdist;

#if defined(HAS_TEXTURE) || defined(HAS_NOISETEXTURE)
    attribute vec2 inTexCoord;
    varying vec2 texCoord1;
#endif

void main(){
    vec4 position = vec4(inPosition, 1.0);
    gl_Position = TransformWorldViewProjectionVR(position);
    vNormal = normalize(g_WorldMatrixInverseTranspose * inNormal);   
    zdist = gl_Position.z;
    #if defined(HAS_TEXTURE) || defined(HAS_NOISETEXTURE)
        texCoord1 = inTexCoord;
    #endif
}

[empirephoenix]

You could try with Java mission Controll or any other tool thaqt can display the current thread stacks to connect.
Then use application till lockup and look at all Thread stacks if you see something interesting. (Eg like somethingImageGenerate() wait() maybee this should help to narrow down what classes are responsible.

[phr00t]

Thread monitor:

http://i.imgur.com/eZY7oLx.png

When the highlighted thread turns red is when the lockup happens. AWT-EventQueue-0 seems to go to "Wait" at the same time indefinitely -- probably explains why the GUI just becomes unresponsive.

Thread dump BEFORE the lockup:

http://pastebin.com/5qq2B7Nu

Thread dumps AFTER the lockup:

http://pastebin.com/ffkxxd0D
http://pastebin.com/4Rtj5qng

[MeFisto94]

Okay, so my findings so far are:

We're currently experiencing a deadlock situation between the AWTTreeLock and the DataObjectPool for some reason.

In Line 330 the AWT-EventQueue-0 locks the AWTTreeLock. This is expected.
In Line 239 it also gets hold of a loaders.DataObjectPool. This is also okay, someone simply wants information about the .j3md and waits for the current Pool Request to finish.

The Thread "DataSystemNodes" in Line 87 is the Problem though.
It locks the DataObjectPool by Processing a Request. This Request is faulty since it tries to create a JPanel without being enqueued in the AWT Thread. This leads to the acquiration of the AWTTreeLock which isn't available ofcourse (though it would if we were the AWT Thread).

Now there are two sights on this: Usually the Creation of a Panel happens from inside the AWT Thread (just checked that: If I place a breakpoint into the Panel's Constructor, it is in AWT Thread) and hence the Invokation of new JPanel() is completely legit. I have to check but I guess this is even what the Netbeans Sample Code does.
The Solution here would be to find the faulty request and change it to be in the AWT Thread instead.

The other sight is, that these requests happen wherever you try to get some information about a file.
In that case you wouldn't expect something AWT related to happen.
The Solution here would be to simply place that Constructor in the AWT Thread and make the other code NPE safe.

Now I am uncertain in what would be the best solution?

BTW: That AWT Stacktrace is the regular one: AssetNode#isFile seems to be the first thing called when a new node is displayed.