| 00:24.55 | kharwell | yup ast_file_read_dirs should be thread safe on all platforms. I think that is one of the reason we wrote it. |
| 00:25.12 | kharwell | Because of that if doing a directory search in asterisk that function should always be used |
| 00:36.12 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 00:36.12 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 00:44.55 | snuff-work | mm.. if i have a random pjsip crash.. is it worth uploading a backtrace? atm don't know how it was caused |
| 00:46.34 | coreyfarrell | snuff-work: I'd say yes.. most crashes qualify as 'major' in my opinion. |
| 00:48.19 | file | do be running bundled though... |
| 00:48.54 | snuff-work | it is always.. and dont optimised =) |
| 00:49.07 | snuff-work | mm 80mb backtraces |
| 00:49.16 | coreyfarrell | snuff-work: did you have dev-mode enabled? |
| 00:52.19 | coreyfarrell | in master dev-mode enables assertions for pjproject, sometimes pjproject uses asserts inappropriately. the idea of dev-mode assertions for pjproject is to 1) find real issues and 2) find places where pjproject should be switched from an assert to a regular error return. |
| 00:53.18 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-onupaukdxhhisgbv) |
| 00:55.50 | snuff-work | yes i have dev-mode on also |
| 00:57.46 | coreyfarrell | it's possible you hit an assertion, I don't remember if bundled pjproject causes an abort for assertions. |
| 00:59.11 | snuff-work | it seems to =) |
| 00:59.17 | snuff-work | and it was an assert |
| 01:00.07 | snuff-work | https://issues.asterisk.org/jira/browse/ASTERISK-27626 |
| 01:00.21 | snuff-work | backtraces uploaded as well now |
| 01:01.54 | snuff-work | might just have to turn off dev mode in the main office and leave it just on mine.. don't think they'll like me killing the phones so often |
| 01:02.42 | coreyfarrell | snuff-work: you uploaded the core dumps? |
| 01:05.19 | snuff-work | yep they are there |
| 01:05.31 | rmudgett | core dumps are not backtraces |
| 01:05.49 | snuff-work | don't worry.. they are cores |
| 01:05.56 | coreyfarrell | I just deleted them. |
| 01:06.01 | snuff-work | oh lol |
| 01:06.04 | rmudgett | core dumps are memory images of the process and only usable by the machine that created them. |
| 01:06.37 | snuff-work | ok.. so u just need BTs then.. |
| 01:06.43 | rmudgett | always |
| 01:06.44 | coreyfarrell | snuff-work: https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace |
| 01:06.48 | snuff-work | aka bt /bt full texts |
| 01:06.54 | snuff-work | its been a while =) |
| 01:07.15 | file | yes, and I think that's an assertion which will abort if dev mode is on |
| 01:09.15 | file | it is |
| 01:09.25 | file | in non-dev mode it would not assert |
| 01:09.35 | snuff-work | sorry more useful data coming right up.. how new is that 'ast_coredumper' script? dont recall it from a year or so ago |
| 01:11.51 | snuff-work | ok now should be useful txt files from the ast_coredumper thing sitting there for both core dumps |
| 01:12.16 | rmudgett | ast_coredumper was introduced around six months ago |
| 01:13.04 | snuff-work | ah nice |
| 01:13.58 | snuff-work | no copyright info attached to it / who wrote it =) |
| 01:15.07 | snuff-work | well i'll bb in a while if anyone wants me to gather anything else |
| 01:20.27 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 01:20.27 | *** 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 |
| 01:30.32 | coreyfarrell | weird, that check is not even done at run-time if PJ_ENABLE_EXTRA_CHECK is disabled (it's enabled by default). |
| 01:57.49 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:f43f:348c:3ccf:c350) |
| 01:57.49 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 04:17.37 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:ecc7:dfde:7de4:64ae) |
| 04:17.37 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 06:00.11 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.168) |
| 07:13.21 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.168) |
| 07:49.39 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:28d3:84af:1c88:e67a) |
| 07:59.17 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 07:59.18 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 08:20.58 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 08:20.58 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 08:25.50 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 11:01.36 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 11:01.36 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 11:47.19 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 11:47.19 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 12:17.21 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 12:40.11 | *** join/#asterisk-dev fblackburn (~fblackbur@modemcable094.94-70-69.static.videotron.ca) |
| 12:44.35 | *** join/#asterisk-dev jkroon (~jkroon@41.21.200.174) |
| 12:53.50 | gtjoseph | coreyfarrell: are you going to fix the CHECK_BLOCKING issue yourself? |
| 13:19.29 | *** join/#asterisk-dev leedm777 (~textual@50-81-29-44.client.mchsi.com) |
| 13:19.29 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 13:25.45 | *** join/#asterisk-dev sotoz (~sotoz@095-097-255-066.static.chello.nl) |
| 13:54.48 | *** join/#asterisk-dev sduthil (~sduthil@modemcable094.94-70-69.static.videotron.ca) |
| 14:26.49 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 14:26.50 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 14:41.46 | *** join/#asterisk-dev sduthil (~sduthil@modemcable094.94-70-69.static.videotron.ca) |
| 15:02.04 | *** join/#asterisk-dev bford (d8cff501@gateway/web/freenode/ip.216.207.245.1) |
| 15:02.04 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:06.15 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-zwpvfqkhoprekrmb) |
| 15:06.15 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:10.17 | file | falls over |
| 15:11.48 | *** join/#asterisk-dev cresl1n (Adium@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 15:11.48 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 15:20.14 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-kpdwfdurtmmtvepm) |
| 15:20.14 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:29.35 | cresl1n | Does anybody know Alexander Traud's IRC handle? |
| 15:29.52 | file | I don't believe I've ever seen him on IRC |
| 15:29.56 | gtjoseph | me neither |
| 15:29.57 | cresl1n | Oh. |
| 15:29.58 | cresl1n | ok |
| 15:30.03 | cresl1n | He emailed me about FOSDEM |
| 15:30.10 | cresl1n | I guess he's never been but he's going this year |
| 15:30.19 | cresl1n | wanted to figure out how everybody found each other |
| 15:30.36 | file | carefully |
| 15:30.51 | cresl1n | ha! |
| 15:39.40 | seanbright | it's traud when he's here |
| 15:42.54 | cresl1n | Thanks seanbright |
| 15:43.02 | seanbright | you're welcome, cresl1n. |
| 15:43.05 | cresl1n | Anybody used the sip_to_pjsip.py script recently? |
| 15:43.54 | file | no |
| 15:44.11 | cresl1n | Oh |
| 15:44.19 | cresl1n | wonder if it's broken-ish |
| 15:44.20 | file | :D |
| 15:44.40 | cresl1n | tsearle: what about you? |
| 15:45.05 | tsearle | i can't vouch for trunk |
| 15:45.13 | tsearle | but I have used it heavily last year |
| 15:45.31 | tsearle | what issue were you seeing with it? |
| 15:45.42 | cresl1n | it's only outputting an empty pjsip.conf |
| 15:45.47 | seanbright | that's a feature |
| 15:45.50 | cresl1n | ha! |
| 15:45.51 | file | last changes done were by tsearle in October |
| 15:45.55 | cresl1n | ok |
| 15:46.42 | tsearle | I've only seen it do empty pjsip.conf if you didn't have a sip.conf in the local dir or failed to specify a sip.conf |
| 15:46.55 | cresl1n | ok |
| 15:48.15 | tsearle | let give it a try |
| 15:48.34 | cresl1n | huh |
| 15:48.43 | cresl1n | I've got to be doing something wrong then |
| 15:48.48 | cresl1n | I've never used it before |
| 15:49.08 | cresl1n | I uncommented a bunch of sections in the sample sip.conf and can't get it to produce any endpoints/etc in pjsip.conf |
| 15:49.16 | cresl1n | just the empty file thing |
| 15:49.23 | cresl1n | Even if I checkout an old version of it |
| 15:49.29 | cresl1n | (aka from a year or so ago |
| 15:49.30 | cresl1n | ) |
| 15:50.18 | file | what does it... say? |
| 15:50.24 | file | the output of the script |
| 15:50.37 | cresl1n | matt@matt-laptop:~/dev/asterisk$ python contrib/scripts/sip_to_pjsip/sip_to_pjsip.py ./sip.conf ./pjsip-2.conf |
| 15:50.37 | cresl1n | Please, report any issue at: |
| 15:50.37 | cresl1n | <PROTECTED> |
| 15:50.37 | cresl1n | Reading ./sip.conf |
| 15:50.37 | cresl1n | Converting to PJSIP... |
| 15:50.37 | cresl1n | Writing ./pjsip-2.conf |
| 15:51.26 | tsearle | ./sip_to_pjsip.py sip.conf |
| 15:51.27 | tsearle | Please, report any issue at: |
| 15:51.27 | tsearle | <PROTECTED> |
| 15:51.27 | tsearle | Reading sip.conf |
| 15:51.27 | tsearle | Converting to PJSIP... |
| 15:51.27 | tsearle | Writing pjsip.conf |
| 15:51.37 | file | I just copied over an old sip.conf and ran it like that, and got a pjsip-2.conf that contains the correct stuff |
| 15:51.43 | cresl1n | nice |
| 15:51.47 | cresl1n | maybe it's a silly thing with my distro |
| 15:51.48 | tsearle | actually |
| 15:51.57 | tsearle | does the default sip.conf have any peers? |
| 15:52.05 | cresl1n | I uncommented a few |
| 15:52.28 | tsearle | with my sip.conf it didn't have any peers, but I still have a non-empty pjsip.conf |
| 15:52.40 | tsearle | with stuf like bindings and user-agent string ported over |
| 15:53.01 | cresl1n | Sorry, when I say emptry, bindaddr came through, just none of the peers |
| 15:53.05 | cresl1n | *empty |
| 15:53.14 | cresl1n | brb, got to get ready for standup |
| 15:56.23 | *** join/#asterisk-dev Worldexe (~Worldexe@95-107-33-134.dsl.orel.ru) |
| 15:57.31 | tsearle | just tested a sip.conf with peers it got converted |
| 15:57.35 | tsearle | sending it your way |
| 16:15.28 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 16:26.22 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 16:26.23 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 16:37.44 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-84-109-19-7.red.bezeqint.net) |
| 16:37.44 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 16:48.33 | coreyfarrell | gtjoseph: possibly. for now I posted the CHECK_BLOCKING issue as I did so someone would ask and we could discuss. I mean I can easily make CHECK_BLOCKING return -1 or 0, but beyond that I'm unsure how the callers should deal with the error. |
| 16:50.55 | coreyfarrell | gtjoseph: I'm thinking it might be smart for CHECK_BLOCKING to frack in the error condition, but I'm not sure if that's too extreme. |
| 16:55.11 | gtjoseph | coreyfarrell: we just got out of standup so maybe the others can chime in |
| 16:55.26 | file | does it still have any value? |
| 16:56.31 | coreyfarrell | sorry I don't understand the question. |
| 16:56.45 | file | does CHECK_BLOCKING itself have any value these days? |
| 16:57.13 | seanbright | it'd be a pretty big win to remove it |
| 16:57.44 | file | many many many years ago it pointed out some bad code |
| 16:58.15 | seanbright | #define CHECK_BLOCKING(x) |
| 16:58.19 | seanbright | yay, fixed! |
| 16:58.50 | file | seanbright: I like removing code from those paths :D |
| 16:58.52 | seanbright | well, and then remove locking |
| 16:59.14 | seanbright | does that remove the need for blocker and blockproc too? |
| 16:59.15 | coreyfarrell | well CHECK_BLOCKING currently set's the blocking thread which is needed to be able to pthread_kill the channel (like for a redirect). |
| 16:59.32 | seanbright | damn |
| 16:59.43 | file | ah yes, that |
| 16:59.48 | file | the many ways to wake up a channel |
| 17:00.13 | coreyfarrell | there can only be one blocker so if another thread is still "running" the channel we can either abort the current function or try to kill the other blocker. |
| 17:00.36 | file | if that occurs you are in uncharted territory as to what all will happen |
| 17:01.06 | file | returning is probably saner, but locking would need to be confirmed |
| 17:02.27 | coreyfarrell | CHECK_BLOCKING would just need to become an expression macro and have a -1 or 0 result.. the caller would need to handle the return. |
| 17:03.42 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:ffae:d9a3:abe5:b91a:affa) |
| 17:03.42 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 17:03.50 | coreyfarrell | so should we frack on CHECK_BLOCKING error? talking about using __ast_assert_failed like AO2 does. |
| 17:04.28 | file | sure |
| 17:05.43 | coreyfarrell | ok I have enough info to put a review together. i've acked the ticket and self-assigned. |
| 18:00.14 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.164) |
| 18:17.23 | *** join/#asterisk-dev mvanbaak (~mvanbaak@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 18:17.23 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 19:23.24 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 19:23.24 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 19:29.22 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d0078289c11568ffc5f.ipv6.abo.wanadoo.fr) |
| 20:48.41 | kharwell | anyone know if the 'tests/apps/page/page_predial' test has a known problem? fails on jenkins or something? |
| 20:49.12 | kharwell | dunno if the jenkins search works, but it turned up nothing |
| 20:49.44 | gtjoseph | i've never seen it fail |
| 20:49.53 | coreyfarrell | just passed locally for me |
| 20:50.14 | coreyfarrell | ran against a build that is probably a week old.. |
| 20:50.25 | kharwell | must be my box then |
| 20:51.22 | coreyfarrell | maybe the test-config.yaml is missing dependency declaration? |
| 20:53.47 | kharwell | could be |
| 20:59.42 | coreyfarrell | rmudgett: do you understand the memory order stuff in atomic built-ins and how it would apply to refcounting (ao2 and jansson)? https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html |
| 21:02.32 | rmudgett | I haven't looked at it. |
| 21:02.57 | coreyfarrell | I feel like __ATOMIC_RELAXED should be fine but I'm not 100% sure (the problem of providing a race doesn't exist). __ATOMIC_SEQ_CST would be the safest but I'm unsure it's actually needed. |
| 21:03.08 | coreyfarrell | s/providing/proving/ |
| 21:32.31 | rmudgett | I haven't been at that low a level in a long time. Multi-core processors add new wrinkles to atomicity as we now have hardware involved in addition to software threads that could try to modify a ref count. |
| 21:39.29 | coreyfarrell | well I know that __atomic_fetch_add(&v, +1) will always be atomic, I think the idea is that __ATOMIC_RELAXED would not block the compiler/processor from reordering that atomic operation before or after other actions. |
| 21:43.56 | coreyfarrell | if using __ATOMIC_RELAXED in theory ao2_ref(obj1, +1); ao2_ref(obj2, -1); could be reordered but it's not supposed to allow reordering of two calls to atomic actions on the same storage space (so if obj2 destructor released a reference to obj1 the reorder should not be allowed). |
| 22:05.01 | rmudgett | Well, I wouldn't expect the ao2_ref calls to be inlined anywhere so reordering shouldn't be a problem. |
| 22:16.14 | *** join/#asterisk-dev jpsharp (~jsharp@linode.fivecats.org) |
| 22:17.52 | jpsharp | if I use ast_call() to make an outgoing call, what do I need to do to make sure the thread gets properly serviced & handled? I'm using it right now, the outgoing call gets made via SIP, but the channel never gets set to AST_STATE_UP when the far end answers and I get a 200 OK back from it. |
| 22:29.26 | file | you have to implement the same logic that app_dial uses, or dial.c uses to service the channel and act on things that happen |
| 22:29.34 | file | or you can use the dialing API (dial.h) which does that stuff for you |
| 22:30.25 | jpsharp | Yeah, I just ran across the dialing API. I was trying to duplicate what was in app_dial, but it looks like the dial api will be a crapload simpler. |
| 22:37.52 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@LFbn-1-5195-12.w90-105.abo.wanadoo.fr) |
| 22:43.01 | rmudgett | coreyfarrell: Is https://gerrit.asterisk.org/#/c/8007/ dependent upon another patch going in? |
| 22:49.54 | coreyfarrell | rmudgett: nope all the loader stuff is stand-alone can be merged in any order. |
| 22:50.04 | coreyfarrell | all the remaining loader stuff that is .. |
| 23:02.44 | *** join/#asterisk-dev tzafrir (~tzafrir@62-90-199-247.barak.net.il) |
| 23:02.44 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 23:42.15 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 23:42.16 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |