Bug #17046 Null pointer access when stored procedure is used
Submitted: 2 Feb 2006 15:24 Modified: 24 Oct 2006 18:00
Reporter: Thomas Krüger Email Updates:
Status: Closed Impact on me:
None 
Category:Connector / NET Severity:S3 (Non-critical)
Version:1.0.7 OS:Windows (Windows XP Prof)
Assigned to: Reggie Burnett CPU Architecture:Any

[2 Feb 2006 15:24] Thomas Krüger 
Description:
When a non-prepared stored procedure is used, the MySqlCommand.Consume() call does not have sqlBuffers assigned; thus they cannot be accessed. 

How to repeat:
Call a stored procedure.

Suggested fix:
Add an additional check to avoid null pointer access during Count.

internal void Consume()
{
	CommandResult result = GetNextResultSet(null);
	while (result != null)
	{
		result.Consume();
		result = GetNextResultSet(null);
	}

	// if we were executing a stored procedure and we are out of sql buffers to execute, 
	// then we need to perform some additional work to get our inout and out parameters
	if (storedProcedure != null && (sqlBuffers == null || sqlBuffers.Count == 0))
		storedProcedure.UpdateParameters(Parameters);
}
[23 Feb 2006 20:18] Reggie Burnett 
Thomas

Can you give me more info?  My test suite calls plenty of stored procedures successfully so a bug report that says calling stored procs don't work is not complete.  Is there anything else you can tell me?
[22 Jun 2006 23:00] Bugs System 
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[26 Jun 2006 12:12] Thomas Krüger 
Program.cs

Attachment: Program.cs (text/plain), 3.15 KiB.
[26 Jun 2006 12:13] Thomas Krüger 
Uploaded Program.cs which shows the effect. Seems, that at least this test is missing in the big test suite!

Thomas
[26 Jun 2006 12:15] Thomas Krüger 
Sorry for the confusion, the stored proc command object must be prepared!
[24 Oct 2006 18:00] Reggie Burnett 
Need more information if we are going to verify this bug.  The test suite for 1.0.7 includes calls to many stored procedures so we know its not just calling an sproc that does it.  We had a problem where stored procedures that generate warnings were causing a problem and that was fixed in 1.0.8.  Please try that version and let us know if you still see the problem.