[asterisk-bugs] [JIRA] Commented: (ASTERISK-19373) Segmentation Fault in ast_udptl_write() due to bad memcpy() call

Fri Aug 17 10:58:07 CDT 2012

    [ https://issues.asterisk.org/jira/browse/ASTERISK-19373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195903#comment-195903 ] 

Rob Gagnon commented on ASTERISK-19373:
---------------------------------------

We upgraded 8 of our servers from 10.5.2 (without the patch) to 10.7.0 (with the 19762 patch) on 8/9/2012.  Without any issues appearing by the 14th, we upgraded the rest of them, and so far have no seg faults caused by this issue.

This is generally good news, and reading the code of the patch, looks like it should solve the problem.  For full disclosure though, I think our T.38 call volume is much lower than it has been due to our platform not always being able to handle the fax calls because of the bug.  We are still waiting for more of our customers to start routing more of their T.38 calls through us.

We've also had updates from CentOS for glibc that may have been a contributing issue as well.  I would bet we could close this issue and re-visit it if anything comes up again.

> Segmentation Fault in ast_udptl_write() due to bad memcpy() call
> ----------------------------------------------------------------
>
>                 Key: ASTERISK-19373
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-19373
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/T.38
>    Affects Versions: 10.1.2
>         Environment: CentOS 5.7 x86_64 24GB Intel Xeon X5650 2.67GHz
>            Reporter: Rob Gagnon
>         Attachments: asterisk-1.8.3.2-t38-null-frame-crash.patch, ASTERISK-19373.diff, T19373_bt_full2.txt, T19373_bt_full.txt, T19373_sip_trace.pcap
>
>
> During Fax gateway processing over SIP, Asterisk core dumps very rarely, but we did finally correlate a core dump to an event in the logs.
> gdb output:
> ~~~~~~~~~~~
> Core was generated by `/usr/sbin/asterisk -f -U asterisk -G asterisk -vvvg -c'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x0000003cb987c312 in memcpy () from /lib64/libc.so.6
> (gdb) bt
> #0  0x0000003cb987c312 in memcpy () from /lib64/libc.so.6
> #1  0x0000000000544c18 in ast_udptl_write ()
> #2  0x00002aaab33ca304 in sip_write (ast=0x15be71a8, frame=0x2aaab8aea008) at chan_sip.c:6577
> #3  0x0000000000472c33 in ast_write ()
> #4  0x0000000000477d11 in ast_generic_bridge ()
> #5  0x0000000000478d1e in ast_channel_bridge ()
> #6  0x00000000004a8ad5 in ast_bridge_call ()
> #7  0x00002aaab2f72e88 in dial_exec_full (chan=0x2aaab87a7018, data=<value optimized out>, 
>     peerflags=0x41593590, continue_exec=0x0) at app_dial.c:2829
> #8  0x00002aaab2f74ea6 in dial_exec (chan=0x169f3670, 
>     data=0x2000000000 <Address 0x2000000000 out of bounds>) at app_dial.c:2929
> #9  0x00000000004f807f in pbx_exec ()
> #10 0x00002aaaaab2104b in handle_exec (chan=0x2aaab87a7018, agi=0x41594830, argc=3, argv=0x41593720)
>     at res_agi.c:2495
> #11 0x00002aaaaab2002c in agi_handle_command (chan=0x2aaab87a7018, agi=0x41594830, 
>     buf=<value optimized out>, dead=0) at res_agi.c:3390
> #12 0x00002aaaaab25f72 in run_agi (chan=0x2aaab87a7018, data=<value optimized out>, 
>     enhanced=<value optimized out>, dead=0) at res_agi.c:3581
> #13 agi_exec_full (chan=0x2aaab87a7018, data=<value optimized out>, enhanced=<value optimized out>, 
>     dead=0) at res_agi.c:3873
> #14 0x00000000004f807f in pbx_exec ()
> #15 0x00000000005078bb in pbx_extension_helper ()
> #16 0x000000000050a68b in __ast_pbx_run ()
> #17 0x000000000050ca7b in pbx_thread ()
> #18 0x000000000054712c in dummy_start ()
> #19 0x0000003cba00673d in start_thread () from /lib64/libpthread.so.0
> #20 0x0000003cb98d44bd in clone () from /lib64/libc.so.6
> (gdb) up
> #1  0x0000000000544c18 in ast_udptl_write ()
> (gdb) up
> #2  0x00002aaab33ca304 in sip_write (ast=0x15be71a8, frame=0x2aaab8aea008) at chan_sip.c:6577
> 6577    chan_sip.c: No such file or directory.
>         in chan_sip.c
> (gdb) p ast->tech_pvt                                                                                    
> $2 = (void *) 0x15c66bf8
> (gdb) p *0x15c66bf8
> $3 = 0
> Message in log file at the same time:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> [Feb 14 08:17:53] WARNING[29141] udptl.c: UDPTL (SIP/XXXXXXXXX-00002a8f): UDPTL asked to send 373781248 bytes of IFP when far end only prepared to accept 375 bytes; data loss will occur.You may need to override the T38FaxMaxDatagram value for this endpoint in the channel driver configuration.
> T38FaxMaxDatagram should be 400 here, as it is set via sip.conf:
> t38pt_udptl=yes,fec,maxdatagram=400
> I would think the "373781248 bytes" is the problem.  This was probably a faulty packet size sent from one side, or it could have been a faulty math problem in the server maybe?
> I also suspected a faulty memory module on the server, however, the server is one of 32 blades running in an HP blade system, and the internal HP hardware monitor indicates no problems with the devices.
> ===================================================
> I'm going to investigate this issue myself as well, but wanted to post the ticket in case there are more people with similar problems, or if someone more familiar with this area of the code can see a simple solution.
> I'm also about to install Asterisk with DEBUG_THREADS and DONT_OPTIMIZE enabled in order to obtain possibly more information if and when another core happens.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira