konqueror with kaffeine-xine plugin crashes on certain sites

Version: (using KDE KDE 3.4.1)
Installed from: Gentoo Packages
Compiler: gcc versie 3.4.3-20050110 (Gentoo 3.4.3.20050110-r2, ssp-3.4.3.20050110-0, pie-8.7.7) Thread model: posix
OS: Linux

I'm often using the Kaffeine-kpart to view videos that are embedded in webpages. When doing this, Konqueror seems to crash pretty often.
It seems that kparts have the ability to crash Konqueror when they misbehave. It should never be possible for a kpart to crash Konqueror (or another application that embeds it).

One crash I can easily reproduce with Kaffeine:
1. View a page embedding a video file or a video file by itself in a tab.
2. Deattach the tab in which the video is playing.

This always crashes for me.
There are also other instances where Kaffeine is able to crash Konqueror.

Sorry, that's just impossible with in-process components. The best that I can suggest is to not install kparts that crash every 5 seconds

Isn't there anything that can be done about this?
Maybe kparts could somehow be blacklisted when they crash once, so that they can't crash Konqueror a second time?

Yes, a KPart proxy would be nice, at least for possibly unstable parts. Reassigning to Konqueror, as I did not find an entry for the KParts framework or Kaffeine. But KHexEdit2 is not the culprit ;)

Yes, sorry that was a mistake.

The idea of a proxy sounds interesting. I was thinking myself along the lines of something like:
1. Konqueror is embedding a certain file type using a certain kpart.
2. The kpart crashes and gets marked as bad (or maybe it's added to a blacklist or something like that)
3. The next time Konqueror comes across something that is embedded using a certain filetype, it takes the next kpart that a user might have installed for this filetype instead.
4. If somehow all the kparts are marked bad after a while, there should be a button or something like that would open the file in an external viewer instead. Since this can never crash Konqueror, in the end all the crashes would be gone.

If bad kparts could be used through some kind of proxy, that would be even better though. Maybe it could also be possible for kparts to mark themselves as 'unstable' so that they are always automaticly proxied? Or the other way around where a kpart needs to be marked as 'stable' first before it is possible to run it without a proxy?

I suppose that "WONTFIX" is not wanted anymore.

There's just one problem: once Konqueror has crashed, it can't mark a part as "bad".

Yes, I was already afraid that this would be a problem. That is one of the reasons why a proxy/no-proxy marking by kpart authors seems like a good idea.

For the 'once Konqueror has crashed'-situation, would it somehow be possible to let DrKonqi handle the marking?

In theory, yes.

 So instead of crashing, it just plain doesn't work anymore?

  As to determining which plugin caused the crash, we can somewhat reliably
determine that. Install a sigsegv/sigfpe handler and then search the
backtrace for the offending kpart library. If it's not a Konqueror
distributed one, blacklist it. And then we either annoy the user or make it
silently not work.

> So instead of crashing, it just plain doesn't work anymore?

Yes. It's really annoying when you've got a Konqueror window open with 10 tabs and one of them crashes the whole instance...
It would be great if this functionality could be implemented somehow. It would make Konqueror (at least on my comps) at lot more stable.

If it would be possible to show the user a warning that a kpart is being blacklisted because it seems to be unstable that would be better than doing it silently I think. In the File Associations part in the Control Center, in the list from the Service Preference Order, maybe the kpart could be listed with an icon in front of it (skull or cross or something like that), so it is clear it is disabled. Also an option to reenable it from there seems logical.

Also one thing about point 4 in my earlier comment (#4), would it be possible to have some sort of generic kpart that would only display a button which someone could click on to have the file/URL passed to an external/serperate viewer?

Maybe it could even be so that once a kpart is blacklisted, a button could always appear. Clicking on the button would open a new instance of Konqueror with the offending kpart in it instead of embedding it in the current instance. Then it wouldn't be a problem if the kpart would crash, since only the new Konqueror instance would be taken down.

*** Bug 105609 has been marked as a duplicate of this bug. ***

*** Bug 101989 has been marked as a duplicate of this bug. ***

*** Bug 108571 has been marked as a duplicate of this bug. ***

*** Bug 110312 has been marked as a duplicate of this bug. ***

*** Bug 112470 has been marked as a duplicate of this bug. ***

*** Bug 107217 has been marked as a duplicate of this bug. ***

*** Bug 112851 has been marked as a duplicate of this bug. ***

*** Bug 111976 has been marked as a duplicate of this bug. ***

*** Bug 113066 has been marked as a duplicate of this bug. ***

*** Bug 113158 has been marked as a duplicate of this bug. ***

*** Bug 113113 has been marked as a duplicate of this bug. ***

*** Bug 113633 has been marked as a duplicate of this bug. ***

*** Bug 112794 has been marked as a duplicate of this bug. ***

*** Bug 114598 has been marked as a duplicate of this bug. ***

*** Bug 115133 has been marked as a duplicate of this bug. ***

*** Bug 115488 has been marked as a duplicate of this bug. ***

*** Bug 116587 has been marked as a duplicate of this bug. ***

Something like 'sessionsaver' (or something addressing bug 83803) might also mitigate the crashes. I run into a similar problem very infrequently while flipping back and forth very quickly in the kpdf part.

*** Bug 118967 has been marked as a duplicate of this bug. ***

*** Bug 119178 has been marked as a duplicate of this bug. ***

*** Bug 122023 has been marked as a duplicate of this bug. ***

*** Bug 123984 has been marked as a duplicate of this bug. ***

In the case of the kaffeine part the crash is caused by the use of xine-lib. The xine documentation (http://xinehq.de/index.php/hackersguide#AEN75) states that a xine frontend "must call XInitThreads() before calling the first Xlib function, because xine will access the display from within a different thread than the frontend". On the face of it this would mean that the kaffeine kpart would have to call XInitThreads(). But the kpart runs inside an application (konqueror) that has already accessed other Xlib functions and XInitThreads() cannot be called anymore (see man XInitThreads).
This leaves only the main application, i.e. konqueror. SUSE seem to have a patch to konqueror that makes it call XInitThreads() in kdemain (http://developer.kde.org/~binner/distributor-patches/Novell/nld9/kdebase3-3.2.1-68.32/konq-init-XThreads.diff).
Are there any reasons not to apply such a patch by default?

interesting design decision from the xine-lib hackers ;(

doesn't enabling Xlib threads otherwise causes a performance penalty of some kind?
The Xlib documentation is rather short on details, just stating:
  "It is recommended that single-threaded programs not call this function."

KDE 3.5 branch SNV
http://iptv.orf.at/ - click on a stream - opens a "black" windows, crashes on exit

I have to add, I can hear the sound of the stream.

Please remove me from your list

On 8 Jul 2006 20:53:53 -0000, Ferdinand Gassauer <email address hidden> wrote:
[bugs.kde.org quoted mail]
Please remove me from your list<br><br><div><span class="gmail_quote">On 8 Jul 2006 20:53:53 -0000, <b class="gmail_sendername">Ferdinand Gassauer</b> &lt;<a href="mailto:<email address hidden>"><email address hidden></a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">------- You are receiving this mail because: -------<br>You are on the CC list for the bug, or are watching someone who is.
<br><br><a href="http://bugs.kde.org/show_bug.cgi?id=109498">http://bugs.kde.org/show_bug.cgi?id=109498</a><br><br><br><br><br>------- Additional Comments From gassauer kde org&nbsp;&nbsp;2006-07-08 22:53 -------<br>I have to add, I can hear the sound of the stream.
<br></blockquote></div><br>

*** Bug 131939 has been marked as a duplicate of this bug. ***

*** Bug 136840 has been marked as a duplicate of this bug. ***

*** Bug 137854 has been marked as a duplicate of this bug. ***

*** Bug 113043 has been marked as a duplicate of this bug. ***

*** Bug 138723 has been marked as a duplicate of this bug. ***

*** Bug 140809 has been marked as a duplicate of this bug. ***

*** Bug 141228 has been marked as a duplicate of this bug. ***

bug 141228 has a more detailed crash log

The general request for blacklisting is one thing, but about all the reports merged here about the XInitThreads-related crash (like 140809 and 141228 at least) : does this still happen in KDE4? The X11-specific code in KShortcut no longer exists, AFAIK (and kaffeine is no more, right?).

@David: you're right: kaffeine is not currently mantained. Probably the specific crash problem cannot be reproduced. Do you suggest to open a new wish about the possibility to have a kpart proxy for a blacklisting or should this bug left opened for this request?

Closing as outdated.