go to bug id or search bugs for
*** Error in `php': double free or corruption (!prev): 0x0000000002b0dec0 ***
Add a Patch
Add a Pull Request
This looks like PCRE issue, did you report it to the PCRE maintainers?
I did't report to the PCRE maintainers.
It has now been reported to the PCRE maintainers, but with no information about the PCRE version. I cannot reproduce a problem with the given pattern - it gives an immediate "unmatched parentheses" error, with or without the backslashes (does PHP remove them?).
> I cannot reproduce a problem with the given pattern […]
Neither can I with PCRE 8.41 (PCRE 8.38 exhibits the bad behavior, though).
@qflbapp Please provide the PCRE_VERSION you are using.
> […] with or without the backslashes (does PHP remove them?).
PHP requires to enclose the regular expression with an arbitrary character (in
this case a slash has been chosen), to separate the actual regexp from the
modifier characters (if any).
Thanks for checking it out. I too can reproduce with 8.38, but not with 8.39 or 8.41 (latest - I didn't bother with 8.40) or with PCRE2 (10.30). Clearly this bug has been fixed. The 8.39 ChangeLog, on a quick scan, does show a bugfix (#14) which is probably the one. 8.38 is nearly 2 years old now. I am going to close the PCRE bug report as already fixed.
Thanks, Philip, that was very helpful.
Anatol, the bug Philip mentions has been assigned CVE-2016-1283, but PHP-7.0
and PHP-7.1 still ship 8.38. Should these be updated, even though that does not
qualify as security issue for PHP, since arbitrary regexps should never be
accepted from untrusted input, IMO.
just update PCRE!
in the meantime no problem any longer
Thanks for the ping, Christoph. I'd be not a big fan of upgrading PCRE, especially in 7.0. The diff is huge not only for PCRE itself, but for ext/pcre, too. With 7.1, too. Not only that, but also it'll require to backport the valgrind support for ext/pcre and run-tests.php, etc. The weight of this issue certainly doesn't justify the backport effort and possible impacts. IMHO, applying the upstream patch is more appropriate. I'll be checking for possible directions.
Upstream patch applied with d11fceab151cd0410645f81eb7444af4388470c3.