MySQL Bugs: #44544: Driver crash on access of null values in date fields

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:	None
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

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

SQLSetDefaults("IBB","IBB","","localhost",3306);

// 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

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.

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.

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.

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

Ok, waiting.

OK, use this as testcase (hopefully complete):
http://harryboeck.dyndns.org/verschiedenes/IBB/MySQL-Testcase.zip

Noted.

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.

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!

Thank you for the update.

Works now.

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&)
_cout
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?

Reducing the test case (some moments please)...

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

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.