| 01:32.36 | *** join/#asterisk-dev infobot (ibot@208.53.50.136) |
| 01:32.36 | *** 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 |
| 04:40.19 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.34) |
| 07:07.57 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:07.57 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:13.30 | *** join/#asterisk-dev pchero_work (~pchero@87.213.240.121) |
| 07:19.27 | *** join/#asterisk-dev gtjoseph (~gtjoseph@unaffiliated/gtj) |
| 07:19.27 | *** mode/#asterisk-dev [+o gtjoseph] by ChanServ |
| 08:02.32 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 09:52.17 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 11:08.09 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.126) |
| 11:13.04 | *** join/#asterisk-dev snuff-work (~snuff-wor@202-161-112-134.tpgi.com.au) |
| 11:13.04 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 12:18.44 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-fbnwrczelwkvjwij) |
| 12:18.44 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 13:00.21 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 13:00.29 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 13:23.01 | file | boom |
| 13:30.42 | cresl1n | clap |
| 13:33.54 | *** join/#asterisk-dev dandann00dle (~dandann00@2601:840:8401:d7ee:cd87:f9f3:b237:db82) |
| 14:05.35 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-rorxboaksjoiwlbf) |
| 14:05.35 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:13.21 | gtjoseph | Fedora 29 is out. The release notes are pretty sparse but glibc was updated to 2.28 |
| 14:15.05 | gtjoseph | On another note... the AstriCon talk videos are starting to make their way to YouTube... https://www.youtube.com/channel/UCMqHgUzCq7NdDl5MtxjZCyg |
| 14:18.51 | cresl1n | Anybody gonna hate me if I +2 the chan_sip deprecation review? |
| 14:19.02 | gtjoseph | not me :) |
| 14:22.13 | file | you do you |
| 14:36.28 | gtjoseph | tsearle: shall I abandon the packetization reviews for you? |
| 14:36.53 | tsearle | well I don't think it should be abandoned from what I gather |
| 14:37.02 | tsearle | just reduced in scope to be just the native bridge |
| 14:37.13 | gtjoseph | ah, wasn't sure |
| 14:37.31 | gtjoseph | no problem |
| 14:37.53 | tsearle | happy haloween btw! |
| 14:38.00 | gtjoseph | Thanks! |
| 14:38.18 | gtjoseph | And to you |
| 14:38.25 | tsearle | and more importantly, since this is a good catholic country, that means tomorrow is a day off! :D |
| 14:38.33 | gtjoseph | Ha! |
| 14:38.43 | tsearle | All Saints Day! |
| 14:38.44 | gtjoseph | <PROTECTED> |
| 14:39.58 | tsearle | now I got a question ref the "offical" testsuite, what changes exactly happen when you build asterisk with testsuite enabled? |
| 14:40.49 | tsearle | the reason I ask is we run testsuite with debs that we build with intention to install in prod |
| 14:40.56 | gtjoseph | --enable-dev-mode, DONT_OPTIMIZE BETTER_BACKTRACES MALLOC_DEBUG DO_CRASH TEST_FRAMEWORK |
| 14:41.21 | tsearle | yeah it's TEST_FRAMEWORK I'm wondering about |
| 14:41.33 | file | it enables the ability to select unit tests, and also enables extra events for tests |
| 14:41.34 | tsearle | does that fundamentally change code, or just add an extra module? |
| 14:41.45 | gtjoseph | TEST_FRAMEWORK is needed to turn on test events |
| 14:42.10 | tsearle | ok, so it can't be just easily shoved in an add-on deb package |
| 14:42.23 | file | no |
| 14:43.00 | gtjoseph | no. although the testsuite doesn't run any of the unit tests, that flag allows the use of the test events which many oif the testsuite tests depend on |
| 14:43.24 | tsearle | yeah that's where I got in trouble |
| 14:43.37 | tsearle | tried running some of the failed tests and they got skipped because of that |
| 14:44.49 | gtjoseph | yep. you CAN turn off all the tests under make cmenuselect |
| 14:45.07 | gtjoseph | oops... "Test Modules" |
| 14:45.46 | tsearle | are they modules? |
| 14:46.12 | tsearle | because my question was more the other way around, can I build for prouction with the flag TEST_FRAMEWORK |
| 14:46.15 | gtjoseph | yeah, they are the unit tests |
| 14:46.26 | gtjoseph | you can but it's not advisable |
| 14:46.29 | tsearle | then shift the extra .so files into a asterisk-testframework .deb |
| 14:46.53 | tsearle | or does it fundamentally modify the core in a way that can't be ripped out post-build |
| 14:47.34 | gtjoseph | hmmm. you could but TEST_FRAMEWORK does incur overhead in core and there are test events in the rtp stack. |
| 14:47.47 | gtjoseph | that would get issued |
| 14:47.58 | tsearle | ok |
| 14:48.02 | gtjoseph | with that flag set. |
| 14:48.11 | tsearle | so I'll just live w/o TEST_FRAMEWORK then |
| 14:48.51 | tsearle | don't have the resources to make 2 separate debian packages & build pipelines, heh |
| 14:49.11 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-guoqrkfezeegcmkq) |
| 14:49.11 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:56.15 | gtjoseph | tsearle: does the testsuite typo fix review need to go into 16 and master? |
| 14:56.36 | tsearle | yes, I'll cherrypick |
| 14:56.51 | gtjoseph | i can do it and +2 them at the same time |
| 14:57.00 | tsearle | ok then :-) |
| 14:57.14 | tsearle | and sorry for the typo in the first place, heh |
| 14:58.40 | gtjoseph | no worries. i'm the king of typos. |
| 15:00.03 | file | typoes! |
| 15:14.07 | tsearle | waves at vicp |
| 15:18.41 | vicp | in Asterisk 13.20.0.....any reason for the cleanup duplication of session->media both on session_end and session_destructor ? (/res_pjsip_session.c) |
| 15:19.20 | file | In case session_end isn't called in an off nominal probably |
| 15:21.10 | file | Otherwise dunno |
| 15:22.12 | vicp | but why not just leaving it for session_destructor? ....session_end sets session->media to NULL ...causing race conditions inside thread running bridge_channel_ind_thread |
| 15:23.44 | file | Probably to release resources as quickly as possible |
| 15:26.40 | vicp | I am bumping session->media inside t38_framehook_read to avoid the race ...but I wonder if there must be a better place to ref count it to the thread running bridge_channel_ind_thread |
| 15:27.09 | vicp | and same for pbx_thread |
| 15:27.57 | file | They have no concept of such things |
| 15:28.06 | file | It's an implementation detail of PJSIP |
| 15:29.47 | vicp | well session->media is a container / ao2 object ...so I assume it should be bumped when passing to another thread... |
| 15:30.51 | file | That depends upon the locking in place and contract. The channel should be locked during that time to protect it if I recall. |
| 15:31.51 | vicp | the channel is unlocked inside framehook_read though ... |
| 15:32.17 | file | Right, so that entire relationship and what is expected has to be determined |
| 15:37.12 | tsearle | I assume special case relationships like frame_hook_read should document who is responsible for what with inline code comments, right? |
| 15:38.11 | file | Ideally |
| 15:41.44 | vicp | the "simply" solution would be just to increase / decrease the reference count in the critical section (inside t38_framehook_read) ...but probably a more correct approach would be to do that before (at the point the new thread is created)....anyhow ...memory ownership should be defined ... |
| 15:51.25 | vicp | anyway..I will send a patch ...and we can discuss further then...thanks |
| 17:12.27 | tsearle | I'm a bit confused, why is this gerrit needed? https://gerrit.asterisk.org/#/c/asterisk/+/10568/ I thought I already addressed the alembic issue in this gerrit https://gerrit.asterisk.org/#/c/asterisk/+/10357/ |
| 17:14.15 | tsearle | ha never mind |
| 17:14.59 | tsearle | didn't look at the diff close enough, thought it was changing from yes/no to bool, but it's just tweaking the bool implementation |
| 17:46.04 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00e41ec93a59e04618.ipv6.abo.wanadoo.fr) |
| 19:23.33 | kharwell | are DEBUG_THREADS enabled on jenkins? |
| 19:24.22 | gtjoseph | nope |
| 19:26.29 | kharwell | darn didn't think so, but was hoping |
| 19:27.00 | kharwell | prob a big pain to enable that too right? |
| 19:27.15 | kharwell | might cause problems with some tests I suppose too |
| 19:27.30 | gtjoseph | not a pain to enable but it does have overhead. what do you need it for? |
| 19:28.03 | gtjoseph | it might introduce timing changes we weren't expecting but we should fix those anyway. |
| 19:28.38 | kharwell | not 100%, but the ast_restart test might be due to a deadlock. I can't duplicate it locally (not yet at least) and was thinking of enabling the "locks" testcondition on the test and then seeing what it turned up when it failed on jenkins again |
| 19:28.59 | kharwell | but that test condition needs DEBUG_THREADS enabled |
| 19:29.37 | gtjoseph | you can always run it in a docker container locally |
| 19:29.43 | kharwell | I guess another alternative would be to somehow get a backtrace on test failure, before asterisk is shutdown |
| 19:29.45 | gtjoseph | that would get you close to the jenkins environment |
| 19:30.00 | kharwell | yeah true I have not tried that yet. I'll do that first and see what it turns up |
| 19:30.29 | gtjoseph | you could actually log into one of the docker slaves and run the container there. |
| 19:32.00 | kharwell | would I need to first exclude it somehow from regular selection? |
| 19:32.20 | gtjoseph | just build it manually |
| 19:32.34 | gtjoseph | and select DEBUG_THREADS in cmenuselect |
| 19:32.36 | kharwell | I haven't ssh'd onto one of these systems yet |
| 19:32.58 | kharwell | I mean wouldn't jenkins attempt to possibly use that slave while I'm logged into it? |
| 19:33.09 | kharwell | (I'm still in a bamboo mindset) |
| 19:33.21 | gtjoseph | use swdev-docker0. it's only the regtistry repository |
| 19:33.43 | gtjoseph | even if you did use one of the busy slaves, jenkins has its own workspace |
| 19:33.53 | kharwell | oh I see now yeah okay I can log onto the machine and use a separate container |
| 19:34.18 | kharwell | or as you say it'd be a different workspace |
| 19:34.26 | coreyfarrell | I had considered making the testsuite use SIGABRT on asterisk when shutdown timed out but that would likely still cause a lot of additional failures. |
| 19:42.19 | kharwell | hrm that makes me wonder. This test does not timeout. Asterisk shutdowns properly it. The testsuite triggers the shutdown on failure so maybe it's not hung. Although I suppose it will shutdown with open dialogs? |
| 19:43.09 | coreyfarrell | not sure what you mean by dialogs.. it won't shutdown with open channels. |
| 19:43.47 | coreyfarrell | an MWI dialog won't prevent shutdown for example. |
| 19:44.40 | kharwell | it's trying to do a sip unsubscribe |
| 19:47.04 | coreyfarrell | active subscriptions don't prevent 'core stop gracefully'. |
| 19:48.30 | kharwell | okay good to know, so what I am looking at might could still fall into the deadlock realm |
| 19:54.23 | coreyfarrell | kharwell: you could change https://github.com/asterisk/testsuite/blob/master/lib/python/asterisk/asterisk.py#L636 from __actual_stop to __send_kill and change the self.process.signalProcess in __send_kill to send signal 6. this would force all instances of asterisk to core dump instead of shutting down at the end of the test. |
| 19:54.54 | coreyfarrell | obviously for testing only as that will cause every test to fail :) |
| 20:17.47 | kharwell | that sounds like the nuclear option, but I'll keep in mind thanks! |
| 20:50.29 | *** join/#asterisk-dev pchero_work (~pchero@dhcp-077-249-058-090.chello.nl) |
| 20:52.06 | *** join/#asterisk-dev dakudos (~dakudos@c-73-243-106-97.hsd1.co.comcast.net) |
| 22:01.26 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-rorxboaksjoiwlbf) |
| 22:32.20 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lfbn-1-5361-63.w90-105.abo.wanadoo.fr) |