| 00:07.14 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 00:23.57 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-nqryisnjmzhyaweo) |
| 06:03.13 | *** join/#asterisk-dev oej (~oej@h87-96-134-129.cust.se.alltele.net) |
| 06:03.13 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:11.51 | *** join/#asterisk-dev bof22 (~Thunderbi@185.13.183.107) |
| 06:14.36 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 06:48.03 | *** join/#asterisk-dev Demon_VoIP (~demon@109.60.135.186) |
| 06:49.10 | *** join/#asterisk-dev jkroon (~jkroon@dustpuppy.is.co.za) |
| 07:15.11 | *** join/#asterisk-dev oej (~oej@213-155-152-114.customer.teliacarrier.com) |
| 07:15.11 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:00.10 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 08:04.29 | *** join/#asterisk-dev pchero_work (~pchero@2a00:c80:1072::152e) |
| 08:09.51 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 08:19.06 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:19.06 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:22.08 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 08:23.27 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 09:07.43 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.55.94) |
| 09:42.25 | *** join/#asterisk-dev oej (~oej@213-155-152-114.customer.teliacarrier.com) |
| 09:42.25 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:07.06 | *** join/#asterisk-dev oej (~oej@213-155-152-114.customer.teliacarrier.com) |
| 10:07.06 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 10:52.57 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.55.4) |
| 12:03.51 | *** join/#asterisk-dev oej (~oej@213-155-152-114.customer.teliacarrier.com) |
| 12:03.51 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:05.49 | *** join/#asterisk-dev oej (~oej@213-155-152-114.customer.teliacarrier.com) |
| 12:05.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:13.38 | file | seanbright: so it was sqlite? |
| 12:16.02 | *** join/#asterisk-dev oej (~oej@213-155-152-114.customer.teliacarrier.com) |
| 12:16.02 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:19.39 | seanbright | file: no |
| 12:19.42 | seanbright | it's app_queue |
| 12:19.51 | file | yay |
| 12:19.54 | seanbright | yeah |
| 12:20.40 | seanbright | and i guess app_queue is usable, but anyone using realtime members must be working around the problem somehow |
| 12:21.07 | seanbright | basically the "interface" property from realtime is never looked at |
| 12:21.19 | seanbright | and i think if that is empty it falls back to "membername" |
| 12:21.26 | seanbright | so that must be how people are working around it... maybe |
| 12:22.28 | file | dunno |
| 12:30.10 | file | ah Amazon, affordable one day shipping |
| 12:31.17 | wdoekes | in 13+ or below? in 11 I use interface with a Local channel (and set state_interface to the SIP/device), but with this patch https://reviewboard.asterisk.org/r/2996/diff/#index_header |
| 12:39.32 | *** join/#asterisk-dev oej (~oej@213-155-152-114.customer.teliacarrier.com) |
| 12:39.32 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:42.29 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.55.156) |
| 12:46.38 | *** join/#asterisk-dev stefan27 (~stefan27@static-212-247-4-149.cust.tele2.se) |
| 13:54.59 | tsearle | is there documentation on how asterisk pjsip handles call xfer? |
| 13:55.37 | tsearle | basically, before I was able to get the domain part of the refer target with SIPDOMAIN |
| 13:56.21 | tsearle | and had ANSWEREDTIME set every time control went back to the dialplan (so each leg duration was known) |
| 13:56.47 | tsearle | is there any way to get the domain of the refer-to target (or better yet the full sip uri) from pjsip? |
| 13:57.25 | file | the header should be in SIPREFERTOHDR |
| 13:57.43 | tsearle | still called SIP even though it's PJSIP? |
| 13:57.46 | file | there's nothing that parses it out and sets domain only |
| 13:57.47 | file | yes |
| 13:57.55 | tsearle | and ref ANSWEREDTIME |
| 13:58.09 | tsearle | it's only set at the very end of the call (beign the sum of all the xfers) correct? |
| 13:58.40 | file | ANSWEREDTIME is set at the end of Dial() |
| 13:58.42 | tsearle | because before I had to get the answered time after each xfer and sum them up |
| 13:58.57 | tsearle | ok, so that should simplify things then |
| 14:12.34 | *** join/#asterisk-dev Demon_VoIP (~demon@109.60.135.186) |
| 14:16.14 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-mlkajkxvtyqorkez) |
| 14:16.14 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:09.35 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.63.62) |
| 15:16.55 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-dentktyhtsgloqfl) |
| 15:16.55 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:17.25 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 15:18.22 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:18.22 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:33.01 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-ywpysztnhrrihhmm) |
| 15:33.01 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 15:33.57 | *** join/#asterisk-dev tuxd00d (~tuxd00d@wsip-184-179-14-87.ph.ph.cox.net) |
| 15:47.29 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-qunrqlecynnlvxyw) |
| 15:47.29 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:48.24 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:48.24 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 16:11.21 | file | gtjoseph: I'm more inclined to make this libasteriskssl fix as minimally invasive as possible |
| 16:12.11 | gtjoseph | yeha agreed |
| 16:13.10 | file | and seanbright did fancy |
| 16:13.51 | seanbright | huzzah |
| 16:20.52 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.63.219) |
| 16:22.40 | file | seanbright: amusingly gtjoseph did that already - it was just in queue to get put up and such :D |
| 16:22.46 | seanbright | oops |
| 16:22.56 | seanbright | want me to abandon? |
| 16:23.03 | file | dunno! |
| 16:23.10 | seanbright | gtjoseph: want me to abandon? :-) |
| 16:23.17 | rmudgett | ask gtjoseph |
| 16:23.21 | gtjoseph | i'm looking |
| 16:23.25 | seanbright | roger |
| 16:23.34 | rmudgett | If you say his name enough he appears... |
| 16:24.01 | rmudgett | beetlejuice beetlejuice beetlejuice |
| 16:25.56 | gtjoseph | so do we all feel comfortable going to 2.6 right now? |
| 16:26.17 | gtjoseph | seanbright: only 1 thing missing from the patch which i'll comment on |
| 16:26.26 | file | yes |
| 16:26.58 | gtjoseph | rmudgett: ? |
| 16:28.04 | rmudgett | It depends on how stable we consider 2.6 is. |
| 16:28.44 | file | if we put it in now we're a good time away from a release, it'll get used more |
| 16:28.54 | file | (through testsuite tests running on everything and gates) |
| 16:28.55 | gtjoseph | i went through the changelogs and didn't see anything that might affect us negatively |
| 16:29.11 | gtjoseph | and of course, ran the testsuite a whole bunch of times |
| 16:29.20 | rmudgett | 2.5 -> 2.5.5 they reworked DNS with resulting crashes |
| 16:29.33 | gtjoseph | yes they did |
| 16:30.11 | gtjoseph | but the only dns changes I saw were the ones we had in bundled |
| 16:30.29 | gtjoseph | if we're not ready, how do we know when we are? |
| 16:31.09 | gtjoseph | ^^ for the general audienbce |
| 16:31.21 | gtjoseph | s/audienbce/audience/ |
| 16:32.03 | seanbright | if the testsuite passes... |
| 16:32.45 | rmudgett | There is only one DNS SRV change in 2.6 that isn't in 2.5.5 and covered by our patches but will be soon. |
| 16:33.06 | gtjoseph | yeah , yours |
| 16:33.34 | gtjoseph | the problem with the testsuite passing is it tests functionality, not performance.stress |
| 16:34.07 | gtjoseph | hmmm. i know. |
| 16:34.50 | file | we don't have the capacity to test that at this time, and until we can put time into such an environment I'm iffy as to whether holding off is a good thing |
| 16:35.20 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 16:35.21 | gtjoseph | seanbright: would you be OK with abandoning your patches and letting us run our stress testing on 2.6 with the patches I already have? |
| 16:35.27 | seanbright | that's fine |
| 16:35.41 | gtjoseph | thanks. |
| 16:35.47 | gtjoseph | i'll get the perf started today. |
| 16:38.27 | seanbright | is the bundled pjproject supposed to rebuild everytime i do a 'make?' |
| 16:38.30 | seanbright | or is that a dev mode thing? |
| 16:40.04 | gtjoseph | it rebuilds if you touch menuselect |
| 16:40.08 | gtjoseph | are you? |
| 16:40.11 | seanbright | i am not |
| 16:40.25 | gtjoseph | it shouldn't rebuild just by repeating a make |
| 16:40.29 | seanbright | k |
| 16:40.39 | gtjoseph | latest GIT? |
| 16:40.42 | seanbright | yeah |
| 16:41.01 | gtjoseph | do a make distclean and see if that clears it up. |
| 16:41.09 | seanbright | i'm modifying a module, which i think causes menuselect-tree to be updated? |
| 16:41.13 | seanbright | i've tried that |
| 16:41.17 | gtjoseph | yes it does |
| 16:41.19 | seanbright | it's a minor annoyance |
| 16:42.44 | seanbright | ok... i need a sanity check when someone has 5 minutes |
| 16:44.03 | gtjoseph | on what subject? |
| 16:44.10 | seanbright | realtime |
| 16:44.17 | gtjoseph | go for it |
| 16:44.21 | seanbright | ok... |
| 16:44.27 | seanbright | 13 git |
| 16:44.36 | seanbright | crack open res/res_config_odbc.c |
| 16:44.43 | seanbright | go to line 412 |
| 16:45.16 | gtjoseph | the line with the 99999 in it ? :) |
| 16:45.18 | seanbright | yes |
| 16:45.21 | seanbright | so |
| 16:45.40 | seanbright | this is a multi query. and for each result we create a new ast_category with the empty string as its name |
| 16:45.59 | gtjoseph | yep |
| 16:46.04 | seanbright | and we append that to an ast_config |
| 16:46.09 | gtjoseph | yep |
| 16:46.22 | seanbright | ok, so when this function returns, we have a chain of categories with blank names |
| 16:46.27 | seanbright | that's all fine and good |
| 16:46.42 | seanbright | so now open pbx/pbx_realtime.c |
| 16:46.53 | file | nope nope nope |
| 16:46.54 | seanbright | and go to line 194 |
| 16:47.02 | seanbright | eh? |
| 16:47.09 | file | it hurts me, it hurts me |
| 16:47.24 | gtjoseph | i'm there even if file is hurting |
| 16:47.27 | seanbright | ok |
| 16:47.41 | seanbright | so there we are iterating the ast_categories from the returned ast_config |
| 16:47.51 | gtjoseph | yep |
| 16:47.59 | seanbright | based on what we saw in res_config_odbc, 'cat' will ALWAYS be the empty string |
| 16:48.14 | gtjoseph | yep |
| 16:48.20 | seanbright | so given that... the rest of the code in that loop will never work |
| 16:49.05 | seanbright | we need to be extracting 'exten' from the ast_category for each row |
| 16:49.16 | seanbright | and passing that to ast_extension_match/close/whatever |
| 16:49.38 | gtjoseph | well, what's the value of mode? |
| 16:49.48 | seanbright | i don't see how that is relevant |
| 16:50.05 | seanbright | well, let me rephrase to sound less douchey |
| 16:50.29 | seanbright | it doesn't matter what the value of mode is, because we are comparing 'cat' to 'exten' and they can never possibly match |
| 16:50.52 | seanbright | so in my datastore, i have an exten '_X.' |
| 16:50.59 | gtjoseph | where are we matching? |
| 16:51.06 | seanbright | match = ast_extension_close(cat, exten, 1); |
| 16:51.22 | gtjoseph | yes but do you know what that actually does? |
| 16:51.32 | seanbright | i don't follow |
| 16:51.48 | seanbright | it tries to match an extension "1234" to a dialplan pattern "_Whatever" |
| 16:52.09 | seanbright | let me ask this another way |
| 16:52.18 | seanbright | this: |
| 16:52.19 | seanbright | char *cat = ast_category_browse(cfg, NULL); |
| 16:52.28 | seanbright | and subsequently, this: cat = ast_category_browse(cfg, cat); |
| 16:52.35 | seanbright | the value of cat will always be "" |
| 16:52.39 | seanbright | can we agree on that? |
| 16:52.42 | gtjoseph | the reason i asked abou tmode is so we can follow down into those functions and see what they do with empty strings |
| 16:53.22 | seanbright | i can do that, but i think the fact that "cat" can never possibly be anything other than "" makes that deep dive immaterial |
| 16:53.34 | gtjoseph | true but it works |
| 16:53.41 | seanbright | it does? |
| 16:54.02 | gtjoseph | storing extensions in realtime?? of course it does. |
| 16:54.23 | seanbright | i will concede that storing extension '1234' in realtime may work (haven't tried it) |
| 16:54.29 | gtjoseph | or are you thinking is't speciofic to the odbc driver? |
| 16:54.59 | seanbright | but based on my reading of the code, putting '_X.' as the extension in the datastore as 'exten' will never work |
| 16:55.17 | seanbright | res_config_sqlite3 and res_config_odbc do the "" category thing |
| 16:55.26 | gtjoseph | empirical evidence? |
| 16:55.31 | gtjoseph | :) |
| 16:55.38 | seanbright | i've tested and it don't work? |
| 16:55.50 | seanbright | res_config_pgsql does the same thing |
| 16:56.05 | gtjoseph | oh you HAVE tested it? |
| 16:56.08 | seanbright | yes |
| 16:56.12 | gtjoseph | hmmm. |
| 16:56.39 | gtjoseph | so we really do need to dig deeper then |
| 16:57.16 | gtjoseph | you can't be the only person who has tried extensions in realtime via res_config_odbc so it's strange |
| 16:57.19 | seanbright | https://gist.githubusercontent.com/seanbright/80497a1322666a55b6240d07c949c2ff/raw/661abc453e681a1123796a6264ff396a8cbd9c35/gistfile1.txt |
| 16:57.57 | seanbright | with some added debugging thrown in |
| 16:58.13 | gtjoseph | yes i see that :) |
| 16:58.28 | seanbright | matching by value probably works |
| 16:58.30 | seanbright | let me test that |
| 16:58.57 | gtjoseph | dump out mode as well |
| 16:59.10 | seanbright | that is what MATCH is |
| 16:59.12 | seanbright | in the debug |
| 16:59.42 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@80.12.63.49) |
| 16:59.46 | seanbright | so in my db, if i create a row with 'exten' set to '1234' and then dial 1234, it works |
| 16:59.59 | seanbright | if i create a row with 'exten' set to '_X.' and then dial 1234, it does not |
| 17:00.01 | gtjoseph | no the mode parameter to realtime_switch_common |
| 17:00.16 | gtjoseph | hmmmmm. |
| 17:00.21 | seanbright | MATCH == MODE_MATCH |
| 17:00.46 | seanbright | i'm just looking for someone to tell me that the way we are iterating the categories is wrong |
| 17:00.56 | seanbright | well, we're iterating correctly |
| 17:01.00 | gtjoseph | ok i i must be blind: pbx_realtime.c:208 realtime_switch_common: MATCH 1234 |
| 17:01.01 | seanbright | but using the category name is wrong |
| 17:01.05 | seanbright | yes |
| 17:01.25 | gtjoseph | oh you mean the literal MATCH |
| 17:01.26 | seanbright | ast_debug(3, "MATCH %s %s\n", cat, exten); |
| 17:01.27 | gtjoseph | ha |
| 17:01.43 | seanbright | that is in the MODE_MATCH case |
| 17:01.59 | gtjoseph | AhHa |
| 17:02.33 | rmudgett | Are you trying to do extensions.conf in realtime? |
| 17:02.38 | seanbright | yes |
| 17:02.48 | seanbright | i mean, not for me |
| 17:02.51 | seanbright | to fix bugs |
| 17:02.52 | seanbright | but yes |
| 17:03.17 | rmudgett | That is plagued by deadlocks that are nearly impossible to eradicate because of how extens are stored in memory. |
| 17:03.18 | gtjoseph | i'm thinking we never supported wildacrds in realtime now |
| 17:03.25 | seanbright | dude |
| 17:03.29 | gtjoseph | i have to look on the wiki |
| 17:03.29 | seanbright | ok |
| 17:03.41 | seanbright | if that is the case... why is the code there? |
| 17:03.52 | seanbright | why are we querying for something starting with an underscore? |
| 17:03.58 | gtjoseph | yeah true |
| 17:04.07 | gtjoseph | but something just ticked my brain |
| 17:04.49 | seanbright | the same thing happens with queues in realtime while iterating queue members |
| 17:05.00 | seanbright | we use the category name as the "interface" |
| 17:05.13 | seanbright | and never actually look at the interface defined by the realtime data source |
| 17:05.19 | gtjoseph | yeah the wiki says no callerid matching but it should do pattern matching |
| 17:07.11 | gtjoseph | so let's go back to res_config_odbc... i'm not seeing anything obvious about an empty name that would cause the issue |
| 17:07.45 | gtjoseph | as long as it's properly parsing the columns into the ast_variable structure |
| 17:07.56 | seanbright | right, which we can assume it is |
| 17:08.47 | gtjoseph | so the rows with the _ ARE being returned correct? |
| 17:08.52 | seanbright | yes |
| 17:08.56 | seanbright | you can see it in my debug |
| 17:09.03 | gtjoseph | then we need to look at ast_extension_match |
| 17:09.10 | seanbright | heh |
| 17:09.14 | seanbright | ok |
| 17:09.27 | seanbright | i have a patch |
| 17:09.27 | seanbright | i'm testing it now |
| 17:09.29 | gtjoseph | to? |
| 17:10.16 | seanbright | https://gist.github.com/seanbright/4defb4f48c0c2a7c82fadbb7e13a4ee0 |
| 17:10.25 | seanbright | just to see what happens |
| 17:12.06 | seanbright | and it works |
| 17:12.55 | seanbright | i guess realtime multi is broken in a lot of places, and i just assumed that wasn't possible with the number of users |
| 17:13.05 | seanbright | maybe what this is telling us is that not many people use realtime |
| 17:13.22 | seanbright | and i should make a patch to remove it... |
| 17:13.24 | seanbright | kidding |
| 17:13.54 | file | which realtime? |
| 17:14.00 | file | pbx_realtime I doubt is used much |
| 17:14.00 | seanbright | all of them |
| 17:14.10 | seanbright | well, let me rephrase |
| 17:14.29 | seanbright | i have seen the problem in pbx_realtime and in app_queue |
| 17:14.36 | seanbright | i have no doubt that pjsip and friends are perfect |
| 17:14.41 | gtjoseph | yeah it's actually kinda bizarre |
| 17:14.58 | seanbright | i'm in the middle of another set of patches |
| 17:15.00 | file | off the beaten path |
| 17:15.06 | gtjoseph | pbx_realtime was assuming that the category name was going to be the extension. |
| 17:15.16 | seanbright | once those ar eup for review, i'll audit the realtime nonsense |
| 17:15.31 | gtjoseph | but there's no way the config drivers could know that |
| 17:16.07 | *** join/#asterisk-dev jkroon (~jkroon@154.73.32.14) |
| 17:16.30 | seanbright | and app_queue assumes it will be the interface name |
| 17:16.36 | seanbright | but it's the empty string there too |
| 17:16.42 | seanbright | anyway, i'll take care of it |
| 17:17.03 | seanbright | thanks for taking a gander gtjoseph |
| 17:17.05 | gtjoseph | cool. you've been a machine this week :) |
| 17:17.10 | gtjoseph | thanks! |
| 17:44.44 | seanbright | so i am currently duplicating a sql utlity function in each of the sql-based realtime backends |
| 17:44.57 | seanbright | i'm tempting to dedupe and put in main/config.c |
| 17:45.04 | seanbright | tempted* |
| 17:45.26 | seanbright | but realtime does not imply sql, so i'm torn |
| 17:58.12 | *** join/#asterisk-dev Demon_VoIP (~demon@109.60.222.253) |
| 18:04.33 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 18:04.48 | seanbright | nevermind. found an easier way. |
| 18:08.53 | *** join/#asterisk-dev leifmadsen_ (~leifmadse@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:08.53 | *** mode/#asterisk-dev [+o leifmadsen_] by ChanServ |
| 18:29.59 | *** join/#asterisk-dev tuxian (~tuxian@igilmour.plus.com) |
| 18:58.04 | *** join/#asterisk-dev CELYA_ (~Thunderbi@80.12.55.200) |
| 19:09.42 | putnopvut | I'm trying to work on an issue where a test is crashing. It's a Lua test. Right now, I can't run it because I don't have asttest installed. When I try to run make, I get: |
| 19:09.43 | putnopvut | src/lfs.c:57:17: fatal error: lua.h: No such file or directory |
| 19:09.44 | putnopvut | <PROTECTED> |
| 19:09.54 | putnopvut | I looked at asttest/Makefile, and it has the following line in it |
| 19:10.04 | putnopvut | CFLAGS:=-g -D_GNU_SOURCE -Wall `pkg-config --cflags lua5.1 2> /dev/null || pkg-config --cflags lua 2> /dev/null` -Iinclude |
| 19:10.13 | putnopvut | Notice the "-Iinclude" at the end |
| 19:10.33 | putnopvut | But when I run make, this is the gcc command that's run:gcc -O2 -Wall -fPIC -W -Waggregate-return -Wcast-align -Wmissing-prototypes -Wnested-externs -Wshadow -Wwrite-strings -pedantic `pkg-config --cflags lua5.1 2> /dev/null || pkg-config --cflags lua 2> /dev/null` -c -o src/lfs.o src/lfs.c |
| 19:10.33 | gtjoseph | do you have lua-devel installed? |
| 19:10.45 | cresl1n | yeah, does that pkg-config line work? |
| 19:11.03 | cresl1n | pkg-config --cflags lua |
| 19:11.08 | cresl1n | if you run it separately |
| 19:11.25 | putnopvut | Ah, that indeed does not run. |
| 19:11.59 | putnopvut | I'm installing liblua-dev now. Hopefully that fixes this. Thanks. |
| 19:13.24 | putnopvut | Welp, that got me past that issue. But I've got a different one now. I'll try to fix it on my own before I bug yall about it. |
| 19:19.33 | putnopvut | And I fixed the other problem now. Turned out I had some mismatching versions of lua and the lua-dev library installed. |
| 20:12.05 | *** join/#asterisk-dev newtonr (RustyNewto@nat/digium/x-tgmfhniekwvmaptw) |
| 20:12.05 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 20:34.40 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-82-81-175-197.red.bezeqint.net) |
| 20:34.40 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:48.26 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 20:48.42 | *** join/#asterisk-dev Deeewayne (~dwayne@c-68-32-120-188.hsd1.al.comcast.net) |
| 20:48.42 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 21:52.08 | *** join/#asterisk-dev djadk (~djadk@148.0.46.251) |
| 21:52.30 | *** part/#asterisk-dev djadk (~djadk@148.0.46.251) |
| 22:09.45 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 22:31.15 | X-Rob | http://pastebin.freepbx.org/view/6ac734e3 |
| 22:31.21 | X-Rob | So 13.14's crashing, yo. |
| 22:33.22 | file | in localtime, how fun |
| 22:33.52 | cresl1n | X-Rob: how reproducible is it? |
| 22:34.01 | X-Rob | cresl1n: 100%. 'core reload' == crash |
| 22:34.08 | cresl1n | Ok |
| 22:34.23 | X-Rob | I was just trying to get some more information and I'll open a ticket |
| 22:34.26 | cresl1n | And it definitely changed between 13.13.x and 13.14.0? |
| 22:34.33 | X-Rob | Yep, roll back to 13.13, no crash. |
| 22:34.37 | X-Rob | We pushed out 13.14 yesterday |
| 22:34.51 | X-Rob | https://community.freepbx.org/t/asterisk-restarts-after-clicking-apply-config-changes/39577 |
| 22:35.09 | cresl1n | interesting |
| 22:35.32 | X-Rob | Commenting out #include http_additional.conf and #include http_custom.conf in /etc/asterisk/http.conf appear to resolve the issue. |
| 22:35.32 | X-Rob | I'm doing a bit more research on this now. I'll update again if I learn more. |
| 22:35.34 | X-Rob | ^^^ from the user |
| 22:35.38 | X-Rob | confirming |
| 22:36.11 | file | there was a TLS crash |
| 22:36.39 | file | https://gerrit.asterisk.org/#/c/4960/ |
| 22:38.15 | X-Rob | User found it. We have 'prefix=' in httpd.conf. |
| 22:38.23 | X-Rob | That causes the crash |
| 22:38.31 | X-Rob | adding somethign to it, or, removing it |
| 22:38.37 | X-Rob | makes it not crash |
| 22:39.21 | X-Rob | ... maybe |
| 22:39.47 | X-Rob | nope, still crashy |
| 22:40.05 | X-Rob | https://www.irccloud.com/pastebin/McYKbHqi/ |
| 22:42.04 | X-Rob | red herring, ignore |
| 22:42.17 | file | what is a red herring? |
| 22:42.26 | file | the crash, or the finding? |
| 22:42.27 | X-Rob | httpd.conf, I can still get it to crash |
| 22:42.55 | X-Rob | I couldn't see how, it's not mentioned in the bt |
| 22:43.47 | file | k |
| 22:45.56 | X-Rob | http://pastebin.freepbx.org/view/efc60e56 <-- yep, in ast_srtftime_local all the time. |
| 22:47.37 | rmudgett | That's in malloc. Need to enable MALLOC_DEBUG |
| 22:48.16 | X-Rob | Well crap. I *think* this machine is set up to rebuild our RPM |
| 22:48.25 | X-Rob | lemme see if it's crappy on my 7 machine |
| 22:49.22 | X-Rob | dammit, I didn't publish for 7 |
| 22:54.27 | X-Rob | and it's fine on7 |
| 22:56.21 | X-Rob | So this is going to take a while. . Sorry 8-( |
| 23:30.37 | Qwell | I'm seeing the crash in tcptls.c, 1132. Which, surprise, involves capath. |
| 23:31.04 | Qwell | I'm guessing it's the same issue - at least on my box. |
| 23:48.40 | *** join/#asterisk-dev tuxd00d (~tuxd00d@ip68-106-11-24.ph.ph.cox.net) |
| 23:55.29 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 23:55.45 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:59.43 | X-Rob | Also, the pjsip intergrity validation is broken, and I need to put a patch in for that. |
| 23:59.44 | X-Rob | I had to disable it |