| 00:19.21 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 00:19.21 | *** 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 |
| 00:21.49 | *** join/#asterisk-dev jkroon_ (~jkroon@165.16.204.172) |
| 01:03.10 | *** join/#asterisk-dev Oooohboy (~Oooohboy@2605:6000:1711:c1ff:88c6:b870:e12c:fc4e) |
| 04:36.29 | *** join/#asterisk-dev CELYA_ (~Thunderbi@159.180.237.175) |
| 04:54.16 | *** join/#asterisk-dev elguero (~miguel323@74-95-21-41-Connecticut.hfc.comcastbusiness.net) |
| 07:45.23 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:45.23 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 08:26.00 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 08:26.00 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:36.49 | *** join/#asterisk-dev jkroon (~jkroon@vc-nat-gp-s-41-13-28-11.umts.vodacom.co.za) |
| 09:38.09 | coreyfarrell | I just got a new/odd error message from `git review -f -R`: error: remote unpack failed: error Missing tree 31a411390999cefce5aff68b2bff34224986b289 |
| 09:45.57 | coreyfarrell | hmm I just started over from the previous commit and cherry-picked my new commit, that worked. |
| 10:11.44 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 11:20.51 | *** join/#asterisk-dev jkroon (~jkroon@vc-nat-gp-s-41-13-56-103.umts.vodacom.co.za) |
| 11:25.56 | *** join/#asterisk-dev CELYA_ (~Thunderbi@ip-91-191-153-122.sd-france.net) |
| 11:41.21 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 11:41.21 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 12:16.50 | *** join/#asterisk-dev CELYA_ (~Thunderbi@ip-91-191-153-122.sd-france.net) |
| 12:33.39 | *** join/#asterisk-dev cresl1n (~Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 12:33.39 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 12:55.16 | *** join/#asterisk-dev pchero (~pchero@x1-6-d8-d7-75-5e-99-79.cpe.webspeed.dk) |
| 13:10.19 | seanbright | can someone put something just KINDA interesting on gerrit today? |
| 13:10.33 | file | I don't have anything :( |
| 13:10.36 | seanbright | UGH |
| 13:11.02 | seanbright | well at least we finally have netbsd and arch linux support in install_prereq |
| 13:11.13 | file | that deserves cake! |
| 13:11.13 | seanbright | users have been clamoring for that |
| 13:12.12 | seanbright | file: your OPTIONS rewrite? |
| 13:12.41 | file | I think gtjoseph has fixes for that |
| 13:12.45 | gtjoseph | i do |
| 13:12.50 | seanbright | well i can't sit here all day |
| 13:12.53 | gtjoseph | trying to get to them today |
| 13:12.56 | seanbright | that's not true... i actually can |
| 13:13.42 | seanbright | i would contribute something, but my time is so limited now that i just drop by to shit on everyone else and then leave |
| 13:13.50 | seanbright | speaking of which... ttyl! |
| 13:35.37 | jsmith | seanbright: Why not just go replace autoconf/automake with meson? |
| 13:35.51 | jsmith | seanbright: There's a project for you :-) |
| 13:35.54 | jsmith | ducks and hides |
| 13:42.37 | seanbright | meson? |
| 13:42.53 | seanbright | well, to be fair, i have about 10 things i /want/ to work on |
| 13:43.03 | seanbright | just no time to do so |
| 13:48.38 | *** join/#asterisk-dev leedm777 (textual@nat/digium/x-hhmxssqdfsdgrgqt) |
| 13:48.38 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 14:11.55 | stefan27 | What's the purpose of ast_module_user_add(chan) ? Or better yet, if there existed publicaly available documentation for it, where and how would I most likely find it? I tried doing 'grep -r ast_module_user_add -C 3' in a checked-out source folder, and i tried entering ast_module_user_add as search word in http://doxygen.asterisk.org/trunk |
| 14:15.53 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-lcdjhrpcgrjuqcuc) |
| 14:15.53 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:16.57 | file | that's old code |
| 14:17.18 | file | but it keeps track of usage of a module |
| 14:17.26 | file | to stop things like doing "module unload" on a module that is in use |
| 14:35.50 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-rywfurjouvbqshtj) |
| 14:35.50 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:37.13 | stefan27 | Ah |
| 14:39.22 | coreyfarrell | stefan27: ast_module_user_add is similar to ast_module_ref but it allows the module loader to hangup channels during 'module unload'.. mostly for cases of a race between new channel and module unload. |
| 14:40.11 | coreyfarrell | gtjoseph: so should I just abandon that install_prereq break-up patch? |
| 14:40.34 | gtjoseph | well, not yet. i want to post to the -dev list first and get feedback |
| 14:51.11 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-blxedbzewpyguwvl) |
| 14:51.11 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 14:52.17 | AsteriskRoss | I've just created issue ASTERISK-27741 as it appears my patch for ASTERISK-27554 fixing 'Call completed elsewhere' has broken cases where Asterisk instances talk to each other |
| 14:52.55 | AsteriskRoss | At present Asterisk doesn't take into account multiple Reason headers and therefore does not pass the hangup cause into the core |
| 14:58.39 | AsteriskRoss | Looking at the code I'm not 100% sure how to resolve the issue. Should we loop through all headers and only process Reason: Q.850? |
| 15:23.27 | file | yes, I believe so |
| 15:48.00 | *** join/#asterisk-dev Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 15:50.43 | seanbright | might be a good idea to implement a header parser for that -> http://www.pjsip.org/pjsip/docs/html/group__PJSIP__PARSER.htm#ga7d57912df8d262a56b4ca38b1563df4a |
| 15:51.26 | seanbright | so that we properly handle multiple header values in a single header |
| 16:13.58 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.172) |
| 16:21.25 | AsteriskRoss | I've just pushed a review, be nice I'm not a C programmer! |
| 16:21.47 | AsteriskRoss | @seanbright I'm not sure how to do that :) |
| 16:31.40 | seanbright | AsteriskRoss: did you test that? |
| 16:35.10 | AsteriskRoss | I'm in the process of doing than now, not sure if the logic is correct |
| 16:36.32 | seanbright | the logic is not correct |
| 16:39.39 | seanbright | to negate a boolean expression, you have to negate the operands and flip the operator |
| 16:40.02 | seanbright | "p || q" becomes "!p && !q" |
| 16:40.51 | seanbright | which is the same as "!(p || q)" |
| 16:40.57 | seanbright | de morgan for the win |
| 16:43.21 | jsmith | seanbright: Pretty soon you'll be drawing Karnaugh maps to avoid glitches when transitioning between states with state machines :-) |
| 16:43.44 | jsmith | seanbright: Look at you go :-) |
| 16:44.18 | seanbright | i've never seen a karnaugh map before. looks fancy. |
| 16:48.02 | jsmith | seanbright: They're super-handy... if you're dealing with boolean logic and state machines. |
| 16:51.43 | AsteriskRoss | So the original is "strncasecmp(cause, "Q.850", 5) || !(cause = strstr(cause, "cause="))" therefore it becomes "!strncasecmp(cause, "Q.850", 5) && (cause = strstr(cause, "cause="))"? |
| 16:53.20 | seanbright | if the desire is to negate it, yes |
| 17:01.03 | AsteriskRoss | If i understand it, it should match a string starting 'Q.850' and set cause= to the substring after 'cause' if that succeeds we need to process that header |
| 17:02.24 | seanbright | the original if statement said: return if the protocol is not Q.850 or if there is no 'cause' param |
| 17:02.46 | seanbright | now it says: do something if the protocol is Q.850 and there is a 'cause' param |
| 17:02.59 | AsteriskRoss | That's how i understood it |
| 17:03.04 | seanbright | perfect |
| 17:03.54 | AsteriskRoss | Thank you for your help @seanbright it is appreciated! |
| 17:04.02 | seanbright | sure thing |
| 17:04.47 | seanbright | i hate trying to mentally parse strcmp and friends |
| 17:21.51 | seanbright | AsteriskRoss: the last argument to pjsip_msg_find_hdr_by_name() the first time you call it should be NULL |
| 17:22.08 | seanbright | each subsequent time you call it it should be header->next |
| 17:22.54 | seanbright | it's expecting a pointer to a header, not an int |
| 17:24.58 | AsteriskRoss | Thanks, that's probably why it segfaults |
| 18:09.29 | AsteriskRoss | New patch set uploaded and confirmed as working for any order Reason header |
| 19:18.25 | *** join/#asterisk-dev Oooohboy (~Oooohboy@2605:6000:1711:c1ff:85a4:68d7:5790:2ebf) |
| 19:56.42 | *** join/#asterisk-dev tzafrir (~tzafrir@62-90-199-247.barak.net.il) |
| 19:56.42 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:18.05 | seanbright | AsteriskRoss: you'll need to reformat your patch to match the asterisk coding guidelines |
| 20:18.12 | seanbright | i linked them in the gerrit review |
| 20:18.22 | seanbright | ... twice now |
| 21:01.57 | coreyfarrell | rmudgett: just realizing if we want we could backport the MALLOC_FAILURE_MSG / DEBUG_CHAOS from __ast_alloc_region and remove the menuselect conflict. |
| 21:03.48 | coreyfarrell | MALLOC_DEBUG would still be an ABI breaking option in 13/15 but at least we'd get errors in the regular asterisk logger. |
| 21:05.37 | rmudgett | I don't think we want to have MALLOC_FAILURE_MSG done to the replacement functions. We could do the DEBUG_CHAOS change to __ast_alloc_region though. I was suggesting that in the last comment of the review. |
| 21:07.18 | rmudgett | calloc could theoretically be redirected to MALLOC_DEBUG before the logger is setup. |
| 21:09.39 | coreyfarrell | when the logger isn't setup it just does fputs(logmsg->message, stdout); |
| 21:12.00 | coreyfarrell | also with DEBUG_MALLOC disabled it's possible to hit MALLOC_FAILURE_MSG before logger is setup (this is the case in all branches). |
| 21:18.13 | rmudgett | Anyway, I don't think we should remove the repl layer. |
| 21:19.13 | coreyfarrell | ok, can you help me understand why? |
| 21:28.57 | rmudgett | I already stated on the review comment. __ast_calloc is a wrapper that adds ASTERISK specific functionality (i.e. Logging failure and DEBUG_CHAOS) |
| 21:29.50 | rmudgett | __ast_repl_calloc() is a replacement version of calloc. It just adds debug tracing without adding additional functionality. |
| 21:30.20 | coreyfarrell | oh so you want bundled pjproject to bypass use failure logging or DEBUG_CHAOS? |
| 21:31.42 | rmudgett | Yes. Though DEBUG_CHAOS is similar to MALLOC_DEBUG in that it is purely debugging. |
| 21:32.54 | rmudgett | Also the versions in asterisk_malloc_debug.c are only for the pjproject stand alone utilities such as pjsua. |
| 21:34.28 | coreyfarrell | asterisk_malloc_debug.h is used by pjproject library but linked to the implementation in main/astmm.c? |
| 21:35.28 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 21:35.28 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 21:39.24 | rmudgett | asteris_malloc_debug.h is included by config_site.h when pjproject includes it and MALLOC_DEBUG is enabled. It is not included when asterisk includes config_site.h |
| 21:40.55 | rmudgett | asterisk_malloc_debug.h reroutes the allocation routines to asterisk's replacements. |
| 21:42.26 | rmudgett | When they are rerouted, the pjproject standalone utilities need the stubs in asterisk_malloc_debug.c to link with. |
| 21:47.47 | rmudgett | Heh. I hadn't posted my explanations on the review yet because of other distractions. |
| 21:48.42 | coreyfarrell | I honestly don't see the risk or reason against calling ast_log_safe when MALLOC_DEBUG is enabled and bundled pjproject has an allocation failure. if MALLOC_DEBUG is not enabled pjproject doesn't use asterisk allocators. |
| 21:48.54 | coreyfarrell | I will look at splitting the __ast_repl back out but I'll have to rerun the performance test. |
| 21:50.11 | coreyfarrell | the test I previously ran was not for 3 levels of non-inline functions (__ast_calloc -> __ast_repl_calloc -> calloc), I'm concerned that bringing the _repl functions back will negatively impact performance with conversion of AST_INLINE_API functions to regular functions. |
| 21:52.28 | rmudgett | I think the optimizer will eliminate the __ast_repl_calloc level when MALLOC_DEBUG is not enabled since it now has access to both functions in the same translation unit. |
| 21:52.53 | rmudgett | in __ast_calloc |
| 21:58.42 | coreyfarrell | hopefully.. it's still a big enough change that I'm going to have to retest (glad I still have the malloc loop you wrote in git stash). |
| 22:02.59 | coreyfarrell | from within Asterisk itself I think only main/astmm.c will reference the __ast_repl functions? so the symbols will be exported for the sake of libasteriskpj.so but that's it? |
| 22:10.36 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00885907463ba8b041.ipv6.abo.wanadoo.fr) |
| 22:23.33 | rmudgett | When optimization is enabled with __ast_calloc and __ast_repl_calloc both in astmm.c, I think the compiler will make __ast_calloc call calloc directly when MALLOC_DEBUG is not enabled. |
| 22:27.06 | coreyfarrell | rmudgett: in the current code __ast_repl_strdup checks for !s in MALLOC_DEBUG, calls strdup directly for !MALLOC_DEBUG. I'm thinking the check is unneeded as __ast_strdup will do the check before calling __ast_repl_strdup so it can be removed from the MALLOC_DEBUG variant? same for __ast_repl_strndup. |
| 22:40.51 | rmudgett | Yes. Considering that the std lib functions are not NULL tolerant. |
| 23:23.44 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-lcdjhrpcgrjuqcuc) |
| 23:30.22 | coreyfarrell | rmudgett: you were right.. no significant change in the performance test.. maybe 100ms faster than last time. |