IRC log for #asterisk-bugs on 20080527

00:21.28notbrightSo, is Asterisk commits reserved only for Digium employees or are there any community guys in lead devel at all?
00:22.21seanbrightyou mean commit access to the svn repo?
00:22.37notbrightYeah
00:23.09seanbrightits not limited to digium employees
00:23.13notbrightOr to make any changes to Asterisk
00:23.23seanbrighti have commit
00:23.28notbrightCuz I filed a bug, and there hasn't been any action all weekend.. including today
00:23.28seanbrightis not a digium employee
00:23.41notbrightOh you're devel?! Wow, you're really bright aren't you! :D
00:23.52filewe Digium people do tend to end up being the ones who do that stuff
00:24.09notbrightaaah
00:24.14seanbrightnot as bright as some, no.
00:24.17fileas it's not very fun :)
00:24.18notbrightSo all the ops in this channel are defacto digiums?
00:24.21seanbrightpoints at file
00:24.33filecitats isn't... Juggie isn't...
00:24.51seanbrightnotices he is not an op
00:24.52seanbrightheh
00:24.59filehttp://svn.digium.com/svn/repotools/authors everyone who has commit
00:25.41notbrightWell, I just wondered all this because it's been 2-3 days with no activity on my bug. There's been times when there was action on other projects (bugs) which are opensource without a company backing.
00:25.54seanbrightits the weekend/memorial day
00:25.59seanbrightthat's the main reason
00:26.02notbrightThis is the only project in my mind that I'm working with with a company backing..
00:26.16seanbrightnotbright: what's the bug number?
00:26.33notbrightseanbright: Yeah I know, but other projects haven't stopped any activity due to it being the weekend.. :)
00:26.41notbrightSo I thought maybe this is different with Digium backing.
00:26.46seanbrightnotbright: issue number?
00:27.01notbrightSince all of them are enjoying the wekeend and at home ;)
00:27.03notbrightM12709
00:27.05MuffinMan[feedback] [Asterisk] Applications/app_cdr 0012709: reload stops all action on CLI reported by Yourname (Karma: +1.50) http://bugs.digium.com/view.php?id=12709
00:28.15seanbrightthis is with 1.4.18 still?  or 1.4.20.1?
00:28.21notbright1.4.20.1
00:28.36notbrightProgressed..
00:31.06seanbrightshould really learn how to read backtraces
00:31.07seanbrightheh
00:31.16notbrightseanbright: Added the note for conveniency. :)
00:31.17fileit is not that hard
00:31.30notbrightPS: Everybody, Happy Memorial day.
00:31.36seanbrightwas kidding
00:32.04notbrightlol I think that's a prereq to become someone elite to actually get commit access..
00:32.17filenot really.
00:32.20notbrightOr file's gonna be like "wtf.. seanbright doesn't know how to read backtraces and has commit?!"
00:32.24notbrightNo?
00:32.36notbrightMan, my understanding of you elito coders is certainly fuct.
00:32.46seanbrightthere really isn't much elitism
00:33.03filestuff can always be reverted.
00:34.16notbrightYou guys are just humble.
00:37.10seanbrightohhh, this is chan_sip stuff
00:37.11seanbrightruns and hides
00:38.45notbrightlol
00:40.04notbrightPS: For future reference, how does a notbright newb like me know where the crash is occurring so I can file it in the right category?
00:40.27notbrightseanbright: I think everyone is running and hiding on that one, it's not even been assigned yet! :D
00:40.44seanbrightbets a dollar file ends up with it
00:41.11notbrightLOL
00:41.41seanbrighti could be wrong anyway
00:41.51seanbrightits trying to delete a schedule entry that isn't there
00:41.54seanbrightwhy?  i have no idea.
00:42.25notbrightBecause my life sucks, why does shit always have to happen to me!
00:43.07seanbrightdoes this only happen under load?
00:46.15seanbrightmeh
00:46.20notbrightNo, as soon as traffic starts.
00:46.22seanbrighti could talk it out for hours, but never figure it out
00:46.27seanbright<-- not that smart
00:46.41notbrightInfact, it starts about 10 mins into traffic.
01:48.54*** join/#asterisk-bugs ZX81 (n=matt@202.55.97.173)
01:49.04ZX81hi, can someone reopen 11243?
01:49.12ZX81The fix has not fixed it
01:49.16ZX81M11243
01:49.20MuffinMan[closed] [Asterisk] Codecs/codec_gsm 0011243: Distortion in Playback of .gsm files over non-GSM channel reported by whiskerp (Karma: neutral) http://bugs.digium.com/view.php?id=11243
01:49.31ZX81today's 1.4 SVN
01:49.46ZX81GCC 4.2.3
01:49.52ZX81DONT_OPTIMIZE fixes it
01:50.51ZX81alternatively export CC=gcc-4.1, export CXX=gcc-4.1 fixes it
01:55.15Qwellstill?  wtf
01:55.33Qwellhmm
01:56.12ZX81heh yeah
01:56.29ZX81Asterisk SVN-branch-1.4-r118251
01:57.14ZX81was driving me insane - am at install, had tested with alaw sound files, then onsite I tested with GSM files and it was distorted
01:57.32ZX81like a 20ms packet size when expecting 30ms kinda sound
01:57.47ZX81found the bug entry, and most of the suggestions work
01:58.08ZX81but the patch you committed is in my version and still have same prob
01:59.34ZX81mine is also debian (same as reporter) - also other people who had the problem were ubuntu
01:59.44ZX81wonders if its debian specific
03:05.02*** join/#asterisk-bugs mackes (n=root@cpe-24-198-43-238.buffalo.res.rr.com)
03:05.57*** join/#asterisk-bugs jcmoore (n=jcmoore@unaffiliated/tgrman)
06:50.18*** join/#asterisk-bugs jmls (n=asterisk@host217-36-208-155.in-addr.btopenworld.com)
10:52.32*** join/#asterisk-bugs DagMoller (n=aguirre@unaffiliated/dagmoller)
11:53.01*** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982)
12:36.15*** join/#asterisk-bugs shido6 (n=shido6@209.114.208.192)
12:51.35fileyou know what would be cool? if we could relate an issue to an SVN commit in the relationships part, and the link would go to the actual commit...
13:08.55*** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage)
13:08.55*** mode/#asterisk-bugs [+o lmadsen] by ChanServ
13:22.53*** join/#asterisk-bugs jmls_home (n=jmls_hom@mail.tessera.co.uk)
13:36.52fileM12718
13:36.53MuffinMan[new] [Asterisk] Channels/chan_h323 0012718: Configure function considers openh323 invalid while version 1.6 considers it valid reported by falves11 (Karma: -3.75) http://bugs.digium.com/view.php?id=12718
13:36.55filestrange.
13:48.23lmadsenM12727
13:48.24MuffinMan[new] [Asterisk] Channels/chan_sip/Subscriptions 0012727: Missing notifications after call to non existing extension or failed global pickup attempt reported by mlegas (Karma: neutral) http://bugs.digium.com/view.php?id=12727
13:48.25lmadsenM12728
13:48.26MuffinMan[new] [Asterisk] Core/NewFeature 0012728: Ex-girlfriend-logic requires also most-specific extension matching reported by marsosa (Karma: neutral) http://bugs.digium.com/view.php?id=12728
14:00.20notbrightM12709
14:00.22MuffinMan[feedback] [Asterisk] Applications/app_cdr 0012709: reload stops all action on CLI reported by Yourname (Karma: +1.50) http://bugs.digium.com/view.php?id=12709
14:33.13*** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla)
14:33.13*** mode/#asterisk-bugs [+o russellb] by ChanServ
14:50.58*** join/#asterisk-bugs jmls_home (n=jmls_hom@mail.tessera.co.uk)
14:55.00*** join/#asterisk-bugs putnopvut (n=putnopvu@216.207.245.1)
14:55.00*** mode/#asterisk-bugs [+o putnopvut] by ChanServ
15:10.41*** join/#asterisk-bugs jpeeler (n=jpeeler@216.207.245.1)
15:13.03*** join/#asterisk-bugs jmls_home (n=jmls_hom@mail.tessera.co.uk)
15:14.25*** join/#asterisk-bugs codefreeze-lap (n=murf@216.166.159.235)
15:40.42fileM12671
15:40.43MuffinMan[feedback] [Asterisk] Applications/app_queue 0012671: Dynamic queue member does not survive reboot/restart when using aliases reported by b_plessis (Karma: neutral) http://bugs.digium.com/view.php?id=12671
15:40.50fileyay, module load order changes worked
15:40.55putnopvutYep.
15:41.05putnopvutSo I suppose perhaps this should be documented somewhere?
15:42.24fileit would probably prevent it from creeping up again
15:43.29putnopvutYes yes.
15:46.15fileCorydon76-dig got it
15:46.21putnopvutYes he did.
15:46.24putnopvutThanks Corydon76-dig!
15:47.00Corydon76-digyw
15:50.07Corydon76-dighttp://ars.userfriendly.org/cartoons/?id=20080527
16:00.41fileM12508
16:00.43MuffinMan[feedback] [Asterisk] Channels/chan_sip/Registration 0012508: handle_response_peerpoke floods asterisk cli with notices, cli crashes reported by kactus (Karma: -1.5) http://bugs.digium.com/view.php?id=12508
16:00.47filethat... is sort of cool
16:01.05filewell, cool in a "hey look at what it is doing" way...
16:03.42russellbeep
16:05.59putnopvutAlso cool in a "hey it fixed itself" sort of way.
16:29.25*** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir)
16:57.36*** join/#asterisk-bugs atis_work (n=atis_wor@193.238.212.171)
18:57.45*** join/#asterisk-bugs atis_work (n=atis_wor@193.238.212.171)
19:08.42notbrightM12709
19:08.44MuffinMan[feedback] [Asterisk] Applications/app_cdr 0012709: reload stops all action on CLI reported by Yourname (Karma: +1.50) http://bugs.digium.com/view.php?id=12709
19:08.47notbrightSomeone please help me with this
19:24.58russellbis this really a bug in app_cdr?
19:30.33Yourname`I have no idea russellb
19:30.44Yourname`seanbright thought it could be chan_sip
19:30.59Yourname`I thought it was CDR because in the cli it kept showing stuff about app_cdr
19:32.13seanbrightwas guessing :)
19:33.56codefreeze-lapit's crashing in ast_sched_del in chan_sip, it appears
19:34.15codefreeze-lapthe association with cdrs is probably incidental.
19:37.29codefreeze-lapthe sched_del couldn't find the item to delete, so it does an assert(0)... which is a serious sort of situation, but demanding asterisk cease to function is a bit extreme....
19:37.36Yourname`ah. sorry guys, I didn't know how to know for sure..
19:38.13putnopvutcodefreeze-lap: ast_assert will only actually abort if DO_CRASH is enabled.
19:38.33codefreeze-lapAh-ha... he did have the DO_CRASH set
19:39.45codefreeze-lapThis kinda looks like the situation we solved in trunk... more conscientious handling of possible race conditions in the sched stuff.  This one came out of the rtp stuff in chan_sip.
19:40.25*** join/#asterisk-bugs d1mas (n=chatzill@ip195.117.adsl.wplus.ru)
19:41.49d1masrussellb: hello. you have any thoughts about 12656 ?
19:45.25russellbi have not had time to look at it.
19:46.07d1masok
19:52.26Yourname`codefreeze-lap: But there's other backtraces sans DO_CRASH
19:57.25*** join/#asterisk-bugs atis_work (n=atis_wor@193.238.212.171)
20:01.59*** join/#asterisk-bugs Deeewayne (n=Deeewayn@216.207.245.1)
20:01.59*** mode/#asterisk-bugs [+o Deeewayne] by ChanServ
20:03.29codefreeze-lapYourname`:   true, the second to last, has a lockup in chan_agent.c; stuck waiting at 1022 (in agent_new()), on a lock (p->applock) that was obtained at 2185 (__login_exec)....
20:03.50russellbDETECT_DEADLOCKS is bad with chan_agent
20:04.09russellbchan_agent abuses a mutex, and under normal operation can hold a lock, or block waiting on one for many minutes ...
20:04.42Yourname`lol all that went right over my head!
20:06.14russellbah, well, it was more in response to codefreeze-lap's comment
20:07.00codefreeze-lapMakes sense, russellb... so what he's spotting in chan_agent, may not be the *real* problem?
20:07.07russellbright
20:07.32codefreeze-lapThe only *real* problem, is that crash in the sched_del routine...
20:07.43russellbwhich is because of DO_CRASH?
20:08.00russellbsolution: don't turn on DO_CRASH !!
20:08.09codefreeze-lapyeah, ... and it wouldn't normally be a crash either....
20:08.23russellbright
20:08.58codefreeze-lapOK, back to square one... could the chan_agent locking end up being the cause of his problem? Somehow?
20:09.51Juggierussellb, flowers and sunshine eh? :P
20:17.42codefreeze-laprussellb: waitaminnute... hold on... there *is* one other pretty serious locking situation there!
20:18.15jsmithcodefreeze-lap: w00t!  You've found it?!?
20:18.31jsmithwishes there were only *one* serious locking problem in chan_agent
20:20.47codefreeze-lapMaybe not. Chan_sip has a string of locks, most of them "tried and failed" ... but they are all probably ok, via trylock() or something normal...
20:25.05russellbJuggie: did you like that?  :)
20:29.07Yourname`I'm glad you guys are getting it all slowly.. :D
20:33.32Juggierussellb, yes that was funny.
20:58.01*** join/#asterisk-bugs atis_work (n=atis_wor@193.238.212.171)
21:20.41lmadsenputnopvut: thx for taking 7403!
21:21.12putnopvutlmadsen: heh, I've been working on it for like two weeks and file just told me this morning that it wasn't actually assigned to me yet.
21:21.30lmadsenhaha... nice... well I'm just glad someone is looking at it
21:21.46lmadsennot that it affects me any, but its one of those bugs that has been there too long
21:22.17putnopvutYes, and as I have found, there is no silver bullet for it either.
21:22.33russellbhow about a brass bullet?
21:22.34lmadsenguess that's why its been open so long
21:22.39lmadsencopper?
21:22.48putnopvutYou can't kill a werewolf with brass or copper.
21:22.49Qwellpotato?
21:22.52putnopvutMaybe.
21:22.59russellbhttps://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
21:23.03russellbthat's the list i was talking about
21:23.06putnopvutalready on it.
21:23.08russellbit may be helpful ..
21:23.09russellbah
21:23.10lmadsenbut a bug can be killed with all of those
21:23.21Qwelllmadsen: unless it's a potato bug
21:23.28lmadseno.O
21:23.36putnopvutrussellb: honestly, from a protocol perspective, it's not so bad. It's the Asterisk side which gives me trouble.
21:23.46putnopvutMainly because "Asterisk is not a proxy (tm)"
21:23.47lmadsenok, I have a 1.5 hr window to go get groceries... I can't keep ordering pizza like I have been
21:23.48lmadsenback in a bit!
21:24.17russellbputnopvut: oh, ok.  i don't have a good understanding of the issue, so i'm not very helpful here.  :)P
21:27.43Yourname`M12709
21:27.45MuffinMan[feedback] [Asterisk] Applications/app_cdr 0012709: reload stops all action on CLI reported by Yourname (Karma: +1.50) http://bugs.digium.com/view.php?id=12709
21:27.53seanbrightheh
21:28.04seanbrightlooks around for a dead horse
21:28.55Yourname`lol
21:29.01Yourname`I don't think it'll get solved anytime soon.. :(
21:29.13seanbrightYourname`: turn off DO_CRASH and you're golden
21:29.33putnopvutNot exactly, considering that he'd still have a deadlock.
21:29.38Yourname`seanbright: It
21:29.39seanbrightputnopvut: shhhh
21:29.51Yourname`It's running on no DO_CRASH and yet coredumps once a day.
21:30.10Yourname`DO_CRASH coredumps once every 15 seconds, heh
21:30.15seanbrightheh
21:32.44seanbrightis there something special about your setup?
21:33.49Yourname`Nope.
21:33.56seanbrightweird.
21:33.58Yourname`It runs on a Dell PE 1850 box..
21:34.10Yourname`2.4Ghz, 250GB, 2GB RAM
21:34.13Yourname`Xeon.
21:34.17Yourname`Nothing else.. :S
21:34.21seanbrighthmm
21:34.27putnopvutomg...I just successfully got a SIP spiral to work.
21:34.27seanbrightrunning on a poweredge here too
21:34.30Yourname`I just had it stacked instead of racked..
21:34.48Qwellputnopvut: hooray!
21:35.02seanbrightwtf is a sip spiral?
21:35.05Qwellputnopvut: commit it, get wasted, and forget it ever happened.
21:35.17putnopvutQwell: heh, no telling how flawed my implementation is.
21:35.37putnopvutseanbright: it's like a loop, except that the request URI has changed, so it's destined for a new place.
21:36.07seanbrighti see...
21:36.11putnopvutAsterisk was detecting such a situation as a loop and sending back a 482 instead of correctly allowing the spiral to happen.
21:36.32seanbrightah
21:36.34seanbrighthot.
21:48.07Yourname`seanbright: How do these locks happen anyway?
21:48.20Yourname`I've cmpletely delete src and tried it, and it still happens..
21:48.26Yourname`Is it the hardware, or what exactly?
21:48.35seanbrightYourname`: which locks?
21:48.40Yourname`Why does queues.conf change make so many deadlocks?
21:48.57seanbrightYourname`: it doesn't in my environment
21:49.10seanbrightYourname`: might be agent channel related?
21:49.14Yourname`But then again, you're bright ;)
21:49.43seanbrightYourname`: there are only a few places in the asterisk codebase i feel comfortable commenting on/changing.
21:50.03seanbrightYourname`: channels/chan_* is definitely not one of them
21:50.12Yourname`ag
21:50.16Yourname`lol

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.