Android Crash Report related to libGLESv2_POWERVR_SGX540_120.so

PowerVR Insider
1

Hello,

We are working on Criminal Case Android (http://goo.gl/5fkXnn) and we are receiving more and more crash reports related to libGLESv2_POWERVR_SGX540_120.so mostly on Samsung GTP3110, GT P5110 and GTP5100.

[pre]SIGSEGV SEGV_MAPERR at 0x00000014
0 libsrv_um_SGX540_120.so 0x4168de18 PVRSRVLockMutex
1 libGLESv2_POWERVR_SGX540_120.so 0x57907214 glBindFramebuffer[/pre]

Without the source code it’s really hard to make sense of this stacktrace. Maybe one of you could put us in the right direction to fix this recurring bug in our code.

Thanks

2

To give you as much details as possible we weren’t able to reproduce the bug with our device however thanks to crashlytics’ unwind library we are able to collect details but not as precise as the driver used as you can see in the screenshot attached.

3

A reproduction of the bug and a driver version of the device in question would help most, and then capturing a trace of the crash would allow us identify the issue.

4

You will find below more details about the only crash we had but unfortunately we didn’t recovered the tombstone from logcat. We’ll try to reproduce it on monday.

GPU DRIVER VERSION:
gl.renderer: PowerVR SGX 540
gl.version: OpenGL ES 2.0 build 1.9.RC2@2139099

STACK TRACE:
Thread : Crashed: Thread
0  libsrv_um_SGX540_120.so            0x41616e18 PVRSRVLockMutex
1  libGLESv2_POWERVR_SGX540_120.so    0x51774214 glBindFramebuffer

Moreover you will find attached in the zip the 2 .so files from to the device

5

We managed to reproduce the crash in another device. Below is all the info we could grab from this issue (also see attached crash tombstone as well as the device libs that present the issue).

[pre]STACK TRACE:
Build fingerprint: 'lge/vee5nfc_open_eu/vee5nfc:4.1.2/JZO54K/9f7a8d40f7:user/release-keys’
pid: 8369, tid: 8385, name: Thread-951 >>> com.prettysimple.criminalcaseandroid <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000014

Stack frame #00 pc 0000b804 /system/vendor/lib/libsrv_um.so (PVRSRVLockMutex+8)

Stack frame #01 pc 0001388c /system/vendor/lib/egl/libGLESv2_mtk.so (glBindFramebuffer+272)
[/pre]

GLES info:
Imagination Technologies, PowerVR SGX 531, OpenGL ES-CM 1.1
Renderer: PowerVR SGX 531
Version: OpenGL ES 2.0 build 1.8@2116011
Device info:
model=LG-E460
brand=lge
name=vee5nfc_open_eu
device=vee5nfc
board=mt6575
cpu.abi=armeabi-v7a
cpu.abi2=armeabi
manufacturer=LGE

6

Are there any errors reported by glGetError prior to the crash?

If you can capture a PVRTrace recording of the crash occurring, we’ll see what we can find.

If necessary, create a ticket on our support portal and you can attach the trace confidentially: https://pvrsupport.imgtec.com/new-ticket

7

Ever since we originally posted this issue we’ve continued our research and tried to understand the cause for it.

We ran PVRTrace to find out exactly what was happening in our app (PVRTrace session where the issue occurs can be downloaded here https://drive.google.com/file/d/0B-vdY4dg0gQMazU2YmtndUN2d2c/view?usp=sharing) which gave us the impression that we were simply running out of memory. However after further testing this seems not to be the case. The problem stems from the creation of too many FBO’s in the spam of one draw cycle.

We found this post (https://www.imgcommunity.local/forums/topic/glcheckframebufferstatus-returns-gl_framebuffer_unsupported-when-creating-too-many-fbo/) that seems to point to this issue being related to a hardware limitation, but we fear this is not the case as the exact same code is running on iOS devices supporting the exact same hardware without any issues.

Could you please look through this log and maybe shed some light on this subject?

GLES info:
Imagination Technologies, PowerVR SGX 531, OpenGL ES-CM 1.1
Renderer: PowerVR SGX 531
Version: OpenGL ES 2.0 build 1.8@2116011
Device info:
model=LG-E460
brand=lge
name=vee5nfc_open_eu
device=vee5nfc
board=mt6575
cpu.abi=armeabi-v7a
cpu.abi2=armeabi
manufacturer=LGE

PS: There seems to be a small issue with your forum’s post system. Even though it states that anchor HTML tags are valid, submiting a post with them will refresh the page as if the post was correctly submited with no error report whatsoever but the post isn’t actually submited. I had to default to url tags. Also when attempting to re-submit the same post it’ll report that the post is a duplicate even though its previous submission apparently failed.

8

Hi Fernando,

[blockquote]but we fear this is not the case as the exact same code is running on iOS devices[/blockquote]
Apple’s driver behaviour is different to our own. I suspect that’s where the limitation lies.

[blockquote]PS: There seems to be a small issue with your forum’s post system.[/blockquote]
We’re aware of the issue and reported it to our web team a few weeks ago. I’ll ping them again to see if this can be resolved.

Thanks for sharing your recording with us. We’ll take a look at it and will aim to follow up with you soon.

9

Fernando,

From the trace you provided it looks like you are rendering several blocks of text as individual framebuffer objects. This can become very memory-expensive, and in this case it is hitting the driver defined allocation limit.