Olivier Bertrand added a comment - 2014-03-21 04:13 Hmmm... This is bizarre. The two tables t1 and t2 are defined on the same file, causing two kinds of rows to be written. Is that you really want to test? When updating, position writing is done by two threads on the same file with unexpected result and finally causing an assertion to fail. I know is should be fool proof and should no crash, but I need some more time to see what I can do.

Elena Stepanova added a comment - 2014-03-21 09:14 - edited The two tables t1 and t2 are defined on the same file, causing two kinds of rows to be written. Is that you really want to test? No, sorry, my bad, copy-paste error while finalizing the test case. (I mean, you are right, eventually it should be fixed for this bizarre configuration too, but it was not the point of the current report). Here is an updated one, the crash is the same: CREATE TABLE t1 (a INT , b CHAR (8)) ENGINE= CONNECT TABLE_TYPE=DOS FILE_NAME= 't1.dos' ; INSERT INTO t1 VALUES (1, 'foo' ),(2, 'bar' ); CREATE TABLE t2 (c CHAR (8), d INT ) ENGINE= CONNECT TABLE_TYPE=DOS FILE_NAME= 't2.dos' ; INSERT INTO t2 VALUES ( 'foo' ,1),( 'bar' ,2); UPDATE t1, t2 SET b = 'qux' , c = 'foobar' ; #3 <signal handler called> #4 0x00007f806e14ea5d in *__GI_fseek (fp=0x7f805a814580, offset=0, whence=2) at fseek.c:40 #5 0x00007f806cd5824c in DOSFAM::CloseTableFile (this=0x7f80564005e0, g=0x7f805ab62000) at 10.0/storage/connect/filamtxt.cpp:956 #6 0x00007f806cd69464 in TDBDOS::CloseDB (this=0x7f80564006a0, g=0x7f805ab62000) at 10.0/storage/connect/tabdos.cpp:901 #7 0x00007f806cd3e545 in CntCloseTable (g=0x7f805ab62000, tdbp=0x7f80564006a0) at 10.0/storage/connect/connect.cc:544 #8 0x00007f806cd31214 in ha_connect::CloseTable (this=0x7f805a94f888, g=0x7f805ab62000) at 10.0/storage/connect/ha_connect.cc:1305 #9 0x00007f806cd35d9b in ha_connect::external_lock (this=0x7f805a94f888, thd=0x7f8066b64070, lock_type=2) at 10.0/storage/connect/ha_connect.cc:3268 #10 0x00000000008685a0 in handler::ha_external_lock (this=0x7f805a94f888, thd=0x7f8066b64070, lock_type=2) at 10.0/sql/handler.cc:5843 #11 0x000000000093e98e in unlock_external (thd=0x7f8066b64070, table=0x7f805a859530, count=1) at 10.0/sql/lock.cc:671 #12 0x000000000093defb in mysql_unlock_tables (thd=0x7f8066b64070, sql_lock=0x7f805a8594f0, free_lock=true) at 10.0/sql/lock.cc:382 #13 0x0000000000610ac8 in close_thread_tables (thd=0x7f8066b64070) at 10.0/sql/sql_base.cc:993 #14 0x000000000067a92d in mysql_execute_command (thd=0x7f8066b64070) at 10.0/sql/sql_parse.cc:5175 #15 0x000000000067d66b in mysql_parse (thd=0x7f8066b64070, rawbuf=0x7f805a8f9088 "UPDATE t1, t2 SET b = 'qux', c = 'foobar'", length=41, parser_state=0x7f806e0e1610) at 10.0/sql/sql_parse.cc:6447 #16 0x0000000000670438 in dispatch_command (command=COM_QUERY, thd=0x7f8066b64070, packet=0x7f8062ab2071 "UPDATE t1, t2 SET b = 'qux', c = 'foobar'", packet_length=41) at 10.0/sql/sql_parse.cc:1308 #17 0x000000000066f7da in do_command (thd=0x7f8066b64070) at 10.0/sql/sql_parse.cc:1005 #18 0x0000000000789e8e in do_handle_one_connection (thd_arg=0x7f8066b64070) at 10.0/sql/sql_connect.cc:1379 #19 0x0000000000789be1 in handle_one_connection (arg=0x7f8066b64070) at 10.0/sql/sql_connect.cc:1293 #20 0x0000000000a2f190 in pfs_spawn_thread (arg=0x7f80626d0170) at 10.0/storage/perfschema/pfs.cc:1853 #21 0x00007f806fcb2b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #22 0x00007f806e1bda7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #23 0x0000000000000000 in ?? ()

Olivier Bertrand added a comment - 2014-03-22 01:05 This example is still unnatural. Multi table UPDATE commands are meant to modify a table with values from other tables and the tables must be joined in some way. Here it is just equivalent to doing to updates and probably more complicated to execute internally. However, it works!