| 00:19.59 | *** join/#asterisk-dev infobot (ibot@208.53.50.136) |
| 00:19.59 | *** 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:32.29 | *** join/#asterisk-dev sahmed (~sahmed@cpe-70-114-236-63.austin.res.rr.com) |
| 04:31.42 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@24-177-250-191.dhcp.nwtn.ct.charter.com) |
| 04:31.42 | *** mode/#asterisk-dev [+o coreyfarrell] by ChanServ |
| 06:18.27 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:18.27 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 06:42.58 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:c1de:9b51:c6ca:f51f) |
| 07:02.37 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 10:34.21 | *** join/#asterisk-dev CELYA_ (~Thunderbi@92.184.105.62) |
| 11:22.36 | tsearle | hey @gtjoseph are you around? |
| 11:22.43 | gtjoseph | i am |
| 11:23.36 | tsearle | cool I was seeing that you've done two commits to res_pjsip_t38.c recently (e.g. this year) |
| 11:24.01 | gtjoseph | I did? I must have blocked them out. :) |
| 11:24.03 | tsearle | and I'm trying to understand them, as I'm have a forced core dump where I have 2 threads stuck |
| 11:24.15 | gtjoseph | ok, let me look |
| 11:24.17 | tsearle | ha sorry, you only did one |
| 11:24.24 | tsearle | <PROTECTED> |
| 11:24.34 | tsearle | commit cea1a22ef300aff2f3eed5cd472b9c47c7668214 |
| 11:24.38 | tsearle | in ast13 |
| 11:24.40 | gtjoseph | which branch? |
| 11:24.43 | gtjoseph | ah |
| 11:25.09 | tsearle | Jan 2nd that one done, and no jira associated |
| 11:25.31 | gtjoseph | yep, ok. timer heap |
| 11:26.16 | tsearle | ok, so ref that, what was wrong with the timer heap and how did it manifest itself as issues? |
| 11:27.52 | gtjoseph | ok so 1 change was to use cancel_if_active and the other was to use pj_timer_entry_init |
| 11:29.02 | gtjoseph | there are issues with the pjproject timer heap overall. a thread could modify the timer entry at the same time the timer thread was trying to actually execute the timer callback |
| 11:29.30 | gtjoseph | this was a source of lots of crashes and corruption |
| 11:29.37 | tsearle | ok |
| 11:30.07 | gtjoseph | the cancel_if_active makes sure that we don't try to cancel a timer while the callback is running or if it had already run |
| 11:30.58 | gtjoseph | the timer_entry_init makes sure that the calling thread doesn't try to modify the entry while it's running. |
| 11:31.28 | gtjoseph | neither of those fixes will fix the issue completely but they make it less likely to happen. |
| 11:32.32 | tsearle | ok... so that possibly may be related to one of 2 issues |
| 11:32.50 | gtjoseph | do you think my fix broke something else? |
| 11:33.03 | tsearle | no |
| 11:33.36 | tsearle | looking that things our code doesn't have yet to see if backporting is benificial fixing our current issues |
| 11:33.45 | gtjoseph | ah |
| 11:34.02 | gtjoseph | I would say "yes" in this case. |
| 11:34.17 | tsearle | the other issue seems a bit clearer |
| 11:34.33 | tsearle | we have 2 threads that are at |
| 11:34.36 | tsearle | session_media = ao2_find(session->media, "image", OBJ_SEARCH_KEY); |
| 11:35.24 | tsearle | and both get stuck trying to get the lock on the ao2 container, thread id of the owner is for a thread that doesn't exist (and possibly invalid) |
| 11:35.46 | tsearle | and also session->media got set to null whil ao2_find was waiting for the lock |
| 11:35.54 | gtjoseph | ew |
| 11:36.42 | tsearle | basically we forced core in prod, and I'm thinking the core dump might have do separate deadlock issues, heh |
| 11:37.57 | tsearle | anyhow thanks for your inputs, I'll go back to trying to figure out what's going on |
| 11:40.45 | gtjoseph | no problem |
| 12:22.18 | *** join/#asterisk-dev scgm11_ (~scgm11@2800:a4:1678:6300:35ce:585a:8931:c2b0) |
| 12:24.32 | tsearle | has anybody ever seen tsx_on_state_proceeding_uas get stuck in an infinite loop? |
| 12:24.50 | file | no |
| 12:25.10 | tsearle | ok |
| 12:26.04 | tsearle | so I guess I need to figure out how it doesn't return at burn 100% cpu |
| 12:32.38 | *** join/#asterisk-dev joshelson (~joshelson@50.227.57.114) |
| 12:51.27 | tsearle | ok, iterating the headers in sanitize_tdata ends up in an infinite loop, meaning probably somebody modified the header list w/o proper locking |
| 13:35.27 | *** join/#asterisk-dev le_gid (QvZpmfApYm@enif.uberspace.de) |
| 13:36.34 | *** join/#asterisk-dev vipul20 (uid64067@gateway/web/irccloud.com/x-zygzqumnfdfqhpkv) |
| 13:46.14 | *** join/#asterisk-dev joshelson (~joshelson@151.181.77.18) |
| 14:20.04 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:20.04 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:20.11 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-otvvrqyalodmxujb) |
| 14:20.11 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:24.46 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-tdrmtlkpnrncvfji) |
| 14:24.46 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:19.58 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-gtyltroowmzitgtw) |
| 15:19.58 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 16:15.44 | *** join/#asterisk-dev dakudos (~dakudos@c-73-243-106-97.hsd1.co.comcast.net) |
| 17:20.11 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00c801bfbb05062d6e.ipv6.abo.wanadoo.fr) |
| 17:34.56 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@LFbn-1-5358-11.w90-105.abo.wanadoo.fr) |
| 17:45.43 | *** part/#asterisk-dev n3t (~n3t@unaffiliated/n3t) |
| 19:14.33 | *** join/#asterisk-dev malcolmd (malcolmd@pdpc/sponsor/digium/malcolmd) |
| 19:14.33 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 19:33.06 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.168) |
| 20:44.30 | jsmith | cresl1n: Any thoughts on moving away from the "iksemel" module for XMPP? It doesn't seem to be maintained upstream, and distros are starting to drop it too... |
| 20:50.20 | seanbright | is there a replacement? |
| 21:25.16 | cresl1n | I wouldn't be opposed if someone wants to make a patch for it |
| 21:26.51 | file | +1 |
| 21:29.29 | jsmith | I just had to disable chan_motif, res_xmpp, and res_calendar_exchange modules in Fedora because they've dropped iksemel due to insecure TLS settings (and failure to build from source anymore) |
| 23:24.30 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-tdrmtlkpnrncvfji) |
| 23:29.38 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 23:29.38 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:59.12 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 23:59.12 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |