Re: [Ayatana-dev] New on Unity

[Jose Cortes <josepablocortes@xxxxxxxxx>]

2011/6/14 Sam Spilsbury <smspillaz@xxxxxxxxx>:
> On Tue, Jun 14, 2011 at 9:06 AM, Jose Cortes <josepablocortes@xxxxxxxxx> wrote:
>> Hi all,
>>
>> I'm new on this project, and I want to help a little,
>> I'm a C++ programmer, but always developed under Win, I would like
>> start to contribute to unity,
>> but I don't have much experience Developing under linux.
>> So, here is my question,
>>
>> wich tools can I use to debug Unity?
>
> You can use the standard set of GNU tools that we use for debugging,
> such as gdb and valgrind for debugging the code end of things. Note
> that the view implementation of unity at least runs inside the same
> process (compiz) which handles redrawing of all elements on the screen
> (windows, panels, etc) and also window management (focus, stacking) so
> if you hit a breakpoint in gdb or a your program receives a signal (eg
> SIGSEGV) which could cause execution to stop, your display would lock
> up and you wouldn't be able to interact with gdb if you were running
> it inside of a terminal running under unity.
>
> Note that in order to resolve this, you'll need to be able to access
> gdb outside of a frozen screen. I usually have another machine
> connected to the network and run gdb over ssh, so when a breakpoint is
> hit I can interact with gdb on the remote machine. That's basically a
> matter of doing something like:
>
> DISPLAY=:0 COMPIZ_CONFIG_PROFILE=ubuntu gdb compiz --replace ccp &
>
> on the remote machine. If you don't have a remote machine, you can use
> VT switching as a means to get back and forth between the debug
> console and unity, so using Ctrl-Alt-F1 and Ctrl-Alt-F7 to get between
> the two. Use the same command for debugging.
>
> If you're not interested in using some of the program control stuff
> that gdb provides such as breakpoints, assembler dumps etc then I
> usually just run compiz through valgrind (sudo apt-get install
> valgrind) on the session I'm working on, eg opening a terminal and
> doing
>
> valgrind compiz --replace ccp &
>
> Running compiz through valgrind is basically the same as running
> compiz through an emulator, so it is going to be slow, however
> valgrind can give you good information at runtime if your program is
> doing anything strange memory wise (the root cause of most crashes)
> and will also give you a full backtrace when a crash happens. Note
> here that when a crash happens you'll lose the ability to focus
> windows (eg type in your terminal) and your panels and launcher will
> disappear, so you'll need to drop to a VT after it happens and launch
> metacity or something similar.
>
> Also note that almost everything in unity except for the launcher can
> be run outside of the window manager process in a separate testing
> window so that you're not relaunching the window manager all the time.
> Those examples are found in the tests/ folder in the source code.
>
> Some other interesting tools for debugging:
>
> ==== X11Vis ====
>
> X11Vis is a small x-request-and-reply interception daemon which you
> can run compiz through in order to debug problems related to calls on
> Xlib (eg XDoThis, XDoThat).  The likelihood of you needing this tool
> is probably quite small since there isn't much in unity except for the
> drag-and-drop code and compiz itself which does a lot of complicated
> Xlib work, but for reference for others, here's how I set it up:
>
> 1. clone it from the github repo
>
> sudo apt-get install git
> git clone https://github.com/x11vis/x11vis.git
>
> 2. install the dependencies
>
> sudo apt-get install cpan
> sudo cpan install AnyEvent AnyEvent::Socket Twiggy Dancer IO::All
> JSON::XS Moose MooseX::Singleton XML::Twig
>
> 3. install x11vis
>
> sudo make install
>
> 4. run the interceptor
>
> ./interceptor/interceptor.pl
>
> The output will be something like:
> "Interceptor running on :8 on 127.0.0.1
>
> Unfortunately, compiz uses server grabs in a few places to ensure that
> in critical sections (eg reparenting, decoration, startup) that we're
> in perfect sync with X11 and that X11 is not processing anybody else's
> requests that could be conflicting with ours until we're done doing
> that operation. This breaks X11vis in a few areas, which sucks. So in
> order to debug these issues you're going to need to build compiz from
> source (there's a build guide here:
> http://wiki.compiz.org/C%2B%2BCompiling). Once you've done that,
> you'll need to edit the following files and comment out references to
> XGrabServer and XUngrabServer:
>
> core/src/window.cpp
> core/src/screen.cpp
> core/src/event.cpp
> core/plugins/decor/src/decor.cpp
>
> There's about 7 or 8 pairs of them. Once that's done, recompile and
> install core and run it like usual to check if it works. Once that's
> done, you can run it under X11vis with something like:
>
> DISPLAY=127.0.0.1:0 compiz --replace ccp &
>
> X11vis will then log and process every single X request that compiz
> (and unity) makes and also every single reply and event that it
> receives. Note that this is a /lot/ of data, mainly because window
> managers are probably the most X-traffic heavy clients out there.
> There's also a request made and events given every time we redraw
> areas of the screen too. So in order to run this, you're going to need
> a fairly powerful machine with a lot of memory (I'd suggest at least
> 4GB). After the (fairly long) startup, you'll be able to interact with
> the interface normally, albeit a bit slower in X-heavy places.
>
> X11vis is only really useful if you have concrete steps the reproduce
> the problem and then you can quickly kill the window manager and use
> metacity or something instead. X11vis also has a handy feature called
> "markers" which help a lot when sifting through the trace reports it
> gives you. Set them with
>
> x11vis -m "Starting to reproduce the bug"
> x11vis -m "Finished reproducing the bug"
>
> Once that's done, you can view the trace reports in a browser while
> the interceptor is running by going to http://localhost:5523 . There's
> a lot of information generated here, and I'd suggest using chromium to
> view this report since the other browsers I've found can't handle that
> much data in AJAX pages. You can then ctrl-f for your marker strings
> and look at all the X traffic coming through both ways there.
>
> ==== ApiTrace ====
>
> ApiTrace is another useful tool which does something similar for
> OpenGL, except that it snapshots the OpenGL state on every frame so
> you can replay frame-by-frame your program to see where rendering
> problems are coming from. Note that at present, it does not work with
> compiz because there is no support for GLX_EXT_texture_from_pixmap, a
> GLX extension that compiz requires. So its only useful at the moment
> on the stuff in tests/
>
> 1. Download it from git
> git clone https://github.com/apitrace/apitrace.git
>
> 2. Install the dependencies
> sudo apt-get install libqson0-dev libqt4-dev libgl1-mesa-dev
>
> 3. Build it
> cd apitrace
> mkdir build
> cd build
> cmake ..
> make && sudo make install
>
> 4. Run your program with the preloaded GL API tracer
>
> LD_PRELOAD=/usr/local/lib/glxretrace.so ./tests/test-places
>
> 5. Retrace it
>
> qapitrace test-places.trace
>
> From there you can inspect bound framebuffers, textures, shaders etc.
>
> That's pretty much everything to do with unity debugging. There's
> other more obscure tools out there that might help, but these ones are
> the main ones that the unity developers use.
>
>>
>> Thanks in Advance,
>> PS: sorry by my poor English
>>
>> Jose Cortés.
>> IRC: Antigravedad
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~ayatana-dev
>> Post to     : ayatana-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~ayatana-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> --
> Sam Spilsbury
>

Thank you for useful information!


Jose Cortés