Bug #44544 Driver crash on access of null values in date fields
Submitted: 29 Apr 2009 14:52 Modified: 24 May 2009 1:03
Reporter: Harry Boeck Email Updates:
Status: Not a Bug Impact on me:
Category:MySQL Server: C API (client library) Severity:S1 (Critical)
Version:6.0.1 OS:Windows
Assigned to: Sveta Smirnova CPU Architecture:Any
Tags: crash, date, null

[29 Apr 2009 14:52] Harry Boeck
On access to a date field with default value null, the driver crashes.
The OS reports an unhandled exception.
The exception mechanism of the gnu compiler does not catch this.

How to repeat:
// This is an excerpt from a demo program for the C++ course at "http://www.ibb.com"...
// Replace the function "SQL" with anything doing a "mysql_query"...


// This is what prepares the bug (an idea, a participant tried out today)...
// He declared a "date" field with default "null" values as the last field...
cout << "create table: " << SQL
    "create table if not exists tab"
    "   `id`    INT             NOT NULL AUTO_INCREMENT PRIMARY KEY,"
    "   `name`  VARCHAR(255)    NOT NULL,"
    "   `date`  DATE            NULL"

cout << "insert into: " << SQL
    "insert into tab values"
    "(NULL , 'Hans', NULL ),"
    "(NULL , 'Wurst', NULL )"

// This is done correctly...
cout << "select some from:\r\n" << SQL
    "select id, name from tab;"

// This is what crashes the demo (trying to display all fields)...
// Commenting this out cirumvents the bug...
cout << "select all from:\r\n" << SQL
    "select * from tab;"

cout << "delete from: " << SQL
    "delete from tab where name in ('Hans','Wurst');"

cout << "drop table: " << SQL
    "drop table tab;"

Suggested fix:
Well - not letting it crash! ;-D
[30 Apr 2009 10:36] Tonci Grgin
Hi Harry and thanks for your report.

You refer to "driver" but do not mention which one nor which version. I presume it's c/C++, right?

You have posted URL but it does not function nor can I find any actual code there.

So, please fill in this bug report properly by adding all necessary info and attaching simple but complete test case so I can check.
[30 Apr 2009 11:10] Harry Boeck
Right: It's the "C-API" in version 6.0.1 (as depicted by "Category") alias "mysqllib.dll".

Well - actually we have tried an old "mysqllib.dll" of version 5.x first, then we updated the dll to version "6.0.1" on both the tutor and the attendee site.
The behavior remained the same.

Since PHP and mysql console both report the content correctly, it's obviously a matter of the C-API database driver.
[30 Apr 2009 12:33] Tonci Grgin
Ok Harry, so it's not connector C++ but some unknown C-API code you've wrote. Without repeatable test case I don't think I can do anything to help.
[30 Apr 2009 14:21] Harry Boeck
Well, I had lessons to give the last houres, sorry...
Actually, it's "mysql_query()" from C-API 6.0.1 what  we use, despite the function call being hidden in an other function.

I'm setting up the files for download at the moment...
[30 Apr 2009 14:30] Tonci Grgin
Ok, waiting.
[30 Apr 2009 14:43] Harry Boeck
OK, use this as testcase (hopefully complete):
[6 May 2009 14:48] Tonci Grgin
[7 May 2009 6:41] Sveta Smirnova
Thank you for the feedback.

I can not open archive:

$unzip MySQL-Testcase
Archive:  MySQL-Testcase.zip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
Archive:  MySQL-Testcase.ZIP
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.

Please correct it.
[8 May 2009 6:01] Harry Boeck
A bit failure on transport? Or an outdated archiver? I have put two additional archive formats in place: "MySQL-Testcase.7z" and "MySQL-Testcase.rar". This should give at least one transmission without failure!
[8 May 2009 6:42] Sveta Smirnova
Thank you for the update.

Works now.
[21 May 2009 9:37] Sveta Smirnova
Thank you for the feedback.

When compiling I get error:

/usr/bin/ld: Undefined symbols:
String::_append(int, int)
operator<<(Cout&, setw)
operator<<(Cout&, char const*)
operator<<(Cout&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
collect2: ld returned 1 exit status

If add #include <iostream>, error is different:

MySQL-Verbindung.cpp: In function 'void anwendung_mit_kapselung(bool)':
MySQL-Verbindung.cpp:226: error: reference to 'cout' is ambiguous

Compiling as `g++ MySQL-Verbindung.cpp -o MySQL-Verbindung `/Users/apple/Applications/mysql-6.0/bin/mysql_config --include --libs` -lc`

What is the correct way to compile test?

Additionally current version is 6.0.10 now. Could you please test in your environment if problem still exists in this version?
[21 May 2009 17:04] Harry Boeck
Reducing the test case (some moments please)...
[23 May 2009 22:49] Harry Boeck
OK, sorry for the delay...

The project consists of two cpp files ("mysql-verbindung.cpp" and "cinout.cpp").
Simply include "cinout.cpp" in "mysql-verbindung.cpp" if you want the project to be compiled by one command line with "mysql-verbindung.cpp" as the only source!

The same matter has been repeatedly verified by a handful of attendees for now - every time, when someone has the idea to include some date fields with null default values at the end of a table. There must be some tutorial in the internet, where this idea descends from.

I'm doing a test with version 6.0.11-alpha now...
[24 May 2009 1:03] Harry Boeck
I have repeated the tests now.

Since the last tests there had been a couple of alterations to the environment on my developer system. That resulted in exception handling now functioning (i'm no expert in gnu compiler command line - sorry).

Thus i spiked the source code with exception catchings now and found the access operation to the "row[<date column index>]" throwing the exception. And there only the copy operation actually doing it.

The documentation text for "MySQL 6.0 Reference Manual :: 20 Connectors and APIs :: 20.10 MySQL C API :: 20.10.1 C API Data Types # MYSQL_ROW" says:

"You cannot treat these as null-terminated strings if field values may contain binary data..."

This would implicate that "You can treat these as null-terminated strings if field values may not contain binary data...", if this text was a complete description.

Obviously it is not. The pointer returned for null values is a null pointer.
Well - not so much exciting, if rethought. Null values obviously should be distinguishable from empty strings. It's not an error, but merely an incomplete description, leading to a false conclusion. Which surely gets resolved by some documentation elsewhere.

Well, for the quality of the API description, i would suggest to include an annotation about null values in the text for the data structure "MYSQL_ROW".

Status: Not a Bug

I've updated the test case to the today's experiments.