[MDEV-13356] 10.0.29 crashes on REGEXP with "(.|x)*" on certain conditions Created: 2017-07-19  Updated: 2017-07-20  Resolved: 2017-07-20

Status: Closed
Project: MariaDB Server
Component/s: OTHER
Affects Version/s: 10.0.24, 10.0.29
Fix Version/s: 10.1.24, 10.0.31, 10.2.7

Type: Bug Priority: Major
Reporter: Nicky Gerritsen Assignee: Sergei Golubchik
Resolution: Duplicate Votes: 0
Labels: None
Environment:

Ubuntu Xenial (16.04)

Attachments: Zip Archive core.zip     File my.cnf    
Issue Links:
Duplicate
is duplicated by MDEV-12420 pcre stack overflow on match Closed
Relates
relates to MDEV-13173 An RLIKE that previously worked on 10... Closed

 Description   

On at least MariaDB server 10.0.24 and 10.0.29 I can let the MariaDB server crash with a simple REGEXP query.

Use the following table:

CREATE TABLE `dummy` (
 
  `id` int(11) NOT NULL AUTO_INCREMENT,
 
  `info` longtext NOT NULL,
 
  PRIMARY KEY (`id`)
 
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

With the following content:

INSERT INTO `dummy` (`id`, `info`) VALUES 
	(1,'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa');

Now execute the following query:

SELECT * FROM dummy WHERE info REGEXP '(.|a)*';

This will result in MySQL crashing everytime. (note: we actually used (.|[\n\s])* in our code but I simplified it a bit here)

Some things I have already noticed:

  • It does not happen if you make the string in the info column 1 character shorter (i.e. it seems to only happen with 241 characters and up). The exact contents of the string does not seem to matter, as long as it is at least 241 characters long.
  • It also happens if you change the info column to a varchar(255) or any other text column.

My my.cnf is attached, as well as a core dump (created with MariaDB 10.0.29-MariaDB-0ubuntu0.16.04.1 on Ubuntu 16.04).

The stack trace for the core dump is:

#0  0x00007fb0782aadfa in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
 
#1  0x00007fb0782b8fec in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
 
#2  0x00007fb0782ab16a in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
 
#3  0x00007fb0782b8fec in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
 
#4  0x00007fb0782ab16a in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
 
#5  0x00007fb0782b8fec in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
 
#6  0x00007fb0782ab16a in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
 
#7  0x00007fb0782b8fec in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
 
#8  0x00007fb0782ab16a in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
 
[... more of these lines...]
 
#481 0x00007fb0782b8fec in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
 
#482 0x00007fb0782ab16a in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
 
#483 0x00007fb0782ad06e in ?? () from /lib/x86_64-linux-gnu/libpcre.so.3
 
#484 0x00007fb0782bc903 in pcre_exec () from /lib/x86_64-linux-gnu/libpcre.so.3
 
#485 0x0000000000780f69 in Regexp_processor_pcre::exec(String*, int, unsigned int) ()
 
#486 0x00000000007811a1 in Regexp_processor_pcre::exec(Item*, int, unsigned int) ()
 
#487 0x00000000007811e4 in Item_func_regex::val_int() ()
 
#488 0x00000000005f5aa1 in ?? ()
 
#489 0x00000000006015d9 in sub_select(JOIN*, st_join_table*, bool) ()
 
#490 0x000000000060cf2d in ?? ()
 
#491 0x0000000000620bbc in JOIN::exec_inner() ()
 
#492 0x0000000000622761 in JOIN::exec() ()
 
#493 0x000000000061f34e in 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*) ()
 
#494 0x000000000061fcc2 in handle_select(THD*, LEX*, select_result*, unsigned long) ()
 
#495 0x00000000005bbfda in ?? ()
 
#496 0x00000000005cb31f in mysql_execute_command(THD*) ()
 
#497 0x00000000005cccda in mysql_parse(THD*, char*, unsigned int, Parser_state*) ()
 
#498 0x00000000005ce4de in dispatch_command(enum_server_command, THD*, char*, unsigned int) ()
 
#499 0x000000000069e92b in do_handle_one_connection(THD*) ()
 
#500 0x000000000069e989 in handle_one_connection ()
 
#501 0x00007fb077c456ba in start_thread (arg=0x7fb078a85700) at pthread_create.c:333
 
#502 0x00007fb0772f03dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

If I need to supply anything else please let me know!

 Comments   
Comment by Nicky Gerritsen [ 2017-07-19 ]

The current 10.2 packages from the MariaDB repo (version 10.2.7+maria~xenial as of writing) does not seem to have this issue by the way, but there it seems the regex does not match any results, which I think it should do.

Comment by Sergei Golubchik [ 2017-07-20 ]

It's pcre stack overflow when recursion goes too deep. A duplicate of MDEV-12420, that was fixed in 10.0.31

It doesn't match the result with a warning "recursion too deep". We prevent stack overflow by limiting recursion depth. In 10.0.31 the limit was 100, always the same. In 10.0.32 it'll depend on the available stack size (usually, about 500 with default settings on x86-64).

Generated at Thu Feb 08 08:04:58 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.