801658 - PandaBoard: invalid graphics buffers supplied to gralloc

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Thomas Zimmermann [:tzimmermann] [:tdz]]

On the PandaBoard, unregisterBuffer failes for some buffers.

> W/GraphicBufferMapper( 1503): unregisterBuffer(0x432c0e40) failed -22 (Invalid argument)

The error comes from a failed call to gralloc. The underlying buffer was not allocated by gralloc, so gralloc cannot handle it. It seems the graphics buffer was created during flattening/unflattening operations.

Comment 1

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Attachment: Displays a cursor image

This problem is caused by the applying the patch 'mouse-test' of bug https://bugzilla.mozilla.org/show_bug.cgi?id=653603, which displays a mouse cursor. When the cursor image leaves the screen, the underlying graphic buffer becomes invalid.

The attached patch is an updated version of 'mouse-test', which keeps the cursor within the screen.

Comment 2

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Just fixing the mouse-test patch is not enough. When the PandaBoard wakes up from suspend, all graphics buffers are invalid, and b2g crashes. The logcat output is shown below.

From what I've see during debugging this problem, it looks as if the graphics driver deletes all buffers when they become invisible, but b2g doesn't. What we'd need to do in this case is to either prevent the driver from throwing away its buffers, or rebuilding them.


> I/IdleService( 1604): Get idle time: time since reset 16 msec
> I/IdleService( 1604): Idle timer callback: current idle time 16 msec
> I/IdleService( 1604): next timeout 1351518307362548 usec (983 msec from now)
> I/IdleService( 1604): SetTimerExpiryIfBefore: next timeout 1351518307362548 usec
> I/IdleService( 1604): reset timer expiry from 0 usec to 1351518307372548 usec
> I/IdleService( 1604): Get idle time: time since reset 37 msec
> I/IdleService( 1604): Idle timer callback: current idle time 37 msec
> I/IdleService( 1604): next timeout 1351518308352874 usec (962 msec from now)
> I/IdleService( 1604): SetTimerExpiryIfBefore: next timeout 1351518308352874 usec
> I/IdleService( 1604): reset timer expiry from 0 usec to 1351518308362874 usec
> W/GraphicBufferMapper( 1604): unregisterBuffer(0x473e1d00) failed -22 (Invalid argument)
> W/GraphicBufferMapper( 1604): unregisterBuffer(0x473e1800) failed -22 (Invalid argument)
> I/IdleService( 1604): Get idle time: time since reset 985 msec
> I/IdleService( 1604): Idle timer callback: current idle time 985 msec
> I/IdleService( 1604): next timeout 1351518308352874 usec (14 msec from now)
> I/IdleService( 1604): SetTimerExpiryIfBefore: next timeout 1351518308352874 usec
> I/IdleService( 1604): reset timer expiry from 0 usec to 1351518308362874 usec
> I/IdleService( 1604): Get idle time: time since reset 16 msec
> I/IdleService( 1604): Idle timer callback: current idle time 16 msec
> I/IdleService( 1604): next timeout 1351518309374908 usec (983 msec from now)
> I/IdleService( 1604): SetTimerExpiryIfBefore: next timeout 1351518309374908 usec
> I/IdleService( 1604): reset timer expiry from 0 usec to 1351518309384908 usec
> W/GraphicBufferMapper( 1604): unregisterBuffer(0x48072d00) failed -22 (Invalid argument)
> W/GraphicBufferMapper( 1604): unregisterBuffer(0x48072ac0) failed -22 (Invalid argument)
> W/GraphicBufferMapper( 1604): unregisterBuffer(0x4805ed00) failed -22 (Invalid argument)
> W/GraphicBufferMapper( 1604): unregisterBuffer(0x48082380) failed -22 (Invalid argument)
> W/GraphicBufferMapper( 1604): unregisterBuffer(0x48082ac0) failed -22 (Invalid argument)
> W/GraphicBufferMapper( 1604): unregisterBuffer(0x48082dc0) failed -22 (Invalid argument)
> W/GraphicBufferMapper( 1604): unregisterBuffer(0x48088cc0) failed -22 (Invalid argument)
> W/GraphicBufferMapper( 1604): unregisterBuffer(0x48088c80) failed -22 (Invalid argument)
> I/IdleService( 1604): Get idle time: time since reset 7 msec
> I/IdleService( 1604): Idle timer callback: current idle time 7 msec
> I/IdleService( 1604): next timeout 1351518310364379 usec (992 msec from now)
> I/IdleService( 1604): SetTimerExpiryIfBefore: next timeout 1351518310364379 usec
> I/IdleService( 1604): reset timer expiry from 0 usec to 1351518310374379 usec
> W/GraphicBufferMapper( 1604): unregisterBuffer(0x473e6c00) failed -22 (Invalid argument)
> W/GraphicBufferMapper( 1604): unregisterBuffer(0x4809e340) failed -22 (Invalid argument)
> W/GraphicBufferMapper( 1604): unregisterBuffer(0x480ac1c0) failed -22 (Invalid argument)
> W/GraphicBufferMapper( 1604): unregisterBuffer(0x481cc040) failed -22 (Invalid argument)
> I/IdleService( 1604): Get idle time: time since reset 5 msec
> I/IdleService( 1604): Idle timer callback: current idle time 5 msec
> I/IdleService( 1604): next timeout 1351518311391484 usec (995 msec from now)
> I/IdleService( 1604): SetTimerExpiryIfBefore: next timeout 1351518311391484 usec
> I/IdleService( 1604): reset timer expiry from 0 usec to 1351518311401484 usec
> D/wpa_supplicant( 1656): nl80211: survey data missing!
> W/GraphicBufferMapper( 1604): unregisterBuffer(0x480886c0) failed -22 (Invalid argument)
> W/AudioFlinger( 1603): Thread AudioOut_1 cannot connect to the power manager service
> W/GraphicBufferMapper( 1604): unregisterBuffer(0x48082f00) failed -22 (Invalid argument)
> I/IdleService( 1604): Get idle time: time since reset 3 msec
> I/IdleService( 1604): Idle timer callback: current idle time 3 msec
> I/IdleService( 1604): next timeout 1351518313358703 usec (996 msec from now)
> I/IdleService( 1604): SetTimerExpiryIfBefore: next timeout 1351518313358703 usec
> I/IdleService( 1604): reset timer expiry from 0 usec to 1351518313368703 usec
> W/GraphicBufferMapper( 1604): unregisterBuffer(0x4806ef00) failed -22 (Invalid argument)
> W/GraphicBufferMapper( 1604): unregisterBuffer(0x4838d240) failed -22 (Invalid argument)
> W/GraphicBufferMapper( 1604): unregisterBuffer(0x483e5240) failed -22 (Invalid argument)
> I/Gecko   ( 1604): [Parent 1604] ###!!! ABORT: Framebuffer not complete -- error 0x8cd6, mFBOTextureTarget 0xde1, aRect.width 1440, aRect.height 2520: file /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/gfx/layers/opengl/LayerManagerOGL.cpp, line 1357
> F/libc    ( 1604): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1)
> I/DEBUG   ( 1602): debuggerd committing suicide to free the zombie!
> I/DEBUG   ( 1715): debuggerd: Oct 26 2012 11:41:47
> I/ServiceManager( 1274): service 'media.audio_flinger' died
> I/ServiceManager( 1274): service 'media.player' died
> I/ServiceManager( 1274): service 'media.camera' died
> I/ServiceManager( 1274): service 'media.audio_policy' died

Comment 3

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Here is a stack trace from the SIGSEGV.

gdb> c
[New Thread 1717.1743]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1717.1743]
_______________________________________________________________________________
Error while running hook_stop:
Value can't be converted to integer.
0x413fa7a0 in mozalloc_abort (msg=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/memory/mozalloc/mozalloc_abort.cpp:23
23	    MOZ_CRASH();
gdb> bt
#0  0x413fa7a0 in mozalloc_abort (msg=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/memory/mozalloc/mozalloc_abort.cpp:23
#1  0x40022f70 in _normal_unlock (mutex=0x0) at bionic/libc/bionic/pthread.c:973
#2  pthread_mutex_unlock (mutex=0x0) at bionic/libc/bionic/pthread.c:1120
#3  0x2323205c in ?? ()
#4  0x2323205c in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
gdb> c

Program received signal SIGCONT, Continued.
[Switching to Thread 1717.1717]
_______________________________________________________________________________
Error while running hook_stop:
Value can't be converted to integer.
__futex_syscall3 () at bionic/libc/arch-arm/bionic/atomics_arm.S:182
182	    swi     #0
gdb> bt
#0  __futex_syscall3 () at bionic/libc/arch-arm/bionic/atomics_arm.S:182
#1  0x40023394 in __pthread_cond_timedwait_relative (cond=0x458a4484, mutex=0x47ac0bf0, reltime=0x0) at bionic/libc/bionic/pthread.c:1477
#2  0x40023448 in __pthread_cond_timedwait (cond=0x458a4484, mutex=0x47ac0bf0, abstime=0x0, clock=0x0) at bionic/libc/bionic/pthread.c:1500
#3  0x4011f230 in PR_WaitCondVar (cvar=0x458a4480, timeout=0xffffffff) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/nsprpub/pr/src/pthreads/ptsynch.c:385
#4  0x40e7647c in mozilla::CondVar::Wait (this=0x435f4238) at ../../dist/include/mozilla/CondVar.h:71
#5  mozilla::Monitor::Wait (this=0x435f4238) at ../../dist/include/mozilla/Monitor.h:47
#6  mozilla::ipc::SyncChannel::WaitForNotify (this=0x435f4238) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/ipc/glue/SyncChannel.cpp:287
#7  0x40e766ee in mozilla::ipc::SyncChannel::Send (this=0x435f4238, _msg=0x43929d00, reply=0xbedcb310) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/ipc/glue/SyncChannel.cpp:96
#8  0x40e74d7a in mozilla::ipc::RPCChannel::Send (this=0x435f4238, msg=0x43929d00, reply=0xbedcb310) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/ipc/glue/RPCChannel.cpp:118
#9  0x40edf8fe in mozilla::layers::PLayersChild::SendUpdate (this=0x4589cf00, cset=<value optimized out>, targetConfig=<value optimized out>, isFirstPaint=@0x48285dcc, reply=0xbedcc614) at /home/tdz/Projects/mozilla/src/B2G-panda/objdir-gecko-debug/ipc/ipdl/PLayersChild.cpp:294
#10 0x40fde458 in mozilla::layers::ShadowLayerForwarder::EndTransaction (this=0x48285db8, aReplies=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/gfx/layers/ipc/ShadowLayers.cpp:359
#11 0x40fbecb6 in mozilla::layers::BasicShadowLayerManager::ForwardTransaction (this=0x48285d40) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/gfx/layers/basic/BasicLayerManager.cpp:1188
#12 0x40fbef90 in mozilla::layers::BasicShadowLayerManager::EndTransaction (this=0x48285d40, aCallback=0x40879811 <mozilla::FrameLayerBuilder::DrawThebesLayer(mozilla::layers::ThebesLayer*, gfxContext*, nsIntRegion const&, nsIntRegion const&, void*)>, aCallbackData=0xbedcd120, aFlags=mozilla::layers::LayerManager::END_NO_COMPOSITE) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/gfx/layers/basic/BasicLayerManager.cpp:1131
#13 0x40898fc4 in nsDisplayList::PaintForFrame (this=<value optimized out>, aBuilder=0xbedcd120, aCtx=<value optimized out>, aForFrame=<value optimized out>, aFlags=0xd) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/layout/base/nsDisplayList.cpp:1110
#14 0x4089910c in nsDisplayList::PaintRoot (this=0xbedcd4a8, aBuilder=0xbedcd120, aCtx=0x0, aFlags=0xd) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/layout/base/nsDisplayList.cpp:975
#15 0x408a78f6 in nsLayoutUtils::PaintFrame (aRenderingContext=<value optimized out>, aFrame=0x47063800, aDirtyRegion=<value optimized out>, aBackstop=<value optimized out>, aFlags=0x304) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/layout/base/nsLayoutUtils.cpp:1853
#16 0x408b3b26 in PresShell::Paint (this=0x471ad500, aViewToPaint=<value optimized out>, aDirtyRegion=<value optimized out>, aFlags=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/layout/base/nsPresShell.cpp:5340
#17 0x40abfb70 in nsViewManager::ProcessPendingUpdatesForView (this=0x47058d90, aView=0x47024d00, aFlushDirtyRegion=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/view/src/nsViewManager.cpp:439
#18 0x40abfc12 in nsViewManager::ProcessPendingUpdates (this=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/view/src/nsViewManager.cpp:1214
#19 0x408b73c4 in nsRefreshDriver::Notify (this=0x435f5c10, aTimer=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/layout/base/nsRefreshDriver.cpp:432
#20 0x40f5ffb8 in nsTimerImpl::Fire (this=0x47057970) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/xpcom/threads/nsTimerImpl.cpp:475
#21 0x40f60066 in nsTimerEvent::Run (this=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/xpcom/threads/nsTimerImpl.cpp:555
#22 0x40f5e19e in nsThread::ProcessNextEvent (this=0x404078e0, mayWait=<value optimized out>, result=0xbedcd877) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/xpcom/threads/nsThread.cpp:620
#23 0x40f3e956 in NS_ProcessNextEvent_P (thread=0x458a4484, mayWait=0x0) at /home/tdz/Projects/mozilla/src/B2G-panda/objdir-gecko-debug/xpcom/build/nsThreadUtils.cpp:220
#24 0x40e73574 in mozilla::ipc::MessagePump::Run (this=0x40403400, aDelegate=0x404260c0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/ipc/glue/MessagePump.cpp:82
#25 0x40f7f428 in MessageLoop::RunInternal (this=0x1000000) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/ipc/chromium/src/base/message_loop.cc:215
#26 0x40f7f4de in MessageLoop::RunHandler (this=0x404260c0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/ipc/chromium/src/base/message_loop.cc:208
#27 MessageLoop::Run (this=0x404260c0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/ipc/chromium/src/base/message_loop.cc:182
#28 0x40dfcfdc in nsBaseAppShell::Run (this=0x42629700) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/widget/xpwidgets/nsBaseAppShell.cpp:163
#29 0x40d3a148 in nsAppStartup::Run (this=0x427aab50) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/toolkit/components/startup/nsAppStartup.cpp:290
#30 0x40793728 in XREMain::XRE_mainRun (this=0xbedcda34) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/toolkit/xre/nsAppRunner.cpp:3799
#31 0x40795d88 in XREMain::XRE_main (this=0xbedcda34, argc=<value optimized out>, argv=0xbedcfc14, aAppData=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/toolkit/xre/nsAppRunner.cpp:3866
#32 0x40795ed4 in XRE_main (argc=0x1, argv=0xbedcfc14, aAppData=0xa9a0, aFlags=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/toolkit/xre/nsAppRunner.cpp:3941
#33 0x0000898a in do_main (argc=0x1, argv=0xbedcfc14) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/b2g/app/nsBrowserApp.cpp:154
#34 main (argc=0x1, argv=0xbedcfc14) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/b2g/app/nsBrowserApp.cpp:239
gdb> c

Child exited with status 11

Program exited with code 013.

Comment 4

[Thomas Zimmermann [:tzimmermann] [:tdz]]

I observed the problem of invalid graphics buffers when

 - I apply the patch and move the mouse out of the visible area,

 - when the PandaBoard wakes up from suspend and I go from the 'lock screen' to the 'main screen', or

 - when I disable OOP, restart, and try to enter the main screen (which always fails).

I currently have two ideas what could go wrong here:

 - The graphics driver to deletes graphics buffers that become invisible, or

 - some weirdness related to OOP.

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

If the graphics driver is deleting the buffers, we should try really hard to make it not do that.  None of the phones we've seen so far exhibit this behavior, and it's highly nontrivial to support it in gecko.

Comment 6

[Thomas Zimmermann [:tzimmermann] [:tdz]]

B2G is aborted because of https://bugzilla.mozilla.org/show_bug.cgi?id=695246.

Comment 7

[Thomas Zimmermann [:tzimmermann] [:tdz]]

The problem is not directly related to the recent kernel change. It also happens with the previous kernel binary from AOSP.

Comment 8

[Thomas Zimmermann [:tzimmermann] [:tdz]]

I thought that https://bugzilla.mozilla.org/show_bug.cgi?id=806029 might help to fix this problem?

The graphic driver is a closed-source binary. We probably can't change it. But if we can free the graphics buffers if an application goes hidden, it seems natural to free them if the system suspends.

Comment 9

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Bug 806029 might ameliorate the problem, but it won't make it go away.  To *really* fix it we need a to invest a significant amount of engineering that's just not worth it at this point.

Why is the pandaboard going in and out of suspend during test runs?

Comment 10

[Thomas Zimmermann [:tzimmermann] [:tdz]]

I don't know if RelEng has specific tests related to suspends. I remember jodiunn mentioned on irc that the current behaviour is a problem for them. Otherwise we could also grab a wake look for now and prevent the PandaBoard from suspending.

John, do you have any requirements on the suspending behaviour of the PandaBoard during automated tests?

Comment 11

[Thomas Zimmermann [:tzimmermann] [:tdz]]

A quick grep revealed that EGL pbuffers are used somewhere in Gecko and/or the underlying Android framework. If they are similar to GLX pbuffers, they can become invalid at any time. Maybe that's the problem here. At least on X11, you'd get an event if this happens. I'll investigate this further...

Comment 12

[Thomas Zimmermann [:tzimmermann] [:tdz]]

According to the EGL 1.4 spec, EGL pbuffers are preserved, but EGL context can be lost during power saving.

Comment 13

[Thomas Zimmermann [:tzimmermann] [:tdz]]

The abort at

> I/Gecko   ( 1604): [Parent 1604] ###!!! ABORT: Framebuffer not complete -- error 0x8cd6, mFBOTextureTarget 0xde1, aRect.width 1440, aRect.height 2520: file /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-804183/gfx/layers/opengl/LayerManagerOGL.cpp, line 1357

is triggered because the frame-buffer setup at line 1338 has an incomplete texture attachment, which is incomplete because the call to TexImage2D at line 1317 failed. This happened because the requested height is larger than GL_MAX_TEXTURE_SIZE, which is 2048 for my hardware.

I noticed that the width and height values in aRect are not always the same. This might come from uninitialized values.

The output from the mode selection is shown below. I wonder if the size of the frame buffer in aRect is that large because it accounts for both display outputs, DVI and HDMI, in some way. The mode selection says 'mirror', but who knows. The resolution is close to WQHD (2560x1440) but not quite the same.

> I/Gecko   ( 1246): Logging GL tracing output to /system/b2g/firefox.trace
> I/Gecko   ( 1246): Attempting load of /data/local/egltrace.so
> I/Gecko   ( 1246): Attempting load of libEGL.so
> D/libEGL  ( 1246): loaded /system/lib/egl/libGLES_android.so
> D/libEGL  ( 1246): loaded /vendor/lib/egl/libEGL_POWERVR_SGX540_120.so
> D/libEGL  ( 1246): loaded /vendor/lib/egl/libGLESv1_CM_POWERVR_SGX540_120.so
> D/libEGL  ( 1246): loaded /vendor/lib/egl/libGLESv2_POWERVR_SGX540_120.so
> I/ti_hwc  ( 1246): clone region is set to (0,0) to (1280,720)
> D/ti_hwc  ( 1246): #0: 640x480 59Hz
> D/ti_hwc  ( 1246): #1: 640x480 75Hz
> D/ti_hwc  ( 1246): #2: 800x600 60Hz
> D/ti_hwc  ( 1246): #3: 800x600 75Hz
> D/ti_hwc  ( 1246): #4: 1024x768 60Hz
> D/ti_hwc  ( 1246): #5: 1024x768 75Hz
> D/ti_hwc  ( 1246): #6: 1280x1024 75Hz
> D/ti_hwc  ( 1246): #7: 1152x864 75Hz
> D/ti_hwc  ( 1246): #8: 1280x960 60Hz
> D/ti_hwc  ( 1246): #9: 1280x1024 60Hz
> D/ti_hwc  ( 1246): picking #0
> I/ti_hwc  ( 1246): external display changed (state=1, mirror={enabled tform=0deg}, dock={enabled tform=0deg}, tv=1
> I/ti_hwc  ( 1246): omap4_hwc_device_open(rgb_order=1 nv12_only=0)
> E/GeckoConsole( 1246): OpenGL LayerManager Initialized Succesfully.
> E/GeckoConsole( 1246): Version: OpenGL ES 2.0 build 1.8@785978
> E/GeckoConsole( 1246): Vendor: Imagination Technologies
> E/GeckoConsole( 1246): Renderer: PowerVR SGX 540
> E/GeckoConsole( 1246): FBO Texture Target: TEXTURE_2D

Comment 14

[Thomas Zimmermann [:tzimmermann] [:tdz]]

(In reply to Thomas Zimmermann from comment #12)
> According to the EGL 1.4 spec, EGL pbuffers are preserved, but EGL context
> can be lost during power saving.

... which means that this context's objects become invalid. However, I have not received an EGL_CONTEXT_LOST error before the abort.

Comment 15

[Thomas Zimmermann [:tzimmermann] [:tdz]]

The workaround of allocating a buffer that is at most the maximum size of the OpenGL implementation seems to work, but looks like a hack. I'll try to find out where the original size values come from.

Comment 16

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Robert, Matt,

I have a question regarding the computation of frame bounds in nsDisplayTransform::GetBounds in layout/base/nsDisplayList.cpp. I'm asking you because have several recent commits in that file.

B2G aborts because it fails to allocate a graphics buffer that is larger than the maximum supported size, which is 2048 per direction. I tried to track the size requirement back to where it's computed and came along the function nsDisplayTransform::GetBounds. This function contains a matrix transformation MatrixTransformRect. It receives the untransformed bounds of a scene element and returns the transformed bounds of the visible rectangle; relative to the parent, right?

The input bounds (x,y,w,h) are (0,0,43200,75600) and the scaling factor between pixels and internal sizes is 60. So the input seems correct (i.e., <2048 pixels per direction). The output of the transformation is (-21457,-36349,86114,150698) units. I cannot make sense of the size values here. Why should the scene element change in size? The transformation matrix is computed by nsDisplayTransform::GetTransform. Can you tell me what the transformation consists of?

Comment 17

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Robert, Matt,

I have a question regarding the computation of frame bounds in nsDisplayTransform::GetBounds in layout/base/nsDisplayList.cpp. I'm asking you because have several recent commits in that file.

B2G aborts because it fails to allocate a graphics buffer that is larger than the maximum supported size, which is 2048 per direction. I tried to track the size requirement back to where it's computed and came along the function nsDisplayTransform::GetBounds. This function contains a matrix transformation MatrixTransformRect. It receives the untransformed bounds of a scene element and returns the transformed bounds of the visible rectangle; relative to the parent, right?

The input bounds (x,y,w,h) are (0,0,43200,75600) and the scaling factor between pixels and internal sizes is 60. So the input seems correct (i.e., <2048 pixels per direction). The output of the transformation is (-21457,-36349,86114,150698) units. I cannot make sense of the size values here. Why should the scene element change in size? The transformation matrix is computed by nsDisplayTransform::GetTransform. Can you tell me what the transformation consists of?

Comment 18

[Matt Woodrow (:mattwoodrow)]

nsDisplayTransform items are created in response to transform/-moz-transform style in the css.

You can step through GetResultingTransformMatrix to see what the transformation is, and step into nsStyleTransformMatrix::ReadTransforms to see what transform properties were specified.

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Thomas Zimmermann from comment #17)
> The input bounds (x,y,w,h) are (0,0,43200,75600) and the scaling factor
> between pixels and internal sizes is 60. So the input seems correct (i.e.,
> <2048 pixels per direction). The output of the transformation is
> (-21457,-36349,86114,150698) units. I cannot make sense of the size values
> here. Why should the scene element change in size? The transformation matrix
> is computed by nsDisplayTransform::GetTransform. Can you tell me what the
> transformation consists of?

Is a particular testcase triggering this? If so, which one?

Comment 20

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Attachment: Clamp FBO texture size to maximum supported values

This patch works around aborting gecko. A real fix will follow when I find out why the requested texture size is too large.

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 683564 [details] [diff] [review]
Clamp FBO texture size to maximum supported values

Review of attachment 683564 [details] [diff] [review]:
-----------------------------------------------------------------

I'm not really the right person to review this, but other than my comment below it looks good.

::: gfx/layers/opengl/LayerManagerOGL.cpp
@@ +1351,5 @@
>    mGLContext->fGenTextures(1, &tex);
>    mGLContext->fBindTexture(mFBOTextureTarget, tex);
>  
> +  GLint maxTex = 0;
> +  mGLContext->fGetIntegerv(LOCAL_GL_MAX_TEXTURE_SIZE, &maxTex);

Call mGLContext->GetMaxTextureSize() to get the cached value of this.

Comment 22

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Attachment: Clamp FBO texture size to maximum supported values [v2]

Updated according to review comment.

Comment 23

[Benoit Girard (:BenWa)]

Comment on attachment 684385 [details] [diff] [review]
Clamp FBO texture size to maximum supported values [v2]

I don't think we want to take this patch even as a workaround. Trying to allocate a large texture is a big problem and should result in a crash rather then being ignored. I would in fact make a counter proposal that if we're asking for a FBO greater then the max FBO size we run a runtime abort or propagate the error for it to be gracefully handled.

Crashing in obviously bad state is useful because we can use crash-stats to know our code is hitting unexpected paths.

Perhaps I'm not being practical here. If you can find a GFX peers to support this approach I would change my mind.

Comment 24

[Thomas Zimmermann [:tzimmermann] [:tdz]]

I can't reproduce this issue any longer. I guess it' still there, I just cannot trigger is reliably.

Comment 25

[Hui.Xu]

(In reply to Thomas Zimmermann [:tzimmermann] from comment #24)
> I can't reproduce this issue any longer. I guess it' still there, I just
> cannot trigger is reliably.
Hi Thomas:
I found this error may be the disorder called by the deconstruct of GraphicBuffer.
Because the LockScreen app is running in the B2G process. According to the B2G gfx system, there is a concept of "Parent <-> Child". Usually the B2G process acts as Parent which is the gralloc's manager and other app acts as Child which use the gralloc memory came from the Parent(by pmem or ashmen).
In this error=-22 cause, the B2G both acts as Parent and Child. Then when the GraphicBuffer is deleted , it maybe first go the Parent switch which will actually call allocator's free function in the compositor thread and then go the Child switch which will unregister the buffer , also error happens.

Comment 26

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Kan-ru, see comment #25.

Comment 27

[Thomas Zimmermann [:tzimmermann] [:tdz]]

(In reply to Hui.Xu from comment #25)
> (In reply to Thomas Zimmermann [:tzimmermann] from comment #24)
> > I can't reproduce this issue any longer. I guess it' still there, I just
> > cannot trigger is reliably.
> Hi Thomas:
> I found this error may be the disorder called by the deconstruct of
> GraphicBuffer.
> Because the LockScreen app is running in the B2G process. According to the
> B2G gfx system, there is a concept of "Parent <-> Child". Usually the B2G
> process acts as Parent which is the gralloc's manager and other app acts as
> Child which use the gralloc memory came from the Parent(by pmem or ashmen).
> In this error=-22 cause, the B2G both acts as Parent and Child. Then when
> the GraphicBuffer is deleted , it maybe first go the Parent switch which
> will actually call allocator's free function in the compositor thread and
> then go the Child switch which will unregister the buffer , also error
> happens.

Hi!

The error message still persists if I apply patch 1.1 from bug 819737, which is the bug report for this problem(?).

Comment 28

[Hui.Xu]

(In reply to Thomas Zimmermann [:tzimmermann] from comment #27)
> (In reply to Hui.Xu from comment #25)
> > (In reply to Thomas Zimmermann [:tzimmermann] from comment #24)
> > > I can't reproduce this issue any longer. I guess it' still there, I just
> > > cannot trigger is reliably.
> > Hi Thomas:
> > I found this error may be the disorder called by the deconstruct of
> > GraphicBuffer.
> > Because the LockScreen app is running in the B2G process. According to the
> > B2G gfx system, there is a concept of "Parent <-> Child". Usually the B2G
> > process acts as Parent which is the gralloc's manager and other app acts as
> > Child which use the gralloc memory came from the Parent(by pmem or ashmen).
> > In this error=-22 cause, the B2G both acts as Parent and Child. Then when
> > the GraphicBuffer is deleted , it maybe first go the Parent switch which
> > will actually call allocator's free function in the compositor thread and
> > then go the Child switch which will unregister the buffer , also error
> > happens.
> 
> Hi!
> 
> The error message still persists if I apply patch 1.1 from bug 819737, which
> is the bug report for this problem(?).
Hi Thomas:
I am not authorized to access bug #819737....
So can you send this patch to my own email ?
Thank you!

Comment 29

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Attachment: Displays a cursor image

Updated patch.

Comment 30

[Justin Wood (:Callek)]

No longer using pandas at mozilla