[MDEV-15184] mysqld crashes with Signal 11 (Is it because of semijoin_nests ??) Created: 2018-02-02 Updated: 2018-03-07 Resolved: 2018-03-07 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Optimizer |
| Affects Version/s: | 10.0.17 |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Major |
| Reporter: | Vijay Chenji | Assignee: | Alice Sherepa |
| Resolution: | Incomplete | Votes: | 0 |
| Labels: | crash | ||
| Environment: |
Database server – CentOS release 6.8 (Final) |
||
| Attachments: |
|
| Description |
|
mysqld is crashing multiple times with Signal 11. The log.error file did not capture any SQL statement at the time of the crash. The same following entries are seen for every crash: Thread pointer: 0x0x7fe6f8f93008 |
| Comments |
| Comment by Daniel Black [ 2018-02-03 ] | ||||||
|
I had a look and despite the age of 10.0.17 it seems very little that I can see has been changed in the vicinity of https://github.com/MariaDB/server/blob/mariadb-galera-10.0.17/sql/opt_subselect.cc#L2203. As you indicated a query would be really helpful as would the 'SHOW CREATE TABLE {tablenames}' and 'SHOW INDEXES FROM {tablesnames}' and a my.cnf file. If you get a core dump and using gdb can you extract the following:
| ||||||
| Comment by Vijay Chenji [ 2018-02-05 ] | ||||||
|
Thank you Daniel for your quick response. Is there an already compiled debugged version of mysqld available which we can use straightaway? | ||||||
| Comment by Daniel Black [ 2018-02-05 ] | ||||||
|
Seems like there's no debuginfo packages (https://jira.mariadb.org/browse/MDEV-12508?focusedCommentId=97056), or debug packages MDEV-13027 yet. How to enable core enabling at runtime see MDEV-13126. Maybe its worth trying the latest version 10.0-galera version at least on one node and see if its reproducible there, I might have missed something looking at its staticly. Note to save your galera rpm package if you have it - seems binary rpm are missing from the archiving scripts | ||||||
| Comment by Vijay Chenji [ 2018-02-09 ] | ||||||
|
Hi Daniel, I was trying to compile mariadb for debugging : These are the steps I was following and the cmake failed to configure. The steps: Installed mariadb 10.0.17 in virtual box centos6. created a build directory beside my source directory /usr/local/ GENERIC BUILD INSTRUCTIONS: [root@vb-nwe build-mariadb]# cmake . -DBUILD_CONFIG=mysql_release -DRPM=centos6 CMake Error: CMAKE_Fortran_COMPILER not set, after EnableLanguage – Configuring incomplete, errors occurred! | ||||||
| Comment by Daniel Black [ 2018-02-10 ] | ||||||
|
cmake has to be run passing the directory of the mariadb source. This can be obtained with {{git clone --single-branch --branch 10.0-galera https://github.com/MariaDB/server.git]] or downloading a mariadb-galera the source tarball from http://archive.mariadb.org/. More instructions see: | ||||||
| Comment by Vijay Chenji [ 2018-02-14 ] | ||||||
|
Hi Daniel, – Installed the source code of mariadb-10.0.17 55/55 Test #55: dbug .............................***Failed 0.00 sec 98% tests passed, 1 tests failed out of 55 Total Test time (real) = 138.14 sec The following tests FAILED: ========= By the way, I was able to run ./scripts/mysql_install_db --defaults-file=./my.cnf and created the system databases 'mysql' and 'performance schema', and also started mysql using ./bin/mysqld_safe --defaults-file=./my.cnf. Please suggest what I can do to get through the debug test. | ||||||
| Comment by Alice Sherepa [ 2018-03-07 ] | ||||||
|
Is it possible for you to find out what query is causing the crash, is it reproducible, how often do you get it? | ||||||
| Comment by Vijay Chenji [ 2018-03-07 ] | ||||||
|
As there was no particular query available that would have caused the multiple crashes, I tried to reproduce the crash by using quite a few queries gathered from the file "log.slowquery". These queries have multiple joins and create temp tables and can apply considerable stress on the database. I ran such queries simultaneously from multiple sessions, but none of these complicated queries could bring down the database and on the contrary all of them got successfully executed after running for a longer than average execution time in real time production.. I did all of these on a virtual box with no real time application connections since I am not supposed to test anything on the production server. Simply to say, I could not reproduce the crash using any of the stress queries. As an alternate solution, we edited the values of these variables in the my.cnf and since then we did not have any more crashes. Not sure if these changes or the application behavior resolved it : Changed from: to this::
You may go ahead and close the ticket. Thanks to you and Daniel for all your suggestions and time. | ||||||
| Comment by Vijay Chenji [ 2018-03-07 ] | ||||||
|
In the above post, the comment out sign # got changed to numbers 1 and 2. These lines were actually commented out in the my.cnf : Commnted out "optimizer_switch='mrr=on'" and commented out optimizer_switch='mrr_sort_keys=on #optimizer_switch='mrr=on' | ||||||
| Comment by Alice Sherepa [ 2018-03-07 ] | ||||||
|
I close it, but if you get some info what/why was that crash, please write) |