| 00:01.02 | *** join/#asterisk-dev mnicholson (~mnicholso@nat/digium/x-gztymbqyuvflthaw) |
| 01:05.19 | *** join/#asterisk-dev JonathanRose (~jonathan@nat/digium/x-cljwgmeliwhwgmvv) |
| 02:11.18 | *** join/#asterisk-dev seraphie (~erin@207.98.195.107) |
| 03:05.18 | *** join/#asterisk-dev micols (~0x2AA7F64@rlogin.dk) |
| 05:08.29 | *** join/#asterisk-dev irroot (~irroot@41.54.221.196) |
| 05:53.54 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 05:53.56 | schmidts | good morning |
| 06:10.17 | Corydon76-home | Anybody else able to connect to origsvn? |
| 06:17.08 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@50-39-153-236.bvtn.or.frontiernet.net) |
| 06:18.27 | russellb | Corydon76-home: network seems to be going up and down over there |
| 06:19.33 | Corydon76-home | Ah |
| 06:46.15 | *** join/#asterisk-dev mnicholson (~mnicholso@nat/digium/x-yywknmbfbpsbdnvr) |
| 06:46.17 | *** join/#asterisk-dev JonathanRose (~jonathan@nat/digium/x-ybedqdtkozznnmrm) |
| 06:50.06 | *** join/#asterisk-dev bbryant (~brett@c-76-26-221-79.hsd1.sc.comcast.net) |
| 06:50.06 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 07:16.34 | *** join/#asterisk-dev irroot (~irroot@pbx.distrotech.co.za) |
| 07:20.22 | schmidts | wdoekes2 could you send me the gdb command to get the output and detach asterisk directly? |
| 07:20.45 | irroot | morrning |
| 07:21.14 | irroot | ideas gents have calls that show if i "core show channels" but are orphans after a call pickup |
| 07:21.32 | irroot | that fails |
| 07:21.36 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 07:24.40 | schmidts | wdoekes2 i just have seen your issue and i have the same problem :( #18136 |
| 07:27.53 | wdoekes2 | the one with -ex |
| 07:28.26 | wdoekes2 | schmidts: gdb `which asterisk` -p `pidof asterisk` -ex 'thread apply all bt' -ex 'thread apply all bt full' -ex detach -ex quit > tmp.txt |
| 07:29.21 | schmidts | thanks the detach and quit was the part i missed ;) |
| 07:41.49 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 07:41.49 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 07:43.55 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 07:44.33 | *** join/#asterisk-dev asterisk-learner (~chatzilla@193.227.170.247) |
| 08:25.17 | *** join/#asterisk-dev Ulrar (~quassel@2a01:e0b:1:136:62eb:69ff:fe8f:18a0) |
| 08:26.33 | Ulrar | Hello. I am developping a app module, for a custom dialplan. I need to set, in the module, a variable to be used in the dialplan. Is there a way to do that ? I know that is possible with the AGI, so I guess it is possible in a module too but I can't find how |
| 08:29.05 | asterisk-learner | Ulrar: yes, check this link : http://www.voip-info.org/wiki/view/Asterisk+cmd+Set |
| 08:30.04 | asterisk-learner | Oh sorry u need the opposite of that ? |
| 08:30.19 | Ulrar | asterisk-learner: I already tried to use Set() in my source but it is a undefined function |
| 08:30.29 | Ulrar | I mean, I need to set a variable in my C code |
| 08:30.55 | Ulrar | An then use it in my dialplan |
| 08:31.20 | schmidts | wdoekes2 thanks for the gdb, just had the deadlock again in 1.6.2.19 and my backtrace looks nearly the same like yours. handle_refer tries to do some indication and dies there :( |
| 08:33.03 | wdoekes2 | Ulrar: look at the other apps/functions.. pbx_set_variable_helper or something like that is what you're looking for |
| 08:34.14 | wdoekes2 | schmidts: good that I'm not the only one. I had the same hang on a different machine twice now too.. I've reverted that particular commit and am waiting for a new hang (which I think won't happen) |
| 08:35.04 | Ulrar | wdoekes2: Thanks. Can it be ast_variable_new ? Just did a "grep variable *" in apps and that's the only result (ast_variable_*) |
| 08:35.15 | asterisk-learner | Ulrar: like wdoekes said, pbx_set_variable_helper() is what u need, and if u need to read back the value in ur C code u use pbx_get_variable_helper() |
| 08:35.41 | asterisk-learner | but be sure to test for NULL when reading first time |
| 08:35.45 | wdoekes2 | (imho, this is sufficiently broken to warrant a 1.6.2.20) |
| 08:36.19 | Ulrar | Don't have any pbx_set in the directory, but I use asterisk 1.4 |
| 08:36.38 | schmidts | Ulrar pbx_builtin_setvar_helper |
| 08:37.05 | Ulrar | Ho, could be, thanks |
| 08:37.10 | Ulrar | I'll try that ! |
| 08:37.31 | schmidts | Ulrar http://www.asterisk.org/doxygen/asterisk1.4/pbx_8c.html#98c5425b90ec7c5e136a40f529170b1b |
| 08:38.10 | schmidts | and thats for the setvar: http://www.asterisk.org/doxygen/asterisk1.4/pbx_8c.html#c74f20f5a5f022a60fdf2db0dc84889c |
| 08:39.01 | Ulrar | Thank you, that's exactly what I was searching |
| 08:44.47 | schmidts | your welcome |
| 09:22.59 | kaii | AST18136 |
| 09:23.04 | kaii | M18136 |
| 09:23.15 | kaii | where's the bot? :( |
| 09:23.27 | irroot | ASTERISK-18136 |
| 09:23.50 | irroot | https://issues.asterisk.org/jira/browse/ASTERISK-18136 |
| 09:25.30 | kaii | found it already, but thx anyway. |
| 10:09.33 | *** join/#asterisk-dev kwk (~kleine@carbon.gonicus.de) |
| 11:36.25 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:36.25 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:55.33 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:55.33 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 11:59.41 | *** join/#asterisk-dev t_dot_zilla (~t_dot_zil@firewall-a.buf.ny.i-evolve.net) |
| 12:14.30 | Kobaz | hmm |
| 12:14.35 | Kobaz | i'm having problems with merge8trunk |
| 12:14.50 | Kobaz | i put rev 328593 into branch 1.8 and merge8trunk is complaining |
| 12:14.59 | Kobaz | $ merge8trunk 328593 |
| 12:14.59 | Kobaz | spawn /home/kobaz/projects/asterisk/repotools/bin/svnmerge.real merge -P branch-1.8-merged -B branch-1.8-blocked -f ../merge.msg -r 328593 |
| 12:15.02 | Kobaz | svnmerge: no integration info available |
| 12:15.03 | pabelanger | Kobaz: merge810 |
| 12:15.09 | Kobaz | ah |
| 12:15.11 | pabelanger | 1.8->1.10->trunk |
| 12:15.21 | Kobaz | ah okay |
| 12:17.35 | Kobaz | i did svn up in repotools, and i on't have a merge810 |
| 12:18.02 | leifmadsen | you have to still 'make install' |
| 12:18.06 | leifmadsen | ./configure && make install |
| 12:18.26 | Kobaz | yeah, did that |
| 12:20.07 | Kobaz | http://pastebin.com/FXA0L32a |
| 12:21.17 | Kobaz | markm {~/projects/asterisk/repotools/bin} kobaz$ ls merge* |
| 12:21.18 | Kobaz | merge24 merge46 merge68 merge8trunk mergedevtrunk mergefrom mergeinit mergerev |
| 12:21.37 | leifmadsen | make install looks like it failed due to permissions... |
| 12:21.44 | leifmadsen | line 56 |
| 12:21.58 | Kobaz | i did another one |
| 12:21.59 | Kobaz | as root |
| 12:22.02 | leifmadsen | oic |
| 12:22.07 | Kobaz | it's down a few lines |
| 12:22.41 | Kobaz | oooh |
| 12:22.43 | Kobaz | i see what happened |
| 12:22.49 | Kobaz | it changed my destination directory |
| 12:24.58 | Kobaz | okay... --prefix |
| 12:25.04 | Kobaz | i forgot about that.... all done |
| 12:41.37 | Kobaz | i'm having a problem merging 1.8 to 1.10 |
| 12:41.52 | Kobaz | er i mean. 1.10 to trunk |
| 12:41.55 | *** part/#asterisk-dev kwk (~kleine@carbon.gonicus.de) |
| 12:42.18 | Kobaz | r328609 merge went into 1.10 just fine |
| 12:45.01 | irroot | trunk will be 1.10 not sure there has been any branch yet ?? |
| 12:45.11 | Kobaz | getting a property conflict http://pastebin.com/0v0Qqzct |
| 12:45.26 | Kobaz | there is a 1.10 already in svn |
| 12:46.25 | irroot | oh okies :P |
| 12:46.29 | irroot | nice |
| 12:47.05 | irroot | missed it |
| 12:47.37 | Kobaz | i wonder what's making the conflict |
| 12:47.52 | Kobaz | i haven't changed any properties... i think it's a merge script issue |
| 12:49.39 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 12:49.39 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 12:49.50 | irroot | have you updated the repo tools |
| 12:49.52 | pabelanger | Kobaz: what does $ svn diff show |
| 12:50.36 | Kobaz | Modified: branch-1.10-merged - /branches/1.10:1-328075,328120,328162,328207,328247,328317,328329,328428-328429,328448,328451,328541 + /branches/1.10:1-328075,328120,328162,328207,328247,328317,328329,328428-328429,328448,328451,328541,328609 |
| 12:50.45 | Kobaz | er, that didn't paste well |
| 12:51.25 | Kobaz | http://pastebin.com/XSDNi6Wp |
| 12:54.04 | pabelanger | Kobaz: don't see anything wrong with the properly. Should be able to 'resolved' and move on |
| 12:54.09 | Kobaz | ah okay |
| 12:54.35 | Kobaz | yay |
| 13:03.18 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-wknagjugfugcbgwq) |
| 13:05.13 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 13:06.46 | Kobaz | UNIQUEID is already unique for a single server |
| 13:06.48 | Kobaz | er |
| 13:11.52 | *** join/#asterisk-dev bklang (~bklang@c-67-165-218-19.hsd1.co.comcast.net) |
| 13:17.37 | *** join/#asterisk-dev dms (~Adium@nat/digium/x-lpugzwiwtjiijlnf) |
| 13:21.06 | irroot | im having channels hang arround in the system after pickup |
| 13:21.22 | irroot | and cant kill em asterisk needs a restart |
| 13:22.41 | Kobaz | are you using res_timer_timerfd |
| 13:23.24 | irroot | nope |
| 13:24.18 | irroot | http://pastebin.com/FekJV4eA <- |
| 13:24.25 | irroot | anyone seen this ?? |
| 13:24.44 | irroot | rings / frames out 0 |
| 13:24.52 | irroot | no bridge |
| 13:26.14 | irroot | will track it down i will |
| 13:42.26 | kaii | irroot: trunk? or which version are you using. alec davis was working on such an issue, his patch went into 1.8.5.0 https://reviewboard.asterisk.org/r/1185/ |
| 13:43.04 | kaii | * was working on a related issue |
| 13:43.08 | irroot | its 1.8.5 |
| 13:43.19 | irroot | im looking @ it thx kaii |
| 13:44.52 | irroot | got those bits thx |
| 13:45.17 | *** join/#asterisk-dev Gugge (~gugge@46.30.120.1) |
| 13:52.01 | *** join/#asterisk-dev anonymouz666 (~anonymouz@187-28-37-118.poolip.RJO.embratel.net.br) |
| 14:01.54 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:01.54 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:06.00 | *** join/#asterisk-dev datachomper (~Adium@nat/digium/x-ililtbamvdofjcon) |
| 14:07.16 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:07.16 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:09.28 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-dbmrpylvtnoxtcvw) |
| 14:37.48 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 14:37.48 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:37.58 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 14:37.58 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:27.55 | *** join/#asterisk-dev irroot (~irroot@41.49.92.73) |
| 15:46.17 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 15:46.17 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 15:58.10 | Ulrar | Mh, what is the C equivalent of $AGI->setcallback(&handler) ? I'm making a module to replace a perl script, and can't find that. I guess I have to pass a function address to something ? |
| 16:00.27 | kpfleming | do you have an AGI library you are using? if not, you'll have to create it from scratch. |
| 16:06.40 | Ulrar | No, I want to make a C module instead of the perl script I currently have |
| 16:06.57 | Ulrar | perl scripts are way to slow |
| 16:07.01 | Ulrar | too* |
| 16:07.28 | Ulrar | So I search the C way to set the hungup callback |
| 16:07.52 | dms | Ulrar . . using fastagi, perl scripts are extremely fast |
| 16:08.17 | Ulrar | dms: I have big configurations files, in perl they need to be read at each call |
| 16:08.23 | Ulrar | Way slower than a C module |
| 16:08.45 | dms | why not use a database? |
| 16:09.02 | kpfleming | there is no 'callback', the callback function is provided by the Perl AGI library you are using |
| 16:09.15 | kpfleming | you will either need to find an AGI library for C, or write an equivalent yourself |
| 16:09.17 | Ulrar | It's not my scripts, and I'm realy bad in perl. C is good for me |
| 16:09.49 | Ulrar | Mh, I already converted some perl scripts and I had no needs of an AGI lib, it's strange |
| 16:10.11 | kpfleming | the $AGI thing you are using *is* an AGI library |
| 16:10.22 | Ulrar | There must be a way to define the function called at the call hungup |
| 16:10.29 | Ulrar | Yeah, in perl |
| 16:10.32 | kpfleming | no. AGI is a text interface. |
| 16:10.46 | kpfleming | using it from C requires reading/writing lines of text from the AGI handle, and parsing them. |
| 16:10.53 | dms | Ulrar, have you checked out the skeleton app . . instead of writing agi stuff in C, why not just create an app? |
| 16:10.56 | kpfleming | it's much lower level than using an AGI library. |
| 16:11.01 | dms | true |
| 16:11.13 | Ulrar | That's exactly what I am doing |
| 16:11.16 | Ulrar | I'm writting apps |
| 16:12.04 | Ulrar | The AGI module used to lunch script must have a way to call function when a call ends, I am just searching a way to do the same |
| 16:13.51 | dms | so, are you writing a C AGI app? or a C Asterisk app? |
| 16:14.07 | Ulrar | C asterisk app |
| 16:14.20 | Ulrar | A module, as I said |
| 16:14.22 | dms | that'll totally different than AGI |
| 16:14.26 | Ulrar | in apps/ directory |
| 16:14.30 | dms | s/that'll/that'll be/ |
| 16:14.40 | Ulrar | Yeah |
| 16:14.52 | Ulrar | That's what I said, I'm trying to convert a perl AGI script to a module |
| 16:15.03 | Ulrar | Not an C AGI |
| 16:15.08 | dms | just making sure |
| 16:17.27 | Ulrar | yeah. So, anyone know how I can set the function who will be called at a call hungup ? |
| 16:17.55 | Ulrar | I'll browse some more code tomorrow if not |
| 16:18.28 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:18.28 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 16:21.12 | dms | Ulrar . . there are several examples in various app sources . . just grep for hangup in the apps dir |
| 16:21.34 | dms | good luck in any case |
| 16:24.08 | Ulrar | I did grep that. Just find lots of hangup_all() and ast_hangup() mostly .. I'll search better tomorrow, may be I missed it |
| 16:27.41 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 16:38.25 | Corydon76-home | Ulrar: when during the hangup process do you want your function called? And for what purpose? |
| 16:39.45 | Corydon76-home | Is it just a resource cleanup function? Do you need to modify the CDR? Do you need to post a CDR? There are lots of different callbacks which can be used |
| 16:41.10 | kpfleming | in general, though, there isn't a C-level API that will allow you to do 2nd-party or 3rd-party call control like you can do with AGI and AMI |
| 16:42.54 | kpfleming | leifmadsen: reports on asterisk-users are that ASTERISK-18103 is a regression that occurred between 1.6.2.18 and 1.6.2.19. if that's the case, in my opinion it really should be addressed, not closed because it doesn't occur in 1.8. regressions are different from normal bugs. |
| 16:43.16 | russellb | agreed |
| 16:43.18 | leifmadsen | kpfleming: that's the Asterisk team leads decision |
| 16:43.59 | russellb | it is my opinion that fixes for major regressions are still fair game for 1.4 and 1.6.2 |
| 16:44.07 | russellb | don't want to leave something broken if we broke it right at the end |
| 16:44.21 | kpfleming | yeah, that was my thinking as well |
| 16:44.37 | russellb | I like your style |
| 16:44.51 | kpfleming | hey... maybe we should add a new severity level for issues: Regression |
| 16:45.23 | Qwell | kpfleming: I would +1 that, but that's "in" now, so not cool anymore. |
| 16:45.38 | Qwell | (read: I +1'd before it was cool) |
| 16:46.17 | russellb | Qwell: yeah, +1 is too mainstream now |
| 16:46.31 | kpfleming | it's even on the main google search results page now. lame. |
| 16:50.31 | Corydon76-home | kpfleming: that's an interesting position that ought to be sent to the mailing list. I've seen some regressions that I haven't bothered fixing in 1.6.2 because it's in maintenance mode. |
| 16:51.26 | russellb | it's one of those things that has to be evaluated on a case by case basis if someone thinks a particular regression is bad enough that it should be fixed |
| 16:51.26 | Corydon76-home | and given that not all developers are on IRC, it should be published there, so everybody is on the same page for regressions in maintenance branches |
| 16:51.50 | Corydon76-home | Okay |
| 17:06.54 | *** join/#asterisk-dev Micc_ (~Micc@c-98-232-41-66.hsd1.wa.comcast.net) |
| 17:07.16 | Micc_ | I need to hire a dev for the day to fix a lock problem we are having with 1.8.5.0 |
| 17:23.23 | irroot | Micc_ im looking at it everyone wish him luck :P |
| 17:28.13 | *** join/#asterisk-dev bklang (~bklang@c-67-165-218-19.hsd1.co.comcast.net) |
| 17:29.28 | mickecarlsson | totally agree on the ASTERISK-18103 |
| 17:29.36 | mickecarlsson | It is a bug |
| 17:29.59 | mickecarlsson | I have looked at three core dumps, all points to the same cause |
| 17:30.01 | irroot | micc_ handle_request_refer locking order problem the owner is not locked when it should be |
| 17:31.31 | irroot | when parking a call perhaps ?? |
| 17:38.57 | irroot | or transfer |
| 17:51.40 | mickecarlsson | leifmadsen here is a good backtrace for you re ASTERISK-18103: http://www.freepbx.org/forum/freepbx/installation/asterisk-core-dump |
| 17:52.11 | leifmadsen | mickecarlsson: it would best if that information was attached to the issue tracker |
| 17:52.17 | leifmadsen | I'm not going to look at it now, and the developers will need it |
| 17:52.26 | leifmadsen | linking somewhere offsite isn't really ideal |
| 17:52.29 | mickecarlsson | OK, can that be done despite it is closed? |
| 17:52.49 | leifmadsen | ASTERISK-18103 |
| 17:52.49 | mickecarlsson | is trying |
| 17:52.58 | leifmadsen | CaptainPants!!! where are you?! |
| 17:53.10 | leifmadsen | sorry, ping me in a few , I'm doing too many things at once right now |
| 17:53.10 | mickecarlsson | :-) |
| 17:55.31 | mickecarlsson | OK, I just added the bt to the ticket. I can dig up at least three more dumps provided by users running AsteriskNOW |
| 18:15.13 | irroot | Micc_ got a patch id like you to try .... |
| 18:18.32 | irroot | any one want to review a patch for a deadlock locking order problem in 1.8.5.0 ?? |
| 18:25.08 | irroot | Micc_ https://reviewboard.asterisk.org/r/1322/ |
| 18:58.13 | *** join/#asterisk-dev CaptainPants (~CaptainPa@nat/digium/x-twqyjdmmrdruwsyl) |
| 19:19.54 | JunK-Y | lo guys |
| 19:38.29 | Micc_ | this looks bad |
| 19:38.29 | Micc_ | [2011-07-18 12:25:18] ERROR[2986]: lock.c:407 __ast_pthread_mutex_unlock: chan_sip.c line 24584 (handle_request_do): mutex 'p->owner' freed more times than we've locked! |
| 19:41.19 | Kobaz | what version? |
| 19:41.34 | Micc_ | 1.8.5.0 |
| 19:41.45 | Micc_ | with irroot's patch. |
| 19:42.10 | Micc_ | getting some weirdness with my CLI too. not responding to some commands sometimes. |
| 19:42.52 | Kobaz | hmm |
| 19:42.53 | Micc_ | got a bunch of locks going on right now too. |
| 19:43.02 | Kobaz | can you run under valgrind? |
| 19:43.10 | Micc_ | but the server isn't stopping incoming calls. |
| 19:43.20 | Micc_ | what is valgrind? |
| 19:45.48 | Micc_ | http://pastebin.com/BcMNi5tM |
| 19:46.52 | Micc_ | this looks like the same problem as the one it was supposed to fix. |
| 19:49.06 | Micc_ | core show channels is not showing all my channels. |
| 19:49.23 | Micc_ | something is really wrong, but I guess I can't complain too much since the server is still running in this state. |
| 19:53.46 | Kobaz | valgrind is a runtime memory checker |
| 19:54.02 | Kobaz | nasty nasty locking problems can be caused by invalid writes and reads to memory |
| 19:54.50 | Micc_ | ok, how do I install that? |
| 19:55.03 | Micc_ | this is production system, will it slow it down much? |
| 19:55.10 | kpfleming | yes, a lot |
| 19:56.01 | Micc_ | I think I have to revert to 1.6.2.11 now. I've got multiple customers saying they are going to leave us now. |
| 19:57.43 | Micc_ | I'm so shaking right now I can't even think straight to decide what to do next. |
| 19:58.16 | Micc_ | I'm trying to unload features to stop parking since I suspect thats where the problem is, but its got a use count of 1 |
| 19:58.28 | Micc_ | is there any way I can disable parking? |
| 19:58.51 | Micc_ | parking not working I figure is better than dropped calls. |
| 19:59.03 | Kobaz | Micc_: if you don't need new features, don't upgrade production without having lots of in house testing |
| 19:59.07 | Kobaz | is my general theory |
| 19:59.15 | Kobaz | and that's with *any* piece of software |
| 19:59.31 | Micc_ | kobaz, we had to upgrade because 1.6.2.19 was locking up too, and we couldn't get support for that. |
| 19:59.36 | Kobaz | well, even if you do need new features, they should be tested too |
| 19:59.39 | Kobaz | oh |
| 19:59.42 | Kobaz | that's a problem |
| 19:59.48 | Micc_ | and I did my own testing pretty well. |
| 20:00.02 | Micc_ | but you know real world is never like testing. |
| 20:00.04 | Kobaz | yeah |
| 20:00.24 | Kobaz | i run into the same thing... i test in the lab and production breaks |
| 20:00.58 | Micc_ | I guess I'm gonna comment out everyones parking lots. |
| 20:01.12 | Micc_ | but the default lot might be used then, that could be worse. |
| 20:01.56 | Kobaz | your patch doesn't fix the problem entirely? |
| 20:02.15 | Kobaz | er, i mean iiroot's patch |
| 20:03.07 | Micc_ | I dunno, maybe it does, maybe the problem is different. |
| 20:03.18 | Micc_ | it seems worse. |
| 20:03.25 | Micc_ | but maybe its just a busier time of day. |
| 20:04.32 | Micc_ | default parkinglot extension is 700, but I use 700 as first extension for all my customers so they could be transfering to 700 when they mean another extension. |
| 20:04.56 | Micc_ | I set the default to 300 or 600 in features.conf but I still get one park extension registering with 700. |
| 20:05.54 | Micc_ | features show now only has 300, but the default 700 was in the output when I did features reload. |
| 20:07.20 | Micc_ | I never saw this error before irroot's patch. |
| 20:07.21 | Micc_ | lock.c: chan_sip.c line 24584 (handle_request_do): mutex 'p->owner' freed more times than we've locked! |
| 20:07.48 | Micc_ | I'm getting a few of them in my logs along with lock.c: chan_sip.c line 24584 (handle_request_do): Error releasing mutex: Operation not permitted |
| 20:08.20 | Micc_ | Seems like that could be causing other problems now. |
| 20:09.07 | Micc_ | Is anyone able to look at his patch and see how that would cause this new error? https://reviewboard.asterisk.org/r/1313/ |
| 20:10.57 | Micc_ | its still causing hangs too. had to restart the server again. |
| 20:12.14 | Micc_ | on a good note, it seems 1.8 has made t38 faxing a bit better. seems like i'm getting less errors. |
| 20:13.21 | kpfleming | it should be a lot better |
| 20:16.22 | Micc_ | I think the release mutex error might be happening when someone is parked. |
| 20:17.26 | Micc_ | the CLI shows a bit more detail than the log for some reason. lock.c:407 __ast_pthread_mutex_unlock: chan_sip.c line 24584 (handle_request_do): mutex 'p->owner' freed more times than we've locked! |
| 20:22.28 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
| 20:22.28 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 20:25.03 | Micc_ | wait, that reviewboard link was a different one. sorry, the one I'm having trouble with is this one https://reviewboard.asterisk.org/r/1322/ |
| 20:33.27 | Micc_ | maybe its happening when theres no more parking spots left. |
| 20:34.18 | Micc_ | or when it rings back to the device that parked it. |
| 20:34.40 | Kobaz | so, theres a bug starting in 1.4 with freeing datastores in app_dial |
| 20:34.52 | Kobaz | still merge to 1.6.2 ? |
| 20:35.00 | Kobaz | and then to 1.8 and then to 1.10 and then to trunk? |
| 20:35.31 | leifmadsen | Kobaz: you'll have to check with russellb because that would cause a new release |
| 20:35.39 | leifmadsen | (which we're not supporting) |
| 20:35.53 | Kobaz | okay, is 1.4 ended now? |
| 20:36.46 | Kobaz | hmm, doesn't 1.4 and 1.6.2 go till 2012? |
| 20:37.02 | Micc_ | Kobaz, thats only for security fixes. |
| 20:37.06 | Kobaz | oh right |
| 20:39.55 | leifmadsen | Kobaz: it's documented too :) https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions |
| 20:40.01 | Kobaz | yeah i just found that |
| 20:40.05 | Kobaz | i remember seeing that page |
| 20:40.28 | Kobaz | it's a very rare timing issue, i don't think it's a security issue |
| 20:40.39 | Kobaz | so it's safe to just throw this into 1.8 and up |
| 20:40.42 | leifmadsen | Kobaz: again, just clear it with russellb :) |
| 20:40.46 | Kobaz | okay sure |
| 20:40.47 | leifmadsen | or that |
| 20:40.56 | Kobaz | could always back merge? |
| 20:41.52 | leifmadsen | you could manage it outside of the main 1.4 repo and make it available under some unsupported branch or something? |
| 20:42.25 | Kobaz | that would work |
| 21:06.23 | Kobaz | do de do |
| 21:06.27 | Kobaz | on a roll.. closed three issues today |
| 21:07.09 | Micc_ | Kobaz, wanna work on mine now? :) |
| 21:07.20 | Kobaz | hehe |
| 21:08.28 | Kobaz | i don't really know sip all that well |
| 21:08.35 | Kobaz | I've played with transfers a little bit |
| 21:08.52 | Kobaz | irroot's patch looks good, but you said you're still having problems? |
| 21:10.41 | Micc_ | yeah, I removed his patch and I'm not getting the p->owner release error anymore. |
| 21:10.52 | Micc_ | His fix didn't stop it from hanging either. |
| 21:11.43 | Kobaz | can you reproduce the problem on a test box |
| 21:11.59 | Micc_ | not yet. |
| 21:12.05 | Micc_ | only happens in production so far. |
| 21:12.19 | Kobaz | that would be really useful |
| 21:14.16 | Micc_ | I'll try to do some more testing. I just can't have my backup server crashed at the same time the production server crashes. |
| 21:14.33 | Kobaz | yeah |
| 21:21.15 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-wknagjugfugcbgwq) |
| 21:22.11 | Micc_ | might have found another bug, couldn't get audio back after parking a call but no free spot was available, call was placed on hold, when I unhold the call there was no audio, could be the phone though. |
| 21:23.15 | Micc_ | I'm not sure what else to try, but I can't make it lock on a test server. |
| 21:23.19 | Kobaz | try with a soft phone? |
| 21:23.33 | Micc_ | no, aastra 6731i's |
| 21:23.50 | Kobaz | well try the same thing with a soft phone and see if you get audio issues |
| 21:24.34 | Micc_ | I can try a polycom or a mitel, I've got lots of phones. |
| 21:25.40 | Kobaz | that too |
| 21:27.58 | Micc_ | I don't really care about the audio problem. I only want to find the lock problem. |
| 21:29.19 | Micc_ | irroot said he'd be back home at 21:00 but I don't know if he meant tomorrow or what, its way after 21:00 his time. |
| 21:31.19 | Kobaz | k |
| 21:31.33 | Kobaz | yeah i can't help with sip too much, he would be the guy... one of the guys |
| 21:33.11 | Kobaz | i'm gonna go get some rust off a lawnmower |
| 21:39.13 | *** join/#asterisk-dev luminforce (~luminforc@rrcs-71-42-183-54.sw.biz.rr.com) |
| 21:39.31 | *** part/#asterisk-dev luminforce (~luminforc@rrcs-71-42-183-54.sw.biz.rr.com) |
| 21:40.36 | *** join/#asterisk-dev luminforce (~luminforc@rrcs-71-42-183-54.sw.biz.rr.com) |
| 21:47.39 | Micc_ | people seem to be getting parked in the wrong place too. |
| 21:49.45 | luminforce | anyone heard of cdr billsec not being recorded correctly when a call is placed on hold remotely? |
| 22:09.39 | Micc_ | I think my main problem is parked calls just keep racking up and they aren't cleared. parkedcalls show is showing lots of numbers (11) in one case but there are no calls connected to those spots. |
| 22:13.34 | Micc_ | I'm starting to think parking in 1.8.5.0 has a lot more work to be done than the simple bit I did to make it pick the right spot. |
| 22:39.09 | *** part/#asterisk-dev luminforce (~luminforc@rrcs-71-42-183-54.sw.biz.rr.com) |
| 23:35.27 | *** join/#asterisk-dev jrrose (~Jon@207.98.203.74) |
| 23:59.15 | 64MAAWNPR | when a transfer to a parking spot it done does that call sip_park and start the sip_park_thread or is the xfer done and just creates a new channel to the exten which uses the Park application? I guess I should look in the Park application for whats going on there. |