Moodle

Linking with forums: http://moodle.org/mod/forum/discuss.php?d=123627

Hi Mike,

I've tried here to backup various courses and it has worked perfectly.

In order to get some more info, it would be great if you could config debug in your site (Admin->Server->Debugging) to its maximum value (DEBUG_DEVELOPER) and then try to execute the backup again. You should end with some sort of error in the page or in the web server logs.

For sure that info can give use some hint about what is happening...TIA and ciao

Hello!
We have similar problems with course backup - the screen with file name and backup details is visible, but when we click on Continue, the header of page with navigation link is output, the internet browser progress bar shows page loading in progress. The http process on server is taking 100% of processor. No respond from server on other pages, only http service restart helps to get server responding again.

The cause of problem is in file backup/backuplib.php when trying to execute regular expression with unicode modifiers.

The code starting on line 2327

static $unicoderegexp;
if (!isset($unicoderegexp)) { $unicoderegexp = @preg_match('/\pL/u', 'a'); // This will fail silenty, returning false, }

assigns to $unicoderegexp value 1 - that means check for unicode modifier using gave a positive result. Further on line 2357 the reg. expr. containing unicode modifirs is constructed and on line 2361 it is passed to function for execution - and this is the function where execution comes into seemly infinite loop.
When we assigned $unicoderegexp = false, non-unicode reg. expr. was executed and backup worked well.

The version of Moodle is 1.9.5, we are using Linux OS, MySql DB. PHP 5.1.6 is compiled with mbstring support. We also tried PHP 5.1.6 without mbstring support, the problem remained.

Wow, that line:

$unicoderegexp = @preg_match('/\pL/u', 'a');

should work without problems at all, is a really simple regexp, that should work (returning true) or fail (error, retuning false).

And that type of check is performed not only in backup code, but at least in pdf libraries and some parts of Zend libraries, if I'm not wrong.

So, IMO, the correct solutions is to find a better PCRE library (at OS level), and recompile PHP using it. See, for example these bugs:

• http://bugs.php.net/bug.php?id=36553
• http://bugs.php.net/bug.php?id=40706

suggested solution involves to update OS PCRE, I don't think that modifying Moodle is the solution in this case.

Could you try that approach, Juris? My Win32/Debian/Mac OS hosts here don't reproduce the problem, so it would be great to know which PCRE version (phpinfo should show it) are you running and what happens if you upgrade to a newer one. In any case, thanks for your research!

Mike, could that be the cause of your problems too? Has sense with the behaviour you experimented.

Ciao

Hello!
The line

$unicoderegexp = @preg_match('/\pL/u', 'a');

works fine, it returns 1.
But few lines forward (on line 2357) more complex unicode reg. expression, which parses backup xml file, is constructed and later executed. The execution of complex reg. expr. fails to execute.

The PCRE information is following
PCRE Library Version 6.6 06-Feb-2006

Thank you, Eloy, for advice. Upgrading PCRE might help, as our current version is not the latest.

Hi Juris,

just one quick test:

just before the problematic complex regexp, before the if:

if ($unicoderegexp) { //We can use unicode modifiers

add this line:

$unicoderegexp = false;

in order to force unicode bits to be out and to force the alternate complex regexp to be used.

Does that work? Or the process continues hanging?

TIA and ciao

Hello Eloy!
Actually this is our temporary solution.
I checked again - placing
$unicoderegexp = false;
before

if ($unicoderegexp) { //We can use unicode modifiers

makes backup process finishing well.

Juris

The next step in testing our system on backup failing problem it trying to use newer version of PCRE. When it is done I will inform about the results.

Hi Juris,

before that... can you try another quick tests?

Just keep out the:

$unicoderegexp = false;

line. That way, the problematic unicode regexp will be executed again

And then, in the regexp being executed... at the end.... where this is written:

.... (?<![,.;])/';

add one "u" after the slash, so it will look:

.... (?<![,.;])/u';

and see if it works in your server.

It seems that some servers need that "u" (stands for "unicode mode") to be able to handle those unicode modifiers properly, sadly, my Mac doesn't (perhaps because it's 100% unicode from OS) and linux isn't. Not sure.

If you can try it... that will help a lot, thanks!

Hello, Eloy!

I tried the test you described and got the message "Backup completed successfully". So seems unicode reg. expr. modification helped!
Still haven't tried to update PCRE as on our OS (CentOS) - it is not so convenient - my colleague said there is no way to to this using RPM and that needs some time to do everything correctly. How do you think, is it worth trying updating PCRE or solution we just tried might be solution of the problem?

P.S.
I will no be able to read and comment any answers until Tuesday - I'm going on excursion in minutes and no internet will be available during traveling.

Juris

Thanks for testing and confirming Juris!

What I'm going to do is to add that modifier (/u) to the unicode expression because it seems to help and cannot imagine any reason for it causing problems.

It's really annoying to see different behaviours depending os different OSs and library versions, certainly!

So, next weekly, the "improved" unicode regular expression will be included, so it's recommended to update your server to it. And, as you are getting "true" in the $unicoderegexp check, it should mean that you don't need to update/recompile your PHP at all.

In the mean time, enjoy with your trip! And thanks again for testing my proposals!

Also, Mike, can you test the solution detailed in my previous comment (too add that "u" at the end of the 1st regular expression?) It would be great to hear that it already fixes your problem.

Ciao

Done, I've added the /u modifier to the unicode regexp. It continues working ok in my Mac, so I'm pretty confident it will cause only better behaviours in sites having problems.

Resolving as fixed. Any feedback will be welcome after next weekly. Ciao

Per instructions, this worked! Thanks!!!

>> you've to modify the file:
>>
>> backup/backuplib.php
>>
>> and, around line 2355 you'll see something like this:
>>
>> // Based in $unicoderegexp, decide the regular ....
>> if ($unicoderegexp) { //We can use unicode modifiers >> $search = "one very long regexp >> that ends on /'; >> } else { //We cannot ue unicode modifiers >> $search = "other very long regexp >> that ends on /'; >> }
>>
>> So, you have to edit the FIRST line of this type:
>>
>> $search = "one very long regexp that ends on /';
>>
>> and change it to:
>>
>> $search = "one very long regexp that ends on /u';
>>
>> i.e. you only have to add one lower "u" between the slash
>> and the single quote.
>>
>> Then, save changes and try backup again.

Great Mike,

thanks so much for feedback! Having two reports (Justin and you) about the change being successful is cool, specially when I wasn't able to reproduce it here. Perfect!

Modification is already in CVS so next weekly build (3rd June 2009) will include it. Ciao

All looks good, thanks guys