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 726689 - Signal marshalling of string + length (GtkTextBuffer::insert-text)
Signal marshalling of string + length (GtkTextBuffer::insert-text)
Status: RESOLVED OBSOLETE
Product: pygobject
Classification: Bindings
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks: 726390
 
 
Reported: 2014-03-19 09:20 UTC by jessevdk@gmail.com
Modified: 2018-01-10 20:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description jessevdk@gmail.com 2014-03-19 09:20:17 UTC 
We're encountering a crasher bug in gedit which is due to the closure marshalling of the insert-text signal on a GtkTextBuffer. I don't know if this is a gtk+ annotation problem, or also a pygobject issue (I glanced over the code, and it seems it would need some adaptation also). In gedit there are some cases in which we call gtk_text_buffer_insert_text with a non-null terminated buffer, specifying the length of text to be inserted explicitly. However, when we have signal handlers installed in python for the insert-text signal, gedit crashes due to the fact that the string argument fails to get marshalled to a python unicode string (since it's not null terminated).
Comment 1 Simon Feltman 2014-03-19 11:07:17 UTC 
By changing the annotation of the 'insert-text' signal to use the length argument, I think you will then hit bug 694735 (related to bug 694448). Changing the buffer to a uint8 array explicitly probably be an API break for the 'insert-text' signal. One fix would just be to make sure specifying the length arg for char pointers generates a better GIR (string+length) as originally thought in bug 694735...  From the PyGObject side of things, I'm pretty sure signals with array lengths work for input args, but there might be a few tweaks. There are a few noted bugs but I think they are related to output array args (bug 669496 and bug 702508).
Comment 2 jessevdk@gmail.com 2014-03-19 11:13:10 UTC 
Yes, it looks like supporting string+length would be a nice fix. In the mean time, I think we'll try to make sure that the buffer we pass to insert-text is always 0 terminated, just to make sure we don't crash.
Comment 3 GNOME Infrastructure Team 2018-01-10 20:38:12 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/68.