Bug 1090405 - Segmentation fault with python3, python3-gobject and WebKit2 WebView
Segmentation fault with python3, python3-gobject and WebKit2 WebView
Status: RESOLVED WORKSFORME
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Other
Current
x86-64 Other
: P5 - None : Major (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-04-20 15:54 UTC by Luca Weiss
Modified: 2018-11-19 16:02 UTC (History)
7 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luca Weiss 2018-04-20 15:54:10 UTC
When running the following code, python3 crashes with a segmentation fault.

import gi
gi.require_version("WebKit2", "4.0")
from gi.repository import WebKit2

class AppView(WebKit2.WebView):
    def __init__(self):
        webkit = WebKit2
        webkit.WebView.__init__(self)

a = AppView()

The same code works on other distros (I wasn't able to test it in Leap 15 yet, but it also works in 42.3).
Comment 1 Matej Cepl 2018-06-09 09:13:01 UTC
Segmentation fault is somewhere in Gtk-land:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f895cc11a79 in _gtk_style_provider_private_get_settings (provider=0x0)
    at gtkstyleproviderprivate.c:123
123	  iface = GTK_STYLE_PROVIDER_PRIVATE_GET_INTERFACE (provider);
(gdb) t a a bt

Thread 1 (Thread 0x7f8965dc24c0 (LWP 31724)):
#0  0x00007f895cc11a79 in _gtk_style_provider_private_get_settings (provider=0x0)
    at gtkstyleproviderprivate.c:123
#1  0x00007f895caacc38 in gtk_css_value_initial_compute (value=<optimized out>, property_id=1, provider=0x0, style=0x560001b7a090 [GtkCssStaticStyle], parent_style=0x0)
    at gtkcssinitialvalue.c:52
#2  0x00007f895cac2763 in gtk_css_static_style_compute_value (style=0x560001b7a090 [GtkCssStaticStyle], provider=0x0, parent_style=0x0, id=1, specified=0x7f895d22b060 <inherit>, section=0x0) at gtkcssstaticstyle.c:237
#3  0x00007f895caadf9c in _gtk_css_lookup_resolve (lookup=lookup@entry=0x560001b78210, provider=provider@entry=0x0, style=style@entry=0x560001b7a090 [GtkCssStaticStyle], parent_style=parent_style@entry=0x0) at gtkcsslookup.c:122
#4  0x00007f895cac269c in gtk_css_static_style_new_compute (provider=provider@entry=0x0, matcher=matcher@entry=0x0, parent=parent@entry=0x0) at gtkcssstaticstyle.c:195
#5  0x00007f895cac26f5 in gtk_css_static_style_get_default () at gtkcssstaticstyle.c:164
#6  0x00007f895caae912 in gtk_css_node_init (cssnode=0x560001b6c030 [GtkCssNode])
    at gtkcssnode.c:667
#7  0x00007f89640fa3f8 in g_type_create_instance (type=<optimized out>) at gtype.c:1860
#8  0x00007f89640db228 in g_object_new_internal (class=class@entry=0x560001b46a40, params=params@entry=0x0, n_params=n_params@entry=0) at gobject.c:1799
#9  0x00007f89640dca2d in g_object_new_with_properties (object_type=94558028775296, n_properties=0, names=names@entry=0x0, values=values@entry=0x0) at gobject.c:1967
#10 0x00007f89640dd4f1 in g_object_new (object_type=<optimized out>, first_property_name=first_property_name@entry=0x0) at gobject.c:1639
#11 0x00007f895cacaa1a in gtk_css_widget_node_new (widget=widget@entry=0x560001b763f0 [GtkWidget]) at gtkcsswidgetnode.c:297
#12 0x00007f895cca46b8 in gtk_widget_init (instance=0x560001b763f0 [GtkWidget], g_class=0x560001b74700) at gtkwidget.c:4420
#13 0x00007f89640fa3f8 in g_type_create_instance (type=<optimized out>) at gtype.c:1860
#14 0x00007f89640db228 in g_object_new_internal (class=class@entry=0x560001b74700, params=params@entry=0x0, n_params=n_params@entry=0) at gobject.c:1799
#15 0x00007f89640dcd3d in g_object_newv (object_type=94558027053232, n_parameters=n_parameters@entry=0, parameters=parameters@entry=0x0) at gobject.c:2036
#16 0x00007f89645820dc in pygobject_constructv (self=self@entry=0x7f89600fb320, n_parameters=0, parameters=0x0) at ../../gi/gobjectmodule.c:1000
#17 0x00007f8964589681 in pygobject_init (self=0x7f89600fb320, args=<optimized out>, kwargs=0x0) at ../../gi/pygobject-object.c:1305
#18 0x00007f896586c77c in  () at /usr/lib64/libpython2.7.so.1.0
#19 0x00007f8965822003 in PyObject_Call () at /usr/lib64/libpython2.7.so.1.0
#20 0x00007f89658900b0 in PyEval_CallObjectWithKeywords ()
    at /usr/lib64/libpython2.7.so.1.0
#21 0x00007f8965830009 in  () at /usr/lib64/libpython2.7.so.1.0
#22 0x00007f8965822003 in PyObject_Call () at /usr/lib64/libpython2.7.so.1.0
#23 0x00007f896588c495 in PyEval_EvalFrameEx () at /usr/lib64/libpython2.7.so.1.0
#24 0x00007f8965885c54 in PyEval_EvalCodeEx () at /usr/lib64/libpython2.7.so.1.0
#25 0x00007f89658382fe in  () at /usr/lib64/libpython2.7.so.1.0
#26 0x00007f8965822003 in PyObject_Call () at /usr/lib64/libpython2.7.so.1.0
#27 0x00007f896582aa7e in  () at /usr/lib64/libpython2.7.so.1.0
#28 0x00007f8965822003 in PyObject_Call () at /usr/lib64/libpython2.7.so.1.0
#29 0x00007f896586b9f7 in  () at /usr/lib64/libpython2.7.so.1.0
---Type <return> to continue, or q <return> to quit---
#30 0x00007f89658690c4 in  () at /usr/lib64/libpython2.7.so.1.0
#31 0x00007f8965822003 in PyObject_Call () at /usr/lib64/libpython2.7.so.1.0
#32 0x00007f896588c495 in PyEval_EvalFrameEx () at /usr/lib64/libpython2.7.so.1.0
#33 0x00007f8965885c54 in PyEval_EvalCodeEx () at /usr/lib64/libpython2.7.so.1.0
#34 0x00007f89658eb249 in PyEval_EvalCode () at /usr/lib64/libpython2.7.so.1.0
#35 0x00007f89658f188f in  () at /usr/lib64/libpython2.7.so.1.0
#36 0x00007f89658f1832 in PyRun_FileExFlags () at /usr/lib64/libpython2.7.so.1.0
#37 0x00007f89658f172e in PyRun_SimpleFileExFlags () at /usr/lib64/libpython2.7.so.1.0
#38 0x00007f89658f7689 in Py_Main () at /usr/lib64/libpython2.7.so.1.0
#39 0x00007f89651bda87 in __libc_start_main (main=
    0x5600009627c0 <main>, argc=2, argv=0x7ffc71478418, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc71478408) at ../csu/libc-start.c:308
#40 0x00005600009627fa in _start () at ../sysdeps/x86_64/start.S:120
(gdb)
Comment 2 Bjørn Lie 2018-06-17 18:45:35 UTC
Hi mgorse

Do you think this would be connected to the python3 port patch?
Comment 3 Michael Gorse 2018-06-21 15:59:49 UTC
I haven't been able to reproduce the crash.
The python 3 patch affects scripts used to build webkit--it isn't directly related to usage of webkit from python via pygobject. Nevertheless, I've published a package without the python 3 patch; I think that it is worth testing, for anyone able to reproduce the bug.
http://download.opensuse.org/repositories/home:/mgorse:/branches:/GNOME:/Factory/
Comment 4 Luca Weiss 2018-08-27 17:00:36 UTC
I can still reproduce the crash on an today-updated system.

@Michael Gorse: I know, that it's been two months, but there's no package behind the URL you posted :)
Comment 5 Sebastian Wagner 2018-11-17 12:21:12 UTC
Works for me on both TW and Leap 15.0
Comment 6 Luca Weiss 2018-11-17 13:06:55 UTC
Still crashes for me (screenshot: https://private.z3ntu.xyz/screenshots/Screenshot_20181117_140546.png)
Comment 7 Dominique Leuenberger 2018-11-19 13:34:35 UTC
Do you have python3-gobject-Gdk installed?

pygobject is split in two parts in openSUSE, in order to allows for g-i bound python code without pulling X in; since you're seeing this in self-written code and not on a package, I could understand the -Gdk package being missing on your system
Comment 8 Luca Weiss 2018-11-19 15:44:06 UTC
No, I didn't have python3-gobject-Gdk installed and after installing it, my example code works and I can also launch the application I had problems with (why I created this bug report).

Can something be done so other people don't hit the same issue in the future => not making Python segfault when this package is missing?
Comment 9 Dominique Leuenberger 2018-11-19 16:02:04 UTC
(In reply to Luca Weiss from comment #8)
> No, I didn't have python3-gobject-Gdk installed and after installing it, my
> example code works and I can also launch the application I had problems with
> (why I created this bug report).
> 
> Can something be done so other people don't hit the same issue in the future
> => not making Python segfault when this package is missing?

No; the way we package pygobject (as said, we want some g-introspected packages without X not pulling in X) has this split. The main issue for the segfault is that not all of the code is properly introspecatble (so there are overrides in place) - without the overrides, the segfaults happen.

The best is to work on packages, and ensure for the users to have the -Gdk package installed.