| 00:18.08 | *** join/#asterisk-dev moy (n=chatzill@74.12.127.152) |
| 00:51.45 | *** part/#asterisk-dev korihor (n=korihor@200.44.218.45) |
| 01:02.29 | *** join/#asterisk-dev outtolunc (n=me@c-71-198-197-201.hsd1.ca.comcast.net) |
| 01:16.12 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 01:16.12 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 01:22.22 | Damin | asterisk*CLI> show version |
| 01:22.23 | Damin | Asterisk SVN-branch-1.2-r170580M built by root @ asterisk.n2net.net on a i686 running Linux on 2009-02-09 20:56:32 UTC |
| 01:23.33 | Damin | asterisk*CLI> !cat /proc/cpuinfo | grep model |
| 01:23.33 | Damin | model : 8 |
| 01:23.34 | Damin | model name : Pentium III (Coppermine) |
| 01:23.37 | Damin | Rock.. |
| 01:23.49 | Damin | Still kicking it on a P-3 1000! :) |
| 01:26.11 | *** join/#asterisk-dev JackEStorm (n=no@ip24-252-118-155.no.no.cox.net) |
| 01:32.46 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 01:44.50 | *** join/#asterisk-dev JerJer (n=jmcnamar@c-71-207-221-127.hsd1.al.comcast.net) |
| 02:08.27 | codefreeze-lap | Hmmm.... I have some code here that is trying to do <long long var> = (long long int)<void * var>; I get "cast from pointer to integer of different size" in 32-bit land; |
| 02:08.27 | codefreeze-lap | and if I go the other way: <int var> = (int)<void *var>; then 64-bit land complains about it. What's the happy medium? |
| 02:20.05 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-76-29-245-9.hsd1.al.comcast.net) |
| 02:20.05 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 02:33.02 | codefreeze-lap | found the solution... intptr_t |
| 02:52.10 | *** join/#asterisk-dev jbjuly (n=joelbrya@203.177.143.137) |
| 02:56.17 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 03:07.16 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 03:07.16 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 03:11.26 | *** join/#asterisk-dev obnauticus (n=obnautic@about/windows/regular/obnauticus) |
| 03:16.47 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 03:16.47 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 03:25.09 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable206.69-20-96.mc.videotron.ca) |
| 03:51.49 | *** join/#asterisk-dev Dovid (n=annon@tony09-121-90.inter.net.il) |
| 03:52.02 | Dovid | anyone from Digium here ? |
| 04:21.05 | Corydon76-dig | Uh, sure, why? |
| 04:21.34 | Dovid | on the site. i was trying to find out info on Cepstral |
| 04:21.43 | Dovid | when I went to purchase online there was nothing there |
| 04:21.45 | *** join/#asterisk-dev CunningPike (n=arodgers@S01060014bf81366b.vc.shawcable.net) |
| 04:22.21 | Dovid | http://www.digium.com/en/wheretobuy/product/CEPSTRAL&disti=no&reseller=no |
| 04:22.25 | Dovid | click on buy online |
| 04:22.43 | Corydon76-dig | Digium is a big company. I really don't know what to tell you other than to email webmaster@digium.com |
| 04:23.03 | Corydon76-dig | Gone are the days when I could know everything that was going on |
| 04:23.24 | Juggie | perhaps sales@digium.com |
| 04:23.57 | Corydon76-dig | Or that address |
| 04:24.05 | Dovid | ok. just wanted to let "you guys" know |
| 04:24.10 | Dovid | going to email the webmaster |
| 04:24.39 | Corydon76-dig | Us knowing doesn't fix the problem |
| 04:24.53 | Corydon76-dig | Where us==developers |
| 04:25.06 | Corydon76-dig | Sales and marketing really doesn't hang out on IRC |
| 04:25.49 | Dovid | u have a point ;) |
| 04:25.52 | Dovid | i sent an email |
| 04:26.13 | Juggie | it used to :) |
| 04:27.31 | Corydon76-dig | Juggie: I dunno. I don't think Greg Vance really ever hung out on IRC |
| 04:28.19 | Juggie | ya, but you guys used to have control of the web servers and such |
| 04:28.38 | Corydon76-dig | and he's the closest person to be considered a geek in the sales dept |
| 04:29.08 | Corydon76-dig | Nah, the developers never had control of the web servers |
| 04:29.23 | Corydon76-dig | though at one time, we were in charge of the company PBX |
| 04:29.52 | Corydon76-dig | Now there's a full-fledged IT dept |
| 04:30.16 | Corydon76-dig | Not "what developers go do when the network isn't behaving" |
| 04:31.39 | Corydon76-dig | Now there's change management and planning and anticipating problems before they take down servers... |
| 04:50.25 | *** join/#asterisk-dev fiddur (n=fiddur@92-32-123-161.tn.glocalnet.net) |
| 05:16.42 | *** join/#asterisk-dev supervillain (n=joelbrya@203.177.143.137) |
| 05:16.58 | supervillain | anyone here developing for IP01-IP08 devices? |
| 05:51.37 | *** join/#asterisk-dev kerframil (n=kerframi@gentoo/user/kerframil) |
| 06:33.26 | jtodd | Cepstral purchases here: http://store.digium.com/products.php?category_id=46 |
| 07:41.51 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@local.xorcom.com) |
| 07:41.51 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:54.35 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 08:29.03 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 08:30.46 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 09:03.46 | *** join/#asterisk-dev frawd (n=francois@244.Red-83-60-157.dynamicIP.rima-tde.net) |
| 09:04.36 | *** part/#asterisk-dev frawd (n=francois@244.Red-83-60-157.dynamicIP.rima-tde.net) |
| 09:09.21 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 09:09.21 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:26.21 | *** join/#asterisk-dev Mr_BOnD_007 (i=Mr_BOnD_@119.160.199.6) |
| 10:08.22 | *** join/#asterisk-dev fiddur (i=fiddur@c042.rit.se) |
| 10:23.10 | *** join/#asterisk-dev steliosk (n=Stelios@ipa107.2.tellas.gr) |
| 10:23.30 | *** join/#asterisk-dev Pazzo (n=ugelt@sadsl-246059.rol.raiffeisen.net) |
| 11:07.43 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:11.01 | *** join/#asterisk-dev frawd (n=francois@235.pool85-49-251.dynamic.orange.es) |
| 11:11.06 | *** part/#asterisk-dev frawd (n=francois@235.pool85-49-251.dynamic.orange.es) |
| 11:24.37 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.36.91) |
| 11:26.07 | *** join/#asterisk-dev janinge (i=j@ninge.net) |
| 11:31.07 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:31.07 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:39.25 | *** join/#asterisk-dev qdk (n=qdk@81.7.168.130) |
| 11:57.55 | *** join/#asterisk-dev korihor (n=korihor@200.44.218.45) |
| 12:09.43 | *** join/#asterisk-dev JT (n=j@unaffiliated/jt) |
| 12:36.57 | *** join/#asterisk-dev DarkRift (n=dark@65.92.250.136) |
| 12:46.28 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 12:46.28 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 12:48.57 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 12:51.28 | *** join/#asterisk-dev anonymouz666 (n=anonymou@189.24.79.73) |
| 12:52.53 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:52.53 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 12:55.16 | lmadsen | morning! |
| 13:19.44 | *** join/#asterisk-dev russellb (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 13:19.44 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 13:21.58 | Dovid | lmadsen: Do you know when digium sales opens ? |
| 13:40.02 | lmadsen | Dovid: probably 9:00am CST (-0600 GMT) |
| 13:40.13 | lmadsen | so about an hour and 40 mins from now |
| 14:09.40 | *** join/#asterisk-dev shido6 (n=shido6@96-28-34-156.dhcp.insightbb.com) |
| 14:10.20 | *** join/#asterisk-dev JerJer (n=jmcnamar@c-71-207-221-127.hsd1.al.comcast.net) |
| 14:21.56 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 14:22.55 | agx | oej, do you have a patch file for asterisk 1.4 about the snom feature: call answered else where? |
| 14:23.17 | oej | Yes, there's a branch in my svn directory |
| 14:23.23 | oej | It has some stuff for queue and local as well |
| 14:23.37 | oej | One bug I'm chasing in the queue/local combination is still to be killed |
| 14:24.44 | agx | oej, ok thanks i'll look there |
| 14:38.23 | Damin | This is a new one: WARNING[20416]: channel.c:2120 ast_indicate: Unable to handle indication 3 for 'SIP/pbx-1-09b559b4' |
| 14:38.50 | Damin | Customer complains that they don't hear ringing on inbound.. I'm not surprised considering Asterisk can't handle the indication.. :) |
| 14:40.29 | file | is res_indications loaded and indications.conf in place with the proper indications? |
| 14:41.27 | lmadsen | that 1.4 and CDRs thread is seriously off topic |
| 14:41.42 | file | lmadsen: no kidding. |
| 14:42.44 | Damin | asterisk*CLI> show modules like res_indications.so |
| 14:42.45 | Damin | Module Description Use Count |
| 14:42.45 | Damin | res_indications.so Indications Configuration 0 |
| 14:42.46 | Damin | 1 modules loaded |
| 14:43.20 | *** join/#asterisk-dev IsUp (n=nocturne@unaffiliated/isup) |
| 14:43.23 | IsUp | hello |
| 14:43.26 | Damin | Weird.. |
| 14:43.41 | Damin | there doesn't seem to be an indications.conf file |
| 14:43.51 | IsUp | theres a file on svn => http://svn.digium.com/view/asterisk/trunk/doc/video.txt |
| 14:44.14 | file | Damin: that would be why, so res_indications has no idea how to generate indications... and thus can't generate ringing |
| 14:44.29 | IsUp | i want to playback h263 files but i cannot convert with gstreamer. anyone can help me about format_h263/format_h264? |
| 14:45.00 | Damin | file: Thanks.. perfectly logical solution.. |
| 14:45.28 | Damin | file: Now the question is which idiot deleted the indications.conf file.. It is there in last friday's backup.. |
| 14:45.38 | Damin | file: AHA! History is your friend.. |
| 14:46.19 | Damin | file: Someone tried to delete indications.conf~, but instead deleted indications.conf |
| 14:46.35 | lmadsen | oops |
| 14:46.40 | shido6 | u still have indications.conf~ , right? :) |
| 14:46.48 | shido6 | hope its not empty |
| 14:47.04 | *** join/#asterisk-dev Marquis42 (n=bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 14:47.37 | Damin | shido6: It's fixed. I just restored from the backup and all is well.. |
| 14:47.43 | Damin | shido6: Now to send the bill.. |
| 14:48.11 | davevg-btwtech | The dial app with the g flag should always continue on to the next priority in the dialplan right? I'm seeing cases where it doesn't with the CANCEL dialstatus. Or am i just misunderstanding the flag? |
| 14:50.04 | IsUp | lmadsen :) |
| 14:50.26 | lmadsen | IsUp: eh? |
| 14:51.09 | IsUp | lmadsen: i need help about h263 conversion.. |
| 14:51.27 | russellb | in my indications API rework, Asterisk won't start without indications.conf |
| 14:51.28 | IsUp | at least i am able to play h263 files but which i recorded with Record() |
| 14:51.30 | russellb | that problem happens way too often |
| 14:51.39 | russellb | it's silly that the code treats it as optional IMO |
| 14:52.27 | lmadsen | IsUp: I've never used h263 |
| 14:54.07 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 14:54.07 | IsUp | okay |
| 14:56.07 | oej | russellb: Alive after yet another flight? |
| 14:58.44 | IsUp | oej? |
| 14:58.56 | oej | IsUp? |
| 14:59.01 | oej | echo() |
| 15:00.39 | IsUp | need help about h263 conversion :) theres a file on SVN. edited by you. can you help me? |
| 15:00.40 | lmadsen | echo..cho..cho...cho |
| 15:00.55 | russellb | oej: barely |
| 15:01.03 | oej | IsUp: Sorry, I get that question too often. Check the archives of asterisk-video |
| 15:01.21 | oej | russellb: Well, I only had a two hour flight, but landed a bit too late tonight. |
| 15:01.32 | IsUp | oej, theres nothing useful on asterisk-video |
| 15:01.48 | oej | IsUp: Then help us write something when you figure it out. :-) |
| 15:02.12 | IsUp | ah sure, i'll lol |
| 15:03.09 | oej | I would search ffmpeg. They have some sort of adaption to our strange format, which is more or less raw rtp data |
| 15:05.06 | *** join/#asterisk-dev moy (n=chatzill@74.12.131.188) |
| 15:11.53 | *** join/#asterisk-dev JerJer (n=jmcnamar@router.asteriasgi.com) |
| 15:12.04 | *** join/#asterisk-dev sruffell (n=sruffell@nat/digium/x-6b12640cfc97d381) |
| 15:12.04 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:14.00 | IsUp | oej: ffmpeg is not supporting it. gstreamer has a plugin i think but i cant find it. |
| 15:14.09 | IsUp | something named 'asteriskh263' |
| 15:17.08 | *** join/#asterisk-dev schmooze (n=schmooze@h69-129-142-83.mdsnwi.tisp.static.tds.net) |
| 15:28.59 | *** join/#asterisk-dev Mw3 (n=mw3@ip59934bd1.rubicom.hu) |
| 15:40.26 | *** join/#asterisk-dev Deeewayne (n=Deeewayn@nat/digium/x-6e8792751b478f1e) |
| 15:40.26 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:46.07 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:46.07 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:51.50 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 16:08.43 | *** join/#asterisk-dev CunningPike (n=arodgers@vpn.dnv.org) |
| 16:24.48 | korihor | sruffell: on http://bugs.digium.com/view.php?id=14451#c99797 I don't believe was hardware specific because my card work with kernel version 2.6.24.7 :( |
| 16:28.46 | sruffell | korihor: hmm....ok...that is a good piece of news. I sent you a follow on email since I know even if you contacted customer support it will be assigned to me. It is just that customers will get better support using the tech support infrastructure we have here rather than waiting for me to get to an issue on the bug tracker. |
| 16:29.09 | sruffell | actually, not a good piece of news, but rather a good data point for resolving the issue. |
| 16:33.42 | korihor | sruffell: I need call DIgium support? or try testing with other kernel version more new that 26.24.7 and minor that 2.6.28.4? |
| 16:40.55 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:44.07 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 16:44.07 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:51.44 | *** join/#asterisk-dev sruffell1 (n=sruffell@nat/digium/x-667b6012382b1b92) |
| 17:05.37 | *** join/#asterisk-dev putnopvut (n=putnopvu@nat/digium/x-bf97232f8d4dceab) |
| 17:05.37 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 18:01.13 | *** join/#asterisk-dev codefreeze-lap (n=murf@72.21.67.40) |
| 18:01.13 | *** mode/#asterisk-dev [+o codefreeze-lap] by ChanServ |
| 18:37.59 | *** join/#asterisk-dev joshaidan (n=joshaida@S01060090f8009fa6.tb.shawcable.net) |
| 18:55.04 | *** join/#asterisk-dev JerJer_ (n=jmcnamar@router.asteriasgi.com) |
| 19:10.16 | Qwell | JerJer: :D |
| 19:20.23 | JerJer | what be up? |
| 19:21.36 | Qwell | JerJer: not too much. it all official now? |
| 19:22.15 | JerJer | it? i have officially moved to Huntsville |
| 19:22.30 | Qwell | cool. should come have lunch sometime |
| 19:22.53 | JerJer | and get a coffee at Beans and Bytes :D |
| 19:22.53 | lmadsen | he's not allowed to fraternize with Qwell's |
| 19:23.01 | Qwell | JerJer: that too |
| 19:23.15 | Qwell | JerJer: remind me to give you a card so I can get a free coffee :P |
| 19:23.19 | lmadsen | wonders if DigiYums was ever suggested as a name |
| 19:23.55 | lmadsen | patent pending! |
| 19:23.56 | lmadsen | :) |
| 19:26.00 | jpeeler | lmadsen: it was |
| 19:28.17 | lmadsen | cool, glad I didn't just think of it way after the contest :) |
| 19:30.25 | *** join/#asterisk-dev CunningPike (n=arodgers@vpn.dnv.org) [NETSPLIT VICTIM] |
| 19:30.25 | *** join/#asterisk-dev korihor (n=korihor@200.44.218.45) [NETSPLIT VICTIM] |
| 19:30.25 | *** join/#asterisk-dev Simon-- (n=sim@staff-nat.netnation.com) [NETSPLIT VICTIM] |
| 19:30.25 | *** join/#asterisk-dev unpaidbill (n=bill@alteredbeastiality.org) [NETSPLIT VICTIM] |
| 19:30.25 | *** join/#asterisk-dev CtRiX (n=CtRiX@aretha.navynet.it) [NETSPLIT VICTIM] |
| 19:30.26 | *** join/#asterisk-dev Atom23 (n=dragxsla@653295hfc172.tampabay.res.rr.com) |
| 19:57.19 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 19:57.19 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 20:27.38 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 20:27.38 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 20:34.05 | JerJer | anyone know, off the top, how to make iptables -L not do dns lookups? (ie display IP addresses) |
| 20:34.59 | jamessan | iptables -Ln |
| 20:35.34 | JerJer | hmm i tried that |
| 20:35.43 | JerJer | iptables: No chain/target/match by that name |
| 20:35.51 | JerJer | even broke out -n |
| 20:36.00 | JerJer | oh well - no biggy |
| 20:36.10 | jamessan | er, -nL |
| 20:39.40 | JerJer | gotcha - sweet |
| 20:39.57 | JerJer | thank you |
| 20:40.08 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 20:40.08 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 20:46.36 | *** join/#asterisk-dev VoipForces (n=courchea@67.55.25.221) |
| 20:47.47 | VoipForces | Looking at the code (1.4.x) of parkandpage and trying to find a reason/fix to be able to announce to multiple extensions. I tries direct SIP/1&SIP/2 or through LOCAL and still does not work. |
| 20:47.51 | VoipForces | Any hints? |
| 20:50.05 | lmadsen | only the first channel that answered would get the call |
| 20:50.14 | lmadsen | (the announce) |
| 20:50.47 | lmadsen | you'd have to do something where you "Page" the two users, put them into a conference, then pageandannounce, and put them into the same conference room |
| 20:51.04 | VoipForces | hmmm. I was trying to announce the park through a page (using SIP headers...) |
| 20:51.25 | lmadsen | right, but you won't get two phones to hear at the same time because asterisk will only allow one of them to answer |
| 20:51.31 | lmadsen | this is really a #asterisk question though |
| 20:51.42 | VoipForces | I know tried it there first... |
| 20:52.25 | lmadsen | note that this isn't level 2 support :) |
| 20:52.48 | VoipForces | Thanks. I'll reork my code to do it in 2 steps. |
| 20:52.58 | lmadsen | you mean your dialplan right? |
| 20:53.19 | VoipForces | my dialplan and pho webapp code. |
| 20:53.23 | lmadsen | ah |
| 20:53.24 | VoipForces | php |
| 20:53.31 | lmadsen | ya, this room is more for development of C level asterisk code |
| 20:54.31 | VoipForces | True and aware of that. Thanks again for the confirmation. |
| 20:54.44 | *** part/#asterisk-dev VoipForces (n=courchea@67.55.25.221) |
| 21:02.41 | *** join/#asterisk-dev ta^3 (n=tacvbo@189.146.172.59) |
| 21:04.34 | *** join/#asterisk-dev CunningPike (n=arodgers@S01060014bf81366b.vc.shawcable.net) |
| 21:08.01 | putnopvut | hates it when he accidentally hits 'u' instead of 'i' when using vim :( |
| 21:08.27 | jamessan | good thing there's <C-r> |
| 21:09.37 | putnopvut | yep |
| 21:11.29 | seanbright | "Tone zones are now managed using astobj2, and it is no longer possible to crash Asterisk by issuing a reload while tone zones are in use." |
| 21:11.34 | seanbright | that sounds like a challenge to me |
| 21:12.00 | russellb | :-p |
| 21:12.02 | ScribbleJ | I personally hate it when I hit :%s/.//g<return>:wq!<return> instead of 'i'. Happens all the time, the keys are like right next to each other. |
| 21:12.42 | seanbright | ScribbleJ: http://bash.org/?5300 (bad language ahoy) |
| 21:12.57 | russellb | seanbright: but seirously ... the way the API was written .. if you reloaded while _any_ tone zone was in use, like, say, stored on an ast_channel because you set it ... it would crash. wtf? |
| 21:13.05 | ScribbleJ | Hahaha, yeah, I'm aware of that, probably where my subconscious pulled the phrase from. Hehe |
| 21:13.32 | russellb | seanbright: I have no idea how nobody ever complained about it |
| 21:13.36 | seanbright | russellb: yeah, that's scary. |
| 21:13.49 | seanbright | is this in 1.4? |
| 21:13.56 | russellb | it is in 1.4, as well |
| 21:13.58 | russellb | patch is against trunk |
| 21:14.00 | russellb | since it's so invasive |
| 21:14.00 | seanbright | fun |
| 21:14.11 | russellb | shrugs |
| 21:14.43 | russellb | I might be able to come up with a much less invasive version for 1.4 |
| 21:15.27 | seanbright | any bugs related to this in mantis? |
| 21:15.30 | russellb | nope. |
| 21:15.33 | seanbright | wow |
| 21:15.36 | russellb | just something i came across in my days. |
| 21:15.45 | seanbright | gotcha |
| 21:16.37 | russellb | I suspect I know why it never got reported ... because it would proabably only affect people using a system where they actually make use of multiple tone zones |
| 21:16.44 | russellb | instead of just setting the system wide default to a single locale |
| 21:16.53 | file | right |
| 21:17.07 | seanbright | i don't think i've ever even editted that file |
| 21:17.07 | russellb | ok, so that explains it. |
| 21:17.19 | file | the chance of someone using multiple tone zones PLUS editing them and reloading is rather slim |
| 21:17.22 | russellb | yeah, most people don't, and the ones that do, change the one line that configures the default |
| 21:17.27 | russellb | file: it wasn't just editing them |
| 21:17.31 | russellb | file: it's _any_ reload |
| 21:17.36 | russellb | file: when they're in use ... |
| 21:17.42 | file | russellb: not... quite |
| 21:17.49 | file | well |
| 21:17.53 | file | in older versions I suppose so |
| 21:19.05 | russellb | unless i'm reading it wrong ... looking at 1.4, on a reload, it goes through and frees every tone zone and then rebuilds them all |
| 21:20.10 | russellb | nope, that isn't supported in 1.4 |
| 21:20.13 | *** join/#asterisk-dev CunningPike_ (n=arodgers@vpn.dnv.org) |
| 21:20.44 | russellb | so, it only does that in trunk/1.6 |
| 21:22.47 | russellb | i lied again, they do get free'd in 1.4, as well |
| 21:22.54 | russellb | anyway, i'll shut up now |
| 21:23.46 | file | gives russellb a drink |
| 21:24.10 | putnopvut | steals it |
| 21:24.27 | Corydon76-dig | spikes it with redbull |
| 21:24.35 | putnopvut | unsteals it |
| 21:28.04 | Corydon76-dig | putnopvut: you don't like Redbull? |
| 21:28.12 | putnopvut | Corydon76-dig: not particularly. |
| 21:28.27 | putnopvut | I'll drink Jaeger bombs and Redbull & Vodka, but not Redbull straight up. |
| 21:28.31 | Corydon76-dig | putnopvut: How about 5-hour energy? |
| 21:28.36 | putnopvut | Never tried it. |
| 21:28.47 | putnopvut | I guess I don't really feel the need for energy drinks. |
| 21:28.53 | Corydon76-dig | Remind me and I'll bring a bottle next Monday |
| 21:29.12 | ScribbleJ | Is it just me, or does Redbull and Vodka taste rather deliciously like Smarties, the candy? |
| 21:29.22 | mnicholson | it seems like it is possible for unloading an application to crash asterisk if another thread is between calls to pbx_findapp() and pbx_exec(), the result of pbx_findapp() should be ref counted |
| 21:29.29 | Corydon76-dig | We might be able to scrape you off the ceiling after our 1:00 meeting |
| 21:29.45 | russellb | mnicholson: add to the list. there are many problems like that in asterisk :-( |
| 21:29.46 | putnopvut | Can I just refuse? |
| 21:29.48 | russellb | mnicholson: but you are correct. |
| 21:30.02 | Corydon76-dig | putnopvut: it's just B-vitamins |
| 21:30.14 | putnopvut | That doesn't answer my question. |
| 21:30.14 | Corydon76-dig | putnopvut: no sugar |
| 21:30.41 | Corydon76-dig | No, you cannot refuse. ;-) |
| 21:30.49 | mnicholson | we will fix them all! |
| 21:31.34 | *** join/#asterisk-dev Mw3 (n=mw3@ip59934bd1.rubicom.hu) |
| 21:31.56 | Corydon76-dig | wonders if the other Mark has had 5-hour |
| 21:32.16 | putnopvut | wow, manager sessions have a lot more verbose messages in trunk than in 1.6.0 |
| 21:32.25 | putnopvut | at least http sessions do. |
| 21:32.57 | russellb | mnicholson: yay :-) |
| 21:34.02 | Corydon76-dig | One ring to fix them all, And in the darkness find them |
| 21:34.14 | ScribbleJ | Oh boy. |
| 21:34.45 | Corydon76-dig | s/ring/tool/ |
| 21:36.19 | Corydon76-dig | Anybody know of an electricfence-like tool for stack variables? |
| 21:37.12 | russellb | it would have to be something built in to the compiler i suppose ... |
| 21:37.17 | putnopvut | I don't know if that can be done. Even valgrind can't handle that. |
| 21:37.31 | russellb | right, you can't write a lib or an external tool to do it |
| 21:37.41 | Corydon76-dig | Yeah, valgrind not being able to handle it is why I want a tool for it |
| 21:38.05 | Corydon76-dig | russellb: you can't write a lib to wrap function calls? |
| 21:38.14 | mnicholson | Corydon76-dig, isn't there a new gcc feature that can detect that? |
| 21:38.38 | Corydon76-dig | mnicholson: I'd love if there was. Any idea what it is called? |
| 21:38.46 | russellb | there is a stack smashing thing you can enable in gcc |
| 21:38.55 | kpfleming | -fstack-protector |
| 21:39.01 | russellb | but that doesn't check individual variables |
| 21:39.34 | mnicholson | i though there was some feature enabled by default in ubuntu 8.10 that was causing something to fail to build that kpfleming was talking about one day |
| 21:40.04 | putnopvut | mnicholson: ah, I remember that... It was some environment variable that's set. |
| 21:40.10 | putnopvut | set to 2, specifically. |
| 21:40.14 | mnicholson | right |
| 21:40.15 | putnopvut | But I can't remember the variable name. |
| 21:50.10 | kpfleming | you are thinking of FORTIFY_SOURCE, which is a compile-time define |
| 21:50.29 | kpfleming | _FORTIFY_SOURCE, to be specific |
| 21:50.47 | Corydon76-dig | I'm also looking at -fstack-check |
| 22:02.00 | *** join/#asterisk-dev qdk (n=qdk@94.191.242.60.bredband.3.dk) |
| 22:02.18 | Corydon76-dig | -fstack-check appears not to work whenever we allocate larger buffers on the stack |
| 22:02.28 | Corydon76-dig | Meaning, pretty much useless for us |
| 22:03.00 | kpfleming | what is 'larger'? |
| 22:03.15 | Corydon76-dig | e.g. char buf[4096] |
| 22:03.25 | kpfleming | really enjoys people using relative terms with no basis of comparison |
| 22:04.01 | Corydon76-dig | Maybe it's all buffers on the stack |
| 22:04.15 | russellb | wonders what exactly it _does_ do |
| 22:04.38 | russellb | it checks the stack to make sure it still exists |
| 22:05.22 | kpfleming | by writing to it repeatedly? |
| 22:06.35 | russellb | it just constantly checks the base pointer register for a value ... any value ... |
| 22:06.36 | Corydon76-dig | It says it generates code to ensure that you don't go beyond the boundary |
| 22:06.50 | Corydon76-dig | of the stack |
| 22:06.57 | russellb | so, checks for stack overflow |
| 22:07.13 | russellb | ? |
| 22:07.22 | Corydon76-dig | but then it says it doesn't actually check anything; it just ensures the OS can detect it |
| 22:07.31 | Corydon76-dig | So I'm a bit confused, too |
| 22:08.36 | mnicholson | -fstack-check looks like it is in place to help the os detect stack overflows |
| 22:09.11 | Corydon76-dig | mnicholson: what does that actually mean, though? |
| 22:09.51 | Corydon76-dig | What does the OS normally do that makes this option make the OS more able to do? |
| 22:10.12 | ScribbleJ | It may have to do with the sstack protection support in the linux kernel. But I thought that was just about randomizing the stack location. |
| 22:11.26 | mnicholson | Corydon76-dig, yeah, not sure there |
| 22:11.45 | mnicholson | perhaps the os normally segfaults |
| 22:11.55 | putnopvut | Typically stack overflows result in a segfault |
| 22:13.21 | Corydon76-dig | putnopvut: only when the return pointer points to nonaddressable memory |
| 22:13.59 | JerJer | do think blow things up often here in Huntsville? i've been hearing booms all day |
| 22:14.09 | JerJer | they * |
| 22:16.01 | Corydon76-dig | I haven't heard that on Mondays, ever, I don't think |
| 22:16.23 | putnopvut | JerJer: yes, yes they do. |
| 22:16.39 | putnopvut | If asteria is near the arsenal, you'll hear explosions from time to time. |
| 22:16.47 | kpfleming | they are |
| 22:17.08 | JerJer | fun |
| 22:17.08 | putnopvut | it's been so long since I've been to asteria. Is it still on bob wallace? |
| 22:17.17 | JerJer | yeah |
| 22:17.35 | JerJer | putnopvut: ^ |
| 22:18.40 | kpfleming | geez... in chan_sip.c, we have if (option_debug > 1) followed by if (debug) followed by ast_verbose |
| 22:18.52 | kpfleming | so if global debug is on, and local debug is on, then generate a verbose message |
| 22:18.56 | kpfleming | that is just stupid |
| 22:19.16 | putnopvut | no kidding. |
| 22:19.16 | JerJer | crack the whipp |
| 22:20.52 | putnopvut | heh, I think I found the place you're talking about. |
| 22:20.55 | putnopvut | SDP parsing code. |
| 22:21.25 | kpfleming | yes |
| 22:24.17 | mnicholson | that should probably be if (debug) |
| 22:24.26 | mnicholson | or maybe not |
| 22:24.42 | mnicholson | if global debug is on, and sip debug is on, then those messages are printed on the console |
| 22:24.43 | kpfleming | it's just non-sensical |
| 22:24.51 | kpfleming | right, but they are not on the debug log channel |
| 22:25.02 | mnicholson | true |
| 22:25.03 | kpfleming | so if you have debug sent to a file, they won't be in it |
| 22:25.25 | mnicholson | is there a way for that code to check if you have debug being sent to the console? |
| 22:25.30 | kpfleming | no |
| 22:25.32 | kpfleming | it should not care |
| 22:25.38 | mnicholson | so it should probably just check debug then |
| 22:25.42 | kpfleming | it should NOT be using verbose for something controlled by debug |
| 22:25.47 | kpfleming | it should be using ast_log(LOG_DEBUG) |
| 22:25.54 | kpfleming | which is what option_debug is for |
| 22:26.08 | kpfleming | but, nearly all of chan_sip is broken in that way, so it's not worth trying to fix |
| 22:26.38 | russellb | that's how all of sip debug is |
| 22:27.00 | russellb | well, probably not all of it ... |
| 22:27.15 | kpfleming | no, it's consistently inconsistent |
| 22:27.18 | russellb | nods |
| 22:27.25 | russellb | i can see the if (debug) part |
| 22:27.26 | mnicholson | i suppose the original author decided that sip debug did not belong in the debug log, but at the same time only wanted to display certain messages if global debug was on |
| 22:27.38 | kpfleming | you could suppose that |
| 22:27.43 | russellb | to control the verbosity of sip debug most likely |
| 22:27.44 | kpfleming | but i doubt it was that well thought out :-) |
| 22:27.49 | mnicholson | heh |
| 22:28.02 | russellb | let's not hate on our own developers :-) |
| 22:28.12 | kpfleming | i also just found a function in rtp.h that returns a struct rtpPayloadType, which is undefined |
| 22:28.35 | kpfleming | it is defined in rtp.c, but the only place that uses that function is chan_h323.c, which has its own copy of the structure definition |
| 22:29.07 | mnicholson | can you make gcc fail if something is not defined? |
| 22:29.19 | kpfleming | not in that way, no |
| 22:29.37 | mnicholson | i believe g++ does it |
| 22:30.14 | kpfleming | although it will warn for structures declared in parameter lists, so it should be able to warn for structures declared as return types |
| 22:30.31 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 22:32.11 | Corydon76-dig | But we do return structures in some cases... ast_tvnow(), for example |
| 22:32.47 | putnopvut | the problem is that the structure is not publicly defined. |
| 22:33.11 | kpfleming | correct |
| 22:33.15 | Corydon76-dig | putnopvut: I'm not sure that the compiler can know that, though |
| 22:33.16 | kpfleming | the function is useless |
| 22:33.19 | kpfleming | yes it can |
| 22:33.30 | Corydon76-dig | Maybe the preprocessor can |
| 22:33.39 | kpfleming | try putting in a prototype that takes a 'struct corydon *' without defining 'struct corydon' |
| 22:33.44 | kpfleming | as an argument, i mean |
| 22:33.54 | russellb | kpfleming: is it defined privately before the header is included? |
| 22:33.56 | kpfleming | the preprocessor knows nothing of that stuff |
| 22:34.05 | kpfleming | russellb: in rtp.c yes |
| 22:34.17 | Corydon76-dig | kpfleming: as an argument or as a return type? |
| 22:34.21 | kpfleming | well, maybe not, i didn't check |
| 22:34.21 | russellb | and chan_h323? |
| 22:34.26 | kpfleming | Corydon76-dig: parameter list, argument |
| 22:34.31 | russellb | would explain why it compiles if so ... |
| 22:34.39 | Corydon76-dig | kpfleming: you can do that just fine |
| 22:34.49 | russellb | but doesn't explain why chan_sip would compile .. |
| 22:34.50 | Corydon76-dig | kpfleming: we do that already in pbx.h |
| 22:34.51 | russellb | silly gcc |
| 22:35.04 | kpfleming | we should not be doing that anywhere |
| 22:35.05 | Corydon76-dig | We have opaque types, like struct ast_context |
| 22:35.12 | kpfleming | those are forward defined |
| 22:35.18 | kpfleming | there is a line 'struct ast_context;' |
| 22:35.32 | kpfleming | you missed the point... this was not defined *anywhere* except in rtp.c |
| 22:35.53 | Corydon76-dig | No, I got the point. I just don't know if the compiler can be smart enough to tell us about that |
| 22:35.54 | *** join/#asterisk-dev mbranca (n=matteo@93-62-230-243.ip24.fastwebnet.it) |
| 22:36.00 | kpfleming | it already does |
| 22:36.05 | kpfleming | that's why i said you should try it |
| 22:36.21 | kpfleming | of course it can be smart enough, it has to know whether a type has been fully defined or not |
| 22:36.38 | mnicholson | i am pretty sure none of that would fly with c++, so it certainly can detect that |
| 22:38.25 | mnicholson | it appears i am wrong, my test code compiles fine |
| 22:39.05 | Corydon76-dig | mnicholson: the reason is that the compiler doesn't need to know the size of the structure, because you've declared it as a pointer |
| 22:39.16 | Corydon76-dig | and it already knows the size of a pointer |
| 22:39.33 | kpfleming | but if there is no forward definition, it should still complain about the structure type being defined in a parameter list |
| 22:39.50 | mnicholson | so only if i try to do something like a->b will it complain |
| 22:39.51 | kpfleming | i've seen it happen plenty of times |
| 22:39.53 | kpfleming | yes |
| 22:40.03 | Corydon76-dig | mnicholson: right |
| 22:40.05 | kpfleming | among others |
| 22:40.28 | Corydon76-dig | You definitely can't deref an undefined structure |
| 22:48.55 | Corydon76-dig | mnicholson: you need -Wmissing-declarations to get gcc to warn you in that case |
| 22:49.28 | kpfleming | yes, that's the one i was thinking of |
| 22:49.41 | putnopvut | ugh, app_chanspy in trunk is subject to stack overflows :( |
| 22:49.44 | kpfleming | but apparently it does not warn about missing declarations for function return values |
| 22:50.29 | Corydon76-dig | OIC... |
| 22:51.32 | kpfleming | i suppose gcc 4.4 might, but that is not yet ready for consumption |
| 22:51.33 | Corydon76-dig | If a function is declared first that returns that structure pointer, then any functions following it can encode the structure pointer as a parameter without a forward declaration... |
| 22:51.51 | kpfleming | no, that's not a declaration |
| 22:51.58 | kpfleming | and this case, it wasn't a structure pointer, it was the actual structure |
| 22:52.25 | Corydon76-dig | I'm telling you gcc behavior. I just verified it. |
| 22:52.41 | kpfleming | well, that's fairly broken then |
| 22:54.47 | Corydon76-dig | It's an interesting case, even if we aren't going to depend upon that behavior |
| 22:57.53 | *** join/#asterisk-dev mbranca (n=matteo@93-62-230-243.ip24.fastwebnet.it) |
| 23:32.15 | *** join/#asterisk-dev lbt_ (n=david@78.32.229.233) |
| 23:32.24 | *** part/#asterisk-dev lbt_ (n=david@78.32.229.233) |
| 23:35.31 | *** join/#asterisk-dev lbt_ (n=david@78.32.229.233) |
| 23:35.48 | lbt_ | would this be the place to bring up "segfault at 99cb712c ip 080cf5d2 sp b72d2004 error 6 in asterisk[8048000+155000]" or should I hang in #asterisk ? |
| 23:38.31 | Corydon76-dig | error 6? |
| 23:39.01 | Corydon76-dig | Are you running on an Intel platform? |
| 23:39.46 | lbt_ | Corydon76-dig: me? |
| 23:39.52 | Corydon76-dig | You |
| 23:39.52 | lbt_ | yes I am |
| 23:40.07 | lbt_ | Hi, I'm new here... My setup is working quite nicely but I am having repeatable crashes. Asterisk is 1.6.1-rc1. I have an X100P (uk) and whenever I try to make a PSTN call I get this if the mwi monitor is running...http://pastebin.com/d6851d8bb |
| 23:40.15 | Corydon76-dig | You first need to obtain a backtrace, as detailed in doc/backtrace.txt |
| 23:40.34 | lbt_ | OK - then come back here? or go to #asterisk ? |
| 23:40.49 | Corydon76-dig | Report the issue at http://bugs.digium.com/ |
| 23:41.24 | lbt_ | ok - wasn't sure if you used irc to triage things first... |
| 23:41.44 | Corydon76-dig | Nope, the bugtracker is for that |
| 23:42.00 | lbt_ | cool, every project is different :) |
| 23:42.03 | Corydon76-dig | but getting a backtrace is the first thing we'd ask for in the case of a crash like that |
| 23:42.32 | lbt_ | well, it's in the rc1 and reproducable - but I'm new enough that it could easily be me |
| 23:42.35 | Corydon76-dig | Depending upon the output, we may ask for additional things out of gdb or valgrind or another set of debugging steps |
| 23:42.58 | Corydon76-dig | You shouldn't be able to easily crash Asterisk |
| 23:43.08 | putnopvut | but yet it seems to happen ;) |
| 23:43.10 | lbt_ | my thoughts exactly |
| 23:44.09 | Corydon76-dig | I've found another way to crash Asterisk, recently, although the likelihood of anybody actually doing it is remote |
| 23:44.48 | lbt_ | until you give it to a real user..... |
| 23:44.57 | putnopvut | lol |
| 23:45.06 | Corydon76-dig | putnopvut: each recursion through pbx_substitute_variables_helper takes up over 12k of stack space. Given enough recursion, you can crash Asterisk with a variable substitution string |
| 23:45.26 | putnopvut | 12k?!! |
| 23:45.33 | Corydon76-dig | Heh, yep |
| 23:45.48 | Corydon76-dig | 3 stack buffers of 4096 bytes apiece |
| 23:45.58 | putnopvut | are you addressing this in your ast_str substitution branch? |
| 23:46.11 | Corydon76-dig | It's one I discovered by rewriting that function |
| 23:46.29 | Corydon76-dig | and yes. |
| 23:46.43 | Corydon76-dig | The buffers get allocated on the heap instead of the stack, now |
| 23:47.28 | Qwell | Corydon76-dig: so like...${${${${${${blah}}}}}} ? |
| 23:47.37 | Corydon76-dig | Qwell: yep |
| 23:47.42 | Qwell | fun |
| 23:48.44 | *** join/#asterisk-dev JerJer (n=jmcnamar@c-71-207-221-127.hsd1.al.comcast.net) |
| 23:48.49 | Corydon76-dig | The other nice thing is that if someone really wants a substitution longer than 4k, they can now have it |
| 23:49.36 | Corydon76-dig | I don't really understand WHY, but they can |
| 23:49.41 | putnopvut | lol |
| 23:49.53 | Corydon76-dig | Actually, I do know of one reason |
| 23:50.08 | putnopvut | ${THE_ENTIRE_CONTENTS_OF_ENCYCLOPEADIA_BRITANNICA} |
| 23:50.16 | Corydon76-dig | calling Page with a bazillion SIP devices |
| 23:51.22 | Corydon76-dig | May not be completely wise, but it's possible |
| 23:51.41 | putnopvut | Corydon76-dig: wanna see something absolutely terrible? Take a look at app_voicemail.c |
| 23:51.55 | putnopvut | Take a look at what the function apply_option does when it comes to the option "options" |
| 23:52.05 | putnopvut | Now imagine a voicemail.conf file that does something like: |
| 23:52.32 | Corydon76-dig | options=options=options=options=... |
| 23:52.34 | putnopvut | 8888 => 7734,POOP,,,options=options=options=options=options=options=options=options=options=options=options=options=options=options=options=options=options=options... |
| 23:52.42 | putnopvut | yes |
| 23:52.48 | Corydon76-dig | Yep |
| 23:52.53 | putnopvut | luckily, the stack frames are very small |
| 23:53.01 | Corydon76-dig | recursion city |
| 23:53.03 | putnopvut | so you'd have to do it a *whole* lot to overflow the stack. |
| 23:53.11 | Qwell | wait |
| 23:53.19 | Qwell | I just had a silly thought |
| 23:53.41 | Qwell | I wonder how many GUIs support putting a , in your VM password. |
| 23:54.05 | putnopvut | hopefully none of them. |
| 23:54.10 | putnopvut | but I see where you're going. |
| 23:54.22 | putnopvut | password: ,,,options=options=options... |
| 23:54.22 | *** join/#asterisk-dev telecos (n=sergio@67.167.219.87.dynamic.jazztel.es) |
| 23:54.36 | Qwell | putnopvut: pretty much |
| 23:54.48 | Qwell | or not even that.. just set any arbitrary option |