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

[Kinsey Moore (JIRA)]

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

Kinsey Moore commented on ASTERISK-19373:
-----------------------------------------

Rob,
Would you mind trying the patch on ASTERISK-19762 (ASTERISK-19762_fix.diff)?

> 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