| 00:09.49 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 00:15.47 | *** join/#asterisk-dev moy (n=moyhu@189.169.83.78) |
| 00:17.41 | *** join/#asterisk-dev RoyK (n=roy@ip-168-52-149-91.dialup.ice.no) |
| 00:17.52 | *** part/#asterisk-dev RoyK (n=roy@ip-168-52-149-91.dialup.ice.no) |
| 00:34.59 | *** join/#asterisk-dev Iamnacho (i=Iamnacho@ip68-103-153-140.ks.ok.cox.net) |
| 00:36.10 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177582050.dsl.bell.ca) |
| 01:12.14 | *** join/#asterisk-dev schmooze (n=schmooze@rrcs-67-52-210-44.west.biz.rr.com) |
| 01:36.01 | *** join/#asterisk-dev techie (n=techie@m0f0e36d0.tmodns.net) |
| 01:37.45 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 01:53.47 | *** join/#asterisk-dev jeffg (i=Vqg27hIC@pdpc/supporter/active/jeffg) |
| 02:20.05 | *** join/#asterisk-dev techie (n=techie@m6e0e36d0.tmodns.net) |
| 03:12.41 | *** join/#asterisk-dev stevie_ramjet (n=putnopvu@c-71-228-178-34.hsd1.al.comcast.net) |
| 03:12.41 | *** mode/#asterisk-dev [+o stevie_ramjet] by ChanServ |
| 03:15.21 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177582050.dsl.bell.ca) |
| 04:23.04 | *** join/#asterisk-dev IgorG (n=IgorG@195.162.49.23) |
| 05:09.33 | *** join/#asterisk-dev steliosk (n=Stelios@85.75.202.96) |
| 05:21.38 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 05:31.03 | *** join/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 05:33.36 | *** part/#asterisk-dev cristina_crow (n=cvintila@212.146.94.66) |
| 07:34.33 | *** join/#asterisk-dev steliosk (n=Stelios@athedsl-168642.home.otenet.gr) |
| 07:35.46 | *** join/#asterisk-dev Daviey (n=dave@ubuntu/member/daviey) |
| 09:02.22 | steliosk | Has anyone seen any bug reference for iax trunking and ztdummy for recent 1.2 asterisk/zaptel/dahdi ? |
| 09:07.45 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 09:07.45 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 09:08.18 | oej | Hello there! |
| 09:34.18 | mvanbaak | hey hey oej ! |
| 09:36.45 | oej | hey |
| 09:42.24 | *** join/#asterisk-dev kami- (n=user@p4FD3871B.dip0.t-ipconnect.de) |
| 10:00.16 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.138) |
| 10:17.06 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 10:17.40 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.41) |
| 10:59.00 | *** join/#asterisk-dev RoyK (n=roy@ip-168-52-149-91.dialup.ice.no) |
| 11:06.45 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 11:10.13 | *** join/#asterisk-dev ccesario (n=ccesario@189-19-9-100.dsl.telesp.net.br) |
| 11:13.43 | *** join/#asterisk-dev juanjoc (n=juanjoc@host223.190-225-200.telecom.net.ar) |
| 11:18.56 | *** join/#asterisk-dev kami- (n=user@p4FD3AC1B.dip0.t-ipconnect.de) |
| 11:19.24 | *** part/#asterisk-dev kami- (n=user@p4FD3AC1B.dip0.t-ipconnect.de) |
| 11:22.45 | *** join/#asterisk-dev shido6 (n=shido6@209.114.208.192) |
| 12:04.23 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 12:04.23 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 12:15.34 | mvanbaak | omg |
| 12:15.40 | mvanbaak | I should stop talking to oej |
| 12:15.56 | mvanbaak | we are now playing Abba here |
| 12:16.06 | mvanbaak | and it looks like it will be playing the whole afternoon |
| 12:16.16 | mvanbaak | track 4 of 168 |
| 12:31.33 | *** join/#asterisk-dev DarylVOIP (n=daryl@75.147.121.177) |
| 12:38.40 | oej | Ahh! ABBA day! |
| 12:38.53 | oej | I'm having an Elton John day here in the office, but that can change, so I'm compatible. |
| 12:39.40 | mvanbaak | I've Been Waiting For You is now playing |
| 12:42.19 | *** join/#asterisk-dev russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 12:42.19 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 12:42.59 | Corydon76-dig | Morning, Russell |
| 12:43.16 | russellb | g'morning |
| 12:44.52 | *** join/#asterisk-dev caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:44.52 | mvanbaak | hey russellb |
| 12:45.05 | mvanbaak | today is Abba day |
| 12:45.30 | Corydon76-dig | Strangely, the Doors are playing now |
| 12:58.36 | oej | The Abba Doors :-) |
| 12:58.48 | oej | switching to Abba day |
| 13:04.59 | mvanbaak | :) |
| 13:05.18 | mvanbaak | we are at track 6 of the Arrival album |
| 13:05.36 | oej | Time to work with realtime templates in SIP |
| 13:05.45 | mvanbaak | ouch |
| 13:05.49 | oej | The only part left not ported from chan_sip2 :-) |
| 13:06.07 | mvanbaak | you are working on chan_sip3 again ? |
| 13:06.22 | oej | I want to, but no. Maybe later this year. |
| 13:06.36 | oej | Many people want it, but don't want to pay. |
| 13:06.47 | mvanbaak | yeah |
| 13:07.04 | Corydon76-dig | Many people want everything. ;-) |
| 13:07.13 | russellb | most don't know what they want |
| 13:07.30 | russellb | "a new chan_sip" sounds nice, but new is not always better :) |
| 13:07.43 | Corydon76-dig | Or express wants that they don't truly have |
| 13:07.54 | russellb | right |
| 13:08.47 | oej | so what are you guys trying to say? |
| 13:08.56 | russellb | i'm not trying to say anything, really |
| 13:09.19 | russellb | maybe that the people that want it, but aren't willing to pay, don't really know what they want in the first place |
| 13:09.32 | russellb | other than they think new is probably better, and they want better all of the time |
| 13:09.35 | russellb | shrugs |
| 13:09.47 | russellb | in summary, people are silly |
| 13:13.05 | Corydon76-dig | and today is Friday... so it's a silly day |
| 13:29.23 | *** join/#asterisk-dev anonymouz666 (n=anonymou@201.19.140.193) |
| 13:40.50 | Corydon76-dig | Qwell: on that lock info lock yesterday, I think there was another problem |
| 13:42.18 | Corydon76-dig | Might be returning pointers was the wrong thing to do. I'm thinking buffers might be better |
| 13:43.07 | Corydon76-dig | I'm thinking in the next step, we deallocate where those pointers are pointing |
| 13:45.43 | *** join/#asterisk-dev I-MOD (n=I-MOD@c-68-62-216-5.hsd1.al.comcast.net) |
| 14:02.45 | *** join/#asterisk-dev FinboySlick (n=FinboySl@207.134.8.4) |
| 14:02.54 | *** join/#asterisk-dev putnopvut (n=putnopvu@216.207.245.1) |
| 14:02.54 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:05.42 | *** join/#asterisk-dev mcargile (n=mcargile@mail.in-florida.net) |
| 14:07.05 | *** part/#asterisk-dev mcargile (n=mcargile@mail.in-florida.net) |
| 14:13.00 | codefreeze-lap | russellb: is there any way to see what's supplying the timing at runtime? |
| 14:16.43 | *** join/#asterisk-dev dioedu (n=dioedu@201.7.117.114) |
| 14:18.13 | *** join/#asterisk-dev esaym (n=user@cpe-70-120-89-6.satx.res.rr.com) |
| 14:23.27 | codefreeze-lap | notices that a. ast_pbx_run() is a wrapper for pthread_create() that adds about a constant 25 microseconds to pthread_create, whether in 1.4 or trunk, it matters not. |
| 14:24.44 | putnopvut | codefreeze-lap: any more findings on what is making the trunk version take so much longer? |
| 14:25.35 | russellb | codefreeze-lap: not right now, no |
| 14:25.43 | russellb | codefreeze-lap: other than "module show like timing" |
| 14:26.03 | russellb | but that's not really good enough, as you may have multiple timing modules loaded |
| 14:26.05 | codefreeze-lap | notices that 1.4 has fairly constant pthread_create times; |
| 14:27.26 | I-MOD | found a bug in tonezone_compat.h when using asterisk 1.4 SVN and zaptel 1.4 SVN, need to check for HAVE_ZAPTEL before checking for HAVE_DAHDI because of dahdi_compat doing "#define HAVE_DAHDI HAVE_ZAPTEL", submitting the bug here in a minute with a patch if there are no objections |
| 14:28.02 | I-MOD | (and i'm still trying to make sure it hasn't already been reported) |
| 14:28.28 | russellb | don't think that has been reported |
| 14:29.45 | codefreeze-lap | notices that in trunk, pthread_create() times get exponentially larger after it yields the "Asterisk Ready" at the CLI; times jump from about 40 microseconds to 750, then jump to 14k, then 29k by the first 6 calls... |
| 14:30.19 | russellb | O.O |
| 14:31.06 | I-MOD | no chan_dahdi category? /me files under chan_zap |
| 14:31.15 | codefreeze-lap | I've been googling, and it seems that when cycles start getting scarce, pthread_create times rise sharply, in general. |
| 14:31.59 | codefreeze-lap | Perhaps a sort of an unintentional built-in safety-check-valve sort of thing |
| 14:33.50 | codefreeze-lap | I-MOD: good going! |
| 14:38.11 | shido6 | ok i fixed the folder problem from yesterday |
| 14:38.13 | shido6 | that sucked |
| 14:38.47 | *** join/#asterisk-dev moy (n=moyhu@nat/ibm/x-6d8197a4d982f1cf) |
| 14:38.52 | shido6 | now i have to find a way to send multiple ppl messages with DIFFERENT prepends |
| 14:39.17 | shido6 | so the same prepend doesnt go out to everyone... or make it an option to send the same prepend or create a new prepend |
| 14:39.48 | shido6 | then announce the greet of the user after a extensions = valid |
| 14:40.04 | I-MOD | mkay, patch is uploaded, issue 12938 |
| 14:40.28 | shido6 | valid_extensions, rather |
| 14:42.53 | *** join/#asterisk-dev outtolunc (n=me@c-67-170-211-86.hsd1.ca.comcast.net) |
| 14:45.48 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 14:48.06 | *** join/#asterisk-dev anthm (n=anthm@CPE-72-131-113-50.wi.res.rr.com) |
| 14:49.48 | putnopvut | Should all inclusions of <dahdi/user.h> be enclosed in a #if defined(HAVE_DAHDI) directive? |
| 14:50.17 | putnopvut | 1.6.0 is not compiling for me in a few places, and adding that directive fixes it for me. It makes sense to me to add it, but I want to double check before I commit anything. |
| 14:53.56 | russellb | not ... really |
| 14:54.04 | russellb | because, those modules shouldn't be compiled if it wasn't found |
| 14:54.17 | russellb | <depend>dahdi</depend> |
| 14:54.21 | putnopvut | russellb: they're not modules though. channel.c and asterisk.c are two examples. |
| 14:54.26 | russellb | oh ... |
| 14:54.30 | russellb | in those cases, yes. |
| 14:54.30 | putnopvut | (well, and chan_iax2) |
| 14:54.36 | russellb | in trunk, they aren't there anymore |
| 14:54.41 | russellb | yeah, chan_iax2 as well |
| 14:54.51 | russellb | those are optional places, and HAVE_DAHDI usage is appropriate |
| 14:54.52 | russellb | commit away |
| 14:54.58 | putnopvut | Righty-right. |
| 14:59.54 | *** join/#asterisk-dev DarylVOIP (n=daryl@75.147.121.177) |
| 15:23.51 | *** join/#asterisk-dev CunningPike (n=arodgers@204.239.8.157) |
| 15:37.30 | Qwell | russellb: re: 125587 - it's new as of 05/30ish. the unlock was never there |
| 15:37.41 | *** part/#asterisk-dev I-MOD (n=I-MOD@c-68-62-216-5.hsd1.al.comcast.net) |
| 15:38.07 | russellb | what function was that again? |
| 15:38.15 | Qwell | ast_find_lock_info? I think |
| 15:38.18 | russellb | ohhhhh |
| 15:38.32 | Qwell | also, it's not just DEBUG_THREADS, from what I could tell |
| 15:38.38 | russellb | looks |
| 15:38.42 | Qwell | main/utils |
| 15:38.45 | Qwell | (.c) |
| 15:39.13 | russellb | well, it has to be, because none of that lock tracking stuff is enabled without DEBUG_THREADS |
| 15:40.06 | russellb | double checked, and yes, only DEBUG_THREADS |
| 15:40.25 | Qwell | so, does the ast_threadstorage_get just not return anything with DEBUG_THREADS off? |
| 15:40.33 | russellb | that function doesn't exist ... |
| 15:40.49 | russellb | the find_lock_info function itself, that is |
| 15:40.54 | russellb | does not exist without DEBUG_THREADS |
| 15:41.05 | Qwell | oh, right |
| 15:41.27 | Qwell | so what does DEADLOCK_AVOIDANCE call? O.o |
| 15:41.53 | Qwell | oh |
| 15:42.05 | Qwell | right, so yeah |
| 15:42.35 | russellb | nothing in that case :) |
| 15:42.38 | Qwell | definitely not the bug I was seeing then :p |
| 15:42.39 | russellb | for the debugging part of it .. |
| 15:43.02 | Corydon76-dig | russellb: those two fixes were to fix very specific deadlocks. So I'm not quite sure what was wrong with adding deadlock avoidance |
| 15:43.06 | Qwell | russellb: Marko was (is) having an iax2 deadlock on his laptop, on like every call. |
| 15:43.19 | russellb | they're wrong based on the most fundamental locking rule in asterisk :) |
| 15:43.36 | russellb | let's keep these discussions on the mailing list, please |
| 15:44.13 | Corydon76-dig | russellb: why not keep the discussions on the bug that led to their commit? |
| 15:44.48 | russellb | because if we need to clarify details on locking rules and such, then i would rather do it where everyone will see |
| 15:44.52 | russellb | because it's quite critical .. |
| 15:45.41 | russellb | Qwell: any details? |
| 15:46.06 | Qwell | schedule_delivery > iax2_queue_frame |
| 15:46.16 | Qwell | couldn't reproduce it when I enabled DEBUG_THREADS.. go figure |
| 15:46.39 | Qwell | (and he doesn't have ccache, so I ran out of time :p) |
| 15:47.00 | Corydon76-dig | russellb: I understand, but I'd like to see an alternative patch that fixes that specific issue |
| 15:47.41 | russellb | if there was a deadlock that patch fixed, then some _other_ code path violated locking order rules |
| 15:47.45 | russellb | and that is the code path that should be fixed |
| 15:47.51 | russellb | i don't have time to go dig into it and fix it |
| 15:48.08 | Corydon76-dig | The ML is great for general discussions, but when it comes to testing patches against issues that specific reporters have, then we need to ensure that the reporter, who is often not on the -dev list, is included. |
| 15:49.02 | russellb | ok. then respond to the thread and acknowledge that you understand the issue, and then the ML discussion is done |
| 15:49.06 | russellb | i don't have time to go fix it |
| 15:49.16 | russellb | i'm pointing out from the higher level what is fundamentally wrong with the patch |
| 15:49.50 | *** join/#asterisk-dev smth (n=chatzill@CPE000d48380389-CM00195eda2522.cpe.net.cable.rogers.com) |
| 15:51.55 | smth | hi, does asterisk surpport early media so far ? |
| 15:52.01 | russellb | #asterisk |
| 15:58.21 | putnopvut | The rule is to lock the channel before the pvt? If that's the case, then chan_sip is a huge violator of that rule. |
| 15:58.44 | putnopvut | do_monitor locks the pvt when it calls find_call, then it locks the pvt->owner afterwards. |
| 15:59.05 | jsmith | learns all kinds of new things about locking |
| 15:59.21 | russellb | it is an absolutely critical rule |
| 15:59.32 | russellb | and violating it has been the #1 cause of deadlocks in asterisk by far |
| 15:59.54 | russellb | there will be cases where you acquire the pvt before the channel |
| 16:00.00 | russellb | you can't get away from it |
| 16:00.18 | russellb | but it's _that_ case where the deadlock avoidance code in channel drivers is used between channel and pvt |
| 16:01.10 | Corydon76-dig | This is the first I've heard of that rule |
| 16:01.42 | putnopvut | I've been using chan_sip as a guideline and thought the rule worked the other way around. |
| 16:01.53 | russellb | well, it has not been documented, it's just the way the code has been written |
| 16:02.01 | Corydon76-dig | putnopvut: it works both ways, actually |
| 16:02.29 | russellb | what do you mean it works both ways? |
| 16:03.02 | Corydon76-dig | Sometimes you have to acquire the channel lock first, and sometimes you have to acquire the pvt lock first in order to even find the channel |
| 16:03.10 | russellb | correct. |
| 16:03.25 | russellb | and in only one of those cases do you have to juggle your locks |
| 16:03.31 | russellb | juggling locks is to obey locking order |
| 16:03.43 | russellb | and the locking order is 1) channel, 2) pvt |
| 16:04.13 | Corydon76-dig | I think you'll need to propose that as a change to the coding guidelines on the -dev list, as we discussed earlier this month |
| 16:04.30 | russellb | ok, i'll write it up. |
| 16:04.42 | Corydon76-dig | Obviously, you've surprised multiple people on that today |
| 16:04.45 | russellb | though it's a guideline that already exists ... |
| 16:04.51 | russellb | that's unfortunate |
| 16:04.59 | russellb | and is a perfect explanation of why we suffer from so many deadlocks |
| 16:05.18 | Corydon76-dig | I agree that it's a reason why we suffer from deadlocks |
| 16:05.21 | russellb | because the code is written with very fuzzy and often seemingly non-existant locking rules |
| 16:05.28 | Corydon76-dig | I've just never heard of a rule to resolve it |
| 16:06.03 | Corydon76-dig | Then you admit that until now, we did not have a rule? |
| 16:06.14 | russellb | it was always an unwritten rule :) |
| 16:06.17 | russellb | it was what the code did |
| 16:06.45 | russellb | it was never specifically documented. |
| 16:06.55 | Corydon76-dig | "Argh" |
| 16:07.07 | russellb | most of asterisk code got documented after the fact ... |
| 16:09.49 | file | knew of "the rule" |
| 16:09.57 | russellb | and how did you know of the rule? |
| 16:10.21 | file | you told it to me long ago actually |
| 16:10.28 | russellb | heh |
| 16:10.41 | file | we should document it though |
| 16:10.46 | russellb | yeah. |
| 16:11.05 | russellb | it's just something that exists in all the channel drivers |
| 16:11.33 | russellb | guess i should have documented the hell out of it long ago |
| 16:11.49 | Corydon76-dig | russellb: If that was true, then we would not have any deadlocks in the channel drivers |
| 16:12.04 | russellb | well, in _most_ of the code in the channel drivers |
| 16:12.11 | Corydon76-dig | Um, yeah |
| 16:12.17 | jsmith | Documentation?!? |
| 16:12.22 | jsmith | Did someone say documentation? |
| 16:12.23 | russellb | there was proper avoidance in some places |
| 16:12.35 | file | anything else re: locking we should doc while at it? |
| 16:12.37 | russellb | and the deadlocks are usually caused when trying to lock the channel with a pvt locked |
| 16:12.53 | russellb | i could probably write an entire document on locking ... |
| 16:12.55 | Corydon76-dig | I was not aware there was any avoidance at all, until Kevin and you started putting them in there |
| 16:14.23 | Corydon76-dig | Not to criticize Mark too much, but the locking has never really been clear cut. |
| 16:14.38 | Corydon76-dig | just sort of "what works" |
| 16:14.55 | *** join/#asterisk-dev Cresl1n (n=matt@216.207.245.1) |
| 16:14.55 | *** mode/#asterisk-dev [+o Cresl1n] by ChanServ |
| 16:15.00 | putnopvut | I recently added a big comment to the top of app_queue documenting the "evolved" locking order. |
| 16:17.47 | russellb | Corydon76-dig: yep ... |
| 16:18.07 | russellb | well i'm working on a message to -dev |
| 16:19.02 | outtolunc | aww poop <G> |
| 16:19.20 | Corydon76-dig | and anywhere we obtain 3 or (help us) 4 locks before doing something... well, I think that's where deadlock avoidance really started out |
| 16:19.59 | russellb | yeah, chan_local / chan_agent have kicked our asses in that regard. |
| 16:20.29 | putnopvut | I f**king hate chan_local |
| 16:20.38 | putnopvut | And chan_agent is even worse. |
| 16:21.21 | Corydon76-dig | And we really have to ignore that locking order when it comes to any of the channel read functions... because it's typically called with another lock whose handle is not passed in |
| 16:21.21 | russellb | but these locking issues are the #1 issue why those modules have been prone to deadlocks |
| 16:21.37 | *** join/#asterisk-dev De_Mon (i=de_mon@fl-71-55-24-227.dhcp.embarqhsd.net) |
| 16:21.42 | russellb | because they increase complexity exponentially, heh |
| 16:21.56 | Qwell | let's just remove all threads |
| 16:22.01 | russellb | or not |
| 16:22.03 | Qwell | no more locking - bam, magic |
| 16:22.26 | Corydon76-dig | Qwell: there is a method of programming without using threads... multiplexing... |
| 16:22.32 | russellb | the read callback is called with what, a 2nd channel locked, too? |
| 16:22.33 | Qwell | Corydon76-dig: ugh |
| 16:22.47 | russellb | there is no problem with that .. |
| 16:22.53 | Corydon76-dig | Yeah, multiplexing is a nightmare to get right |
| 16:23.33 | russellb | and don't forget taking advantage of SMP ... |
| 16:24.03 | Corydon76-dig | russellb: The exact scenario escapes me, but yes, there is a problem with the read functions and locking order |
| 16:24.08 | jreign | <PROTECTED> |
| 16:24.08 | jreign | [Jun 27 13:17:29] NOTICE[25291]: app_directed_pickup.c:159 pickup_exec: No target channel found for 1556. |
| 16:24.24 | Corydon76-dig | jreign: this is NOT tier 2 support |
| 16:24.25 | Qwell | jreign: #asterisk, please |
| 16:25.17 | Corydon76-dig | russellb: it usually occurs when ast_read and ast_hangup collide |
| 16:26.26 | russellb | i'm not sure how that's even possible, heh |
| 16:26.32 | russellb | as the same thread is responsible for both ... |
| 16:26.38 | Corydon76-dig | trying to read a frame off a channel that is in the process of hangup |
| 16:27.02 | russellb | right, but I don't know of a code path that could do that .. |
| 16:27.29 | Corydon76-dig | russellb: one of those issues that you told me to revert code on was that specific deadlock |
| 16:28.58 | jreign | alright |
| 16:29.06 | *** join/#asterisk-dev blackhole (n=Mishu@unaffiliated/blackhole) |
| 16:29.33 | blackhole | http://svn.digium.com/svn/asterisk/branches/1.4/main/app.c, I am looking at this code after if (prepend && outmsg) { |
| 16:29.52 | russellb | a code path that can have 2 different threads calling ast_read and ast_hangup on the same channel is broken for worse reasons ... |
| 16:30.00 | *** join/#asterisk-dev J4zen (n=Jeroen@213-84-194-178.adsl.xs4all.nl) |
| 16:31.48 | blackhole | when u get a message in your voicemailbox you listen to it. now u want to FORWARD it to another user so you press 8 and enter your extensions seperated by a "*" now it asks you if you want to prepend the message you are sending you prepend the message and it sends the message YOU received with your PREPEND and if i go back to listen to MY message its got the prepend message , i want to keep my orginal message and not prepend message |
| 16:32.15 | blackhole | what i think the code changes needed is in if (prepend && outmsg) { in app.c |
| 16:32.44 | Corydon76-dig | blackhole: file a bug |
| 16:32.46 | blackhole | Can someone look at this and give me idea what i need to do so my orginal message stays |
| 16:33.12 | blackhole | Corydon76-dig, Will file a bug but i need to resolve this.. |
| 16:33.18 | blackhole | so if anyone of you can help it would be great |
| 16:33.20 | Qwell | I think that bug exists |
| 16:33.35 | Qwell | (on mantis) |
| 16:33.44 | blackhole | Qwell, Any idea how can i resolve it? |
| 16:33.54 | Qwell | M11616 |
| 16:33.57 | MuffinMan | [closed] [Asterisk] Applications/app_voicemail 0011616: Forwarded voicemail with prepended message replaces source voicemail reported by jamessan (Karma: +0.50) http://bugs.digium.com/view.php?id=11616 |
| 16:35.30 | Corydon76-dig | blackhole: are you using current SVN 1.4? |
| 16:35.47 | Corydon76-dig | or any release since February 1st? |
| 16:35.53 | blackhole | nope.. asterisk 1.4.18 |
| 16:35.56 | blackhole | I am using |
| 16:36.01 | Corydon76-dig | Well, there's the problem |
| 16:36.03 | Corydon76-dig | Update |
| 16:36.04 | Qwell | hits his head on the tabl |
| 16:36.05 | Qwell | e |
| 16:36.57 | Corydon76-dig | In the future, if you find something that acts weird, you might try the latest code. We may have already fixed the problem |
| 16:38.09 | blackhole | Hmm, Thanks. Actually its on server and i can't change it so i have to stick with this version but yes i can try new version on some development machine |
| 16:38.56 | Corydon76-dig | blackhole: If you can't change the production version, why even ask if it's a problem? |
| 16:39.20 | Corydon76-dig | Kind of silly, don't you think? |
| 16:39.38 | blackhole | i can change.. |
| 16:39.44 | blackhole | but not the version |
| 16:39.50 | Qwell | that's safe |
| 16:39.50 | blackhole | like i can fix the code of same version |
| 16:40.03 | Qwell | blackhole: Is this box on the Internet? |
| 16:40.06 | blackhole | yes |
| 16:40.11 | Qwell | UPGRADE NOW |
| 16:40.18 | blackhole | I think i will have to... |
| 16:40.24 | Qwell | You are vulnerable to several security flaws. |
| 16:40.29 | blackhole | Hmm, I understand.. |
| 16:42.07 | tzafrir_laptop | Upgrade now, or (apply what patches?) |
| 16:42.26 | tzafrir_laptop | But this is more of an #asterisk thing |
| 16:50.59 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.42) |
| 16:51.08 | *** join/#asterisk-dev kamanashisroy (n=kamanash@202.56.7.140) |
| 17:25.31 | *** join/#asterisk-dev oej (n=olle@cust-IP-10.data.tre.se) |
| 17:25.31 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 17:31.54 | *** part/#asterisk-dev bkw_ (n=brian@adsl-70-234-169-185.dsl.tul2ok.sbcglobal.net) |
| 17:39.09 | *** join/#asterisk-dev Schmooze (n=Schmooze@rrcs-67-53-189-178.west.biz.rr.com) |
| 17:45.46 | shido6 | what did i do to get `AST_MODULE' undeclared here (not in a function) |
| 17:47.06 | russellb | broke it? |
| 17:50.12 | shido6 | heh |
| 17:56.15 | Corydon76-dig | shido6: are you compiling from outside the directory? |
| 17:56.36 | mvanbaak | with DEBUG_THREADS I should have 'core show locks' right ? |
| 17:56.37 | Corydon76-dig | AST_MODULE is defined by the Makefile |
| 17:56.47 | Corydon76-dig | mvanbaak: yessir |
| 17:56.50 | jpeeler | what are dahdi subchannels? |
| 17:57.04 | mvanbaak | hhmm |
| 17:57.12 | mvanbaak | gheh |
| 17:57.18 | Corydon76-dig | jpeeler: DAHDI/1-1, DAHDI/1-2... the -1 and -2 are subchannels |
| 17:57.27 | mvanbaak | need to do 'gmake clean' on obsd before it compiles that in |
| 17:57.28 | Cresl1n | jpeeler: they're used for 3 way calling and other similar features |
| 17:57.29 | mvanbaak | weird |
| 17:57.37 | Corydon76-dig | jpeeler: they're used for things like flash-hook transfer and 3way calling |
| 17:58.05 | Corydon76-dig | or call waiting |
| 17:59.07 | Qwell | jpeeler: are you hookflash pulsing? |
| 17:59.17 | Qwell | that's *hard* on those crappy coretelcos... |
| 17:59.43 | Corydon76-dig | Or pulseflash hooking? |
| 18:00.18 | jpeeler | Qwell: i was exploring the different tones produced |
| 18:00.34 | jpeeler | i actually do not know how to make a 3 way call |
| 18:00.43 | Qwell | hold for .5s |
| 18:00.48 | mvanbaak | ok, lets see if my box will deadlock again |
| 18:00.59 | Qwell | (after you're connected to somebody) |
| 18:01.07 | mvanbaak | the stuff they reported about IAX locking asterisk in 1.4 is happening to me on -trunk as well |
| 18:01.11 | Qwell | once you lift, you should get a stuttered dialtone |
| 18:01.16 | Qwell | maybe |
| 18:01.22 | Qwell | might just be a normal dialtone...I forget |
| 18:01.39 | Corydon76-dig | http://portland.craigslist.org/mlt/pet/733066123.html |
| 18:01.40 | mvanbaak | both OpenBSD and Debian linux |
| 18:01.42 | jpeeler | i don't have enough phones anyway |
| 18:02.04 | jsmith | Qwell: Normal dialtone again |
| 18:02.17 | *** join/#asterisk-dev joetester2 (n=chatzill@216.191.34.13) |
| 18:03.23 | shido6 | initializer element is not constant |
| 18:04.25 | shido6 | Corydon76-dig: I make a symbolic link and i use /usr/src/asterisk |
| 18:04.33 | shido6 | tried in both dir's now |
| 18:07.31 | shido6 | is there a log file or something i can delete before recompiling |
| 18:13.59 | shido6 | it always chooses app_voicemail.c |
| 18:14.08 | shido6 | why doesnt it compile everything else? |
| 18:14.19 | shido6 | recompile everything else |
| 18:22.12 | russellb | locking info guidelines addition posted to -dev ... |
| 18:23.00 | *** part/#asterisk-dev FinboySlick (n=FinboySl@207.134.8.4) |
| 18:24.22 | mvanbaak | oeh, tomorrow I'll have osx 10.5 |
| 18:25.22 | jsmith | mvanbaak: w00t! |
| 18:25.39 | jsmith | mvanbaak: Does that mean we can expect a large set of patches on Monday? |
| 18:25.56 | russellb | is on osx 10.5 right now |
| 18:26.08 | jsmith | has it on his other partition, but he rarely uses it |
| 18:26.33 | mvanbaak | jsmith: I think some digium devs already run it |
| 18:26.41 | mvanbaak | so I bet it Just Works(tm) |
| 18:26.45 | russellb | it should |
| 18:27.00 | *** join/#asterisk-dev ctooley (n=ctooley@rrcs-71-42-115-245.sw.biz.rr.com) |
| 18:27.01 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 18:27.09 | mvanbaak | russellb: just for your info |
| 18:27.18 | mvanbaak | the pthread timers work great in OpenBSD |
| 18:27.22 | mvanbaak | even better then in Linux |
| 18:27.51 | mvanbaak | ok, friday evening |
| 18:27.59 | mvanbaak | time to get a drink with some friends |
| 18:38.34 | Qwell | Cresl1n: what's a CIC? |
| 18:38.55 | seanbright | charles in charge |
| 18:39.03 | Qwell | makes perfect sense |
| 18:39.17 | seanbright | carrier indication code? |
| 18:39.22 | Cresl1n | it's a label for a DS0 |
| 18:39.22 | Qwell | ~cic |
| 18:39.28 | Cresl1n | yeah, carrier indication code |
| 18:39.28 | Qwell | jbot: die |
| 18:39.29 | jbot | ACTION takes two shots to the head and crumples to the ground, lifeless. |
| 18:39.33 | Cresl1n | I think that's what it stands for |
| 18:39.41 | Qwell | jbot: cic is Carrier Indication Code (maybe) |
| 18:39.41 | jbot | okay, Qwell |
| 18:39.43 | Qwell | :D |
| 18:39.43 | seanbright | http://en.wikipedia.org/wiki/Carrier_Identification_Code |
| 18:40.02 | seanbright | jbot, forget cic |
| 18:40.02 | jbot | seanbright: i forgot cic |
| 18:40.20 | seanbright | jbot, cic is Carrier Identification Code (or something) |
| 18:40.21 | jbot | seanbright: okay |
| 18:40.39 | Corydon76-dig | jbot: cic is also Charles In Charge |
| 18:40.39 | jbot | Corydon76-dig: okay |
| 18:40.44 | seanbright | jbot, fist fight Qwell |
| 18:40.44 | jbot | ACTION uses fight Qwell as a handpuppet |
| 18:40.53 | Qwell | O.o |
| 18:40.54 | seanbright | EW |
| 18:40.58 | Qwell | wow |
| 18:41.08 | Corydon76-dig | Well, alrighty then |
| 18:41.08 | seanbright | that is just... horrible |
| 18:41.14 | Qwell | jbot: forget fist |
| 18:41.14 | jbot | i didn't have anything called 'fist' to forget, Qwell |
| 18:41.19 | seanbright | noooooooooooooooooo! |
| 18:41.20 | seanbright | hahah |
| 18:41.22 | Qwell | oh dear, that's coded |
| 18:42.03 | seanbright | apologizes for finding that 'feature' |
| 18:42.14 | Qwell | just poked TimRiker :p |
| 18:42.15 | Corydon76-dig | jbot: fist seanbright |
| 18:42.16 | jbot | ACTION uses seanbright as a handpuppet |
| 18:42.20 | seanbright | ugh |
| 18:42.23 | seanbright | Corydon76-dig: you would |
| 18:42.26 | seanbright | son of a... |
| 18:42.27 | seanbright | heh |
| 18:42.39 | Corydon76-dig | pets seanbright |
| 18:42.44 | seanbright | better |
| 18:42.46 | Qwell | ~pet Qwell |
| 18:42.47 | jbot | ACTION reaches over and pets Qwell on the head, saying "There, there! It'll all be ok!" |
| 18:43.43 | Corydon76-dig | I remember the first time I heard about that activity... |
| 18:43.49 | seanbright | runs away screaming |
| 18:44.43 | Corydon76-dig | Guy in a bathhouse, thinks this guy is a amputee and says "it looks like that guy has his hand up the other guy's ass". The other guy looks and says, "He does" |
| 18:44.50 | putnopvut | loling at "fist" |
| 18:46.30 | russellb | w .. t .. f |
| 18:46.59 | Corydon76-dig | jbot has such wonderful talents |
| 18:47.47 | russellb | ~thwack Corydon76-dig |
| 18:47.48 | jbot | ACTION beats Corydon76-dig on the thumb with a toaster |
| 18:47.56 | russellb | ~frag putnopvut |
| 18:47.57 | jbot | ACTION readies the nuke launcher and fires some rounds at putnopvut |
| 18:48.25 | russellb | ~tackle seanbright |
| 18:48.26 | jbot | ACTION tackles seanbright to the ground. |
| 18:48.31 | russellb | giggles |
| 18:48.34 | putnopvut | ~lart russellb |
| 18:48.34 | jbot | hits russellb with an anvil and laughs with a contralto voice ... Haha Ha HA Ha |
| 18:48.35 | Qwell | as opposed to? |
| 18:49.00 | Qwell | ~kill russellb |
| 18:49.00 | jbot | ACTION shoots a charged anti-electron gun at russellb |
| 18:49.33 | *** join/#asterisk-dev De_Mon (i=de_mon@fl-71-55-24-227.dhcp.embarqhsd.net) |
| 18:49.37 | seanbright | prefers the rail gun |
| 18:49.52 | Corydon76-dig | Make love, not war. |
| 18:49.59 | seanbright | hippy |
| 18:50.00 | russellb | ~sex |
| 18:50.01 | jbot | updatedb; locate; talk; date; cd; strip; look; touch; finger; unzip; uptime; gawk; head; apt-get install condom; mount; fsck; gasp; more; yes; yes; yes; more; umount; apt-get remove --purge condom; make clean; sleep, or super extractor, http://sf.net/projects/sex/ |
| 18:50.33 | seanbright | no 'repeat' calls in there? |
| 18:53.05 | Corydon76-dig | Not that I know of |
| 18:53.19 | seanbright | ah well |
| 18:53.21 | Corydon76-dig | You could do a for loop, though |
| 18:53.34 | seanbright | oh weird |
| 18:53.43 | seanbright | i was thinking of yes |
| 18:54.07 | Corydon76-dig | There is a repeat command in Logo, though |
| 18:54.31 | putnopvut | what is "gasp?" |
| 18:54.38 | seanbright | gnu asp |
| 18:54.53 | seanbright | kids |
| 18:55.08 | Corydon76-dig | seanbright: that's what it is |
| 18:55.25 | Corydon76-dig | GNU ASsembler Preprocessor |
| 18:55.30 | seanbright | ahh |
| 18:55.32 | seanbright | sweet |
| 18:56.37 | Corydon76-dig | gasp || gasm |
| 18:57.12 | russellb | heh |
| 18:59.32 | Corydon76-dig | We could, of course, incorporate that... |
| 18:59.33 | seanbright | gasp || gasm || git |
| 18:59.41 | seanbright | take it to the next leve. |
| 18:59.44 | seanbright | s/leve/level/ |
| 18:59.47 | Corydon76-dig | orgit? |
| 19:00.00 | seanbright | ohhh |
| 19:00.01 | seanbright | ahahaha |
| 19:00.03 | seanbright | now i get it |
| 19:00.04 | seanbright | nice work. |
| 19:28.43 | jsmith | pounds his head against the wall |
| 19:28.57 | jsmith | Wasn't there a way to automatically run things when Asterisk starts up?!? |
| 19:29.04 | jsmith | can't seem to find it, and it's driving him nuts |
| 19:29.16 | *** join/#asterisk-dev techie (n=techie@m120e36d0.tmodns.net) |
| 19:34.20 | seanbright | console.conf or something |
| 19:34.57 | seanbright | err |
| 19:35.00 | seanbright | cli.conf? |
| 19:35.02 | bbryant | cli.conf |
| 19:35.26 | seanbright | that's at cli connect time, not asterisk start up though |
| 19:35.31 | jsmith | :-( |
| 19:35.42 | jsmith | I thought there was some sort of auto-start thing as well |
| 19:36.14 | file | what sort of things would it run? |
| 19:36.22 | russellb | cli.conf is what you are thinking of |
| 19:36.27 | russellb | and it really is when asterisk starts up ... |
| 19:36.33 | seanbright | oh, good. |
| 19:36.39 | russellb | it's CLI commands (hence cli.conf) that will execute at startup |
| 19:36.47 | seanbright | ohhhh |
| 19:36.54 | seanbright | well that's confusing. |
| 19:36.56 | seanbright | heh |
| 19:36.57 | jsmith | OK... and it's not in 1.4, right? Just 1.6 betas? |
| 19:37.01 | russellb | well ... you're confusing |
| 19:37.04 | russellb | yes, 1.6/trunk |
| 19:37.23 | russellb | trivial to backport probably if you wanted to |
| 19:37.30 | seanbright | ~stab russellb |
| 19:37.30 | jbot | ACTION runs at russellb with an origami Swiss Army knife, and inflicts a nasty paper cut. |
| 19:37.37 | russellb | ~kick seanbright |
| 19:37.38 | jbot | ACTION kicks seanbright |
| 19:37.48 | seanbright | ~fis... |
| 19:37.49 | seanbright | heh |
| 19:37.53 | putnopvut | ~fish |
| 19:37.54 | jbot | well, fish is FISHFISHFISH! DO THE FISH DANCE! "Give a man a fish and you'll feed him a day. Teach him how to fish and he'll feed himself for the rest of his life." This is so appropriate, instead of asking us to tell you exactly what to do, why not read some docs, then come back and ask specific questions which aren't covered?, or http://www.p-nand-q.com/maldives/rbr/fish/sf25.jpg |
| 19:38.00 | russellb | ~nowwhat |
| 19:38.01 | jbot | So you just installed Asterisk now what? http://www.youtube.com/watch?v=ULgwbvj768E |
| 19:38.04 | putnopvut | lol |
| 19:48.05 | Corydon76-dig | I want my two minutes back! |
| 20:05.56 | *** join/#asterisk-dev J4zen (n=Jeroen@213-84-194-178.adsl.xs4all.nl) |
| 20:08.38 | ctooley | I haven't gotten all the way through it and I want the last 10 minutes of my life back. |
| 20:09.20 | *** part/#asterisk-dev Cresl1n (n=matt@216.207.245.1) |
| 20:30.25 | *** join/#asterisk-dev qdk (n=qdk@0x573fe57e.bynqu2.broadband.tele.dk) |
| 21:01.22 | *** join/#asterisk-dev RoyK (n=roy@ip-168-52-149-91.dialup.ice.no) |
| 21:22.22 | seanbright | it probably goes without saying... but this is patently wrong, yes? |
| 21:22.26 | seanbright | if (something) { |
| 21:22.35 | seanbright | <PROTECTED> |
| 21:22.36 | seanbright | } |
| 21:27.28 | putnopvut | heh, I'm curious what the else part of that if does. |
| 21:28.08 | seanbright | well |
| 21:28.12 | seanbright | i guess my question is |
| 21:28.16 | seanbright | between the if (something) check |
| 21:28.20 | seanbright | and the attempted lock |
| 21:28.25 | seanbright | something could go away |
| 21:28.34 | seanbright | assuming it was accessible from another thread |
| 21:28.36 | seanbright | right? |
| 21:28.48 | seanbright | 'something' could go away |
| 21:29.14 | putnopvut | Yeah, that's true. |
| 21:29.23 | seanbright | ok |
| 21:30.10 | outtolunc | because the ast_channel_lock is an 'attempt if not already' (iirc) it is more a leap of faith |
| 21:30.31 | seanbright | ast_channel_lock? |
| 21:30.34 | putnopvut | outtolunc: could you clarify a bit more? |
| 21:30.42 | outtolunc | must have misread |
| 21:30.51 | outtolunc | misread.. |
| 21:31.08 | seanbright | so in a nutshell, if i need to reliably access 'something' |
| 21:31.12 | seanbright | i need an external lock |
| 21:31.55 | putnopvut | yeah, or there's always refcounting, if possible. |
| 21:32.00 | seanbright | right |
| 21:32.08 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 21:32.08 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 21:32.12 | seanbright | pardon the nub question :) |
| 21:32.23 | russellb | not necesarily |
| 21:32.32 | russellb | you simply need a reliable reference to the something |
| 21:32.38 | russellb | you don't need an external lock ... |
| 21:32.49 | seanbright | define 'reliable reference' |
| 21:33.01 | russellb | you don't need to be holding a lock to ensure something doesn't go away |
| 21:33.10 | russellb | i.e. ... reference counted objects ... |
| 21:33.15 | seanbright | no, i understand that |
| 21:33.36 | seanbright | but let's say i have to lock a shared resource |
| 21:34.17 | russellb | yes, you need some external mechanism to ensure that the shared resource is valid before you attempt to lock it |
| 21:34.22 | seanbright | right |
| 21:34.32 | russellb | the external mechanism may or may not be a lock |
| 21:34.53 | russellb | it may be nothing other than the fact that it's something that never goes away and is always valid ... |
| 21:34.58 | seanbright | well sure |
| 21:36.36 | seanbright | <-- nub |
| 21:38.33 | *** join/#asterisk-dev jbot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 21:38.33 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- IAX2/guest@pbx.digium.com/asterisk-dev -=- Asterisk trunk: res_telepathy release tomorrow-=- Tier 2 and Tier 3.14159 support is in #asterisk -=- Automated Builds, thx file! - http://buildbot.digium.com -=- http://video.google.com/videoplay?docid=7287180007025709537&hl=en |
| 21:38.45 | seanbright | wonders if 'fist' was removed |
| 21:41.19 | russellb | heh |
| 21:41.59 | russellb | ~fist himself |
| 21:41.59 | jbot | ACTION uses himself as a handpuppet |
| 21:42.05 | russellb | nope |
| 21:45.27 | Corydon76-dig | russellb: ping |
| 21:46.08 | russellb | pong |
| 21:46.13 | russellb | (was about to step away, though) |
| 21:46.16 | Corydon76-dig | M12863 |
| 21:46.18 | MuffinMan | [new] [Asterisk] Channels/chan_sip/Registration 0012863: Asterisk gives up on registration after receiving 408 Timeout response once reported by ricvil (Karma: neutral) http://bugs.digium.com/view.php?id=12863 |
| 21:46.39 | Corydon76-dig | You committed the first part of this... just wanted to see if you could look at the suggested change |
| 21:47.24 | russellb | yeah, let's see what I did ... |
| 21:48.49 | russellb | oh, hm, guess I didn't think about that change very much, heh |
| 21:48.56 | russellb | removing the rest seems fine .. |
| 21:49.06 | Corydon76-dig | okay |
| 21:52.17 | *** part/#asterisk-dev Rem| (n=remi@bg-fw2out.monmouth.com) |
| 21:53.54 | russellb | i guess i figured that by destroying the dialog, that didn't mean that a new one wouldn't get created to try again |
| 21:53.57 | russellb | guess that's not the case |
| 21:53.58 | russellb | shrugs |
| 21:55.35 | Corydon76-dig | I'm going to do one other thing... reset regattempts, so we keep trying |
| 21:55.48 | *** join/#asterisk-dev denon (n=denon@tooth.decay.org) |
| 21:56.01 | Corydon76-dig | Getting a response is always better that none, which is what the maxregattempts I think was trying to solve |
| 21:57.08 | russellb | sounds good :) |
| 21:57.21 | russellb | i think giving up should be a pretty rare case, and only when the RFC explicitly says to do that ... |
| 21:57.33 | russellb | which some fatal responses ...500s, 600s? something like that ... |
| 21:57.36 | russellb | runs off for a bit |
| 21:57.43 | Corydon76-dig | like when we get a 479 |
| 22:37.42 | seanbright | hrmmm |
| 22:37.49 | seanbright | http://refactormycode.com/ |
| 22:44.34 | russellb | O.O |
| 22:44.36 | russellb | random |
| 22:44.46 | putnopvut | strfry("random"); |
| 22:44.51 | Qwell | no, you want random? |
| 22:44.51 | Qwell | http://www.yyyyyyy.info/ |
| 22:44.56 | seanbright | just thought it was a cool site |
| 22:44.59 | seanbright | tough room. |
| 22:45.03 | Qwell | it's like the Internet threw up |
| 22:45.05 | russellb | seanbright: yeah, that is neat .... |
| 22:45.10 | russellb | i'd probably have fun on it |
| 23:18.40 | seanbright | codefreeze-lap: i may have missed it, did you ever work out the lock timing stuff? |
| 23:40.04 | *** join/#asterisk-dev DarkRift (i=dark@bas10-montreal02-1177582050.dsl.bell.ca) |
