| 00:46.42 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:4485:bad8:ab18:30f6) |
| 00:46.42 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 00:49.45 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 00:49.45 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 00:51.36 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:5c1d:7008:145c:311a) |
| 00:51.37 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 01:08.01 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:5da8:16b6:4bba:2eaa) |
| 01:08.02 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 01:09.39 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:8529:342:e57a:ad16) |
| 01:09.39 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 01:28.33 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:3417:48ee:bb6f:d075) |
| 01:28.33 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 01:42.05 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:c81d:840a:15e3:77c6) |
| 01:42.05 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 03:19.59 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 03:20.00 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 04:01.37 | *** join/#asterisk-dev leedm777 (~textual@2604:2d80:8404:8011:14c2:b2e3:5fa4:87dd) |
| 04:01.37 | *** mode/#asterisk-dev [+o leedm777] by ChanServ |
| 08:41.52 | *** join/#asterisk-dev snuff-work (~snuff-wor@210.9.148.102) |
| 08:41.53 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 12:31.08 | coreyfarrell | file / gtjoseph: hopefully you're enjoying your weekend.. at some point could someone help me understand `struct ast_sip_session` lifecycle? even with a 33 second delay before shutting down modules I'm still getting a large number of tests leaking one or more of that object. |
| 12:36.09 | coreyfarrell | I know that's not a simple or easy question, any tips will be appreciated. |
| 12:39.11 | file | it currently follows the lifetime of the INVITE session/dialog, which terminates as a result of a timer internally in PJSIP and runs within the monitor thread itself |
| 12:40.28 | file | that dispatches it to another thread though |
| 12:55.58 | coreyfarrell | it seems to be `inv_session->mod_data[session_module.id] = ao2_bump(session);` from ast_sip_session_alloc that is being leaked, at least when the session is created by handle_new_invite_request.. |
| 13:03.50 | file | my suggestion is to add logging, run through normal scenario, see how it works, go from there |
| 13:08.45 | gtjoseph | coreyfarrell: you can also try timer_t1=100 and timer_b=6400 in pjsip.conf/system to bring the timer down to the minimums |
| 13:09.06 | gtjoseph | it's actually timer_b that controls the lifecycle but it's dependent on timer_t1 |
| 13:09.51 | gtjoseph | with those settings things should be cleaned up about 6.4 seconds after a successful call end. |
| 13:09.59 | coreyfarrell | gtjoseph: I tried that and I believe it caused some (or many) tests to fail. didn't really try to troubleshoot why. |
| 13:10.17 | gtjoseph | ok, might want to isolate 1 test and try it then |
| 13:10.27 | gtjoseph | just to see if it's a factor |
| 13:11.18 | gtjoseph | pjsip show settings will show you the actual settings. the default is 32 seconds IIRC |
| 13:11.41 | coreyfarrell | most of the basic calls tests pass. I think I might be dealing with off-nominal paths. |
| 13:12.32 | gtjoseph | probably because if the call doesn't end successfully and pjproject tries to continue to send BYEs for instance, the timer wouldn't have kicked in |
| 13:14.21 | coreyfarrell | I'll be adding some logging as file suggested.. one thing I'm noticing is in new_invite() a few paths 'goto end' before the timer is initialized. |
| 13:14.35 | gtjoseph | you could also pick 1 test that fails and turn the pjproject logging up to full to see exactly when it gives upo |
| 13:15.56 | gtjoseph | in the case you mentioned do we get an immediate return with error or dies pjproject give is a success then send us an event to tell us it failed? |
| 13:21.42 | coreyfarrell | new_invite isn't called by pjproject, we call it directly from handle_new_invite_request on the newly created session. if get_destination doesn't return SIP_GET_DEST_EXTEN_FOUND we abort without setting up a timer. |
| 13:22.28 | gtjoseph | oh, you mean our timer |
| 13:22.31 | gtjoseph | sorry |
| 13:26.40 | coreyfarrell | yes pjsip_timer_init_session.. we only init that timer if the destination extension is found. |
| 13:29.48 | coreyfarrell | I'll have to crank up the logging and see what it tells me. going to try working with the allow_overlap test since that one leaks and likely has paths which doesn't setup our timer. |
| 13:30.42 | file | that timer is session timers |
| 13:31.12 | file | (SIP session timers) |
| 17:51.28 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.169) |
| 19:16.04 | *** join/#asterisk-dev seanbright (~sean@asterisk/community-developer/seanbright) |
| 19:16.04 | *** mode/#asterisk-dev [+o seanbright] by orwell.freenode.net |
| 21:43.24 | *** join/#asterisk-dev AsteriskRoss (259d3426@gateway/web/freenode/ip.37.157.52.38) |
| 22:06.27 | *** join/#asterisk-dev elcontrastador (~textual@70-90-215-98-BusName-ca.sacra.hfc.comcastbusiness.net) |