00:21.28 | notbright | So, is Asterisk commits reserved only for Digium employees or are there any community guys in lead devel at all? |
00:22.21 | seanbright | you mean commit access to the svn repo? |
00:22.37 | notbright | Yeah |
00:23.09 | seanbright | its not limited to digium employees |
00:23.13 | notbright | Or to make any changes to Asterisk |
00:23.23 | seanbright | i have commit |
00:23.28 | notbright | Cuz I filed a bug, and there hasn't been any action all weekend.. including today |
00:23.28 | seanbright | is not a digium employee |
00:23.41 | notbright | Oh you're devel?! Wow, you're really bright aren't you! :D |
00:23.52 | file | we Digium people do tend to end up being the ones who do that stuff |
00:24.09 | notbright | aaah |
00:24.14 | seanbright | not as bright as some, no. |
00:24.17 | file | as it's not very fun :) |
00:24.18 | notbright | So all the ops in this channel are defacto digiums? |
00:24.21 | seanbright | points at file |
00:24.33 | file | citats isn't... Juggie isn't... |
00:24.51 | seanbright | notices he is not an op |
00:24.52 | seanbright | heh |
00:24.59 | file | http://svn.digium.com/svn/repotools/authors everyone who has commit |
00:25.41 | notbright | Well, 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.54 | seanbright | its the weekend/memorial day |
00:25.59 | seanbright | that's the main reason |
00:26.02 | notbright | This is the only project in my mind that I'm working with with a company backing.. |
00:26.16 | seanbright | notbright: what's the bug number? |
00:26.33 | notbright | seanbright: Yeah I know, but other projects haven't stopped any activity due to it being the weekend.. :) |
00:26.41 | notbright | So I thought maybe this is different with Digium backing. |
00:26.46 | seanbright | notbright: issue number? |
00:27.01 | notbright | Since all of them are enjoying the wekeend and at home ;) |
00:27.03 | notbright | M12709 |
00:27.05 | MuffinMan | [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.15 | seanbright | this is with 1.4.18 still? or 1.4.20.1? |
00:28.21 | notbright | 1.4.20.1 |
00:28.36 | notbright | Progressed.. |
00:31.06 | seanbright | should really learn how to read backtraces |
00:31.07 | seanbright | heh |
00:31.16 | notbright | seanbright: Added the note for conveniency. :) |
00:31.17 | file | it is not that hard |
00:31.30 | notbright | PS: Everybody, Happy Memorial day. |
00:31.36 | seanbright | was kidding |
00:32.04 | notbright | lol I think that's a prereq to become someone elite to actually get commit access.. |
00:32.17 | file | not really. |
00:32.20 | notbright | Or file's gonna be like "wtf.. seanbright doesn't know how to read backtraces and has commit?!" |
00:32.24 | notbright | No? |
00:32.36 | notbright | Man, my understanding of you elito coders is certainly fuct. |
00:32.46 | seanbright | there really isn't much elitism |
00:33.03 | file | stuff can always be reverted. |
00:34.16 | notbright | You guys are just humble. |
00:37.10 | seanbright | ohhh, this is chan_sip stuff |
00:37.11 | seanbright | runs and hides |
00:38.45 | notbright | lol |
00:40.04 | notbright | PS: 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.27 | notbright | seanbright: I think everyone is running and hiding on that one, it's not even been assigned yet! :D |
00:40.44 | seanbright | bets a dollar file ends up with it |
00:41.11 | notbright | LOL |
00:41.41 | seanbright | i could be wrong anyway |
00:41.51 | seanbright | its trying to delete a schedule entry that isn't there |
00:41.54 | seanbright | why? i have no idea. |
00:42.25 | notbright | Because my life sucks, why does shit always have to happen to me! |
00:43.07 | seanbright | does this only happen under load? |
00:46.15 | seanbright | meh |
00:46.20 | notbright | No, as soon as traffic starts. |
00:46.22 | seanbright | i could talk it out for hours, but never figure it out |
00:46.27 | seanbright | <-- not that smart |
00:46.41 | notbright | Infact, it starts about 10 mins into traffic. |
01:48.54 | *** join/#asterisk-bugs ZX81 (n=matt@202.55.97.173) |
01:49.04 | ZX81 | hi, can someone reopen 11243? |
01:49.12 | ZX81 | The fix has not fixed it |
01:49.16 | ZX81 | M11243 |
01:49.20 | MuffinMan | [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.31 | ZX81 | today's 1.4 SVN |
01:49.46 | ZX81 | GCC 4.2.3 |
01:49.52 | ZX81 | DONT_OPTIMIZE fixes it |
01:50.51 | ZX81 | alternatively export CC=gcc-4.1, export CXX=gcc-4.1 fixes it |
01:55.15 | Qwell | still? wtf |
01:55.33 | Qwell | hmm |
01:56.12 | ZX81 | heh yeah |
01:56.29 | ZX81 | Asterisk SVN-branch-1.4-r118251 |
01:57.14 | ZX81 | was 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.32 | ZX81 | like a 20ms packet size when expecting 30ms kinda sound |
01:57.47 | ZX81 | found the bug entry, and most of the suggestions work |
01:58.08 | ZX81 | but the patch you committed is in my version and still have same prob |
01:59.34 | ZX81 | mine is also debian (same as reporter) - also other people who had the problem were ubuntu |
01:59.44 | ZX81 | wonders 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.35 | file | you 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.52 | file | M12718 |
13:36.53 | MuffinMan | [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.55 | file | strange. |
13:48.23 | lmadsen | M12727 |
13:48.24 | MuffinMan | [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.25 | lmadsen | M12728 |
13:48.26 | MuffinMan | [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.20 | notbright | M12709 |
14:00.22 | MuffinMan | [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.42 | file | M12671 |
15:40.43 | MuffinMan | [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.50 | file | yay, module load order changes worked |
15:40.55 | putnopvut | Yep. |
15:41.05 | putnopvut | So I suppose perhaps this should be documented somewhere? |
15:42.24 | file | it would probably prevent it from creeping up again |
15:43.29 | putnopvut | Yes yes. |
15:46.15 | file | Corydon76-dig got it |
15:46.21 | putnopvut | Yes he did. |
15:46.24 | putnopvut | Thanks Corydon76-dig! |
15:47.00 | Corydon76-dig | yw |
15:50.07 | Corydon76-dig | http://ars.userfriendly.org/cartoons/?id=20080527 |
16:00.41 | file | M12508 |
16:00.43 | MuffinMan | [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.47 | file | that... is sort of cool |
16:01.05 | file | well, cool in a "hey look at what it is doing" way... |
16:03.42 | russellb | eep |
16:05.59 | putnopvut | Also 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.42 | notbright | M12709 |
19:08.44 | MuffinMan | [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.47 | notbright | Someone please help me with this |
19:24.58 | russellb | is this really a bug in app_cdr? |
19:30.33 | Yourname` | I have no idea russellb |
19:30.44 | Yourname` | seanbright thought it could be chan_sip |
19:30.59 | Yourname` | I thought it was CDR because in the cli it kept showing stuff about app_cdr |
19:32.13 | seanbright | was guessing :) |
19:33.56 | codefreeze-lap | it's crashing in ast_sched_del in chan_sip, it appears |
19:34.15 | codefreeze-lap | the association with cdrs is probably incidental. |
19:37.29 | codefreeze-lap | the 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.36 | Yourname` | ah. sorry guys, I didn't know how to know for sure.. |
19:38.13 | putnopvut | codefreeze-lap: ast_assert will only actually abort if DO_CRASH is enabled. |
19:38.33 | codefreeze-lap | Ah-ha... he did have the DO_CRASH set |
19:39.45 | codefreeze-lap | This 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.49 | d1mas | russellb: hello. you have any thoughts about 12656 ? |
19:45.25 | russellb | i have not had time to look at it. |
19:46.07 | d1mas | ok |
19:52.26 | Yourname` | 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.29 | codefreeze-lap | Yourname`: 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.50 | russellb | DETECT_DEADLOCKS is bad with chan_agent |
20:04.09 | russellb | chan_agent abuses a mutex, and under normal operation can hold a lock, or block waiting on one for many minutes ... |
20:04.42 | Yourname` | lol all that went right over my head! |
20:06.14 | russellb | ah, well, it was more in response to codefreeze-lap's comment |
20:07.00 | codefreeze-lap | Makes sense, russellb... so what he's spotting in chan_agent, may not be the *real* problem? |
20:07.07 | russellb | right |
20:07.32 | codefreeze-lap | The only *real* problem, is that crash in the sched_del routine... |
20:07.43 | russellb | which is because of DO_CRASH? |
20:08.00 | russellb | solution: don't turn on DO_CRASH !! |
20:08.09 | codefreeze-lap | yeah, ... and it wouldn't normally be a crash either.... |
20:08.23 | russellb | right |
20:08.58 | codefreeze-lap | OK, back to square one... could the chan_agent locking end up being the cause of his problem? Somehow? |
20:09.51 | Juggie | russellb, flowers and sunshine eh? :P |
20:17.42 | codefreeze-lap | russellb: waitaminnute... hold on... there *is* one other pretty serious locking situation there! |
20:18.15 | jsmith | codefreeze-lap: w00t! You've found it?!? |
20:18.31 | jsmith | wishes there were only *one* serious locking problem in chan_agent |
20:20.47 | codefreeze-lap | Maybe 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.05 | russellb | Juggie: did you like that? :) |
20:29.07 | Yourname` | I'm glad you guys are getting it all slowly.. :D |
20:33.32 | Juggie | russellb, yes that was funny. |
20:58.01 | *** join/#asterisk-bugs atis_work (n=atis_wor@193.238.212.171) |
21:20.41 | lmadsen | putnopvut: thx for taking 7403! |
21:21.12 | putnopvut | lmadsen: 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.30 | lmadsen | haha... nice... well I'm just glad someone is looking at it |
21:21.46 | lmadsen | not that it affects me any, but its one of those bugs that has been there too long |
21:22.17 | putnopvut | Yes, and as I have found, there is no silver bullet for it either. |
21:22.33 | russellb | how about a brass bullet? |
21:22.34 | lmadsen | guess that's why its been open so long |
21:22.39 | lmadsen | copper? |
21:22.48 | putnopvut | You can't kill a werewolf with brass or copper. |
21:22.49 | Qwell | potato? |
21:22.52 | putnopvut | Maybe. |
21:22.59 | russellb | https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors |
21:23.03 | russellb | that's the list i was talking about |
21:23.06 | putnopvut | already on it. |
21:23.08 | russellb | it may be helpful .. |
21:23.09 | russellb | ah |
21:23.10 | lmadsen | but a bug can be killed with all of those |
21:23.21 | Qwell | lmadsen: unless it's a potato bug |
21:23.28 | lmadsen | o.O |
21:23.36 | putnopvut | russellb: honestly, from a protocol perspective, it's not so bad. It's the Asterisk side which gives me trouble. |
21:23.46 | putnopvut | Mainly because "Asterisk is not a proxy (tm)" |
21:23.47 | lmadsen | ok, I have a 1.5 hr window to go get groceries... I can't keep ordering pizza like I have been |
21:23.48 | lmadsen | back in a bit! |
21:24.17 | russellb | putnopvut: oh, ok. i don't have a good understanding of the issue, so i'm not very helpful here. :)P |
21:27.43 | Yourname` | M12709 |
21:27.45 | MuffinMan | [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.53 | seanbright | heh |
21:28.04 | seanbright | looks around for a dead horse |
21:28.55 | Yourname` | lol |
21:29.01 | Yourname` | I don't think it'll get solved anytime soon.. :( |
21:29.13 | seanbright | Yourname`: turn off DO_CRASH and you're golden |
21:29.33 | putnopvut | Not exactly, considering that he'd still have a deadlock. |
21:29.38 | Yourname` | seanbright: It |
21:29.39 | seanbright | putnopvut: shhhh |
21:29.51 | Yourname` | It's running on no DO_CRASH and yet coredumps once a day. |
21:30.10 | Yourname` | DO_CRASH coredumps once every 15 seconds, heh |
21:30.15 | seanbright | heh |
21:32.44 | seanbright | is there something special about your setup? |
21:33.49 | Yourname` | Nope. |
21:33.56 | seanbright | weird. |
21:33.58 | Yourname` | It runs on a Dell PE 1850 box.. |
21:34.10 | Yourname` | 2.4Ghz, 250GB, 2GB RAM |
21:34.13 | Yourname` | Xeon. |
21:34.17 | Yourname` | Nothing else.. :S |
21:34.21 | seanbright | hmm |
21:34.27 | putnopvut | omg...I just successfully got a SIP spiral to work. |
21:34.27 | seanbright | running on a poweredge here too |
21:34.30 | Yourname` | I just had it stacked instead of racked.. |
21:34.48 | Qwell | putnopvut: hooray! |
21:35.02 | seanbright | wtf is a sip spiral? |
21:35.05 | Qwell | putnopvut: commit it, get wasted, and forget it ever happened. |
21:35.17 | putnopvut | Qwell: heh, no telling how flawed my implementation is. |
21:35.37 | putnopvut | seanbright: it's like a loop, except that the request URI has changed, so it's destined for a new place. |
21:36.07 | seanbright | i see... |
21:36.11 | putnopvut | Asterisk was detecting such a situation as a loop and sending back a 482 instead of correctly allowing the spiral to happen. |
21:36.32 | seanbright | ah |
21:36.34 | seanbright | hot. |
21:48.07 | Yourname` | seanbright: How do these locks happen anyway? |
21:48.20 | Yourname` | I've cmpletely delete src and tried it, and it still happens.. |
21:48.26 | Yourname` | Is it the hardware, or what exactly? |
21:48.35 | seanbright | Yourname`: which locks? |
21:48.40 | Yourname` | Why does queues.conf change make so many deadlocks? |
21:48.57 | seanbright | Yourname`: it doesn't in my environment |
21:49.10 | seanbright | Yourname`: might be agent channel related? |
21:49.14 | Yourname` | But then again, you're bright ;) |
21:49.43 | seanbright | Yourname`: there are only a few places in the asterisk codebase i feel comfortable commenting on/changing. |
21:50.03 | seanbright | Yourname`: channels/chan_* is definitely not one of them |
21:50.12 | Yourname` | ag |
21:50.16 | Yourname` | lol |