Version 2 (modified by Sebastien Decugis, 10 years ago) (diff)



This page describes a few steps that you can follow in order to track a problem with freeDiameter.

Gathering debug messages

If your problem occurs following a reproductible sequence of events, you may get useful information by:

  • Compiling the framework with DEBUG support. This is done by selecting for example CMAKE_BUILD_TYPE=Debug during the build configuration (see Installation for more information).
  • Running the daemon with a higher level of details in the debug output. This is done by passing one or more -d flags on the command line. The level can be increased up to 10 times (-dddddddddd) but the framework becomes usually unusable after 4 or 5... Anyway, in most cases, -ddd should give enough feedback to get a precise idea of what is going on.
  • In addition, if you were able to isolate the function or at least source file where the problem is occurring, you can use --dbg_func=<funcname> or --dbg_file=<filename> to get maximum detailed information in this function/file only.

It is also of course possible to use a debugger such as gdb with freeDiameter, although its multithreaded design makes it a bit more difficult.

Reporting a problem

Please use the help function of this site first to look for similar reports. This searches both the existing tickets and the mailing-list archives.

If your problem is not already solved, please report to the support mailing-list: If possible, include as much useful information as possible, including: your configuration file (if relevant, strip / alter any confidential information), the debug messages showing the problem, the Operating System on which you are running the framework, the steps to reproduce the problem. In some cases, a network capture (realized with wireshark for example) may also be helpful.