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
