| 00:01.36 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 00:01.37 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 00:05.49 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 00:10.37 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c00::f03c:91ff:fe6e:6894) |
| 00:11.40 | *** join/#asterisk-dev ivan` (~ivan@unaffiliated/ivan/x-000001) |
| 00:18.54 | *** join/#asterisk-dev HeN (uid3747@gateway/web/irccloud.com/session) |
| 00:20.07 | *** join/#asterisk-dev coreyfarrell (~cfarrell@71-80-124-168.dhcp.wlmn.ct.charter.com) |
| 00:25.04 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 01:00.49 | *** join/#asterisk-dev protocoldoug (~quassel@unaffiliated/protocoldoug) |
| 02:02.56 | mjordan | so, this is good. Most of the codec sdp offer/answer tests I wrote back in February for the media format work are passing |
| 02:03.00 | mjordan | is a little surprised |
| 03:07.06 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113d03.dyn.optonline.net) |
| 03:51.11 | coreyfarrell | mjordan: very cool! |
| 04:32.54 | mjordan | just published it. Eventually I'll have to get the tests up for review as well. There's one that doesn't pass, but it didn't pass before, and looks to be a bug in pjproject |
| 04:33.24 | mjordan | or at least, I hope it is, because I can't figure it out in res_pjsip_sdp_rtp :P |
| 04:34.36 | coreyfarrell | cool I'll take a look at some point this weekend |
| 04:35.25 | coreyfarrell | been a bit busy the past couple days working on a catalyst migration from centos5 to centos6 :( |
| 05:01.03 | mjordan | ugh |
| 05:01.51 | mjordan | there are definitely some ref leaks still. I think the next step once this is done is to do the renaming, and as part of that, do what you suggested and macro-tize the functions to map their callers down into the REF_DEBUG log |
| 05:02.49 | coreyfarrell | agreed |
| 05:03.18 | coreyfarrell | that's part of why I was suggesting we temporarily disable building of broken modules (even if they will be fixed in a week).. |
| 05:03.38 | coreyfarrell | getting better REF_DEBUG output will allow us to work on the leaks sooner |
| 05:06.22 | coreyfarrell | I know that getting a format_attr module working would help verify the API's, but at this point in the media_formats I'd prefer to start working on bug searching/fixing |
| 05:07.42 | coreyfarrell | given the temperatures we've been having I have to run AC which limits my computing power, that's the reason I was asking about getting bamboo going again so I can just go through the test logs |
| 05:11.50 | mjordan | ah |
| 05:12.12 | mjordan | Let me try and get a compile test up and running. I'm pretty sure the script will let me disable those modules. |
| 05:40.00 | coreyfarrell | mjordan: needs to be pointed to the new /team location |
| 05:41.08 | coreyfarrell | oh wait looks like you noticed that nevermind :) |
| 06:53.59 | *** join/#asterisk-dev datachomper (~russ@nat/digium/session) |
| 07:39.18 | *** join/#asterisk-dev HeN (uid3747@gateway/web/irccloud.com/x-mbdwjqulxonennym) |
| 07:40.55 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-qzihlzachovfkctc) |
| 09:59.26 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 09:59.26 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 10:03.59 | *** join/#asterisk-dev miguel3239 (~miguel323@2001:470:1f06:12c4::2) |
| 10:11.02 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:110e:b5d:7dfd:e460) |
| 10:33.16 | *** join/#asterisk-dev Tim_Toady (~fuzzy@83.212.108.130) |
| 12:32.54 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113d03.dyn.optonline.net) |
| 14:10.30 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 14:16.06 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113d03.dyn.optonline.net) |
| 15:34.37 | *** join/#asterisk-dev mjordan (~mjordan@75.76.55.191) |
| 15:34.37 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:45.54 | *** join/#asterisk-dev NirS (~NirS@5.28.148.71) |
| 15:46.01 | NirS | Morning all |
| 15:51.53 | NirS | hi all |
| 15:52.06 | NirS | any change someone accidentaly broke the endbeforehexten=yes in cdr.conf ? |
| 15:52.19 | NirS | regardless if it's yes or no, the result is identical |
| 16:06.24 | mjordan | NirS: What version of Asterisk |
| 16:11.28 | NirS | 11.9.0 |
| 16:11.30 | NirS | hey matt |
| 16:11.33 | NirS | I'll rephrase |
| 16:11.49 | NirS | the issue seems to be like this |
| 16:12.17 | NirS | Let's say I dial out on the channel, if I disconnect or there is an error - the CDR is registered after the "h" extension had been executed |
| 16:12.37 | NirS | if the channel was answered, the CDR is inserted before the "h" extension - as I would expect |
| 16:13.00 | NirS | the behavior seems a bit in-consistent - or have I got it up side down |
| 16:13.16 | NirS | or the doc is just plain confusing |
| 16:25.59 | mjordan | looks at the code |
| 16:27.46 | mjordan | so, end before h exten does not exactly control when the CDR is posted. It controls when the CDR's end time is set, and whether or not that end time includes the time it takes for the CDR to execute in the 'h' extension |
| 16:28.58 | mjordan | I will say that we have quite a bit of tests for endbeforehexten that run on 1.8/11 and those tests are humming along, so I'd be surprised if we changed the behaviour of it |
| 16:29.49 | mjordan | the actual posting of the CDR occurs separately from whether or not the end time gets updated as a result of executing the h extension logic |
| 16:45.51 | NirS | I see your point |
| 16:46.07 | NirS | the documentation seems a bit confusing to me, I understood differently |
| 16:46.30 | NirS | well, time to head on home now, I'll logon later on again, probably |
| 16:52.05 | mjordan | coreyfarrell: small amount of progress on the format leak. Pretty sure that what is causing the format to be leaked is a stray ast_format_cap. |
| 16:52.19 | mjordan | coreyfarrell: here's an open question with the ref debugging things however |
| 16:53.10 | mjordan | Generally, for common allocation/ref bump routines, such as ast_format_cap_alloc or ast_format_cache_get, is not the name of the routine but who called it |
| 16:53.26 | mjordan | we can get who called it by macro-ing it, and passing the FILE/FUNC/LINE macros down into the ao2 routines themselves |
| 16:53.44 | mjordan | the small problem with this is that you do, unfortunately, lose the name of the function that is pushing the data down. |
| 16:54.01 | mjordan | So now we have the caller of, say, ast_format_cache_get, but not that the function that was called *was* ast_format_cache_get |
| 16:55.08 | mjordan | one way we could work around that would be to use the tag field in the debug versions to say either: (a) the name of the function that was called, or (b) undo the proposed changes and use the tag field instead as a way to indicate which function called this one |
| 16:56.07 | mjordan | I'm leaning towards option (a), as it loses the least amount of information. Generally you want to know who and where called a common ref bumping routine, and you just need the name of the routine they called that did the ref bumping |
| 16:56.21 | mjordan | ast_format_cap_alloc is not going to be the entity that leaks the memory, it will be the caller |
| 17:07.35 | mjordan | and I found one major leak of ast_format_cap_alloc - line 818 of channel.c, __ast_channel_alloc_ap - ast_channel_native_formats_set bumps the ref count on the capabilities structure. The creation ref has to be decremented after that call. |
| 17:32.35 | file | falls into existence |
| 17:38.22 | mjordan | welcome file |
| 17:38.42 | mjordan | we may have a *few* leaks :-) |
| 17:38.52 | file | to the restaurant at the end of the universe? |
| 17:40.43 | mjordan | indeed |
| 17:41.08 | mjordan | wishes pjsip unloaded |
| 18:05.56 | file | how many times can we win and lose, how many times can we break the rules |
| 18:24.37 | mjordan | 2. |
| 18:25.06 | mjordan | and after disabling a bunch of stuff - https://bamboo.asterisk.org/bamboo/browse/ATB-MRB-25 |
| 18:25.48 | mjordan | alas, test_format_api is a bit ... broken. |
| 18:36.22 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-pieqzutlvsqghptd) |
| 19:03.02 | mjordan | coreyfarrell: And I think I'm running into the problem you did - statically defined frames holding onto a reference to an ao2 object. |
| 19:03.09 | mjordan | takes a break |
| 19:29.40 | coreyfarrell | mjordan: I'm more interested in knowing that channel.c / set_format() / line 5257 added a reference, so tagging with ast_format_cap_add seems right to me. |
| 19:31.53 | coreyfarrell | mjordan: what you were saying about pjsip unload is why I was starting my testing with chan_sip. I know it's old and ugly code, but it does unload cleanly. well it did in 11, the big point being that it did unload cleanly at one point. |
| 19:38.15 | *** join/#asterisk-dev TazzNZ (~pieter@office-nat1.ytechops.co.nz) |
| 19:46.34 | coreyfarrell | mjordan: I just emailed you a patch that I was working on a while ago for test_format_api. this is before I got rid of ast_format_copy, but is much closer to compiling than what's currently in the repo |
| 19:46.48 | coreyfarrell | I'm out for a bit.. talk to you later if you're online |
| 20:21.12 | coreyfarrell | mjordan: are you going to reschedule bamboo to do the unit tests without test_format_api? I know that would be a nice one to have but everything would be nice too :) |
| 20:24.34 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113d03.dyn.optonline.net) |
| 20:26.00 | *** join/#asterisk-dev TazzNZ (~pieter@office-nat1.ytechops.co.nz) |
| 20:26.41 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 20:27.00 | *** join/#asterisk-dev drmessano^ (~nonya@pdpc/supporter/active/drmessano) |
| 20:32.51 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 20:33.50 | *** join/#asterisk-dev russellb (~russellb@redhat/russellb) |
| 20:33.50 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 21:14.13 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 21:14.13 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:46.20 | *** join/#asterisk-dev snuff-work (~snuffy@203.63.71.233) |
| 22:46.20 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:05.26 | *** join/#asterisk-dev snuff-work (~snuffy@203.63.71.233) |
| 23:05.26 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |