| 00:19.20 | *** join/#asterisk-dev infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 00:19.21 | *** topic/#asterisk-dev is Take the March 2019 Asterisk User Survey! https://goo.gl/forms/xL1VUHRsf95saly13 -- 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.51 | *** join/#asterisk-dev opticron (~opticron@136.53.69.43) |
| 04:40.52 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 06:16.22 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 06:33.31 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.58) |
| 07:10.18 | *** join/#asterisk-dev scgm11_ (~scgm11@27.red-213-4-21.staticip.rima-tde.net) |
| 08:11.05 | *** join/#asterisk-dev scgm11_ (~scgm11@147.204.224.35.bc.googleusercontent.com) |
| 08:15.26 | *** join/#asterisk-dev scgm11__ (~scgm11@27.red-213-4-21.staticip.rima-tde.net) |
| 08:48.17 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 10:02.50 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01:e0a:d:1111:b749:768d:ed77:7c9a) |
| 10:07.22 | *** join/#asterisk-dev pchero_work (~pchero@87.213.247.82) |
| 12:33.40 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 13:16.03 | *** join/#asterisk-dev scgm11_ (~scgm11@27.red-213-4-21.staticip.rima-tde.net) |
| 13:40.11 | seanbright | dumb question... when looking at a backtrace, how do you determine which of threads caused the crash? |
| 13:42.08 | seanbright | is it always the first thread listed? always the last one? |
| 13:42.32 | file | that's an interesting question - isn't it always the selected thread within gdb ie the last one? |
| 13:43.01 | seanbright | i don't know... that's why i'm asking :) |
| 13:43.11 | file | I've never thought about it |
| 13:43.18 | seanbright | https://issues.asterisk.org/jira/secure/attachment/58608/core-asterisk-running-2019-09-30T13-33-22-0400-brief.txt |
| 13:43.35 | seanbright | 343 threads. so it's either Thread 1 or Thread 343... is that our contention? |
| 13:43.36 | file | that's a deadlock, not a crash |
| 13:43.40 | seanbright | oh |
| 13:43.43 | seanbright | well that explains it |
| 13:43.54 | file | users just tend to go for crash when describing such things |
| 13:43.58 | seanbright | the title of the ticket is... "Asterisk Crashes" |
| 13:44.00 | seanbright | heh |
| 13:44.40 | *** join/#asterisk-dev Guest80184 (danjenkins@gateway/shell/matrix.org/x-yuztlsbqtsyewhob) |
| 13:44.40 | *** mode/#asterisk-dev [+o Guest80184] by ChanServ |
| 13:47.18 | file | Guest80184: . |
| 14:08.12 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-kdhfewlpziqizvlh) |
| 14:08.12 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:13.21 | *** join/#asterisk-dev dadrc (~quassel@unaffiliated/drc) |
| 14:18.19 | *** join/#asterisk-dev dadrc (~quassel@unaffiliated/drc) |
| 14:51.41 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-czqgwlvcrmwkfluv) |
| 14:51.41 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 16:38.51 | coreyfarrell | kharwell: just so my comment isn't confused ao2_global_object is still needed in res_pjsip_mwi.. the shutdown ref would ensure dlclose can never run on the module so callbacks into it won't crash. |
| 16:45.16 | kharwell | yes a pjsip serialize can potentially be set to execute after the module unloads. I modified res_pjsip_mwi to use its serializer pool for all taskprocessing and then protected it with a shutdown group. |
| 16:46.34 | kharwell | However, depending on the load, there is still potential for the default sip serializers to be used, so adding the shutdown ref would add protection for that (wasn't sure how to handle that at this point so that is good), plus any other cases missed |
| 17:26.04 | kharwell | thinking more about it. The shutdown ref will prevent manual unloading. The added shutdown group should hopefully prevent crashes on unload now for most scenarios. |
| 17:27.40 | kharwell | The only one I can think of is if on load the mwi serializer pool didn't initialize and then default sip one was used. I could add a the shutdown_ref only if this off nominal case occurs? |
| 18:05.18 | kharwell | I updated the review to handle the above |
| 21:01.17 | seanbright | does freepbx distribute a modified version of asterisk? |
| 21:01.21 | seanbright | or is it vanilla? |
| 21:12.12 | file | it's mostly vanilla, they have one or two patches - one which can go away in the future, the other that can't due to liecnsing |
| 22:39.19 | *** join/#asterisk-dev pc-m (~pcm@cable-66-129-132-216.b2b2c.ca) |
| 23:31.57 | *** join/#asterisk-dev pc-m (~pcm@cable-66-129-132-216.b2b2c.ca) |