[solved]Game crashes with IllegalStateException when switching resolution

Greetings,



I’ve got a problem with switching resolutions and the water-filter (at least it looks like that).



Somewhere in the game I change the resolution with this one:



[java]

public void changeResolution(boolean fullScreen, DisplayMode mode)

{

AppSettings settings = new AppSettings(true);



settings.setWidth(mode.getWidth());

settings.setHeight(mode.getHeight());

settings.setFrequency(mode.getFrequency());

settings.setBitsPerPixel(mode.getBitsPerPixel());



settings.setFullscreen(fullScreen);



setSettings(settings);



restart();



[/java]



Than for 5-10 seconds everything seems to work fine. the resolution is changed and I can go on. After that the game crashes out of nowhere with the following:



FATAL: === jMonkeyEngine FBO State ===

FrameBuffer[format=512x512x1, drawBuf=0]

Depth => BufferTarget[format=Depth]

Color(0) => TextureTarget[format=RGBA8]



=== OpenGL FBO State ===

Context doublebuffered? false

FBO ID: 1

Is proper? true

Is bound to draw? true

Is bound to read? true

Draw buffer: GL_COLOR_ATTACHMENT0

Read buffer: GL_COLOR_ATTACHMENT0

== Renderbuffer Depth ==

RB ID: 1

Is proper? true

Type: None

== Renderbuffer Color0 ==

RB ID: -1

Is proper? false

Type: None

19.09.2012 00:43:15 com.jme3.app.Application handleError

FATAL: Uncaught exception thrown in Thread[LWJGL Renderer Thread,5,main]

java.lang.IllegalStateException: Framebuffer doesn’t have any renderbuffers attached.

at com.jme3.renderer.lwjgl.LwjglRenderer.checkFrameBufferError(LwjglRenderer.java:1316)

at com.jme3.renderer.lwjgl.LwjglRenderer.setFrameBuffer(LwjglRenderer.java:1593)

at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:952)

at com.jme3.water.WaterFilter.preFrame(WaterFilter.java:199)

at com.jme3.post.FilterPostProcessor.preFrame(FilterPostProcessor.java:329)

at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:948)

at com.jme3.renderer.RenderManager.render(RenderManager.java:1016)

at com.jme3.app.SimpleApplication.update(SimpleApplication.java:251)

at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:151)

at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:181)

at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:228)

at java.lang.Thread.run(Thread.java:662)



The scenery includes only a light, the sky, the waterfilter and some niftyGui elements.



Has anybody experienced something similar?

I found out some things:

  • the water-filter is not the trouble-maker because of the following:
  • if there’s no post-processor attached it seems to work
  • if there’s a post-processor without a filter attached it seems to work, too
  • if I attach a post-filter with the water-filter or a TranslucentBucketFilter, it’s crashing again



    Hope that’s helpfull. I’ll now go on to write a test-case.

ok i’ll check it out.

are you using multiple monitors? if so try it with only 1, and see if that fixes anything

@wezrule: Sorry, no. It’s just one.

If I do not add the NiftyJmeDisplay to the scenery, it also does not crash, when switching the resolution.



This is the line I just removed: guiViewPort.addProcessor(display);

Damn, I’ve got it.



On res-switching, I turned the vsync off (which was on before). So it looks like that after 10-12 seconds the viewport gets out of sync with something which breaks the renderer.



edit: having vsync completey deactivated kills the game again… -.-

Tried it on a gentoo-linux. Same problem but not every resolution is “corrupt”. Some are working, some not.



At least VSync has to be off to cause this issue. And somehow nifty seems to be a cause, too, but it’s just a guess.

Did you manage to make a test case?

No, all tests I try to write are working fine (unfortunately).

@nehon: I’ve uploaded the game with the issue here.



www.shipswithcannons.net/downloads/pirateHellResolutionIssueTest.zip



To cause the problem you have to change the resolution and wait 10-15 seconds.

I’m downloading it

ok I have the error too.

I’m pretty sure i didn’t get it with previous alpha test and i did switch resolution.

What did you change?



Edit : heu…nope, I just found your alpha version on my hard drive and the error occurred here too…

okay I’m pretty sure now it’s an ui-element that causes the trouble. Now I have to find out which one.

I forgot to mention that there’s music playing while the game is running and if I deactivate the music, the resolution-switching works fine again.



So the following can be said:



If I deactivate post-filter it works

If I deactivate the nifty-ui it works

If I deactivate the sound, it works.



But all together does not work.

Okay, our new targets name is: garbage collector. I logged the free memory and it looked like that the game crashes every time the VM tries to call the garbage collector (after the restart, not before).



If I call the gc right after the restart, everything seems to work fine.



Would be the best cause, cause it’s very easy to fix. I’ll continue the tests and see if I’m right.

It’s definitely a problem with the garbage-collector.



Doing this:

[java]



restart();

Runtime.getRuntime().gc();



[/java]



solves the problem.

That’s very strange…

I’m clueless about what’s going on…

@pspeed any idea?

@nehon said:
That's very strange....
I'm clueless about what's going on....
@pspeed any idea?


I'm not familiar with the code that restarts the app so this is all pure speculation just based on the facts in this thread. Sometimes that's enough, though.

JME and the GC only have one real "interaction" and that's that when GC is called it will queue any of the weak references that are no longer connected. JME will then release the native objects that are no longer used. So it would seem like something related to this, maybe. But as I said, I'm just guessing.

I want to think of something somehow freeing up objects that are still needed... so when GC finally hits then there is a crash. Calling GC earlier maybe forces the objects to be regrabbed somehow. Points against this theory: why did the weak references get queued if the objects were still referenced? I also can't think of anything in the rendering that would refresh these objects if they've gone bad.

But maybe someone more knowledgeable on those than me sees something. (shrug)