MySQL Bugs: #9754: Different behaviour with original EXE compared with self-compiled EXE

Bug #9754	Different behaviour with original EXE compared with self-compiled EXE
Submitted:	8 Apr 2005 11:41	Modified:	28 May 2005 16:37
Reporter:	Manuel Matonin	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Server: Compiling	Severity:	S1 (Critical)
Version:	4.1.11	OS:	Windows (WIN XP SP2)
Assigned to:		CPU Architecture:	Any

Description:
The mysqld.nt.exe binary you provide size is 3506176 bytes. Compiling the MySQL 4.1.11 project (Win32 nt) with VC6 SP6 I get 3522560 bytes.

Now comes the mysterious behaviour:
When using my own compiled binary (RELEASE mode) I never manage to save data into LONGTEXT column. While the DEBUG version works fine. After debugging I found out there is something wrong with the function Field_blob::max_data_length(). It just returns 0 in RELEASE mode and this will be the LONGTEXT data length... This is because casting unsigned __int64 into unsigned long.

The question is how the original binary is compiled to avoid such behaviour ?

How to repeat:
CREATE TABLE `test_blob` (
  `_id` int(10) unsigned NOT NULL auto_increment,
  `_guid` varchar(11) default NULL,
  `_blob` longtext,
  PRIMARY KEY  (`_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

INSERT INTO test_blob SET `_blob`="1234";
mysql> SELECT * from test_blob where _id=last_insert_id();
+-----+-------+-------+
| _id | _guid | _blob |
+-----+-------+-------+
|   1 | NULL  |       |
+-----+-------+-------+
1 row in set (0.00 sec)

I downloaded the mysql-4.1.11-win-src.zip and compiled on my working
machine (not the release build machine):

D:\mysql-4.1.11\client_release>dir mysqld-nt.exe
 O volume na unidade D não tem nome.
 O número de série do volume é A842-7885

 Pasta de D:\mysql-4.1.11\client_release

08/04/2005  11:39         3.506.176 mysqld-nt.exe
               1 arquivo(s)      3.506.176 bytes
               0 pasta(s) 13.376.098.304 bytes disponíveis

D:\mysql-4.1.11\client_release>mysqld-nt --standalone --console
050408 11:46:45  InnoDB: Started; log sequence number 0 48370
mysqld-nt: ready for connections.
Version: '4.1.11-nt'  socket: ''  port: 3306  Source distribution

D:\mysql-4.1.11\client_release>mysql -uroot test
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.1.11-nt

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> CREATE TABLE `test_blob` (
    ->   `_id` int(10) unsigned NOT NULL auto_increment,
    ->   `_guid` varchar(11) default NULL,
    ->   `_blob` longtext,
    ->   PRIMARY KEY  (`_id`)
    -> ) ENGINE=MyISAM DEFAULT CHARSET=latin1;
Query OK, 0 rows affected (0.17 sec)

mysql> INSERT INTO test_blob SET `_blob`="1234";
Query OK, 1 row affected (0.03 sec)

mysql> SELECT * from test_blob where _id=last_insert_id();
+-----+-------+-------+
| _id | _guid | _blob |
+-----+-------+-------+
|   1 | NULL  | 1234  |
+-----+-------+-------+
1 row in set (0.00 sec)

mysql>

We use the VC++ 6.0a compiler with SP 5.
However already it was reported a similar issue with VC++ 6.0 Compiler
Japanese version and for the lack of this version we aren't able for to
repeat and analyze the reason of this issue. The most probably reason
is the use of the Optimization: Maximize Speed.
Could you please describe more detailed your compiler and OS environment
for to try to reproduce on my side.

Thanks in advance.

Indeed, the reason for this kind of behaviour was code optimization. After changing project settings and turning off optimization (Disable) the compiled binary worked the same way as the original binary you provide. The only difference was the size in bytes. (now the size is over 4 megabytes)

I compiled the same source on another machine too, it has VC++ 6 SP6 installed, the binary size was 3510272 (NT release with optimization setting 'Maximize Speed'). I experienced the same behaviour: 

c:\mysql\bin>mysql -uroot test
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3 to server version: 4.1.11-nt-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> desc test_blob;
+-------+------------------+------+-----+---------+----------------+
| Field | Type             | Null | Key | Default | Extra          |
+-------+------------------+------+-----+---------+----------------+
| _id   | int(10) unsigned |      | PRI | NULL    | auto_increment |
| _guid | varchar(11)      | YES  |     | NULL    |                |
| _blob | longtext         | YES  |     | NULL    |                |
+-------+------------------+------+-----+---------+----------------+
3 rows in set (0.00 sec)

mysql> INSERT INTO test_blob SET `_blob`="1234";
Query OK, 1 row affected, 1 warning (0.02 sec)

mysql> SELECT * FROM test_blob WHERE `_id`=last_insert_id();
+-----+-------+-------+
| _id | _guid | _blob |
+-----+-------+-------+
|   3 | NULL  |       |
+-----+-------+-------+
1 row in set (0.01 sec)

mysql>

If the original binary is compiled using optimization property 'Maximize Speed' then I don't understand why file sizes are different on different machines and why the original binary works different way regarding inserts into longtext field ?

The problem here that I only stay in the guess, since I can't to reproduce
the issue on my box, so I need your help in to find what is the environment
issue which causes that compiler behavior. If I will able to provoke it then
I will debug the handle of longtext fields.

Thanks in advance

OS: Win XP SP2
COMPILER: VC++ 6.0 Enterprise Edition SP6
COMPILER OPTIMIZATION: Maximize Speed
MYSQL BINARY: mysqld-nt.exe 3522560 bytes

Waht else can I provide to solve this mysterious LONGTEXT field anomaly ?

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

Thank you for submitting this bug. However, we provide official
binaries for the platform in question and hence will not handle
compilation-related bugs for this platform.

To download MySQL binaries for this platform, please go to:
http://dev.mysql.com/downloads/