| Summary: | ASTERISK-12416: Asterisk 1.4.21.1 segfaults many times daily using mixmonitor | ||
| Reporter: | David Brillert (aragon) | Labels: | |
| Date Opened: | 2008-07-20 14:37:42 | Date Closed: | 2009-01-27 14:14:11.000-0600 |
| Priority: | Critical | Regression? | No |
| Status: | Closed/Complete | Components: | Applications/app_mixmonitor |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) 13116.diff ( 1) btfull.txt | |
| Description: | Random crashes while mixmonitor is used backtrace attached ****** ADDITIONAL INFORMATION ****** Asterisk 1.4.21.1 (gdb) bt #0 0x008170ec in memcpy () from /lib/tls/libc.so.6 #1 0x080f75c4 in ast_slinfactory_read () #2 0x080754a5 in audiohook_read_frame_both () #3 0x08075991 in ast_audiohook_read_frame () #4 0x00c087e1 in mixmonitor_thread (obj=0x9d33718) at app_mixmonitor.c:166 ASTERISK-1 0x08106ad0 in dummy_start () ASTERISK-2 0x0095c3cc in start_thread () from /lib/tls/libpthread.so.0 ASTERISK-3 0x008751ae in clone () from /lib/tls/libc.so.6 (gdb) bt full #0 0x008170ec in memcpy () from /lib/tls/libc.so.6 No symbol table info available. #1 0x080f75c4 in ast_slinfactory_read () No symbol table info available. #2 0x080754a5 in audiohook_read_frame_both () No symbol table info available. #3 0x08075991 in ast_audiohook_read_frame () No symbol table info available. #4 0x00c087e1 in mixmonitor_thread (obj=0x9d33718) at app_mixmonitor.c:166 fr = (struct ast_frame *) 0x0 mixmonitor = (struct mixmonitor *) 0x9d33718 fs = (struct ast_filestream *) 0x9de1570 oflags = 577 ext = 0x9d34ce2 "WAV" errflag = 0 __PRETTY_FUNCTION__ = "mixmonitor_thread" ASTERISK-1 0x08106ad0 in dummy_start () No symbol table info available. ASTERISK-2 0x0095c3cc in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. ASTERISK-3 0x008751ae in clone () from /lib/tls/libc.so.6 No symbol table info available. bt also attached as btfull.txt | ||
| Comments: | By: snuffy (snuffy) 2008-07-20 16:10:12 This bt seems a little small.. just to confirm.. was this taken with 'dont optimise' turned on? By: David Brillert (aragon) 2008-07-20 20:15:36 compiled by default w/ DONT_OPTIMIZE, MALLOC_DEBUG and DEBUG_THREADS flags. By: Sean Bright (seanbright) 2008-07-22 15:49:21 Something is wrong with the backtrace, there should be symbol information from the ast_* and audiohooks_* function calls. You might need to do a 'make clean' or even a 'make distclean' and rebuild/reinstall. By: David Brillert (aragon) 2008-07-28 15:20:55 Please close this bug report. Problem appears related to mixmonitor recording all incoming calls. Some DNIS use destination to fax extensions. These calls were also recorded during fax reception . I have made changes to avoid mixmonitor during incoming or outgoing fax. By: snuffy (snuffy) 2008-07-28 15:59:25 closed on request of reporter By: David Brillert (aragon) 2008-07-30 13:24:19 The segfaults are back 27 segfaults in last two days By: David Brillert (aragon) 2008-07-30 13:47:16 I'll try get some better backtraces and possibly install valgrind But what I think is happening is that the DNIS incoming line is monitored. The queue is monitored And the user records each call to and from his local extension I presume this can create some race condition since mixmonitor attempts to record the call multiple times. By: Joel Vandal (jvandal) 2008-07-31 10:55:29 For a very strange reason, this problem occur only night between 04h00 and 05h00am, I see between 5 and 30 core create each night. Always same backtrace on all core dump. By: Sean Bright (seanbright) 2008-07-31 11:24:42 "Always same backtrace on all core dump." Do you have a better backtrace available then the one attached to this issue already? By: Joel Vandal (jvandal) 2008-07-31 11:31:52 Nope :( And this is same trace that someone else post on ASTERISK-12494 By: Joel Vandal (jvandal) 2008-08-02 07:00:42 Another thing I just see is that each time Asterisk crash, few seconds before Hylafax/IAXmodem try to send a fax to an outgoing number. Hylafax -> IAXmodem -> * -> Zap channels Since the crash is about 'mixmonitor' (according to backtrace), does it's possible that MixMonitor have some issues with 'fax signalling' ? I will check on my outgoing dialplan if I use MixMonitor and if this is the case, perhaps ignore this command when it's an outbound fax. (No need to monitor the fax call). By: Joel Vandal (jvandal) 2008-08-04 08:06:26 Problem is caused by 'MixMonitor' and fax tone. == Begin MixMonitor Recording IAX2/iaxmodem0-6286 -- Zap/71-1 is proceeding passing it to IAX2/iaxmodem0-6286 -- Zap/71-1 is ringing -- Zap/71-1 answered IAX2/iaxmodem0-6286 fireworx*CLI> Disconnected from Asterisk server I have fix the crash problem by adding a GotoIf when call from IAXmodem to bypass the MixMonitor(...) application dialplan... exten => s,n,GotoIf($["foo${FAXMODEM}" = "foo"]?$[${PRIORITY} + 1] : $[${PRIORITY} + 2]) exten => s,n,MixMonitor iax.conf... [iaxmodem0] setvar=FAXMODEM=iaxmodem0 By: c0rnoTa (c0rnota) 2008-08-06 04:17:06 I have a similar problems with app_mixmonitor, but my issue appears on SIP voice channels (not fax). I have 3 affected servers. After starting MixMonitor, audiohook.c spams my log files: asterisk 1.4.21.2: [Jul 30 07:42:13] DEBUG[4735] audiohook.c: Read factory 0x8453050 was pretty quick last time, waiting for them. .. [Jul 30 07:42:22] DEBUG[4735] audiohook.c: Write factory 0x8453a6c was pretty quick last time, waiting for them. .. asterisk 1.4.18: DEBUG[XXXX] audiohook.c Failed to get 160 samples from read factory ... After that, server does not crash, but my commands in cli have no answer and no replays. What produces pretty quick factories? Why this message appears? More detailed i wrote in russian forum http://www.asteriskforum.ru/viewtopic.php?t=2636 Sorry for my English. By: David Brillert (aragon) 2008-08-12 10:39:57 After jvandal made changes to dialplan the system no longer segfaults Definitely it seems that mixmonitor and fax don't play nice in same sandbox. By: Mark Michelson (mmichelson) 2008-08-29 11:08:03 c0rnoTa: Those messages are happening due to the way in which the audiohook on a MixMonitor works. If you look at issue ASTERISK-12324 and apply the last patch there (called 13005_final.patch) those messages should go away. I'll take a closer look at the possible ramifications of fax and mixmonitor. By: c0rnoTa (c0rnota) 2008-08-30 07:41:57 Thx a lot, putnopvut. I'll try 13005_final.patch on one of 3 affected servers and give you response late. By: Mark Michelson (mmichelson) 2008-08-30 16:10:19 I looked more closely at the code and couldn't make a direct correlation between the use of fax tones and a crash when using MixMonitor. If it's possible, can you set this up to crash and run valgrind so I can see where the corruption occurs? Thanks! By: David Brillert (aragon) 2008-09-03 15:46:54 Sorry putnopvut I'd love to help but I can't reintroduce the crash into this customer's environment. Jvandal's solution has prevented any segfaults from happening. The workaround does fix my reported problem. http://bugs.digium.com/view.php?id=13116#91041 I think jvandal also implemented something else into dialplan to fix an outgoing call problem related to this dial plan... dialplan... exten => s,n,GotoIf($["foo${FAXMODEM}" = "foo"]?$[${PRIORITY} + 1] : $[${PRIORITY} + 2]) exten => s,n,MixMonitor iax.conf... [iaxmodem0] setvar=FAXMODEM=iaxmodem0 By: Gaëtan Duchaussois (gaetan) 2008-09-03 16:17:47 We have the same problem, but we could not make a relation between crash and faxes. it only occurs time to time. Next crash i will start asterisk with valgrind By: Jens von Bülow (jensvb) 2008-10-28 03:24:46 Hi, I have a system that started doing this yesterday...10+ crashes a day, I have recompiled with "MENUSELECT_CFLAGS=DONT_OPTIMIZE DEBUG_THREADS". Backtrace from latest crash below. <snip> Core was generated by `/usr/sbin/asterisk -f -vvvg -c'. Program terminated with signal 11, Segmentation fault. #0 0x08106f5b in ast_slinfactory_read (sf=0x85b0684, buf=0xb61bbf30, samples=160) at slinfactory.c:132 132 memcpy(offset, frame_data, frame_ptr->samples * sizeof(*offset)); (gdb) set pagination off (gdb) bt full #0 0x08106f5b in ast_slinfactory_read (sf=0x85b0684, buf=0xb61bbf30, samples=160) at slinfactory.c:132 frame_ptr = (struct ast_frame *) 0x865cfa8 sofar = 0 ineed = 160 remain = 140254728 frame_data = (short int *) 0x0 offset = (short int *) 0xb61bbf30 #1 0x0807561c in audiohook_read_frame_both (audiohook=0x85afb50, samples=160) at audiohook.c:246 i = 0 usable_read = 1 usable_write = 1 buf1 = 0xb61bc080 buf2 = 0xb61bbf30 read_buf = (short int *) 0xb61bc080 write_buf = (short int *) 0x0 final_buf = (short int *) 0x0 data1 = (short int *) 0x0 data2 = (short int *) 0x0 frame = {frametype = AST_FRAME_VOICE, subclass = 64, datalen = 320, samples = 160, mallocd = 0, mallocd_hdr_len = 0, offset = 0, src = 0x0, data = 0x0, delivery = {tv_sec = 0, tv_usec = 0}, frame_list = {next = 0x0}, flags = 0, ts = 0, len = 0, seqno = 0} __PRETTY_FUNCTION__ = "audiohook_read_frame_both" #2 0x0807589d in ast_audiohook_read_frame (audiohook=0x85afb50, samples=160, direction=AST_AUDIOHOOK_DIRECTION_BOTH, format=64) at audiohook.c:293 read_frame = (struct ast_frame *) 0x0 final_frame = (struct ast_frame *) 0x0 #3 0x006e344a in mixmonitor_thread (obj=0x85afb50) at app_mixmonitor.c:166 fr = (struct ast_frame *) 0x0 mixmonitor = (struct mixmonitor *) 0x85afb50 fs = (struct ast_filestream *) 0x856edb0 oflags = 577 ext = 0x85b112f "wav" errflag = 0 __PRETTY_FUNCTION__ = "mixmonitor_thread" #4 0x0811821a in dummy_start (data=0x84e4218) at utils.c:895 __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {12173300, 0, -1239692400, -1239694392, 483459930, -1562689262}, __mask_was_saved = 0}}, __pad = {0xb61bc480, 0x0, 0x0, 0xb7dab378}} __cancel_routine = (void (*)(void *)) 0x806a5f7 <ast_unregister_thread> __cancel_arg = (void *) 0xb61bcb90 not_first_call = 0 ret = (void *) 0xb8cb8c a = {start_routine = 0x6e337f <mixmonitor_thread>, data = 0x85afb50, name = 0x85f4be0 "mixmonitor_thread started at [ 286] app_mixmonitor.c launch_monitor_thread()"} lock_info = (struct thr_lock_info *) 0x85748e8 mutex_attr = {__size = "\001\000\000", __align = 1} ASTERISK-1 0x00b8d46b in start_thread () from /lib/libpthread.so.0 No symbol table info available. ASTERISK-2 0x00ae4dbe in clone () from /lib/libc.so.6 No symbol table info available. (gdb) </snip> PS: We do run app_rxfax from "agx-ast-addons" with spandsp5.... but the crashes happen even when app_rxfax is "module unload app_rxfax"'ed.... By: Jens von Bülow (jensvb) 2008-11-27 04:45:02.000-0600 Hi All, I think I have managed to track this one down to the jitter buffer... If I have "jbenabled=yes" in sip.conf, it is usually just a matter of time before the crash happens. (If I force the jitter buffer, it is almost a certainty that asterisk will segfault) I have not tried any of the other jitterbuffer implementations yet. Regards Jens By: Jens von Bülow (jensvb) 2008-11-27 04:50:52.000-0600 Again notice that one of the pointers used in memcpy is null... and that is not going to work <snip> Core was generated by `/usr/sbin/asterisk -f -U asterisk -G asterisk -vvvg -c'. Program terminated with signal 11, Segmentation fault. #0 0x00000000004cb854 in ast_slinfactory_read (sf=0x1376e9d0, buf=0x4185fb30, samples=160) at slinfactory.c:132 132 memcpy(offset, frame_data, frame_ptr->samples * sizeof(*offset)); (gdb) (gdb) bt full #0 0x00000000004cb854 in ast_slinfactory_read (sf=0x1376e9d0, buf=0x4185fb30, samples=160) at slinfactory.c:132 frame_ptr = (struct ast_frame *) 0x13d426d0 sofar = 0 ineed = 160 remain = 0 frame_data = (short int *) 0x0 offset = (short int *) 0x4185fb30 #1 0x0000000000432732 in audiohook_read_frame_both (audiohook=0x1376dde0, samples=160) at audiohook.c:246 i = 0 usable_read = 1 usable_write = 1 buf1 = 0x4185fc80 buf2 = 0x4185fb30 read_buf = (short int *) 0x4185fc80 write_buf = (short int *) 0x0 final_buf = (short int *) 0x0 data1 = (short int *) 0x0 data2 = (short int *) 0x0 frame = {frametype = AST_FRAME_VOICE, subclass = 64, datalen = 320, samples = 160, mallocd = 0, mallocd_hdr_len = 0, offset = 0, src = 0x0, data = 0x0, delivery = {tv_sec = 0, tv_usec = 0}, frame_list = { next = 0x0}, flags = 0, ts = 0, len = 0, seqno = 0} __PRETTY_FUNCTION__ = "audiohook_read_frame_both" #2 0x0000000000432a7e in ast_audiohook_read_frame (audiohook=0x1376dde0, samples=160, direction=AST_AUDIOHOOK_DIRECTION_BOTH, format=64) at audiohook.c:293 read_frame = (struct ast_frame *) 0x0 final_frame = (struct ast_frame *) 0x0 #3 0x00002aaab2a1bbd2 in mixmonitor_thread (obj=0x1376dde0) from /usr/lib/asterisk/modules/app_mixmonitor.so fr = (struct ast_frame *) 0x0 mixmonitor = (struct mixmonitor *) 0x1376dde0 fs = (struct ast_filestream *) 0x2aaad81a7a20 oflags = 577 ext = 0x1376f4c7 "WAV" errflag = 0 __PRETTY_FUNCTION__ = "mixmonitor_thread" #4 0x00000000004deafc in dummy_start (data=0x141c5d80) at utils.c:895 __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {0, -2995632210857998324, 0, 1099303232, 1089486848, 4096, -2995632210857997988, -2995632209754545967}, __mask_was_saved = 0}}, __pad = {0x418601d0, 0x0, 0x13cb7250, 0x0}} __cancel_routine = (void (*)(void *)) 0x4276d5 <ast_unregister_thread> ---Type <return> to continue, or q <return> to quit--- __cancel_arg = (void *) 0x41860940 not_first_call = 0 ret = (void *) 0x33deb49880 a = {start_routine = 0x2aaab2a1bb1e <mixmonitor_thread>, data = 0x1376dde0, name = 0x13bac760 "mixmonitor_thread started at [ 286] app_mixmonitor.c launch_monitor_thread()"} lock_info = (struct thr_lock_info *) 0x13ff7500 mutex_attr = {__size = "\001\000\000", __align = 1} ASTERISK-1 0x00000033df006307 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. ASTERISK-2 0x00000033de8d1ded in clone () from /lib64/libc.so.6 No symbol table info available. (gdb) (gdb) </snip> By: David Brillert (aragon) 2008-11-27 12:40:02.000-0600 I just wanted to say that jvandal's work around did fix my problem in the dialplan. I am the original bug reporter and think this bug report can be closed. However I see others still have problems... I will not be providing any additional feedback so if a marshall decides to close this bug it is not necessary to wait for any additional feedback from myself. I shall leave this to the discretion of the bug marshall's. By: Mark Michelson (mmichelson) 2008-12-01 09:50:23.000-0600 My opinion is that this should not be closed yet given that there still seems to be a problem with the memcpy in ast_slinfactory_read. I can try to run some tests with the jitterbuffer forced and see if I can get the crash to happen myself. By: Martin Vit (festr) 2008-12-01 10:01:11.000-0600 I've created patch for chan_misdn on 1.4 which activates jitterbuffer (this patch is now in 1.6 and trunk). I though my crashdumps is caused by some wiredness in misdn and this jitterbuffer but it could be probably releated to this bug. What I have seen on my system: i was able to reproduce this bug anytime with g729 (intels one) and recording channel. Calls was in this direction misdn->sip with activated jitterbuffer and recording . When no jitterbuffer no crash. What is interesting, when it crashes for the first time, the second time is it ok (probably to some memory allocations). But when i replace asterisk binary and codec binary (but with the same binary) it crashes again very soon. Also what I remember it occurs only on incoming calls from misdn to sip (but not sure 100%). I've also some small patch which puts translators righ after dejittering and crashes gone. Without patch, translators are before putting frames to jitterbuffer and it crashes. Hope that this helped :) edit: i've forgotten to say that it crashes with iLBC too (very often) but with alaw it was hard to reproduce but sometimes it crashed. By: Jens von Bülow (jensvb) 2008-12-01 10:55:58.000-0600 Hi All, Just to update, 1) The first backtrace I provided was on a system where the call was in a zaptel (wct4xxp) 2 sip (snom) direction. 2) The 2nd backtrace was on a sip (asterisk 1.4) 2 sip (snom) direction. I have a 2nd server handling all my PRI's - total of 4 across 2 x wct4xxp - talking to another DL380 - asterisk 1.4 - handling 380 phones (4 x PRI <-> 2 x TE412P <-> DL380 <-> SIP <-> DL380 <-> 380 x SNOM 320 phones) I also tried changing the jitterbuffer from "fixed" to "jbimpl=adaptive"... with "fixed" asterisk segfaults. With "adaptive" asterisk has "blank" calls (no audio) I hope that helps. Regards Jens By: Mark Michelson (mmichelson) 2008-12-01 12:48:28.000-0600 jensvb: what codecs are in use on the calls which crash? By: Jens von Bülow (jensvb) 2008-12-01 15:23:42.000-0600 Hi. I am currently using gsm on the sip2sip calls... just because the snom320 supports it (which was the reason I offloaded the zaptel(alaw)2sip(gsm) transcoding onto its own server. By: Mark Michelson (mmichelson) 2008-12-01 17:38:20.000-0600 jensvb: I tried to reproduce the issue with sip-to-sip calls using a forced, fixed jitterbuffer, but I couldn't make Asterisk crash. If you still have a core dump handy, can you open it in gdb and show what it displays when typing p frame_ptr->samples p frame_ptr->datalen Thanks! I'll also try switching to gsm for my calls to see if that helps to make the crash occur. By: Jens von Bülow (jensvb) 2008-12-01 22:31:09.000-0600 hth.... (gdb) bt full 1 #0 0x00000000004cb854 in ast_slinfactory_read (sf=0x1376e9d0, buf=0x4185fb30, samples=160) at slinfactory.c:132 frame_ptr = (struct ast_frame *) 0x13d426d0 sofar = 0 ineed = 160 remain = 0 frame_data = (short int *) 0x0 offset = (short int *) 0x4185fb30 (More stack frames follow...) (gdb) p frame_ptr->samples $3 = 160 (gdb) p frame_ptr->datalen $4 = 0 (gdb) By: Mark Michelson (mmichelson) 2008-12-02 13:35:01.000-0600 I started wondering how a frame that claims to have 160 samples but has NULL data and a 0 datalen could get in the queue of frames used by MixMonitor. I couldn't reproduce the problem here, but I did find in the jitter buffer code that if a jitter buffer implementation tells the core to interpolate a frame, then a frame will be created with a NULL data pointer, a datalen of 0, but will have its samples set to 160 (240 if iLBC is used). Such interpolated frames seem to be sort of "placeholders" for when the jitter buffer cannot give an actual frame of voice. Such frames appear to be legitimate and have their uses. So I think an appropriate fix is to make sure that before giving a frame off to the MixMonitor's queue of frames, check to make sure that it has data in it first. I'll write a patch for this which you can test. By: Mark Michelson (mmichelson) 2008-12-02 13:45:17.000-0600 I've uploaded a patch, 13116.diff, which I think will fix the issue. Just to make me feel a bit safer about this, if you have a core dump handy, can you open it in gdb and print frame_ptr->src? If its value is "JB interpolation," it will make me feel better about my conclusions I have made while analyzing this. By: Jens von Bülow (jensvb) 2008-12-02 22:48:17.000-0600 Hi There, >> ... open it in gdb and print frame_ptr->src? >> If its value is "JBinterpolation," ... Well done! <snip> (gdb) bt full 1 #0 0x00000000004cb854 in ast_slinfactory_read (sf=0x1376e9d0, buf=0x4185fb30, samples=160) at slinfactory.c:132 frame_ptr = (struct ast_frame *) 0x13d426d0 sofar = 0 ineed = 160 remain = 0 frame_data = (short int *) 0x0 offset = (short int *) 0x4185fb30 (More stack frames follow...) (gdb) print frame_ptr->src $1 = 0x13d42780 "JB interpolation" (gdb) </snip> By: Jens von Bülow (jensvb) 2008-12-02 22:53:02.000-0600 There is a grammatical error in your comment in your diff... >> ... number of samples defined. Once such situation is >> + * when a jitter buffer is in use ... Should probably read "One such situation" By: Mark Michelson (mmichelson) 2008-12-03 16:59:35.000-0600 You're correct about the grammatical error. I will fix it when I merge the patch into Asterisk, assuming that it works correctly to fix the crash. By: Tilghman Lesher (tilghman) 2009-01-07 19:52:59.000-0600 jensvb: can you verify that this patch fixes the issue? By: Joshua C. Colp (jcolp) 2009-01-26 15:43:48.000-0600 There has been no response in quite some time but despite that I think this patch should be fine to put in and should solve the issue. By: Mark Michelson (mmichelson) 2009-01-27 13:59:51.000-0600 All right. I'll merge the patch, then! Thanks. By: Digium Subversion (svnbot) 2009-01-27 14:05:21.000-0600 Repository: asterisk Revision: 171621 U branches/1.4/main/slinfactory.c ------------------------------------------------------------------------ r171621 | mmichelson | 2009-01-27 14:05:20 -0600 (Tue, 27 Jan 2009) | 18 lines Prevent a crash from occurring when a jitter buffer interpolated frame is removed from a slinfactory slinfactory used the "samples" field of an ast_frame in order to determine the amount of data contained within the frame. In certain cases, such as jitter buffer interpolated frames, the frame would have a non-zero value for "samples" but have NULL "data" This caused a problem when a memcpy call in ast_slinfactory_read would attempt to access invalid memory. The solution in use here is to never feed frames into the slinfactory if they have NULL "data" (closes issue ASTERISK-12416) Reported by: aragon Patches: 13116.diff uploaded by putnopvut (license 60) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=171621 By: Digium Subversion (svnbot) 2009-01-27 14:10:49.000-0600 Repository: asterisk Revision: 171622 _U trunk/ U trunk/main/slinfactory.c ------------------------------------------------------------------------ r171622 | mmichelson | 2009-01-27 14:10:49 -0600 (Tue, 27 Jan 2009) | 26 lines Merged revisions 171621 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r171621 | mmichelson | 2009-01-27 14:06:01 -0600 (Tue, 27 Jan 2009) | 18 lines Prevent a crash from occurring when a jitter buffer interpolated frame is removed from a slinfactory slinfactory used the "samples" field of an ast_frame in order to determine the amount of data contained within the frame. In certain cases, such as jitter buffer interpolated frames, the frame would have a non-zero value for "samples" but have NULL "data" This caused a problem when a memcpy call in ast_slinfactory_read would attempt to access invalid memory. The solution in use here is to never feed frames into the slinfactory if they have NULL "data" (closes issue ASTERISK-12416) Reported by: aragon Patches: 13116.diff uploaded by putnopvut (license 60) ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=171622 By: Digium Subversion (svnbot) 2009-01-27 14:12:36.000-0600 Repository: asterisk Revision: 171623 _U branches/1.6.0/ U branches/1.6.0/main/slinfactory.c ------------------------------------------------------------------------ r171623 | mmichelson | 2009-01-27 14:12:36 -0600 (Tue, 27 Jan 2009) | 34 lines Merged revisions 171622 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r171622 | mmichelson | 2009-01-27 14:11:30 -0600 (Tue, 27 Jan 2009) | 26 lines Merged revisions 171621 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r171621 | mmichelson | 2009-01-27 14:06:01 -0600 (Tue, 27 Jan 2009) | 18 lines Prevent a crash from occurring when a jitter buffer interpolated frame is removed from a slinfactory slinfactory used the "samples" field of an ast_frame in order to determine the amount of data contained within the frame. In certain cases, such as jitter buffer interpolated frames, the frame would have a non-zero value for "samples" but have NULL "data" This caused a problem when a memcpy call in ast_slinfactory_read would attempt to access invalid memory. The solution in use here is to never feed frames into the slinfactory if they have NULL "data" (closes issue ASTERISK-12416) Reported by: aragon Patches: 13116.diff uploaded by putnopvut (license 60) ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=171623 By: Digium Subversion (svnbot) 2009-01-27 14:14:08.000-0600 Repository: asterisk Revision: 171624 _U branches/1.6.1/ U branches/1.6.1/main/slinfactory.c ------------------------------------------------------------------------ r171624 | mmichelson | 2009-01-27 14:14:07 -0600 (Tue, 27 Jan 2009) | 34 lines Merged revisions 171622 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r171622 | mmichelson | 2009-01-27 14:11:30 -0600 (Tue, 27 Jan 2009) | 26 lines Merged revisions 171621 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r171621 | mmichelson | 2009-01-27 14:06:01 -0600 (Tue, 27 Jan 2009) | 18 lines Prevent a crash from occurring when a jitter buffer interpolated frame is removed from a slinfactory slinfactory used the "samples" field of an ast_frame in order to determine the amount of data contained within the frame. In certain cases, such as jitter buffer interpolated frames, the frame would have a non-zero value for "samples" but have NULL "data" This caused a problem when a memcpy call in ast_slinfactory_read would attempt to access invalid memory. The solution in use here is to never feed frames into the slinfactory if they have NULL "data" (closes issue ASTERISK-12416) Reported by: aragon Patches: 13116.diff uploaded by putnopvut (license 60) ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=171624 | ||