Dialogic Support Helpweb
Dialogic® IP Media Server
How to analyze a core file and submit information to support
Symptom:
Sometimes, processes running in the Dialogic® IP Media Server may cause a core dump if an unexpected situation arises that cannot be handled. Usually, this file is sent to the Dialogic technical support team for further analysis.
To get quicker diagnosis and resolution if this occurs, it is helpful for the user to run a few simple commands to collect the stack trace from the dump file.
To get quicker diagnosis and resolution if this occurs, it is helpful for the user to run a few simple commands to collect the stack trace from the dump file.
Reason for the issue:
When a core dump is created the first step in diagnosis is to extract the stack trace.
Fix / Solution:
If the IP Media Server is operational, use the Web User Interface and after logging in, go to Logs->Core Files menu option and check to see if any core dumps exist. If present, the files can be downloaded through the same menu so that core dump can be sent to the Dialogic technical support team along with the software version information.
To extract the stack trace, use SSH to access the IP Media Server and follow the steps below:
1. After logging in change to super user (run "sudo su" and provide the password).
2. Go to the /var/snowshore/log directory (run "cd /var/snowshore/log") and check to see that the core file is present. The core dump file will be present in this directory with the name core.[processID of the executable that core dumped] name (e.g. core.3253).
3. Run "file [core_dump_file]" and hit Enter (e.g. "file core.3253"). The output will be given as below:
4. After running this step, the last item in the output will indicate the process that crashed; it is within the single quotes at the end (e.g. 'vxmld' above).
5. Once the process/excecutable is identified, run the gdb debugger on the core dump. Go to the /opt/snowshore/bin directory (run "cd /opt/snowshore/bin").
6. To execute the debugger, run the following command - "gdb [crashed_process_name] [core_dump_file]" and hit Enter. For the case above, the execution is as given below along with the output:
7. Up to this point, the core dump analysis contains some data about the files being used to generate the stack dump.
To get the information on the stack, when the "(gdb" prompt comes up (as given above) run the "where" command. This is shown below:
8. At the next "(gdb)" prompt type "exit" to quit the debugger.
9. Save all data from above that came out to stderr and stdout (from steps 3 to 8).
10. Zip up the core dump file and the output obtained above and send it to Dialogic technical support along with information about the scenario that caused the core dump occurred and the version information of the Dialogic® IP Media Server.
Product List
To extract the stack trace, use SSH to access the IP Media Server and follow the steps below:
1. After logging in change to super user (run "sudo su" and provide the password).
2. Go to the /var/snowshore/log directory (run "cd /var/snowshore/log") and check to see that the core file is present. The core dump file will be present in this directory with the name core.[processID of the executable that core dumped] name (e.g. core.3253).
3. Run "file [core_dump_file]" and hit Enter (e.g. "file core.3253"). The output will be given as below:
snow-sip > file core.3253
core.3253: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from 'vxmld'
4. After running this step, the last item in the output will indicate the process that crashed; it is within the single quotes at the end (e.g. 'vxmld' above).
5. Once the process/excecutable is identified, run the gdb debugger on the core dump. Go to the /opt/snowshore/bin directory (run "cd /opt/snowshore/bin").
6. To execute the debugger, run the following command - "gdb [crashed_process_name] [core_dump_file]" and hit Enter. For the case above, the execution is as given below along with the output:
snow-sip > gdb vxmld /var/snowshore/log/core.3253
warning: .dynamic section for "/lib/tls/libpthread.so.0" is not at the expected address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for "/lib/tls/librt.so.1" is not at the expected address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for "/usr/lib/libxml2.so.2" is not at the expected address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for "/lib/tls/libc.so.6" is not at the expected address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for "/lib/ld-linux.so.2" is not at the expected address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for "/usr/lib/libz.so.1" is not at the expected address
warning: difference appears to be caused by prelink, adjusting expectations
warning: .dynamic section for "/lib/tls/libm.so.6" is not at the expected address
warning: difference appears to be caused by prelink, adjusting expectations
379 ScSipTransport.c: No such file or directory.
GNU gdb Red Hat Linux (6.3.0.0-1.132.EL4rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".
Core was generated by `sipd -c 500 -l 500'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/tls/libpthread.so.0...done.
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /lib/tls/librt.so.1...done.
Loaded symbols for /lib/tls/librt.so.1
Reading symbols from /usr/lib/libxml2.so.2...done.
Loaded symbols for /usr/lib/libxml2.so.2
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/tls/libm.so.6...done.
Loaded symbols for /lib/tls/libm.so.6
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
#0 0x0808f7f5 in ScSipXSResend (pstTimer=0x854f068, pvTimerData=0x86ffb18,
bRetriesExhausted=1 '\001') at ScSipTransport.c:379
in ScSipTransport.c
(gdb)
7. Up to this point, the core dump analysis contains some data about the files being used to generate the stack dump.
To get the information on the stack, when the "(gdb" prompt comes up (as given above) run the "where" command. This is shown below:
(gdb) where
#0 0x0808f7f5 in ScSipXSResend (pstTimer=0x854f068, pvTimerData=0x86ffb18,
bRetriesExhausted=1 '\001') at ScSipTransport.c:379
#1 0x0808e984 in TimerThread () at ScTimer.c:654
#2 0x0053e371 in start_thread () from /lib/tls/libpthread.so.0
#3 0x004879be in query_module () from /lib/tls/libc.so.6
8. At the next "(gdb)" prompt type "exit" to quit the debugger.
9. Save all data from above that came out to stderr and stdout (from steps 3 to 8).
10. Zip up the core dump file and the output obtained above and send it to Dialogic technical support along with information about the scenario that caused the core dump occurred and the version information of the Dialogic® IP Media Server.
Product List
Dialogic® IP Media Server
Glossary of Acronyms / Terms
IPMS - IP Media Server
IP - Internet Protocol
IP - Internet Protocol
Related Documentation
Current link to Dialogic® IP Media Server Documentation:
http://www.cantata.com/support/productinfo.cfm?frmProduct=SnowShore%20Media%20Server&frmCategory=Download
http://www.cantata.com/support/productinfo.cfm?frmProduct=SnowShore%20Media%20Server&frmCategory=Download
