Re: [Maria-developers] failing tests
Hi Olivier, Vladislav, Please have a look into MDEV-9739 Assertion `m_status == DA_ERROR || m_status == DA_OK' failed in Diagnostics_area::message() ; connect.xml* tests fail in buildbot The crash appeared after this commit by Vladislav: commit 3a24f1cf8426409a69619982e84ca498d581f8a1 Author: Vladislav Vaintroub <vvaintroub@googlemail.com> Date: Mon Feb 22 12:48:03 2016 +0100 MDEV-9307 - provide info about DATA/INDEX directory in INFORMATION_SCHEMA.TA BLES (in CREATE_OPTIONS column) Vladislav thinks that the actual problem resides in the ConnectSE code, in a wrong use of my_error(). Can you please take over the problem from this point? Thanks. On 03/21/2016 12:54 PM, Alexander Barkov wrote:
Hi Olivier,
On 03/20/2016 02:10 AM, Olivier Bertrand wrote:
Hello Alexander,
Le 19/03/2016 14:59, Alexander Barkov a écrit :
Hi Olivier,
On 03/19/2016 02:18 AM, Olivier Bertrand wrote:
Hello Alexander,
I went into linux ubuntu and pass the tests but all XML tests were skipped saying "need libxml2". However I could check was libxml2 was installed indeed. Don't know what to do next. Please make sure that libxml2-dev is installed. It was not and I installed it. However it did not change anything.
Please make sure to remove CMakeCache.txt and run cmake again from scratch. Does this help?
The problem is that libxml2 is not recognized as installed when compiling Connect and then the XML type is not available. (trying to create an XML table fails saying "invalid table type")
Btw, how do the tests fail and for what reason?
For some reasons it crashes in DEBUG build when doing this query:
SELECT count(*) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='test' AND TABLE_NAME='t1' AND ENGINE='CONNECT' AND CREATE_OPTIONS LIKE '%`table_type`=XML%' AND CREATE_OPTIONS LIKE '%xmlsup=libxml2%'
with this stack trace:
sql/sql_error.h:705(Diagnostics_area::message() const)[0x563787dda10a] sql/sql_select.cc:2669(JOIN::exec_inner())[0x563787dd97b5] sql/sql_select.cc:3453(mysql_select(THD*, Item***, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*))[0x563787ddcd1b] sql/sql_select.cc:384(handle_select(THD*, LEX*, select_result*, unsigned long))[0x563787dd2811] sql/sql_parse.cc:5936(execute_sqlcom_select)[0x563787da2ae4] sql/sql_parse.cc:2962(mysql_execute_command(THD*))[0x563787d98625] sql/sql_parse.cc:7336(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x563787da615d] sql/sql_parse.cc:1490(dispatch_command(enum_server_command, THD*, char*, unsigned int))[0x563787d94846] sql/sql_parse.cc:1109(do_command(THD*))[0x563787d93576] sql/sql_connect.cc:1349(do_handle_one_connection(THD*))[0x563787ec8a6c] sql/sql_connect.cc:1262(handle_one_connection)[0x563787ec87bb] perfschema/pfs.cc:1862(pfs_spawn_thread)[0x56378827a1da] /lib64/libpthread.so.0(+0x760a)[0x7f427b8aa60a] /lib64/libc.so.6(clone+0x6d)[0x7f427959fa4d]
Can you please try to compile a DEBUG version on Linux and check if you get the same problem?
In the meanwhile I'll try to find the commit which caused this problem.
Thanks.
Olivier
Le 18/03/2016 14:46, Alexander Barkov a écrit :
Hello Olivier,
a few tests are failing in the main 10.1 tree on Linux:
connect.xml connect.xml_grant connect.xml_html connect.xml_mdev5261 connect.xml_mult
Can you please have a look?
Thanks!
Hi, Alexander! I've fixed it two days ago. On Mar 21, Alexander Barkov wrote:
Hi Olivier, Vladislav,
Please have a look into
MDEV-9739 Assertion `m_status == DA_ERROR || m_status == DA_OK' failed in Diagnostics_area::message() ; connect.xml* tests fail in buildbot
The crash appeared after this commit by Vladislav:
commit 3a24f1cf8426409a69619982e84ca498d581f8a1 Author: Vladislav Vaintroub <vvaintroub@googlemail.com> Date: Mon Feb 22 12:48:03 2016 +0100 MDEV-9307 - provide info about DATA/INDEX directory in INFORMATION_SCHEMA.TABLES (in CREATE_OPTIONS column)
Vladislav thinks that the actual problem resides in the ConnectSE code, in a wrong use of my_error().
Can you please take over the problem from this point?
Thanks.
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Hi, Sergei, When you said you fixed it, was it in some ConnectSE code? Note that countless problems already occured because of this infamous assert. Regards, Olivier Le 21/03/2016 13:00, Sergei Golubchik a écrit :
Hi, Alexander!
I've fixed it two days ago.
On Mar 21, Alexander Barkov wrote:
Hi Olivier, Vladislav,
Please have a look into
MDEV-9739 Assertion `m_status == DA_ERROR || m_status == DA_OK' failed in Diagnostics_area::message() ; connect.xml* tests fail in buildbot
The crash appeared after this commit by Vladislav:
commit 3a24f1cf8426409a69619982e84ca498d581f8a1 Author: Vladislav Vaintroub <vvaintroub@googlemail.com> Date: Mon Feb 22 12:48:03 2016 +0100 MDEV-9307 - provide info about DATA/INDEX directory in INFORMATION_SCHEMA.TABLES (in CREATE_OPTIONS column)
Vladislav thinks that the actual problem resides in the ConnectSE code, in a wrong use of my_error().
Can you please take over the problem from this point?
Thanks.
Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Hi, Olivier! On Mar 21, Olivier Bertrand wrote:
Hi, Sergei,
When you said you fixed it, was it in some ConnectSE code?
No, in sql_show.cc. When the error happened in that function, the expectation was that there was my_error() with the error message. But handler::info() only returns an error code. This is my fix: https://github.com/MariaDB/server/commit/a1782b4
Note that countless problems already occured because of this infamous assert.
The assert means that some code didn't issue an error as it was expected to. Or that some code issued an error and it was later ignored and mariadb tried to report a success for a failed statement. This can, indeed, occur for many reasons, that's why this assert fails often. Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Hi Sergei, In response to a feature request (see MDEV-9765) I have developed a first version of a JDBC table type for CONNECT. Directly calling JDBC drivers from C++ seems difficult. JDBC drivers are designed to be called from Java applications and the issue is that the JDBC API can have parameters or return Java classes or objects. In addition they often throw Java Exceptions. From C++, Java code can be called using the JNI interface but handling the above problems is combersome. This is why, at least in a first version, I have written a Java class (JdbcInterface) that calls JDBC functions with proper objects and takes care of Exceptions. CONNECT uses JNI to call this intermediate class. How can this be distributed? The Java JdbcInterface.class must be accessible in the CLASSPATH that is defined when installing JDBC drivers. When compiling MariaDB, this means also that the source file JdbcInterface.java must be compiled along with the rest of the CONNECT source files. I have no idea on how this can be achieved. Regards, Olivier
participants (3)
-
Alexander Barkov -
Olivier Bertrand -
Sergei Golubchik