Problem Reporting

If you encountered a problem in SER, let us know -- we will be glad to verify and fix it. To keep our development effort focused, help us please by following these suggestions:

• Verify that the problem is not already fixed. See the "ISSUES" link above.
• Decide where to post your report.
  • If you are using a stable release, post to our user forum at serusers@iptel.org so that the user community is aware of a problem.
  • If you are user of a CVS snapshot, post please to serdev@iptel.org to make sure that the user community is not burdened with development issues.
  • Our support customers are encouraged to use serhelp@iptel.org for the most rapid answers to their problems.
• Include information related to your setting and problem:
  • Name and version of your operating system -- you can obtain it by calling uname -a
  • SER distribution: release number and package
  • SER build -- you can obtain it by calling ser -V
  • Your SER configuration file
  • SER logs -- with default settings few logs are printed to syslog facility which typically dumps them to /var/log/messages. To enable detailed logs dumped to stderr, apply the following configuration options: debug=8, log_stderror=yes, fork=no.
  • Captured SIP messages -- you can obtain them using tools such as ngrep or ethereal.
  • If SER crashed, send us backtrace or the whole core. To generate core dump you need to:
    • Have sufficient core quota on your system (use ulimit -c LIMIT to set it high)
    • Have writing permissions in SER's working directory. You can set the directory with SER's command-line option "-w DIR_NAME".
    • You may better recompile SER in debug mode: make clean; make all mode=debug (compiler's optimization can otherwise eliminate some important debugging information)
    To print backtrace, start gdb (gdb ser CORE_FILE) and type "bt". If you send us the core, use caution as it may grow big. Create a compressed (gzip/bzip2) tarball of all: sources, binaries and core. Put it on your web/ftp server or send it by email separately to serhelp@iptel.org (This email address has no size quota.)
  • If you think there is a memory leak , enable memory debugging and watch server's exit log for excessively frequent reports on unallocated memory fragments. Be prepared to have to filter out many reports for fragments that do not free on server exit -- just seek such which repeat too frequently.
    • enable debugging support in binaries: replace -DF_MALLOC with -DDBG_MALLOC in Makefile.defs and recompile all ser (make proper; make all)
    • set adequate memory reporting level in ser configuration file: memlog must be lower than debug (e.g., memlog=2, debug=3)
    • restart ser and run it for sufficiently long period of time
    • kill ser (killall -TERM ser)
    • analyze memory report in syslog
    • report how much traffic and time it took for memory exhaustion to occur from server start