In an ideal world, everything should always work reliably without any glitches.
But this is not an ideal world, so you may encounter problems (sorry!), this section should help you figure out what is going wrong or at least help you gather enough information so that someone can help you.
Where is the problem?The first thing to do is to identify the problem:
- If the application does not even start, look at early failures below
- Always enable debug mode, this will report more information which may be useful to you or others trying to help you
- Have you checked the FAQ?
- Connection problems?
- Session problems?
- If you still cannot find a solution to your problem, just ask
Getting More InformationThe first thing to do is to run the software (this applies to both the server and the applet) in debug mode.
This can be done in the Configuration panel for the applet, in the configuration files, using a signal (see below), or by starting the software from the command line and adding
--debug_mode, ie for the applet:
Threads and signalsIn case you suspect a threading problem, you can send the
SIGUSR1signal to make the process dump all the threads currently active.
It will also turn on debugging, which can be turned off with
To get more diagnostic messages (especially in the case of non-start or early failures), you may also launch the client from the command line:
This will print all the early diagnostic messages to your terminal.
winswitch_applet --log_to_tty --debug-imports
Because of the asynchronous nature of the
X11 protocol, you will generally get a cryptic
error message of the form:
The error was 'BadWindow (invalid Window parameter)'. (Details: serial 473436 error_code 3 request_code 42 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)
In order to debug these types of errors with GTK3 you will need to run the application in gdb (either launch it from there - or simply attach to the process pid) and ensure that the application is started with the following environment variable set:
You should then be able to get a backtrace using gdb. You may be able to break on
For more information, including many environment variables used for debugging GTK internals, see GTK running (gnome.org).