@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" <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
