Crash when alter table with enum column collated utf8_unicode_ci

Crash when alter table with enum column collated utf8_unicode_ci

am 13.07.2004 04:58:51 von Jeremy March

There is a crashing bug in 4.1.4 (bk pulled as of July 12) when
executing ALTER TABLE on a table with an enum column collated with
utf8_unicode_ci. It works fine with utf8_general_ci. This is the case
for both myisam and innodb tables. I tested this on a pentium 3 running
red hat linux 9. I've included the error log entry at the bottom.

best regards,
Jeremy March


CREATE TABLE t1 (yesno enum ('Y', 'N') DEFAULT 'N' COLLATE
utf8_unicode_ci);

mysql crashes with alter table:
ALTER TABLE t1 ADD COLUMN col2 CHAR(20);


it works when using utf8_general_ci, though:
CREATE TABLE t1 (yesno enum ('Y', 'N') DEFAULT 'N' COLLATE
utf8_general_ci);

ALTER TABLE t1 ADD COLUMN col2 CHAR(20);


Error log entry:

040712 22:49:09 mysqld ended

040712 22:49:36 mysqld started
040712 22:49:36 InnoDB: Started; log sequence number 0 74128
040712 22:49:36 Warning: Can't open time zone table: Table
'mysql.time_zone_leap_second' doesn't exist trying to live without them
/usr/local/bk2mysql-4.1/libexec/mysqld: ready for connections.
Version: '4.1.4-beta-log' socket:
'/usr/local/bk2mysql-4.1/tmp/mysql.sock' port: 3307
mysqld got signal 11;
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=16777216
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
= 80383 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8580f28
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=0x41dfa984, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x813d9b4
0x40043618
(nil)
0x81cab69
0x81c8239
0x81c5b96
0x8150d5a
0x81552d5
0x814efb9
0x814ebe2
0x814e449
0x4003e2b6
0x420de407
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 instructions 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 0x8570568 = alter table t1 add column col2 char(20)
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.

Number of processes running now: 0
040712 22:50:45 mysqld restarted
040712 22:50:45 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
040712 22:50:45 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 74165.
InnoDB: Doing recovery: scanned up to log sequence number 0 74165
InnoDB: Last MySQL binlog file position 0 79, file name
../tholobate-bin.000245
040712 22:50:45 InnoDB: Flushing modified pages from the buffer pool...
040712 22:50:45 InnoDB: Started; log sequence number 0 74165
040712 22:50:45 Warning: Can't open time zone table: Table
'mysql.time_zone_leap_second' doesn't exist trying to live without them
/usr/local/bk2mysql-4.1/libexec/mysqld: ready for connections.
Version: '4.1.4-beta-log' socket:
'/usr/local/bk2mysql-4.1/tmp/mysql.sock' port: 3307



--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org

Re: Crash when alter table with enum column collated utf8_unicode_ci

am 14.07.2004 22:24:12 von Dean Ellis

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremy,

> There is a crashing bug in 4.1.4 (bk pulled as of July 12) when
> executing ALTER TABLE on a table with an enum column collated with
> utf8_unicode_ci. It works fine with utf8_general_ci. This is the case
> for both myisam and innodb tables. I tested this on a pentium 3 running
> red hat linux 9. I've included the error log entry at the bottom.
>
> CREATE TABLE t1 (yesno enum ('Y', 'N') DEFAULT 'N' COLLATE
> utf8_unicode_ci);
>
> mysql crashes with alter table:
> ALTER TABLE t1 ADD COLUMN col2 CHAR(20);

I have verified this and will file the bug report so that this is
resolved as soon as possible. Thank you for the report!

Best regards,
- --
Dean Ellis, Support Engineer & Software Developer
MySQL AB, www.mysql.com

Are you MySQL certified? http://www.mysql.com/certification
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFA9ZZsAebV/bGJ5NERAs+/AKCQnii2D6F6tAs1AnyYJTKtMOuXDwCd GWYK
F6L3LoJ5DzpQdGvKw13DAwo=
=nVnV
-----END PGP SIGNATURE-----

--
MySQL Bugs Mailing List
For list archives: http://lists.mysql.com/bugs
To unsubscribe: http://lists.mysql.com/bugs?unsub=gcdmb-bugs@m.gmane.org