After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 787640 - Segfault in soup_message_headersiter_next when running request.get_http_headers in a webkit extension
Segfault in soup_message_headersiter_next when running request.get_http_heade...
Status: RESOLVED OBSOLETE
Product: pygobject
Classification: Bindings
Component: introspection
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2017-09-13 17:37 UTC by msdemlei
Modified: 2018-01-10 21:00 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description msdemlei 2017-09-13 17:37:43 UTC
First off, apologies for this somewhat lousy bug report -- I'm a bit
discouraged by the apparent complexity of the python webkit/gi wrapping
and, on the other hand, hope that the problem may be obvious if one
understands that system.

I'm trying to write a python extension to webkit using aperez' extension
wrapper
(https://github.com/aperezdc/webkit2gtk-python-webextension-example/; I
hope that's not relevant, though).  In the extension, I'm doing,
essentially, in a page-created handler:

		self.current_page.connect("send-request", self.on_send_request)

Then the code:

	def on_send_request(self, web_page, request, redirect):
		request.get_http_headers()

(yes, just obtaining the http header object is enough even if it is
immediately discarded) causes a segfault in the rendering process;
diagnostics like this is logged:

  WebKitWebProces[32583]: segfault at 4 ip 00000000f223dfef sp 00000000ff901d44 error 4 in libsoup-2.4.so.1.8.0[f21f6000+bb000]

When examining a core dumped, like this:

  gdb /usr/lib/i386-linux-gnu/webkit2gtk-4.0/WebKitWebProcess core

with the debug symbols for libsoup (but not webkitgtk until someone
tells me it's actually useful), the traceback looks like this:

  #0  soup_message_headers_iter_next (iter=0xffe94be0, name=0xffe94bd0, 
      value=0xffe94bd4) at soup-message-headers.c:539
  #1  0xf6269fa1 in ?? () from /usr/lib/i386-linux-gnu/libwebkit2gtk-4.0.so.37
  [lots of frames within libwebkit2gtk]
  #43 0xf39761ab in WTF::RunLoop::performWork() ()
     from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
  #44 0xf3974ce8 in ?? ()
     from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
  #45 0xf3cff39b in g_main_context_dispatch ()
     from /lib/i386-linux-gnu/libglib-2.0.so.0
  #46 0xf3cff789 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
  #47 0xf3cffb39 in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
  #48 0xf39757c1 in WTF::RunLoop::run() ()
     from /usr/lib/i386-linux-gnu/libjavascriptcoregtk-4.0.so.18
  #49 0xf52be56a in ?? () from /usr/lib/i386-linux-gnu/libwebkit2gtk-4.0.so.37
  #50 0xf52be39c in WebProcessMainUnix ()
     from /usr/lib/i386-linux-gnu/libwebkit2gtk-4.0.so.37
  #51 0x56597692 in main ()

This is for gir1.2-soup-2.4 and libsoup2.4 as in Debian stretch
(2.56.0-2), all called from python3.

So, I'm hoping it's just a forgotten or skipped INCREF at a strategic
location in the wrapper -- but when I tried to look for it, I quickly got
lost in gi and gtk and glib and their interactions.

So -- any chance someone with sufficient insight could have a look?  Or
is there some overview over how all the gears work together and what I
can do to make diagnosis a bit easier?
Comment 1 GNOME Infrastructure Team 2018-01-10 21:00:14 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pygobject/issues/141.