| 20:36.59 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 20:36.59 | *** topic/#asterisk-dev is Topic for #asterisk-dev is: Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- IAX2 is now RFC 5456. |
| 20:43.02 | seanbright | Corydon76-dig: i think watchdir[] needs to be initialized |
| 20:43.17 | seanbright | 'readlink does not append a NUL character to buf' |
| 20:44.34 | Corydon76-dig | Good catch |
| 20:44.54 | russellb | the code also needs more cowbell |
| 20:45.38 | eliel | data_api_gsoc2009 ready to get merged? :-) |
| 20:46.00 | seanbright | eliel: no, we've decided to not move forward with that. |
| 20:46.02 | seanbright | heh |
| 20:46.14 | Qwell | data has been deprecated. |
| 20:46.15 | Corydon76-dig | seanbright: that has the potential to fix the symlink test... |
| 20:46.16 | russellb | probably, i wanted to do an in depth review this week but then got sick |
| 20:46.17 | eliel | he, ok, i will remove the branch |
| 20:46.22 | russellb | noooo |
| 20:46.28 | seanbright | Corydon76-dig: will test |
| 20:46.38 | russellb | i guess we can always make changes in trunk *shrugs* |
| 20:46.40 | seanbright | Corydon76-dig: the goto on 447 is unneeded as well |
| 20:46.47 | russellb | i think seanbright should review it |
| 20:46.53 | seanbright | man |
| 20:46.54 | eliel | russellb: agree |
| 20:46.57 | russellb | haha |
| 20:47.07 | eliel | seanbright: i will wait for your review then.... |
| 20:47.08 | seanbright | i'm the only one of you schmucks not getting paid |
| 20:47.09 | eliel | :) |
| 20:47.10 | seanbright | heh |
| 20:47.16 | russellb | seanbright: we could fix that |
| 20:47.21 | seanbright | hush |
| 20:47.33 | russellb | hushes |
| 20:48.03 | Corydon76-dig | seanbright: Yeah, I need a responsible housemate. You want to move here? No income tax! |
| 20:48.10 | seanbright | heh |
| 20:48.12 | russellb | lol |
| 20:49.09 | eliel | seanbright: i am not getting paid for this... :) |
| 20:49.10 | seanbright | Corydon76-dig: both tests still fail after: char watchdir[PATH_MAX + 1] = { 0 }; |
| 20:49.24 | eliel | merging this to trunk is a gift to the asterisk community |
| 20:49.33 | Corydon76-dig | We can bleach the room for you. The current housemate only does a limited amount of porn in there... |
| 20:50.30 | russellb | it is definitely Friday afternoon in here |
| 20:55.31 | Kobaz | never would have noticed |
| 20:55.50 | kpfleming | it is also friday afternoon in my office |
| 20:56.10 | Qwell | weird. It's Thursday morning in mine. |
| 20:56.21 | Qwell | stupid timezones |
| 20:56.24 | russellb | it's always Thursday morning somewhere |
| 20:56.30 | Qwell | never could quite get the hang of them |
| 20:57.26 | kpfleming | lols at engrish funny |
| 21:02.50 | jkroon | russellb, btw, support emailed me after my supplier apparently kicked up a bit of a storm with their sales manager. "sorry, we only support three cards in a system" |
| 21:03.13 | jkroon | even though I can reproduce the issue with only a single PRI in the system too. |
| 21:03.39 | russellb | jkroon: i also contacted our support manager, glad they got with you |
| 21:04.28 | jkroon | they still haven't actually helped other than to tell me that I need to test with newer versions of stuff, which I have done already on someone's recommendation here, same results. |
| 21:04.36 | jkroon | told them as much, now i wait again. |
| 21:04.51 | russellb | that's the standard first steps before anything is escalated |
| 21:06.42 | jkroon | completely understandable. |
| 21:07.27 | russellb | i hope they are able to resolve your issue, sorry i can't do more |
| 21:07.32 | jkroon | ok, having a core dump, what now? I can't seem to get a bt of all threads that was active at the time of crash. |
| 21:07.52 | jkroon | i seriously doubt they can. i suspect it's a software bug... |
| 21:07.56 | russellb | you just need a bt of the thread that blew up |
| 21:08.07 | russellb | they will be able to report internally as appropriate if it is a bug |
| 21:08.17 | jkroon | well, it doesn't blow up, it deadlocks, refuses to make more calls. |
| 21:08.43 | jkroon | fair enough, but I've had "open" bugs on the digium site for > 14 months now, still unresolved. |
| 21:08.47 | jkroon | with working patches. |
| 21:08.53 | jkroon | posted with the bug reports. |
| 21:08.56 | russellb | issues.asterisk.org? |
| 21:08.58 | russellb | that's different... |
| 21:09.18 | jkroon | how? |
| 21:09.19 | russellb | customers with issues reported internally get higher priority than stuff on mantis |
| 21:09.28 | jkroon | o.O |
| 21:09.51 | jkroon | ok, so mantis is purely for the OSS side of things, if you've actually bought hardware from digium you get preference? |
| 21:10.11 | seanbright | one would assume |
| 21:10.15 | jkroon | and digium really couldn't care about the OSS side because it doesn't bring them money directly? |
| 21:10.26 | seanbright | jeez |
| 21:10.27 | russellb | um, we have an entire team dedicated to doing OSS stuff |
| 21:10.28 | jsmith | jkroon: That's absolutely not true |
| 21:10.48 | jkroon | i would hope it's not true, but it surely does feel that way some days. |
| 21:10.49 | Kobaz | fixing any bug is important |
| 21:10.56 | russellb | you really need to calm the heck down and take your frustrations out where they are due, and not here in a channel of open source devs and volunteers |
| 21:10.57 | Kobaz | any bug that's fixed is one less that will affect everyone else |
| 21:11.29 | Kobaz | jkroon: some bugs are harder to fix than others |
| 21:11.44 | Kobaz | jkroon: i have bugs that are really old too, that haven't been resolved |
| 21:11.45 | jkroon | Kobaz, i posted working patches - how much easier can I make it? |
| 21:11.59 | seanbright | runs away |
| 21:12.11 | Kobaz | jkroon: the people that need to review what you posted apparently are working on other things |
| 21:12.19 | seanbright | Corydon76-dig: i will try to play around with the openbsd stuff this weekend |
| 21:12.38 | jkroon | apparently. |
| 21:13.03 | Kobaz | jkroon: i've put in a bit of time to help you out... and now i feel like you're not appreciative |
| 21:13.20 | Kobaz | if you want stuff to be fixed right now... go buy an avaya system |
| 21:13.22 | jkroon | anyway, before I get thrown out of here, any help on the call deadlock issue? a core dump is senseless because I can't get the traces of all threads. |
| 21:13.33 | Kobaz | jkroon: yes you can |
| 21:13.46 | russellb | enable DEBUG_THREADS, grab "core show locks" output from the asterisk CLI |
| 21:14.16 | jkroon | Kobaz, do NOT get me wrong, I do differentiate between those that help in these channels and the lag @ digium. that's why I typically much rather try my luck here. |
| 21:14.19 | Kobaz | jkroon: be patient, be accepting, and be open... and you're problems will get solved... give it time... it's open source |
| 21:14.29 | jkroon | and I've also personally assisted others. |
| 21:14.37 | jkroon | so thanks to you. |
| 21:15.23 | jkroon | if it weren't for the folks in this # ... |
| 21:16.37 | Kobaz | goes back to breaking stuff |
| 21:16.50 | jkroon | just btw, i'm seeing this with asterisk 1.6.2.6 and dahdi 2.2.1 as well. |
| 21:16.58 | jkroon | going to retry with 2.2.1.1 as well. |
| 21:18.19 | jkroon | another interesting observation was that if I kill specific DAHDI/ channels it'll continue, but deadlock again within a couple of calls. |
| 21:18.37 | Kobaz | sounds like a resource contention issue |
| 21:18.40 | jkroon | not sure why. it's as if (without looking at the code) there is some per-channel lock that gets left locked. |
| 21:18.46 | Kobaz | finite number of locks on something |
| 21:19.19 | jkroon | contention or lock leaking. |
| 21:19.35 | jkroon | core show locks should tell. |
| 21:19.36 | Kobaz | jkroon: there's locks all over the place, if something doesn't get unlocked after it's done then you're stuck |
| 21:19.57 | jkroon | no, then I go and find the code and add the code to unlock it. |
| 21:20.09 | jkroon | then I file a bug. |
| 21:20.13 | Kobaz | no i mean.. you are not stuck... but... the system is stuck |
| 21:20.21 | jkroon | :) |
| 21:20.53 | jkroon | ok well, 75 call setups per second really doesn't sound like "crazy contention" if you ask me. |
| 21:21.01 | jkroon | but i've been known to be wrong. |
| 21:22.06 | jkroon | is there a performance impact for the DEBUG_THREADS option? |
| 21:22.17 | jkroon | I suspect on systems that aren't too loaded I may just compile that in standard. |
| 21:22.18 | Qwell | probably some, yes |
| 21:22.45 | Kobaz | i probably should add that to my standard build |
| 21:22.46 | Qwell | there's certainly overhead from it, as additional things are done on each mutex |
| 21:23.06 | Kobaz | i already have DONT_OPTIMISE and other debug stuff in my production builds |
| 21:23.12 | Kobaz | might as well throw in more stuff |
| 21:23.17 | russellb | storing where every lock is held from, and storing that info in a global thread/lock registry |
| 21:24.08 | Qwell | Kobaz: if you really want to slow things down, you could run it in valgrind standard. |
| 21:24.13 | jkroon | question is - how heavy of an impact does that have on performance? I'm not too worried about RAM, purely latency of setting up calls, but if it's like a few extra cycles, who cares? |
| 21:24.23 | Kobaz | Qwell: i was thinking that too, but that's a 40% hit |
| 21:24.44 | jkroon | i'll settle for DEBUG_THREADS |
| 21:24.53 | Qwell | jkroon: I doubt anybody does any performance testing with DEBUG_THREADS vs not |
| 21:25.28 | Kobaz | i have an issue with a box that was running 1.6.0.26 that I need to valgrind |
| 21:25.33 | jkroon | as a very unscientific benchmark: I see no difference in load average. |
| 21:25.44 | Kobaz | the problem is, i can't get it to reproduce with the same software on a test box, only on the production box |
| 21:25.54 | Kobaz | jkroon: load average doesn't tell you much |
| 21:26.18 | Kobaz | load average tells you how many processes are concurrently in the run state on average... with a bunch of fancy calculations |
| 21:26.38 | Qwell | Kobaz: it's not even all that fancy |
| 21:26.58 | jkroon | well, it gives you an idea of the number of processes ready to run on average at any given point in time, so if asterisk was using 10% more CPU the l/a should climb by ~10%. which it's not. at establishing 75 calls per second the processor is idling, so frankly, that's a non-issue. |
| 21:27.03 | jkroon | into production it goes. |
| 21:28.12 | Kobaz | good luck |
| 21:31.29 | kpfleming | russellb: you can stop at any time :-) |
| 21:32.25 | russellb | i can stop what |
| 21:32.57 | kpfleming | committing stuff... you went home sick |
| 21:33.10 | russellb | heh |
| 21:33.15 | russellb | well, that's what happens when work is fun |
| 21:34.05 | russellb | i'm doing most of this python hacking on personal time, since I'm basically a python n00b |
| 21:34.26 | Corydon76-dig | seanbright: what's especially fun about kqueue is that it holds so much promise. We could finally relieve the poll(2) problems on Mac OS X by reimplementing poll with kqueue |
| 21:34.40 | russellb | i didn't know we still had poll() problems |
| 21:34.53 | russellb | we just use select() and everything seems to be working fine AFAIK |
| 21:35.19 | Corydon76-dig | russellb: yes, but select has problems once a process uses file descriptors above 1024 |
| 21:35.24 | jkroon | hmm, the trace i did get ended up in poll() ... but it came directly from main() iirc. |
| 21:35.27 | russellb | nods |
| 21:35.32 | jkroon | so i don't think that's the problem. |
| 21:35.44 | russellb | core show locks is your friend if a deadlock is the problem |
| 21:36.09 | Kobaz | what version is that in |
| 21:36.11 | Kobaz | it's not in 1.6.0 |
| 21:36.31 | russellb | it's in every version if you compile with DEBUG_THREADS |
| 21:36.33 | russellb | maybe not 1.2 |
| 21:36.35 | russellb | but definitely 1.4 and up |
| 21:36.39 | Kobaz | oh okay |
| 21:36.47 | Kobaz | i dont have debug threads on |
| 21:36.52 | Qwell | DEBUG_CHANNEL_LOCKS is gone now, right? |
| 21:37.00 | russellb | in trunk it is |
| 21:41.35 | jkroon | Lock #0 (channel.c): MUTEX 2619 __ast_read &chan->lock_dont_use <-- what a name for a lock :p |
| 21:42.08 | russellb | don't use directly, anyway |
| 21:42.19 | Corydon76-dig | russellb: found why it won't ever work on OS X... kqueue and poll will only work on sockets, not file descriptors |
| 21:42.39 | russellb | we've had problems with poll() on unix sockets |
| 21:42.56 | jkroon | what's the difference? isn't everything in the unix world a file anyway? |
| 21:43.09 | file | OSX is funny like that |
| 21:43.09 | Corydon76-dig | jkroon: sockets aren't |
| 21:43.45 | Corydon76-dig | Well, most sockets aren't. Unix sockets are the exception, which is probably why they don't work on OS X |
| 21:43.55 | Corydon76-dig | (with poll) |
| 21:44.07 | jkroon | well, not to create them but after that they're simple character streams that's described by an fd like any file? |
| 21:44.18 | jkroon | oh, i see what you're saying. |
| 21:45.09 | jkroon | blah, now I've got all the debug stuff compiled in now it won't deadlock. |
| 21:45.26 | jkroon | the overhead probably makes the race less likely. |
| 21:46.20 | jkroon | if it is a race ... |
| 21:46.23 | russellb | a heisenbug! |
| 21:46.36 | russellb | the best kind |
| 21:47.58 | jkroon | yea, 54k calls success. |
| 21:48.07 | jkroon | i had a run a little earlier crash at 920. |
| 21:48.26 | jkroon | well, not crash. |
| 21:52.43 | Kobaz | keep working at it, you'll get it |
| 21:53.19 | jkroon | well, it's running now. so going to leave it running until it stops. |
| 21:53.37 | jkroon | even if it means i go to bed, grab 6 hours of sleep and come back. |
| 21:55.05 | *** join/#asterisk-dev moy (~chatzilla@74.12.123.160) |
| 21:55.11 | jkroon | which i think is the call i need to make. see ya all later. although, most of you will probably be sleeping around that time :p |
| 21:57.45 | jkroon | night all, sorry for the little outburst, thanks, sleep well. |
| 22:02.59 | *** join/#asterisk-dev jtodd (p8mgwlzb47@asterisk/community-director-and-tie-dye-shirt-lover/jtodd) |
| 22:02.59 | *** mode/#asterisk-dev [+o jtodd] by ChanServ |
| 22:04.55 | hardwire | Is the GotoIFTime built in documentation correct? |
| 22:05.15 | hardwire | I can't seem to use labelfalse and omit labeltrue |
| 22:06.17 | Corydon76-dig | hardwire: What makes you think this is a support channel? |
| 22:06.39 | hardwire | I'm not asking for support. |
| 22:07.04 | Corydon76-dig | hardwire: you're having trouble using it... usage question... |
| 22:07.21 | Corydon76-dig | #asterisk |
| 22:07.55 | hardwire | I am no longer having trouble, I approached my problem differently and this is no longer a problem for me. However I believe the documentation does not reflect the functionality of the app. |
| 22:08.09 | hardwire | you're welcome. |
| 22:08.37 | hardwire | I wanted to ask in a dev oriented channel first before posting a bug and wasting leifmadsens time. |
| 22:09.35 | hardwire | once a ticket is established it's up to somebody on the ticket system to close it.. on IRC I can simply ask and not recieve and not run home crying when nobody cares. I can just wait a while then push it off to the ticket system. |
| 22:09.36 | Corydon76-dig | So you could waste a developer's time, instead of the guy whose job function is to shield the developers from having to hunt down red herrings |
| 22:10.07 | hardwire | Corydon76-dig: I would think that if you wanted that protection you would be in a channel other than this one, or this one would have a secret associated with it. |
| 22:10.28 | Corydon76-dig | hardwire: No, that's THIS channel |
| 22:10.36 | russellb | it's a trivial question, and hardwire is hardcore enough to ask a little something now and then |
| 22:10.37 | hardwire | is there a #asterisk-not-newbs-3rd-party-hackers channel? |
| 22:10.39 | russellb | cut him some slack Corydon76-dig :-) |
| 22:11.08 | Corydon76-dig | AFAIK, GotoIfTime works perfectly |
| 22:11.35 | hardwire | yeh.. I assumed AFAIK was the situation.. that's why I'm ammending to what you K |
| 22:12.05 | Corydon76-dig | hardwire: given that I wrote the command, my knowledge is pretty darn good |
| 22:12.18 | hardwire | submits a bug report |
| 22:12.26 | file | accept the possibility that you can be wrong :P |
| 22:13.02 | Corydon76-dig | file: darn good, not perfect. ;-) |
| 22:13.30 | hardwire | before I submit the bug.. is labeltrue required if I want to specify labelfalse? |
| 22:14.44 | Corydon76-dig | No, just need to include both delimiters |
| 22:15.06 | Corydon76-dig | i.e. GotoIfTime(...?:context,exten,pri) |
| 22:15.12 | hardwire | yar |
| 22:21.25 | hardwire | Corydon76-dig: :) I just realized this was due to cascading GotoIfTime |
| 22:21.30 | hardwire | your record is untarnished for now |
| 22:21.36 | *** join/#asterisk-dev Netgeeks (~chris@173.11.68.155) |
| 22:21.55 | hardwire | totally got gotchad |
| 22:22.00 | hardwire | russellb: not as hard core as need be atm. |
| 22:23.37 | russellb | well get to work on that |
| 22:24.26 | hardwire | yar. I wouldn't mind seeing how labels can contain context,exten,priority however |
| 22:24.31 | hardwire | that info was on voip-info.org |
| 22:25.23 | hardwire | voip-info.org doesn't know about labelfalse tho :) |
| 22:25.45 | *** join/#asterisk-dev mpe (~mpe@0x4dd624b2.adsl.cybercity.dk) |
| 23:00.57 | *** join/#asterisk-dev jeffg (~jeffg@pdpc/supporter/professional/jeffg) |
| 23:06.31 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 23:07.25 | *** join/#asterisk-dev moy (~chatzilla@74.12.123.160) |
| 23:51.30 | *** join/#asterisk-dev elguero (~miguel323@ns1.nashuacs.com) |