Android的＆QUOT; CPU可挂＆QUOT;错误 [英] Android "cpu may be pegged" bug

问题描述

前言：这种严重的错误可能导致Android设备来锁定（无法preSS主页/后退按键，需要硬复位）。它与OpenGL的表面和音频播放相关。 logcat的重复东西的效果的

W/SharedBufferStack( 398): waitForCondition(LockCondition) timed out (identity=9, status=0). CPU may be pegged. trying again.

一旦这个错误的每一秒，故名。这样做的根本原因可能是由于一个死锁缓冲数据时，是它的声音或图形。的

在华硕Eee变压器平板电脑测试我的应用程序时，我偶尔会得到这个错误。在发生崩溃时，使用声线填充的MediaPlayer 对象 MediaPlayer.create（背景下，R.raw.someid）; 和 GLSurface 线程负载使用位图纹理

I occasionally get this bug when testing my app on the Asus EEE Transformer tablet. The crash occurs when the sound thread populates MediaPlayer objects using MediaPlayer.create(context, R.raw.someid); and the GLSurface thread loads textures from bitmaps using

Bitmap bitmap = BitmapFactory.decodeResource(context.getResources(),
                R.drawable.textureMap,opts);
gl.glGenTextures(1, texAtlas, 0);
gl.glBindTexture(GL10.GL_TEXTURE_2D, texAtlas[0]);
gl.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_MIN_FILTER, GL10.GL_NEAREST);
gl.glTexParameterf(GL10.GL_TEXTURE_2D, GL10.GL_TEXTURE_MAG_FILTER, GL10.GL_LINEAR);
GLUtils.texImage2D(GL10.GL_TEXTURE_2D, 0, bitmap, 0);
bitmap.recycle();

我不认为原因是音频，因为音频的确实际上仍然发挥（它加载音频那么时间x量之后发挥它的线程）。如果是这样，使用上述code的原因在于OpenGL ES的缓冲。

I don't think the cause is the audio, as the audio does in fact still play (the thread which loads the audio then plays it after x amount of time). If so, the cause lies in the OpenGL ES buffering using the above code.

相关材料

• 这SO帖子指的是这个bug。他们使用的OpenGL ES 2.0和NDK。我使用OpenGL ES 1.1（虽然大多数设备仿真1.1至2.0，所以在技术上，他们使用的是2.0），我不使用NDK。此外，他们还采用Android 2.1和我发生崩溃在Android 3.2.1。
• 本网站错误链接到 AudioTrack 对象。但是，我不使用，在我的应用程序。
• <一个href="http://$c$c.google.com/p/android/issues/detail?id=20833&q=cpu%20may%20be%20pegged&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars">The Android的Bug跟踪列出这是一个已知的bug，但作为尚没有解决办法（和它的不固定蜂窝+）。

• This SO post refers to this bug. They use OpenGL ES 2.0 and NDK. I use OpenGL ES 1.1 (albeit most devices emulate 1.1 through 2.0, so technically they are using 2.0) and I do not use the NDK. Further, they use Android 2.1 and my crash occurs on Android 3.2.1.
• This site links the bug to the AudioTrack object. However, I do not use that in my app.
• The Android Bug Tracker lists this as a known bug, but as of yet there is no solution (and it's not fixed in Honeycomb+).

常用元素

• 在冷冻时会出现缓冲。被缓冲的事情通常是相当大的，因此图像（错误更频繁地发生的较大的图像）或音频典型地受到影响。
• 在冻结仅出现在某些设备上。
• 在冻结不涉及具体的Andr​​oid版本 - 已经被记录在2.1和3.2.1，等等
• 在冻结不涉及使用NDK的。
• 在冻结是没有关系的单一的编程习惯（为了缓冲，文件类型等）

我的问题是pretty的简单。是否有解决此问题？如果你不能prevent它，是有办法优雅地失败，prevent整个装置被砖？

My question is pretty simple. Is there a workaround for this issue? If you can't prevent it, is there a way to fail elegantly and prevent the whole device being bricked?

推荐答案

在我比赛的情况下，waitForCondition问题已经注意到了三星Galaxy S（安卓2.3.3）。当然，我不知道这个问题已经被注意到在不同的设备，但可能存在有太多的问题。幸运的是我能够重现它作为我的一个朋友已经拿到了设备，他还跟借给我了一个星期。 在我的情况下，比赛几乎全部用Java编写的（通过NDK几个电话OpenGL函数），所以我真的不知道这是否会适用于您的问题太多。

反正它似乎问题以某种方式与OpenGL的内部缓冲区。在psented低于已被注释掉（1）已更改为（​​2）该行的code $ P $ - 手动配置的选择。我没有测试它彻底呢，但因为这种变化我还没有发现任何结冰，所以有希望..

更新1：作为一个额外的信息，我想我听说有人有同样的问题，他的CPU被盯住他的解决办法是设置所有的OpenGL表面成分为8位（alpha分量太），而不是565或4位（我不记得什么是错误的配置）

更新2：的也可以考虑使用EGLConfigChooser以下实现：<一href="http://libgdx.google$c$c.com/svn-history/r2518/trunk/backends/gdx-backend-android/src/com/badlogic/gdx/backends/android/surfaceview/GdxEglConfigChooser.java"相对=nofollow> GdxEglConfigChooser.java 。如果这没有帮助，最终使用的方法presented在<一个href="http://$c$c.google.com/p/libgdx/source/browse/trunk/backends/gdx-backend-android/src/com/badlogic/gdx/backends/android/surfaceview/GLSurfaceView20.java?r=2518"相对=nofollow> GLSurfaceView20.java 。

更新3：此外简化程序着色器一样，因为它可能有助于有点太

In the case of my game the "waitForCondition" problem has been noticed on Samsung Galaxy S (Android 2.3.3). Of course I don't know if the issue has been noticed on different devices, but probably the problem exists there too. Fortunately I was able to reproduce it as one of my friends has got the device and he was kind enough to lent me one for a week. In my case the game is practically all written in Java (few calls through NDK to OpenGL functions), so I'm not really sure if this will apply to your problem too.

Anyway it seems that the problem is somehow related to OpenGL internal buffers. In the code presented below the line which has been commented out (1) has been changed to (2) - manual config selection. I didn't test it thoroughly yet, but since that change I haven't noticed any freezes, so there is a hope..

UPDATE 1: As an additional info, I think I read somewhere that somebody had the same problem with his CPU gets pegged and his solution was to set up all the OpenGL Surface components to 8 bits (alpha component too) rather than 565 or 4 bits (I don't remember exactly what was the faulty configuration)

UPDATE 2: Also one may consider to use the following implementation of the EGLConfigChooser: GdxEglConfigChooser.java. If this doesn't help eventually use the approach presented in GLSurfaceView20.java.

UPDATE 3: Additionally simplifying the program shaders as much as it's possible helped a bit too.

// in Activity...
glView = new GLSurfaceView(this);
glView.setEGLContextClientVersion(2); // OpenGL ES 2.0
//      glView.setEGLConfigChooser(false); // (1) false - no depth buffer
glView.getHolder().setFormat(PixelFormat.TRANSLUCENT);
glView.setEGLConfigChooser(8,8,8,8,0,0); // (2) TODO: crashes on devices which doesn't support this particular configuration
glView.setRenderer(new MyRenderer(this));

这篇关于Android的＆QUOT; CPU可挂＆QUOT;错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！