Android“cpu 可能被钉住"漏洞 [英] Android "cpu may be pegged" bug

问题描述

前言:这个严重的错误会导致 Android 设备锁定(无法按 Home/Back 按钮，需要硬重置).它与 OpenGL 表面和音频播放相关联.Logcat 重复了一些事情，效果是

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

每秒一次，因此这个错误的名称.造成这种情况的根本原因可能是由于缓冲数据时出现死锁，无论是声音还是图形.

在 Asus EEE Transformer 平板电脑上测试我的应用时，我偶尔会遇到此错误.当声音线程使用 MediaPlayer.create(context, R.raw.someid); 填充 MediaPlayer 对象并加载 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 时间后播放它).如果是这样，原因在于使用上述代码的 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 帖子 指的是这个错误.他们使用 OpenGL ES 2.0 和 NDK.我使用 OpenGL ES 1.1(尽管大多数设备模拟 1.1 到 2.0，所以从技术上讲，它们使用的是 2.0)并且我不使用 NDK.此外，他们使用 Android 2.1，而我的崩溃发生在 Android 3.2.1 上.
• 本网站链接AudioTrack 对象的错误.但是，我不会在我的应用中使用它.
• Android Bug Tracker 将此列为已知错误，但目前尚无解决方案(Honeycomb+ 中未修复).

• 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+).

常用元素

• 缓冲时发生冻结.缓冲的内容通常非常大，因此通常会影响图像(图像越大，错误发生的频率越高)或音频.
• 冻结仅发生在某些设备上.
• 冻结与特定的 Android 版本无关 - 已在 2.1 和 3.2.1 等版本中记录.
• 冻结与使用 NDK 无关.
• 冻结与单一的编程实践(缓冲顺序、文件类型等)无关

我的问题很简单.这个问题有解决方法吗?如果无法阻止，有没有办法优雅地失败并防止整个设备变砖?

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?

推荐答案

在我的游戏中，三星 Galaxy S (Android 2.3.3) 出现了waitForCondition"问题.当然我不知道这个问题是否在不同的设备上被注意到了，但问题可能也存在那里.幸运的是，我能够复制它，因为我的一个朋友得到了这个设备，他很友好地借给我一个一周.在我的情况下，游戏几乎都是用 Java 编写的(很少通过 NDK 调用 OpenGL 函数)，所以我不确定这是否也适用于您的问题.

无论如何，问题似乎与OpenGL内部缓冲区有关.在下面显示的代码中，已注释掉的行 (1) 已更改为 (2) - 手动配置选择.我还没有彻底测试它，但是自从那个改变我没有注意到任何冻结，所以有希望..

更新 1: 作为附加信息，我想我在某处读到有人遇到与他的 CPU 挂钩的相同问题，他的解决方案是将所有 OpenGL Surface 组件设置为 8 位(alpha 组件也是) 而不是 565 或 4 位(我不记得究竟是什么错误配置)

更新 2: 也可以考虑使用 EGLConfigChooser 的以下实现:GdxEglConfigChooser.java.如果这没有帮助，最终使用 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“cpu 可能被钉住"漏洞的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！