| 00:16.14 | *** join/#asterisk-dev elguero (~miguel323@c-76-24-45-163.hsd1.nh.comcast.net) |
| 00:21.33 | *** join/#asterisk-dev mpe_ (~mpe@0xd99d3f8f.customer.cybercity.dk) |
| 01:05.43 | *** join/#asterisk-dev dwayne (~dwayne@c-71-207-214-190.hsd1.al.comcast.net) |
| 01:22.42 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 02:26.53 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-34-122-182.ptld.qwest.net) |
| 02:40.36 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 04:12.30 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 04:12.30 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 04:28.27 | *** join/#asterisk-dev miguel3239 (~miguel323@ns1.nashuacs.com) |
| 05:38.09 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-34-110-194.ptld.qwest.net) |
| 06:12.24 | *** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se) |
| 06:12.24 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:07.11 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 07:07.11 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 07:29.15 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 07:29.57 | *** join/#asterisk-dev schmidts (~schmidts@lmlo.sil.at) |
| 07:30.00 | schmidts | good morning |
| 07:33.22 | *** join/#asterisk-dev hehol (~Adium@ip-78-94-0-76.unitymediagroup.de) |
| 07:34.11 | snuff-work | ello |
| 07:48.22 | schmidts | hello snuff, everything allright? |
| 07:50.41 | snuff-work | yer end of week.. almost home time |
| 07:53.46 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:53.46 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 09:24.46 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 09:43.39 | *** join/#asterisk-dev jermey_g (~jeremey_g@gw-sthlm01.rebtel.com) |
| 09:45.35 | *** join/#asterisk-dev mpe_ (~mpe@178.72.27.239) |
| 09:48.49 | *** join/#asterisk-dev GhOnDiE (~GhOnDiE@92.29.179.207) |
| 11:04.07 | *** join/#asterisk-dev kerframil (~kerframil@gentoo/user/kerframil) |
| 11:04.22 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.211.10) |
| 11:25.46 | *** join/#asterisk-dev crowbar7 (~JKLOBUCAR@12.2.84.2) |
| 11:27.22 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:27.22 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 11:55.04 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:55.04 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:38.31 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 12:38.31 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 13:11.57 | *** join/#asterisk-dev Deeewayne (~dwayne@75-150-14-49-Atlanta.hfc.comcastbusiness.net) |
| 13:11.57 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 13:20.54 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 13:20.54 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 13:30.58 | schmidts | i wish you all a nice weekend! |
| 13:33.46 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 13:38.51 | *** join/#asterisk-dev guilhermebr (~Guilherme@200.103.96.98) |
| 13:40.34 | *** join/#asterisk-dev bklang (~bklang@12.130.119.18) |
| 13:55.12 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 13:57.43 | *** join/#asterisk-dev crowbar7 (~JKLOBUCAR@12.2.84.2) |
| 14:23.57 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:23.57 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:24.20 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:24.20 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:24.44 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:24.44 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:32.41 | *** join/#asterisk-dev bklang (~bklang@12.130.119.18) |
| 14:39.26 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 15:09.21 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:09.21 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:31.19 | Kobaz | hmm |
| 15:31.42 | Kobaz | i'm malloc debugging this one box... there's 3 megs reported, but asterisk is using 55 megs alltogether |
| 15:32.01 | Kobaz | what's the rest just the stack and heap? or is there other unreported items |
| 15:33.41 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 15:34.22 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:34.22 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:37.21 | *** join/#asterisk-dev frawd (~francois@174.Red-88-13-131.dynamicIP.rima-tde.net) |
| 15:48.26 | *** join/#asterisk-dev bklang (~bklang@209.117.47.253) |
| 15:48.51 | Corydon76-home | Stack, code segment, library allocations, heap structures... |
| 15:49.29 | Corydon76-home | You need to subtract out the shared library space |
| 15:52.38 | Kobaz | now it's a bit bigger |
| 15:52.39 | Kobaz | <PROTECTED> |
| 15:52.41 | Kobaz | <PROTECTED> |
| 15:52.56 | Kobaz | 121m with 3.5m mallocated |
| 15:53.01 | Kobaz | it just keeps growing |
| 15:53.37 | Kobaz | i have to restart this asterisk nightly otherwise it uses a gig at the end of the week and winds up triggering the oom killer |
| 15:54.54 | Kobaz | i'm grepping through the code and there's lots of calls straight to malloc |
| 15:55.03 | Kobaz | instead of ast_malloc |
| 16:01.01 | Kobaz | i dont think it's going to grow 10 megs per hour on shared libraries, so it's gotta be heap or there's a leaking malloc that's not being tracked |
| 16:33.43 | *** join/#asterisk-dev Victor_Yure (~victor@unaffiliated/victoryure/x-837844) |
| 16:47.28 | Corydon76-home | Kobaz: Where is it using malloc directly? |
| 16:47.50 | Corydon76-home | Kobaz: turn on DONT_OPTIMIZE and grep through the .i files |
| 16:48.14 | Corydon76-home | because malloc() is #define'd away when MALLOC_DEBUG is on |
| 16:48.18 | *** join/#asterisk-dev bklang (~bklang@209.117.47.253) |
| 16:51.23 | Kobaz | oh |
| 16:51.25 | Kobaz | damn |
| 16:51.34 | Kobaz | i've been going through all the files and replacing malloc with ast_malloc |
| 16:51.39 | Kobaz | and free,realloc,calloc etc |
| 16:51.58 | Kobaz | Corydon76-home: if you grep for malloc(, it's all over the place |
| 16:53.41 | russellb | even if you use malloc directly, it'll still get handled my MALLOC_DEBUG |
| 16:53.49 | russellb | MALLOC_DEBUG was added way before we had ast_malloc and friends |
| 16:55.49 | Corydon76-home | Kobaz: so it's probably some library call that isn't being used properly to release its memory |
| 16:57.11 | Kobaz | russellb: ah |
| 16:57.35 | *** join/#asterisk-dev Praise (~Fat@unaffiliated/praise) |
| 16:58.55 | Kobaz | this system i can actually play with after hours |
| 16:59.02 | Kobaz | i should valgrind it |
| 16:59.53 | russellb | mhm |
| 17:00.45 | Kobaz | i've never been able to get meaningful leak information from valgrind on asterisk though |
| 17:00.55 | Kobaz | there's always leaks reported, i dont know if it's correct or not |
| 17:11.53 | Kobaz | how do you guys check for leaks? |
| 17:21.00 | Corydon76-home | MALLOC_DEBUG, same as what you're doing |
| 17:21.51 | anonymouz666 | where is Corydon76-dig? |
| 17:21.57 | anonymouz666 | heh |
| 17:28.05 | *** join/#asterisk-dev hugorebelo (~hugo@187.35.137.180) |
| 17:34.54 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@2002:c037:40af:1234:fa1e:dfff:fedd:e05b) |
| 17:40.02 | *** join/#asterisk-dev jdoe_ (jdoe@falseprophet.ca) |
| 17:45.45 | Kobaz | Corydon76-home: and if MALLOC_DEBUG doesn't reveal anything? |
| 17:46.19 | Corydon76-home | Kobaz: haven't come across that situation yet |
| 17:46.24 | Kobaz | heh |
| 17:46.50 | Corydon76-home | There are no tools we're hiding from you. |
| 17:47.13 | Kobaz | hehe, i'm not saying you're hiding anything, just wondering what would be the best approach |
| 17:48.52 | *** join/#asterisk-dev jdoe (jdoe@falseprophet.ca) |
| 17:51.06 | *** join/#asterisk-dev jdoe (jdoe@665.be) |
| 17:53.31 | Corydon76-home | Figure out what you're doing different from everybody else |
| 17:54.23 | Corydon76-home | Eliminate usage of various modules until the leak disappears, perhaps |
| 17:58.04 | Kobaz | yeah |
| 18:09.29 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@192.55.64.175) |
| 18:20.04 | *** join/#asterisk-dev SuD (~alex@89.7.113.215) |
| 18:20.08 | *** part/#asterisk-dev SuD (~alex@89.7.113.215) |
| 18:25.20 | *** join/#asterisk-dev bklang (~bklang@m185a36d0.tmodns.net) |
| 19:09.14 | Kobaz | i think i found my problem with the polycom phones getting stuck ringing |
| 19:09.27 | Kobaz | if you dial a phone in a hangup handler, they don't like that |
| 19:12.37 | *** join/#asterisk-dev guilhermebr (~Guilherme@189.63.49.247) |
| 19:33.49 | kpfleming | if you dial a phone in a hangup handler, you aren't going to be able to connect to it if it answers anyway |
| 19:36.08 | Kobaz | yeah |
| 19:36.27 | Kobaz | well. i'm not doing that on purpose... well the code isn't supposed to do that |
| 19:36.48 | Kobaz | but it looks like if you dial a polycom in a hangup handler, the polycom will continue to ring even though all asterisk channels are gone |
| 19:36.58 | Kobaz | i've seen this problem before |
| 20:02.23 | *** join/#asterisk-dev ybit2 (~quassel@unaffiliated/ybit) |
| 20:03.07 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 20:03.07 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 20:43.25 | *** join/#asterisk-dev alecdavis (~alec@202-78-149-14.cable.telstraclear.net) |
| 20:44.01 | alecdavis | M509 |
| 20:44.03 | MuffinMan | [closed] [Asterisk] Core/General 0000509: [patch] New application app_campon reported by pliew https://issues.asterisk.org/view.php?id=509 |
| 20:44.24 | alecdavis | M464 |
| 20:44.26 | MuffinMan | [closed] [Asterisk] Applications/app_queue 0000464: [patch] Campon feature reported by pliew https://issues.asterisk.org/view.php?id=464 |
| 20:45.07 | russellb | you could implement that same thing with a bit of dialplan |
| 20:45.12 | alecdavis | Paul Liew, many years ago got this done, but it was closed as it was seen over complicated. |
| 20:45.19 | russellb | and 1.8 includes real call completion supplementary services support |
| 20:45.19 | alecdavis | dialplan does cut it. |
| 20:45.49 | alecdavis | dialplan doesn't keep the calls in order. |
| 20:46.01 | russellb | nope, but the CCSS code in 1.8 does |
| 20:46.10 | russellb | and doesn't require you to sit there on the phone and wait |
| 20:46.12 | russellb | it will call you back |
| 20:46.51 | alecdavis | would you want that for and esternal caller. |
| 20:47.01 | alecdavis | external doh. |
| 20:47.46 | russellb | hmm ... maybe. it depends. the code also includes native support for the service over SIP and ISDN (EuroISDN, anyway), so it can travel back up the network if it supports it |
| 20:47.58 | russellb | for cases that it doesn't, i'd have to refresh myself on how the "generic" CCSS stuff works in the dialplan |
| 20:48.29 | russellb | http://svn.digium.com/view/asterisk/branches/1.8/doc/tex/ccss.tex?view=markup |
| 20:50.10 | russellb | might need some additional hooks into CallCompletionRequest() to be able to specify how to call the channel back |
| 20:50.44 | alecdavis | The issue we have is a call centre in a queue answering calls, but then direct calls come into them, not through the queue, on a 2nd line, they hate it. 'campon' work's around that. |
| 20:52.16 | russellb | well, i guess a lot of this CC infrastructure could be utilized to implement something very similar to the existing CallCompletionRequest, but a blocking method of doing it |
| 20:52.24 | russellb | this is all 1.8, though |
| 20:52.31 | alecdavis | or even 3rd line, and thats where the queueing of campedon calls is desired. |
| 20:52.43 | russellb | nods |
| 20:52.50 | russellb | brb.. |
| 20:56.29 | alecdavis | so here's the question: Do we want Campon without losing the order of the caller (requires a dynamic queue)? |
| 20:58.09 | russellb | I would be ok with that as long as it utilized the CC code to accomplish it |
| 20:58.23 | russellb | as for how to do it to get it into trunk |
| 21:03.24 | alecdavis | calling back the caller, only works if they have callerid enabled, or from the corporate world - they have their own individual DDI number to call back their desk phone. |
| 21:05.32 | russellb | nods |
| 21:06.05 | russellb | i'm saying, utilize all the work done for CC that knows how to monitor for availability and keeps callers in line |
| 21:10.10 | alecdavis | app_queue could also use the same CC methods :) |
| 21:11.31 | alecdavis | no. that wont work, app_queue is about trying a group of people. |
| 21:20.47 | Kobaz | this looks like a bug... http://pastebin.com/vAd6fbNY |
| 21:21.06 | Kobaz | h has one line, the NoOp... but then the dialplan falls through to the next exten |
| 21:21.46 | file | right. |
| 21:22.50 | Kobaz | if i put a Return() in there after the noop, then it will end and not go to the next exten |
| 21:22.50 | Kobaz | but then i get a warning saying there's no stack |
| 21:23.15 | file | you have written your dialplan to do exactly what it is doing. |
| 21:23.35 | Kobaz | it shouldn't fall through to the next exten, it's done with h |
| 21:24.02 | file | the h exten isn't that special |
| 21:24.18 | Kobaz | it's a regular exten |
| 21:24.43 | Kobaz | so it has to do with the pattern match? |
| 21:25.08 | Kobaz | if you did _11X and then _1XX ... it would execute both, if it didn't otherwise hang up? |
| 21:26.01 | file | the closest extension is found as each priority is executed |
| 21:26.16 | file | runs off |
| 21:26.25 | Kobaz | okay, so it doesn't automatically exit the exten when it's done |
| 21:26.42 | Kobaz | i would expect it to do that, but okay |
| 21:26.54 | *** part/#asterisk-dev alecdavis (~alec@202-78-149-14.cable.telstraclear.net) |
| 21:27.01 | Kobaz | good to know |
| 21:27.16 | Kobaz | i think i'll add another dialplan app that's like Return, but just exits the context |
| 21:27.30 | Kobaz | the last time i tried to Hangup() from within a hangup handler, bad things happened |
| 21:27.36 | Kobaz | need like an End() |
| 22:46.38 | *** join/#asterisk-dev Juggie (~Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com) |