Skip to content

Installed Golang started having problems with PHP preg_replace function! But wait, it was because of old PCRE version

March 25, 2013

We use DokuWiki as an internal Wiki, for some misc help manuals, which we refer to while doing some routine tasks like building an image properly, or even for small things like manually fixing some data in the Database.

The setup (DokuWiki written in PHP) has been working fine for 2 years now. And so much fine so that, we forgot any and every detail about it.

Now, last week had installed Go on one of the servers (incidentally on the same one which has DokuWiki). The install comprised of mainly the Go language, and just few Go packages from GitHub and Google code.

Today morning, I just had to refer to a manual in DokuWiki, for one of the semi-manual tasks, and it won’t open. The DokuWiki just stopped working!

It would simply refuse to open any page. Won’t allow to login, or even to change the password (reset the password) or any darn thing.

It immediately occurred that, it has to be something related to Go. Oh gosh, did Googly guys, just replace some of the core system libraries as part of the install? Did I accidentally delete the DB used by DokuWiki, in the hurry to test out Go’s MySql driver? Does DokuWiki even use MySQL at all?

Quickly checked up the answer for the last one, and thankfully it was a ‘no’. It does not. Great. So it has to be something to do with Go install.

But how do I check it out, this stupid thing. is not moving at all, beyond the first page, refusing to do any thing whether its Login; password reset; or any wiki page opening.

After some amount of random struggle, an idea occurred to grep for the error messages given out by DokuWiki in its code. So off I went on that scent…

Below is the debug trail, of how the problem was solved. Have been wanting to write notes for every such experience, for sometime.

But just writing without sharing, becomes too boring to write. Sharing makes it more interesting to write, and also write properly. So here goes, the detailed steps, which may be very boring for a reader, without context:

1. So first step grep for the error message, given out by DokuWiki. After grepping successively for .php, then */.php and then */*/*.php, ultimately got.

lang.php:$lang[‘resendpwdnouser’]  = ‘Sorry, we can\’t find this user in our database.’;

and it was in inc/lang/en (some 3 levels down)

2. Then started to grep for ‘resendpwdnouser’ in a similar way, and landed it in inc/auth.php

auth.php:            msg($lang[‘resendpwdnouser’].’ : ‘.$user, -1); —

3. And it was happening from a piece of code which calls $auth->getUserData($user)
and if the returned value is null sets this message

4. Now changed tactic and started outing some custom error messages of mine, from within the code of getUserData() . This way localised it to a function cleanUser() . This cleanUser() guy was totally cleaning up every user id passed to it mysteriously!

5. Within cleanUser() what was happening was cleanID() getting called, and within it it was happening within utf8_stripspecials() [Note all these may have been in different files/packages]

Also another discovery at this point was that, this cleanID() is being called from hundreds of places, to clean any text/ID of any special characters. And what it was doing was it was just making it blank(cleaning it up!).

6. Finally within utf8_stripspecials() it was happening from a PHP library function called preg_replace(http://php.net/manual/en/function.preg-replace.php)

7. A host of funny chars were being passed to the function to be replaced by a simple ‘_’, and one or some of which were causing problems.
   So now the tactic changed to find out which character or what in the function was causing problem.

8. Finally, it was revealed that calling it with a u in the end was causing problem. Meaning:

echo preg_replace(‘/[a]/u’, ‘b’, ‘gaab’).’\n’; // Major problems
echo preg_replace(‘/[a]/’, ‘b’, ‘gaab’).’\n’; // Works fine …

9) And on testing it with a simple small program was able to replicate this. Great! And mercifully it was outputting a neat compile time(gasp!) error message.

10) So now the hunt was for the following in Google search:

PHP Warning:  preg_replace(): Compilation failed: unknown option bit(s) set at offset 0

11) From then on it was quick, got some reasonable pointers including the better one (https://forums.aws.amazon.com/message.jspa?messageID=366065) which said, that it happens because if we upgrade from a version 5.3.13 of PHP to a version after it, then it needs a PCRE update (PCRE, apparently was a library for perl compatible regexp).

12) Quickly did a ‘yum update pcre’ and it upgraded from version 7.x to 8.x!

13) Now ran the local test. Bingo! It worked. Tried the DokuWiki, and it worked just like last week! great! Hurray!

So what was the problem. How could Go spoil it for me?

14) Turns out after installing Go, I had to restart the httpd on that server, to proxy some directives for the Go server.
And it turns out that restart of httpd was after some 3 months. And in between I had updated PHP, but ofcourse did not upgrade PCRE (Why would I?; Who would?)

So thankfully Go, was not to blame. Else, would have been stuck in a bigger mess, of amicably resolving any core library dispute for both.

Hopefully this documentation serves as an interesting story and is useful, the next time in some way! (Countless such stories happen and are forgotten, with some tiny experiential gist goes somewhere into the subconscious/unconscious mind)

Advertisements

From → Uncategorized

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: