| 00:05.55 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 02:45.59 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 05:26.19 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 06:07.59 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 06:19.05 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 06:19.31 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 06:28.23 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 06:41.42 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 06:45.33 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 07:15.00 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 07:15.00 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 07:50.24 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 07:58.35 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.121) |
| 08:02.19 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.121) |
| 08:41.14 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 08:45.00 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:54.00 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 09:14.38 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 10:55.54 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-wgcuwthehksawaae) |
| 10:55.54 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 11:48.57 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 11:58.39 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 13:24.55 | seanbright | cresl1n: i did compile test them, of course. |
| 13:25.16 | seanbright | csavinovich: will take a look |
| 13:29.12 | seanbright | csavinovich: that error doesn't make sense to me |
| 13:29.52 | seanbright | red_cp is one of the while loop conditions |
| 13:30.46 | seanbright | pchero_work: question - in chan_sip.c on line 11640 |
| 13:30.56 | seanbright | change 'char *rest;' to 'char *rest = NULL;' |
| 13:31.00 | seanbright | and see if you still get the compile error |
| 13:35.02 | seanbright | actually, according to the docs, that shouldn't change anything: 'The application need not initialize the pointer pointed to by state to any particular value' |
| 13:46.42 | pchero_work | seanbright: Sure, I'll test it after work. :) |
| 13:47.58 | pchero_work | I'm just doubting, if it's gcc's bug, then should it be changed it? |
| 13:48.40 | seanbright | gcc bug or not, if you could compile before the change to strtok_r(), it's a problem for us |
| 13:48.50 | bford | seanbright: if it's any help, i get warnings when compiling, but actual errors when compiling in dev-mode that result in a failure to compile |
| 13:48.50 | bford | gcc --version |
| 13:48.50 | bford | gcc (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609 |
| 13:48.52 | seanbright | i'm fine rolling it back |
| 13:49.04 | seanbright | yes, you are both using ancient versions of gcc |
| 13:49.05 | seanbright | heh |
| 13:49.08 | bford | :P |
| 13:49.17 | seanbright | what is that? trusty or xenial? |
| 13:49.28 | bford | xenial iirc |
| 13:49.32 | seanbright | lsb_release -a |
| 13:50.16 | pchero_work | Hm. my one was debian-9.8, which is newest. |
| 13:50.18 | bford | well, elementary distribution, based on ubuntu, so the info it spat out wasn't all that helpful ha |
| 13:50.25 | seanbright | gotcha |
| 13:50.50 | seanbright | ok, well, i don't have anything but bionic readily accessible to me |
| 13:51.14 | seanbright | here is my proposal |
| 13:51.26 | seanbright | 1) we roll back the strtok -> strtok_r patch |
| 13:51.42 | seanbright | ... (which i think is wrong, but that is immaterial) |
| 13:51.54 | seanbright | 2) someone else beat on it and figure out how to fix it |
| 13:52.05 | seanbright | i lean towards #2 |
| 13:52.12 | seanbright | also: https://issues.asterisk.org/jira/browse/ASTERISK-28161 |
| 13:52.39 | seanbright | what are our thoughts on that? |
| 13:54.29 | pchero_work | I would take 2. We can get around this. It doesn't affect to real processing. If we can get around the warning, then it would be good enough. |
| 13:56.02 | file | seanbright: the patch likely came from gtjoseph, he may have better memory on it |
| 13:56.05 | file | does not recall it |
| 13:56.15 | gtjoseph | eh what? |
| 13:56.18 | bford | holy moly, the number of comments. will take a look at it |
| 13:56.18 | bford | and we definitely need to eliminate gcc complaining about it because it does fail in dev-mode, which is needed for test framework |
| 13:56.48 | bford | "it" not referring to Ross Beer's thing |
| 13:56.51 | file | gtjoseph: Ross had a patch he said we gave him to change the typedef for a pj_timer_t |
| 13:57.11 | gtjoseph | yes |
| 13:57.26 | gtjoseph | it was a test patch to see if the timer was rolling over |
| 13:57.37 | gtjoseph | it wasn't |
| 13:58.05 | seanbright | so he should roll out that patch? |
| 13:58.46 | gtjoseph | well. if the timer is still showing negative numbers then that confirms that it's not a roll over issue |
| 13:59.14 | seanbright | but aren't the timer ids negative when they are "checked out?" |
| 13:59.26 | seanbright | like... intentionally |
| 13:59.39 | seanbright | we should have used sofiasip |
| 13:59.41 | seanbright | /s |
| 14:00.06 | gtjoseph | yeah what i was testing was if a rollover was causing negative numbers that weren't pointing to a real slot. |
| 14:00.30 | seanbright | i don't think that 140068368185622 could reasonably point to a real slot |
| 14:00.37 | seanbright | but this goes back to your memory trampling theory |
| 14:01.22 | gtjoseph | exactly. with a long, there's virtually no possiblity of a rollover so it's not that that's causing the negative numbers |
| 14:01.54 | gtjoseph | it has to be either something trampling on the memory or something getting freed while there's still a timer on the heap. |
| 14:08.26 | csavinovich | https://www.irccloud.com/pastebin/jptvZsma/ |
| 14:09.16 | csavinovich | @seanbright: I will like to try @pchero's suggestion for |
| 14:09.16 | csavinovich | in chan_sip.c on line 11640 change 'char *rest;' to 'char *rest = NULL;' |
| 14:09.16 | csavinovich | only thing is I will have to create me an Ubuntu env, I hope somebody has Ubuntu gcc-6.3... I'll ask the reporter |
| 14:10.34 | seanbright | csavinovich: pchero_work is the reporter |
| 14:10.51 | csavinovich | ah |
| 14:10.56 | seanbright | pchero_work == sungtae kim |
| 14:11.24 | gtjoseph | what environment do you need? |
| 14:11.54 | seanbright | the pastebin you linked is "deleted" |
| 14:11.55 | csavinovich | interesting.... well @pchero_work, would you please try it and let us know? |
| 14:12.34 | csavinovich | @gtjoseph it would be Ubuntu- GCC 6.3 |
| 14:12.44 | gtjoseph | yeah which Ubuntu version |
| 14:13.06 | seanbright | pchero_work is running debian 9.8, not ubuntu |
| 14:13.08 | seanbright | if that matters |
| 14:14.02 | gtjoseph | i don't have an easy setup for debian yet so something that matches gcc and is ubuntu, centos or fedora would be better |
| 14:14.14 | gtjoseph | as long as it reproduces the issue |
| 14:14.18 | gtjoseph | of course |
| 14:14.46 | seanbright | bford said it happened on elementary but he can't tell me the version |
| 14:14.55 | gtjoseph | does a gcc 4.8 cause the issue? |
| 14:15.15 | gtjoseph | if so, we've got plenty of centos environments |
| 14:15.16 | csavinovich | @gtjoseph |
| 14:15.16 | csavinovich | $ uname -a |
| 14:15.16 | csavinovich | Linux debian 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux |
| 14:15.33 | bford | gcc --version |
| 14:15.33 | bford | gcc (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609 |
| 14:15.41 | bford | lsb_release -a |
| 14:15.42 | bford | No LSB modules are available. |
| 14:15.42 | bford | Distributor ID:elementary |
| 14:15.42 | bford | Description:elementary OS 0.4.1 Loki |
| 14:15.42 | bford | Release:0.4.1 |
| 14:15.42 | bford | Codename:loki |
| 14:16.03 | csavinovich | @gtjoseph, it is actually Debian |
| 14:16.05 | gtjoseph | well i can spin up a ubuntu 16 in a few seconds |
| 14:16.09 | gtjoseph | i know |
| 14:16.19 | gtjoseph | but we don't have a debian ready-made environment yet |
| 14:16.30 | file | loki is 16.04 |
| 14:19.03 | csavinovich | @seanbright disregard the pastebin :) |
| 14:20.22 | seanbright | done |
| 14:21.23 | seanbright | according to the GCC issue and the mailing list thread, initializing the 3rd argument to strtok_r should be enough |
| 14:21.41 | seanbright | char *rest = NULL; |
| 14:23.24 | csavinovich | if (pchero_work==sungtae_kim) { |
| 14:23.24 | csavinovich | <PROTECTED> |
| 14:23.24 | csavinovich | } |
| 14:23.24 | csavinovich | else { |
| 14:23.24 | csavinovich | <PROTECTED> |
| 14:23.25 | csavinovich | } |
| 14:24.21 | seanbright | to give credit where it is due - it was actually my suggestion |
| 14:24.28 | seanbright | pats himself on the back |
| 14:24.47 | seanbright | of course i am the one who broke it in the first place |
| 14:25.25 | seanbright | gtjoseph: audiofilter is such voodoo |
| 14:25.48 | gtjoseph | that you do so well! |
| 14:26.08 | csavinovich | I will have to apply a switch statement now! |
| 14:26.08 | csavinovich | switch{ |
| 14:26.08 | csavinovich | case pchero_work: |
| 14:26.08 | csavinovich | case seanbright: |
| 14:26.08 | csavinovich | } |
| 14:29.33 | seanbright | csavinovich: nice work |
| 14:29.49 | seanbright | audiofilter -n 0.86916 -1.73829 0.86916 -d 1.00000 -1.74152 0.77536 |
| 14:29.54 | seanbright | ahhh... yes... right... mhmmm |
| 14:30.00 | seanbright | i know some of these words |
| 14:44.09 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.121) |
| 14:50.05 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-uuldgqoafnpubvld) |
| 14:50.05 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:52.51 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 14:54.36 | *** join/#asterisk-dev stevedav_ (~stevedavi@197.155.252.3) |
| 15:05.27 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 15:21.25 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 15:25.00 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 15:28.39 | bford | seanbright: pchero_work: there were a couple different cases where that warning during compiling popped up. initializing them to NULL as per your suggesting sean resolves the problem |
| 15:28.54 | bford | suggestion* |
| 15:34.35 | seanbright | good deal |
| 15:34.39 | seanbright | ship it |
| 15:34.45 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 15:36.08 | seanbright | bford: throw a ASTERISK-28362 in your commit message |
| 15:36.23 | bford | seanbright: will do |
| 15:51.47 | csavinovich | @seanbright and all: warning gone too in my environment. I am closing ASTERISK-28362 |
| 15:51.59 | file | don't close it |
| 15:52.05 | file | when it's merged it will autoclose |
| 15:52.12 | csavinovich | @file: okay |
| 15:52.26 | seanbright | well, sorry for fucking it up to begin with |
| 15:52.32 | seanbright | but it's GCC's fault, not mine |
| 15:52.37 | csavinovich | bford: I take you are the one committing the change to line 11640 in chan_sip.c? |
| 15:52.53 | seanbright | csavinovich: https://gerrit.asterisk.org/c/asterisk/+/11219 |
| 15:52.53 | file | seanbright: you don't make a cake without breaking some eggs, except if it's eggless I guess |
| 15:53.38 | csavinovich | you guys are fast |
| 15:53.41 | bford | csavinovich: yep it's up on gerrit |
| 15:53.59 | seanbright | res_fax doesn't bitch? |
| 15:54.20 | seanbright | that was changed in the original patch |
| 15:55.23 | file | seemingly not? |
| 15:55.27 | seanbright | hmm |
| 15:56.24 | bford | didn't on mine, let me take another look |
| 15:56.36 | seanbright | res_fax.c:812 |
| 15:56.49 | seanbright | *rest is declared but not initialized |
| 15:57.14 | file | probably wise to do it also |
| 15:57.46 | bford | was just checking to see if i had fax left out in my build or not, but it's in there. weird that it doesn't complain |
| 15:57.48 | bford | i can add it |
| 15:58.20 | seanbright | well |
| 15:58.32 | seanbright | there are a lot of other places we use strtok_r and don't init that arg |
| 15:58.36 | seanbright | and they don't complain |
| 15:58.48 | seanbright | (there's another place in pbx_dundi.c, in fact) |
| 15:58.55 | seanbright | it's rabbit hole |
| 15:59.03 | bford | the never-ending issue |
| 15:59.04 | seanbright | i wouldn't bother changing places that don't generate errors |
| 15:59.10 | seanbright | personally |
| 15:59.21 | seanbright | we know that it is safe to not init it |
| 15:59.21 | file | ok! :D |
| 15:59.32 | seanbright | it's A rabbit hole, rather |
| 15:59.35 | seanbright | a bike shed |
| 15:59.42 | seanbright | a wheat thresher |
| 15:59.45 | seanbright | i made that last one up |
| 15:59.46 | bford | if someone reports an issue against it or if we run into it again, it's easy enough to eliminate the warning anyways |
| 16:00.01 | kharwell | OR explicitly initialize all variables everywhere. you know for future proofing and all that |
| 16:00.10 | seanbright | patches welcome |
| 16:02.07 | seanbright | you'd think gcc would have some kind of flag to auto init all stack local variables |
| 16:02.14 | seanbright | not that we really want to do that |
| 16:03.14 | file | I'd also like to propose a change to ignore all segfault signals |
| 16:04.32 | seanbright | makes sense to me |
| 16:04.41 | seanbright | that would reduce the issue tracker traffic |
| 16:05.32 | file | oh, and changing all headers in the source code to have seanbright's email address |
| 16:05.40 | seanbright | fine with me |
| 16:05.53 | seanbright | sean.bright+forward-to-file@gmail.com |
| 16:06.25 | file | bonus points for forwarding to my sangoma address that I keep meaning to switch to, but can't bring myself to deal with updating everything |
| 16:06.47 | file | is lazy |
| 16:07.11 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 16:16.55 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 17:37.54 | *** join/#asterisk-dev pchero (~pchero@dhcp-077-249-058-090.chello.nl) |
| 17:45.03 | seanbright | so if you dial a PJSIP channel, is there a way to get a header off of the remote side's 200 OK response? |
| 17:46.39 | file | no |
| 18:17.21 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 18:21.05 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00f4d7ddd1bc0987bc.ipv6.abo.wanadoo.fr) |
| 18:52.04 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 18:58.05 | seanbright | file: thanks |
| 19:02.51 | *** join/#asterisk-dev CELYA_ (~Thunderbi@lfbn-1-5196-243.w90-105.abo.wanadoo.fr) |
| 19:06.04 | pchero | Wow... |
| 19:06.25 | pchero | Sorry to couldn't answer it for a while. I was busy to washing the dishes. -_-; |
| 19:07.10 | pchero | csavinovich: seanbright: I've tested it just now. Yes it looks fine for me as well. :) |
| 19:07.28 | pchero | https://gerrit.asterisk.org/c/asterisk/+/11219 :) |
| 19:12.29 | pchero | btw, what about other strtok_r()? |
| 19:14.08 | *** join/#asterisk-dev dadrc (~quassel@unaffiliated/drc) |
| 19:14.53 | seanbright | we didn't change the ones that don't emit the warning/error. |
| 19:20.03 | pchero | ah?? |
| 19:20.54 | seanbright | are you seeing this error other than the two places fixed in the review? |
| 19:23.27 | pchero | Checking now. :) |
| 19:27.34 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 19:33.31 | pchero | Ah, sorry, I can't see it. :) |
| 21:58.03 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 22:37.28 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 23:11.16 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-uuldgqoafnpubvld) |