| 06:27.44 | *** join/#asterisk-dev Deeewayne (~dwayne@2605:a601:a803:7800:ffaf:2fa4:84dc:10e4) |
| 06:27.44 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 07:02.26 | *** join/#asterisk-dev vipul20 (uid64067@gateway/web/irccloud.com/x-hzehhftejrttxbqj) |
| 07:13.34 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 07:18.36 | *** join/#asterisk-dev pchero_work (~pchero@87.213.240.121) |
| 07:34.00 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 10:06.16 | *** join/#asterisk-dev pchero_work (~pchero@87.213.240.121) |
| 11:16.11 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 11:16.11 | *** topic/#asterisk-dev is Take the March 2019 Asterisk User Survey! https://goo.gl/forms/xL1VUHRsf95saly13 -- 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 |
| 11:35.11 | *** join/#asterisk-dev tzafrir (~tzafrir@lemon.tzafrir.org.il) |
| 11:35.11 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 11:50.00 | *** join/#asterisk-dev pchero_work (~pchero@51.247.195.35.bc.googleusercontent.com) |
| 13:03.11 | danjenkins | could someone give me a hand with some pattern matching for dialplan? how do i say I want *4 and then as many numbers as you want? |
| 13:03.21 | danjenkins | . is just wildcard so allows letters |
| 13:03.49 | danjenkins | am i forgetting about some regex type functionality? |
| 13:04.24 | danjenkins | or do i have to use the regex function :S |
| 13:04.41 | danjenkins | oh i cant do that as thats a route identifier |
| 13:10.10 | jsmith | danjenkins: You'd think that would be easy, but it's complicated, because there's no easy way to say "one or more digits" |
| 13:10.33 | jsmith | danjenkins: _*4. would grab anything that started with *4, including numbers or letters. |
| 13:10.34 | danjenkins | glad im not going mad |
| 13:10.42 | danjenkins | right! |
| 13:11.17 | danjenkins | i understand there has to be a limit for the pattern matching to work as it does :) |
| 13:11.46 | danjenkins | i was just trying to make it extremely flexible for the client but i'll go back to him and ask for specifics |
| 13:16.46 | danjenkins | thanks jsmith |
| 13:17.28 | seanbright | never knew about @ variables |
| 13:17.49 | seanbright | was the original blog entry just the stuff above the ~~~~~ ? |
| 13:37.44 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.37.79) |
| 13:46.10 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-ucydgdtzhudqugjf) |
| 13:46.10 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:04.12 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:04.12 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:15.53 | gtjoseph | seanbright: yes |
| 14:16.28 | tsearle | so I wasn't the only one who didn't know about the @ variables :-P |
| 14:18.50 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-ekwiystiwsubawzs) |
| 14:18.50 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:19.06 | tsearle | also from the blog I gather that @ variables are read only |
| 14:19.22 | tsearle | e.g. you can't use it as a endpoint scoped counter for example |
| 14:19.50 | file | endpoints are always immutable |
| 14:24.46 | *** join/#asterisk-dev tzafrir (~tzafrir@lemon.tzafrir.org.il) |
| 14:24.46 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 14:25.58 | seanbright | gtjoseph: did you lose a bet or something? |
| 14:26.45 | cresl1n | My breakfast is sometimes immutable |
| 14:27.21 | tsearle | immutable breakfasts are the worst! |
| 14:31.12 | seanbright | oh hey, the green line is above the red line! |
| 14:31.14 | seanbright | progress |
| 14:35.33 | seanbright | ASTERISK-28307 and ASTERISK-28337 have similar backtraces |
| 14:37.05 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-ghaezfcohegxleyh) |
| 14:37.05 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:45.42 | seanbright | nevermind, i misread |
| 14:56.07 | jsmith | Shoot -- even *I* didn't know about the @ variables... |
| 15:00.46 | seanbright | but it's documented right in main/sorcery.c at line 1017 |
| 15:00.49 | seanbright | get with it, jsmith |
| 15:01.02 | jsmith | seanbright: I know, right?!? I'm getting old... and slow... |
| 15:01.54 | seanbright | https://reviewboard.asterisk.org/r/2585/ |
| 15:12.56 | *** join/#asterisk-dev tzafrir (~tzafrir@lemon.tzafrir.org.il) |
| 15:12.56 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 17:03.34 | *** join/#asterisk-dev CELYA_ (~Thunderbi@lstlambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 18:10.39 | seanbright | is there a call-limit equivalent in chan_pjsip? |
| 18:11.18 | file | no |
| 18:12.19 | seanbright | k |
| 18:17.04 | seanbright | kharwell: i _could_ use realloc |
| 18:17.18 | seanbright | i don't understand why the current __make_room doesn't |
| 18:17.30 | kharwell | yeah I was kinda wondering the same thing |
| 18:17.31 | seanbright | maybe because it has to zero the suffix region anyway? |
| 18:17.38 | seanbright | hmmm |
| 18:17.42 | seanbright | but it doesn't have to zero it |
| 18:17.44 | seanbright | yeah i dunno |
| 18:18.08 | *** join/#asterisk-dev pchero (~pchero@dhcp-077-249-058-090.chello.nl) |
| 18:24.24 | rmudgett | When growing the new memory area needs to be zeroed and realloc does not do that. |
| 18:24.53 | seanbright | why does it need to be zeroed? |
| 18:24.58 | seanbright | out of curiosity |
| 18:26.13 | seanbright | (... and yes, i know how malloc, calloc, and realloc work - how is that relevant?) |
| 18:27.01 | seanbright | also: check out the %zu format specifier |
| 18:27.13 | seanbright | it's for printing size_ts |
| 18:27.34 | rmudgett | Imagine a vector of pointers. You insert an element at an index that is beyond the current size. The elements between the previous end and the newly inserted element need to be NULL. |
| 18:29.49 | seanbright | ok, i didn't know inserting at an arbitrary point past the end of the vector was a thing |
| 18:30.15 | rmudgett | Formats does this |
| 18:31.17 | seanbright | ð |
| 19:30.39 | coreyfarrell | seanbright / kharwell: in AST_VECTOR_COMPACT() if the realloc fails wouldn't that leak the elements? for example if the vector has reference counted ao2 objects then we leak a reference to every object in the vector. |
| 19:31.08 | seanbright | sorry, i don't follow |
| 19:31.16 | seanbright | if realloc fails, nothing happens |
| 19:31.17 | kharwell | if it fails the old memory is kept |
| 19:31.55 | seanbright | we're assigning the result of the realloc to a temporary |
| 19:32.24 | seanbright | it would leak if we did: (vec)->elems = ast_realloc((vec)->elems, ...) |
| 19:32.31 | seanbright | but we aren't doing that |
| 19:32.32 | coreyfarrell | ah sorry nevermind |
| 19:41.13 | coreyfarrell | seanbright: I reread the man page and saw another issue |
| 19:41.26 | seanbright | fantastic news |
| 19:48.26 | kharwell | seanbright: regarding realloc and shrinking memory. I take your comment to mean that shrinking memory to realloc will never result in a new memory allocation? |
| 19:58.37 | seanbright | i am very confused right now |
| 19:59.16 | seanbright | kharwell: what is your concern? |
| 19:59.36 | seanbright | if realloc() succeeds, everything is taken care of |
| 19:59.45 | seanbright | if realloc() fails, nothing changes |
| 20:00.39 | seanbright | i supposed that realloc()ing to a smaller size could result in a brand new allocation, but i don't see why that matters |
| 20:01.33 | kharwell | if realloc succeeds it potentially allocates new memory. So you have three cases to check. If NULL, not null, and if not null and new mem was allocated. If new mem then realloc did the memcpy for you, but you still have to free the old memory |
| 20:02.09 | kharwell | so potential memory leak if realloc allocated new memory and the old mem is not free'd |
| 20:03.46 | seanbright | from https://pubs.opengroup.org/onlinepubs/9699919799/functions/realloc.html |
| 20:03.53 | seanbright | "The realloc() function shall deallocate the old object pointed to by ptr and return a pointer to a new object that has the size specified by size." |
| 20:05.04 | seanbright | i have an update to the review which i am about to post |
| 20:05.12 | kharwell | oh hrm I totally skipped that part in my brain when reading the man page. It's there to, "If the area pointed to was moved, a free(ptr) is done" |
| 20:05.31 | seanbright | i was about to passive aggressively abandon the review |
| 20:05.34 | seanbright | heh |
| 20:05.43 | seanbright | i still may |
| 20:05.46 | kharwell | kinda back to coreyfarrell's point then earlier. In this case what happens to the secondary memory allocated (or ref counts) if any? |
| 20:05.48 | seanbright | i don't really care that much |
| 20:06.04 | kharwell | ha I was wondering if that would happen |
| 20:06.26 | seanbright | "In this case what happens to the secondary memory allocated (or ref counts) if any?" |
| 20:06.29 | seanbright | huh? |
| 20:06.43 | coreyfarrell | kharwell: I was wrong about the refcount thing. |
| 20:07.23 | kharwell | oh ha yeah there is non as it was extra memory to begin with |
| 20:07.51 | kharwell | and the memory inside gets moved |
| 20:09.33 | kharwell | blames the Friday version of file |
| 20:09.40 | file | blame all you want |
| 20:09.47 | seanbright | ok, patch set 4 is up |
| 20:10.05 | seanbright | keep the -1s coming, i'm still in a good mood |
| 20:10.16 | kharwell | has rmudgett even looked a it yet? maybe we can get it up to 5 or 6 :-D |
| 20:10.27 | seanbright | i have no doubt |
| 20:13.31 | rmudgett | :D |
| 20:22.05 | seanbright | coreyfarrell: it's exactly what you suggested |
| 20:22.10 | seanbright | unless i misunderstood |
| 20:23.04 | coreyfarrell | seanbright: ugh for some reason I thought I suggested using AST_VECTOR_FREE... I'm tired :/ |
| 20:23.17 | seanbright | join the club |
| 20:23.32 | seanbright | how'd you quit smoking, btw? |
| 20:23.34 | kharwell | does this mean that ->elems could be = to NULL or undefined in the current = 0 case? |
| 20:23.37 | seanbright | cold turkey? patch? gum? |
| 20:23.51 | seanbright | ->elems will be NULL |
| 20:23.54 | file | shuts Gerrit down to force everyone to party instead |
| 20:24.17 | kharwell | I think AST_VECTOR_REMOVE will crash then if called after |
| 20:24.34 | kharwell | first line is: typeof((vec)->elems[0]) res; |
| 20:24.52 | seanbright | well then that will happen already if you do AST_VECTOR_INIT(meh, 0) |
| 20:25.12 | seanbright | maybe typeof doesn't actually dereference anything |
| 20:25.28 | coreyfarrell | seanbright: I tried everything, cold turkey is what worked for me. the patch gave me skin rashes every place I put one (on a 3 day delay so after I got the first rash I knew 2 more were coming). the gum made my stomach sick. |
| 20:25.48 | seanbright | coreyfarrell: how much were you smoking before you quit? |
| 20:26.13 | coreyfarrell | seanbright: 20-25/day |
| 20:26.27 | seanbright | yeah, that's where i'm at |
| 20:26.42 | kharwell | hopefully that's not packs |
| 20:26.53 | seanbright | i'm on year 23 though |
| 20:27.06 | coreyfarrell | kharwell: AST_VECTOR_REMOVE will always crash if idx > vec->max |
| 20:28.00 | seanbright | i guess i could add tests... but i really don't want to |
| 20:28.07 | coreyfarrell | seanbright: yeah was probably about 17 years for me. |
| 20:28.23 | seanbright | any cravings anymore? |
| 20:29.31 | coreyfarrell | no cravings. a fleeting thought every once in a while... but any thought is quickly followed by "eww, why?" then I forget. |
| 20:30.05 | kharwell | coreyfarrell: yeah wonder if an assert should have been put in. oh wellz |
| 20:30.34 | seanbright | if you're removing an element at a specific index, you should know the size of the thing beforehand i would think |
| 20:30.51 | coreyfarrell | seanbright: I can't remember the last time I even had a smoke in a dream (that did happen regularly for probably a year) |
| 20:31.26 | seanbright | coreyfarrell: i know that once i get to that point i will be glad to have quit |
| 20:31.36 | seanbright | it's the getting there part that i am not looking forward to |
| 20:31.44 | coreyfarrell | none of it was a big deal past the first few weeks |
| 20:31.56 | kharwell | seanbright: one last thing hopefully. Does this mean the return could be undefined? "If the size of the space requested is zero, the behavior shall be implementation-defined: either a null pointer is returned, or the behavior shall be as if the size were some non-zero value, except that the behavior is undefined if the returned pointer is used to access an object." |
| 20:32.51 | seanbright | kharwell: yes, you are correct |
| 20:32.58 | coreyfarrell | kharwell: in that case nothing should be trying to access any element if (vec)->max == 0. |
| 20:33.16 | seanbright | i will make it explicit |
| 20:33.32 | kharwell | I don't think I really saw anything except in the REMOVE code. Could be one other place |
| 20:33.43 | seanbright | kharwell: i would like to point out - had i just used ast_calloc() as in the first patch, everything would be fine |
| 20:33.53 | seanbright | so this is on you |
| 20:33.57 | kharwell | I wasn't going to mention that |
| 20:34.22 | coreyfarrell | I think the AST_VECTOR_REMOVE thing is a total separate issue / was an issue before seanbright's patch. |
| 20:34.29 | kharwell | yeah |
| 20:35.05 | kharwell | looks like AST_VECTOR_CALLBACK does it too |
| 20:35.27 | seanbright | ok, so what am i doing? |
| 20:35.37 | coreyfarrell | kharwell: no AST_VECTOR_CALLBACK is fine |
| 20:35.38 | kharwell | not sure how typeof handles that case. guess undefined, so who knows |
| 20:35.40 | seanbright | besides wanting to punch myself in the face? |
| 20:36.14 | kharwell | coreyfarrell: typeof((vec)->elems[0]) <-- won't that cause a problem if elems is NULL or undefined? |
| 20:36.27 | coreyfarrell | seanbright: IMO your patch is fine as is. AST_VECTOR_REMOVE is unrelated to your patch |
| 20:36.30 | seanbright | i don't think it derefences anything |
| 20:36.52 | coreyfarrell | kharwell: no, typeof() is a compile time directive. |
| 20:37.28 | seanbright | ok, so to kharwell's last point, let's pretend this happens: |
| 20:37.41 | seanbright | AST_VECTOR_INIT(&foo, 1); |
| 20:37.47 | seanbright | AST_VECTOR_COMPACT(&foo); |
| 20:37.54 | seanbright | AST_VECTOR_APPEND(&foo, "sean"); |
| 20:38.21 | kharwell | that should alloc new memory and reset the pointer |
| 20:38.26 | seanbright | so after _COMPACT, ->elems is either NULL or 'undetermined' |
| 20:38.54 | seanbright | ahh, and that will do an ast_calloc |
| 20:38.54 | kharwell | in __make_room |
| 20:38.54 | seanbright | ok |
| 20:38.58 | seanbright | i'm happy |
| 20:39.18 | kharwell | I think coreyfarrell is correct. I forgot typeof is compile time, so stuff should be fine from what I can tell |
| 20:39.58 | coreyfarrell | is `memcpy(new_elems, vec->elems, 0)` safe if vec->elems is one of those 'undefined' realloc pointers? |
| 20:40.22 | coreyfarrell | from __make_room. rmudgett do you know? |
| 20:40.24 | seanbright | i would assume if it's 0 it's a no-op |
| 20:40.32 | file | ditto |
| 20:41.13 | coreyfarrell | that's what I'm thinking (assuming) it shouldn't try to access the source for a 0 byte copy. |
| 20:41.24 | seanbright | posix is silent on it |
| 20:42.37 | seanbright | no one is going to use this new #define, so all of this is moot |
| 20:43.14 | seanbright | i also feel like the first commit of chan_pjsip had fewer review comments... |
| 20:43.14 | coreyfarrell | I thought you had plans? |
| 20:43.23 | seanbright | not anymore. this process has ruined me. |
| 20:43.44 | seanbright | yes, i have plans for it |
| 20:44.03 | seanbright | i want to see it littering all of the backtraces in jira for the next few releases |
| 20:49.37 | kharwell | seanbright: you should be a call to it right at the end of __make_room so we never have too much memory allocated |
| 20:49.50 | seanbright | now... in how many places do we rely on realloc() returning NULL if n is 0? |
| 20:50.03 | seanbright | kharwell: heh |
| 20:50.16 | seanbright | (i hope he's joking) |
| 20:50.33 | *** join/#asterisk-dev FreshneverFrozen (~FreshNeve@67.184.4.14) |
| 20:50.33 | kharwell | me too |
| 20:54.08 | FreshneverFrozen | Happy Friday everyone, I asked a question in the main #asterisk channel regarding how to troubleshoot an issue with app_mixmon that I believe will lead me to filing a bug, but I'm not sure what the next steps are if I'm actually chasing a bug or a misconfiguration or perhaps even a non-supported configuration. TLDR: Having issues with sending to multiple destinations with app_voicemail not built on a system - VM storage is realtime and works |
| 20:54.47 | FreshneverFrozen | %s/sending to multiple destinations/sending to multiple destinations with app_mixmon via AMI |
| 20:59.58 | seanbright | what does MixMonitor have to do with Voicemail exactly? |
| 21:00.54 | seanbright | also: are you using Asterisk 13.x, 16.x, or FreePBX? |
| 21:02.03 | seanbright | FreshneverFrozen: ^^^^ |
| 21:04.30 | FreshneverFrozen | 13.4 |
| 21:04.40 | FreshneverFrozen | and mixmon can store things into a voicemail box with option m |
| 21:04.50 | seanbright | ahh |
| 21:04.54 | FreshneverFrozen | or when told to via AMI |
| 21:04.55 | seanbright | let me take a gander |
| 21:05.10 | seanbright | that's a weird feature |
| 21:05.30 | FreshneverFrozen | having not done much work in the asterisk code base - trying to read all the preprocessors / defines is hard |
| 21:05.44 | FreshneverFrozen | then add in what's going on and its a challenge for me |
| 21:07.09 | seanbright | can you show an example of how you're calling the manager action? |
| 21:07.15 | seanbright | like, an actually failing example? |
| 21:07.27 | FreshneverFrozen | sure... give me a few to pull it out of the app that calls it. |
| 21:07.38 | seanbright | according to app_mixmonitor.c: /* recipients are in a single string with a format format resembling "mailbox@context/INBOX,mailbox2@context2,mailbox3@context3/Work" */ |
| 21:09.50 | FreshneverFrozen | action: 'MixMonitor' |
| 21:09.50 | FreshneverFrozen | Channel: decryptedChannel |
| 21:09.50 | FreshneverFrozen | File: fileName |
| 21:09.50 | FreshneverFrozen | options: m(4998@AMPDK,4999@AMPDK) |
| 21:10.04 | FreshneverFrozen | meant to paste that into a PB, sorry for the spam - but yeah that matches my syntax |
| 21:10.35 | FreshneverFrozen | hadn't considered it, but do I need quotes? |
| 21:11.02 | seanbright | no |
| 21:11.15 | seanbright | turn on debugging and see if there is anything interesting there |
| 21:11.17 | seanbright | core set debug 10 |
| 21:11.21 | seanbright | err |
| 21:11.31 | seanbright | core set debug 10 app_mixmonitor.c (i think...) |
| 21:11.48 | seanbright | core set debug 10 app_mixmonitor.so |
| 21:12.08 | FreshneverFrozen | k setting up a test with that |
| 21:12.13 | seanbright | and that assumes that you have debug logging going somewhere, so check /etc/asterisk/logger.conf |
| 21:13.12 | coreyfarrell | 13.4.0 is over 3 years old. |
| 21:13.24 | seanbright | one thing at a time |
| 21:13.43 | FreshneverFrozen | yeah... lots of DB changes went in right after 13.4.0 for realtime and we never got around to getting past that... |
| 21:14.28 | seanbright | there are no bugs, just undocumented features |
| 21:14.35 | seanbright | speaking of which, have you heard about @ variables? |
| 21:14.43 | seanbright | kids |
| 21:17.33 | FreshneverFrozen | haha |
| 21:17.59 | seanbright | i mean... you should already be seeing some verbose output |
| 21:18.08 | FreshneverFrozen | yeah i did |
| 21:18.09 | seanbright | "MixMonitor attempting to send voicemail copy to... |
| 21:18.10 | FreshneverFrozen | saw it attempting |
| 21:18.15 | FreshneverFrozen | yep and it tries for both |
| 21:18.22 | seanbright | ok, pastebin something so i can look at it |
| 21:18.37 | FreshneverFrozen | so it natively doesn't support it... apparently we wrote a script that calls it after the fact in a hangup handler... |
| 21:18.39 | FreshneverFrozen | embarassing... |
| 21:19.01 | FreshneverFrozen | and that script seems to not be handling the syntax of the comma delimited mailboxes |
| 21:19.15 | FreshneverFrozen | so sorry i've wasted your time and all involved |
| 21:19.26 | FreshneverFrozen | and yes - i still need to get to current ast 13 |
| 21:19.28 | FreshneverFrozen | :-/ |
| 21:19.38 | seanbright | you son of a bitch |
| 21:19.45 | seanbright | no problem |
| 21:19.48 | seanbright | glad you got it figured out |
| 21:20.07 | FreshneverFrozen | i didn't know you could turn on debugging per module... saves me so much disk space |
| 21:20.13 | FreshneverFrozen | and time |
| 21:20.33 | seanbright | yup, it's pretty cool |
| 21:21.24 | seanbright | i'm out - enjoy your weekends |
| 21:21.31 | FreshneverFrozen | you too thanks again! |
| 23:10.41 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-ucydgdtzhudqugjf) |