| 04:25.27 | *** join/#asterisk-dev infobot (ibot@96-86-209-99-static.hfc.comcastbusiness.net) |
| 04:25.27 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 08:03.53 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.110) |
| 08:03.53 | *** mode/#asterisk-dev [+o jkroon] by ChanServ |
| 09:39.18 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.110) |
| 09:39.18 | *** mode/#asterisk-dev [+o jkroon] by ChanServ |
| 11:07.07 | *** join/#asterisk-dev andrewya_ (~andrewyag@114.141.97.1) |
| 12:26.14 | *** join/#asterisk-dev music (~music@pool-108-45-131-149.washdc.fios.verizon.net) |
| 14:20.50 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-xvortrkwmktnxfra) |
| 14:20.50 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:33.02 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-zkzuxirzyuwhpyox) |
| 14:33.02 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:34.58 | *** join/#asterisk-dev jkroon (~jkroon@105.12.1.197) |
| 15:34.59 | *** mode/#asterisk-dev [+o jkroon] by ChanServ |
| 17:06.07 | *** join/#asterisk-dev andrewyager (~andrewyag@114.141.97.1) |
| 18:01.34 | *** join/#asterisk-dev InterLinked (~ambassado@cpe-24-209-155-151.wi.res.rr.com) |
| 18:02.15 | InterLinked | Is anyone here familiar with audiohooks and limitations of directly modifying frames in callbacks? Whenever I modify the frame data in a loop, Asterisk crashes and I get a High fence violation memory corruption, but I'm doing so consistent with how other audiohooks modify frames, such as func_volume. I've checked and the data size is 2 bytes and even using 1-byte values causes a crash, so... |
| 18:02.17 | InterLinked | ...it doesn't seem to be a buffer overrun. |
| 18:36.05 | kharwell | frames are translated to slin before being passed to the audiohook correct? What's the native format of the frame before translation? I wonder if something is corrupting the data elsewhere |
| 18:44.30 | InterLinked | This is on an IAX2 -> SIP call using uLaw/G711, if that's what you mean? |
| 18:55.56 | kharwell | Does the problem still occur on a SIP -> SIP call? |
| 19:21.55 | InterLinked | Yes, it does, but the actual dialplan content seems to matter. When I have a SIP -> SIP call or an IAX2 -> SIP call, it crashes. If I have an income SIP call that just does PlayTones() and doesn't make an outgoing call, it doesn't crash. |
| 19:27.14 | InterLinked | It also crashes on a SIP -> Local -> SIP call. |
| 19:58.03 | InterLinked | Further testing reveals that simply playing an audio file will cause it to crash as well. PlayTones, however, does not. |
| 19:59.39 | file | there are multiple ways audiobook can be used (different types), showing backtrace and code has a better chance of yielding help |
| 20:20.29 | electronic_eel | InterLinked: crashes on just some seemingly independent actions are often a sign of some memory corruption always happening, but with slightly random variations in effect due to different memory layout depending on your actions |
| 20:20.54 | electronic_eel | i usually have a go with valgrind in that case |
| 20:21.27 | electronic_eel | but i haven't tried asterisk in valgrind, so there might be some noise even in a unmodified asterisk |
| 20:23.59 | InterLinked | All right, here is the latest core dump. Every single dump seems different, this one for instance doesn't say fence explicitly, but they all seem memory related. Some have do_crash, some don't. The function code is here: https://code.phreaknet.org/asterisk/func_notchfilter.c |
| 20:24.35 | InterLinked | Line 427 is the line that is causing the crash, and searching for "y >> NB" will take you there. A lot of this is old Zaptel code which I ported in, some of which was C++ which had to be rewritten in C. |
| 20:24.54 | InterLinked | Core dump: https://code.phreaknet.org/asterisk/core-full.txt |
| 20:27.31 | kharwell | In your call to sf_detect try passing in frame->samples instead of frame->datalen |
| 20:34.00 | InterLinked | ...Wow, I feel like an idiot now, I think that might be it, it hasn't crashed so far, at least! frame->samples is 160, as opposed to the datalength between 2x as much since each is 2 bytes. I guess that would explain why I could always read something that looked normal in those memory locations but writing to 160-320 in the array caused corruption. |
| 20:36.06 | InterLinked | Thank you, it does run without crashing now! It doesn't do what it's supposed to do, but that's a different issue. |
| 20:37.21 | kharwell | cool deal glad that fixed it for you. It's easy to get the datalen and samples swapped |
| 20:40.25 | InterLinked | I believe the sample values represent amplitudes, so as long as they are not all 0, one should *probably* hear something, right? Or is that not necessarily the case? |
| 20:47.44 | kharwell | I *think* that is correct. That is 0 is essentially silence, or non audio or whatever the correct word :-) |
| 21:18.45 | InterLinked | Okay, still some things to do, but I think it's getting there as my notch filter partially works now. Since my code incorporates a lot of defunct Zaptel code, is there anything special as far as citing that? Or is that covered by the general Asterisk GNU license? I did have to rewrite all the C++ to C, but the stuff that was already C I didn't modify. |
| 21:41.40 | *** join/#asterisk-dev andrewya_ (~andrewyag@114.141.97.1) |
| 21:48.09 | kharwell | Not 100% sure actually. I think if the source used is licensed under the GPL or something less restrictive, and you give attribution then maybe fine? However Asterisk has a dual licensing model so not sure how that'd fit. |
| 21:52.54 | file | code as taken from that fork of zaptel is a no-go if it exists only in it |
| 22:05.24 | InterLinked | I'm not 100% sure if it's a Zaptel fork or the original Zaptel itself. Much of the code specific to the notch filter is from old Zaptel code, since Zaptel had a notch filter and a bunch of stuff that no longer exists with DAHDI. The 3 parts are a complex math library in C++, which I rewrote into C, mknotch from 1992 (not Zaptel-exclusive), and then the sf_detect function in the Zaptel core... |
| 22:05.25 | InterLinked | ...to do the notch stuff. |
| 22:06.26 | InterLinked | I think the last part might be the only thing that's "Zaptel-exclusive", would I be able to rewrite that somehow so it's different or is that still not compliant? I know there were some issues with Zaptel but I don't know if that was just the trademark or the code too. |
| 22:17.04 | file | the code was fine |
| 22:17.23 | file | it ultimately depends upon the licensing of everything involved/taken from |
| 22:21.16 | InterLinked | Okay, it looks like almost everything was code from something else in 1992, included in Zaptel - the only thing I am concerned about is I took the sf_detect function from this: https://github.com/pttlink/zaptel/blob/0b47d748d2bfd33af60667a934da74d71f83f5c3/kernel/zaptel-base.c - this seems to be the Zaptel-specific part |
| 22:21.58 | file | if it exists only in the fork then it can't be used, if it exists in dahdi as we distribute then it's fine |
| 22:22.53 | InterLinked | It doesn't exist in DAHDI, a lot of signalling support was removed in the transition. If I rewrote it slightly, would that be good enough or not really? It's a fairly simple algorithm so I'm not sure how to change it up drastically |
| 22:23.40 | file | https://www.irccloud.com/pastebin/O0svP0jq/ |
| 22:24.03 | file | ...looks like there's an sf_detect in dahdi? |
| 22:25.02 | InterLinked | Yup, I was looking in the wrong place, my bad |
| 22:25.37 | InterLinked | Looks like it's exactly the same. This is intended to be channel agnostic, even if DAHDI isn't installed, so can I just note that it's DAHDI code and include it in the function? I think that covers all the attribution then |
| 22:25.47 | file | yes |
| 22:27.00 | InterLinked | Excellent, thank you! |
| 22:27.36 | file | I expect you'll be the only one who will ever use this thing |
| 22:28.17 | InterLinked | Quite a few people, likely, in certain communities. People have been asking for this kind of thing for a while, so I went ahead and cobbled it together. |
| 22:28.29 | file | uh huh |
| 22:28.53 | InterLinked | Basically, it's useful for filtering out the 2600 Hz frequency in SF signalling. |
| 22:29.20 | InterLinked | I don't know what other uses exist for it, but that's what I suspect most uses of it would be, filtering 2600 Hz out |