| 00:41.45 | *** join/#asterisk-dev Deeewayne (n=dwayne@c-71-228-179-90.hsd1.al.comcast.net) |
| 00:41.46 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 01:42.10 | *** join/#asterisk-dev moy (n=moy@CPE001cdfec4cee-CM00080dab8485.cpe.net.cable.rogers.com) |
| 01:43.17 | *** join/#asterisk-dev pyite_ (n=pyite@unaffiliated/pyite) |
| 01:55.58 | *** join/#asterisk-dev pyite_ (n=pyite@unaffiliated/pyite) |
| 01:56.24 | *** part/#asterisk-dev pyite_ (n=pyite@unaffiliated/pyite) |
| 02:05.37 | *** join/#asterisk-dev denon (i=root@synapse.subneural.net) |
| 02:26.53 | philipp64 | can someone have a quick look at 15793? |
| 02:27.21 | russellb | M15793 |
| 02:27.23 | MuffinMan | [new] [DAHDI-tools] General 0015793: [patch] Missing slash causes wrong file to be removed, which fails silently reported by pprindeville (Karma: +4.00) https://issues.asterisk.org/view.php?id=15793 |
| 02:27.27 | philipp64 | show of hands: how many are here against their will? |
| 02:27.32 | russellb | raises hand |
| 02:27.51 | philipp64 | could be worse... they could be cuffed... |
| 02:28.41 | philipp64 | it's a one-character fix. |
| 02:28.45 | philipp64 | could we fast-track it? |
| 02:34.43 | russellb | someone will get to it ... have patience! |
| 02:34.51 | russellb | you seem to do this for every single issue you post ... |
| 02:35.29 | snuff-work | thinks isn't it late for russ to be up |
| 02:36.07 | *** join/#asterisk-dev qdk (n=qdk@0x573d8d8b.bynqu1.dynamic.dsl.tele.dk) [NETSPLIT VICTIM] |
| 02:50.47 | ctooley | I'm running into an issue and I'm thinking it might be in the AMI queue. What's the cps capacity of a run of the mill quad core box when doing originates via AMI? |
| 02:51.20 | snuff-work | has no idea |
| 02:53.39 | JunK-Y | ctooley: no clue, how many do you have? |
| 02:56.48 | ctooley | We're attempting to originate hundreds per minute, but we're not getting past a certain point. We don't seem to be able to get past 10 cps. |
| 02:57.03 | ctooley | We really need to be able to get to at least 30 |
| 02:58.19 | snuff-work | must try dtracing * sometime with these cases |
| 02:58.50 | JunK-Y | they are never been processed or just taking long time to originate? |
| 02:59.31 | snuff-work | ami originates are kinda like call files.. |
| 03:00.31 | ctooley | They're just getting queued up and slowly being processed |
| 03:00.42 | JunK-Y | i much prefer originate then .call |
| 03:00.52 | JunK-Y | ctooley: are you going to astricon btw? |
| 03:01.17 | ctooley | JunK-Y, Not at the moment, but things change on a daily basis. |
| 03:02.31 | JunK-Y | kk |
| 03:03.07 | JunK-Y | im looking for a "roomate" to share a room at astricon, i already made the reservation, its a 2 beds non-smoking room. |
| 03:04.03 | ctooley | Well, if I go I'll be dragging my pregnant wife along to visit her friends in the Phoenix area. |
| 03:04.29 | ctooley | Probably not the kind of "roommate(s)" you're looking for. :-) |
| 03:04.49 | JunK-Y | how hot are their friends :P |
| 03:04.50 | philipp64 | russellb: the impatience of youth (cough). |
| 03:05.03 | philipp64 | is actually wheezing, not coughing... |
| 03:05.59 | JunK-Y | ur gf is pregnant, congrats, i wish health to ur wife and baby |
| 03:06.00 | ctooley | JunK-Y, I don't think her friends are what you're looking for. |
| 03:07.13 | JunK-Y | i see! |
| 03:08.02 | ctooley | Well... she's my fiance` at the moment, she'll be my wife by then. |
| 03:09.11 | JunK-Y | for how long are you together? |
| 03:15.01 | Juggie | is there a way to modify an agent penalty in a queue on the fly via ami? |
| 03:20.25 | JunK-Y | Juggie: not that I know |
| 03:20.45 | *** join/#asterisk-dev pyite_ (n=pyite@unaffiliated/pyite) |
| 03:20.59 | ctooley | JunK-Y, We've been dating since January, I ordered a ring in April, we found out she was pregnant in May and I proposed in June. |
| 03:21.19 | *** part/#asterisk-dev pyite_ (n=pyite@unaffiliated/pyite) |
| 03:21.20 | JunK-Y | cool, cool. |
| 03:24.31 | Corydon76-dig | ctooley: when's your (next) vasectomy scheduled? |
| 03:30.42 | Juggie | ctooley, sounds like your on fast forward there buddy :) |
| 03:32.14 | ctooley | Corydon76-dig, We're going to work on that post-baby |
| 03:32.21 | ctooley | Juggie, Yeah... something like that |
| 03:41.52 | Corydon76-dig | Teryl and I have been trying forever to get pregnant... it just isn't taking for some reason... |
| 04:10.49 | *** join/#asterisk-dev rizwank (n=rizwank@pool-71-118-51-238.lsanca.dsl-w.verizon.net) |
| 04:10.54 | *** part/#asterisk-dev rizwank (n=rizwank@pool-71-118-51-238.lsanca.dsl-w.verizon.net) |
| 04:15.25 | *** join/#asterisk-dev errotan (n=errotan@62.201.122.164) |
| 04:20.37 | *** join/#asterisk-dev itamarjp (n=itamar@189-015-164-078.xd-dynamic.ctbcnetsuper.com.br) |
| 04:37.42 | snuff-work | hehe |
| 05:32.29 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 05:32.29 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 05:41.19 | *** join/#asterisk-dev lmsteffan (n=laurent@reef.ac-noumea.nc) |
| 05:47.46 | *** join/#asterisk-dev |Cybex| (n=John@atwork-26.r-212.178.82.atwork.nl) |
| 06:44.49 | mvanbaak | mornin |
| 06:48.41 | *** join/#asterisk-dev sergee (n=serg@voip1.west-call.com) |
| 06:52.58 | snuff-work | ello mvanbaak |
| 07:15.49 | *** join/#asterisk-dev tamiel (n=tamiel@213.30.183.226) |
| 07:29.31 | sergee | oej: hi there! |
| 07:31.09 | oej | Morning |
| 07:32.43 | sergee | oej: is there any example of saving sip_pvt when channel is gone? |
| 07:33.06 | oej | It's always saved up to 30 secs after channel is gone. Always. |
| 07:33.13 | oej | We need to be able to handle retransmits |
| 07:33.40 | oej | Maybe not if we send bye and they actually confirm it with 200 OK though |
| 07:34.38 | sergee | oej: as far as i understand, there is no way to access sip_pvt when channel is gone, right? |
| 07:35.01 | oej | When channel is gone, you're not in the dialplan any more, right? |
| 07:35.17 | oej | The sip_pvt disconnects from the channel at hangup, but remains all by itself. |
| 07:35.25 | sergee | oej: why? i'm in the 'h' extension |
| 07:35.49 | oej | In the H extension I believe both the ast_channel and the SIP_pvt remains |
| 07:36.05 | sergee | oej: "remote" call-leg is gone, and "near" cal leg is still there |
| 07:36.17 | oej | Right |
| 07:36.33 | oej | But it's down |
| 07:36.33 | sergee | peer1 - asterisk - peer2 |
| 07:36.40 | sergee | peer2 sends BYE |
| 07:36.55 | oej | Righto |
| 07:37.12 | oej | check how the rtpaudioqos and stuff is handled |
| 07:37.48 | oej | hmmm |
| 07:38.17 | oej | This is interesting |
| 07:38.46 | oej | In some cases, these headers are sent in the 200 OK if we send BYE, right |
| 07:41.19 | *** join/#asterisk-dev ZX81 (n=Matt_Rid@121.74.14.197) |
| 07:43.21 | *** join/#asterisk-dev ZX81 (n=Matt_Rid@121.74.14.197) |
| 07:53.56 | sergee | oej: I am sorry to bother you again, but it seems like i missing something, |
| 07:54.09 | sergee | oej: the main question i have: |
| 07:54.22 | *** part/#asterisk-dev ZX81 (n=Matt_Rid@121.74.14.197) |
| 07:54.34 | sergee | oej: how can we access sip_pvt from dialplan when the channel is gone? |
| 07:54.50 | oej | There are no good answers to that... |
| 07:55.13 | oej | You have the bridgepvtid as a channel variable, right |
| 07:55.24 | oej | I think that's the only trace of the remote sip pvt you have |
| 07:55.44 | sergee | oej: PS: actualy i study RTPAUDIOQOS and made M15800 inspired by M15800.. |
| 07:55.58 | sergee | oej: ok thank you, i'll dig that way |
| 07:56.30 | oej | This is an architectural problem. |
| 07:56.39 | oej | Now, if you create a channel datastore on the inbound channel |
| 07:57.03 | oej | We could use that for many things, like the QOS values |
| 07:57.19 | oej | I think that's the way forward really |
| 07:57.26 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@62.90.10.53) |
| 07:57.27 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 07:57.39 | oej | The question is how much data we have before the bridge is down |
| 07:58.31 | oej | If we receive ast_hangup from the incoming channel, I think that the sip channel disconnects and have a life of it's own. At that point, there's no way to connect to the previously bridged channel in a reliable way. |
| 08:02.02 | oej | This is a very interesting issue |
| 08:02.41 | sergee | oej: can you clarify what do you mean by "inbound channel" in this case? |
| 08:03.35 | sergee | oej: Inbound channel = reciever of INVITE ? |
| 08:10.06 | *** join/#asterisk-dev Pazzo (n=ugelt@reserved-225136.rol.raiffeisen.net) |
| 08:10.08 | oej | Peer1 -> pbx -> peer2 |
| 08:10.20 | oej | peer1 sets up the call to the pbx, the pbx sets up the call to peer2 |
| 08:10.30 | oej | peer1->pbx is inbound, pbx->peer2 is outbound |
| 08:11.37 | sergee | oej: ok thanks, so we'll initialise "cross-channel storage", right? storage for chan1 @chan2, and storage for chan2 @chan1? |
| 08:12.10 | sergee | hmm, actualy we don't need storage for chan1 @chan2 |
| 08:12.20 | sergee | since we can acess it in 'h' |
| 08:13.51 | oej | The big question here is if chan2 can reach storage in chan1 at hangup time |
| 08:14.10 | oej | If we send BYE we want data from the 200 ok - can we still handle that? I guess that the bridge is gone by then |
| 08:19.46 | sergee | yes bridge is gone before 200ok |
| 08:21.55 | sergee | oej: so to handle "BYE case" i simply need to put all headers from the BYE into datastorage attached to incoming channel, right? |
| 08:23.14 | oej | for the incoming by from peer2 |
| 08:23.29 | sergee | oej: and it would be harder to get headers from 200OK, btw hardware at my disposal (linksys 2102, cisco 5350) doesn't add custom headers to 200OK, they add it only to BYE. |
| 08:23.29 | oej | But that doesn't solve the issue. If we implement this, we will get requirements to solve all cases |
| 08:23.44 | oej | That's weird. |
| 08:24.01 | oej | So they only report quality if they do the hangup? |
| 08:24.08 | sergee | give me 5 minutes, i'll run tests again |
| 08:25.07 | *** join/#asterisk-dev _ys (n=ys@xgw.infor.net.ru) |
| 08:30.21 | sergee | oej: tested with 5350, cisco add header "Reason: Q.850;cause=31" only to BYE and not to 200OK, will test linksys now |
| 08:31.51 | sergee | oej: linksys adds to both, 200OK and BYE |
| 08:32.46 | sergee | oej: probably cisco doesn't add it's header to 200OK because ISDN network wasn't the saurce of disconnect |
| 08:36.32 | *** join/#asterisk-dev sergee (n=serg@195.94.224.202) |
| 08:41.37 | oej | Yes, the reason is only added to bye |
| 08:41.45 | oej | But the qos I would guess goes in both |
| 08:42.06 | oej | We should propably parse the reason header properly on incoming and set hangupcause |
| 08:48.46 | *** join/#asterisk-dev ms110 (n=shehzad@122.169.77.107) |
| 08:49.43 | ms110 | hello every one |
| 08:50.05 | *** join/#asterisk-dev ZX81 (n=Matt_Rid@121.74.14.197) |
| 08:53.13 | sergee | oej: should we consider Cisco's implementation as standard? i mean other vendors could use another header/format for isdn Reason.. |
| 08:53.39 | sergee | oej: on the other hand i saw the same header with the same format from huawei |
| 08:53.45 | oej | The reason header is RFC standard |
| 08:53.54 | oej | What we're using is non-standard and we should change |
| 08:54.26 | oej | RFC 3326 |
| 08:59.05 | sergee | oej: thanks! |
| 09:00.06 | oej | So let's take the REason stuff as separate work, and then come back to the "capture stuff from BYE/200 OK on BYE" messages... That part requires a lot of work. |
| 09:25.39 | *** join/#asterisk-dev obnauticus (n=l@about/windows/regular/obnauticus) |
| 09:44.42 | ZX81 | oej lol at you retweeting me quoting you :) |
| 09:44.58 | oej | It's a loop :-) |
| 09:45.08 | ZX81 | totally - we'll destroy the universe! |
| 10:34.03 | *** part/#asterisk-dev ZX81 (n=Matt_Rid@121.74.14.197) |
| 10:59.18 | *** join/#asterisk-dev |Cybex| (n=John@atwork-26.r-212.178.82.atwork.nl) |
| 11:20.53 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:20.53 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 11:46.39 | *** join/#asterisk-dev Bertrix (n=Bertrix@94-225-128-217.access.telenet.be) |
| 11:46.52 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 11:46.52 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 11:46.57 | Bertrix | Where would I start if I wanted to write a hardware driver? |
| 11:49.04 | oej | With some hardware I guess |
| 11:49.09 | oej | :-) |
| 11:49.30 | mvanbaak | ooooooooh, oej being the smart one today |
| 11:49.45 | leifmadsen | +donkey :) |
| 11:49.53 | oej | Yes, it's my turn. I think you're on this friday, mvanbaak. |
| 11:49.53 | Bertrix | I have the hardware ;) |
| 11:50.11 | leifmadsen | Bertrix: I'd probably look at the existing hardware drivers I guess, and the channel drivers associated with it |
| 11:50.16 | mvanbaak | oej: sure thing. |
| 11:50.40 | leifmadsen | Bertrix: http://www.asterisk.org/developers is also probably useful |
| 11:50.43 | oej | Bertrix: Can you describe it a bit more. "hardware" can be anything from a 300 baud modem to a pair of scissors... |
| 11:50.52 | Bertrix | A line card. |
| 11:51.05 | leifmadsen | ...for? |
| 11:51.07 | oej | Then go check if the dahdi drivers would work for you |
| 11:51.08 | Bertrix | I designed one, and it works with my own software but I would like to use it with asterisk |
| 11:51.18 | Bertrix | POTS |
| 11:53.06 | Bertrix | To the pc it is seen as a soundcard with a output and input channel per line and one serial port for all channels to set and read out things such as ringing and off-hook |
| 11:53.14 | oej | Then dahdi is for you. If you can write a driver that works with the dahdi kernel driver, you don't need to change anything inside asterisk |
| 11:53.28 | Bertrix | ah |
| 11:53.39 | Bertrix | thanks oej. I'll look into it |
| 11:53.40 | oej | Oh, that is similar to mobile drivers I've seen |
| 11:54.04 | oej | They hacked chan_alsa or chan_oss - our drivers for sound cards |
| 11:54.10 | oej | Maybe that is a way for you too |
| 12:05.04 | tzafrir_laptop | how do you dial with chan_alsa / chan_oss ? |
| 12:06.04 | oej | from the cli |
| 12:06.18 | oej | very good for testing :-) |
| 12:06.38 | tzafrir_laptop | yeah, but sent in-line? as some sort of signalling? |
| 12:07.17 | *** join/#asterisk-dev Hatrix (n=Hatrix@213.201.24.127.static.user.ono.com) |
| 12:14.29 | Hatrix | hello guys, i have a *very* strange compile issue, i am using stock debian package and i am trying to recompile with no optimizations etc. |
| 12:14.35 | Hatrix | and i get this: |
| 12:14.38 | Hatrix | <PROTECTED> |
| 12:14.46 | tzanger | hmm that reminds me |
| 12:14.59 | Hatrix | but i compiled it like 3 weeks ago?!?! |
| 12:14.59 | tzanger | I gotta make my driver tell zaptel^Wdahdi about dtmf events |
| 12:17.04 | Hatrix | a distclean does not help either |
| 12:21.55 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 12:21.55 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 12:28.51 | tzafrir_laptop | Hatrix, where do you try to build it on? Anyway, most maintainers of that package are in #debian-voip in irc.debian.org |
| 12:28.59 | tzafrir_laptop | (OFTC) |
| 12:28.59 | *** join/#asterisk-dev Victor_Yure (n=victor@unaffiliated/victoryure/x-837844) |
| 12:38.36 | Hatrix | h tzafrir_laptop i obviosly build it on debian, but 32bit architecture ... or what are you exactly asking regarding "where"? |
| 12:39.09 | tzafrir_laptop | how did you build it? dpkg-buildpackage (or debuild or whatever)? |
| 12:39.24 | tzafrir_laptop | Did you add some patches of your own? |
| 12:41.26 | Hatrix | tzafir i build with dpkg-buildpackage, i only included one patch of my own, which fixes a core-dump with app_queue, the patch is taken from a more recent svn checkout, but it compiled before with this patch! |
| 12:42.20 | tzafrir_laptop | What patch? Any bug open for that with the Debian package? |
| 12:44.27 | Hatrix | this is the patch: |
| 12:44.27 | Hatrix | http://pastebin.com/m2076c9ff |
| 12:45.26 | Hatrix | I did not open a bug for this debian package |
| 12:47.10 | Hatrix | but as you can see, the patch has nothing to do with this error-massge .. |
| 12:48.25 | tzafrir_laptop | hmm.... quilt has no problem with diff -c patches? |
| 12:48.45 | Hatrix | no, it applies nicely, does not give me any errors |
| 12:49.19 | Hatrix | Applying patch runsolutions/app_queue |
| 12:49.19 | Hatrix | patching file apps/app_queue.c |
| 12:49.35 | Hatrix | this is the only output i get, runs through cleanly |
| 12:50.50 | tzafrir_laptop | have you built it with malloc debugging or something similar? |
| 12:51.12 | *** join/#asterisk-dev qdk (n=qdk@81.7.168.130) |
| 12:52.08 | Hatrix | moment ... i enabled: dont optimize, thread debug and channel lock debugging |
| 13:11.09 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 13:11.09 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 13:17.45 | Hatrix | hmm |
| 13:45.01 | *** join/#asterisk-dev russellb_ (n=russell@asterisk/digium-open-source-team-lead/russellb) |
| 13:45.01 | *** mode/#asterisk-dev [+o russellb_] by ChanServ |
| 13:47.13 | *** join/#asterisk-dev MuffinMan (n=muffinma@asterisk/issue-tracker-bot/muffinman) |
| 13:48.30 | *** join/#asterisk-dev russellb (n=russellb@asterisk/digium-open-source-team-lead/russellb) |
| 13:48.30 | *** mode/#asterisk-dev [+o russellb] by ChanServ |
| 13:49.47 | *** join/#asterisk-dev Hatrix (n=Hatrix@213.201.24.127.static.user.ono.com) |
| 13:51.27 | *** join/#asterisk-dev file (n=file@asterisk/developer-and-muffin-lover/file) |
| 13:51.27 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 14:02.09 | oej | That was a quick visit by russellb... |
| 14:02.39 | russellb | :-) |
| 14:03.50 | oej | It was your other persona leaving... Aha! |
| 14:04.11 | oej | Russellb: Just wanted to check if you had time to re-review the mutestream code on reviewboard? |
| 14:04.35 | russellb | not yet |
| 14:04.44 | russellb | but I can certainly do so today |
| 14:05.00 | oej | np, just wanted to send a gentle reminder... ;-) |
| 14:05.17 | oej | I think I addressed all your comments. Thansk! |
| 14:05.20 | oej | Thanks! |
| 14:05.32 | Hatrix | ni russel, i get lots of utils/ael.flex:241: undefined reference to `_ast_malloc' and utils/ael.flex:242: undefined reference to `ast_copy_string' compile errors, i found out in google that at one point in time you had the same problem? |
| 14:09.06 | russellb | try "make distclean" first, just in case |
| 14:09.18 | Hatrix | russellb: i did this |
| 14:10.41 | Hatrix | i also used a clean directory to compile, it compiled 3 weeks ago |
| 14:10.45 | Hatrix | and today it does not |
| 14:10.52 | Hatrix | and it's driving me NUTS :-) |
| 14:10.58 | Hatrix | and i do not why |
| 14:11.12 | Hatrix | i just wanted to compile the package with don't optimize to get a usefull coredump |
| 14:11.14 | Hatrix | *sigh* |
| 14:11.54 | russellb | oej: review posted |
| 14:12.14 | oej | me too, posted another review request ;-) |
| 14:12.41 | Hatrix | it says this before all the errors: aelparse.o: In function `ael_yylex': |
| 14:13.06 | Hatrix | as i do not use ael, can i just exclude it from the build process? but i guess it's referenced a lot |
| 14:20.48 | tzafrir_laptop | Hatrix, well, you don't really need aelparse |
| 14:21.01 | tzafrir_laptop | However I suspect it just happened to be the first one |
| 14:22.34 | Hatrix | ok, how can i exclude it just to be sure? i also downloaded right now the sources (apt-get source asterisk) and did nothing but fakeroot dpkg-b... and i have the same problem!! ?? !! ?? |
| 14:22.41 | *** join/#asterisk-dev kpfleming (n=kpflemin@asterisk/digium-director-of-software-tech/kpfleming) |
| 14:22.41 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 14:23.32 | *** join/#asterisk-dev putnopvut (n=putnopvu@asterisk/master-of-queues/mmichelson) |
| 14:23.32 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:24.12 | tzafrir_laptop | Hatrix, I suppose they weren't tested with those debug options |
| 14:24.29 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 14:24.29 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 14:24.41 | tzafrir_laptop | Such a link issue wopuld probably happen only to stuff under utils/ |
| 14:26.35 | *** part/#asterisk-dev |Cybex| (n=John@atwork-26.r-212.178.82.atwork.nl) |
| 14:27.21 | Hatrix | uffff, |
| 14:27.25 | Hatrix | i guess you where right |
| 14:28.08 | *** join/#asterisk-dev The_Boy_Wonder (n=davidvos@asterisk/batman-developer/dvossel) |
| 14:28.08 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 14:30.20 | Hatrix | but i need to compile without optimizations, what do i do now? |
| 14:30.59 | *** join/#asterisk-dev Deeewayne (n=dwayne@75.76.254.162) |
| 14:31.00 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 14:32.39 | Hatrix | as soon as i have OPTIMIZE=-O0 i cannot compile anymore ... |
| 14:36.00 | oej | russellb: Thanks! Will fix. |
| 14:37.18 | Hatrix | so, if i want to have no optimization in the debian package i am screwed? how do i report my crashes than, right now the core-dumps are not usefull, it's really driving me out of my mind ... |
| 14:41.11 | kpfleming | the debian developers could make 'debug' versions of the packages available, that are built with debugging symbols and no optimization. that's what we do for AsteriskNOW and RPM distributions. |
| 14:42.04 | tzafrir_laptop | debugging symbols: are in a separate package already |
| 14:42.13 | tzafrir_laptop | (you mostly get that for free) |
| 14:42.17 | kpfleming | but they aren't useful if the binaries are optimized |
| 14:42.23 | tzafrir_laptop | why? |
| 14:42.49 | tzafrir_laptop | the non-optimized binary is, well, sub-optimal |
| 14:43.22 | tzafrir_laptop | fuirthermore, IIRC a non-optimized build makes asterisk explicitly incompatible with modules, |
| 14:43.30 | kpfleming | because the compiler inlines so much code and moves things around so much that functions completely disappear and line number references point to useless locations |
| 14:43.36 | tzafrir_laptop | which forces providing such packaging for all modules packages |
| 14:43.59 | kpfleming | why would it be incompatible with modules? |
| 14:44.23 | tzafrir_laptop | The build flags. Not sure which of them, though |
| 14:44.51 | kpfleming | that's not optimization |
| 14:46.21 | tzafrir_laptop | if it were a single binary, this was simple. But in this case we'll need to either make conflicting packages (pain for users) or relocate astmoddir in brute force |
| 14:47.11 | tzafrir_laptop | and then after we'll do that we'll get an equivalent complaint about not providing binaries with malloc debugging or whatever |
| 14:47.48 | tzafrir_laptop | Which is why I generally prefer to use live_ast in such cases and rebuild from source |
| 14:47.50 | kpfleming | yes. one of the burdens of being a packager, unfortunately. |
| 14:50.16 | Hatrix | what is live_ast? |
| 14:50.57 | Hatrix | so, basically, i am frelled and can not use a non-optimized debian built? |
| 14:52.31 | tzafrir_laptop | kpfleming, DONT_OPTIMIZE changes AST_BUILDOPT_CHECKSUM |
| 14:52.44 | tzafrir_laptop | err.. AST_BUILDOPT_SUM |
| 14:52.50 | kpfleming | hmm |
| 14:52.55 | kpfleming | we should fix that then |
| 14:53.08 | kpfleming | DONT_OPTIMIZE does not change the ABI between the core and modules |
| 14:54.25 | Hatrix | ok, so, in short, is there anything i can do NOW do get a non optimized build? |
| 14:58.25 | *** join/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 14:58.27 | tzafrir_laptop | I suppose that this is a build issue that was fixed later in the 1.4 cycle |
| 14:58.38 | tzafrir_laptop | I'll have to look into it |
| 14:59.02 | tzafrir_laptop | most of the things in utils/ are not really needed |
| 14:59.50 | kpfleming | correct, i wouldn't even package them in a distro package if i was doing it |
| 15:00.45 | Hatrix | ok, so, can i exclude it? how do i do this without breaking everything? i rather would install a non-optimized build because i want to have a good look at the core dump the next time * kills itself |
| 15:01.25 | tzafrir_laptop | well, we generally try to package the results of 'make install' |
| 15:02.55 | kpfleming | tzafrir_laptop: yeah, and i'm thinking we should stop installing that stuff |
| 15:04.13 | oej | russellb: Over to you, sir :-) |
| 15:06.47 | *** join/#asterisk-dev eliel (n=eliels@200.61.172.61) |
| 15:06.48 | *** mode/#asterisk-dev [+o eliel] by ChanServ |
| 15:11.00 | *** join/#asterisk-dev xpot-mobile (n=james@mx0.synergyconsultant.net) |
| 15:16.16 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 15:23.50 | Hatrix | tzafrir_laptop: :-) ... hmm, any news? or do i have to wait until you have a solution? if so, how can we stay in contact? as i really need this .... |
| 15:25.58 | *** join/#asterisk-dev anthm (n=anthm@freeswitch/developer/anthm) |
| 15:26.46 | Deeewayne | would anyone mind reviewing https://reviewboard.asterisk.org/r/347/ ? |
| 15:27.09 | *** join/#asterisk-dev Qwell (i=north@pdpc/sponsor/digium/Qwell) |
| 15:27.09 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 15:39.04 | *** join/#asterisk-dev Laureano (n=Laureano@190.245.108.131) |
| 15:41.15 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 15:41.15 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 15:50.05 | tzafrir_laptop | Hatrix, live_ast is http://svn.asterisk.org/svn/asterisk/trunk/contrib/scripts/live_ast |
| 16:02.49 | *** join/#asterisk-dev CunningPike (n=CunningP@204.239.8.157) |
| 16:20.12 | *** join/#asterisk-dev hugorebelo (n=hugorebe@200-171-132-124.completo.com.br) |
| 16:24.01 | *** join/#asterisk-dev qdk (n=qdk@195.242.194.41) |
| 17:06.28 | *** join/#asterisk-dev angler (n=angler@pdpc/sponsor/digium/angler) |
| 17:07.01 | *** join/#asterisk-dev jmls (n=jmls@host217-36-208-155.in-addr.btopenworld.com) |
| 17:07.09 | jmls | leifmadsen: ping |
| 17:07.16 | leifmadsen | jmls: pong! |
| 17:07.22 | jmls | I *really* enjoyed your last email response ... |
| 17:07.28 | jmls | "First, you should attempt to reproduce the issue on 1.4.26.1 as that is a newer version than 1.4.26.1" |
| 17:07.29 | leifmadsen | which one was that? |
| 17:07.33 | leifmadsen | doh! |
| 17:07.34 | jmls | heh |
| 17:07.35 | leifmadsen | typo's ftw |
| 17:07.52 | russellb | typo is ftw? |
| 17:08.04 | leifmadsen | sure! :) |
| 17:08.14 | russellb | and you call yourself a writer!! |
| 17:08.15 | russellb | :-p |
| 17:08.16 | russellb | <3 |
| 17:08.16 | jmls | ~reproduce leifmadsen |
| 17:08.23 | russellb | O.O |
| 17:08.30 | leifmadsen | too much translationparty |
| 17:08.36 | jmls | urk |
| 17:08.55 | jmls | anyways, just thought I'd stir the pot ;) |
| 17:09.00 | leifmadsen | ha! |
| 17:09.39 | leifmadsen | you could correct me :) |
| 17:10.01 | Qwell | I think he just did :p |
| 17:14.14 | leifmadsen | slaps Qwell with a large pike |
| 17:16.12 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 17:23.55 | *** join/#asterisk-dev outtolunc (n=me@c-98-248-96-110.hsd1.ca.comcast.net) |
| 17:47.17 | kpfleming | Deeewayne: you need to change your email address in reviewboard... i just reviewed your patch, but the email to you about it bounced |
| 17:50.21 | Deeewayne | I looked in my preferences and only see "enable syntax highlighting" and "which group do you belong to" |
| 17:50.35 | russellb | looks |
| 17:50.45 | Deeewayne | I looked for that yesterday and thought I saw somewhere that it uses mantis accounts, which has the correct email address.... can't find that right now |
| 17:51.02 | jmls | runs off to get some coffee |
| 17:51.03 | russellb | what is the address you would like to use? |
| 17:51.07 | russellb | i think I need to change it ... |
| 17:51.11 | Deeewayne | dwayne.hubbard@gmail.com |
| 17:51.32 | russellb | okay, fixed |
| 17:51.36 | Deeewayne | russellb, thanks |
| 17:52.01 | Qwell | waves to Deeewayne |
| 17:52.38 | Deeewayne | kpfleming, thanks for the review. I thought it was kind of strange for the ATT & NATIONAL service/acknowledge values to change as well |
| 17:52.39 | Qwell | Deeewayne: I totally tweeted that when I got to a red light. |
| 17:52.49 | Deeewayne | hey qwell :-) |
| 17:52.50 | *** join/#asterisk-dev itamarjp (n=itamar@189-015-64-036.xd-dynamic.ctbcnetsuper.com.br) |
| 17:53.04 | file | Qwell: were you prepared to retransmit the OHAI? |
| 17:53.19 | leifmadsen | Qwell: and I saw it :) |
| 17:53.26 | Qwell | I was. The retransmit time would have been short though, since he was de-merging |
| 18:01.24 | Deeewayne | russellb, would the incorrect email address explain why my reviewboard request never hit the mailing list ? |
| 18:01.55 | Corydon76-dig | Yes, if that email address is not subscribed |
| 18:03.24 | Deeewayne | eeep ... I just found another coding guideline mistake in that patch |
| 18:07.17 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 18:07.17 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 18:15.56 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 18:23.12 | *** join/#asterisk-dev moy (n=moy@bas1-unionville55-1177733667.dsl.bell.ca) |
| 18:26.02 | tzafrir_laptop | M14577 |
| 18:26.04 | MuffinMan | [confirmed] [DAHDI-linux] dahdi (the module) 0014577: [patch] FXO channels "hookstate" incorrect on startup reported by jkroon (Karma: +1.25) https://issues.asterisk.org/view.php?id=14577 |
| 18:26.45 | tzafrir_laptop | Any idea why Asterisk 1.6 suddenly enabled a test that was disabled by default before ? |
| 18:27.01 | tzafrir_laptop | This breaks 1.6 with FXO channels |
| 18:27.31 | leifmadsen | tzafrir_laptop: because Asterisk 1.6 has become sentient? |
| 18:27.43 | tzafrir_laptop | The suggested fix is sub-optimal. Before I apply it in the driver I want to understand why I need to bother |
| 18:28.20 | tzafrir_laptop | leifmadsen, See the related topic there |
| 18:28.45 | tzafrir_laptop | err... related issue: https://issues.asterisk.org/view.php?id=15429 |
| 18:29.26 | tzafrir_laptop | It is currently why I hesitate recommending people with our hardware to use 1.6 |
| 18:29.39 | tzafrir_laptop | (In the debian packages we patched it away) |
| 18:31.09 | tzafrir_laptop | Nobody was able to even explain specifically what this test is for. Only a vague "something related with channel bank" |
| 18:33.43 | leifmadsen | ya, I won't be any more help here :) |
| 18:36.33 | *** join/#asterisk-dev De_Mon (i=de_mon@fl-69-34-134-91.dhcp.embarqhsd.net) |
| 19:00.08 | *** join/#asterisk-dev murdock_ut (n=chatzill@mail.kimballequipment.com) |
| 19:00.28 | *** join/#asterisk-dev sasargen (n=chatzill@173-124-140-145.pools.spcsdns.net) |
| 19:02.15 | *** join/#asterisk-dev oej (n=olle@ns.webway.se) |
| 19:02.15 | *** mode/#asterisk-dev [+o oej] by ChanServ |
| 19:03.07 | kpfleming | umm.. i hate to be party fouler, but should 'mutestream' have a name that is more specific to audio? we also have video streams, text streams, etc. |
| 19:03.49 | russellb | OMG NEGATIVE NANCY |
| 19:03.53 | russellb | j/k, that's a very fair suggestion :-) |
| 19:03.58 | russellb | MUTE_AUDIO_STREAM perhaps |
| 19:04.05 | russellb | or MUTE_STREAM(audio) |
| 19:04.06 | russellb | shrugs |
| 19:04.10 | russellb | oej: ^^^ |
| 19:04.30 | kpfleming | ALLYOURAUDIOAREBELONGTOUS() |
| 19:04.41 | oej | At some point we might add other media |
| 19:04.54 | kpfleming | sure |
| 19:05.02 | kpfleming | but then the syntax should allow for it now |
| 19:05.14 | russellb | mutes kpfleming's text |
| 19:05.24 | oej | But shouldn't it mute all media in a direction? |
| 19:05.26 | russellb | <kpfleming> ------------------- |
| 19:05.27 | russellb | that's all I see |
| 19:05.28 | oej | If possible |
| 19:05.37 | kpfleming | then it's MUTECHANNEL |
| 19:05.50 | kpfleming | or MUTESTREAM(all) |
| 19:05.52 | oej | No, because that assumes both directions |
| 19:06.04 | kpfleming | no, you still specify a direction |
| 19:06.15 | oej | MUTESOMETHING |
| 19:06.35 | russellb | MUTEWORLD |
| 19:06.48 | kpfleming | as long as the syntax won't break when someone wants to be able to suppress video or text, i'm fine with the name |
| 19:06.53 | oej | Let's change to MUTEAUDIO now for the function and AMI and worry about extensions when we can trash out video |
| 19:06.54 | kpfleming | but if the syntax will have to change... |
| 19:07.00 | kpfleming | ok |
| 19:07.05 | kpfleming | i'm good with that too |
| 19:07.16 | mvanbaak | ZEROFRAMES |
| 19:07.19 | kpfleming | or replace the video with animations |
| 19:07.23 | oej | We can re-add MUTESTREAM when we can actually do that |
| 19:07.28 | kpfleming | yep! |
| 19:07.31 | oej | Abba music videos |
| 19:07.33 | *** join/#asterisk-dev qdk (n=qdk@0x573d8d8b.bynqu1.dynamic.dsl.tele.dk) |
| 19:07.37 | russellb | INSERTNAUGHTYVIDEOCLIP() |
| 19:07.38 | mvanbaak | omg |
| 19:07.41 | kpfleming | with subtitles! |
| 19:08.07 | oej | RANDOMAUDIOCLIPS from other channels |
| 19:08.22 | mvanbaak | RICKROLL() |
| 19:12.28 | oej | Hmm. I really want to mute DTMF too... If I grab DTMF in the hook, will it be filtered out? |
| 19:13.25 | kpfleming | yes, AST_FRAME_DTMF_BEGIN is also passed to audiohooks |
| 19:13.28 | *** join/#asterisk-dev jtodd (i=uancftet@ns.fox-den.com) |
| 19:13.28 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 19:13.40 | kpfleming | i'm not sure what you can do to it to make it be suppressed though |
| 19:13.47 | file | but not in a way that allows you to intercept and suppress it though |
| 19:13.51 | kpfleming | turn it into AST_FRAME_NULL, that's what you can do |
| 19:14.03 | kpfleming | oh yeah |
| 19:14.15 | kpfleming | because then ast_write assumes it is still AST_FRAME_DTMF |
| 19:14.16 | kpfleming | ouch |
| 19:14.19 | file | correct |
| 19:15.07 | leifmadsen | russellb: I'd suggest a dancing sausage for muted video. |
| 19:15.17 | leifmadsen | heck, we already have the graphic! |
| 19:15.46 | *** join/#asterisk-dev atis_work (n=atis_wor@193.238.212.171) |
| 19:17.34 | *** part/#asterisk-dev korihor (n=korihor@190.77.83.180) |
| 19:18.01 | oej | So the verdict is to take AST_FRAME_DTMF and just make it to NULL... |
| 19:18.04 | oej | Interesting. |
| 19:18.10 | kpfleming | nope, that' won't work |
| 19:18.59 | oej | Well, I don't want a muted person to be able to send DTMF... :-) |
| 19:19.10 | oej | Maybe we can extend audiohooks for that later |
| 19:19.14 | kpfleming | yeah |
| 19:19.20 | kpfleming | it's nearly all there now |
| 19:19.23 | kpfleming | just some small tweaks |
| 19:19.43 | kpfleming | although that's really not an audiohook at all... |
| 19:19.48 | oej | But beyond me, so unless one of you have time for the tweaks, it'll have to wait |
| 19:19.48 | kpfleming | its a dtmfhook |
| 19:19.59 | oej | so we have to rename audiohooks? |
| 19:20.00 | oej | :-) |
| 19:20.07 | kpfleming | videohook, texthook |
| 19:20.18 | kpfleming | modemhook |
| 19:20.22 | kpfleming | that's all we've got |
| 19:20.26 | mvanbaak | streamhook(type) |
| 19:20.46 | oej | control hook for ast_control frames. I want to stop ALL hangups and hold frames. |
| 19:20.57 | mvanbaak | whehehehe |
| 19:21.43 | Qwell | kpfleming: can't forget imagehooks |
| 19:21.54 | kpfleming | umm... yeah |
| 19:21.57 | kpfleming | so heavily used |
| 19:23.13 | oej | htmlhooks is crying, being forgotten |
| 19:23.28 | tzafrir_laptop | hmm.... overriding a remote IVR with a dtmf hook? |
| 19:23.44 | oej | yep. Randomly replacing dtmf... |
| 19:24.02 | tzafrir_laptop | Randomly? |
| 19:24.26 | oej | Why do it fifo when we can use random access? |
| 19:24.54 | mvanbaak | sweet |
| 19:45.13 | *** join/#asterisk-dev snuff-home (n=snuffy@203-219-29-182-bri-ts6-2600.tpgi.com.au) |
| 19:45.13 | *** mode/#asterisk-dev [+o snuff-home] by ChanServ |
| 19:47.37 | *** join/#asterisk-dev WHYS (n=drumm@137.28.94.209) |
| 19:52.28 | *** join/#asterisk-dev oej_ (n=olle@ns.webway.se) |
| 19:52.28 | *** mode/#asterisk-dev [+o oej_] by ChanServ |
| 20:04.34 | snuff-home | mm gmail down for anyone? |
| 20:04.50 | Qwell | snuff-home: interwebs says yes |
| 20:06.11 | snuff-home | nice.. 1st time i've had that myself when tryin to access |
| 20:06.12 | snuff-home | :) |
| 20:06.40 | Qwell | dunno, works for me. I've just seen other people whispering about it |
| 20:08.09 | Deeewayne | I am also whispering about it |
| 20:08.27 | kpfleming | The GMail Whisperers |
| 20:08.35 | putnopvut | hates that every time I change ccss.h, I have to recompile the world |
| 20:08.47 | Deeewayne | pushes putnopvut |
| 20:08.52 | kpfleming | putnopvut: using ccache? |
| 20:08.57 | putnopvut | kpfleming: nope |
| 20:09.13 | putnopvut | falls over so hard from Deeewayne's push that he is somehow still standing afterward. |
| 20:09.31 | leifmadsen | snuff-home: it went down for me too |
| 20:10.00 | snuff-home | mm.. i always access my gmail via https |
| 20:10.12 | leifmadsen | ya, same here |
| 20:10.43 | snuff-home | hotmail is the suck.. no option to have full encrypted session |
| 20:12.56 | snuff-home | mm guess i'll try my gmail in 3 hrs when i get into work |
| 20:14.08 | *** part/#asterisk-dev |Cybex| (n=John@80.100.126.176) |
| 20:19.41 | *** join/#asterisk-dev kerframil (n=kerframi@gentoo/user/kerframil) |
| 20:20.28 | *** join/#asterisk-dev KyleK (n=Kyle@allspark.shadowmage.org) |
| 20:38.14 | *** join/#asterisk-dev pyite (n=pyite@unaffiliated/pyite) |
| 20:38.54 | *** part/#asterisk-dev pyite (n=pyite@unaffiliated/pyite) |
| 20:43.03 | *** join/#asterisk-dev denon (i=denon@synapse.subneural.net) |
| 20:44.38 | *** join/#asterisk-dev mnt_real (n=sinan@bas12-montrealak-1167975979.dsl.bell.ca) |
| 20:45.58 | *** join/#asterisk-dev tzafrir_laptop (n=tzafrir@bzq-179-75-202.static.bezeqint.net) |
| 20:45.58 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 20:47.30 | leifmadsen | kpfleming: I've found a couple of new fax issues in mantis, however they are not T.38 (chan_dahdi related) -- would those still be assigned to you for now, or is that an entirely separate realm that has no application to your faxing knowledge? :) |
| 20:47.45 | kpfleming | are they app_fax? |
| 20:48.18 | leifmadsen | ummm, one is not, and the other I need to get more information from it appears |
| 20:48.30 | leifmadsen | however I think you answered my question |
| 20:48.31 | kpfleming | i don't uinderstand how they can be fax issues but not be t.38 or app_fax |
| 20:49.16 | leifmadsen | fax detection in chan_dahdi |
| 20:49.24 | kpfleming | oh |
| 20:49.26 | leifmadsen | the other one said fax, but isn't really fax related |
| 20:49.31 | kpfleming | yeah, i know enough about that to be helpful |
| 20:49.44 | leifmadsen | kpfleming: there is a patch attached to it, so I'll assign for review |
| 20:59.21 | *** join/#asterisk-dev ZX81 (n=Matt_Rid@121.74.14.197) |
| 20:59.59 | kpfleming | leifmadsen: 15809 is not really fax related, it's a bug in chan_dahdi's configuration parser i suppose... or it may not be a bug at all |
| 21:05.42 | oej | russellb: Congratulations on that mp3 bug. I've known for a long time that running mp3 can cause the wildest bug reports in the tracker, but no one has found it - until now. I hope this solves it once and for all. |
| 21:06.16 | ZX81 | totally - that commit was worthy of a news article :) |
| 21:06.35 | oej | Absolutely. Maybe programmer of the day award too ;-) |
| 21:06.57 | ZX81 | +1 |
| 21:06.59 | ZX81 | :) |
| 21:07.59 | russellb | thanks guys :-) |
| 21:09.02 | mvanbaak | +1 from me as well |
| 21:09.03 | putnopvut | russellb: I'm convinced that there are still other places where something similar is done, based on the recent bug report that had something similar happening but using format_wav |
| 21:09.13 | putnopvut | But yeah, awesome job getting the mp3 one fixed. |
| 21:09.19 | russellb | nods |
| 21:09.34 | russellb | seems like something else is happening that causes a similar result .. |
| 21:09.41 | russellb | i've been looking, but haven't found it (or them) yet |
| 21:09.51 | putnopvut | Yeah, See |
| 21:09.55 | putnopvut | M15719 |
| 21:09.57 | MuffinMan | [acknowledged] [Asterisk] Core/FileFormatInterface 0015719: Crash in ast_readaudio_callback reported by rgj (Karma: neutral) https://issues.asterisk.org/view.php?id=15719 |
| 21:09.59 | putnopvut | For a good example |
| 21:10.14 | putnopvut | That looks like the FILE * is being stomped on. |
| 21:10.27 | russellb | Yeah, I saw that one. It's behaving different ... |
| 21:10.43 | russellb | well, that one is because both the s->owner and s->orig_chan_name are bogus |
| 21:10.45 | mvanbaak | hhmm, there are more places in chan_sip that do not copy the parkinglot setting |
| 21:10.50 | mvanbaak | I think I'm almost there |
| 21:11.00 | putnopvut | russellb: well, the second bt posted looks like corruption of the FILE * |
| 21:11.05 | putnopvut | I should have been more specific. |
| 21:11.39 | Qwell | well, 64-bit would go back further with the corruption |
| 21:11.52 | Qwell | stomping f wouldn't be unreasonable |
| 21:12.06 | russellb | right, but in this case we know format_mp3 didn't do it |
| 21:12.11 | Qwell | err, wait, 32-bit would go more. whichever |
| 21:12.30 | mvanbaak | we should stop supporting 32bit |
| 21:13.12 | putnopvut | sends mvanbaak to lawlingrad |
| 21:14.15 | kpfleming | are any of the other reports reproducable enough to be able to test patches against them? |
| 21:14.53 | russellb | that one is |
| 21:14.59 | russellb | I'm going to attack it next with some debugging |
| 21:17.39 | kpfleming | well... a brute force method would be to identify each module that is a source of 'ast_frame *' in that scenario, and one-by-one, have them return frames using ast_frdup() instead of their local frame pointer |
| 21:17.49 | kpfleming | when you find the one that makes the problem stop happening, you have a clue |
| 21:18.43 | Qwell | so here's an interesting question |
| 21:18.53 | Qwell | that code has been there since 1.4 has existed |
| 21:19.02 | Qwell | why did all of the reports have bug numbers in the 15000s? |
| 21:20.40 | kpfleming | probably a number of older reports just got closed out because nobody could reproduce the problem or determine the cause |
| 21:21.28 | russellb | Oh, you're using format_mp3? Stop that, that module sucks. |
| 21:21.32 | russellb | that was my usual approach |
| 21:21.46 | kpfleming | now we know what the suckage was |
| 21:21.52 | russellb | hopefully |
| 21:24.04 | russellb | so this one is using chan_agent ... |
| 21:24.13 | russellb | and looking at agent_read() slightly worries me ... |
| 21:24.24 | putnopvut | agent_read is a bastard of a function |
| 21:24.38 | Corydon76-dig | Don't hold back |
| 21:24.40 | russellb | it does an ast_read() on an underlying channel and returns that frame. So the underlying channel is not locked while the frame is processed |
| 21:24.59 | russellb | meaning that a _lot_ of things could happen to that underlying channel while something is processing that frame |
| 21:25.18 | russellb | that's a bit of a concern.. |
| 21:25.50 | russellb | I hate just guessing, though |
| 21:25.55 | kpfleming | yeah |
| 21:26.06 | kpfleming | and there shouldn't be many things happening to an agent subchannel |
| 21:26.15 | kpfleming | although they certainly can |
| 21:26.18 | Marquis42 | Famous last words |
| 21:26.21 | jmls | heh |
| 21:26.29 | kpfleming | and thats one reason why we deprected callback agent mode |
| 21:26.43 | russellb | I think I want to just throw a huge buffer in the middle of ast_filestream to see if it makes a difference |
| 21:26.48 | russellb | right in front of the audio buffer |
| 21:27.01 | russellb | that would at least help see if it's the same type of thing that format_mp3 caused |
| 21:27.53 | putnopvut | ah, so when it becomes non-NULL, you go "HA! GOTCHA!" |
| 21:27.58 | Corydon76-dig | One thing that I've never understood is how we know that AST_FRIENDLY_OFFSET is large enough |
| 21:28.05 | putnopvut | er, not non-NULL, but not all zero's |
| 21:28.07 | putnopvut | zeroes |
| 21:28.16 | russellb | we'd know if we wrote a piece of code where a larger offset would be useful :-) |
| 21:29.05 | Corydon76-dig | russellb: it just concerns me that it's a giant magic value |
| 21:29.13 | russellb | it's not giant |
| 21:29.15 | russellb | it's 64 |
| 21:29.35 | Corydon76-dig | I don't mean giant in that way |
| 21:29.52 | Corydon76-dig | More like the gorilla in the room |
| 21:30.22 | kpfleming | the size only matters if consumers of frames are frequently forced to copy the frame because the offset wasn't big enough |
| 21:30.41 | kpfleming | if any code is writing data ahead of the buffer without checking the supplied offset size, that is badly broken |
| 21:31.08 | mvanbaak | size does matter ;) |
| 21:31.27 | Corydon76-dig | Remind me... what all is stored within the offset? |
| 21:31.50 | russellb | headers |
| 21:31.51 | russellb | packet headers |
| 21:31.53 | kpfleming | rtp.c uses it to build the rtp header |
| 21:31.56 | kpfleming | same for udptl |
| 21:33.00 | Corydon76-dig | and we've taken into account possibly wider types on 64-bit, right? |
| 21:33.38 | kpfleming | tehse are packet headers |
| 21:33.43 | kpfleming | there are no wider types |
| 21:35.45 | Corydon76-dig | Do we assume the offset in all cases? Is there a source for frames where we don't eet the offset? |
| 21:35.51 | Corydon76-dig | s/eet/set/ |
| 21:36.05 | kpfleming | no code should ever assume the offset, that's what i just said above |
| 21:36.07 | putnopvut | Corydon76-dig: I think Qwell did some looking to see if that was the case |
| 21:36.15 | russellb | there is a field in the frame that indicates if the offset is there |
| 21:36.17 | kpfleming | not only can you not assume the offset, you can't assume how much it will be |
| 21:36.39 | russellb | (and how much it is, if it is there) |
| 21:42.59 | Qwell | putnopvut: no, I just looked for other places where it wasn't used when creating a frame |
| 21:43.16 | putnopvut | Right, which is what Corydon76-dig asked about (the second half of his question) |
| 21:44.21 | Qwell | oh |
| 21:46.09 | russellb | all of the format_ modules appear to be doing the right thing. |
| 21:46.31 | russellb | i threw up a quick hack of a debug patch to see if we can verify if it's the same type of bug, though |
| 21:46.39 | Qwell | well, format_jpeg is probably wrong |
| 21:46.50 | Qwell | s/probably/possibly/ |
| 21:46.59 | Qwell | it's just not using offset stuff at all |
| 21:47.11 | Qwell | not that anybody actually uses it though |
| 21:49.20 | kpfleming | that's fine |
| 21:49.38 | kpfleming | if it produces frames with offset == 0, then consumers of those frames that need 'head space' will have to copy the frame to make some |
| 21:49.44 | Qwell | ahh |
| 21:49.52 | Qwell | so it's just inefficient |
| 21:49.54 | russellb | and ... how many people do you think use format_jpeg :-) |
| 21:49.59 | kpfleming | if we a scatter-gather style sendto() function, we wouldn't need this offset stuff at all |
| 21:50.04 | kpfleming | russellb: all of them! |
| 21:50.09 | russellb | kpfleming: ! |
| 21:50.19 | kpfleming | well... they load it anyway :-) |
| 21:50.26 | russellb | heh, right .. |
| 21:51.27 | putnopvut | looks at the debug patch that russellb put up. |
| 21:51.31 | russellb | lols that we still have images/asterisk-into.jpg in the source tree |
| 21:51.50 | *** join/#asterisk-dev alecdavis (n=sivad@202-78-149-14.cable.telstraclear.net) |
| 21:52.27 | seanbright | animlogo.gif is trippy |
| 21:52.43 | seanbright | for all the vmail.cgi peeps out there |
| 21:53.09 | russellb | ha .. |
| 21:54.12 | putnopvut | russellb: man, if there were a mem equivalent of strspn, you wouldn't neet that for loop in that debug patch on 15719... |
| 21:54.32 | kpfleming | no... it would be hidden in the function ;-) |
| 21:55.17 | russellb | yeah, but I don't care that much about it being pretty :-) |
| 21:55.21 | russellb | 4096 was probably excessive ... |
| 21:55.23 | russellb | but oh well |
| 21:55.52 | seanbright | static char no_corruption[4096] = { 0 }; |
| 21:55.57 | seanbright | and then use memcmp |
| 21:55.58 | seanbright | duh |
| 21:56.07 | putnopvut | ah memcmp. I'm dumb |
| 21:56.11 | alecdavis | any one able to shed some light on the proposed implementation of ISDN Subaddr. |
| 21:56.27 | Qwell | russellb: should make it print out the entire thing in hex after i, so we can see what is being written there |
| 21:56.45 | russellb | i guess ... memcmp() is probably implemented in some really fancy efficient way |
| 21:56.47 | Qwell | might help clue in a bit |
| 21:57.00 | mvanbaak | Hello! my name is Dr. GreenThumb! |
| 21:57.05 | mvanbaak | meh |
| 21:57.09 | russellb | Qwell: yeah, let's just see if it happens first |
| 21:57.11 | seanbright | yeah, they probably compare 4 bytes at a time |
| 21:57.15 | russellb | seanbright: yup |
| 21:57.43 | russellb | if someone wants to upload a new one that uses memcmp(), go for it, but i'm too lazy |
| 21:58.12 | seanbright | ditto. |
| 21:58.18 | seanbright | you had me at "if" |
| 21:59.27 | putnopvut | The only problem I have with the patch is that the crash may happen before the filestream destructor is run. |
| 21:59.41 | putnopvut | It may be worthwhile to check the filestream's state after each fmt->read callback. |
| 21:59.59 | putnopvut | Eh, but the uploaded patch will probably suffice. |
| 22:00.06 | Qwell | after the read is too early I think |
| 22:00.20 | russellb | well, sure, it may crash, but if it's the problem I'm looking for, it won't crash anymore, because it'll overwrite stuff that doesn't matter |
| 22:00.27 | putnopvut | oh, duh :) |
| 22:07.10 | alecdavis | anyone listening and using ISDN connections to the PSTN. But haven't enough DDI numbers for all extensions. How cool would it be to dial the pilot number and be directly connected to extension, without going through an Automated attendant. |
| 22:10.03 | alecdavis | if interested, have a look at mantis bug #15604, it's for the branches, not trunk. |
| 22:19.32 | alecdavis | This direct dial in (bypassing the operator and Automated Attendant) becomes possible, when the Called SubAddress is populated in the ISDN SETUP message. |
| 22:26.20 | Marquis42 | Hrm.... post-review fail: Error uploading diff: One or more fields had errors (105) |
| 22:30.43 | russellb | I suppose you had one or more fields with errors in them |
| 22:31.29 | Marquis42 | heh... That stands to reason I guess... Although thus far I had only told it my username and password. |
| 22:33.01 | russellb | hm |
| 22:33.13 | russellb | are you running it from a trunk checkout? |
| 22:33.19 | russellb | with "svn diff" showing the code you want to post? |
| 22:33.31 | Marquis42 | It's a checkout of my branch |
| 22:34.06 | russellb | post-review is essentially a tool to post the output of "svn diff" |
| 22:34.15 | russellb | so you'll have to apply your changes to a trunk checkout first |
| 22:34.25 | Marquis42 | Ah, OK. Me = fail. I'll do that, thanks. |
| 22:34.29 | russellb | np |
| 22:34.48 | russellb | http://www.asterisk.org/doxygen/trunk/Reviewboard.html |
| 22:35.09 | russellb | there are a couple of other notes about dealing with posting stuff where the files are new |
| 22:35.47 | Marquis42 | Documentation, that's craziness. ;) I'll go about reading that, thanks. No new files here, but good to know in case I do have a review with some. |
| 22:35.59 | russellb | Oh, that's right, it's built into res_jabber |
| 22:36.07 | russellb | k! |
| 22:36.07 | Marquis42 | Yup |
| 22:38.01 | mvanbaak | post-review is SWEET |
| 22:40.55 | Corydon76-dig | So is PB&J bread |
| 22:41.17 | putnopvut | Unless you use beef jelly |
| 22:41.59 | Corydon76-dig | putnopvut: bizarre |
| 22:42.14 | putnopvut | If there is such a thing, I'd like to try it :) |
| 22:42.26 | russellb | O.o |
| 22:42.34 | Corydon76-dig | putnopvut: I think that's aka Bag Balm |
| 22:42.47 | putnopvut | Bag Balm? |
| 22:43.06 | Corydon76-dig | http://www.google.com/products?q=bag+balm |
| 22:44.23 | Corydon76-dig | Originally designed and used to keep dairy cows' teats from getting chapped in cold weather |
| 22:45.19 | Marquis42 | There is nothing worse that chapped teats. |
| 22:45.22 | Marquis42 | s/that/than/ |
| 22:45.51 | Corydon76-dig | Marquis42: you'd agree, if you ever tried to milk a cow with chapped teats |
| 22:46.38 | Marquis42 | Heh... I can't say that I've ever done that. I *have* milked cows, but I'm pretty sure they were chapped-teat free. |
| 22:46.56 | Corydon76-dig | http://www.americanlivestock.com/p-46-bag-balm.aspx?gclid=CI7sruK-0ZwCFVhj2godHg7wIQ |
| 22:53.30 | Corydon76-dig | jtodd: does the patch on 14542 fix it for you? |
| 23:05.43 | *** join/#asterisk-dev leifmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 23:05.43 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 23:40.11 | Marquis42 | Hrmmmm... How long should reviewboard requests take to hit the asterisk-dev mailing list? |
| 23:44.09 | leifmadsen | I'd think not too long |
| 23:44.31 | leifmadsen | Marquis42: I hope to get some testing in on thursday! |
| 23:44.39 | leifmadsen | I saw your commit that you're pretty close to being done |
| 23:44.46 | Marquis42 | Cool, thanks for whatever you can do. |
| 23:45.21 | Marquis42 | Yeah, in terms of features it's done. I just need to make sure it works with the largest variety of PubSub implementations that I can, and write some documentation. |
| 23:47.00 | Marquis42 | No idea about the reviewboard e-mail, though. :/ If anybody is interested, it's review request #351 |
| 23:49.19 | russellb | hm, an email address wasn't set on your account. |
| 23:49.27 | russellb | How long ago was the first time you logged in to reviewboard? |
| 23:49.32 | russellb | a lonnnng time ago, or more recently? |
| 23:49.40 | russellb | yes, that question is very specific :-) |
| 23:51.51 | russellb | it looks like my auth backend that uses mantis isn't properly handling email addresses. |
| 23:51.57 | russellb | Soooooooo ... my bad |
| 23:52.42 | russellb | or hm, maybe it is working' |
| 23:52.44 | russellb | heck i don't know |
| 23:52.47 | russellb | but surely it's my fault |
| 23:52.54 | *** join/#asterisk-dev sruffell (n=sruffell@asterisk/the-kernel-guy/sruffell) |
| 23:52.54 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |