[MDEV-7804] Segfault when creating CONNECT table Created: 2015-03-19  Updated: 2015-07-28  Resolved: 2015-07-28

Status: Closed
Project: MariaDB Server
Component/s: Galera, Storage Engine - Connect
Affects Version/s: 10.0.17-galera
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Chris Casto Assignee: Nirbhay Choubey (Inactive)
Resolution: Duplicate Votes: 1
Labels: connect-engine
Environment:

CentOS release 6.6 (Final)

Linux 2.6.32-504.12.2.el6.x86_64 #1 SMP Wed Mar 11 22:03:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

VMWare guest w/ SAN storage

2 vCPUs
16 GB RAM


Attachments: File mariadb_connect.cnf     Text File mariadb_error_2015-03-19.txt     File mariadb_server.cnf     File my.cnf    

 Description   

I installed MariaDB-Galera-server and MariaDB-connect-engine via the yum repository. Whenever I tried creating a CONNECT table via ODBC, I get this error:

> CREATE TABLE local_table ENGINE=CONNECT TABLE_TYPE=ODBC tabname='remote_table' CONNECTION='RemoteDSN' OPTION_LIST='UseDSN=Yes';

ERROR 1113 (42000): A table must have at least 1 column

I thought that maybe the CONNECT engine wasn't installed, but when I ran SHOW ENGINES it had a "Yes" under support. Oh well. It's annoying that it won't auto-detect the column names, but whatever. So I tried connecting to a different MySQL database using TABLE_TYPE=MYSQL, and I get this instead:

> CREATE TABLE local_table (
report_id int(10) unsigned NOT NULL,
name varchar(255) DEFAULT NULL,
year smallint(5) unsigned DEFAULT NULL,
file_id int(10) unsigned DEFAULT NULL,
status tinyint(3) unsigned DEFAULT NULL,
type varchar(45) DEFAULT NULL
) ENGINE=CONNECT table_type=MYSQL CONNECTION='mysql://user:password@server/schema/table';

ERROR 1911 (HY000): Unknown option 'table_type'

Weird. So I tried taking table_type out...

ERROR 2013 (HY000): Lost connection to MySQL server during query

Uh oh. Sure enough, the error log has a nice little stacktrace telling me all about the segfault it just encountered, and I'm left with a shell of a table that causes additional segfaults any time I try to SELECT against it. The attached error log contains two segfaults: one from the CREATE and one from the SELECT.

I've tried uninstalling and reinstalling the various MarisDB packages in different order to no avail. This was a clean OS install, so there is currently nothing else installed on it other than the CentOS stock packages, Puppet, and unixODBC.

I don't know if this is relevant or not, but while the CONNECT engine does show up when I run SHOW ENGINES, it does not show up in the list of engines available when using the MySQL Workbench GUI to create a table.



 Comments   
Comment by Elena Stepanova [ 2015-03-19 ]

nirbhay_c,

Could you please check it out before we get Olivier involved?
Specifically, whether the CREATE statement works on a Galera cluster (I don't have one handy, but I'm sure you do). It works fine on a standalone server, so it might have something to do with MGC.

Or maybe you already know and have it documented that Galera does not support Connect engine? I would expect it to be true, but then it would be great to somehow prevent installing unsupported engines.

Comment by Chris Casto [ 2015-03-19 ]

I forgot to add the galera.cnf, but I have wsrep_on set to OFF because I'm testing things on a single instance before I start scaling out. Also, when the CONNECT engine didn't work I tried the same thing with the FEDERATED engine and it worked fine.

Comment by Nirbhay Choubey (Inactive) [ 2015-03-21 ]

Hi! I tried repeating some of provided scenarios on CentOS and Ubuntu on
MariaDB Galera Cluster (10.0.17-MariaDB-wsrep), but couldn't repeat the
issues.

 
SERVER 1
========
 
MariaDB [test]> CREATE TABLE remote_table (
    ->   report_id int(10) unsigned NOT NULL,
    ->   name varchar(255) DEFAULT NULL,
    ->   year smallint(5) unsigned DEFAULT NULL,
    ->   file_id int(10) unsigned DEFAULT NULL,
    ->   status tinyint(3) unsigned DEFAULT NULL,
    ->   type varchar(45) DEFAULT NULL
    -> ) ENGINE=InnoDB;
Query OK, 0 rows affected (0.07 sec)
 
MariaDB [test]> INSERT INTO remote_table VALUES(1, "foo", 1, 1, 1, "bar");
Query OK, 1 row affected (0.01 sec)
 
 
SERVER 2
========
 
MariaDB [test]> SELECT VERSION();
+-----------------------+
| VERSION()             |
+-----------------------+
| 10.0.17-MariaDB-wsrep |
+-----------------------+
1 row in set (0.00 sec)
 
MariaDB [test]> INSTALL SONAME 'ha_connect.so';Query OK, 0 rows affected (0.00 sec)
 
MariaDB [test]> CREATE TABLE local_table ENGINE=CONNECT TABLE_TYPE=MYSQL CONNECTION='mysql://root:@127.0.0.1:16001/test/remote_table';
Query OK, 0 rows affected (0.10 sec)
 
MariaDB [test]> SELECT * FROM local_table;
+-----------+------+------+---------+--------+------+
| report_id | name | year | file_id | status | type |
+-----------+------+------+---------+--------+------+
|         1 | foo  |    1 |       1 |      1 | bar  |
+-----------+------+------+---------+--------+------+
1 row in set (0.00 sec)

The issue does not seem to be specific to galera cluster.
bertrandop Could you please take a look?

Comment by Olivier Bertrand [ 2015-03-21 ]

I never used galera and cannot make any test on it.
However these errors are very strange as if a very old version of CONNECT was used. Or perhaps it is because to use ODBC and MYSQL table types, CONNECT must be compiled with these preprocessor variables defined:

MYSQL_SUPPORT
ODBC_SUPPORT

Are you sure they are defined in the compile process?
If so you also might want to define:

HUGE_SUPPORT
ZIP_SUPPORT
PIVOT_SUPPORT
LIBXML2_SUPPORT

Normally all this should be handled in CMakeLists.txt in which for instance you can find:

#
# MySQL
#
 
OPTION(CONNECT_WITH_MYSQL
       "Compile CONNECT storage engine with remote MySQL connection support"
       ON)
 
IF(CONNECT_WITH_MYSQL)
  SET(CONNECT_SOURCES ${CONNECT_SOURCES}
  myconn.cpp myconn.h tabmysql.cpp tabmysql.h)
  add_definitions(-DMYSQL_SUPPORT)
  IF(NOT UNIX)
    #
    # TODO: remove this
    # change to use "#include "../../include/mysql.h" in the sources.
    INCLUDE_DIRECTORIES("../../include/mysql")
  ENDIF(NOT UNIX)
ENDIF(CONNECT_WITH_MYSQL)

Perhaps CONNECT_WITH_MYSQL and CONNECT_WITH_ODBC are not ON by default on your system.

This does not explain why TABLE_TYPE is not recognized as an option. This is like CONNECT was not recognized at all.

About the error log, it does not provide useful information. It should if the version is a _DEBUG version but is useless if using a RELEASE version.

Your last comment seems to show that everything worked allright. So what was specific in the test that failed?

In your last comment you execute:

INSTALL SONAME 'ha_connect.so';

Did you mean:

INSTALL PLUGIN CONNECT SONAME 'ha_connect.so';

Comment by Nirbhay Choubey (Inactive) [ 2015-03-21 ]

The issue does not seem to be related to galera cluster. The connect engine package
(MariaDB-connect-engine), on the other hand, is generated from 10.0 source, where
I do see the suggested changes already in place.

https://github.com/MariaDB/server/blob/10.0/storage/connect/CMakeLists.txt#L168

Also, from the attached error log, the connect engine does not looks pretty new :

150319  9:36:39 [Note] CONNECT: Version 1.03.0006 February 06, 2015

INSTALL SONAME is a variant of INSTALL PLUGIN that loads all the plugins
from the specified library.
https://mariadb.com/kb/en/mariadb/install-soname/

Comment by Olivier Bertrand [ 2015-03-21 ]

Can you compile a DEBUG version of the server that crashes. Then I could see where the error occured.

Another hint:
It happens that the ha_connect.so module does not contain only the CONNECT plugin. It also contains all the json UDF's.
Perhaps loading UDF's as if they were PLUGIN's caused these problems.

Comment by Olivier Bertrand [ 2015-03-21 ]

I have done some more tests:

INSTALL SONAME works (even if UDF's are not installed)
The version of CONNECT is the last one.
Compiling without ODBC (by not having ODBC_SUPPORT defined) produces the expected message:
"Unsupported table type ODBC"
Compiling without MYSQL support fails at compile time.

Therefore the only thing that could help me find the cause of your error is a log file from a DEBUG version.

Comment by Nirbhay Choubey (Inactive) [ 2015-07-28 ]

Duplicate of MDEV-8240.

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