MySQL Bugs: #27383: Crash in test "mysql_client

Bug #27383	Crash in test "mysql_client_test"
Submitted:	22 Mar 2007 20:28	Modified:	26 Jun 2007 18:50
Reporter:	Joerg Bruehe	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Tests	Severity:	S3 (Non-critical)
Version:	4.1 + 5.0	OS:	Other (Various, including Linux, HP-UX and Solaris)
Assigned to:	Georgi Kodinov	CPU Architecture:	Any

Description:
This report is from the 5.0.38 release build,
but the effect is much older.

Symptom:
=====
mysql_client_test              [ fail ]

Errors are (from /PATH/mysqltest-time) :
mysqltest: At line NNN: command "$MYSQL_CLIENT_TEST --getopt-ll-test=25600M >> $MYSQLTEST_VARDIR/log/mysql_client_test.log 2>&1" failed
(the last lines may be the most important ones)
Result from queries before failure can be found in r/mysql_client_test.log
=====

It is not limited to a specific CPU or compiler.

How to repeat:
Occurred when running the test suite.

It looks like I am experiencing the same problem. As looking through the bug database, it looks like following reports can be about the same problem:
#27383, #23929, #19829.

My system is Fedora Core 6 as installed from CDs or with updates up to 4th Apr.
(gcc 4.1.1, glibc 2.5, kernel 2.6.20, see in attached files).

MySQL is 5.0.38 enterprise (commercial) and for build using .src.rpm for rhel4.

During the build the regression tests fail on mysql_client_test with:

mysql_client_test              [ fail ]

Errors are (from /usr/src/redhat/BUILD/mysqlcom-5.0.38/mysql-test/var/log/mysqltest-time) :
sh: line 1:  1716 Aborted                 /usr/src/redhat/BUILD/mysqlcom-5.0.38/tests/mysql_client_test --no-defaults --testcase --user=root --port=9306 --socket=/usr/src/redhat/BUILD/mysqlcom-5.0.38/mysql-test/var/tmp/master.sock --vardir=/usr/src/redhat/BUILD/mysqlcom-5.0.38/mysql-test/var --getopt-ll-test=25600M >>/usr/src/redhat/BUILD/mysqlcom-5.0.38/mysql-test/var/log/mysql_client_test.log 2>&1
mysqltest: At line 12: command "$MYSQL_CLIENT_TEST --getopt-ll-test=25600M >> $MYSQLTEST_VARDIR/log/mysql_client_test.log 2>&1" failed
(the last lines may be the most important ones)
Result from queries before failure can be found in r/mysql_client_test.log

Aborting: mysql_client_test failed in default mode. To continue, re-run with '--force'.
Stopping All Servers
Shutting-down Instance Manager

Content of r/mysql_client_test.log is:

exec of '/usr/src/redhat/BUILD/mysqlcom-5.0.38/tests/mysql_client_test --no-defa
ults --testcase --user=root --port=9306 --socket=/usr/src/redhat/BUILD/mysqlcom-
5.0.38/mysql-test/var/tmp/master.sock --vardir=/usr/src/redhat/BUILD/mysqlcom-5.
0.38/mysql-test/var --getopt-ll-test=25600M >> /usr/src/redhat/BUILD/mysqlcom-5.
0.38/mysql-test/var/log/mysql_client_test.log 2>&1 failed, error: 34304, status:
 134, errno: 0

I do not really know how important this bug is, but I think it is not really good if regression tests are crashing.

The content of var/log/mysql_client_test.log will be attached in files.

I am quite new in MySQL, what else can I supply to get this problem sorted?

var/log/mysql_client_test.log output for the crash

Attachment: mysql_client_test.log (text/x-log), 12.32 KiB.

list of installed packages and their versions Fedora Core 6 with updates

Attachment: installedpkgs.txt (text/plain), 23.32 KiB.

Vladimir, the files you have submitted will be fine. Thanks!

Duplicate of Bug#20803.

Sorry, this is no duplicate of bug#20803 -
that bug is specific to ICC,
while we have the symptom also in the "debug" builds on Solaris Sparc 64bit
where we use the Sun Studio compiler (5.1.19-beta build).
Note that the original report includes HP-UX/HP-PA and Linux/x86 (gcc).

Either different compilers cause similar failures, or we have a problem in our code in addition to the ICC one, both showing similar symptoms.

I have just observed the same failure in the following environment:

MySQL 4.1.22
Solaris 10 x86 (64bit)
SunStudio 11 compilers

Please open the mysql_client_test.log file and check where the crash occurs. mysql_client_test is quite a big program with several test cases.

The output of make test-force

Attachment: testout (application/octet-stream, text), 23.43 KiB.

No file called mysql_client_test.log was created. However the output of
make test-force did include what appears to be a line number in
mysql_client_test.c. I have uploaded this output.

The file also some information from other failed tests.

I have tried to reproduce the failure using the original set of files (binaries and source) that caused the failure on the very same build box that had the failure. I've run the testsuite 10 times in a row with no success.
Feel free to reopen the bug (or better make a new one) if there's a good way to reproduce the problem.

I just had it in the build of 4.1.23,
but only once:
Solaris 10, x86_64, "classic" configuration, "normal" test:

mysql_client_test              [ fail ]

Errors are (from /PATH/mysqltest-time) :
Abort - core dumped
mysqltest: At line 12: command "$MYSQL_CLIENT_TEST --getopt-ll-test=25600M >> $MYSQLTEST_VARDIR/log/mysql_client_test.log
2>&1" failed

It passed in the "PS" test of the same binary, it passed in all other configurations on that platform, it passed on all other platforms -
so the chances for reproduction are low.

I have tried to reproduce the failure using the original set of files (binaries and
source) that caused the failure on the very same build box that had the failure. I've run
the testsuite 5 times in a row with no success.
Feel free to reopen the bug (or better make a new one) if there's a good way to reproduce
the problem.

looks like related to bug #28400.

Marking bug #28400 as a duplicate of this one.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/29168

ChangeSet@1.2494, 2007-06-20 12:42:21+03:00, gkodinov@magare.gmz +1 -0
  Bug #27383: Crash in test "mysql_client_test"
  
  The C optimizer may decide that data access operations
  through pointer of different type are not related to 
  the original data (strict aliasing).
  This is what happens in fetch_long_with_conversion(),
  when called as part of mysql_stmt_fetch() : it tries 
  to check for truncation errors by first storing float
  (and other types of data) into a char * buffer and then 
  accesses them through a float pointer.
  This is done to prevent the effects of excess precision
  when using FPU registers.
  Fixed by making the intermediary variables volatile (
  to not re-introduce the excess precision bug) and using
  the intermediary value instead of the char * buffer.
  Note that there can be loss of precision for both signed
  and unsigned 64 bit integers converted to double and back,
  so the check must stay there (even for compatibility 
  reasons).
  Based on the excellent analysis in bug 28400.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/29376

ChangeSet@1.2494, 2007-06-22 13:49:40+03:00, gkodinov@magare.gmz +1 -0
  Bug #27383: Crash in test "mysql_client_test"
  
  The C optimizer may decide that data access operations
  through pointer of different type are not related to 
  the original data (strict aliasing).
  This is what happens in fetch_long_with_conversion(),
  when called as part of mysql_stmt_fetch() : it tries 
  to check for truncation errors by first storing float
  (and other types of data) into a char * buffer and then 
  accesses them through a float pointer.
  This is done to prevent the effects of excess precision
  when using FPU registers.
  However the doublestore() macro converts a double pointer
  to an union pointer. This violates the strict aliasing rule.
  Fixed by making the intermediary variables volatile (
  to not re-introduce the excess precision bug) and using
  the intermediary value instead of the char * buffer.
  Note that there can be loss of precision for both signed
  and unsigned 64 bit integers converted to double and back,
  so the check must stay there (even for compatibility 
  reasons).
  Based on the excellent analysis in bug 28400.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/29389

ChangeSet@1.2494, 2007-06-22 15:34:28+03:00, gkodinov@magare.gmz +1 -0
  Bug #27383: Crash in test "mysql_client_test"
  
  The C optimizer may decide that data access operations
  through pointer of different type are not related to 
  the original data (strict aliasing).
  This is what happens in fetch_long_with_conversion(),
  when called as part of mysql_stmt_fetch() : it tries 
  to check for truncation errors by first storing float
  (and other types of data) into a char * buffer and then 
  accesses them through a float pointer.
  This is done to prevent the effects of excess precision
  when using FPU registers.
  However the doublestore() macro converts a double pointer
  to an union pointer. This violates the strict aliasing rule.
  Fixed by making the intermediary variables volatile (
  to not re-introduce the excess precision bug) and using
  the intermediary value instead of the char * buffer.
  Note that there can be loss of precision for both signed
  and unsigned 64 bit integers converted to double and back,
  so the check must stay there (even for compatibility 
  reasons).
  Based on the excellent analysis in bug 28400.

As the reporter of bug#28300, this patch#29389 works for me.

Pushed into 5.1.21-beta

Pushed into 5.0.46

Noted in 5.0.46, 5.1.21 changelogs.

Added a workaround for an Intel FPU-related gcc bug that caused a
client library crash.

Corrected changelog entry:

Fixed a case of unsafe aliasing in the source that caused a client
library crash when compiled with gcc 4 at high optimization levels.

Bug #29705 was marked as duplicate of this one.