| 00:00.14 | knightr | $["${__REVERSAL_REJECT}"="TRUE" & "${CHANNEL(reversecharge)}"="1" ]?macro-hangupcall) |
| 00:00.22 | knightr | oops |
| 00:00.27 | knightr | $["${__REVERSAL_REJECT}"="TRUE" & "${CHANNEL(reversecharge)}"="1" ] |
| 00:00.55 | file | so, dialplan |
| 00:01.11 | knightr | channel(reversecharge) should not be evaluated if __REVERSAL_REJECT is not true.. |
| 00:01.27 | knightr | sorry, I am just trying to help figuring out this problem |
| 00:01.52 | knightr | I barely know anything about coding directly in Asterisk language... |
| 00:02.22 | knightr | so I didn't know how to answer your question... |
| 00:03.06 | knightr | I am a programmer though and I have the problem so I am just trying to help the people that can actually fix this track down what is the cause... |
| 00:03.09 | file | I don't know dialplan to that degree and #asterisk or the asterisk-users mailing list would have a greater audience |
| 00:03.24 | knightr | I have asked the question multiple times there |
| 00:03.35 | knightr | at many times |
| 00:03.55 | knightr | and I was told to look at Asterisk code... |
| 00:04.05 | knightr | to find my answer... |
| 00:04.38 | knightr | It is most likely C or C++ which I am not that good at |
| 00:04.51 | knightr | and I doubt the parser is that easy to understand... |
| 00:05.22 | knightr | thank you for trying to help though... |
| 00:28.29 | snuff-work | knightr: maybe try using the ${EXISTS(<var>)} = 1 & the rest.. |
| 00:29.12 | snuff-work | then u should be able to avoid the error msg.. since exists will test if the variable has been set at all |
| 00:29.23 | knightr | snuff-work, thanks, I will try... |
| 00:29.56 | knightr | It really feels like Asterisk doesn't do lazy evaluation though... |
| 00:30.37 | knightr | because in the latest test |
| 00:30.42 | snuff-work | i thought ur problem was that your 1st variable does not 'exist' therefore is generating a parse error ? |
| 00:30.46 | snuff-work | when eval |
| 00:30.51 | knightr | nope... |
| 00:31.01 | knightr | latest test has this before |
| 00:31.11 | knightr | let me paste the line, one sec.. |
| 00:31.31 | knightr | __REVERSAL_REJECT=FALSE |
| 00:31.44 | knightr | just before the test that fails.. |
| 00:32.03 | knightr | so if __REVERSAL_REJECT is defined... |
| 00:32.21 | knightr | then why does this fail with "reversecharge" not being defined? |
| 00:32.27 | knightr | $["${__REVERSAL_REJECT}"="TRUE" & "${CHANNEL(reversecharge)}"="1" ] |
| 00:32.45 | knightr | that's why I thought Asterisk might not do lazy evaluation... |
| 00:33.20 | snuff-work | well.. i've re-read it.. since your using quotes.. shouldn't matter if var doesn't exist (at least on left) |
| 00:33.32 | snuff-work | since it would eval to "" = "1" |
| 00:33.40 | knightr | I tried making sense of the code that parses this but it's a little too much for me (I am not very good in C or C++) |
| 00:33.41 | snuff-work | and fail |
| 00:33.52 | knightr | the only thing I can think of when looking at that code |
| 00:34.08 | knightr | is that it looks like it's trying to figure out if the operands are compatible it seems |
| 00:34.25 | knightr | and maybe that's why it tried to evaluate "reversecharge" |
| 00:34.32 | knightr | but then I barely understand that code... |
| 00:34.47 | knightr | theorically you are right... |
| 00:34.49 | snuff-work | pastebin.. the lines around the code.. and the error you see |
| 00:35.04 | knightr | but I see this: |
| 00:35.26 | knightr | [2015-09-08 19:34:42] WARNING[8049][C-00000536]: func_channel.c:596 func_channel_read: Unknown or unavailable item requested: 'reversecharge' |
| 00:35.50 | knightr | and that is just after the set __REVERSAL_REJECT=FALSE... |
| 00:37.41 | knightr | this is the line preceding that error: Executing [1235551212@from-trunk:9] Set("SIP/Voipms-0000002", "__REVERSAL_REJECT=FALSE") in new stack |
| 00:38.02 | snuff-work | yes.. but your issue is with http://cplonline.com.au/dell-200gb-ssd-sas-12gpbs-2-5in-hp-hdd-13g-400-aflw.html |
| 00:38.04 | snuff-work | oops |
| 00:38.16 | snuff-work | your issue is with ${CHANNEL(reversecharge)} |
| 00:39.12 | snuff-work | and that 'error' is just it can't find the vaule |
| 00:40.21 | snuff-work | don't see that being a big issue |
| 00:43.28 | knightr | I have a problem with a hard drive? |
| 00:43.30 | knightr | ;-) ;-) ;-) |
| 00:44.40 | knightr | people keep on complaining about it though, I had kinda made my peace with it but I am not alone and people keep on talking about it over and over again... |
| 00:45.07 | snuff-work | its just a 'warning' stating the the channel variable doesn't exist |
| 00:45.15 | knightr | I know... |
| 00:45.33 | snuff-work | so.. if u really didn't want the msg about it not existing.. |
| 00:45.45 | knightr | I wonder why they didn't define it for all channels and not just for PRI though.. |
| 00:46.04 | snuff-work | goto.. func_channel.c:596 and disable the warning for 'non existant' |
| 00:46.06 | snuff-work | =) |
| 00:46.19 | knightr | ROTFL... |
| 00:46.46 | snuff-work | well.. SIP has no idea of 'reversecharge' where ISDN etc does |
| 00:47.14 | knightr | apparently there were discussions about adding it to SIP |
| 00:47.15 | snuff-work | so.. another way would be to check the channel type being queried.. BEFORE doing the 'reversecharge' check |
| 00:47.24 | knightr | which never gave any result |
| 00:47.31 | knightr | at least that's what I was told... |
| 00:47.41 | snuff-work | so it should only fire when ISDN/PRI type |
| 00:48.10 | knightr | but if the problem is that Asterisk doesn't do lazy eval |
| 00:48.16 | knightr | or do some sort of pre-eval |
| 00:48.30 | snuff-work | mm.. *writes test* |
| 00:48.42 | knightr | then even putting that test on the left side of the "&" will generate that warning, no? |
| 00:49.12 | *** join/#asterisk-dev Synthase_ (uid63346@gateway/web/irccloud.com/x-kycituexobrifcuv) |
| 00:52.51 | knightr | nice SSD by the way, a little costly though... |
| 00:53.16 | snuff-work | well.. its a 'dell' branded so they are going to be at least 2-3x |
| 00:53.21 | snuff-work | a normal ssd |
| 00:53.24 | snuff-work | plus its SAS |
| 00:53.28 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:43d:101:862b:2bff:fead:2cce) |
| 00:53.31 | knightr | no s... |
| 00:54.46 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 00:54.47 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 00:55.49 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:199:4200:d92e:7495:8599:22b:a004) |
| 00:56.36 | knightr | oops, you are right, I had not noticed... |
| 01:00.05 | snuff-work | ok.. i see what your getting at.. |
| 01:00.55 | snuff-work | my best guess.. is that yes.. we do not do lazy eval.. which i thought was the case.. |
| 01:01.03 | snuff-work | so.. in order to 'combat' that.. |
| 01:01.24 | snuff-work | break your thing into 2 lines instead of one combined.. |
| 01:01.25 | snuff-work | =) |
| 01:04.05 | WIMPy | So there's an option for a little performance boost. |
| 01:05.02 | knightr | snuff-work, thank you! |
| 01:05.30 | knightr | thought so because there isn't any other way to explain it as far as I can see.. |
| 01:05.55 | knightr | and I thought the same about needing to put it on those separate lines |
| 01:06.16 | snuff-work | looking at the function for comparison.. its very basic.. |
| 01:07.37 | knightr | but I know very little about Asterisk language so I would have a hard time doing it, I am just trying to help debug it but I won't be the one fixing it... |
| 01:08.00 | snuff-work | but i'm prob missing something else.. as by the time it gets to like a goto if.. each side has already been 'parsed' and values retrieved |
| 01:08.17 | knightr | is it in ast_expr.cc? |
| 01:08.29 | knightr | that's where it seemed to be |
| 01:08.58 | knightr | but I am not very good in C/C++... |
| 01:09.18 | knightr | if it's there it looks like it checks if the operands are compatible |
| 01:09.34 | knightr | could it be that which cause it to evaluate the operands anyway? |
| 01:11.02 | snuff-work | no idea.. i avoid this sort of stuff.. try to do things on the fringes =) |
| 01:12.00 | knightr | LOL... |
| 01:12.39 | knightr | was that the right source file though, did I find the right one (ast_expr.cc)? |
| 01:12.57 | snuff-work | can't even tell u that.. |
| 01:13.08 | knightr | no problem, thank you... |
| 01:14.08 | knightr | thank you for your help, I feel much better now that someone who knows Asterisk a looooooot better than I do think that Asterisk most likely doesn't do lazy evaluation.. |
| 01:19.23 | knightr | snuff-work, how does one check for channel type, I am going to try modifying that code... |
| 01:19.51 | knightr | if the channel type is not the right one, I will try some sort of goto (or maybe an inline if it that work) over it... |
| 01:21.14 | knightr | my guess is something like "${CHANNEL(type)" = "THE_RIGHT_CHANNEL_TYPE) ? |
| 01:24.29 | knightr | looks like it's "${CHANNEL(channeltype)}", I just need to find out which channel type reversecharge applied to.. |
| 01:26.25 | snuff-work | yep |
| 01:27.08 | knightr | thank you! |
| 01:27.31 | knightr | I wish I had that kind of hardware, I only have SIP and DAHDI here... |
| 01:27.58 | knightr | so I can't test if it will actually work.. |
| 01:28.08 | knightr | when it should that is... |
| 01:28.15 | snuff-work | well even if u make it 2 if's.. |
| 01:28.30 | snuff-work | so see if the __REVERSE_CHARGE is set |
| 01:28.50 | snuff-work | if that is false.. jump somewhere else.. |
| 01:29.13 | snuff-work | or do your 2nd test in the next if of ${CHANNEL(reversecharge)} |
| 01:29.33 | snuff-work | so your likely to see a lot 'less' of the message saying it doesn't exist |
| 01:30.13 | knightr | thing is |
| 01:30.45 | knightr | __REVERSE_CHARGE should theorically not be settable when the channel type is not the right one... |
| 01:30.50 | knightr | but you are right... |
| 01:31.13 | knightr | no need to evaluate the channel stuff if __REVERSE_CHARGE is false... |
| 01:31.22 | snuff-work | =) |
| 01:31.47 | knightr | thank you very much for your help! |
| 01:31.53 | snuff-work | np |
| 01:35.45 | knightr | Goodnight and take care snuff! time for me to prepare to go to sleep... |
| 01:35.54 | snuff-work | almost midday here |
| 01:36.19 | knightr | 9:35 pm here... |
| 01:36.41 | knightr | (Canada) |
| 01:37.13 | knightr | and there are quite a few things I need to take care of before I go to sleep... |
| 01:37.23 | knightr | oops |
| 01:37.29 | knightr | I wanted to say Goodbye |
| 01:37.37 | knightr | and not Goodnight |
| 01:37.43 | knightr | sorrrrrrrry... |
| 01:38.03 | knightr | I usually know better than to assume people are in the same timezone as I am... |
| 01:39.03 | knightr | I have friends for which it's very early in the morning right now so I tend to think about this... |
| 01:39.20 | knightr | Goodbye, take care! |
| 01:39.43 | snuff-work | nite |
| 01:39.50 | knightr | Thank you! |
| 01:40.34 | *** part/#asterisk-dev knightr (~Nicolas@mythtv/developer/knightr) |
| 03:34.03 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 03:34.03 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 04:57.50 | *** join/#asterisk-dev oej (~oej@2001:718:1001:110:a52c:bdfd:7099:237) |
| 04:57.50 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 05:32.44 | *** join/#asterisk-dev oej (~oej@2001:718:1001:110:a52c:bdfd:7099:237) |
| 05:32.44 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:35.15 | *** join/#asterisk-dev babak (uid19622@gateway/web/irccloud.com/x-ogrgidvztwexdyac) |
| 06:54.35 | *** join/#asterisk-dev oej (~oej@2001:718:1001:110:cd4e:d337:e351:fd76) |
| 06:54.35 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 07:01.30 | *** join/#asterisk-dev pchero_work (~pchero@109.70.54.56) |
| 07:07.33 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:07.33 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:57.33 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:50.07 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 12:24.45 | *** join/#asterisk-dev n8ideas (~n8ideas@l136.denver.dsl.forethought.net) |
| 12:30.56 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:28.57 | *** join/#asterisk-dev oej (~oej@92.61.95.218) |
| 13:28.57 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:35.14 | *** join/#asterisk-dev oej (~oej@2001:718:1001:110:2c36:7944:58b4:4ef1) |
| 13:35.14 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 13:39.41 | *** join/#asterisk-dev oej (~oej@92.61.95.218) |
| 13:39.41 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:06.52 | wdoekes | anyone around who has a clue about app_chanspy and locking therein? I've ran into a deadlock (ast 11.16) where it's trying to get a channels lock, while it already has a channel locked (according to pthread_mutex_t->owner). and it locks with someone else who (properly) locks the channels list first before locking individual channels |
| 14:08.07 | *** join/#asterisk-dev oej (~oej@eduroam-230-129.vsb.cz) |
| 14:08.07 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:10.01 | *** join/#asterisk-dev oej (~oej@2001:718:1001:110:51f5:c66d:e6e7:1794) |
| 14:10.02 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 14:10.16 | wdoekes | for instance, in channel_cpy(), some accesses to chan involve a ast_channel_lock/unlock pair, and others don't. I fail to see why |
| 14:13.10 | wdoekes | similarly, start_spying(internal_bridge_autochan..) gets ->chan locked, while, start_spying(spyee_autochan..) doesn't |
| 14:15.46 | *** join/#asterisk-dev n8ideas (~n8ideas@63.225.29.167) |
| 14:17.17 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-ldvkqyrqjrmlcqxm) |
| 14:18.23 | wdoekes | (the locked channel is a zombied Local one btw) |
| 14:23.36 | *** join/#asterisk-dev putnopvut (putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:23.36 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:37.54 | wdoekes | putnopvut: you wouldn't happen to have a clue about locking madness in app_chanspy? it appears it causes an occasional deadlock by holding a lock before attempting to lock the channels list. but I don't see any missing unlock()s. I do however see lots of unlocked accesses to chan. |
| 14:40.21 | putnopvut | wdoekes: Unfortunately I haven't worked closely with app_chanspy in a long time. Do you know which lock is being held while attempting to lock the channels list? |
| 14:41.01 | wdoekes | looking at a zombie Local channel |
| 14:41.56 | wdoekes | it was a call set up through AMI, which was probably being spied upon. I see no verbose messages from the spying thread though |
| 14:42.57 | wdoekes | shortly after the call got set up, asterisk locked up. and I got spammed with Exceptionally long voice queue length queuing to |
| 14:43.29 | wdoekes | s/asterisk/the main sip thread/ (but that's because it quickly locks on the channels list as well) |
| 14:46.13 | wdoekes | http://fpaste.org/265223/ <-- asterisk 11.16, with clean app_chanspy.c. thread 7 wants to get the channels list, thread 61 wants to get that Local zombie channel |
| 14:55.38 | wdoekes | as for the AMI/Originate'd call, it was the Local-part of a A-leg that was answering/answered. the last message from the LWP 24662 was: Local/IDxxx@osvpi_route_phoneaccount-00081df2;1 answered Local/512@osvpi_account_call_int_permitted-00081df1;2 -- where it appears that the channel name of the locked channel is "Local/IDxxx@osvpi_route_phoneaccount-00081df2;1<ZOMBIE>" |
| 14:57.05 | wdoekes | and as for my questions about locks. I see for instance start_spying(internal_bridge_autochan..) with a surrounding lock, while start_spying(spyee_autochan..) has no such lock. and there a more cases where I don't see why one of the access to chan is locked and the other is not |
| 14:57.19 | wdoekes | *are |
| 15:18.46 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-yeitrkczrclzskgb) |
| 15:19.59 | *** join/#asterisk-dev n8ideas (~n8ideas@50-206-225-4-static.hfc.comcastbusiness.net) |
| 15:34.36 | *** join/#asterisk-dev benasse (~benasse@nowhere.cicogna.fr) |
| 15:49.20 | *** join/#asterisk-dev mjordan (mjordan@nat/digium/x-iyqtblhkrnpuoakl) |
| 15:49.20 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 16:09.19 | *** join/#asterisk-dev superscrat (asanders@nat/digium/x-bjsipagjpaliqtak) |
| 18:06.11 | *** join/#asterisk-dev zerohalo (~zerohalo@2601:199:4200:d92e:c4a5:6efc:28a0:b5d9) |
| 18:25.10 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-gmmlwyjtbyqbsnki) |
| 19:30.43 | *** join/#asterisk-dev leedm777 (leedm777@nat/digium/x-yexrndlnuikyqxps) |
| 20:04.36 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-179-40-172.cust.bezeqint.net) |
| 20:04.36 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 21:55.22 | *** join/#asterisk-dev [TK]D-Fender (~joe@64.235.216.2) |
| 21:55.38 | *** join/#asterisk-dev ctb (ctb@2600:3c01::f03c:91ff:fe93:711b) |
| 22:47.32 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-ldvkqyrqjrmlcqxm) |
| 23:26.05 | *** join/#asterisk-dev elguero (~miguel323@2001:470:1f06:12c4::2) |
| 23:52.37 | *** join/#asterisk-dev superscrat (~asanders@173-21-89-217.client.mchsi.com) |
| 23:59.24 | superscrat | hello, file. |
| 23:59.30 | file | moo |