| Bug #39802 | On Windows, 32-bit time_t should be enforced | ||
|---|---|---|---|
| Submitted: | 2 Oct 2008 11:38 | Modified: | 14 Jul 18:04 |
| Reporter: | Calvin Sun | ||
| Status: | Closed | ||
| Category: | Server: Compiling | Severity: | S1 (Critical) |
| Version: | 5.1 | OS: | Microsoft Windows |
| Assigned to: | Narayanan venkateswaran | Target Version: | 5.1+ |
| Triage: | Triaged: D2 (Serious) | ||
[2 Oct 2008 12: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 15: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 19:42]
Miguel Solorzano
VS2003 32-bit
Attachment: VS2003-update_time.PNG (image/png, text), 17.16 KiB.
[10 Oct 2008 19: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 21: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 22: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=
[17 Oct 2008 0: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 14: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 15: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 12: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 12: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 10: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 21: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 18: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 15: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 15: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 15: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 18: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)
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)