Need help tracking down a crash (JME 3.0)

Troubleshooting General Help
1

Hey. We just released a game (Nations at War Digital) and some users are reporting a crash when starting one of the missions. My usual ways of producing an error log seem to get lost somehow, the best I have right now is a hs_err_pid logfile that someone sent me:

I see a couple of stack traces, one for niftygui and one for some texture updating but I couldn’t conclude if that is directly related to the crash or merely juxtaposition.
This mission doesn’t do anything notably differently, I tried looking at the one unique texture we load (a 2D map) which does have an odd resolution of 4244x2692, no other missions fail just this one. Most missions have maps that are 4096x2692 but we have another that is 4096x5272, all divisible by 4 and using DXT1 format, surely this can’t be some kind of ancient hardware limitation?

I don’t know how to understand these reports or where to even begin, if anyone could provide some pointers that would be great.
Thanks!

1 Like
2

I’m not someone with enough knowledge to answer your question… but I see some things in the log that could help you.

  1. Looks like your user is running Windows 8 (not even 8.1) which went unsupported years ago (even without problems with your game, surely they need to update for security reasons?) Who knows if Microsoft is even pushing GPU driver updates to that old version? And from a quick google, it seems this could be a driver issue
  2. You are distributing your game with an ancient JRE built on Dec 18 2013:
    JRE (1.7.0_51-b13)
  3. As you state here, is this the game that is still on jMonkey 3.0 from years and years ago?

If there are other users reporting this issue that have up to date operating systems and gpu drivers, it might be helpful to include crash logs from those as well.

3
  1. I’m using Windows 7, works fine for me. I still get graphics driver updates :stuck_out_tongue:
  2. Yeah we’re on a “dont change anything unless absolutely necessary” principle at this point. But I guess java 8 might be okay. I’ll investigate, thanks for the tip!
  3. Same game, yes. I’m hoping the publisher might fund a port to Unity for upcoming spinoffs, haha

Haven’t had anyone else give log files yet, I don’t have specs either.

4

Windows 8 (not 8.1) was unsupported as of January 12, 2016.
Windows 7, mainstream support ended on January 13, 2015.
Windows 7, extended support ended on January 14, 2020
So you might want to consider upgrading.
I don’t use windows so I don’t know what these mean for driver updates, but it looks like security patches have stopped completely. I doubt new driver releases are being pushed to operating systems that aren’t getting security patches anymore.

If I were in your shoes (I understand how difficult it is to maintain the legacy code you have :slight_smile: ) I would eliminate any of those uncertain variables that might be causing the issue by themselves, such as outdated JRE (you could even use a newer JRE 1.7 release, yours wasn’t the last one) and outdated operating systems (and drivers) to just make clear what you’re actually dealing with is even a bug that you are able to fix.

5

It looks to me like the crash occurred in native code used by OpenGL to generate mipmaps on AMD graphics adapters. If a driver update is available, that might help.

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [atio6axx.dll+0x177255c]
 
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.lwjgl.opengl.EXTFramebufferObject.nglGenerateMipmapEXT(IJ)V+0
j  org.lwjgl.opengl.EXTFramebufferObject.glGenerateMipmapEXT(I)V+15
j  com.jme3.renderer.lwjgl.LwjglRenderer.updateTexImageData(Lcom/jme3/texture/Image;Lcom/jme3/texture/Texture$Type;I)V+679
J  com.jme3.renderer.lwjgl.LwjglRenderer.setTexture(ILcom/jme3/texture/Texture;)V
j  com.jme3.material.MatParamTexture.apply(Lcom/jme3/renderer/Renderer;Lcom/jme3/material/Technique;)V+14
j  com.jme3.material.Material.render(Lcom/jme3/scene/Geometry;Lcom/jme3/renderer/RenderManager;)V+180
j  com.jme3.renderer.RenderManager.renderGeometry(Lcom/jme3/scene/Geometry;)V+204
j  com.jme3.renderer.queue.RenderQueue.renderGeometryList(Lcom/jme3/renderer/queue/GeometryList;Lcom/jme3/renderer/RenderManager;Lcom/jme3/renderer/Camera;Z)V+51
j  com.jme3.renderer.queue.RenderQueue.renderQueue(Lcom/jme3/renderer/queue/RenderQueue$Bucket;Lcom/jme3/renderer/RenderManager;Lcom/jme3/renderer/Camera;Z)V+83
j  com.jme3.renderer.RenderManager.renderViewPortQueues(Lcom/jme3/renderer/ViewPort;Z)V+54
j  com.jme3.renderer.RenderManager.flushQueue(Lcom/jme3/renderer/ViewPort;)V+3
j  com.jme3.renderer.RenderManager.renderViewPort(Lcom/jme3/renderer/ViewPort;F)V+267
j  com.jme3.renderer.RenderManager.render(FZ)V+123
6

What if their systems supports max 4096 texture? Have you checked the max texture size?
eg. use

int size = app.getRenderer().getLimits().get(Limits.TextureSize);
System.out.println("size " + size);
7

In my post I listed another texture that exceeds 4096 but doesn’t seem to have the issue.

I got the same user to give me some specs:
Sapphire Radeon RX 580 Pulse. Driver is stable version Radeon Software 20.2.2 (latest available to them)
It seems no actual error is pushed out on System.err, I had them run a launch argument that would output a few basic lines to see how far the mission setup gets and we finally got the log… no error, just my diagnostic lines (which suggests the code runs fine), it probably is some weird hardware kink upon JME uploading the new texture data (as sgold pointed out)
Fingers crossed for a JRE update, I guess.