264738 2011-01-29 13:50:59 +0000 plasma desktop crash virtuoso-t running at 100% after nfs umount 2011-11-21 11:56:44 +0000 1 1 10 Unmaintained plasma4 desktop unspecified openSUSE Linux RESOLVED WONTFIX NOR normal --- 0 bruno plasma-bugs-null 0 oldest_to_newest 1080573 0 bruno 2011-01-29 13:50:59 +0000 Version: unspecified (using KDE 4.6.0) OS: Linux Open new bug as asked by Dario in Bug 209263 - What I was doing when the application crashed: unfortunately there's a case we can crash it. I didn't try to reproduce it actually ( takes times and must go away, but can be done at anytime ) This is how to reproduce it even wth 4.6.0 I've to explain my setup : /ioda/data can have to state, serve as mountpoint when I'm connected to my main nfs server, otherwise it's a symlink to my local synchronised (by unison) data pointing to /home/ioda_data Some of my pim data, and also nepomuk indexed folders are on this place. Reproducible: Didn't try Steps to Reproduce: So this time I've start kde with the nfs mounted. and launch the syncronizing process. No trouble. At this end of the process, I unmount the nfs share and replace it by it's symlink. (the umount process goes well, so we can affirm at this time no files where open) I've only konversation open at that time + konsole Once the symlink has been in place virtuoso-t start running at 100% cpu during 4-5minutes. In the mean times, I loose plasma control (can't change desktop by clicking on icon in systray bar. but able to change with ctrl+F# ) 60 to 80 minutes after virtuoso-t running at 100% plasma-desktop start using 100% cpu too. Then crash (this backtrace) and restart properly. After plasma-desktop restart everything works as expected. It's pretty easy to me to reproduce it, so if dev's give me the how to get a good valgrind trace (which process must be analized) I can give that one. Actual Results: crash bad Expected Results: working good :-) I repeat, if any dev's can drive me to backtrace it more deeply or granually, just drop me a note about what and how to do it I'm frequently on irc (tigerfoot) in #opensuse-kde for example. drkonqui backtrace is here http://bugs.kde.org/attachment.cgi?id=56612 -- Backtrace (Reduced): #8 0x00007f0e95228b3d in __gnu_cxx::__verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:93 #9 0x00007f0e95226d56 in __cxxabiv1::__terminate (handler=<value optimized out>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:39 #10 0x00007f0e95226d83 in std::terminate () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:49 #11 0x00007f0e95226ed6 in __cxxabiv1::__cxa_rethrow () at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:116 #12 0x00007f0e9648d373 in QEventLoop::exec (this=0x7fff9c9cc780, flags=...) at kernel/qeventloop.cpp:214 1187908 1 aseigo 2011-11-21 09:12:47 +0000 sorry, removing and then replacing the filesystem underneath plasma while it is running is not supported. virtuoso is reindexing what it sees as a changed fs (which it is; perhaps it could handle it more gracefully) and plasma is likely going into a deathspiral due to having one or more of its mmap'd caches removed underneath it. 1188008 2 bruno 2011-11-21 11:56:44 +0000 If I can understand the roots of it. Why did we have the option about removable media? Shouldn't be treated the same? Actually I've changed my mind about it, and have the nfs no more replacing the local copy. unison is used to sync them. And I anticipated your fix :D forbidden virtuoso/nepomuk to go there....