| 00:02.44 | moy_ | hello everyone ... does anybody know who should I request to get my certificate renewed to? looks like it expired just yesterday |
| 00:04.50 | Kobaz | talk to jeff peeler |
| 00:05.05 | Kobaz | jpeeler@digium.com |
| 00:08.21 | moy_ | Kobaz: u sure he still at Digium? I tried emailing him (remembering the last time he did it), but I got the email returned |
| 00:09.52 | Kobaz | hmm |
| 00:09.57 | Kobaz | that's who i talked to |
| 00:10.04 | Kobaz | in january |
| 00:10.41 | Kobaz | give russell or leif a poke on monday |
| 00:16.31 | file | Jeff Peeler is no longer with Digium. |
| 00:16.59 | Kobaz | moy_: that would explain it |
| 00:18.31 | moy_ | indeed ... I sent email to russellb already |
| 00:51.13 | *** join/#asterisk-dev jhmichelle352 (~jhmichell@41.206.146.255) |
| 02:12.50 | *** join/#asterisk-dev joshaidan (~brianj@S0106001c1023e838.tb.shawcable.net) |
| 03:15.22 | jhmichelle352 | kobaz:ping |
| 03:16.19 | Kobaz | poke |
| 03:16.22 | Kobaz | pong |
| 03:16.26 | jhmichelle352 | great |
| 03:16.32 | Kobaz | you fixed it? |
| 03:16.56 | jhmichelle352 | no , i was actually away , but i have a question |
| 03:17.27 | jhmichelle352 | ast_queue_hangup calls ast_queue_frame which locks without even checking for locks |
| 03:17.59 | Kobaz | what's locked before that? |
| 03:17.59 | jhmichelle352 | channel.c line 1014 ast_channel_lock(chan); |
| 03:18.09 | Kobaz | so the channel is locked the whole time |
| 03:18.40 | jhmichelle352 | actually ast_write has a lock ok |
| 03:19.19 | jhmichelle352 | when ast_queue_hangup is called ast_queue_frame try to make a lock also |
| 03:19.35 | jhmichelle352 | but my question is |
| 03:19.54 | jhmichelle352 | doesn't ast_queue_frame need to check for locks before locking? |
| 03:20.09 | Kobaz | recursive locks are okay |
| 03:20.15 | Kobaz | you can lock your own channel multiple times |
| 03:20.23 | Kobaz | you just need to unlock it the same number of times |
| 03:20.31 | Kobaz | if it's been locked previously by the same thread, it's okay to lock it again |
| 03:21.34 | jhmichelle352 | i see but if it's trying to acquire a lock on an already locked channel doesn't it wait till that lock is acquired |
| 03:21.49 | Kobaz | if you have |
| 03:21.52 | Kobaz | ast_channel_lock(chan); |
| 03:21.54 | Kobaz | dostuff |
| 03:21.55 | Kobaz | ast_channel_lock(chan); |
| 03:21.57 | Kobaz | that's fine |
| 03:22.11 | Kobaz | it will get the lock on chan, and then the next time it gets the lock it will get it right away |
| 03:22.11 | jhmichelle352 | as long as you unlock it 2 times |
| 03:22.14 | Kobaz | it already has a lock |
| 03:22.14 | Kobaz | yeah |
| 03:22.25 | Kobaz | it's called recursive locking |
| 03:22.30 | Kobaz | it makes writing the code a little simpler |
| 03:23.35 | jhmichelle352 | well i have been doing software architure for 7 years now and the first time i hear about recursive locking :) |
| 03:23.50 | Kobaz | there's always something new |
| 03:24.43 | jhmichelle352 | great thanks i will continue tracing now,i just woke up it's 5:24 am here |
| 03:25.38 | Kobaz | heh |
| 03:28.50 | jhmichelle352 | kobaz: i have been thinking about the recursive locking doesn't this undermine the whole concept of locking , i mean you lock for a shared memory access , why don't just use signaling |
| 03:29.26 | Kobaz | it's only for a single thread |
| 03:29.32 | Kobaz | thread A |
| 03:29.37 | Kobaz | lock(chan); lock(chan); |
| 03:29.42 | Kobaz | thread B |
| 03:29.46 | Kobaz | lock(chan) // waiting |
| 03:31.53 | jhmichelle352 | well i don't see why you need a lock on a sequential excution but as long as it's legal i will continue tracing :) |
| 03:33.20 | Kobaz | actually i guess it depends on the stack (and firewall settings) wether you get an icmp or not |
| 03:33.24 | Kobaz | er |
| 03:33.24 | Kobaz | wrong window |
| 03:45.50 | jhmichelle352 | kobaz: what happens when ast_channel_tech callback is called and it's not implemented in the a certain module? |
| 03:46.13 | jhmichelle352 | like indicate for instance |
| 03:46.37 | Kobaz | 7200 on both machines |
| 03:46.54 | Kobaz | er, i need to pay more attention to channel names |
| 03:47.01 | jhmichelle352 | yup |
| 03:47.08 | jhmichelle352 | :) |
| 03:47.53 | Kobaz | anyway |
| 03:47.57 | Kobaz | if there's no tech callback |
| 03:48.32 | Kobaz | basically they don't get called |
| 03:50.13 | jhmichelle352 | because i see in ast_write a call for chan->tech->indicate( , where this callback is not implemented in our module |
| 03:50.43 | Kobaz | if (chan->tech->indicate) { |
| 03:50.57 | Kobaz | there's a bunch of those around if you notice |
| 03:51.18 | jhmichelle352 | chan->tech->indicate(chan, fr->subclass, fr->data.ptr, fr->datalen); |
| 03:51.18 | Kobaz | chan->tech->indicate shouldn't be called unless it's non-null |
| 03:51.34 | jhmichelle352 | yeah |
| 03:51.43 | jhmichelle352 | i see |
| 03:51.59 | jhmichelle352 | thanks |
| 04:44.39 | *** join/#asterisk-dev jhmichelle352 (~jhmichell@41.206.146.255) |
| 07:18.14 | *** join/#asterisk-dev irroot (~irroot@41.49.146.4) |
| 09:30.34 | *** join/#asterisk-dev irroot (~irroot@41.55.112.98) |
| 10:02.39 | *** join/#asterisk-dev irroot (~irroot@197.106.28.129) |
| 10:04.32 | *** join/#asterisk-dev moy_ (~moy@bas5-toronto47-1167928560.dsl.bell.ca) |
| 10:32.37 | *** join/#asterisk-dev irroot (~irroot@197.173.190.98) |
| 11:11.25 | *** join/#asterisk-dev irroot (~irroot@197.171.151.1) |
| 11:12.03 | *** join/#asterisk-dev jhmichelle352 (~jhmichell@41.206.146.255) |
| 11:12.17 | *** join/#asterisk-dev jhmichelle352 (~jhmichell@41.206.146.255) |
| 11:16.10 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:16.10 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:22.08 | *** join/#asterisk-dev irroot (~irroot@41.54.32.162) |
| 11:35.32 | *** join/#asterisk-dev tamiel (~tamiel@ip-28.net-81-220-88.toulouse.rev.numericable.fr) |
| 13:11.22 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:cce6:ba9d:9aef:52bd) |
| 13:20.22 | leifmadsen | Kobaz: nice work! how many issues does that potentially close? |
| 13:21.35 | *** join/#asterisk-dev tamiel (~tamiel@ip-28.net-81-220-88.toulouse.rev.numericable.fr) |
| 13:26.30 | Kobaz | a whole bunch |
| 13:26.41 | Kobaz | but not jhmichelle352's issue though |
| 14:03.49 | leifmadsen | too bad |
| 14:13.46 | Kobaz | heh |
| 14:15.33 | leifmadsen | I mean that with a total lack of sarcasm too (which may be hard to believe) |
| 14:18.53 | Kobaz | hehe, ah |
| 14:45.17 | jhmichelle352 | :) |
| 14:57.56 | *** join/#asterisk-dev mpe (~mpe@2.104.127.55) |
| 15:06.59 | Kobaz | oh, another one |
| 15:07.37 | Kobaz | just mark everything related to 0018028 |
| 15:07.41 | Kobaz | so we can close out every issue |
| 15:07.49 | Kobaz | :) |
| 15:08.01 | jhmichelle352 | kobaz i know some issues related to 18028 |
| 15:09.20 | jhmichelle352 | 15609 ,15900 , 17521 ,18511 |
| 15:09.39 | jhmichelle352 | timerfd: |
| 15:09.59 | Kobaz | leifmadsen ^ |
| 15:10.18 | leifmadsen | jhmichelle352: thanks I'm going through issues now and marking some other ones as related as well |
| 15:10.26 | leifmadsen | Kobaz: working on that |
| 15:10.46 | jhmichelle352 | 18816,18166 |
| 15:10.50 | jhmichelle352 | and 18569 both |
| 15:11.08 | Kobaz | nice |
| 15:14.06 | jhmichelle352 | these are the issues that i always chek for updates |
| 15:14.26 | jhmichelle352 | *check |
| 15:19.44 | *** part/#asterisk-dev mpe (~mpe@2.104.127.55) |
| 15:20.13 | leifmadsen | Kobaz: you are going to close a LOT of issues |
| 15:21.43 | jhmichelle352 | actually some of the issue are not yet finished |
| 15:22.10 | jhmichelle352 | they are all related to ast_write deadlock which i am working on |
| 15:23.06 | jhmichelle352 | kobaz: in issue 19304 i see you are following up the ast_wrie problem |
| 15:23.08 | MuffinMan | [ready for testing] [Asterisk] Resources/res_timing_timerfd 0019304: [patch] Random entire asterisk deadlock when use builtin_atxfer when use res_timing_timerfd module reported by microlana https://issues.asterisk.org/view.php?id=19304 |
| 15:23.19 | *** join/#asterisk-dev mpe (~mpe@2.104.127.55) |
| 15:23.46 | jhmichelle352 | you mentioned that if i we use dahdi timer then the hangup problem will go away right? |
| 15:23.52 | Kobaz | yes |
| 15:24.05 | Kobaz | in my tests that's what i've seen |
| 15:25.03 | jhmichelle352 | so all what i have todo is remob res_timming_pthread and res_timing_timer_fd |
| 15:25.09 | jhmichelle352 | *remove |
| 15:25.17 | jhmichelle352 | ? |
| 15:25.37 | jhmichelle352 | from menu-select i mean |
| 15:27.06 | jhmichelle352 | ? |
| 15:27.14 | leifmadsen | ok I'm done relating issues |
| 15:27.29 | Kobaz | nah |
| 15:27.31 | Kobaz | just edit modules.conf |
| 15:27.37 | Kobaz | noload => res_timing_timer_fd |
| 15:27.38 | Kobaz | etc |
| 15:27.42 | Kobaz | res_timing_timer_fd.so |
| 15:27.58 | jhmichelle352 | and res_timing_pthread ? |
| 15:28.32 | jhmichelle352 | liefmadsen: wow all this issue are related :) |
| 15:31.02 | Kobaz | if dahdi is loaded i don't think pthread is loaded |
| 15:31.07 | jhmichelle352 | is there logs for this irc conversations that are archived online? |
| 15:31.08 | Kobaz | but you can add that to noload for sanity |
| 15:31.17 | Kobaz | jhmichelle352: yeah somewhere |
| 15:33.33 | jhmichelle352 | i will test the dahdi timing in the next hr and update you with my findings |
| 15:34.43 | Kobaz | good good |
| 15:37.22 | jhmichelle352 | by the way is there any asterisk protocol that has traffic statistical detection avoidance i.eobfuscation |
| 15:37.26 | jhmichelle352 | obfuscation |
| 15:38.15 | Kobaz | there really is no 'asterisk protocol' |
| 15:38.19 | Kobaz | other than iax |
| 15:38.31 | Kobaz | if you want security, route over an encrypted vpn |
| 15:38.31 | jhmichelle352 | i mean asterisk supported protocol |
| 15:38.42 | Kobaz | there is srtp |
| 15:38.47 | Kobaz | and sip tls |
| 15:39.01 | jhmichelle352 | as i already mentioned statiscal |
| 15:39.09 | jhmichelle352 | vpns are no good |
| 15:39.56 | jhmichelle352 | i will actually start working on one soon, this is the new level of traffic shapping |
| 15:40.30 | Kobaz | what's the goal? |
| 15:41.16 | jhmichelle352 | well isp vendors are comming up with new technics of blocking voip, which is not healthy for the internet as a whole |
| 15:41.29 | *** join/#asterisk-dev cyphorious (~cyphoriou@212-183-65-51.adsl.highway.telekom.at) |
| 15:41.32 | jhmichelle352 | so the latest way is statistical shaping |
| 15:41.39 | Kobaz | which isps are blocking? |
| 15:41.59 | jhmichelle352 | well in the middle east for example tedata |
| 15:42.52 | jhmichelle352 | beside it's an added security, like skype there protocol employs some technics to beat that |
| 15:43.01 | Kobaz | interesting |
| 15:43.24 | jhmichelle352 | offcourse overhead well be a major design conern |
| 15:44.19 | jhmichelle352 | even in the stats i heared that somecarriers block voip over 3g |
| 15:44.49 | Kobaz | yeah |
| 15:45.23 | jhmichelle352 | see that why such protocols will be a must for the future |
| 15:45.44 | Kobaz | and then other people will write code to detect the shaping |
| 15:45.56 | jhmichelle352 | yeah it's an arms race |
| 15:46.19 | jhmichelle352 | but it's simply security |
| 15:46.29 | Kobaz | it seems to be self-modifying |
| 15:46.40 | Kobaz | and every so often inject pictures of lady gaga or something |
| 15:46.54 | jhmichelle352 | :) |
| 15:47.01 | jhmichelle352 | justin bieber |
| 15:47.33 | jhmichelle352 | no it well be a little bit sophisticated than that |
| 15:47.49 | jhmichelle352 | it will memic browsing for example |
| 15:47.59 | jhmichelle352 | or streaming on youtube |
| 15:48.52 | jhmichelle352 | just a normal browsing behaviour, it will be even hard for a human to notic that |
| 17:32.55 | *** join/#asterisk-dev joshaidan (~brianj@S0106001c1023e838.tb.shawcable.net) |
| 17:54.25 | jhmichelle352 | kobaz: ping |
| 17:54.33 | Kobaz | meep |
| 17:55.54 | jhmichelle352 | i didn't start the dahadi timing yet but there this a new error that is poping up for the first time since applying timerfd patch i will pastebin |
| 17:56.38 | jhmichelle352 | http://pastebin.com/gueApqCQ |
| 17:57.23 | Kobaz | i haven't tested at all on 1.6.2 |
| 17:57.42 | jhmichelle352 | yeah , that's why i am reporting :) |
| 17:58.12 | Kobaz | that's caused by some other problem |
| 17:58.15 | jhmichelle352 | do you think it's even related? |
| 17:58.21 | jhmichelle352 | ok |
| 17:58.45 | Kobaz | the low level problem is reading a timer that's not doing anything |
| 17:58.57 | Kobaz | but there's a high level problem, the code shouldn't try and read the timer anyway |
| 17:59.06 | Kobaz | so something, somewhere, is reading a timer when it shouldn't |
| 17:59.13 | Kobaz | which can cause all kinds of other problems |
| 17:59.20 | Kobaz | so the patch just fixes one specific condition |
| 17:59.28 | Kobaz | and it's more of a workaround than a true fix |
| 17:59.44 | Kobaz | the real fix is to find the code that's using the timers wrong |
| 17:59.57 | Kobaz | but you get that error instead of a deadlock now? |
| 18:00.23 | jhmichelle352 | now actually i still get a deadlock, but that error was on a different channel |
| 18:00.50 | Kobaz | well okay, let me rephrase |
| 18:01.01 | Kobaz | did you ever get a deadlock in the timerfd code? |
| 18:02.29 | Kobaz | because if you didn't this patch should have no effect on your problem |
| 18:02.45 | jhmichelle352 | yes, sometimes the timer spewes read error: bad file descriptor , that was rare and i never reported that never the less so far after the patch i havn't seen any timer errors |
| 18:04.01 | Kobaz | this patch specifically fixes the problem with reading an idle timer |
| 18:04.22 | Kobaz | if the patch is helping, you will see warnings in the console saying that the deadlock was avoided |
| 18:04.47 | jhmichelle352 | as i mentioned before i commented out all the warnings for cpu time sake |
| 18:04.52 | jhmichelle352 | :) |
| 18:05.46 | Kobaz | but you wont know if the patch did anything without the warnings |
| 18:06.26 | jhmichelle352 | i can turn the warning on but i need some kind of idea how often will they be called since this is a production box |
| 18:06.48 | Kobaz | it might never be called |
| 18:06.54 | Kobaz | or it might be called a bazillion times |
| 18:07.04 | jhmichelle352 | :) |
| 18:07.18 | Kobaz | so, heh |
| 18:07.23 | jhmichelle352 | well i will test it in the off peak hrs |
| 18:07.26 | Kobaz | it depends on your setup and what code is running, and etc etc |
| 18:07.32 | jhmichelle352 | sure |
| 19:25.05 | *** join/#asterisk-dev joshaidan_ (~brianj@S0106001c1023e838.tb.shawcable.net) |
| 19:42.29 | *** join/#asterisk-dev joshaidan (~brianj@S0106001c1023e838.tb.shawcable.net) |
| 21:02.47 | *** join/#asterisk-dev tamiel (~tamiel@ip-28.net-81-220-88.toulouse.rev.numericable.fr) |
| 21:39.10 | jhmichelle352 | kobaz: ping |