xpra icon
Bug tracker and wiki

Version 2 (modified by Antoine Martin, 6 years ago) (diff)

add info on debug version of error.py

Debugging

Via Logging

Simply start xpra from the command line and add "-d all" to it. The 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.


Some 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:

grep -re "XPRA_.*DEBUG" src/xpra | grep 'os.environ'
grep -re "XPRA_.*DEBUG" src/wimpiggy | grep 'os.environ'

At time of writing this shows the following options, which should all be self explanatory:

  • XPRA_KEYBOARD_DEBUG
  • XPRA_DAMAGE_DEBUG
  • XPRA_DEBUG_SOUND
  • XPRA_X11_DEBUG

Other Environment Variables

There 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:

grep 'os.environ' src/xpra
grep 'os.environ' src/wimpiggy

Notably:

  • some x264 attributes: XPRA_X264_*_PROFILE, XPRA_X264_*_MIN_QUALITY, XPRA_X264_*_QUALITY
  • a lossless damage threshold values: XPRA_MAX_NONVIDEO_PIXELS and MAX_NONVIDEO_OR_INITIAL_PIXELS
  • sound test: XPRA_SOUND_TEST
  • opengl: XPRA_OPENGL

Please refer to the actual code for details.

GDB

When dealing with crashes ("core dumped"), the best way to debug is to fire gdb.

Getting a Backtrace

xpra start ...
# or xpra attach ...
ps -ef | grep xpra
gdb python $PID_OF_XPRA_PROCESS_TO_DEBUG
# wait for it to load all the debug symbols
(gdb) continue

Then 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. Note: installing the required "debug" symbol packages for your distribution is out of scope, please refer to your vendor's package manager for details (ie: debian and yum debuginfo-install).

X11 errors

Occasionally you may encounter an X11 crash (BadDrawable, BadWindow, etc). These are more tricky. You may need to set a breakpoint:

(gdb) break gdk_x_error

(or _XError if gdk_x_error is not found) And get a backtrace from there when gdb hits it.

Unfortunately, because of the asynchronous nature of X11 calls, the error may generate this crash after the event that caused it. In this case, we may want to force all X11 calls to be synchronized (which will hurt performance and may even hide the bugs - beware of heisenbugs!), trace all X11 calls, etc. this modified error.py allows you to do just that (see the constants at the top).

Venerable Print Statements

When 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..

Attachments (1)

  • error.py (6.7 KB) - added by Antoine Martin 6 years ago. debug version of error.py which allows us to force sync calls, add logging, etc

Download all attachments as: .zip