| 00:08.40 | leifmadsen | well played sirs |
| 00:45.35 | Micc_ | without pthread I'm getting crashes all the time when I try to use ConfBridge now. |
| 00:56.36 | leifmadsen | o.O |
| 00:56.43 | leifmadsen | I haven't had any crashes with confbridge and dahdi yet |
| 00:56.53 | leifmadsen | at least in reasonable testing, not hi load yet |
| 00:57.00 | leifmadsen | (other than the testing I did at digium) |
| 00:59.14 | Micc_ | very low load, it happened every time when I had noload = res_timing_pthread.so |
| 01:02.11 | Micc_ | so what component/s would I put for this deadlock buck in pthread? Not the crash I was most recently talking about, but this http://pastebin.com/tEnZNXt6 |
| 01:03.58 | Kobaz | weird |
| 01:04.04 | Micc_ | but on that other issue, I loaded pthreads and now no crash. |
| 01:04.05 | Kobaz | without pthread timing you crash? |
| 01:04.10 | Micc_ | yes. |
| 01:04.16 | Kobaz | what timing module? |
| 01:04.20 | Micc_ | dahdi |
| 01:04.25 | Micc_ | the latest one on asterisk.org. |
| 01:04.28 | Kobaz | card or dummy? |
| 01:04.37 | Micc_ | dummy |
| 01:05.02 | pabelanger | why are you still using dummy? |
| 01:05.25 | Kobaz | Micc_: that's a deadlock... but you said you crash? |
| 01:05.38 | Kobaz | pabelanger: because pthread timing and timerfd timing have bugs? |
| 01:06.19 | pabelanger | But, my understanding is dahdi_dummy is not even enabled by default for compiling |
| 01:06.24 | Kobaz | Micc_: can you reproduce the problem with BETTER_BACKTRACES |
| 01:26.00 | Micc_ | probably not, this is in production already. We didn't see this problem in testing. |
| 01:26.10 | Micc_ | I think we have to roll back now. |
| 01:26.16 | Micc_ | use asterisk 10 |
| 01:27.09 | Micc_ | oh crap. I think I hit cancel but jira posted the bug anyways. |
| 01:30.39 | Micc_ | I think it might have something to do with the change I made in ConfBridge. |
| 01:31.26 | Micc_ | I added an end application to clear all the channels in a room. I took the code from leave_marked_end I think. |
| 01:31.55 | Micc_ | so I don't think I should file a bug until I verify that isn't causing it. |
| 01:33.29 | pabelanger | Ya, if you are modifying the source of asterisk, you can't submit a bug after you have modified code |
| 01:33.48 | pabelanger | but, if you remove your logic and it still fails, they ya, feel free to submit it as a bug |
| 03:19.24 | *** join/#asterisk-dev Micc (~Mic@c-24-19-33-189.hsd1.wa.comcast.net) |
| 04:27.11 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 04:27.11 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 06:26.40 | Micc | now I just need to figure out a new way to clear a ConfBridge. I suppose I'll just put all the channels in the database and loop through them all requesting them to hangup. |
| 06:37.15 | Juggie | no way to ask for a list from confbridge? |
| 08:16.08 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 08:16.08 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 08:36.05 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 09:10.59 | *** join/#asterisk-dev bombev (~bombev@213.91.132.40) |
| 10:04.28 | *** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3) |
| 12:34.54 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 12:34.54 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 13:21.58 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 13:21.58 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 14:00.19 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-dqensnjaadaxydev) |
| 14:02.50 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:02.50 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:07.51 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:07.51 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:09.43 | *** join/#asterisk-dev leedm777 (~leedm777@nat/digium/x-mhxfukaaquuunbbo) |
| 15:33.00 | *** join/#asterisk-dev spditner (~simon@206.248.134.2) |
| 15:38.21 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:38.21 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:05.37 | *** join/#asterisk-dev Rico29 (~rico@oceanet-telecom-fttb-129-2.olm.fr) |
| 16:32.34 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:48.34 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:48.58 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 17:03.13 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-aqydqcgljziadzow) |
| 17:03.13 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 17:29.15 | Corydon76-home | putnopvut: I'm hoping your new channel driver will register its technology as "SIP2", because I expect that the two channel drivers will coexist for a time. Correct? |
| 17:30.42 | mjordan | Corydon76-home: I'm not sure we've decided yet what to do about that, other than they have to coexist |
| 17:31.00 | pabelanger | chan_new_sip |
| 17:31.06 | mjordan | that may mean that the new one registers as SIP and the old one registers as something else |
| 17:31.21 | Corydon76-home | pabelanger: yes, but the technology is the prefix that Dial uses to create new channels |
| 17:31.41 | pabelanger | nods |
| 17:32.19 | Corydon76-home | mjordan: I'd prefer that the old one keeps its name for at least one major release, so the kinks can be worked out without breaking anybody's dialplans with a single major release upgrade |
| 17:32.34 | Corydon76-home | and you will break some people. It is unavoidable. |
| 17:32.43 | mjordan | Corydon76-home: probably more then "some" |
| 17:32.59 | mjordan | During development it should have its own name |
| 17:33.34 | mjordan | I think the final technology registration is something to decide nearer to release time. We'll have to see how well the project goes. |
| 17:33.58 | Corydon76-home | I don't know if you were aware of it, but the current Voicemail is actually Voicemail2, and it existed as both names for a period after it was simply Voicemail2... |
| 17:34.13 | file | imo I don't foresee doing that transition for quite awhile |
| 17:35.16 | Corydon76-home | chan_<stackname> |
| 17:35.34 | file | naming is undecided/undiscussed |
| 17:39.54 | mjordan | jrose_atDigium: what timing sources did you use for your testing of r2186? |
| 18:01.00 | jrose_atDigium | I've tried with timerfd enabled and disabled. |
| 18:01.18 | jrose_atDigium | I assume it falls back to the dahdi timer without timerfd. |
| 18:01.24 | jrose_atDigium | I'm not sure how all that works though to be honest. |
| 18:01.36 | jrose_atDigium | mjordan: ^ |
| 18:04.18 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189-25-53-120.user.veloxzone.com.br) |
| 18:08.24 | mjordan | jrose_atDigium: it doesn't quite feel like we understand the original problem Jeff was trying to solve. |
| 18:33.06 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 18:33.06 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 20:09.53 | jrose_atDigium | mjordan: This is true. I don't know if there is anyway we can really understand it in the first place considering that Jeff was only able to reproduce the original problem after getting remote access to the reporter's machine though. |
| 20:11.05 | jrose_atDigium | putnopvut was of the opinion that his change merely served to work around the problem anyway though and that we should go with the revert with the understanding that the original problem might crop back up. |
| 20:13.42 | putnopvut | Yep. The original change was a total non-solution. That, coupled with the fact that res_timing_timerfd has seen many changes since the original fix means that reverting the odd behavior in ast_channel_alloc() feels like a good way to fix the current issue. If the original issue resurfaces, then it can be addressed by fixing whatever res_timing_timerfd has wrong with it rather than working around it. |
| 20:15.35 | jrose_atDigium | Unfortunately I've also found more, non-timer-specific ways for meetme to fall into the same trap. |
| 20:15.45 | jrose_atDigium | They are all similar though in that they involve hangups while Asterisk is playing a sound to a channel in the conf_run loop. |
| 20:17.54 | putnopvut | So the question then, is why doesn't the loop break? |
| 20:18.35 | jrose_atDigium | It all comes back to ast_waitfor_nandfds. |
| 20:19.04 | putnopvut | What is it returning once the channel has hung up? |
| 20:19.38 | jrose_atDigium | Normally when it exits from a hangup, it gets a channel from that function and then executes the break condition if can't cant get a frame from ast_read_noaudio. |
| 20:20.29 | putnopvut | But in the situation where a sound is played, what is different in the return? |
| 20:20.31 | jrose_atDigium | When we have one of these odd hangup conditions it gets NULL instead. |
| 20:20.57 | jrose_atDigium | This isn't abnormal though, and typically every other pass through the loop it gets a NULL as well. |
| 20:21.14 | jrose_atDigium | It just stops getting anything but NULL after the hangup. |
| 20:22.21 | putnopvut | Gotcha. So it comes back to that ast_check_hangup() that got removed. That would be useful for determining if the channel is gone. Of course that got purposely removed. |
| 20:22.31 | jrose_atDigium | yes |
| 20:22.40 | putnopvut | I'm going to look more closely at the revision where that was removed to get a better idea of what exactly the idea there was. |
| 20:23.01 | jrose_atDigium | http://lists.digium.com/pipermail/asterisk-commits/2011-January/047556.html |
| 20:23.03 | jrose_atDigium | that might help |
| 20:23.27 | putnopvut | Yep, I've got the log up at the moment. |
| 20:24.41 | putnopvut | Interesting. Reading russellb's log message more closely, he says that the rest of his changes actually fix the issue and that he removed the ast_check_hangup() because it didn't need to be there. I think you're finding quite the opposite. It does need to be there for this particular case. |
| 20:25.04 | putnopvut | So if you add it back, then it *shouldn't* cause the issue that russellb was fixing to resurface. |
| 20:25.28 | russellb | look at me with detailed commit messages! |
| 20:25.34 | putnopvut | hellz yeah |
| 20:25.36 | russellb | good thing, i certainly don't remember this stuff now |
| 20:25.39 | putnopvut | heh |
| 20:28.39 | file | russellb, but do you remember... eventlets? |
| 20:28.45 | jrose_atDigium | Well, cool beans. |
| 20:28.57 | russellb | file: maybe. |
| 20:29.05 | leifmadsen | file: nice |
| 20:29.22 | file | russellb, lies! |
| 20:32.44 | *** join/#asterisk-dev JimDickenson (~dickenson@c-71-193-138-117.hsd1.or.comcast.net) |
| 20:34.50 | jrose_atDigium | putnopvut: Is it a problem if we still get warning messages under the following circumstance: ast_streamfile plays one sound file to the channel. Channel hangs up during the playback of this file, but immediately afterwards another sound is played with streamfile to the same channel which has already hungup causing a warning message |
| 20:35.42 | jrose_atDigium | specifically: |
| 20:35.55 | jrose_atDigium | file.c:764 ast_readaudio_callback: Failed to write frame |
| 20:36.23 | JimDickenson | I am trying to get the raw sip response value in a dialplan using ABE c..3.7.2 |
| 20:36.47 | jrose_atDigium | An easy fix for that would be to just add a check_hangup condition to the beginning of ast_streamfile, but I'm not sure if it represents a deeper problem or not. |
| 20:37.27 | putnopvut | jrose_atDigium: probably you'd want to add the ast_check_hangup() to wherever ast_streamfile() is being called. |
| 20:37.46 | jrose_atDigium | ok, so don't just put it within ast_streamfile then. Got it. |
| 20:38.02 | putnopvut | JimDickenson: can't do it with that version. You'd need to use Asterisk 11 or later to get that. |
| 20:38.15 | JimDickenson | I have tried to set a channel variable in handle_response() but sometimes the channel name I get is not correct |
| 20:39.15 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 20:39.15 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 20:39.59 | JimDickenson | This works most of the time: |
| 20:40.01 | JimDickenson | owner = p->owner; |
| 20:40.02 | JimDickenson | if (owner) { |
| 20:40.02 | JimDickenson | // jcd 30oct2012 |
| 20:40.02 | JimDickenson | if (owner->chan_list.next) { |
| 20:40.03 | JimDickenson | char resp_str[10]; |
| 20:40.03 | JimDickenson | snprintf(resp_str, sizeof(resp_str), "%d", resp); |
| 20:40.03 | JimDickenson | pbx_builtin_setvar_helper(owner->chan_list.next, "CfMC_SIP_RESPONSE", resp_str); |
| 20:40.04 | JimDickenson | ast_verbose("CfMC-JCD - Setting var CfMC_SIP_RESPONSE to %s for %s\n", resp_str, owner->chan_list.next->name); } |
| 20:40.04 | JimDickenson | // jcd end |
| 20:40.04 | JimDickenson | owner->hangupcause = hangup_sip2cause(resp); } |
| 20:40.43 | leifmadsen | JimDickenson: pssst... pastebin.com |
| 20:41.11 | JimDickenson | sometimes owner->chan_list.next does not have the channel I am interested in |
| 20:43.00 | JimDickenson | After the dial I have a userevent that sends DIALSTATUS but I need finer control |
| 20:43.30 | pabelanger | WALLOFTEXT |
| 20:43.47 | JimDickenson | the above code is from handle_response() |
| 20:46.48 | putnopvut | JimDickenson: owner->chan_list.next just simply points to the next channel in the list of channels that are globally in the system. It's not necessarily in any way related to owner. |
| 20:49.14 | JimDickenson | Is there anything available in handle_response() than can be used to tie back to the channel that did the dial command? |
| 20:52.25 | JimDickenson | The SIP Call-ID is that of the called leg but that is not available to me unless the call completes. I need to get the raw SIP value before the h extension for non-completed calls |
| 20:53.00 | putnopvut | Yeah, you can't get that since the calls are not bridged. The outbound call leg in the SIP code has no knowledge of the inbound leg. |
| 20:53.26 | putnopvut | I had mentioned Asterisk 11 before. It actually has a feature where you can get the technology-specific codes on outbound channels if you want. Let me find the wiki page about it. |
| 20:53.46 | putnopvut | https://wiki.asterisk.org/wiki/display/AST/Hangup+Cause |
| 23:06.46 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-aqydqcgljziadzow) |