MySQL Bugs: #55538: MySQL 5.1.49 with 2038 year check is broken.

Bug #55538	MySQL 5.1.49 with 2038 year check is broken.
Submitted:	25 Jul 2010 18:07	Modified:	9 Jan 2011 20:40
Reporter:	Brad Smith	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: General	Severity:	S1 (Critical)
Version:	5.1.49, 5.1.50, 5.1.51, 5.1.52, 5.1.53	OS:	Other (OpenBSD and FreeBSD amd64)
Assigned to:		CPU Architecture:	Any

Description:
OS: OpenBSD -current

Ever since this commit MySQL is now broken..

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

# ./mysqld
100725 14:01:06 [ERROR] This MySQL server doesn't support dates later then 2038
100725 14:01:06 [ERROR] Aborting

Segmentation fault (core dumped)
# date 
Sun Jul 25 14:05:50 EDT 2010

How to repeat:
Start up MySQL.

Suggested fix:
Unknown.

Please, send the results of

uname -a

command.

$ uname -a
OpenBSD speedy.comstyle.com 4.7 GENERIC.MP#214 amd64

Same for FreeBSD 6.3. Core dumped at start with the very same message.
$uname -a
$FreeBSD 6.3-RELEASE alpha

See

http://bugs.mysql.com/bug.php?id=55755

for fix

This is still busted with 5.1.50. Come on guys this is ridiculous putting out releases that don't even start up. Great Q&A testing.

I had not checked with FreeBSD 6.3 yet, but our official binaries (from dev.mysql.com) on FreeBSD 7.0 just work:

$ uname -a
FreeBSD freebsd.mshome.net 7.0-RELEASE FreeBSD 7.0-RELEASE #3: Fri Apr  3 18:00:06 EEST 2009     root@freebsd.mshome.net:/usr/obj/usr/src/sys/CUSTOM  i386
$ bash
[openxs@freebsd /usr/home/openxs]$ cd mysql-5.1.50-freebsd7.0-i386
[openxs@freebsd /usr/home/openxs/mysql-5.1.50-freebsd7.0-i386]$ bin/mysqld_safe &
[1] 49995
[openxs@freebsd /usr/home/openxs/mysql-5.1.50-freebsd7.0-i386]$ 100831 15:37:01 mysqld_safe Logging to '/usr/home/openxs/mysql-5.1.50-freebsd7.0-i386/data/freebsd.mshome.net.err'.
100831 15:37:01 mysqld_safe Starting mysqld daemon with databases from /usr/home/openxs/mysql-5.1.50-freebsd7.0-i386/data

[openxs@freebsd /usr/home/openxs/mysql-5.1.50-freebsd7.0-i386]$ bin/mysql -uroot test
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.1.50 MySQL Community Server (GPL)

Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2 license

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

As for OpenBSD, please, inform about configure options used to build.

autoconf log

Attachment: configure.log (application/octet-stream, text), 30.82 KiB.

The autoconf options being used are...

--with-big-tables --with-libwrap --with-low-memory --with-plugins=max-no-ndb
--with-ssl=/usr --without-docs --without-readline

Let me know if there is any other info from the build that you are in need of.

This seems to be an issue only for 64-bit hosts. MySQL works fine on i386 but fails on amd64 and sparc64.

To add other informations, on OpenBSD-amd64 time_t is defined as int, LONG_MIN is (-0x7fffffffffffffffL-1) and LONG_MAX is 0x7fffffffffffffffL.

5.1.51 as well. come on, lets hurry this up.

For the time being to be able to move forward to 5.1.52 I have reverted the commit I mentioned initially to allow MySQL to function on the 64-bit architectures.

Also affects 5.1.53.

This not looks like a MySQL problem.

It looks like that this problem only happens on old BSD versions.
BSD versions that wasn't 2038 save already.

Please test with the new actual versions of OpenBSD and FreeBSD.

This is the latest release. I can't run anything newer.

Whether the OS is 2038 safe or not is not the question. MySQL worked fine for just under 12 years and now it is broken.

Still busted with MySQL 5.1.53

101213 20:08:03 mysqld_safe Starting mysqld daemon with databases from /var/mysql
101213 20:08:03 [ERROR] This MySQL server doesn't support dates later then 2038
101213 20:08:03 [ERROR] Aborting

Segmentation fault (core dumped) 
101213 20:08:03 mysqld_safe mysqld from pid file /var/mysql/xena.mcw.com.au.pid ended
101213 20:08:53 mysqld_safe Starting mysqld daemon with databases from /var/mysql
101213 20:08:53 [ERROR] This MySQL server doesn't support dates later then 2038
101213 20:08:53 [ERROR] Aborting

Segmentation fault (core dumped) 

xena:mysql {132} uname -a
OpenBSD xena.mcw.com.au 4.8 GENERIC.MP#0 amd64

Let's say this is a duplicate of Bug #55755 (verified already), as there is a solution suggested there.

I'm sorry, but little can be done for OSes that don't support 8 byte time_t (2038-safe). I will fix the check at hand, but don't expect mysql on these OSes to work correctly with dates post 2038.

No one has asked for dates past 2038 to work. It is pretty obvious this will not work as is. We want MySQL fixed so it is no longer broken. It worked fine for 13+ years and then this "check" was added which broke it, not cool at all.

Brad, can you please check if the fix in 55755 (http://lists.mysql.com/commits/128103) addresses your problems ?

Parts of the commited change will not compile as is...

for..
  if ((tmp < TIMESTAMP_MIN_VALUE) 
#if SIZEOF_TIME_T > 4
      || (tmp > TIMESTAMP_MAX_VALUE))
#endif

The last ) has to be moved below #endif in both my_time.cc and set_var.cc.

Also I noticed you have #if SIZEOF_TIME_T > 4 in some spots instead of
#if SIZEOF_TIME_T > SIZEOF_LONG which is used within the IS_VALID_TIME() macro.

After fixing the code so it compiles this now allows MySQL to work on 64-bit architectures for OpenBSD.

In my last comment I said..

Also I noticed you have #if SIZEOF_TIME_T > 4 in some spots instead of
#if SIZEOF_TIME_T > SIZEOF_LONG which is used within the IS_VALID_TIME() macro.

I meant to say use #if SIZEOF_TIME_T > SIZEOF_INT.

Brad,

 thanks for spotting the typo in the diff. Will fix it in the next version. 
About the suggestion to use SIZEOF_LONG/SIZEOF_INT in comparisons I think I should stick with the constant 4 : we don't have a named constant for the size of INT32, but since by definition it's 4 I don't think we need one. At the places where this is used the code is trying to find out whether a value supplied is a valid mysql timestamp and not a valid time_t.

This is still busted with 5.1.61,5.6.14. 

#uname -a

Linux localhost 2.6.32-220.el6.x86_64 #1 SMP Tue Dec 6 19:48:22 GMT 2011 x86_64 x86_64 x86_64 GNU/Linux

#date

Mon Oct 25 18:18:36 CST 2038