| 01:05.37 | *** join/#asterisk-bugs Juggie (n=Juggie@CPE001601df17fb-CM001ceac25ada.cpe.net.cable.rogers.com) |
| 01:05.37 | *** mode/#asterisk-bugs [+o Juggie] by ChanServ |
| 14:57.25 | *** join/#asterisk-bugs infobot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 14:57.25 | *** topic/#asterisk-bugs is Asterisk Bugs Discussion -=- http://bugs.digium.com/ -=- http://asterisk.org/developers/bug-guidelines - If you are not discussing a report already posted to the bugtracker, the discussion probably belongs in #asterisk. -=- Best overall issue count: 272 -=- Monitor new reports in #asterisk-commits -=- Test bugs marked Ready For Testing -=- Mantis happy now. |
| 15:01.04 | *** join/#asterisk-bugs jpeeler (n=jpeeler@asterisk/digium-software-dev/jpeeler) |
| 15:09.50 | *** join/#asterisk-bugs infobot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 15:09.51 | *** topic/#asterisk-bugs is Asterisk Bugs Discussion -=- http://bugs.digium.com/ -=- http://asterisk.org/developers/bug-guidelines - If you are not discussing a report already posted to the bugtracker, the discussion probably belongs in #asterisk. -=- Best overall issue count: 272 -=- Monitor new reports in #asterisk-commits -=- Test bugs marked Ready For Testing -=- Mantis happy now. |
| 15:33.16 | *** join/#asterisk-bugs Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 15:33.16 | *** mode/#asterisk-bugs [+o Corydon76-lap] by ChanServ |
| 16:31.15 | *** join/#asterisk-bugs oej (n=olle@ns.webway.se) |
| 16:57.05 | Qwell | seanbright: commit it! |
| 16:57.13 | Qwell | (also, woot) |
| 16:57.29 | Qwell | ((and, stupid solaris...)) |
| 16:57.53 | Qwell | it still sort of amuses me that Solaris sh acts that way |
| 17:04.33 | seanbright | oh did it work for him? |
| 17:04.34 | seanbright | super. |
| 17:04.43 | Qwell | he still gets other warnings, but it's not too important |
| 17:09.44 | seanbright | would be nice to resolve those too |
| 17:09.56 | Qwell | strcompat should |
| 17:10.01 | Qwell | not sure what that's about |
| 17:10.36 | seanbright | shrugs |
| 17:10.50 | seanbright | should i commit this fix to 1.4 as well? |
| 17:11.01 | Qwell | yeah, if it's there too |
| 17:11.19 | seanbright | nope |
| 17:11.22 | seanbright | thankfully |
| 17:11.24 | Qwell | then nope :D |
| 17:11.29 | seanbright | no ^ magic, anyway |
| 17:11.33 | Qwell | ahh |
| 17:19.26 | *** join/#asterisk-bugs linuxer_igor (n=linuxer_@mlsrj200152096p202.mls.com.br) |
| 17:21.26 | linuxer_igor | help, I have a problema with DAHDI |
| 17:22.02 | linuxer_igor | update my server today for 1.0.6rc4 and the DAHDI don't work |
| 17:22.31 | linuxer_igor | stay up but do not register |
| 17:44.31 | Qwell | M13113 |
| 17:44.34 | MuffinMan | [new] [Asterisk] Core/General 0013113: [patch] Can't build RPM with 1.4.21.1 (few errors & fix) reported by sybasesql (Karma: +1.50) http://bugs.digium.com/view.php?id=13113 |
| 17:44.42 | Qwell | Is there any reason we should even HAVE an RPM target in the Makefile? |
| 17:45.07 | Qwell | it makes little sense to me |
| 17:46.25 | Qwell | besides, there are plenty of spec files that exist in the world already. no reason to have one in the source that will get out of date all the time |
| 17:47.28 | lmadsen | I like the idea of having an RPM target, but if no one is going to keep it up to date, then I suppose not |
| 17:49.10 | *** join/#asterisk-bugs bbryant (n=brett@68.208.65.50) |
| 17:49.10 | *** mode/#asterisk-bugs [+o bbryant] by ChanServ |
| 17:53.42 | Qwell | I don't know if it's worth the effort to 1) keep it up to date, and 2) make it support menuselect options |
| 17:54.14 | lmadsen | ya, I'm not opposed to it being removed since it has never worked right afaik |
| 17:54.51 | Qwell | it's so trivial to grab the SRPM from Fedora or somewhere, if you need an RPM. It'll be far more "correct" anyways |
| 17:55.53 | lmadsen | shrugs as he installs from source |
| 19:01.01 | mvanbaak | Qwell: I think that if you are going to support an rpm target you should also support deb/opbsd_pkg/fbsd_pkg/slackware_tgs/etc/etc/etc |
| 19:05.22 | seanbright | minix/hurd/com64 |
| 19:06.14 | mvanbaak | like I said: etc/etc/etc |
| 19:08.37 | *** join/#asterisk-bugs implicit (n=bayan@unaffiliated/implicit) |
| 19:08.37 | *** mode/#asterisk-bugs [+o implicit] by ChanServ |
| 19:15.33 | seanbright | atari2600/vms/eniac |
| 19:19.38 | seanbright | enigma |
| 19:19.41 | seanbright | abacus |
| 19:19.56 | seanbright | stone tablet |
| 19:27.29 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |
| 19:29.47 | mvanbaak | I have an atari2600 |
| 19:29.51 | mvanbaak | if you want to test |
| 19:30.07 | mvanbaak | and a sinclair spectrum |
| 19:30.16 | mvanbaak | and an Apple II |
| 19:54.24 | *** join/#asterisk-bugs linuxer_igor (n=linuxer_@mlsrj200152096p202.mls.com.br) |
| 19:59.53 | *** join/#asterisk-bugs Corydon76-lap (n=Corydon7@pdpc/supporter/bronze/Corydon76-home) |
| 19:59.53 | *** mode/#asterisk-bugs [+o Corydon76-lap] by ChanServ |
| 20:00.25 | *** join/#asterisk-bugs geoff2010 (n=geoffrey@75.150.14.50) |
| 20:42.18 | geoff2010 | just have a general question about bugs.digium.com. if a legit bug on a 'stable' release is posted with a backtrace and description what is the usual timeframe before someone gets a chance to look at it? |
| 20:42.36 | seanbright | geoff2010: what bug number? |
| 20:43.06 | geoff2010 | 13435 |
| 20:43.31 | seanbright | M13435 |
| 20:43.38 | MuffinMan | [new] [Asterisk] Core/General 0013435: Asterisk 1.4.21.2 crash ast_do_masquerade (segfault at 00000000000000d8 rip 0000003ad54082f9 rsp 0000000040523fb0 error) reported by geoff2010 (Karma: neutral) http://bugs.digium.com/view.php?id=13435 |
| 20:43.45 | geoff2010 | seanbright: not trying to be pushy, i have never submitted a bug up here and was just curious |
| 20:44.04 | geoff2010 | that's it. |
| 20:44.37 | russellb | geoff2010: I wouldn't hold your breath at this point ... we're pretty slammed, as you can see from the count of open issues |
| 20:44.56 | russellb | in the meantime, I would try the latest release candidate of Asterisk 1.4.22 |
| 20:45.07 | russellb | svn co http://svn.digium.com/svn/tags/1.4.22-rc4 asterisk-1.4.22-rc4 |
| 20:45.21 | russellb | in case it has been fixed since 1.4.21 |
| 20:45.37 | putnopvut | yuck, that looks like a redirect of a hung-up channel. |
| 20:45.38 | russellb | 1.4.22 has close to 300 fixes ... |
| 20:45.59 | russellb | besides, that's the first thing someone will say when they do get to the bug report :) |
| 20:46.11 | file | it is a redirect of a channel that is going to undergoe a Local channel optimization masquerade |
| 20:46.36 | geoff2010 | @file: yes, that is correct, it's a race condition where i issue a redirect on a channel which appears to be going through the masquerade process already |
| 20:46.41 | russellb | should be safe, though, if channel locking is being done properly in the redirect and masq code :( |
| 20:47.18 | seanbright | that's a big if |
| 20:47.26 | russellb | nods |
| 20:47.29 | file | russellb: well... not exactly |
| 20:47.36 | russellb | o.O |
| 20:47.37 | file | masquerading doesn't happen when you call the function |
| 20:47.40 | russellb | nods |
| 20:47.44 | file | it happens on the next read/write |
| 20:47.52 | russellb | right |
| 20:48.09 | russellb | so, it's a masq of a channel that has already been masq'd? |
| 20:48.18 | file | that will be masq'd |
| 20:48.55 | seanbright | on the next read/write |
| 20:49.01 | seanbright | is all caught up. |
| 20:49.47 | geoff2010 | what read/write is being referred to? |
| 20:50.12 | russellb | perhaps we should get on the phone |
| 20:50.22 | russellb | i fail to see the point in time that can cause something to blow up |
| 20:50.32 | file | is about to reboot his phone so it upgrades |
| 20:50.47 | seanbright | imagine if edison were alive to read that message |
| 20:50.52 | seanbright | err |
| 20:50.53 | seanbright | hahaha |
| 20:50.55 | seanbright | bell, rather. |
| 20:50.57 | file | and i'm not saying the seg fault isn't an issue... |
| 20:51.07 | russellb | clearly it's an issue :) |
| 20:51.10 | file | but setting up a channel to masquerade when it is already going to is |
| 20:51.12 | geoff2010 | if the phone had a blinking light edison would be psyched :) |
| 20:51.19 | seanbright | geoff2010: well played. |
| 20:51.30 | russellb | file: then the local masq process is bad. |
| 20:51.43 | seanbright | goes away |
| 20:51.49 | russellb | channel_masq() and do_masq() _really_ should be an atomic operation |
| 20:52.21 | file | yes |
| 20:52.53 | russellb | oh wow ... if a channel that is already scheduled to masq has channel_masq() called on it ... |
| 20:52.57 | russellb | it's basically a no-op |
| 20:53.09 | russellb | and the following do_masq() is going to access a channel that it has no right to access |
| 20:53.15 | russellb | sheesh |
| 20:53.22 | file | it's... a mess |
| 20:53.24 | russellb | yes. |
| 20:53.35 | russellb | ok, so, the action_redirect() _does_ do this process in an atomic fashion, so it's ok |
| 20:53.44 | russellb | which _unfortunately_ leads us to chan_local ... |
| 20:53.44 | russellb | :( |
| 20:53.48 | file | nods |
| 20:53.53 | russellb | this is +1 sad |
| 20:54.07 | jsmith-teaching | Kablooey! |
| 20:54.10 | russellb | geoff2010: i don't expect this to be fixed in a new version ... |
| 20:54.27 | geoff2010 | @rusellb: i am getting that sense |
| 20:55.16 | russellb | file: here's an idea! it's sort of a hack to keep async_goto from crashing |
| 20:55.23 | russellb | So, in this case, channel_masq() will return an error |
| 20:55.31 | russellb | We can detect the error, and not try to complete the masq |
| 20:55.39 | russellb | right now it blinding goes on and calls do_masq |
| 20:55.51 | russellb | instead of blowing up, it would just fail the redirect |
| 20:56.02 | file | nods |
| 20:56.06 | russellb | agreed? |
| 20:56.19 | russellb | dare I just commit that? |
| 20:56.21 | russellb | that would be easy ... |
| 20:58.20 | russellb | compiles |
| 20:58.22 | file | wouldn't make it work though... but would stop the crash |
| 20:58.50 | russellb | well right |
| 20:58.58 | russellb | but if a masq is happening, there's nothing we can do |
| 20:59.01 | russellb | it's just not going to work ... |
| 20:59.22 | russellb | we could be evil and loop around trying to wait for the masq to occur ... |
| 20:59.26 | geoff2010 | making a single redirect fail is always a better option than a core dump, no? |
| 20:59.39 | russellb | but that involves releasing the channel lock, and going back to get it from the channel list each time we want to retry |
| 20:59.42 | russellb | i'd rather not. |
| 20:59.45 | russellb | geoff2010: yeah :) |
| 21:00.01 | file | yay russellb |
| 21:00.10 | geoff2010 | can i just confirm that this is, in fact a race condition? it appears that my strategic placement of a 250ms sleep has made the problem not happen. |
| 21:00.23 | russellb | geoff2010: yes, it is |
| 21:00.44 | russellb | this should fix it ... http://pastebin.ca/1197528 |
| 21:02.59 | russellb | committed :) |
| 21:03.16 | russellb | geoff2010: and by "don't hold your breath", i meant, "hang on, I'll fix it right now" |
| 21:03.47 | geoff2010 | @russellb: not everyone has as good a sense of time as you! |
| 21:03.59 | russellb | however, the patch did not make it into the 1.4.22 and 1.6.0 release candidates I _just_ made |
| 21:04.04 | russellb | sighs |
| 21:06.08 | russellb | geoff2010: thanks for the well written report :) |
| 21:09.19 | geoff2010 | russellb: thanks for looking at that, i understand you guys are swamped. it's much appreciated! |
| 21:34.45 | *** join/#asterisk-bugs mvanbaak_ (n=michiel@asterisk/contributor-and-bug-marshal/mvanbaak) |
| 22:04.41 | *** join/#asterisk-bugs shido6 (n=shido6@209.114.208.192) |
| 22:09.12 | *** join/#asterisk-bugs tuxd00d (n=tuxd00d@128.187.132.25) |
| 22:32.38 | *** join/#asterisk-bugs fakhir (n=fakhir@unaffiliated/fakhir) |