54

I'm very interested in this, as I have also been thinking about how to solve the Plasma stability issues.

Not sure if your proposal here is workable (it seems rather hackish), but it's probably worth giving a try. If that really works, it could also be interesting for other applications.

Catching an exception is nice, but this does not prevent rogue plasmoid A to write into the memory of plasmoid B or in the memory of the core plasma-desktop.
This is what used to occur on operating systems without memory protection (Windows < 95, Mac OS < 10) where process A could read/write memory of process B.

Nowadays processes can't read/write other process memories, that's why using separate processes gives more protection.

@agateau
That's true, the idea is a compromiss between performance, difficulty of implementation and safety. Most errors happen because of SIGSEGV (everywhere) or division by zero (in geometrical computations).

@markey
Of course it is hackish (that is why it makes fun ), but look at the kinit-code...

Now there is a plasma-like proof of concept (there are objects crashing in different ways). It works fine, you can download it here.

The User wrote:@agateau
That's true, the idea is a compromiss between performance, difficulty of implementation and safety. Most errors happen because of SIGSEGV (everywhere) or division by zero (in geometrical computations).

SIGSEGV happens when a process reads or writes outside its allowed memory. If plasmoid A writes on plasmoid B memory, it won't produce a crash in A code, but may cause a crash in B code. Your system will then consider B to be faulty.

Certainly, B may produce a SIGSEGV.
But there are more usual errors like simple *0 and 0 / 0.

PS:
Unfortunately some ugly code is needed to start DrKonqi. We need a way to let DrKonqi immediately receive the bt. But that is no fundamental problem for the concept.

You should check it out. Now it is really cool:
likeplasmoiddrkonqiexperiment will create three "LikePlasmoids" (simple windows), one of them will crash inside the event-system, one of them will crash in another thread and one is simply stable. When one of them crashes, DrKonqi will be started, you can look at the backtrace, the window will be closed and you will be able to continue using the program.

http://websvn.kde.org/trunk/playground/ ... hcatching/
home/kde/trunk/playground/libs/crashcatching

You need KDE-trunk for DrKonqi-support, the other examples just need Qt4.

The User

After some discussion in kde we had this result: There is a dangerous scenario: Imagine a Plasmoid would access global data that will be reused in the same process and it does not use the dataengine-concept but performs a synchronous call. While writing data this call could fail. The crash-handler would delete the Plasmoid, but there could be broken data.
Some thaughts:
1. If it happens in a separate thread, termination is the wrong way to do it, an exception should be thrown and SIGABRT be catched.
2. It is very hard to detect such functions at runtime.
3. What should happen? The design of the Plasmoid seems to be broken, maybe it also writes inconsistent data to HD.
4. It would be the same with the "multiple processes idea" if they would try to modify shared data.
5. Backups may help.
6. It should be possible to say: This Plasmoid should cause a real crash, because it is to unsafe.
7. Are there any Plasmoids with such a broken design?