Been investigating a freeze in our app, that randomly occurs on a specific device when rendering a specific object, and had discovered what looks like a deliberate dead loop that the driver might conditionally invoke inside the libGLESv2 library. The casue is not clear, as the app does not freese on other devices, including those with PowerVR GPU, and there appears to be no relevant diagnostic messages in the log prior to the freeze. I can however provide the exact call stack and the point inside the library where the dead loop is implemented, and looking for someone with enough insight into internal logic of the driver to help me figure out why it would opt to freeze, and then hopefully how to work around that.
Shared library info:
ELF 32-bit LSB shared object
version 1 (SYSV)
frame #0: 0x632038a5 libGLESv2_POWERVR_SGX540_121.so.1.9.2188537`USPInstBlockFinaliseInsts + 2069 frame #1: 0x631fc1ee libGLESv2_POWERVR_SGX540_121.so.1.9.2188537`FinaliseInstructions + 62 frame #2: 0x631f6652 libGLESv2_POWERVR_SGX540_121.so.1.9.2188537`PVRUniPatchFinaliseShader + 434 frame #3: 0x631ec6bf libGLESv2_POWERVR_SGX540_121.so.1.9.2188537`SetupUSEFragmentShader + 719 frame #4: 0x631f0320 libGLESv2_POWERVR_SGX540_121.so.1.9.2188537`ValidateState + 368 frame #5: 0x631bc5ac libGLESv2_POWERVR_SGX540_121.so.1.9.2188537`glDrawElements + 380 frame #6: 0x4086ea7a libGLESv2.so`glDrawElements + 58 frame #7: 0x67cf316b libgame.so`Render::RenderDeviceGLES2::DrawIndexedPrimitives(this=<unavailable>, type=TriangleList, elements_offset=<unavailable>, elements_count=<unavailable>, indices=<unavailable>) at RenderDeviceGLES2.cpp:2262
The instruction at #0:
0x632038a5 <+2069>: jmp 0x632038a5 ; <+2069> (eb fe jmp 0x0)
(0x5A8A5 is the actual offset of the jmp 0x0 instruction inside the library) It appears to follow a call to USPInstBlockInsertHWInst() at 0x5A5B7, and lays on its non-zero return execution path.
This unfortunatelly tells me nothing about what the driver doesn’t like about our shader.
thanks for reporting this, can you please let us know what platform this is?
Can you please also send us a PVRTrace file of the problematic applicaiton?
It’s an Android device. It isn’t rooted so I don’t think I’ll be able to use tools on it.
you can use PVRTrace on other devices and you should still be able to reproduce the issue on the original one.
Yes probably, but then I don’t quite understand how that would help.
I think I might have been misunderstood. This is not a bug report. There is basically no hope that an update would reach this device, even if driver is to be fixed on your side, so a bug report wouldn’t get me anywhere.
I have a device+software specific case, a call stack, and some other bits of information already collected. What I am looking for is someone with insight into driver’s internal logic to make general sense of the behavior I’m seeing. Sure there can’t be many logical paths that would get a driver to enter a deadloop at that specific point.
we can use that file to reproduce your issue and maybe find you a workaround.
I’ll also try to find a person who has insight into that driver for you, but in the meantime can you please provide us with a PVRTrace recording?
Not very likely, at least not in the immediate future. Rooting a device is a whole another set of hoops to jump through, and it might be a while before I get a time window to work on this issue again. We don’t develop OS-level software and usually have no use for the root access.
I can provide shader sources, though they don’t appear to contain the cause and would only add to the confusion I’m afraid.
Alright, I’ll try to contact someone for you.