[android-developers] Re: Exception Locking Canvas

@Jason: thanks for your inputs again!

Any idea why does the request to acquire/allocate Graphic Buffer fail
with Bad address?

W/GraphicBufferMapper(2541): registerBuffer(0x3a2408) failed -14 (Bad
address)
W/Surface(2541): registerBuffer(...) failed -14 (Bad address)
E/Surface(2541): getBufferLocked(0, 0, 0, 0, 00000033) failed (Bad
address)
E/Surface(2541): dequeueBuffer failed (Bad address)

What is the reason for above exception?
Is there a problem in memory addressed by 0x3a2408?

On May 6, 11:11 am, "Jason Teagle" <teagle.ja...@gmail.com> wrote:
> >I meant - If we use the app for a longer duration of time without
> >navigating out or switching to a different app we see Canvas Lock with
> >Bad address.
>
> Hmmm... since that [particular case] pretty much eliminates problems caused
> by activities going to the background and possibly being killed, that
> suggests that the problem is in how you are rendering to the surface. See
> below.
>
> >Even when we keep transitioning between activities quickly, after
> >15-20 tries, we observe the same "Lock Canvas" issue.
>
> (Which suggests a resource / other memory leak or releasing problem, or
> threading issue. Can't think how to progress that one for a moment.)
>
> >The first activity
> >has a GLSurfaceView on which we render Bitmaps(drawing in DIRTY MODE).
> >This activity is never finished.
>
> But have you accounted for the possibility of your app being killed under
> heavy device load while it is in the background, for the case where fast
> switching back and forth causes the failure ('fast' implying that it might
> not be getting time to garbage collect properly, causing allocated memory
> build-up)?
>
> (I don't know how one should protect against that other than to save program
> state on a pause - I'm hoping more experienced members are still reading
> this along with us.)
>
> >These bitmaps are rendered/cleared from the
> >GLSurfaceView everytime an activity is Entered/exited from, using
> >Broadcasts.
>
> Can you be sure you are not trying to use information in a broadcast
> receiver that may no longer be valid because the calling (=
> broadcast-sending) code has dumped it too early? (It is my understanding
> that broadcasts are asynchronous - if that is not the case, then ignore this
> bit.)
>
> >After a bitmap object becomes useless in the context, we
> >pop it from the stack, call recycle to free native memory and nullify
> >the java reference.
>
> Sounds pretty sensible. In case the problem is gc not getting enough time to
> do its job, might be worthy temporarily calling System.gc() every time you
> dump a bitmap - I'm not sure this is a wise choice for permanent code, but
> it might help show if the problem lies in this area.
>
> >Yes, if we remove the calls to GLSurfaceView.requestRender() the issue
> >goes away.
>
> OK, but now a slightly different test: go back to calling requestRender() as
> before, but in your custom renderer, just do some standard OpenGL stuff like
> outputting a dummy triangle or two; don't try rendering the bitmap to the
> surface. So we're going through the frame rendering process (basic OpenGL
> stuff), but avoiding doing anything fancy with a bitmap (not that rendering
> an image to an OpenGL surface should be a problem, but still). Don't create
> any bitmaps or destroy them - so we're basically trying to take the bitmap
> itself out of the equation and see if that is where the problem lies).
>
> (This should be a separate test from trying System.gc() mentioned above -
> try gc() first, as is the quickest to try.)

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