MySQL Bugs: #68771: Crash Doing ADO RecordSet.Move

Bug #68771	Crash Doing ADO RecordSet.Move
Submitted:	26 Mar 2013 2:58	Modified:	1 Jul 2013 6:52
Reporter:	Angela Lamb	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Connector / ODBC	Severity:	S2 (Serious)
Version:	5.2.4	OS:	Windows (XP SP3)
Assigned to:	Bogdan Degtyariov	CPU Architecture:	Any

Description:
I am using Connector/ODBC with classic ASP. I use ADO to access the MySQL database. This works fine until I use RecordSet.Move with a higher value of NumRecords. Values of 50 & 100 work fine and give the expected result, but a value of 150 causes a crash in MyOdbc5w.

I used DebugDiag 1.2 to catch the exception in the IIS worker process:

myodbc5w!SQLForeignKeysW+144e2 called from
ntdll!RtlFreeHeap+647 called from
odbc32!SQLExtendedFetch+c7 called from
msdasql!CFetchRowsExtFetch::FetchRows+451 called from
msdasql!CRowset::FetchRows+2d called from   
msdasql!CImpIRowsetScroll::GetNextRows+3b5 called from    
msadrh15!CRowsetHelper::GetNextRows+63 called from    
msado15!CRecordset::GetNextRecords+d5 called from   
msado15!CRecordset::MoveRelative+203 called from   
msado15!CRecordset::Move+16e ...

I'll attach the dump file generated and the DebugDiag analysis.

Connector/ODBC 5.2.4 GA
MySQL 5.6.10 GA
MDAC 2.8

How to repeat:
Don't currently have a simple test case: the SQL depends on my DB structure. I can try to create one if reqd.

DebugDiag Dump Analysis

Attachment: CrashHang_Report__Date_03_26_2013__Time_02_19_22AM__125.mht (message/rfc822, text), 80.82 KiB.

Hi Angela,

thank you for the detailed report.
I see that the crash occurs in SQLForeignKeysW function. Unfortunately, calculating the offset (0x144E2) inside the code is a tricky task because the binary library (myodbc5w.dll) is speed-optimized and the machine instructions are executed in a different order than in the source code.

I compiled a debug version of myodbc5w.dll file with all debug symbols and line numbers to make things easier. When the crash occurs next time the dump report should have the source line number showing where exactly things went wrong.

Please do the following steps:

1. Stop IIS because it holds lock on myodbc5w.dll
2. Rename myodbc5w.dll into myodbc5w.dll.bak. The file is usually located in:
   C:\Program Files\MySQL\Connector ODBC 5.2\Unicode
3. Download and unpack the contents of zip archive (myodbc5w-r1135.zip)
   into the directory where you had myodbc5w.dll.
   The archive contains the debug version of myodbc5w.dll and the symbols
   database (myodbc5w.pdb)
4. Start IIS
5. Try to reproduce the crash
6. Send me another crash report for analysis.

Thanks.

I have reproduced the problem with the diagnostics that you sent.

The stack trace now looks like this:

myodbc5w!sql_get_data+661
myodbc5w!fill_fetch_buffers+1f7 called from
myodbc5w!my_SQLExtendedFetch+70f called from
myodbc5w!SQLExtendedFetch+4e called from
odbc32!SQLExtendedFetch+c7 called from
msdasql!CFetchRowsExtFetch::FetchRows+451 called from
msdasql!CRowset::FetchRows+2d called from
msdasql!CImpIRowsetScroll::GetNextRows+3b5 called from
msadrh15!CRowsetHelper::GetNextRows+63 called from
msado15!CRecordset::GetNextRecords+d5 called from
msado15!CRecordset::MoveRelative+203 called from
msado15!CRecordset::Move+16e ...

The above is edited, I'll attach the new DebugDiag analysis with the full info.

Crash ananysis with supplied diagnostics.

Attachment: CrashHang_Report__Date_03_28_2013__Time_06_41_00PM__250.mht (message/rfc822, text), 81.96 KiB.

Angela,

Thank you for sending the new crash report.
I see the crash is happening in the following lines (results.c: 415-416):

 *((SQLINTEGER *)rgbValue)= (SQLINTEGER) get_int64(stmt,
                                    column_number, value, length);

There is only one possibility for a crash to occur, when rgbValue is an invalid pointer that goes out of bounds of the allocated buffer. It cannot be NULL because the NULL condition was checked in the code before.

This can happen when the application miscalculated the row array size. Since the row array is allocated by ADO I hardly believe it could make such a mistake. Therefore, we need to try other means.

I made a test VB script, which creates a table and inserts 200 records in there.
Then it selects the rows and moves the pointer to the number 150 using Recordset.Move method.

Can you modify the script to make it crash?
Thanks.

VB test case

Attachment: 68771.vbs (application/octet-stream, text), 4.15 KiB.

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

Please note that this bug report is waiting on your reply. It will be automatically closed if you do not provide us any feedback.

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

No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you.

Verifying this bug still exists. When using connector/ODBC under classic asp and then doing a .move on an open recordset, a serious IIS crash occurs.

Through process of elimination, I was able to narrow the specific row count problem down to 114. That is, the problem occurs ONLY when moving to a record higher than 113 (rs.move 114 causes an error while lower values function perfectly). This error may be reproduced time and again.

Looping through the recordset using movenext 114 times is an acceptable workaround...but this bug definitely still exists.

IIS 8.5
ODBC Driver Version - ODBC 5.03.04.00 (6/19/2014 release date)