| 01:19.58 | *** join/#asterisk-dev mpe (~mpe@65.161.206.209) |
| 02:23.30 | *** join/#asterisk-dev mpe (~mpe@65.161.206.209) |
| 02:49.03 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 02:49.08 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 03:47.28 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-34-115-128.ptld.qwest.net) |
| 06:17.00 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |
| 06:18.30 | *** join/#asterisk-dev oej (~olle@2001:470:1f15:d79:225:ff:fe44:74ec) |
| 06:18.30 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 06:20.00 | *** join/#asterisk-dev ahowlader (howlader@180.234.36.10) |
| 06:21.54 | *** join/#asterisk-dev Corydon76-dig (white@c-69-137-80-31.hsd1.tn.comcast.net) |
| 06:21.54 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 06:45.08 | *** join/#asterisk-dev Corydon76-dig (eleven@c-69-137-80-31.hsd1.tn.comcast.net) |
| 06:45.08 | *** mode/#asterisk-dev [+o Corydon76-dig] by ChanServ |
| 06:54.47 | *** join/#asterisk-dev lftsy (~lftsy@install.deckpoint.ch) |
| 08:07.47 | *** join/#asterisk-dev tiny_D (~tiny_D@mail.snom.com) |
| 08:20.00 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 09:16.46 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/developer/jpeeler) |
| 09:16.46 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 09:17.17 | *** join/#asterisk-dev angler (~angler@pdpc/sponsor/digium/angler) |
| 09:17.24 | *** join/#asterisk-dev mnicholson (~mnicholso@nat/digium/x-wtuxztwjowtzurzn) |
| 09:24.04 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 09:24.04 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 11:00.40 | *** join/#asterisk-dev schmidts (~schmidts@lmlo.sil.at) |
| 11:00.44 | schmidts | hello all |
| 11:25.51 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:25.51 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:31.27 | *** join/#asterisk-dev Pitel (~pitel@ip-94-113-20-150.net.upcbroadband.cz) |
| 11:31.49 | Pitel | help! how to sue mergefrom to merger commit from 1.8 branch to trunk? |
| 11:33.38 | russellb | Pitel: hi :-) |
| 11:34.04 | russellb | $ svn co http://svn.digium.com/svn/repotools ; cd repotools ; sudo make install |
| 11:34.15 | russellb | then, in trunk .... cd trunk ; merge8trunk <revision> |
| 11:34.15 | Pitel | yup, I did that |
| 11:34.21 | russellb | where <revision> is the commit to 1.8 |
| 11:35.31 | russellb | On a slightly different note, please always compile Asterisk by running ./configure with --enable-dev-mode |
| 11:35.31 | Pitel | thanks :) |
| 11:35.37 | russellb | http://bamboo.asterisk.org/browse/AST-18-179/ |
| 11:36.36 | Pitel | oh, ok, will solve that after lunch :) |
| 11:36.47 | russellb | and my last thing to bug you about is the commit message. for a review, format it as ... Review: http://reviewboard.asterisk.org/r/<reviewnumber>/ |
| 11:36.49 | russellb | http://www.asterisk.org/doxygen/trunk/CommitMessages.html |
| 11:37.28 | russellb | with my nit picking out of the way ... welcome to the commit club, and thank you for your contributions to Asterisk! |
| 11:39.30 | schmidts | i have a question about the reviewboard |
| 11:39.45 | schmidts | i want to paste a patch into it and allways get this error |
| 11:39.51 | schmidts | Unable to parse diff revision header '2010-09-03 11:08:10.000000000 +0000' |
| 11:40.42 | russellb | how are you posting it |
| 11:41.03 | schmidts | repository: asterisk |
| 11:41.11 | russellb | ah, so the web interface |
| 11:41.17 | schmidts | basedirectory: svn.digium.com/svn/asterisk/branches/1.6.2/ |
| 11:41.27 | schmidts | yes |
| 11:41.51 | russellb | the web interface is a bit painful (as compared to post-review) |
| 11:41.53 | russellb | http://www.asterisk.org/doxygen/trunk/Reviewboard.html |
| 11:43.04 | schmidts | i will try this |
| 11:43.07 | schmidts | thanks russel |
| 11:43.08 | russellb | k |
| 11:43.10 | russellb | np |
| 11:46.08 | schmidts | ok i know what i ?ve done wrong, just using diff instead of snv diff ;) |
| 11:46.26 | russellb | perhaps |
| 11:46.46 | russellb | in general, if you want to use the web interface to post patches, fine, but you're on your own |
| 11:47.02 | russellb | but i will always help anyone having trouble with post-review |
| 11:47.33 | schmidts | thx ;) |
| 11:49.57 | schmidts | ok posting it via the web interface now gives me the error The file 'svn.digium.com/svn/asterisk/branches/1.6.2/channels/chan_sip.c' (r284848) could not be found in the repository |
| 11:50.13 | schmidts | and as described in the reviewboard.html i didnt have a post-review script |
| 11:50.55 | russellb | install python-setuptools ... then $ sudo easy_install -U RBTools |
| 11:51.49 | russellb | but anyway, hint, your base path is wrong ... should be branches/1.6.2/.... |
| 11:52.01 | russellb | or just branches/1.6.2 probably |
| 11:52.15 | schmidts | ok |
| 11:52.50 | schmidts | i worked in the webif with the right base path |
| 11:52.52 | schmidts | thx |
| 11:55.37 | russellb | you're welcome ... i guess :-p |
| 12:06.42 | schmidts | what groups or people i have to add in a review request? |
| 12:07.10 | schmidts | group asterisk-dev ? |
| 12:07.21 | russellb | yes |
| 12:07.27 | russellb | let me fix your account up real quick ... |
| 12:11.35 | schmidts | my first reviewrequest *proud* :D |
| 12:16.38 | russellb | \o/ |
| 12:16.42 | russellb | I will look today :-) |
| 12:16.54 | schmidts | :D |
| 12:17.12 | russellb | and then I'll say ... OMG WHAT DID YOU DO |
| 12:17.27 | russellb | just kidding ;-) |
| 12:17.56 | schmidts | i hope you will say this, after trying the impact of this patch in subscribe handling |
| 12:18.05 | russellb | haha.. |
| 12:18.40 | russellb | this is great timing, we can still sneak performance improvements into the 1.8 branch |
| 12:18.53 | russellb | our release policy is that we don't make changes like that to existing releases though :-/ |
| 12:19.12 | russellb | unless the severity is such that it could almost be considered a bug |
| 12:19.23 | russellb | which may be the case here, heh |
| 12:19.38 | schmidts | it causes a deadlock situation so i would say its bug |
| 12:19.44 | russellb | oh, well then yes |
| 12:19.56 | russellb | (I haven't looked ... I just assumed it was a performance thing) |
| 12:20.02 | schmidts | not deadlock at all but atleast a long lock |
| 12:20.24 | schmidts | it is a performance thing ;) |
| 12:21.54 | russellb | oh dear |
| 12:21.59 | russellb | that code does seem odd |
| 12:22.15 | russellb | why not just let it expire like every other dialog? |
| 12:22.23 | schmidts | i hope you mean that part i have removed? |
| 12:22.24 | russellb | (I guess that's what you're proposing here) :-) |
| 12:22.27 | russellb | yes |
| 12:22.37 | russellb | i'm agreeing that the code is unnecessary and wrong and stupid and .... |
| 12:22.46 | schmidts | thats exactly what olle said yesterday :D |
| 12:23.27 | russellb | and could even have the potential of removing something it shouldn't |
| 12:23.29 | russellb | badness |
| 12:24.02 | russellb | ship it! |
| 12:24.19 | russellb | now you need commit access - send an email to jpeeler@digium.com requesting a svn certificate |
| 12:25.44 | schmidts | will do |
| 12:25.46 | schmidts | thank you |
| 12:26.06 | russellb | apologies for the paste bomb coming, but to save a step, here is the info he's going to ask you for: |
| 12:26.10 | russellb | 1) proper name |
| 12:26.10 | russellb | 2) Company name or other affiliation, if any |
| 12:26.10 | russellb | 3) Email address |
| 12:26.11 | russellb | 4) Desired 'nickname' for your Subversion account |
| 12:26.11 | russellb | 5) Location (city, state/province, country) where you reside or will |
| 12:26.11 | russellb | primarily be committing from |
| 12:26.13 | russellb | 6) Desired passphrase (password) for the certificate; you can |
| 12:26.17 | russellb | communicate this to me via the secure means of your choice |
| 12:26.19 | russellb | (GPG-encrypted email, for example (my key is on pgp.mit.edu)) |
| 12:27.28 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 12:27.28 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 12:30.20 | schmidts | i have asked for his pgp key, if this wont work i will send it to you |
| 12:32.16 | russellb | k |
| 12:36.32 | schmidts | outch, restarting asterisk with 20k peers in astdb would cause much network traffic, have to remeber this for next time |
| 12:38.22 | kpfleming | schmidts: there are other parts of chan_sip that stagger the outbound traffic at startup... that may be necessary for your stuff too |
| 12:41.21 | *** join/#asterisk-dev oej (~olle@2001:470:1f15:d79:225:ff:fe44:74ec) |
| 12:41.21 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 12:42.16 | schmidts | i dont think we would run 20k peers on a production system in future, it just had forgotten that my testsystem was running since yesterday |
| 12:42.47 | schmidts | and after restart asterisk sends an option package to everyone, but the problem might be it sends a package to every peer at once |
| 12:44.43 | kpfleming | right. for outbound registrations at startup, they are staggered by a random amount (up to five seconds i think) so that they don't happen all at once |
| 12:45.06 | kpfleming | actually, that's qualify pings, i think |
| 12:45.13 | kpfleming | so that's very close to what you are doing |
| 12:50.53 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 12:50.53 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 12:51.12 | Pitel | russellb: well, now I commited fix for my C90 fail, but when I try to merge it to trunk, it says svnmerge: "." has local modifications; it must be clean (I didn;t commited the previous merge, because I want to commit working version if possible) |
| 12:51.35 | russellb | Pitel: ok. first revert everything from trunk: $ svn revert -R . |
| 12:51.48 | russellb | then, merge _both_ revisions at once by doing ... $ merge8trunk <rev1>,<rev2> |
| 12:53.08 | russellb | then, ??? ... Profit! |
| 12:53.11 | Pitel | thanks, seems it's working |
| 12:53.14 | russellb | cool. |
| 12:53.15 | Pitel | :) |
| 12:53.18 | snuff-home | mmm.. finally figured out what was wrong with my enum.. needed to be bit more 'specific' in my naptr construction |
| 12:53.28 | russellb | snuff-home: yay :-) |
| 12:54.17 | snuff-home | best thing is.. jtodd made a good set of tests on the original issue 8089 |
| 12:54.20 | MuffinMan | [closed] [Asterisk] Functions/NewFeature 0008089: [patch] The record# parameter in ENUMLOOKUP is ignored reported by otmar https://issues.asterisk.org/view.php?id=8089 |
| 12:54.35 | snuff-home | so even less work.. i almost feel bad |
| 12:55.29 | snuff-home | first i stole func_srv test.. now stealing jtodd's extensions test from that enum issue |
| 12:55.41 | russellb | don't feel bad - that's working smart :-) |
| 12:56.06 | russellb | it's a compliment to copy from them |
| 12:56.35 | snuff-home | now if i was a real dev.. i would have completed this all within a day.. but i'm such a hack these days :) |
| 12:57.06 | russellb | nah, it's very helpful, no matter how long it takes |
| 13:04.27 | snuff-home | issues not getting any smaller.. need some more love from new devs |
| 13:04.50 | russellb | Pitel: http://bamboo.asterisk.org/browse/AST-FREEBSDTRUNK-187/ |
| 13:05.04 | russellb | Pitel: strdupa() is Linux specific. Use ast_strdupa() instead |
| 13:05.19 | Pitel | argh! ok :) |
| 13:05.41 | russellb | Also, if you create an account on there and associate it with your svn account, it will email you when a build breaks from your commit ;-) |
| 13:08.18 | russellb | <3 bamboo.asterisk.org |
| 13:08.20 | Pitel | Ok, it will be useful :) |
| 13:13.09 | Pitel | bamboo indeed looks like a cool thing |
| 13:16.48 | russellb | it's unfortunately very unhappy this week |
| 13:16.54 | russellb | we have some tests to fix up ... |
| 13:17.07 | schmidts | bamboo is a mail bomber :D |
| 13:17.23 | russellb | yup |
| 13:17.34 | russellb | only when stuff is broken, though |
| 13:18.47 | schmidts | i have a fundemantal question about the astdb->sync |
| 13:19.09 | schmidts | is it really necessary to sync every change to the disk? |
| 13:20.39 | schmidts | i thought about using a scheduler (which?) to sync it to disk every minute, but i just know the sip scheduler which wouldnt be the right place for this |
| 13:21.34 | russellb | depends how important people think it is to keep registration data saved off in case asterisk has to restart ... |
| 13:22.17 | *** join/#asterisk-dev otherwiseguy (~terry@cpe-75-87-99-1.kc.res.rr.com) |
| 13:22.19 | russellb | i would think it's less critical for chan_sip |
| 13:22.28 | russellb | but much more important in the case of using it from the dialplan |
| 13:22.39 | russellb | just like any other database, data integrity is pretty darn important. |
| 13:23.06 | schmidts | full ack ;) |
| 13:23.33 | russellb | worst case for chan_sip, calls can't be delivered until the registration is refreshed ... |
| 13:23.49 | schmidts | yes |
| 13:23.59 | russellb | which could be bad if registrations are spaced out enough, i guess |
| 13:24.22 | russellb | I guess I don't know the answer to that - that's for people like you that use it to decide :-) |
| 13:25.24 | schmidts | in my case (> 3000 peers) i would say, i want a runngin system, maybe if 50 peers are unreachable for an hour i could live with this |
| 13:26.44 | schmidts | others wouldnt think so |
| 13:27.52 | schmidts | i will have a look at the dialplan database use, maybe its easy to build a way to tell the ast_db function if its necessary to save immediatly or just wait for the scheduler |
| 13:29.13 | schmidts | i have my testsystem running with astdb->sync completly turned off, just sync on delete or update but i allready had a situation where i had to delete the astdb out of the spool directory to restart asterisk |
| 13:29.15 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 13:30.21 | snuff-home | mm.. wasn't there someone already proposing a 'ast_db' shim.. so u could use whatever u wanted to be ast_db.. memcache.. mysql.. sqlite etc.. |
| 13:31.47 | schmidts | olle opened an issue but i think this was something different |
| 13:32.05 | oej | What's up? |
| 13:32.59 | schmidts | https://issues.asterisk.org/view.php?id=17681 |
| 13:33.21 | schmidts | we are talking about the need for any astdb function to sync every change to disk |
| 13:33.30 | oej | Can't we hand it off to another thread optionally? |
| 13:33.34 | oej | Like we do with CDR batching. |
| 13:33.42 | oej | I think that would make sense in a larger system. |
| 13:34.01 | oej | Just focus on SIP regs and queue them up for a separate thread to save and then send the response back |
| 13:35.24 | schmidts | this could cause many register retransmits or is a 100 trying ok for a register packet? |
| 13:36.10 | oej | 100 trying is just a message saying "stop retransmitting, I'm working on it." |
| 13:36.19 | oej | What you want is send 200 OK without waiting for astdb |
| 13:36.31 | oej | Look at cdr.conf where we have an option to run in "batch mode" |
| 13:36.40 | oej | basically, hand over the record to store to another thread |
| 13:36.45 | oej | and assume it works out |
| 13:37.13 | russellb | handing it to another thread doesn't alleviate the load |
| 13:37.27 | russellb | the load is still there, and likely worse since you've introduced more context switching required to get the job done |
| 13:37.36 | russellb | to make it better, the number of syncs needs to be reduced |
| 13:38.28 | oej | Can't we fix that if we batch handle it? |
| 13:38.38 | oej | This has to be optional |
| 13:38.51 | oej | In some cases, I don't want to send 200 OK until it's on disk. |
| 13:39.57 | schmidts | maybe the default batch=no option like in cdr.conf would be the right for this too |
| 13:40.07 | russellb | well the particular issue isn't even fixable in chan_sip, regardless of when or where you do do a write to astdb, the internals of the astdb API are syncing to disk on every write |
| 13:40.45 | russellb | maybe someone should make it possible to put astdb into a different database, perhaps through the realtime API, so that a higher performance database could be used |
| 13:40.46 | russellb | haha |
| 13:40.50 | russellb | ;-) oej |
| 13:41.06 | snuff-home | astdb = evilness on solaris in a compiling sense sparc inparticular.. but another matter :) |
| 13:41.49 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-145.cablep.bezeqint.net) |
| 13:41.49 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 13:43.44 | snuff-home | speaking about context switches.. i was looking over stuff to do with node.js... interesting project |
| 13:44.31 | schmidts | astdb->sync uses the unix sync or fsync? |
| 13:45.07 | snuff-home | astdb = sqlite v2 + patches i recall.. |
| 13:46.56 | russellb | db1 |
| 13:47.17 | russellb | it calls mpool_sync ... |
| 13:47.47 | russellb | keeps looking |
| 13:47.49 | russellb | fsync() it is |
| 13:48.04 | schmidts | ok maybe we could try fdatasync instead |
| 13:48.05 | russellb | main/db1-ast/mpool/mpool.c - mpool_sync() |
| 13:48.14 | schmidts | http://linux.die.net/man/2/fdatasync |
| 13:49.06 | schmidts | i will try it ;) |
| 13:50.24 | schmidts | ok still slow :( |
| 13:50.41 | russellb | nods |
| 13:50.57 | schmidts | needs around 10ms on every sync counting up pending on the size of astdb |
| 13:52.16 | schmidts | i will try to copy the cdr batch structure to use with astdb and try the speed of this |
| 13:52.42 | schmidts | the problem with chan_sip.c or atleast every channel the time sync needs, no packages are read |
| 13:52.53 | sruffell | is the public mirror for DAHDI still out of date? |
| 13:53.07 | russellb | sruffell: not to my knowlege |
| 13:53.19 | oej | hmm. Astdb over realtime. If someone could do that. Right. |
| 13:53.36 | oej | No one volounteered to help me with the missing function calls. |
| 13:53.45 | oej | Everything works, but not everything from the cli. |
| 13:54.02 | sruffell | russellb: I'm still getting "No such revision 9293" when trying to create a reviewboard review. |
| 13:54.16 | russellb | sruffell: k, then nobody told me it was broken, heh |
| 13:54.37 | sruffell | oh...sorry......yeah...I didn't say anything to you about that specifically. |
| 13:55.46 | russellb | np, will fix now |
| 13:59.41 | russellb | sruffell: fixed |
| 13:59.47 | sruffell | many thanks! |
| 14:00.19 | *** join/#asterisk-dev Krafte (~andy@141.84.69.66) |
| 14:01.03 | russellb | and hopefully made so that it will break much less often on dahdi |
| 14:01.09 | russellb | (at the cost of your commits taking longer) |
| 14:05.09 | sruffell | cool |
| 14:05.18 | *** join/#asterisk-dev moy_ (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 14:06.08 | snuff-home | gets some zz's |
| 14:07.22 | Krafte | hello |
| 14:07.42 | Krafte | i made a rather large patch for chan_mobile |
| 14:07.50 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 14:08.10 | Krafte | now recieving sms does work with nearly all phones |
| 14:08.32 | Krafte | but i have a problem and a question |
| 14:10.05 | Krafte | i want to read a varialbe from the config but it gets truncated? |
| 14:11.01 | Krafte | if (!strcasecmp(v->name, "sms_charset")) {ast_copy_string(pvt->sms_charset, v->value, sizeof(v->value));} |
| 14:13.09 | schmidts | i am not sure, but wouldnt it be better like this: ast_copy_string(pvt->sms_charset, v->value, sizeof(pvt-sms_charset)); |
| 14:13.51 | schmidts | the size checks if you have enough space in the target, not to copy the whole string |
| 14:14.23 | russellb | schmidts is correct |
| 14:14.37 | Krafte | i'll try |
| 14:15.51 | schmidts | but this would still truncate the string if its too large for the target |
| 14:20.25 | Krafte | ok i see my error... it works thanks |
| 14:21.01 | Krafte | ok now the questions were to commit the patch? |
| 14:21.45 | schmidts | as russel just told me today, i would say: http://www.asterisk.org/doxygen/trunk/Reviewboard.html |
| 14:31.06 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:31.06 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:33.09 | anonymouz666 | kpfleming: I think I backported (right) to 1.4 the feature you wrote to disable the ECHOCAN from dialplan. Well... it compiles... let's see now if It works |
| 14:33.25 | kpfleming | nice |
| 14:36.20 | *** join/#asterisk-dev eliel (~eliels@201.234.94.226) |
| 14:36.20 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 14:47.01 | *** join/#asterisk-dev bbryant (~brett@c-76-26-221-79.hsd1.sc.comcast.net) |
| 14:47.01 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 14:49.17 | Kobaz | jpeeler: poke |
| 14:49.30 | jpeeler | Kobaz: hi |
| 14:49.35 | Kobaz | jpeeler: i found out what's sucking up 100% cpu randomly in asterisk |
| 14:49.37 | Kobaz | it's autoservice |
| 14:49.38 | |Rain| | wheeee, 373 deadlocked threads |
| 14:49.46 | Kobaz | your lwp patch is quite wonderful |
| 14:50.01 | Kobaz | so... the next question... is why is autoservice going nuts |
| 14:50.12 | Kobaz | that could be related to this error: |
| 14:50.17 | Kobaz | [Sep 2 16:22:12] ERROR[1862]: app_dial.c:1901 dial_exec_full: Could not stop autoservice on calling channel |
| 14:51.14 | jpeeler | quite possibly, i'm glad the patch helped but i don't think i can help you any further at this point |
| 14:51.20 | Kobaz | heh, k |
| 14:52.03 | jpeeler | your bugs are usually complicated though, so breaking down the steps to reproduce locally makes things much much easier |
| 14:52.14 | Kobaz | yeah |
| 14:52.33 | Kobaz | i'll try and reproduce it in the dev box |
| 14:54.30 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 14:55.20 | |Rain| | hrm, I have a feeling a deadlock in __ao2_iterator_next shouldn't happen :E it looks like the only thing that pokes astobj2->priv_data.lock is ao2 internally |
| 14:56.53 | schmidts | yes, but if something has a lock on the next object you will get a deadlock on the iterator_next |
| 15:01.48 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 15:05.05 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:11.47 | Kobaz | hmm |
| 15:12.11 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 15:14.05 | schmidts | cya all on monday and have a nice weekend |
| 15:14.22 | *** join/#asterisk-dev ybit (~quassel@unaffiliated/ybit) |
| 15:18.37 | Kobaz | this autoservice stop function is really strange |
| 15:19.41 | Kobaz | apparently a result of 0 is success... but if the channel has not been removed succesfully from the autoservice use count, then it returns 0? |
| 15:19.56 | Kobaz | everything seems all backwards |
| 15:20.18 | Kobaz | at the softhangup check too... if the channel is not in softhangup, return 0... i would think that should be a failure |
| 15:25.10 | Kobaz | the way autoservice is written, it looks like a huge cpu hog waiting to happen (which it is). it's checking various conditions and then doing a continue with no sleeps, on a mostly infinite loop |
| 15:30.25 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@97-120-38-198.ptld.qwest.net) |
| 15:31.01 | kpfleming | the 'sleep' is calling poll() on all the channels it is providing service for |
| 15:33.40 | russellb | virtually every loop in asterisk for doing channel processing sleeps on ast_waitfor*() |
| 15:34.01 | russellb | ast_waitfor() / ast_read() / process frame / continue |
| 15:37.01 | *** join/#asterisk-dev marv (~timr@router.asteriasgi.com) |
| 16:22.24 | *** join/#asterisk-dev CunningPike (~CunningPi@204.239.12.183) |
| 16:29.53 | *** join/#asterisk-dev bbryant (~brett@c-76-26-221-79.hsd1.sc.comcast.net) |
| 16:29.53 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 16:33.16 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@97-120-29-164.ptld.qwest.net) |
| 16:35.23 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:35.23 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 16:53.58 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 16:57.34 | Kobaz | kpfleming: russellb: oh hmm... well somehow it's looping like nuts and sucking 100% cpu |
| 16:59.12 | Kobaz | [Sep 3 12:59:01] ERROR[7375]: app_dial.c:1901 dial_exec_full: Could not stop autoservice on calling channel |
| 16:59.24 | Kobaz | as soon as i get that error... cpu usage goes up |
| 16:59.54 | *** join/#asterisk-dev erinspice (~erin@207.98.195.107) |
| 17:10.28 | *** join/#asterisk-dev mpe (~mpe@65.161.206.209) |
| 17:14.36 | *** join/#asterisk-dev Netgeeks (~chris@gw1.netgeeks.net) |
| 17:21.15 | *** join/#asterisk-dev sgimeno (~chatzilla@95.122.12.192) |
| 17:26.55 | *** join/#asterisk-dev ahowlader (howlader@180.234.33.62) |
| 17:54.08 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-148.cablep.bezeqint.net) |
| 17:54.09 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 17:56.53 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 17:56.53 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 18:05.32 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:05.32 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 18:14.26 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:14.26 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 18:48.32 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:48.32 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 18:53.46 | *** join/#asterisk-dev mpe (~mpe@65.161.206.209) |
| 19:16.37 | *** join/#asterisk-dev hugorebelo (~hugo@bd219fe4.virtua.com.br) |
| 19:48.30 | *** join/#asterisk-dev bbryant (~brett@c-76-26-221-79.hsd1.sc.comcast.net) |
| 19:48.30 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 19:53.27 | |Rain| | who wants to help me debug a deadlock? :P |
| 19:54.04 | |Rain| | or has everyone's brain, like mine, already gone on vacation? |
| 19:56.00 | *** join/#asterisk-dev otherwiseguy (~terry@cpe-75-87-99-1.kc.res.rr.com) |
| 19:59.59 | russellb | |Rain|: build with DEBUG_THREADS, run "core show locks" |
| 20:00.03 | russellb | it practically debugs itself :-) |
| 20:01.08 | |Rain| | well |
| 20:01.14 | |Rain| | I've found where the deadlock is |
| 20:01.33 | |Rain| | so that's a start |
| 20:04.33 | |Rain| | I have ast_do_masquerade() holding a channel lock and calling queue_transfer_fixup which wants to get a queue lock while, in another thread, app_queue's end_bridge_callback is holding a queue lock and trying to get a channel lock to set a variable |
| 20:05.36 | |Rain| | what I don't know is how to approach fixing it or why it makes my head hurt |
| 20:11.32 | *** join/#asterisk-dev bbryant (~brett@c-76-26-221-79.hsd1.sc.comcast.net) |
| 20:11.32 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 20:15.03 | *** join/#asterisk-dev otherwiseguy (~terry@cpe-75-87-99-1.kc.res.rr.com) |
| 20:16.58 | *** join/#asterisk-dev otherwiseguy (~terry@75.87.99.1) |
| 20:18.56 | *** join/#asterisk-dev Sipster (~Sipster@modemcable045.5-200-24.mc.videotron.ca) |
| 20:30.56 | *** join/#asterisk-dev CoderForLife (~Miranda@cpe-174-101-150-41.cinci.res.rr.com) |
| 20:34.23 | |Rain| | ast_do_masquerade locks clonechan, which is the channel end_bridge_callback is calling set_queue_variables on |
| 20:46.30 | |Rain| | ok, so attempting to word this more clearly: thread A locks the call_queue struct in app_queue's end_bridge_callback, which then calls set_queue_variables, which unsurprisingly calls pbx_builtin_setvar_multiple(). pbx_builtin_setvar_multiple locks the channel. meanwhile, thread B locks the channel struct (clonechan) in do_masquerade, then calls the fixup callback (queue_transfer_fixup), which calls update_queue() which wants to lock the queue struct |
| 20:46.52 | |Rain| | hopefully that's enough state for me to write a bug report on a day my brain is working better :) |
| 21:02.30 | *** join/#asterisk-dev ybit (~quassel@unaffiliated/ybit) |
| 21:27.48 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@63.64.154.89) |
| 21:34.21 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 21:34.21 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 22:01.44 | *** join/#asterisk-dev schreiber1337 (3f75ee02@gateway/web/freenode/ip.63.117.238.2) |
| 22:24.45 | *** join/#asterisk-dev mpe (~mpe@65.161.206.209) |
| 23:06.36 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 23:06.36 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 23:40.47 | *** join/#asterisk-dev tzafrir (~tzafrir@212.179.75.202) |
| 23:40.47 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 23:47.41 | *** join/#asterisk-dev moy_ (~moy@74.12.96.53) |
| 23:59.21 | *** join/#asterisk-dev ybit (~quassel@unaffiliated/ybit) |