| 00:08.06 | *** join/#asterisk-dev snuff-home (~snuffy@203-219-29-182.tpgi.com.au) |
| 00:08.06 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 01:56.32 | *** join/#asterisk-dev otherwiseguy (~otherwise@cpe-69-76-221-79.kc.res.rr.com) |
| 03:09.27 | *** join/#asterisk-dev mjordan (~mjordan@user-69-1-6-49.knology.net) |
| 03:09.27 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 04:26.29 | *** join/#asterisk-dev Kobaz (~kobaz@its.kobaz.net) |
| 05:11.04 | *** join/#asterisk-dev otherwiseguy (~otherwise@69.76.221.79) |
| 07:51.28 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 08:00.13 | *** join/#asterisk-dev schmidts (~schmidts@Lo20-rt01.lm33.sil.at) |
| 08:00.15 | schmidts | good morning |
| 08:16.31 | *** join/#asterisk-dev irroot (~gregory@196-210-183-220.dynamic.isadsl.co.za) |
| 08:35.56 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 08:43.03 | schmidts | irroot could you just take a look at this row: http://www.asterisk.org/doxygen/asterisk1.8/res__rtp__asterisk_8c-source.html#l01170 |
| 08:43.34 | schmidts | depending on my core dump it looks like the rtpheader wasnt set right (out of bounds) which caused the seqfault |
| 08:44.13 | schmidts | and there is no check done if rtpheader has a correct value |
| 08:47.09 | irroot | schmidts yeah seems freaky with the last pb |
| 08:48.49 | schmidts | i dont want to say something wrong but i guess this part of rtp was last time touched atleast 3 years ago :D |
| 08:49.07 | irroot | is it repeatable ? |
| 08:49.23 | irroot | its not the rtp i suspect but a funky frame |
| 08:51.05 | schmidts | the server was running for around 2 and a half week and has processed over 125k calls, so it looks like it doesnt happens very often |
| 08:51.40 | schmidts | there are only 2 Pris connected to this server and i use chan_ss7 on it but i dont think this has something to do with it |
| 08:52.19 | irroot | schmidts its possible that chan_ss7 lets something through that messes with rtp |
| 08:54.41 | schmidts | btw i forget to say, this happend AFTER a hangup |
| 08:54.53 | irroot | you said it was in h :P |
| 08:55.40 | schmidts | ok i might not have anything to do with ss7 at all |
| 08:55.53 | schmidts | the last thing i see in syslog was a hangup of a local call back to another server |
| 08:56.01 | schmidts | so this was only sip and no ss7 involved |
| 09:01.26 | schmidts | your segfault also sounds nice :D do you use hints? |
| 09:03.14 | irroot | schmidts yes we do some custom ones too |
| 09:04.10 | schmidts | 1.8 ? |
| 09:04.26 | schmidts | cause i have noticed this a long time ago but didnt dig into it |
| 09:04.32 | irroot | yeah and 10 now that we started rollin out |
| 09:04.43 | schmidts | still the same problem with 10? |
| 09:07.18 | *** join/#asterisk-dev _ys (~Miranda@HS3-192-239.xG.SPb.SkyLink.RU) |
| 09:07.53 | irroot | i only seen this at a rather vanilla site |
| 09:08.13 | irroot | im tracking back |
| 09:10.22 | schmidts | ok ;) |
| 09:10.33 | schmidts | so are you able to reproduce this? |
| 09:11.10 | irroot | it happends all the time setting up a sandbox to do it |
| 09:12.11 | schmidts | does it happen on the first sip reload or do you have to do it more than once? |
| 09:13.38 | schmidts | cause on my 2 hosted pbx server i have around 2000 hints and up to 2000 sip subscriptions on each and i do a sip reload every 15 minutes and never had a segfault |
| 09:19.37 | irroot | schmidts on reload every time |
| 09:20.13 | schmidts | sip reload or core reload? |
| 09:24.10 | irroot | both |
| 09:24.19 | irroot | when sip reload is run |
| 09:24.36 | irroot | the only change from rc4 is the nat warning |
| 09:30.36 | irroot | the BT is not so useful on the live system |
| 09:32.26 | schmidts | same for me :D |
| 09:32.38 | schmidts | dont optimize isnt much fun on a production system as we know :D |
| 10:01.39 | schmidts | irroot i guess i have found it :D |
| 10:02.12 | irroot | hehe still on the todo list |
| 10:02.16 | schmidts | this is the address of rtpheader: 0xfffffffffffffff4 |
| 10:02.31 | schmidts | rtpheader is data.ptr - hrdlen which is 12 |
| 10:02.45 | schmidts | so lets think just a second what we get when we add 12 to 0xfffffffffffffff4 |
| 10:03.00 | schmidts | looks like data.ptr is NULL and its not checked anywhere |
| 10:08.14 | irroot | schmidts but the frame is not null |
| 10:11.12 | schmidts | the data.ptr is null |
| 10:13.43 | *** join/#asterisk-dev mpe (~mpe@office.ipvision.dk) |
| 10:18.44 | irroot | the question is always but why :P |
| 10:20.24 | irroot | ast_null_frame |
| 10:22.41 | schmidts | btw in the backtrace i can see this happend on an ss7 call |
| 10:23.54 | irroot | http://www.asterisk.org/doxygen/asterisk1.8/res__rtp__asterisk_8c-source.html#l01334 <- this shows null is checked |
| 10:24.29 | irroot | schmidts ^^ |
| 10:25.19 | schmidts | strange |
| 10:28.11 | schmidts | but why this happens? |
| 10:30.42 | wdoekes2 | where is the backtrace? isn't raw_write called from the smoother bit? |
| 10:31.33 | wdoekes2 | oh wait, that's checked too |
| 10:31.49 | schmidts | wdoekes2 i will pastebin the whole trace |
| 10:32.15 | schmidts | http://pastebin.com/Lz3KbLPw |
| 10:34.51 | *** join/#asterisk-dev _ys (~Miranda@HS3-193-212.xG.SPb.SkyLink.RU) |
| 10:35.27 | schmidts | so any ideas? |
| 10:35.54 | wdoekes2 | hm.. the only thing I can think of is that the smoother isn't thread safe, but that would have greater implications |
| 10:36.18 | wdoekes2 | so this is odd indeed |
| 10:36.57 | schmidts | i dont know if you have seen this wdoekes2 but this machine just proceeded around 125k calls without any problems, so this problem isnt really reproduceable ;) |
| 10:41.21 | wdoekes2 | ..the other explanation would be someone writing over your memory, but that's even less funny |
| 10:41.52 | schmidts | wdoekes2 thanks :D |
| 10:44.02 | schmidts | wdoekes2 but i dont think its an accident that the memory value is exactly NULL if i add the hdrlen again |
| 10:44.19 | wdoekes2 | indeed.. |
| 10:44.57 | wdoekes2 | print *f; |
| 10:45.37 | wdoekes2 | print *frame; |
| 10:45.48 | wdoekes2 | (that last one) |
| 10:46.58 | schmidts | not so good idea on a production system i think |
| 10:48.12 | wdoekes2 | in gdb |
| 10:49.03 | wdoekes2 | I wonder if the rest of frame is unscathed (or 0) |
| 10:49.39 | schmidts | aaah ok will try it |
| 10:49.55 | wdoekes2 | and the smoother too.. |
| 10:49.57 | wdoekes2 | up |
| 10:50.00 | wdoekes2 | print *rtp->smoother |
| 10:53.52 | schmidts | dont work |
| 10:54.08 | schmidts | i have tried it in ast_rtp_raw_write, in ast_rtp_write and ast_write |
| 10:55.03 | wdoekes2 | what do you mean, don't work? |
| 10:55.36 | schmidts | print *rtp->smoother dont work |
| 10:55.42 | schmidts | There is no member named smoother. |
| 10:56.24 | wdoekes2 | mm.. there should be one.. unless you're running different code |
| 10:57.06 | schmidts | i use my dev branch but this part isnt touched |
| 10:58.29 | wdoekes2 | print *rtp |
| 10:58.57 | wdoekes2 | that should be there, and tell you which members it has |
| 11:00.15 | schmidts | yep |
| 11:00.38 | schmidts | http://pastebin.com/TidDJcH6 |
| 11:02.20 | schmidts | wtf?? |
| 11:02.21 | schmidts | (gdb) print frame->data.ptr |
| 11:02.21 | schmidts | $4 = (void *) 0x7ffd107ecbf0 |
| 11:02.35 | schmidts | that doesnt look like NULL |
| 11:04.39 | wdoekes2 | that's in #1 ? or in #2 ? |
| 11:04.42 | schmidts | could this happen on the cast to unsigned char * |
| 11:04.44 | schmidts | in #2 |
| 11:04.48 | wdoekes2 | that's irrelevant |
| 11:05.08 | wdoekes2 | look in #1 |
| 11:05.10 | wdoekes2 | (down) |
| 11:05.13 | schmidts | no sorry i was in #1 |
| 11:05.48 | wdoekes2 | and what kind of datatype is 'rtp' (in #2)? |
| 11:05.51 | wdoekes2 | print rtp |
| 11:06.06 | wdoekes2 | ..since we expect it to have a smoother |
| 11:07.44 | schmidts | in #2 i only have p->rtp and this gives me: $7 = (struct ast_rtp_instance *) 0x7ffcec0982d8 |
| 11:08.50 | wdoekes2 | oh.. bah.. I mixed up the locations |
| 11:08.54 | wdoekes2 | I meant #0 and #1 |
| 11:09.50 | schmidts | ok ;) |
| 11:13.06 | wdoekes2 | this seems wrong: |
| 11:13.07 | wdoekes2 | #0 ast_rtp_raw_write (instance=0x7ffcec0982d8, frame=0x7ffd107ecc90, codec=8) at /usr/src/unleash-the-beast/include/asterisk/unaligned.h:62 |
| 11:13.11 | wdoekes2 | #1 0x00007ffcfc1cca21 in ast_rtp_write (instance=0x7ffcec0982d8, frame=0x7ffd107ecc90) at res_rtp_asterisk.c:1345 |
| 11:13.25 | wdoekes2 | frame is the same, but it shouldn't be |
| 11:14.01 | wdoekes2 | if you're using the smoother, you get: return &s->f; from ast_smoother_read(rtp->smoother) |
| 11:14.43 | wdoekes2 | and I don't see how &s->f could be the same as the frame passed in |
| 11:16.34 | wdoekes2 | but if it was, there could be all sorts of trouble ahead: e.g. this memcpy in smoother_frame_feed(): memcpy(s->data + s->len, f->data.ptr, f->datalen); |
| 11:17.24 | wdoekes2 | oh wait.. ->data != ->f, never mind that last bit |
| 11:29.53 | wdoekes2 | schmidts: in any case, $3 did have a smoother, what's its contents? |
| 11:37.03 | schmidts | give me a second i will look |
| 11:52.30 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 11:52.31 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 12:06.39 | schmidts | wdoekes2 sorry here it is: |
| 12:06.40 | schmidts | $17 = {size = 160, format = 8, flags = 0, samplesperbyte = 1, opt_needs_swap = 0, f = {frametype = 0, subclass = {integer = 0, codec = 0}, datalen = 0, |
| 12:06.40 | schmidts | <PROTECTED> |
| 12:06.40 | schmidts | <PROTECTED> |
| 12:06.41 | schmidts | <PROTECTED> |
| 12:06.47 | schmidts | eeehh sorry i pastebin it |
| 12:06.59 | schmidts | http://pastebin.com/suNHRkAy |
| 12:20.41 | *** part/#asterisk-dev irroot (~gregory@196-210-183-220.dynamic.isadsl.co.za) |
| 12:23.08 | *** join/#asterisk-dev irroot (~gregory@196-210-183-220.dynamic.isadsl.co.za) |
| 12:27.29 | wdoekes2 | schmidts: that's a lot of zeroes you have there |
| 12:28.36 | schmidts | yes thats true, but i dont know if this is normal or not |
| 12:29.29 | wdoekes2 | me neither.. depends on what _feed() does (or should do) with the supplied frame |
| 12:39.56 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 12:52.05 | *** join/#asterisk-dev merbanan (~benjamin@asterix-e.southpole.se) |
| 13:02.39 | *** join/#asterisk-dev aimka (~aimka@unaffiliated/aimka) |
| 13:02.41 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 13:33.37 | *** join/#asterisk-dev anonymouz666 (~anonymouz@189.25.16.145) |
| 13:37.17 | *** join/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 14:01.23 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-zxobjulqrtgvjchu) |
| 14:01.24 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:01.45 | *** join/#asterisk-dev jrose_atDigium (~jon@nat/digium/x-xwcyqttvpxhllsxt) |
| 14:05.26 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-bxzzzgcdqvkuxinh) |
| 14:26.20 | schmidts | wdoekes2 i dont think you need a review for this tcptls_session fix |
| 14:26.45 | schmidts | or atleast i would give you a ship it right now ;) |
| 14:32.55 | schmidts | wdoekes2 or not give me a second to check this |
| 14:33.42 | wdoekes2 | I don't have my keys here .. feel tree to commit it yourself :) |
| 14:35.25 | schmidts | as i said i am checking this right now |
| 14:44.58 | schmidts | maybe i am stupid but i dont see the problem he is complaining about? |
| 14:45.14 | schmidts | on the head of sip_prepare_socket there is: struct ast_tcptls_session_instance *tcptls_session; |
| 14:45.34 | schmidts | some rows below without any goto to the cleanup section there is this: |
| 14:45.35 | schmidts | <PROTECTED> |
| 14:48.17 | schmidts | and only below this there are several gotos to the cleanup section which he mention in the mail |
| 14:49.55 | *** join/#asterisk-dev sustav (~alfa@nat/digium/x-egqvtqqvrgvothxo) |
| 14:50.10 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-tywnodpftfkyrahj) |
| 14:50.10 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 14:50.52 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-yxnwzegkeoobfzza) |
| 14:50.58 | *** join/#asterisk-dev mnicholson (~mnicholso@nat/digium/x-tiibzaetegikoeal) |
| 14:50.58 | *** mode/#asterisk-dev [+o mnicholson] by ChanServ |
| 14:53.58 | wdoekes2 | schmidts: 1.8.x svn, line 25297: if tcptls_session is non-NULL, it ends there, otherwise tcptls_session is guaranteed to be NULL |
| 15:00.07 | *** join/#asterisk-dev jrose_atDigium (~jon@nat/digium/x-oeycpnnjmeizhmjj) |
| 15:00.54 | schmidts | ok go it |
| 15:06.05 | schmidts | then its really just a typo ;) |
| 15:08.46 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:08.46 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:16.55 | *** join/#asterisk-dev UnixDev (unixdev@unaffiliated/unixdev) |
| 15:23.32 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:23.32 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:24.17 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:24.18 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 15:26.50 | *** part/#asterisk-dev otherwiseguy (~otherwise@rrcs-173-197-0-67.west.biz.rr.com) |
| 15:36.02 | *** join/#asterisk-dev zerohalo (~zerohalo@74-94-141-204-ma.hfc.comcastbusiness.net) |
| 15:54.14 | *** join/#asterisk-dev sruffell (~Adium@asterisk/the-kernel-guy/sruffell) |
| 15:54.15 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:24.27 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:48.04 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:50.11 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 16:51.46 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 17:32.55 | *** join/#asterisk-dev citywok (~citywok@67-134-194-33.dia.static.qwest.net) |
| 18:07.35 | anonymouz666 | is it safe to: amd = pbx_builtin_getvar_helper(p->owner, "AMD"); if (!ast_strlen_zero(amd)) { add_header(req, "X-AMD", amd); } |
| 18:26.24 | *** join/#asterisk-dev oron_laptop (~oron_lapt@line25-214.adsl.actcom.co.il) |
| 18:29.35 | mjordan | anonymouz666: you'll want to make sure the locking order is correct on p and p->owner when you call that. Locking order should be p->owner, then p - and p->owner should be locked prior to calling pbx_builtin_getvar_helper. Without knowing where in chan_sip you want to put that, I'm not sure if that's the case |
| 18:33.58 | anonymouz666 | inside the function transmit_response_with_sdp() |
| 18:34.33 | anonymouz666 | when the call is answered I exec a macro that sets AMD var, and then when transmiting the 200 OK I put this value if exists into X-AMD header |
| 18:35.53 | anonymouz666 | do I need to lock / unlock ? |
| 18:42.01 | mjordan | anonymouz666: which version? |
| 18:42.04 | mjordan | er, of asterisk |
| 18:42.48 | anonymouz666 | this is the old 1.4 |
| 18:42.53 | mjordan | oh... |
| 18:42.55 | mjordan | hm. |
| 18:42.58 | mjordan | tricky |
| 18:44.26 | anonymouz666 | I had this code once working, but I lost it. I didn't remember if I lock or no but I guess yes |
| 18:45.47 | mjordan | I can't answer for that. I don't think in transmit_response_with_sdp p->owner is locked, but p probably is. So, if you need to lock the channel before calling pbx_builtin_getvar_helper (which you do need to do, per that method's documentation at least), you would need to unlock p, lock p->owner, lock p, do your logic, then unlock p, unlock p->owner, and relock p. But I'm basing the locking order off of 1.8+, so your mileage may var |
| 18:49.49 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 18:49.49 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 18:49.52 | mjordan | if p->owner is locked, btw, then this is a non-issue. The problem is transmit_response_with_sdp is called from a lot of places, and I don't know if p->owner is locked in all of them or not. |
| 18:50.46 | anonymouz666 | if yes, I don't need to care about locking, right? |
| 18:53.27 | sruffell | tzafrir: will returning an error from DAHDI_STARTUP ioctl like in https://github.com/sruffell/dahdi-linux/commit/64e0decf705d cause any problems for you? Looked safe to me but I thought I should double check since there is the one place where you return an error from that callback. |
| 18:54.22 | sruffell | (I want to commit https://github.com/sruffell/dahdi-linux/commit/512c984d5a24 which depends on the change in dahdi-base) |
| 18:55.19 | mjordan | if p->owner is locked then you can call pbx_builtin_getvar_helper |
| 18:55.44 | mjordan | if p->owner is not locked, but p is, then you have to care a lot, because you don't want to lock p->owner after you've locked p, causing a locking inversion (and most likely deadlocking) |
| 18:56.17 | mjordan | or at least, most likely *eventually* deadlocking. No guarantee when that would happen, but you'd be rolling the dice |
| 18:58.26 | tzafrir | sruffell, looks ok |
| 18:58.42 | sruffell | ok, thanks. |
| 18:58.45 | anonymouz666 | mjordan: ast_mutex_lock(&p->lock); is called |
| 18:58.56 | anonymouz666 | when SIP answers and send the 200 OK |
| 19:01.57 | *** join/#asterisk-dev Netgeeks (~chris@173.11.68.156) |
| 19:02.35 | anonymouz666 | then I can add: ast_mutex_lock(&p->owner->lock); pbx_builtin_getvar_helper(...); ast_mutex_unlock(&p->owner->lock); |
| 19:03.31 | tzafrir | sruffell, see in the mail a fix (hopefully) for the surprise removal in DAHDI |
| 19:03.56 | tzafrir | sparse also has some new complaints about dahdi-base.c |
| 19:04.22 | sruffell | :/ I haven't run sparse in a bit. |
| 19:07.16 | sruffell | tzafrir: hmm…what version of sparse are you running….it just came up clean on trunk. |
| 19:08.10 | sruffell | only in xpp are there three warnings. |
| 19:09.28 | sruffell | updates sparse to 0.4.4 |
| 19:11.03 | sruffell | no change |
| 19:11.10 | tzafrir | right. An old sparse |
| 19:12.55 | tzafrir | Re-sent patch. Forgot to include some changegs in it |
| 19:13.20 | *** join/#asterisk-dev datachomper (~Adium@75.76.6.182) |
| 19:14.15 | sruffell | looks |
| 19:15.51 | anonymouz666 | was locked |
| 19:15.58 | anonymouz666 | heh |
| 19:17.27 | mjordan | anonymouz666: hm... if you lock p->owner after p, you're inverting the locking order that is established between a channel and it's sip_pvt that is established at least in 1.8. I can't speak for 1.4 - you'll probably just have to test it. |
| 19:17.56 | sruffell | tzafrir: I just emailed the ack. |
| 19:18.10 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-etirwzwlnryutsox) |
| 19:18.12 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 19:18.43 | oron_laptop | sruffell, tzafrir: good, now we won't have panics on device hotplugging :-O |
| 19:19.09 | anonymouz666 | mjordan: now I am lost :) |
| 19:19.14 | sruffell | using the file_ops didn't occur to me…seems clean. |
| 19:19.28 | mjordan | :-) It's tricky |
| 19:19.44 | oron_laptop | sruffell: Yes, I've hit myself on the head (how come I didn't think about it before?) |
| 19:22.00 | mjordan | so, the locking order is supposed to go channel, then sip_pvt. So in the case of p->owner and p, you would first lock p->owner, then lock p. If, however, a function (or the caller of a function) has already locked p, but has not locked p->owner (probably because they didn't need to actually change the channel), and you need to lock p->owner, you need to first unlock p before locking p->owner. Otherwise, you can run into situations w |
| 19:22.06 | mjordan | clear as mud! |
| 19:22.34 | oron_laptop | sruffell: note that I left behind the old "workarounds" as ERR() messages. If all is OK, we may remove them later (2.7?) |
| 19:22.50 | sruffell | nods |
| 19:22.56 | sruffell | that is what I was thinking you were thinking. :) |
| 19:23.50 | Qwell | mjordan: You got cut off at "run into situations w" |
| 19:24.06 | sruffell | but…I guess there would also be a short race…if a call comes in between when private_data is set to NULL and the f_op is changed. |
| 19:24.08 | oron_laptop | sruffell: seems like I wasn't thinking at all... |
| 19:24.14 | mjordan | qwell: thanks |
| 19:24.20 | mjordan | Otherwise, you can run into situations where thread A has locked p and goes to lock p->owner but Thread B has locked p->owner and needs to lock p (deadlock). If the locking order is maintained, then you don't run into that scenario. |
| 19:25.50 | oron_laptop | sruffell: You are right. I also suspect there may be other corner cases about calls which are "midflight"... |
| 19:26.01 | sruffell | nods. |
| 19:26.10 | sruffell | but it's certainly all better than what currently exists... |
| 19:27.15 | oron_laptop | sruffell: Yes. the current situation almost guaranteed that every disconnect of PRI (asterisk does not close D-channels yet) caused deadlocks/panics. |
| 19:28.59 | tzafrir | On the Asterisk front there are https://reviewboard.asterisk.org/r/726/ and https://reviewboard.asterisk.org/r/1598/ |
| 19:30.35 | oron_laptop | sruffell, tzafrir: It's a pitty the '726' review was sitting almost 1.5 years in the queue... |
| 19:31.09 | oron_laptop | sruffell, tzafrir: but maybe with some pushing and shoving we may see full dahdi hotplug in our lifetimes ;-) |
| 19:31.28 | anonymouz666 | mjordan: what happens if the caller of a function locks p, and in the function another lock(p); |
| 19:31.31 | sruffell | :) I have hope.... |
| 19:32.36 | oron_laptop | sruffell: our proposed user-space script already dahdi_cfg + asterisk -rx 'dahdi create...' |
| 19:33.27 | oron_laptop | sruffell: It works -- we disconnect/reconnect devices (in different order: pinned-spans) and get a dial tone. |
| 19:34.12 | sruffell | very cool. I still need to look at that. I don't poke around up in Asterisk-land too much. |
| 19:34.15 | oron_laptop | sruffell: (analog devices [review 726 not applied yet]) |
| 19:34.28 | sruffell | (in case you didn't notice) |
| 19:34.37 | oron_laptop | sruffell: he,he,he... |
| 19:37.18 | mjordan | anonymouz666: locks should be recursive, but that's never happy code |
| 19:40.37 | anonymouz666 | If I understand correctly then the correct order is: unlock(p) lock(p->owner) lock(p) getvar() unlock(p) unlock(p->owner) |
| 19:47.17 | anonymouz666 | oh miss the lock(p) at the end |
| 19:49.03 | oron_laptop | sruffell, tzafrir: Oops, just had a compile failure on my F15 box -- I only add nodev_ioctl() and not the {compat,unlocked} versions... |
| 19:49.32 | tzafrir | Try the new(er) version I sent you |
| 19:52.30 | oron_laptop | checking |
| 19:54.40 | anonymouz666 | mjordan: very stragen thing is: try_suggested_sip_codec() uses getvar on p->owner, and the caller of function is in sip_answer that calls try_suggested_sip_codec without p->owner->lock, just p->lock |
| 20:00.38 | *** join/#asterisk-dev datachomper (~Adium@75.76.6.182) |
| 20:06.10 | mjordan | anonymouz666: well, they probably shouldn't do that |
| 20:06.26 | mjordan | if nothing else, you open yourself to a race condition on the channel |
| 20:07.33 | leifmadsen | wdoekes2: thanks on ASTERISK-18997 |
| 20:30.54 | *** join/#asterisk-dev The_Boy_Wonder (~Adium@asterisk/batman-developer/dvossel) |
| 20:30.55 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 20:40.36 | *** join/#asterisk-dev mjordan (~mjordan@nat/digium/x-pjlakigazrdeihtq) |
| 20:40.37 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 21:46.27 | *** join/#asterisk-dev irroot (~gregory@197.170.157.231) |
| 22:14.40 | *** join/#asterisk-dev tzafrir (~tzafrir@bzq-218-155-147.cablep.bezeqint.net) |
| 22:14.41 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 22:17.11 | *** join/#asterisk-dev Tim_Toady (~fuzzy@77.49.234.191.dsl.dyn.forthnet.gr) |
| 22:23.29 | *** part/#asterisk-dev datachomper (~Adium@75.76.6.182) |
| 22:40.21 | *** join/#asterisk-dev zerohalo (~zerohalo@74.60.136.128) |
| 23:08.28 | *** part/#asterisk-dev mjordan (~mjordan@nat/digium/x-pjlakigazrdeihtq) |
| 23:18.45 | *** join/#asterisk-dev Freeaqingme (~Freeaqing@91.214.168.110) |