Summary: | Kontact crashes when reading HTML E-Mails in KMail | ||
---|---|---|---|
Product: | [Applications] kontact | Reporter: | Oliver Maurhart <dyle71> |
Component: | Assignee: | kdepim bugs <kdepim-bugs> | |
Status: | RESOLVED UPSTREAM | ||
Severity: | crash | CC: | gdlvmleaf, joachim, kde, khangyi, konold, machanch, montel, renda.krell, s.heimbach, schwarzesschafxxl, skaumo, snoopy, spirosla, stof999, wbauer1 |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
See Also: | https://bugzilla.gnome.org/show_bug.cgi?id=738270 | ||
Latest Commit: | Version Fixed In: |
Description
Oliver Maurhart
2015-01-28 10:41:50 UTC
it's for each html mail ? or a specific html mail ? Mhm, it has been for a specific HTML mail. But for this certain E-Mail all the time. It turned off HTML E-Mail rendering in general. For this E-Mail I turned it on. But still images were not loaded. So in a seconds step I clicked on Loading Images and it is this when after some seconds KMail crashed. But it was not an important mail. More actually an ad. I also lost interest and I kicked the mail already. Sorry. But maybe the backtrace is still of interest ... if Webkit - gtk+-2.24.25/gdk/x11/gdkdisplay-x11.c:173 is in some sense really of interest to KDE. I mean: why does KMail HTML rendering refer to Webkit gtk+ in the first place? Isn't Qt Webkit sufficiant? Then again I lack deeper knowledge on how webkit qt/gtk do relate to each other and Qt/KDE rendering. It's in qwebkit But without specific email we can't report bug to qt I close as bug as upstream. FYI, the backtrace looks quite similar to the one in this openSUSE bugreport: https://bugzilla.opensuse.org/show_bug.cgi?id=901006 There the crash is caused by the evince-browser-plugin (that's also the reason why GTK is involved). Do you have that installed? Apparently this plugin also causes problems with Firefox (therefore it is being removed from openSUSE's evince package), so I'm not sure this is a QtWebKit bug. Mhm, yes I do have evince installed. $ eix -e evince [I] app-text/evince Available versions: 3.12.2(0/evd3.4-evv3.3)^t (~)3.12.2-r1(0/evd3.4-evv3.3)^t (~)3.14.1(0/evd3.4-evv3.3)^t (~)3.14.1-r1(0/evd3.4-evv3.3) [m]**9999(0/evd3.4-evv3.3)^t[1] {debug djvu doc dvi gnome +introspection libsecret nautilus +postscript t1lib tiff xps} Installed versions: 3.14.1-r1(11:15:31 AM 01/26/2015)(introspection postscript tiff -debug -djvu -dvi -gnome -libsecret -nautilus -t1lib -xps) Homepage: https://wiki.gnome.org/Apps/Evince Description: Simple document viewer for GNOME How do I check if on my system (Gentoo) the series KMail -> qwebkit -> webkit-gtk -> evince holds? (In reply to dyle from comment #5) > How do I check if on my system (Gentoo) the series KMail -> qwebkit -> > webkit-gtk -> evince holds? Well, if you have an EMail with which you can reproduce the crash, you could try to remove the plugin and see if it still crashes. It should be /usr/lib(64)/browser-plugins/libevbrowserplugin.so or similar. You have 3.14.1 installed, that's the same version that crashed for me (I mainly experienced the crashes with Konqueror, but could reproduce them with rekonq and qt4-browser which all use QtWebKit, like Akregator does as well). Since I removed evince-browser-plugin (it's a separate package in openSUSE), I had no more crashes. You can compile evince without the browser plugin, just add the option "--disable-browser-plugin" to your call of configure. Btw, you keep mentioning webkit-gtk, but this is not at all involved here. It's the evince-browser-plugin that loads/uses GTK, as evince is a GNOME/GTK application. Ok, Now you've raised the attention of my "Sportsgeist". The error is clearly found in gtk+, involving any Plugin, not particular evince. It keeps me wondering why my HTML rendering should wind up in evince, since I coded QtWebKit Apps already and didn't find any need to include other stuff. But then again, you are right in the general principle. Basically QtWebKit inits Gtk for some modules. This may be evince, but reading the source this may also be Adobe Flash or any other plugin. So, unlinking evince dependencies may resolve the problem, but this is a) a hack and b) only sufficient if the module/plugin in question is actually evince. In other module/plugin might crash as well. Nevertheless at line 115 in QtWebKit Plugin Loader gtkInit() is invoked (for any module). # nl -ba /var/tmp/portage/dev-qt/qtwebkit-4.8.6-r1/work/qt-everywhere-opensource-src-4.8.6/src/3rdparty/webkit/Source/WebCore/plugins/qt/PluginPackageQt.cpp | grep -C 14 '^ *115' 101 static void initializeGtk(QLibrary* module = 0) 102 { 103 // Ensures missing Gtk initialization in some versions of Adobe's flash player 104 // plugin do not cause crashes. See BR# 40567, 44324, and 44405 for details. 105 if (module) { 106 typedef void *(*gtk_init_ptr)(int*, char***); 107 gtk_init_ptr gtkInit = (gtk_init_ptr)module->resolve("gtk_init"); 108 if (gtkInit) { 109 // Prevent gtk_init() from replacing the X error handlers, since the Gtk 110 // handlers abort when they receive an X error, thus killing the viewer. 111 #ifdef Q_WS_X11 112 int (*old_error_handler)(Display*, XErrorEvent*) = XSetErrorHandler(0); 113 int (*old_io_error_handler)(Display*) = XSetIOErrorHandler(0); 114 #endif 115 gtkInit(0, 0); 116 #ifdef Q_WS_X11 117 XSetErrorHandler(old_error_handler); 118 XSetIOErrorHandler(old_io_error_handler); 119 #endif 120 return; 121 } 122 } 123 124 QLibrary library(QLatin1String("libgtk-x11-2.0.so.0")); 125 if (library.load()) { 126 typedef void *(*gtk_init_check_ptr)(int*, char***); 127 gtk_init_check_ptr gtkInitCheck = (gtk_init_check_ptr)library.resolve("gtk_init_check"); 128 // NOTE: We're using gtk_init_check() since gtk_init() calls exit() on failure. 129 if (gtkInitCheck) This winds up finally in gtk+ at line 173 crashing: # nl -ba /var/tmp/portage/x11-libs/gtk+-2.24.25-r1/work/gtk+-2.24.25/gdk/x11/gdkdisplay-x11.c | grep -C 4 '^ *173' 169 170 display = g_object_new (GDK_TYPE_DISPLAY_X11, NULL); 171 display_x11 = GDK_DISPLAY_X11 (display); 172 173 display_x11->use_xshm = TRUE; 174 display_x11->xdisplay = xdisplay; 175 176 #ifdef HAVE_X11R6 177 /* Set up handlers for Xlib internal connections */ Simply because the GTK+ devs take it for granted, that "display_x11 = GDK_DISPLAY_X11 (display);" must return a non-NULL pointer. Why it doesn't in my case, I cannot say (yet). However, I consider forgetting to check a pointer for NULL value before dereferencing (line 173) not to be a good programming practice. This is not a good sign of code quality. =( It's clearly upstream at the gtk+. IMHO if gtk+ fails to open up a x11 display it should return with a proper error message (e.g. "Failed to init X11 Display") but must not crash the calling application (which might anything finally utilizing gtk+). But, sadly, I currently lack the requirements - the specific email causing the trouble - to retry and to find out why my "display_x11 = GDK_DISPLAY_X11 (display);" fails. Maybe it's a race condition on threads (if multi-threading is an option here), maybe it got to do something with my nvidia-driver, maybe something totally else. Don't know. Well, I only had this crash with evince-browser-plugin. And I'm using radeon here, so this is definitely not related to the nvidia driver... ;) It's unconditionally reproducible here (on two different systems), so I don't think it's a race-condition either. If you want to reproduce it, run Konqueror (with the WebKit engine) or rekonq and browse to one of the sites I mentioned in the openSUSE bugreport, in particular http://build.opensuse.org/ (just opening that site should cause the crash). If you want to follow this up, there's this GNOME bugreport e.g. (which status is RESOLVED NOTGNOME :-( ): https://bugzilla.gnome.org/show_bug.cgi?id=738270 Huh! You are right! Opening up http://build.opensuse.org/ in konqueror crashes at the exact same place! o.O I don't know if "RESOLVED NOTGNOME" is the right choice. It's clearly a gtk+ bug to me. And as such it might not be Gnome per se - when one defines "Gnome" not to be confused with "Gimp Toolkit". That's like filing a bug report for Qt on the kde.bugzilla and then resolving it as "NOTKDE". Which is true then. However, the gtk+ devs *do* refer to the gnome bugzilla ... what a mess. Ok, I'll attach myself to the correct bug report at the gnome site and give the devs a nudge again. (In reply to dyle from comment #10) > Ok, I'll attach myself to the correct bug report at the gnome site and give > the devs a nudge again. Thanks! I was thinking the same right now . Actually I forgot about this bug since I uninstalled evince-browser-plugin, because I didn't see any more crashes. (I did contemplate to investigate it further back then) And as I mentioned, openSUSE's GNOME team decided to just remove evince-browser-plugin from the distribution (unrelated to QtWebKit), because of the upstream bug's status, so I didn't care either any more... But it definitely would be better to solve this problem at the source, I think. *** Bug 340873 has been marked as a duplicate of this bug. *** *** Bug 343856 has been marked as a duplicate of this bug. *** *** Bug 342731 has been marked as a duplicate of this bug. *** *** Bug 349859 has been marked as a duplicate of this bug. *** *** Bug 352248 has been marked as a duplicate of this bug. *** *** Bug 349919 has been marked as a duplicate of this bug. *** *** Bug 349959 has been marked as a duplicate of this bug. *** *** Bug 350357 has been marked as a duplicate of this bug. *** *** Bug 350942 has been marked as a duplicate of this bug. *** *** Bug 351216 has been marked as a duplicate of this bug. *** *** Bug 352012 has been marked as a duplicate of this bug. *** *** Bug 353069 has been marked as a duplicate of this bug. *** *** Bug 359985 has been marked as a duplicate of this bug. *** *** Bug 360370 has been marked as a duplicate of this bug. *** *** Bug 381785 has been marked as a duplicate of this bug. *** |