Routing component (and unit tests) fails on CentOS #4093

Closed
grEvenX opened this Issue Apr 23, 2012 · 35 comments

Comments

Projects
None yet
10 participants
Contributor

grEvenX commented Apr 23, 2012

Running php PHP 5.3.3, Centos kernel 2.6.18-308.el5.028stab099.3 .

The following change breaks the preg_match function in my environment:
symfony/routing@2241c99

Seems like there has been some related issues on this topic before:
https://bugs.php.net/bug.php?id=46904&edit=3

Complete phpunit log:

PHPUnit 3.6.10 by Sebastian Bergmann.

Configuration read from /home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/phpunit.xml.dist

..................................SSSSSSSSSSSSSSSSSSSSSSSSSSSSS  63 / 131 ( 48%)
SSSSSS.........FEEE..E....EEEEE.E.E.....S...S.................. 126 / 131 ( 96%)
.....

Time: 0 seconds, Memory: 12.00Mb

There were 11 errors:

1) Symfony\Component\Routing\Tests\Matcher\Dumper\PhpMatcherDumperTest::testDump with data set #0 (Symfony\Component\Routing\RouteCollection, 'url_matcher1.php', array())
preg_match(): Compilation failed: unrecognized character after (?< at offset 9

/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/Dumper/PhpMatcherDumper.php:194
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/Dumper/PhpMatcherDumper.php:149
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/Dumper/PhpMatcherDumper.php:86
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/Dumper/PhpMatcherDumper.php:71
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Tests/Matcher/Dumper/PhpMatcherDumperTest.php:45
/usr/bin/phpunit:46

2) Symfony\Component\Routing\Tests\Matcher\Dumper\PhpMatcherDumperTest::testDump with data set #1 (Symfony\Component\Routing\RouteCollection, 'url_matcher2.php', array('Symfony\\Component\\Routing\\Tests\\Fixtures\\RedirectableUrlMatcher'))
preg_match(): Compilation failed: unrecognized character after (?< at offset 9

/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/Dumper/PhpMatcherDumper.php:194
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/Dumper/PhpMatcherDumper.php:149
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/Dumper/PhpMatcherDumper.php:86
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/Dumper/PhpMatcherDumper.php:71
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Tests/Matcher/Dumper/PhpMatcherDumperTest.php:45
/usr/bin/phpunit:46

3) Symfony\Component\Routing\Tests\Matcher\Dumper\PhpMatcherDumperTest::testDump with data set #2 (Symfony\Component\Routing\RouteCollection, 'url_matcher3.php', array())
preg_match(): Compilation failed: unrecognized character after (?< at offset 9

/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/Dumper/PhpMatcherDumper.php:194
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/Dumper/PhpMatcherDumper.php:149
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/Dumper/PhpMatcherDumper.php:86
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/Dumper/PhpMatcherDumper.php:71
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Tests/Matcher/Dumper/PhpMatcherDumperTest.php:45
/usr/bin/phpunit:46

4) Symfony\Component\Routing\Tests\Matcher\TraceableUrlMatcherTest::test
preg_match(): Compilation failed: unrecognized character after (?< at offset 9

/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/TraceableUrlMatcher.php:57
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php:90
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/TraceableUrlMatcher.php:37
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Tests/Matcher/TraceableUrlMatcherTest.php:31
/usr/bin/phpunit:46

5) Symfony\Component\Routing\Tests\Matcher\UrlMatcherTest::testMatch
preg_match(): Compilation failed: unrecognized character after (?< at offset 9

/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php:132
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php:90
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Tests/Matcher/UrlMatcherTest.php:82
/usr/bin/phpunit:46

6) Symfony\Component\Routing\Tests\Matcher\UrlMatcherTest::testMatchWithPrefixes
preg_match(): Compilation failed: unrecognized character after (?< at offset 9

/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php:132
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php:118
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php:118
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php:90
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Tests/Matcher/UrlMatcherTest.php:135
/usr/bin/phpunit:46

7) Symfony\Component\Routing\Tests\Matcher\UrlMatcherTest::testMatchWithDynamicPrefix
preg_match(): Compilation failed: unrecognized character after (?< at offset 5

/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php:132
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php:118
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php:118
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php:90
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Tests/Matcher/UrlMatcherTest.php:150
/usr/bin/phpunit:46

8) Symfony\Component\Routing\Tests\Matcher\UrlMatcherTest::testMatchNonAlpha
preg_match(): Compilation failed: unrecognized character after (?< at offset 5

/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php:132
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php:90
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Tests/Matcher/UrlMatcherTest.php:160
/usr/bin/phpunit:46

9) Symfony\Component\Routing\Tests\Matcher\UrlMatcherTest::testMatchWithDotMetacharacterInRequirements
preg_match(): Compilation failed: unrecognized character after (?< at offset 5

/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php:132
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php:90
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Tests/Matcher/UrlMatcherTest.php:170
/usr/bin/phpunit:46

10) Symfony\Component\Routing\Tests\Matcher\UrlMatcherTest::testMatchRegression
preg_match(): Compilation failed: unrecognized character after (?< at offset 9

/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php:132
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php:90
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Tests/Matcher/UrlMatcherTest.php:197
/usr/bin/phpunit:46

11) Symfony\Component\Routing\Tests\Matcher\UrlMatcherTest::testDecodeOnce
preg_match(): Compilation failed: unrecognized character after (?< at offset 9

/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php:132
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php:90
/home/even/callmanager/vendor/symfony/routing/Symfony/Component/Routing/Tests/Matcher/UrlMatcherTest.php:226
/usr/bin/phpunit:46

--


There was 1 failure:

1) Symfony\Component\Routing\Tests\Matcher\Dumper\PhpMatcherDumperTest::testDumpWhenSchemeIsUsedWithoutAProperDumper
Failed asserting that exception of type "PHPUnit_Framework_Error_Warning" matches expected exception "\LogicException".

/usr/bin/phpunit:46

FAILURES!
Tests: 131, Assertions: 163, Failures: 1, Errors: 11, Skipped: 37.
Contributor

vicb commented Apr 24, 2012

The syntax is supposed to be available since PHP 5.2.2 (http://fr.php.net/manual/en/regexp.reference.subpatterns.php) - the bug is dated from 2008.

Is 5.3.3 your CLI version (php -v) ? could you also check the PCRE version (php -i).

Contributor

grEvenX commented Apr 24, 2012

Thanks for the quick update. Might be a regression in PHP, not sure:

[root@devops ~]# php -v
PHP 5.3.3 (cli) (built: Feb 22 2012 19:38:14)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

[root@devops ~]# php -i
pcre

PCRE (Perl Compatible Regular Expressions) Support => enabled
PCRE Library Version => 6.6 06-Feb-2006

Directive => Local Value => Master Value
pcre.backtrack_limit => 100000 => 100000
pcre.recursion_limit => 100000 => 100000

Contributor

mvrhov commented Apr 24, 2012

It's not a regression you are building the PHP with system pcre library and not the one shipped with php.

Contributor

vicb commented Apr 24, 2012

PHP 5.3.3 is supposed to used PCRE 8.02 .

This syntax is available since PCRE 7.0 see the changelog, v7.0 item 34a

@Tobion what about reverting this change ?

Contributor

grEvenX commented Apr 24, 2012

@mvrhov: I'm not building PHP myself, using the latest CentOS distributed php53 version

Contributor

grEvenX commented Apr 24, 2012

On that note; https://bugs.launchpad.net/ius/+bug/608119 (IUS is not official CentOS distribution though, but it outlines the problem with the centos package system).

I can probably get this fixed with some updates somehow on the server, but the question is if this might affect other users badly as well :/

Member

Tobion commented Apr 24, 2012

Then centos is building flawed PHP. This might also result in other bugs/inconsistencies. So reverting the change will not eliminate the real problem.

Owner

fabpot commented Apr 24, 2012

Let's revert this change, it's not a critical change anyway, so let's not break things for nothing.

Contributor

grEvenX commented Apr 24, 2012

Good to know, I updated my PHP packages from the IUS community now, so it works for me, but I think it quickly can be a source of frustration for the other centos users...

Member

Tobion commented Apr 24, 2012

There are probably other bugs when using incompatible packages. So reverting it will only mask them. Then we can probably not use any advanced features (like unicode support) because people might have misconfigured PHP with outdated packages. But if you think that's the way to go.

Member

Tobion commented Apr 24, 2012

I would rather add a PCRE version check to the requirements check of symfony.

Contributor

grEvenX commented Apr 24, 2012

@Tobion But is this an "incompatible package", or is it just an uncommon combination.
The question would rather be, what PCRE version do you intend to support for the project...

Member

Tobion commented Apr 24, 2012

Well, using a 6 year old PCRE with a current PHP version, should be considered incompatible.

Contributor

vicb commented Apr 24, 2012

@Tobion the plan is to revert the commit and add a warning in check.php

Contributor

vicb commented Apr 24, 2012

and make sure the "new" syntax is not used anywhere else in Sf2

Member

Tobion commented Apr 24, 2012

it's not only the new syntax that fails. It's probably also unicode routes that won't work correctly with such an old PCRE version. So we can drop this stuff too: #3629
So either we support PCRE 6.6 06-Feb-2006 or not. And as you apperently want to support it, who will test every feature against it?

Contributor

vicb commented Apr 24, 2012

Do unicode routes work properly as of today ?

Contributor

mvrhov commented Apr 24, 2012

IMHO php 5.3.2 comes with PCRE 8.0 and this is the minimum version that should be required.
If someone is running backports on older Linux distributions and those backports use system pcre then the bug should be filed in the bug tracker for that specific backport

@vicb vicb referenced this issue in symfony/symfony-standard Apr 27, 2012

Merged

Check for PCRE > 8.0 #324

Contributor

vicb commented Apr 27, 2012

A minimum requirement of PCRE 8.0 is the best. See symfony/symfony-standard#324

@vicb vicb closed this Apr 27, 2012

fabpot added a commit to symfony/symfony-standard that referenced this issue Apr 27, 2012

merged branch vicb/check/pcre (PR #324)
Commits
-------

c7c44db Check for PCRE > 8.0

Discussion
----------

Check for PCRE > 8.0

related to symfony/symfony#4093

Well, about a month ago I downloaded the "fat" silex package and I'm having the same issue there.

[Mon Aug 27 16:34:39 2012] [error] [client XX.81.148.90] PHP Warning: preg_match():
Compilation failed: unrecognized character after (?< at offset 5
in [...]/httpdocs/vendor/symfony/routing/Symfony/Component/Routing/Matcher/UrlMatcher.php on line 117 

In staging the code works: Debian 6, PHP 5.3.3-7+squeeze13 with Suhosin-Patch (cli) (built: Jun 10 2012 07:31:32)
In production I get the error: My hosting provider uses a Plesk 10.4 (running on CentOs?) with PHP 5.3.3.

This makes Silex doesn't match my URLs.

Member

Tobion commented Aug 27, 2012

Check the symfony requirements on the production machine (web/config.php).

Well, theres no requirements as i downloaded the package (not phar). It
works perfectly in the debian machine (staging) and in my local
environment. I don't think that's the problem: that file doesn't even exist
and the warning talks about invalid character.
El 27/08/2012 17:39, "Tobias Schultze" notifications@github.com escribió:

Check the symfony requirements on the production machine (web/config.php).


Reply to this email directly or view it on GitHubhttps://github.com/symfony/symfony/issues/4093#issuecomment-8059796.

Member

Tobion commented Aug 27, 2012

It's because your production machines uses an outdated PCRE.

All right. It might be it. I guess I'll have to search about that in an
other forum. Thanks for the help.

EDIT: It was that, with PCRE versión 6.6 it doesn't work.

Hi to all, I start a test over a centos server 6.3 for Symfony 2.1.2... The check file, say that I need Pcre extension 8+.... I have 7.x But I can't find any rpm or tutorial for solver this problem.... someone could use SF2 2.1.2 over centos???

artemiuz commented Nov 9, 2012

Hi all,

For Symfony 2.1.3 and PCRE <8 you could replace rows in
vendor\symfony\symfony\src\Symfony\Component\Routing\RouteCompiler.php:

114: return sprintf('%s(?P<%s>%s)?', preg_quote($token[1], self::REGEX_DELIMITER), $token[3], $token[2]);
116: $regexp = sprintf('%s(?P<%s>%s)', preg_quote($token[1], self::REGEX_DELIMITER), $token[3], $token[2]);

and clean the cache.

Contributor

pborreli commented Nov 9, 2012

could someone provide a PR in order to fix Symfony core for all version of PCRE ?

Member

Tobion commented Nov 9, 2012

@pborreli we already discussed it and decided not to support custom PHP compilations with outdated PCRE versions. Or are you able to test all features against all versions and combinations?

Contributor

pborreli commented Nov 9, 2012

@Tobion if we know an easy fix for PCRE <8 why don't fix it? as i understand it's not custom PHP compilation but standard CentOS PHP package.

Contributor

mvrhov commented Nov 9, 2012

CentOS is notorious for compiling a PHP with a system PCRE and also shipping an old PCRE version.
http://stackoverflow.com/questions/12212079/pcre-librairies-version-is-too-old

finally i can compile PHP, manually :) , and PCRE8+, but i can't install with php-intl
or i have say in web intl is installed, but on CLI, isn't ... and therefore
php composer.phar update
don't work :(

Member

stof commented Nov 9, 2012

@puentesdiaz be careful than the web and the CLI often use different php.ini files

i think same, but my php -i show : Loaded Configuration File => /usr/local/lib/php.ini

same of my phpinfo() Loaded Configuration File /usr/local/lib/php.ini

Contributor

mvrhov commented Nov 11, 2012

Just look at the link the OP posted as a php bug. It contains the PCRE versions and the corresponding PHP version the one shipped with. PCRE 7.8 your distribution is compiling PHP with, originally shipped with php 5.2.7 which was in sometime in 2008.
My opinion is still the same as it was 7 months ago... The minimum version of PCRE sf2 should support is the one that shipped with the minimum version of PHP sf2 supports.

fabpot added a commit that referenced this issue Nov 19, 2012

merged branch Tobion/routing-centos (PR #6062)
This PR was merged into the 2.1 branch.

Commits
-------

1daefa5 [Routing] made it compatible with older PCRE version (pre 8)

Discussion
----------

[Routing] compatibility with older PCRE version (pre 8)

fixes #4093

Ok I changed my mind about this issue.
1. I figured more people are affected than I thought and CentOS is stubborn.
2. Symfony still uses the old regex style `?P<param>` in several other components. So also doing so in the routing makes it more consistent.
3. Even if it's definitely not good to use an over 6 year old PCRE version with a recent PHP version, we can still try to provide the best experience. It doesn't mean we support outdated software stacks of custom PHP compilations as we won't and cannot specifically test against it.

@fabpot: I will do a seperate PR on master when you merged this because the code changed alot in master so it cannot easily be merged I guess. I will also convert the symfony requirement for PCRE in the requirements check to a recommendation.
Member

Tobion commented Nov 19, 2012

fix merged in 21. the routing should be compatible with centos now.

@vicb vicb referenced this issue in sensiolabs/SensioDistributionBundle Nov 19, 2012

Merged

PCRE version from requirement to recommendation #68

mbence pushed a commit to mbence/csaladsegito that referenced this issue Feb 3, 2014

merged branch vicb/check/pcre (PR #324)
Commits
-------

c7c44db Check for PCRE > 8.0

Discussion
----------

Check for PCRE > 8.0

related to symfony/symfony#4093
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment