| 01:15.36 | *** join/#asterisk-bugs seraphie (~erin@75.76.38.159) |
| 05:01.53 | *** join/#asterisk-bugs irroot (~irroot@197.104.43.6) |
| 06:20.46 | *** join/#asterisk-bugs singler (~singler@81-7-123-162.static.zebra.lt) |
| 06:24.30 | *** join/#asterisk-bugs irroot (~irroot@pbx.distrotech.co.za) |
| 06:25.22 | *** join/#asterisk-bugs tzafrir (~tzafrir@local.xorcom.com) |
| 11:44.27 | *** join/#asterisk-bugs leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 11:44.27 | *** mode/#asterisk-bugs [+o leifmadsen] by ChanServ |
| 13:02.58 | *** join/#asterisk-bugs malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:02.58 | *** mode/#asterisk-bugs [+o malcolmd] by ChanServ |
| 13:06.59 | *** join/#asterisk-bugs malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 13:06.59 | *** mode/#asterisk-bugs [+o malcolmd] by ChanServ |
| 13:09.50 | *** join/#asterisk-bugs oej (~olle@ns.webway.se) |
| 13:18.34 | leifmadsen | Corydon76-home: ping? |
| 13:18.48 | Corydon76-home | pong |
| 13:19.38 | leifmadsen | ohai! |
| 13:19.45 | Corydon76-home | sup? |
| 13:20.40 | leifmadsen | I think I found a bug in voicemail with SQL because it's trying to do a limit 1 against an MSSQL database |
| 13:20.49 | leifmadsen | going to look at the diff in app_voicemail.c |
| 13:21.06 | leifmadsen | I was going to ask if it might be an ODBC problem, but the SQL prep would be done in app_voicemail |
| 13:21.25 | leifmadsen | it's doing this: SELECT msgnum FROM voicemessages WHERE dir=? order by msgnum desc limit 1 |
| 13:21.39 | leifmadsen | when I think for MSSQL it needs to do: SELECT TOP 1 msgnum FROM voicemessages WHERE dir=? order by msgnum desc |
| 13:21.51 | Corydon76-home | Ah, so it's an invalid query |
| 13:22.29 | Corydon76-home | There's no real fix for that other than to encode a value that says whether limits are based upon the limit clause or the top clause |
| 13:22.30 | leifmadsen | right |
| 13:22.51 | leifmadsen | like in res_odbc.conf ? |
| 13:22.56 | Corydon76-home | preferably in res_odbc.conf, yes |
| 13:23.06 | leifmadsen | ya, limit 1 is invalid in MSSQL as I just found out |
| 13:23.19 | leifmadsen | upgrading from 1.8.4.2 to 1.8.5.0 broke his voicemail :) |
| 13:23.24 | Corydon76-home | Then add an api to access that value, same as backslash_is_escape |
| 13:23.32 | leifmadsen | ok, I will do that |
| 13:23.57 | Corydon76-home | Or just remove the "limit 1" clause |
| 13:24.14 | leifmadsen | where is backslash_is_escape, res_odbc.c right? |
| 13:24.29 | Corydon76-home | If only the first row is ever accessed, then the addition of 'limit 1' was an improper optimization |
| 13:24.34 | Corydon76-home | Yes |
| 13:24.50 | leifmadsen | I'm going to find out who put in limit 1 and see why they thought it was necessary |
| 13:25.02 | leifmadsen | I'm curious if limit 1 is necessary at all |
| 13:25.39 | Corydon76-home | Just eliminating it is probably enough... without getting into this mega-issue detailing how to do limits |
| 13:26.37 | leifmadsen | agreed |
| 13:26.59 | leifmadsen | I will try just removing the limit 1 and search for who made the change so I can discuss too |
| 13:27.00 | leifmadsen | thanks! |
| 13:27.30 | leifmadsen | alecdavid :) |
| 13:27.31 | Corydon76-home | Revision 312212 introduced the problem |
| 13:27.35 | leifmadsen | alecdavis :) |
| 13:27.46 | Corydon76-home | Yep |
| 13:28.12 | irroot | round of beers all agree ?? |
| 13:28.36 | leifmadsen | :D |
| 13:28.43 | leifmadsen | hmmmm now I have to figure out why it was added |
| 13:28.52 | Corydon76-home | Looks like the issue went into 1.4 and up, so given last-release-broken, it may need another-final-release |
| 13:28.53 | leifmadsen | seems like it was to fix a resequencing problem |
| 13:29.02 | leifmadsen | yep agreed |
| 13:29.13 | leifmadsen | let me find the issues and open a new one as a regression and tag it for 1.4+ |
| 13:29.16 | leifmadsen | malcolmd: ^^^ |
| 13:30.14 | malcolmd | yeah, i can concur with that. regressions in "last release" aren't good. we don't want that hanging out there for all time |
| 13:30.23 | leifmadsen | agreed |
| 13:30.28 | leifmadsen | and it totally breaks voicemail on MSSQL |
| 13:31.22 | Corydon76-home | Given this problem type and the potential for further issues, I would like to suggest a modification of the code guidelines to emphasize that SQL must be portable |
| 13:31.33 | leifmadsen | +1 |
| 13:31.45 | Corydon76-home | and include this, along with other examples as SQL that isn't portable |
| 13:31.49 | Marquis42 | Yeah, +1 from me too. I only use MySQL personally, but non-portable SQL sucks. |
| 13:32.29 | Corydon76-home | Or include a link in the code guidelines to a website that presents a fuller discussion |
| 13:33.09 | leifmadsen | I only use MySQL as well until a customer calls me who is using MSSQL :) |
| 13:33.23 | Marquis42 | lol |
| 13:35.15 | leifmadsen | Corydon76-home: thanks for your time and input |
| 13:35.28 | Corydon76-home | yw |
| 13:37.27 | Marquis42 | FWIW, I agree with Corydon76-home that just removing the 'limit 1' is the right fix here. There's no reason that will change the logic used. |
| 13:39.47 | leifmadsen | ok cool, so limit 1 is just unnecessary -- I'll put that in my bug report |
| 13:40.04 | leifmadsen | will file it as soon as I recompile this box as it is crashing/deadlocking on 1.8.5.0 as well, so adding some additional debug flags |
| 13:40.22 | leifmadsen | does file get notified every time someone uses the word file in their sentence? |
| 13:40.26 | leifmadsen | file: is that true? :) |
| 13:40.26 | Marquis42 | Well it's an optimization, but in this case one that's non-portable and obviously breaks MSSQL users (at least). |
| 13:40.38 | file | leifmadsen, yes. |
| 13:40.38 | Marquis42 | haha |
| 13:41.00 | leifmadsen | Marquis42: right, and the only solution for that is a separate option (per Corydon76-home) which seems silly just to optimize the return on a SELECT |
| 13:41.21 | leifmadsen | I mean, I guess it could be useful if you had 1000 msg's in your INBOX.... :) |
| 13:41.48 | Marquis42 | Even then your database would have to be pretty slow and/or heavily abused. |
| 13:44.10 | leifmadsen | ya |
| 13:44.23 | leifmadsen | and if that's the case you have other problems already :) |
| 13:44.46 | Marquis42 | Exactly |
| 13:49.08 | *** join/#asterisk-bugs The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 13:51.06 | Corydon76-home | leifmadsen: so next, write a test that will fail on this condition... |
| 13:51.31 | Corydon76-home | and succeed with your fix |
| 13:52.07 | leifmadsen | Corydon76-home: fancy! |
| 13:52.57 | Corydon76-home | I believe there's a developer version of MS SQL Server which could be justifiably used for this type of test in our continuous integration |
| 13:56.09 | Corydon76-home | Not really kidding... this is a potential future issue, and we should make a reasonable attempt to ensure automated tests will find it and flag it |
| 14:03.57 | *** join/#asterisk-bugs putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:03.57 | *** mode/#asterisk-bugs [+o putnopvut] by ChanServ |
| 14:08.03 | leifmadsen | Corydon76-home: I totally agree |
| 14:08.27 | leifmadsen | I will make notes and such -- unfortunately all I have time for today is to file the issue |
| 14:14.33 | Juggie | Corydon76-home, there are indeed developer versions of mssql. |
| 15:31.36 | *** join/#asterisk-bugs irroot (~irroot@197.108.59.225) |
| 16:00.00 | *** join/#asterisk-bugs serafie (~erin@nat/digium/x-gtwqnfppkwtysoaz) |
| 16:31.14 | Corydon76-home | Juggie: I was thinking along the lines of a cheap version |
| 16:31.26 | Corydon76-home | Maybe even free |
| 17:28.03 | seanbright | sql express is free i think |
| 17:28.17 | seanbright | http://www.microsoft.com/sqlserver/en/us/editions/express.aspx |
| 17:28.34 | *** join/#asterisk-bugs dwayne (~dwayne@c-71-207-214-190.hsd1.al.comcast.net) |
| 17:53.02 | leifmadsen | seanbright: thanks! added as a comment to the open issue |
| 18:44.44 | leifmadsen | pabelanger: +1 on your comment about blindly closing issues from now on if the appropriate information is not provided |
| 18:45.27 | Qwell | -1 from me |
| 18:48.17 | leifmadsen | Qwell: but we're talking about your best friend! |
| 18:48.22 | malcolmd | yeah, i'm a -1 on that also |
| 18:48.54 | leifmadsen | no, it's just for this one reporter, not everyone |
| 18:49.02 | Qwell | I object to the word blindly. |
| 18:49.11 | leifmadsen | he has been providing lack luster issues for years now -- he knows better |
| 18:49.12 | Qwell | for him, I say we just delete his account and ban his entire country. |
| 18:49.17 | serafie | could write a workflow plugin |
| 18:49.29 | leifmadsen | I'm tired of constantly telling him to provide the appropriate debugging information |
| 18:49.58 | Qwell | Can we have a "Close with prejudice"? |
| 18:50.01 | leifmadsen | ASTERISK-18239 is what I speak of |
| 18:50.10 | Qwell | so that if we close it that way, it can't be reopened by the reporter? |
| 18:50.11 | leifmadsen | which I can't even load right now |
| 18:50.42 | leifmadsen | anyways -- can someone look a that backtrace and tell me if it looks ike something in Dial() or if it's because of res_timing_pthread? |
| 18:50.49 | leifmadsen | (or if you can even tell anything from it?) |
| 18:51.45 | serafie | but... he has tried everything in the book! |
| 18:52.24 | leifmadsen | :) |
| 18:52.45 | leifmadsen | omg jira is so slow from here, I'm going to have to stop |
| 18:57.32 | Qwell | umm, when was option a added to Dial()? |
| 18:58.17 | Qwell | no it's not that one |
| 18:58.18 | leifmadsen | Qwell: at least 1.8 |
| 18:58.19 | leifmadsen | <PROTECTED> |
| 18:58.19 | leifmadsen | <PROTECTED> |
| 18:58.26 | Qwell | maybe it is |
| 18:58.33 | Qwell | 227897 mnicholson OPT_CALLER_ANSWER = (1 << 31), |
| 18:58.34 | Qwell | <PROTECTED> |
| 18:58.34 | Qwell | <PROTECTED> |
| 18:58.34 | Qwell | 103249 mvanbaak #define DIAL_STILLGOING (1 << 31) |
| 18:58.38 | Qwell | both are 1 << 31 |
| 18:58.42 | leifmadsen | ouch |
| 18:59.24 | leifmadsen | ya I see that here too |
| 18:59.24 | leifmadsen | <PROTECTED> |
| 18:59.24 | leifmadsen | }; |
| 18:59.24 | leifmadsen | #define DIAL_STILLGOING (1 << 31) |
| 19:00.02 | leifmadsen | so ummmm.... we need to move #define DIAL_STILLGOING to (1 << 40) ? |
| 19:00.44 | Qwell | no, that one is newer and needs to move |
| 19:01.11 | leifmadsen | that's what I'm saying isn't it? |
| 19:01.18 | leifmadsen | or are you saying OPT_CALLER_ANSWER is newer |
| 19:01.19 | Qwell | no :p |
| 19:01.20 | Qwell | yes |
| 19:01.29 | leifmadsen | ok "that one" was ambiguous :) |
| 19:02.12 | Qwell | of course, I don't think this is actually related to his bug |
| 19:02.19 | Qwell | It is curious that he's using option a though |
| 19:44.22 | Qwell | 1111111111111111111111111111111110000000000000000000101000000000 |
| 19:44.32 | Qwell | That is a broken 64-bit flag. |
| 19:48.13 | Qwell | Why the heck would the upper 32 get set? |
| 20:00.02 | *** join/#asterisk-bugs malcolmd_ (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 20:00.03 | *** mode/#asterisk-bugs [+o malcolmd_] by ChanServ |
| 20:40.35 | *** join/#asterisk-bugs tzafrir (~tzafrir@212.179.75.202) |