[MDEV-17352] Crash with CONNECT + Informix ODBC driver + discovery Created: 2018-10-02  Updated: 2018-10-03

Status: Open
Project: MariaDB Server
Component/s: Storage Engine - Connect
Affects Version/s: 10.2.19
Fix Version/s: 10.2

Type: Bug Priority: Major
Reporter: Valerii Kravchuk Assignee: Olivier Bertrand
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Ubuntu 14.04


 Description   

I've installed Informix 11..70 from this binaries:

rw-rw-r- 1 openxs openxs 483799040 вер 11 17:31 iif.11.70.FC8DE.linux-x86_64.tar

and tried to use CONNECT engine via their ODBC driver to work with Informix table:

create table t1(id int, c1 int);

I'll skip installation details, odbs.ini and odbcinst.ini etc for now (available at request). Everything works until I try to create a table without providing columns:

MariaDB [test]> create table informix_t3(id int, c1 int) engine=connect table_type=ODBC tabname='t1' dbname='test' connection='dsn=inf';
 
Query OK, 0 rows affected (0,06 sec)
 
 
 
MariaDB [test]> select * from informix_t3;
 
+------+------+
 
| id   | c1   |
 
+------+------+
 
|    1 |    2 |
 
+------+------+
 
1 row in set (0,03 sec)
 
 
 
MariaDB [test]> select version();
 
+-----------------+
 
| version()       |
 
+-----------------+
 
| 10.2.19-MariaDB |
 
+-----------------+
 
1 row in set (0,00 sec)
 
 
 
MariaDB [test]> create table informix_t11 engine=connect table_type=ODBC tabname='T1' dbschema='TEST' connection='dsn=inf';
 
ERROR 2013 (HY000): Lost connection to MySQL server during query
 
MariaDB [test]>

In gdb I see the following backtrace:

(gdb) c
 
Continuing.
 
[New Thread 0x7f833d3f6700 (LWP 20265)]
 
 
 
Program received signal SIGSEGV, Segmentation fault.
 
[Switching to Thread 0x7f833d3f6700 (LWP 20265)]
 
__strncpy_ssse3 () at ../sysdeps/x86_64/multiarch/strcpy-ssse3.S:2743
 
2743    ../sysdeps/x86_64/multiarch/strcpy-ssse3.S: No such file or directory.
 
(gdb) bt
 
#0  __strncpy_ssse3 () at ../sysdeps/x86_64/multiarch/strcpy-ssse3.S:2743
 
#1  0x00007f833e47d02b in strncpy (__len=18446744073709551615,
 
    __src=<optimized out>, __dest=<optimized out>)
 
    at /usr/include/x86_64-linux-gnu/bits/string3.h:120
 
#2  TYPVAL<char*>::SetValue_char (this=0x7f82d011dc70, cp=<optimized out>,
 
    n=-1) at /home/openxs/git/server/storage/connect/value.cpp:1384
 
#3  0x00007f833e4a5d5a in ODBConn::GetCatInfo (this=this@entry=0x7f82cffff048,
 
    cap=0x7f82d00baf08)
 
    at /home/openxs/git/server/storage/connect/odbconn.cpp:2441
 
#4  0x00007f833e4a6cc4 in ODBCColumns (g=g@entry=0x7f82d403b610,
 
    dsn=dsn@entry=0x7f82cffff018 "dsn=inf", db=db@entry=0x0,
 
    table=table@entry=0x7f82d4039578 "", colpat=colpat@entry=0x0,
 
    maxres=<optimized out>, maxres@entry=0, info=false,
 
    sop=sop@entry=0x7f82cffff020)
 
    at /home/openxs/git/server/storage/connect/odbconn.cpp:406
 
#5  0x00007f833e41ddfd in connect_assisted_discovery (thd=0x7f82d4016738,
 
    table_s=0x7f833d3f3250, create_info=0x7f833d3f3d80)
 
    at /home/openxs/git/server/storage/connect/ha_connect.cc:5781
 
#6  0x00007f83432bc2c8 in create_table_impl (thd=thd@entry=0x7f82d4016738,
 
    orig_db=orig_db@entry=0x7f82d40204a0 "",
 
    orig_table_name=orig_table_name@entry=0x7f82d401fe48 "",
 
    db=db@entry=0x7f82d40204a0 "",
 
    table_name=table_name@entry=0x7f82d401fe48 "",
 
    path=path@entry=0x7f833d3f3920 "./test/informix_t1", options=...,
 
    create_info=create_info@entry=0x7f833d3f3d80,
 
    alter_info=alter_info@entry=0x7f833d3f3cd0,
 
    create_table_mode=create_table_mode@entry=-3,
 
    is_trans=is_trans@entry=0x7f833d3f3b9f,
 
    key_info=key_info@entry=0x7f833d3f3908,
 
    key_count=key_count@entry=0x7f833d3f3904, frm=frm@entry=0x7f833d3f3910)
 
    at /home/openxs/git/server/sql/sql_table.cc:4875
 
#7  0x00007f83432bcb4a in mysql_create_table_no_lock (
 
    thd=thd@entry=0x7f82d4016738, db=db@entry=0x7f82d40204a0 "",
 
    table_name=table_name@entry=0x7f82d401fe48 "",
 
    create_info=create_info@entry=0x7f833d3f3d80,
 
    alter_info=alter_info@entry=0x7f833d3f3cd0,
 
    is_trans=is_trans@entry=0x7f833d3f3b9f, create_table_mode=-3)
 
    at /home/openxs/git/server/sql/sql_table.cc:5019
 
#8  0x00007f83432bcccf in mysql_create_table (thd=thd@entry=0x7f82d4016738,
 
    create_table=create_table@entry=0x7f82d401fe90,
 
    create_info=create_info@entry=0x7f833d3f3d80,
 
    alter_info=alter_info@entry=0x7f833d3f3cd0)
 
    at /home/openxs/git/server/sql/sql_table.cc:5082
 
#9  0x00007f8343242c2d in mysql_execute_command (thd=thd@entry=0x7f82d4016738)
 
    at /home/openxs/git/server/sql/sql_parse.cc:3988
 
#10 0x00007f834324395f in mysql_parse (thd=0x7f82d4016738,
 
    rawbuf=<optimized out>, length=<optimized out>,
 
    parser_state=0x7f833d3f5260, is_com_multi=<optimized out>,
 
    is_next_command=<optimized out>)
 
    at /home/openxs/git/server/sql/sql_parse.cc:8011
 
#11 0x00007f8343246aa6 in dispatch_command (command=command@entry=COM_QUERY,
 
    thd=thd@entry=0x7f82d4016738, packet=packet@entry=0x7f82d400a2f9 "",
 
    packet_length=packet_length@entry=105,
 
    is_com_multi=is_com_multi@entry=false,
 
    is_next_command=is_next_command@entry=false)
 
    at /home/openxs/git/server/sql/sql_parse.cc:1824
 
#12 0x00007f8343247418 in do_command (thd=0x7f82d4016738)
 
    at /home/openxs/git/server/sql/sql_parse.cc:1378
 
#13 0x00007f83433029cc in do_handle_one_connection (
 
    connect=connect@entry=0x7f83468f7b08)
 
    at /home/openxs/git/server/sql/sql_connect.cc:1335
 
#14 0x00007f8343302ae4 in handle_one_connection (arg=0x7f83468f7b08)
 
    at /home/openxs/git/server/sql/sql_connect.cc:1241
 
#15 0x00007f834126e184 in start_thread (arg=0x7f833d3f6700)
 
    at pthread_create.c:312
 
#16 0x00007f834077b03d in clone ()
 
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

I think this is somewhat similar to MDEV-9414, but with other ODBC driver and database used.

 Comments   
Comment by Olivier Bertrand [ 2018-10-03 ]

On Windows after installing Informix and creating a 'Informix' DSN targetting the sysuser database for user informix, I could successfully create the table:

create table xuser
 
engine=CONNECT table_type=ODBC tabname=sysusers
 
connection='DSN=Informix';

No crash. The table was created as:

CREATE TABLE `xuser` (
 
  `username` char(32) DEFAULT NULL,
 
  `usertype` char(1) DEFAULT NULL,
 
  `priority` smallint(5) DEFAULT NULL,
 
  `password` char(16) DEFAULT NULL,
 
  `defrole` char(32) DEFAULT NULL
 
) ENGINE=CONNECT DEFAULT CHARSET=latin1 CONNECTION='DSN=Informix' `TABLE_TYPE`='ODBC' `TABNAME`='sysusers';

and

select * from xuser;

returned:

username usertype priority password defrole
informix D 9    
public C 5    

Now looking at your backtrace, I see that the TYPVAL<char>::SetValue_char function was called with its last parameter n=-1. This is very strange. this function is called from:

      for (n = 0, crp = qrp->Colresp; crp; n++, crp = crp->Next) {
 
	if (vlen[n] == SQL_NO_TOTAL)
 
	  ThrowDBX("Unexpected SQL_NO_TOTAL returned from SQLFetch");
 
	else if (vlen[n] == SQL_NULL_DATA)
 
          pval[n]->SetNull(true);
 
        else if (crp->Type == TYPE_STRING)
 
          pval[n]->SetValue_char(pbuf[n], (int)vlen[n]);
 
        else
 
          pval[n]->SetNull(false);
 
 
 
        crp->Kdata->SetValue(pval[n], i);
 
        cap->Vlen[n][i] = vlen[n];
 
        } // endfor crp

In the IF statement, this parameter is the value of 

vlen[n]

and when equal to -1 the TYPVAL<char>::SetValue_char function should not be called because SQL_NULL_DATA is defined to -1. The only way this could happen is if for some reason the value of SQL_NULL_DATA were different from -1 on your system.

I don't know whether you can check that on your system. Meanwhile I can't reproduce the error.

Generated at Thu Feb 08 08:35:49 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.