Application: kwin (4.8.4 (4.8.4)) KDE Platform Version: 4.8.4 (4.8.4) (Compiled from sources) Qt Version: 4.8.1 Operating System: Linux 3.2.0-26-generic x86_64 Distribution: Ubuntu 12.04 LTS -- Information about the crash: - What I was doing when the application crashed: When running some KDE progs and additionally starting bleachbit, all progs crashed. 8GB memory available. digiKam 4.6 taking about 4 GB KDE should think seriously about reliabitity and rock solid progs instead of pushing "versio mania..." The crash can be reproduced some of the time. -- Backtrace: Application: KWin (kwin), signal: Bus error Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7f00c4293780 (LWP 2149))] Thread 3 (Thread 0x7f00a8a01700 (LWP 2209)): #0 0x00007f00c3a9d823 in select () at ../sysdeps/unix/syscall-template.S:82 #1 0x00007f00bf2ed366 in qt_safe_select (nfds=18, fdread=0x7f009c000ac8, fdwrite=0x7f009c000d60, fdexcept=0x7f009c000ff8, orig_timeout=<optimized out>) at kernel/qcore_unix.cpp:83 #2 0x00007f00bf2f27b2 in QEventDispatcherUNIXPrivate::doSelect (this=0x7f009c000910, flags=..., timeout=0x0) at kernel/qeventdispatcher_unix.cpp:223 #3 0x00007f00bf2f2ca3 in QEventDispatcherUNIX::processEvents (this=0x7f009c0008f0, flags=...) at kernel/qeventdispatcher_unix.cpp:926 #4 0x00007f00bf2bfc82 in QEventLoop::processEvents (this=<optimized out>, flags=...) at kernel/qeventloop.cpp:149 #5 0x00007f00bf2bfed7 in QEventLoop::exec (this=0x7f00a8a00dd0, flags=...) at kernel/qeventloop.cpp:204 #6 0x00007f00bf1befa7 in QThread::exec (this=<optimized out>) at thread/qthread.cpp:501 #7 0x00007f00bf29f9ff in QInotifyFileSystemWatcherEngine::run (this=0x12279b0) at io/qfilesystemwatcher_inotify.cpp:248 #8 0x00007f00bf1c1fcb in QThreadPrivate::start (arg=0x12279b0) at thread/qthread_unix.cpp:298 #9 0x00007f00b83e7e9a in start_thread (arg=0x7f00a8a01700) at pthread_create.c:308 #10 0x00007f00c3aa44bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #11 0x0000000000000000 in ?? () Thread 2 (Thread 0x7f00a3fff700 (LWP 2210)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x00007f00c055a222 in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4 #2 0x00007f00c055a259 in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4 #3 0x00007f00b83e7e9a in start_thread (arg=0x7f00a3fff700) at pthread_create.c:308 #4 0x00007f00c3aa44bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #5 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f00c4293780 (LWP 2149)): [KCrash Handler] #6 0x00007f00bfad2fc5 in lock (this=<optimized out>) at ../../kdecore/util/kshareddatacache.cpp:1231 #7 KSharedDataCache::Private::CacheLocker::cautiousLock (this=0x7fffc8095100) at ../../kdecore/util/kshareddatacache.cpp:1255 #8 0x00007f00bfad3b50 in KSharedDataCache::Private::CacheLocker::CacheLocker (this=0x7fffc8095100, _d=<optimized out>) at ../../kdecore/util/kshareddatacache.cpp:1278 #9 0x00007f00bfacd156 in KSharedDataCache::find (this=0x110cc90, key=..., destination=0x7fffc80951d0) at ../../kdecore/util/kshareddatacache.cpp:1630 #10 0x00007f00c352d019 in KIconLoaderPrivate::findCachedPixmapWithPath (this=0x10f2950, key=..., data=..., path=...) at ../../kdeui/icons/kiconloader.cpp:861 #11 0x00007f00c352d392 in KIconLoader::loadIcon (this=0x10ad9e0, _name=..., group=KIconLoader::Small, size=32, state=0, overlays=..., path_store=0x0, canReturnNull=true) at ../../kdeui/icons/kiconloader.cpp:1225 #12 0x00007f00c36b363c in KWindowSystem::icon (win=56623202, width=32, height=32, scale=true, flags=12) at ../../kdeui/windowmanagement/kwindowsystem_x11.cpp:688 #13 0x00007f00c3dbd662 in KWin::Client::getIcons (this=0x1220890) at ../../kwin/client.cpp:2066 #14 0x00007f00c3dea65b in KWin::Client::manage (this=0x1220890, w=<optimized out>, isMapped=false) at ../../kwin/manage.cpp:135 #15 0x00007f00c3db0d12 in KWin::Workspace::createClient (this=<optimized out>, w=56623202, is_mapped=false) at ../../kwin/workspace.cpp:569 #16 0x00007f00c3ddb952 in KWin::Workspace::workspaceEvent (this=0x11da720, e=0x7fffc8096510) at ../../kwin/events.cpp:358 #17 0x00007f00c3dcd4b8 in KWin::Application::x11EventFilter (this=0x7fffc8096820, e=0x7fffc8096510) at ../../kwin/main.cpp:359 #18 0x00007f00be6b2b85 in qt_x11EventFilter (ev=0x7fffc8096510) at kernel/qapplication_x11.cpp:441 #19 qt_x11EventFilter (ev=0x7fffc8096510) at kernel/qapplication_x11.cpp:429 #20 0x00007f00be6c1f98 in QApplication::x11ProcessEvent (this=0x7fffc8096820, event=0x7fffc8096510) at kernel/qapplication_x11.cpp:3444 #21 0x00007f00be6ecb3a in QEventDispatcherX11::processEvents (this=0xfeaad0, flags=...) at kernel/qeventdispatcher_x11.cpp:132 #22 0x00007f00bf2bfc82 in QEventLoop::processEvents (this=<optimized out>, flags=...) at kernel/qeventloop.cpp:149 #23 0x00007f00bf2bfed7 in QEventLoop::exec (this=0x7fffc8096760, flags=...) at kernel/qeventloop.cpp:204 #24 0x00007f00bf2c4f67 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1148 #25 0x00007f00c3dcfc36 in kdemain (argc=<optimized out>, argv=<optimized out>) at ../../kwin/main.cpp:541 #26 0x00007f00c39d376d in __libc_start_main (main=0x400640 <main(int, char**)>, argc=3, ubp_av=0x7fffc8096f48, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffc8096f38) at libc-start.c:226 #27 0x0000000000400671 in _start () Possible duplicates by query: bug 284770. Reported using DrKonqi
*** This bug has been marked as a duplicate of bug 274741 ***
*** This bug has been marked as a duplicate of bug 254741 ***
> KDE should think seriously about reliabitity and rock solid progs instead of > pushing "versio mania..." Just don't use bleachbit. They think they are smart and delete files (caches) used by KDE applications. Of course every application crashes if you delete the files it's using. Just google for KDE and bleachbit and you will notice that it's not a good idea. I also recommend to read http://lwn.net/Articles/313679/
@Martin This is not entirely correct (I hate to do this) First off, two things /are/ correct: 1. DON'T USE BLEACHBIT! Do you really want to allow "stuff" to delete "stuff"?? Seriously, you better have a good backup system. Data in /tmp and /run is deleted with the next reboot and everything else is NOT JUNK. Logs are no junk, caches are no junk. If you *know* you won't need that log anymore or *want* to invalidate a cache, that's fine. Do so. Bleachbit does certainly neither know nor want. 2. Also the bleachbit developers apparently don't entirely know what they do - but that's inherent to the task. Now on what's wrong: *Deleting* a file (even a shared data cache!) is "harmless" (well, you just lost random data, but that's it) The kernel keeps the file hooked internally (so if you ever accidentally delete a file and have any application open that has the file handle open, you can still fetch it from /proc - someone should tell Adobe...) and the data behind file handles is not corrupted at all (but of course the memory is now tagged free and at some point sth. will be written there) What bleachbit however does (by certain configuration) is to *override* the inodes and in this case it's like writing directly into random applications memory (that's the point and flaw of SHM) As result the application memory is suddenly corrupt and about anything can happen (usually it crashes)
I do not know, if you -or someone else - right and I am wrong. That would be fine. When thinking about probabilities, the number of CONTRAS is larger than the number of PROs I just de-install bleachbit to avoid further questions on y machine. Is there a a best-practise on how to deal with date 8backup, taking care of data) and so on? Maybe some type of expert-system to be _really_ innovative on KDEs side... one could check for harmful progs on a systems automatically or ones to endanger KDE installation. Axel --- Am 10.07.2012 17:52, schrieb Thomas Lübking : > https://bugs.kde.org/show_bug.cgi?id=303308 > > --- Comment #4 from Thomas Lübking <thomas.luebking@gmail.com> --- > @Martin > This is not entirely correct (I hate to do this) > > First off, two things /are/ correct: > 1. DON'T USE BLEACHBIT! > > Do you really want to allow "stuff" to delete "stuff"?? > Seriously, you better have a good backup system. > > Data in /tmp and /run is deleted with the next reboot and everything else is > NOT JUNK. > Logs are no junk, caches are no junk. > If you *know* you won't need that log anymore or *want* to invalidate a cache, > that's fine. Do so. Bleachbit does certainly neither know nor want. > > 2. Also the bleachbit developers apparently don't entirely know what they do - > but that's inherent to the task. > > Now on what's wrong: > *Deleting* a file (even a shared data cache!) is "harmless" (well, you just > lost random data, but that's it) > The kernel keeps the file hooked internally (so if you ever accidentally delete > a file and have any application open that has the file handle open, you can > still fetch it from /proc - someone should tell Adobe...) and the data behind > file handles is not corrupted at all (but of course the memory is now tagged > free and at some point sth. will be written there) > > What bleachbit however does (by certain configuration) is to *override* the > inodes and in this case it's like writing directly into random applications > memory (that's the point and flaw of SHM) > > As result the application memory is suddenly corrupt and about anything can > happen (usually it crashes) >
Bleachbit "endangers" *everything* it didn't care about in its blacklist (afaik kde cache data was added in recent versions but that doesn't make it less harmful - there's more than KDE and Gnome) > Is there a a best-practise on how to deal with date 8backup, taking care of data) and so on? No, but there are ways for every kind of demand: https://wiki.archlinux.org/index.php/Backup > Maybe some type of expert-system to be _really_ innovative on KDEs > side... one could check for harmful progs on a systems automatically or > ones to endanger KDE installation. Yes, please. Let's have virus scanners. /sarcasm Bleachbit is not malware but just "dangerous" - so is dd. And nc can turn your box into a drone. The approach is to not install and run stuff you do not understand - otherwise everything can be harmful, on every operating system - and virus scanners on windows increase their false positives - mostly because the signature amount is meanwhile /that/ large that clashes are unavoidable. PS: you reply to a bugtracker, please don't quote and in case you seek deeper discussion on this topic head over to forum.kde.org