Bug 357754 - Crash in eglCreateImageKHR
Summary: Crash in eglCreateImageKHR
Status: RESOLVED UPSTREAM
Alias: None
Product: kwin
Classification: Plasma
Component: egl (show other bugs)
Version: 5.5.2
Platform: openSUSE Linux
: NOR crash
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-09 18:11 UTC by Fabian Vogt
Modified: 2016-01-11 15:42 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Vogt 2016-01-09 18:11:48 UTC 
I accidentially set QT_DEVICE_PIXEL_RATIO=100 when opening a Qt application that uses OpenGL and kwin_x11 crashes repoducably with the following backtrace until I kill the application:

#0  0x00007fcc67729d8d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007fcc67729c24 in __sleep (seconds=0) at ../sysdeps/unix/sysv/linux/sleep.c:138
#2  0x00007fcc5f5d2c33 in ?? () from /usr/lib64/libKF5Crash.so.5
#3  0x00007fcc5f5d32a9 in ?? () from /usr/lib64/libKF5Crash.so.5
#4  0x00007fcc5f5d3709 in KCrash::defaultCrashHandler(int) () from /usr/lib64/libKF5Crash.so.5
#5  <signal handler called>
#6  dri2_create_image_khr_pixmap (ctx=<optimized out>, attr_list=<optimized out>, buffer=<optimized out>, disp=0x363b480) at drivers/dri2/platform_x11.c:1051
#7  dri2_x11_create_image_khr (drv=<optimized out>, disp=0x363b480, ctx=<optimized out>, target=<optimized out>, buffer=<optimized out>, attr_list=<optimized 
out>)
    at drivers/dri2/platform_x11.c:1074
#8  0x00007fcc598c6279 in eglCreateImageKHR (dpy=0x363b480, ctx=0x0, target=12464, buffer=0x7657a89, attr_list=0x7ffdd25b8db0) at main/eglapi.c:1331
#9  0x00007fcc6738fada in KWin::AbstractEglTexture::loadTexture (this=0x4d8c670, pix=124091017, size=...) at 
/usr/src/debug/kwin-5.5.2/abstract_egl_backend.cpp:312
#10 0x00007fcc6739075a in KWin::AbstractEglTexture::loadTexture (this=0x4d8c670, pixmap=0x514c720) at /usr/src/debug/kwin-5.5.2/abstract_egl_backend.cpp:289
#11 0x00007fcc6732ba24 in KWin::OpenGLWindowPixmap::bind (this=this@entry=0x514c720) at /usr/src/debug/kwin-5.5.2/scene_opengl.cpp:1696
#12 0x00007fcc6732bbe8 in KWin::SceneOpenGL::Window::bindTexture (this=this@entry=0x538a3d0) at /usr/src/debug/kwin-5.5.2/scene_opengl.cpp:1301
#13 0x00007fcc6732e00e in KWin::SceneOpenGL::Window::beginRenderWindow (this=<optimized out>, mask=<optimized out>, region=..., data=...)
    at /usr/src/debug/kwin-5.5.2/scene_opengl.cpp:1362
#14 0x00007fcc6732e4c6 in KWin::SceneOpenGL2Window::performPaint (this=this@entry=0x538a3d0, mask=mask@entry=1, region=..., data=...)
    at /usr/src/debug/kwin-5.5.2/scene_opengl.cpp:1523
#15 0x00007fcc67333d02 in KWin::SceneOpenGL2::performPaintWindow (this=this@entry=0x378dee0, w=w@entry=0x1ceb000, mask=<optimized out>, mask@entry=1, 
region=...,
    data=...) at /usr/src/debug/kwin-5.5.2/scene_opengl.cpp:1174
#16 0x00007fcc67333ef0 in KWin::SceneOpenGL2::finalDrawWindow (this=0x378dee0, w=w@entry=0x1ceb000, mask=mask@entry=1, region=..., data=...)
    at /usr/src/debug/kwin-5.5.2/scene_opengl.cpp:1160
#17 0x00007fcc67340149 in KWin::EffectsHandlerImpl::drawWindow (this=0x387cb70, w=w@entry=0x1ceb000, mask=mask@entry=1, region=..., data=...)
    at /usr/src/debug/kwin-5.5.2/effects.cpp:502
#18 0x00007fcc648c716a in KWin::ContrastEffect::drawWindow (this=this@entry=0x1634db0, w=w@entry=0x1ceb000, mask=mask@entry=1, region=..., data=...)
    at /usr/src/debug/kwin-5.5.2/effects/backgroundcontrast/contrast.cpp:387
#19 0x00007fcc673400ee in KWin::EffectsHandlerImpl::drawWindow (this=0x387cb70, w=w@entry=0x1ceb000, mask=mask@entry=1, region=..., data=...)
    at /usr/src/debug/kwin-5.5.2/effects.cpp:499
#20 0x00007fcc648476d2 in KWin::BlurEffect::drawWindow (this=this@entry=0x170e930, w=w@entry=0x1ceb000, mask=mask@entry=1, region=..., data=...)
    at /usr/src/debug/kwin-5.5.2/effects/blur/blur.cpp:450
#21 0x00007fcc673400ee in KWin::EffectsHandlerImpl::drawWindow (this=0x387cb70, w=w@entry=0x1ceb000, mask=mask@entry=1, region=..., data=...)
    at /usr/src/debug/kwin-5.5.2/effects.cpp:499
#22 0x00007fcc64d1ebb1 in KWin::Effect::drawWindow (this=this@entry=0x3831b40, w=w@entry=0x1ceb000, mask=mask@entry=1, region=..., data=...)
    at /usr/src/debug/kwin-5.5.2/libkwineffects/kwineffects.cpp:582
#23 0x00007fcc673400ee in KWin::EffectsHandlerImpl::drawWindow (this=0x387cb70, w=w@entry=0x1ceb000, mask=mask@entry=1, region=..., data=...)
    at /usr/src/debug/kwin-5.5.2/effects.cpp:499
#24 0x00007fcc673147c1 in KWin::Scene::finalPaintWindow (this=<optimized out>, w=w@entry=0x1ceb000, mask=mask@entry=1, region=..., data=...)
    at /usr/src/debug/kwin-5.5.2/scene.cpp:606
#25 0x00007fcc6733ff9a in KWin::EffectsHandlerImpl::paintWindow (this=0x387cb70, w=w@entry=0x1ceb000, mask=mask@entry=1, region=..., data=...)
    at /usr/src/debug/kwin-5.5.2/effects.cpp:465
#26 0x00007fcc64d1ea91 in KWin::Effect::paintWindow (this=this@entry=0x1634db0, w=w@entry=0x1ceb000, mask=mask@entry=1, region=..., data=...)
    at /usr/src/debug/kwin-5.5.2/libkwineffects/kwineffects.cpp:552
#27 0x00007fcc6733ff4e in KWin::EffectsHandlerImpl::paintWindow (this=0x387cb70, w=w@entry=0x1ceb000, mask=mask@entry=1, region=..., data=...)
    at /usr/src/debug/kwin-5.5.2/effects.cpp:462
#28 0x00007fcc64d1ea91 in KWin::Effect::paintWindow (this=this@entry=0x170e930, w=w@entry=0x1ceb000, mask=mask@entry=1, region=..., data=...)
    at /usr/src/debug/kwin-5.5.2/libkwineffects/kwineffects.cpp:552

AFAICS, in #8, ctx should not be 0x0 when calling eglCreateImageKHR.
With the GLX backend, the application is a huge rectangle, as expected.

Reproducible: Always

Steps to Reproduce:
1. Start kwin_x11 with gdb
2. QT_DEVICE_PIXEL_RATIO=100 marble
Comment 1 Thomas Lübking 2016-01-09 20:38:46 UTC 
Nope, EGL_NO_CONTEXT (ie. 0x0) is deliberate.
I assume this crashes in the driver for a simple OOM condition -> driver bug (more or less)

@Martin, maybe we should have a sanity check here as well (ie. if it exceeds the max texture size anyway, there's no point in loading it - I assume this happens on glx, preventing the crash with a giant invalid texture)?
Comment 2 Martin Flöser 2016-01-11 11:18:24 UTC 
obviously the driver shouldn't crash on a too large pixmap. Given that I'm not sure whether we should check for a work around. After all there might be many more crashy conditions in the driver code.

Anyway: I think that should go to upstream bug tracker. Adding a test case for it should be relatively easy - for once in a while we actually know what triggered the crash.
Comment 3 Fabian Vogt 2016-01-11 12:30:14 UTC 
(In reply to Martin Gräßlin from comment #2)
> Anyway: I think that should go to upstream bug tracker. Adding a test case
> for it should be relatively easy - for once in a while we actually know what
> triggered the crash.

Ok, reported as https://bugs.freedesktop.org/show_bug.cgi?id=93667
Should I leave this report open until it's fixed in Mesa?
Comment 4 Thomas Lübking 2016-01-11 15:42:37 UTC 
For the moment, there's little point in this since atm. there's no consideration to workaround this (and it's rather a corner case by accidentally causing OOM conditions in the driver)

It's a driver bug per
* If insufficient memory is available to complete the specified
         operation, the error EGL_BAD_ALLOC is generated.

Iff the driver devs should be unable to fix it, one might pitch for a workaround again (then just re-open the bug, rant about stubborn driver devs etc. and we'll see what to do about it ;-)