https://bugs.kde.org/show_bug.cgi?id=343446
--- Comment #8 from [email protected] --- 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. _______________________________________________ Kdepim-bugs mailing list [email protected] https://mail.kde.org/mailman/listinfo/kdepim-bugs
