If Ekiga doesn't operate as expected or crashes, the debug output helps enormously to understand what is the problem. There are two debug outputs: one is for ekiga internals, and another one is the classical gdb output.
How to get a debug output
This output shows information about ekiga while running (for crashes see the next section). Run ekiga with the following arguments:
ekiga -d 4 2>output.txt
The output.txt file contains the debug output of ekiga you need to send us (see below for how to send it).
- The following information is found in the output file: your IP address, the username and the registrar for all your active SIP accounts (but not the associated passwords), the SIP address of all your contacts in the roster, name of your sound and video card, the active audio and video codecs, and other minor information. If some of them are confidential, replace them with a search/replace.
- If you wish to analyse this file yourself, there is a small script which can help: it shows from this file only the packets exchanged.
How to get a stack backtrace from a crash or freeze
This stack backtrace is needed only when ekiga crashes or when ekiga freezes.
- If you use packages from your gnu/linux distribution, then you need to install debug packages for ptlib, opal and ekiga, whose name end generally in -dbg or -dbgsym, such as libpt-...-dbg (e.g. for ubuntu read DebuggingProgramCrash). These debug packages are additional packages that do not affect your existing program, but provide extra information (debugging symbols) needed by developers. This makes it a lot easier to find the exact place in the program code where that problem occurs, and to fix it.
- If you have compiled ptlib, opal and ekiga yourself, you have nothing to do (by default, compilation is with debug symbols).
Getting the stack backtrace
In a terminal, type:
$ gdb ekiga 2>&1 | tee gdb-ekiga.txt (gdb) run
Note: it's better to enable debug output in the same time. You can start ekiga in a new terminal like this:
$ gdb --args ekiga -d 4 2>&1 | tee gdb-ekiga.txt (gdb) run
Now Ekiga should run normally. Perform the action you did to make it crash, then go back to the terminal window and you should see something like SIGSEGV at... If Ekiga freeze, go back to the terminal window and hit CTRL-C.
At this stage type:
(gdb) thread apply all bt (gdb) quit
The file gdb-ekiga.txt has the backtrace you need to send us (see below for how to send it).
How to get a debug output
If you use ekiga 4.0.0 or later, the simplest solution is to type
ekiga.exe -d 4 using Start->Execute menu.
Alternatively, you can open a command terminal, go to the directory where Ekiga has been installed (using
cd command) and run ekiga like this:
ekiga.exe -d 4
Yet another solution is to change the path in the Ekiga icon in the Desktop from ekiga.exe to ekiga.exe -d 4, and execute it.
In all cases, the output containing Ekiga traces is put in ekiga-stderr.txt on the Desktop. Send us this file (see below for how to send it).
How to get a stack backtrace from a crash
You need to have the GNU Project Debugger gdb at hand. Download it (or alternatively search for the latest bin file), extract from this archive the
gdb.exe file and put it somewhere on your computer (preferably either in
PATH, or in
C:, see below).
Getting the stack backtrace
The simplest method to obtain the stack backtrace is to open a command terminal, go to the directory where ekiga is installed, for example:
cd "Program Files"\Ekiga
afterwards start gdb like this:
or, if gdb is not in the PATH, prefix it with its full path, for example:
You will see a few lines printed and a prompt
Now Ekiga should run normally.
Perform the action you did to make it crash than go back to the previous msys window and you should see something like
At this stage type
thread apply all bt then press "Enter" and send us the display (see below for how to send it).
(An alternative method to get the stacktrace is presented at http://www.freedroid.org/dev_docu/node4.html.)
How to break the execution of Ekiga in case it freezes
If your problem is that Ekiga freezes (without crashing), then you need to break Ekiga with CTRL-C. Due to different handling of CTRL-C on windows, pressing it during the execution of Ekiga in gdb either does nothing, or exits the application and gdb as well. A workaround is to use the small application debugbreak shown at this post to send a "break signal" to Ekiga.
For that, get that file, replace Windows.h with windows.h in it and compile it on gnu/linux with the command (do not take into account the four warnings about printf):
i686-w64-mingw32-gcc -o debugbreak.exe -mthreads debugbreak.c
or, if you use the old mingw32:
i586-mingw32msvc-gcc -o debugbreak.exe -mno-cygwin -mthreads debugbreak.c
Finally, you execute it on Windows in a command terminal with:
where PID is the process identifier of Ekiga during the execution. To find out the PID, open Task Manager (right-click on bottom bar and choose Task Manager), click on Processes tab and look for ekiga.exe (if PID column is not shown, then choose View->ColumnSelection and check on PID (Process Identifier) item to show it).
Sending the data to us
If the output is greater than about 35KB, then:
- either compress it (gzip output),
- or copy it on an Internet site like http://pastebin.ca/ (and give us the link)
After that, send us the output and add a description of the actions you performed when Ekiga did not act correctly.
Note that there is no moderator on ekiga mailing lists, so if you receive an e-mail with an error like "message is too big, your e-mail is waiting moderator approval", you have to resend your message by reducing the size even more.