RESOLVED FIXED 80509
OOM running webgl/sdk/tests/conformance/context/context-creation-and-destruction.html
https://bugs.webkit.org/show_bug.cgi?id=80509
Summary OOM running webgl/sdk/tests/conformance/context/context-creation-and-destruct...
Tomeu Vizoso
Reported 2012-03-07 05:37:54 PST
Running the test at https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/context/context-creation-and-destruction.html causes the process to run out of memory and ultimately crashes in the GL driver. Wonder if it's related to #76225. This is with the HEADs of both WebKit and Mesa. gdb --args ./Programs/GtkLauncher --enable-webgl=1 https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/context/context-creation-and-destruction.html Mesa: User error: GL_OUT_OF_MEMORY in glTexImage Mesa: User error: GL_OUT_OF_MEMORY in glTexImage2D Mesa: User error: GL_OUT_OF_MEMORY in glTexImage Program received signal SIGSEGV, Segmentation fault. 0xaaf85425 in st_validate_attachment (ctx=0xc51e5f8, screen=0x8323418, att=0xc547910, bindings=2) at state_tracker/st_cb_fbo.c:446 446 format = stObj->pt->format; (gdb) bt #0 0xaaf85425 in st_validate_attachment (ctx=0xc51e5f8, screen=0x8323418, att=0xc547910, bindings=2) at state_tracker/st_cb_fbo.c:446 #1 0xaaf8571f in st_validate_framebuffer (ctx=0xc51e5f8, fb=0xc547730) at state_tracker/st_cb_fbo.c:544 #2 0xaaed29fa in _mesa_test_framebuffer_completeness (ctx=0xc51e5f8, fb=0xc547730) at main/fbobject.c:864 #3 0xaaed5136 in _mesa_CheckFramebufferStatusEXT (target=36160) at main/fbobject.c:1884 #4 0xb603d90d in WebCore::GraphicsContext3D::reshapeFBOs (this=0xc479e00, size=...) at ../Source/WebCore/platform/graphics/opengl/GraphicsContext3DOpenGL.cpp:120 #5 0xb603e7ee in WebCore::GraphicsContext3D::reshape (this=0xc479e00, width=2048, height=2048) at ../Source/WebCore/platform/graphics/opengl/GraphicsContext3DOpenGLCommon.cpp:239 #6 0xb6012aa7 in WebCore::WebGLRenderingContext::initializeNewContext ( this=0xc547a68) at ../Source/WebCore/html/canvas/WebGLRenderingContext.cpp:514 #7 0xb6012505 in WebCore::WebGLRenderingContext::WebGLRenderingContext ( this=0xc547a68, passedCanvas=0xc47b150, context=..., attributes=...) at ../Source/WebCore/html/canvas/WebGLRenderingContext.cpp:446 #8 0xb6012163 in WebCore::WebGLRenderingContext::create (canvas=0xc47b150, attrs=0x8fccee0) at ../Source/WebCore/html/canvas/WebGLRenderingContext.cpp:415 #9 0xb59f5408 in WebCore::HTMLCanvasElement::getContext (this=0xc47b150, type=..., attrs=0x8fccee0) at ../Source/WebCore/html/HTMLCanvasElement.cpp:197 #10 0xb56873a0 in WebCore::JSHTMLCanvasElement::getContext (this=0xac61cd80, exec=0xac0401e8) at ../Source/WebCore/bindings/js/JSHTMLCanvasElementCustom.cpp:75 #11 0xb617e9d8 in WebCore::jsHTMLCanvasElementPrototypeFunctionGetContext ( exec=0xac0401e8) at DerivedSources/WebCore/JSHTMLCanvasElement.cpp:208 #12 0xac632f29 in ?? () #13 0xb4be36ef in JSC::JITCode::execute (this=0xabf9cce0, registerFile=0x816258c, callFrame=0xac040038, globalData=0x824a2e8) at ../Source/JavaScriptCore/jit/JITCode.h:127 #14 0xb4be09ef in JSC::Interpreter::executeCall (this=0x8162580, callFrame=0xac01fcb4, function=0xac61d880, callType=JSC::CallTypeJS, callData=..., thisValue=..., args=...) at ../Source/JavaScriptCore/interpreter/Interpreter.cpp:1270 #15 0xb4c9cc4e in JSC::call (exec=0xac01fcb4, functionObject=..., callType=JSC::CallTypeJS, callData=..., thisValue=..., args=...) at ../Source/JavaScriptCore/runtime/CallData.cpp:39 #16 0xb5655f88 in WebCore::JSMainThreadExecState::call (exec=0xac01fcb4, functionObject=..., callType=JSC::CallTypeJS, callData=..., thisValue=..., ---Type <return> to continue, or q <return> to quit--- args=...) at ../Source/WebCore/bindings/js/JSMainThreadExecState.h:56 #17 0xb56bd8fd in WebCore::ScheduledAction::executeFunctionInContext ( this=0xc4784c0, globalObject=0xac01fc40, thisValue=..., context=0x8248208) at ../Source/WebCore/bindings/js/ScheduledAction.cpp:110 #18 0xb56bdae4 in WebCore::ScheduledAction::execute (this=0xc4784c0, document= 0x8248100) at ../Source/WebCore/bindings/js/ScheduledAction.cpp:130 #19 0xb56bd6a4 in WebCore::ScheduledAction::execute (this=0xc4784c0, context=0x8248208) at ../Source/WebCore/bindings/js/ScheduledAction.cpp:80 #20 0xb5c483a1 in WebCore::DOMTimer::fired (this=0xc4b6950) at ../Source/WebCore/page/DOMTimer.cpp:149 #21 0xb5d9f213 in WebCore::ThreadTimers::sharedTimerFiredInternal ( this=0x8168580) at ../Source/WebCore/platform/ThreadTimers.cpp:115 #22 0xb5d9f157 in WebCore::ThreadTimers::sharedTimerFired () at ../Source/WebCore/platform/ThreadTimers.cpp:93 #23 0xb6382b41 in WebCore::timeout_cb () at ../Source/WebCore/platform/gtk/SharedTimerGtk.cpp:49 #24 0xb2b393d3 in g_timeout_dispatch (source=0xc087e28, callback=0xb6382b1d <WebCore::timeout_cb(gpointer)>, user_data=0x0) at gmain.c:3854 #25 0xb2b37667 in g_main_dispatch (context=0x80815b0) at gmain.c:2510 #26 0xb2b3822d in g_main_context_dispatch (context=0x80815b0) at gmain.c:3047 #27 0xb2b38418 in g_main_context_iterate (context=0x80815b0, block=1, dispatch=1, self=0x821a640) at gmain.c:3118 #28 0xb2b38892 in g_main_loop_run (loop=0x8216b98) at gmain.c:3312 #29 0xb3133155 in gtk_main () from /usr/lib/libgtk-3.so.0 #30 0x0804bca9 in main (argc=1, argv=0xbfffea04) at ../Tools/GtkLauncher/main.c:509
Attachments
Patch (23.13 KB, patch)
2012-05-06 09:28 PDT, Martin Robinson
alex: review+
Tomeu Vizoso
Comment 1 2012-03-07 08:34:43 PST
I can confirm that the test causes 500 calls to glXCreateNewContext and none to glXDestroyContext. Nouveau crashes rendering the display unusable until a reboot.
Martin Robinson
Comment 2 2012-05-06 09:28:38 PDT
Alejandro G. Castro
Comment 3 2012-05-16 03:45:05 PDT
Comment on attachment 140422 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=140422&action=review Looks good to me :), thanks. It fixes the issue reported. > Source/WebCore/platform/graphics/cairo/GLContext.h:33 > + static PassOwnPtr<GLContext> createContextForWindow(uint64_t windowHandle, GLContext* sharingContext); Is there a situation where we do not want to use the static shared context or we can create a new one? > Source/WebCore/platform/graphics/glx/GLContextGLX.cpp:96 > + > + Nit: two lines.
Martin Robinson
Comment 4 2012-05-18 12:14:15 PDT
Comment on attachment 140422 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=140422&action=review Thanks for the review! >> Source/WebCore/platform/graphics/cairo/GLContext.h:33 >> + static PassOwnPtr<GLContext> createContextForWindow(uint64_t windowHandle, GLContext* sharingContext); > > Is there a situation where we do not want to use the static shared context or we can create a new one? Not at the moment, but this situation has a high probability of arising in the future and it's good, I think, to keep this class general. >> Source/WebCore/platform/graphics/glx/GLContextGLX.cpp:96 >> + > > Nit: two lines. Okay. Will fix!
Martin Robinson
Comment 5 2012-05-18 12:16:11 PDT
Note You need to log in before you can comment on or make changes to this bug.