| 00:05.36 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-28-58.cablep.bezeqint.net) |
| 00:05.36 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 01:11.14 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 01:15.39 | *** join/#asterisk-dev russellb (~russellb@redhat/russellb) |
| 01:15.39 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 01:17.02 | *** join/#asterisk-dev Qwell (north@asterisk/developer/Qwell) |
| 01:17.02 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 02:18.52 | *** join/#asterisk-dev wedhorn (~wedhorn@110-175-181-222.static.tpgi.com.au) |
| 02:26.10 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 03:30.36 | *** join/#asterisk-dev nix8n82 (~AndChat56@67.139.112.186) |
| 03:48.04 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 04:51.51 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 05:09.12 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 05:53.00 | *** join/#asterisk-dev bulkorok (~Benjamin@gw1.pinguin.ag) |
| 08:25.34 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:7d03:35f:d4e:57e6) |
| 08:26.13 | Stefan27 | my asterisk is taking up tons of RAM. pmap -XX shows it has almost 1000 mmap2'd anon blocks of size 1 MB or 2 MB 1012 3c900000 rw-p 00000000 00:00 0 1012 1012 1012 0 0 0 1012 1012 1012 0 0 4 4 0 rd wr mr mw me nr |
| 08:26.34 | Stefan27 | or 2048 ae600000 rw-p 00000000 00:00 0 2048 2048 2048 0 0 0 2048 792 2048 0 0 4 4 0 rd wr mr mw me nr |
| 08:26.46 | Stefan27 | what objects in asterisk might they correspond to? |
| 08:34.52 | Stefan27 | I think most of the 1 MB blocks are malloced for sip_pvt structs? (I'm not that experienced with strace, pmap and C) is there any way to make asterisk log its mallocs? |
| 08:46.50 | coreyfarrell | Stefan27: you want to recompile asterisk with MALLOC_DEBUG or REF_DEBUG to more info. |
| 08:50.31 | coreyfarrell | Stefan27: see https://wiki.asterisk.org/wiki/display/AST/MALLOC_DEBUG+Compiler+Flag and https://wiki.asterisk.org/wiki/display/AST/Reference+Count+Debugging |
| 08:57.10 | Stefan27 | is MALLOC_DEBUG as heavy as REF_DEBUG? REF_DEBUG created 10 GB logs in no time |
| 08:59.09 | coreyfarrell | MALLOC_DEBUG is not as nearly as heavy |
| 09:00.26 | coreyfarrell | it will effect performance since every allocation is tracked (grouped by file:line). i'd recommend running it only to reproduce the issue and produce outputs |
| 09:02.13 | coreyfarrell | I suggest the same recommendation for REF_DEBUG - run it the minimum time needed to reproduce the issue. with REF_DEBUG you also want to be sure to 'core stop gracefully' |
| 09:05.39 | Stefan27 | yea i was tracking a random bug with REF_DEBUG, (it hasnt happend in last 100 000 calls since i started tracking). This bug im tracking now is probably deterministic. (the test case is a stress-test with queues and local channels) |
| 10:24.41 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 10:24.41 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:55.14 | Stefan27 | MALLOC_DEBUG resulted in instant segmentation fault when starting asterisk |
| 10:55.39 | Stefan27 | does it require something? |
| 11:00.14 | coreyfarrell | shouldn't do that :( |
| 11:00.24 | coreyfarrell | doesn't require anything |
| 11:00.50 | wdoekes | most recent asterisk? |
| 11:01.14 | wdoekes | there were a couple of ast_free/free issues with that and built-in libedit |
| 11:04.08 | Stefan27 | 12.6.1 is most recent still? |
| 11:07.49 | Stefan27 | Program received signal SIGSEGV, Segmentation fault. |
| 11:07.50 | Stefan27 | region_data_wipe (reg=0x831ef58) at astmm.c:286 |
| 11:07.50 | Stefan27 | 286 *pos = FREED_MAGIC; |
| 11:08.15 | wdoekes | http://lists.digium.com/pipermail/asterisk-commits/2014-September/070353.html |
| 11:09.23 | wdoekes | or https://issues.asterisk.org/jira/browse/ASTERISK-24322 |
| 11:10.22 | Stefan27 | Recompiling with DONT_OPTIMIZE results in Asterisk running fine. |
| 11:10.27 | Stefan27 | I'll try that |
| 11:12.59 | Stefan27 | how did you find that jira so fast? |
| 11:13.17 | Stefan27 | did you use some clever search words or did you remember this problem from your own memory? |
| 11:15.54 | wdoekes | memory |
| 11:16.15 | wdoekes | but I used the clever MALLOC_DEBUG search word |
| 11:16.20 | wdoekes | https://issues.asterisk.org/jira/browse/ASTERISK-24322?jql=status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20Triage%2C%20%22Waiting%20for%20Feedback%22)%20AND%20text%20~%20%22malloc_debug%22 |
| 11:16.54 | *** join/#asterisk-dev mbowie (~mbowie@162.212.36.9) |
| 11:40.01 | Stefan27 | i know a little more about my other weirdproblem from a few days ago now. My asterisk gets stuck in a loop (300 000+ iterations) in chan_sip.c::__sip_ack at: 'while((cur->retransid > -1 && ast_sched_del(sched, cur->retransid)) {'. It seems that the pkt in question has never been sent to retrans_pkt() ... ((because I logged the memory address of the &cur (sip_pkt) struct for which the loop |
| 11:40.02 | Stefan27 | got stuck ... and i had also logged the address of any pkt inputted to retrans_pkt since the start of asterisk -- no match)) |
| 11:41.14 | Stefan27 | This only happens like once every 100 000 calls, but somehow the scheduler doesn't recognize the retransid |
| 12:06.39 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 12:12.15 | *** join/#asterisk-dev mbowie (~mbowie@162.212.36.9) |
| 12:41.21 | file | Stefan27, https://issues.asterisk.org/jira/browse/ASTERISK-24321 |
| 12:44.44 | Stefan27 | wow that does look like my issue |
| 12:45.51 | Stefan27 | although i use a patched version of 12.6.1 and i'm in a tough spot because if i unpatch back to 12.6.1-src my test-scripts dont work |
| 12:48.48 | file | revision 425503. |
| 12:49.01 | file | it's a one liner |
| 12:52.19 | Stefan27 | oh how great, 425503 and none of the other 15 commits? |
| 12:52.39 | Stefan27 | aha they were for other branches |
| 12:59.57 | *** join/#asterisk-dev Qwell (north@asterisk/developer/Qwell) |
| 12:59.57 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 13:08.10 | Stefan27 | thanks mr file |
| 13:10.31 | *** join/#asterisk-dev mbowie (~mbowie@162.212.36.9) |
| 13:12.09 | *** join/#asterisk-dev Qwell (north@asterisk/developer/Qwell) |
| 13:12.09 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 13:30.01 | *** join/#asterisk-dev fornax (~fornax@p5797A59F.dip0.t-ipconnect.de) |
| 13:56.21 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 13:56.47 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-mgdulwbtnpqngder) |
| 14:08.25 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-pkfhyenukyphwrus) |
| 14:18.01 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:18.02 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:18.33 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:18.33 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:18.45 | *** part/#asterisk-dev bulkorok (~Benjamin@gw1.pinguin.ag) |
| 14:20.24 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-cxyoqkeohpybiyzb) |
| 14:20.24 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:33.02 | *** join/#asterisk-dev rmudgett (~rmudgett@nat/digium/x-adjzxnmfeclxqoyz) |
| 15:06.42 | sruffell | seanbright: What are you planning on your module loader branch? Just out of curiosity? |
| 15:06.54 | seanbright | sruffell: https://wiki.asterisk.org/wiki/display/~dlee/Asterisk+Module+Loading+Improvements |
| 15:07.15 | seanbright | something along those lines |
| 15:08.34 | *** join/#asterisk-dev fornax (~fornax@p5797A59F.dip0.t-ipconnect.de) |
| 15:09.00 | sruffell | Hmmâ¦interesting. |
| 15:10.32 | sruffell | Okâ¦.I've not seen that before. I've often thought about implementing something like the kernel module loader in asterisk, using a deps file that can be querried at runtime directly from the information in the .so files so that information about dependencies doesn't have to be maintained in the XML files. |
| 15:10.57 | sruffell | I'll need to study that page more carefully and see where the common parts are. |
| 15:12.17 | sruffell | Besides the channels, for apps I would like to just be able to write the dialplan and have Asteirsk be able to load the correct dialplan applications and deps when parsing the dialplan. |
| 15:12.35 | sruffell | Anywayâ¦â¦sorry for the interruption... |
| 15:30.06 | opticron | the things you suggest sound dangerously close to magic |
| 15:32.02 | sruffell | hehâ¦but I believe possible. My motivation is to encourage people to run Asterisk with the smallest memory footprint possible so when running on small systems someone who hasn't hand tuned modules.conf doesn't complain that chan_dahdi is broken when a call comes in and the system has to page code back into memory. |
| 15:32.22 | sruffell | â¦if asterisk had been otherwise idle. |
| 15:33.05 | sruffell | and that paging of memory cases buffer overruns in the kernel, etc.. causing callerid, etc to be missed. |
| 15:33.45 | Negr0 | sruffell: I like the idea for sure, although how do you handle realtime? |
| 15:34.06 | Negr0 | knows nobody should actually be using realtime, is realistic in knowing that people do it anyway. |
| 15:34.35 | Marquis42 | Woah, sorry about the nick... Changed it on an inside joke in another room and forgot to change back.... :/ |
| 15:34.36 | sruffell | lol |
| 15:34.38 | wdoekes | what about realtime and modules? |
| 15:34.48 | Marquis42 | realtime dialplan is what I mean |
| 15:34.51 | sruffell | yeah..I'm not sure why realtime matters for deps... |
| 15:35.09 | sruffell | ahhâ¦shouldn't matterâ¦if dialplan comes from realtime vs if it is read from a file... |
| 15:35.20 | Marquis42 | You were talking about Asterisk looking at the dialplan and "magically" loading the right modules. |
| 15:35.29 | sruffell | if is sees a call to an application that isn't loaded, it should be able to consult the deps file and load it when processing the updates. |
| 15:35.35 | Marquis42 | Are you saying it would actually load it dynamically at runteim? i.e., while executing dialplan? |
| 15:35.42 | Marquis42 | ah, ok |
| 15:35.51 | sruffell | the "magic" will come from building the deps file in the modules folder at install time. |
| 15:35.56 | Marquis42 | clever, although what's the latency penalty for loading a module while executing DP? |
| 15:35.59 | sruffell | based on sections in the .so files. |
| 15:36.16 | sruffell | it gets done when DP is loaded..not when runningâ¦so.... |
| 15:36.25 | sruffell | (if not already loaded via modules.conf) |
| 15:36.39 | Marquis42 | ok, so for realtime DP it'll read all of the DB rows at startup? |
| 15:36.53 | wdoekes | that wouldn't work for a changing db |
| 15:36.57 | sruffell | I'm guessingâ¦I'm not too familiar with realtime so I might be misunderstanding.... |
| 15:37.06 | wdoekes | I would drop realtime-dialplan support |
| 15:37.12 | *** join/#asterisk-dev sgalarneau (~sgalarnea@nat/digium/x-xhedcucdlwegioex) |
| 15:37.58 | sruffell | no complaints from meâ¦but then I do not ever use it... |
| 15:38.32 | wdoekes | I don't even think it works for anyone. perhaps add a log_warning "if you see this, please send a mail to ... so we know that there is someone using RT DP" |
| 15:38.48 | Marquis42 | I hate it anyway, so no complaints from me if it's not supported there. I think the complexities vastly outweigh the benefits in that situation. |
| 15:39.30 | Marquis42 | FWIW, I'm mostly playing devil's advocate here. I love the idea and hope to see it working. |
| 15:41.51 | mjordan | wdoekes: there's still a surprising number of people using it, but yes, it's terrible and we should all feel sorry for anyone crazy enough to use it (and it's impending deadlocks of doom) |
| 15:42.19 | mjordan | goes to check something about pbx_realtime |
| 15:42.21 | sruffell | But alsoâ¦I recognize that DAHDI could also help the problem by allowing more dynamic channel buffers, so in cases like this it will just allow more audio to be buffered up on a particular channel before Asterisk is ready to start processing it because of a ring signal or something... |
| 15:42.58 | mjordan | right. |
| 15:43.12 | mjordan | pretty sure pbx_realtime does not actually query the database at run time. |
| 15:43.12 | leifmadsen | mjordan: we use it at ThinkingPhones unfortunately :\ |
| 15:43.18 | mjordan | leifmadsen: cra cra |
| 15:43.28 | mjordan | and you're not deadlocking? |
| 15:43.36 | leifmadsen | (with that being said, I am taking steps to rip that BS out of there) |
| 15:43.37 | Marquis42 | We didn't say we're not deadlocking. ;) |
| 15:43.39 | leifmadsen | mjordan: not all the time |
| 15:43.42 | sruffell | lol |
| 15:43.56 | leifmadsen | like right now... not deadlocking |
| 15:43.57 | leifmadsen | like right now... not deadlocking |
| 15:43.59 | leifmadsen | deadlock |
| 15:44.06 | Marquis42 | haha |
| 15:44.38 | leifmadsen | Marquis42: this is our way of making everyone take the removal of realtime dialplan seriously... |
| 15:44.40 | mjordan | it's actually a bug in pbx core and switch statements, so it *technically* isn't pbx_realtime's fault. But fixing it is rather hard. |
| 15:44.50 | leifmadsen | "you guys do know that realtime dialplan deadlocks a lot right?" |
| 15:45.01 | mjordan | but, theoretically, you shouldn't have to have an active DB connection until something does a dialplan lookup |
| 15:45.10 | leifmadsen | the whole idea around realtime dialplan makes me want to hurt a baby seal |
| 15:45.16 | sruffell | awwww |
| 15:45.17 | Marquis42 | lol |
| 15:45.27 | Marquis42 | That poor seal didn't do anything to you! ;) |
| 15:45.42 | leifmadsen | Marquis42: have you ever seen how black their eyes are?! |
| 15:45.51 | leifmadsen | static dialplan and looking up dynamic information is a much better approach in my experience |
| 15:45.59 | Marquis42 | +INF |
| 15:46.13 | Marquis42 | func_odbc FTMFW |
| 15:46.21 | leifmadsen | just don't use unixodbc from 2004 |
| 15:46.27 | Marquis42 | heh |
| 15:46.42 | file | leifmadsen, quite |
| 15:59.52 | wdoekes | <@leifmadsen> Marquis42: this is our way of making everyone take the removal of dialplan seriously... <-- I'm telling Paul you said that |
| 16:00.08 | Marquis42 | lolz |
| 16:00.11 | Marquis42 | Please do |
| 16:00.29 | gtjoseph | SHHHHHH!! We just got him to sleep. |
| 16:00.30 | Marquis42 | I have some more popcorn to consume while the flames roll in. ;) |
| 16:01.15 | leifmadsen | wdoekes: LOL wow I totally mispoke :) |
| 16:01.24 | leifmadsen | I meant... at thinkingphones, the removal of realtime dialplan :) |
| 16:01.30 | leifmadsen | hilarity ensues |
| 16:02.35 | wdoekes | there was a bit of packet loss around some of your words |
| 16:04.06 | leifmadsen | I blame file |
| 16:04.09 | mjordan | I have hope that we may finally be past that bit of sideways conversation. I'm probably wrong, but I'm still hopin'. |
| 16:04.28 | leifmadsen | I haven't caught up on that thread yet, so there is still hope for me to respond to some things |
| 16:04.30 | leifmadsen | :D |
| 16:04.34 | Marquis42 | heh |
| 16:04.46 | leifmadsen | mjordan: you should move all the mailing lists to web based so that you can lock the conversation |
| 16:04.52 | leifmadsen | ducks |
| 16:05.01 | Marquis42 | I know jsmith offered some helpful suggestions while (hopefully) not feeding the troll. We'll see how that goes... |
| 16:05.30 | mjordan | I won't lie, I did look to see what Discourse offered |
| 16:05.38 | mjordan | alas, it doesn't quite work well enough yet as a replacement for mailing lists. |
| 16:05.50 | leifmadsen | sadness |
| 16:06.07 | leifmadsen | posts to mailing list that mjordan says he's moving the mailing list to web based |
| 16:06.13 | mjordan | the nice thing about more modern platforms is that it doesn't have to be one person acting as an admin. Most of them (such as the StackExchange model of platforms) have a way for the community to self-police |
| 16:06.27 | Marquis42 | leifmadsen: trolol |
| 16:06.29 | mjordan | leifmadsen: just make sure we only talk about it in secret. I need schill! |
| 16:06.32 | mjordan | er, a schill |
| 16:06.40 | leifmadsen | lol |
| 16:07.02 | leifmadsen | mjordan: astridevcon is like the Stonecutters right? |
| 16:07.04 | file | let's move to a web based platform that is behind a VPN that is authenticated against JIRA and requires at least 3 code reviews to be done |
| 16:07.17 | leifmadsen | file: now that's something I could get behind! |
| 16:07.21 | mjordan | leifmadsen: what, you didn't get your secret badge? |
| 16:07.37 | leifmadsen | mjordan: there are no secret badges |
| 16:07.40 | leifmadsen | taps side of nose |
| 16:07.44 | Marquis42 | Badges!?!? We don't need no stinkin' badges! |
| 16:07.55 | leifmadsen | this is going downhill very fast |
| 16:07.59 | leifmadsen | I'm happy to have contributed |
| 16:08.03 | file | or uphill |
| 16:08.08 | file | uphill is the new downhill |
| 16:25.44 | wdoekes | tzafrir: there's a leading "+" in your r4118 |
| 16:27.22 | mjordan | wdoekes: ha! My eyes transposed that as 'patch, ignore the +' |
| 16:42.54 | gtjoseph | mjordan: Something broke! (Error 500) when trying to create a new review request |
| 16:43.09 | file | cool |
| 16:45.02 | gtjoseph | Oops, nevermind. I tried to upload a git formatted patch. Still I should get a nicer error. :) |
| 16:45.35 | file | git your git formatted patch away from there |
| 16:45.46 | gtjoseph | :) |
| 16:45.52 | file | gtjoseph, did the stuff work? |
| 16:46.34 | gtjoseph | YES! I was just about to im you. I moved my pbx over to a wandboard last night and it's working fine. |
| 16:46.42 | file | awesome |
| 16:46.51 | gtjoseph | thanks again! |
| 16:46.54 | file | yw |
| 16:49.16 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:49.20 | malcolmd | gtjoseph: yay! |
| 16:49.32 | malcolmd | file: you sent 2.1.1 build? |
| 16:50.02 | file | malcolmd, I gave him a bleeding edge 2.1 branch build because I thought he could HANDLE IT! |
| 16:50.10 | gtjoseph | yay |
| 16:50.21 | malcolmd | hah, well that's got the 2.1.1 fixes, so yay |
| 16:50.25 | file | yes |
| 16:50.32 | malcolmd | ./s/fixes/fix |
| 16:56.22 | gtjoseph | i think i broke reviewboard. it's super slow. |
| 16:57.49 | sgriepentrog | No, it's just Thursday. |
| 16:59.04 | sgriepentrog | It's Gt.R.Dun Thursdays (get review done) |
| 17:06.56 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 17:22.57 | mjordan | gtjoseph: still slow? |
| 17:23.17 | gtjoseph | better now. wasa handing for minutes earlier |
| 17:23.22 | gtjoseph | was hanging |
| 17:30.57 | file | it took a siesta |
| 17:37.23 | mjordan | opticron: if you have a chance, you may want to take a look at https://reviewboard.asterisk.org/r/4132/, since you were involved in the patch that caused it |
| 17:37.43 | leifmadsen | mjordan is so gentle |
| 17:37.48 | mjordan | IIRC, the reason for it was for embedded semi-colons in URIs in Dial strings |
| 17:37.56 | mjordan | leifmadsen: meh, he can walk over to my office and smack me around |
| 17:39.18 | leifmadsen | mjordan: if I know anything about opticron, I know that you're probably safe |
| 17:39.19 | leifmadsen | :D |
| 17:41.50 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 17:41.51 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 17:41.56 | opticron | delivers a virtual smacking |
| 18:00.24 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 18:35.47 | seanbright | file: someone at astricon mentioned you had done something with, i assume, xattrs? |
| 18:35.59 | file | I looked at them long ago |
| 18:36.06 | file | didn't do anything |
| 18:36.12 | seanbright | gotcha |
| 18:36.39 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 18:37.50 | *** join/#asterisk-dev fornax (~fornax@85.183.43.221) |
| 19:17.31 | gtjoseph | anyone know if in YAML you can refer to a TestCase variable like self.test_name ? |
| 19:17.50 | opticron | highly unlikely |
| 19:18.24 | gtjoseph | because YAML doesn't allow it or because TestCast doesn't? |
| 19:18.41 | opticron | there are some things that are parametric within the YAML, but they tend to use curly braces and we had to write explicit code to parse it out |
| 19:19.11 | opticron | where are you trying to use such things? |
| 19:19.49 | gtjoseph | I have some common py code that I need to reference from multiple tests so I was just going to adjust the search path to add the test's parent directory |
| 19:20.46 | opticron | that'll have to be hardcoded unless you modify the test loader |
| 19:21.00 | gtjoseph | which I just did: 'add-relative-to-search-path' :) |
| 19:21.10 | gtjoseph | i was looking for an easy way out though |
| 19:21.44 | gtjoseph | like 'add-to-search-path: [ test_name + '..' ]' |
| 19:29.23 | Stefan27 | according to malloc debug : memory show summary and memory show summary stasis_channels.c I have 53344544 bytes in 13178 allocations by ast_channel_snapshot_create() line 213 of stasis_channels.c (steadily growing) which takes up more than half my heap. Why might that be? It seems to happen in a test case with 50 people in queue A, 10 members in queue A, queue A has ringall strategy. |
| 19:29.23 | Stefan27 | the members of queue A are Local channels, which in turn call real sip peers...In contrast when i have 50 SIP peers calling 50 other SIP peers there's also rapid allocations from ast_channel_snapshot_create() but they are removed a few seconds later so it doesn't increase... |
| 19:29.40 | Stefan27 | does that ring a bell for anyone or i have to examine it further? |
| 19:31.58 | Stefan27 | (version 12.6.1) |
| 20:03.08 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 20:06.39 | seanbright | i kinda hate MODULEINFO |
| 20:16.31 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-gmvdjioymkvtbopg) |
| 20:16.31 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 20:30.33 | gtjoseph | opticron: it has to be >= or the null will get written past the end of the budder |
| 20:30.36 | gtjoseph | buffer |
| 20:30.54 | *** join/#asterisk-dev sgalarneau (~sgalarnea@nat/digium/x-dgoknmwrdkmenmfc) |
| 20:35.13 | opticron | uhhh...let me look at that again just to be sure |
| 20:35.48 | gtjoseph | if te string ends with a ; the we stop before printing the \ that would have escaped it |
| 20:36.05 | gtjoseph | ast_escape_quoted does the same thing which is where I coped from |
| 20:38.46 | opticron | yeah, I read it backward |
| 20:38.55 | gtjoseph | no worries |
| 20:38.55 | opticron | it's fine |
| 20:39.21 | gtjoseph | unbit tests forthcoming though |
| 20:39.40 | opticron | cool |
| 20:40.55 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 21:07.23 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 21:23.58 | Marquis42 | feeds the troll |
| 21:26.33 | Marquis42 | bklang: Our Wikipedia quotes passed like ships in the night ;) But you technically beat me to it. :) |
| 21:30.45 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-hfxyrxrexdkpkncy) |
| 21:30.45 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 21:42.00 | *** join/#asterisk-dev otherwiseguy (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 21:44.04 | bklang | Marquis42: Ha, I saw that too. I guess I'm that much quicker to the "Send" button |
| 21:44.47 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-cxyoqkeohpybiyzb) |
| 21:59.50 | *** join/#asterisk-dev terryw (~otherwise@23-228-175-118.mci.googlefiber.net) |
| 22:30.13 | coreyfarrell | seanbright: is there something about the module system you don't hate? |
| 22:31.53 | rmudgett | Is there something about the module system to like? |
| 22:32.00 | rmudgett | :) |
| 22:32.17 | coreyfarrell | just the idea that it can be replaced |
| 22:35.52 | *** join/#asterisk-dev snuff-work (~snuffy@203.87.61.22) |
| 22:35.53 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:39.37 | coreyfarrell | Stefan27: if the leak you are dealing with is from ast_channel_snapshot_create, you will need REF_DEBUG. since channel snapshots are reference counted malloc_debug doesn't give enough info |
| 22:41.10 | coreyfarrell | Stefan27: last night I was investigating a leak captured by the testsuite that might be related to the issue you are experiencing. if I figure out a patch I will ping you |
| 22:49.10 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-pkfhyenukyphwrus) |
| 23:39.56 | coreyfarrell | is 1.8 in security fix only mode? I already deleted my working copies of 1.8 since the the wiki says it went to security only on 10/21 |
| 23:40.39 | coreyfarrell | trying to decide if I should bother applying r4094 to 1.8 |