Bug 4786 - After failed call to SqlConnection.Open (due to invalid password), subsequent invalid password attempts result in wrong exception
Summary: After failed call to SqlConnection.Open (due to invalid password), subsequent...
Status: RESOLVED FIXED
Alias: None
Product: Class Libraries
Classification: Mono
Component: System.Data (show other bugs)
Version: 2.10.x
Hardware: PC Linux
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-04-30 22:17 UTC by Robert Wilkens
Modified: 2012-05-24 16:50 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Robert Wilkens 2012-04-30 22:17:59 UTC
Description of Problem:
I have a function that gets called as a result of clicking a log in button (OnClick Event).  If i put in an invalid password, the first time it gives me an appropriate exception ('invalid login') the second time the error is more indicative of a bug ('reference not set to instance of an object' or similar wording).

Steps to reproduce the problem:
1. Create a screen which prompts for username/password
2. Place a login button on the screen, and set the callback function to create a new sqlconnection(connection_string), then have it call Open() on that connection.
3. Click login more than once with an invalid password.

Here's some sample code for the onclick event:
	protected void LoginClick (object sender, System.EventArgs e)
	{
		SQLConn = "Data Source=robwilkenssql.db.6210828.hostedresource.com;Initial Catalog=robwilkenssql;User ID=" + UserText.Text + ";Password=" + PassText.Text + ";MultipleActiveResultSets=True;";
		MyConnection=null;
        try
        {
                MyConnection = new SqlConnection(SQLConn);
                MyConnection.Open();
				
		MainMenuDlg Menu=new MainMenuDlg();//this only gets created if login succesful due to exceptions being raised on failure...
................. code removed from this point to exception handling

		}

		catch (Exception ex)
        {
			if  (MyConnection!=null){
				MyConnection.Close();
			}
			ShowMessage("Error logging into Database: "+ex.Message);	
        }


Actual Results:
From Open: Exception that says (on 2nd attempt): Object reference not set to an instance of an object

Expected Results:
From Open: Exception that says (on 2nd attempt): login failed for user 'username'

How often does this happen? 
Every time, as long as it's the 2nd attempt (or later).

Additional Information:
Comment 1 Robert Wilkens 2012-05-02 08:42:28 UTC
I have submitted a patch for this via github.  I did not generate unit tests for it, and wasn't honestly sure how to start on that.  It basically was a problem in Mono.Data.Tds.Protocol.TdsConnectionPool (which is called from SqlConnection.Open()) -- There's a condition in there where it would have to 'retry' (which happens on subsequent attempts if there is a dead connection in the pool), and before it went to the retry point it needed to reset 'result=null' which it wasn't doing, because at the top of the retry point the first thing it does is check "while (result == null)" to enter the loop, and the loop was being bypassed because it was never null on retries.  It needs to be null to find a new result which was the point of the retry in the first place.
Comment 2 Robert Wilkens 2012-05-03 15:53:59 UTC
I did generate a unit test for it now, and that is available in the pull request on github.
Comment 3 Miguel de Icaza [MSFT] 2012-05-24 16:50:49 UTC
Thanks for the patch!