Bug #39802 On Windows, 32-bit time_t should be enforced
Submitted: 2 Oct 2008 9:38 Modified: 18 Jun 2010 1:15
Reporter: Calvin Sun Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Compiling Severity:S1 (Critical)
Version:5.1 OS:Microsoft Windows
Assigned to:
Triage: Triaged: D2 (Serious)

[2 Oct 2008 9:38] Calvin Sun
Description:
Starting from MSVC C++ 2005 (v8), the default size of time_t is changed from 32-bit to 64-bit. As the result, the binaries built with pre-v8 MSVC C++ do not work with the binaries built with v8 or after (server crashes).

Given the fact that MySQL 5.1 is still built with MSVC C++ 2003, and some (if not most) partners / users are using MSVC C++ 2005 or later. This will create binary incompatibility.

How to repeat:
Build mysqld with MSVC C++ 2003 vs. build mysqld with MSVC C++ 2005, you will see the difference of time_t (update_time in the following case):

with MSVC C++ 2005:
        update_time    0x0000000000000000    __int64

with MSVC C++ 2003:
        update_time    0x00000000    long

Suggested fix:
Add _USE_32BIT_TIME_T to the main CMakeLists.txt, such as:

# Checks for 32-bit version. And always use 32-bit time_t for compatibility
IF(CMAKE_GENERATOR MATCHES "Visual Studio" AND CMAKE_SIZEOF_VOID_P MATCHES 4)
  ADD_DEFINITIONS(-D_USE_32BIT_TIME_T)
ENDIF(CMAKE_GENERATOR MATCHES "Visual Studio" AND CMAKE_SIZEOF_VOID_P MATCHES 4)
[2 Oct 2008 10:25] Vladislav Vaintroub
Calvin, I'm not so sure about it. Why? Do we  use time_t in our exported API functions? If so, should not that be fixed to something more stable and known size?
[2 Oct 2008 13:40] Calvin Sun
The following three are part of class ha_statistics:

  time_t create_time;			/* When table was created */
  time_t check_time;
  time_t update_time;

And ha_statistics is part of class handler:

  ha_statistics stats;

Change the data type could be another way to address the issue.
[10 Oct 2008 17:42] Miguel Solorzano
VS2003 32-bit

Attachment: VS2003-update_time.PNG (image/png, text), 17.16 KiB.

[10 Oct 2008 17:44] Miguel Solorzano
Hi Calvin,

I built the 32-bit version with VS2003 and 64-bit version with VS2005. I saw the same definition for both. Please see prior picture attached taken using VS2003.
Thanks.
[10 Oct 2008 19:32] Calvin Sun
Miguel,

Please check the official released binary. This is what I have from '5.1.28-rc-community-debug':

-        this    0x062f8050 {prebuilt=0x02df5aa0 user_thd=0x062b3340 lock={...} ...}    ha_innobase * const
-        handler    {table_share=0x0630a6f8 table=0x0630a040 cached_table_flags=0x0000000c0041849e ...}    handler

...

-        stats    {data_file_length=0x0000000000004000 max_data_file_length=0x0000000000000000 index_file_length=0x0000000000004000 ...}    ha_statistics
        data_file_length    0x0000000000004000    unsigned __int64
        max_data_file_length    0x0000000000000000    unsigned __int64
        index_file_length    0x0000000000004000    unsigned __int64
        max_index_file_length    0xa5a5a5a5a5a5a5a5    unsigned __int64
        delete_length    0x0000000000000000    unsigned __int64
        auto_increment_value    0x0000000000000000    unsigned __int64
        records    0x0000000000000001    unsigned __int64
        deleted    0x0000000000000000    unsigned __int64
        mean_rec_length    0x00004000    unsigned long
        create_time    0x00000000    long
        check_time    0x00000000    long
        update_time    0x00000000    long

...

Again, this is from MySQL official released binary. You can see all three xxx_time are 32-bit long.

Also, on this page: http://msdn.microsoft.com/en-us/library/w4ddyt9h(VS.80).aspx

"In versions of Visual C++ and Microsoft C/C++ before Visual C++ 2005, time_t was a long int (32 bits) and hence could not be used for dates past 3:14:07 January 19, 2038, UTC. In Visual C++ 2005, time_t is equivalent to __time64_t by default, but defining _USE_32BIT_TIME_T changes time_t to __time32_t and forces many time functions to call versions that take the 32-bit time_t. "
[13 Oct 2008 20:54] Miguel Solorzano
Thank you for the feedback.

VISUAL STUDIO 2005

-		this	0x01e85a30 {table_share=0x00000000 table=0x00000000 cached_table_flags=
		Sql_alloc	{...}	Sql_alloc

-		stats	{data_file_length=0 max_data_file_length=0 index_file_length=0 ...}	ha_statistics
		data_file_length	0	unsigned __int64
		max_data_file_length	0	unsigned __int64
		index_file_length	0	unsigned __int64
		max_index_file_length	10344644715844964239	unsigned __int64
		delete_length	0	unsigned __int64
		auto_increment_value	0	unsigned __int64
		records	0	unsigned __int64
		deleted	0	unsigned __int64
		mean_rec_length	0	unsigned long
		create_time	0	__int64
		check_time	0	__int64
		update_time	0	__int64
		block_size	0	unsigned int
		multi_range_sorted	true	bool
+		multi_range_curr	0x8f8f8f8f {start_key={...} end_key={...} ptr=??? ...}	

VISUAL STUDIO 2003

-	this	0x01f713c8 {table_share=0x00000000 {table_category=???
	Sql_alloc	{...}	Sql_alloc

-	stats	{data_file_length=0 max_data_file_length=0 index_file_length=0 ...}	ha_statistics
	data_file_length	0	unsigned __int64
	max_data_file_length	0	unsigned __int64
	index_file_length	0	unsigned __int64
	max_index_file_length	10344644715844964239	unsigned __int64
	delete_length	0	unsigned __int64
	auto_increment_value	0	unsigned __int64
	records	0	unsigned __int64
	deleted	0	unsigned __int64
	mean_rec_length	0	unsigned long
	create_time	0	long
	check_time	0	long
	update_time	0	long
	block_size	0	unsigned int
	multi_range_sorted	true	bool
+	multi_range_curr	0x8f8f8f8f {start_key={key=??? length=??? keypart_map=??? ...} end_key=
[16 Oct 2008 22:27] Vladislav Vaintroub
I created Bug#40092 asking to change external APIs to datatypes with known size.
I think it would be a better solution than forcing users of our libraries to non-default settings (just because we failed to switch the compiler at the right time)
[30 Apr 2009 12:36] Bugs System
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/73143

2880 Narayanan V	2009-04-30
      Bug#39802 On Windows, 32-bit time_t should be enforced
      Bug#40092 Storage engine API uses time_t datatype
      
      Change the usage of time_t in the storage
      engine API to datatypes with known size
     @ sql/handler.h
        Bug#39802 On Windows, 32-bit time_t should be enforced
        Bug#40092 Storage engine API uses time_t datatype
        
        Changed create_time, check_time, update_time in the
        ha_statistics and PARTITION_INFO structures to ulong.
[30 Apr 2009 13:06] Bugs System
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/73151

2880 Narayanan V	2009-04-30
      Bug#39802 On Windows, 32-bit time_t should be enforced
      Bug#40092 Storage engine API uses time_t datatype
      
      Change the usage of time_t in the storage
      engine API to datatypes with known size
     @ sql/handler.h
        Bug#39802 On Windows, 32-bit time_t should be enforced
        Bug#40092 Storage engine API uses time_t datatype
        
        Change create_time, check_time, update_time
        in the ha_statistics and PARTITION_INFO
        structures to ulong.
[4 May 2009 10:00] Bugs System
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/73286

2891 Narayanan V	2009-05-04
      BUG#39802 On Windows, 32-bit time_t should be enforced
      
      A backport of fix for "BUG40092 - Storage engine API uses
      time_t datatype".
      
      Starting from MSVC C++ 2005 (v8), the default size of time_t
      is changed from 32-bit to 64-bit. As the result, the binaries
      built with pre-v8 MSVC C++ do not work with the binaries
      (storage engine plugins) built with v8 or after (server
      crashes).
      
      Fixed storage engine API to use datatype with known size
      (ulong) instead of time_t.
     @ sql/handler.h
        Bug#39802 On Windows, 32-bit time_t should be enforced
        
        Change create_time, check_time, update_time
        in the ha_statistics and PARTITION_INFO
        structures to ulong.
[13 May 2009 10:11] Bugs System
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/73919

2875 Anurag Shekhar	2009-05-13
      Bug #39802 On Windows, 32-bit time_t should be enforced
      
      This patch fixes compilation warning, "conversion from 'time_t' to 'ulong', 
      possible loss of data". 
      The fix is to typecast time_t to ulong before assigning it to ulong. 
      Backported this from 6.0-bugteam tree.
     @ storage/archive/ha_archive.cc
        type casting time_t to ulong before assigning.
     @ storage/federated/ha_federated.cc
        type casting time_t to ulong before assigning.
     @ storage/innobase/handler/ha_innodb.cc
        type casting time_t to ulong before assigning.
     @ storage/myisam/ha_myisam.cc
        type casting time_t to ulong before assigning.
[28 May 2009 8:18] Bugs System
Pushed into 5.1.36 (revid:joro@sun.com-20090528073639-yohsb4q1jzg7ycws) (version source revid:jimw@mysql.com-20090515174051-ndjvfd1e9hc9k9c3) (merge vers: 5.1.36) (pib:6)
[17 Jun 2009 19:25] Bugs System
Pushed into 5.4.4-alpha (revid:alik@sun.com-20090616183122-chjzbaa30qopdra9) (version source revid:anurag.shekhar@sun.com-20090514062426-qfqtj2vn41uubh6p) (merge vers: 6.0.12-alpha) (pib:11)
[14 Jul 2009 16:04] MC Brown
A note has been added to the 6.0.10 changelog: 

Storage engine plugins on Windows could've been built with a definition of time_t which was different from the server expectations. The difference could cause affected plugins to crash. In addition, the use of the time_t type in the storage engine API layer has been enforced.
[26 Aug 2009 13:46] Bugs System
Pushed into 5.1.37-ndb-7.0.8 (revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (version source revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (merge vers: 5.1.37-ndb-7.0.8) (pib:11)
[26 Aug 2009 13:46] Bugs System
Pushed into 5.1.37-ndb-6.3.27 (revid:jonas@mysql.com-20090826105955-bkj027t47gfbamnc) (version source revid:jonas@mysql.com-20090826105955-bkj027t47gfbamnc) (merge vers: 5.1.37-ndb-6.3.27) (pib:11)
[26 Aug 2009 13:48] Bugs System
Pushed into 5.1.37-ndb-6.2.19 (revid:jonas@mysql.com-20090825194404-37rtosk049t9koc4) (version source revid:jonas@mysql.com-20090825194404-37rtosk049t9koc4) (merge vers: 5.1.37-ndb-6.2.19) (pib:11)
[27 Aug 2009 16:33] Bugs System
Pushed into 5.1.35-ndb-7.1.0 (revid:magnus.blaudd@sun.com-20090827163030-6o3kk6r2oua159hr) (version source revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (merge vers: 5.1.37-ndb-7.0.8) (pib:11)
[5 May 2010 15:16] Bugs System
Pushed into 5.1.47 (revid:joro@sun.com-20100505145753-ivlt4hclbrjy8eye) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[6 May 2010 8:57] MC Brown
Added to the 5.1.47 changelog.
[28 May 2010 6:14] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100524190136-egaq7e8zgkwb9aqi) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (pib:16)
[28 May 2010 6:42] Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20100524190941-nuudpx60if25wsvx) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[28 May 2010 7:10] Bugs System
Pushed into 5.5.5-m3 (revid:alik@sun.com-20100524185725-c8k5q7v60i5nix3t) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[28 May 2010 21:48] Paul Dubois
Push resulted from incorporation of InnoDB tree. No changes pertinent to this bug.
Re-closing.
[15 Jun 2010 8:15] Bugs System
Pushed into 5.5.5-m3 (revid:alik@sun.com-20100615080459-smuswd9ooeywcxuc) (version source revid:mmakela@bk-internal.mysql.com-20100415070122-1nxji8ym4mao13ao) (merge vers: 5.1.47) (pib:16)
[15 Jun 2010 8:32] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100615080558-cw01bzdqr1bdmmec) (version source revid:mmakela@bk-internal.mysql.com-20100415070122-1nxji8ym4mao13ao) (pib:16)
[17 Jun 2010 12:21] Bugs System
Pushed into 5.1.47-ndb-7.0.16 (revid:martin.skold@mysql.com-20100617114014-bva0dy24yyd67697) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[17 Jun 2010 13:09] Bugs System
Pushed into 5.1.47-ndb-6.2.19 (revid:martin.skold@mysql.com-20100617115448-idrbic6gbki37h1c) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)
[17 Jun 2010 13:49] Bugs System
Pushed into 5.1.47-ndb-6.3.35 (revid:martin.skold@mysql.com-20100617114611-61aqbb52j752y116) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)