MySQL Bugs: #77017: Use of strLen in execute.c & memory leak

Bug #77017	Use of strLen in execute.c & memory leak
Submitted:	12 May 2015 13:48	Modified:	16 Aug 2015 4:52
Reporter:	andrew turnbull	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	Connector / ODBC	Severity:	S5 (Performance)
Version:	5.3.4	OS:	Windows
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
While stepping though my and your code in Windbg I noticed that you call strLen as below in doQuery

if (query_length == 0)
   56     {
   57       query_length= strlen(query);
   58     }

This seems to take a long time and as far as I can see always returns zero. I suspect that query may not be null terminated. I am not sure of the impact of this in the calling code. I am attempting to trace a memory leak to appears to occur with large statements.

How to repeat:
Step through do_query in execute.c

Hello Andrew Turnbull,

Thank you for the bug report.
The query might be not null-terminated, then the query_length parameter must contain the length for the query string otherwise it is considered as null-terminated and strlen() is used to determine the length. if strlen(query) returns zero it means that query_length is misleading and initially the length comes from the user code. if the user code knows about wrong null termination that might take place it must provide the query length.

Thanks,
Chiranjeevi.

Sorry but this makes no sense to me. I am using Microsoft ADODB and Visual Basic. I simply pass a normal BSTR to connection.execute. As far as I know I have no mechanism to pass the query length.

In addition I have almost confirmed 100% that there is a leak with large statements containing multiple queries in the ADODB/MyOdbc stack somewhere. I did this by adding an externally settable flag (IE I can change it while my application is running) that instructs it to either call connection.execute or skip that step. Like this:

If dontExecuteStatus Then

Else

connection.Execute (Mid$(executeString, 1, lenExecuteString) & ";")

End If

When it execute the statement private bytes climbs about 1 meg per 12 hours. When it does not execute the statement private bytes is almost entirely flat. Unfortunately I cannot paste the graphs showing this into this submission.

My initial suspicion was that since your code does not seem to be able to determine the query length at that point it may leave some kind of buffer of that length allocated.

Hello Andrew Turnbull,

Thank you for your feedback.
I could not repeat the issue using on Microsoft ADODB and Visual Basic,   MySQL Connector / ODBC 5.3.4. Could you please provide complete repeatable test case to confirm this issue at our end?

Thanks,
Chiranjeevi.

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".

What do you need me to do? Make you some code? This was easy to reproduce but I can do that if that is what you want?

Are you saying that you do not see strLen returning 0?

Yes Andrew, could you please provide us complete reproducible test case to confirm this issue at our end?

Hi Andrew,

I have tried your test project and set break-points to check what values query_length will take before and after measuring the query length with strlen() function. The values for query and query_length were assigned as expected.

Please check the screenshot (screenshot_debug_vb.png)

Screenshot from Visual Studio debugging session

Attachment: screenshot_debug_vb.png (image/png, text), 182.64 KiB.

Andrew,

The reason why your debugger was still displaying the zero length for query_length could be the mismatch between the source, the DLL (myodbc5w.dll) and/or the symbol file (myodbc5w.pdb).

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".