Question

我有一个基于OpenGL的应用程序，当用户按下按钮时，它会在本机模拟器上运行时挂起。主线程卡在glTexSubImage2D调用中，据我所知，内部正在写入连接到模拟器中某个服务器进程的套接字（QemuPipeStream :: writeFully）：

lldb) thread backtrace
* thread #1: tid = 5036, 0xb73b2706 libc.so`write + 22, name = 'foo.bar', stop reason = signal SIGSTOP
    frame #0: 0xb73b2706 libc.so`write + 22
    frame #1: 0xabf81611 libOpenglSystemCommon.so`QemuPipeStream::writeFully(void const*, unsigned int) + 97
    frame #2: 0xab8069bf libGLESv2_enc.so`??? + 273
    frame #3: 0xab7a5668 libGLESv2_emulation.so`glTexSubImage2D + 120
    frame #4: 0xa41287a2 libbeeb.so`Beeb_drawFrame + 98
    frame #5: 0xa41110d0 libbeeb.so`Java_libbeeb_BeebView_bbcDrawFrame + 32
  * frame #6: 0xa4a56765 base.odex`int libbeeb.BeebView.bbcDrawFrame() + 105 at BeebView.java:0
    frame #7: 0xa4a56ab5 base.odex`void libbeeb.BeebView.videoCallback() + 57 at BeebView.java:28
    frame #8: 0xb3a17a83 libart.so`art_quick_invoke_stub + 339
    frame #9: 0xb3a235c5 libart.so`art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*) + 213
    frame #10: 0xb3dec47d libart.so`.L1360 + 74
    frame #11: 0xb3cd3216 libart.so`art::JNI::CallVoidMethodV(_JNIEnv*, _jobject*, _jmethodID*, char*) + 589

该应用程序有点不寻常，因为它从它的主线程执行所有OpenGL渲染。这是因为它不是游戏，保持单线程比引入专用的渲染线程和相关的同步更有意义。

Answer 1

这肯定是Google / Intel的x86 Android模拟器中的一个错误，因为Genymotion或硬件上不会出现此问题。

OpenGL ES挂在x86_64仿真器上

1 个答案: