| 00:40.54 | *** join/#asterisk-dev ipengineer (~zconkle@108.206.120.218) |
| 00:50.39 | rmudgett | mjordan: The media_format sig_pri.c compile error is actually a type mismatch that is also in v1.8+ |
| 00:51.51 | mjordan | ha |
| 00:51.56 | mjordan | why didn't it get flagged there? |
| 00:53.21 | rmudgett | Because enums are not flagged by the compiler and implicitly get converted to ints. |
| 00:53.55 | rmudgett | The media stuff removed the define that was being used. |
| 00:54.36 | rmudgett | AST_FORMAT_ULAW != SIG_PRI_ULAW |
| 01:06.23 | opticron | coreyfarrell, looks like a combination of that and moving the conditional format unref behind the AST_MALLOCD_HDR conditional fixed it, currently checking for leaks |
| 01:14.09 | *** join/#asterisk-dev ipengineer (~zconkle@108.206.120.218) |
| 02:04.41 | coreyfarrell | opticron: we may need to also create an AST_MALLOCD_FMT and unref for that or AST_MALLOCD_HDR |
| 02:06.47 | coreyfarrell | opticron: the thing is with the ao2_replace I suspect you will eventually find a segfault |
| 02:16.31 | opticron | I'm currently unreffing behind both AST_MALLOCD_HDR tests and Playback() seems to be what's causing the current ref leak I'm looking at |
| 02:17.03 | opticron | and if frame dup/free was causing a leak, I hope I'd see it... |
| 02:17.49 | opticron | all the *_sample calls seem to be leaking |
| 02:17.52 | opticron | for each codec |
| 02:18.17 | coreyfarrell | one thing I just realized, ao2_replace == ao2_cleanup if it's behind AST_MALLOCD_HDR conditional |
| 02:19.13 | opticron | I was also toying with skipping the ao2_replace entirely if the two pointers are the same to save spam in the ref logs |
| 02:20.12 | coreyfarrell | I was suggesting ao2_replace for __frame_free, to ensure that if it's run against a static frame then fr->subclass.format will be NULL'ed, cause a crash next time around |
| 02:20.50 | opticron | yeah, I ran into that fast |
| 02:20.55 | coreyfarrell | currently if ast_frfree is run against a static frame the format is unref'ed but not NULL'ed |
| 02:21.32 | coreyfarrell | and if ast_frfree is run once against a static frame, you can be sure it will be run more times, eventually causing the format to be freed |
| 02:23.34 | coreyfarrell | I wish ast_frame was an ao2, but that would be too big of a change at this stage (especially with the unknown performance impact) |
| 02:49.34 | Corydon76-home | Anybody of the Digium people happen to know if res_fax_digium.so is supposed to pay attention to any of the values in res_fax.conf or not? |
| 03:39.13 | Corydon76-home | Actually, never mind. I just made it work. |
| 03:41.58 | Corydon76-home | I had to reduce maxdelay=500 though |
| 06:11.52 | *** join/#asterisk-dev oej (~Adium@h87-96-134-129.dynamic.se.alltele.net) |
| 06:11.52 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:31.26 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:15b2:bfa2:fdeb:a694) |
| 06:33.11 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 06:45.58 | *** join/#asterisk-dev stevePearPear (~stevePear@183.90.37.218) |
| 06:59.01 | *** join/#asterisk-dev stevePearPear (~stevePear@183.90.37.218) |
| 07:02.48 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:02.48 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:29.55 | *** join/#asterisk-dev tgu (~tgu@212.68.194.46) |
| 07:43.22 | *** join/#asterisk-dev stevePearPear (~stevePear@180.255.248.3) |
| 08:37.26 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:6:f80:224:acbf:d145:ab95:9423) |
| 09:03.23 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 09:09.53 | *** join/#asterisk-dev stevePearPear (~stevePear@180.255.248.3) |
| 09:11.00 | *** join/#asterisk-dev Qwell (north@pdpc/sponsor/digium/Qwell) |
| 09:11.00 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 09:13.37 | *** join/#asterisk-dev spditner (~simon@76-10-182-232.dsl.teksavvy.com) |
| 09:13.55 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 09:14.50 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 09:46.21 | *** join/#asterisk-dev Stefan27 (~Stefan27@212.247.4.149) |
| 12:02.49 | *** join/#asterisk-dev HeN (uid3747@gateway/web/irccloud.com/x-abwljxwmrasgivvg) |
| 13:01.01 | *** join/#asterisk-dev skrusty (~skrusty@168.63.14.171) |
| 13:04.11 | *** join/#asterisk-dev ivan` (~ivan@unaffiliated/ivan/x-000001) |
| 13:39.12 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 13:39.12 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:54.13 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-jukmulrxxnaicrfx) |
| 13:54.13 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 13:57.50 | *** part/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 13:59.11 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-yswezjssncpntlbd) |
| 13:59.29 | *** join/#asterisk-dev vassilux (~vassilux@LMontsouris-656-01-80-156.w82-127.abo.wanadoo.fr) |
| 14:04.19 | vassilux | I wand to get ISDN callref from ast_channel. The field const struct ast_channel_tech *tech from ast_channel can be good for this ? |
| 14:05.06 | *** join/#asterisk-dev tparcina (~tomo@212.92.200.41) |
| 14:05.37 | tparcina | I'm trying to insall asterisk 11 from asterisk-11 repository. |
| 14:06.04 | tparcina | And the package says that it depends on dahdi. |
| 14:06.22 | tparcina | Is it u bug, or it should be like that? |
| 14:08.35 | opticron | tparcina, which ever package you are using to install Asterisk 11 probably includes chan_dahdi which would cause the package to depend on DAHDI. These types of questions are better asked on #asterisk-users |
| 14:09.15 | tparcina | opticron: Thank you. |
| 14:09.38 | tparcina | I have asked there, but I didn't get any good answer. |
| 14:10.30 | mjordan | vassilux: no, the ast_channel_tech has nothing to do with a particular run time value. |
| 14:10.38 | tparcina | This seams like unnecessary dependency. |
| 14:17.06 | vassilux | ok thank. Is there a way to get callref ? Sorry I try to understand and write something like alarmreceiver. |
| 14:17.45 | mjordan | vassilux: callref is a little vague. Which specific variable from which channel driver are you attempting to retrieve? On what struct is it stored? |
| 14:18.00 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 14:21.42 | WIMPy | Where is the link to "like alarmreceiver"? |
| 14:22.46 | vassilux | When pri debug is activate I can see reference on the log like this : Making new call for cref 165, where 165 is callref. |
| 14:23.34 | WIMPy | You are aware, that you need the direction to make the callref unique? |
| 14:24.12 | mjordan | that's still not answering my question either :-) If you are attempting to modify the source, you need to understand the portions that you want to interact with - particularly if you want to expose them in different parts of the application |
| 14:24.14 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:24.14 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:25.13 | vassilux | Yes. It is jsut forst time :-) and I want understand how it works :-). Sorry guys. Very newbie questions. |
| 14:25.47 | vassilux | I talk about app_alarmreceiver.c |
| 14:27.47 | vassilux | Yes mjordan. I try do it |
| 14:28.03 | WIMPy | Where is the link between that app and the callref? What are you trying to do? |
| 14:37.18 | vassilux | Ok. I try to interface an external system with the alarmreceiver application. When a new call coming I have to notify the external system(by UDP socket) than a new call coming and the external system provide the protocol to use. It sure is that at the moment there only contactid protocol. |
| 14:37.49 | vassilux | but I try to understand how it works |
| 14:40.48 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-ycrkdalseimhiovq) |
| 14:40.48 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:45.53 | *** join/#asterisk-dev otherwiseguy (~otherwise@nat/cisco/x-onxwozsxypqbytyt) |
| 14:51.05 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 15:02.59 | coreyfarrell | mjordan: about the latest review, how will we avoid ast_format_cap_get_format(p->reqcap, 0) == ast_format_none? I mean in situations where other formats were added to the cap we don't want none. |
| 15:16.13 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-zpscpqrlrndombbj) |
| 15:23.08 | *** join/#asterisk-dev SGjunior (~sgjunior@96.127.222.20) |
| 15:24.52 | *** join/#asterisk-dev SGjunior (~sgjunior@96.127.222.20) |
| 15:25.44 | mjordan | I think we have two choices. |
| 15:26.06 | mjordan | We either NULL check things, or we allow none to come out of a capabilities structure. |
| 15:26.33 | mjordan | A lot of the NULL checks I just removed were put in there because a channel's native capabilities structure had no formats in it |
| 15:27.28 | mjordan | If none does come out of a capabilities structure, generally, I don't think it is going to be terribly harmful. It doesn't have a mapping in an RTP codec, so it can't be represented in an offer/answer |
| 15:28.07 | mjordan | Generally, channel drivers are explicit about what they want their preferred codec to be, and replace and/or set up the capabilities on a channel explicitly based on the configuration. So the 'none' capability should not persist for channels. |
| 15:28.22 | coreyfarrell | what if we have ast_format_cap procedures that return ast_format NULL-check the result? so it would never actually get added it but gets returned from an empty format_cap |
| 15:28.40 | coreyfarrell | oh so most channel drivers will clear the channel cap before adding the "real" ones? |
| 15:29.22 | mjordan | that or they copy the formats over |
| 15:29.37 | opticron | pushed my fixes up to https://reviewboard.asterisk.org/r/3736/ |
| 15:29.39 | mjordan | and ast_format_cap_copy removes the formats from the dst |
| 15:30.06 | mjordan | coreyfarrell: take a look at chan_sip's sip_new routine, roughly line 8121 |
| 15:30.15 | mjordan | where it sets up the native formats |
| 15:30.42 | mjordan | that ast_format_cap_copy blows away the existing native formats on the channel, which - since it just came out of alloc - has the ast_format_none in it |
| 15:31.18 | mjordan | the reason why all this is necessary is due to either (a) unit tests that abuse channels and their technologies, and (b) strange corner cases that do happen in the wild where somehow, for whatever reason, a channel ends up with no formats (we've seen those bug reports) |
| 15:31.44 | mjordan | if somehow a channel ends up with no formats, freaking out and warning like crazy is fine, but it can and will happen |
| 15:31.50 | mjordan | I'm not sure we should be crashing on that. |
| 15:32.01 | coreyfarrell | mjordan: you've addressed my concern |
| 15:32.10 | mjordan | I'm still concerned :-D |
| 15:32.25 | mjordan | I think some of this stuff with ast_format_none needs to be tested more to see if I'm right |
| 15:32.26 | coreyfarrell | I wasn't thinking about the fact that channel drivers create a new cap and replace the channel cap, instead of directly adding to the channel cap |
| 15:32.50 | mjordan | I do wonder if maybe we should - at least in the interim - assert if something is ast_format_none when we don't think it should be |
| 15:33.12 | mjordan | Ideally, no channel driver would ever let a channel end up without the capabilities that it wants the channel to have |
| 15:33.47 | mjordan | completely unrelated: the indentation in xmpp.h is a mess. Anyone mind if I push up a whitespace only fix to 11+? |
| 15:34.21 | file | nope |
| 15:34.23 | coreyfarrell | ast_assert produces no code unless DEVMODE is turned on, so I say assert away |
| 15:35.17 | mjordan | k, I'll push a few more asserts in there. I definitely want us to catch these things over the next week |
| 15:36.20 | mjordan | the trick is to assert in places that shouldn't get an ast_format_none while still letting the unit tests pass :-) |
| 15:36.52 | coreyfarrell | the unit test will pass as long as we don't have DO_CRASH? |
| 15:37.16 | mjordan | yeah, but it's nice to run with DO_CRASH on the unit tests as well. They do catch astobj2 issues |
| 15:37.16 | coreyfarrell | assert error's in the logs from passing tests should be ok |
| 15:37.25 | mjordan | it's a conundrum! |
| 15:37.53 | file | IT'S COUNTDOWN |
| 15:39.15 | jsmith | file: It's the final countdown? |
| 15:39.19 | file | jsmith, incorrect |
| 15:39.20 | jsmith | gets a tune stuck in file's head |
| 15:39.35 | file | https://en.wikipedia.org/wiki/Countdown_(game_show) |
| 15:43.09 | coreyfarrell | mjordan: I think we should add the asserts, set bamboo to run unit tests without DO_CRASH, see how many asserts it causes |
| 15:44.18 | mjordan | okay |
| 15:44.34 | mjordan | jsmith: even if it didn't work on file, it worked on me :-( |
| 15:44.43 | jsmith | mjordan: I'm sneaky like that |
| 15:45.11 | jsmith | mjordan: The worst is if you sing the lyrics to "Amazing Grace" to the tune of "Gilligan's Island" -- that'll never get out of your head, once you find how well it fits |
| 15:45.16 | file | MIND CONTROL |
| 15:45.33 | mjordan | NOOOO |
| 15:45.35 | jsmith | ... "Was lost but now I'm found.... was lost but now I'm found" |
| 15:45.38 | opticron | BRAIN CONTROL |
| 15:46.04 | file | I don't remember Amazing Grace or the tune of Gilligan's Island, so I'm safe |
| 15:46.07 | coreyfarrell | mjordan: might want to tweak main/test.c to ast_log the start/end of tests (it currently uses ast_cli for output). this will make it easier to see where asserts come from |
| 15:46.25 | jsmith | mjordan: Sorry to hit you with a stray bullet there -- I've been trained by my friends in other channels to implant earworms quite effectively |
| 15:47.28 | file | imagines mjordan going all Matrix and dodging it |
| 15:47.32 | mjordan | coreyfarrell: the way the script runs it in bamboo is as a remote execution, so we get the CLI output in the log |
| 15:47.47 | mjordan | hm. |
| 15:48.06 | mjordan | I *think* that will get an assert, since those get dumped out to the default CLI output as well (due to them being ERRORs) |
| 16:07.18 | mjordan | heh. Frack-alicious |
| 16:13.03 | jrose_atDigium | Hmmmm, I think there is a problem with ast_codec_pref_append in the media branch. It keeps removing the old orders with each pass through it while building the codec list via ast_codec_pref_remove. |
| 16:13.26 | jrose_atDigium | I'll see if I can't whip up a quick patch for it. It might not just affect chan_iax2 though. |
| 16:13.49 | file | I think it's only used in chan_iax2. |
| 16:14.06 | mjordan | yeah, most things avoid format_compatibility like the plague. |
| 16:14.26 | mjordan | and it is another method that can be moved to chan_iax2! |
| 16:14.51 | jrose_atDigium | hmmmmm |
| 16:16.25 | mjordan | opticron: coreyfarrell: I think we need to decide if statically allocated frames should be holding a reference to a format |
| 16:17.56 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 16:59.51 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-toiqprdwixnmswgk) |
| 16:59.51 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 17:01.17 | coreyfarrell | mjordan: opticron: I'm inclined to think that statically allocated frames (fr->mallocd == 0) should either not hold a reference to format, or the reference should be cleaned by the unit that owns the static frame |
| 17:02.06 | mjordan | I'm worried about setting a precedent where some frames bump a reference and some don't |
| 17:02.37 | mjordan | The only "good thing" is that frames in the cache generally can't go away... so it probably is okay to not bump the ref count. |
| 17:02.38 | mjordan | Hrm. |
| 17:02.51 | coreyfarrell | personally I dislike the whole idea of static frames |
| 17:03.02 | mjordan | those probably can't go away in a week |
| 17:03.24 | coreyfarrell | agreed. for asterisk 14 I'd like to look into switching frames to ao2 |
| 17:07.29 | mjordan | opticron: for now, are you going to keep hunting down the crash caused by the frames? |
| 17:07.54 | mjordan | opticron: and btw, thanks, your patch fixed local channels doing a playback (which then crashes, but hey, at least it got the right file format) |
| 17:10.48 | mjordan | opticron: btw, in the crash I'm seeing there, we're free'ing the same frame twice |
| 17:11.57 | opticron | ew |
| 17:12.23 | opticron | I have not seen a double frame free |
| 17:12.35 | mjordan | yup, that is what is happening :-) If you set format->subclass.format = NULL in __frame_free after the cleanup, you'll crash quickly due to getting a null format |
| 17:12.45 | mjordan | someone is abusing the frame! |
| 17:14.43 | opticron | the only thing I've seen so far is the format shenaniganry where the frame's format's refcount goes below 0 and I have all the assert crash stuff turned on, so I don't see beyond that |
| 17:18.04 | coreyfarrell | would it be helpful to add an assert to __frame_free before or after the format cleanup? IE ao2_cleanup(fr->subclass.format); ast_assert(fr->mallocd); |
| 17:19.42 | mjordan | well, if static frames are supposed to bump the ref count, then fr->mallocd doesn't have to be true |
| 17:19.53 | mjordan | static frames can also be free'd |
| 17:20.14 | mjordan | pretty sure I know what is doing it. The question comes back to, again, whether or not we want statically allocated frames to alter the ref count of formats. |
| 17:20.19 | mjordan | file: you have any thoughts on that? |
| 17:21.07 | coreyfarrell | mjordan: the other question is if static frames hold refs to format, who is responsible for unref'ing? should it be __frame_free or the unit that added the ref to the static frame.. |
| 17:21.22 | file | mjordan, I'm torn |
| 17:21.49 | mjordan | generally, static frames are still supposed to be free'd. |
| 17:21.56 | mjordan | (usually, they are) |
| 17:22.06 | mjordan | but I agree, it's problematic for certain modules. |
| 17:22.49 | file | I wouldn't say usually... there's still a lot that doesn't |
| 17:23.19 | mjordan | and yup, I was right. file.c's read_frame, which typically uses a static frame stored on the filestream, which is returned each time by the format modules so that they don't have to allocate a frame each time... |
| 17:23.33 | mjordan | and it gets free'd on each read. |
| 17:23.41 | mjordan | so! Decision time :-) |
| 17:23.48 | pabelanger | sell |
| 17:25.22 | file | I think the simplest way is to always bump up, and always require an ast_format_free regardless - it's easiest to explain when talking about this stuff and there's no "EXCEPT" |
| 17:25.43 | mjordan | except that there are some static frames that are really hard to free. |
| 17:26.05 | file | that just proves the point! right? RIGHT? |
| 17:26.34 | mjordan | well, except that if the static frames bump up the ref count, and are hard to free, then you have a memory leak |
| 17:27.05 | mjordan | if they instead are viewed as 'short lived, and you better dup them if want them to stick around', then there's less of a concern of a memory leak |
| 17:27.13 | mjordan | for example, the frames in the header files (ex_alaw.h) that are called by the samples are leaked like CRAZY |
| 17:27.34 | mjordan | each time they bump the ref count and in the ref debug logs I've looked at, they are free'd "sometimes" |
| 17:27.48 | mjordan | ref counts on some formats are in the + hundreds |
| 17:29.07 | file | nods |
| 17:29.11 | opticron | another ref leak fix: https://reviewboard.asterisk.org/r/3737/ |
| 17:29.53 | mjordan | I'm leaning towards not bumping the ref on static frames. If we assume that static frames are using things from the format cache, then there shouldn't be any need for them to bump the format in the first place |
| 17:29.58 | mjordan | the format cache only goes away on shutdown |
| 17:30.03 | mjordan | and the static frames are short lived. |
| 17:30.37 | mjordan | it's a mixed bag right now whether or not a static frame bumps the reference count. We're going to have to dig through them. |
| 17:30.40 | mjordan | Objections? |
| 17:30.49 | coreyfarrell | mjordan: I think having __frame_free not touch static frames would make REF_DEBUG a lot easier. |
| 17:30.49 | file | none |
| 17:31.00 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-adynhblrbnfbcrmd) |
| 17:31.15 | mjordan | k! I'll start cleaning out the frames in the codecs/formats/file area, since I'm looking at that right now |
| 17:31.55 | mjordan | opticron: sounds like your de-ref patch is back on the menu |
| 17:32.10 | opticron | hooray! |
| 17:33.21 | opticron | should I push it back up to reviewboard or do you want to incorporate it in your gathering of things in codecs/formats/file/etc. |
| 17:33.25 | opticron | ? |
| 17:37.31 | mjordan | you can go for it, I've got a lot of thing to look at |
| 17:40.29 | mjordan | ew |
| 17:40.43 | mjordan | this does mean, unfortunately, that we can't auto-bump the ref count in the format_cache |
| 17:40.54 | mjordan | that is, ast_format_cache_get_slin_by_rate shouldn't increase the ref count |
| 17:41.00 | mjordan | callers of it will have to do that if they need to |
| 17:44.08 | opticron | and that one is up here: https://reviewboard.asterisk.org/r/3738/ |
| 17:44.57 | coreyfarrell | mjordan: why no ref for ast_format_cache_get_slin_by_rate? |
| 17:45.14 | mjordan | it is used both by format comparisons and stored in various places, as well as being used directly on static frames |
| 17:45.26 | mjordan | if used on a static frame, and the ref count is bumped, it will never get de-ref'd |
| 17:45.49 | mjordan | you *could* de-ref it, but de-ref'ing something and then using it is a bad pattern to fall into |
| 17:46.33 | coreyfarrell | mjordan: you're talking about in audiohook.c? |
| 17:46.39 | mjordan | and elsewhere |
| 17:46.41 | mjordan | softmix as well. |
| 17:46.45 | mjordan | app_jack |
| 17:46.49 | mjordan | some other locations. |
| 17:48.17 | coreyfarrell | mjordan: in audiohook.c at least it looks like it already de-ref's the format on static frames |
| 17:48.22 | mjordan | it does |
| 17:48.28 | mjordan | it is not consistent |
| 17:48.51 | coreyfarrell | the way it's done in audiohook.c seems correct to me. |
| 17:48.59 | mjordan | we can't have it both ways |
| 17:49.27 | mjordan | well, we can try to, but it's going to turn into a bigger train wreck than it already is |
| 17:50.31 | mjordan | if nothing else, the "rules" for when you bump the ref count on a format is going to be very hard to get correct. |
| 17:50.31 | coreyfarrell | any unit that adds a ref to fr->subclass.format on a static fr is responsible for de-refing, I'm not sure how that's having it both ways. |
| 17:51.16 | mjordan | I'll give that a shot. I'm not sure I'm going to like any of this when it's done :-) |
| 17:53.39 | coreyfarrell | the call to ast_format_cache_get_slin_by_rate in app_mixmonitor does not go to a frame but it is leaked |
| 18:03.50 | mjordan | coreyfarrell: I'm stuck hunting down some things in app_jack, if you'd like to fix that go for it :-) |
| 18:09.42 | coreyfarrell | oops I was wrong, it is already unref'ed I just didn't see it for whatever reason |
| 18:10.17 | mjordan | rmudgett: I'm going to remove the ref bump in dahdi_read on p->subs[idx].f.subclass.format = ao2_bump(ast_channel_rawreadformat(ast)); |
| 18:10.31 | mjordan | since that is in a read callback, it will get dup'd immediately |
| 18:10.49 | rmudgett | mjordan: k |
| 18:11.17 | mjordan | and we don't dispose of the statically allocated frame on the channel pvt, which sounds like it would be annoying |
| 18:12.21 | *** part/#asterisk-dev Marquis42 (~mrbmw@d149-67-95-208.try.wideopenwest.com) |
| 18:14.14 | rmudgett | mjordan: I think chan_dahdi has pre-existing frame leaks due to inconsistencies in how it handles its static frames with duped frames. |
| 18:15.11 | *** join/#asterisk-dev Victor_Yure (~victor_yu@unaffiliated/victoryure/x-837844) |
| 18:15.29 | mjordan | if nothing else we'll be bumping ref counts less after this |
| 18:16.45 | mjordan | opticron: go ahead and commit r3738 :-) |
| 18:17.49 | opticron | just did |
| 18:18.21 | mjordan | and I can now playback monkeys to a channel without crashing. Progress! |
| 18:18.27 | opticron | hooray! |
| 18:21.01 | mjordan | first pass on static frame format ref reduction up - r3739 |
| 18:33.25 | mjordan | oh chan_phone... why must you leak on module load |
| 18:33.40 | tm1000 | file: webrtc still in review board? |
| 18:33.53 | file | nope, that got merged... last week? |
| 18:34.07 | tm1000 | file: not offically released yet though right? |
| 18:34.08 | mjordan | speaking of that... we should probably make that release. |
| 18:34.19 | mjordan | I mean, short rc timeframe |
| 18:34.58 | tm1000 | mjordan: yeah just curious what the timeframe was as I wanted to know if I should force GameGamer43 to build rpms or build from source |
| 18:35.25 | mjordan | generally, we like to wait a bit to allow the RCs to get used. But there is no set time frame for RCs. |
| 18:35.58 | mjordan | In this particular case, those RCs mostly contain the security fixes from the previous release and a few major bug fixes. |
| 18:36.13 | mjordan | I don't think there's a huge risk of regression, which is generally why we have a few weeks of RC time |
| 18:36.19 | tm1000 | mjordan: the community demands webrtcâ¦â¦ |
| 18:36.21 | tm1000 | work slave work |
| 18:36.23 | mjordan | (or a week, or a few days...) |
| 18:36.24 | tm1000 | hahahah |
| 18:36.25 | tm1000 | :-) |
| 18:36.26 | tm1000 | ok :-) |
| 18:36.41 | mjordan | well, there is that. Getting the release out would get some of the noise surrounding the WebRTC issues reduced, which is a good thing |
| 18:37.05 | mjordan | there are probably other legitimate WebRTC interop issues, but it's hard to tell if people are running with the right patches, etc. |
| 18:37.16 | tm1000 | mjordan: true, it would also help in the fact that your marketing team keeps attending webrtc conferences while webrtc doesnt work in Asterisk |
| 18:37.21 | tm1000 | hides from the strong arm of mjordan |
| 18:37.29 | mjordan | Hey, I don't control marketing |
| 18:37.32 | tm1000 | :-) |
| 18:37.49 | mjordan | And it works! Just with an older version of chrome. And not firefox. So use old chrome. |
| 18:38.09 | tm1000 | mjordan: anyways whatever happens happens. I was just seeing if I needed source or to get new rpms from a release :-) |
| 18:38.18 | rmudgett | It's not as shiny. :) |
| 18:38.22 | tm1000 | mjordan: hahah :-) |
| 18:38.27 | mjordan | anyone strongly against a 2 day RC cycle, speak now or forever hold your peace |
| 18:38.36 | mjordan | will wait a few minutes |
| 18:38.39 | rmudgett | holds mum |
| 18:38.57 | hexanol | someone knows well res_config_pgsql.c ? |
| 18:39.02 | tm1000 | is excited for a potential release today |
| 18:39.09 | hexanol | sorry to interrupt the conversation |
| 18:39.39 | hexanol | I believe I found a deadlock in it |
| 18:39.54 | mjordan | hexanol: it is an extended support module without a dedicated maintainer, so you're probably just best off asking your question |
| 18:40.11 | hexanol | well |
| 18:40.17 | hexanol | I believe it's missing |
| 18:40.37 | hexanol | an ast_mutex_lock(&pgsql_lock); |
| 18:40.44 | hexanol | in the require_pgsql function |
| 18:40.58 | hexanol | and it's actually causing a deadlock, but in a funny way |
| 18:41.25 | hexanol | i.e. the fact it's not locking it's lock before accessing the connection in find_table called from require_pgsql |
| 18:41.36 | hexanol | another thread can use the same postgres connection |
| 18:41.44 | hexanol | at the same time as the thread in require_pgsql |
| 18:42.09 | hexanol | and this is not a valid use of libpq, i.e. connection should not be used from 2 different thread at the same time |
| 18:42.27 | hexanol | and basically, what's happening, is that libpq can block in pqSocketPoll |
| 18:42.48 | hexanol | waiting for a file descriptor to have something to read |
| 18:43.02 | hexanol | which will never happens because the other thread read all the stuff from the socket |
| 18:43.50 | hexanol | so... that's it, I guess I'll open a bug on the asterisk tracker, just wanted to knew |
| 18:44.09 | hexanol | if it made sense to another person |
| 18:44.19 | mjordan | hexanol: where is it not using the lock? |
| 18:44.32 | mjordan | hexanol: I do see it using it before pgsql_exec in that function |
| 18:44.40 | hexanol | in require_pgsql |
| 18:44.44 | hexanol | require_pgsql calls find_table |
| 18:44.55 | opticron | fyi, chan_sip in the media formats branch is leaking peers which is causing all kinds of other leaks... |
| 18:45.06 | hexanol | find_table locks something before calling pgsql_exec |
| 18:45.15 | hexanol | but it is not locking the pgsql_lock |
| 18:45.17 | mjordan | find_table needs to lock before calling pgsql_exec |
| 18:45.17 | hexanol | as far as I can tell |
| 18:45.25 | mjordan | hexanol: btw, I would recommend providing a patch with your issue |
| 18:45.38 | mjordan | since res_config_pgsql is extended support, it is unlikely to get a fix unless another developer runs into your same issue |
| 18:45.56 | hexanol | ok |
| 18:49.39 | hexanol | would you recommend not using res_config_pgsql but using a module that is a "core support module" ? (like res_config_odbc) |
| 18:54.27 | mjordan | If you feel like you can support a module, or if the community is supporting a module, then you should feel free to use it |
| 18:54.37 | mjordan | There are a number of well maintained community supported modules. |
| 18:54.43 | mjordan | The folks here at Digium fix things in core supported modules. |
| 19:05.06 | sgriepentrog | opticron: atm, I'm having trouble with it crashing during a call from unref'ing the ulaw format. |
| 19:05.48 | opticron | sgriepentrog, update to latest branch, it'll hopefully be fixed |
| 19:05.58 | opticron | so fun times in chan_sip |
| 19:06.41 | opticron | peer destruction function tears down the mailboxes list, each mailbox holds a ref to the peer in a stasis subscription |
| 19:07.04 | mjordan | go go circular dependencies |
| 19:07.36 | opticron | that in turn prevents the peer's format cap structure from being destroyed which trickles down into formats leaking |
| 19:07.43 | mjordan | opticron: aren't you supposed to be working on chan_pjsip? :-P |
| 19:07.54 | opticron | everything is connected |
| 19:07.59 | mjordan | not if you don't load it |
| 19:08.12 | opticron | fair point |
| 19:08.23 | sgriepentrog | Nope. still crashes |
| 19:08.26 | opticron | who is working on chan_sip? |
| 19:08.32 | mjordan | sgriepentrog |
| 19:08.35 | opticron | ah |
| 19:08.54 | mjordan | hopes people are assigning themselves to the public issues .... ;-) |
| 19:08.57 | opticron | sgriepentrog, ^^ that'll be useful for future leak hunting when you get there |
| 19:09.39 | opticron | sgriepentrog, be prepared to resolve many crashes |
| 19:09.42 | sgriepentrog | yup. same thing. it still destroys format ulaw during the call. |
| 19:09.48 | opticron | gnarly |
| 19:09.57 | sgriepentrog | They're getting worse each time I update code ;-) |
| 19:10.01 | opticron | haha |
| 19:19.05 | *** join/#asterisk-dev terryw (~otherwise@nat/cisco/x-ihenifkddfnqliws) |
| 19:22.08 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 19:22.09 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 19:38.30 | putnopvut | So, do I go with this as my function name, or do I change it? http://ur1.ca/hq0ho |
| 19:39.43 | mjordan | lawl |
| 19:39.58 | mjordan | might be a *bit* hard to defend that |
| 19:42.44 | file | putnopvut, I'll back you on this... if you back me on something undefined in the future |
| 19:43.01 | putnopvut | that's risky |
| 19:43.16 | file | OR help me dig a hole... for... something |
| 19:43.39 | putnopvut | Also risky |
| 19:43.52 | putnopvut | reminds me of a They Might be Giants song: "Dig my Grave" |
| 19:43.53 | malcolmd | product management is gonna play a big brother veto on that one |
| 19:45.01 | malcolmd | but if it was generate_silly_european_random_string, we'd be totally okay with it ;) |
| 19:45.16 | file | darn, I can't overrule malcolmd |
| 19:45.18 | file | I'm not that elite |
| 19:45.25 | file | unless I called in a favor... |
| 19:45.30 | putnopvut | I'd have to add more chars for silly european random strings |
| 19:45.50 | putnopvut | Like that German hard S letter, or the Norwegian/Danish o with a line through it. |
| 19:46.01 | file | malcolmd, this is when your network connection is supposed to drop but I doubt that'll happen |
| 19:46.27 | malcolmd | no, that's just my jabber connection that's up and down like the motion of the ocean |
| 19:51.31 | file | putnopvut, don't we have a generate random string already? |
| 19:51.47 | file | meh whatever |
| 19:52.05 | file | wonders if he is thinking about PJSIP |
| 19:52.39 | TazzNZ | waves - sup all |
| 19:52.41 | file | ah yup - http://www.pjsip.org/pjlib/docs/html/group__PJ__PSTR.htm#gae0f30eb53208168b12b6c8e50649ce89 |
| 20:06.27 | mjordan | so, here's one piece of good news - with no channel drivers loaded, core_local (Local channels) can playback a file to themselves without leaking anything |
| 20:07.46 | TazzNZ | nice :) |
| 20:17.26 | opticron | mjordan, all my patches have also gotten chan_pjsip to the same place |
| 20:17.37 | opticron | it doesn't leak anything except for what sorcery won't release |
| 20:18.20 | opticron | though I can't dial another pjsip channel atm |
| 20:18.37 | opticron | you can't have a translator path to (nothing) |
| 20:23.52 | mjordan | sounds like that's the next thing then |
| 20:24.43 | mjordan | I'm going to keep poking at the core, bridging, recording/mixmonitor, etc. |
| 20:35.41 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 20:49.26 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 20:51.46 | *** join/#asterisk-dev mbowie (~mbowie@162.212.36.9) |
| 20:56.25 | *** join/#asterisk-dev sgriepentrog (~sgriepent@50.247.43.97) |
| 22:11.29 | opticron | chan_pjsip channels can make calls again! https://reviewboard.asterisk.org/r/3742/ |
| 22:33.39 | *** join/#asterisk-dev ipengineer (~zconkle@static-71-252-134-63.dllstx.fios.verizon.net) |
| 22:33.40 | *** join/#asterisk-dev chazzam (~chazz@donutokyo.info) |
| 22:36.07 | *** join/#asterisk-dev Sjors (~sgielen@foo.kassala.de) |
| 22:36.22 | *** join/#asterisk-dev ivan` (~ivan@unaffiliated/ivan/x-000001) |
| 22:36.22 | *** join/#asterisk-dev HeN (uid3747@gateway/web/irccloud.com/x-abwljxwmrasgivvg) |
| 22:36.22 | *** join/#asterisk-dev wdoekes (~walter@wjd.osso.nl) |
| 22:36.22 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c00::f03c:91ff:fe6e:6894) |
| 22:37.18 | *** join/#asterisk-dev HeN (uid3747@gateway/web/irccloud.com/x-swrxlvephqozwzvn) |
| 22:37.32 | *** join/#asterisk-dev ivan` (~ivan@unaffiliated/ivan/x-000001) |
| 22:52.55 | *** join/#asterisk-dev Gugge (gugge@194.150.109.208) |
| 22:54.14 | *** join/#asterisk-dev felipe_ (~felipe@unaffiliated/felipe) |
| 23:05.41 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-yswezjssncpntlbd) |
| 23:32.24 | *** join/#asterisk-dev Jacoby6000 (~Jacoby600@static-71-252-134-63.dllstx.fios.verizon.net) |
| 23:33.49 | Jacoby6000 | If we can come up with an agreeable delimeter between email addresses on the voicemail table, would anybody be opposed to a patch to the review board allowing voicemails to dispatch emails to multiple email adresses |
| 23:34.09 | Jacoby6000 | This guy used pipes, but the idea is the same: http://mike.eire.ca/2012/02/03/asterisk-1-8-vm-multiple-emails/ |