| 04:01.05 | *** join/#asterisk-bugs tuxd00d (n=tuxd00d@128.187.132.25) |
| 04:22.24 | *** join/#asterisk-bugs Juggie (i=Juggie@CPE001601df17fb-CM001a6682d7b6.cpe.net.cable.rogers.com) |
| 04:22.25 | *** mode/#asterisk-bugs [+o Juggie] by ChanServ |
| 09:58.55 | *** join/#asterisk-bugs _ys (i=yuri@91.151.196.254) |
| 10:51.46 | *** part/#asterisk-bugs jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 10:52.27 | *** join/#asterisk-bugs jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 12:02.53 | *** join/#asterisk-bugs DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 12:04.08 | *** join/#asterisk-bugs albertoandrade (n=alberto@200.195.161.164) |
| 12:13.36 | *** join/#asterisk-bugs shido6 (n=shido6@209.114.208.192) |
| 12:25.33 | *** join/#asterisk-bugs juanjoc (n=juanjoc@host190.190-225-197.telecom.net.ar) |
| 12:51.44 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 13:02.15 | *** join/#asterisk-bugs bweschke (n=BJ_Wesch@c-76-124-82-215.hsd1.nj.comcast.net) |
| 14:24.12 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 14:55.13 | *** join/#asterisk-bugs jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:21.19 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:21.19 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 15:29.57 | *** join/#asterisk-bugs putnopvut (n=putnopvu@216.207.245.1) |
| 15:29.57 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 16:01.12 | putnopvut | M12528 |
| 16:01.14 | MuffinMan | [closed] [Asterisk] Core/General 0012528: [patch] vmail.cgi problem with forwarding without selecting a message reported by pukepail (Karma: +2.00) http://bugs.digium.com/view.php?id=12528 |
| 16:01.40 | putnopvut | This code predates my work on app_queue, so I was wondering if anyone had a good explanation for why realtime queues are not loaded unless a specific queue is requested. |
| 16:05.02 | lmadsen | that is essentially how realtime seems to work -- you get the data once it is requested |
| 16:05.06 | lmadsen | there is no pre-caching |
| 16:05.39 | lmadsen | it is only cached upon first request |
| 16:05.43 | lmadsen | why... I don't know :) |
| 16:05.56 | putnopvut | Right, I understand that much, but when you don't specify a queue with the "queue show" command, the cached realtime info is returned instead of querying the backend for up-to-date data. |
| 16:06.43 | lmadsen | agreed |
| 16:06.46 | lmadsen | that seems to be what happens |
| 16:06.54 | lmadsen | it'd be nice if it actually did another lookup |
| 16:06.59 | putnopvut | It wouldn't be hard to do that. |
| 16:07.15 | putnopvut | I just didn't want to change it only to be told that it was done that way for a reason. |
| 16:07.26 | Corydon76-dig | How would it know that its data is not up-to-date? |
| 16:07.40 | lmadsen | why care about that? just poll every time |
| 16:07.46 | putnopvut | exactly. |
| 16:07.47 | lmadsen | assume its out of date |
| 16:07.59 | Corydon76-dig | Then why cache the information at all? |
| 16:08.06 | lmadsen | I don't know... why? |
| 16:08.22 | lmadsen | it's already polling every time a queue is requested by the dialplan |
| 16:08.28 | Corydon76-dig | That is the question, and I'm sure there's a good reason |
| 16:08.31 | lmadsen | which is a much heavier burden than what the CLI will do |
| 17:27.34 | *** join/#asterisk-bugs Burlington (n=Burlingt@fw01ext.voicepulse.com) |
| 18:16.34 | *** join/#asterisk-bugs _ys (n=yuri@236-069.nat.mns.ru) |
| 18:16.40 | *** join/#asterisk-bugs Burlington2 (n=burlingt@fw01ext.voicepulse.com) |
| 18:43.46 | *** join/#asterisk-bugs Gareth (i=gareth@www.wiked.org) |
| 18:44.24 | russellb | someone please help Gareth with his IAX2 problem in 1.4.21 |
| 18:44.32 | russellb | I have seen multiple reports of this and we need to get to the bottom of it |
| 18:44.36 | Gareth | russellb: thanks. |
| 18:44.42 | russellb | np |
| 18:46.38 | Gareth | Something I just noticed, I see that asterisk is listening on port 4569 (IAX) but if I try and connect using just telnet to the port...I get a connection refused. |
| 18:47.06 | Gareth | OH. nm. |
| 18:47.18 | Gareth | forgot, its UDP not TCP :) |
| 18:52.16 | putnopvut | What's the issue? |
| 18:53.04 | _ys | russellb: how to fix "ERROR[74250]: res_timing_pthread.c:153 pthread_timer_set_rate: res_timing_pthread only supports timers at a max rate of 50 / sec" ? |
| 18:53.18 | Gareth | inbound IAX connections are failing...Ive tried 2 ata adapters and a soft phone just now. The softphone timed out while connecting. |
| 18:53.30 | russellb | _ys: find where the code tries to use a timer at a higher rate, and depending on the result, we'll change it |
| 18:53.34 | russellb | putnopvut: deadlock |
| 18:53.47 | Gareth | I was using Realtime, thought perhaps that was the issue but I moved the accounts into /etc/asterisk/iax.conf but am seeing the same results. |
| 18:54.42 | putnopvut | Ah. Gareth, if this is reliably reproducible, then if you don't mind, could you re-compile with DEBUG_THREADS selected in menuselect (if it isn't already) and pastebin the output of "core show locks" when the problem occurs? |
| 18:55.03 | file | putnopvut: thanks for looking at it |
| 18:55.35 | *** join/#asterisk-bugs DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 18:56.30 | Gareth | putnopvut: unfortunately this is a production phone system being actively used, I won't be able to bring it down until no one is using it. |
| 18:56.46 | putnopvut | Gareth: ah, I see... |
| 18:57.13 | _ys | russellb: chan_iax2 |
| 18:57.46 | putnopvut | Well, perhaps you could attach to the running process with gdb and issue a thread apply all bt full and pastebin the output of that. Perhaps that may give some useful output, but if the code was built without DONT_OPTIMIZE selected in menuselect, there's no guarantee that will be helpful. |
| 18:57.56 | putnopvut | Gareth: is there an open bug report for this? |
| 18:58.05 | Gareth | putnopvut: was just looking on the bugs site. |
| 18:58.17 | putnopvut | Gareth: okay. |
| 18:58.28 | file | I think Corydon76-dig got it |
| 18:58.34 | putnopvut | yeah, I was just about to say... |
| 18:58.50 | russellb | _ys: only if you configure it that way |
| 18:59.29 | russellb | nm |
| 18:59.30 | russellb | stupid bug |
| 18:59.46 | _ys | . |
| 19:00.12 | _ys | on load (reload) stage |
| 19:00.12 | russellb | fixed |
| 19:00.15 | _ys | good |
| 19:00.23 | Corydon76-dig | Two cases in there that may never trip the bug, but I thought it woudl be better safe than sorry |
| 19:01.37 | putnopvut | Gareth: I don't know if it was clear or not, but it seems that Corydon76-dig's closure of issue 12795 *may* also fix the bug you're experiencing. |
| 19:01.48 | Gareth | looks |
| 19:03.01 | Gareth | oh okay cool...thanks. |
| 19:07.11 | _ys | Hm. memory leak in i execute "CLI> astobj2 test <n>" it's ok or not? |
| 19:07.44 | _ys | ... if i execute ... |
| 19:09.06 | putnopvut | _ys: that should not cause a memory leak. |
| 19:11.36 | _ys | putnopvut: You can test independently. w/cli "memory show summary" before "astobj2 test 1" and after .... |
| 19:13.45 | putnopvut | _ys: I'm compiling trunk right now... |
| 19:21.08 | putnopvut | Yeah, there's definitely a leak in astobj2 happening. |
| 19:25.35 | _ys | I found these in xml_trannslate (manager.c) If ao2 obj with ref count = 1 linked to container, and container destructor called (ref = 0), linked object is not destructed as expected.. |
| 19:31.56 | seanbright | hmmm |
| 19:32.05 | seanbright | might be because of the patch this morning |
| 19:33.43 | seanbright | i don't see how, though. |
| 19:43.46 | seanbright | putnopvut: are you looking at it? |
| 19:44.11 | putnopvut | seanbright: yeah, and it's not because of this morning's fix. |
| 19:44.24 | putnopvut | I just ran a test with that reverted and the memory leak is still there. |
| 19:44.39 | seanbright | phew |
| 19:44.40 | jsmith | w00t |
| 19:44.40 | _ys | putnopvut: You right |
| 19:49.29 | *** join/#asterisk-bugs d1mas (n=chatzill@ip195.117.adsl.wplus.ru) |
| 19:50.29 | putnopvut | _ys: I think you're right about the fact that the individual objects in the container are not being freed when the container is freed. |
| 19:51.23 | d1mas | russellb: hello. I have a question regarding 12656. You are saying in the commit comment: "There was still a small window of opportunity |
| 19:51.25 | d1mas | for a DTMF frame, or some other deferred frame type, to come in and get dropped". What you mean? Under what circumstances a frame will be lost? |
| 19:52.39 | _ys | putnopvut: I know :). But i don't know where |
| 19:52.40 | _ys | «exactly» |
| 19:52.40 | _ys | ñ àíãëèéñêîãî |
| 19:52.40 | _ys | â òî÷íîñòè, òî÷íî, êàê ðàç |
| 19:52.40 | _ys | ñ íåìåöêîãî |
| 19:52.40 | _ys | ñ ôðàíöóçñêîãî |
| 19:52.42 | _ys | ñ èòàëüÿíñêîãî |
| 19:52.44 | _ys | ñ èñïàíñêîãî |
| 19:52.46 | _ys | exactly |
| 19:52.47 | seanbright | stop |
| 19:52.48 | _ys | lol |
| 19:52.53 | putnopvut | what was that? |
| 19:53.04 | _ys | copy paste error |
| 19:53.09 | russellb | d1mas: i have no idea |
| 19:53.24 | russellb | i probably do |
| 19:53.29 | russellb | but i don't have time to look right now |
| 19:53.38 | russellb | i think i meant _before_ that patch, there was a chance dtmf would get lost |
| 19:53.46 | d1mas | russellb: ah. ok |
| 19:53.59 | d1mas | sorry |
| 19:57.41 | d1mas | russellb: there was a bug in the patch by the way - i submitted a fix in 12874. And what worries me most is when you will be able to take a look at 12658 and do something about it... |
| 20:13.20 | russellb | M12658 |
| 20:13.22 | MuffinMan | [new] [Asterisk] Core/PBX 0012658: [patch] DTMF issues on Zap reported by dimas (Karma: +90.00) http://bugs.digium.com/view.php?id=12658 |
| 20:15.37 | russellb | yeah, it's unlikely i can look at it anytime soon. |
| 20:17.33 | russellb | that's what happens when your resources are about 300% committed with work to do |
| 20:22.18 | seanbright | hands russellb a cupcake |
| 20:22.52 | russellb | accepts |
| 20:23.03 | seanbright | its going to be alright |
| 20:23.07 | seanbright | heh |
| 20:24.33 | seanbright | putnopvut: ah ha, was the the problem? |
| 20:24.41 | putnopvut | nope, just something I noticed. |
| 20:24.42 | seanbright | s/was the/was that/ |
| 20:24.43 | putnopvut | :( |
| 20:24.44 | seanbright | ah |
| 20:24.46 | seanbright | drat. |
| 20:25.28 | seanbright | it happens in 1.4 as well |
| 20:25.33 | seanbright | if that is helpful at all |
| 20:25.48 | seanbright | i'll take a look later tonight if you haven't gotten to it |
| 20:25.51 | seanbright | for now, i depart. |
| 20:31.37 | d1mas | qwell: regarding your note on 12874 - when I did "svn update", chan_zap.c was removed and chan_dahdi.c appeared. The same happened to some zap applications. |
| 20:31.55 | Qwell | d1mas: this is true |
| 20:32.03 | Qwell | but it doesn't require dahdi to be installed |
| 20:32.12 | Qwell | and everything is still backward compat with the zap name (even chan_dahdi) |
| 20:32.20 | Qwell | you can even module unload chan_zap.so, and it will work |
| 20:32.49 | d1mas | qwell: ah. I see. I was just a bit scared by these renames and thought you renamed CLI commands / config files as well |
| 20:32.57 | Qwell | we did |
| 20:33.04 | Qwell | but it's all backward compat |
| 20:33.06 | Qwell | (in 1.4) |
| 20:33.13 | d1mas | qwell: got it |
| 20:34.11 | jpeeler | actually i don't know about the module unloading |
| 20:34.27 | Qwell | just loading? |
| 20:34.31 | Qwell | or, reload I guess? |
| 20:35.00 | jpeeler | hrm, maybe i did do it |
| 20:36.28 | jpeeler | actually chan_zap shouldn't exist |
| 20:36.53 | jpeeler | so i didn't bother translating that name since command line completion should make it obvious |
| 20:37.08 | Qwell | bad example then |
| 20:37.30 | jpeeler | ew, i think i see a problem though |
| 20:41.06 | putnopvut | seanbright, I think I may have found the leak in astobj2, and I think it is specific to the astobj2 test CLI command. |
| 20:43.23 | putnopvut | Yep, I think I found it. |
| 21:07.34 | *** join/#asterisk-bugs trapa (n=2264581@207.230.238.94) |
| 21:07.47 | *** part/#asterisk-bugs trapa (n=2264581@207.230.238.94) |
| 22:48.16 | seanbright | putnopvut: sweet. |
| 22:49.06 | putnopvut | seanbright: I was kind of disappointed and yet at the same time relieved to see that the error was just in the astobj2 test handler. |
| 22:50.57 | seanbright | putnopvut: well, on the flip side, finding a memory leak in astobj2 itself would be scary |
| 22:51.06 | seanbright | putnopvut: for sip, iax, etc :) |
| 22:51.24 | putnopvut | Yeah. |
| 22:51.24 | seanbright | queues |
| 22:51.41 | seanbright | we'd probably just be able to close 50 bugs :) |
| 22:52.08 | russellb | there was a mem leak in astobj2 |
| 22:52.21 | russellb | but would only hurt if you dynamically created containers |
| 22:52.24 | seanbright | right |
| 22:52.26 | seanbright | and often |
| 22:52.33 | russellb | and destroyed them with elements still linked into the container |
| 22:52.41 | russellb | looks at main/manager.c |
| 22:52.50 | seanbright | that sounds familiar... |
| 22:52.57 | russellb | that's a harsh bug ... |
| 22:53.04 | seanbright | bows |
| 22:53.10 | russellb | might even justify another release cycle |
| 22:53.12 | russellb | soonish |
| 22:53.14 | russellb | seanbright: +1 |
| 22:53.18 | seanbright | i'd like to thank all the people that made this possible |
| 22:53.24 | russellb | for that, i'll buy you dinner |
| 22:53.27 | seanbright | heh |
| 22:53.29 | seanbright | score |
| 22:53.36 | seanbright | someplace casual, i don't dress up |
| 22:53.40 | russellb | heh |
| 22:53.43 | russellb | btw, i'm thinking monday |
| 22:53.52 | Corydon76-dig | seanbright: I'll feed you dinner... |
| 22:53.53 | seanbright | and poles with naked ladies on them is always a plus |
| 22:54.14 | putnopvut | Softball time! |
| 22:54.21 | seanbright | russellb: works for me... keep in mind i'll be traveling in rush hour, so might need to make it in the evening sometime |
| 22:54.38 | seanbright | Corydon76-dig: thanks, bud. |
| 22:54.50 | Corydon76-dig | giggles |
| 22:55.10 | russellb | seanbright: sure ... like 8 pm or something ... |
| 22:55.21 | seanbright | russellb: perfect |
| 22:56.15 | russellb | time to go hit some balls |
| 22:56.29 | seanbright | o.O |
| 22:56.33 | russellb | soft ones |
| 22:56.38 | seanbright | O.o |
| 22:56.40 | seanbright | heh |
| 22:56.45 | seanbright | enjoy |
| 22:56.48 | russellb | thanks, cya |
| 23:36.36 | *** join/#asterisk-bugs implicit (n=implicit@ip68-4-97-211.oc.oc.cox.net) |
| 23:36.36 | *** mode/#asterisk-bugs [+o implicit] by ChanServ |