Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Duplicate
-
10.0(EOL), 10.1(EOL), 10.2(EOL)
-
None
Description
@@ -155,7 +155,7 @@
|
CREATE TABLE total (v BIGINT(20) UNSIGNED NOT NULL) ENGINE=CONNECT TABLE_TYPE=TBL TABLE_LIST='t1,t2' OPTION_LIST='thread=yes,port=PORT';;
|
SELECT * FROM total order by v desc;
|
v
|
-22
|
+11
|
11
|
DROP TABLE total;
|
DROP TABLE t1;
|
@@ -156,7 +156,7 @@
|
SELECT * FROM total order by v desc;
|
v
|
22
|
-11
|
+22
|
DROP TABLE total;
|
DROP TABLE t1;
|
DROP TABLE t2;
|
@@ -155,8 +155,8 @@
|
CREATE TABLE total (v BIGINT(20) UNSIGNED NOT NULL) ENGINE=CONNECT TABLE_TYPE=TBL TABLE_LIST='t1,t2' OPTION_LIST='thread=yes,port=PORT';;
|
SELECT * FROM total order by v desc;
|
v
|
-22
|
-11
|
+21
|
+21
|
DROP TABLE total;
|
DROP TABLE t1;
|
DROP TABLE t2;
|
Attachments
Issue Links
- blocks
-
MDEV-7069 Fix buildbot failures in main server trees
-
- Stalled
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
Activity
I've never had this failure on my local machines either, but we see it every now and then in buildbot. It happened on your trees too once or twice, although quite long ago.
So, I suppose the best that can be done is to push the fix into your tree and see how it goes.
reproduced on ppc64le - Ubuntu Xential-16.04 CMAKE_BUILD_TYPE=Debug
12:51:57 connect.tbl w20 [ fail ]
|
12:51:57 Test ended at 2016-06-21 02:51:57
|
12:51:57
|
12:51:57 CURRENT_TEST: connect.tbl
|
12:51:57 --- /source/storage/connect/mysql-test/connect/r/tbl.result 2016-06-21 02:31:14.803252182 +0000
|
12:51:57 +++ /source/storage/connect/mysql-test/connect/r/tbl.reject 2016-06-21 02:51:56.942168747 +0000
|
12:51:57 @@ -155,7 +155,7 @@
|
12:51:57 CREATE TABLE total (v BIGINT(20) UNSIGNED NOT NULL) ENGINE=CONNECT TABLE_TYPE=TBL TABLE_LIST='t1,t2' OPTION_LIST='thread=yes,port=PORT';;
|
12:51:57 SELECT * FROM total order by v desc;
|
12:51:57 v
|
12:51:57 -22
|
12:51:57 +11
|
12:51:57 11
|
12:51:57 DROP TABLE total;
|
12:51:57 DROP TABLE t1;
|
12:51:57
|
12:51:57 mysqltest: Result content mismatch
|
I pushed the fix on my tree but don't know whether it is distributed yet.
What I am waiting for is to see if the bug still occurs when the fix is included.
| Description |
http://buildbot.askmonty.org/buildbot/builders/kvm-bintar-quantal-x86/builds/4208/steps/test/logs/stdio
{noformat} @@ -155,7 +155,7 @@ CREATE TABLE total (v BIGINT(20) UNSIGNED NOT NULL) ENGINE=CONNECT TABLE_TYPE=TBL TABLE_LIST='t1,t2' OPTION_LIST='thread=yes,port=PORT';; SELECT * FROM total order by v desc; v -22 +11 11 DROP TABLE total; DROP TABLE t1; {noformat} http://buildbot.askmonty.org/buildbot/builders/kvm-deb-precise-amd64/builds/6333/steps/test_5/logs/stdio {noformat} @@ -156,7 +156,7 @@ SELECT * FROM total order by v desc; v 22 -11 +22 DROP TABLE total; DROP TABLE t1; DROP TABLE t2; {noformat} http://buildbot.askmonty.org/buildbot/builders/kvm-deb-trusty-amd64/builds/2812/steps/test_5/logs/stdio {noformat} @@ -155,8 +155,8 @@ CREATE TABLE total (v BIGINT(20) UNSIGNED NOT NULL) ENGINE=CONNECT TABLE_TYPE=TBL TABLE_LIST='t1,t2' OPTION_LIST='thread=yes,port=PORT';; SELECT * FROM total order by v desc; v -22 -11 +21 +21 DROP TABLE total; DROP TABLE t1; DROP TABLE t2; {noformat} |
http://buildbot.askmonty.org/buildbot/builders/kvm-bintar-quantal-x86/builds/4208/steps/test/logs/stdio
{noformat} @@ -155,7 +155,7 @@ CREATE TABLE total (v BIGINT(20) UNSIGNED NOT NULL) ENGINE=CONNECT TABLE_TYPE=TBL TABLE_LIST='t1,t2' OPTION_LIST='thread=yes,port=PORT';; SELECT * FROM total order by v desc; v -22 +11 11 DROP TABLE total; DROP TABLE t1; {noformat} http://buildbot.askmonty.org/buildbot/builders/kvm-deb-precise-amd64/builds/6333/steps/test_5/logs/stdio {noformat} @@ -156,7 +156,7 @@ SELECT * FROM total order by v desc; v 22 -11 +22 DROP TABLE total; DROP TABLE t1; DROP TABLE t2; {noformat} http://buildbot.askmonty.org/buildbot/builders/kvm-deb-trusty-amd64/builds/2812/steps/test_5/logs/stdio {noformat} @@ -155,8 +155,8 @@ CREATE TABLE total (v BIGINT(20) UNSIGNED NOT NULL) ENGINE=CONNECT TABLE_TYPE=TBL TABLE_LIST='t1,t2' OPTION_LIST='thread=yes,port=PORT';; SELECT * FROM total order by v desc; v -22 -11 +21 +21 DROP TABLE total; DROP TABLE t1; DROP TABLE t2; {noformat} {color:red}*The test has been added to disabled.def. Remove it from the list when both this problem and |
| Description |
http://buildbot.askmonty.org/buildbot/builders/kvm-bintar-quantal-x86/builds/4208/steps/test/logs/stdio
{noformat} @@ -155,7 +155,7 @@ CREATE TABLE total (v BIGINT(20) UNSIGNED NOT NULL) ENGINE=CONNECT TABLE_TYPE=TBL TABLE_LIST='t1,t2' OPTION_LIST='thread=yes,port=PORT';; SELECT * FROM total order by v desc; v -22 +11 11 DROP TABLE total; DROP TABLE t1; {noformat} http://buildbot.askmonty.org/buildbot/builders/kvm-deb-precise-amd64/builds/6333/steps/test_5/logs/stdio {noformat} @@ -156,7 +156,7 @@ SELECT * FROM total order by v desc; v 22 -11 +22 DROP TABLE total; DROP TABLE t1; DROP TABLE t2; {noformat} http://buildbot.askmonty.org/buildbot/builders/kvm-deb-trusty-amd64/builds/2812/steps/test_5/logs/stdio {noformat} @@ -155,8 +155,8 @@ CREATE TABLE total (v BIGINT(20) UNSIGNED NOT NULL) ENGINE=CONNECT TABLE_TYPE=TBL TABLE_LIST='t1,t2' OPTION_LIST='thread=yes,port=PORT';; SELECT * FROM total order by v desc; v -22 -11 +21 +21 DROP TABLE total; DROP TABLE t1; DROP TABLE t2; {noformat} {color:red}*The test has been added to disabled.def. Remove it from the list when both this problem and |
http://buildbot.askmonty.org/buildbot/builders/kvm-bintar-quantal-x86/builds/4208/steps/test/logs/stdio
{noformat} @@ -155,7 +155,7 @@ CREATE TABLE total (v BIGINT(20) UNSIGNED NOT NULL) ENGINE=CONNECT TABLE_TYPE=TBL TABLE_LIST='t1,t2' OPTION_LIST='thread=yes,port=PORT';; SELECT * FROM total order by v desc; v -22 +11 11 DROP TABLE total; DROP TABLE t1; {noformat} http://buildbot.askmonty.org/buildbot/builders/kvm-deb-precise-amd64/builds/6333/steps/test_5/logs/stdio {noformat} @@ -156,7 +156,7 @@ SELECT * FROM total order by v desc; v 22 -11 +22 DROP TABLE total; DROP TABLE t1; DROP TABLE t2; {noformat} http://buildbot.askmonty.org/buildbot/builders/kvm-deb-trusty-amd64/builds/2812/steps/test_5/logs/stdio {noformat} @@ -155,8 +155,8 @@ CREATE TABLE total (v BIGINT(20) UNSIGNED NOT NULL) ENGINE=CONNECT TABLE_TYPE=TBL TABLE_LIST='t1,t2' OPTION_LIST='thread=yes,port=PORT';; SELECT * FROM total order by v desc; v -22 -11 +21 +21 DROP TABLE total; DROP TABLE t1; DROP TABLE t2; {noformat} |
I have tried some more elaborate tests but was not able to reproduce this bug.
However, I noted that one variable was set and tested by different threads. I have added a mutex protection to avoid possible issues caused by this.
Not being able to reproduce, I cannot say that this will fix the bug. This will have to be tested when next releases will contain that change.
the test was moved to connect.tbl_thread in 10.2, but it fails just the same
What do you mean "just the same"?
In connect.tbl_thread there are two parts:
The first one tests using a THREAD TBL table against several servers. Until recently, it always failed on Linux saying "table rt3 does not exist". Because of this, the second part that is the copy of the THREAD test of the previous TBL test is never executed.
That was the one that sometimes failed (rarely) on some platforms. It resulted in a wrong result being returned causing in a result length mismatch.
Did you fix the first part failure and have the second part failing?
Yes. First part is fixed here: https://github.com/MariaDB/server/commit/158f96f6e30 (see also all other CONNECT tests that use TABLE_TYPE=MYSQL). Second part fails here: https://buildbot.askmonty.org/buildbot/builders/kvm-fulltest/builds/9846/steps/test_3/logs/stdio
Ok thanks. Note that the second part has two tests and only the second one failed.
Now I see what is the probable cause of it:
Simultaneous execution of several queries cannot be done on the same server. This is why the local tables are currenly not executed simultaneously. However, the same must be also done on remote servers.
I shall work on this and propose a fix.
| Link |
This issue relates to |
| Status | Open [ 1 ] | In Progress [ 3 ] |
connect.tbl_thread w2 [ fail ]
|
Test ended at 2017-10-30 10:23:20
|
CURRENT_TEST: connect.tbl_thread
|
mysqltest: At line 60: query 'SELECT * FROM total order by a desc' failed: 2013: Lost connection to MySQL server during query
|
|
|
The result from queries just before the failure was:
|
< snip >
|
CONNECTION='mysql://root@127.0.0.1:SLAVE_PORT/test/rt4';
|
SELECT * FROM t4;
|
a b
|
12 test12
|
13 test13
|
14 test14
|
15 test15
|
CREATE TABLE t5 ENGINE=CONNECT TABLE_TYPE=MYSQL
|
CONNECTION='mysql://root@127.0.0.1:SLAVE_PORT/test/rt5';
|
SELECT * FROM t5;
|
a b
|
16 test16
|
17 test17
|
18 test18
|
19 test19
|
CREATE TABLE total (a int, b char(10))
|
ENGINE=CONNECT TABLE_TYPE=TBL TABLE_LIST='t1,t2,t3,t4,t5'
|
OPTION_LIST='thread=yes,port=PORT';
|
set connect_xtrace=1;
|
SELECT * FROM total order by a desc;
|
|
|
More results from queries before failure can be found in /home/alice/aliska/10.2/mysql-test/var/2/log/tbl_thread.log
|
|
|
|
|
Server [mysqld.1 - pid: 21335, winpid: 21335, exit: 256] failed during test run
|
Server log from this test:
|
----------SERVER LOG START-----------
|
New CONNECT 0x7f6c780dcd80, table: total
|
Delete CONNECT 0x7f6c780dcd80, table: <null>, xp=(nil) count=0
|
New CONNECT 0x7f6c780de1b0, table: total
|
open: name=./test/total mode=2 test=18
|
external_lock: this=0x7f6c780de1b0 thd=0x7f6c78000a98 xp=0x7f6c78074550 g=0x7f6c78062c10 lock_type=0
|
0x7f6c780de1b0 check_mode: cmdtype=0
|
Cmd=SELECT * FROM total order by a desc
|
New mode=10
|
Calling CntCheckDB db=test cras=0
|
external_lock: rc=0
|
0x7f6c780de1b0 In info: flag=18 valid_info=0
|
XTAB: making new TABLE total (null)
|
XTAB: making new TABLE t1 (null)
|
TBL: Name=t1 db=test
|
XTAB: making new TABLE t2 (null)
|
TBL: Name=t2 db=test
|
Linking tables t1... to t2
|
XTAB: making new TABLE t3 (null)
|
TBL: Name=t3 db=test
|
Linking tables t1... to t3
|
XTAB: making new TABLE t4 (null)
|
TBL: Name=t4 db=test
|
Linking tables t1... to t4
|
XTAB: making new TABLE t5 (null)
|
TBL: Name=t5 db=test
|
Linking tables t1... to t5
|
rnd_init: this=0x7f6c780de1b0 scan=1 xmod=10 alter=0
|
ColDB: am=115 colname=a tabname=total num=0
|
cdp(1).Name=a cp=(nil)
|
making new PRXCOL C1 a at 0x7f6c7ffff4f0
|
colp=0x7f6c7ffff4f0
|
ColDB: am=115 colname=b tabname=total num=0
|
cdp(2).Name=b cp=(nil)
|
making new PRXCOL C2 b at 0x7f6c7ffff570
|
colp=0x7f6c7ffff570
|
TBM OpenDB: tdbp=0x7f6c7ffff3d8 tdb=R1707 use=0 key=(nil) mode=10
|
making copy TABLE t1 <null>
|
Subtable t1 in ./test/
|
ColDB: am=190 colname=a tabname=t1 num=0
|
cdp(1).Name=a cp=(nil)
|
making new MYSQLCOL C1 a at 0x7f6c7ffffb90
|
colp=0x7f6c7ffffb90
|
ColDB: am=190 colname=b tabname=t1 num=0
|
cdp(2).Name=b cp=(nil)
|
making new MYSQLCOL C2 b at 0x7f6c7ffffc58
|
colp=0x7f6c7ffffc58
|
making copy TABLE t2 <null>
|
New CONNECT 0x7f6c78101500, table: t2
|
Delete CONNECT 0x7f6c78101500, table: <null>, xp=(nil) count=0
|
Subtable t2 in ./test/
|
ColDB: am=190 colname=a tabname=t2 num=0
|
cdp(1).Name=a cp=(nil)
|
making new MYSQLCOL C1 a at 0x7f6c80000278
|
colp=0x7f6c80000278
|
ColDB: am=190 colname=b tabname=t2 num=0
|
cdp(2).Name=b cp=(nil)
|
making new MYSQLCOL C2 b at 0x7f6c80000340
|
colp=0x7f6c80000340
|
Linking tables t1... to t2
|
making copy TABLE t3 <null>
|
New CONNECT 0x7f6c78101500, table: t3
|
Delete CONNECT 0x7f6c78101500, table: <null>, xp=(nil) count=0
|
Subtable t3 in ./test/
|
ColDB: am=190 colname=a tabname=t3 num=0
|
cdp(1).Name=a cp=(nil)
|
making new MYSQLCOL C1 a at 0x7f6c80000960
|
colp=0x7f6c80000960
|
ColDB: am=190 colname=b tabname=t3 num=0
|
cdp(2).Name=b cp=(nil)
|
making new MYSQLCOL C2 b at 0x7f6c80000a28
|
colp=0x7f6c80000a28
|
Linking tables t1... to t3
|
making copy TABLE t4 <null>
|
New CONNECT 0x7f6c78101500, table: t4
|
Delete CONNECT 0x7f6c78101500, table: <null>, xp=(nil) count=0
|
Subtable t4 in ./test/
|
ColDB: am=190 colname=a tabname=t4 num=0
|
cdp(1).Name=a cp=(nil)
|
making new MYSQLCOL C1 a at 0x7f6c80001048
|
colp=0x7f6c80001048
|
ColDB: am=190 colname=b tabname=t4 num=0
|
cdp(2).Name=b cp=(nil)
|
making new MYSQLCOL C2 b at 0x7f6c80001110
|
colp=0x7f6c80001110
|
Linking tables t1... to t4
|
making copy TABLE t5 <null>
|
New CONNECT 0x7f6c78101500, table: t5
|
Delete CONNECT 0x7f6c78101500, table: <null>, xp=(nil) count=0
|
Subtable t5 in ./test/
|
ColDB: am=190 colname=a tabname=t5 num=0
|
cdp(1).Name=a cp=(nil)
|
making new MYSQLCOL C1 a at 0x7f6c80001730
|
colp=0x7f6c80001730
|
ColDB: am=190 colname=b tabname=t5 num=0
|
cdp(2).Name=b cp=(nil)
|
making new MYSQLCOL C2 b at 0x7f6c800017f8
|
colp=0x7f6c800017f8
|
Linking tables t1... to t5
|
=====> Local table t1
|
=====> Local table t2
|
=====> New remote table t3
|
=====> New remote table t4
|
=====> New remote table t5
|
ThreadOpen: Thd=2013268632
|
ColDB: am=190 colname=a tabname=t1 num=0
|
cdp(1).Name=a cp=0x7f6c7ffffb90
|
colp=0x7f6c7ffffb90
|
MYSQLC Open: m_DB=6C0008C8 size=1272
|
ColDB: am=190 colname=b tabname=t1 num=0
|
ThreadOpen: Thd=2013268632
|
cdp(2).Name=b cp=0x7f6c7ffffc58
|
colp=0x7f6c7ffffc58
|
ThreadOpen: Thd=2013268632
|
MYSQLC Open: m_DB=700008C8 size=1272
|
Opening subtable t1
|
MYSQLC Open: m_DB=680008C8 size=1272
|
MYSQLC Open: m_DB=78101098 size=1272
|
Query=SELECT `a`, `b` FROM `rt4`
|
Query=SELECT `a`, `b` FROM `t1`
|
Query=SELECT `a`, `b` FROM `rt5`
|
Query=SELECT `a`, `b` FROM `rt3`
|
ExecSQL: m_Res=781038C8 size=152 m_Fields=2 m_Rows=4
|
MYSQLC Close: m_DB=78101098
|
MySQL CloseDB: closing t1 rc=0
|
ColDB: am=190 colname=a tabname=t2 num=0
|
cdp(1).Name=a cp=0x7f6c80000278
|
colp=0x7f6c80000278
|
ColDB: am=190 colname=b tabname=t2 num=0
|
cdp(2).Name=b cp=0x7f6c80000340
|
colp=0x7f6c80000340
|
Opening subtable t2
|
MYSQLC Open: m_DB=78101098 size=1272
|
ExecSQL: m_Res=6800BA68 size=152 m_Fields=2 m_Rows=0
|
Table t5 ready
|
ExecSQL: m_Res=6C00BA68 size=152 m_Fields=2 m_Rows=4
|
Table t4 ready
|
ExecSQL: m_Res=7000BA68 size=152 m_Fields=2 m_Rows=4
|
Table t3 ready
|
Query=SELECT `a`, `b` FROM `rt2`
|
ExecSQL: m_Res=781038D8 size=152 m_Fields=2 m_Rows=4
|
MYSQLC Close: m_DB=78101098
|
MySQL CloseDB: closing t2 rc=0
|
ColDB: am=190 colname=a tabname=t3 num=0
|
cdp(1).Name=a cp=0x7f6c80000960
|
colp=0x7f6c80000960
|
ColDB: am=190 colname=b tabname=t3 num=0
|
cdp(2).Name=b cp=0x7f6c80000a28
|
colp=0x7f6c80000a28
|
Reading subtable t3
|
MYSQLC Close: m_DB=700008C8
|
MySQL CloseDB: closing t3 rc=0
|
ColDB: am=190 colname=a tabname=t4 num=0
|
cdp(1).Name=a cp=0x7f6c80001048
|
colp=0x7f6c80001048
|
ColDB: am=190 colname=b tabname=t4 num=0
|
cdp(2).Name=b cp=0x7f6c80001110
|
colp=0x7f6c80001110
|
Reading subtable t4
|
MYSQLC Close: m_DB=6C0008C8
|
MySQL CloseDB: closing t4 rc=0
|
ColDB: am=190 colname=a tabname=t5 num=0
|
cdp(1).Name=a cp=0x7f6c80001730
|
colp=0x7f6c80001730
|
ColDB: am=190 colname=b tabname=t5 num=0
|
cdp(2).Name=b cp=0x7f6c800017f8
|
colp=0x7f6c800017f8
|
Reading subtable t5
|
171030 10:23:15 [ERROR] 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.
|
|
|
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
|
|
|
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.
|
|
|
Server version: 10.2.10-MariaDB-debug-log
|
key_buffer_size=1048576
|
read_buffer_size=131072
|
max_used_connections=4
|
max_threads=153
|
thread_count=5
|
It is possible that mysqld could use up to
|
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 63152 K bytes of memory
|
Hope that's ok; if not, decrease some variables in the equation.
|
|
|
Thread pointer: 0x7f6c78000a98
|
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...
|
stack_bottom = 0x7f6ca0495e70 thread_stack 0x49000
|
/home/alice/aliska/10.2/sql/mysqld(my_print_stacktrace+0x38)[0x55a5c74944df]
|
/home/alice/aliska/10.2/sql/mysqld(handle_fatal_signal+0x3a3)[0x55a5c6d25d62]
|
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f6ca8e77390]
|
/home/alice/aliska/10.2/mysql-test/var/2/plugins/ha_connect.so(_ZN6PRXCOL10ReadColumnEP7_global+0x5d)[0x7f6ca3560149]
|
/home/alice/aliska/10.2/mysql-test/var/2/plugins/ha_connect.so(_ZN6COLBLK4EvalEP7_global+0xba)[0x7f6ca34f3348]
|
/home/alice/aliska/10.2/mysql-test/var/2/plugins/ha_connect.so(_Z11EvalColumnsP7_globalP3TDBbb+0xc4)[0x7f6ca34e7caf]
|
/home/alice/aliska/10.2/mysql-test/var/2/plugins/ha_connect.so(_Z11CntReadNextP7_globalP3TDB+0x11c)[0x7f6ca34e7e95]
|
/home/alice/aliska/10.2/mysql-test/var/2/plugins/ha_connect.so(_ZN10ha_connect8rnd_nextEPh+0xb0)[0x7f6ca34db438]
|
/home/alice/aliska/10.2/sql/mysqld(_ZN7handler11ha_rnd_nextEPh+0x16d)[0x55a5c6d2c969]
|
/home/alice/aliska/10.2/sql/mysqld(+0x816aa8)[0x55a5c6d21aa8]
|
/home/alice/aliska/10.2/sql/mysqld(_Z8filesortP3THDP5TABLEP8FilesortP16Filesort_trackerP4JOINy+0x8a5)[0x55a5c6d20063]
|
/home/alice/aliska/10.2/sql/mysqld(_Z17create_sort_indexP3THDP4JOINP13st_join_tableP8Filesort+0x300)[0x55a5c6b2dfb5]
|
/home/alice/aliska/10.2/sql/mysqld(_ZN13st_join_table10sort_tableEv+0x102)[0x55a5c6b289ba]
|
/home/alice/aliska/10.2/sql/mysqld(_Z21join_init_read_recordP13st_join_table+0x61)[0x55a5c6b28604]
|
/home/alice/aliska/10.2/sql/mysqld(_Z10sub_selectP4JOINP13st_join_tableb+0x281)[0x55a5c6b265ca]
|
/home/alice/aliska/10.2/sql/mysqld(+0x61abc0)[0x55a5c6b25bc0]
|
/home/alice/aliska/10.2/sql/mysqld(_ZN4JOIN10exec_innerEv+0xac1)[0x55a5c6b006d1]
|
/home/alice/aliska/10.2/sql/mysqld(_ZN4JOIN4execEv+0xcc)[0x55a5c6affb72]
|
/home/alice/aliska/10.2/sql/mysqld(_Z12mysql_selectP3THDP10TABLE_LISTjR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x2f3)[0x55a5c6b00d42]
|
/home/alice/aliska/10.2/sql/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x15f)[0x55a5c6af55db]
|
/home/alice/aliska/10.2/sql/mysqld(+0x5b656c)[0x55a5c6ac156c]
|
/home/alice/aliska/10.2/sql/mysqld(_Z21mysql_execute_commandP3THD+0x18f9)[0x55a5c6ab72c2]
|
/home/alice/aliska/10.2/sql/mysqld(_Z11mysql_parseP3THDPcjP12Parser_statebb+0x2a2)[0x55a5c6ac4ee5]
|
/home/alice/aliska/10.2/sql/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0xfee)[0x55a5c6ab2bb2]
|
/home/alice/aliska/10.2/sql/mysqld(_Z10do_commandP3THD+0x700)[0x55a5c6ab1509]
|
/home/alice/aliska/10.2/sql/mysqld(_Z24do_handle_one_connectionP7CONNECT+0x1ca)[0x55a5c6bfe97e]
|
/home/alice/aliska/10.2/sql/mysqld(handle_one_connection+0x30)[0x55a5c6bfe6fe]
|
/home/alice/aliska/10.2/sql/mysqld(+0xa4f256)[0x55a5c6f5a256]
|
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7f6ca8e6d6ba]
|
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f6ca83023dd]
|
|
|
Trying to get some variables.
|
Some pointers may be invalid and cause the dump to abort.
|
Query (0x7f6c780fe550): SELECT * FROM total order by a desc
|
Connection ID (thread ID): 1705
|
Status: NOT_KILLED
|
Thread 1 (Thread 0x7f6ca0496700 (LWP 21358)):
|
#0 __pthread_kill (threadid=<optimized out>, signo=11) at ../sysdeps/unix/sysv/linux/pthread_kill.c:62
|
#1 0x000055a5c74945d1 in my_write_core (sig=11) at /home/alice/aliska/10.2/mysys/stacktrace.c:477
|
#2 0x000055a5c6d2610e in handle_fatal_signal (sig=11) at /home/alice/aliska/10.2/sql/signal_handler.cc:303
|
#3 <signal handler called>
|
#4 0x00007f6ca3560149 in PRXCOL::ReadColumn (this=0x7f6c7ffff4f0, g=0x7f6c78062c10) at /home/alice/aliska/10.2/storage/connect/tabutil.cpp:739
|
#5 0x00007f6ca34f3348 in COLBLK::Eval (this=0x7f6c7ffff4f0, g=0x7f6c78062c10) at /home/alice/aliska/10.2/storage/connect/colblk.cpp:140
|
#6 0x00007f6ca34e7caf in EvalColumns (g=0x7f6c78062c10, tdbp=0x7f6c7ffff3d8, reset=false, mrr=false) at /home/alice/aliska/10.2/storage/connect/connect.cc:396
|
#7 0x00007f6ca34e7e95 in CntReadNext (g=0x7f6c78062c10, tdbp=0x7f6c7ffff3d8) at /home/alice/aliska/10.2/storage/connect/connect.cc:445
|
#8 0x00007f6ca34db438 in ha_connect::rnd_next (this=0x7f6c780de1b0, buf=0x7f6c78071dc0 "") at /home/alice/aliska/10.2/storage/connect/ha_connect.cc:4000
|
#9 0x000055a5c6d2c969 in handler::ha_rnd_next (this=0x7f6c780de1b0, buf=0x7f6c78071dc0 "") at /home/alice/aliska/10.2/sql/handler.cc:2576
|
#10 0x000055a5c6d21aa8 in find_all_keys (thd=0x7f6c78000a98, param=0x7f6ca0493960, select=0x7f6c78092760, fs_info=0x7f6c78100840, buffpek_pointers=0x7f6ca0493b60, tempfile=0x7f6ca04939f0, pq=0x0, found_rows=0x7f6c78100a20) at /home/alice/aliska/10.2/sql/filesort.cc:788
|
#11 0x000055a5c6d20063 in filesort (thd=0x7f6c78000a98, table=0x7f6c780dd618, filesort=0x7f6c78092960, tracker=0x7f6c7809c908, join=0x7f6c7808f0c0, first_table_bit=1) at /home/alice/aliska/10.2/sql/filesort.cc:279
|
#12 0x000055a5c6b2dfb5 in create_sort_index (thd=0x7f6c78000a98, join=0x7f6c7808f0c0, tab=0x7f6c7807df50, fsort=0x7f6c78092960) at /home/alice/aliska/10.2/sql/sql_select.cc:21704
|
#13 0x000055a5c6b289ba in st_join_table::sort_table (this=0x7f6c7807df50) at /home/alice/aliska/10.2/sql/sql_select.cc:19539
|
#14 0x000055a5c6b28604 in join_init_read_record (tab=0x7f6c7807df50) at /home/alice/aliska/10.2/sql/sql_select.cc:19480
|
#15 0x000055a5c6b265ca in sub_select (join=0x7f6c7808f0c0, join_tab=0x7f6c7807df50, end_of_records=false) at /home/alice/aliska/10.2/sql/sql_select.cc:18575
|
#16 0x000055a5c6b25bc0 in do_select (join=0x7f6c7808f0c0, procedure=0x0) at /home/alice/aliska/10.2/sql/sql_select.cc:18122
|
#17 0x000055a5c6b006d1 in JOIN::exec_inner (this=0x7f6c7808f0c0) at /home/alice/aliska/10.2/sql/sql_select.cc:3483
|
#18 0x000055a5c6affb72 in JOIN::exec (this=0x7f6c7808f0c0) at /home/alice/aliska/10.2/sql/sql_select.cc:3278
|
#19 0x000055a5c6b00d42 in mysql_select (thd=0x7f6c78000a98, tables=0x7f6c7804d440, wild_num=1, fields=..., conds=0x0, og_num=1, order=0x7f6c780774e0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7f6c780fdb10, unit=0x7f6c78004638, select_lex=0x7f6c78004d90) at /home/alice/aliska/10.2/sql/sql_select.cc:3678
|
#20 0x000055a5c6af55db in handle_select (thd=0x7f6c78000a98, lex=0x7f6c78004570, result=0x7f6c780fdb10, setup_tables_done_option=0) at /home/alice/aliska/10.2/sql/sql_select.cc:373
|
#21 0x000055a5c6ac156c in execute_sqlcom_select (thd=0x7f6c78000a98, all_tables=0x7f6c7804d440) at /home/alice/aliska/10.2/sql/sql_parse.cc:6420
|
#22 0x000055a5c6ab72c2 in mysql_execute_command (thd=0x7f6c78000a98) at /home/alice/aliska/10.2/sql/sql_parse.cc:3454
|
#23 0x000055a5c6ac4ee5 in mysql_parse (thd=0x7f6c78000a98, rawbuf=0x7f6c780fe550 "SELECT * FROM total order by a desc", length=35, parser_state=0x7f6ca04951f0, is_com_multi=false, is_next_command=false) at /home/alice/aliska/10.2/sql/sql_parse.cc:7861
|
#24 0x000055a5c6ab2bb2 in dispatch_command (command=COM_QUERY, thd=0x7f6c78000a98, packet=0x7f6c78007f49 "", packet_length=35, is_com_multi=false, is_next_command=false) at /home/alice/aliska/10.2/sql/sql_parse.cc:1805
|
#25 0x000055a5c6ab1509 in do_command (thd=0x7f6c78000a98) at /home/alice/aliska/10.2/sql/sql_parse.cc:1360
|
#26 0x000055a5c6bfe97e in do_handle_one_connection (connect=0x55a5ca648158) at /home/alice/aliska/10.2/sql/sql_connect.cc:1354
|
#27 0x000055a5c6bfe6fe in handle_one_connection (arg=0x55a5ca648158) at /home/alice/aliska/10.2/sql/sql_connect.cc:1260
|
#28 0x000055a5c6f5a256 in pfs_spawn_thread (arg=0x55a5ca6f9098) at /home/alice/aliska/10.2/storage/perfschema/pfs.cc:1863
|
#29 0x00007f6ca8e6d6ba in start_thread (arg=0x7f6ca0496700) at pthread_create.c:333
|
#30 0x00007f6ca83023dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
|
|
|
***Warnings generated in error logs during shutdown after running tests: connect.tbl_thread
|
|
|
171030 10:23:15 [ERROR] mysqld got signal 11 ;
|
Attempting backtrace. You can use the following information to find out
|
|
|
connect.tbl_thread w2 [ pass ] 83
|
***Warnings generated in error logs during shutdown after running tests: connect.tbl_thread
|
|
|
mysqld: /home/alice/aliska/10.2/sql/mysqld.cc:4059: void my_malloc_size_cb_func(long long int, my_bool): Assertion `(longlong) thd->status_var.local_memory_used >= 0 || !debug_assert_on_not_freed_memory' failed.
|
Attempting backtrace. You can use the following information to find out
|
|
connect.tbl_thread [ fail ]
|
Test ended at 2017-10-30 10:30:20
|
|
|
CURRENT_TEST: connect.tbl_thread
|
--- /10.2/storage/connect/mysql-test/connect/r/tbl_thread.result 2017-10-27 11:03:38.740520711 +0200
|
+++ /10.2/storage/connect/mysql-test/connect/r/tbl_thread.reject 2017-10-30 10:30:19.890060929 +0100
|
@@ -94,14 +94,6 @@
|
18 test18
|
17 test17
|
16 test16
|
-15 test15
|
-14 test14
|
-13 test13
|
-12 test12
|
-11 test11
|
-10 test10
|
-9 test09
|
-8 test08
|
7 test07
|
6 test06
|
5 test05
|
|
|
mysqltest: Result length mismatch
|
|
| Link |
This issue relates to |
On which platform and using which MariaDB version did you get these results?
FYI: a last fix about thread TBL tables was pushed on August 27. Any version dating prior to this is prone to be buggy. Of course, this does not make sure that latest versions are not buggy.
This is a difficult problem since I was never able to reproduce it on any of my machines.
If it is clear that this table type is still buggy, the only fix will be to have the thread feature removed.
sorry, forgot to write about it. I tested on Ubuntu 16.04, 10.2.10-MariaDB-debug, commit b94a62b5dfa48; --repeat=200
I got his today with latest 10.2.12:
CURRENT_TEST: connect.tbl_thread
— /usr/local/mariadb-10.2.12-linux-i686/mysql-test/plugin/connect/connect/r/tbl_thread.result 2018-01-02 13:30:39.000000000 +0000
+++ /usr/local/mariadb-10.2.12-linux-i686/mysql-test/plugin/connect/connect/r/tbl_thread.reject 2018-01-02 14:07:46.835927257 +0000
@@ -90,17 +90,17 @@
set connect_xtrace=1;
SELECT * FROM total order by a desc;
a b
-19 test19
-18 test18
-17 test17
-16 test16
15 test15
14 test14
13 test13
12 test12
11 test11
+11 test11
+10 test10
10 test10
9 test09
+9 test09
+8 test08
8 test08
7 test07
6 test06
This is in buildbot on kvm-bintar-trusty-x86 (note 32 bit)
When running "mysql-test-run --repeat=100 connect.tbl_thread" I got after a while:
CURRENT_TEST: connect.tbl_thread
mysqltest: At line 60: query 'SELECT * FROM total order by a desc' failed: 1296: Got error 174 '(1064) You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '' at line 1 [SELECT ]' from CONNECT
More information that I hope is helpful:
CURRENT_TEST: connect.tbl_thread
mysqltest: At line 60: query 'SELECT * FROM total order by a desc' failed: 1296: Got error 122 '(1064) You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '`, `b` FROM `rt3``, `b` FROM `rt2`' at line 1 [SELECT `S' from CONNECT
In the mysqld.1.
In var/log/connect.tbl_thread/mysqld.1/mysqld.log I found the following
that may explain the problem:
697 Query CREATE TABLE total (a int, b char(10))
ENGINE=CONNECT TABLE_TYPE=TBL TABLE_LIST='t1,t2,t3,t4,t5'
OPTION_LIST='thread=yes,port=16040'
697 Query set connect_xtrace=1
697 Query SELECT * FROM total order by a desc
701 Connect root@localhost as anonymous on test
701 Query SELECT `a`, `b` FROM `t1`
701 Quit
702 Connect root@localhost as anonymous on test
702 Query SELECT `SELECT `a`, `b` FROM `rt3``, `b` FROM `rt2`
702 Quit
The problem is probably the extra SELECT` that was added first in the query.
When the above test goes right, then it log file looks like:
4 Query CREATE TABLE total (a int, b char(10))
ENGINE=CONNECT TABLE_TYPE=TBL TABLE_LIST='t1,t2,t3,t4,t5'
OPTION_LIST='thread=yes,port=16040'
4 Query set connect_xtrace=1
4 Query SELECT * FROM total order by a desc
8 Connect root@localhost as anonymous on test
8 Query SELECT `a`, `b` FROM `t1`
8 Quit
9 Connect root@localhost as anonymous on test
9 Query SELECT `a`, `b` FROM `rt2`
9 Quit
So it's clear that the problem is the extra garbage in front the query or
alternative connect things that the name of the first column is
"SELECT `a`, `b` FROM `rt3`"
After looking at how the query is generated in TDBMYSQL::MakeSelect()
I am inclined to think that the problem is that the field name somehow
gets wrong if the table object is used many times.
While running tests in a loop, I also got an error at:
#4 0x0000000000bd09e6 in STRING::GetNext (this=0x7fb150001ad0)
at /my/maria-10.2/storage/connect/xobject.h:153
153
(gdb) p G
$1 = (PGLOBAL) 0x20606260202c6061
(gdb) p G->Sarea
Cannot access memory at address 0x20606260202c6061
This could also mean that you have a memory overrun somewhere 
| issue.field.resolutiondate | 2018-01-04 16:41:16.0 | 2018-01-04 16:41:16.288 |
| Fix Version/s | N/A [ 14700 ] | |
| Fix Version/s | 10.2 [ 14601 ] | |
| Fix Version/s | 10.0 [ 16000 ] | |
| Fix Version/s | 10.1 [ 16100 ] | |
| Resolution | Duplicate [ 3 ] | |
| Status | In Progress [ 3 ] | Closed [ 6 ] |
| Workflow | MariaDB v3 [ 75897 ] | MariaDB v4 [ 150483 ] |
Elena, I found an error that could possibly explain this bug but cannot check it because I was never able to reproduce it.
Could you make this change in TDBTBM::ResetDB in file tabtbl.cpp line 601:
/***********************************************************************//* Reset read/write position values. *//***********************************************************************/void TDBTBM::ResetDB(void){for (PCOL colp = Columns; colp; colp = colp->GetNext())if (colp->GetAmType() == TYPE_AM_TABID)colp->COLBLK::Reset();// Local tablesfor (PTABLE tabp = Tablist; tabp; tabp = tabp->GetNext())((PTDBASE)tabp->GetTo_Tdb())->ResetDB();// Remote tablesfor (PTBMT tp = Tmp; tp; tp = tp->Next)((PTDBASE)tp->Tap->GetTo_Tdb())->ResetDB();Tdbp = (Tablist) ? (PTDBASE)Tablist->GetTo_Tdb() : NULL;Crp = 0;} // end of ResetDBAnd test if it fixes your error.
Thanks.