Bug 152845 - plasma crashes on closing "3d earth model" widget
Summary: plasma crashes on closing "3d earth model" widget
Status: RESOLVED FIXED
Alias: None
Product: plasma4
Classification: Unmaintained
Component: widget-misc (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR crash
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 155316 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-25 01:44 UTC by Marcin Ślusarz
Modified: 2008-07-04 18:09 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Fuller backtrace (2.15 KB, text/plain)
2007-12-25 20:12 UTC, Simon St James
Details
Backtrace (4.0.3/Kubuntu/amd64) (6.10 KB, text/plain)
2008-04-03 16:16 UTC, Martin Fitzpatrick
Details
Backtrace (4.0.3/Kubuntu/amd64) (2.36 KB, text/plain)
2008-04-09 16:01 UTC, Martin Fitzpatrick
Details
plasma crash backtrace on debian/experimental/amd64 (4.35 KB, text/plain)
2008-05-04 16:35 UTC, Bastian M. Wojek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcin Ślusarz 2007-11-25 01:44:43 UTC
Version:           rev 740861 (using KDE Devel)
Installed from:    Compiled sources
OS:                Linux

when i add "3d earth model" widget it says:
"This object could not be created for the following reason:
OpenGL Shaders not supported"

so i click 'X' and plasma crashes with the following backtrace:

Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1238411568 (LWP 3902)]
[KCrash handler]
#6  0x00000000 in ?? ()
#7  0xb7e0e9d2 in QGLPixelBufferPrivate::cleanup ()
   from /storage/tmp/kde4dev/qt-unstable/lib/libQtOpenGL.so.4
#8  0xb7e04727 in QGLPixelBuffer::~QGLPixelBuffer ()
   from /storage/tmp/kde4dev/qt-unstable/lib/libQtOpenGL.so.4
#9  0xb7f29995 in ~Private (this=0x84d4578)
    at /storage/tmp/kde4dev/kdebase/workspace/libs/plasma/glapplet.cpp:37
#10 0xb7f295e8 in ~GLApplet (this=0x85c1558)
    at /storage/tmp/kde4dev/kdebase/workspace/libs/plasma/glapplet.cpp:86
#11 0xb43d97bf in ~BlueMarble (this=0x85c1558)
    at /storage/tmp/kde4dev/plasma-extragear/applets/bluemarble/bluemarble.cpp:60
#12 0xb747c7a1 in QObject::event ()
   from /storage/tmp/kde4dev/qt-unstable/lib/libQtCore.so.4
#13 0xb6c49f51 in QApplicationPrivate::notify_helper ()
   from /storage/tmp/kde4dev/qt-unstable/lib/libQtGui.so.4
#14 0xb6c4a252 in QApplication::notify ()
   from /storage/tmp/kde4dev/qt-unstable/lib/libQtGui.so.4
#15 0xb7a15a1b in KApplication::notify (this=0x8060540, receiver=0x85c1558,
    event=0x858b9d0)
    at /storage/tmp/kde4dev/kdelibs/kdeui/kernel/kapplication.cpp:319
#16 0xb746a356 in QCoreApplication::notifyInternal ()
   from /storage/tmp/kde4dev/qt-unstable/lib/libQtCore.so.4
#17 0xb746d725 in QCoreApplication::sendEvent ()
   from /storage/tmp/kde4dev/qt-unstable/lib/libQtCore.so.4
#18 0xb746a82d in QCoreApplicationPrivate::sendPostedEvents ()
   from /storage/tmp/kde4dev/qt-unstable/lib/libQtCore.so.4
#19 0xb746a983 in QCoreApplication::sendPostedEvents ()
   from /storage/tmp/kde4dev/qt-unstable/lib/libQtCore.so.4
#20 0xb7493d99 in postEventSourceDispatch ()
   from /storage/tmp/kde4dev/qt-unstable/lib/libQtCore.so.4
#21 0xb64a8df2 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#22 0xb64abdcf in ?? () from /usr/lib/libglib-2.0.so.0
#23 0x0807c498 in ?? ()
#24 0x00000000 in ?? ()
#0  0xffffe410 in __kernel_vsyscall ()

i'm using kde4daily rev 740861
Comment 1 Pino Toscano 2007-12-05 11:11:10 UTC
Re-unconfirm (owner changing confirmed the bug).
Comment 2 Yitzchak Schwarz 2007-12-11 01:42:13 UTC
I have the same problem.
Comment 3 Jason Stubbs 2007-12-21 13:38:09 UTC
Not playground but extragear according to directories in the traceback...
Comment 4 Jason Stubbs 2007-12-21 15:25:51 UTC
I can't reproduce this and can't see how its possible from the code. But I did just notice one thing in the traceback:

from /storage/tmp/kde4dev/qt-unstable/lib/libQtOpenGL.so.4

Please reopen if this can be reproduced with KDE HEAD and a stable Qt.
Comment 5 Marcin Ślusarz 2007-12-21 19:49:55 UTC
rejecting reports from kde4daily users is not the best way to encourage more testing...

Comment 6 Riccardo Iaconelli 2007-12-21 21:39:22 UTC
We're sorry, we're not rejecting because "it's from KDE4Daily" but because we are not able to reproduce it, and this problem seems to happen just when using the image in the virtual machine.
If we can do something to fix it on a "normal" system, and the first step to do something is actually reproduce it, we'll surely have a look at the bug, reopen this report, and try to fix it. =)

I hope you will understand, we're working hard to bring Plasma into a releaseble state. =)
Comment 7 Jason Stubbs 2007-12-22 02:53:48 UTC
kde4daily uses an unstable qt? I will ask the maintainer exactly what he's using then. Looking at the traceback, the issue looks like it's occuring within Qt.
Comment 8 Marcin Ślusarz 2007-12-22 20:28:26 UTC
Riccardo: I understand it now. Thanks for clarification.
Comment 9 Jason Stubbs 2007-12-25 13:14:09 UTC
qt-unstable is apparently just an artifact of building kde4 for so long and it's actually qt-copy. However, this does look to be a qt bug when tracing things out so what should be done with it?
Comment 10 Simon St James 2007-12-25 20:12:46 UTC
Created attachment 22677 [details]
Fuller backtrace

Since this is no longer INVALID, here's a fuller backtrace including Qt calls.
Comment 11 Alex Merry 2008-01-05 22:32:36 UTC
If it is a Qt bug, it should go to qt-bugs@trolltech.com
Comment 12 Aaron J. Seigo 2008-01-11 00:31:45 UTC
*** Bug 155316 has been marked as a duplicate of this bug. ***
Comment 13 Robin Kjeld 2008-03-02 03:33:39 UTC
I have this issue as well
Comment 14 Rex Dieter 2008-03-04 15:48:15 UTC
Seeing this in fedora as well:
http://bugzilla.redhat.com/435656
For me, it kills the entire desktop/session, not just plasma.  crazy, wierd that is.
Comment 15 Martin Fitzpatrick 2008-04-03 16:16:29 UTC
Created attachment 24164 [details]
Backtrace (4.0.3/Kubuntu/amd64)
Comment 16 Martin Fitzpatrick 2008-04-03 16:19:15 UTC
Confirmed on 4.0.3/Kubuntu/amd64. On this system adding the widget works fine, but displays the "OpenGL Shaders not supported" message in the standard plasma frame. Only when closing the applet does it crash, bringing down plasma and the taskmanager (on taskbar). Restarting plasma works fine (minus taskmanager).
Comment 17 Martin Fitzpatrick 2008-04-09 16:01:05 UTC
Created attachment 24280 [details]
Backtrace (4.0.3/Kubuntu/amd64)
Comment 18 Akarsh Simha 2008-04-18 09:43:30 UTC
I have this issue as well. It happened when the 'Chemical Data' widget could not be created and I tried to close it.

I can produce the backtrace if required.

This is from a fresh build that I did yesterday from the SVN.
Comment 19 Bastian M. Wojek 2008-05-04 16:35:03 UTC
Created attachment 24627 [details]
plasma crash backtrace on debian/experimental/amd64

I see a similar behavior when closing any widget (tried kalgebra and trashcan).

I'm using plasma and extragear-plasma 4.0.72+svn802997/amd64 from
debian/experimental.
Comment 20 premierSullivan 2008-05-15 23:14:37 UTC
Confirmed here, crashes on remove.  My version of kde was head a week ago, compiled from source.  Run as a full user on a full X session, not as a virtual machine.  I have the latest ubuntu nVidia drivers on an 8800GT, which runs any composting just fine... I find it very unlikely that I don't have openGL shader support.
Comment 21 Anne-Marie Mahfouf 2008-05-16 08:46:23 UTC
The applet runs fine here. I have the nvidia proprietary driver 1.0-9639
Running the nvidia-settings dialog gives me GL_EXT_Cg_shader as OpenGL extension.

Running plasma from Konsole, when I add the 3D Earth Model, I get as output in konsole:
[kde4@localhost ~]$ plasma(6247)/libplasma PlasmaAppletItemModel::mimeData: GETTING MIME DATA
plasma(6247)/libplasma CustomDragTreeView::startDrag: Size:  112  Off:  16                   
plasma(6247) BlueMarble::initializeGL:                                                       
plasma(6247) BlueMarble::initializeGL: Loading shader                                        
plasma(6247) BlueMarble::initializeGL: Initing shader                                        
plasma(6247) BlueMarble::initializeGL: Loading atmosphere shader 

and when I remove it I get no crash.

Can all nvidia users check if you have the same? Can you check the nvidia OpenGL options you have? If you have the crash, please check and report the output from running plasma from a terminal and adding and removing the applet. (kquitapp plasma and plasma in a terminal will run plasma from there)
Comment 22 Sebastian Sauer 2008-06-04 04:18:13 UTC
* Backtrace from comment #19 is a dup of bug #162018 and comment #20 confirms the other bug
* last known version where it happens is 4.0.3, anybody who's able to reproduce it in 4.1-beta1 or later?
Comment 23 Sebastian Sauer 2008-06-24 09:35:47 UTC
ok, I mark this report now as closed cause it seems noone is able to reproduce this any longer (judging from the missing feedback to comment #21 :-)
if there is still someone able to reproduce this, please reopen the report and provide us some additional details like what KDE4-version, like details about your nvidia-driver, etc. Thanks in advance.
Comment 24 Kevin Kofler 2008-07-04 15:24:59 UTC
Uh, the bug report was about the applet crashing (instead of failing gracefully) when you do NOT have the required OpenGL shaders. So the people who should test this are people who are NOT using the proprietary nvidia driver.

I also question the usefulness of having an applet in kdeplasmoids which only works with proprietary software.
Comment 25 Jason Stubbs 2008-07-04 15:37:06 UTC
for what it's worth, i couldn't reproduce this when using mesa opengl way back when. with mesa, it came up saying that the applet couldn't be initialized or some such after which i was able to remove it.
Comment 26 Aaron J. Seigo 2008-07-04 18:09:10 UTC
yes, it works properly here on my machine that doesn't have the necessary GL features.

btw, there's nothing inherently proprietary about programmable shaders. it's just that the only driver that currently implements this feature on x.org is proprietary; but it's part of the openGL spec and an open driver could just as easily support them as well.