| 00:02.42 | *** join/#asterisk-dev RoyK (n=roy@ip-18-22-149-91.dialup.ice.no) |
| 00:03.50 | *** join/#asterisk-dev atisss (n=atis@193.238.213.215) |
| 00:03.58 | atisss | hey |
| 00:04.33 | atisss | i just found out that res_monitor isn't audiohook'ed |
| 00:05.13 | file | correct, app_mixmonitor is... if res_monitor was rewritten to use audiohooks, it would just be app_mixmonitor with a different name |
| 00:05.19 | file | they do things differently. |
| 00:05.33 | atisss | well, yes |
| 00:05.51 | atisss | the only difference is that res_monitor creates two files |
| 00:06.10 | atisss | well, but isn't there a conflict between non-audiohooks and audiohooks |
| 00:06.44 | file | define conflict |
| 00:06.52 | atisss | emm, some locking problems |
| 00:07.04 | file | nope. |
| 00:07.34 | atisss | really? i thought audiohooks is the only way how i could reliably use monitor and chanspy together |
| 00:08.10 | file | nope... |
| 00:08.20 | *** part/#asterisk-dev RoyK (n=roy@ip-18-22-149-91.dialup.ice.no) |
| 00:08.27 | file | res_monitor doesn't really interact with or mess with the audiohooks stuff at all |
| 00:08.45 | file | and I have never heard of it causing an issue with even the old spy architecture |
| 00:09.00 | atisss | hmm, i have read it somewhere |
| 00:09.09 | atisss | and i was having crashes too |
| 00:09.13 | atisss | well.. |
| 00:11.19 | atisss | However, the implementation has been problematic. It has been a long road of crashes and deadlocks that has caused the underlying code to be re-written multiple times. The Audiohooks is the latest chapter in the saga of ChanSpy and MixMonitor. |
| 00:11.26 | atisss | rusellbryant.net |
| 00:11.32 | file | correct. |
| 00:12.10 | atisss | i still don't get - what's the difference of monitor and mixmonitor - except 2 files vs 1 |
| 00:13.01 | file | Monitor has been around a long time and is directly hooked into the relative functions for reading and writing frames from a channel... it's directly stuck in there, and it gets frames from each and puts 'em in the respective file |
| 00:13.30 | file | MixMonitor uses the audiohooks stuff which works on a larger scale to allow all sorts of applications to hook into the audio |
| 00:14.37 | atisss | well, but previous mixmonitor - that didn't had audiohooks |
| 00:14.38 | file | it used the old spy architecture, same idea - different implementation |
| 00:14.38 | atisss | it was doing the same |
| 00:14.38 | atisss | and chanspy the same |
| 00:14.44 | atisss | and somewhere there was a problem |
| 00:14.48 | file | yes. |
| 00:15.11 | *** join/#asterisk-dev Shaun2222 (n=Shaun222@ip68-4-127-67.oc.oc.cox.net) |
| 00:15.37 | atisss | well, i'm afraid that problem is still there because old res_monitor hooks on channel, and audiohooks does the same |
| 00:15.56 | atisss | ok, i don't know the internals - but that's my view |
| 00:16.11 | file | what is the current issue? |
| 00:16.15 | atisss | if you want, i could launch my tests with latest patch for night, and see how it's going |
| 00:16.27 | atisss | emm, chanspy crash |
| 00:16.39 | file | that chanspy crash has nothing to do with res_monitor or audiohooks |
| 00:16.46 | atisss | i hoped that with audiohooks it would finally be stable |
| 00:16.56 | Shaun2222 | hmm whats res_telepathy for? |
| 00:17.30 | file | it's a locking issue, and russellb is presently working on the final fix for it |
| 00:17.40 | atisss | ok, so i'm back to testing with russel's patch |
| 00:24.04 | atisss | ok, have a good night |
| 00:24.25 | file | have a pleasant evening |
| 00:26.32 | russellb | app_chanspy locking is quite complicated |
| 00:27.30 | tzafrir | Shaun2222, http://telepathy.freedesktop.org/ (not) |
| 00:48.00 | JerJer | is jpeeler a new comitter ? |
| 00:48.17 | file | new employee |
| 00:48.27 | JerJer | ok - i spoze |
| 00:48.51 | file | learning things here and there |
| 00:49.55 | JerJer | just keeping one eyeball on the svn logs :) |
| 01:02.09 | *** join/#asterisk-dev outtolunc (n=me@c-67-174-216-60.hsd1.ca.comcast.net) |
| 01:02.52 | outtolunc | sorry to be lazy, i can't remember, did queue ack get dropped in 1.4+ |
| 01:03.11 | outtolunc | ack_call that is |
| 01:07.06 | outtolunc | braindead, it was chan_agent and it is still there... |
| 01:16.04 | *** join/#asterisk-dev anthm (n=anthm@70-9-24-37.area4.spcsdns.net) |
| 01:16.04 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 01:17.51 | *** join/#asterisk-dev RoyK (n=roy@ip-87-8-149-91.dialup.ice.no) |
| 01:39.36 | *** join/#asterisk-dev jeffg (i=Hdn3KkIl@pdpc/supporter/active/jeffg) |
| 02:13.39 | *** join/#asterisk-dev anthm (n=anthm@68-29-144-6.area4.spcsdns.net) |
| 02:13.39 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 02:29.31 | *** join/#asterisk-dev tengulre (n=tengulre@125.71.208.16) |
| 02:29.46 | tengulre | anybody here working for digium? |
| 02:30.31 | denon | if your looking for sales or tech support, this probably isn't the place |
| 02:30.37 | denon | [you're] |
| 03:22.39 | *** join/#asterisk-dev puzzled (n=patrick@puzzled.xs4all.nl) |
| 03:32.32 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 03:32.32 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 04:07.01 | *** join/#asterisk-dev bkruse_home (n=kruz@76.73.154.120) |
| 04:07.01 | *** mode/#asterisk-dev [+o bkruse_home] by ChanServ |
| 04:24.35 | JerJer | fo shissle |
| 04:28.30 | *** join/#asterisk-dev bkruse_home (n=kruz@76.73.154.120) |
| 04:28.31 | *** mode/#asterisk-dev [+o bkruse_home] by ChanServ |
| 06:57.33 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 06:57.33 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:01.13 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 07:38.07 | *** join/#asterisk-dev tzafrir (n=tzafrir@62.90.10.53) |
| 07:38.07 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 08:03.47 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 08:15.17 | *** join/#asterisk-dev jbot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 08:15.17 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- IAX2/guest@misery.digium.com/asterisk-dev -=- Asterisk trunk: res_telepathy release tomorrow-=- Tier 2 and Tier 3.14159 support is in #asterisk -=- Lost: Sanity Found: Banana |
| 08:19.56 | oej | Morning |
| 08:25.43 | *** join/#asterisk-dev qdk (n=qdk@85.235.253.139) |
| 08:41.40 | snuff-work | hello eok |
| 08:41.49 | snuff-work | *oej even |
| 08:42.07 | oej | he he |
| 09:01.39 | snuff-work | mmm.. failing on __WORDSIZE.. |
| 09:01.56 | *** join/#asterisk-dev Sajjad_Ali_Musht (n=Sajjad_A@octroi.enst-bretagne.fr) |
| 10:28.44 | mvanbaak | mornin |
| 11:17.47 | *** join/#asterisk-dev BBHoss (n=hoss@c-71-207-173-38.hsd1.al.comcast.net) |
| 11:24.35 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 11:37.07 | _ys | hi, hm asterisk-commit channel are dead? |
| 11:46.32 | *** join/#asterisk-dev RoyK (n=roy@ip-58-8-149-91.dialup.ice.no) |
| 11:50.53 | *** join/#asterisk-dev slavon_net (n=slavon@slavon.bigtelecom.ru) |
| 11:50.55 | slavon_net | hello all |
| 11:51.11 | slavon_net | how to backtrace SegFault like this? |
| 11:51.25 | slavon_net | Program terminated with signal 11, Segmentation fault. |
| 11:51.26 | slavon_net | #0 0xb73cd314 in ?? () from /lib/libc.so.6 |
| 11:51.26 | slavon_net | (gdb) bt |
| 11:51.26 | slavon_net | #0 0xb73cd314 in ?? () from /lib/libc.so.6 |
| 11:51.26 | slavon_net | #1 0x00000000 in ?? () |
| 11:51.26 | slavon_net | (gdb) |
| 11:52.03 | slavon_net | asterisk crush 1-3 times in hour =( |
| 11:52.15 | slavon_net | Revision: 101392 |
| 11:52.25 | slavon_net | branches/1.4 |
| 12:05.23 | mvanbaak | compile with DONT_OPTIMIZE flag set in 'make menuselect' |
| 12:07.04 | slavon_net | flag is set |
| 12:07.25 | mvanbaak | try: bt full |
| 12:07.25 | *** join/#asterisk-dev anonymouz666 (n=anonymou@200.218.193.6) |
| 12:08.00 | slavon_net | (gdb) bt full |
| 12:08.00 | slavon_net | #0 0xb73cd314 in ?? () from /lib/libc.so.6 |
| 12:08.00 | slavon_net | No symbol table info available. |
| 12:08.00 | slavon_net | #1 0x00000000 in ?? () |
| 12:08.00 | slavon_net | No symbol table info available. |
| 12:08.01 | slavon_net | (gdb) |
| 12:09.32 | slavon_net | if i "do thread apply all bt" i see debug information at other threads |
| 12:21.49 | tzafrir | slavon_net, looks like the stack there is in bad shape. You can't get a backtrace |
| 12:22.48 | slavon_net | ohh |
| 12:22.51 | slavon_net | again crash |
| 12:22.56 | slavon_net | i got backtrace |
| 12:23.22 | slavon_net | 4 0x080e4f49 in __ast_pthread_mutex_unlock (filename=0xb73ab120 "\001", lineno=458, func=0x1cc <Address 0x1cc out of bounds>, mutex_name=0xffa1 <Address 0xffa1 out of bounds>, t=0xdf73060) |
| 12:23.22 | slavon_net | <PROTECTED> |
| 12:24.06 | slavon_net | do post in bugtracker or we together fix problem now? |
| 12:24.38 | slavon_net | Again bugs in AUDIOHOOCKS |
| 12:25.50 | slavon_net | i can give shell |
| 12:32.22 | jmls | Corydon76-dig: ping |
| 12:35.27 | sergee | jmls: icmp_seq=99 Time to live exceeded |
| 12:38.17 | *** join/#asterisk-dev Laureano (n=chatzill@200.59.172.38) |
| 12:38.22 | *** join/#asterisk-dev snuff-home (n=snuffy@220-253-3-74.VIC.netspace.net.au) |
| 12:42.45 | jmls | sergee: segfault |
| 12:53.22 | sergee | jmls: ouch |
| 12:56.30 | sergee | Corydon76-dig: Corydon76-vcch: i found small bug of yours :) |
| 12:56.42 | snuff-home | mm segfaults are at least surprising.. compile errors are almost as fustrating.. |
| 12:57.14 | snuff-home | best bit is when u fix a compile error that creates a segfault :) |
| 12:58.36 | sergee | M11886 |
| 12:58.37 | MuffinMan | [new] [Asterisk] Functions/func_realtime 0011886: function REALTIME() broken reported by sergee http://bugs.digium.com/view.php?id=11886 |
| 12:58.46 | sergee | that was for Corydon76-* |
| 13:01.16 | jmls | sergee: I was segfaulting myself ;) |
| 13:01.33 | *** join/#asterisk-dev oej (n=olle@cust-IP-10.data.tre.se) |
| 13:01.33 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:01.44 | sergee | jmls: i don't want to know where is your core :)) |
| 13:09.34 | jmls | I've got a "C" question: |
| 13:09.38 | jmls | given this code: |
| 13:09.39 | jmls | <PROTECTED> |
| 13:09.40 | jmls | <PROTECTED> |
| 13:10.13 | jmls | why would you not put the test for a valid member_config within the ast_config_destroy function itself ? |
| 13:16.32 | sergee | probably, there are other actions which are used in conjunction with ast_config_destroy() inside the 'if' block? |
| 13:17.10 | jmls | not in this case |
| 13:18.23 | sergee | i see it, but may be there are other cases? |
| 13:20.48 | file | slavon_net: 11888 makes no sense... |
| 13:21.08 | slavon_net | not understan? |
| 13:23.56 | file | probably memory corruption... |
| 13:25.07 | sergee | jmls: check all cases where ast_destroy_config() is used, and if it always a single operator after if(), then probably it would be nice to move if() inside of this function |
| 13:26.47 | slavon_net | file how to detect? pbx have 30-60 sl in one time... i can't run valgrind at this load... |
| 13:38.46 | *** join/#asterisk-dev jmesquita (n=jmesquit@143.107.13.147) |
| 14:02.34 | *** join/#asterisk-dev jeffg (i=Rcjm2Suz@pdpc/supporter/active/jeffg) |
| 14:06.11 | *** join/#asterisk-dev bweschke (n=bweschke@204.13.233.213) |
| 14:06.11 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 14:22.16 | bweschke | morning! |
| 14:28.15 | jmls | Corydon76-dig: ping ? |
| 14:28.27 | Corydon76-dig | pong |
| 14:28.31 | jmls | whoohoo |
| 14:28.43 | jmls | having some problems with realtime queue members from curl |
| 14:29.01 | Corydon76-dig | Report a bug |
| 14:30.23 | jmls | ok. I added some diagnostics to the .c file |
| 14:30.23 | jmls | http://www.pastebin.ca/886167 |
| 14:30.40 | jmls | wanted to make sure I wasn't being stupid first ;) |
| 14:30.50 | Corydon76-dig | Please put it on the bugtracker, I don't have time to look at it right now |
| 14:30.58 | jmls | that's ok. No worries. |
| 14:49.48 | *** join/#asterisk-dev jcmoore (n=jcmoore@unaffiliated/tgrman) |
| 14:52.21 | *** join/#asterisk-dev RoyK (n=roy@ip-58-8-149-91.dialup.ice.no) |
| 14:55.09 | *** join/#asterisk-dev agx (n=AGX@host63-216-static.34-88-b.business.telecomitalia.it) |
| 14:59.06 | jmls | Corydon76-dig: when you have the time, I've logged it |
| 14:59.09 | jmls | M11889 |
| 14:59.10 | MuffinMan | [new] [Asterisk] Resources/res_config_curl 0011889: Queue members seem not to work reported by jmls http://bugs.digium.com/view.php?id=11889 |
| 14:59.17 | jmls | thanks in advance. |
| 15:03.33 | *** join/#asterisk-dev sruffell (n=sruffell@adsl-074-185-078-025.sip.bhm.bellsouth.net) |
| 15:03.33 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:06.05 | *** join/#asterisk-dev jameswf-home (n=james@dsl093-157-131.phx1.dsl.speakeasy.net) |
| 15:27.31 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 15:34.04 | *** join/#asterisk-dev ManxPower (n=manxpowe@19.sub-75-202-0.myvzw.com) |
| 15:42.45 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 16:00.09 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) |
| 16:06.53 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 16:06.53 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 16:07.39 | *** join/#asterisk-dev joetester (n=patrick@216.191.34.13) |
| 16:15.53 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 16:15.53 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 16:17.23 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 16:17.40 | *** part/#asterisk-dev corramor (n=corramor@216.207.245.1) |
| 16:26.19 | *** join/#asterisk-dev corramor (n=corramor@216.207.245.1) |
| 16:27.03 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 16:27.03 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 16:49.38 | *** join/#asterisk-dev RoyK (n=roy@ip-85-4-149-91.dialup.ice.no) |
| 16:55.30 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:59.00 | agx | does junghans BRI card works with chan_misdn now? i got it detected from "misdn-init" scan but when i start the module then "dmesh" show "hfc-multi: 0 device detected" |
| 16:59.32 | tzafrir | agx, and should use hfcmulti |
| 16:59.38 | Qwell | agx: that isn't a development question. please ask in #asterisk |
| 17:00.02 | tzafrir | One thing though, I suspect that if you modprobe qozap at this stage, it will not notrice that the card is in use |
| 17:00.13 | tzafrir | oops |
| 17:01.31 | agx | Qwell, ok |
| 17:02.37 | atis_work | hey, who did something to mantis? |
| 17:02.43 | *** join/#asterisk-dev myiagy (n=Jose@200.215.59.133) |
| 17:02.46 | atis_work | it leads to downloads.digium.com |
| 17:02.49 | Qwell | <russellb> mantis going down temporarily ... |
| 17:02.59 | jsmith | atis_work: It'll be back momentarily |
| 17:03.19 | russellb | backing up the db currently |
| 17:03.20 | atis_work | ok, just wanted to make sure that it's not accidently |
| 17:03.22 | russellb | it's ... kinda big |
| 17:03.29 | Qwell | russellb: how big? |
| 17:03.51 | atis_work | why would you need to take it down for backup? |
| 17:03.52 | russellb | 250 to 300 MB after bzip2 |
| 17:04.01 | russellb | atis_work: backup and an update |
| 17:04.13 | russellb | it's down for the update, not the backup |
| 17:04.14 | atis_work | oh, ok |
| 17:04.21 | russellb | but the backup has to lock the db anyway |
| 17:04.26 | atis_work | nope |
| 17:04.48 | atis_work | mysqldump -C --lock-tables=FALSE |
| 17:04.53 | jsmith | Must by MySQL... |
| 17:05.33 | atis_work | :D |
| 17:05.41 | jsmith | file: You can't lock me... I've got MVCC! |
| 17:06.45 | oej | jsmith: MySQL just brought a lot of US dollars to the Kingdom of Sweden. I'm not complaining... |
| 17:07.26 | jsmith | oej: Well, hopefully now that Sun bought them out, we'll see a PostgreSQL-based database engine for MySQL |
| 17:07.47 | oej | he he |
| 17:08.01 | oej | Some friends got dirty rich |
| 17:08.12 | jsmith | oej: Honestly thought, the problem isn't MySQL itself -- it's people not knowing how to do proper database design.... things like enforced foreign keys, transactions, etc. |
| 17:08.29 | oej | right |
| 17:08.49 | jsmith | And it doesn't help that MySQL didn't support a lot of those things early on |
| 17:09.00 | jsmith | (and that they'd had to keep switching database engines to try to get those features) |
| 17:09.26 | jsmith | It's MyISAM... no, it's InnoDB, uh, no, it's uh... Gemini, oh, wait, nope... uh, what's next? |
| 17:09.41 | russellb | it's back up. |
| 17:09.45 | Qwell | jsmith: hmm, I recall hearing something about a postgresql backend for mysql before |
| 17:09.53 | Qwell | or, maybe it was the other way around? |
| 17:10.08 | jsmith | Qwell: Why would *anyone* want the other way around? |
| 17:10.13 | Qwell | no idea |
| 17:10.32 | Qwell | must've been a postgresql backend.. |
| 17:10.45 | jsmith | "Hi, I'd like to take out the 450 big block engine and replace it with a lawnmower engine... Can I please?!?" |
| 17:11.39 | Qwell | hmm, maybe it was something else.. |
| 17:14.38 | Corydon76-vcch | Yeah, mysql has a great federated frontend |
| 17:14.39 | anonymouz666 | Asterisk CVS-05/30/03-20:39:27, Copyright (C) 1999-2001 Linux Support Services, Inc. |
| 17:14.40 | anonymouz666 | my box |
| 17:15.20 | Corydon76-vcch | Holy cow, that's old |
| 17:15.29 | anonymouz666 | haha |
| 17:15.54 | jsmith | Wow |
| 17:16.27 | anonymouz666 | it still works |
| 17:18.47 | denon | not so ancient, that'd be 1.2 already wouldnt it? |
| 17:20.44 | kpfleming | no |
| 17:20.55 | kpfleming | 1.2 was released in 2005, 1.4 in 2006 |
| 17:21.08 | kpfleming | that's probably not even 1.0 |
| 17:21.23 | denon | could be .. |
| 17:21.50 | denon | I have to keep telling myself that 1.2 isnt recent anymore .. |
| 17:21.55 | denon | it feels recent |
| 17:21.57 | jsmith | denon: It's not |
| 17:22.08 | denon | 1.0 still feels recent, was quite a milestone |
| 17:23.43 | atis_work | huh, for me 1.6 feels recent.. i'm already wanting audiohooks and realtime_store/destroy |
| 17:23.56 | denon | that was a day .. mark uploaded 1.0 from the podium for the first astricon as I recall |
| 17:24.05 | atis_work | 1.4 is oldie.. of course a bit refreshed now with audiohooks |
| 17:25.50 | tzafrir | kpfleming, any chance you could look into building zaptel on 2.4 kernels again? At least on Debian Sarge? (with devfs support)? |
| 17:26.28 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 17:26.28 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 17:27.11 | mvanbaak | ello all |
| 17:27.27 | denon | so yeah, 1.0 was 2004 |
| 17:28.22 | tzafrir | M11884 |
| 17:28.23 | MuffinMan | [new] [Zaptel] General 0011884: Build fails on Debian 3.1/2.4.27-3-686: static struct member reported by tzafrir http://bugs.digium.com/view.php?id=11884 |
| 17:30.02 | kpfleming | i'll look at that later today, i'm going to spend some time this afternoon working on the open zaptel issues |
| 17:30.11 | russellb | kpfleming: <3 |
| 17:30.18 | kpfleming | there is no need to comment out the 'static' keyword, just remove it |
| 17:30.26 | kpfleming | it's wrong to be there, that was a mistake on my part |
| 17:30.44 | kpfleming | you can commit those changes if you want, they are both correct |
| 17:31.41 | tzafrir | that mode is just a number I made up |
| 17:36.00 | atis_work | russellb: i got another crash on issue 0011877 |
| 17:36.06 | atis_work | with chanspy.diff3 |
| 17:36.15 | atis_work | do you want valgrind? |
| 17:36.34 | russellb | yeah |
| 17:37.00 | atis_work | ok, that'll take some hour probably :) |
| 17:37.03 | russellb | atis_work: curious ... did diff1 crash too? |
| 17:37.10 | atis_work | umm |
| 17:37.33 | atis_work | dont remember if i tried it |
| 17:37.57 | russellb | ok, i would also be interested in that ... but if it does, then let's proceed with diff3 ... |
| 17:38.11 | atis_work | ok |
| 17:38.18 | Simon-- | kpfleming: I opened a bug a little while ago re ztcfg default behaviour. I see you've added ref counting to tone zones and such, so now it shouldn't crash (yay), but will it still toast live calls if one runs "ztcfg"? |
| 17:39.07 | Simon-- | (because everyone likes to do that when trying to figure out zaptel problems, thinking it behaves like "ifconfig") |
| 17:39.25 | atis_work | russellb: you mean yours chanspy.diff not 11877.patch posted by file |
| 17:39.51 | russellb | atis_work: right |
| 17:40.22 | russellb | your last crash isn't in chanspy, either ... |
| 17:40.29 | russellb | i'm not sure if that's good or bad :) |
| 17:40.39 | russellb | either we fixed your crash and you hit a different one, or i did something very bad ... |
| 17:42.39 | atis_work | last one was faster |
| 17:42.41 | atis_work | ~10 minutes |
| 17:43.33 | atis_work | but the last one is also on channel hangup |
| 17:44.36 | russellb | crashed when deleting a channel variable it looks like |
| 17:46.58 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:47.54 | kpfleming | Simon--: ztcfg has not broken live calls for over a year |
| 17:48.05 | kpfleming | it does not modify channels whose signaling configuration has not been changed |
| 17:50.58 | Simon-- | kpfleming: hrmm. the one I built in june did.. |
| 17:51.24 | russellb | atis_work: haha |
| 17:51.31 | russellb | atis_work: you're teletorturing yourself! |
| 17:51.34 | Simon-- | kpfleming: ok, I'll test and complain if it does touch anything :) btw, if I were to, eg., change the LBU on a PRI, would it then kill live calls? |
| 17:52.12 | Simon-- | I would suspect it would likely at least reset the link ;) |
| 17:52.42 | *** join/#asterisk-dev agx (n=badpengu@81-174-44-33.dynamic.ngi.it) |
| 17:56.41 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177583384.dsl.bell.ca) |
| 17:58.14 | kpfleming | yes, and yes |
| 17:59.30 | atis_work | ok, first patch also crashed |
| 17:59.43 | atis_work | i think those crashes are related to show/queues/show channels |
| 18:00.08 | atis_work | i got my web frontend down for while, and i just opened it, when it's crashed |
| 18:02.50 | atis_work | russellb: you want backtraces of first patch also in mantis? |
| 18:03.13 | atis_work | #0 0xb5baaec9 in __ast_pthread_mutex_unlock (filename=0xb5badf93 "app_chanspy.c", lineno=388, func=0xb5baf3dc "chanspy_ds_destroy", mutex_name=0xb5baf3ef "&chanspy_ds->lock", t=0 |
| 18:03.13 | atis_work | #1 0xb5bac16d in chanspy_ds_destroy (data=0x87f2bf8) at app_chanspy.c:388^ |
| 18:05.09 | JerJer | I am getting a lot of searches on one of my blogs with keyword phrases like "digium aa50 setting timezone" or "digium aa50 timezone problem" |
| 18:05.23 | JerJer | are people just stupid or is there some tz issue on the aa50 ? |
| 18:07.41 | *** join/#asterisk-dev hendrixski (n=hendrixs@cpe-74-65-1-222.rochester.res.rr.com) |
| 18:08.18 | JerJer | aa50 offset is another keyword phrase that has brought me 15 unique visitors in the past few days |
| 18:10.21 | JerJer | also most of the traffic is from europe, russia or japan - might be black hats scraping me |
| 18:13.09 | hendrixski | Does monitoring start before or after a caller is connected to a member? |
| 18:15.46 | atis_work | russellb: last valgrind crashed almost immediately - i hadn't started any real calls, just logged in agents |
| 18:15.50 | atis_work | ERROR[31593] /usr/dist/asterisk-1.4.18-rc1/include/asterisk/lock.h: chan_agent.c line 2544 (agent_devicestate): Deadlock? waited 5 sec for mutex '&(&agents)->lock' |
| 18:16.40 | JerJer | hendrixski: good question.... a total guess would be that monitoring should be doing its thang whenever there are frames to be 'monitored' |
| 18:17.03 | JerJer | then again I am totally and completely guessing |
| 18:17.36 | hendrixski | JerJer, right, and there would only be frames once someone is connected |
| 18:22.05 | mvanbaak | back |
| 18:28.37 | *** join/#asterisk-dev qdk (n=qdk@87.63.229.126) |
| 18:56.59 | russellb | atis_work: do you have DO_CRASH enabled? |
| 18:57.07 | atis_work | nope |
| 18:57.13 | atis_work | just DETECT_DEADLOCKS |
| 18:57.27 | russellb | ok |
| 18:57.43 | russellb | can i see the trace? |
| 18:57.49 | atis_work | ok, i got two valgrind outputs |
| 18:58.01 | atis_work | but they are really - not as before |
| 18:58.20 | atis_work | ok, i'm gonna upload within 2 minutes |
| 18:58.24 | russellb | thank you |
| 19:00.54 | atis_work | the last one seems mysql related - could it be because of db connection problems |
| 19:02.38 | atis_work | russellb: uploaded |
| 19:03.56 | russellb | thanks |
| 19:14.14 | atis_work | ok, i got another one - i think it's really related to "show channels" and "show queues" trough AMI |
| 19:14.35 | atis_work | uploading in few minutes |
| 19:17.14 | russellb | atis_work: how heavily do you use chan_agent? |
| 19:17.27 | atis_work | well, all agents |
| 19:18.44 | *** join/#asterisk-dev ManxPower (n=manxpowe@19.sub-75-202-0.myvzw.com) |
| 19:18.54 | russellb | do you use the AGENT dialplan function? agent logoff CLI command or manager action? |
| 19:21.36 | atis_work | AgentCallbackLogin trough manager, and then QueueAdd trough manager |
| 19:22.24 | atis_work | btw, if you see the debug log - there's "show queues" and "show channels" at 13:09:58, and crash is at 13:10:08 |
| 19:22.37 | atis_work | i have 10 second cache for those |
| 19:22.55 | atis_work | the last log, i just uploaded |
| 19:23.07 | atis_work | 2008-01-31-k-debug.txt |
| 19:24.46 | atis_work | i know - it's bad :( i'm already migrating away from agent channel for several months |
| 19:25.11 | russellb | thanks, just curious because i just fixed some things in those areas ... doesn't sound like it affects you though |
| 19:25.18 | russellb | is this all on a test machine? |
| 19:25.32 | atis_work | yes |
| 19:25.40 | *** join/#asterisk-dev ZX81 (n=ZX81@202.20.97.211) |
| 19:25.51 | russellb | ok, good |
| 19:25.58 | atis_work | you fixed something in before 1.4.18 or now in branch? |
| 19:26.36 | russellb | just now in 1.4 |
| 19:26.44 | russellb | if you aren't using those things, it won't matter |
| 19:27.04 | atis_work | nope, i'm at rc3 |
| 19:27.06 | atis_work | should i try? |
| 19:28.10 | russellb | nah ... |
| 19:28.20 | russellb | do you have DONT_OPTIMIZE set? |
| 19:28.30 | russellb | if no, please set it |
| 19:29.24 | RoyK | imho asterisk should be built with DONT_OPTIMIZE by default |
| 19:29.31 | atis_work | sure i have it, how would i get useful backtraces without it |
| 19:29.45 | atis_work | i got it even on production ;) |
| 19:29.58 | RoyK | I've done some tests and the optimisation isn't worth much - the stuff in RTP is too fscked and that's what's spending time |
| 19:30.43 | atis_work | Index: apps/app_queue.c |
| 19:30.43 | atis_work | =================================================================== |
| 19:30.43 | atis_work | --- apps/app_queue.c (revision 101344) |
| 19:30.43 | atis_work | +++ apps/app_queue.c (working copy) |
| 19:30.43 | atis_work | @@ -3280,6 +3280,7 @@ |
| 19:30.53 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:30.59 | Qwell | This is why we don't paste things on IRC :D |
| 19:31.11 | atis_work | woh |
| 19:31.11 | Qwell | ~pb |
| 19:31.12 | jbot | [~pb] A "pastebin" is a web-based service where you can paste anything over 3 lines without flooding the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://www.rafb.net/paste |
| 19:31.13 | atis_work | i got this custom patch |
| 19:31.24 | atis_work | but i guess it doesnt do anything bad |
| 19:31.31 | atis_work | just output |
| 19:32.16 | jpeeler | can multiple AMI commands be serviced simultaneously or does it process them one by one? |
| 19:32.30 | russellb | jpeeler: 1 at a time, per session |
| 19:32.34 | atis_work | they are on one connection - 1 at time |
| 19:32.46 | russellb | jpeeler: multiple manager sessions can execute simultaneously |
| 19:32.59 | jpeeler | right |
| 19:33.20 | russellb | there are very likely some race conditions in config handling over manager if more than one is active at a time |
| 19:33.35 | atis_work | they are there, i know it |
| 19:34.04 | russellb | using a proxy has nothing to do with this issue ... |
| 19:34.04 | jpeeler | well then why instead of parsing the string for 6 digit number is a for loop used to find the number |
| 19:34.14 | jpeeler | this is manager.c in the handle_updates |
| 19:34.21 | russellb | jpeeler: let me look |
| 19:35.10 | russellb | ah, yes, i have looked at this before ... |
| 19:35.23 | russellb | the thing is ... all requested actions will be numbed starting with 0 |
| 19:35.32 | jpeeler | right |
| 19:35.42 | russellb | so it's handling them in numeric order |
| 19:35.44 | jpeeler | oh, to keep them in order |
| 19:36.09 | russellb | and as soon as it hits a number with no associated Action-, it breaks out |
| 19:36.12 | JunK-Y | what would be really cool is the ami to subscrire to specific events. |
| 19:36.25 | russellb | JunK-Y: yep ... |
| 19:43.27 | Juggie | thats already kind of partially there. |
| 19:43.29 | jpeeler | russellb, well this makes handling failures tough then |
| 19:43.45 | jpeeler | if one action command fails and the rest that follows depends on that command to be successful |
| 19:43.51 | atis_work | russellb: if it helps on my issue i could grant you ssh access to my test machines and show how to launch tests |
| 19:44.02 | jpeeler | should the whole batch be aborted if there is one failure? |
| 19:47.13 | russellb | atisss: yeah, it could be useful, if it's easy to run the tests :) |
| 19:47.22 | russellb | jpeeler: well, i wouldn't make the manager code worry about that i guess |
| 19:47.26 | russellb | leave that up to the client |
| 19:48.07 | *** join/#asterisk-dev pgarcia (n=pedgarci@201.72.232.157) |
| 19:48.15 | jpeeler | hmm, alright |
| 19:49.10 | *** join/#asterisk-dev ZaVoid (n=zavoid@66-95-182-90.client.dsl.net) |
| 19:49.20 | ZaVoid | hi all |
| 19:55.05 | russellb | jpeeler: if something fails, the client should, in theory, be able to undo stuff before telling asterisk to reload ... |
| 19:56.30 | ZaVoid | hi russellb |
| 19:56.50 | jpeeler | true but the client has to know to do something |
| 19:57.20 | jpeeler | some things are reported as "success" when they failed or nothing happened |
| 19:57.42 | jpeeler | i guess? |
| 19:58.29 | russellb | they are? if something is reported as success when it failed, then that's a bug i guess :) |
| 19:58.58 | jpeeler | yeah, and that's what i was going to change |
| 19:59.14 | jpeeler | but since the commands are processed in batches |
| 19:59.27 | jpeeler | then bad command in the middle has great potential |
| 19:59.33 | jpeeler | and then even worse if the result is returned as success |
| 20:00.03 | russellb | ah .. hmmm |
| 20:00.12 | jpeeler | so that's why i thought it would be a good thing to just halt upon a bad command |
| 20:00.24 | russellb | yeah, i think so too |
| 20:00.25 | russellb | also |
| 20:00.34 | russellb | the response for failure should indicate which command failed |
| 20:00.42 | jpeeler | definitely |
| 20:00.58 | russellb | jpeeler: there is plenty of Asterisk code to clean up :) |
| 20:01.10 | jpeeler | well it looks like i'm doing it, or trying to |
| 20:01.16 | russellb | good stuff. |
| 20:01.58 | mvanbaak | <--- thinking about picking up chan_skinny realtime again |
| 20:03.44 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:05.56 | ctooley | JunK-Y, in regard to your statement above about Manager event subscriptions, I wish the same were true in "debug" for things like SIP. I'd really like to "trace" a specific call or set up a trace to be able to get all the signaling related to a call to/from a particular number/destination. |
| 20:06.51 | ctooley | I'll often have to trace a specific number routing problem and end up having to sift through thousands of messages because there are so many calls going on at once. |
| 20:08.04 | mvanbaak | I usually tcpdump the stuff based on client ip and use wireshark to look at the dump |
| 20:14.01 | jmls | does 1.6 asterisk work with 1.4 zaptel ? |
| 20:14.05 | Qwell | yes |
| 20:14.15 | Qwell | no need for 1.6 zaptel at this point |
| 20:14.45 | jmls | my 1.4 starts up, zap is available. Stop. Make install 1.6, start 1.6, get " ERROR[3044]: chan_zap.c:13045 build_channels: Unable to register channel '1-10'" |
| 20:19.45 | jmls | yikes! |
| 20:20.15 | jmls | eeeeuuuwww. that's a whole lot of spaghetti :) |
| 20:21.20 | jpeeler | is it ever considered valid syntax to have two contexts/categories in a config file? |
| 20:21.30 | jpeeler | of the same name |
| 20:21.31 | russellb | jpeeler: absolutely |
| 20:21.31 | Qwell | with the same name, you mean? |
| 20:21.32 | Qwell | yeah |
| 20:21.33 | russellb | oh |
| 20:21.55 | Qwell | quite common in sip.conf, where you have both a type=user and type=peer entry |
| 20:22.01 | Qwell | can have* |
| 20:22.06 | russellb | Qwell: good call |
| 20:22.10 | russellb | mvanbaak: cert sent |
| 20:22.13 | mvanbaak | cool |
| 20:22.49 | jpeeler | alright then |
| 20:23.32 | oej | qwell: with config macros, that's also possible |
| 20:23.45 | oej | Depends on where you are, the app won't see it |
| 20:23.55 | *** part/#asterisk-dev pgarcia (n=pedgarci@201.72.232.157) |
| 20:24.14 | putnopvut | jpeeler: it's also possible in chan_sip if people use the (+) syntax to continue a context further in the file. |
| 20:24.36 | russellb | true, there are some interesting things with config inheritance and templates ... |
| 20:24.39 | putnopvut | s/chan_sip/sip.conf/ |
| 20:24.45 | russellb | but for what he's working on (manager config actions), they don't apply i don't think |
| 20:24.52 | putnopvut | Ah, all righty. |
| 20:25.03 | mvanbaak | got it |
| 20:25.03 | russellb | however, that template stuff works in all files |
| 20:25.14 | jpeeler | still helpful to know |
| 20:25.19 | russellb | sure |
| 20:25.21 | jpeeler | eventually |
| 20:25.26 | russellb | it's documented in doc/ somewhere ... |
| 20:25.39 | russellb | jpeeler: sudo apt-get install rubber ; make asterisk.pdf |
| 20:25.53 | russellb | there is a section in there that talks about the stuff available to config files |
| 20:26.06 | mvanbaak | team/mvanbaak/ ? |
| 20:26.24 | russellb | mvanbaak: yeah |
| 20:29.42 | jpeeler | russellb, the makefile script fails to find rubber :( |
| 20:30.09 | mvanbaak | it works |
| 20:30.18 | russellb | jpeeler: re-run configure |
| 20:30.28 | russellb | mvanbaak: sweet |
| 20:30.38 | jpeeler | ah yes, i forgot about that |
| 20:30.57 | mvanbaak | yup |
| 20:31.02 | mvanbaak | CHAMPAGNE !!!!!! |
| 20:31.13 | russellb | yay, party! |
| 20:31.49 | oej | mvanbaak: Save it a month... |
| 20:31.59 | oej | mvanbaak: And share with people in need :-) |
| 20:32.13 | mvanbaak | oej: I will buy new one once you are here |
| 20:32.25 | oej | mvanbaak: Ok, then drink! |
| 20:32.50 | oej | jpeeler: Saw a potentially dangerous manager action in your commit. |
| 20:32.59 | oej | jpeeler: The one that manipulates files or store a file |
| 20:33.07 | oej | jpeeler: Needs some sort of sandbox |
| 20:33.09 | mvanbaak | lol oej |
| 20:33.22 | mvanbaak | oej: I'm feeding it to Nancy ;) |
| 20:33.42 | oej | mvanbaak: STOP! She needs to translate a document for me first!!! |
| 20:33.50 | jpeeler | oej, so far i thought i had only committed actions that read from files |
| 20:34.00 | mvanbaak | hahahahahahaha |
| 20:34.16 | oej | jpeeler: THen I misunderstood that command. Sorry. It was in one branch somewhere. |
| 20:34.49 | oej | jpeeler: Got me thinking about sandboxes and manager security, maybe I lost track before I had read all of it... Happens ;-) |
| 20:35.28 | mvanbaak | oej: you going to FOSDEM ? |
| 20:35.39 | jpeeler | oej, no worries |
| 20:35.54 | jmls | tzafrir: ping |
| 20:35.56 | oej | mvanbaak: I was planning to do that after our meeting |
| 20:35.57 | putnopvut | Odd question, but in what file is the "option_debug" variable defined? |
| 20:36.05 | russellb | main/asterisk.c i think |
| 20:36.07 | oej | mvanbaak: You too? |
| 20:36.11 | tzafrir | jmls, pong |
| 20:36.18 | putnopvut | russellb: Thanks. |
| 20:36.20 | Qwell | mvanbaak: options.h is needed to use it |
| 20:36.37 | jmls | tzafrir: you the chan_zap guy ? |
| 20:36.47 | tzafrir | I figure I'm one of them |
| 20:36.54 | jmls | got a patch for you if you would be so kind as to look it over |
| 20:36.57 | jmls | M11894 |
| 20:36.58 | MuffinMan | [new] [Asterisk] Channels/chan_zap 0011894: [patch] added line numbers to warnings and errors reported by jmls http://bugs.digium.com/view.php?id=11894 |
| 20:37.11 | mvanbaak | oej: yeah, I'm going to FOSDEM |
| 20:37.44 | mvanbaak | Qwell: options.h for realtime you mean ? |
| 20:37.47 | tzafrir | jmls, is there a patch there? |
| 20:37.56 | Qwell | for option_debug |
| 20:38.10 | jmls | heh. yes. |
| 20:38.17 | mvanbaak | erm, yes. |
| 20:39.33 | tzafrir | Looks useful. |
| 20:39.53 | jmls | at least now you know *where* the error is ;) |
| 20:40.04 | tzafrir | In case one uses an #include, the line numbers will turn out a bit strange, right? |
| 20:40.16 | jmls | erm, more than likely |
| 20:40.33 | jmls | depends on how the parser numbers the lines |
| 20:40.33 | mvanbaak | oej: we can give you a ride (beware, we only have a Nissan Micra 1.0) |
| 20:40.42 | jmls | mvanbaak: eeek |
| 20:41.03 | jmls | <PROTECTED> |
| 20:41.08 | tzafrir | Also, a matter of style: I preffer sentences to be ended by a full stop (.) |
| 20:41.17 | mvanbaak | lol |
| 20:41.22 | jmls | I thought that they all were. |
| 20:41.37 | jmls | oh, poo |
| 20:41.42 | putnopvut | Qwell: I think you meant to direct the option_debug thing at me, not mvanbaak. |
| 20:42.00 | Qwell | oh, right |
| 20:42.20 | Qwell | I saw the question first, then went back and looked at who asked, and saw somebody say mvanbaak on the previous line |
| 20:42.29 | putnopvut | But the options.h thing is a lot better than what I did, which was to put extern int option_debug at the top of the file. |
| 20:42.35 | oej | mvanbaak: Let's discuss that later... Guess it depends on the amount of luggage I'm carrying. Sounds like fun though. |
| 20:43.21 | mvanbaak | uhhuh |
| 20:44.29 | jmls | tzafrir: patched with . |
| 20:46.28 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 20:54.42 | atisss | russellb: i just emailed you access info to my testing machines |
| 20:54.48 | atisss | feel free to play with them |
| 21:02.44 | oej | jpeeler: found it |
| 21:02.51 | oej | jpeeler: The listcontexts command |
| 21:03.02 | jpeeler | ok yes |
| 21:03.29 | oej | jpeeler: "Will dump contexts of a context in a given file" - I parsed it as writing a given file... |
| 21:04.02 | oej | jpeeler: Also, the phrase "context" is something we use for the dialplan only in trainings. Otherwise we tend to call it "sections" |
| 21:04.13 | oej | jpeeler: Otherwise, it would be very confusing |
| 21:04.29 | jpeeler | well even more so since in the code it's called categories |
| 21:04.41 | oej | jpeeler: That's asterisk. Welcome. |
| 21:04.55 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 21:04.55 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 21:04.56 | oej | jpeeler: I'm just surprised it's not called "channels" like so many other things |
| 21:05.40 | oej | jpeeler: Many doc files refer to the "general section of a config file" etc etc, so section is established. |
| 21:05.58 | oej | jpeeler: saying "The context specified in the general context of sip.conf" would be hard to understand |
| 21:06.15 | oej | jpeeler: So I would suggest "listsections" instead of "listcontexts" |
| 21:07.25 | oej | Good night folks, time to hug the teddy bear and hope for sweet dreams. |
| 21:07.38 | jpeeler | i'll keep that in mind |
| 21:07.48 | mvanbaak | have fun oej |
| 21:09.49 | russellb | file: have you had a chance to look at chan_refcount at all? |
| 21:09.52 | russellb | i'm tempted to merge it :-p |
| 21:10.09 | russellb | can't decide if i should do it now, or wait until 1.6.0 |
| 21:10.31 | mvanbaak | ok, running 12 different asterisk versions on an ibm thinkpad is _NOT_ going to work |
| 21:11.05 | mvanbaak | testing dundi here |
| 21:12.22 | file | I have not, but I can put it on my agenda for tomorrow |
| 21:12.43 | atisss | russellb: did you get my mail with access info |
| 21:13.03 | russellb | i did, thanks |
| 21:13.10 | russellb | file: no huge rush :) |
| 21:13.38 | russellb | atisss: as soon as i pulled it up, my computer blew up |
| 21:13.40 | russellb | i blame you! |
| 21:13.41 | russellb | not really .. |
| 21:13.49 | putnopvut | russellb: I'd wait until 1.6.0 has been released. |
| 21:14.11 | putnopvut | I know it's still in beta now, but it'd be nice to get the existing bugs out before anything huge like that is introduced. |
| 21:14.19 | atisss | :) |
| 21:16.50 | russellb | fair enough. |
| 21:18.02 | snuff-work | Qwell: ping? |
| 21:18.02 | russellb | STOP IT |
| 21:18.56 | jmls | *pop* |
| 21:19.31 | russellb | s/throw/throws/ |
| 21:23.03 | jmls | got a segfault: would "... state_interface=0x0) at app_queue.c:1319" be a bad thing ? (1.6) |
| 21:23.13 | putnopvut | Yes, it would. |
| 21:23.17 | jmls | heh |
| 21:23.25 | putnopvut | Could you pastebin a backtrace? |
| 21:24.02 | jmls | http://www.pastebin.ca/886698 |
| 21:24.18 | Qwell | snuff-home: pong |
| 21:24.55 | jmls | putnopvut: this happens the second time I type "queue show ROCK" |
| 21:24.59 | jmls | from the cli |
| 21:25.43 | putnopvut | The first time it works? |
| 21:25.58 | jmls | well, it doesn't segfault ;) |
| 21:26.09 | putnopvut | heh |
| 21:26.12 | Qwell | deadly pong there... |
| 21:26.15 | putnopvut | Okay, I'm looking at that line. |
| 21:26.25 | Qwell | snuff-work: pong |
| 21:26.38 | jmls | putnopvut: it is always second time |
| 21:26.49 | jmls | _however_ |
| 21:26.50 | putnopvut | Ah, this is the same error I made in a previous scenario. |
| 21:26.54 | jmls | oh, ok |
| 21:27.05 | jmls | a bug, then ? |
| 21:27.10 | putnopvut | Yes, definitely. |
| 21:27.17 | putnopvut | It'll be easy to fix, though. |
| 21:27.19 | jmls | jsmith: ha! chalk another one up ! |
| 21:27.21 | Qwell | Dear subversion maintainers, |
| 21:27.27 | Qwell | give me svn diff --follow-externals please. |
| 21:27.30 | Qwell | Thanks, Qwell. |
| 21:27.31 | jsmith | jmls: w00t! |
| 21:28.04 | jmls | no-one beleived me with the 1004 byte memory leak. |
| 21:28.15 | jmls | but codefreeze found it :) |
| 21:28.20 | jsmith | jmls: I believed you! |
| 21:28.27 | jsmith | jmls: I just didn't take the time to do anything about it |
| 21:28.53 | *** part/#asterisk-dev RoyK (n=roy@ip-85-4-149-91.dialup.ice.no) |
| 21:34.11 | snuff-work | qwell.. basically there is only uint32_t on solaris.. not u_int32_t.. that's from include/sys/int_types.h |
| 21:34.28 | Qwell | snuff-work: yeah, I know. Just wasn't sure on the include |
| 21:34.40 | Qwell | we have it right in compat.h...maybe editline should be using that? |
| 21:34.56 | Qwell | u_int32_t makes me sad |
| 21:35.02 | snuff-work | mm but i think when i added compat.h to editline it blew up on me |
| 21:35.06 | Qwell | oh |
| 21:35.17 | Qwell | so, how did this work before, and suddenly stop working? |
| 21:35.21 | snuff-work | it was a while ago though since i've tried |
| 21:35.47 | snuff-work | it never worked.. i just posted the patch today.. since it was such a 'sledgehammer' ;) |
| 21:36.13 | putnopvut | jmls: fixed in trunk revision 101576 |
| 21:36.31 | snuff-work | mm.. i will double check 1.4 |
| 21:37.28 | jmls | putnopvut: compiling as I type ... |
| 21:38.02 | jmls | I think that something is not quite right with 1.6 and realtime queues though |
| 21:38.12 | jmls | let me check |
| 21:39.38 | jmls | putnopvut: your patch fixed my initial problem |
| 21:39.41 | jmls | thanks |
| 21:39.56 | jmls | _however_ |
| 21:40.37 | jmls | using realtime, I am returning the queue information, with a strategy=rrmemory |
| 21:41.06 | jmls | under 1.4, queue show ROCK shows it with " in 'rrmemory' strategy" |
| 21:41.28 | jmls | under 1.6, queue show ROCK shows it with "in 'ringall' strategy" |
| 21:41.41 | jmls | same backend. same connection |
| 21:42.46 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 21:42.47 | snuff-work | btw there was my other solaris patch/bug.. the configure stuff.. could we commit the changed 'ldap' part ;) |
| 21:43.06 | putnopvut | jmls: well, that seems wrong... |
| 21:43.19 | putnopvut | Realtime queue? |
| 21:43.25 | jmls | putnopvut: yup |
| 21:43.39 | putnopvut | Okay, let me see what could be causing the problem. |
| 21:43.58 | putnopvut | By the way, "ringall" is what it will default to if an invalid strategy is specified. |
| 21:44.07 | putnopvut | It may for some reason think that yours is invalid. |
| 21:44.07 | jmls | oh, is rrmemory invalid ? |
| 21:44.13 | putnopvut | No, it's valid. |
| 21:44.17 | putnopvut | I need to see what's up. |
| 21:44.24 | jmls | k |
| 21:45.12 | Qwell | snuff-work: line 70, main/editline/np/vis.c, there's is a #ifdef SOLARIS |
| 21:45.24 | Qwell | can you add a #include <sys/inttypes.h> in there, and see if that works? |
| 21:46.22 | putnopvut | jmls: I see what the problem is. I made a change for static queues that I forgot to make for realtime queues. |
| 21:46.29 | jmls | a bug ? |
| 21:46.32 | jmls | ;) |
| 21:46.34 | putnopvut | Yes. |
| 21:46.40 | jmls | jsmith: heh |
| 21:46.53 | putnopvut | The strategy simply isn't being set for realtime queues right now. That's a MAJOR bug the way I see it. |
| 21:47.07 | putnopvut | I'll have a fix in a jiffy. |
| 21:47.12 | jmls | yikes. I guess no-ones testing realtime queues under 1.6 then |
| 21:47.34 | putnopvut | Either that or they all use ringall and don't notice the problem ;) |
| 21:47.39 | jmls | lol |
| 21:47.40 | aashi_france | <PROTECTED> |
| 21:48.05 | jsmith | aashi_france: Asterisk is a back-to-back user agent |
| 21:48.20 | jsmith | aashi_france: That type of question belongs in #asterisk, not #asterisk-dev |
| 21:49.26 | aashi_france | i posted my question but did not have answer fron #asterisk sorry for pasting it here |
| 21:53.38 | snuff-work | mm yer.. 1.4 fails same place editline |
| 22:03.09 | Qwell | snuff-work: see above :) |
| 22:03.33 | Qwell | it should work, and won't break on Linux/BSD |
| 22:03.41 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 22:05.26 | putnopvut | jmls: fixed in 101578. Thanks for finding these! |
| 22:06.10 | jmls | np. Let me test it for you |
| 22:06.19 | putnopvut | Great! |
| 22:07.36 | jmls | urm 729 that is |
| 22:09.41 | jmls | oh, yikes |
| 22:09.41 | jmls | putnopvut: it's more broken :( |
| 22:09.48 | jmls | <PROTECTED> |
| 22:10.02 | russellb | eep |
| 22:10.27 | atisss | :D |
| 22:10.48 | mvanbaak | off to bed |
| 22:10.54 | Qwell | woah |
| 22:11.03 | Qwell | ohhhhh, I see |
| 22:11.19 | Qwell | nm |
| 22:12.02 | putnopvut | jmls: ouch! |
| 22:12.11 | putnopvut | Okay... |
| 22:12.31 | putnopvut | Oops, left off an ! |
| 22:12.42 | jmls | <PROTECTED> |
| 22:13.04 | putnopvut | Fixed in 101580 |
| 22:13.15 | jmls | just in front of the strcasecmp ? |
| 22:14.03 | jmls | putnopvut: YAY ! |
| 22:14.20 | jmls | I have a "Show Queue" screen that looks right ;) |
| 22:14.33 | jmls | now. |
| 22:14.55 | putnopvut | jmls: yep, the strcasecmp needed a ! |
| 22:15.12 | jmls | Why does a realtime queuemember only show (realtime) as the interface. Why not a (realtime) (local/5707@agentq/n) |
| 22:16.14 | putnopvut | jmls: that seems a bit off... the (realtime) is just to indicate that the member is a realtime member, it shouldn't take the place of the interface. |
| 22:16.45 | jmls | it's that way in 1.4 as well |
| 22:17.02 | putnopvut | Really? When I do it, it properly displays the interfaces. |
| 22:17.42 | putnopvut | http://pastebin.ca/886761 |
| 22:18.07 | jmls | ah, no. You are showing the member name |
| 22:18.13 | jmls | the interface is not showing |
| 22:18.48 | putnopvut | Can you show me what you mean? |
| 22:19.44 | jmls | putnopvut: http://pastebin.ca/886764 |
| 22:20.26 | jmls | with "normal" queue members, you would see |
| 22:20.37 | jmls | jmls44 (local/5707@agentq/n) (Not in use) has taken no calls yet |
| 22:20.40 | putnopvut | By "normal" you mean not realtime? |
| 22:20.43 | jmls | yes |
| 22:21.20 | putnopvut | Hmm, for my static queue members, I'm not seeing that. |
| 22:21.38 | putnopvut | I just have SIP/1000 (Not in use) has taken no calls yet |
| 22:21.44 | putnopvut | No interface in parens. |
| 22:22.16 | jmls | ohhh |
| 22:22.29 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 22:22.29 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 22:22.36 | jmls | with normal members I see |
| 22:22.39 | jmls | local/5816@agentq/n (dynamic) |
| 22:23.06 | jmls | sorry, my fault |
| 22:23.19 | jmls | I just expected to see member name as well as interface ;) |
| 22:23.26 | putnopvut | I can understand. |
| 22:23.41 | jmls | but .. why .. with realtime am I seeing the member name and not the interface ? |
| 22:23.52 | jmls | jmls44 is the member name |
| 22:24.04 | jmls | when I call the queue, it calls local/5707@agentq |
| 22:24.15 | putnopvut | Do you have a member name set for the non-realtime member? |
| 22:24.25 | putnopvut | Because if you don't, then it sets the member name to its interface. |
| 22:24.35 | jmls | that is probably it, then |
| 22:24.41 | jmls | I use AddQueueMember |
| 22:26.26 | jmls | putnopvut: you are going to hate me |
| 22:26.37 | jmls | a reload does not clear the queue members properly |
| 22:27.00 | jmls | if I change the member name, it is not relected unless I restart asterisk |
| 22:27.29 | putnopvut | Okay, let's see if I can figure out why. |
| 22:27.55 | putnopvut | Also, I'm guessing "relected" is a typo, but for the life of me, I cannot figure out what word you mean. |
| 22:28.03 | *** join/#asterisk-dev ZaVoid (n=zavoid@c-67-165-25-195.hsd1.ct.comcast.net) |
| 22:28.06 | jsmith | putnopvut: Selected? |
| 22:28.08 | jmls | reflected |
| 22:28.13 | jsmith | reflected! |
| 22:28.31 | putnopvut | Ah, reflected makes sense :) |
| 22:29.18 | jmls | yeah, reload app_queue.so does not "reread" the changed member name |
| 22:29.31 | putnopvut | Oh, that's done on purpose actually. |
| 22:29.44 | putnopvut | A reload should not affect realtime queues or members at all. |
| 22:29.44 | jmls | oh ? |
| 22:29.53 | putnopvut | No, that information is changed "as needed" |
| 22:30.03 | jsmith | putnopvut: :-) |
| 22:30.04 | jmls | but what if the underlying information has changed in the meantime ? |
| 22:30.42 | putnopvut | There are a few places in app_queue that the realtime information is reread. |
| 22:31.09 | putnopvut | Between attempts to call queue members, when a caller enters a queue, and if you attempt to show a realtime queue are three that come to mind. |
| 22:31.25 | jmls | if a member is added or removed from the backend, that is always updated ? |
| 22:31.34 | putnopvut | It should be :) |
| 22:31.38 | jmls | oh, ok |
| 22:32.21 | putnopvut | Yeah, lmadsen found a bug quite a while back that a caller could enter an empty queue and even though members would log into the queue, the caller would wait forever because when he entered, there were no members. |
| 22:32.44 | putnopvut | So I added periodic checks to realtime during a call's lifetime so that adding and deleting members would be reflected in memory. |
| 22:33.02 | jmls | well, ladies and gentlemen, thanks to Corydon76-dig and putnopvut I am now working with realtime queues and queuemembers driven by res_config_curl ! |
| 22:33.12 | putnopvut | jmls: Awesome |
| 22:33.21 | tzanger | jmls: nice |
| 22:33.25 | putnopvut | wait, what ladies? ;) |
| 22:33.29 | jmls | heh |
| 22:33.41 | jmls | there may be one lurking somewhere |
| 22:35.46 | jmls | right. that's me for the night |
| 22:36.05 | jmls | I'm sure putnopvut will breathe a sigh of relief ;) |
| 22:36.36 | jmls | can't I get karma points for bugs found even though they never make it through to mantis ? |
| 22:37.18 | jsmith | jmls: I'm sure we can work something out |
| 22:37.35 | jmls | yay! |
| 22:37.46 | jmls | with that news, jmls slinks off to sleep |
| 22:37.49 | jsmith | Bugs username? |
| 22:37.55 | jmls | jmls ;) |
| 22:38.24 | jsmith | Just making sure |
| 22:39.29 | atisss | jmls, btw there's an uniqueid column in realtime - to update members, not replace them |
| 22:39.39 | atisss | i found out that accidently by digging source |
| 22:39.49 | jmls_sleep | yeah, got that. Thanks ;) |
| 22:41.07 | atisss | just have to forward-port to trunk |
| 22:41.11 | russellb | yeah, do it quick before putnopvut gets tired of working on app_queue :) |
| 22:41.23 | putnopvut | app_queue is awesome and will never get old. |
| 22:41.38 | putnopvut | I couldn't even type that with a straight face. |
| 22:42.02 | russellb | i thought you meant it |
| 22:42.29 | jmls | mm, got to jump in here |
| 22:42.41 | putnopvut | Well, the part about it being awesome is somewhat of a lie...it needs massive work. |
| 22:42.45 | file | putnopvut: I bet you never thought you would get yourself into that... |
| 22:42.47 | jmls | I was thinking of a simple app_queue |
| 22:42.52 | putnopvut | But I really do enjoy working on it. |
| 22:43.09 | jmls | the "hardest" part is deciding on which queue member to call, is it not ? |
| 22:43.11 | file | putnopvut wants YOU to join the app_queue task force! |
| 22:43.26 | jmls | what strategy, which agent, which penalty etc etc |
| 22:43.50 | jmls | what if you were to use realtime to ask another application which agent to send the call to ? |
| 22:44.19 | putnopvut | jmls: that's SORT of what's been discussed as the next generation of app_queue. |
| 22:45.00 | jmls | my application is much better at knowing who is available, and I can run all sorts of programming logic to determine the agent to send the next call to |
| 22:45.06 | putnopvut | Not necessarily realtime, but using an external process to determine the logic behind everything but have Asterisk provide the facilities for having callers and members and bridging them. |
| 22:45.42 | jmls | I only mentioned realtime because you can do that today with res_config_curl ;) |
| 22:45.53 | putnopvut | True. |
| 22:46.09 | jmls | or perhaps even stored procedures with sql |
| 22:46.40 | jmls | atisss: so I don't have to have a db engine sitting on the asterisk box |
| 22:46.58 | putnopvut | jeez, the man page for curl sounds like a marketing flyer... |
| 22:47.29 | putnopvut | "curl offers a busload of useful tricks...the amount of features will make your head spin!" |
| 22:47.33 | jmls | so am I. But I can call my programs through a web server, and the programs can determine which agents are available rather than trying to do it through a select statement |
| 22:48.00 | atisss | oh |
| 22:48.02 | atisss | :) |
| 22:49.25 | jmls | atisss: it's very powerful. It also allows you to build a simple small asterisk box without a large amount of dependencies |
| 22:50.13 | atisss | putnopvut: i could give you some hints ;) |
| 22:50.13 | jmls | putnopvut: if you have any more discussions on the future of app_queue , would you try to let me know ? |
| 22:51.00 | putnopvut | Yeah, we definitely need input from those who implement queues heavily. |
| 22:51.18 | jmls | tie in the realtime stats update, and it would be _really_ cool ;) |
| 22:51.33 | putnopvut | Right now we're just trying to hammer out a very rough idea of what queues should be without delving too deeply into architectural needs or features. |
| 22:52.16 | atisss | jmls, you mean - realtime "show queues"? |
| 22:52.48 | atisss | i got patch for it |
| 22:52.54 | jmls | all the queue stats being sent to the realtime engine whenever they change ? |
| 22:53.00 | atisss | yes yes yes |
| 22:53.06 | jmls | putnopvut: !!! |
| 22:53.20 | putnopvut | atisss: Cool! |
| 22:53.21 | atisss | i'm just testing it, but seems to work good |
| 22:54.29 | jmls | I could test it on 1.4 for you |
| 22:54.40 | atisss | great :) |
| 22:54.53 | snuff-work | Qwell: u_int32_t isn't def'd in there.. compile failed again.. better add ifndef for u_int32_t in there.. :) |
| 22:55.09 | atisss | jmls, do you use state_interface patch? |
| 22:55.13 | jmls | nope |
| 22:55.15 | Qwell | oh |
| 22:55.18 | atisss | i got one big patch, that includes this |
| 22:55.29 | jmls | my app determines the "state" of the device, combined with group_count |
| 22:55.30 | atisss | because they conflicted - changing same lines |
| 22:55.53 | atisss | well, but it's better that queue get's also real state of sip peers |
| 22:56.08 | jmls | we use local channels - that is covered by this patch ? |
| 22:56.11 | atisss | that's what i was hacking for month, until i found state_interface backport |
| 22:56.23 | atisss | yup, i'm trying to do that |
| 22:56.37 | snuff-work | Qwell: http://www.pastebin.ca/886808 |
| 22:56.46 | snuff-work | works after adding tat |
| 22:56.50 | jmls | atisss: really interested in helping |
| 22:56.52 | jmls | but, I .... reallly ...... need ..... to ........ sleep |
| 22:56.56 | atisss | :) |
| 22:56.58 | atisss | me too |
| 22:57.02 | jmls | catch you tomorrow ? |
| 22:57.05 | atisss | sure |
| 22:57.08 | Qwell | snuff-work: I'm trying to avoid that hack |
| 22:57.11 | atisss | good night |
| 22:57.12 | putnopvut | Have a good night jmls_sleep ! |
| 22:57.21 | jmls_sleep | thanks |
| 22:57.23 | jmls_sleep | night all |
| 22:57.26 | snuff-work | well u_int32_t doesn't exist in solaris headers |
| 22:57.29 | Qwell | snuff-work: can you `ggrep -r u_int32_t /usr/include`, and see where it's defined? (it's defined somewhere) |
| 22:57.44 | putnopvut | Qwell: sure it isn't supposed to be uint32_t? |
| 22:57.45 | Qwell | well, should be defined somewhere |
| 22:57.48 | Qwell | putnopvut: that's the problem |
| 22:57.54 | putnopvut | Oh...nevermind then :) |
| 22:58.09 | putnopvut | I'm so Linux-centric it's not even funny. |
| 22:58.42 | snuff-work | /usr/include/cdio/types.h |
| 22:58.49 | snuff-work | <PROTECTED> |
| 22:59.28 | Qwell | snuff-work: nowhere else? |
| 22:59.44 | snuff-work | /usr/include/netinet/ip_compat.h |
| 23:00.10 | snuff-work | /usr/include/dat/dat_platform_specific.h |
| 23:00.18 | Qwell | stupid solaris |
| 23:04.01 | snuff-work | ;) |
| 23:04.32 | atisss | putnopvut: are you available to discuss some changes in app_queue? |
| 23:05.17 | snuff-work | btw.. the 'awk' aka finding gnu version in configure.. how to go about it |
| 23:05.20 | putnopvut | atisss: sure. What's up? |
| 23:05.33 | Qwell | snuff-work: I commented on that bug |
| 23:06.21 | russellb | darnit ... have to make rc4 |
| 23:06.36 | putnopvut | russellb: what fix prompted its release? |
| 23:06.44 | russellb | the one i'm about to commit ... |
| 23:06.49 | putnopvut | Ooh... |
| 23:06.49 | snuff-work | atm i can't run bootstrap.. automake not high enough version |
| 23:06.56 | russellb | something i did caused g729 decoders to not get released in some situations |
| 23:07.08 | atisss | oh, sorry, i got messed up in my code.. there's actually nothing to discuss, it will work as before.. just improving :) |
| 23:11.49 | putnopvut | russellb: ooh, that commit message sounds like it probably fixed a hefty memory leak. |
| 23:11.55 | *** join/#asterisk-dev _charly_ (i=kroseneg@sunrise.schmidham.net) |
| 23:13.58 | russellb | putnopvut: yeah ... a pretty decent one |
| 23:14.30 | russellb | something that would leak on every call |
| 23:14.37 | russellb | in the case of transcoding |
| 23:15.11 | putnopvut | A leak on every frame processed or just once per call? |
| 23:15.15 | russellb | per call |
| 23:18.39 | *** join/#asterisk-dev denon (n=denon@tooth.decay.org) |
| 23:25.41 | atisss | putnopvut: here's something for app_queue - it's just a first step of all my queue patches |
| 23:25.43 | atisss | http://bugs.digium.com/view.php?id=11896 |
| 23:29.19 | putnopvut | atisss: I'm taking a look at that... |
| 23:41.39 | putnopvut | atis_home: Seems like a good patch on first glance. I need to think of edge cases to be sure that it is always applicable. |
| 23:42.31 | tzanger | bah I am mistaken |
| 23:42.36 | tzanger | 40000 sq ft not 40000 sq km |
| 23:42.38 | tzanger | er sq m |
| 23:42.43 | tzanger | fuck |
| 23:42.47 | tzanger | 40000 ft2 not 40000 m2 |
| 23:42.49 | tzanger | there that's better |
| 23:43.10 | tzanger | haha that's only a factor of 10 off |
| 23:43.26 | tzanger | although I've been in 40k m2 factories (engine plants) |
| 23:43.48 | tzanger | thousands of engines all over the place, above you, beside you, below you... snaking through the entire plant |
| 23:44.28 | russellb | tzafrir: i think you switched channels accidentally |
| 23:44.34 | russellb | tzafrir: sorry |
| 23:44.37 | russellb | tzanger: ^^^ |
| 23:44.39 | tzanger | haaaaaaaaahahahahha |
| 23:44.42 | tzanger | I'm so stupid |
| 23:44.51 | atis_home | putnopvut: sure |
| 23:45.20 | tzanger | russellb: thanks :-) |
| 23:45.55 | atis_home | syntax is ok? |
| 23:47.09 | putnopvut | atis_home: the only thing I noticed that is typically not used is the if (rt_uniqueid_str) used in rt_handle_member_record |
| 23:47.28 | putnopvut | Typically, Asterisk uses ast_strlen_zero to see if a string is NULL or is zero-length. |
| 23:47.41 | atis_home | ok, i could fix that |
| 23:47.43 | putnopvut | It just tends to be safer than checking for the existence of the string pointer. |
| 23:47.46 | putnopvut | But that's very minor. |
| 23:48.18 | putnopvut | The one thing that I'm curious about is why you store the uniqueid for the member as an integer. |
| 23:48.47 | atis_home | oh, by the way - the rt_handle_member_record had all other parameters checked like that |
| 23:48.48 | putnopvut | Since it is stored and retrieved from the db as a string, you could just leave it that way for the member structure. |
| 23:49.06 | atis_home | umm, in db it's supposed to be primary key |
| 23:49.15 | atis_home | well, i guess nobody wants it to be string |
| 23:49.42 | putnopvut | Right, what I meant is that Asterisk's realtime architecture always reads everything from the database as a string, even if it's stored internally as an integer. |
| 23:49.45 | atis_home | actually i suspect that nobody really used the uniqueid - it was somewhere in code, but no docs |
| 23:49.59 | atis_home | i updated wiki when i found it |
| 23:50.12 | atis_home | hmm, you would want it string? |
| 23:50.20 | putnopvut | No, an int is probably fine. |
| 23:50.53 | atis_home | i also really didn't wanted to mess with pointers - i'm afraid of C pointers :p |
| 23:51.02 | putnopvut | atis_home: a lot of people are :) |
| 23:51.02 | atis_home | all the sizekeeping.. |
| 23:51.55 | atis_home | so, all the rt_handle_member_config could be updated to check strings with ast_strlen_zero, right? |
| 23:52.18 | atis_home | penalty_str, paused_str... |
| 23:58.23 | atis_home | done, patch in mantis |