In short:
I have a UI that appears whenever any unexpected exception happens, and displays the full stacktrace + additional information to help pinpoint the issue.
I now have an exception (fixing the exception is trivial, and not the issue here) that manages to lock up the client, after some investigation i ended up with BitmapText being the culprit.
The following textcase leads to a hard freeze of the jme app on my machine. I use jme git version with a few weeks delay.
package de.visiongamestudios.client;
import java.io.File;
import java.io.FileNotFoundException;
import java.util.Scanner;
import com.jme3.app.SimpleApplication;
import com.jme3.font.BitmapText;
public class TestBitmapBug extends SimpleApplication{
String text = "";
@Override
public void simpleInitApp() {
try {
Scanner in = new Scanner(new File("./text.txt"));
while(in.hasNext()){
text += in.next();
}
guiNode.detachAllChildren();
guiFont = assetManager.loadFont("Interface/Fonts/Default.fnt");
BitmapText helloText = new BitmapText(guiFont, false);
helloText.setSize(guiFont.getCharSet().getRenderedSize());
helloText.setText(text);
helloText.setLocalTranslation(300, 480, 0);
guiNode.attachChild(helloText);
} catch (FileNotFoundException e) {
e.printStackTrace();
}
}
public static void main(String[] args) {
new TestBitmapBug().start();
}
}
And here is the exception text, causing the lookdown. Upon first rendering the assemble methods seem to be running forever, however I do not understand them good enough to make sense of this behaviour. With just 144 lines and around 250k letter5s i think it should still work. (The error view is scrollable)
My NoScript doesn’t seem to like the page you linked so I couldn’t see the exception, but could it be that there’s too much geometry? Each vertex needs an index and indices are stored in a ShortBuffer so the number of vertices cannot exceed Short.MAX_VALUE which I believe is 65535 meaning you can only display a maximum of 16,383 characters.
If you want to display more you need multiple Geometries.
Yes that seems very reasonable, thanks, so it probably freezes because the index wraps and it never reaches the expected value.
The text is a very long spring exception with about 250k letters.
I will test if it works if clamp it at 16k letters, if it does it should be easy enough to automatically split it into multiple max16k parts.
…but the work around may be far easier than a proper fix given the complexity (ugliness?) of the BitmapText code and the simplicity of the work around.
If you are also logging your exceptions to some persistent log file (and if not, why not?) then you might try just truncating the message if it’s longer than a certain length with the idea that the original is nicely found in a log file and the long one is not particularly pleasant to look at in a UI anyway.
Guava even has a nice method for truncating a string to a maximum length and adding some text if it truncates it.
Expanding on the suggestion from @pspeed you could log your stack trace to a log file and in the application just print out Exception.getMesssge(). I have not run into a situation where the string returned from that is anywhere near 16,000, characters.
Yes, I did implement something similar by now, first splitting by line, then truncate each after 250chars, is enough to actually get a useable stacktrace
There should proably be an if (text.lenght>~16000) throw illegalstate exception ? If so I could just make a pull request.
