Bug 145671 - sandboxing of kpart components
Summary: sandboxing of kpart components
Status: RESOLVED INTENTIONAL
Alias: None
Product: kdelibs
Classification: Unmaintained
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-19 12:53 UTC by Elmar Stellnberger (AT/K)
Modified: 2024-05-06 17:41 UTC (History)
2 users (show)

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

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Elmar Stellnberger (AT/K) 2007-05-19 12:53:01 UTC 
Version:            (using KDE KDE 3.5.6)
Installed from:    SuSE RPMs
OS:                Linux

It happens so often that Konqueror or some other KDE application crashes because of an error in a KParts component. It should really be worth a consideration if there is any way to protect the hosting main application from hangs or crashes in one of its KPart-plugins.
  There should not be any hang if the plugin code was executed in a different thread. I can not assess to which extent it will be possible to separate or protect the address spaces of the host app. and its plugin (shared memory?, read only access?). 
  f.e. Bug 145670 describes a hang followed by a crash.
Comment 1 Friedrich W. H. Kossebau 2008-06-15 12:51:04 UTC 
Agreed, some kind of proxy KPart would be nice to have.
Comment 2 Christoph Cullmann 2024-05-06 17:41:27 UTC 
I think that is not realistic, all happens in process, there is no easy way to separate that.