| 00:03.18 | mjordan | coreyfarrell: sorry about that, the correct posting should now be up |
| 00:04.33 | coreyfarrell | thanks.. unfortunately not tonight but I will look at rtp_engine.c soon |
| 00:40.02 | *** join/#asterisk-dev sgriepentrog (~sgriepent@173.209.212.146) |
| 02:00.25 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 03:55.52 | *** join/#asterisk-dev ivan` (~ivan@unaffiliated/ivan/x-000001) |
| 04:22.51 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 04:22.51 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 04:22.51 | *** join/#asterisk-dev coreyfarrell (~cfarrell@71-80-124-168.dhcp.wlmn.ct.charter.com) |
| 04:22.51 | *** join/#asterisk-dev seanbright (~sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 04:22.51 | *** mode/#asterisk-dev [+oo tzafrir seanbright] by wilhelm.freenode.net |
| 04:27.42 | *** join/#asterisk-dev tonyclewis (sid6025@gateway/web/irccloud.com/x-ndewrkjihzdjhqim) |
| 05:44.03 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 06:41.03 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:41.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:41.25 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:6160:a32a:4d3a:a6fc) |
| 06:41.31 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 06:41.31 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:21.55 | *** join/#asterisk-dev tgu (~tgu@host-212-68-194-46.brutele.be) |
| 07:46.05 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 07:46.05 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:50.26 | oej | Morning folks |
| 08:49.39 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 08:51.07 | Stefan27 | is it ok for an asterisk/C-newbie to ask questions here? Im trying to make some custom changes to chan_sip.c for our company among other things... what does pvt mean in sip_pvt? couldnt make full sense of http://doxygen.asterisk.org/1.4/structsip__pvt.html |
| 09:24.03 | wdoekes | I believe it's "private", the (sip-)technology private data of the channel |
| 11:05.09 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 11:30.24 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113d03.dyn.optonline.net) |
| 11:42.32 | seanbright | we should deprecate chan_iax2 as well... who's with me?! |
| 11:49.06 | Tim_Toady | o/ |
| 11:49.10 | Tim_Toady | :P |
| 12:00.44 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:09.45 | oej | stefan27: Yes this is the right channel for that kind of questions. |
| 12:34.32 | *** join/#asterisk-dev Marquis42 (~mrbmw@d149-67-95-208.try.wideopenwest.com) |
| 12:41.49 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 12:41.49 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:45.17 | *** join/#asterisk-dev Dovid (~Dovid@ool-2f113d03.dyn.optonline.net) |
| 12:54.25 | *** join/#asterisk-dev stevePearPear (~stevePear@cm244.epsilon47.maxonline.com.sg) |
| 13:19.44 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-30-203.user.veloxzone.com.br) |
| 13:43.25 | *** join/#asterisk-dev jameswf (uid27319@gateway/web/irccloud.com/x-vhpgydvexexfnifc) |
| 13:46.08 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-smpntbvthkcfbdmy) |
| 13:49.17 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-xyjxwhpvlzwviwif) |
| 13:49.17 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:52.04 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 13:55.05 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:55.05 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:58.53 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 14:05.27 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-ypfkfqmcqvpsdstz) |
| 14:05.27 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:08.28 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:08.28 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:16.49 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-edvwyihqywveaout) |
| 14:22.05 | *** join/#asterisk-dev michael_work (~michael@bzq-82-168-31-134.red.bezeqint.net) |
| 14:36.39 | mjordan | Qwell: what are you up to for lunch today? |
| 14:36.53 | file | IT'S A TRAP |
| 14:37.35 | Qwell | mjordan: unknown |
| 14:43.54 | mjordan | Qwell: taco truck? |
| 14:44.13 | Qwell | possibly - will have to see if I have a car later |
| 14:51.07 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-yxspxxhqumzjgblu) |
| 15:04.42 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:04.42 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:08.06 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 15:09.28 | Qwell | mjordan: it'll have to be another day ;/ |
| 15:11.34 | *** part/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 15:25.54 | mjordan | np |
| 15:56.04 | putnopvut | Hm, I'm not sure if the rest of you are doing as experimental code as I have been lately, but I've been encountering crashes during development testing. So I turned on "DONT_OPTIMIZE" in menuselect. Unfortunately, I'm still seeing "<value optimized out>" in my backtraces, making it difficult to debug. Is DONT_OPTIMIZE known to have any issues at the moment? |
| 15:57.39 | putnopvut | As an example, this is what is output during a noisy build when making app_authenticate.so from app_authenticate.c: http://ur1.ca/hn9r4 |
| 15:58.07 | putnopvut | I chose app_authenticate at random. My testing has nothing to do with it. I just figured it worked as an example of a module being built. |
| 15:58.12 | mjordan | putnopvut: not that I know of, but I ran into something similar last night. Turns out I was corrupting the stack on a thread, which valgrind caught for me, but I couldn't get that thread to have symbols no matter what. It was an odd corner case however |
| 15:59.18 | putnopvut | Here's my bt: http://ur1.ca/hn9ra . It probably won't be too helpful since it references changes in my working copy. However, you can see all the "<value optimized out>" messages in it. |
| 15:59.55 | putnopvut | Anyway, I should be able to figure this problem out without much issue, but I figured the DONT_OPTIMIZE behavior was worth mentioning in here. |
| 16:02.04 | mjordan | yeah, not sure |
| 16:02.37 | file | odd... |
| 16:06.02 | file | lunchy lunch |
| 16:11.58 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:11.58 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:48.28 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:54.49 | mjordan | putnopvut: ping |
| 16:55.12 | putnopvut | mjordan: pong |
| 17:15.44 | coreyfarrell | mjordan: sorry my latest review is against one revision back, but I already started it and you didn't change rtp_engine.c anyhow |
| 17:39.20 | mjordan | np |
| 17:39.28 | mjordan | putnopvut: heh, sorry, got distracted |
| 17:39.36 | mjordan | putnopvut: was wondering if the NOTIFY work on RLS could be kicked off |
| 17:39.45 | mjordan | not by you necessarily :-) |
| 17:39.55 | mjordan | or if it's better to wait until the inbound subscription stuff is done |
| 17:40.51 | putnopvut | Two things: 1) I'd rather do it myself since, as is usually the case, no matter how well I think I've prepared in advance, when it comes time to code, I find mistakes in the plan or come up with something better. 2) It would probably do well to have the inbound subscription stuff done. |
| 17:41.13 | putnopvut | Part of the inbound subscription stuff is adding XXX comments in the code where NOTIFY-related changes need to be made. |
| 17:47.10 | mjordan | works for me |
| 17:48.19 | putnopvut | Thanks |
| 17:48.32 | putnopvut | Dealing with an annoying crash in subscription unit tests :-/ |
| 17:49.22 | file | Triple X! |
| 17:51.59 | putnopvut | file: Let's say I've retrieved an object from sorcery. If I call ast_sorcery_delete() on the object, do I also need to call ao2_ref(obj, -1) on the object, or does the ast_sorcery_delete() steal and decrement my reference? |
| 17:52.09 | file | it does not steal it |
| 17:52.26 | putnopvut | hm, okay |
| 17:55.00 | putnopvut | My refcounts are off for a sorcery object of mine, and I thought that might be the issue. |
| 17:55.09 | putnopvut | enables REF_DEBUG and goes back at it. |
| 17:55.12 | file | where's the object coming from? |
| 17:56.14 | putnopvut | I'm ast_sorcery_alloc'ing it and then ast_sorcery_create'ing it in my test. I figure that requires me to then ast_sorcery_delete and ao2_cleanup() the object at the end of the test. |
| 17:56.25 | putnopvut | The sorcery backend is res_sorcery_memory. |
| 17:56.47 | file | yup |
| 17:57.05 | file | the alloc should have it at 1, the create will bump it to 2, the delete will dec it to 1, the cleanup should dec it to 0 and destroy |
| 17:57.07 | putnopvut | It looks like I'm decrementing the refcount one time too many. |
| 17:57.23 | putnopvut | Yeah, I'm also doing some ast_sorcery_retrieve_by_id() calls in there. |
| 17:57.28 | file | you don't have it in a RAII_VAR and are calling ao2_cleanup twice? |
| 17:58.08 | putnopvut | I'm using RAII_VAR, but the dtor function is a custom function that calls ast_sorcery_delete() and ao2_cleanup() on the object. I'll double check to be sure I'm not cleaning it up somewhere else in the test too. |
| 17:59.20 | putnopvut | Yeah, not doing an extra ao2_cleanup() in the test itself. It's probably somewhere in an API call or something. |
| 18:02.48 | putnopvut | Hopefully REF_DEBUG will elucidate the issue. |
| 18:03.22 | coreyfarrell | putnopvut: look carefully at the last two lines of REF_DEBUG output for stasis object leaks. I've seen where the last two ao2_cleanup cause the ref_log to say you are decrementing from 2 twice in a row |
| 18:03.49 | putnopvut | coreyfarrell: okay, will do. Thanks for the tip |
| 18:04.28 | putnopvut | Still waiting for compilation to finish, for the moment though. |
| 18:05.24 | mjordan | Nice usage of the word "elucidate" |
| 18:07.21 | putnopvut | ugh, /tmp/refs is empty after running Asterisk. |
| 18:07.31 | mjordan | putnopvut: good news! |
| 18:07.34 | putnopvut | Actually it doesn't exist. |
| 18:07.35 | mjordan | check /var/log/asterisk |
| 18:07.39 | putnopvut | will do |
| 18:21.31 | putnopvut | Hm, the object I care about doesn't seem to be present in the ref log at all >_< |
| 18:22.06 | putnopvut | Well, at least with the -n option specified. |
| 18:23.03 | putnopvut | Ah, it's here without -n specified. Probably because the unref that "skews" the object crashes Asterisk before it's logged. |
| 18:26.15 | coreyfarrell | putnopvut: do you have all the latest commits to 12/trunk (r417509 from 12 for example) |
| 18:27.37 | putnopvut | I'm in my working branch, at 417706 |
| 18:27.45 | putnopvut | So should have those changes. |
| 18:28.52 | coreyfarrell | DO_CRASH enabled? I think ast_assert is called for invalid ao2 object's before REF_DEBUG code |
| 18:30.40 | putnopvut | No, I don't have DO_CRASH enabled. |
| 18:30.50 | mjordan | is a fan of DO_CRASH |
| 18:30.57 | mjordan | but not THREAD_DO_CRASH |
| 18:31.02 | mjordan | (it's a bit trigger happy) |
| 18:31.32 | file | crashes into a thread |
| 18:32.42 | putnopvut | Noticed I had an automerge conflict. Resolving that and updating, then will enable DO_CRASH and see what I can find. |
| 18:32.59 | coreyfarrell | putnopvut: double-check that you have the commit I mentioned, it's from 4 days ago |
| 18:33.41 | putnopvut | coreyfarrell: yep, got it. |
| 18:54.34 | putnopvut | btw, I solved my issue. The reason that I was having trouble finding where the refcounting error was is that...there was no refcounting error! |
| 18:54.58 | putnopvut | I was trying to free a non-allocated pointer in my object destructor. |
| 18:55.12 | file | yay |
| 19:00.14 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-sycqcruoxabynhvj) |
| 19:21.12 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 19:43.06 | mjordan | anyone against throwing menuselect into Asterisk trunk? |
| 19:43.36 | jsmith | mjordan: Make it so! |
| 19:43.55 | file | as long as it does not cause a nuclear reactor overload |
| 19:44.02 | jsmith | mjordan: I honestly don't think it even needs a discussion... |
| 19:44.31 | mjordan | heh |
| 19:44.39 | mjordan | might mean we need to do something about mxml unfortunately |
| 19:45.45 | jsmith | mjordan: I have no qualms about making it another dependency |
| 19:46.14 | mjordan | true. I see debian has it, redhat I wouldn't worry about. I suppose we could keep our svn repo of it (ew) for the short term in case someone needed it. |
| 19:46.48 | coreyfarrell | mjordan: will be nice to not have to wait for 'svn status' to check 3 repositories.. not as nice as GIT, but baby steps are still good |
| 19:46.54 | mjordan | well |
| 19:47.05 | mjordan | if we get rid of all of the svn externals, then there's definitely a shorter step towards git |
| 19:49.25 | jsmith | mjordan: Fedora has it :-) |
| 19:50.35 | coreyfarrell | if fedora has it then that solves the problem of building a package for centos/rhel |
| 19:50.54 | mjordan | nifty |
| 19:51.05 | coreyfarrell | mjordan: also you have to keep the svn repo of it longer term.. until 1.8/11/12 are end of life |
| 19:51.11 | mjordan | yeah |
| 19:51.17 | mjordan | it isn't going away any time soon, but it moves us closer. |
| 19:56.39 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 19:56.39 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:14.39 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 20:56.34 | *** join/#asterisk-dev danjenkins_ (~dan@cpc11-folk2-2-0-cust171.1-2.cable.virginm.net) |
| 21:01.55 | *** join/#asterisk-dev TazzNZ (~TazzNZ@office-nat1.ytechops.co.nz) |
| 21:15.36 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-255-171-52.mci.googlefiber.net) |
| 21:16.09 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:31.17 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 21:31.18 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 22:15.29 | file | mjordan, I have a... problem. |
| 22:16.42 | file | if the format interface callbacks which modify attributes return a new format I then need to make sure that new format is reflected throughout the consumer (capabilities, RTP engine, etc) - but we currently have no way to really replace (in position) a format in a caps structure |
| 22:19.18 | file | your RTP engines will impact this |
| 22:22.16 | mjordan | yeah |
| 22:22.18 | mjordan | phooey. |
| 22:22.28 | mjordan | I don't think we can store attributes on the format then. |
| 22:22.32 | mjordan | Formats have to be immutable |
| 22:23.41 | mjordan | How often do we create formats though? Generally, it should only happen when we parse an SDP |
| 22:23.53 | file | yes |
| 22:23.58 | mjordan | so, two channel drivers? |
| 22:24.00 | file | pretty much outside input |
| 22:24.09 | file | yes |
| 22:24.13 | mjordan | that's not terrible then. |
| 22:24.26 | mjordan | Really, when you get a new format back from attribute creation, you have to go update your RTP instance with it |
| 22:24.46 | mjordan | there should be a callback that will give you the payload type back given a specific format |
| 22:24.52 | mjordan | which you could then ao2_replace it out |
| 22:25.14 | mjordan | it's a bit clunky, but we've got a lot of 'sharing' that happens, and I'm not sure how to solve that without tearing everything up yet again :-) |
| 22:25.55 | file | does your RTP engine changes make it easy to update? cause I'm not sure how ao2_replace would help with that... |
| 22:26.44 | mjordan | looks |
| 22:26.49 | mjordan | I vaguely recall a function |
| 22:27.41 | mjordan | not quite |
| 22:27.43 | mjordan | I was thinking of ast_rtp_codecs_payload_code |
| 22:27.46 | mjordan | which is very similar |
| 22:27.58 | file | yeah |
| 22:28.06 | mjordan | you could write an analogous function that returns back a ref bumped version of the ast_rtp_payload_type object |
| 22:28.14 | mjordan | er |
| 22:28.15 | mjordan | well |
| 22:28.34 | mjordan | it'd be a bit sneaky, but you could ao2_replace out the format on the payload type object |
| 22:28.38 | mjordan | generally payload type objects are immutable as well |
| 22:28.40 | mjordan | HOWEVER |
| 22:28.45 | mjordan | we aren't really changing the format on it |
| 22:28.53 | mjordan | just replacing it with the same format with some attributes |
| 22:28.57 | mjordan | the RTP engine itself won't care about that |
| 22:29.20 | mjordan | the only thing that will care is when we go to generate the SDP and/or pass the attributes over on the outbound call, but that wont' happen at the same time as the update |
| 22:29.23 | mjordan | so you could safely get away with that |
| 22:29.51 | mjordan | the other option would be to have another rtp_codecs 'update' that locks rtp_codecs, makes a new instance of ast_rtp_payload_type, puts the new format on there, and updates the whole thing |
| 22:29.53 | mjordan | that would be 'safer' |
| 22:29.59 | file | yeah |
| 22:30.01 | mjordan | but probably isn't strictly necessary |
| 22:30.13 | mjordan | do you know the payload code when you generate the attributes? |
| 22:30.16 | mjordan | If so, it's a pretty fast operation |
| 22:30.22 | mjordan | otherwise, looking up by format is definitely slower |
| 22:30.31 | mjordan | but given how few formats have attributes that require this, it isn't generally a problem |
| 22:30.35 | file | uhhhh |
| 22:30.55 | file | yes. |
| 22:31.12 | mjordan | celt, h263, h254, opus, vp8 (?), silk, speex (?) |
| 22:31.24 | mjordan | er, h264 |
| 22:31.31 | mjordan | so really, other than Opus, meh. And ... Opus is Opus. |
| 22:32.37 | mjordan | have to bounce out. The other option would be to store attributes elsewhere, but I'm not sure where. |
| 22:32.49 | file | they really do belong with the format |
| 22:33.06 | mjordan | then make a new one it is :-\ |
| 22:42.38 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-smpntbvthkcfbdmy) |
| 22:53.54 | *** join/#asterisk-dev snuff-work (~snuffy@203.63.71.233) |
| 22:53.55 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 23:14.05 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 23:14.40 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |