Bugs or missing features are always possible in any software or other branches of engineering. We will try to fix the problems in Yate as soon as possible. Please note that our priorities may be different than yours.

Even if you spent time and accumulated frustration trying to fix a problem you should always make a good report of the problem. Try to make it brief, informative and correct. Simply writing: “It doesn't work!” will hardly ever get the problem fixed or investigated.

Before making a bug report you should check if the problem was known before. Someone may be working on it, it may have been fixed or there may be workarounds.

Make sure you are running a clean build of Yate. Subtle problems may be caused by partial builds. If the compiler crashed at any point you should clean everything and start building from start.
Read the Documentation, especially the parts related to your problem.
Verify if any other equipment or software you use is compatible with Yate.
Check the Bug tracker for open bug reports of the problem. Please look at the closed and resolved bugs too – the problem may have been already fixed in a new release or in Git.
Check the List archive if the problem wasn't reported before.
Ask our friend, Google.

Making a useful bug report is not difficult. You have to provide us maximum of information so we can locate the problem.

A brief description of the problem, what you expected to happen and what you actually observe happening.
Whether the problem appears always or is intermittent.
Details about the hardware you are running Yate on – type, speed and number of processors, size of memory.
The version of your operating system and/or distribution.
Information on any firewall or NAT you may have on that computer or in the network (for VoIP protocols).
Version of Yate, date of latest Git update if applicable.
Logs, preferably with the highest level of debugging. Please enable timestamping (options -Dt, -De or -Df).
Backtraces of the stack if Yate crashes and a core dump is available.
Ethereal packet captures or at least tcpdump logs (tcpdump -nn is usually enough) if you suspect network related problems.

Please do NOT include large log files. Also, never include core files – they are useless without the executable that crashed and all its libraries and modules.

Do not use screen or telnet captures from rmanager. Some scripts and third party libraries write only to the log file and you may be missing important information if you take it from other sources. Only log file or console information is complete.

Crashes caused by memory corruptions leave useless core files (since the damage was caused earlier, typically by a different thread). If you see "glibc detected ... memory corruption" then please do not post such backtraces. The logs may provide some information about what went wrong.

There are several places you can use to report bugs:

For small problems or just to quickly ask a question you can use IRC – the #yate channel on the Freenode network (irc.freenode.net).
More complex problems can be asked on the Mailing List. – the answer may be slower but more people may be able to answer.
Finally, there's the Bug tracker where you can report a problem, add notes, logs and patches and track how the report was handled.

Creating an useful backtrace may be tricky. Here is a formula to get plenty of information:

Replace core FILENAME with the name of the generated core file. The yate-bt-all.log file will contain a backtrace of all threads. For best results Yate should be compiled with debug symbols. This does not hit the performance or memory usage, just increase the size of the files on disk.

Recent versions of Yate provide a readily made gdb-bt-all.txt in the tools subdirectory of sources.

If you have a core dump but Yate was compiled without symbols you can recompile it and get a proper backtrace – just make sure you don't change the source or configure options. Issuing a "make clean debug" will recreate all binaries with exactly the same addresses but with debugging information. Do not use "make ddebug" or "make xdebug" as these will change the code.

If Yate doesn't create core files when it crashes:

Check that the directory Yate is started in is writable, there's where the core files are dumped.
Make sure you set something like ulimit -c unlimited or start Yate with the -C command line option.
Check if core size limits aren't restricted by the superuser, system policy or filesystem quota.