SERi [1] developers put immense effort in developing stable and robust software. However, error reports appear -- sometimes they are caused by misconfiguration, sometimes by software error, sometimes they are just false alarms. This memo provides you with suggestions how to look for help:

• First, make sure you have made yourself familiar with SER documentation [2], SER FAQ [3] and SER Howtos [4] -- frequently you may find an answer to your problem there
  [5]
• Then you may try to search in SER mailing list archives [6] and if still unsuccesful, you can try to solicit help from the mailing list [7]
  
• If you are sure that the problem is caused by software error, submit a report to our bug tracking system [8].
  
• Include all the information our bug tracker is asking for: version, name of suspected component if known, environment (OS version -- you can obtain this using "uname -a", hardware, etc.) and detailed desription of the error.
• The description should include message dumps (you can obtain those using ngrep, tcpdump, ethereal or other popular utilities), message logs (typically somewhere under /var/log, depending on the OS you are using) and your SER configuration file. Mention if the code you are using has been modified.
  
• 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 seri [9] 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 and notify serdev@iptel.org.
• 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