[MDEV-22684] 10.4.13 crashes when creating CHECK constraint Created: 2020-05-24  Updated: 2020-05-26  Resolved: 2020-05-25

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table
Affects Version/s: 10.4.13
Fix Version/s: 10.5.4, 10.4.14

Type: Bug Priority: Major
Reporter: Petr Skoda Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None

Attachments: File install_check.sql    
Issue Links:
Duplicate
duplicates MDEV-22563 Segfault on duplicate free of Item_f... Closed
Relates
relates to MDEV-22563 Segfault on duplicate free of Item_f... Closed

 Description   

The following sample SQL code crashes MariaDB using offical docker image mariadb:10.4.13, it worked fine with mariadb:10.4.12.

SET SESSION sql_mode = 'STRICT_ALL_TABLES,ANSI_QUOTES';
 
 
 
CREATE TABLE test1 (
 
    id BIGINT(10) NOT NULL auto_increment,
 
    col1 TINYINT(1) NOT NULL,
 
    col2 TINYINT(1) NOT NULL,
 
    col3 TINYINT(1) NOT NULL,
 
    CONSTRAINT PRIMARY KEY (id)
 
);
 
 
 
ALTER TABLE test1 ADD CONSTRAINT "test1_col3_constraint" CHECK (col3 IN (0,1));
 
ALTER TABLE test1 ADD CONSTRAINT `test1_col2_constraint` CHECK (col2 IN (0,1));
 
ALTER TABLE test1 ADD CONSTRAINT test1_col1_constraint CHECK (col1 IN (0,1));

The same problem pops up with mariadb:10.5.3 sometimes too, but it does not seem to be fully reproducible. I am using OSX docker, but my colleagues managed to reproduce it in Linux too.

mariadb:10.3.23 is working fine.

 Comments   
Comment by Elena Stepanova [ 2020-05-24 ]

Is there a coredump or a failure report in the log with any parts of a stack trace at all? And if so, do they resemble this in any way?

READ of size 8 at 0x61d0000431a8 thread T31
 
    #0 0x55739bb96611 in Item_func_in::cleanup() /data/src/10.4-bug/sql/item_cmpfunc.h:2414
 
    #1 0x55739b1df94d in Item::delete_self() /data/src/10.4-bug/sql/item.h:2182
 
    #2 0x55739b1df94d in Query_arena::free_items() /data/src/10.4-bug/sql/sql_class.cc:3779
 
    #3 0x55739b1e5739 in THD::cleanup_after_query() /data/src/10.4-bug/sql/sql_class.cc:2279
 
    #4 0x55739b2d9d5b in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /data/src/10.4-bug/sql/sql_parse.cc:7923
 
    #5 0x55739b2dfdba in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /data/src/10.4-bug/sql/sql_parse.cc:1842
 
    #6 0x55739b2e3626 in do_command(THD*) /data/src/10.4-bug/sql/sql_parse.cc:1360
 
    #7 0x55739b5527f7 in do_handle_one_connection(CONNECT*) /data/src/10.4-bug/sql/sql_connect.cc:1412
 
    #8 0x55739b552a1a in handle_one_connection /data/src/10.4-bug/sql/sql_connect.cc:1316
 
    #9 0x7f640da974a3 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x74a3)
 
    #10 0x7f640bbcbd0e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xe8d0e)

I got the above using your test case on a local build of 10.4.13 with release configuration + ASAN enabled, which makes me think you are encountering the problem reported in MDEV-22563. I couldn't reproduce it with your test in the docker container, but it means nothing, as failures of this kind are notoriously intermittent.

Comment by Petr Skoda [ 2020-05-24 ]

This is what the "docker logs" says:

Thread pointer: 0x7f15f4000c08
 
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 = 0x7f166026add8 thread_stack 0x49000
 
mysqld(my_print_stacktrace+0x2e)[0x55aeff9a8e8e]
 
mysqld(handle_fatal_signal+0x515)[0x55aeff424915]
 
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f166737a890]
 
mysqld(_ZN12Item_func_in7cleanupEv+0x37)[0x55aeff54b267]
 
mysqld(_ZN11Query_arena10free_itemsEv+0x2d)[0x55aeff1cac2d]
 
mysqld(_ZN3THD19cleanup_after_queryEv+0x11b)[0x55aeff1ccb4b]
 
mysqld(_Z11mysql_parseP3THDPcjP12Parser_statebb+0x25b)[0x55aeff21d02b]
 
mysqld(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0x16d5)[0x55aeff21f705]
 
mysqld(_Z10do_commandP3THD+0x104)[0x55aeff220bb4]
 
mysqld(_Z24do_handle_one_connectionP7CONNECT+0x25e)[0x55aeff2fd23e]
 
mysqld(handle_one_connection+0x3d)[0x55aeff2fd2fd]
 
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76db)[0x7f166736f6db]
 
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f1665d9188f]
 
 
 
Trying to get some variables.
 
Some pointers may be invalid and cause the dump to abort.
 
Query (0x7f15f4013040): ALTER TABLE test1 ADD CONSTRAINT `test1_col2_constraint` CHECK (col2 IN (0,1))
 
Connection ID (thread ID): 8
 
Status: NOT_KILLED

Is there anywhere else I can look for logs? Or is there any build I could test in relation to MDEV-22563?

I'll attach SQL with real commands that triggered the problem originally for multiple people in our company.

In any case thanks for the feedback.

Comment by Elena Stepanova [ 2020-05-24 ]

Thanks, this is sufficient. The stack trace in your log is clearly the same, and I've also checked that at least on my build the patch for MDEV-22563 stops your test cases from failing (both the short one from the description and the long one from the attachment).

Yes, it would be great if you could check it on your side as well. Unfortunately, we don't seem to have OSX builds, but if you or your colleagues can check on Linux or build from sources, you can find the source tarball and the variety of Linux binaries here: http://hasky.askmonty.org/archive/10.4/build-32907/

Comment by Petr Skoda [ 2020-05-24 ]

Thanks Elena, I'll find somebody to test it on Linux today.

Comment by Petr Skoda [ 2020-05-25 ]

I can confirm MariaDB built using "git checkout 10.4" now appears to work again, thanks a lot, I think this issue can be closed now.

Comment by Elena Stepanova [ 2020-05-25 ]

Thanks for checking.

Closing as fixed by the patch for MDEV-22563.

Comment by Dave dV [ 2020-05-26 ]

Sorry for piggybacking on this issue, but it seems related, so I was hoping someone could check whether it's been fixed with this or I need to log a new issue:

I am getting crashes on 10.4.13+maria~stretch whenever trying to alter columns of a table that contains a CHECK constraint. The alter command seems to go through, and the modification is there when the DB is back up:

CREATE TABLE `test` (
 
  `foo` tinyint(1) DEFAULT 0,
 
  CONSTRAINT `CONSTRAINT_1` CHECK (`foo` in (0,1))
 
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 
 
 
SET check_constraint_checks=0; # does not affect either way…
 
 
 
ALTER TABLE `test` ADD COLUMN `bar` FLOAT;
 
 
 
# → crashes (but column `bar` is created)
 
 
 
ALTER TABLE `test` DROP CONSTRAINT `CONSTRAINT_1`;
 
ALTER TABLE `test` ADD COLUMN `baz` FLOAT;
 
 
 
# → no crash

Using Docker versions, I confirmed I get a crash (of the whole container, actually) with 10.4.13, but 10.5 seems OK.

Comment by Petr Skoda [ 2020-05-26 ]

Hi Dave, the statements from your comment executed fine for me with the patch present.

Comment by Dave dV [ 2020-05-26 ]

Petr, thanks for checking!
Good news then. I'll hold off on posting an issue until I can double-check on the next version (bit short on time right now to install from git).

Any chance you could confirm that you do get the crash with the same version pre-patch (just so I can rule out some exotic platform-related issue).

Comment by Petr Skoda [ 2020-05-26 ]

yes, crashing without the patch:

totaradb> CREATE TABLE `test` (
 
                                  `foo` tinyint(1) DEFAULT 0,
 
                                  CONSTRAINT `CONSTRAINT_1` CHECK (`foo` in (0,1))
 
          ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
 
[2020-05-27 08:59:22] completed in 13 ms
 
totaradb> SET check_constraint_checks=0
 
[2020-05-27 08:59:22] completed in 2 ms
 
totaradb> ALTER TABLE `test` ADD COLUMN `bar` FLOAT
 
[2020-05-27 08:59:22] [08000] (conn=9) unexpected end of stream, read 0 bytes from 4 (socket was closed by server)
 
[2020-05-27 08:59:22] java.io.EOFException: unexpected end of stream, read 0 bytes from 4 (socket was closed by server)

Generated at Thu Feb 08 09:16:39 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.