PCRE 8.21 to 8.20 update is available.
- Thread starter _ross
- Start date
Richard G
Verified User
Seems strange that this is happening.
We have 3 servers, on 2 I got the update, then I read this message.
The third one had version 8.21 in versions.txt and I could run update as much as I want, nothing happened, versions stayed at 8.21, not even after running manually the ./custombuild cron in /etc/cron.daily.
Now this night the cron has been running and I got a message on server 3 to update from 8.21 to 8.20.
On server 3 I had pcre installed by the OS
pcre.x86_64 6.6-6.el5_6.1
The other 2 also, but the 32bit version:
pcre.i386 6.6-6.el5_6.1
All servers running on Centos 5.5.
Couldn't it have something to do that DA let's pcre downgrade the pcre version due to the problems with the 8.21 version and vbulletin?
http://www.directadmin.com/forum/showthread.php?t=42532
Because the thread you refer to, does not contain the cause for having this issue with the pcre downgrade on all 3 of our servers.
Having pcre installed by the OS has not ever caused any problems before with pcre updates. And the version numbers are completely different, and always were.
Or am I missing something?
I asked a question about it here:
http://www.directadmin.com/forum/showthread.php?t=42517&highlight=
But nobody answered on that yet.
We have 3 servers, on 2 I got the update, then I read this message.
The third one had version 8.21 in versions.txt and I could run update as much as I want, nothing happened, versions stayed at 8.21, not even after running manually the ./custombuild cron in /etc/cron.daily.
Now this night the cron has been running and I got a message on server 3 to update from 8.21 to 8.20.
On server 3 I had pcre installed by the OS
pcre.x86_64 6.6-6.el5_6.1
The other 2 also, but the 32bit version:
pcre.i386 6.6-6.el5_6.1
All servers running on Centos 5.5.
Couldn't it have something to do that DA let's pcre downgrade the pcre version due to the problems with the 8.21 version and vbulletin?
http://www.directadmin.com/forum/showthread.php?t=42532
Because the thread you refer to, does not contain the cause for having this issue with the pcre downgrade on all 3 of our servers.
Having pcre installed by the OS has not ever caused any problems before with pcre updates. And the version numbers are completely different, and always were.
Or am I missing something?
I asked a question about it here:
http://www.directadmin.com/forum/showthread.php?t=42517&highlight=
But nobody answered on that yet.
I doubt it. My experience tells me that custombuild only compares an installed version number with available in a following way "equal or not". And that's all. It does not check which version number is greater.
So you can downgrade and upgrade from one version to another, and custombuild only shows, that available version does not match with the installed one.
Richard G
Verified User
But that is exactly what I find strange because it surely did match.
On server 3, version 8.21 was already installed, also versions.txt said 8.21.
So seen that way, there was no reason for custombuild to do any changes or up/downgrades. Still after the nightly cronjob the night after the other 2 servers, it said to downgrade to 8.20.
In spite of the fact that there was no reason to if I understand your explanation correctly.
On server 3, version 8.21 was already installed, also versions.txt said 8.21.
So seen that way, there was no reason for custombuild to do any changes or up/downgrades. Still after the nightly cronjob the night after the other 2 servers, it said to downgrade to 8.20.
In spite of the fact that there was no reason to if I understand your explanation correctly.
SeLLeRoNe
Super Moderator
I suppose has been downgraded from john cause was causing big issue with vbullettin for a bug (still not defined if is curl bug or vbulletin bug).. so.. i suppose was the best thing to do.
Regards
Regards
Richard G
Verified User
Yes I also thought he downgraded for that reason.
So we all have the same, then it's oke, we don't have to worry that there might be a little problem with the versions file
So we all have the same, then it's oke, we don't have to worry that there might be a little problem with the versions file
mjwebhosting
Verified User
- Joined
- Jun 18, 2011
- Messages
- 32
it seems that they have found the problem:
We believe that we have identified the problem, and that it is fixed by
this patch:
--- code/trunk/pcre_compile.c 2011/12/07 16:52:34 793
+++ code/trunk/pcre_compile.c 2011/12/18 10:03:38 807
@@ -1655,7 +1655,8 @@
case OP_ASSERTBACK:
case OP_ASSERTBACK_NOT:
do cc += GET(cc, 1); while (*cc == OP_ALT);
- /* Fall through */
+ cc += _pcre_OP_lengths[*cc];
+ break;
This patch was already applied to the PCRE trunk (after 8.21) to fix a
different report of the same bug. A failing pattern was provided in that
report, so it was easy to figure out what was going on. This is the
ChangeLog entry:
2. Fixed a bug in fixed-length calculation for lookbehinds that would
show up only in quite long subpatterns.
The patterns in that PHP function were presumably long enough to trigger
the bug.
I have only been able to post this message because of a great amount of
investigative work that was done by a PCRE user who has been
communicating with me privately. (I must ask if it's ok to acknowledge
his/her identity here.) This user did the hard work of constructing a
full pattern from the PHP function and ran a lot of tests on it. Because
the bug could cause a reference to uninitialized memory, the results
could be random. With the above patch, no errors have arisen in a large
number of tests.
Philip
We believe that we have identified the problem, and that it is fixed by
this patch:
--- code/trunk/pcre_compile.c 2011/12/07 16:52:34 793
+++ code/trunk/pcre_compile.c 2011/12/18 10:03:38 807
@@ -1655,7 +1655,8 @@
case OP_ASSERTBACK:
case OP_ASSERTBACK_NOT:
do cc += GET(cc, 1); while (*cc == OP_ALT);
- /* Fall through */
+ cc += _pcre_OP_lengths[*cc];
+ break;
This patch was already applied to the PCRE trunk (after 8.21) to fix a
different report of the same bug. A failing pattern was provided in that
report, so it was easy to figure out what was going on. This is the
ChangeLog entry:
2. Fixed a bug in fixed-length calculation for lookbehinds that would
show up only in quite long subpatterns.
The patterns in that PHP function were presumably long enough to trigger
the bug.
I have only been able to post this message because of a great amount of
investigative work that was done by a PCRE user who has been
communicating with me privately. (I must ask if it's ok to acknowledge
his/her identity here.) This user did the hard work of constructing a
full pattern from the PHP function and ran a lot of tests on it. Because
the bug could cause a reference to uninitialized memory, the results
could be random. With the above patch, no errors have arisen in a large
number of tests.
Philip
Richard G
Verified User
So it was indeed a pcre bug and no vbulletin bug
interfasys
Verified User
People using FreeBSD don't need to downgrade, just use the port.