MySQL Bugs: #17508: Update query causes Access Violation during parameter binding

Bug #17508	Update query causes Access Violation during parameter binding
Submitted:	17 Feb 2006 8:20	Modified:	30 Jun 2007 14:51
Reporter:	David Stevenson	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	Connector / ODBC	Severity:	S2 (Serious)
Version:	3.51.12	OS:	Windows (Windows XP w/SP2)
Assigned to:		CPU Architecture:	Any

Description:
I have recently discovered a problem saving a Microsoft Project 2003 File using the SQL ODBC connector 3.51.12 (stable general release on your downloads page) and MYSQL version 5.0.18-nt-log.  I've set up the empty MSProject schema in MYSQL in advance, so only a few tables need to be updated or appended to when I save a new project (getting around the incompatible datatypes problem).  One of the queries causes an Access Violation (AV!).  I've attached WINDBG to watch the failure, as well as compiled the ODBC connector using VS2003 with debug options enabled.  This allowed me to see a complete stack trace, and connect it to the source where the problem is.  It turns out that REALLOC is failing in some way (the heap might be corrupt?) and because we're in debug mode, the heap consistency check fails before or after it.  This happens during parameter binding of my update query, when the query is supposed to be escaped (all details listed below).  The data to be updated isn't larger than LONGBLOB's maximum size, so this update shouldn't be failing.  Thanks!

-David Stevenson
stevend@umail.ucsb.edu

--- The offending query is ---
"update MSP_PROJECTS set RESERVED_BINARY_DATA = ? where PROJ_ID = 1"
The table MSP_PROJECTS column RESERVED_BINARY_DATA is of type LONGBLOB

--- WinDBG fails with the following information ---
HEAP[WINPROJ.EXE]: Invalid Address specified to RtlValidateHeap( 04460000, 05FEC1F8 )
(c70.ce4): Break instruction exception - code 80000003 (first chance)

And it appears that the problem is occuring during parameter binding, as you can see from the stack below:
Stack Trace
-----------------------
ChildEBP RetAddr  
0011deec 7c96c943 ntdll!DbgBreakPoint
0011def4 7c96cd80 ntdll!RtlpBreakPointHeap+0x28
0011df08 7c960af8 ntdll!RtlpValidateHeapEntry+0x113
0011df6c 7c85e7af ntdll!RtlValidateHeap+0xe0
0011df80 05cc7c74 kernel32!HeapValidate+0x14
0011df98 05cc6b24 myodbc3!_CrtIsValidHeapPointer+0xa4 [f:\vs70builds\3077\vc\crtbld\crt\src\dbgheap.c @ 1807]
0011dfb8 05cc68df myodbc3!realloc_help+0x204 [f:\vs70builds\3077\vc\crtbld\crt\src\dbgheap.c @ 663]
0011e000 05cc6877 myodbc3!_realloc_dbg+0x4f [f:\vs70builds\3077\vc\crtbld\crt\src\dbgheap.c @ 883]
0011e020 05ca50b1 myodbc3!realloc+0x17 [f:\vs70builds\3077\vc\crtbld\crt\src\dbgheap.c @ 824]
0011e03c 05c8c186 myodbc3!my_realloc+0x31
0011e05c 05c8ce86 myodbc3!extend_buffer+0x66 [c:\mysql-connector-odbc-3.51.12-win-src\myodbc3\execute.c @ 227]
0011e070 05ca0281 myodbc3!extend_escape_buffer+0x16 [c:\mysql-connector-odbc-3.51.12-win-src\myodbc3\execute.c @ 261]
0011e090 05c8ca84 myodbc3!mysql_odbc_escape_string+0x61
0011e16c 05c8c34b myodbc3!insert_param+0x5c4 [c:\mysql-connector-odbc-3.51.12-win-src\myodbc3\execute.c @ 522]
0011e19c 05c8d21a myodbc3!insert_params+0x13b [c:\mysql-connector-odbc-3.51.12-win-src\myodbc3\execute.c @ 314]
0011e1d8 05c8cffc myodbc3!my_SQLExecute+0x20a [c:\mysql-connector-odbc-3.51.12-win-src\myodbc3\execute.c @ 710]
0011e1e4 74345079 myodbc3!SQLExecute+0xc [c:\mysql-connector-odbc-3.51.12-win-src\myodbc3\execute.c @ 631]
0011e200 2d8a205a odbc32!SQLExecute+0xd3
WARNING: Stack unwind information not available. Following frames may be wrong.
0011ec68 2d8ab8bc pj11od11!ODBC_GetPoolCache+0x1035
0011eca4 2d8a5780 pj11od11!ODBC_GetCntrID+0x6f94

When we examine the frame for insert_param(...), the values of the varaible param are as follows:
   +0x000 SqlType          : -4
   +0x002 CType            : -2
   +0x004 buffer           : 0x05b80020  ""
   +0x008 pos_in_query     : 0x05f20070  "? where PROJ_ID = 1"
   +0x00c value            : (null) 
   +0x010 ValueMax         : 925772
   +0x014 actual_len       : 0x0011ec48  -> 925772
   +0x018 value_length     : 0
   +0x01c alloced          : 0
   +0x020 used             : 1
   +0x024 real_param_done  : 1

How to repeat:
Difficult to repeat, I'm working on trying to figure out what exact sequence of queries causes the AV.  I'm hoping to post instructions for using Microsoft Project 2003 generate a simple file that will cause the problem, but all the simple projects (with very few tasks) I've made so far have been working for both saving and loading!

Suggested fix:
Check the memory allocation scheme for expanding really large escaped parameters during the binding phase.

Hi!

I was unable to reproduce this bug.  Can you please send me your queries and create table statements (and possibly even a project file) so that we can track this bug down ?

Thanks!

Alright!   I have found a dataset that will crash the ODBC connector.  Attached is a database schema:  schema_msproject.  

Run this schema using 'source' in MYSQL command client.  It will create a database: 'proj1'.  

Open Microsoft Project 2003 (with most recent service pack), and open the file Shelby...75.mpp. 

Click save as... and select ODBC.  Save it using the MYSQL ODBC Driver to the database proj1.

IT WILL CRASH.

Then... reimport the schema.

Open "Shelby ...60.mpp" and save it to the same database. 

IT WILL NOT CRASH.

the only difference between the two is that the last 15 tasks have been deleted.  Does it have to be the last 15 tasks?  NO!  We've tried lots of combinations of deleting tasks, and they all seem fail with between 60 and 75 tasks.

The MYSQL schema that sets up an MSProject database with the right tables.

Attachment: schema_msproject (text/plain), 34.23 KiB.

A sample MSProject 2003 file with 60 tasks

Attachment: Shelby Development-60.zip (application/x-zip-compressed, text), 100.99 KiB.

A sample MSProject 2003 file with 75 tasks.

Attachment: Shelby Development-75.zip (application/x-zip-compressed, text), 167.39 KiB.

Hi David. Thanks for your problem report and sorry for the delay. 
I don't have MS Projects so I have to ask you to provide small standalone test case in VS2003 showing this problem.

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

I have the problem and I want to use MySQL ODBC to save/load data to/from MS-Project.
I use Connector 3.51 and MySQL 4.1.10a-nt.
I tried a big MPP file containing above 1000 activities and after saving around 500 rows of tasks error entitled:
"[MySQL][ODBC 3.51 Driver][mysqld-4.1.10a-nt] mysql server has gone away" happen and remaining data left away!!!!
what is the solution!!!
New connector or New MySQL or NONE!

By the way!!!
I checked back the data inserted in MySQL and I found that all tasks have been inserted into table! but during saving to ODBC the error which I said still occurred!
I don't know whether this error makes further ploblem in data or not!
I check a 2140 task project in MSP and all tasks got in the table.
I have made some changes to the "schema_msproject.txt" file:
here is the change (is it OK or not):

find: "ENGINE=InnoDB DEFAULT CHARSET=latin1;"
replace with: "TYPE=MyISAM;"

Help me if "[MySQL][ODBC 3.51 Driver][mysqld-4.1.10a-nt] mysql server has gone away" error does something to my data or not.

Thanks Further

Hi, AFAIS
> find: "ENGINE=InnoDB DEFAULT CHARSET=latin1;"
> replace with: "TYPE=MyISAM;"

MS Project is trying to save data to InnoDB table while, possibly, you have InnoDB dissabled in your my.ini file. You should search for and modify respective settings to make your *environment* work.

> Help me if "[MySQL][ODBC 3.51 Driver][mysqld-4.1.10a-nt] mysql server has gone
away" error does something to my data or not.

Check general query log from server to see what was sent to MySQL server.

MSP fills the tables in MyISAM type, but two table left empty after the error which I explain above occures, these two are:

msp_conversions
msp_string_types

does anybody knows the problem? how can I be sure that all data are saved by MySQL ODBC from MSproject?

Running MS Projects 2002 Professional via ODBC 3.51.12.  Tried latest version 3.51.16 (loads properly). Open MS Project crashes.  Database version: 5.0.16nt.

Client application: Microsoft AccessXP with latest service pack.  Access connection is fine.  Can load/update fine.  The problem is trying to load larger MS project files via odbc.  The problem is similar to the previous posts. Tables were InnoDB.  Converted them to MyISAM. Problem still persists.  Tried loading larger proect files into MS AccessXP via ODBC.  Works fine.

Please help.  The problem seems to be with the ODBC connection as the MSAccess update is very quick with MS Projects.

Hardware: HP Compaq NC8000 
Operating System: Windows 2000 Professional

Tried this on:
Hardware: Intel 945GP 
Operating System: Windows XP Professional

Problem persists.

Hi all. As I said I don't have MS projects nor do I know much about it so we'll have to take a longer way around...

Please attach:
 - General query log from MySQL server from the moment you start import till the moment error occurs (and more if insert / load continues)
 - my_sql_sqrevr.err file from MySQL servers data directory
 - ODBC trace from driver manager
 - SHOW CREATE TABLE for table that fails
 - my.ini / cnf file from MySQL server

I am willing to give this one more try.

Resolved error loading file.  Switched on the error log and founf the (Got a packet bigger than 'max_allowed_packet' bytes)

SET GLOBAL max_allowed_packet=10000000;

This resovled the error.  Thanks for the pointers.  Will try larger project files.  

Is there a setting  that must be made on the client side?

thank you for the prompt feedback.

I loaded an MS Project file containing 10,000 activities and it went fine.  I had to increase the max_packet_allowed to 32,000,000.

Although a 10,0000 activity schedule is unrealistic.  Its a good test of the MySQL server.  

Thanks again for the good work.

Vishnu, it is hard to tell what happens in all of the clients accessing MySQL server, as you can tell first-hand, so we need to get as much info as possible.

In any case, I am glad the problem is solved.