php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #81185 preg_match fails to match while it seemingly should
Submitted: 2021-06-21 11:35 UTC Modified: 2021-07-04 04:22 UTC
Votes:3
Avg. Score:4.7 ± 0.5
Reproduced:3 of 3 (100.0%)
Same Version:3 (100.0%)
Same OS:2 (66.7%)
From: hans at reachdigital dot nl Assigned:
Status: No Feedback Package: PCRE related
PHP Version: 7.4.20 OS: macOS Big Sur
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: hans at reachdigital dot nl
New email:
PHP Version: OS:

 

 [2021-06-21 11:35 UTC] hans at reachdigital dot nl 
Description:
------------
While debugging an issue (within Magento), I stumbled upon a case where preg_match() is giving an unexpected result compared to previous PHP versions.

In our case a given pattern is matching two particular strings on older PHP versions, but fails to match one of them in PHP 7.4.16 (as well as PHP 8.0.6)

Please refer to the test script I've added, which when run with PHP 7.4.16 indicates that the pattern matches both strings, but when run with PHP 7.4.20 indicates that only one string matches.

Interestingly, putting something like '.+' at the beginning of the pattern makes it work as expected again

Test script:
---------------
$pattern = "#/(?<moduleName>[^/]+)/layout/[^/]*\.xml$#i";
$res1 = preg_match($pattern,            "/Users/nickdekleijn/Sites/project-12gobiking-m2/vendor/magento/theme-adminhtml-backend/Magento_Backend/layout/default.xml", $matches);
$res2 = preg_match($pattern, "/Users/wimvanderputten/Documents/gob/project-12gobiking-m2/vendor/magento/theme-adminhtml-backend/Magento_Backend/layout/default.xml", $matches);
var_dump($res1);
var_dump($res2);

Expected result:
----------------
int(1)
int(1)

Actual result:
--------------
int(0)
int(1)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2021-06-21 11:42 UTC] danack@php.net
-Status: Open +Status: Feedback
 [2021-06-21 11:42 UTC] danack@php.net 
I don't get the results you seem to have: https://3v4l.org/Xl4DM

Please can you test setting ini_set("pcre.jit", "0") and see if that makes a difference?
 [2021-06-21 11:52 UTC] hans at nieser dot nl 
Hey there, a few colleagues of mine who are both running into this issue (I am running 7.4.20 myself so am not affected) report that adding `ini_set("pcre.jit", "0")` to the test script does indeed make it give the expected result
 [2021-06-21 11:55 UTC] hans at reachdigital dot nl 
Small correction to my previous comment: I am running the older not-affected  7.4.16 PHP version, my colleagues who are affected are running 7.4.20 and 8.0.6
 [2021-06-21 12:01 UTC] hans at reachdigital dot nl 
In case this is relevant, PRCRE library versions and default for my colleague running 7.4.20:

PCRE (Perl Compatible Regular Expressions) Support => enabled
PCRE Library Version => 10.37 2021-05-26
PCRE Unicode Version => 13.0.0
PCRE JIT Support => enabled
PCRE JIT Target => x86 64bit (little endian + unaligned)
pcre.backtrack_limit => 1000000 => 1000000
pcre.jit => 1 => 1
pcre.recursion_limit => 100000 => 100000

And for me, running PHP 7.4.16:

PCRE (Perl Compatible Regular Expressions) Support => enabled
PCRE Library Version => 10.36 2020-12-04
PCRE Unicode Version => 13.0.0
PCRE JIT Support => enabled
PCRE JIT Target => x86 64bit (little endian + unaligned)
pcre.backtrack_limit => 1000000 => 1000000
pcre.jit => 1 => 1
pcre.recursion_limit => 100000 => 100000
 [2021-06-21 13:06 UTC] hans at reachdigital dot nl 
Might be a dupe of https://bugs.php.net/bug.php?id=81101 - my affected colleagues are running the same PCRE lib version that this bug is related to (10.37)
 [2021-07-04 04:22 UTC] php-bugs at lists dot php dot net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 17:01:30 2024 UTC