| 06:18.32 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:18.32 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:33.42 | *** join/#asterisk-dev Aur313 (~aurele@84.239.69.5) |
| 07:40.31 | Aur313 | hello, I am tracking a bug, I may have a fix, where should I post anything? |
| 07:58.09 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.126) |
| 11:17.46 | file | Aur313: everything goes through JIRA and for inclusion, Gerrit |
| 11:46.35 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 11:46.35 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 12:27.20 | gtjoseph | @seanbright: i'm around NOW. :) |
| 12:28.43 | seanbright | gtjoseph: hiii |
| 12:29.00 | gtjoseph | issues with the voicemail thing? |
| 12:29.10 | seanbright | many comments added |
| 12:29.56 | gtjoseph | i saw. so that code was all existing and i didn't want to mess with it too much. |
| 12:30.02 | seanbright | k |
| 12:30.14 | file | it is radioactive |
| 12:30.21 | seanbright | it's a string append |
| 12:30.29 | seanbright | can we stop pretending that is difficult or scary? |
| 12:30.33 | seanbright | i will push a new revision |
| 12:31.06 | gtjoseph | you don't have to. i can fix it. |
| 12:31.23 | seanbright | it's awful code |
| 12:31.26 | seanbright | i realize you didn't write it |
| 12:31.35 | gtjoseph | awful is an understatement. |
| 12:31.41 | seanbright | but there is an opportunity to make it less awful, why wouldn't we take it? |
| 12:32.03 | seanbright | the chances of us fucking it up more are zero |
| 12:32.06 | gtjoseph | it's like chan_sip. there's always a fear of breaking something else and going down a rabbit hole. |
| 12:32.18 | seanbright | it's a leaf function |
| 12:32.31 | seanbright | that turns x and y into x, x@y, or y |
| 12:33.57 | seanbright | actually, that's not even true |
| 12:34.03 | seanbright | that turns x and y into x, x@y, or @y |
| 12:34.29 | seanbright | and in reality, we always pass a non-empty mailbox and context |
| 12:34.49 | seanbright | more effort has been spent discussing it than is required to make it less sucky |
| 12:34.51 | gtjoseph | FLW |
| 12:35.24 | seanbright | i don't know what that means, but i agree wholeheartedly |
| 12:35.32 | gtjoseph | Famous Last Words |
| 12:35.34 | gtjoseph | :) |
| 12:35.36 | seanbright | ahh |
| 12:35.54 | gtjoseph | gimme 5 minutes and i'll paste a proposed solution. |
| 12:43.11 | seanbright | gtjoseph: line 13228, poll_state->mailbox can not be empty |
| 12:43.17 | seanbright | i will add comment on review if you like |
| 12:43.24 | gtjoseph | no that's fine |
| 12:45.28 | file | Taco Tuesday. |
| 13:01.28 | gtjoseph | seanbright: how about this... https://pastebin.com/fcwgGVdC |
| 13:04.39 | seanbright | that's good-ish |
| 13:04.43 | seanbright | the last argument to snprintf is wrong |
| 13:04.55 | seanbright | and i would 'len = snprintf(mailbox, len, ...)' |
| 13:04.57 | gtjoseph | yeha fixed |
| 13:05.34 | gtjoseph | yep on thhat as well. |
| 13:05.47 | seanbright | and then remember that len is chars, so you need to add 1 for the \0 |
| 13:05.54 | seanbright | and then i will stop bitching |
| 13:05.54 | seanbright | heh |
| 13:07.19 | seanbright | just out of curiosity - why alloca() and not just 'char mailbox[sizeof(...)]'? |
| 13:09.34 | gtjoseph | because I can never anticipate out what richard will complain about and I know alloca is "richard safe" |
| 13:10.33 | gtjoseph | that and i don't remember if ast_alloca passes through the malloc_debug code but i know that the array definition does not. |
| 13:19.07 | seanbright | so the behavior is now different |
| 13:19.16 | seanbright | previously it checked that 'mailbox' was not empty |
| 13:19.23 | seanbright | now it checks that 'vmu->mailbox' is not empty |
| 13:19.33 | seanbright | mind if i take a crack at it? |
| 13:20.26 | gtjoseph | right. only mailbox is required. if vmu->mailbox is not empty then mailbox can't be empty either. |
| 13:22.04 | seanbright | ahh |
| 13:22.08 | gtjoseph | so should i not bother cherry-picking? :) |
| 13:23.21 | seanbright | i don't follow |
| 13:23.49 | seanbright | what exactly is valid? |
| 13:23.57 | seanbright | 1234, 1234@default, @default |
| 13:24.00 | seanbright | all 3 of those? |
| 13:24.05 | seanbright | only the first 2? |
| 13:24.23 | gtjoseph | no @context isn't valid |
| 13:24.29 | gtjoseph | the minimum is mailbox |
| 13:24.41 | seanbright | got it |
| 13:25.29 | gtjoseph | so OK? cherry-picks aren't clean so i have to do them manually. |
| 13:25.56 | seanbright | well, it's not my opinion that matters |
| 13:26.00 | seanbright | but it looks better to me |
| 13:26.15 | gtjoseph | if you're going to -1 it then it does matter. :) |
| 13:26.32 | seanbright | ok, then hold on |
| 13:28.45 | seanbright | http://paste.ubuntu.com/p/YHzDJHZXxt/ |
| 13:28.51 | seanbright | that is my opinion - take it or leave it |
| 13:28.55 | seanbright | i won't -1 either way |
| 13:29.12 | seanbright | err |
| 13:29.30 | seanbright | i really should compile test |
| 13:30.31 | seanbright | this one: http://paste.ubuntu.com/p/2GpJWpRHc8/ |
| 13:31.24 | gtjoseph | i'm going to leave the alloca but i'll do the rest |
| 13:31.28 | seanbright | heh |
| 13:31.29 | seanbright | k |
| 13:32.17 | seanbright | is there a technical reason that he doesn't allow you to use array notation? |
| 13:33.14 | gtjoseph | no clue |
| 13:34.24 | seanbright | k |
| 13:41.17 | *** join/#asterisk-dev CELYA_ (~Thunderbi@92.184.96.249) |
| 13:47.25 | *** join/#asterisk-dev AsteriskRoss (259d3426@gateway/web/freenode/ip.37.157.52.38) |
| 13:53.05 | seanbright | what's the over-under on getting a +1? |
| 13:54.14 | gtjoseph | i choose not to play |
| 13:55.24 | seanbright | heh |
| 14:09.22 | *** join/#asterisk-dev libardi (~libardi@177.194.124.58) |
| 14:11.14 | seanbright | https://pasteboard.co/HEsYKEn.png |
| 14:11.30 | seanbright | that SRTP encrypted payload certainly LOOKS wrong |
| 14:11.34 | seanbright | UUUUUUUUUUUUUUUUUUUUU |
| 14:12.04 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-hqoiegvkvspuobbw) |
| 14:12.04 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:12.27 | file | seanbright: oh that's cute |
| 14:16.28 | seanbright | and 0x55... is 0101010101, etc |
| 14:23.46 | gtjoseph | isn't that what malloc_debug writes to freed storage? |
| 14:26.08 | seanbright | 0xdeaddead |
| 14:26.38 | gtjoseph | someone writes the UUUUU/0x55 but i can't remember now |
| 14:27.55 | seanbright | main/alaw.c uses it as a mask |
| 14:28.18 | seanbright | and coincidentally OP is using alaw... but that is probably irrelevant |
| 14:29.44 | gtjoseph | yeah i saw that unless the packet isn't really encrypted. |
| 14:31.05 | file | ponders |
| 14:32.00 | file | seanbright: is that from us or to us? |
| 14:32.18 | seanbright | from us |
| 14:32.39 | seanbright | well, let me confirm |
| 14:33.21 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:33.21 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:33.50 | seanbright | yes, from us |
| 14:34.06 | cresl1n | Ugh... https://gerrit.asterisk.org/#/c/asterisk/+/10048/ |
| 14:34.19 | cresl1n | I feel like I'm walking into a trap every time there's an app_queue patch |
| 14:34.33 | seanbright | i like how he +1'd his own review |
| 14:34.34 | gtjoseph | you are :) |
| 14:34.36 | file | you are, but that's life |
| 14:34.39 | seanbright | or her |
| 14:38.01 | seanbright | file: oddly, in that pcap, we send RTP before DTLS even starts |
| 14:38.12 | file | yeah, the code isn't currently that smrt |
| 14:40.32 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-txlomyemwhreialn) |
| 14:40.32 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:47.13 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-tddvraqmcgtwknxf) |
| 14:47.13 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:01.14 | seanbright | i have the same problem |
| 15:01.23 | seanbright | i'm hoping things change in the future |
| 15:04.22 | seanbright | rmudgett: gtjoseph and i were discussing earlier - for allocating arrays on the stack, when is ast_alloca(x) vs. foo[x] preferable? |
| 15:04.36 | seanbright | other than when x is unknown at compile time |
| 15:06.18 | gtjoseph | we're in standup right now |
| 15:06.34 | seanbright | better than a holdup |
| 15:06.46 | file | fixed a problem by unplugging and plugging it back in |
| 15:06.50 | gtjoseph | not always :) |
| 15:19.26 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-eyszyzwuxhvurdxa) |
| 15:52.07 | rmudgett | seanbright: I don't think there really is a guideline on which to use. You could write the code either way because arrays can be dynamically sized when you enter the block. |
| 15:53.16 | rmudgett | Though you probably don't want to have a dynamically sized array within a loop just like you don't want to us alloca() within a loop. |
| 15:57.45 | seanbright | got it. thanks. |
| 16:19.49 | kharwell | actually I think it is safe to use a variable length array in a loop whereas you would not want to use alloca |
| 16:21.10 | seanbright | "For such an object that does have a variable length array type, its lifetime extends from the declaration of the object until execution of the program leaves the scope of the declaration.27) If the scope is entered recursively, a new instance of the object is created each time. The initial value of the object is indeterminate." |
| 16:22.49 | kharwell | right so I think that means it resets every loop, where alloca remains in scope until the end of the function. |
| 16:23.03 | kharwell | you can alloca something in a loop and use it afterwards, but not a variable length array |
| 16:25.31 | seanbright | right |
| 16:25.32 | seanbright | nifty |
| 16:29.12 | kharwell | interestingly it appears variable length arrays are optional in c11, so some compilers could not have them or drop support |
| 16:42.11 | coreyfarrell | our README says we require 'gcc language extensions' so I think we're fine to use optional language features as long as they're implemented in gcc. |
| 16:45.01 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.171) |
| 16:57.29 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 17:03.49 | pc-m | Hello everyone, I'm trying to submit a patch on Gerrit and I think I might have 2 accounts with the same username for Gerrit. When submitting I get an error saying that my email is not registered and shows me an old email from a previous job which was probably using the username pcadotte which is also my current username. Is there anyone I could get in touch with to get that sorted out? |
| 17:06.09 | file | um |
| 17:06.31 | file | what's the precise message you get, and what's the username? |
| 17:08.15 | pc-m | Here's the error https://pastebin.com/zGjjfaqq |
| 17:08.23 | pc-m | my openid username is pc-m |
| 17:08.31 | pc-m | my gerrit username is pcadotte |
| 17:08.56 | file | HRM |
| 17:09.53 | file | did you register the email address as mentioned in the error? |
| 17:10.16 | coreyfarrell | I thought gerrit and openid usernames were supposed to be the same thing |
| 17:10.22 | file | coreyfarrell: I wish. |
| 17:10.41 | pc-m | I tried to use the same but I think pc-m was invalid for gerrit |
| 17:11.13 | file | I just added that email to your account |
| 17:11.14 | file | try now |
| 17:11.39 | pc-m | same error |
| 17:12.23 | file | how about now... |
| 17:12.51 | pc-m | I'm not 100% sure I signed the license agreement with my @wazo.io email address. Could that be the problem? I had the impression that I would not be able to log in Gerrit if it was not signed. |
| 17:13.09 | pc-m | still no luck |
| 17:13.18 | file | no, not exactly |
| 17:13.51 | file | hrm |
| 17:14.07 | file | and it's still stating that only the proformatique email address is registered? |
| 17:14.16 | pc-m | yes |
| 17:14.17 | file | oh |
| 17:14.22 | file | you are using username pcm |
| 17:14.44 | file | not pcadotte |
| 17:14.44 | pc-m | no, I'm using pcadotte in my .ssh/config |
| 17:15.12 | file | um, what if you update your git remote to be the correct username there? what happens? |
| 17:16.30 | file | because you are connecting as "pcm" |
| 17:16.41 | file | [2018-09-18 12:15:50,592 -0500] 8228feb1 pcm a/1000163 git-receive-pack./asterisk.git 3ms 2412ms 0 git/2.17.1 |
| 17:17.58 | pc-m | you're right I must have left that from previous test. My patch is now submitted. Thanks |
| 17:19.21 | off-nominal | doesn't see it |
| 17:20.29 | off-nominal | oh, nevermind. i see it. |
| 17:31.22 | file | off-nominal: can you become so off-nominal that you become nominal? |
| 17:32.53 | off-nominal | file: reply hazy, try again. |
| 17:33.35 | file | off-nominal: noted |
| 17:33.53 | off-nominal | i had to look up magic 8 ball responses because i couldn't remember them |
| 17:33.57 | off-nominal | i hope you appreciate the effort |
| 17:34.02 | file | very much so |
| 18:12.34 | coreyfarrell | rmudgett: about the stasis_message change I wasn't suggesting that you allow tag == NULL in 15+. I think in that case suppressing the REF_DEBUG message is still a bug, just not a crash bug. |
| 18:14.13 | coreyfarrell | calls to ao2_ref involving the type object do not use tag == NULL so we'd end up not logging the allocation but then we'd log all the ref/unref actions. |
| 18:17.00 | rmudgett | Doh. Right. Though in this case we eventually abort creating the stasis type object. So we won't log the allocation but would log the destruction. |
| 18:19.23 | rmudgett | reverted back to original patch |
| 18:21.44 | coreyfarrell | the commit message in 15+ is inaccurate because no risk of crash but I'm over it :) |
| 18:24.17 | gtjoseph | rmudgett: your patch doesn't address the cache's bump of type when it creates a new cache entry. should it? |
| 18:24.37 | rmudgett | gtjoseph: That's the next patch to go up |
| 18:24.54 | gtjoseph | oh, this is one of "those" patch series isn't it? |
| 18:24.57 | gtjoseph | :) |
| 18:25.50 | rmudgett | Not a series as they are totally independent and could be merged in either order |
| 18:55.27 | *** join/#asterisk-dev drc (~quassel@unaffiliated/drc) |
| 19:47.39 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d001907ecfb943e4f19.ipv6.abo.wanadoo.fr) |
| 23:25.08 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-hqoiegvkvspuobbw) |
