Bug 1491833 - MariaDB server segfaults with select query
Summary: MariaDB server segfaults with select query
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: mariadb
Version: 7.4
Hardware: x86_64
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Michal Schorm
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 1551022 1584029
TreeView+ depends on / blocked
 
Reported: 2017-09-14 19:40 UTC by Jason
Modified: 2018-10-30 15:43 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1584029 (view as bug list)
Environment:
Last Closed: 2018-10-30 15:43:46 UTC


Attachments (Terms of Use)

Description Jason 2017-09-14 19:40:06 UTC
Description of problem:
MariaDB server segfaults when performing certain SELECT queries against the database.
This started after upgrading to version mariadb-server-5.5.56-2.el7.x86_64
Upgrading to version "MariaDB-5.5.57-centos7-x86_64-server.rpm" from MariaDB fixes the issue.
Here is the changelog for MariaDB for version 5.5.57. I assume one of these bug fixes remedied the issue.
https://mariadb.com/kb/en/library/mariadb-5557-changelog/

Version-Release number of selected component (if applicable):
mariadb-server-5.5.56-2.el7.x86_64


How reproducible:
Always and on different machines.


Steps to Reproduce:
1. Executing the attached query causes segfault every time
2.
3.

Actual results:
MariaDB segfaults 


Expected results:
MariaDB returns the information from the query :)


Additional info:
Changing to the RPM package MariaDB-5.5.57-centos7-x86_64-server.rpm from MariaDB fixes the issue.
------------------------------------------------------------------

Query that causes the segfault:
------------------------------------------------------------------
select `servers1`.`id` as `ID`, `servers1`.`name` as `Name`, `servers1`.`short_name` as `ShortName`, `servers1`.`serial_number` as `SerialNumber`, `servers1`.`created_by` as `CreatorID`, `servers1`.`preferences_id` as `PreferenceID`, `servers1`.`status_id` as `StatusID`, `servers1`.`order` as `Order`, `servers1`.`plan_id` as `PlanID`, `servers1`.`plan_users` as `PlanUsers`, `servers1`.`installed` as `Installed`, `servers1`.`allow_access` as `Accessible`, `servers1`.`visible` as `Visible`, `servers1`.`category` as `Category`, `servers1`.`updated_at` as `UpdatedAt`, `servers1`.`id` as `ID`, `servers1`.`preferences_id` as `PreferenceID` from `servers` as `servers1` where `servers1`.`id` in ('8165', '8166', '8807', '8917', '13274') having (servers1.id in (select d.server_id from ec_demo_servers as d, user_ec as s where (s.id=d.sales_id OR d.sales_id=0) and s.user_id=37717) OR servers1.id IN (select s.server_id from project_server as s, client_project as p, contact_targets as t, contact_target_departments as d where s.project_id=p.project_id and p.client_id=t.target_id and t.department_id=d.id and d.name='Sales' and t.contact_id=32385))


Crash Dump from the logfile
------------------------------------------------------------------

170914  9:50:46 [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 http://kb.askmonty.org/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: 5.5.56-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=62
max_threads=386
thread_count=4
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 977874 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x5652103fecc0
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 = 0x7f92dd555dc0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x5651fe36a96d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x5651fdf80285]
/lib64/libpthread.so.0(+0xf5e0)[0x7f959b3095e0]
/usr/libexec/mysqld(+0x3962ef)[0x5651fde742ef]
/usr/libexec/mysqld(_Z20get_best_combinationP4JOIN+0x35b)[0x5651fde7adcb]
/usr/libexec/mysqld(+0x3b73b3)[0x5651fde953b3]
/usr/libexec/mysqld(_ZN4JOIN8optimizeEv+0x675)[0x5651fde98625]
/usr/libexec/mysqld(_ZN13st_select_lex31optimize_unflattened_subqueriesEb+0xc8)[0x5651fde47b18]
/usr/libexec/mysqld(_ZN4JOIN8optimizeEv+0x1ec7)[0x5651fde99e77]
/usr/libexec/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0xc8)[0x5651fde9aae8]
/usr/libexec/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x2db)[0x5651fde9b5fb]
/usr/libexec/mysqld(+0x36b9d9)[0x5651fde499d9]
/usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x45d1)[0x5651fde54001]
/usr/libexec/mysqld(_ZN18Prepared_statement7executeEP6Stringb+0x3dd)[0x5651fde680cd]
/usr/libexec/mysqld(_ZN18Prepared_statement12execute_loopEP6StringbPhS2_+0xa8)[0x5651fde68218]
/usr/libexec/mysqld(_Z19mysqld_stmt_executeP3THDPcj+0x187)[0x5651fde68507]
/usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x966)[0x5651fde57b36]
/usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x5651fdf0a632]
/usr/libexec/mysqld(handle_one_connection+0x4a)[0x5651fdf0a6da]
/lib64/libpthread.so.0(+0x7e25)[0x7f959b301e25]
/lib64/libc.so.6(clone+0x6d)[0x7f9599aff34d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f9260034cb8): select `servers1`.`id` as `ID`, `servers1`.`name` as `Name`, `servers1`.`short_name` as `ShortName`, `servers1`.`serial_number` as `SerialNumber`, `servers1`.`created_by` as `CreatorID`,$
Connection ID (thread ID): 255922
Status: NOT_KILLED

Comment 2 Michal Schorm 2017-10-08 00:18:51 UTC
I went through the MariaDB changelog, however I was not able to distinguish the possible fix.

I'll assume this issue will be solved by rebase to >=5.5.57.

I tried to reproduce the issue, however, without data, I was NOT successful.
But I'll leave it there for later reproducer creation:

---


mysql -u root



create database REPRODUCER;
use REPRODUCER;

create table servers (id int, name int, short_name int, serial_number int, created_by int, preferences_id int, status_id int, `order` int, plan_id int, plan_users int, installed int, allow_access int, visible int, category int, updated_at int);
create table ec_demo_servers (sales_id int, server_id int);
create table user_ec (id int, user_id int);
create table project_server (server_id int, project_id int);
create table client_project (client_id int, project_id int);
create table contact_targets (target_id int, department_id int, contact_id int);
create table contact_target_departments (id int, name int);

select `servers1`.`id` as `ID`, `servers1`.`name` as `Name`, `servers1`.`short_name` as `ShortName`, `servers1`.`serial_number` as `SerialNumber`, `servers1`.`created_by` as `CreatorID`, `servers1`.`preferences_id` as `PreferenceID`, `servers1`.`status_id` as `StatusID`, `servers1`.`order` as `Order`, `servers1`.`plan_id` as `PlanID`, `servers1`.`plan_users` as `PlanUsers`, `servers1`.`installed` as `Installed`, `servers1`.`allow_access` as `Accessible`, `servers1`.`visible` as `Visible`, `servers1`.`category` as `Category`, `servers1`.`updated_at` as `UpdatedAt`, `servers1`.`id` as `ID`, `servers1`.`preferences_id` as `PreferenceID` from `servers` as `servers1` where `servers1`.`id` in ('8165', '8166', '8807', '8917', '13274') having (servers1.id in (select d.server_id from ec_demo_servers as d, user_ec as s where (s.id=d.sales_id OR d.sales_id=0) and s.user_id=37717) OR servers1.id IN (select s.server_id from project_server as s, client_project as p, contact_targets as t, contact_target_departments as d where s.project_id=p.project_id and p.client_id=t.target_id and t.department_id=d.id and d.name='Sales' and t.contact_id=32385));

Comment 3 Michal Schorm 2017-10-08 13:09:43 UTC
I  tried to add dummy data which return non-zero set. Unfortunatelly, still no crash reproduced.

---

mysql -u root

create database REPRODUCER;
use REPRODUCER;

create table servers (id int, name varchar(20), short_name varchar(20), serial_number int, created_by int, preferences_id int, status_id int, `order` int, plan_id int, plan_users int, installed int, allow_access int, visible int, category int, updated_at int);
create table user_ec (id int, user_id int);
create table ec_demo_servers (sales_id int, server_id int);
create table project_server (server_id int, project_id int);
create table client_project (client_id int, project_id int);
create table contact_targets (target_id int, department_id int, contact_id int);
create table contact_target_departments (id int, name varchar(20));

INSERT INTO servers values (1, "x", "x", 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1);
INSERT INTO servers values (8165, "x", "x", 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1);
INSERT INTO servers values (8166, "x", "x", 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1);
INSERT INTO servers values (8807, "x", "x", 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1);
INSERT INTO servers values (8917, "x", "x", 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1);
INSERT INTO servers values (13274, "x", "x", 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1);

INSERT INTO user_ec values (1, 1);
INSERT INTO user_ec values (2, 1);
INSERT INTO user_ec values (2, 37717);

INSERT INTO ec_demo_servers values (0, 10);
INSERT INTO ec_demo_servers values (1, 100);
INSERT INTO ec_demo_servers values (2, 1000);
INSERT INTO ec_demo_servers values (2, 8165);
INSERT INTO ec_demo_servers values (0, 8166);
INSERT INTO ec_demo_servers values (2, 8807);
INSERT INTO ec_demo_servers values (0, 8917);
INSERT INTO ec_demo_servers values (2, 13274);

INSERT INTO project_server values (8807, 1);
INSERT INTO project_server values (8807, 2);
INSERT INTO project_server values (8807, 3);
INSERT INTO project_server values (8807, 4);
INSERT INTO project_server values (8807, 5);

INSERT INTO client_project values (1, 1);
INSERT INTO client_project values (2, 1);
INSERT INTO client_project values (3, 1);
INSERT INTO client_project values (4, 1);

INSERT INTO contact_targets values (1, 1, 1);
INSERT INTO contact_targets values (1, 1, 32385);
INSERT INTO contact_targets values (1, 3, 32385);

INSERT INTO contact_target_departments values (1, "x");
INSERT INTO contact_target_departments values (1, "Sales");
INSERT INTO contact_target_departments values (2, "Sales");

select `servers1`.`id` as `ID`, `servers1`.`name` as `Name`, `servers1`.`short_name` as `ShortName`, `servers1`.`serial_number` as `SerialNumber`, `servers1`.`created_by` as `CreatorID`, `servers1`.`preferences_id` as `PreferenceID`, `servers1`.`status_id` as `StatusID`, `servers1`.`order` as `Order`, `servers1`.`plan_id` as `PlanID`, `servers1`.`plan_users` as `PlanUsers`, `servers1`.`installed` as `Installed`, `servers1`.`allow_access` as `Accessible`, `servers1`.`visible` as `Visible`, `servers1`.`category` as `Category`, `servers1`.`updated_at` as `UpdatedAt`, `servers1`.`id` as `ID`, `servers1`.`preferences_id` as `PreferenceID` from `servers` as `servers1` where `servers1`.`id` in ('8165', '8166', '8807', '8917', '13274') having (servers1.id in (select d.server_id from ec_demo_servers as d, user_ec as s where (s.id=d.sales_id OR d.sales_id=0) and s.user_id=37717) OR servers1.id IN (select s.server_id from project_server as s, client_project as p, contact_targets as t, contact_target_departments as d where s.project_id=p.project_id and p.client_id=t.target_id and t.department_id=d.id and d.name='Sales' and t.contact_id=32385));

Comment 4 Honza Horak 2017-10-10 10:37:06 UTC
Jason, are you able to provide more data to reproduce this, please?

Comment 5 Evert Nagel 2017-10-19 14:52:56 UTC
Not sure if this is the exact same bug, but it reproduces easily and is fixed with 5.5.57:
https://jira.mariadb.org/browse/MDEV-13180


Note You need to log in before you can comment on or make changes to this bug.