> 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 <halfl...@gmail.com> wrote: > Hey, > > On Sat, Jul 28, 2012 at 7:11 AM, Yaa101 <yaa...@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 _______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
