| 00:06.02 | *** part/#asterisk-dev corramor (n=corramor@nat/digium/x-e79e2131cf041faf) |
| 01:00.37 | *** join/#asterisk-dev jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 01:00.37 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 01:07.40 | *** join/#asterisk-dev mvanbaak_ (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 01:07.41 | *** mode/#asterisk-dev [+o mvanbaak_] by ChanServ |
| 01:20.46 | *** part/#asterisk-dev korihor (n=korihor@201.211.168.130) |
| 01:31.42 | *** join/#asterisk-dev bbryant (n=brett@c-68-59-20-153.hsd1.sc.comcast.net) |
| 01:31.42 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 01:54.53 | *** join/#asterisk-dev corramor (n=corramor@nat/digium/x-5c119546cbd9fcf4) |
| 01:55.20 | *** join/#asterisk-dev mvanbaak (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 01:55.20 | *** mode/#asterisk-dev [+o mvanbaak] by ChanServ |
| 02:16.48 | *** join/#asterisk-dev korihor (n=korihor@190.78.32.60) |
| 02:24.29 | *** join/#asterisk-dev dwayne (i=dwayne@76.29.245.9) |
| 02:26.00 | *** join/#asterisk-dev russellb_ (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 02:26.00 | *** mode/#asterisk-dev [+o russellb_] by ChanServ |
| 05:27.04 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 05:27.04 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 06:04.04 | *** join/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 06:04.04 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 06:53.57 | *** join/#asterisk-dev nicox (n=nicox@212-183-42-122.adsl.highway.telekom.at) |
| 07:10.51 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 07:10.51 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 07:25.20 | mvanbaak | wedhorn: very lagged pong |
| 07:25.30 | *** join/#asterisk-dev T3RA (n=teraband@58.171.169.21) |
| 07:25.37 | T3RA | Afternoon |
| 07:25.42 | mvanbaak | good mornin |
| 07:26.21 | T3RA | got an Asterisk question... anyone able to answer ? |
| 07:30.06 | *** join/#asterisk-dev kkjoe (n=opera@p509893b3.dip0.t-ipconnect.de) |
| 07:33.11 | mvanbaak | maybe. but if it's not development related you will have more luck in #asterisk |
| 07:46.59 | *** join/#asterisk-dev L-info (n=L-info@g0962184.demon.co.uk) |
| 07:53.06 | T3RA | ahh |
| 07:53.10 | T3RA | thanks |
| 07:58.18 | mvanbaak | no problem :) |
| 08:15.36 | *** join/#asterisk-dev philipp64 (n=chatzill@63.224.43.239) |
| 09:04.19 | *** join/#asterisk-dev mvanbaak_ (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 09:04.20 | *** mode/#asterisk-dev [+o mvanbaak_] by ChanServ |
| 09:22.21 | wedhorn | mvanbaak_: pj's crash, it could be a lock thing. Notice in his latest backtrace it mentions both hangup and newcall. They could be trampling on each other. |
| 09:25.32 | mvanbaak_ | yeah, I saw that as well |
| 09:25.43 | mvanbaak_ | I wonder if it happens without your patch as well |
| 09:27.54 | wedhorn | don't know. Makes it hard to debug if we can't replicate it |
| 09:28.36 | mvanbaak_ | indeed |
| 09:31.20 | wedhorn | on closer inspection, the channel is the same for both the newcall and hangup. That is not good |
| 09:32.03 | wedhorn | I wonder if freeing the sub has caused the problem to appear earlier |
| 09:34.43 | wedhorn | bad hook switch or dirt on the contacts? hangup could throw a make-break-make triggering a new call before the old has finished hanging up |
| 09:35.42 | mvanbaak | sounds reasonable |
| 09:36.04 | wedhorn | do you know whether pj's got more than one phone and if so is the issue related to a specific phone? |
| 09:39.24 | mvanbaak | dont know |
| 09:40.04 | mvanbaak | but, if that's the case we can try it right ? |
| 09:40.20 | mvanbaak | setup a call, and hit the hook switch fast |
| 09:40.31 | wedhorn | I'll post a note asking him, will also ask for a tcp dump to see if the phone is sending unexpected packets (like offhook during a hangup) |
| 09:40.55 | wedhorn | best of luck, any idea how quick the hangup would be done |
| 09:41.18 | mvanbaak | hhmm, let me try |
| 09:42.24 | mvanbaak | hhmm |
| 09:42.33 | mvanbaak | if I hit the hook switch real fast it wont hangup |
| 09:43.07 | wedhorn | 175 and I got a segfault |
| 09:43.57 | mvanbaak | oh wait, I'm running without your patch right now |
| 09:44.12 | mvanbaak | let me repatch |
| 09:45.11 | wedhorn | the core dump looks similar to what pj posted |
| 09:45.25 | wedhorn | don't have skinny_new, but got skinny_ss and hangup in the same bt |
| 09:47.35 | mvanbaak | and I have the same bt as pj with your patch |
| 09:47.48 | mvanbaak | without your patch no coredump happens |
| 09:47.57 | mvanbaak | with your patch I get the same backtrace as pj |
| 09:48.12 | wedhorn | his original backtrace was different |
| 09:48.23 | mvanbaak | including having skinny_newcall and skinny_hangup in the same bt |
| 09:48.30 | mvanbaak | want me to pastebin my bt ? |
| 09:48.42 | wedhorn | no, I think we have the same issue |
| 09:48.58 | *** join/#asterisk-dev jeffg (i=yWNOGRKx@pdpc/supporter/active/jeffg) |
| 09:49.11 | wedhorn | the difference is the timing of how far the new channel gets before the hangup destroys it (at a guess) |
| 09:49.29 | mvanbaak | hhmm, sub in newcall and hangup are the same indeed |
| 09:49.37 | wedhorn | =bad |
| 09:50.37 | wedhorn | need to look at some better locking (or the offhook stuff) |
| 09:50.40 | mvanbaak | yup |
| 09:50.46 | mvanbaak | the line is different though |
| 09:51.03 | wedhorn | that's weird |
| 09:51.15 | mvanbaak | device and session are 0 in hangup |
| 09:51.21 | mvanbaak | but they are set in newcall |
| 09:53.24 | wedhorn | how the hell can the line be different? |
| 09:53.42 | wedhorn | flashing the hook shouldn't change the line |
| 09:55.31 | *** join/#asterisk-dev mvanbaak_ (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 09:55.31 | *** mode/#asterisk-dev [+o mvanbaak_] by ChanServ |
| 09:55.41 | mvanbaak_ | did you get that ? |
| 09:55.59 | mvanbaak_ | I pasted the line info from my bt |
| 09:56.03 | wedhorn | nope, what? |
| 09:56.07 | mvanbaak_ | in hangup: |
| 09:56.11 | mvanbaak_ | <PROTECTED> |
| 09:56.16 | mvanbaak_ | in newcall: |
| 09:56.21 | mvanbaak_ | <PROTECTED> |
| 09:56.57 | wedhorn | weird, no in mine, skinny_ss and hangup, d, l, sub, and channel are the same |
| 09:57.26 | mvanbaak_ | well, in hangup my d and session are 0x0 |
| 09:57.43 | mvanbaak_ | only sub is the same |
| 09:58.00 | wedhorn | that is strange, what do you have in skinny_ss |
| 09:58.34 | mvanbaak_ | skinny_ss and skinny_newcall are the same |
| 09:59.25 | mvanbaak_ | c, sub, l and d |
| 10:00.01 | wedhorn | anyway, the rugby's about to start, gotta go watch us beat the kiwis |
| 10:00.17 | mvanbaak_ | wait |
| 10:00.32 | mvanbaak_ | the ast_channel in skinny_ss and skinny_newcall is the same as given to ast_hangup |
| 10:01.09 | wedhorn | maybe the segfault occured before d,l etc was set |
| 10:01.29 | mvanbaak_ | #0 0xb6bcfa07 in skinny_hangup (ast=0x828e9a0) at chan_skinny.c:3625 |
| 10:02.25 | mvanbaak_ | s = d->session |
| 10:02.28 | mvanbaak_ | but d = 0x0 |
| 10:02.32 | mvanbaak_ | so that makes sense |
| 10:03.45 | mvanbaak_ | I have to go soon as well. shopping and packing boxes |
| 10:05.01 | wedhorn | that would cause a crash |
| 10:05.12 | mvanbaak_ | uhhuh |
| 10:05.15 | wedhorn | maybe you got a different crash? |
| 10:05.24 | wedhorn | two for the price of one ;) |
| 10:07.33 | wedhorn | anyway, I'll have more of a look at it in the morning |
| 10:08.51 | mvanbaak_ | no problem |
| 10:09.07 | mvanbaak_ | if you want my bt just contact me here or drop me a mail at michiel@vanbaak.info |
| 11:07.52 | *** join/#asterisk-dev nicox (n=nicox@212-183-43-149.adsl.highway.telekom.at) |
| 11:37.03 | *** join/#asterisk-dev nicox_ (n=nicox@213-33-11-227.adsl.highway.telekom.at) |
| 11:48.12 | *** join/#asterisk-dev nicox (n=nicox@213-33-11-227.adsl.highway.telekom.at) |
| 12:48.25 | *** join/#asterisk-dev russellb (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 12:48.25 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 13:42.10 | mvanbaak_ | hey russellb |
| 13:42.28 | mvanbaak_ | russellb: did you see my post to -dev about the new record4trunk <rev> |
| 13:52.42 | russellb | sure did |
| 13:52.44 | russellb | sounds good :) |
| 13:52.48 | russellb | thanks for getting that tool updated |
| 13:57.37 | mvanbaak | no problem |
| 13:57.59 | mvanbaak | it's faster for those not having a 100mbit line to origsvn ;) |
| 13:58.21 | mvanbaak | it's better at caching revision sets and logs |
| 13:58.38 | mvanbaak | and I liked working on it |
| 13:59.03 | russellb | awesome :) |
| 13:59.30 | mvanbaak | I'm going to create 3 diffs and send them upstream |
| 13:59.40 | mvanbaak | let's see how they handle that :) |
| 14:01.59 | seanbright | app_rpt == t3h suck |
| 14:02.20 | seanbright | well, maybe it's awesome... but it won't compile |
| 14:05.52 | russellb | i just disable it and pretend it's not there :-/ |
| 14:06.09 | mvanbaak | I do that as well |
| 14:07.33 | seanbright | yeah |
| 14:07.46 | seanbright | well... we might want to address that at some point |
| 14:07.51 | seanbright | instead of just turning a blind eye |
| 14:07.52 | seanbright | heh |
| 14:08.49 | seanbright | and by "we" i mean "one of you guys" |
| 14:09.53 | mvanbaak | whehehehe |
| 14:12.18 | russellb | it has already been addressed |
| 14:12.25 | russellb | ... i added <defaultenabled>no |
| 14:12.28 | russellb | :-D |
| 14:12.39 | seanbright | haha |
| 14:12.42 | seanbright | touche. |
| 14:19.39 | *** join/#asterisk-dev jeffg (i=BVWENtVK@pdpc/supporter/active/jeffg) |
| 14:26.09 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.108.195) |
| 14:26.09 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 14:34.34 | seanbright | hmmm |
| 14:34.36 | seanbright | x = (ast_random() % (rtpend-rtpstart)) + rtpstart; |
| 14:34.40 | seanbright | that line crashes my server |
| 14:38.21 | seanbright | oh... rtpend = 0 and rtpstart = 0 |
| 14:38.22 | seanbright | hrmmm |
| 14:40.10 | russellb | do you have those set to 0 in your config? |
| 14:40.19 | russellb | those certainly are not the defaults :) |
| 14:43.01 | russellb | even if it's your config, it's still file's fault |
| 14:43.11 | seanbright | where would that be in config? |
| 14:43.16 | russellb | rtp.conf |
| 14:43.16 | seanbright | i don't see anything in sip.conf |
| 14:43.18 | seanbright | ahh |
| 14:43.24 | seanbright | i don't have one of those |
| 14:43.24 | seanbright | :) |
| 14:43.28 | seanbright | default! bam! |
| 14:43.56 | russellb | ooh |
| 14:44.06 | seanbright | tilghman's conf change? |
| 14:44.12 | russellb | perhaps |
| 14:44.18 | russellb | it's a bug though |
| 14:44.27 | russellb | if no conf, for the love of ... please don't use 0 and 0 :) |
| 14:44.48 | russellb | div by 0 is bad mmkay? |
| 14:45.13 | seanbright | hehe |
| 14:45.26 | seanbright | putting rtp.conf in /etc/asterisk fixed her right up |
| 15:50.28 | mvanbaak | russellb: are you using the latest version of mkrelease from repotools ? |
| 15:50.35 | mvanbaak | I'm having a problem with it |
| 15:50.53 | mvanbaak | <PROTECTED> |
| 15:50.59 | russellb | hrm |
| 15:51.00 | russellb | yeah |
| 15:51.02 | mvanbaak | that line number is not ok |
| 15:51.07 | mvanbaak | I modified it a bit |
| 15:51.13 | russellb | works for me |
| 15:51.14 | russellb | :) |
| 15:51.29 | mvanbaak | but also, with a clean version I get the same |
| 15:51.36 | mvanbaak | the last popd is useless |
| 15:51.40 | mvanbaak | and I can see why |
| 15:51.50 | mvanbaak | because we are already in the dir where we started |
| 15:51.51 | mvanbaak | :) |
| 15:52.12 | mvanbaak | ah well |
| 15:52.18 | mvanbaak | who cares, if it works for you |
| 15:52.27 | russellb | shrugs |
| 15:52.32 | mvanbaak | as you can see, I'm stealing the script ;) |
| 15:52.34 | russellb | using bash? |
| 15:52.39 | mvanbaak | yup |
| 15:52.42 | russellb | heh, feel free to steal it |
| 15:52.44 | mvanbaak | it's on top of the file |
| 15:52.46 | russellb | that's why it's there |
| 15:52.51 | mvanbaak | #!/usr/bin/env bash |
| 15:53.22 | mvanbaak | thanks a lot for sharing it |
| 15:55.58 | mvanbaak | ow, just so you know. it's not working on OpenBSD ;) |
| 15:57.02 | mvanbaak | basically because the use of all the long options for cut and tar |
| 15:57.49 | mvanbaak | cut --delimiter== --fields=2 => cut -d = -f 2 |
| 15:58.28 | *** join/#asterisk-dev DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 15:59.31 | russellb | feel free to change stuff if you want to minimize differences |
| 15:59.36 | russellb | as long as you don't change the behavior ... |
| 15:59.40 | russellb | and don't break it for me :) |
| 16:04.33 | mvanbaak | lol |
| 16:05.10 | mvanbaak | you know, I dont think a release engineer @ digium will ever create releases using an OpenBSD workstation/server |
| 16:05.16 | mvanbaak | so I'll just leave it as is |
| 16:05.38 | mvanbaak | I'm already modifying it heavily to make it work in our setup |
| 16:05.52 | mvanbaak | but the script we had was shitty, and you guys came up with some nice stuff |
| 16:06.17 | mvanbaak | I'm now fighting with svn --log because I get the oldest commit on top and the newest at the bottom |
| 16:06.47 | *** join/#asterisk-dev lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:06.47 | *** mode/#asterisk-dev [+o lmadsen] by ChanServ |
| 16:28.12 | *** join/#asterisk-dev sruffell (n=sruffell@69-220-176-227.ded.ameritech.net) |
| 16:28.12 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:31.25 | mvanbaak | ugh |
| 16:31.28 | mvanbaak | I'm STUPID |
| 16:31.35 | mvanbaak | shoots himself |
| 16:33.42 | *** part/#asterisk-dev korihor (n=korihor@190.78.32.60) |
| 16:36.30 | tzafrir_laptop | and hits korhor |
| 16:36.50 | sruffell | :) |
| 16:40.28 | mvanbaak | cool, I have it working |
| 16:52.15 | *** join/#asterisk-dev jcollie (n=jcollie@fedora/jcollie) |
| 17:47.17 | *** part/#asterisk-dev kkjoe (n=opera@p509893b3.dip0.t-ipconnect.de) |
| 18:13.18 | *** join/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 18:13.18 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 18:15.35 | *** join/#asterisk-dev L-info (n=L-info@g0962184.demon.co.uk) |
| 18:16.36 | *** join/#asterisk-dev korihor (n=korihor@201.211.168.130) |
| 18:18.06 | *** join/#asterisk-dev moy (n=moy@189.169.91.147) |
| 18:28.29 | *** join/#asterisk-dev moy (n=moy@189.169.91.147) |
| 18:36.43 | *** join/#asterisk-dev L-info (n=L-info@g0962184.demon.co.uk) |
| 18:47.01 | *** join/#asterisk-dev L-info (n=L-info@g0962184.demon.co.uk) |
| 18:47.56 | *** join/#asterisk-dev L-info (n=L-info@g0962184.demon.co.uk) |
| 18:48.43 | *** join/#asterisk-dev L-info (n=L-info@g0962184.demon.co.uk) |
| 19:04.47 | *** join/#asterisk-dev jeffg_ (i=BP0Pogfo@pdpc/supporter/active/jeffg) |
| 19:19.31 | *** join/#asterisk-dev mog (n=mog@c-68-62-219-86.hsd1.al.comcast.net) |
| 19:19.31 | *** mode/#asterisk-dev [+o mog] by ChanServ |
| 20:26.19 | *** join/#asterisk-dev jsolis (n=jimmy@201.230.174.242) |
| 21:04.54 | *** join/#asterisk-dev ctooley (n=ctooley@209.33.108.195) |
| 21:04.54 | *** mode/#asterisk-dev [+o ctooley] by ChanServ |
| 21:15.27 | mvanbaak | what is this prep_tarball script ? |
| 21:15.28 | mvanbaak | ;) |
| 21:16.25 | mvanbaak | oh wait, it's in asterisk/ instead of repotools/ |
| 21:16.27 | mvanbaak | never mind |
| 21:28.03 | wedhorn | mvanbaak: as you're around. Been having a bit more or dig around pj's crash and we have different sub grabbing procedures |
| 21:28.33 | mvanbaak | nice ! |
| 21:28.37 | wedhorn | the old phones basically grab l->activesub and the new phones find the sub based on ref etc |
| 21:28.50 | mvanbaak | yeah |
| 21:29.42 | wedhorn | from memory I think pj's phone(s) use activesub as well (no ref in the packet) |
| 21:30.20 | wedhorn | the problem is fixing it. When I start coding I end up trying to rewrite the sub handling :/ |
| 21:31.30 | mvanbaak | ug, that's sad |
| 21:32.02 | wedhorn | yeah, it's embedded in one of the messes that we plan on rewriting |
| 21:32.14 | mvanbaak | yeah |
| 21:32.23 | mvanbaak | I see it |
| 21:32.31 | mvanbaak | I dont see any other way to fix it neither |
| 21:32.50 | mvanbaak | no 'quick' fixes there |
| 21:33.31 | wedhorn | I was thinking of adding some delays into the code which should make the cash easier to replicate (I haven't been able to get another crash) |
| 21:33.42 | wedhorn | but where? |
| 21:33.54 | *** join/#asterisk-dev russellb (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 21:33.54 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 21:34.03 | mvanbaak | wb russellb |
| 21:34.32 | mvanbaak | gheh, that was fast |
| 21:34.37 | *** join/#asterisk-dev russellb (n=russellb@asterisk/developer-and-stable-maintainer/drumkilla) |
| 21:34.37 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 21:34.45 | mvanbaak | wedhorn: I dont know. |
| 21:35.01 | mvanbaak | wedhorn: stupid idea, I know, but ..... |
| 21:35.13 | mvanbaak | wedhorn: cant we lock the whole stuff during hangup ? |
| 21:35.15 | wedhorn | no such thing with skinny |
| 21:35.18 | russellb | there we go |
| 21:35.38 | mvanbaak | hey russellb, wb |
| 21:36.12 | wedhorn | yeah, but you need to lock both the offhook and onhook stuff, as well as the hangup stuff from core and wherever else we start and stop calls |
| 21:36.13 | mvanbaak | russellb: testing my modified mkrelease on our sourceforge.net hosted project now :) |
| 21:36.16 | mvanbaak | hurray |
| 21:37.13 | mvanbaak | russellb: I found out the mkrelease script is good at finding bugs in libapache2-svn on Debian :) |
| 21:37.25 | mvanbaak | found 3 bugs in their packages with it :) |
| 21:37.29 | russellb | heh, neat |
| 21:37.57 | mvanbaak | svn export https://my.debian.box/svn/project/branches/stable/ChangeLog OldLog |
| 21:38.11 | mvanbaak | that coredumps Debian apache2+svn |
| 21:58.39 | *** join/#asterisk-dev snuff-one (n=snuf@C-61-68-151-217.bur.connect.net.au) |
| 22:08.31 | *** join/#asterisk-dev snuff-one (n=snuf@C-61-68-151-217.bur.connect.net.au) |
| 22:43.27 | mvanbaak | yay, I have mkrelease create a release+download on sourceforge.net now \o/ |
| 22:43.35 | mvanbaak | all automagically |
| 22:49.52 | mvanbaak | gheh, never expected it to work with sf.net |
| 22:49.55 | mvanbaak | but it does |
| 22:54.07 | seanbright | hmmm |
| 22:54.36 | seanbright | so here is what i am trying to find out |
| 22:54.49 | seanbright | you have 3 SIP UAs |
| 22:55.08 | mvanbaak | FAIL |
| 22:55.09 | seanbright | A, B, and C. C is subscribed to the device state of B. |
| 22:55.09 | mvanbaak | ;) |
| 22:55.26 | seanbright | A calls B, causing the device state of SIP/B to change to Ringing |
| 22:56.16 | seanbright | when C is NOTIFY'd, i want to determine what caused B to start ringing (in this case, A) |
| 22:56.36 | wedhorn | mvanbaak: you still got your crash backtrace? |
| 22:56.42 | seanbright | and i'm not convinced there is a good way of doing that. |
| 22:56.57 | mvanbaak | wedhorn: yes |
| 22:57.23 | mvanbaak | wedhorn: well, I still have the core file and I did not recompile yet |
| 22:57.33 | mvanbaak | wedhorn: so I can generate it for you |
| 22:57.38 | wedhorn | can you tell me if ast->tech_pvt and sub in skinny_hangup are the same or different (should be the same) |
| 22:58.41 | russellb | seanbright: i don't think there is a good way of doing that ... |
| 22:58.52 | seanbright | russellb: sweet! |
| 22:58.58 | russellb | seanbright: in fact, you shouldn't be looking at the state of B at all, anyway |
| 22:59.08 | russellb | seanbright: you need to be paying attention to _extension_ states |
| 22:59.15 | russellb | which is != state of a SIP UA |
| 22:59.38 | seanbright | hmmm. |
| 22:59.39 | russellb | all you know is an extension is ringing ... |
| 22:59.43 | seanbright | right |
| 22:59.45 | russellb | why? who cares why? :) |
| 22:59.45 | mvanbaak | wedhorn: http://pastebin.com/d72fcfd63 |
| 22:59.49 | russellb | it just is :) |
| 23:00.26 | seanbright | russellb: well... |
| 23:00.29 | russellb | WELL |
| 23:00.46 | wedhorn | mvanbaak: what's ast->tech_pvt is skinny_hangup? |
| 23:00.52 | seanbright | russellb: when extension B starts ringing, i want to display some info on C's screen. |
| 23:01.00 | seanbright | russellb: specifically, who is calling. |
| 23:01.04 | JunK-Y | russellb: is the astridevcon list has been offially released? |
| 23:01.34 | russellb | seanbright: wow, that's tricky |
| 23:01.39 | seanbright | russellb: yes, i know. |
| 23:01.51 | russellb | seanbright: in fact ... I'm going to say that's just not possible in our current architecture |
| 23:02.31 | seanbright | ouch |
| 23:02.32 | russellb | so if we were really going to do this ... |
| 23:02.44 | seanbright | ok, well that sucks |
| 23:02.49 | seanbright | rolls back the last few hours |
| 23:02.52 | russellb | info about who is causing the extension to ring would need to be included in the extension state change |
| 23:03.01 | seanbright | right |
| 23:03.04 | russellb | and that's just very much non-trivial |
| 23:03.10 | russellb | and out of the scope of this project IMO |
| 23:03.11 | seanbright | agreed. |
| 23:03.18 | russellb | did it already do something like that? :( |
| 23:03.27 | seanbright | no |
| 23:03.30 | seanbright | well |
| 23:03.35 | mvanbaak | wedhorn: ??? |
| 23:03.47 | seanbright | the proposed patch changes all of the devstate stuff to pass a cid name and num around |
| 23:03.55 | russellb | seanbright: ah, interesting |
| 23:04.01 | seanbright | but limited |
| 23:04.03 | seanbright | and lame |
| 23:04.05 | russellb | heh |
| 23:04.12 | russellb | ok, well, just forget about that part for now |
| 23:04.20 | wedhorn | move "up" to skinny_hangup and then "print ast->tech_pvt" |
| 23:04.22 | seanbright | forgotten |
| 23:04.38 | russellb | being a multiprotocol system makes stuff like this so much more difficult |
| 23:04.40 | russellb | heh |
| 23:04.42 | russellb | but fun! <3 |
| 23:04.44 | seanbright | yeah... |
| 23:05.01 | seanbright | sending the who-caused-this info around would be... interesting |
| 23:05.17 | russellb | no doubt! |
| 23:05.26 | russellb | and i'll think about it |
| 23:05.41 | russellb | to see if i can think of a good "architecturally compatible" way of doing it |
| 23:05.41 | seanbright | there are a bunch of cases where it would be completely worthless info |
| 23:05.50 | mvanbaak | wedhorn: $1 = (void *) 0x828deb0 |
| 23:06.15 | seanbright | m'kay |
| 23:06.17 | wedhorn | ok, they're the same, damn |
| 23:06.50 | seanbright | russellb: and as far as i know, i am paying attention to extension state... |
| 23:06.51 | wedhorn | actually, while you're there, how about sub->parent |
| 23:06.57 | russellb | seanbright: probably so |
| 23:06.59 | seanbright | exten => 100,hint,SIP/100 |
| 23:07.01 | seanbright | ? |
| 23:07.03 | russellb | seanbright: just making sure we're on the same page |
| 23:07.04 | wedhorn | and l->parent |
| 23:07.04 | russellb | nods |
| 23:07.19 | seanbright | yeah, i've never been good with terminology |
| 23:07.35 | russellb | well in that case, they end up being the same state |
| 23:07.40 | seanbright | right |
| 23:07.41 | mvanbaak | wedhorn: |
| 23:07.45 | mvanbaak | (gdb) print sub->parent |
| 23:07.45 | mvanbaak | $2 = (struct skinny_line *) 0x8293c70 |
| 23:07.45 | mvanbaak | (gdb) print l->parent |
| 23:07.45 | mvanbaak | $3 = (struct skinny_device *) 0x0 |
| 23:08.11 | russellb | but, exten => 100,hint,SIP/100&SIP/101&IAX2/foo&Zap/42&Console/default |
| 23:08.12 | russellb | :-p |
| 23:08.17 | seanbright | yeah |
| 23:08.20 | seanbright | "Unavailable" |
| 23:08.21 | seanbright | heh |
| 23:08.48 | seanbright | at this point i'm just using the devstate callbacks |
| 23:09.38 | mvanbaak | hint,Zap/42 should return: Always bring your towel |
| 23:10.03 | mvanbaak | or: Dont panic |
| 23:10.10 | mvanbaak | pick the one you like best |
| 23:10.29 | wedhorn | mvanbaak: howabout sub->related, and if so, sub->related->related |
| 23:11.08 | russellb | the devstate callbacks? |
| 23:11.09 | russellb | eh? |
| 23:11.11 | seanbright | that was a lie |
| 23:11.36 | mvanbaak | wedhorn: |
| 23:11.38 | mvanbaak | (gdb) print sub->related |
| 23:11.38 | mvanbaak | $4 = (struct skinny_subchannel *) 0x828e778 |
| 23:11.39 | mvanbaak | (gdb) print sub->related->related |
| 23:11.39 | mvanbaak | $5 = (struct skinny_subchannel *) 0xb7da44f8 |
| 23:11.46 | seanbright | ~pb |
| 23:11.46 | jbot | [~pb] A "pastebin" is a web-based service where you can paste anything over 3 lines without flooding the channel. Here are links to a few : http://www.pastebin.com , http://pastebin.ca , http://channels.debian.net/paste , http://paste.lisp.org , http://www.rafb.net/paste |
| 23:11.49 | seanbright | heh |
| 23:11.59 | mvanbaak | oh shaddap |
| 23:12.19 | wedhorn | just paste 'em two at a time ;) |
| 23:12.20 | seanbright | russellb: basically just hooking in when NOTIFYs are sent out |
| 23:12.32 | russellb | nods |
| 23:12.44 | russellb | which is handled by an _extension state_ callback :-p |
| 23:12.47 | seanbright | since SUBSCRIBE/NOTIFY is extension specific and not device |
| 23:12.50 | seanbright | yes |
| 23:12.55 | seanbright | terminology ^^^ |
| 23:13.05 | seanbright | i'll practice |
| 23:13.20 | russellb | it's all good |
| 23:14.06 | wedhorn | mvanbaak: sub->owner - hopefully the last |
| 23:14.19 | seanbright | on the upside... i'm feeling 75% confident that i 60% know what i am doing at this point |
| 23:17.23 | *** part/#asterisk-dev korihor (n=korihor@201.211.168.130) |
| 23:21.53 | mvanbaak | wedhorn: |
| 23:21.54 | mvanbaak | (gdb) print sub->owner |
| 23:21.54 | mvanbaak | $6 = (struct ast_channel *) 0x20 |
| 23:23.23 | wedhorn | that's ugly. Looks like ast_channel is point to sub garbage, that is probably fixable in the existing code |
| 23:26.19 | mvanbaak | sorry if I dont have an answer |
| 23:26.39 | mvanbaak | I'm working on 3 projects right now, and it's 1:26 |
| 23:27.18 | mvanbaak | wedhorn: http://cia.vc/stats/author/mvanbaak |
| 23:30.24 | wedhorn | mvanbaak: it's ok, I recompiled without thinking and can't get another crash, but I think our crashes are due to my excessive freeing of sub. Doesn't help pj and his original crash though |
| 23:31.22 | wedhorn | I'll fix memleak3 (should be fairly easy) and see what happens |
| 23:33.21 | *** join/#asterisk-dev snuff-one (n=snuf@C-61-68-151-217.bur.connect.net.au) |