| 00:26.11 | *** part/#asterisk-dev RoyK (n=roy@91.149.24.225) |
| 01:01.12 | *** join/#asterisk-dev RoyK (n=roy@91.149.24.225) |
| 01:23.59 | *** join/#asterisk-dev RoyKa (n=roy@91.149.26.90) |
| 01:29.40 | *** part/#asterisk-dev RoyKa (n=roy@91.149.26.90) |
| 02:29.30 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.32.126) |
| 03:00.28 | *** join/#asterisk-dev snuff-work (i=1000@61.29.30.137) |
| 03:54.22 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 03:54.22 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 04:28.44 | *** join/#asterisk-dev snuff-work (i=1000@61.29.30.137) |
| 04:45.07 | *** join/#asterisk-dev De_Mon (i=de_mon@fl-71-55-239-242.dhcp.embarqhsd.net) |
| 05:58.17 | *** join/#asterisk-dev oej (n=olle@soll4-125.cust.blixtvik.net) |
| 05:58.17 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:07.34 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 07:41.08 | jmls | if a var is defined as char *buffer, malloced with ast_malloc(64000), is it valid to say ast_verb(3,"test %s",buffer) ? |
| 07:42.34 | snuff-work | mm.. no null terminator |
| 07:43.04 | snuff-work | if was ast_calloc() at least it would all be 0's.. |
| 07:43.21 | jmls | snuff-work: it's set using pbx_substitute_variables_helper |
| 07:44.00 | snuff-work | its valid.. just need to make sure that the string is null terminated |
| 07:44.13 | jmls | doesn't pbx_substitute_variables_helper do that ? |
| 08:04.50 | tzafrir | Daviey, here? |
| 08:29.39 | *** join/#asterisk-dev oej (n=olle@213.115.215.130) |
| 08:29.39 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 08:41.48 | *** join/#asterisk-dev qdk (n=qdk@85.235.253.139) |
| 09:57.44 | jmls_school_run | Corydon76-dig: ping |
| 10:35.22 | Daviey | tzafrir: yup |
| 10:39.59 | *** join/#asterisk-dev pnlarsson (n=pnlarsso@c83-248-96-159.bredband.comhem.se) |
| 11:03.20 | jmls | can someone look at the code snippet at http://www.pastebin.ca/854515 |
| 11:03.30 | jmls | and tell me why sizeof(buffer) returns 4 ? |
| 11:06.16 | *** join/#asterisk-dev RoyK (n=roy@fw.fortel.no) |
| 11:06.34 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 11:06.35 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:13.08 | tzafrir | Daviey, so a plain Zaptel works on Ubuntu? |
| 11:14.35 | Daviey | yup |
| 11:14.42 | Daviey | well using m-a |
| 11:14.49 | Daviey | but not svn :( |
| 11:15.07 | *** join/#asterisk-dev andrelg (n=andrelg@server01.outcenter.com.br) |
| 11:19.29 | sergee | jmls: buffer is a pointer, sizeof returns you a size of that pointer. 4 bytes is a size of pointer on 32bit systems.. |
| 11:20.11 | jmls | so what would I use to get the sizeof buffer itself ? |
| 11:21.00 | *** join/#asterisk-dev _ys (i=yuri@91.151.196.254) |
| 11:21.02 | jmls | or should I just use 64000 instead ? |
| 11:21.40 | jmls | the line in question is pbx_substitute_variables_helper(NULL, query->str, buffer, sizeof(buffer)) |
| 11:21.50 | jmls | should it be pbx_substitute_variables_helper(NULL, query->str, buffer, 64000) |
| 11:21.54 | sergee | tipycaly valgrind is used when you need to debug mallocs.. |
| 11:25.18 | jmls | sergee: I know what the problem is -> 4 is being passed as the size of the string to use. I am guessing that I need to pass 64000 (the size of the malloc) but not sure. |
| 11:27.01 | sergee | jmls: you need to pass value that was used during malloc, and it would be better if it is a variable, or #define-ed (macro) value - not hardcoded digits.. |
| 11:27.34 | jmls | thought so. Thanks. |
| 11:28.11 | sergee | glad to help |
| 11:42.11 | *** join/#asterisk-dev IgorG (n=igorg@195.162.32.126) |
| 11:44.35 | *** join/#asterisk-dev myiagy (n=Jose@189.34.24.93) |
| 12:05.35 | jmls | err, is there any chance that* can crash without a core dump ? |
| 12:05.55 | jmls | it is started with safe_asterisk |
| 12:06.15 | jmls | I'm trying to figure out of someone "restarted" it from the CLI |
| 12:08.56 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.64.193) |
| 12:17.01 | sergee | jmls: you can always launch asterisk "inside" gdb.. |
| 12:23.44 | jmls | the production box just crashed "no calls" , but there is no core file. I've never seen that before |
| 12:28.11 | tzanger | jmls: depends on the distro; if ulimits have -c set to 0 or the kernel corefile generation parameters in /proc have it not creating corefiles... you wont' get any |
| 12:28.16 | tzanger | surprised me too on a few boxes :-) |
| 12:28.33 | jmls | tzafrir: we've always had core dumps before |
| 12:39.26 | jmls | yay! success! |
| 12:39.55 | jmls | including update of password. |
| 12:41.53 | tzafrir | jmls, also try: echo '/tmp/core.%e-%t' >/proc/sys/kernel/core_pattern |
| 12:42.07 | tzafrir | (or the equivalent /etc/sysctl.conf line) |
| 12:42.26 | jmls | ;) |
| 12:43.24 | tzafrir | RTFM http://lxr.linux.no/linux/Documentation/sysctl/kernel.txt |
| 12:43.32 | atisss | jmls: what's res_config_cur? retrieve config trough HTTP? |
| 12:43.42 | jmls | atisss: yup! |
| 12:43.49 | tzafrir | atisss, the real-time version |
| 12:43.50 | atisss | cool |
| 12:44.29 | atisss | umm, retrieve config every time trough curl? |
| 12:45.32 | jmls | voicemail / queues / queue members, sure |
| 12:45.40 | jmls | sip peers ? maybe |
| 12:45.54 | jmls | tzafrir: thanks for the link |
| 12:45.57 | atisss | sip peers needs update |
| 12:46.05 | jmls | so does voicemail |
| 12:46.17 | atisss | well, that could be done trough HTTP put or FTP.. |
| 12:46.29 | jmls | curl updates as well |
| 12:46.57 | tzafrir | jmls, you can even do a creasy thing as to pipe the core file to a script |
| 13:14.54 | *** join/#asterisk-dev Victor_Yure (n=Victor_Y@postfix.tradein.com.br) |
| 13:28.21 | *** join/#asterisk-dev triiiple (i=triple@pi.nxs.se) |
| 13:31.17 | sergee | M7904 |
| 13:31.19 | MuffinMan | [confirmed] [Asterisk] Applications/app_dial 0007904: Transfer capability is inherited by a channel after being transfered via atxfer reported by k-egg http://bugs.digium.com/view.php?id=7904 |
| 13:31.32 | sergee | testers are welcome :) |
| 13:41.30 | jmls | ooo. Does anyone know if #exec works in sip.conf ? |
| 13:49.35 | jmls | hmm. borked |
| 13:49.44 | tzafrir | jmls, it works in every config file (if enabled) |
| 13:49.54 | tzafrir | Just like #include works everywhere |
| 13:50.07 | jmls | I'm doing something wrong then |
| 13:50.21 | tzafrir | Does #exec work anywhere else? |
| 13:51.00 | jmls | I copied the [1223] section from sip.conf into /tmp/jls.conf, replaced it with a #exec /tmp/mysip.sh, mysip.sh does a /bin/cat /tmp/jls.conf |
| 13:51.13 | jmls | sip reload: [Jan 14 13:47:01] WARNING[13855]: config.c:1056 process_text_line: No '=' (equal sign) in line 1 of /var/tmp/exec.1200318421.9153424 |
| 13:51.31 | jmls | and peer 1223 no longer exists |
| 13:51.35 | *** join/#asterisk-dev ctooley (n=ctooley@doc-72-47-33-80.maryville.mo.cebridge.net) |
| 13:57.39 | *** join/#asterisk-dev msetim (n=marcos@200.195.161.164) |
| 13:57.57 | msetim | hi |
| 13:58.38 | msetim | when I run a HTTP manager request to "mxml?action=agents" what file is responsible to create this output? |
| 14:00.19 | jmls | tzafrir: fixed it. mea culpa |
| 14:09.20 | jmls | Corydon76-dig: ping |
| 14:10.03 | atisss | hey, i just noticed that GROUP_COUNT still counts originating channel, when it's on h extension |
| 14:10.13 | atisss | should it be that way? |
| 14:10.58 | jmls | manually remove it from the group if you don't want it |
| 14:11.00 | jmls | ;) |
| 14:12.06 | atisss | thanks, that's an idea |
| 14:12.29 | atisss | however i suppose it should be removed when channel is already being hanged up |
| 14:21.11 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 14:21.11 | *** join/#asterisk-dev myiagy (n=Jose@189.34.24.93) [NETSPLIT VICTIM] |
| 14:21.11 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 14:21.11 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) [NETSPLIT VICTIM] |
| 14:21.11 | *** join/#asterisk-dev qdk (n=qdk@85.235.253.139) [NETSPLIT VICTIM] |
| 14:21.11 | *** join/#asterisk-dev Damin (n=damin@nucleus.nacs.net) [NETSPLIT VICTIM] |
| 14:21.11 | *** join/#asterisk-dev JunK-Y (n=junky@modemcable183.17-83-70.mc.videotron.ca) |
| 14:21.11 | *** join/#asterisk-dev adker (n=chatzill@74-33-205-192.br1.glv.ny.frontiernet.net) |
| 14:21.11 | *** join/#asterisk-dev monkeytype (n=Bill@216.207.245.1) |
| 14:21.11 | *** join/#asterisk-dev kpfleming (n=kpflemin@nat/digium/x-8b21230e5df7048d) |
| 14:21.12 | *** join/#asterisk-dev d3wayne (n=deeewayn@76.29.245.9) |
| 14:21.12 | *** join/#asterisk-dev davevg-btwtech (n=davevg-b@nj-67-76-177-147.sta.embarqhsd.net) [NETSPLIT VICTIM] |
| 14:21.12 | *** mode/#asterisk-dev [+ooo putnopvut kpfleming d3wayne] by irc.freenode.net |
| 14:21.16 | *** part/#asterisk-dev myiagy (n=Jose@189.34.24.93) |
| 14:23.01 | *** join/#asterisk-dev bweschke (n=bweschke@204.13.233.213) |
| 14:23.01 | *** mode/#asterisk-dev [+o bweschke] by ChanServ |
| 14:24.24 | atisss | hmm, i think the fix for group_count is quite simple - in app.c, ast_app_group_get_count add check for !gi->chan->_softhangup |
| 14:24.41 | atisss | anything else i should take in mind? |
| 14:26.24 | jmls | atisss: not sure it's broken. The channel is still active, although the call may be hung up |
| 14:26.48 | atisss | well, but there's nothing you can do with channel being hanged up |
| 14:27.15 | jmls | there's all sorts of things you can do. My h extension is quite long ;) |
| 14:27.29 | jmls | sorry, h dialplan |
| 14:27.35 | atisss | well, mine too.. |
| 14:27.53 | atisss | but i want to detect when call is over and user don't have any more calls |
| 14:27.56 | jmls | Corydon76-dig: !! |
| 14:28.02 | atisss | i'm using h as event |
| 14:31.15 | atisss | jmls: i just tested wait(20) on h, it doesn't influence devices in any way - you can call from devices that have channels doing something on h extension |
| 14:33.50 | jmls | meh. Just let me know if any of you buggers change this - I have dialplans that take account of this fact. If you change it, I'll have to change the dialplan :( |
| 14:34.37 | atisss | how do you take account of that? |
| 14:34.51 | jmls | count - 1 |
| 14:34.52 | jmls | ;) |
| 14:34.55 | atisss | :D |
| 14:34.59 | atisss | that's a workaround |
| 14:35.21 | jmls | yeah, a workaround that will be broken if this is changed 8-) |
| 14:35.39 | atisss | well, then i think you agree that it's a bug? |
| 14:36.20 | jmls | no, I refer back to my original comment: not sure it's broken. The channel is still active, although the call may be hung up |
| 14:36.33 | jmls | and it is a _channel_ count, not a _device_ count |
| 14:37.09 | atisss | well, yes, but it's proposed to be generally used for limiting calls per device |
| 14:37.58 | jmls | "generally", maybe. But I use it to keep track of how many channels are in, for example, my outbound dialler campaign. Nothing to do with devices |
| 14:38.38 | atisss | sure, but you also do count-1 so you would expect to have it not counted |
| 14:38.50 | atisss | ok, any more opinions on this? |
| 14:38.59 | jmls | that's the very last line in my h extension :) |
| 14:39.19 | *** join/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 14:39.19 | jmls | it's the phone system updating the dialler database |
| 14:39.46 | atisss | btw, why do you have the limit? |
| 14:42.30 | jmls | So I can keep track of the number of lines being used by variaous processes . (Dialler / inbound queues / extensions etc) |
| 14:43.17 | jmls | dammit. School run time |
| 14:43.24 | atisss | :) |
| 14:43.59 | jmls_away | be back soon |
| 14:48.22 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 14:48.22 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 14:55.48 | *** join/#asterisk-dev jcmoore (n=jcmoore@unaffiliated/tgrman) |
| 15:21.25 | *** join/#asterisk-dev monkeytype (n=Bill@216.207.245.1) |
| 15:32.56 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:32.56 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 15:33.12 | lmadsen | morning all |
| 15:35.28 | *** join/#asterisk-dev jsmith (n=user@68-246-114-6.area3.spcsdns.net) |
| 15:35.28 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 15:37.41 | *** join/#asterisk-dev shido6 (n=shido6@204.126.120.132) |
| 15:39.42 | *** topic/#asterisk-dev by file -> 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 |
| 15:40.00 | jcmoore | mmmm, banana |
| 15:44.29 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:44.30 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 16:02.19 | atisss | russellb: Russell, maybe you have an opinion on how GROUP_COUNT should treat channels being hanged up |
| 16:02.43 | atisss | we had some discussion here, but nobody from developers joined :( |
| 16:03.13 | russellb | i have no opinions |
| 16:03.15 | atisss | the question is - should channels that are dead, and on h extension be counted within GROUP_COUNT |
| 16:03.30 | russellb | my short answer is yes |
| 16:03.51 | russellb | if you don't want it counted, you should remove the channel from the group in your h exten |
| 16:04.29 | atisss | ok |
| 16:04.41 | atisss | that's more troublesome for me, but i'll try do that way |
| 16:07.47 | atisss | my thinking was a bit opposite - as most common use of GROUP_COUNT is to limit calls per device - if chan->_softhangup then it doesn't block device anymore |
| 16:08.52 | *** join/#asterisk-dev jsmith (n=jsmith@72.21.36.138) |
| 16:08.52 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 16:12.43 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177584655.dsl.bell.ca) |
| 16:13.19 | *** join/#asterisk-dev moy (n=moyhu@nat/ibm/x-4a2884508981f8d3) |
| 16:14.01 | *** join/#asterisk-dev fakhir (n=fakhir@unaffiliated/fakhir) |
| 16:15.44 | jmls_away | yikes |
| 16:15.47 | jmls_away | ps -ef |
| 16:15.59 | jmls_away | how many times should /usr/sbin/asterisk be in this list ? |
| 16:16.28 | bweschke | on linux ? |
| 16:16.30 | bweschke | or bsd? |
| 16:16.31 | bweschke | or? |
| 16:16.32 | jmls_away | yup |
| 16:16.34 | file | that depends... some systems show threads as separate processes, others do not |
| 16:16.35 | jmls_away | linux |
| 16:17.13 | bweschke | I've got it once with ps -ef on a fedora machine here |
| 16:17.21 | jmls_away | centos 5 2.6.9-55 |
| 16:19.14 | jmls | is there a way of ignoring threads as separate processes ? |
| 16:23.49 | tzafrir | you want to see all the threads? |
| 16:23.54 | tzafrir | -m, IIRC |
| 16:24.09 | jmls | no, I want to see if all the /usr/sbin/asterisk are threads ;) |
| 16:24.25 | jmls | iow I want to see only the "main" processes, not the threads |
| 16:24.55 | jmls | I currently have 56 /usr/sbin/asterisk listed in ps -ef |
| 16:25.32 | jmls | we've had problems since I updated to 1.4 svn 98467 |
| 16:26.29 | tzafrir | ps (1) mentions ps -eLf and ps axms |
| 16:27.20 | jmls | Hmm. the PID is the same, the PPiID is the same |
| 16:27.32 | jmls | so I think it must be the one process |
| 16:31.58 | jmls | no, there's something wrong here. Phys memory is being eaten up, and now swap is being gobbled |
| 16:33.25 | tzafrir | what do you mean? who eats memory? you can easily see that with ps| sort or top ('M') |
| 16:34.17 | jmls | <PROTECTED> |
| 16:34.36 | jmls | 903m 832m 7932 S 0.0 82.3 0:00.58 asterisk |
| 16:34.44 | tzafrir | 832 resident? |
| 16:34.49 | jmls | yup |
| 16:35.26 | jmls | 915m 832m 7932 S 0.0 82.3 0:00.07 asterisk |
| 16:35.35 | jmls | oh, crap |
| 16:35.47 | jmls | that's why it's crashed twice today, it runs out of swap |
| 16:36.03 | tzafrir | debug memory allocations? :-( |
| 16:36.31 | jmls | I'm someone who has zero knowledge on how to even start this :( |
| 16:36.59 | tzafrir | There's one such option in the compile flags |
| 16:37.48 | jmls | yeah, it would be nice, but this is a live system and I'm getting a beating already. |
| 16:38.00 | jmls | I'm gonna have to revert to a previous version |
| 16:38.03 | tzafrir | After you do that, you'll be able to see how much exactly was allocated from various parts of the code. |
| 16:38.34 | tzafrir | ideally 700MB or so of that 800MB would be from one specific allocation point... |
| 16:39.10 | tzafrir | ah, ok |
| 16:39.32 | jmls | is that malloc debug ? |
| 16:39.45 | jmls | what impact does it have on performance ? |
| 16:39.54 | jmls | I'd like to find the problem |
| 16:40.08 | jmls | but not at the expense of my life 8-) |
| 16:49.46 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 16:51.17 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.12.183) |
| 16:52.29 | jmls | is there any memory stuff I can do whilst it's running ? |
| 16:52.33 | jmls | gdb / etc |
| 16:53.40 | jsmith | jmls: As I recall, there are some CLI commands to check the memory allocations |
| 16:53.49 | jsmith | jmls: That's about all I know, unfortunately |
| 16:54.45 | tzafrir | The only spring into action if Asteirsk is built with memory allocation support, IIRC |
| 16:55.54 | jmls | tzafrir: is there any impact on having memory allocation support compiled ? I have reverted to r98614 and need to recompile now anyway |
| 16:56.17 | tzafrir | IIRC there isn't much of an impact. But I waited for someone else to respond |
| 16:56.30 | jmls | malloc_debug, yes ? |
| 16:56.52 | tzafrir | right |
| 16:57.05 | jmls | make clean; make install on it's way ;) |
| 17:04.52 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 17:07.28 | Simon-- | is there a module for "core show locks", or something that needs to be enabled for it to show up? |
| 17:08.14 | file | DEBUG_THREADS Compiler Flag. |
| 17:09.06 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 17:13.50 | *** join/#asterisk-dev Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 17:13.50 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 17:18.12 | *** join/#asterisk-dev key2 (n=Ritual@193.33.36.20) |
| 17:18.57 | jmls | how do I stop memory show allocations ? |
| 17:18.59 | jmls | :( |
| 17:19.18 | outtolunc | unload the module <G> checking |
| 17:19.25 | *** part/#asterisk-dev key2 (n=Ritual@193.33.36.20) |
| 17:19.28 | jmls | exit worked for me |
| 17:19.30 | jmls | :) |
| 17:20.40 | jmls | memory seems to be going up at 1m per second or so |
| 17:20.46 | jmls | asterisk usage that is |
| 17:22.47 | jmls | yikes. Just doubled is resident size, from 50m to 110m |
| 17:23.28 | bweschke | what does "memory show summary" tell you ? |
| 17:23.49 | jmls | a whole list of xxx bytes in yyy allocations in file |
| 17:23.57 | jmls | 41390723 bytes ( 31521503 cache) in 268556 allocations in file 'frame.c |
| 17:24.04 | bweschke | frame.c is growing ? |
| 17:24.08 | jmls | oh, yes |
| 17:24.09 | Qwell | russellb: did you see that email from rizzo on -dev, about chan_oss indications? |
| 17:24.16 | jmls | <PROTECTED> |
| 17:24.20 | Qwell | ahh, nm |
| 17:24.23 | Qwell | stupid thunderbird |
| 17:24.28 | jmls | 47826693 bytes ( 36702689 cache) in 302702 allocations in file 'frame.c' |
| 17:24.41 | russellb | already responded |
| 17:24.47 | Qwell | yeah, saw..sorry :D |
| 17:24.53 | russellb | someone needs to test it ... |
| 17:24.55 | jmls | <PROTECTED> |
| 17:25.02 | jmls | bweschke: is that a bad thing ? |
| 17:25.07 | bweschke | jmls: quite, yes |
| 17:25.11 | russellb | jmls: do you have a bunch of calls? |
| 17:25.12 | jmls | ;) |
| 17:25.22 | jmls | 21 channels, 11 calls |
| 17:25.25 | bweschke | it should rise as your volume of calls rises |
| 17:25.26 | bweschke | but |
| 17:25.34 | bweschke | not rise as the duration of those calls go on |
| 17:25.40 | russellb | i would expect the total size to be close to the cache size |
| 17:25.45 | jmls | <PROTECTED> |
| 17:25.50 | russellb | yeah, that's bad |
| 17:25.53 | jmls | 20 channels, 10 calls |
| 17:25.54 | russellb | frames are likely leaking somewhere |
| 17:26.03 | russellb | best way to find out is to hang up all the calls ... |
| 17:26.15 | russellb | the cache will go away ... anything left over is leaked frames |
| 17:26.15 | jmls | right. Ops would be pleased :) |
| 17:26.49 | jmls | 69825005 bytes ( 54360257 cache) in 422114 allocations in file 'frame.c', with same number of calls |
| 17:27.03 | jmls | this is r98614 |
| 17:27.06 | jmls | 1.4 svn |
| 17:27.45 | russellb | using app_queue ? |
| 17:27.50 | jmls | yes .. |
| 17:27.52 | russellb | putnopvut: ping |
| 17:28.14 | russellb | putnopvut: I have a feeling we need to review recent changes to app_queue for frame leaks |
| 17:29.29 | Corydon76-lap | jmls: I have something for you to try |
| 17:29.34 | jmls | okay .. |
| 17:29.35 | russellb | jmls: any modifications? |
| 17:29.42 | Qwell | that wouldn't have anything to do with 97978, would it? |
| 17:29.50 | russellb | i don't see anything in app_queue that looks like ti would leak frames ... |
| 17:29.58 | jmls | russellb: I don't either |
| 17:30.00 | Corydon76-lap | in main/translate.c, at the end of ast_trans_frameout, change return ast_frisolate(f); to return f; |
| 17:30.08 | Qwell | heh, it would :D |
| 17:30.55 | russellb | Corydon76-dig: yes, that is definitely the culprit ... |
| 17:31.17 | Corydon76-lap | Shouldn't frames get called with ast_frfree() in all cases? |
| 17:32.06 | russellb | i'm not sure what crash you were fixing ... but it seems like the fix should be elsewhere |
| 17:32.15 | jmls | is that all the changes required ? I'm getting people to log out now so I can restart asterisk with the patch |
| 17:32.31 | russellb | jmls: yeah, should be |
| 17:32.51 | Corydon76-lap | russellb: the problem is that it's returning with memory that could be immediately freed |
| 17:32.56 | jmls | ok, when the 30 calls are finished, I'll restart. |
| 17:32.58 | Corydon76-lap | russellb: as the comment says |
| 17:33.34 | *** join/#asterisk-dev jpeeler (n=jpeeler@216.207.245.1) |
| 17:33.45 | Corydon76-lap | Masquerading is the instance that causes that memory to be freed |
| 17:34.42 | Corydon76-lap | so it should frisolate or frdup, shouldn't it? |
| 17:35.04 | jmls | Corydon76-lap: got res_config_curl working with voicemail |
| 17:35.12 | Corydon76-lap | jmls: sweet |
| 17:35.25 | russellb | Corydon76-dig: well, there are a lot of places in Asterisk that use static frames like this, and they haven't broken before ... |
| 17:35.39 | jmls | very. I had to patch it, see the bug report. I also added some comments |
| 17:36.21 | Corydon76-lap | russellb: I'm pretty sure that most places use stack memory, though |
| 17:36.37 | russellb | not necessarily ... there is a frame in the rtp structure |
| 17:36.43 | russellb | same with stuff in iax2 |
| 17:37.16 | russellb | but i want to revert this change and figure out how to fix whatever crash was caused another way |
| 17:37.24 | Corydon76-lap | Well, take a look at 11698 and see if you see an alternate way to do it |
| 17:37.25 | russellb | this causes multiple malloc()'s for _every_ transcoded frame |
| 17:38.13 | file | which is bad, mmmk? |
| 17:38.24 | tzanger | what's wrong with a little malloc |
| 17:38.27 | tzanger | jeez you guys are no fun |
| 17:38.37 | Corydon76-lap | Well, malloc or crash, ummmm |
| 17:38.42 | russellb | heh |
| 17:38.45 | Corydon76-lap | Anyway |
| 17:38.48 | tzanger | my personal favourite is malloc and crash |
| 17:39.04 | russellb | Corydon76-dig: it's all good, we'll figure it out another way |
| 17:39.21 | Corydon76-lap | russellb: I'll be interested to see what you come up with |
| 17:39.40 | file | tzanger: are you malloced? |
| 17:39.42 | Corydon76-lap | or whoever fixes it, what the solution is |
| 17:39.53 | russellb | Corydon76-dig: yeah, i'll try to work on it this afternoon, after our meeting |
| 17:39.56 | russellb | for now, it's lunch time. |
| 17:39.57 | tzanger | file: I'm definitely something |
| 17:40.10 | file | yes, go to lunch now or else you shall be late |
| 17:41.03 | jmls | hey hey hey |
| 17:41.17 | jmls | frame.c is no longer appearing in memory show summary |
| 17:43.16 | putnopvut | russellb: pong |
| 17:43.24 | jmls | putnopvut: you missed the fun |
| 17:44.00 | jmls | when I do a "make update" is there a "version history" |
| 17:44.09 | jmls | i.e. went from rxxxx to ryyyy |
| 17:44.31 | Corydon76-lap | Nope, would be neat, though |
| 17:44.37 | jmls | would be very useful |
| 17:45.13 | jmls | help people like me revert ;) |
| 17:45.22 | putnopvut | jmls: yes I did. |
| 17:45.26 | jmls | definately fixed - asterisk is stable at 15M |
| 17:45.31 | Corydon76-lap | We expect your patch within 48 hours. ;-) |
| 17:45.32 | jmls | thanks very much guys |
| 17:46.00 | jmls | Corydon76-dig: ha! |
| 17:48.49 | Corydon76-lap | jmls: didn't you hear? Those are the rules... |
| 17:49.13 | Corydon76-lap | You come up with a great idea, it's automatically assigned to you. ;-) |
| 17:49.33 | putnopvut | Hm, so I guess I didn't fsck up app_queue too badly then? |
| 17:50.47 | file | putnopvut: you didn't... much |
| 17:51.51 | *** join/#asterisk-dev kamanashisroy (n=root@202.56.7.135) |
| 17:52.58 | kamanashisroy | Hi, I have a problem regarding dial, I wanted to execute dialplan while two channels are bridged .. I used G() option while dialing .. |
| 17:53.03 | kamanashisroy | http://paste.uni.cc/18094 here is the story |
| 17:53.22 | kamanashisroy | finally I could not find how to hangup one channel when other hangs up :( |
| 17:53.51 | kamanashisroy | and I think we can write an application 'stillTalking' which will return 0/1 , 0 when the bridged channel is not talking ..else 1 |
| 17:53.59 | kamanashisroy | if(bchan = ast_bridged_channel(chan)) { return !(ast_check_hangup(bchan)) } return 0; |
| 17:54.06 | kamanashisroy | what do you think ? |
| 17:54.22 | mvanbaak | hey Corydon76-lap |
| 17:54.48 | Corydon76-lap | Morning, mvanbaak |
| 17:55.16 | mvanbaak | Corydon76-lap: when is the best time to bug you bout cdr_adaptive_odbc (or vice versa) |
| 17:55.41 | Corydon76-lap | Now, I guess |
| 17:55.58 | mvanbaak | ok |
| 17:56.07 | mvanbaak | I just want some pointers |
| 17:56.18 | mvanbaak | this is my setup (well, the setup I want) |
| 17:56.35 | mvanbaak | I have a couple of contexts in my dialplan |
| 17:56.40 | Corydon76-lap | Okay, how about 0x24ff673a |
| 17:56.50 | mvanbaak | calls starting in context 1 should log to db1 |
| 17:56.58 | Corydon76-lap | and 0x24ff67fe |
| 17:56.59 | mvanbaak | calls starting in context 2 should log to db2 |
| 17:57.01 | jsmith | Corydon76-dig: That's a great pointer! |
| 17:57.05 | file | hey! that's MY pointer |
| 17:57.12 | mvanbaak | is that possible with adaptive ? |
| 17:57.19 | mvanbaak | I cannot see how |
| 17:57.26 | Corydon76-lap | mvanbaak: nope |
| 17:57.42 | Corydon76-lap | mvanbaak: all calls get logged to every database |
| 17:57.52 | mvanbaak | ah |
| 17:58.00 | mvanbaak | now the code makes sense to me |
| 17:58.08 | mvanbaak | I was reading it with this idea in mind |
| 17:58.15 | mvanbaak | so I got stuck over and over again |
| 17:58.29 | mvanbaak | hhmm |
| 17:58.38 | Corydon76-lap | That's an interesting idea, but not what adaptive implements |
| 17:58.51 | mvanbaak | back to the drawing board |
| 17:59.15 | mvanbaak | the csv backend creates a file based on accountcode |
| 17:59.41 | mvanbaak | so I was thinking you could pick a [somesection] from adaptive configfile based on the accountcode |
| 17:59.49 | mvanbaak | that would've been awesome :) |
| 18:00.33 | mvanbaak | my main problem is: I have a pbx that hosts multiple customers. I want to log calls made from/to a customer to their own CRM database |
| 18:00.50 | mvanbaak | now I can do that with adaptive and some extra filtering in the CRM app |
| 18:01.12 | mvanbaak | so, I can get it implemented and no need to disappoint my boss |
| 18:01.29 | Corydon76-lap | You could do it with triggers |
| 18:01.41 | jmls | Corydon76-lap: done |
| 18:01.54 | jmls | M11766 |
| 18:01.55 | MuffinMan | [new] [Asterisk] Core/BuildSystem 0011766: [patch] Add log of version updates reported by jmls http://bugs.digium.com/view.php?id=11766 |
| 18:02.02 | *** join/#asterisk-dev atisss (n=atisss@193.238.212.171) |
| 18:02.14 | Corydon76-lap | jmls: nice... I was just kidding, but we'll take it. ;-) |
| 18:02.20 | jmls | lol |
| 18:02.53 | mvanbaak | Corydon76-lap: yeah, triggers in mysql....... |
| 18:03.01 | Corydon76-lap | mvanbaak: if you set a particular column with a value that says "not here", then adaptive will try, then fail |
| 18:03.18 | Corydon76-lap | Ah... |
| 18:03.48 | Corydon76-lap | I think it only retries once. |
| 18:05.30 | Corydon76-lap | mvanbaak: triggers are the only way with adaptive... it's much too forgiving of the data for you to try anything else |
| 18:06.24 | mvanbaak | yeah |
| 18:06.43 | mvanbaak | I'll see what I can do |
| 18:07.19 | mvanbaak | maybe if I understand adaptive some more I can patch it. but not right now |
| 18:07.52 | jsmith | mvanbaak: Or, could you use views to only show a subset of the data to each customer? |
| 18:08.25 | mvanbaak | jsmith: yeah, I was thinking about that |
| 18:08.41 | mvanbaak | but, it would put a lot of extra data in the database that I'll never use |
| 18:08.53 | mvanbaak | so some sort of cleanup is needed |
| 18:14.37 | kamanashisroy | Hi, I have a problem regarding dial, I wanted to execute dialplan while two channels are bridged .. I used G() option while dialing .. |
| 18:14.37 | kamanashisroy | http://paste.uni.cc/18094 here is the story |
| 18:14.37 | kamanashisroy | what do you think ? |
| 18:15.02 | mvanbaak | kamanashisroy: I think you should ask in #asterisk |
| 18:15.58 | kamanashisroy | mvanbaak: I have done that and I also included the discussion from that place in the pasteabin .. |
| 18:16.32 | kamanashisroy | mvanbaak:actually that did not lead a solution .. But I think we need an dialplan application finally .. |
| 18:16.55 | kamanashisroy | Imvanbaak: think we can write an application 'stillTalking' which will return 0/1 , 0 when the bridged channel is not talking ..else 1 |
| 18:17.10 | kamanashisroy | Imvanbaak: if(bchan = ast_bridged_channel(chan)) { return !(ast_check_hangup(bchan)) } return 0; |
| 18:21.53 | kamanashisroy | let me know what you think ? |
| 18:22.23 | mvanbaak | so you need to do something whenever the called party hangsup eh ? |
| 18:22.47 | mvanbaak | cant you use the h exten for that ? |
| 18:22.59 | file | the G option doesn't do what you seem to think it does... |
| 18:23.10 | file | as soon as both channels are answered and up they both go to that place in the dialplan |
| 18:23.27 | file | (that is specified/documented) |
| 18:23.34 | file | they aren't bridged together. |
| 18:24.19 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 18:25.33 | file | you can't execute dialplan logic like that while they are bridged together |
| 18:25.35 | kamanashisroy | file: yes it works like that .. and after we go to those channel we do not know when the other party hangs up .. I mean this knowledge is importent , is not it ? |
| 18:25.35 | kamanashisroy | mvanbaak: good idea, but it continues to loop in the 'while loop' .. |
| 18:26.12 | kamanashisroy | kams: But I can hear the voice in the both end .. right ? |
| 18:26.18 | file | kamanashisroy: no it's not, because the two channels are no longer talking to eachother... they are two separate channels executing dialplan logic separately |
| 18:26.40 | kamanashisroy | file: I mean it is bridged .. |
| 18:27.25 | file | it's not. |
| 18:27.55 | kamanashisroy | file: I assure you that I have tested .. when the two channes are in different dialplan loops, I talked in one end and heard sound in the other .. |
| 18:28.06 | mvanbaak | yes |
| 18:28.10 | mvanbaak | but they are not bridged |
| 18:28.24 | file | they aren't. |
| 18:29.19 | kamanashisroy | mvanbaak: you mean not bridged .. but the voice pass through the other channels .. ? |
| 18:30.02 | kamanashisroy | file: I do not know what is the meaning of "bridged" , But I can hear sound .. let me test again .. |
| 18:32.11 | kamanashisroy | file: just tested again, when it is sending text message it is also sending voice from the other channel .. |
| 18:32.28 | Qwell | mvanbaak: committed :D:D |
| 18:32.29 | file | how are you testing? |
| 18:32.33 | kamanashisroy | I can hear the voice and also there is an animation when there is voice, so I mean I can also see the voice :) |
| 18:32.50 | mvanbaak | Qwell: whehehehehe |
| 18:33.03 | mvanbaak | thanks man |
| 18:33.14 | mvanbaak | one patch less on my production machine ! |
| 18:33.15 | kamanashisroy | file: I sent you the dialplan http://paste.uni.cc/18095 here |
| 18:33.18 | Qwell | I'm still bothered by the fact that I can only get the icon with cfwdall, but...whatever |
| 18:33.22 | file | not dialplan |
| 18:33.26 | file | I mean how are you physically testing it |
| 18:33.35 | kamanashisroy | I have xlite registered .. |
| 18:33.36 | Qwell | if DEA comes up with some magic packet traces, I'll try to look at it again |
| 18:33.44 | Qwell | I actually should ask him for some... |
| 18:33.47 | kamanashisroy | file: xlite is the caller |
| 18:33.58 | kamanashisroy | file: and yate-gtk2 is the receiver .. |
| 18:34.13 | kamanashisroy | xlite dials 888 |
| 18:34.24 | mvanbaak | Qwell: yeah, we should |
| 18:34.24 | kamanashisroy | asterisk sends call to yate-gtk2 |
| 18:34.30 | kamanashisroy | and after that you can see the log :) |
| 18:34.33 | Qwell | adding a note to that bug..hopefully he'll get it |
| 18:34.59 | file | what are they? what are you calling? |
| 18:35.44 | kamanashisroy | file: I want to place a IP Phone where xlite is sitting now .. |
| 18:35.58 | kamanashisroy | file: and send the ip phone billing information when it is calling .. |
| 18:36.20 | file | call a remote server that just plays back an audio file and see if you hear it |
| 18:36.48 | kamanashisroy | file: so I need to execute the dialplan , fetch data from mysql, and send text messages to the IP phone in each 5 minitues .. |
| 18:37.20 | kamanashisroy | file: I am sorry .. why ? |
| 18:37.26 | file | because I think you're hearing echo. |
| 18:37.38 | file | the two channels do not exchange audio if you use the G option |
| 18:37.53 | kamanashisroy | file: Note, I talked in the yate and saw animation in xlite .. |
| 18:38.18 | file | that's why I said call a remote server that just plays back an audio file... if you hear it then I'm crazy |
| 18:38.41 | mvanbaak | I can hear it ! |
| 18:39.13 | mvanbaak | there goes my karma ;) |
| 18:39.16 | kamanashisroy | in our country I cannot use voip :-P forbidden .. I am just a software engineer writing code :( |
| 18:39.41 | file | you've got Asterisk, create an extension that plays back demo-congrats and use chan_local to call it |
| 18:39.43 | kamanashisroy | I cannot send call to remote server :( |
| 18:39.53 | kamanashisroy | OK |
| 18:40.02 | mvanbaak | ok |
| 18:40.15 | mvanbaak | put the x-lite in a different room, and put a radio close to it |
| 18:40.21 | mvanbaak | set it to auto-answer |
| 18:40.33 | mvanbaak | make sure you cannot hear the radio in the room where yate is |
| 18:40.40 | mvanbaak | there you go |
| 18:42.04 | mvanbaak | btw, you could see in your dialplan the 2 legs are not bridged |
| 18:42.21 | mvanbaak | otherwise the call to Answer() would not complete succesful |
| 18:42.24 | mvanbaak | I think |
| 18:43.14 | bweschke | file: give kamanashisroy your ABBA album for testing - then it will be MoIP, not VoIP |
| 18:43.32 | file | eep! |
| 18:43.56 | kamanashisroy | mvanbaak: I am working on play back hold on .. I shall give you the result soon .. |
| 18:45.49 | mvanbaak | lol bweschke |
| 18:45.58 | bweschke | :-D |
| 18:47.16 | bweschke | I've got the Mamma Mia! cast recording already |
| 18:47.44 | kamanashisroy | file: you are right .. no voice :( |
| 18:47.49 | tzanger | "bridging queen, audio frames with nothing inbetween..." |
| 18:48.01 | kamanashisroy | mvanbaak: no voice :( |
| 18:48.10 | file | kamanashisroy: exactly, there shouldn't be. |
| 18:48.16 | mvanbaak | kamanashisroy: we know :) |
| 18:48.22 | bweschke | and play it with almost the same frequency as I do the Boomtown Rats every Monday morning :-D |
| 18:48.28 | bweschke | tzanger: lol |
| 18:49.02 | file | kamanashisroy: I can't think of any way to do what you want. |
| 18:49.42 | kamanashisroy | file: may be use dial.h and write a dial special application -- bad idea ? |
| 18:50.39 | mvanbaak | better to write some daemon that watches the AMI |
| 18:51.23 | mvanbaak | on call setup start some timer that will send those messages to the phone from time to time |
| 18:51.32 | mvanbaak | stop the timer on call end |
| 18:52.31 | kamanashisroy | mvanbaak: something like background thread .. that will detect the channel answer and start sending message and stop doing this when the channel hangs up .. right ? |
| 18:52.57 | mvanbaak | yeah. but you dont have to put it in asterisk. You can simply monitor the manager interface |
| 18:58.28 | kamanashisroy | than you everyone .. i think I have found the solution :) http://bugs.digium.com/bug_view_page.php?bug_id=6131&history=1#history |
| 18:58.48 | kamanashisroy | thank* you everyone, good bye |
| 19:07.09 | *** part/#asterisk-dev kamanashisroy (n=root@202.56.7.135) |
| 19:38.38 | russellb | Corydon76-dig: ping ... |
| 19:38.39 | russellb | M11698 |
| 19:38.41 | MuffinMan | [assigned] [Asterisk] Core-General 0011698: Segmentation fault / Memory corruption with intensive AMI reported by Callmewind http://bugs.digium.com/view.php?id=11698 |
| 19:38.52 | russellb | Can you point me to which backtrace pointed you to that frame error? |
| 19:39.09 | russellb | i see lots of stuff related to the chan_sip fix, but haven't seen the frame error ... |
| 19:39.11 | russellb | i'm probably blind. |
| 19:42.49 | russellb | oh wait, i think i see the read errors now, in valgrind2.txt |
| 19:51.39 | *** join/#asterisk-dev monkeytype (n=Bill@216.207.245.1) |
| 19:57.28 | *** join/#asterisk-dev Netgeeks (n=chris@204.11.231.198.static.etheric.net) |
| 19:58.32 | *** join/#asterisk-dev mcargile (n=mcargile@rrcs-24-173-134-222.se.biz.rr.com) |
| 20:01.44 | *** join/#asterisk-dev atisss (n=atisss@193.238.212.171) |
| 20:07.02 | russellb | Corydon76-dig: this is a nasty bug |
| 20:07.20 | russellb | Corydon76-dig: so, the issue is that the channel is locked inside of ast_read(), and also inside of ast_write() |
| 20:07.48 | russellb | so, you may retrieve a frame from ast_read(), and the channel gets masqueraded before you re-acquire the channel in ast_write() |
| 20:08.02 | russellb | and, as you have pointed out, the frame built into the translation path is no longer valid at that point |
| 20:08.39 | russellb | so, my first instinct is that the channel needs to be locked for the entire read/write cycle |
| 20:08.47 | russellb | but that means changing _a lot_ of code in asterisk |
| 20:11.27 | russellb | but, i have another idea .... |
| 20:12.19 | russellb | <3 |
| 20:12.25 | file | except when they aren't. |
| 20:13.17 | russellb | right. |
| 20:13.39 | russellb | and we won't speak about the frequency of one vs. the other... |
| 20:13.54 | file | quite. |
| 20:17.17 | mvanbaak | it's fun to look at the .asc files of asterisk releases |
| 20:17.22 | mvanbaak | Version: GnuPG v1.4.6 (GNU/Linux) |
| 20:17.26 | mvanbaak | Version: GnuPG v1.4.7 (Darwin) |
| 20:17.40 | mvanbaak | let's see how many different versions we see in there |
| 20:18.06 | russellb | 1.4.broken (OpenBSD) |
| 20:18.07 | russellb | pwnt |
| 20:18.08 | russellb | :-p |
| 20:18.15 | mvanbaak | hahahaha |
| 20:18.23 | russellb | just trolling. |
| 20:18.47 | mvanbaak | 1.4.6 on OpenBSD as well |
| 20:18.55 | mvanbaak | 4.1 that is |
| 20:19.19 | *** join/#asterisk-dev _mihai_ (n=_mihai_@x42073b02.ip.e-nt.net) |
| 20:19.42 | mvanbaak | 1.4.7p0 on my workstation |
| 20:20.08 | anonymouz666 | _mihai_ joining the ast-dev it means some iax2 stuff. |
| 20:20.35 | mvanbaak | ut-oh |
| 20:20.36 | _mihai_ | oh noes, I've got a bad rep :) |
| 20:20.44 | _mihai_ | hi all, |
| 20:20.54 | mvanbaak | lol, heya _mihai_ |
| 20:20.57 | _mihai_ | no iax2 stuff, just thought i'd drop by and say hi |
| 20:22.39 | russellb | while you're here, i figured i'd throw these 20 iax2 bugs at you |
| 20:22.40 | russellb | (not really) |
| 20:23.04 | mvanbaak | btw, you should update the svnmerge script |
| 20:23.08 | mvanbaak | <PROTECTED> |
| 20:23.25 | russellb | mvanbaak: did our -P -B options get upstream? |
| 20:23.27 | russellb | if so, we can just copy it in |
| 20:23.28 | mvanbaak | it's testend as working in OpenBSD and OSX as well |
| 20:24.24 | russellb | i'm pretty sure those were the only things we added ... |
| 20:24.38 | mvanbaak | nah |
| 20:24.49 | russellb | probably small changes, though ... |
| 20:24.56 | russellb | wanna submit a patch to get ours updated? :) |
| 20:24.57 | mvanbaak | 12 lines of 'Differences from official svnmerge" |
| 20:25.12 | mvanbaak | working on it already |
| 20:29.27 | *** join/#asterisk-dev shido6 (n=shido6@204.126.120.132) |
| 20:31.35 | mvanbaak | whoa |
| 20:31.39 | mvanbaak | differences are huge |
| 20:44.51 | *** join/#asterisk-dev atisss (n=atisss@193.238.212.171) |
| 20:47.49 | mvanbaak | cool, the new svnmerge has a rollback method |
| 20:48.50 | *** join/#asterisk-dev ZX81 (n=ZX81@202.49.106.158) |
| 20:55.07 | mvanbaak | the -P is not there yet |
| 20:55.12 | mvanbaak | but the blocked thing is |
| 20:58.56 | russellb | odd |
| 21:00.01 | jmls | Corydon76-dig: ping |
| 21:02.30 | Corydon76-lap | pong |
| 21:07.45 | jmls | wondering if you've had a chance to look at the comments on the bug for res_config_curl |
| 21:09.45 | Corydon76-lap | Yep |
| 21:10.22 | Corydon76-lap | jmls: the reason I did it the way I did was to avoid conflicts with possible column names |
| 21:10.56 | Corydon76-lap | although I certainly could change the default single query from "" to "single" or something like that |
| 21:12.42 | jmls | having something rather than nothing is better |
| 21:12.55 | Corydon76-lap | Okay, I'll make that change shortly |
| 21:13.17 | jmls | ok, and the other change was the "mode" - why have that as part of PATH_INFO ? Why not as a "mode" post variable ? |
| 21:13.51 | Corydon76-lap | To avoid conflicts with table names |
| 21:13.57 | Corydon76-lap | or column names, rather |
| 21:14.34 | Corydon76-lap | Consider update, where we have two different classes of data... one for lookup, one for update |
| 21:14.53 | jmls | ok .. |
| 21:14.57 | Corydon76-lap | That's why I put the lookup in the GET and the update in the POST |
| 21:15.39 | jmls | mmm, ok. |
| 21:15.59 | Corydon76-lap | and the rest of them are just universally like that, for consistency |
| 21:16.07 | jmls | fair enough |
| 21:16.15 | jmls | were my patches alright, though ? |
| 21:16.28 | jmls | well, ok, patch |
| 21:16.37 | Corydon76-lap | Sure, I did it a slightly different way... I declared a constant and used it in both places |
| 21:16.44 | jmls | that was a bugger to track down for a non-c developer ;) |
| 21:17.14 | jmls | and is there any chance of a 1.4 backport ? I could use it in production then .. |
| 21:17.18 | Corydon76-lap | Reason being, you can then alter the constant and both halves work correctly |
| 21:17.33 | Corydon76-lap | I can look at it this afternoon |
| 21:17.37 | jmls | Corydon76-lap: sergee suggested that to me |
| 21:17.54 | jmls | but you used 64000, 256000 and 100 for buffer ;) |
| 21:18.01 | jmls | in different place of the code. |
| 21:18.25 | Corydon76-lap | Yeah, just arbitrary constants |
| 21:18.33 | Corydon76-lap | No rhyme or reason, really |
| 21:18.53 | jmls | hrh |
| 21:19.12 | jmls | and how's that supposed to help the week and needy like me to learn ? |
| 21:19.18 | jmls | <PROTECTED> |
| 21:19.59 | Corydon76-lap | Well, we normally use even constants, but somebody pointed out that the chunks used are actually larger, due to malloc's internal memory structures that also need to be part of the allocation request |
| 21:20.30 | Corydon76-lap | So I dropped it a little bit, to ensure we don't allocate memory unnecessarily |
| 21:21.06 | Corydon76-lap | That's probably a little more information than you need |
| 21:21.59 | russellb | Corydon76-dig: see rev 98853 |
| 21:22.12 | russellb | it's a ... hack ... |
| 21:22.26 | Corydon76-lap | hooray |
| 21:22.37 | russellb | but let me know what you think ... |
| 21:23.02 | Corydon76-lap | Holy cow |
| 21:23.14 | Corydon76-lap | That's a very invasive fix |
| 21:23.21 | russellb | heh |
| 21:24.13 | russellb | it's the only thing i could think of that was API and ABI compatible, and didn't involve changing up channel locking in _every_ place that calls ast_read / ast_write |
| 21:24.25 | Corydon76-lap | Right |
| 21:31.51 | *** part/#asterisk-dev corramor (n=corramor@nat/digium/x-299cbec17f22e2b9) |
| 21:31.53 | russellb | Corydon76-dig: did you see my pointer grossness in ast_translate_frame_freed() ? |
| 21:38.49 | mvanbaak | hhmm |
| 21:39.02 | mvanbaak | there's some weird stuff in digium svnmerge |
| 21:39.27 | mvanbaak | <PROTECTED> |
| 21:39.35 | mvanbaak | but it's listed as: -B |
| 21:41.42 | mvanbaak | ah |
| 21:41.44 | mvanbaak | never mind |
| 21:44.31 | *** join/#asterisk-dev atisss (n=atisss@193.238.212.171) |
| 21:52.22 | jmls | russellb: remember the 1.6 compile times were much slower than 1.4 ? |
| 21:52.56 | jmls | think I found it - 1.4 didn't have any debug stuff in the compiler flags |
| 21:53.51 | *** join/#asterisk-dev crich_de (n=crich@port-212-202-36-195.dynamic.qsc.de) |
| 21:54.09 | russellb | jmls: i think i turned them back on though |
| 21:54.57 | mvanbaak | russellb: does your svnmerge do '--record-only' ? |
| 21:55.03 | russellb | no idea |
| 21:55.05 | russellb | never heard of it |
| 21:55.17 | mvanbaak | Add the ability to mark revisions as merged via 'merge --record-only', |
| 21:55.17 | mvanbaak | effectively a way to manipulate the merge memory stored in the |
| 21:55.17 | mvanbaak | "svnmerge-integrated" property. This is the converse of the 'block' |
| 21:55.18 | mvanbaak | concept (which marks revisions which shouldn't be merged). |
| 21:56.12 | mvanbaak | we use it from time to time |
| 21:56.17 | mvanbaak | say, you commit something to trunk |
| 21:56.28 | mvanbaak | and the gods decide it should go into 1.4 as well |
| 21:56.32 | mvanbaak | what do you do? |
| 21:56.41 | mvanbaak | you commit it to 1.4 and block it from trunk ? |
| 21:56.43 | file | get a drink and pass out? |
| 21:56.52 | mvanbaak | file ;) |
| 21:57.42 | mvanbaak | can you try this please: svnmerge help merge |
| 21:57.50 | mvanbaak | does it show a -M option ? |
| 21:58.00 | mvanbaak | I think not |
| 21:58.21 | mvanbaak | no, it doesn't |
| 22:16.57 | jmls | can you use #exec in the [globals] section ? |
| 22:17.07 | *** join/#asterisk-dev corramor (n=corramor@216.207.245.1) |
| 22:17.32 | kpfleming | yes... #exec is handled by the text file parser |
| 22:18.10 | mvanbaak | kpfleming: where do you use the exit code of svnmerge ? |
| 22:18.17 | kpfleming | eh? |
| 22:18.34 | mvanbaak | rev 6 of digium svnmerge: |
| 22:18.36 | mvanbaak | support different return values, and return '2' when 'avail' has nothing to merge |
| 22:18.37 | jmls | excellent. That saves a heap of trouble. thanks |
| 22:18.48 | jmls_sleeping | goodnight all |
| 22:18.53 | kpfleming | mvanbaak: probably in our automerge script |
| 22:19.00 | jmls_sleeping | thanks for all the help tracking down that memory leak guys. |
| 22:19.14 | jmls_sleeping | Corydon76-dig: thanks for res_config_curl ;) |
| 22:19.25 | mvanbaak | kpfleming: I'm trying to get your svnmerge up to upstream version |
| 22:19.25 | *** join/#asterisk-dev codefreeze (n=steve_mu@216.166.159.235) |
| 22:19.25 | *** mode/#asterisk-dev [+o codefreeze] by ChanServ |
| 22:19.34 | kpfleming | that would be cool |
| 22:19.53 | mvanbaak | digium version misses some really cool stuff that is in the upstream version |
| 22:21.12 | mvanbaak | 2 things that will make your life easier: |
| 22:21.18 | mvanbaak | rollback of an svnmerge |
| 22:21.56 | mvanbaak | without 2way 'svnmerge init' being able to create a patch for trunk if a branch was made from trunk |
| 22:22.16 | mvanbaak | it will 'find and ignore svnmerge commits to this branch' |
| 22:22.59 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 22:23.09 | kpfleming | that would be nice |
| 22:23.18 | mvanbaak | yeah |
| 22:23.25 | mvanbaak | I have the -P and -B already in |
| 22:23.34 | mvanbaak | I'm now fighting with the exit code :) |
| 22:24.14 | mvanbaak | oh, and the new version will help rizzo |
| 22:24.21 | mvanbaak | <PROTECTED> |
| 22:25.57 | mvanbaak | and it uses the the python 2.4 subprocess module instead of the popen stuff |
| 22:26.07 | mvanbaak | that one is like 350% faster |
| 22:26.54 | mvanbaak | hhmm |
| 22:27.19 | mvanbaak | your --ignore-ancestry is no longer needed |
| 22:27.50 | mvanbaak | Prevent spurious conflicts on the merge and blocked property |
| 22:27.50 | mvanbaak | when the source branch contains merge property information for |
| 22:27.51 | mvanbaak | other branches i.e. a transitive merge A -> B -> C is executed. |
| 22:29.53 | mvanbaak | Implement `svnmerge rollback'. |
| 22:29.54 | mvanbaak | The `rollback' sub-command can be used to rollback previously integrated |
| 22:29.54 | mvanbaak | revisions. |
| 22:29.57 | mvanbaak | OEH ! |
| 22:30.27 | mvanbaak | ok, I'll work on the exit code |
| 22:32.00 | mvanbaak | hhmm, you also have a patch to allow 'avail' to work on a non working copy.... |
| 22:32.02 | *** join/#asterisk-dev magumbade (n=magumbad@ppp-82-135-5-188.dynamic.mnet-online.de) |
| 22:41.03 | *** join/#asterisk-dev outtolunc (n=me@adsl-66-218-53-172.dslextreme.com) |
| 22:58.01 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177585286.dsl.bell.ca) |
| 23:04.03 | *** join/#asterisk-dev Shaun2222 (n=Shaun222@ip68-4-127-67.oc.oc.cox.net) |
| 23:04.33 | Shaun2222 | from what i've read WaitExtn() doesnt work in macro's, is there a workaround or patch or somthing to fix this? |
| 23:04.59 | Corydon76-lap | This is not tier 2 support |
| 23:05.07 | Corydon76-lap | See topic |
| 23:08.21 | mvanbaak | meh |
| 23:08.33 | mvanbaak | running svnmerge on zaptel/trunk is fun |
| 23:08.40 | Qwell | mvanbaak: don't. |
| 23:08.49 | mvanbaak | duh |
| 23:08.51 | Qwell | it's seriously b0rked |
| 23:08.56 | mvanbaak | yup |
| 23:09.01 | mvanbaak | big time |
| 23:09.51 | mvanbaak | I think the only remedy is: svn remove ${digium}/zaptel/trunk && svn copy ${digium}/zaptel/branches/1.4 ${digium}/zaptel/trunk |
| 23:11.12 | Qwell | mvanbaak: that's what we're going to do eventually |
| 23:11.28 | mvanbaak | btw |
| 23:11.46 | mvanbaak | will CCME be any good to grab packetdumps for the chan_skinny stuff ? |
| 23:11.52 | Qwell | no idea |
| 23:12.11 | Qwell | and DEA says he'd be happy to get cfwdbusy traces...except he can't get CCM to *DO* cfwdbusy :p |
| 23:12.29 | Qwell | it's not a default softkey, and it's apparently undocumented, or something... |
| 23:12.37 | mvanbaak | I'm renewig my cisco account, and it gives me access to CCME images |
| 23:12.52 | mvanbaak | I already have a virtual machine setup for it |
| 23:12.59 | mvanbaak | so I can deploy CCME on it |
| 23:20.36 | *** join/#asterisk-dev anthm (n=anthm@mb50736d0.tmodns.net) |
| 23:20.36 | *** mode/#asterisk-dev [+o anthm] by ChanServ |
| 23:30.12 | *** part/#asterisk-dev sruffell (n=sruffell@216.207.245.1) |
| 23:32.02 | mog | Qwell, you around |
| 23:32.05 | Qwell | am |
| 23:32.21 | mog | you seen this [2055615.832634] ioctl32(asterisk:32334): Unknown cmd fd(10) cmd(80044a2f){t:'J';sz:4} arg(ffce50e0) on /dev/zap/timer |
| 23:32.25 | Qwell | nope.. |
| 23:32.42 | mog | on a sparc64 |
| 23:32.57 | mog | was trying to ztdummy |
| 23:32.59 | Qwell | oh |
| 23:33.11 | Qwell | yeah, don't bother |
| 23:33.14 | mog | lol |
| 23:33.15 | mog | wahhh |
| 23:33.21 | mog | oh well |
| 23:33.29 | Qwell | it uses 32-bit on kernel, and 64-bit on userspace...or backwards. it doesn't work |
| 23:33.39 | mog | gross |
| 23:33.42 | mog | its ubuntu |
| 23:33.47 | mog | im suprised they would do that |
| 23:33.55 | Qwell | nah, that's what everybody does with sparc64 |
| 23:34.01 | Qwell | it's the "right" way to do it |
| 23:34.30 | Qwell | zaptel would need to support compat ioctls for that to work |
| 23:34.35 | mog | yea |
| 23:35.58 | *** join/#asterisk-dev RoyK (n=roy@91.149.27.45) |
| 23:38.59 | *** join/#asterisk-dev Victor_Yure (n=Victor_Y@201.9.1.95) |
| 23:43.55 | *** part/#asterisk-dev RoyK (n=roy@91.149.27.45) |