| Bug #41942 | myODBC ENTER SQLDescribeCol / faulting module myodbc5.dll, version 5.1.5.0 | ||
|---|---|---|---|
| Submitted: | 8 Jan 2009 3:42 | Modified: | 5 Feb 2009 13:54 |
| Reporter: | Thaddee bechtold | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | Connector / ODBC | Severity: | S3 (Non-critical) |
| Version: | 5.1.5 | OS: | Windows (XP SP3) |
| Assigned to: | Jess Balint | CPU Architecture: | Any |
| Tags: | crash, MyODBC, SQLDescribeCol | ||
[8 Jan 2009 3:42]
Thaddee bechtold
[8 Jan 2009 4:31]
Jess Balint
Thaddee, Thanks for your bug report. Can you include the full ODBC trace log and the schema of the table you are querying?
[8 Jan 2009 5:04]
Thaddee bechtold
SQL log file
Attachment: SQL.LOG (application/octet-stream, text), 34.74 KiB.
[8 Jan 2009 5:04]
Thaddee bechtold
Schema of the Database
Attachment: schema.txt (text/plain), 1.18 KiB.
[12 Jan 2009 15:01]
Tonci Grgin
Thaddee, I do not see a failure in trace file. As it appears to me, anything could have happened. Can you attach simple and self-contained test case demonstrating this error every time it's run?
[12 Jan 2009 19:53]
Thaddee bechtold
Hi, For me the failure is that we enter SQLDescribeCol but we never come out any more (see SQL.LOG trace). In place of comming back we see the message faulting module myodbc5.dll, version 5.1.5.0, fault address 0x00015a44. Maybe something todo with the fact that one argument of SQLDescribeCol is NULL ? UCHAR * 0x00000000 I will try to build a simple C++ project that demonstrate the error.
[12 Jan 2009 21:45]
Tonci Grgin
Thaddee, I agree with your analysis. Probably non-terminated result buffer caused the crash... Waiting for test case.
[13 Jan 2009 2:45]
Jess Balint
Unfortunately this alone is not the issue. The driver checks for this and won't attempt to write into a NULL pointer. I double checked with odbcte32.
[13 Jan 2009 15:36]
Vasco Veloso
I can also reproduce this problem with 5.1.5 and AFAIK it seems to be related to the cursor library.
The problem does not occur with connector version 3.51.
Test case:
int main(int argc, char* argv[])
{
int rc;
HENV henv = NULL;
HDBC hdbc = NULL;
HSTMT hstmt = NULL;
#define CONN_STR_MAXSIZE 400
#define LOC_BUFF_LEN 256
UCHAR szDSNBuffer[CONN_STR_MAXSIZE] = { 0 };
UCHAR szCatalog[LOC_BUFF_LEN] = { 0 };
UCHAR szOwner[LOC_BUFF_LEN] = { 0 };
UCHAR szTable[LOC_BUFF_LEN] = { 0 };
UCHAR szTabType[LOC_BUFF_LEN] = { 0 };
UDWORD cRow = 0;
UWORD RowStatus = 0;
rc = SQLAllocHandle(SQL_HANDLE_ENV, NULL, &henv);
rc = SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER) SQL_OV_ODBC3, 0);
rc = SQLAllocHandle(SQL_HANDLE_DBC, henv, &hdbc);
rc = SQLSetConnectAttr(hdbc, SQL_ATTR_ODBC_CURSORS, (SQLPOINTER) 1, 0);
rc = SQLDriverConnect(hdbc, GetDesktopWindow(), (UCHAR*)szDSNString, SQL_NTS,
szDSNBuffer, CONN_STR_MAXSIZE, NULL, SQL_DRIVER_COMPLETE_REQUIRED);
if (SQL_SUCCESS == rc)
{
rc = SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt);
rc = SQLTables(hstmt, NULL, 0, NULL, 0, NULL, 0, (UCHAR*)"'TABLE'", SQL_NTS);
rc = SQLBindCol(hstmt, 1, SQL_C_TCHAR, szCatalog, LOC_BUFF_LEN, NULL);
rc = SQLBindCol(hstmt, 2, SQL_C_TCHAR, szOwner, LOC_BUFF_LEN, NULL);
rc = SQLBindCol(hstmt, 3, SQL_C_TCHAR, szTable, LOC_BUFF_LEN, NULL);
rc = SQLBindCol(hstmt, 4, SQL_C_TCHAR, szTabType, LOC_BUFF_LEN, NULL);
rc = SQLExtendedFetch(hstmt,SQL_FETCH_NEXT,0, &cRow, &RowStatus);
SQLFreeHandle(SQL_HANDLE_STMT, hstmt);
}
SQLFreeHandle(SQL_HANDLE_DBC, hdbc);
SQLFreeHandle(SQL_HANDLE_ENV, henv);
return 0;
}
This will crash on SQLExtendedFetch.
The last ODBC log line is:
mysqltst 13b4-1690 ENTER SQLDescribeCol
HSTMT 008F4310
UWORD 4
UCHAR * 0x00000000
SWORD 66
SWORD * 0x00000000
SWORD * 0x008FC460
SQLULEN * 0x008FC3B4
SWORD * 0x008FC3B2
SWORD * 0x00000000
If I remove the SQLSetConnectAttr line regarding SQL_ATTR_ODBC_CURSORS, it does not crash and data is fetched for the first table.
With my schema, when it works, 5.1.5 does not return a catalog name, but 3.51 does return a catalog name identical to the database name. Maybe this is a hint?...
[13 Jan 2009 16:03]
Vasco Veloso
This problem is also present in version 5.1.4, since that's where I first stumbled in it. I believe that 5.1.3 also suffers from the same problem.
[13 Jan 2009 16:06]
Vasco Veloso
My ODBC log file.
Attachment: SQL - mysqltest.LOG (, text), 9.41 KiB.
[15 Jan 2009 5:31]
Thaddee bechtold
Hi,
Now I have prepared a demo that show the issue.
Here is the center part of this test application:
void CtestmysqlDlg::OnBnClickedOk()
{
CDatabase oBase ;
Ct_usage oRecordCcc(&oBase) ;
if (oBase.Open ("CCC"))
{
if ( oRecordCcc.Open ())
{
MessageBox ("OK!");
oRecordCcc.Close ();
}
oBase.Close ();
}
}
When the application call oRecordCcc.Open () then it crash and it did not display the message box with OK.
I will prepare a ZIP with all the project files and also the EXE.
[15 Jan 2009 5:35]
Thaddee bechtold
Here the Microsoft Visual Studio 2005 project
Attachment: testmysql.zip (application/x-zip-compressed, text), 59.75 KiB.
[15 Jan 2009 5:39]
Thaddee bechtold
Hi, The previous application suppose that you have created an ODBC System DSN of name "CCC". To make it run on a Windows computer you need to have installed the Microsoft Visual C++ 2005 Redistributable package: http://www.microsoft.com/downloads/details.aspx?FamilyId=32BC1BEE-A3F9-4C13-9C99-220B62A19...
[21 Jan 2009 3:24]
Thaddee bechtold
Hi, I tried to change some options of the ODBC drivers (enable dynamic cursor, disable drivers provided cursor, ...). At the end I switch on arround 12 options flags But it still always crash. Regards, Thaddee
[30 Jan 2009 17:47]
Jess Balint
Verified against 5.1.5. Fix was pushed into rev 800. Adding test. Will be released in 5.1.6. Fix can be found in snapshot builds at: http://downloads.mysql.com/snapshots.php
[31 Jan 2009 4:50]
Thaddee bechtold
Hi, I have launched my test program with this version: mysql-connector-odbc-noinstall-5.1.6r823_20090115_2050-win32.zip It does not crash any more. I will now test my full application. Then I will wait the release of 5.1.6 to put in production. Thank you, Thaddee
[2 Feb 2009 12:59]
Tony Bedford
An entry was added to the 5.1.6 changelog: Connector/ODBC crashed on accessing CRecordSet.
[3 Feb 2009 17:50]
Jess Balint
changelog entry should be more like: Calling SQLDescribeCol() with a NULL buffer and non-zero buffer length causes a crash.
[5 Feb 2009 13:54]
Tony Bedford
Changelog updated accordingly. Thank you!
[27 Feb 2009 21:17]
Jess Balint
Bug#42335 marked as a duplicate of this
[14 Sep 2009 6:23]
Tonci Grgin
Bug#47071 was marked as duplicate of this report.
