Android Crash Report related to libGLESv2_POWERVR_SGX540_120.so

Tagged: , , ,

This topic contains 8 replies, has 4 voices, and was last updated by  PaulL 2 years, 3 months ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #48591

    Mathieu
    Member

    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.

    SIGSEGV SEGV_MAPERR at 0x00000014
    0  libsrv_um_SGX540_120.so            0x4168de18 PVRSRVLockMutex
    1  libGLESv2_POWERVR_SGX540_120.so    0x57907214 glBindFramebuffer

    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

    #48633

    Mathieu
    Member

    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.

    Attachments:
    You must be logged in to view attached files.
    #48635

    PaulL
    Admin

    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.

    #48639

    Mathieu
    Member

    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

    Attachments:
    You must be logged in to view attached files.
    #48657

    Fernando
    Member

    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).

    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)
    

    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

    Attachments:
    You must be logged in to view attached files.
    #48662

    PaulL
    Admin

    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

    #49260

    Fernando
    Member

    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://community.imgtec.com/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.

    #49264

    Joe Davis
    Member

    Hi Fernando,

    but we fear this is not the case as the exact same code is running on iOS devices

    Apple’s driver behaviour is different to our own. I suspect that’s where the limitation lies.

    PS: There seems to be a small issue with your forum’s post system.

    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.

    #49310

    PaulL
    Admin

    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.

Viewing 9 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic.