| 00:22.47 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 00:38.42 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 00:38.42 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 01:03.49 | *** join/#asterisk-dev jetsnoc (i=brian@207-150-160-180.static.sagonet.net) |
| 01:04.24 | *** join/#asterisk-dev khalidkolsi (n=khalidko@119.63.136.59) |
| 01:04.28 | khalidkolsi | hello |
| 01:05.13 | khalidkolsi | any one here that can help me plz |
| 01:20.51 | *** join/#asterisk-dev seanbright (n=sean@asterisk/contributor-and-bug-marshal/seanbright) |
| 01:20.51 | *** mode/#asterisk-dev [+o seanbright] by ChanServ |
| 01:23.22 | *** join/#asterisk-dev Deeewayne (n=dwayne@76.29.245.9) |
| 01:23.22 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 02:37.18 | seanbright | file: ping? |
| 02:37.42 | file | pong? |
| 02:37.55 | seanbright | something is wonky with streaming audio and moh in 1.4 |
| 02:38.06 | seanbright | and i see that you did a couple of commits in regards to that recently |
| 02:38.16 | seanbright | and by wonky i mean "i doesn't work" |
| 02:39.44 | file | oh goody. |
| 02:39.54 | seanbright | http://pastie.org/private/nn9lskyyfowzvzwrchp3a |
| 02:39.57 | seanbright | that's my config |
| 02:40.14 | seanbright | i can copy that m3u url into itunes and it plays without a problem |
| 02:40.24 | file | download the m3u and get the actual stream URL |
| 02:40.44 | russellb | is this config that used to work? |
| 02:41.26 | seanbright | claims a user on mantis, yes. |
| 02:42.04 | seanbright | M15134 |
| 02:42.06 | MuffinMan | [new] [Asterisk] Resources/res_musiconhold 0015134: asterisk does not stream using currrent versions of mpg123 reported by johnakabean (Karma: neutral) https://issues.asterisk.org/view.php?id=15134 |
| 02:42.12 | seanbright | but i mean... it *should* work |
| 02:44.22 | russellb | i would ask him to find a previous version that did work ... |
| 02:44.34 | russellb | before we go looking for a change that broke something that didn't happen ... |
| 02:44.53 | file | I tested using di.fm when I did my last changes and it did work then |
| 02:45.15 | seanbright | hmm |
| 02:45.17 | russellb | shrugs |
| 02:45.20 | seanbright | i see a lot of this: |
| 02:45.21 | seanbright | [Jun 4 22:44:43] DEBUG[22219] res_musiconhold.c: Read 39 bytes of audio while expecting 640 |
| 02:45.24 | seanbright | [Jun 4 22:44:44] DEBUG[22219] res_musiconhold.c: Read 147 bytes of audio while expecting 640 |
| 02:45.27 | seanbright | [Jun 4 22:44:44] DEBUG[22219] res_musiconhold.c: Read 39 bytes of audio while expecting 640 |
| 02:45.27 | russellb | orly. |
| 02:45.30 | seanbright | [Jun 4 22:44:44] DEBUG[22219] res_musiconhold.c: Read 147 bytes of audio while expecting 640 |
| 02:45.33 | seanbright | but i hear a lot of nothing |
| 02:45.40 | seanbright | "squat" as they call it in the business. |
| 02:45.50 | file | seanbright: did you do as I suggested and get the actual stream URL from the m3u? |
| 02:45.53 | seanbright | yes |
| 02:46.26 | seanbright | application=mpg123 -q -s --mono -r 8000 -f 8192 http://cast.radiogaga-muenchen.de:8000/mobile.mp3 |
| 02:51.04 | seanbright | it also doesn't appear to even start streaming to asterisk unless i 'moh reload' after initial startup. |
| 02:51.07 | seanbright | moh is complicated. |
| 02:52.56 | seanbright | annnnd asterisk crashes on stop now. |
| 02:52.57 | seanbright | wtf? |
| 02:53.31 | russellb | wheeeeeeee |
| 02:54.58 | russellb | feels good to be coding .. |
| 02:55.29 | seanbright | i've just been doing a lot of blank staring |
| 02:55.31 | seanbright | it's pretty awesome |
| 02:56.26 | seanbright | file: any thoughts or hints? |
| 02:56.48 | file | I currently have the mental capacity of a peanut, so no |
| 02:56.51 | russellb | Tricky... |
| 02:56.56 | russellb | here's a sanity check you could do |
| 02:57.01 | russellb | run that mpg123 command out to a file |
| 02:57.05 | russellb | and open it with audacity |
| 02:57.08 | russellb | make sure it looks sane |
| 02:57.23 | seanbright | will do |
| 02:57.26 | russellb | (and plays back sane) |
| 02:58.05 | russellb | if that looks/sounds good, then we can dig into the code to see what is happening |
| 02:58.34 | seanbright | hmmm |
| 02:58.47 | seanbright | ok, i might have wasted everyone's time |
| 03:03.44 | russellb | nah |
| 03:04.03 | russellb | it's all a big learning experience |
| 03:04.08 | russellb | sometimes it results in code ... sometimes not |
| 03:04.10 | russellb | whatev' ! |
| 03:04.42 | *** join/#asterisk-dev moy (n=moy@CPE001cdfec4cee-CM00080dab8485.cpe.net.cable.rogers.com) |
| 03:05.41 | russellb | passes out |
| 03:11.14 | seanbright | ok, i didn't waste anyone's time |
| 03:11.18 | seanbright | phew |
| 03:11.44 | seanbright | just grabbed a stream from di.fm and it don't work |
| 03:12.04 | seanbright | redirected from mpg123 to a file and opened it up on goldwave (windows audio app) and it's fine |
| 03:12.56 | seanbright | application=mpg123 -q -s --mono -r 8000 -f 8192 http://94.232.114.240:6304 |
| 03:30.35 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 03:30.35 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 03:40.53 | *** join/#asterisk-dev kamanashisroy (n=kamanash@119.30.36.77) |
| 04:00.16 | *** join/#asterisk-dev lmsteffan (n=laurent@reef.ac-noumea.nc) |
| 04:10.13 | *** part/#asterisk-dev lmsteffan (n=laurent@reef.ac-noumea.nc) |
| 05:56.19 | *** join/#asterisk-dev lmsteffan (n=laurent@reef.ac-noumea.nc) |
| 06:11.28 | *** join/#asterisk-dev sergee (n=serg@195.94.224.197) |
| 07:49.57 | *** join/#asterisk-dev DarkRift (n=dark@65.92.171.232) |
| 08:19.18 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 08:19.18 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 09:44.31 | *** join/#asterisk-dev Mw3 (i=mw3@mw3.hu) |
| 09:44.45 | *** join/#asterisk-dev BlargMaN00 (n=blarg@12.234.16.130) |
| 09:44.45 | *** join/#asterisk-dev mbranca (n=matteo@2001:1418:130:0:21e:8cff:fe51:5b05) |
| 09:44.46 | *** join/#asterisk-dev mnicholson (n=mnichols@nat/digium/x-7f5e8449999e8403) [NETSPLIT VICTIM] |
| 09:44.46 | *** join/#asterisk-dev Daviey (n=Daviey@ubuntu/member/pdpc.gold.Daviey) [NETSPLIT VICTIM] |
| 09:44.46 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 10:30.40 | *** join/#asterisk-dev qdk (n=qdk@81.7.168.130) |
| 11:05.18 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 11:18.28 | kaii | seanbright: try playing with the "-b" (buffer) parameter of mpg123 .. i assume its a timing issue with buffered output and asterisk reading it. |
| 11:18.59 | kaii | with *unbuffered output |
| 11:20.01 | kaii | also test if asterisk can play back the file you captured with redirected output of mpg123. if it can, its an indicator for the timing issue thin. |
| 11:26.22 | kaii | if the result sounds awkward, mpg123 codec/rate/channel mixing/conversion failed |
| 11:30.59 | *** join/#asterisk-dev Corydon76-dig (i=blue@pdpc/supporter/bronze/Corydon76-home) |
| 11:30.59 | *** join/#asterisk-dev destructure (n=mu@trollbooth.com) [NETSPLIT VICTIM] |
| 11:30.59 | *** join/#asterisk-dev wdoekes (n=walter@wjd.osso.nl) |
| 11:31.00 | *** mode/#asterisk-dev [+o Corydon76-dig] by irc.freenode.net |
| 11:46.14 | *** join/#asterisk-dev Corydon76-dig (i=blue@pdpc/supporter/bronze/Corydon76-home) |
| 11:46.14 | *** join/#asterisk-dev destructure (n=mu@trollbooth.com) [NETSPLIT VICTIM] |
| 11:46.14 | *** join/#asterisk-dev wdoekes (n=walter@wjd.osso.nl) |
| 11:46.14 | *** mode/#asterisk-dev [+o Corydon76-dig] by irc.freenode.net |
| 11:55.29 | *** join/#asterisk-dev Corydon76-dig (i=blue@pdpc/supporter/bronze/Corydon76-home) |
| 11:55.29 | *** join/#asterisk-dev destructure (n=mu@trollbooth.com) [NETSPLIT VICTIM] |
| 11:55.30 | *** join/#asterisk-dev wdoekes (n=walter@wjd.osso.nl) |
| 11:55.30 | *** mode/#asterisk-dev [+o Corydon76-dig] by irc.freenode.net |
| 12:22.06 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 12:32.33 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 12:32.33 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 12:35.43 | eliel | morning |
| 12:38.44 | *** join/#asterisk-dev jeffg (n=jeffg@pdpc/supporter/active/jeffg) |
| 12:43.43 | *** join/#asterisk-dev ccesario_ (n=ccesario@189-19-6-236.dsl.telesp.net.br) |
| 12:45.42 | snuff-home | ello eliel |
| 12:46.09 | eliel | llo snuff-home |
| 12:47.18 | snuff-home | so gettin better? |
| 12:47.32 | eliel | yes! :) thanks |
| 12:47.59 | snuff-home | says long weekend here this week |
| 12:48.37 | eliel | i need that! :) |
| 12:49.10 | snuff-home | mm.. which reminds me.. need to fix automerge on ao2jabber.. |
| 12:51.55 | snuff-home | mm.. that reminds me.. what did ppl do with this error.. |
| 12:52.16 | snuff-home | Could not resolve hostname `origsvn.digium.com': Temporary failure in name resolution (https://origsvn.digium.com) |
| 12:52.49 | eliel | mm, don't know, ping someone @digium :) |
| 12:53.06 | snuff-home | u never had that issue? |
| 12:53.08 | leifmadsen | works here |
| 12:53.34 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:53.34 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:54.22 | snuff-home | mm nm.. forgot my vm doesn't have default gw |
| 12:54.25 | snuff-home | :) |
| 12:57.04 | snuff-home | likes his opera 10 beta1 |
| 12:59.26 | mvanbaak | likes the fact google-chrome-testing.deb is unable to do resolving ;-) |
| 12:59.40 | snuff-home | lol |
| 13:00.37 | mvanbaak | back to the good old days where we had a dedicated ip for everything and everyone knew the ip-addreses from memory |
| 13:00.54 | snuff-home | svnmerge: command execution failed (exit code: 1) |
| 13:00.55 | snuff-home | svn propget --strict "svnmerge-integrated" "https://origsvn.digium.com/svn/asterisk/trunk" |
| 13:00.58 | snuff-home | svn: PROPFIND request failed on '/svn/asterisk/trunk' |
| 13:01.00 | snuff-home | svn: PROPFIND of '/svn/asterisk/trunk': SSL negotiation failed: SSL error: sslv3 alert handshake failure (https://origsvn.digium.com) |
| 13:01.12 | snuff-home | when i try to svnmerge merge -f mymsg.msg |
| 13:02.06 | kpfleming | that's odd |
| 13:02.24 | kpfleming | i'm not having any trouble accessing origsvn |
| 13:03.29 | snuff-home | mm.. think i managed to type pass wrong.. |
| 13:03.32 | snuff-home | working this time |
| 13:03.56 | mvanbaak | or hickup in your connection to origsvn |
| 13:04.16 | mvanbaak | I used to get that error all the time when sf.net moved all their stuff to a new datacenter |
| 13:04.27 | mvanbaak | their routing to .eu sucked big time in the beginning |
| 13:05.21 | snuff-home | just hopes this branch will re-merge ok with slight massage |
| 13:05.48 | snuff-home | btw.. sip_registry is still astobj v1.. is there any reason that its not v2? |
| 13:09.49 | kpfleming | the reason would be that nobody has converted it :-) |
| 13:17.00 | snuff-home | k.. i tried converting the smdi v1 objects.. with great fail |
| 13:18.50 | eliel | is there any problem with automerge? |
| 13:19.23 | snuff-home | mm wouldn't know... my branch was broke since 31 may n been lazy to refix it |
| 13:19.37 | eliel | my branch was not merged and there where no conflicts... |
| 13:19.49 | snuff-home | mm :( |
| 13:20.27 | snuff-home | will see armin van buuren this weekend.. |
| 13:23.44 | leifmadsen | nice! |
| 13:23.48 | leifmadsen | I'd like to see Armin |
| 13:24.10 | snuff-home | its not a full show though.. will just be a 2 hr set i think.. |
| 13:28.10 | leifmadsen | still would be cool to see |
| 13:28.22 | snuff-home | mmm.. |
| 13:29.25 | snuff-home | i went to big one on nye.. but no armin there.. he was in nyc for nye |
| 13:40.10 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 13:40.10 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 13:41.19 | snuff-home | calls it a night.. |
| 13:57.21 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 13:59.28 | wackypl | re |
| 13:59.42 | *** join/#asterisk-dev smth (n=mike__@199.84.137.3) |
| 14:01.38 | *** join/#asterisk-dev outtolunc (n=me@c-98-248-96-110.hsd1.ca.comcast.net) |
| 14:03.46 | *** join/#asterisk-dev davevg-btwtech (n=davevg__@67.76.177.147) |
| 14:13.08 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 14:13.08 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 14:13.57 | *** join/#asterisk-dev xpot-mobile (n=james@static-66-182-88-85.bbsc.net) |
| 14:14.42 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:14.42 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:20.54 | festr_ | hi. I've trouble with the latest 1.4. I'm using in dialplan command System(mkdir -p /var/spool/asterisk/monitor/2009-06-04) and sometimes it leads to load 6 on single cpu system. Any idea how to debug what is going on? |
| 14:27.05 | *** join/#asterisk-dev shido6 (n=shido6@96-28-35-120.dhcp.insightbb.com) |
| 14:28.31 | leifmadsen | festr_: probably using 'gdb' or 'valgrind' on the running asterisk process |
| 14:36.54 | *** join/#asterisk-dev fred-tmft (n=fred-tea@c-69-244-180-112.hsd1.mi.comcast.net) |
| 14:38.03 | *** part/#asterisk-dev fred-tmft (n=fred-tea@c-69-244-180-112.hsd1.mi.comcast.net) |
| 14:50.05 | mnicholson | who can explain ast_call_forward() for me? I have a question about the caller and orig parameters |
| 14:51.40 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:51.40 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:55.11 | russellb | mnicholson: talk to The_Boy_Wonder, he just added it |
| 14:58.14 | mnicholson | The_Boy_Wonder, please explain the caller and orig params to the ast_call_foward() function. I am trying to merge that into the newcdr branch and I need to pass the "requester" to ast_request |
| 14:59.10 | The_Boy_Wonder | mnicholson: ok |
| 15:02.06 | The_Boy_Wonder | mnicholson: caller is the inbound channel, orig is the outbound channel "original channel" that requested the forward. Lots of the orig channel's info is copied into the "new" channel and then "orig" is hung up because it is no longer needed. |
| 15:02.12 | festr_ | leifmadsen: load is too high. i've tried gdb without success |
| 15:02.17 | festr_ | it hangs forever |
| 15:02.24 | leifmadsen | festr_: eep |
| 15:02.33 | leifmadsen | might have to load asterisk from gdb first then |
| 15:02.43 | leifmadsen | instead of attaching |
| 15:02.48 | mnicholson | The_Boy_Wonder, what situations would this function be used in? |
| 15:02.48 | The_Boy_Wonder | mnicholson: if caller is NULL, the forward will still work |
| 15:03.09 | The_Boy_Wonder | anytime a ast_channel's call_forward string is set |
| 15:03.31 | festr_ | leifmadsen: i'm not able to reproduce this bug |
| 15:03.48 | festr_ | it happens time to time |
| 15:03.53 | festr_ | once per 3 day |
| 15:03.55 | leifmadsen | festr_: ok... I'm not able to help beyond what I've already said |
| 15:04.19 | festr_ | i mean if anyone can thing about reasen why system could cuase such high load |
| 15:04.25 | festr_ | system mkdir -p /var/... |
| 15:07.20 | mnicholson | The_Boy_Wonder, so I should use the orig channel as the channel requesting the forward then. Thanks. |
| 15:07.39 | The_Boy_Wonder | yep |
| 15:11.48 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 15:31.49 | *** join/#asterisk-dev moy (n=moy@74.12.123.90) |
| 15:36.37 | *** join/#asterisk-dev marv[work] (n=timr@router.asteriasgi.com) |
| 15:57.16 | *** join/#asterisk-dev russellb_ (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 15:57.16 | *** mode/#asterisk-dev [+o russellb_] by ChanServ |
| 15:57.21 | Qwell | Corydon76-dig: I read that branch name as "malloc on hold" at first. |
| 15:59.15 | Corydon76-dig | Heh |
| 16:12.40 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:12.40 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 16:36.21 | *** join/#asterisk-dev xpot-mobile (n=james@static-66-182-88-85.bbsc.net) |
| 16:49.18 | *** join/#asterisk-dev BlargMaN00 (n=blarg@12.234.16.130) |
| 16:50.06 | *** join/#asterisk-dev BlargMaN00 (n=blarg@12.234.16.130) |
| 17:14.29 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 17:14.29 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 17:51.38 | kpfleming | seanbright: thanks for the reviewboard response.. .you beat me to it :-) |
| 17:57.05 | seanbright | no sweat |
| 17:57.13 | seanbright | Corydon76-dig: i found out something about backtraces |
| 17:57.41 | seanbright | the address next to a frame is not the frame's address in the stack, but the function's address in the process space |
| 17:57.51 | seanbright | if you do: |
| 17:57.55 | seanbright | frame 0 |
| 17:57.56 | seanbright | info f |
| 17:58.05 | seanbright | it will show you the address in the stack |
| 18:04.20 | seanbright | also, i have a 64 bit test machine and i temporarily up'd AST_STACKTRACE to 1MB to diagnose that voicemail issue and the crash stopped. so it does appear to be stack related. |
| 18:06.12 | Corydon76-dig | You mean AST_STACKSIZE, right? |
| 18:06.19 | seanbright | i do, yes. |
| 18:08.29 | seanbright | anyway. i can duplicate the issue here, so if you want me to test any patches or anything, let me know. |
| 18:08.50 | Corydon76-dig | seanbright: well, you're one step ahead of me, now |
| 18:09.19 | seanbright | is the solution really as simple as working my way back through the stack frame reducing stack usage? |
| 18:09.33 | Corydon76-dig | seanbright: I think so |
| 18:09.42 | seanbright | alrighty. will give it a whilr. |
| 18:09.45 | seanbright | s/lr/rl/ |
| 18:09.48 | seanbright | heh |
| 18:10.25 | Corydon76-dig | Figure out where you're consuming memory like a beotch and either reduce the memory usage or switch it to using heap allocations |
| 18:14.32 | seanbright | heh. |
| 18:14.33 | seanbright | done. |
| 18:14.34 | eliel | s/a/d/ |
| 18:15.04 | eliel | he doesn't remember me.. |
| 18:19.00 | seanbright | Corydon76-dig: thoughts? http://pastebin.ca/1448946 |
| 18:23.46 | seanbright | that frees up 18544 bytes |
| 18:26.19 | seanbright | meh... fail. |
| 18:32.35 | Corydon76-dig | seanbright: make sure you check the result of the allocation |
| 18:32.48 | seanbright | yeah... it's got other problems |
| 18:34.07 | seanbright | how about this for bizarre... with no code change (1.6.0) if i have a logger.conf file, it doesn't crash. if i don't have it, it does. |
| 18:34.17 | seanbright | just confirmed. |
| 18:34.54 | Corydon76-dig | Unrelated crash? |
| 18:34.58 | seanbright | same crash |
| 18:35.08 | Corydon76-dig | Hah |
| 18:35.14 | seanbright | if i put a logger.conf in /etc/asterisk that crash goes away |
| 18:35.25 | Corydon76-dig | Okay, that's just bizarre |
| 18:35.30 | seanbright | indeed. |
| 18:36.29 | Corydon76-dig | Holy schnikies |
| 18:36.46 | seanbright | eh? |
| 18:40.14 | seanbright | ah... i think i know why |
| 18:40.41 | seanbright | logger.conf being there makes the localtime initialization (loading/parsing) happen when the logger loads |
| 18:40.49 | seanbright | smaller stack |
| 18:41.01 | kpfleming | good catch |
| 18:41.32 | seanbright | so that's our bug fix |
| 18:41.39 | seanbright | "we no longer support *not* having logger.conf" |
| 18:41.40 | seanbright | heh |
| 18:42.51 | Corydon76-dig | So localtime uses too much stack? |
| 18:43.00 | Corydon76-dig | relative to voicemail? |
| 18:43.09 | kpfleming | just the initialization |
| 18:43.21 | kpfleming | which could just be done earlier during startup |
| 18:43.58 | Corydon76-dig | kpfleming: yeah, but localtime initialization still needs to take less, because it supports non-native timezones |
| 18:44.15 | Corydon76-dig | err, because VOICEMAIL supports non-native timezones |
| 18:44.59 | Corydon76-dig | seanbright: so do you want to fix it? |
| 18:45.28 | Corydon76-dig | Or having made the discovery, do you want to sit back and bask in the glory while I fix it? |
| 18:46.20 | kpfleming | yes, i understand the complication |
| 18:46.25 | kpfleming | good luck :-) |
| 18:46.39 | Corydon76-dig | Heh |
| 18:47.19 | Corydon76-dig | One could force a monitor thread for localtime initialization, and use signals for when it needs to parse a new zone |
| 18:48.01 | kpfleming | not 'signals', but something like that |
| 18:48.19 | Corydon76-dig | not signals, pthread_cond's |
| 18:48.52 | kpfleming | well, you'd need to tell it the zone name to parse, and get a result back |
| 18:49.38 | Corydon76-dig | I'm thinking insert a name into a list, send it a wakeup, then cond_wait |
| 18:50.05 | seanbright | well, he is my question |
| 18:50.09 | Corydon76-dig | When it's done with the list of names, it sends a broadcast |
| 18:50.25 | seanbright | and this may be naive |
| 18:50.51 | seanbright | but why not just have a 480k thread stack size on 64 bit processors |
| 18:50.57 | Corydon76-dig | or dispense with the broadcast, store the tid, and cond_signal |
| 18:51.33 | Corydon76-dig | seanbright: because people with 64-bit processors don't necessarily have more memory |
| 18:51.47 | seanbright | but they do have bigger pointers |
| 18:51.55 | kpfleming | setting a larger stack size does not use more memory |
| 18:52.02 | kpfleming | only if someone actually tries to use it |
| 18:52.18 | kpfleming | it uses more address space, but as seanbright says, there is tons of that on 64-bit boxes |
| 18:52.31 | seanbright | the way i see it we have half the stack space on a 64bit processor than on a 32bit one |
| 18:52.35 | kpfleming | so that may be very reasonable |
| 18:52.38 | kpfleming | no, that's not true |
| 18:52.39 | Corydon76-dig | kpfleming: oh, right. It doesn't actually map until there's a page fault |
| 18:52.51 | kpfleming | putting an array of characters on the stack takes the same space on either system |
| 18:53.07 | kpfleming | only pointers are larger, and potentially padding between structures |
| 18:53.15 | seanbright | ahh |
| 18:53.21 | seanbright | i'm showing my ig'nance |
| 18:54.27 | Corydon76-dig | kpfleming: so only in the worst case (not average case) is the stack half size on 64-bit processors |
| 18:54.45 | Corydon76-dig | best case is the same effective size and average case is somewhere in between |
| 18:55.16 | seanbright | in the majority of cases, we'll have less stack space |
| 18:55.20 | seanbright | that is my entire point. |
| 18:56.15 | seanbright | it feels like a band-aid fix, but it would work. |
| 18:56.20 | Corydon76-dig | I'm now in agreement with both of you. Increasing the stack size on 64-bit platforms is a reasonable option |
| 18:56.36 | Corydon76-dig | seanbright: not a bandaid fix; it's the right fix. |
| 18:56.45 | seanbright | the question is, how much? :) 150% seems good to me |
| 18:57.15 | Corydon76-dig | As Kevin said, they're not going to run out of process space (and each process gets its own map space) |
| 18:57.24 | seanbright | so just double it? |
| 18:57.26 | Corydon76-dig | so twice is fine |
| 18:57.38 | seanbright | how does this affect LOW_MEMORY? |
| 18:58.05 | Corydon76-dig | LOW_MEMORY is intended for use on a single system which is 32-bit |
| 18:58.12 | seanbright | so no change, then. |
| 18:58.23 | Corydon76-dig | I wouldn't worry about it until somebody makes it an issue |
| 18:59.15 | Corydon76-dig | Why someone would choose a 64-bit system if they're only going to put 16MB on the board is beyond me |
| 18:59.22 | seanbright | heh |
| 19:00.06 | Corydon76-dig | For 16MB, you might as well use a 16-bit processor |
| 19:02.09 | Corydon76-dig | seanbright: btw, your question made me take a hard look at logger.c, with a question of... why is the default global_logmask initialized to -1? |
| 19:04.33 | seanbright | what is correct preprocessor check for 64bit? |
| 19:05.19 | Corydon76-dig | #elif __WORDSIZE == 64 |
| 19:05.37 | Corydon76-dig | It's in logger.c, in ast_backtrace() |
| 19:06.04 | seanbright | aha. thanks. |
| 19:07.19 | seanbright | i assume AST_BACKGROUND_STACKSIZE should change as well? |
| 19:09.06 | Corydon76-dig | Yes |
| 19:10.33 | Corydon76-dig | kpfleming: what was the reason for making the background thread stacksize smaller? |
| 19:11.02 | seanbright | it's the same |
| 19:11.08 | seanbright | except when LOW_MEMORY is defined |
| 19:11.12 | seanbright | then it's 48 |
| 19:11.17 | Corydon76-dig | Ah |
| 19:14.09 | kpfleming | it's smaller because on LOW_MEMORYsystems, there could very well be no MMU, in which case the full stack size is allocated, not just address space |
| 19:15.10 | seanbright | http://pastie.org/private/s4m6pmkc0n6cbrzoizchuw |
| 19:15.14 | seanbright | does that work for you gents? |
| 19:15.38 | kpfleming | no pasties for me, i'm married |
| 19:15.49 | seanbright | youuuuu! |
| 19:15.54 | seanbright | i see what you did there. |
| 19:16.32 | seanbright | but seriously |
| 19:16.33 | seanbright | :) |
| 19:20.17 | kpfleming | i get '502 Bad Gateway' for that URL |
| 19:21.46 | seanbright | https://issues.asterisk.org/file_download.php?file_id=22928&type=bug |
| 19:21.56 | Corydon76-dig | seanbright: I'm fine with that |
| 19:22.23 | kpfleming | it's wrong |
| 19:22.26 | seanbright | i am actually going to test it and make sure it works now... *blush* |
| 19:22.29 | seanbright | fuck |
| 19:22.29 | Corydon76-dig | on the else, I'd put a comment that says /* __WORDSIZE == 32 */ |
| 19:22.31 | seanbright | for real? |
| 19:22.41 | kpfleming | AST_STACKSIZE_KILOBYTES == 480 is a 480MB stack, not a 480KB stack |
| 19:22.47 | seanbright | oh snap |
| 19:22.57 | seanbright | heh |
| 19:23.04 | kpfleming | well... hmm |
| 19:23.16 | seanbright | oh |
| 19:23.17 | seanbright | no |
| 19:23.26 | kpfleming | don't add the extra level of macros |
| 19:23.37 | seanbright | ok |
| 19:23.43 | kpfleming | or change their names to something else, i guess |
| 19:24.16 | kpfleming | AST_STACKSIZE_MEGABYTES would be fine |
| 19:24.33 | kpfleming | or AST_STACKSIZE_MEGAOCTETS :-) |
| 19:24.58 | seanbright | https://issues.asterisk.org/file_download.php?file_id=22929&type=bug |
| 19:25.12 | seanbright | Corydon76-dig: will add the comment during commit |
| 19:25.37 | kpfleming | the second one can just be #define AST_BACKGROUND_STACKSIZE AST_STACKSIZE |
| 19:26.04 | kpfleming | but yep, that's good |
| 19:26.25 | seanbright | https://issues.asterisk.org/file_download.php?file_id=22930&type=bug |
| 19:26.27 | seanbright | :) |
| 19:27.45 | seanbright | i wonder if this is going to 'fix' other random crashes |
| 19:27.59 | seanbright | would be nice. |
| 19:28.02 | Corydon76-dig | On 64-bit systems, probably |
| 19:28.38 | Corydon76-dig | kpfleming: our stacksize is seriously 240MB? |
| 19:28.47 | kpfleming | yes |
| 19:28.50 | Corydon76-dig | That seems wrong |
| 19:28.54 | kpfleming | wait... |
| 19:28.56 | seanbright | KB |
| 19:29.04 | seanbright | the language i used in my patch was misleading |
| 19:29.05 | kpfleming | no, i was completely wrong :-) |
| 19:29.11 | kpfleming | my brain was elsewhere |
| 19:29.21 | Qwell | should the AST_BACKGROUND_STACKSIZE change on 64-bit systems as well? |
| 19:29.23 | kpfleming | but yeah, the macro names made it seem that way |
| 19:29.36 | kpfleming | it does |
| 19:29.40 | kpfleming | except for LOW_MEMORY |
| 19:29.40 | seanbright | Qwell: already in my patch |
| 19:29.46 | kpfleming | maybe it should double for LOW_MEMORY as well |
| 19:29.48 | Qwell | sorry, that's what I mean |
| 19:29.52 | Qwell | in LOW_MEMORY |
| 19:30.16 | kpfleming | we need #redefine AST_STACKSIZE AST_STACKSIZE * 2 |
| 19:30.52 | Corydon76-dig | or use __WORDSIZE in the calculation |
| 19:30.58 | kpfleming | yeah! |
| 19:31.04 | seanbright | i tried that |
| 19:31.06 | kpfleming | so then when 128-bit systems come along, we're all set |
| 19:31.10 | seanbright | __WORDSIZE * 7.5 |
| 19:31.17 | Qwell | and it'll work on 16-bit systems too |
| 19:31.27 | Qwell | or even 24-bit |
| 19:31.35 | Corydon76-dig | seanbright: can't do floating point math in macros |
| 19:31.38 | russellb | 36-bit! |
| 19:31.40 | seanbright | Corydon76-dig: drat |
| 19:31.43 | kpfleming | seanbright: (size_t) (__WORDSIZE * .7.5) |
| 19:31.46 | kpfleming | what? macros are just text |
| 19:32.07 | kpfleming | you just need to cast the resutl to a non-floating point type so that the function calls will accept it |
| 19:32.18 | seanbright | are we seriously doing this? |
| 19:32.23 | seanbright | or just trolling |
| 19:32.27 | kpfleming | i don't see why not |
| 19:32.31 | seanbright | ok, so |
| 19:32.48 | seanbright | #define AST_STACKSIZE ((size_t) (__WORDSIZE * 7.5)) |
| 19:32.48 | kpfleming | actually, even better would be (__WORDSIZE * 8) - 16 |
| 19:33.15 | kpfleming | which avoids the floating point math, and also better expresses our desire for power-of-two block size minus 16KB |
| 19:33.39 | seanbright | #define AST_STACKSIZE ((__WORDSIZE * 8) - 16) |
| 19:33.41 | seanbright | eh? |
| 19:33.43 | Qwell | #define AST_STACKSIZE (((__WORDSIZE * 8) - 16) * 1024) ? |
| 19:33.45 | kpfleming | yep |
| 19:33.57 | kpfleming | to the second one |
| 19:34.00 | seanbright | heh |
| 19:34.01 | seanbright | ok |
| 19:34.19 | kpfleming | and the background one would be __WORDSIZE * 1.5, which will require casting |
| 19:34.29 | Qwell | why not * 2 - 16? |
| 19:34.36 | kpfleming | oh, duh |
| 19:34.36 | kpfleming | yes |
| 19:34.38 | kpfleming | never mind |
| 19:34.48 | seanbright | i am so confused :) |
| 19:34.50 | kpfleming | whistles as he walks away |
| 19:34.56 | seanbright | background stack is the same size as STACKSIZE |
| 19:35.03 | seanbright | or am i missing something? |
| 19:35.04 | Qwell | #if LOW_MEMORY #define AST_BACKGROUND_STACKSIZE (((__WORDSIZE * 2) - 16) * 1024) |
| 19:35.07 | kpfleming | not in LOW_MEMORY |
| 19:35.14 | seanbright | ahh |
| 19:35.15 | seanbright | ok |
| 19:35.41 | Corydon76-dig | We subtract out 16k because 16k is used for thread maps of some sort? |
| 19:35.43 | Qwell | Go team! |
| 19:35.52 | kpfleming | #define AST_STACKSIZE 0 |
| 19:35.52 | kpfleming | fixed |
| 19:36.35 | Corydon76-dig | We probably should document why the -16 |
| 19:36.38 | kpfleming | heap allocator overhead |
| 19:36.46 | kpfleming | and other bits |
| 19:36.57 | kpfleming | if you ask for 64K, the kernel will really allocate 128KB or 96KB |
| 19:37.05 | seanbright | http://pastie.org/private/agojk1kpca9fw9p90oocq |
| 19:37.10 | kpfleming | on the AA50, that was a huge difference |
| 19:37.38 | seanbright | everyone happy with that? |
| 19:38.21 | Corydon76-dig | kpfleming: isn't the heap allocator overhead only 48 bytes (max?) |
| 19:38.36 | kpfleming | not in the kernel, which is where stacks come from |
| 19:39.35 | Corydon76-dig | Oh, kernel allocator for the process space |
| 19:41.09 | Corydon76-dig | I suppose the kernel stores registers in the same space during a context switch |
| 19:45.32 | Qwell | seanbright: looks right to me. that isn't saying much though |
| 19:52.37 | kpfleming | seanbright: +1 |
| 19:53.27 | seanbright | excellent. |
| 19:53.35 | seanbright | will have the reporter test and then commit. |
| 19:53.45 | seanbright | 1.4 -> 1.6.2 |
| 19:53.53 | seanbright | where -> == 'through' |
| 19:55.08 | seanbright | i guess i should just do it regardless. |
| 19:57.15 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 20:07.23 | eliel | russellb: ping |
| 20:07.57 | russellb | pong |
| 20:08.40 | eliel | is there a way to check why automerge is not doing its job in a team/group/ branch? |
| 20:09.37 | eliel | automerge is setted |
| 20:09.46 | seanbright | set |
| 20:09.46 | Juggie | automerge does lots of weird things :) |
| 20:09.50 | russellb | did you set the svnmerge-integrated property? |
| 20:09.56 | eliel | set sorry |
| 20:09.57 | eliel | :) |
| 20:10.04 | seanbright | no apology necessary |
| 20:10.05 | seanbright | just helpingg. |
| 20:10.11 | seanbright | s/gg/g/ |
| 20:10.28 | eliel | russellb: via svnmerge init? |
| 20:10.43 | russellb | yes |
| 20:11.10 | eliel | svnmerge-integrated: /trunk:1-199221 |
| 20:11.47 | russellb | 221? it's not that behind :-) |
| 20:12.15 | seanbright | automerge only runs once an hour |
| 20:12.45 | eliel | russellb: i have ran a manual merge |
| 20:13.03 | eliel | there where no conflicts at that moment |
| 20:13.19 | eliel | automerge prop was still set |
| 20:13.29 | seanbright | svn pl -v $DIGIUM/asterisk/team/group/data_api_gsoc2009 |
| 20:13.35 | seanbright | i see automerge-email but not automerge |
| 20:14.30 | eliel | http://pastebin.ca/1449051 |
| 20:14.39 | eliel | i see it on my working copy ... mmm |
| 20:14.58 | seanbright | svn commit . |
| 20:15.01 | seanbright | :) |
| 20:15.14 | eliel | nothing to be commited |
| 20:15.23 | seanbright | weird. |
| 20:16.29 | seanbright | try updating |
| 20:18.03 | eliel | yes, i tried updating but nothing was being updated... now i have tried 'svn update .' and it work.. now i have a conflic to fix.. |
| 20:18.32 | seanbright | sorry |
| 20:18.39 | eliel | nono, thanks |
| 20:18.43 | seanbright | i break everything i touch! |
| 20:18.43 | seanbright | heh |
| 20:18.46 | eliel | maybe now it work |
| 20:18.51 | eliel | s |
| 20:20.46 | seanbright | my guess is that automerge failed at some point and removed the property |
| 20:21.16 | eliel | but... it was not removed from my working copy (??) |
| 20:21.36 | russellb | blames seanbright |
| 20:21.37 | eliel | ok, now it is working |
| 20:21.50 | putnopvut | 200000 is just around the corner... |
| 20:21.56 | russellb | yesssssssss |
| 20:21.59 | Qwell | putnopvut: so's 2010! |
| 20:22.31 | seanbright | commit asterisk 198156 |
| 20:22.37 | MuffinMan | [198156] Committed by root on 2009-05-29T20:19:13.390166Z: automerge cancel |
| 20:22.37 | MuffinMan | .. http://svn.digium.com/view/asterisk?view=rev&revision=198156 |
| 20:23.45 | eliel | what that means? |
| 20:23.54 | seanbright | that means that automerge failed |
| 20:23.59 | seanbright | and the property was removed |
| 20:24.01 | russellb | it should have emailed you .. |
| 20:24.08 | kpfleming | if you asked it to :-) |
| 20:24.14 | seanbright | eliel: check your Spam folder |
| 20:24.16 | eliel | yes, i did, and it did |
| 20:24.27 | seanbright | eliel: little gmail trick that i use... |
| 20:24.39 | seanbright | set automerge-email to: eliels+automerge@gmail.com |
| 20:24.54 | seanbright | then you can filter on that to address. |
| 20:25.18 | eliel | but maybe i did something wrong when running the manual merge |
| 20:25.31 | seanbright | no |
| 20:25.37 | seanbright | so automerge fails because of conflicts |
| 20:25.51 | seanbright | it 'svn pd automerge .' and then 'svn commit' |
| 20:25.56 | seanbright | you do an 'svn update' and *poof* |
| 20:26.03 | seanbright | that property disappears from your wc |
| 20:26.15 | eliel | yes, but it did not |
| 20:26.16 | seanbright | oh... but it didn't |
| 20:26.19 | seanbright | hrm |
| 20:26.21 | seanbright | maybe you didn't svn update |
| 20:26.23 | seanbright | :) |
| 20:26.44 | eliel | yes, but nothing was updated |
| 20:27.32 | eliel | seanbright: thanks, it looks like it is fixed now |
| 20:27.41 | seanbright | splendid. |
| 20:27.41 | eliel | commit asterisk 100000 |
| 20:27.47 | MuffinMan | [100000] Committed by root on 2008-01-23T21:16:20.912226Z: automerge commit |
| 20:27.48 | MuffinMan | .. http://svn.digium.com/view/asterisk?view=rev&revision=100000 |
| 20:27.57 | kpfleming | commit asterisk pi |
| 20:28.12 | eliel | commit asterisk 31415 |
| 20:28.18 | MuffinMan | [31415] Committed by root on 2006-06-01T17:00:18.639432Z: automerge commit |
| 20:28.18 | MuffinMan | .. http://svn.digium.com/view/asterisk?view=rev&revision=31415 |
| 20:28.35 | seanbright | let's not do this today |
| 20:35.14 | Corydon76-dig | seanbright: awww |
| 20:35.24 | Corydon76-dig | seanbright: but it's late afternoon on a Friday |
| 20:38.21 | seanbright | someone get viewvc working again |
| 20:38.25 | seanbright | then you can play |
| 20:38.26 | seanbright | heh |
| 20:38.54 | Corydon76-dig | will be taking a puppy to the vet later today |
| 20:39.10 | putnopvut | Corydon76-dig: is that some weird euphemism? |
| 20:39.40 | Corydon76-dig | putnopvut: that depends... euphemism for what? |
| 20:39.50 | putnopvut | Anything really. |
| 20:39.57 | Corydon76-dig | Not to my knowledge |
| 20:40.09 | seanbright | something other than taking an actual puppy to an actual vet. |
| 20:40.11 | Corydon76-dig | Peaches got a dachsund |
| 20:40.28 | Corydon76-dig | We named him George |
| 20:40.50 | Corydon76-dig | "I'm going to love him and squeeze him and call him 'George'" |
| 20:43.40 | Corydon76-dig | http://www.imdb.com/title/tt0054593/quotes |
| 21:20.24 | kpfleming | i have procured for you a lovely bass |
| 21:21.25 | Qwell | 1961... wow |
| 21:44.20 | seanbright | <PROTECTED> |
| 22:16.54 | seanbright | night guys and gals. |
| 22:16.58 | seanbright | looks around for gals... |
| 22:17.00 | seanbright | night guys. |
| 22:17.44 | mnicholson | can stuf for addons go on reviewboard? |
| 22:18.38 | russellb | yup |
| 22:19.38 | mnicholson | what should I set the branch to? |
| 22:21.13 | russellb | whatever you want, it's not interpreted ... |
| 22:21.28 | russellb | something that explains what the patch is made against, heh |
| 22:21.35 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 22:21.35 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 22:21.57 | mnicholson | russellb, having some problems https://reviewboard.asterisk.org/r/274/ |
| 22:23.27 | russellb | did you use post-review? |
| 22:23.42 | mnicholson | i didn't post this one, but probably not |
| 22:24.09 | russellb | R274 |
| 22:24.12 | MuffinMan | [R274] add initial support for AT+CUSD command [Pending] Submitted by Artem => https://reviewboard.asterisk.org/r/274/ |
| 22:27.25 | russellb | It's a base path problem |
| 22:27.36 | russellb | using post-review handles that properly |
| 22:27.46 | russellb | or he can re-upload and specify "/trunk" as the base path |
| 22:28.26 | leifmadsen | man, no matter how many times I make a release, I always underestimate just how much time it takes |
| 22:28.30 | russellb | http://www.asterisk.org/doxygen/trunk/Reviewboard.html |
| 22:28.34 | leifmadsen | russellb: I can see why you don't want to do them anymore :) |
| 22:28.36 | russellb | there is some info on post-review |
| 22:28.39 | *** part/#asterisk-dev korihor (n=korihor@190.72.237.209) |
| 22:28.43 | russellb | leifmadsen: it's pretty darn important, though |
| 22:28.48 | leifmadsen | oh heck ya |
| 22:28.56 | russellb | I did it because I knew it needed to be done, until I just couldn't anymore ... |
| 22:28.59 | leifmadsen | it just takes a lot longer than you think it would |
| 22:29.00 | russellb | I really appreciate you taking it on |
| 22:29.02 | russellb | yes. |
| 22:29.14 | russellb | if you have ideas on improving our release processes, then I'm all ears. |
| 22:29.15 | leifmadsen | russellb: I'm glad to help! |
| 22:29.26 | leifmadsen | russellb: it's mostly just the updating all the locations that have information |
| 22:29.42 | leifmadsen | if I could do a ./publish now that'd be sweet :) |
| 22:30.06 | leifmadsen | I think the next time I do a release I will make a script to update all the symlinks on downloads though |
| 22:30.11 | leifmadsen | that'll help speed it up |
| 22:30.16 | russellb | cool |
| 22:30.25 | leifmadsen | I'd do it now, but my g/f is being very patient with me right now since it's 6:30 on a Friday :) |
| 22:33.14 | leifmadsen | ok, now that it is all released, I am heading out! peas out homies. |
| 22:34.48 | Qwell | d'oh, he left. such a script does exist for the symlinks |
| 22:36.08 | Qwell | nm, that's pretty specific to sounds I guess |
| 22:40.37 | russellb | do we have a sounds maintainer? |
| 22:40.44 | russellb | or has it been random people updating sounds packages ... |
| 23:02.03 | Qwell | shrugs |
| 23:02.51 | Qwell | svn log says kpfleming and tilghman were the last 20 commits |
| 23:03.12 | Qwell | I snuck into top 30! |
| 23:05.45 | russellb | k |
| 23:08.33 | *** join/#asterisk-dev eliel (n=eliels@120-17-235-201.fibertel.com.ar) |
| 23:08.33 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 23:21.08 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 23:21.08 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 23:41.34 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 23:41.34 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 23:48.50 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-21-152.hsd1.sc.comcast.net) |
| 23:48.50 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |