Author
Topic: Strange Fatal Error (Read 2374 times)

Really strange. Maybe I was just lucky. I started the test case maybe 25 times in total and never got the error. One more thing to try: After setting up all of your objects and before rendering the first frame, call World.compileAllObjects() and see if that changes anything.

'Force' closing and then retrying it seems to help as well for me to reproduce this error after launching it again. (in the newer Android versions this is usually quite easier to do by opening recently used apps list and then swiping the app away)

I'm already calling World.compileAllObjects() before rendering the first frame... well partially, if you meant rendering the first frame of the world because I already do blit a loading screen before that. (I think it's the same in the testcase)Basically how I do this:-> Load objects and much info in the Renderer's constructor-> Initialize framebuffer in onSurfaceChanged-> Before leaving the onSurfaceChanged method, I start a new Thread to load textures-> The app will already start onDrawFrame methods (it will just use the framebuffer to blit a loading screen here), but due to checking if the above mentioned Thread.isAlive() it won't start rendering the world and drawing the world.-> When textures are loaded, the objects are first added to the world (in the Thread).-> Then I call World.buildAllObjects() (in the Thread).-> Then I call World.compileAllObjects() (still in the Thread), and the Thread dies after this.-> So basically the onDrawFrame can now continue with the World rendering and drawing, but it just crashes instead (or crashes after a while).

I also tried to NOT make the thing Thread'ed. So it would just basically do the things that would now happen in the Thread in onSurfaceChanged, but it doesn't give a difference except that the onDrawFrame is now being blocked... And it will still crash.

_________________________EDIT:I tried Object3D.shareCompiledData(obj) in the hope it would fix something using (this will happen before World.buildAllObjects() is called in the Thread but this will happen in the Thread):

//final Enumeration<Object3D> objs = world.getObjects();//while (objs.hasMoreElements()) {//final Object3D beep = objs.nextElement();//if (beep != earth) {//beep.shareCompiledData(earth);//}//}Buuut nope...I just reverted that (commented it out) because the scaling seems messed up when I use that and it didn't fix anything anyway...(scaling is probably my fault... but it didn't fix anything... so yeah, just reverted it)

Your test APK seems to work fine for me on a Nexus 5X. I've never set it as a wallpaper though and just used the test-button in the GUI, but I guess that should be fine!? I opened it maybe 2 dozen times, I always swiped it into oblivion before doing so, I rotated the device while it was rendering, I swiped around on the screen and didn't crash once.

I also looked into the reported crashs of my game in Google Play and I got one report similar to yours, also with an Adreno GPU and on Android 4.4. Not sure, what this should tell us though.

Do you have something fancy running in the background on your device like some GL debugging hook app or some magic memory cleaner or virus scanner or anything like that?

Hmmm... Did you try to set the "Model Geometry Quality" to "High"? (for me this settings seems to make the crash more likely to happen)

I looked into the crashreports of my other app (the Skin Viewer 3D app) and it got reports of fatal signals as well... However, never this code=2 one.

Do I have something running in the background?GL debugging hook app: Nope. (I did enable to log GL traces in Developers Options for the logs, but it's off now)Some magic memory cleaner: Nope. My stock OS will tell me when some background app/process is using a lot of battery... but it won't close the app, just notify only.Virus scanner: Nope.

________

In meanwhile, I've been trying to scrap things from the testcaserenderer to see where the crash does appear and where it does not.And I got something that might be interesting to you.

Blitting affects the memory layout in the GPU's memory, as does every change like using another texture or another model size (no "luck" in reproducing the crash with high detail models either BTW), so I guess every hint into the "this might cause it"-direction so far might be a red herring. The thread doesn't apply. You can be 100% sure that all these buffer sizes in the engine are correct. I've already checked them multiple times in the past because of other problems and it always turned out that they are fine and not the cause of any problems. I even modified them on purpose to see how the engine behaves and it behaved exactly as one would expect: Either crash (if 1 too large) or fail to render stuff (if 1 too short).In addition, if this happens, it seems to happen on Adreno only. Granted, Adreno is the most popular GPU for Android devices (because it's part of Snapdragon), but if it would affect others, there should be at least some reports of that coming in...but there are none.

Anyway...looking at the stacktrace from the last thread (from your old device), it looks like as if it *might* be related to blitting though, because the native calls include cache_vertex_arrays, which actually makes no sense for geometry rendered from VBOs (or at least that's what I'm guessing, but who am I to know how a driver programmer thinks...).

Can you still confirm that it goes away when not blitting anything at all (that includes lens flares)?

"Can you still confirm that it goes away when not blitting anything at all (that includes lens flares)?"For the TestCaseRenderer I tried to launch the renderer 25 times with all blitting commented (the testcaserenderer didn't have a lens flare): 0 crashes.

For the LiveWallpaperRenderer (which I use in my app) I tried commenting out blitting and lensflare calls: still crashes. The only thing that seems to make crashes muuuch less common in the LiveWallpaperRenderer is to disable clouds and moon (I don't know why particularly these Object3D's...) or using Low/Ultra/Extreme polygon model seems to make crashes less likely to happen.

I actually doubt blitting is the real cause because the problem persists on the LiveWallpaperRenderer with all blitting disabled...

I tried to use the Config.blittingMode for 1, 2, 5, 6 and 8 in the TestCaseRenderer. Nothing helped, they all crashed...

But I don't know why but for some reason Config.blittingMode = 8 seems to work for both the TestRenderer and the LiveWallpaperRenderer now though... o.OI don't really understand why it didn't earlier... Or maybe I didn't push the app to the device properly...Though Config.blittingMode = 6 did crash on the TestRenderer once... but crashes seem less likely when the value is higher

I really don't know why the GLDebug crashes here...or, I actually do know. But I don't see how it has ever been able to work (which it did), given that the class hasn't changed in the last few years. Very puzzling.

Anyway, I've uploaded a new beta version that should fix that.

About the blitting...could be another red herring, because 8 (unlike all the smaller values) will again tinker with the memory layout in the GPU's memory. Maybe that helps more or less by accident. All the values below 8 are adding addition flushing and syncing into the blitting pipeline. I somehow hoped that this would help, because the desktop version contains a similar fix for older Radeon based GPUs...and as we all know (or maybe not...) Adreno is an anagram of Radeon, because they once belonged both to ATI. But obviously, it doesn't really fix it.

Sooo...if it keeps working with 8, then so be it. If it starts failing again (which I actually expect it to), the log output of the, now hopefully working, debugger will still be helpful.

Settings: Config.blittingMode=5Result: Crashes most of the time without being able to see the world. When it does load, everything seems fine. But watching in the direction of the sun/lensflare seems a bit laggy for some reason.Crashlog: http://pastebin.com/a14ceSVb

Settings: Config.blittingMode=7Result: Crashes most of the time without being able to see the world. When it does load, everything seems fine. But watching in the direction of the sun/lensflare seems extremely laggy.When the sun is hidden behind the Earth (so the lens flare is hidden), the lag is gone.When not watching in the direction of the sun/lens flare, the lag is gone as well.So basically, the extreme lag is only there when the lens flare is being blitted.Crashlog: http://pastebin.com/QfZtQpdS

Settings: Config.blittingMode=8Result: No crash, no lag.Crashlog: None (couldn't get the live wallpaper to crash, I tried loads of different combinations)Log: http://pastebin.com/zd1LxDTM (works normally here)

I would say my problem is solved when using Config.blittingMode=8 I wonder what your opinion is on this, because you seem sceptical...Thanks a lot so far!

Three another small things, it seems that a lot of textures are being loaded. (I guess most are 2x2 textures...)It's probably because my loading screen blits letters onto the framebuffer using 'new Texture(2,2, new RGBColor(col,col,col))' (with col ranging from 0 to 254)Wouldn't it be possible to just be able to bllt colors instead?I suppose that would be more lightweight than having to load textures and unload them in the end.Or is this nothing to worry about?

I also wonder if Object3D.shareCompiledData(obj); would be wise to use for me... since basically all objects use the same Mesh and have the same model.Main differences between some of the objects are: transparency, inverted culling and texture.

And the last thing I wondered about is that jPCT supports and uses 32-bit colored textures by default. But isn't it true that most devices these days only have a screen that is capable of displaying 16-bit colors? So why aren't the textures loaded as 16-bit textures? Wouldn't it be better to save my texture files (compressed) as 16-bit or 24-bit textures to reduce the APK file size? Or should I keep it 32-bit for future devices? I'm a bit puzzled about all of this...

First to your new questions: It would be better to put all the colors into one texture instead of several tiny ones. shareCompiledData() will save some memory and might improve performance slightly, so I suggest to use it if possible.Todays screens might not be able to display full 24bit colors, but they certainly support more than 16bit. You can do a simple test: Create a texture with some color gradients, load it twice and call enable4bpp(true) on one of them. Then render both and you'll see the difference.

About the crashes: Judging from the log output, it seems to stop when binding the index buffer (but for the second time). This isn't related to blitting. However, the size values of that buffer are all fine. In fact, the buffer is twice as large as it has to be but I fail to see a problem with that (I'll try to fiux that anyway though).

Could you try this: Set the Config.blittingMode back to 0 and build all objects by calling build(false);. That should implicitly disable geometry indices. If that helps, we have at least a clue of what could cause it. If it doesn't help, I would like to see the debug log of the result.

EDIT:And another thing, I've been interested in using a shader for the FrameBuffer... but it only works for blitting apparently...Is there some way to make the shader work for everything that will be displayed on screen (in 2D)? (so including world renders)

Great. Now it crashes on assigning an empty buffer, which makes no sense at all. So it's not the index either. Everything else in the log output looks fine. I'm out of ideas for now. I'll read the log again later today...

Got it, thanks a lot for the help I've been using my live wallpaper for a few days now and it hasn't crashed so far

There is something I'm wondering though...So I upload textures, build the world objects and compile the world objects in a separate Thread. While doing so, the FrameBuffer will keep blitting a loadingscreen (untill the Thread dies). Then World.renderScene and World.draw will be called... But the first time when that is called, the (last blitted loading) screen seems to hang for a few seconds... As if either World.renderScene or World.draw is doing heavy blocking operations on its first call... Is it possible to move the (heavy) operations that happen in the first World.renderScene/World.draw call in the separate loading Thread I talked about earlier?

EDIT:Coincidentally just got a user report on the Google Play Store with the following crash report: