MySQL Bugs: #89192: SQLExecute crash the process memory access violation

Bug #89192	SQLExecute crash the process memory access violation
Submitted:	11 Jan 2018 15:44	Modified:	15 Jan 2018 18:49
Reporter:	BaiYang Bai	Email Updates:
Status:	Unsupported	Impact on me:	None
Category:	Connector / ODBC	Severity:	S2 (Serious)
Version:	5.3.9	OS:	Windows (Win7 32bit)
Assigned to:		CPU Architecture:	Any

Description:
SQLExecute crash the app with a statement compiled by SQLPrepare successfully (SQLPrepare return 0).

How to repeat:
SQLPrepare a wrong SQL statement, for example: "SELECT id, nType, () AS filter, ..." and SQLExecute it, the current process crashed. 

Suggested fix:
The behavior is OK when we downgrade to the 5.2.7 odbc driver, 5.2.7 won't break the process and return an appropriate error message: "[MySQL][ODBC 5.2(w) Driver][mysqld-5.0.37]sphinxql: syntax error, unexpected ')' near ') AS filter..." 

Yes, we are connect to the sphinx server, not mysql. But I think it still a bug to crash the whole process.

Here are some info belong to the crash (may be not so useful):
[2018-01-11 21:37:05.487335 UTC+0800][Fatal]   (util.errhnd) unrecoverable underlaying error ocurred: The thread tried to read from or write to a virtual address for which it does not have the appropriate access {r(0)/w(1); acc. addr} (exp. number: 0xC0000005).
  pid            = 17132
  tid            = 17084
  exp. code addr = 0x5069BFAB
  parameters     = 0x0; 0x6952
[2018-01-11 21:37:05.733349 UTC+0800][Fatal]   (util.errhnd) call stack backtrace
  5069BFAB (myodbc5w): (filename not available): SQLGetCursorNameW
  50684B49 (myodbc5w): (filename not available): SQLGetCursorNameW
  50684930 (myodbc5w): (filename not available): SQLGetCursorNameW
  50683DCF (myodbc5w): (filename not available): SQLGetCursorNameW
  64DA9716 (ODBC32): (filename not available): SQLDriverConnect
  64DA95A7 (ODBC32): (filename not available): SQLDriverConnect
  0066A365 (myapp): (filename not available): (function-name not available)
  0066C4DC (myapp): (filename not available): (function-name not available)
  778D5642 (ntdll): (filename not available): alldiv
  752E0EF0 (KERNELBASE): (filename not available): ReleaseSemaphore
  7789E394 (ntdll): (filename not available): RtlInitUnicodeString
  7789E394 (ntdll): (filename not available): RtlInitUnicodeString
  7789E0E2 (ntdll): (filename not available): RtlAllocateHeap
  752E14DE (KERNELBASE): (filename not available): WaitForSingleObjectEx
  66D94D83 (MSVCR80): (filename not available): malloc
  66D94D83 (MSVCR80): (filename not available): malloc
  66DC0E30 (MSVCR80): (filename not available): operator new
@ tid = 17084

Thank you for the bug report. We only process bugs run against MySQL binaries, so if you are able to test against a MySQL server and provide a repeatable test code attach it here for our test.

Yeah, I know. But I think if a program can be crashed (SEGFAULT) by just send some bytes to it through network, then it definitely contains some flaws (No matter who sent bytes to it).

You can return an error if you don't support that, but you can't just trigger a SETFUALT, right?