Application: kwin (4.10.00) KDE Platform Version: 4.10.00 Qt Version: 4.8.4 Operating System: Linux 3.8.0-rc7-cmr x86_64 Distribution: "Arch Linux" -- Information about the crash: - What I was doing when the application crashed: KWin was starting from KDM - Unusual behavior I noticed: Screen flashed once with (what seemed to be) some corrupted texture. - Custom settings of the application: Effects enabled: zoom, dashboard, fade, highlight window, login, logout, maximize, maximize animation, screenshot, slide, sliding popups, taskbar thumbnails, translucency, startup feedback, dialog parent, cover switch, desktop grid, outline, present windows Happens with stock arch package as well, but I compiled extra/kdebase-workspace from the ABS The crash can be reproduced every time. -- Backtrace: Application: KWin (kwin), signal: Bus error Using host libthread_db library "/usr/lib/libthread_db.so.1". [Current thread is 1 (Thread 0x7ff32b2a9780 (LWP 630))] Thread 5 (Thread 0x7ff307f14700 (LWP 633)): #0 0x00007ff325b14d01 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x00007ff325da0d37 in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQtCore.so.4 #2 0x00007ff325d9454f in ?? () from /usr/lib/libQtCore.so.4 #3 0x00007ff325da087c in ?? () from /usr/lib/libQtCore.so.4 #4 0x00007ff325b10e0f in start_thread () from /usr/lib/libpthread.so.0 #5 0x00007ff32aaecefd in clone () from /usr/lib/libc.so.6 Thread 4 (Thread 0x7ff3074fd700 (LWP 634)): #0 0x00007ff325b14954 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x00007ff32738e7a7 in ?? () from /usr/lib/libQtScript.so.4 #2 0x00007ff32738e7d9 in ?? () from /usr/lib/libQtScript.so.4 #3 0x00007ff325b10e0f in start_thread () from /usr/lib/libpthread.so.0 #4 0x00007ff32aaecefd in clone () from /usr/lib/libc.so.6 Thread 3 (Thread 0x7ff30633b700 (LWP 635)): #0 0x00007ff325b14d01 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x00007ff325da0d37 in QWaitCondition::wait(QMutex*, unsigned long) () from /usr/lib/libQtCore.so.4 #2 0x00007ff325d9454f in ?? () from /usr/lib/libQtCore.so.4 #3 0x00007ff325da087c in ?? () from /usr/lib/libQtCore.so.4 #4 0x00007ff325b10e0f in start_thread () from /usr/lib/libpthread.so.0 #5 0x00007ff32aaecefd in clone () from /usr/lib/libc.so.6 Thread 2 (Thread 0x7ff304ebd700 (LWP 641)): #0 0x00007ff325b14954 in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 #1 0x00007ff276f0cedb in radeon_drm_cs_emit_ioctl () from /usr/lib/xorg/modules/dri/r600_dri.so #2 0x00007ff325b10e0f in start_thread () from /usr/lib/libpthread.so.0 #3 0x00007ff32aaecefd in clone () from /usr/lib/libc.so.6 Thread 1 (Thread 0x7ff32b2a9780 (LWP 630)): [KCrash Handler] #5 0x00007ff32aa8b59b in __memset_sse2 () from /usr/lib/libc.so.6 #6 0x00007ff276ef768f in r600_texture_create_object () from /usr/lib/xorg/modules/dri/r600_dri.so #7 0x00007ff276ef7967 in r600_texture_create () from /usr/lib/xorg/modules/dri/r600_dri.so #8 0x00007ff276f09d35 in dri2_allocate_textures () from /usr/lib/xorg/modules/dri/r600_dri.so #9 0x00007ff276f08865 in dri_st_framebuffer_validate () from /usr/lib/xorg/modules/dri/r600_dri.so #10 0x00007ff276f08a8e in dri_set_tex_buffer2 () from /usr/lib/xorg/modules/dri/r600_dri.so #11 0x00007ff32ae7ce02 in KWin::GlxTexture::loadTexture(unsigned long const&, QSize const&, int) () from /usr/lib/libkdeinit4_kwin.so #12 0x00007ff32ae749d5 in KWin::SceneOpenGL::Window::bindTexture() () from /usr/lib/libkdeinit4_kwin.so #13 0x00007ff32ae7b048 in KWin::SceneOpenGL::Window::performPaint(int, QRegion, KWin::WindowPaintData) () from /usr/lib/libkdeinit4_kwin.so #14 0x00007ff32ae73d9f in KWin::SceneOpenGL2::performPaintWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib/libkdeinit4_kwin.so #15 0x00007ff32ae73f4e in KWin::SceneOpenGL2::finalDrawWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib/libkdeinit4_kwin.so #16 0x00007ff32ae87e55 in KWin::EffectsHandlerImpl::drawWindow(KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib/libkdeinit4_kwin.so #17 0x00007ff32ae66fca in KWin::Scene::finalPaintWindow(KWin::EffectWindowImpl*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib/libkdeinit4_kwin.so #18 0x00007ff32ae880d7 in KWin::EffectsHandlerImpl::paintWindow(KWin::EffectWindow*, int, QRegion, KWin::WindowPaintData&) () from /usr/lib/libkdeinit4_kwin.so #19 0x00007ff32ae69b77 in KWin::Scene::paintWindow(KWin::Scene::Window*, int, QRegion, KWin::WindowQuadList) () from /usr/lib/libkdeinit4_kwin.so #20 0x00007ff32ae68e9d in KWin::Scene::paintSimpleScreen(int, QRegion) () from /usr/lib/libkdeinit4_kwin.so #21 0x00007ff32ae66f0e in KWin::Scene::finalPaintScreen(int, QRegion, KWin::ScreenPaintData&) () from /usr/lib/libkdeinit4_kwin.so #22 0x00007ff32ae882a0 in KWin::EffectsHandlerImpl::paintScreen(int, QRegion, KWin::ScreenPaintData&) () from /usr/lib/libkdeinit4_kwin.so #23 0x00007ff32ae68298 in KWin::Scene::paintScreen(int*, QRegion*) () from /usr/lib/libkdeinit4_kwin.so #24 0x00007ff32ae779ce in KWin::SceneOpenGL::paint(QRegion, QList<KWin::Toplevel*>) () from /usr/lib/libkdeinit4_kwin.so #25 0x00007ff32ae6266c in KWin::Compositor::performCompositing() () from /usr/lib/libkdeinit4_kwin.so #26 0x00007ff32ae63130 in KWin::Compositor::slotCompositingOptionsInitialized() () from /usr/lib/libkdeinit4_kwin.so #27 0x00007ff325eb2b8f in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4 #28 0x00007ff325d91487 in QFutureWatcherBase::event(QEvent*) () from /usr/lib/libQtCore.so.4 #29 0x00007ff32503018c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #30 0x00007ff32503460a in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #31 0x00007ff32a5de426 in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5 #32 0x00007ff325e9d6ae in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4 #33 0x00007ff325ea1011 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQtCore.so.4 #34 0x00007ff3250d131c in ?? () from /usr/lib/libQtGui.so.4 #35 0x00007ff325e9c3ff in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #36 0x00007ff325e9c688 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #37 0x00007ff325ea1328 in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4 #38 0x00007ff32ae18f1a in kdemain () from /usr/lib/libkdeinit4_kwin.so #39 0x00007ff32aa25a15 in __libc_start_main () from /usr/lib/libc.so.6 #40 0x0000000000400701 in _start () Reported using DrKonqi
crashes in driver. You should report on the driver's bugtracker but please make sure to install debug symbols.
*** Bug 316949 has been marked as a duplicate of this bug. ***
*** Bug 317162 has been marked as a duplicate of this bug. ***
*** Bug 317140 has been marked as a duplicate of this bug. ***
Upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=61182
*** Bug 316393 has been marked as a duplicate of this bug. ***
*** Bug 317963 has been marked as a duplicate of this bug. ***
According to the upstream bug report, this is also a KWin bug, as it should not select MSAA visuals.
https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/6cf057777555a5d0c834de3a0165a62916cf3b40
Patch does not seem to be in master, pot. unmerged 4.9 only commit?
Nope, lost with very recent updates in git master only. 4.10 should *not* be using MSAA visuals (unless there's no other visual available - can someone with this bug please attach the output of "glxinfo", thanks)
Created attachment 78755 [details] glxinfo output
Nope, the only 32bit config (with matching visual) is not tagged MSAA. Can you apply a patch to check which buffer is picked and its MSAA size?
(In reply to comment #13) yes, will be happy to help
Git commit a021eacfbd2f2e8cb1f1caf1b66204880c1e7992 by Fredrik Höglund. Committed on 09/04/2013 at 18:55. Pushed by fredrik into branch 'KDE/4.10'. kwin/glx: Avoid MSAA configs in initDrawableConfigs() This is the same fix that was applied to initBufferConfigs() in commit 6cf057777555a5d0c834de3a0165a62916cf3b40. M +18 -1 kwin/glxbackend.cpp http://commits.kde.org/kde-workspace/a021eacfbd2f2e8cb1f1caf1b66204880c1e7992
(In reply to comment #15) > Git commit a021eacfbd2f2e8cb1f1caf1b66204880c1e7992 by Fredrik Höglund. Do not see crashes anymore with these changes. Thanks!
*** Bug 318219 has been marked as a duplicate of this bug. ***
*** Bug 318252 has been marked as a duplicate of this bug. ***
*** Bug 318256 has been marked as a duplicate of this bug. ***
*** Bug 318286 has been marked as a duplicate of this bug. ***
Hi, I'm currently also running Fedora 18 and updated kde to 4.10.2 from updates-testing. This version contains the commit from comment #15 - i've checked the source -, but for me kwin still crashes. Backtrace is identical to the one of the original poster. Martin Kho KDE: 4.10.2 kde-workspace-4.10.2-4.fc18.x86_64 HW: Radeon HD 6570 Mesa: 9.1-3.fc18.x86_64 Kernel: 3.8.7-201.fc18.x86_64
(In reply to comment #21) > I'm currently also running Fedora 18 and updated kde to 4.10.2 from > updates-testing. This version contains the commit from comment #15 The patch selects the minimum msaa buffer - that's not necessarily 0 (check glxinfo) for all outputs. Despite that, the problem are insufficient resources to map - in the apparent original case - an entire msaa buffer. I assume there could be different causes, though. -> Does only happen at startup? -> Does it also happen if you start to a naked X (only xterm) and launch just kwin there?
Hi Thomas, >> -> Does only happen at startup? Yes >> -> Does it also happen if you start to a naked X (only xterm) and launch just kwin there? No Martin Kho Btw.: I'v 2 24" monitors connected to my computer, 1 via hdmi and 1 via DVI. Disconnecting one monitor 'solves' the issue.
OP here. I also have two 1080p monitors hooked up, both via DVI, perhaps that is related? (Would be good information for upstream I think).
(In reply to comment #23) > >> -> Does it also happen if you start to a naked X (only xterm) and launch just kwin there? > No What if you disable the login effect and log into normal KDE? If it doesn't help, create ~/.kde/share/autostart/plasma-netbook.desktop (eventually .../.kde4/...) ------- snip ----------- [Desktop Entry] Exec=plasma-netbook Hidden=true OnlyShowIn=KDE; X-KDE-autostart-phase=BaseDesktop ------- /snip ----------- This will prevent plasma-desktop (wallpaper, panels) from starting up (i've seen it, resp. panels doing hefty resizes at startup - just a wild guess)
Hi, 1. Disabeling the login effect has no effect. Still crash. 2. Starting plasma-netbook does not crash, but it's only visable on one monitor. So I'm no sure if the resizes are a problem. Martin Kho
FYI: Jerome Glisse created a patch to prevent cogl from using multisample visual config for front or pixmap [1]. If I read the patch correct, Jerome totally excludes msaa visuals. Btw. I haven't tried his patch. Martin Kho [1] https://mail.gnome.org/archives/commits-list/2013-January/msg09862.html
(In reply to comment #27) > FYI: > Jerome Glisse created a patch to prevent cogl from using multisample visual config for front or pixmap [1]. To know whether here actually might a MSAA buffer be selected (ie. there simply is no non-msaa buffer for at least one depth) one had to see the output of glxinfo (eg. in Eugenes attachment there's a non MSAA 32 & 24 bit visual and buffer) You could try tro restrict the maximum size of plasma-desktop (panels) to sth. "reasonable" (ie. eg. screen "1920,64" or so) - do you use the blur effect?
(In reply to comment #28) > (In reply to comment #27) > > FYI: > To know whether here actually might a MSAA buffer be selected (ie. there > simply is no non-msaa buffer for at least one depth) one had to see the > output of glxinfo (eg. in Eugenes attachment there's a non MSAA 32 & 24 bit > visual and buffer) I tried Fedora 18 Gnome, but couldn't get it crashing when in normal operation. In the report at freedesktop.org someone had crashes with a rotated screen. I also got the "Oh no ..." messages. Not sure it's related. > You could try tro restrict the maximum size of plasma-desktop (panels) to > sth. "reasonable" (ie. eg. screen "1920,64" or so) - do you use the blur > effect? I've tried to turn off all effects one by one. No difference, still log in crashes. Totally disable desktop effects is the only way to stop them. In auto mode my resolutions are as follows: Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 16384 x 16384 HDMI-0 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 60.0*+ 1920x1080 50.0 60.0 1600x1200 60.0 1680x1050 59.9 1280x1024 60.0 1440x900 59.9 1280x960 60.0 1280x800 59.9 1280x720 50.0 60.0 1024x768 60.0 800x600 60.3 56.2 720x576 50.0 720x480 59.9 640x480 60.0 DVI-0 connected 1920x1200+1920+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 60.0*+ 1920x1080 60.0 1600x1200 60.0 1680x1050 59.9 1280x1024 60.0 1280x960 60.0 1024x768 60.0 800x600 60.3 640x480 60.0 720x400 70.1 VGA-0 disconnected (normal left inverted right x axis y axis) When choosing 1680x1050 for both monitors kwin crashes two times, which results in a black screen. I'm not sure if this is what you ment by 'sth. "reasonable"'? Martin Kho Btw. I get more and more the feeling that the crashes are not a kwin issue, but solely a mesa c.q. r600g driver problem. In Fedora 17 - same kde version - I've never had such crashes. IMHO mesa broke kwin with the addition of the msaa feature. May be it's just a matter of bad implementation?
(In reply to comment #29) > When choosing 1680x1050 for both monitors kwin crashes two times, which > results in a black screen. I'm not sure if this is what you ment by 'sth. > "reasonable"'? Errr.. I meant restricting the size of particular (pot. plasma: desktop & panels) windows through "kcmshell4 kwinrules". Esp. autohiding panels do "weird" stuff here and due to your findings reg. starting only kwin, i wonder whether this is because of a window (temporarily) growing to an enormous size (leading to the OOM, thus mapping condition) > Btw. I get more and more the feeling that the crashes are not a kwin issue, > but solely a mesa c.q. r600g driver problem. Yes is. The crash itself happens when the driver tries to map memory. Of course MSAA buffers are prone to cause such (because of their memory demands) but even *if* KWin would still pick MSAA buffers (attach your glxinfo and i can tell you ;-) this should no way lead to a crash (we would not want to do so, because it slows things down) in the driver.
Created attachment 79029 [details] glxinfo (mesa 9.1) Hi Thomas, I overlooked this question. Here is my glxinfo Martin Kho
More like a hint ;-) With the patches of comment #9 and #15 applied, no msaa buffer or config should be selected.
Created attachment 79030 [details] Gnome-shell crash backtrace FYI: As can be seen in the backtrace cogl has the same 'problem'. I'll try to find out if Jerome's patch solves this issue.
Hi, Well, I've rebuild cogl with Jerome's patch and I've to admit that gnome-shell doesn't crash when I rotate the screen. Martin Kho
(In reply to comment #34) > Hi, > > Well, I've rebuild cogl with Jerome's patch and I've to admit that > gnome-shell doesn't crash when I rotate the screen. From comment #21 it doesn't seem you built kde-workspace / kwin - how sure are you that those patches are in the build? http://pkgs.fedoraproject.org/cgit/kde-workspace.git/tree/ does not seem to suggest that at all... (at least not to me ;-)
(In reply to comment #35) > (In reply to comment #34) > > Hi, > > > > Well, I've rebuild cogl with Jerome's patch and I've to admit that > > gnome-shell doesn't crash when I rotate the screen. > From comment #21 it doesn't seem you built kde-workspace / kwin - how sure > are you that those patches are in the build? > http://pkgs.fedoraproject.org/cgit/kde-workspace.git/tree/ > does not seem to suggest that at all... (at least not to me ;-) I downloaded the srpm (from koji) , unpacked it and unpacked the tarball. I was indead surprised that the commit was in, because the source was created 31 March and glxbackend.cpp from 1 March. The patch was committed 9 April. Huh? Martin Kho
(In reply to comment #36) > was indead surprised that the commit was in, because the source was created > 31 March and glxbackend.cpp from 1 March. The patch was committed 9 April. > Huh? There 're two similar locations where this applies - once for the visual configs (comment #15) and once for the buffer objects (comment #9 - there's also been a source refactor inbetween) - watch out for GLXFBConfig *fbconfigs = glXGetFBConfigs(display(), DefaultScreen(display()), &cnt); at the msaa check in glxbackend.cpp resp. that they occur in ::initDrawableConfigs()
(In reply to comment #37) > (In reply to comment #36) > > was indead surprised that the commit was in, because the source was created > > 31 March and glxbackend.cpp from 1 March. The patch was committed 9 April. > > Huh? > > There 're two similar locations where this applies - once for the visual > configs (comment #15) and once for the buffer objects (comment #9 - there's > also been a source refactor inbetween) - watch out for > > GLXFBConfig *fbconfigs = glXGetFBConfigs(display(), > DefaultScreen(display()), &cnt); > > at the msaa check in glxbackend.cpp resp. that they occur in > ::initDrawableConfigs() Hum... I see msaa_buffers/samples in initBufferConfigs() but not in initDrawableConfigs(). Ah.. I misses the second patch. I'll try to rebuild kde-workplace with the second commit. I'm afraid that this whole discussion will be very embarrassing for me :-) I'll let you know what my results will be. At least for now thanks for your patience. Martin Kho
Hi, I'm feeling very foolish :-) The commit from comment #15 indead solved my kwin crash. Now wait for the fix Marek Olšák has promised. Thanks again for the excellent work ... and sorry for the noise. Martin Kho
(In reply to comment #39) > I'm feeling very foolish :-) Nevermind - better some noise resulting in a confirmation than silence and a remaining Problem.
Hello I think I'm experiencing the same problem. As a very novice Linux (Arch) user I don't know how to check whether the fix is in the official packages or not... Just a while ago I've updated two KDE packages - kdebase-runtime and kdelibs (released today) - but the problem is still there (after full reboot), so either the patch from comment #15 is not in them or it's another problem. Could I ask which package is going to be affected by the proposed patch? There's no "kwin" package in Arch, and these two I've just updated look as the most basic so I expected them to contain the fix... Thx in advance
Would a guess that the affected package would be kdebase-workspace (currently 05.04.2013) be right? Sorry for the noise...
(In reply to comment #42) > Would a guess that the affected package would be kdebase-workspace > (currently 05.04.2013) be right? kdebase-workspace is correct, the patch will be included in 4.10.3 downstream binary packages unless explicitly backported (what would be unusual for Arch) Notice that this does NOT fix the Mesa memory mapping bug (crash cause), but only prevents KWin from picking unwanted MSAA buffers (therefore mostly bypassing the Mesa bug, though)
Thx for the info! I hope that we'll see the updated package soon (;
Created attachment 79374 [details] New crash information added by DrKonqi kwin (4.10.2) on KDE Platform 4.10.2 using Qt 4.8.4 - What I was doing when the application crashed: Screen lock, wait a half an hour, try to login. As I see by using alt-tab, all screen effects were disabled after crach, so maybe it related to gl effects -- Backtrace (Reduced): #6 __memset_sse2 () at ../sysdeps/x86_64/multiarch/../memset.S:873 #7 0x00007fb2a9ee4573 in memset (__len=<optimized out>, __ch=204, __dest=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string3.h:84 #8 r600_texture_create_object (screen=screen@entry=0x2beba80, base=base@entry=0x7fff2f31f990, pitch_in_bytes_override=pitch_in_bytes_override@entry=0, buf=buf@entry=0x0, surface=surface@entry=0x7fff2f31ec90) at r600_texture.c:509 #9 0x00007fb2a9ee4857 in r600_texture_create (screen=0x2beba80, templ=0x7fff2f31f990) at r600_texture.c:601 #10 0x00007fb2a9ef6f85 in dri2_drawable_process_buffers (att_count=1, atts=0x7fff2f31fa70, buffer_count=1, buffers=0x2991d50, drawable=0x2991df0) at dri2.c:254
*** Bug 318742 has been marked as a duplicate of this bug. ***
*** Bug 318982 has been marked as a duplicate of this bug. ***
Created attachment 79496 [details] New crash information added by DrKonqi kwin (4.10.2) on KDE Platform 4.10.2 using Qt 4.8.4 - What I was doing when the application crashed: Kde was starting after login on Fedora 18. Network was down -- Backtrace (Reduced): #6 0x00007f6ac9a5dff2 in r600_texture_create_object () from /usr/lib64/dri/r600_dri.so #7 0x00007f6ac9a5e2c7 in r600_texture_create () from /usr/lib64/dri/r600_dri.so #8 0x00007f6ac9a70a25 in dri2_allocate_textures () from /usr/lib64/dri/r600_dri.so #9 0x00007f6ac9a6f595 in dri_st_framebuffer_validate () from /usr/lib64/dri/r600_dri.so #10 0x00007f6ac9a6f7ce in dri_set_tex_buffer2 () from /usr/lib64/dri/r600_dri.so
Hi Philippe, FYI: kde-workspace-4.10.2-8.fc18 - in updates-testing - 'solves' this issue for Fedora 18. A Mesa fix is in master. HTH Martin Kho
*** Bug 318996 has been marked as a duplicate of this bug. ***
*** Bug 319098 has been marked as a duplicate of this bug. ***
*** Bug 319110 has been marked as a duplicate of this bug. ***
*** Bug 319123 has been marked as a duplicate of this bug. ***
*** Bug 319236 has been marked as a duplicate of this bug. ***
Where does that leave users of Kubuntu 13.04? Do I understand from this thread that a fix will be coming to its repos in the near-ish future? EB
(In reply to comment #55) > Where does that leave users of Kubuntu 13.04? Do I understand from this > thread that a fix will be coming to its repos in the near-ish future? > EB I talked yesterday with Kubuntu devs about this bug. They intend to backport it. I don't know exactly when this is going to happen, best have a look at launchpad.
On 05/03/2013 10:46 AM, Martin Gräßlin wrote: > https://bugs.kde.org/show_bug.cgi?id=315089 > > --- Comment #56 from Martin Gräßlin <mgraesslin@kde.org> --- > (In reply to comment #55) >> Where does that leave users of Kubuntu 13.04? Do I understand from this >> thread that a fix will be coming to its repos in the near-ish future? >> EB > I talked yesterday with Kubuntu devs about this bug. They intend to backport > it. I don't know exactly when this is going to happen, best have a look at > launchpad. > Thanks for the quick reply. My nerd skills are pretty weak and I feel quite out of my depth. I'm glad this problem is not somehow of my own doing and that smart people are solving it. Take care. EB
Kubuntu users should have a look at https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/1174495 for testing instructions. Once the fix is verified as working it should arrive in regular 13.04 updates in 7 days. Thanks.
Thank you for the update! ========== Eric L Beyer, MD Canandaigua Medical Group On May 4, 2013, at 11:07 AM, Harald Sitter <sitter@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=315089 > > Harald Sitter <sitter@kde.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |sitter@kde.org > > --- Comment #58 from Harald Sitter <sitter@kde.org> --- > Kubuntu users should have a look at > https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/1174495 for > testing instructions. > > Once the fix is verified as working it should arrive in regular 13.04 updates > in 7 days. > > Thanks. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
*** Bug 319487 has been marked as a duplicate of this bug. ***
*** Bug 319654 has been marked as a duplicate of this bug. ***
*** Bug 319692 has been marked as a duplicate of this bug. ***
*** Bug 321774 has been marked as a duplicate of this bug. ***
This bug is not fixed, still happens with kwin-4.10.4 and mesa-9.1.4 bug #322773
(In reply to comment #64) > This bug is not fixed, still happens with kwin-4.10.4 and mesa-9.1.4 bug > #322773 This has to be proven. An OOM error (on entirely different stacktrace and occasion) does not necessarily mean that it is this very issue (selecting an MSAA drawable) in the client code - just that the driver is OOM.