[MCOL-1657] Drop table crashes crashes the server during upgrade to development branch Created: 2018-08-16  Updated: 2018-11-12  Resolved: 2018-11-12

Status: Closed
Project: MariaDB ColumnStore
Component/s: MariaDB Server
Affects Version/s: 1.2
Fix Version/s: Icebox

Type: Bug Priority: Major
Reporter: Ravi Prakash (Inactive) Assignee: Andrew Hutchings (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Environment:

CentOS Linux 7.4

Issue Links:
Duplicate
duplicates MCOL-1809 Document mysql_upgrade requirement as... Closed

 Description   

I ran into this problem and while attempting to drop a table in the development branch (1.2). The mysqld server crashed with the following trace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f68e811d700 (LWP 24237)]
0x000055a553ff0c4f in ha_sequence::ha_sequence (this=0x7f6854014aa8, hton=0x55a556d97660, share=0x0)
at /home/rprakash/mariadb/mariadb-columnstore-server/sql/ha_sequence.cc:53
(gdb) bt 7
#0 0x000055a553ff0c4f in ha_sequence::ha_sequence (this=0x7f6854014aa8, hton=0x55a556d97660, share=0x0)
at /home/rprakash/mariadb/mariadb-columnstore-server/sql/ha_sequence.cc:53
#1 0x000055a553ff1d98 in sequence_create_handler (hton=0x55a556d97660, share=0x0, mem_root=0x7f68540061a8)
at /home/rprakash/mariadb/mariadb-columnstore-server/sql/ha_sequence.cc:376
#2 0x000055a5538760b6 in get_new_handler (share=0x0, alloc=0x7f68540061a8, db_type=0x55a556d97660)
at /home/rprakash/mariadb/mariadb-columnstore-server/sql/handler.cc:267
#3 0x000055a55387b3dc in ha_delete_table (thd=0x7f6854000b00, table_type=0x55a556d97660, path=0x7f68e811b080 "./mydb/d1", db=0x7f68e811ad10,
alias=0x7f6854014250, generate_warning=true) at /home/rprakash/mariadb/mariadb-columnstore-server/sql/handler.cc:2539
#4 0x000055a55364bafd in mysql_rm_table_no_locks (thd=0x7f6854000b00, tables=0x7f6854014228, if_exists=false, drop_temporary=false, drop_view=false,
drop_sequence=false, dont_log_query=false, dont_free_locks=false) at /home/rprakash/mariadb/mariadb-columnstore-server/sql/sql_table.cc:2514
#5 0x000055a55364ab07 in mysql_rm_table (thd=0x7f6854000b00, tables=0x7f6854014228, if_exists=false, drop_temporary=false, drop_sequence=false)
at /home/rprakash/mariadb/mariadb-columnstore-server/sql/sql_table.cc:2128
#6 0x000055a553580e17 in mysql_execute_command (thd=0x7f6854000b00) at /home/rprakash/mariadb/mariadb-columnstore-server/sql/sql_parse.cc:5091

The following steps are likely to reproduce the problem. Create some tables definitions. May want to store some rows in it. Build 1.2 binaries, post-install and postConfigure new binaries. Connect to the the database and drop the tables. I used the following table definitions.

CREATE TABLE t1 ( c1 int not null, c2 bigint, c3 float,
c4 double, c5 char(10), c6 varchar(20), c7 datetime ,
c8 tinytext, c9 tinyblob, c10 text, c11 blob,
c12 mediumtext, c13 mediumblob, c14 longtext,
c15 longblob ) engine=columnstore max_rows = 1000;
CREATE TABLE tn1 ( c1 int not null, c2 bigint not null, c3 float not null,
c4 double not null, c5 char(10) not null, c6 varchar(20) not null, c7 datetime not null,
c8 tinytext not null, c9 tinyblob not null, c10 text not null, c11 blob not null,
c12 mediumtext not null, c13 mediumblob not null, c14 longtext not null,
c15 longblob not null) engine=columnstore max_rows = 1000 min_rows=10;

I have not yet tried more than once.

 Comments   
Comment by Ravi Prakash (Inactive) [ 2018-08-16 ]

I also noticed that if one describes the table before dropping it works. For example:

desc d1;
drop table d1;

Worked.
In this case the table d1 was created using the following statement.

CREATE TABLE d1 ( c1 int not null default 10, c2 bigint default 2147483648,
c3 float default 3.3, c4 double default 7.7,
c5 char(10) default 'def char',
c6 varchar(20) default 'def varchar ',
c7 datetime default '2018-06-07' ) engine=columnstore;

Comment by Patrick LeBlanc (Inactive) [ 2018-10-31 ]

This is likely due to the server version update. I ran into the same thing stepping through the process of upgrading CS 1.1.6 to 1.2.1. The missing step in the process was running mysql_upgrade after upgrading CS.

Comment by Andrew Hutchings (Inactive) [ 2018-11-12 ]

tl;dr: this is a duplicate of MCOL-1809 and is due to mysql_upgrade not being run on a 1.1 -> 1.2 upgrade.

Longer version:
The table IDs have shifted from 10.2 -> 10.3, ColumnStore is given 44 in 1.1 but that is HA_SEQUENCE in 1.2. The sequence handler isn't designed to be accessed using drop table and a NULL pointer dereference happens.

Several functions will fix the table ID but mysql_upgrade is the preferred method.

Generated at Thu Feb 08 02:30:23 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.