[MDEV-13173] An RLIKE that previously worked on 10.0 now returns "Got error 'pcre_exec: recursion limit of 100 exceeded' from regexp" Created: 2017-06-26  Updated: 2017-08-14  Resolved: 2017-07-20

Status: Closed
Project: MariaDB Server
Component/s: OTHER, Server
Affects Version/s: 10.1.24, 10.0.31
Fix Version/s: 10.1.26, 10.0.32, 10.2.8

Type: Bug Priority: Major
Reporter: Rich Theobald Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: contribution, foundation
Environment:

Ubuntu 14.04


Issue Links:
Relates
relates to MDEV-13356 10.0.29 crashes on REGEXP with "(.|x)... Closed

 Description   

The PCRE recursion limit has apparently decreased in 10.1. There is no way to increase this limit through configuration.

eg:

MariaDB [10_1_sandbox]> SELECT CONCAT(REPEAT('100,',98),'101') RLIKE '^(([1-9][0-9]*),)*[1-9][0-9]*$' TEST;
+------+
| TEST |
+------+
|    1 |
+------+
1 row in set (0.02 sec)
 
MariaDB [10_1_sandbox]> SELECT CONCAT(REPEAT('100,',99),'101') RLIKE '^(([1-9][0-9]*),)*[1-9][0-9]*$' TEST;
+------+
| TEST |
+------+
|    0 |
+------+
1 row in set, 1 warning (0.02 sec)
 
MariaDB [sandbox]> show warnings;
+---------+------+--------------------------------------------------------------------+
| Level   | Code | Message                                                            |
+---------+------+--------------------------------------------------------------------+
| Warning | 1139 | Got error 'pcre_exec: recursion limit of 100 exceeded' from regexp |
+---------+------+--------------------------------------------------------------------+
1 row in set (0.15 sec)

In 10.0:

MariaDB [10_0_sandbox]> SELECT CONCAT(REPEAT('100,',99),'101') RLIKE '^(([1-9][0-9]*),)*[1-9][0-9]*$' TEST;
+------+
| TEST |
+------+
|    1 |
+------+
1 row in set (0.14 sec)



 Comments   
Comment by Elena Stepanova [ 2017-06-26 ]

The difference in behavior is reproducible, it was introduced by this revision:

commit d672f88ef73e3fc566a382600968c3e51249de1a
Author: Daniel Black <grooverdan@users.sourceforge.net>
Date:   Sat Apr 8 22:47:56 2017 +1000
 
    MDEV-12420: PCRE stack overflow

I will leave it to danblack and serg to decide whether this particular effect was desirable.

Comment by Sergei Golubchik [ 2017-06-26 ]

Not desirable, it's a bug.

Comment by Daniel Black [ 2017-06-27 ]

So Regexp_processor_pcre::set_recursion_limit(THD *) was added however never called and hence the default 100L being used. Would this need to be called by fix_fields (which has a THD arg)?

Few commits are relevant commits d672f88ef73e3fc566a382600968c3e51249de1a..52aa200919b1fd9357c05bcdfc66a42e51f242b3

Comment by Daniel Black [ 2017-07-04 ]

https://github.com/grooverdan/mariadb-server/tree/10.0-MDEV-13173-pcre_exec-100-limit

Comment by Rich Theobald [ 2017-08-14 ]

It looks like the limit was not increased enough.

The warning on 10.1.26 is now:

MariaDB [test]> SELECT CONCAT(REPEAT('0,1,21,',99),'101') RLIKE '^([0-9]+,)*[0-9]+$' TEST;
+------+
| TEST |
+------+
|    0 |
+------+
1 row in set, 1 warning (0.01 sec)
 
MariaDB [test]> show warnings;
+---------+------+--------------------------------------------------------------------+
| Level   | Code | Message                                                            |
+---------+------+--------------------------------------------------------------------+
| Warning | 1139 | Got error 'pcre_exec: recursion limit of 519 exceeded' from regexp |
+---------+------+--------------------------------------------------------------------+
1 row in set (0.00 sec)

This works on 10.0.28

MariaDB [staging]> SELECT CONCAT(REPEAT('0,1,21,',99),'101') RLIKE '^([0-9]+,)*[0-9]+$' TEST;
+------+
| TEST |
+------+
|    1 |
+------+
1 row in set (0.18 sec)

Is this configurable?

Comment by Sergei Golubchik [ 2017-08-14 ]

Yes, it's automatically detected based on your stack size (thread stack size divided by prce frame size, minus some safety margin), few more levels of recursion would've crashed your server.

Increase thread stack — that should help. See the --thread-stack option.

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