I found more details about the bug. it seems related with the information, gpus_ReturnGuiltyForHardwareRestart. after google it, it seems that there is quite limited information about this bug. Have you ever met this before and know how to solve this?


I think it is necessary for me to update what i have found about the crash.

It seems that the crashed described above is not related with subview for that after i disabled all the lines for processing the subview, the crash still happens.

The related code is as follows,

{ float scissor_x = _xMin; float scissor_y = _yMin; float scissor_w = _xAdd; float scissor_h = _yAdd; glEnable(GL_SCISSOR_TEST); glScissor(scissor_x, scissor_y, scissor_w, scissor_h); computeXY();//process some computation. glDisable(GL_SCISSOR_TEST); drawImage();//render the result computed above to the screen. _xAdd++; _yAdd++; _xAdd = (_xAdd > 300) ? 100 : _xAdd; _yAdd = (_yAdd > 300) ? 100 : _yAdd; }

The lines listed above will be called during each frame. I do not know whether there is some requirements for using glscissor(). If the value of _xAdd, _yAdd, is set as invariable, then the program goes successfully. But, if both of them are changed during each frame, the program is sure to crash after a few steps.

I really puzzled about it.

Here is the output of debugger,

(lldb) bt * thread #1: tid = 0x7262e, 0x337bc94a libGPUSupportMercury.dylib`gpus_ReturnGuiltyForHardwareRestart + 10, queue = ' thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1) frame #0: 0x337bc94a libGPUSupportMercury.dylib`gpus_ReturnGuiltyForHardwareRestart + 10


I have solved this problem. When gl_scissor() is called, you have to make sure the pixel/texel, taking part in following computation own effective values. So, before i use gl_scissor(), i will initialize all the FBO buffers to make are that all the pixels or texels own effective value.


人吐槽 人点赞



用户名: 密码:
验证码: 匿名发表