| 00:17.17 | elguero | russellb: just curious about something I saw looking through the code, everything in chan_sip.c appears to now be using parse_uri_legacy_check, should the code added to support routing text messages outside of a call use that as well instead of just parse_uri? Line 23631 |
| 01:30.34 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 02:33.27 | *** join/#asterisk-dev Jamuel (~Adium@c-67-180-156-186.hsd1.ca.comcast.net) |
| 03:29.56 | *** join/#asterisk-dev guilhermebr (~Guilherme@177.17.218.125) |
| 03:58.54 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 03:58.54 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 05:12.43 | *** join/#asterisk-dev irroot (~irroot@dsl-185-122-118.dynamic.wa.co.za) |
| 06:56.29 | *** join/#asterisk-dev ehsanf (~ehsanf@177-54-222-209.mycybernet.net) |
| 07:08.04 | ehsanf | Howdy ... I am trying to update chan_gtalk to accept user/pass from Dial string directly rather than being fixed to the config file (and res_jabber as gtalk depends on it) ... anyone here working or has worked on the chan_gtalk and/or res_jabber modules? |
| 07:18.25 | irroot | http://skype-open-source.blogspot.com/2011/06/skype-protocol-reverse-engineered.html |
| 07:26.46 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 08:01.50 | *** join/#asterisk-dev hehol (~hehol@2001:1438:1009:200:847f:93f5:143e:ea3) |
| 09:12.06 | irroot | curse you svn .... guess i need to become more familiar with it |
| 10:05.46 | *** join/#asterisk-dev sgimeno (~chatzilla@163.117.206.10) |
| 11:17.02 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:17.02 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 11:30.05 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:30.05 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:34.19 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 12:34.19 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 12:34.44 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 12:34.44 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 12:55.33 | *** join/#asterisk-dev dms (~Adium@nat/digium/x-jxiruivcwatdybaa) |
| 13:18.46 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 13:23.27 | *** join/#asterisk-dev pabelanger (~pabelange@2607:f2c0:a000:166:beae:c5ff:fe3e:b315) |
| 13:23.27 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 13:24.15 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 13:30.08 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 13:32.12 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 13:37.28 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 13:39.43 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 14:02.53 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:02.53 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:16.01 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:16.01 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:20.42 | *** join/#asterisk-dev jhmichelle352 (~jhmichell@41.69.251.37) |
| 14:21.19 | jhmichelle352 | m18028 |
| 14:21.22 | MuffinMan | [confirmed] [Asterisk] Core/PBX 0018028: [patch] Exceptionally long queue length queuing to XXXXX reported by alecdavis https://issues.asterisk.org/view.php?id=18028 |
| 14:21.39 | *** part/#asterisk-dev dms (~Adium@nat/digium/x-jxiruivcwatdybaa) |
| 14:22.45 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:22.45 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:24.05 | jhmichelle352 | is there anyone here intersted in is 18028 |
| 14:24.11 | jhmichelle352 | *issue ? |
| 14:25.20 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 14:26.48 | *** join/#asterisk-dev Corydon76-home (peuce@c-69-137-80-31.hsd1.tn.comcast.net) |
| 14:26.48 | *** mode/#asterisk-dev [+o Corydon76-home] by ChanServ |
| 14:40.02 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 14:47.18 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 15:01.01 | *** join/#asterisk-dev irroot (~irroot@197.173.111.75) |
| 15:11.22 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 15:20.49 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:34.21 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:34.21 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:37.49 | *** join/#asterisk-dev i_eat_children (~chatzilla@firewall-a.buf.ny.i-evolve.net) |
| 15:40.48 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 15:40.48 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 15:50.21 | *** join/#asterisk-dev rgagnon (~rgagnon@99-185-128-25.lightspeed.austtx.sbcglobal.net) |
| 15:50.39 | *** part/#asterisk-dev rgagnon (~rgagnon@99-185-128-25.lightspeed.austtx.sbcglobal.net) |
| 16:02.37 | *** join/#asterisk-dev irroot (~irroot@197.105.171.224) |
| 16:14.47 | irroot | put up latest t38gw patch including work added by mnicholson |
| 17:17.26 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@nc-67-232-27-41.dhcp.embarqhsd.net) |
| 17:21.49 | *** join/#asterisk-dev irroot (~irroot@197.108.123.224) |
| 17:29.10 | *** join/#asterisk-dev bbryant (~brett@74.222.125.175) |
| 17:29.10 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 17:55.17 | *** join/#asterisk-dev malcolmd_ (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 17:55.17 | *** mode/#asterisk-dev [+o malcolmd_] by ChanServ |
| 17:59.35 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 17:59.35 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 18:21.34 | *** join/#asterisk-dev irroot (~irroot@197.170.179.72) |
| 19:59.54 | *** join/#asterisk-dev paravoid (~paravoid@zebra.cslab.ece.ntua.gr) |
| 20:13.36 | Kobaz | aww |
| 20:13.48 | Kobaz | something made moh shoe clases crash |
| 20:17.17 | kpfleming | umm... what? |
| 20:17.24 | Kobaz | moh show classes |
| 20:17.44 | Kobaz | http://pastebin.ca/2074251 |
| 20:17.46 | Kobaz | 1.8 svn |
| 20:17.59 | Kobaz | i reran with valgrind and i can't reproduce it though |
| 20:22.19 | *** join/#asterisk-dev Devon_ (~chatzilla@63.214.236.169) |
| 20:51.28 | russellb | Kobaz: what was the result of those timerfd patches you were testing? |
| 20:51.40 | Kobaz | it fixes the crashes |
| 20:51.46 | russellb | lockups you mean? |
| 20:51.50 | Kobaz | we |
| 20:51.51 | Kobaz | er |
| 20:51.57 | Kobaz | yeah deadlocks not crashes |
| 20:52.22 | russellb | k, we need to get that merged |
| 20:52.24 | Kobaz | but there's some odd side effects, like channels dont get hung up right away when the timer gets read without events pending |
| 20:52.31 | Kobaz | okay, i can do that |
| 20:52.46 | russellb | hmm ... I guess that's better than locking up the whole application |
| 20:52.50 | Kobaz | it's definitly a major improvement, since asterisk is still functional |
| 20:52.50 | Kobaz | yes |
| 20:52.55 | russellb | do they get hung up eventually? |
| 20:52.58 | Kobaz | yeah they do |
| 20:53.09 | russellb | ok, so not as terrible then |
| 20:53.15 | jhmichelle352 | m18028 |
| 20:53.18 | MuffinMan | [confirmed] [Asterisk] Core/PBX 0018028: [patch] Exceptionally long queue length queuing to XXXXX reported by alecdavis https://issues.asterisk.org/view.php?id=18028 |
| 20:53.30 | russellb | Kobaz: maybe post the resulting patch on reviewboard and I'll ack it? |
| 20:53.32 | Kobaz | i have a patch that's a combination of the two related issues |
| 20:53.35 | Kobaz | okay |
| 20:53.40 | russellb | awesome |
| 20:54.32 | Kobaz | so official move to jira |
| 20:54.39 | Kobaz | so everything is all working? |
| 20:55.33 | russellb | the core parts are working yes :-) |
| 20:55.44 | russellb | no svnbot equivalent, so we'll have to manually close issues for now |
| 20:56.34 | Kobaz | ah |
| 20:56.56 | russellb | and I still haven't updated reviewboard ... :-/ |
| 20:57.01 | Kobaz | aw |
| 20:57.04 | russellb | it does auth against the mantis database right now |
| 20:57.10 | Kobaz | anything new and exciting in the new revireboard |
| 20:57.31 | russellb | and so new users won't be able to use reviewboard until i figure out how to make it authenticate against the new auth service |
| 21:01.00 | Kobaz | aw |
| 21:01.02 | Kobaz | poor new users |
| 21:01.21 | russellb | just means i need to fix it asap ... |
| 21:11.29 | Kobaz | https://reviewboard.asterisk.org/r/1255/ |
| 21:15.36 | russellb | leifmadsen: you around? |
| 21:17.30 | russellb | Kobaz: note posted |
| 21:18.37 | Kobaz | k |
| 21:18.58 | Kobaz | commit to 1,8 and merge to trunk? |
| 21:19.09 | Kobaz | this stuff is all new to 1.8 i think, no timerfd in 1.6.2 that i remember |
| 21:19.11 | russellb | yup (assuming you change log messages) |
| 21:19.17 | russellb | hmm, let me check |
| 21:19.37 | russellb | timerfd is in 1.6.2 |
| 21:19.41 | russellb | might as well merge it there |
| 21:19.53 | Kobaz | oh |
| 21:19.54 | Kobaz | okay then |
| 21:19.59 | Kobaz | i thought i remember it being new |
| 21:20.12 | russellb | thanks, Kobaz ! |
| 21:20.21 | Kobaz | welcome welcome |
| 21:24.22 | jhmichelle352 | kobaz is this fix for issue 18028 |
| 21:24.24 | MuffinMan | [confirmed] [Asterisk] Core/PBX 0018028: [patch] Exceptionally long queue length queuing to XXXXX reported by alecdavis https://issues.asterisk.org/view.php?id=18028 |
| 21:24.28 | jhmichelle352 | ? |
| 21:24.57 | Kobaz | yes |
| 21:25.03 | jhmichelle352 | wow |
| 21:25.25 | jhmichelle352 | so what was the problem exactly from an architecture stand point? |
| 21:25.46 | Kobaz | something is waiting on a timer that was never set |
| 21:25.57 | Kobaz | so it waits forever since there's nothing that's going to trigger the timer |
| 21:26.21 | jhmichelle352 | and this causes the exceptionally long queue to be spewed and the the max transmit also |
| 21:26.25 | Kobaz | either that or the timer was set, something else got the event, and there's an extra timer check that shouldn't happen |
| 21:26.42 | Kobaz | it causes a deadlock in the channels, which causes all kinds of chaos |
| 21:26.54 | Kobaz | breaks just about everything |
| 21:27.36 | jhmichelle352 | i will try it right away on a production system, i actually got so feedup with it that i removed the entire block of removinig frames in channel.c |
| 21:28.06 | jhmichelle352 | this part i removed AST_LIST_TRAVERSE_SAFE_BEGIN(&chan->readq, cur, frame_list) { |
| 21:28.06 | jhmichelle352 | /* Save the most recent frame */ |
| 21:28.07 | jhmichelle352 | if (!AST_LIST_NEXT(cur, frame_list)) { |
| 21:28.07 | jhmichelle352 | break; |
| 21:28.07 | jhmichelle352 | } else if (cur->frametype == AST_FRAME_VOICE || cur->frametype == AST_FRAME_VIDEO || cur->frametype == AST_FRAME_NULL) { |
| 21:28.07 | jhmichelle352 | if (++count > 64) { |
| 21:28.07 | jhmichelle352 | break; |
| 21:28.07 | jhmichelle352 | } |
| 21:28.08 | jhmichelle352 | AST_LIST_REMOVE_CURRENT(frame_list); |
| 21:28.08 | jhmichelle352 | ast_frfree(cur); |
| 21:28.09 | jhmichelle352 | } |
| 21:29.26 | jhmichelle352 | kobaz: will there be a patch for 1.6 |
| 21:29.46 | jhmichelle352 | 1.6.2.18 is what i am using |
| 21:30.02 | jhmichelle352 | i can actually report finding right away? |
| 21:30.14 | Kobaz | russellb: i like using #ifdef AST_DEV_MODE |
| 21:30.28 | Kobaz | is there a dev mode in 1.6.2? |
| 21:31.20 | jhmichelle352 | i don't know |
| 21:31.41 | jhmichelle352 | i download the latest version that's it :) |
| 21:32.13 | Kobaz | that was a question for russel |
| 21:32.29 | jhmichelle352 | lol , sorry :) |
| 21:32.32 | Kobaz | i guess i'll have to check out 1.6l.2 |
| 21:32.36 | Kobaz | 1.6.2 |
| 21:34.42 | jhmichelle352 | kobaz the change is only to res_timing_timerfd.c right ? so that i can manually change the code in the production sytem till the patch is out |
| 21:36.19 | Kobaz | yeah |
| 21:37.04 | jhmichelle352 | kobaz: and it's the same for 1.6 as for 1.8 i mean no more checks will be needed |
| 21:44.56 | russellb | Kobaz: yeah, dev-mode is there |
| 21:45.52 | russellb | it's AST_DEVMODE |
| 21:46.06 | russellb | when you do ./configure --enable-dev-mode |
| 21:46.13 | russellb | you'll get that defined in include/asterisk/buildopts.h |
| 21:46.40 | Kobaz | yeah |
| 21:46.46 | russellb | well how about this ... if AST_DEVMODE, ERROR/WARNING, else ast_debug() |
| 21:46.47 | Kobaz | i used it briefly to fix the thing from bamboo |
| 21:46.54 | Kobaz | ah okay, yeah that sounds good |
| 21:46.58 | russellb | cool |
| 21:47.01 | Kobaz | btw, i never got an email from bamboo |
| 21:47.32 | russellb | pabelanger is your man for bamboo issues |
| 21:47.48 | Kobaz | k |
| 22:13.27 | jhmichelle352 | kobaz: i implemented the patch in a production system now and i report findings right away |
| 22:13.34 | jhmichelle352 | *will |
| 22:15.06 | jhmichelle352 | by the way i commented out the warning so that they don't take cpu time |
| 22:19.30 | jhmichelle352 | kobaz: ping |
| 22:45.59 | jhmichelle352 | kobaz: ping |
| 22:55.29 | *** join/#asterisk-dev eugeneoden (~goden@99-62-173-93.lightspeed.austtx.sbcglobal.net) |
| 23:07.05 | Kobaz | pong |
| 23:07.09 | Kobaz | was eating dinner |
| 23:07.17 | jhmichelle352 | sire no prb |
| 23:07.20 | jhmichelle352 | *sure |
| 23:07.26 | jhmichelle352 | i tested the patch |
| 23:07.36 | jhmichelle352 | i still get locked channels |
| 23:07.48 | Kobaz | noo |
| 23:08.08 | Kobaz | well it fixes some stuff |
| 23:08.14 | Kobaz | pastebin core show locks |
| 23:08.24 | Kobaz | be back in a sec |
| 23:08.57 | jhmichelle352 | sure |
| 23:11.15 | Kobaz | k |
| 23:11.21 | Kobaz | do you have debug threads turned on |
| 23:11.25 | jhmichelle352 | yup |
| 23:11.45 | jhmichelle352 | i will also acknoledge one more thing in a second |
| 23:12.37 | Kobaz | what does core show locks show |
| 23:13.27 | jhmichelle352 | 3 locks , just a sec i am doing pastbin now |
| 23:15.45 | jhmichelle352 | http://pastebin.com/iDHcqHw7 |
| 23:16.43 | jhmichelle352 | kobaz: also as i reported in the tracker of issue 18028 the max retries to host xxx goes forever after the call is hungup |
| 23:16.45 | MuffinMan | [confirmed] [Asterisk] Core/PBX 0018028: [patch] Exceptionally long queue length queuing to XXXXX reported by alecdavis https://issues.asterisk.org/view.php?id=18028 |
| 23:16.53 | Kobaz | this is a different bug |
| 23:17.07 | jhmichelle352 | ??? |
| 23:17.24 | jhmichelle352 | please ignore the first 3 locks |
| 23:17.32 | jhmichelle352 | there are internal to our channel |
| 23:17.34 | Kobaz | the timerfd fix, fixes a different bug than what you're showing in the locks |
| 23:17.58 | jhmichelle352 | i thought it fix's the exceptionally long queue on iax |
| 23:18.07 | Kobaz | if it was the timerfd bug, you sould see locks in res_timer_timerfd |
| 23:18.20 | Kobaz | well, that message will show up due to a number of reasons |
| 23:18.22 | Kobaz | it fixes one of them |
| 23:18.25 | Kobaz | sadly not yours :( |
| 23:18.30 | jhmichelle352 | :) |
| 23:18.40 | jhmichelle352 | good work anyway |
| 23:18.53 | Kobaz | thanks, i'm mostly investivating and testing, i didn't write the patch |
| 23:18.58 | Kobaz | i combined two peoples patches into one |
| 23:19.20 | Kobaz | the patch fixes a definite problem, if you are using timerfd instead of dahdi |
| 23:19.32 | Kobaz | but your issu comes from a different bug |
| 23:20.23 | jhmichelle352 | i am actually using timerfd and even sometimes i get an error from timer fd but that crash's the system totally, but it's very rare and i think it's dueto something in our module |
| 23:21.00 | jhmichelle352 | anyway, do you happen to know what causes max retries acts madly like that |
| 23:21.19 | jhmichelle352 | i mean in the protocol rfc it's specified only 4 times |
| 23:23.00 | Kobaz | well, if something is taking much longer than asteirsk expects, then frames will build up in queue |
| 23:23.45 | jhmichelle352 | yup, but after the call is teared down from the callee it should stop retransmitting |
| 23:24.37 | Kobaz | unless there continues to be a deadlock |
| 23:24.47 | Kobaz | and channels dont tear down properly and are left still processing stuff |
| 23:24.53 | jhmichelle352 | exactly |
| 23:25.19 | jhmichelle352 | is there some way that i can destroy a channel , what deadlocks was there? |
| 23:25.26 | jhmichelle352 | *ever |
| 23:25.30 | Kobaz | no |
| 23:25.58 | Kobaz | the only way for a channel thread to go away is for it to finish |
| 23:26.17 | Kobaz | it's not a process, like say apache where you can kill a misbehaving process |
| 23:26.50 | Kobaz | you can send a kill to the pthread |
| 23:26.59 | Kobaz | but that's rife with undefined behavior |
| 23:27.09 | Kobaz | only the thread that got a lock can unlock it |
| 23:27.21 | jhmichelle352 | yup |
| 23:27.42 | jhmichelle352 | i was only asking because in pthread you can set the thread to have the canel flag |
| 23:27.51 | jhmichelle352 | *cancel flag |
| 23:28.11 | Kobaz | yeah but it still has to finish what it's doing, or get out of it somehow |
| 23:29.53 | jhmichelle352 | okay , i have a question why does a deadlock apears even if you are using a trylock |
| 23:30.06 | jhmichelle352 | i only saw this behaviour when i started dealing with asterisk |
| 23:30.23 | Kobaz | simple programs are locking shared memory or something like that |
| 23:30.31 | Kobaz | so you trylock, wait, trylock, get the lock. unlock, done |
| 23:30.38 | Kobaz | deadlock is unlikly |
| 23:31.04 | Kobaz | with ast's many many many shared resources, and lots of locks deadlocks can easily happen |
| 23:31.15 | Kobaz | really common deadlock scenerio: |
| 23:31.26 | Kobaz | channel A locks A |
| 23:31.30 | Kobaz | channel B locks B |
| 23:31.44 | Kobaz | channel A trys to lock B, but can't since channel B has it |
| 23:31.53 | Kobaz | channel B trys to lock A, but can't since channel A has it |
| 23:32.04 | Kobaz | neither channel will finish processing because each is waiting for the other |
| 23:32.18 | Kobaz | so, locking order becomes very critical |
| 23:32.58 | Kobaz | it you define the locking order to be, always lock A, and then B, you will avoid that deadlock condition |
| 23:33.14 | jhmichelle352 | great on that example ast_write tries to lock 10 time then if it fails it returns why does a deadlock happen here even when locking fails |
| 23:33.47 | Kobaz | because it's doing something else afterwards, and still holding a lock |
| 23:34.50 | jhmichelle352 | ahh , so the problem is after the the trylock and core show locks shows where the lock was acquired not failed right? |
| 23:35.32 | Kobaz | core show locks will show you two things |
| 23:35.39 | Kobaz | where the lock was aquired, and what locks are waiting |
| 23:36.23 | jhmichelle352 | that demystifies alot :) |
| 23:36.46 | jhmichelle352 | thanks kobaz |
| 23:37.18 | Kobaz | yeah it's not really clear at first when looking at all the lock stuff, as to what is going on |
| 23:37.47 | jhmichelle352 | actually now the core show locks makes sense |
| 23:38.15 | Kobaz | so somewhere in ast_write, it's processing, and doing something |
| 23:38.17 | Kobaz | or maybe just waiting |
| 23:38.22 | Kobaz | and not releaseing a lock |
| 23:38.43 | jhmichelle352 | i actually spotted part of the problem just a sec |
| 23:39.32 | Kobaz | oo |
| 23:40.50 | jhmichelle352 | why does the same thread that acquired the lock has to unlock it? |
| 23:42.20 | Kobaz | it's the way pthreads works |
| 23:44.26 | jhmichelle352 | yeah, If a thread attempts to unlock a mutex that it has not locked or a mutex which is unlocked, undefined behavior results |
| 23:45.43 | Kobaz | you can do it, but yeah it's bad, and unportable |
| 23:46.40 | jhmichelle352 | well, i think the only way to hunt this problem down is by debugging ast write -> ast_log |
| 23:46.58 | Kobaz | sounds good |
| 23:48.52 | jhmichelle352 | i will start working on it right away |
| 23:51.34 | Kobaz | see if you can reduce your dialplan to something that still causes the problem |
| 23:51.47 | Kobaz | have a repeatable process that triggers the bug |
| 23:54.24 | jhmichelle352 | sure , i am using a modified freepbx dialplan without the gui, but i will strip it down from all the bells and wessels. but i also think that bandwidth plays a major factor here , which makes reproducibility hard |
| 23:54.56 | Kobaz | so it could be a race condition |
| 23:55.54 | jhmichelle352 | i will check for that too |
| 23:56.53 | Kobaz | if it's a race condition, something may be moving on too soon |
| 23:56.59 | Kobaz | ie: a lock should be grabbed before processing |
| 23:58.18 | jhmichelle352 | i suspected ast_queue_hangup need a lock before proccessing but the documentation says it doesn't so i will have to check for that inside ast_write |
| 23:59.02 | *** join/#asterisk-dev moy_ (~moy@bas5-toronto47-2925351284.dsl.bell.ca) |