IRC log for #asterisk-dev on 20110823

00:03.17pabelangerkorch: #asterisk
00:06.08dwmw2_gone__hm, app_v110 really can't keep up well on my via eden
00:11.32dwmw2_gone__takes 25% CPU time just to generate the bitstream :)
00:27.46*** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-146.cablep.bezeqint.net)
00:27.46*** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ
01:23.45*** join/#asterisk-dev dwmw2_gone__ (~ctrlproxy@twosheds.infradead.org)
01:35.18*** join/#asterisk-dev philipp64|laptop (~chatzilla@50-39-128-145.bvtn.or.frontiernet.net)
05:30.23*** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202)
05:30.23*** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ
06:34.15*** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za)
06:42.06*** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:85f0:acf6:3e17:dd74)
06:52.24*** join/#asterisk-dev fenlander (~fenlander@82.152.81.57)
07:01.29*** join/#asterisk-dev jacc0 (~jacc0@D522448D.static.ziggozakelijk.nl)
07:01.32jacc0hi all
07:02.17jacc0how do I debug a memory leak in asterisk 1.8.6-rc1? I was told to do a "core show memory" but it doesn't work; even if I compile with MALLOC_DEBUG
07:17.46*** join/#asterisk-dev chazzam (~chazz@173-24-236-90.client.mchsi.com)
07:33.50jacc0is that a bug?
07:36.31*** join/#asterisk-dev tamiel (~tamiel@213.30.183.226)
07:36.33jacc0I've got it, should use: "memory show summary"
07:39.20jacc0110116980 bytes in 71135 allocations in file '/usr/src/asterisk-1.8.6.0-rc1/include/asterisk/lock.h'
07:39.29jacc0seems to be the source of the mem leak
07:40.07jacc0but why is it pointing to my source files? si it becasue of the copmiler flags I've set?
07:40.12jacc0*because
08:13.42*** join/#asterisk-dev oej (~olle@static-213-115-251-100.sme.bredbandsbolaget.se)
08:13.42*** mode/#asterisk-dev [+o oej] by ChanServ
08:23.22kaiimorning olle
08:23.39oejMorning, Kaii
08:26.52jacc0hi
08:34.15*** join/#asterisk-dev sgimeno (~sgimeno@163.117.206.10)
10:22.47*** join/#asterisk-dev dwmw2_gone__ (~ctrlproxy@twosheds.infradead.org)
10:23.30*** join/#asterisk-dev Ulrar (~quassel@2a01:e0b:1:136:62eb:69ff:fe8f:18a0)
11:36.32oejsvnmerge doesn't work with python 3.
11:45.21oejmoves back to python 2.7
12:11.52*** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za)
12:46.02*** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-orcnhxeodbezzaai)
12:46.02*** mode/#asterisk-dev [+o mjordan] by ChanServ
13:15.15*** join/#asterisk-dev serafie (~erin@nat/digium/x-xlvhkedagreedjpt)
13:29.09*** join/#asterisk-dev sustav (~alfa@nat/digium/x-ucnwolgodieqspfn)
13:36.32*** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson)
13:36.32*** mode/#asterisk-dev [+o putnopvut] by ChanServ
13:43.12*** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming)
13:43.12*** mode/#asterisk-dev [+o kpfleming] by ChanServ
13:48.11*** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg)
13:52.48*** join/#asterisk-dev mpe (~mpe@office.ipvision.dk)
13:52.53*** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br)
14:22.26*** join/#asterisk-dev bklang (~bklang@2001:470:8:5de:225:ff:fe49:f8cd)
14:23.33anonymouz666channel.c:985 __ast_queue_frame: Exceptionally long voice queue length queuing to IAX2 - this warning means that a CHANNEL CORE can't read() as fast as channel driver send audio frames?
14:34.33acidfoohave you added sleep(1) into the code ;P
14:56.47*** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell)
14:56.47*** mode/#asterisk-dev [+o sruffell] by ChanServ
14:56.51*** join/#asterisk-dev irroot (~irroot@197.170.17.166)
14:58.55*** join/#asterisk-dev bbryant (~brett@c-174-56-132-225.hsd1.sc.comcast.net)
14:58.55*** mode/#asterisk-dev [+o bbryant] by ChanServ
15:00.42*** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-orcnhxeodbezzaai)
15:01.03*** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-fuyzhgskxonophso)
15:01.03*** mode/#asterisk-dev [+o mjordan] by ChanServ
15:08.18*** join/#asterisk-dev AlecTaylor (AlecTaylor@unaffiliated/alectaylor)
15:08.20AlecTaylorhi
15:08.21AlecTaylorDo you know of a locally-hostable project which allows for call-in radio-shows to be hosted (and interacted with) through a web-interface?
15:17.16jsmithAlecTaylor: I'm not aware of anything like that -- you might check in #asterisk though
15:19.30AlecTaylork
15:20.12pabelangerKobaz: ping?
15:20.28Kobazmeep
15:22.30pabelangerKobaz: Wanted to see if you ran into any issue with the recent timerfd patch?  I thought I seen you say something about it yesterday
15:22.54*** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel)
15:22.54*** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ
15:29.04*** join/#asterisk-dev linusXtorvalds (~e_dot_zil@pool-98-118-168-221.bflony.fios.verizon.net)
15:29.12linusXtorvaldsQwell, what gives?
15:29.21*** mode/#asterisk-dev [+b *!*e_dot_zil@*.bflony.fios.verizon.net] by Qwell
15:29.21*** kick/#asterisk-dev [linusXtorvalds!~north@pdpc/sponsor/digium/Qwell] by Qwell (go away)
15:33.35Kobazit looks good
15:34.08pabelangerKobaz: ok cool.  Thanks
15:34.37pabelangeralso, regarding your load/unload chan_dahdi issue, do you know when that started happening?
15:38.37*** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com)
15:45.48Kobaz1.8 definitely
15:45.52Kobazpossibly 1.6.2
15:45.58Kobazbut i haven't really done much with 1.6.2
15:46.08Kobazit didn't happen in 1.6.0.26
15:46.21Kobazare you able to reproduce?
15:46.53pabelangerKobaz: no, i haven't tested yet.  I wanted to see if it was a regression in 1.8
15:48.16Kobazi did post a note on the ticket
15:48.33Kobazyeah it is a regression, i've seen that before in 1.4ish or maybe early 1.6.0
15:49.57Kobazi'm also having problems streaming music from a custom app
15:50.02Kobazmadplay/mpg123
15:50.22Kobazthere's zero rtp coming out of asterisk
16:23.25anonymouz666Kobaz: same thing here, I just tested
16:23.35anonymouz6661.8.6.0-rc1
16:26.12anonymouz666chan_dahdi.c line 5772 (destroy_all_channels): Error obtaining mutex: Invalid argument chan_dahdi.c line 5779 (destroy_all_channels): mutex '&pri->lock' freed more times than we've locked!
16:29.59*** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell)
16:29.59*** mode/#asterisk-dev [+o Qwell] by ChanServ
16:30.14*** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm)
16:42.48*** join/#asterisk-dev wdoekes2 (~walter@wjd.osso.nl)
16:43.58*** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net)
17:03.12dwmw2_gone__Is there a way to give a 'fallback' frame to a dahdi channel, so it'll send that frame instead of ever letting the outbound channel go idle?
17:03.44kpflemingdwmw2_gone__: not that i am aware of
17:03.53kpflemingit would have to be done down in DAHDI itself, though
17:03.56dwmw2_gone__it would make app_v110 much nicer on slow machines.
17:04.10kpflemingit would not be hard to add in DAHDI
17:04.57dwmw2_gone__http://david.woodhou.se/app_v110.c
17:05.10dwmw2_gone__also, how do I get the urate parameter?
17:05.23kpflemingi have no clue what that is
17:05.33dwmw2_gone__in http://david.woodhou.se/app_v110.c.2006
17:05.54dwmw2_gone__oh, wait, in that I don't get it either
17:05.59dwmw2_gone__I got it from misdn once
17:06.07dwmw2_gone__it's in the channel setup somewhere
17:07.36kpflemingthat's beyond me :-)
17:08.41dwmw2_gone__in the bearer capability IE perhaps
17:09.20dwmw2_gone__PRI Span: 2 < Bearer Capability (len= 8) [ Ext: 1  Coding-Std: 0  Info transfer capability: Unrestricted digital information (8)
17:09.20dwmw2_gone__PRI Span: 2 <                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
17:09.20dwmw2_gone__PRI Span: 2 <                                User information layer 1: V.110 Rate Adaption (33)
17:09.20dwmw2_gone__PRI Span: 2 <                                Async: 1, Negotiation: 0, User rate: 9.6 kbit/s (0x8)
17:09.24dwmw2_gone__yeah, there it is
17:25.23dwmw2_gone__argh
17:25.33dwmw2_gone__the dwmw2a account doesn't have a disclaimer on file, so can't upload the new app_v110.c
17:25.42dwmw2_gone__the dwmw2 account does, but the system won't send its password reminder
17:25.47kpfleminghmm
17:25.49kpfleminglet me check
17:26.03dwmw2_gone__clicks 'no this is another type of attachment' :)
17:26.14dwmw2_gone__kpfleming: I think it might be sending from an invalid address that doesn't pass sender verification
17:26.36dwmw2_gone__I was trying to file a bug about that the other day, but got a Java IOError 'disk full' from jira
17:26.40kpflemingdwmw2_gone__: don't do that... we'll be forced to delete it
17:27.36kpflemingwell, i can't move your license agreement to a different account, but i can manually change the password on dwmw2
17:27.49dwmw2_gone__can you make it match the one on dwmw2a?
17:28.11dwmw2_gone__and perhaps even delete dwmw2a
17:28.52kpflemingwell, not really, no
17:29.06dwmw2_gone__np. If you set it to something, I can change it, right?
17:29.10kpflemingyes
17:31.22dwmw2_gone__Ok, hopefully final version of app_v110.c attached to issue 15175
17:31.32dwmw2_gone__it's only been six years since I wrote it :)
18:50.43*** join/#asterisk-dev philipp64|laptop (~chatzilla@50-39-128-145.bvtn.or.frontiernet.net)
19:28.12*** join/#asterisk-dev philipp64|laptop (~chatzilla@50-39-128-145.bvtn.or.frontiernet.net)
19:32.49*** join/#asterisk-dev mpe (~mpe@212.45.120.202)
19:47.09*** join/#asterisk-dev JonathanRose (~jonathan@nat/digium/x-lyorxqfhzamrjnnb)
19:47.15JonathanRosejoin #asterisk-bugs
19:48.49*** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com)
19:55.05*** join/#asterisk-dev bklang (~bklang@2001:470:8:5de:225:ff:fe49:f8cd)
20:03.19*** join/#asterisk-dev fenlander (~fenlander@82.152.81.57)
20:37.06*** join/#asterisk-dev JonathanRose (~jonathan@nat/digium/x-nznyddujgtfnjgub)
21:01.33pabelangerCorydon76-home: ping
21:02.21Corydon76-homepabelanger: pong
21:03.03pabelangerCorydon76-home: I think your Mac OS patch for the sound files is missing the $(DESTDIR) variable.
21:04.39pabelangereg: make DESTDIR=/tmp sounds
21:04.46Corydon76-homeOkay...
21:05.27pabelangerI just wanted to run it by you before submitting a patch.  In the process of testing it now
21:05.32Corydon76-homeI have to warn you, though, that Makefile is incredibly difficult to modify in a way that works correctly
21:05.51Corydon76-homeAll of those macros...
21:08.25pabelangerCorydon76-home: what would you suggest?
21:08.59QwellWhat is the deal with $(MAKE_FOO)?
21:09.05Corydon76-homeMy workaround was to use symlinks where possible
21:09.12Corydon76-homeQwell: See configure.ac
21:09.42QwellIt appears to only be used for sounds/
21:10.01Corydon76-homeQwell: you're mistaken
21:10.10QwellWhere else is it used?
21:10.31Corydon76-homeQwell: anywhere there's a space in a standard path
21:12.01Qwellcan you give an example of its usage?  I only see those vars referenced in sounds/Makefile
21:12.33Qwellfrom the top-level Makefile:
21:12.36Qwell<PROTECTED>
21:12.42QwellI would expect that to also be MAKE_ASTDATADIR
21:13.48Corydon76-homeI'll look at it after while.  I don't have time to work on it right now.
21:14.47Corydon76-homeOkay, you're right.  sounds/Makefile is the only place it's actually used
21:15.02Corydon76-homeBecause it's the only place where quoting a path won't work
21:15.30Corydon76-homeand the symlink is set up (with DESTDIR in mind) in MAKE_PREINSTALL (see makeopts)
21:16.26Corydon76-homeMAKE_PREINSTALL is built in configure.ac
21:17.10Corydon76-homepabelanger: so no, I don't think the lack of DESTDIR in sounds/Makefile is a problem.  In fact, the removal of it was part of the solution
21:18.44pabelangerCorydon76-home: Hmm... I'm not sure why, but something is broken.
21:19.23Corydon76-homepabelanger: File an issue with the particulars, and I'll look at it when I have time
21:19.57pabelangerrc1, works: http://pastebin.com/LReJLwsk
21:20.00pabelangerrc2, broke: http://pastebin.com/xRHhcNb6
21:20.26pabelangerCorydon76-home: Yup, already on it. Thanks
21:20.36Corydon76-homeUh, permission denied!
21:20.52pabelangerfor the URLs?
21:21.20Corydon76-homeHow are you specifying the DESTDIR?
21:21.21pabelangeror, the error message
21:21.36Corydon76-homethe error message
21:22.05pabelangerPATH=$PATH:/tmp/buildd/asterisk-1.8.6.0~rc2/debian/dummyprogs /usr/bin/make OPTIMIZE=-O2 MAKECMDGOALS=dont-optimize NOISY_BUILD=yes ASTDATADIR=/usr/share/asterisk ASTVARRUNDIR=/var/run/asterisk DESTDIR=/tmp/buildd/asterisk-1.8.6.0~rc2/debian/tmp install
21:24.02Corydon76-homeWhy are you redefining ASTDATADIR and ASTVARRUNDIR in the Make command line?
21:25.23pabelangerThat is how the packages are built from upstream debian
21:25.55pabelangerI'd have to go back in the history to see why they are set
21:26.17Corydon76-homeThat seems rather strange.  Those paths really should be given to configure at that point, although it's probably not germane here
21:26.29pabelangernods
21:26.47Corydon76-homeActually, I think I know what the problem is
21:36.02Corydon76-homePatch uploaded to the issue
21:36.06*** join/#asterisk-dev leroybuckingham (43350083@gateway/web/freenode/ip.67.53.0.131)
21:40.09*** join/#asterisk-dev tamiel (~tamiel@ip-183.net-81-220-86.toulouse.rev.numericable.fr)
21:40.24*** join/#asterisk-dev philipp64|laptop (~chatzilla@50-39-128-145.bvtn.or.frontiernet.net)
21:40.30pabelangerCorydon76-home: testing now
21:42.03pabelangerneed to walk the dog while this is compiling
21:47.40QwellCorydon76-home: I added a different patch.  Thoughts?
21:49.17leroybuckinghamHey guys I think somebody should really investigate the change in SVN REV 301505 .  Starting with 1.6.2.18 I'm seeing DTMF signals dropping off the other side of the call when the user dials quickly.  It doesn't matter which DTMF mode they're using or what type of peer either side is.
21:49.45leroybuckinghamI modified my copy of 1.6.2.18 to switch the dtmf end frame back to the first half of the case and that fixed the issue
21:50.07leroybuckinghamthe problem persists in 1.6.2.20, but is fine in 1.6.2.16
21:50.15leroybuckinghamI'm running on debian lenny if that matters
21:51.24Corydon76-homeQwell: Now put a space in either DESTDIR or ASTDATADIR and try it
21:51.38QwellI did
21:51.53Corydon76-homeAnd?
21:51.58Qwellworksforme
21:52.06Corydon76-homeQwell: Try it on Mac OS X
21:54.35Corydon76-homeThis still isn't getting my other work done, so I need to pass for the time being
22:02.22pabelangerCorydon76-home: your patch seems to have fixed it
22:03.06Corydon76-homepabelanger: try Qwell's patch.  If it fixes it on Mac, then we can dispose of quite a bit of extra stuff
22:14.25pabelangerCorydon76-home: Qwell: seems to work
22:14.25pabelangerunder OS X
22:58.33*** join/#asterisk-dev Crowb4r (u1012@gateway/web/irccloud.com/x-zaedmysphuqilgsk)
23:25.38*** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-fuyzhgskxonophso)
23:29.16*** join/#asterisk-dev Corydon76-home (purple@c-69-137-80-31.hsd1.tn.comcast.net)
23:29.16*** mode/#asterisk-dev [+o Corydon76-home] by ChanServ
23:37.44*** join/#asterisk-dev Deeewayne (~dwayne@c-71-207-214-190.hsd1.al.comcast.net)
23:37.44*** mode/#asterisk-dev [+o Deeewayne] by ChanServ

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.