Bug 264738

Summary: plasma desktop crash virtuoso-t running at 100% after nfs umount
Product: [Unmaintained] plasma4 Reporter: Bruno Friedmann <bruno>
Component: desktopAssignee: Plasma Bugs List <plasma-bugs>
Status: RESOLVED INTENTIONAL    
Severity: normal    
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Bruno Friedmann 2011-01-29 13:50:59 UTC
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
Comment 1 Aaron J. Seigo 2011-11-21 09:12:47 UTC
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.
Comment 2 Bruno Friedmann 2011-11-21 11:56:44 UTC
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....