A while ago I bumped into an issue with eglSwapBuffers freezing the phone with the following message showing up in the device log:
W/SharedBufferStack( 1110): waitForCondition(LockCondition) timed out (identity=28, status=0). CPU may be pegged. trying again.
I've seen discussion on this issue all over the web but the only solution I've found to have any effect is calling glFinish after eglSwapBuffers. This solution, however, results in the framerate dropping by a whooping 10-20, which is far from acceptable.
Issues have been opened and one can be found here
Someone commented that using square textures eliminated the issue. By square I initially thought he meant power-of-two textures but after making sure I was not using any non-power-of-two textures and not getting rid of the issue I began to think that he might have actually meant textures with matching width and height?
I'm testing on an HTC Desire with Android 2.3.3. Someone commented that future versions should have fixed this issue but 2.3.3 is installed on so many devices that we can't disregard it.
Anyway, anyone have any thoughts on this? We're very close to shipping a title and this issue is threatening out schedule.
I also came across this issue, I used to re-install the Application and it worked for me.If not, then simply reboot your device.This issue is related to internal isssue of OpenGLES.You can refer this link:
Android "cpu may be pegged" bug
Related
I have been playing with optimizing my app, and I see that there are some general ideas on how much memory it should use... I'm running between 70-80Mb right now, is that a crazy number or just a little on the heavy side?
My second question is about the memory I am using. About 42Mb is taken up by graphics, whether I run the app with the layout graphics or run it without setting any views... any ideas on where to look? I feel like it is the theme, but I am not sure how to test that.
I've been searching for days to figure out why it uses so much and cannot figure it out. It remains constant regardless of which activity I am on, any ideas are welcome!
UPDATE:
I ended up running it on an emulator and got about 26Mb, more what I was expecting, but it runs at 70Mb with the 42Mb of graphics on the actual device.
The emulator allows for a 384Mb app after getting memoryclass information, while the device only allows 256Mb... the emulator has more storage and runs more efficiently.
The emulator is Android 8.1 27api while the device is Android 7.0 24api.
Tried on an older Android 5.1.1 api 22 below also.
Any ideas?
I have another question with about why the emulators have a such a difference in performance here if you know the answer on that, but I wanted to keep these questions separate: Other Question
Android Studio has an awesome tool called Memory Profiler. It helps you analyze possible memory leaks and see which calls are using up the most memory. You can even pause the processor and 'zoom in' to deep dive on the call stack.
You can use LeakCanary A memory leak detection library for Android and Java. Maintain by Square. This is one of the best developer's Tool for memory optimization and detecting leaks.here
my first android game it's almost done, and I'm on the way to publish it on the play store.
Today I tested it on some friends phone and it worked on all except for a samung a5. On this phone the meshes flicker, apper and disapper and look deformed. This when playing game where I use a lot of frame buffer, in the main menu where there is a simpler animation everything look right.
The game is developed with libGdx and use some custom shader. I've tested it on 8 other different device without no issue (excepect for low frame rate on samsung galaxy tab s4).
I ask yours advise:
1) what should I start to check to find the problem with a5?
2) do you think I should delay the publication until the bug it's solved ora I should publish it excluding A5 ( or maybe all devices with similar GPU) from compatibility list?
My big problem is that at the moment I don't have the device with me (it's the personal phone of a friend of mine...) and probably I will have it for only a limited amount of time, so I want to be preparated to avoid to lock the device for too much time to my friend.
Thanks to all!
First, I'd make sure you don't have any OpenGL errors - add calls to glGetError and validate frame buffers and shader programs, you can do this without the device and adding extra asserts like this is always worthwhile (assuming you don't already have them). Next, try using the tools provided by the GPU manufacturer. In your case the snapdragon profiler. To minimize the time you'll be using your friends device, get the tools installed ahead of time and if you have access to another Qualcomm device, then use that to familiarize yourself with the software. With luck the cause of problem might become immediately obvious. If not, then it's just a binary search of disabling parts of your code until you narrow it down to a particular shader/draw call, then examine/tweak that to figure out what bit is going wrong.
That's a tough call. If it's a driver bug, then it might only occur on particular revisions. Some A5 devices might work if they're on different versions of Android from your friends device. That said, the A5 is relatively recent and Samsung/Qualcomm drivers tend to be pretty solid IME, so it's more likely an error in your code that happens to only be exposed on certain devices. Personally I would delay release unless your release strategy is timing sensitive, from the limited data you have, your game doesn't work on >10% of devices.
Just wanted to share an experience I had to see if anyone came across such issue, if they found the cause and more importantly how they fixed it.
The problem is pretty simple: while debugging native code on a Nexus 6, which as the Adreno 420 GPU, eglSwapBuffer could crash under certain circumstances when using Android 5.1 (5.0 worked perfectly).
Since I could not repro it I am unable to tell you what went wrong. According to the documentation, elgSwapBuffer calls internally glFlush; and so if I call glFlush before calling eglSwapBuffer all of a sudden it works perfectly.
My guess is that the driver does not flush properly thus crashing when swaping the buffers.
Any comments on this?
Cheers,
D
I'm having the same problem and I can reproduce it. It happens obviously because it runs out of stack memory due to deep nested loops in the rendering process.
Android Lollipop 5.1: Fatal signal 11 (SIGSEGV), code 2, fault addr 0x9e985ff8 in tid 4093 (RenderThread) / when using lot of nine patch graphics
I've already reported it to the google issue tracker:
https://code.google.com/p/android/issues/detail?id=163100
Update: Meanwhile I found a way to work around this issue. It's definitely not a long time solution, but for the moment, it's just the best available to stop my apps from crashing.
I disabled GPU rendering for particular graphic layers. It slows the drawing down a bit, but not significant.
So the nightmare is over for now, but I still think, this issue must be fixed on the driver itself. It cannot be that something that worked perfect with 5.0.2 and below, immediately stops to work with 5.1.
I have seen some weird behavior on the N6 as well, and while I cannot rule out app bugs, it looks to me like the Adreno driver is to blame.
Specifically, in landscape mode, our GLSurfaceView only renders one half of it's content, but occasionally flickers all of it. And with certain scenes being rendered there is intermittent flickering. In a case of extra weirdness, I have seen one half of the screen completely freeze, stuck on app content, even after returning to the launcher via the home button. It appears kind of like it would if it used multi stream transport and one of the streams was getting lost.
I downloaded the samples from OpenCV for Android and let them run in eclipse on a real device (Nexus 7). They all work fine, but when I'm looking at the LogCat log, I see ca 20 errors displayed for each frame. The log is filled with them. Although all the samples work, this irritates me and makes it hard to debug the code.
Here a screenshot of the log:
Does anyone know where these errors come from and what they mean?
Should I worry about them, if no: can I somehow hide them? if yes: what to do?
Another question:
I get, when running the JavaCameraView idle (Sample CameraPreview) only 15fps max. This is few, isn't it? Or is this always like this when using OpenCV with Java (over JNI) instead of c++?
Thanks in advance for any hints!
Isa
The next OpenCV version will fix a few camera bugs, maybe it fixes those messages. There is one specific to Nexus 7 2013, but looks different from yours.
JavaCamera is usually slower than NativeCamera but more stable (less buggy). But it also depends from other factors like ambient light (less light = slower), chosen resolution.
When using the ART runtime on my HTC One GPE with Eclipse the currently executing line of code indicator does not move when Step Over and Step Into are used. The execution appears to continue, but it is very hard to tell where it's at without the indicator. Switching back to Dalvik resolves the issue. Has anyone experienced this and is there any way to fix it?
Was having the same problem, switching back to Dalvik fixed the issue for me too
what made it hard to find is the fact that the debug was working rundomly sometimes on the first instructions dont know why
Yeah, the new VM as it shipped with kitkat has several bugs that affect debugging. In particular, stepping doesn't work at all well. There are numerous bug fixes already checked in to AOSP. I think this particular bug was fixed by this change, relatively innocuous though it sounds: https://android.googlesource.com/platform/art/+/f2910eef247b45ce1d489e323b36b5de6b6157aa
If you have a Nexus device you can build AOSP yourself and try it out. If not, you'll have to switch back to dalvik for now.
If you find other bugs, please use b.android.com to report them. You can't assume someone will make us aware of bug reports on stack overflow!