| 01:44.17 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 01:44.18 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 01:50.44 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 01:50.44 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 02:04.28 | *** join/#asterisk-bugs mackes (n=root@cpe-24-198-43-238.buffalo.res.rr.com) |
| 02:19.20 | *** join/#asterisk-bugs mackes (n=root@cpe-24-198-43-238.buffalo.res.rr.com) |
| 02:38.04 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 04:06.39 | *** join/#asterisk-bugs mackes (n=root@cpe-24-198-43-238.buffalo.res.rr.com) |
| 06:36.34 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 10:56.31 | *** join/#asterisk-bugs DagMoller (n=aguirre@unaffiliated/dagmoller) |
| 11:59.14 | *** join/#asterisk-bugs jeremy_g (n=jerms@static-213-115-44-90.sme.bredbandsbolaget.se) |
| 12:00.17 | jeremy_g | bed bugs |
| 12:04.42 | *** join/#asterisk-bugs russellb (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 12:04.42 | *** mode/#asterisk-bugs [+o russellb] by ChanServ |
| 12:11.41 | *** join/#asterisk-bugs caio1982 (i=caio1982@CAcert-br/caio1982) |
| 12:19.55 | *** join/#asterisk-bugs shido6 (n=shido6@209.114.208.192) |
| 13:15.44 | *** join/#asterisk-bugs lmadsen (n=Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 13:15.44 | *** mode/#asterisk-bugs [+o lmadsen] by ChanServ |
| 13:52.33 | *** join/#asterisk-bugs putnopvut (n=putnopvu@216.207.245.1) |
| 13:52.33 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 15:00.40 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 15:17.58 | *** join/#asterisk-bugs bbryant (n=brett@216.207.245.1) |
| 15:17.58 | *** mode/#asterisk-bugs [+o bbryant] by ChanServ |
| 15:27.03 | *** join/#asterisk-bugs drumkilla (n=russell@asterisk/developer-and-stable-maintainer/drumkilla) |
| 15:27.03 | *** mode/#asterisk-bugs [+o drumkilla] by ChanServ |
| 15:32.14 | *** join/#asterisk-bugs danlock2 (n=bean@wikipedia/danlock2) |
| 15:51.16 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 16:12.09 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 16:57.31 | *** join/#asterisk-bugs atis_work (n=atis_wor@193.238.212.171) |
| 17:07.46 | *** join/#asterisk-bugs Yourname` (n=chatzill@unaffiliated/yourname/x-837320) |
| 17:08.07 | Yourname` | Hi Corydon76-dig, thanks for your help earlier on mantis. I now have atleast 3 backtraces for you guys.. |
| 17:08.12 | Yourname` | M12709 |
| 17:08.13 | MuffinMan | [feedback] [Asterisk] Applications/app_cdr 0012709: reload stops all action on CLI reported by Yourname (Karma: neutral) http://bugs.digium.com/view.php?id=12709 |
| 17:09.18 | Corydon76-dig | Yourname`: excellent, thank you |
| 17:09.57 | Yourname` | No, thank YOU. |
| 17:21.27 | *** join/#asterisk-bugs mking_cd (n=mking_cd@pool-72-78-183-123.phlapa.east.verizon.net) |
| 17:21.59 | mking_cd | Has anyone had a problem with ChanSpy() having un-synced audio after the spied on user puts the other caller on hold? |
| 17:24.32 | putnopvut | mking_cd: does that involve pressing DTMF? |
| 17:24.59 | putnopvut | mking_cd: because I have noticed that pressing DTMF digits when spying will cause the audio to be delayed by however long you pressed the DTMF. |
| 17:25.21 | mking_cd | no, it's not DTMF |
| 17:25.29 | putnopvut | oh...hm, then that's something else. |
| 17:26.39 | file | mking_cd: what exact version? |
| 17:26.42 | file | of Asterisk |
| 17:26.52 | mking_cd | caller A calls caller B. Caller C spies caller A. Caller A puts caller B on hold. Caller A resumes with Caller B. Caller C (spy) hears caller B's audio from while he was on hold |
| 17:27.08 | mking_cd | 1.4.19 |
| 17:28.09 | file | I'm pretty sure that was fixed in .20 |
| 17:28.28 | file | commit asterisk 113296 |
| 17:28.30 | MuffinMan | [113296] Committed by file on 2008-04-08T15:03:43.641748Z: If audio suddenly gets fed into one side of a channel after a lapse of frames flush the other factory so that old audio does not remain in the factory causing the sync code to not execute. |
| 17:28.31 | MuffinMan | ..(closes issue #12296) |
| 17:28.31 | MuffinMan | ..Reported by: jvandal |
| 17:28.45 | file | that came after .19 was released |
| 17:29.08 | mking_cd | thanks file |
| 17:29.29 | mking_cd | and MuffinMan |
| 17:29.43 | mking_cd | I'll check out the bug and patch my system |
| 17:31.10 | mking_cd | From what I can tell, bug 12296 fixes a similar problem with MixMonitor, I assume that bug was also effecting ChanSpy()? |
| 17:31.26 | file | yes. |
| 17:31.49 | file | hrm, actually now that I think about it... maybe not |
| 17:32.44 | mking_cd | it's weird, the caller B audio is delayed by the exact amount of time that he was on hold. |
| 17:33.17 | mking_cd | Pressing * to switch spied channels (but there are not other matched channels to spy), re-syncs the audio |
| 17:33.30 | file | if it does not fix it, file an issue report so it does not get lost |
| 17:34.28 | Yourname` | Corydon76-dig: Quick question, am I right in putting it under app_cdr for the crash? |
| 17:36.08 | mking_cd | I will do that. I'll have to patch and test my lab systems |
| 17:36.21 | Corydon76-dig | Yourname`: probably not, but I'm trying to figure out the backtrace right now |
| 17:36.48 | Corydon76-dig | Yourname`: I'm not really sure where the crash is happening, because what gdb reports doesn't make any sense |
| 17:48.17 | Yourname` | :S |
| 17:48.28 | Yourname` | Corydon76-dig: Is there anything else I can do to help? |
| 17:53.19 | Corydon76-dig | Yourname`: may need another pair of eyes |
| 17:59.07 | mking_cd | file, 113296 fixes the ChanSpy() issue |
| 17:59.16 | mking_cd | at least, in my limited testing :-) |
| 17:59.17 | file | neat |
| 17:59.33 | drumkilla | commit asterisk 113296 |
| 17:59.34 | mking_cd | time to schedule a maintenance event ;-) |
| 17:59.35 | MuffinMan | [113296] Committed by file on 2008-04-08T15:03:43.641748Z: If audio suddenly gets fed into one side of a channel after a lapse of frames flush the other factory so that old audio does not remain in the factory causing the sync code to not execute. |
| 17:59.36 | MuffinMan | ..(closes issue #12296) |
| 17:59.36 | MuffinMan | ..Reported by: jvandal |
| 18:02.19 | Yourname` | Corydon76-dig: lol |
| 18:02.39 | Corydon76-dig | Yourname`: that means another person to look at the issue |
| 18:05.23 | Yourname` | Corydon76-dig: Understando mundo. |
| 18:56.46 | *** join/#asterisk-bugs atis_work (n=atis_wor@193.238.212.171) |
| 19:37.50 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 19:57.21 | *** join/#asterisk-bugs atis_work (n=atis_wor@193.238.212.171) |
| 19:59.58 | Yourname` | Corydon76-dig: core show locks at y0 service! |
| 20:00.13 | Corydon76-dig | Yourname`: cool |
| 20:01.21 | Qwell | Yourname`: silly question - have you tried anything newer than 1.4.18? |
| 20:02.36 | Yourname` | Qwell: Yes, I've had numerous issues with DTMF and queues... too big a risk, so I reverted back to .18, which worked well. |
| 20:11.30 | Corydon76-dig | Yourname`: I note that 1.4.18 doesn't include the fix that you reported in issue #12242 |
| 20:11.53 | Corydon76-dig | which is dtmf related |
| 20:13.33 | Yourname` | Corydon76-dig: Naw, I didn't report it. |
| 20:13.50 | Yourname` | That issue was another dtmf issue. DTMF effery to me. :( |
| 20:14.34 | Corydon76-dig | What was the new DTMF issue? |
| 20:15.56 | Yourname` | I don't remember correctly, but I think it was something when an agent presses a number to be as DTMF, it wouldn't pass on. Nothing was changed in the conf at all. It was just an upgrade.. then when I reverted it was fine again. |
| 20:16.12 | Yourname` | I definitely went on #asterisk for help. |
| 20:16.21 | Yourname` | And might have even posted to the list, let me see if I did. |
| 20:23.06 | Yourname` | http://preview.tinyurl.com/6sa3ho |
| 20:23.35 | Yourname` | But I also think there was a lot more that happened, and since no one was _really_ that helpful and I was losing time since it was a production box, I quickly reverted. |
| 20:24.11 | Yourname` | I vaguely remember that on #asterisk, around the same time, a couple users complained of the same thing and one of them acknowledged the reverting back to 1.4.18 helped. |
| 20:50.07 | Yourname` | I read somewhere that sometimes restarts take care of locks, but I just restarted about 10 mins ago.. and no dice. |
| 20:57.01 | *** join/#asterisk-bugs atis_work (n=atis_wor@193.238.212.171) |
| 20:57.15 | Qwell | Yourname`: NOTHING changed in the conf? |
| 20:57.22 | Qwell | Didn't we go over this yesterday? :) |
| 20:58.37 | Yourname` | Qwell: No, I'm telling Corydon76-dig of the previous issue which actually made me revert to 1.4.18 |
| 20:59.06 | Yourname` | A month or so old issue ;) |
| 20:59.06 | Qwell | yes, just rehashing the whole "make sure nothing ACTUALLY changed, whether you know about it or not" thing |
| 20:59.17 | Yourname` | lol thanks |
| 20:59.25 | Qwell | which I'm sure you remember all too well from yesterday ;) |
| 20:59.37 | Yourname` | Yes, I do. I can't believe I did that, heh |
| 21:01.01 | Corydon76-dig | Qwell: dtmfmode defaults to rfc2833, correct? |
| 21:01.16 | Qwell | probably |
| 21:01.20 | Qwell | or auto |
| 21:01.43 | Corydon76-dig | I wonder if autodetection was what screwed him up |
| 21:04.00 | Corydon76-dig | Yourname`: Are you just doing a 'reload' command when this happens? Nothing more specific? |
| 21:04.33 | Corydon76-dig | i.e. can you isolate this down to "reload chan_agent.so" or "sip reload" or "reload app_queue.so"? |
| 21:05.28 | Yourname` | Corydon76-dig: Right now I'm not even doing any reloads.. too scared. |
| 21:05.43 | Yourname` | Yesterday the whole that started this was reload app_queue.so |
| 21:05.52 | Yourname` | Nothing seemed to happen on the CLI. |
| 21:06.02 | Yourname` | So, I _totally_ forgot that it might have locked up. |
| 21:06.08 | Yourname` | I went ahead and did a reload. |
| 21:06.26 | Yourname` | Then it stuck for sure, cuz I didn't see anything at all. |
| 21:07.05 | Corydon76-dig | Well, here's the thing about any CLI command. It will not show any more output until the command is complete |
| 21:07.29 | Corydon76-dig | so it might not even be locked up, just waiting for a resource |
| 21:08.01 | Yourname` | Yeah, I waited more than 30 secs after reload app queue |
| 21:08.13 | Yourname` | But since there's been atleast a few restarts. |
| 21:13.20 | Corydon76-dig | Yourname`: are you using AgentCallbackLogin? |
| 21:14.08 | Yourname` | Corydon76-dig: AgentLogin |
| 21:20.26 | putnopvut | M12671 |
| 21:20.42 | 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 |
| 21:20.57 | putnopvut | Issue has been identified but the "fix" doesn't seem to work for the reporter. |
| 21:21.12 | putnopvut | I'm wondering if anyone has some feedback or can suggest another course of action. |
| 21:24.40 | Corydon76-dig | putnopvut: perhaps res_features.so needs a preload, as well? |
| 21:25.10 | putnopvut | Is that because chan_local depends on res_features? |
| 21:25.27 | Corydon76-dig | I'd also not specify app_queue at all and let it autoload, if possible |
| 21:25.46 | Corydon76-dig | Or make the first couple preload and only app_queue as just "load" |
| 21:25.56 | putnopvut | Gotcha... |
| 21:26.15 | putnopvut | For res_features, should that be loaded before or after the channel drivers and before or after app_queue? |
| 21:26.27 | putnopvut | I guess before app_queue since app_queue calls ast_bridge_call. |
| 21:26.27 | Corydon76-dig | First |
| 21:26.58 | Corydon76-dig | That's why it's rolled into main in trunk |
| 21:27.11 | putnopvut | Righty-right. |
| 21:27.28 | Corydon76-dig | and if he's doing any realtime at all, those also need to be preload |
| 21:28.19 | Corydon76-dig | OH! |
| 21:28.41 | Corydon76-dig | He's got Agent members in his persistent members, but he's not preloading chan_agent.so |
| 21:28.54 | Corydon76-dig | That might help |
| 21:28.57 | putnopvut | No, he just calls them Agents, but they're local channels. |
| 21:29.23 | putnopvut | Agent/xxx is what he has set for the member name. |
| 21:29.33 | putnopvut | He's not the only one that does that. It seems very confusing to me. |
| 21:29.44 | Corydon76-dig | Oh |
| 21:30.46 | Corydon76-dig | Yeah, that's messed up |
| 21:32.40 | Corydon76-dig | Got it |
| 21:32.50 | Corydon76-dig | preload => pbx_extensions.so |
| 21:33.31 | Corydon76-dig | The devicestate of a Local channel is whether it exists in the dialplan. No dialplan, then the Local channel doesn't exist |
| 21:33.58 | Corydon76-dig | or pbx_config.so rather |
| 21:36.49 | Corydon76-dig | putnopvut: note added |
| 21:37.25 | *** join/#asterisk-bugs mvanbaak (n=michiel@vanbaak.xs4all.nl) |
| 21:37.53 | putnopvut | Corydon76-dig: thanks! :) |
| 21:52.49 | Yourname` | Hmm, I can't revert to 1.4.17.. because that had some problems, neither can I upgrade. 1.4.18 was such a good boy for so long.. :( |
| 22:02.55 | Corydon76-dig | Yourname`: I assume you've already looked at 1.4.20? |
| 22:04.43 | Yourname` | All these locks are in chan_agent.c |
| 22:04.56 | Yourname` | Corydon76-dig: I'm going to be looking at 1.4.20.1 soon too |
| 22:05.26 | Yourname` | Corydon76-dig: newb question, I don't need to always upgrade the other libpri/zaptel/addons everytime I upgrade asterisk, right? |
| 22:06.09 | Corydon76-dig | Sometimes in all cases |
| 22:08.08 | Yourname` | ah |
| 22:09.57 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 22:18.22 | Yourname` | Alright, I'm going to jump into 1.4.20.1 |
| 22:31.31 | Yourname` | Whoa DO_CRASH doesn't seem to be present in 1.4.20.1 |
| 22:31.53 | Qwell | Why did you have DO_CRASH enabled? |
| 22:32.24 | Yourname` | When I needed it to coredump this morning, yeah... |
| 22:37.00 | putnopvut | The absense of DO_CRASH is a side-effect of adding the new ast_assert function. |
| 22:37.46 | putnopvut | Actually, it's still there... |
| 22:38.00 | putnopvut | Ah, that's right, ast_assert will only crash if DO_CRASH is defined. |
| 22:41.28 | Yourname` | So... |
| 22:41.38 | Yourname` | How can I enable it in make menuselect? |
| 22:41.57 | Yourname` | I really want to so it crashes and dumps so I can give you guys more info, heh |
| 22:42.39 | putnopvut | Yourname`: oh, I know what the deal is... |
| 22:42.55 | putnopvut | DO_CRASH is only selectable if you ran configure with dev mode turned on. |
| 22:43.13 | putnopvut | But the thing is, I think we can probably get to the root of your issue without that. |
| 22:43.16 | Yourname` | I see, DONT_OPTIMIZE(checked), DEBUG_CHANNEL_LOCKS, DEBUG_THREADS (checked), LOW_MEMORY, MALLOC_DEBUG, RADIO_RELAX, STATIC_BUILD, LOADABLE_MODULES (checked) |
| 22:43.31 | Yourname` | root of my bug issue you mean? |
| 22:43.36 | putnopvut | Exactly. |
| 22:43.41 | Yourname` | Or root of why DO_CRASH is not visible? |
| 22:43.52 | putnopvut | I know exactly why DO_CRASH isn't visible. |
| 22:44.13 | Yourname` | Oh, ok. I got excited there for a second, heh. But this is good to. Please help, good sir. |
| 22:44.49 | putnopvut | I would love to, especially since your problem started by trying an operation on the queue module. |
| 22:45.06 | Yourname` | No no, I'm doing a fresh upgrade to 1.4.20.1 this time. |
| 22:45.12 | putnopvut | Oh. |
| 22:45.18 | putnopvut | Then don't worry about DO_CRASH. |
| 22:45.45 | putnopvut | Anyway, I actually have to get going in another minute or two. Got an appointment at 6:00. |
| 22:45.48 | Yourname` | But yeah, some queue thing went nuts on 1.4.18, which is at M12709. And Corydon76-dig has been looking at it, but I'm trying to run to 1.4.20.1 and see if it fixes. |
| 22:46.18 | putnopvut | I'm not sure about that specific issue, but I know lots of deadlocks have been fixed between those versions. |
| 22:46.27 | seanbright | then just run ./configure --enable-dev-mode |
| 22:46.50 | Yourname` | seanbright: Ok. Is that a new thing tho, post 1.4.20? |
| 22:47.08 | seanbright | Yourname`: nope, its been around |
| 22:47.13 | putnopvut | Gotta go. Good luck Yourname` ! |
| 22:47.25 | Yourname` | I've always done ./configure and then make menuselect and it was working. Hmm. |
| 22:47.29 | Yourname` | putnopvut: Thanks! :) |
| 22:47.48 | seanbright | Yourname`: DO_CRASH was changed to only show up when --enable-dev-mode is passed to configure before 1.4.20.1 was released. |
| 22:47.58 | Yourname` | seanbright: Did it. And make menuselect still no show. |
| 22:48.09 | seanbright | gmake dist-clean |
| 22:48.14 | seanbright | start over |
| 22:48.18 | seanbright | err |
| 22:48.20 | seanbright | make dist-clean |
| 22:48.35 | Yourname` | k |
| 22:48.54 | Yourname` | I'm praying this 1.4.20.1 removes all the deadlockers :( |
| 22:49.24 | Yourname` | seanbright: Works! I see it now, thanks man! |
| 22:49.28 | seanbright | yup |
| 22:49.59 | Yourname` | So, I'm going to run dont optimize, debug threads, debug channel locks and do crash. |
| 22:50.12 | Yourname` | And then go on with my life. If it ever coredumps, I'll have good info. |
| 22:50.31 | seanbright | correct |
| 22:58.46 | Yourname` | Thanks seanbright |
| 22:58.59 | notbright | In your honor. |
| 22:59.12 | seanbright | heh |
| 22:59.22 | seanbright | its my name, not a statement of fact |
| 22:59.43 | notbright | In my case, it is the latter ;) |
| 22:59.53 | notbright | Honor and truth. Two birds, my friend. |
| 23:15.42 | notbright | Looks like the deadlocks are gone! |
| 23:16.06 | notbright | Just this error: 19:14:41] WARNING[6729]: app_queue.c:3014 try_calling: The device state of this queue member, Agent/216, is still 'Not in Use' when it probably should not be! Please check UPGRADE.txt for correct configuration settings. |
| 23:21.50 | *** join/#asterisk-bugs mackes (n=root@cpe-24-198-43-238.buffalo.res.rr.com) |
| 23:22.44 | notbright | ...and it doesn't say much in upgrade.txt about this |
| 23:23.49 | notbright | Corydon76-dig: I upgraded to 1.4.20.1, I don't see any deadlocks on CLI. |
| 23:24.08 | notbright | (Shit, I forgot to check DETECT_DEADLOCKS, that's probably why I'm not seeing any. Recompile time..) |
| 23:26.47 | notbright | Yuuup, my bad. There's still quite a few I see in the CLI. |
| 23:26.53 | notbright | Let me gdb it up. |
| 23:27.08 | notbright | What's with that error tho? |
| 23:38.37 | notbright | Corydon76-dig: I updated M12709 with more info. |
| 23:38.40 | notbright | M12709 |
| 23:38.42 | 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 |