xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.


Changes between Initial Version and Version 1 of Debugging


Ignore:
Timestamp:
01/07/13 08:53:48 (8 years ago)
Author:
Antoine Martin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Debugging

    v1 v1  
     1= Debugging =
     2
     3== Via Logging ==
     4Simply start xpra from the command line and add "{{{-d all}}}" to it.
     5The amount of data logged can be overwhelming, so make sure you log it to a file then you can use grep to find and extract the data you are looking for.
     6
     7[[BR]]
     8
     9Some modules do not log by default, either to reduce the amount of logging or to avoid the overhead of logging in critical paths. Logging can generally be enabled using environment variables, you can find the list of such runtime configuration options with:
     10{{{
     11grep -re "XPRA_.*DEBUG" src/xpra | grep 'os.environ'
     12grep -re "XPRA_.*DEBUG" src/wimpiggy | grep 'os.environ'
     13}}}
     14At time of writing this shows the following options, which should all be self explanatory:
     15* {{{XPRA_KEYBOARD_DEBUG}}}
     16* {{{XPRA_DAMAGE_DEBUG}}}
     17* {{{XPRA_DEBUG_SOUND}}}
     18* {{{XPRA_X11_DEBUG}}}
     19
     20
     21== Other Environment Variables ==
     22There are other environment variables which can be used to tune the behaviour of the system and may be used for debugging or testing, you can obtain the full list with:
     23{{{
     24grep 'os.environ' src/xpra
     25grep 'os.environ' src/wimpiggy
     26}}}
     27Notably:
     28* some x264 attributes: {{{XPRA_X264_*_PROFILE}}}, {{{XPRA_X264_*_MIN_QUALITY}}}, {{{XPRA_X264_*_QUALITY}}}
     29* a lossless damage threshold values: {{{XPRA_MAX_NONVIDEO_PIXELS}}} and {{{MAX_NONVIDEO_OR_INITIAL_PIXELS}}}
     30* sound test: {{{XPRA_SOUND_TEST}}}
     31* opengl: {{{XPRA_OPENGL}}}
     32Please refer to the actual code for details.
     33
     34
     35== GDB ==
     36When dealing with crashes ("core dumped"), the best way to debug is to fire gdb.
     37=== Getting a Backtrace ===
     38{{{
     39xpra start ...
     40# or xpra attach ...
     41ps -ef | grep xpra
     42gdb python $PID_OF_XPRA_PROCESS_TO_DEBUG
     43# wait for it to load all the debug symbols
     44(gdb) continue
     45}}}
     46Then once you get a crash, gdb should show you its prompt again and you can extract the python stacktrace with {{{py-bt}}} and the full stacktrace with {{{bt}}}. Having both is useful.
     47Note: installing the required "debug" symbol packages for your distribution is out of scope, please refer to your vendor's package manager for details (ie: [http://wiki.debian.org/HowToGetABacktrace debian] and [http://yum.baseurl.org/wiki/YumUtils/DebugInfoInstall yum debuginfo-install]).
     48
     49=== X11 errors ===
     50Occasionally you may encounter an X11 crash ({{{BadDrawable}}}, {{{BadWindow}}}, etc). These are more tricky. You may need to set a breakpoint:
     51{{{
     52(gdb) break gdk_x_error
     53}}}
     54(or {{{_XError}}} if {{{gdk_x_error}}} is not found)
     55And get a backtrace from there when gdb hits it.
     56
     57Unfortunately, because of the asynchronous nature of X11 calls, the error may generate this crash after the event that caused it.
     58''need more info on debugging this case..''
     59
     60== Venerable Print Statements ==
     61When all else fails, or just when appropriate, sprinkling some {{{print}}} statements around the critical sections of code is often the best way to get a clearer picture of what is really going on..
     62