Bug 80509 - OOM running webgl/sdk/tests/conformance/context/context-creation-and-destruction.html
Summary: OOM running webgl/sdk/tests/conformance/context/context-creation-and-destruct...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebGL (show other bugs)
Version: 528+ (Nightly build)
Hardware: Other Linux
: P2 Normal
Assignee: Martin Robinson
URL:
Keywords:
Depends on:
Blocks: 86037
  Show dependency treegraph
 
Reported: 2012-03-07 05:37 PST by Tomeu Vizoso
Modified: 2012-05-18 12:16 PDT (History)
1 user (show)

See Also:


Attachments
Patch (23.13 KB, patch)
2012-05-06 09:28 PDT, Martin Robinson
alex: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tomeu Vizoso 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
Comment 1 Tomeu Vizoso 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.
Comment 2 Martin Robinson 2012-05-06 09:28:38 PDT
Created attachment 140422 [details]
Patch
Comment 3 Alejandro G. Castro 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.
Comment 4 Martin Robinson 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!
Comment 5 Martin Robinson 2012-05-18 12:16:11 PDT
Committed r117612: <http://trac.webkit.org/changeset/117612>