Bug #5901 CHECK TABLE crashes on a TIMESTAMP column in upgrade 4.0 -> 4.1
Submitted: 5 Oct 2004 16:19 Modified: 5 Oct 2004 19:05
Reporter: Heikki Tuuri Email Updates:
Status: Closed Impact on me:
Category:MySQL Server Severity:S1 (Critical)
Version: OS:
Assigned to: Dmitry Lenev CPU Architecture:Any

[5 Oct 2004 16:19] Heikki Tuuri
heikki@hundin:~/mysql-4.0/client> ./mysql test
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.0.22-debug-log

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

mysql> create table t3(a timestamp, b timestamp, index(a, b)) type = innodb;
Query OK, 0 rows affected (0.00 sec)

mysql> create table t4(a timestamp, b timestamp, index(a, b)) type = myisam;
Query OK, 0 rows affected (0.00 sec)

mysql> exit
heikki@hundin:~/mysql-4.0/client> ./mysqladmin shutdown
heikki@hundin:~/mysql-4.0/client> cd
heikki@hundin:~> cd mysql-4.1
heikki@hundin:~/mysql-4.1> cd client
heikki@hundin:~/mysql-4.1/client> ./mysql test
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 4.1.6-gamma-debug-log

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

mysql> check table t4;
ERROR 2013 (HY000): Lost connection to MySQL server during query

heikki@hundin:~/mysql-4.1/sql> ./mysqld
041005 18:47:01  [WARNING] You have enabled the binary log, but you haven't set
server-id to a non-zero value: we force server id to 1; updates will be logged t
o the binary log, but connections from slaves will not be accepted.
InnoDB: Resetting space id's in the doublewrite buffer
041005 18:47:01  InnoDB: Started; log sequence number 0 309795444
InnoDB: You are upgrading to an InnoDB version which allows multiple
InnoDB: tablespaces. Wait that purge and insert buffer merge run to
InnoDB: completion...
InnoDB: Full purge and insert buffer merge completed.
InnoDB: You have now successfully upgraded to the multiple tablespaces
InnoDB: format. You should NOT DOWNGRADE to an earlier version of
InnoDB: InnoDB! But if you absolutely need to downgrade, see
InnoDB: http://dev.mysql.com/doc/mysql/en/Multiple_tablespaces.html
InnoDB: for instructions.
./mysqld: ready for connections.
Version: '4.1.6-gamma-debug-log'  socket: '/home/heikki/bugsocket'  port: 3307
Source distribution
mysqld: field.cc:2980: timestamp_auto_set_type Field_timestamp::get_auto_set_typ
e() const: Assertion `0' failed.
mysqld got signal 6;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 253436
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0x428878d8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instru
ctions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8b4a9b8 = check table t4
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.


Using an InnoDB type table, some gdb output:

Program received signal SIGABRT, Aborted.
[Switching to Thread 147466 (LWP 5402)]
0x40142b71 in kill () from /lib/i686/libc.so.6
(gdb) bt
#0  0x40142b71 in kill () from /lib/i686/libc.so.6
#1  0x40065cf1 in pthread_kill () from /lib/i686/libpthread.so.0
#2  0x4006600b in raise () from /lib/i686/libpthread.so.0
#3  0x40142904 in raise () from /lib/i686/libc.so.6
#4  0x40143e8c in abort () from /lib/i686/libc.so.6
#5  0x4013be84 in __assert_fail () from /lib/i686/libc.so.6
#6  0x08144849 in Field_timestamp::get_auto_set_type() const (this=0x0)
    at field.cc:2980
#7  0x08199eb5 in open_table(THD*, char const*, char const*, char const*, bool*)
 (thd=0x8b40568, db=0x8b07c70 "test", table_name=0x8b4a9f8 "ibtest09",
    alias=0x8b4aa20 "ibtest09", refresh=0x428880a7) at sql_base.cc:948
#8  0x0819b4df in open_ltable(THD*, st_table_list*, thr_lock_type) (
    thd=0x8b40568, table_list=0x8b4aa30, lock_type=TL_READ_NO_INSERT)
    at sql_base.cc:1589
#9  0x08209f03 in mysql_admin_table (thd=0x8b40568, tables=0x8b4aa30,
    check_opt=0x8b4090c, operator_name=0x83984c7 "check",
    lock_type=TL_READ_NO_INSERT, open_for_modify=false, extra_open_options=32,
    prepare_func=0, operator_func={__pfn = 0xc9, __delta = 0})
    at sql_table.cc:1774
#10 0x0820b5fa in mysql_check_table(THD*, st_table_list*, st_ha_check_opt*) (
    thd=0x0, tables=0x0, check_opt=0x0) at sql_table.cc:2265
#11 0x0817a99c in mysql_execute_command(THD*) (thd=0x8b40568)
    at sql_parse.cc:2613
#12 0x0817e5ed in mysql_parse(THD*, char*, unsigned) (thd=0x8b40568,
    inBuf=0x8b4a9b8 "check table ibtest09", length=146015648)
    at sql_parse.cc:4046
#13 0x081777c7 in dispatch_command(enum_server_command, THD*, char*, unsigned)
    (command=COM_QUERY, thd=0x8b40568, packet=0x8b423d1 "", packet_length=21)
    at sql_parse.cc:1457
#14 0x081770db in do_command(THD*) (thd=0x8b40568) at sql_parse.cc:1272
#15 0x081765c2 in handle_one_connection (arg=0x0) at sql_parse.cc:1016
#16 0x40062f60 in pthread_start_thread () from /lib/i686/libpthread.so.0
#17 0x400630fe in pthread_start_thread_event () from /lib/i686/libpthread.so.0
#18 0x401f5327 in clone () from /lib/i686/libc.so.6
(gdb) frame 6
#6  0x08144849 in Field_timestamp::get_auto_set_type() const (this=0x0)
    at field.cc:2980
2980        DBUG_ASSERT(0);
(gdb) list
2975      default:
2976        /*
2977          Normally this function should not be called for TIMESTAMPs without
2978          auto-set property.
2979        */
2980        DBUG_ASSERT(0);
2981        return TIMESTAMP_NO_AUTO_SET;
2982      }
2983    }
(gdb) frame 7
#7  0x08199eb5 in open_table(THD*, char const*, char const*, char const*, bool*)
 (thd=0x8b40568, db=0x8b07c70 "test", table_name=0x8b4a9f8 "ibtest09",
    alias=0x8b4aa20 "ibtest09", refresh=0x428880a7) at sql_base.cc:948
948         table->timestamp_field_type= table->timestamp_field->get_auto_set_ty
(gdb) list
943       table->outer_join= table->null_row= table->maybe_null= table->force_in
dex= 0;
944       table->status=STATUS_NO_RECORD;
945       table->keys_in_use_for_query= table->keys_in_use;
946       table->used_keys= table->keys_for_keyread;
947       if (table->timestamp_field)
948         table->timestamp_field_type= table->timestamp_field->get_auto_set_ty
949       DBUG_ASSERT(table->key_read == 0);
950       DBUG_RETURN(table);
951     }

How to repeat:
I used mysql system tables generated by make test. In MySQL 4.0 one must use different tables than in 4.1.

Thus, the problem might be in make test, but I believe it is not. Just some ordinary bug.


[5 Oct 2004 19:05] Dmitry Lenev
Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at

Additional info:

ChangeSet 1.2053.2.1 2004/10/05 21:23:38 dlenev@brandersnatch.localdomain
  Fixed small bug in handling of pre-4.1 TIMESTAMP columns which was
  introduced during implementation of TIMESTAMP columns, which are able 
  to store NULLs