FATAL ERROR: Invalid URL.

[zeu52]

I am seeing this error pop up on my forum quite a bit from time to time.

When it occurs either the page is there but just with the error at the top or the page isn't with just the error or in the Admin CP (where it is most prone to happen) the content can be missing from either of the panes with the error at the top.

Just wondered if anyone else has come across this?

i use latest 4.x : vBulletin 4.2.3 pl 2
PHP 5.6.24
MySQL 5.5.50 (mysqli)

Regards

[Dragonsys]

<a href="http://www.vbulletin.com/forum/forum/vbulletin-4/vbulletin-4-questions-problems-and-troubleshooting/4019114-fatal-error-invalid-url" target="_blank">http://www.vbulletin.com/forum/forum...or-invalid-url</a>

Others have had the issue, but it doesn't seem like they ever figured out the root cause.

[Paul M]

Its checking if the PHP $GLOBALS variable exists.

This is something that has always existed in php (and still does).
It looks like they changed its behavior in php 5.4, so its not always initialized straight away, but it should always exist by the time that check runs.

http://php.net/manual/en/reserved.variables.globals.php
As of PHP 5.4 $GLOBALS is now initialized just-in-time.

[zeu52]

i had to comment the code to make it work

if (!is_array($GLOBALS))
{
var_dump ($GLOBALS);
//die('<strong>Fatal Error:</strong> Invalid URL.');
}

but now i get more error like:

No Thread specified. If you followed a valid link, please notify the administrator

Sorry! This forum is not accepting new posts.

[Paul M]

You will do.

The check stops the code proceeding completely, but if you allow it to proceed, its going to fail in many ways as $GLOBALS does not exist.

[zeu52]

But if you allow it to proceed it fail 100% and i cant enter Admin Cp or see forums

is there any workaround?

[Paul M]

Get your server (apache) fixed.

$GLOBALS is created by php, not vbulletin, if its missing then any php software is going to have problems.

[hugh_]

Get your server (apache) fixed.

$GLOBALS is created by php, not vbulletin, if its missing then any php software is going to have problems.

I've been having this problem intermittently on one of two vbuletin installations only running of the same PHP and Apache installation. What do you mean exactly by fixing Apache? In my case I believe the culprit may be Dragonbyte's SEO plugin...

Thanks.

[RichieBoy67]

I've been having this problem intermittently on one of two vbuletin installations only running of the same PHP and Apache installation. What do you mean exactly by fixing Apache? In my case I believe the culprit may be Dragonbyte's SEO plugin...

Thanks.
Well to test that theory just disable that plug in and see if the issue still occurs.

[hugh_]

Get your server (apache) fixed.

$GLOBALS is created by php, not vbulletin, if its missing then any php software is going to have problems.

Paul if you could expand on this comment I would be pretty grateful...

So far I've tried disabling all plugins, removing all suspect files and over writing all install files several times. But I haven't been able to fix this and I've had the problem for more than a year and a half. I've enabled maximum log levels (trace8 and E-ALL) in Apache and PHP but still no smoking gun. Even stranger I have two identical copies of vBulletin and plugins running different web sites off the same PHP and Apache installation but only one has ever had the problem. The only lead I have is that whenever I get the error or crash OpenSSL errors seems to be logged such as:

OpenSSL: read 5/5 bytes from BIO#7fde28011fe0 [mem: 7fde48011463] (BIO dump follows)
OpenSSL: read 26/26 bytes from BIO#7fde2c016610 [mem: 7fde3000dda8] (BIO dump follows)
AH02001: Connection closed to child 128 with standard shutdown (server www.example.com:443)

Also whether this might be related to a bug in mod_ssl with small chunked files, based on searches for the above. And that I can consistently reproduce the problem if I rebuild search with a number of items to update less than 5000, but if I use a number far in excess, say 10000, the problem happens much less often if at all. Could there be some link there? I don't know.

PHP 5.6.29 using php5-fpm
MariaDB 10.1.20
OpenSSL/1.0.1t
Apache 2.4.10

[Paul M]

Paul if you could expand on this comment I would be pretty grateful...

Sorry, but there isnt really much more can be said.
PHP creates GLOBALS, if its missing, then it suggests a php/apache/server issue.

I notice you are using fpm, which personally, I avoid, is there any reason you are using it ?

[BirdOPrey5]

Perhaps this? https://bugs.php.net/bug.php?id=65223

Response from PHP team based on bug report of missing $GLOBALS


Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

super-globals (aka. auto globals) are not added to symbol tables by defaultfor performance reasons unless the parser sees need. i.e.

<?php
$_SERVER;
print_r($GLOBALS);
?>

will list it. You can also control this using auto_gloals_jit in php.ini: http://www.php.net/manual/en/ini.core.php#ini.auto-globals-jit


Solutions seems to be to force auto_gloals_jit to true in php.ini file.

[hugh_]

Sorry, but there isnt really much more can be said.
PHP creates GLOBALS, if its missing, then it suggests a php/apache/server issue.

I notice you are using fpm, which personally, I avoid, is there any reason you are using it ?

I use it because it's a lot faster than the alternative. Why avoid it?

--------------- Added 1482261998 at 1482261998 ---------------

Perhaps this? https://bugs.php.net/bug.php?id=65223

Response from PHP team based on bug report of missing $GLOBALS

Solutions seems to be to force auto_gloals_jit to true in php.ini file.

I have that setting enabled already unfortunately.

--------------- Added 1482309694 at 1482309694 ---------------

So I haven't had the problem in 24 hours since upgrading to 4.2.4 Release Candidate 2 but I remember it seeming to go away the last few times I upgraded.

[hugh_]

Still no sign of this problem with 4.2.4 RC2.

[Paul M]

You wont see it die with that fatal error if thats what you mean.

It was converted to a user warning in 4.2.4, so php will log the warning and attempt to carry on.