49514
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?
<hr>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 = 'com.apple.main- thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x1)
frame #0: 0x337bc94a libGPUSupportMercury.dylib`gpus_ReturnGuiltyForHardwareRestart + 10
Answer1:
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.
Thx.
