Re: Crash deep in OpenGL (!!)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Crash deep in OpenGL (!!)

Ken Turkowski
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


On Sunday, June 19, 2011 9:57:57 AM UTC-7, Tim in Boulder wrote:
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

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/android-ndk/-/MXsnT0JZdVkJ.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
Reply | Threaded
Open this post in threaded view
|

Re: Crash deep in OpenGL (!!)

Gavin Kinsey
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 [hidden email]

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