Re: Writing a buffer with UTF-8 content.



> 6) Given a JSString object, we have no bookkeeping (afaik) on how
> strings are stored in it.

That is bad...

> 10) The workaround bypasses the issue
So the workaround with the 1 byte arrays is a kind of surrogate
C-String.

Is that array translated by gjs internals into a C-String and then fed
to the called C library function?

If so, then one might package that differently and call it CString or
something like that to help spread the info on this issue to other
developers.


> It's much easier to get a second machine and ssh in.
That is not so hard, I guess... open a terminal here and ssh into the
remote and let the remote ssh into my machine.

Thanks for the answers Ray.

-- 
(o_
//\  Regards, Groeten,
V_/_ Bas Burger.


On Mon, 30 Jul 2012 10:43:53 -0400
Ray Strode <halfline gmail com> wrote:

> 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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]