GNOME Bugzilla – Bug 726390
Crash when trying to open certain files while the multi edit plugin is active
Last modified: 2019-03-23 20:50:42 UTC
If I have the "multi edit" plugin active, gedit will instantly crash if I try to open some files I have, such as "Documents/idées pour condo.markdown" or "Documents/smileys japonais (all japanese emoticons).txt". This happens both if I try to open the file with ctrl+O or if I run "gedit Documents/the_file". Here is the backtrace I could get through gdb when opening the markdown file mentioned above (you can see some of the strings through the backtrace...) (gdb) bt full
+ Trace 233342
From the trace, this looks like a bug in pygobject rather than gedit. It seems it never even enters the multiedit plugin, but crashes when trying to marshal the string of the insert-text signal. Can you please give some more information on the exact versions of gedit and pygobject installed on your system? I could also not reproduce this, but I'm running gedit 3.8.3 with python gobject 3.10.0.
This is Gedit 3.10.3 + python3-gobject 3.10.2 installed on Fedora 20, 64 bits.
Well, I just upgraded to gedit 3.10.4 and pygobject 3.10.2, and I can't reproduce. Since we haven't had any other reports, I'm starting to think along the lines of something being weird on your system. I asked someone else to reproduce, also on fedora, and nope :( If this is a pygobject issue, could you try and see if the same problem occurs with another plugin, for example the snippets plugin should also trigger this. Are you sure you're not accidentally linking to another version of pygobject somehow?
Yeah, just using the stock versions. But as I mentioned I think this happens only on some files, it must be caused by particular non-english contents... I'll email the file to your gmail address (rather than attaching it to this bug report ;)
OK, I can reproduce this now, but only when I try to open those files using ISO-8859-15 encoding. Opening them in UTF-8 seems to not make anything crash. Is that what happens for you as well?
Created attachment 272380 [details] [review] Make sure text passed to insert_text is null terminated
I think this patch provides a quickfix for the immediate problem. It should solve more or less all issues, since it ensures all text passed to gtk is properly null terminated. This in turn should allow pygobject to not care about the length argument for the insert-text signal. See also bug #726689 for more details. The downsides to this patch are that it will do some more allocations in some corner cases, when dealing with invalid text. At least it solves the crash for me.
Created attachment 272381 [details] [review] Make sure text passed to insert_text is null terminated
Review of attachment 272381 [details] [review]: looks good to me, but this bug has been there for a few releases, so I think we do not need to rush it and request a freeze break
> OK, I can reproduce this now, but only when I try to open those files using > ISO-8859-15 encoding. Opening them in UTF-8 seems to not make anything crash. > Is that what happens for you as well? I don't know, in gedit's "open" filechooser I let it to "detect encoding automatically", and this also happens if you open the files from the commandline (gedit ~/Documents/the_document.markdown). I thought everything was unicode these days, at least all files created by gedit. So I'm not sure why gedit would misdetect that markdown file as not being unicode...
It should normally try utf-8 first, unless there was a metadata attribute set on it, but that means you'd have to have explicitly opened it once in that encoding (or saved it in that encoding). The bug can also appear when you have a file with windows line endings (i.e. \r\n) which is the case for the two files you sent me.
pushed. I am closing this bug since there is the pygobject one tracking the underlying issue
Jeff or Jesse, do you still have the files to reproduce this bug? The file loading and saving stuff is being moved to GtkSourceView, and the above patch is not yet applied (I copied the gedit code before).
I'm trying to reproduce this bug with a code like: > gchar text[4] = {'a', 'b', 'c', 'd'}; > gtk_text_buffer_insert (buffer, &iter, text, 4); With the multi-edit plugin modified to always use the text variable in the insert-text signal handler. And it doesn't crash. I wanted to reproduce the crash to try to fix it by adding annotations to the insert-text signal like this: > @text: (array length=len) (element-type uint8): the UTF-8 text to be inserted > @len: length of the inserted text in bytes
For example g_file_set_contents() has also a "gchar *" parameter with a length, and it uses the [array length=length][element-type guint8] annotation.
For the record, to reproduce the crash: /* The last character is an invalid UTF-8 character. */ gchar text[4] = {'a', 'b', 'c', '\xC0'}; gtk_text_buffer_insert (buffer, &iter, text, 3); With the insert-text signal connected in Python. The annotation like g_file_set_contents() helps a little, it avoids the crash, but there is a bug with the text variable in Python: > Warning: g_value_get_pointer: assertion 'G_VALUE_HOLDS_POINTER (value)' failed