Crash deep in OpenGL (!!)

323 views
Skip to first unread message

Tim Mensch

unread,
Jun 14, 2011, 11:05:37 PM6/14/11
to android-ndk
Hi all,

I was wondering if anyone else has seen this; on my Milestone (running
2.1) I get a crash every so often deep in OpenGL code. I have to play
the game for several minutes to see it, and when it does happen the call
stack is worthless (pasted below).

If anyone has seen this before, please let me know, whether or not you
found the issue. I haven't tested other platforms yet (it takes a while
to reproduce regardless), and I'll dig for it brute force if necessary,
but considering it's so hard to repro I'm hoping for hints to save a bit
of time. :)

Tim

The log: (there's nothing interesting prior to this in the log from the
rendering thread at all -- just the standard messages printed by other
bits of my code at various times and in other threads)

06-14 20:52:29.391 I/DEBUG (19277): *** *** *** *** *** *** *** ***
*** *** *** *** *** *** *** ***
06-14 20:52:29.399 I/DEBUG (19277): Build fingerprint:
'MOTO_WIND/umts_sholes/umts_sholes/sholes:2.1-update1/SHOLS_U2_02.38.0/6904598:user/rel-keys'
06-14 20:52:29.399 I/DEBUG (19277): pid: 19463, tid: 19632 >>>
com.quickcharge.hamster.free <<<
06-14 20:52:29.399 I/DEBUG (19277): signal 11 (SIGSEGV), fault addr
4772b138
06-14 20:52:29.399 I/DEBUG (19277): r0 431ba3d4 r1 4772b138 r2
00000014 r3 0000000c
06-14 20:52:29.399 I/DEBUG (19277): r4 00a508c0 r5 00a51724 r6
00000002 r7 00000004
06-14 20:52:29.399 I/DEBUG (19277): r8 00000014 r9 00000001 10
00000004 fp 00000001
06-14 20:52:29.399 I/DEBUG (19277): ip 80000000 sp 47e46bb8 lr
81306a44 pc afe0df48 cpsr a8000050
06-14 20:52:30.188 I/DEBUG (19277): #00 pc 0000df48
/system/lib/libc.so
06-14 20:52:30.188 I/DEBUG (19277): #01 lr 81306a44
/system/lib/egl/libGLESv1_CM_POWERVR_SGX530_121.so
06-14 20:52:30.188 I/DEBUG (19277):
06-14 20:52:30.188 I/DEBUG (19277): code around pc:
06-14 20:52:30.188 I/DEBUG (19277): afe0df38 24c0c001 24c0e001
e1b0ce83 aa000001
06-14 20:52:30.188 I/DEBUG (19277): afe0df48 f4a1030d f480031d
3a000001 f421070d
06-14 20:52:30.188 I/DEBUG (19277): afe0df58 f400071d f5d1f000
f5d1f040 e2522040
06-14 20:52:30.188 I/DEBUG (19277):
06-14 20:52:30.188 I/DEBUG (19277): code around lr:
06-14 20:52:30.188 I/DEBUG (19277): 81306a34 e59c102c e59c2024
e1a0e00f e59cf034
06-14 20:52:30.188 I/DEBUG (19277): 81306a44 e2866001 e2855004
e5942eb0 e3a03001
06-14 20:52:30.188 I/DEBUG (19277): 81306a54 e1560002 3affffec
e2840d77 e1a01008
06-14 20:52:30.188 I/DEBUG (19277):
06-14 20:52:30.188 I/DEBUG (19277): stack:
06-14 20:52:30.188 I/DEBUG (19277): 47e46b78 00000000
06-14 20:52:30.188 I/DEBUG (19277): 47e46b7c 00000000
06-14 20:52:30.188 I/DEBUG (19277): 47e46b80 00000000
06-14 20:52:30.196 I/DEBUG (19277): 47e46b84 00a508c0 [heap]
06-14 20:52:30.196 I/DEBUG (19277): 47e46b88 eeeeeeef
06-14 20:52:30.196 I/DEBUG (19277): 47e46b8c 4772b138
06-14 20:52:30.196 I/DEBUG (19277): 47e46b90 0063b7c4 [heap]
06-14 20:52:30.196 I/DEBUG (19277): 47e46b94 00983078 [heap]
06-14 20:52:30.196 I/DEBUG (19277): 47e46b98 00000000
06-14 20:52:30.196 I/DEBUG (19277): 47e46b9c 00a508c0 [heap]
06-14 20:52:30.196 I/DEBUG (19277): 47e46ba0 00a5171c [heap]
06-14 20:52:30.196 I/DEBUG (19277): 47e46ba4 00000000
06-14 20:52:30.196 I/DEBUG (19277): 47e46ba8 00000004
06-14 20:52:30.196 I/DEBUG (19277): 47e46bac 00000014
06-14 20:52:30.196 I/DEBUG (19277): 47e46bb0 df002777
06-14 20:52:30.196 I/DEBUG (19277): 47e46bb4 e3a070ad
06-14 20:52:30.196 I/DEBUG (19277): #00 47e46bb8 431ba3d4 /dev/pvrsrvkm
06-14 20:52:30.196 I/DEBUG (19277): 47e46bbc 81306a44
/system/lib/egl/libGLESv1_CM_POWERVR_SGX530_121.so
06-14 20:52:30.196 I/DEBUG (19277): 47e46bc0 00a508c0 [heap]
06-14 20:52:30.196 I/DEBUG (19277): 47e46bc4 00000004
06-14 20:52:30.196 I/DEBUG (19277): 47e46bc8 00000004
06-14 20:52:30.196 I/DEBUG (19277): 47e46bcc 00000000
06-14 20:52:30.204 I/DEBUG (19277): 47e46bd0 00000006
06-14 20:52:30.204 I/DEBUG (19277): 47e46bd4 81308404
/system/lib/egl/libGLESv1_CM_POWERVR_SGX530_121.so
06-14 20:52:30.204 I/DEBUG (19277): 47e46bd8 00a508c0 [heap]
06-14 20:52:30.204 I/DEBUG (19277): 47e46bdc 8136a5e4
/system/lib/egl/libGLESv1_CM_POWERVR_SGX530_121.so
06-14 20:52:30.204 I/DEBUG (19277): 47e46be0 00000004
06-14 20:52:30.204 I/DEBUG (19277): 47e46be4 00000000
06-14 20:52:30.204 I/DEBUG (19277): 47e46be8 00000006
06-14 20:52:30.204 I/DEBUG (19277): 47e46bec 813098b0
/system/lib/egl/libGLESv1_CM_POWERVR_SGX530_121.so
06-14 20:52:30.204 I/DEBUG (19277): 47e46bf0 00000004
06-14 20:52:30.204 I/DEBUG (19277): 47e46bf4 00000000
06-14 20:52:30.204 I/DEBUG (19277): 47e46bf8 00000000
06-14 20:52:30.204 I/DEBUG (19277): 47e46bfc 00000000
06-14 20:52:32.391 D/dalvikvm( 1347): GC freed 6 objects / 208 bytes in
111ms
06-14 20:52:33.071 I/ActivityManager( 1283): Process
com.quickcharge.hamster.free (pid 19463) has died.

Gregory Ray

unread,
Jun 14, 2011, 11:31:23 PM6/14/11
to andro...@googlegroups.com
Based that it's crashing in the PVR system, if I was to take a stab in the dark I would say you might be loading textures in mid gameplay and running out of a memory.


--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.




--
Gregory Ray
Co-founder, Seek Mobile Interactive, Inc.

---

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

Tim Mensch

unread,
Jun 14, 2011, 11:52:28 PM6/14/11
to andro...@googlegroups.com
Thanks, that's a reasonable guess -- I'll try ensuring all textures are preloaded and see what happens (it may crash instantly, of course, but having it crash sooner is better than having it crash after 10 minutes... ;).

Tim

Olivier Guilyardi

unread,
Jun 15, 2011, 6:22:31 AM6/15/11
to andro...@googlegroups.com
On 06/15/2011 05:05 AM, Tim Mensch wrote:

> 06-14 20:52:30.188 I/DEBUG (19277): #00 pc 0000df48
> /system/lib/libc.so
> 06-14 20:52:30.188 I/DEBUG (19277): #01 lr 81306a44
> /system/lib/egl/libGLESv1_CM_POWERVR_SGX530_121.so

Have you tried addr2line? Eg:

$ adb pull /system/lib/libc.so
$ adb pull /system/lib/egl/libGLESv1_CM_POWERVR_SGX530_121.so
$ arm-linux-androideabi-addr2line -f -e libc.so 0000df48
$ arm-linux-androideabi-addr2line -f -e libGLESv1_CM_POWERVR_SGX530_121.so 81306a44

--
Olivier

Tim Mensch

unread,
Jun 15, 2011, 2:35:37 PM6/15/11
to andro...@googlegroups.com
On 6/15/2011 4:22 AM, Olivier Guilyardi wrote:
> Have you tried addr2line? Eg:

I hadn't, but sure, why not:

tim@Panther /c/Users/tim/projects/games/HamsterAttack
$
/f/Devel/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/arm-linux-androideabi-addr2line.exe
-f -e libc.so 0000df48
memcpy
??:0

tim@Panther /c/Users/tim/projects/games/HamsterAttack
$
/f/Devel/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/arm-linux-androideabi-addr2line.exe


arm-linux-androideabi-addr2line -f -e libGLESv1_CM_POWERVR_SGX530_121.so
81306a44

??
??:0
??
??:0

So it was in a memcpy(), but we can't tell much else. Could be that
Gregory was right and it ran out of memory, or it could be that there's
a threading bug where loading graphics at runtime can occasional barf.
In either case, if I preload my graphics, it will either crash less (if
the problem is threading) or immediately (if I'm running out of memory).
So I'll try preloading and see what happens. :)

If you have any other thoughts, though, let me know.

Tim

Tim Mensch

unread,
Jun 16, 2011, 3:05:49 AM6/16/11
to andro...@googlegroups.com
On 6/14/2011 9:31 PM, Gregory Ray wrote:
> Based that it's crashing in the PVR system, if I was to take a stab in
> the dark I would say you might be loading textures in mid gameplay and
> running out of a memory.

I now preallocate all of the textures I'm using (I'm pretty sure, at
least). If I were wrong, I should see a log message right before the
crash: Just before I load a texture into OpenGL, I print out its newly
allocated texture ID. So unless glGenTextures( 1, &texture ) is what's
crashing (and why would glGenTextures use the PVR subsystem?), it
doesn't appear to be that it's running out of memory. :(

I've added an extra log statement before glGenTextures "just in case",
but I doubt that's the issue. Doesn't cost me anything to add the log
statement, though.

Any other guesses? This time I had to play through 24 levels to get it
to crash, but the crash dump was basically the same as last time. :(

It could still be memory-related, though. About four seconds AFTER the
crash I saw this both times:

06-15 23:13:15.459: INFO/ActivityManager(1283): Low Memory: No more
background processes.

I used to see that before a lot more often -- until I killed a bad
memory leak. And it didn't seem to ever cause a crash then. At this
point I'm beginning to wonder if ANOTHER app is doing something that's
asking for RAM and causing this problem; playing through several levels
on Windows (where I can watch the RAM usage) shows it holding steady. I
can look at ways of reducing my overall footprint, though it's a
trade-off with user experience when I have to reload any textures I
discard after they're loaded. About a half second before the crash (this
time) I see "AudioHardwareMot -- AudioMgr:Output 0xb538 exiting
standby", but nothing else that seems related.

Thoughts? My next approach will be to reduce runtime memory usage, to
see if that helps, but if anyone has another thought I'm all ears.

Tim

Colin Knapp

unread,
Jun 16, 2011, 8:52:36 AM6/16/11
to andro...@googlegroups.com

Hey does your app use multithreading? If it does maybe you have a process that is just sitting there spinning it's wheels, eating memory? Are you clearing the video buffer at all or are the previous level textures just inadvertently not being purged?

Not much open gl experience but normal development frequently has memory issues.

Tim Mensch

unread,
Jun 16, 2011, 1:01:07 PM6/16/11
to andro...@googlegroups.com
I do have threads, and I've been trying to figure out if I have a thread conflict, but nothing is eating memory while it spins. The threads are in C++, and they sleep a bit each time through the loop, so they should be friendly.

What I have is a "worker" thread that (in theory) never touches OpenGL, and a "renderer" thread that just draws the screen (this is the thread started by GLSurfaceView). There are two draw queues so the worker can be filling one while the renderer is drawing the other. When my renderer is called, it:

1. Grabs a copy of the "queueToDraw" variable
2. Toggles the local copy from 0->1 or 1->0
3. Spins on a loop that looks like this:
    while (1)
    {
        {
            qcMutexHold queueMutex(gSysData.queueMutex);
    
            if (queueToDraw!=gSysData.currentQueue)
            {
                gSysData.queueToDraw = queueToDraw;
                break;
            }
        } // release mutex, then sleep, then try again

        // bail if we've been deactivated
        if (!m_active)
        {
            return ;
        }

        usleep(800); 
    }
So it only starts drawing after the main thread has had a chance to toggle currentQueue. On the other side, in update, it does this:
    {
        qcMutexHold queueMutex(gSysData.queueMutex);
        gSysData.currentQueue ++;
        if (gSysData.currentQueue == qcSysData::kNumQueues)
        {
            gSysData.currentQueue = 0;
        }
    }

    // If we've gotten ahead of the draw loop, then block
    // here while we wait for the draw queue to advance.

    while (gSysData.currentQueue == gSysData.queueToDraw)
    {
        // bail if we've been deactivated
        if (!m_active)
        {
            return ;
        }
        usleep(400);
    }
In other words, it immediately toggles the currentQueue and then waits for queueToDraw to be updated. I've considered using a system based on a semaphore, so the renderer can simply block waiting for the main thread to be ready, but it's not been high on my priority list compared to other issues, and one or the other side would still need to block and spin... Regardless, I'm pretty sure the problem isn't here. There may be performance problems associated with the above code, but I can't see how either of those could cause a crash deep in OpenGL.

Clearing the video buffer doesn't save any memory; it just sets all the pixels to the same color. I have verified that I release textures back to GL when I no longer need them. And I also watched the actual memory usage of the same game on Windows, and it stays pretty constant (there's some variation, because I use Lua and Lua is garbage-collected, but it stays in the same range for multiple levels).

My current going theories are:

1. Undiagnosed threading issue (OpenGL has a bad habit of crashing if you try to shut it down from another thread, for example, and though that issue isn't happening this time around, it could be something similar).

2. Android is deciding to kill the app over memory usage, and it's either a coincidence that it's crashing in GL in the same place (in a memcpy), or it's due to the nature of how the memory usage is being killed. It's a SEGV on what looks like a reasonable memory pointer, so it could be trying to swap out some memory, for example?

3. I'm doing something marginal SOMEWHERE that's causing OpenGL to barf in a memory-corruption way, and it just takes a while to surface (I had a problem with bad normals a while back that would cause an intermittent crash in DirectX when the "normalize normals" option was enabled, for example).

4. I have a really subtle memory corruption bug that either never happens on Windows, or does so in such a way that the built-in methods don't detect it (Visual Studio has relatively good barriers in place for such errors -- checking deallocated heap memory for modifications, for example, and checking of buffer boundaries to see if you're overrunning a buffer).

5. It's a bona-fide OpenGL bug in the Milestone OpenGL driver that I'm hitting, for whatever reason: my particular combination of textures, or my particular usage of GL calls, or whatever. I've seen drivers bugs in DirectX, for example, where if you alternate using indexed and non-indexed draw calls, some draws will simply fail. Sometimes intermittently. I guess most games tend to use all of one or the other? Intel video cards are the worst for driver bugs, if anyone cares... :)

Let me know if I missed anything. :)

Tim

Tim Mensch

unread,
Jun 18, 2011, 11:24:04 PM6/18/11
to andro...@googlegroups.com
If anyone knows how to get the "native" tab in DDMS to actually spit out
something useful, please let me know. Does it only work on rooted
devices? When I try on the emulator, it typically crashes, and I don't
have any unlocked devices handy. :/

Are there any docs anywhere on how to make it work, on the emulator or
otherwise?

Tim

a1

unread,
Jun 19, 2011, 6:10:18 AM6/19/11
to andro...@googlegroups.com
I'd say that both stacktrace (only two calls with start point in opengl implementation?) and address 0x81306a44 looks suspicious and by suspicious I mean invalid :). So most plausible hypothesis are: invalid buffer access on stack variable ending in stack corruption, call through pointer with invalid pointer (much less likely since usually it will leave some traces, 'random' memory corruption ie. in some place due to bug you are writing to 'random' address.

--
Bart

Tim Mensch

unread,
Jun 19, 2011, 12:57:57 PM6/19/11
to andro...@googlegroups.com
On 6/19/2011 4:10 AM, a1 wrote:
I'd say that both stacktrace (only two calls with start point in opengl implementation?) and address 0x81306a44 looks suspicious and by suspicious I mean invalid :). So most plausible hypothesis are: invalid buffer access on stack variable ending in stack corruption, call through pointer with invalid pointer (much less likely since usually it will leave some traces, 'random' memory corruption ie. in some place due to bug you are writing to 'random' address.

The address 0x81306a44 is solidly in my library -- I even get a valid function when I do addr2line -- but thanks for the input.

The stacktrace beginning in OpenGL is not that unusual -- sometimes system libraries are built with optimizations that mess up a stack trace. In fact, I have another trace now from a different phone that shows the calls all the way up to my library (see below), and I was able to narrow it down to a particular call (glDrawArrays) that it always crashes on, on both platforms.

It's looking like a threading issue at this point, which means I probably need to clean up all my communication between threads. This is the one place I'd like to be using a language like Erlang that lets me send read-only packets from one thread to another, so I don't need to worry about them being modified (or worse, deleted; I see a "/dev/zero (deleted)" reference below that implies a pointer to a deleted item? Not sure what else that would mean).

Tim

06-18 19:54:55.092 28412 28412 I DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
06-18 19:54:55.092 28412 28412 I DEBUG   : Build fingerprint: 'VirginMobile/LGE/thunderc/thunderc:2.2.1/FRG83/eng.lge.20101213.204043:user/release-keys'
06-18 19:54:55.092 28412 28412 I DEBUG   : pid: 26656, tid: 26665  >>> com.quickcharge.hamster <<<
06-18 19:54:55.092 28412 28412 I DEBUG   : signal 11 (SIGSEGV), fault addr 4c84a9e8
06-18 19:54:55.092 28412 28412 I DEBUG   :  r0 492955a0  r1 4c84a9e8  r2 fffffff0  r3 00000000
06-18 19:54:55.092 28412 28412 I DEBUG   :  r4 00000000  r5 000015a0  r6 00002000  r7 002b04e8
06-18 19:54:55.092 28412 28412 I DEBUG   :  r8 815cb020  r9 00000000  10 00060000  fp fffa0000
06-18 19:54:55.092 28412 28412 I DEBUG   :  ip 00000000  sp 4896b8e0  lr 818027bc  pc afd0f178  cpsr 60000010
06-18 19:54:55.162 28412 28412 I DEBUG   :          #00  pc 0000f178  /system/lib/libc.so
06-18 19:54:55.162 28412 28412 I DEBUG   :          #01  pc 000027b8  /system/lib/libgsl.so
06-18 19:54:55.162 28412 28412 I DEBUG   :          #02  pc 00080498  /system/lib/egl/libGLESv2_adreno200.so
06-18 19:54:55.162 28412 28412 I DEBUG   :          #03  pc 00087690  /system/lib/egl/libGLESv2_adreno200.so
06-18 19:54:55.162 28412 28412 I DEBUG   :          #04  pc 0005e84e  /system/lib/egl/libGLESv2_adreno200.so
06-18 19:54:55.162 28412 28412 I DEBUG   :          #05  pc 0006119c  /system/lib/egl/libGLESv2_adreno200.so
06-18 19:54:55.162 28412 28412 I DEBUG   :          #06  pc 0007a032  /system/lib/egl/libGLESv2_adreno200.so
06-18 19:54:55.162 28412 28412 I DEBUG   :          #07  pc 0001384e  /system/lib/egl/libGLESv1_CM_adreno200.so
06-18 19:54:55.172 28412 28412 I DEBUG   :          #08  pc 0001b2d6  /system/lib/egl/libGLESv1_CM_adreno200.so
06-18 19:54:55.172 28412 28412 I DEBUG   :          #09  pc 00094eb4  /data/data/com.quickcharge.hamster/lib/libhamster.so
06-18 19:54:55.172 28412 28412 I DEBUG   :          #10  pc 000df0f0  /data/data/com.quickcharge.hamster/lib/libhamster.so
06-18 19:54:55.172 28412 28412 I DEBUG   :          #11  pc 0009346c  /data/data/com.quickcharge.hamster/lib/libhamster.so
06-18 19:54:55.172 28412 28412 I DEBUG   :
06-18 19:54:55.172 28412 28412 I DEBUG   : code around pc:
06-18 19:54:55.172 28412 28412 I DEBUG   : afd0f158 e2522020 849c3020 e8a00ff0 2afffff9
06-18 19:54:55.172 28412 28412 I DEBUG   : afd0f168 e2822020 e312001f 0a00000c e1b0ce02
06-18 19:54:55.172 28412 28412 I DEBUG   : afd0f178 28b100f0 48b10300 28a000f0 48a00300
06-18 19:54:55.172 28412 28412 I DEBUG   : afd0f188 e1b0cf02 24913004 40d140b2 24803004
06-18 19:54:55.172 28412 28412 I DEBUG   : afd0f198 40c040b2 e3120001 15d13000 15c03000
06-18 19:54:55.172 28412 28412 I DEBUG   :
06-18 19:54:55.172 28412 28412 I DEBUG   : code around lr:
06-18 19:54:55.172 28412 28412 I DEBUG   : 8180279c e5906008 e0831001 e1510006 8a000006
06-18 19:54:55.172 28412 28412 I DEBUG   : 818027ac e5903000 e1a0100e e0830005 eb0009be
06-18 19:54:55.172 28412 28412 I DEBUG   : 818027bc e1a00004 e28dd008 e8bd8070 e59f104c
06-18 19:54:55.172 28412 28412 I DEBUG   : 818027cc e59fe04c e1a02005 e79c0001 e08c100e
06-18 19:54:55.172 28412 28412 I DEBUG   : 818027dc e58d6000 e28000a8 ebffff44 e3e00000
06-18 19:54:55.172 28412 28412 I DEBUG   :
06-18 19:54:55.172 28412 28412 I DEBUG   : stack:
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8a0  00000000 
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8a4  00060000  [heap]
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8a8  818090d8  /system/lib/libgsl.so
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8ac  00000010 
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8b0  0029e3f8  [heap]
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8b4  4896b8c4 
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8b8  00000002 
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8bc  80080911  /system/lib/libicudata.so
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8c0  afd41928  /system/lib/libc.so
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8c4  afd0fc58  /system/lib/libc.so
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8c8  afd41928  /system/lib/libc.so
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8cc  afd0fcb0  /system/lib/libc.so
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8d0  00004000 
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8d4  00000000 
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8d8  e3a070ad 
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8dc  ef9000ad 
06-18 19:54:55.172 28412 28412 I DEBUG   : #00 4896b8e0  000015a0 
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8e4  00002000 
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8e8  002b04e8  [heap]
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8ec  815cb020 
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8f0  00000000 
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8f4  00060000  [heap]
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8f8  fffa0000 
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b8fc  492955a0  /dev/zero (deleted)
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b900  00000000 
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b904  818027bc  /system/lib/libgsl.so
06-18 19:54:55.172 28412 28412 I DEBUG   : #01 4896b908  00000003 
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b90c  007ee458  [heap]
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b910  007ee458  [heap]
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b914  00000001 
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b918  004ccad8  [heap]
06-18 19:54:55.172 28412 28412 I DEBUG   :     4896b91c  81a8049b  /system/lib/egl/libGLESv2_adreno200.so


Tim

Turk

unread,
Dec 4, 2012, 8:30:38 PM12/4/12
to andro...@googlegroups.com
I am getting a crash in the same place. I have a video playback application, where I pre-allocate three ALPHA textures, one each for Y, U, and V, and upload data to them 30-60 frames per second. The textures are uploaded before all drawing, and drawing is punctuated by a swap buffers. Then the upload cycle begins again.

I don't see how it could be running out of memory, since the textures are allocated once. I use glTexSubImage2D() to do th eupload.

I/DEBUG   (11875):     beacb450  80103f50  /system/lib/libgsl.so
I/DEBUG   (11875):     beacb454  c00c0923  
I/DEBUG   (11875):     beacb458  beacb474  [stack]
I/DEBUG   (11875):     beacb45c  0000000c  
I/DEBUG   (11875):     beacb460  ffffffff  
I/DEBUG   (11875):     beacb464  00000000  
I/DEBUG   (11875):     beacb468  00000001  
I/DEBUG   (11875):     beacb46c  8049cc15  /system/lib/egl/libGLESv2_adreno200.so
I/DEBUG   (11875):     beacb470  008fb5b8  [heap]
I/DEBUG   (11875):     beacb474  66631000  
I/DEBUG   (11875):     beacb478  408ce000  /dev/zero (deleted)
I/DEBUG   (11875):     beacb47c  00000001  
I/DEBUG   (11875):     beacb480  00000020  
I/DEBUG   (11875):     beacb484  00000001  
I/DEBUG   (11875):     beacb488  df002777  
I/DEBUG   (11875):     beacb48c  e3a070ad  
I/DEBUG   (11875): #00 beacb490  408ce000  /dev/zero (deleted)
I/DEBUG   (11875):     beacb494  8048d13d  /system/lib/egl/libGLESv2_adreno200.so
I/DEBUG   (11875): #01 beacb498  008fb3f8  [heap]
I/DEBUG   (11875):     beacb49c  00000140  
I/DEBUG   (11875):     beacb4a0  008fb3f8  [heap]
I/DEBUG   (11875):     beacb4a4  00000001  
I/DEBUG   (11875):     beacb4a8  00000001  
I/DEBUG   (11875):     beacb4ac  80489e81  /system/lib/egl/libGLESv2_adreno200.so
I/DEBUG   (11875):     beacb4b0  0001f000  /data/local/tmp/GL2Test
I/DEBUG   (11875):     beacb4b4  00000001  
I/DEBUG   (11875):     beacb4b8  fffff050  
I/DEBUG   (11875):     beacb4bc  fffff37c  
I/DEBUG   (11875):     beacb4c0  0053dbc4  [heap]
I/DEBUG   (11875):     beacb4c4  00000001  
I/DEBUG   (11875):     beacb4c8  008fb690  [heap]
I/DEBUG   (11875):     beacb4cc  805c5e54  /system/lib/egl/libGLESv2_adreno200.so
I/DEBUG   (11875):     beacb4d0  00000000  
I/DEBUG   (11875):     beacb4d4  8049c935  /system/lib/egl/libGLESv2_adreno200.so
I/DEBUG   (11875):     beacb4d8  beacb508  [stack]
I/DEBUG   (11875):     beacb4dc  008fb3f8  [heap]
I/DEBUG   (11875):     beacb4e0  beacb508  [stack]
I/DEBUG   (11875):     beacb4e4  0053dbc0  [heap]
I/DEBUG   (11875):     beacb4e8  008fb3f8  [heap]
I/DEBUG   (11875):     beacb4ec  00000000  
I/DEBUG   (11875):     beacb4f0  beacb508  [stack]
I/DEBUG   (11875):     beacb4f4  0053dbc0  [heap]
I/DEBUG   (11875):     beacb4f8  008fb3f8  [heap]
I/DEBUG   (11875):     beacb4fc  8048d2d1  /system/lib/egl/libGLESv2_adreno200.so

Gavin Kinsey

unread,
Dec 5, 2012, 8:35:42 AM12/5/12
to andro...@googlegroups.com
On Wednesday 05 December 2012 01:30:38 Turk wrote:
> I am getting a crash in the same place. I have a video playback
> application, where I pre-allocate three ALPHA textures, one each for Y,
> U, and V, and upload data to them 30-60 frames per second. The textures
> are uploaded before all drawing, and drawing is punctuated by a swap
> buffers. Then the upload cycle begins again.
>
> I don't see how it could be running out of memory, since the textures are
> allocated once. I use glTexSubImage2D() to do th eupload.

Are you using powers of two textures? I found that some devices that claim
to support NPoT textures occasionally over read the buffers if you actually
try to use them. I implemented a blacklist to force my code to use PoT code
paths for those devices. It's probably buggy drivers and not the actual GPU
but just going off the GL_RENDERER is easier so I use that.

My current blacklist is "Adreno 200" and "Adreno 205".

--
Gavin Kinsey
AD Holdings Plc


--------------------------------------------------------
This email and any files transmitted with it are CONFIDENTIAL and intended solely for the use of the individual or entity to whom they are addressed. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system; you may not copy this message or disclose its contents to anyone. The recipient should check this email and any attachments for the presence of viruses. The Company accepts no liability for any damage caused by any virus transmitted by this email. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the Company. Contact Customer Services for details customer...@dmicros.com
Reply all
Reply to author
Forward
0 new messages