Description:
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
Bye
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
mysql>
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.
key_buffer_size=36700160
read_buffer_size=131072
max_used_connections=1
max_connections=100
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 253436
K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x8b40568
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:
0x81630f5
0x4006896c
0x40142b71
0x4006600b
0x40142904
0x40143e8c
0x4013be84
0x8144849
0x8199eb5
0x819b4df
0x8209f03
0x820b5fa
0x817a99c
0x817e5ed
0x81777c7
0x81770db
0x81765c2
0x40062f60
0x401f5327
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
thd->thread_id=1
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.
heikki@hundin:~/mysql-4.1/sql>
.....................
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 }
2984
(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
pe();
(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
pe();
949 DBUG_ASSERT(table->key_read == 0);
950 DBUG_RETURN(table);
951 }
952
(gdb)
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.
Regards,
Heikki
