| 00:00.42 | gtjoseph | file: i changed the shutdown order to be exactly like it was originally and re-posted for 13. hopefully that works. |
| 00:01.22 | gtjoseph | zuul gave it a +1. when do the gates run? |
| 00:01.35 | file | when it gets a +2 |
| 00:01.55 | gtjoseph | any way to trigger it manually? |
| 00:02.00 | file | no |
| 00:02.09 | file | ponders |
| 00:02.16 | file | actually give me a sec |
| 00:02.47 | file | SO |
| 00:02.49 | file | theoretically |
| 00:02.54 | file | comment regate |
| 00:03.35 | file | ah, it may not work due to the approval requirement |
| 00:03.35 | file | hum |
| 00:04.26 | file | aha |
| 00:05.58 | file | interesting |
| 00:07.08 | file | I'm a bit confused |
| 00:07.45 | file | I did a +2 |
| 00:08.54 | file | I'm a bit confused why the comment didn't work though |
| 00:11.04 | file | Item 151 on today's glitch list. |
| 00:11.16 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-gsoqameswftitiiy) |
| 00:11.31 | file | my Jurassic Park reference drove kharwell away |
| 00:11.47 | gtjoseph | :) |
| 00:15.34 | gtjoseph | well, this is going to take a while. :) |
| 00:17.21 | file | yup |
| 00:17.33 | gtjoseph | lazy hamsters. |
| 00:18.17 | gtjoseph | the only other thing might be that I destroy the endpoint now and that wasn't done before. |
| 00:18.34 | file | that's probablyyyyyyyy it |
| 00:19.12 | gtjoseph | it must be a timing thing then since I just ran the testsuite again and 215 tests passed with no failures |
| 00:19.31 | gtjoseph | this is before the change i just made. |
| 00:21.57 | file | https://www.youtube.com/watch?v=vtkGtXtDlQA |
| 00:22.23 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 00:23.22 | gtjoseph | Ha! |
| 00:36.16 | gtjoseph | damn |
| 00:41.08 | gtjoseph | file: looks like it's still failing. Should I just remove the call to pjsip_endpt_destroy? |
| 00:41.27 | file | probably |
| 00:43.30 | gtjoseph | done if you wan to +2 it again. |
| 00:44.12 | file | I can once it verifies |
| 00:44.14 | gtjoseph | one of these days i'll spin up a vm with only 4g of memory and 1 cpu |
| 00:44.45 | file | the CentOS nodes are... not THAT bad |
| 00:44.50 | file | the Ubuntu nodes are fast |
| 00:46.45 | gtjoseph | did you abort that job? |
| 00:46.55 | file | nope? |
| 00:47.20 | gtjoseph | 2016-02-11 17:44:40 Build was aborted |
| 00:47.20 | gtjoseph | 2016-02-11 17:44:40 Aborted by anonymous |
| 00:47.39 | file | Zuul cancelled it automatically |
| 00:47.55 | gtjoseph | because of the re-post? |
| 00:47.58 | file | yes |
| 00:48.00 | gtjoseph | ah |
| 00:48.14 | file | it has a constant event stream so it knows |
| 00:48.33 | gtjoseph | as does the Shadow. |
| 00:50.27 | file | next on my Jenkins agenda is wiki documentation update jobs |
| 00:52.29 | file | that's a weekend thing, though |
| 00:52.58 | gtjoseph | weekend / weekday, what's the difference? |
| 00:53.27 | file | if I break the world on the weekend I don't have to rush to put the pieces back together |
| 00:53.42 | gtjoseph | ah, true. |
| 01:02.57 | gtjoseph | file: zuul approved |
| 01:03.03 | file | yup yup |
| 01:03.09 | file | +2 given |
| 01:03.45 | file | oh |
| 01:03.51 | file | is working on documentation |
| 01:33.54 | file | well, certainly close |
| 01:34.25 | gtjoseph | yeah, haven't seen any core dumps yet |
| 01:34.57 | file | the documentation too |
| 01:35.13 | file | I don't have the user/pass for the wikibot account, but it seems to do all the right stuff |
| 01:35.14 | gtjoseph | :) |
| 01:37.35 | file | tries the 13 one |
| 01:41.55 | file | 13 seems to work too |
| 01:42.43 | file | that's cool |
| 01:42.59 | file | I can get the deets tomorrow and, well, run them and see how much of a mess it makes on the wiki |
| 01:56.47 | file | gtjoseph, yup! better |
| 01:57.21 | gtjoseph | still unstable |
| 01:57.41 | gtjoseph | looking for the casue |
| 01:57.41 | file | yeah, but those are sporadic test failures we're fixing |
| 01:57.47 | gtjoseph | ah, cool. |
| 01:57.59 | file | Mark has a fix up for one of 'em |
| 01:58.14 | file | https://gerrit.asterisk.org/#/c/2241/ |
| 01:58.21 | gtjoseph | cool. ok, i need to cherry-pick to master now. |
| 02:03.31 | file | I'll sort it out tomorrow |
| 02:20.47 | *** join/#asterisk-dev drmessano (sid104353@pdpc/supporter/active/drmessano) |
| 05:14.21 | *** join/#asterisk-dev Synthase_ (uid63346@gateway/web/irccloud.com/x-hnetlnefjqzhidmn) |
| 05:55.28 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 06:31.20 | *** join/#asterisk-dev doome_ (~doome@94-21-194-175.pool.digikabel.hu) |
| 06:41.15 | *** join/#asterisk-dev goddva (~goddva@77.40.154.242) |
| 07:01.39 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 07:04.36 | *** join/#asterisk-dev Jacke (jacke@valhalla.bofh.org) |
| 07:10.21 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 07:10.55 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 07:11.13 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 08:04.28 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 08:26.28 | *** join/#asterisk-dev oej (~oej@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 08:26.28 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:33.48 | *** join/#asterisk-dev oej (~oej@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 08:33.48 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:36.06 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:29.03 | *** join/#asterisk-dev oej (~oej@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 09:29.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:30.13 | *** join/#asterisk-dev stefan27 (~stefan27@212.247.4.149) |
| 09:31.53 | stefan27 | can opus still not be included in asterisk 13 - see http://lists.digium.com/pipermail/asterisk-dev/2013-May/060356.html It seems Lorenzo Miniero wrote an opus patch 3 years ago but it never made it to trunk due to legal issues? |
| 09:39.02 | *** join/#asterisk-dev oej (~oej@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 09:39.02 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:43.00 | *** join/#asterisk-dev oej (~oej@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 09:43.00 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:59.56 | *** join/#asterisk-dev oej (~oej@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 09:59.56 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 11:43.26 | file | stefan27, there have been no changes to the situation |
| 12:07.47 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 12:07.47 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:52.32 | stefan27 | thanks |
| 13:24.17 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:51.32 | *** join/#asterisk-dev acidfoo_ (~acidfoo@69-165-149-25.dsl.teksavvy.com) |
| 13:56.41 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:56.41 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:00.39 | file | nods to cresl1n |
| 14:23.49 | file | coreyfarrell, moo |
| 14:24.08 | coreyfarrell | file: woof |
| 14:24.27 | file | coreyfarrell, Badalian is filing issues... a lot of them |
| 14:25.27 | file | coreyfarrell, is that something you'd be interested in looking at since it's the sort of nitty gritty stuff you like? (I have a feeling some of it while true is not really stuff that would impact us, and it's all theoretical from code analysis) |
| 14:28.18 | coreyfarrell | I'm creating a filter in JIRA for Badalian's tickets now.. |
| 14:28.47 | file | I'm not sure really what he's doing, it seems as though he took stuff from his main TSAN issue and created individual issues |
| 14:31.47 | coreyfarrell | well I did ask him to test PJSIP separate from the rest.. maybe that's prompted the individual tickets |
| 15:00.47 | file | coreyfarrell, thanks for taking a look! |
| 15:05.56 | coreyfarrell | anyone who works with or knows anything about res_stun_monitor want to take a look at ASTERISK-25781? it looks like that one is complaining about different threads reading and writing bitfields. |
| 15:09.21 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-rqxgkqirhnemslvd) |
| 15:11.07 | cresl1n | jcolp!!!!! |
| 15:13.43 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-cxirygytjgwfvhch) |
| 15:47.15 | file | achoo. |
| 15:50.58 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-kpgtyyruhvqdnhld) |
| 16:28.01 | cresl1n | awho? |
| 16:29.28 | file | wiki documentation from the source is now updating nightly once again |
| 16:45.27 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 16:45.27 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:40.08 | coreyfarrell | rmudgett: I was just taking another look at ASTERISK-25761. is it possible that '#define SOME_FLAG (1 << 31)' should be '#define SOME_FLAG (1U << 31U)'? or 1UL << 31UL in the case of 64bit fields.. |
| 17:44.42 | rmudgett | coreyfarrell: I think that warning is because of the default type of 1 being an int. So in (1 << 31) It would be too far for an int. Should change to (1U << 31) . The 31 shift value does not need a type since that is how far to shift and is well within an int. |
| 17:45.17 | rmudgett | For 64 bit flags it should be (1ULL << 31) |
| 17:46.09 | coreyfarrell | oh right I forgot that typeof(1U) == typeof(1UL). |
| 17:46.52 | rmudgett | At least on most modern platforms. Asterisk wont work on platforms where an int is 16 bits :) |
| 17:47.14 | rmudgett | Too much code assuming an int is 32 bits. |
| 17:48.18 | coreyfarrell | in my own code I always use uint32_t if I need that specific number of bits |
| 18:06.35 | *** join/#asterisk-dev doome_ (~doome@94-21-194-175.pool.digikabel.hu) |
| 18:22.59 | *** join/#asterisk-dev acidfoo_ (~acidfoo@208.114.164.24) |
| 18:49.08 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 18:49.08 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:04.11 | gtjoseph | wishes ./configure automatically regenerated itself if it was older than configure.ac |
| 19:27.09 | *** join/#asterisk-dev goddva (~goddva@2a02:fe0:c510:e300:ae9e:17ff:fe91:a8c9) |
| 20:09.27 | coreyfarrell | rmudgett: do you have an opinion on ASTERISK-25783? tl;dr: ast_shutting_down does not protect the read of shutdown_pending from other threads writing. writes to shutdown_pending are done under mutex. |
| 20:12.03 | coreyfarrell | well that one I could probably just use a lock in ast_shutting_down. ASTERISK-25782 has a similar issue with global_logmask where locking would probably be too expensive. |
| 20:20.05 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 20:20.05 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:23.06 | rmudgett | Locking may shut up that sanitizer, but it won't change anything. That variable is used as a boolean. |
| 20:23.17 | rmudgett | I think that it is a red herring |
| 20:23.36 | rmudgett | not something that is a real problem |
| 20:25.28 | rmudgett | It would be best to tell the sanitizer to ignore that finding. |
| 20:26.39 | coreyfarrell | agreed on shutdown_pending.. what about global_logmask? that's more of a bitmask. |
| 20:30.04 | coreyfarrell | actually the global_logmask might be a real issue. during reload we set it to 0 then add values back in. so during logger reload messages would be lost. |
| 20:35.51 | rmudgett | global_logmask is protected by logchannels RW lock when changing it. |
| 20:36.21 | rmudgett | Again it is just the read that is triggering the sanitizer. |
| 20:36.57 | coreyfarrell | I know that.. my point is that ast_log_full can reach that check while global_logmask == 0 (during reload). |
| 20:39.07 | coreyfarrell | during reload there is a period of time that log messages are silently dropped. or am I missing something which prevents that? |
| 20:40.16 | rmudgett | Looks like they could be dropped. I'm not sure that it would be advisable to lock it to test though. Could be way too expensive CPU wise. |
| 20:41.55 | coreyfarrell | maybe reload could use a local variable to build the mask, then assign the final value at the end. that wouldn't get rid of the sanitizer message but would prevent loss of messages. |
| 20:44.53 | rmudgett | init_logger_chain() should create a new value to replace only at the end. |
| 20:47.53 | rmudgett | update_logchannels() would also need to build a local mask before replacing. |
| 20:48.18 | rmudgett | For v13 you'd need to backport a change you made on master about the logchannel's lock |
| 20:48.29 | coreyfarrell | yeah I'll do a full audit of global_logmask and make sure it's done right. |
| 20:53.09 | coreyfarrell | hmm so you're making me think that ASTERISK-25773 isn't really a bug either. as long as multiple threads don't try to use ast_set_flag(&ast_options, value) from multiple threads then it's ok? |
| 21:12.47 | rmudgett | coreyfarrell: Yes that should be correct. I did some quick looks and it seems only the AST_OPT_FLAG_DEBUG_MODULE flag is changed by the CLI for "core set debug on module" |
| 21:13.51 | rmudgett | for the ast_options flags |
| 21:16.56 | rmudgett | consolethread is only written the one time. |
| 21:39.26 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.dynamic.se.alltele.net) |
| 21:39.26 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 22:09.33 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 22:09.33 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 22:42.25 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 23:47.52 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-cxirygytjgwfvhch) |