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 730390 - crash in profile editor
crash in profile editor
Status: RESOLVED FIXED
Product: gnome-terminal
Classification: Core
Component: general
3.13.x
Other Linux
: Normal critical
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-05-19 16:49 UTC by Christian Persch
Modified: 2014-05-21 08:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christian Persch 2014-05-19 16:49:43 UTC
https://retrace.fedoraproject.org/faf/reports/436958/ :

1 	g_markup_escape_text 	/lib/libglib-2.0.so.0 	- 	-
2 	g_markup_vprintf_escaped 	/lib/libglib-2.0.so.0 	- 	-
3 	g_markup_printf_escaped 	/lib/libglib-2.0.so.0 	- 	-
4 	terminal_profile_edit 	/usr/libexec/gnome-terminal-server 	- 	-

Not sure what's happening here... maybe memory corruption from earlier.

The code is the escaping of the encoding names afaict, which looks safe...
Comment 1 Egmont Koblinger 2014-05-20 13:13:44 UTC
My encoding list (g-t 3.13) contains a "0007 User Defined" entry, whereas that's a boxed
00
07

like when the font's missing the glyph for U+0007.

Maybe 3.12 stored something in different format than 3.13? Or something results in undesired garbage in the settings.

Shall I send you some of my configs? (Which?)
Comment 2 Christian Persch 2014-05-20 13:31:10 UTC
$ gsettings get org.gnome.Terminal.Legacy.Settings encodings | hexdump -C

might be useful.
Comment 3 Egmont Koblinger 2014-05-20 14:50:56 UTC
It says
['ISO-8859-2', 'current', 'UTF-8', 'ISO-8859-1']
(no control characters, so I omitted hexdumping)

At the same time, the menu contains:
  Central European (ISO-8859-2)
· Unicode (UTF-8)
  User Defined (that 0007 symbol here)
  Western (ISO-8859-1)

so it's the "current" that's buggy (I guess that refers to the system locale, right?)
Comment 4 Christian Persch 2014-05-20 15:00:43 UTC
Yes, that should be 'current'. However that's just the result of g_get_charset() which should stay valid for the entire run... can you run gnome-terminal-server under valgrind memcheck and see if it's reporting anything? [https://wiki.gnome.org/Apps/Terminal/Debugging and https://wiki.gnome.org/Valgrind]
Comment 5 Egmont Koblinger 2014-05-20 15:11:58 UTC
Just a quick grep in the code: in 3.12 there's a
  g_get_charset (&charset);
but in git master it's not there anymore, we're not calling this method to get the charset.

Maybe we have an uninitialized value? (Right now it's U+0002 for me.)

I'll be back probably later tonight - the commit where that line disappeared might be a good start to track this down.
Comment 6 Christian Persch 2014-05-20 15:27:54 UTC
g_get_charset returns a const string that's kept in a glib internal cache.

master doesn't have 'current' anymore since it enforces that locale = utf-8.
Comment 7 Egmont Koblinger 2014-05-21 08:11:20 UTC
There are three calls to terminal_app_ensure_encoding():

terminal-app.c: the charset param comes from an array declared as gs_strfreev.
terminal-screen.c: the charset param comes from a gs_free char*.
terminal-window.c: the charset param comes from vte_terminal_get_encoding() which might alter/free the value on charset change.

This is passed on to terminal_encoding_new() which calls g_intern_static_string() on the value.

I guess this should be g_intern_string() (which indeed fixes my bug – and hopefully fixes the original crash too).

There's only one more call to terminal_encoding_new(), in terminal_app_init() => terminal_encodings_get_builtins(), the charset value passed is allocated once at app_init and destroyed once at app_finalize so I guess we're not leaking anything outside of the GQuark world.
Comment 8 Christian Persch 2014-05-21 08:22:30 UTC
Right, thanks! Should be fixed on master now; 3-12 does g_strdup there so should be fine.