Re: Writing a buffer with UTF-8 content.

[Ray Strode <halfline gmail com>]

Hey,

On Sat, Jul 28, 2012 at 7:11 AM, Yaa101 <yaa101 xs4all nl> wrote:

Thanks for filing the bug, I have too little background on the
internals to be able to file the bug-report as detailed as you did.

Sure.
 

If I understand the bug report well, the reason the bug is there is
because of the facility that the workaround uses?

Basically:

1) strings in _javascript_ are stored in a data structure called JSString.
2) GLib functions don't know about the JSString object, they know about C strings.
3) When GLIb functions get called, GJS "under the hood" converts JSString to C strings.
4) JSString objects have 16-bit arrays not 1-byte arrays like (like C strings normally are).
5) There are multiple ways strings can be stored in those 16-bit arrays.
(3 ways: convert to utf-16, make every odd byte blank and store data in every even byte, store
packed binary data in both bytes)
6) Given a JSString object, we have no bookkeeping (afaik) on how strings are stored in it.
7) If a glib function returns a utf-8 string (like g_key_file_to_data), then GJS takes that string
and puts it in a JSString object as utf-16.
8) When a function is called that expects arbitrary binary data (like g_file_set_contents), GJS
guesses that the JSString object is encoded in the every-odd-byte-blank way.
9) The bug happens when you take a JSString object with utf-16 data in it and use it for a function
that wants a JSString object with every-odd-byte-blank.
10) The workaround bypasses the issue by storing the data in a different structure under the hood
than a JSString, that structure always stores the bytes in a 1-byte arrays, so it's already in a form
g_file_set_contents wants.

 

Can you show me where there are instructions to setup gdb on a single
machine for gnome-shell and the libraries used?

There's some info here:

https://live.gnome.org/GnomeShell/Debugging

Debugging gnome-shell from a single machine is kind of hard though. Since gnome-shell draws the
screen, you can't have gdb on the same VT as gnome-shell since you won't be able to see the screen, and you can end up in a situation where the debugger has gnome-shell stopped when it's told the X server to freeze servicing clients temporarily.

You can work around this by running screen in a terminal, going to a vt and running screen -x to attach to the session from outside the session,
then gdb attaching to the process.  Unfortunately, you'll hit another snag, which is that when you're switched away dri2 won't draw (it sits waiting on a lock).
You can work around this by starting gnome-shell with software renderering (by exporting LIBGL_ALWAYS_SOFTWARE=y), or by toggling back and forth between the the X server VT and the VT with gdb frequently.

It's much easier to get a second machine and ssh in.

--Ray