[kontact] [Bug 343446] Kontact crashes when reading HTML E-Mails in KMail

[dyle at dyle.org]

https://bugs.kde.org/show_bug.cgi?id=343446

--- Comment #8 from dyle at dyle.org ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.