6.0.0-git
2019-03-23

[#12103] Blank page on browsing turba address books
Summary Blank page on browsing turba address books
Queue Horde Framework Packages
Queue Version Git master
Type Bug
State Resolved
Priority 1. Low
Owners jan (at) horde (dot) org, mrubinsk (at) horde (dot) org, slusarz (at) horde (dot) org
Requester csoft2k5 (at) gmail (dot) com
Created 2013-03-09 (2205 days ago)
Due
Updated 2013-03-12 (2202 days ago)
Assigned 2013-03-09 (2205 days ago)
Resolved 2013-03-11 (2203 days ago)
Milestone
Patch No

History
2013-03-12 09:10:44 arjen+horde (at) de-korte (dot) org Comment #43 Reply to this comment
Even with Horde_Core-2.4.3, the problem in some PHP installations is
not fixed completely. Although the Addressbook now opens fine from
the Horde portal, there still is an issue with messages that are
being logged incorrectly.
This has nothing to do with this ticket.  Please open a new ticket 
if you want to report.
http://bugs.horde.org/ticket/12109
2013-03-12 08:53:52 Michael Slusarz Comment #42 Reply to this comment
Even with Horde_Core-2.4.3, the problem in some PHP installations is 
not fixed completely. Although the Addressbook now opens fine from 
the Horde portal, there still is an issue with messages that are 
being logged incorrectly.
This has nothing to do with this ticket.  Please open a new ticket if 
you want to report.
2013-03-12 08:46:20 arjen+horde (at) de-korte (dot) org Comment #41 Reply to this comment
Even with Horde_Core-2.4.3, the problem in some PHP installations is 
not fixed completely. Although the Addressbook now opens fine from the 
Horde portal, there still is an issue with messages that are being 
logged incorrectly.

Since the upgrade to Horde_Core-2.4.2, Horde is spamming my syslog 
with messages like

Mar 10 21:30:10 mail horde: [imp] Login success for arjen (Horde user 
arjen) [192.168.1.126] to {localhost:143 [imap]} [pid 3574 on line 183 
of "/srv/www/htdocs/horde/imp/lib/Auth.php"]

The above is from an ActiveSync client by the way and coincides with 
PING and SYNC messages in the webserver log.

I configured logging for level WARNING:

   $conf['log']['priority'] = 'WARNING';
   $conf['log']['ident'] = 'horde';
   $conf['log']['name'] = LOG_LOCAL7;
   $conf['log']['type'] = 'syslog';
   $conf['log']['enabled'] = true;

This message is logged with priority 'NOTICE' (I checked that), which 
is lower than the 'WARNING' threshold, so these messages should never 
have made it to the syslog.

The behaviour is as expected when downgrading to Horde_Core-2.4.1.
2013-03-11 19:30:32 Michael Slusarz Comment #40 Reply to this comment
Mea culpa.  Was reading an incorrect/outdated version of the PHP manual.

Turns out that these error messages MUST fatally error out (which 
makes sense):

E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, 
E_COMPILE_WARNING

But these error messages don't trigger the user defined error handler 
anyway.  So that should not be an issue here.
2013-03-11 19:28:00 Michael Slusarz Comment #39 Reply to this comment

[Show Quoted Text - 13 lines]
As to the former - that is just an incorrect statement.  If hordeInit 
is non-empty, than injector MUST have been initialized.  Period.   
Anything else is a PHP bug.

And the latter is also an incorrect statement.  Absolutely no 
destruction goes on before a custom error handler is triggered.  If 
your custom error handler doesn't exit the script internally, PHP will 
continue to process the script.  Fatal errors are not fatal at the 
engine level; they are fatal at the error reporting level.

So let's call a spade a spade.  This fix is nothing more than a patch 
against broken PHP installations.  It has nothing to do with how we 
handle error reporting.
2013-03-11 18:18:58 Jan Schneider State ⇒ Resolved
 
2013-03-11 17:37:26 hanns (at) hannsmattes (dot) de Comment #38 Reply to this comment
Does that fix it?
Yes, it does.

Hanns
2013-03-11 17:11:42 delrio (at) mie (dot) utoronto (dot) ca Comment #37 Reply to this comment
Does that fix it?
Yes, it works for me again after that change to Horde.php.
Thanks!
2013-03-11 17:08:36 Jan Schneider Version ⇒ Git master
Queue ⇒ Horde Framework Packages
 
2013-03-11 17:08:08 Jan Schneider Comment #36
Assigned to Jan Schneider
Reply to this comment
Does that fix it?
2013-03-11 17:02:22 Git Commit Comment #35 Reply to this comment
Changes have been made in Git (master):

commit 7927bb3ef72f8acd48398737814a379f03c59229
Author: Jan Schneider <jan@horde.org>
Date:   Mon Mar 11 18:01:23 2013 +0100

     [jan] Fix error handler in some PHP versions (Bug #12103).

  framework/Core/package.xml |    4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

http://git.horde.org/horde-git/-/commit/7927bb3ef72f8acd48398737814a379f03c59229
2013-03-11 17:02:16 Git Commit Comment #34 Reply to this comment
Changes have been made in Git (master):

commit ddb8342bb51c88af4cedce8b60857726c7671679
Author: Jan Schneider <jan@horde.org>
Date:   Mon Mar 11 17:59:17 2013 +0100

     Explicitly check if $injector exists (Bug #12103).

     Since this code is called directly from PHP as an error handler, 
we have no
     control when the code is called, and whether the injector has already been
     created or has already been destructed.

  framework/Core/lib/Horde.php |    3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)

http://git.horde.org/horde-git/-/commit/ddb8342bb51c88af4cedce8b60857726c7671679
2013-03-11 16:35:28 delrio (at) mie (dot) utoronto (dot) ca Comment #33 Reply to this comment
Same error here on a Solaris server after pear upgrade today.
Server: Solaris 11.1, PHP 5.3.14 (Oracle Solaris php-53 package)

Packages upgraded:
upgrade ok: channel://pear.horde.org/Horde_Imap_Client-2.7.2
upgrade ok: channel://pear.horde.org/Horde_ActiveSync-2.3.2
upgrade ok: channel://pear.horde.org/Horde_Core-2.4.2

Error when accessing /turba/browse.php:

[Mon Mar 11 12:18:40 2013] [error] PHP Fatal error:  Call to a member 
function getInstance() on a non-object in /var/php/5.3/pear/Horde.php 
on line 76, referer: https://server.name/turba/
[Mon Mar 11 12:18:40 2013] [error] PHP Stack trace:, referer: 
https://server.name/turba/
[Mon Mar 11 12:18:40 2013] [error] PHP   1. 
Horde_ErrorHandler::errorHandler() 
/var/php/5.3/pear/Horde/ErrorHandler.php:0, referer: 
https://server.name/turba/
[Mon Mar 11 12:18:40 2013] [error] PHP   2. Horde::log() 
/var/php/5.3/pear/Horde/ErrorHandler.php:168, referer: 
https://server.name/turba/

All caches were cleared after the upgrade.
2013-03-11 04:48:30 Michael Slusarz Comment #32 Reply to this comment
Although looking at that script file - it won't correctly clear the 
cache if using local temp file caching.  That should be fixed.
Never mind.  the script is correct.
2013-03-11 04:37:44 Michael Slusarz Comment #31 Reply to this comment
If Horde_ErrorHandler can't be found, there is either a problem with 
your installation or a problem with your autoloader (i.e. a PHP
Seeing as how autoloading might be an issue, might be a good idea to run the
horde-autoloader-cache-prune script (which should have been installed 
in the pear directory when Horde_Autoloader_Cache was installed).

Although looking at that script file - it won't correctly clear the 
cache if using local temp file caching.  That should be fixed.
2013-03-11 04:30:57 Michael Slusarz Comment #30 Reply to this comment
[Sun Mar 10 12:20:28 2013] [error] [client 192.168.1.121] PHP 
Warning:  Invalid callback Horde_ErrorHandler::errorHandler, class 
'Horde_ErrorHandler' not found in 
/usr/share/php5/PEAR/PEAR/Config.php on line 650, referer: 
https://www.example.com/horde/login.php
If Horde_ErrorHandler can't be found, there is either a problem with 
your installation or a problem with your autoloader (i.e. a PHP issue).
And when I open the addressbook, I get the following (much shorter) 
stacktrace:

[Sun Mar 10 12:21:07 2013] [error] [client 192.168.1.121] PHP Fatal 
error:  Call to a member function getInstance() on a non-object in 
/usr/share/php5/PEAR/Horde.php on line 76, referer: 
https://www.example.com/horde/services/portal/index.php
FWIW, this is definitely not the log error from opening a turba 
addressbook.  This is a log error being generated by the portal page.
2013-03-11 04:11:31 Michael Slusarz Comment #29 Reply to this comment
I don't want to stand in the way of progress, but this would 
basically mean that PHP 5.4 would be a requirement from now on and 
PHP 5.3 would no longer be supported.
Except this is an incorrect statement.  Mike R has verified that at 
least two different versions of PHP 5.3 work fine.

Sure enough: as I predicted before, this IS a problem with people's 
PHP (because it is impossible under the PHP programming rules for this 
to occur).

Everyone needs to make sure they are NOT using an opcode cache (e.g. 
APC, xcache).  Bugs in that kind of software are exactly the kind of 
things that will cause these kind of unexplainable parsing errors.
2013-03-10 14:55:21 csoft2k5 (at) gmail (dot) com Comment #28
New Attachment: php.ini Download
Reply to this comment
I've attached the php.ini from CentOS's stock version of php. What can 
it  be wrong with it ? The only thing modified is the date.timezone 
variable.
2013-03-10 14:41:03 arjen+horde (at) de-korte (dot) org Comment #27 Reply to this comment

[Show Quoted Text - 11 lines]
According to phpinfo(), I have the following values:

     output_handler (no value)
     zlib.output_compression Off
     zlib.output_handler (no value)

The weird thing is, I have changed nothing in php.ini, yet PHP 5.3.22 
fails, but PHP 5.4.12 works.

I have to admit that I may be comparing apples with oranges here. The 
versions of PHP 5.3 (5.3.15 and 5.3.22) I was using so far came from a 
different repository than PHP 5.4.12, so there is a chance that they 
were built with different options.
2013-03-10 13:51:21 Michael Rubinsky Comment #26 Reply to this comment
[Sun Mar 10 12:04:33 2013] [error] [client 192.168.1.121] PHP Fatal 
error:  ob_start(): Cannot use output buffering in output buffering 
display handlers in /usr/share/php5/PEAR/Horde.php on line 1524, 
referer: https://www.example.com/horde/services/portal/index.php

Of course, the page will be blank then.
This sounds like a configuration error in php.

Are you using output compression configured in php.ini or have some 
other value for output_handler() configured in your php.ini?

2013-03-10 13:42:13 Michael Rubinsky Comment #25 Reply to this comment
I've managed  to make it work on a test system by upgrading the stock
php 5.3.3 from CentOS (as I use CentOS on the production server) to
5.4.12 from Remi's repository. So I  guess it's again about  the
incompatibility between horde and php versions from different
distributions.
More accurately, it's about Horde code triggering a bug or 
misconfiguration in the php you are using.
I'm afraid this is indeed the case. I upgraded to PHP 5.4.12 too, 
which seems to work fine indeed.

While I agree that PHP 5.3.3 might be considered 'too old', PHP 
5.3.22 (which I was using so far) was only released a little over 
two weeks ago. I don't want to stand in the way of progress, but 
this would basically mean that PHP 5.4 would be a requirement from 
now on and PHP 5.3 would no longer be supported.
FWIW, I use php 5.3.x from ubuntu and 5.3.x from MacPorts on my 
development machines. I am experiencing none of these problems.

2013-03-10 13:24:30 arjen+horde (at) de-korte (dot) org Comment #24 Reply to this comment
I've managed  to make it work on a test system by upgrading the 
stock php 5.3.3 from CentOS (as I use CentOS on the production 
server) to 5.4.12 from Remi's repository. So I  guess it's again 
about  the incompatibility between horde and php versions from 
different distributions.
I'm afraid this is indeed the case. I upgraded to PHP 5.4.12 too, 
which seems to work fine indeed.

While I agree that PHP 5.3.3 might be considered 'too old', PHP 5.3.22 
(which I was using so far) was only released a little over two weeks 
ago. I don't want to stand in the way of progress, but this would 
basically mean that PHP 5.4 would be a requirement from now on and PHP 
5.3 would no longer be supported.
2013-03-10 12:11:59 csoft2k5 (at) gmail (dot) com Comment #23 Reply to this comment
I've managed  to make it work on a test system by upgrading the stock 
php 5.3.3 from CentOS (as I use CentOS on the production server) to 
5.4.12 from Remi's repository. So I  guess it's again about  the 
incompatibility between horde and php versions from different 
distributions.
No more errors  in apache logs, but only this in horde.log :

2013-03-10T13:59:54+02:00 WARN: HORDE [turba] PHP ERROR: Invalid 
argument supplied for foreach() [pid 8762 on line 314 of 
"/var/www/horde5/turba/lib/View/List.php"]
2013-03-10T13:59:54+02:00 WARN: HORDE [turba] PHP ERROR: Invalid 
argument supplied for foreach() [pid 8762 on line 314 of 
"/var/www/horde5/turba/lib/View/List.php"]


2013-03-10 12:09:32 arjen+horde (at) de-korte (dot) org Comment #22 Reply to this comment
After installing php5-xdebug, I'm fanally getting somewhere. I see 
two different stacktraces popping up in the Apache logs.

When logging in, a whole bunch of minor variations of the following:
[trim]

The error messages on startup were caused by Xcache somehow. When 
enabled, it would only log these messages the first time after a 
server restart. Subsequent logins would not show this anymore. After 
disabling Xcache completely, there were no more of these messages. 
Until the original problem of this ticket is found, I'?l keep Xcache 
disabled.

[Show Quoted Text - 17 lines]
These are still shown, although I doubt that the above stacktrace is 
really useful.
2013-03-10 11:33:39 arjen+horde (at) de-korte (dot) org Comment #21 Reply to this comment
After installing php5-xdebug, I'm fanally getting somewhere. I see two 
different stacktraces popping up in the Apache logs.

When logging in, a whole bunch of minor variations of the following:

[Sun Mar 10 12:20:28 2013] [error] [client 192.168.1.121] PHP Warning: 
  Invalid callback Horde_ErrorHandler::errorHandler, class 
'Horde_ErrorHandler' not found in /usr/share/php5/PEAR/PEAR/Config.php 
on line 650, referer: https://www.example.com/horde/login.php
[Sun Mar 10 12:20:28 2013] [error] [client 192.168.1.121] PHP Stack 
trace:, referer: https://www.example.com/horde/login.php
[Sun Mar 10 12:20:28 2013] [error] [client 192.168.1.121] PHP   1. 
{main}() /srv/www/htdocs/horde/services/portal/index.php:0, referer: 
https://www.example.com/horde/login.php
[Sun Mar 10 12:20:28 2013] [error] [client 192.168.1.121] PHP   2. 
Horde_Registry::appInit() 
/srv/www/htdocs/horde/services/portal/index.php:15, referer: 
https://www.example.com/horde/login.php
[Sun Mar 10 12:20:28 2013] [error] [client 192.168.1.121] PHP   3. 
Horde_Registry->pushApp() /usr/share/php5/PEAR/Horde/Registry.php:257, 
referer: https://www.example.com/horde/login.php
[Sun Mar 10 12:20:28 2013] [error] [client 192.168.1.121] PHP   4. 
Horde_Core_LoginTasks->runTasks() 
/usr/share/php5/PEAR/Horde/Registry.php:1572, referer: 
https://www.example.com/horde/login.php
[Sun Mar 10 12:20:28 2013] [error] [client 192.168.1.121] PHP   5. 
Horde_LoginTasks->runTasks() 
/usr/share/php5/PEAR/Horde/Core/LoginTasks.php:48, referer: 
https://www.example.com/horde/login.php
[Sun Mar 10 12:20:28 2013] [error] [client 192.168.1.121] PHP   6. 
Horde_LoginTasks_Task_AdminCheck->execute() 
/usr/share/php5/PEAR/Horde/LoginTasks.php:211, referer: 
https://www.example.com/horde/login.php
[Sun Mar 10 12:20:28 2013] [error] [client 192.168.1.121] PHP   7. 
Horde_Core_Db_Migration->__construct() 
/srv/www/htdocs/horde/lib/LoginTasks/Task/AdminCheck.php:61, referer: 
https://www.example.com/horde/login.php
[Sun Mar 10 12:20:28 2013] [error] [client 192.168.1.121] PHP   8. 
Horde_Autoloader->loadClass() 
/usr/share/php5/PEAR/Horde/Autoloader.php:0, referer: 
https://www.example.com/horde/login.php
[Sun Mar 10 12:20:28 2013] [error] [client 192.168.1.121] PHP   9. 
Horde_Autoloader->_include() 
/usr/share/php5/PEAR/Horde/Autoloader.php:21, referer: 
https://www.example.com/horde/login.php

And when I open the addressbook, I get the following (much shorter) 
stacktrace:

[Sun Mar 10 12:21:07 2013] [error] [client 192.168.1.121] PHP Fatal 
error:  Call to a member function getInstance() on a non-object in 
/usr/share/php5/PEAR/Horde.php on line 76, referer: 
https://www.example.com/horde/services/portal/index.php
[Sun Mar 10 12:21:07 2013] [error] [client 192.168.1.121] PHP Stack 
trace:, referer: https://www.example.com/horde/services/portal/index.php
[Sun Mar 10 12:21:07 2013] [error] [client 192.168.1.121] PHP   1. 
Horde_ErrorHandler::errorHandler() 
/usr/share/php5/PEAR/Horde/ErrorHandler.php:0, referer: 
https://www.example.com/horde/services/portal/index.php
[Sun Mar 10 12:21:07 2013] [error] [client 192.168.1.121] PHP   2. 
Horde::log() /usr/share/php5/PEAR/Horde/ErrorHandler.php:168, referer: 
https://www.example.com/horde/services/portal/index.php
2013-03-10 11:10:46 arjen+horde (at) de-korte (dot) org Comment #20 Reply to this comment

[Show Quoted Text - 10 lines]
I forgot to mention that if Horde::debug is uncommented, the following 
is logged in the Apache logs:

[Sun Mar 10 12:04:33 2013] [error] [client 192.168.1.121] PHP Fatal 
error:  ob_start(): Cannot use output buffering in output buffering 
display handlers in /usr/share/php5/PEAR/Horde.php on line 1524, 
referer: https://www.example.com/horde/services/portal/index.php

Of course, the page will be blank then.
2013-03-10 10:20:55 arjen+horde (at) de-korte (dot) org Comment #19 Reply to this comment
This truly makes zero sense.  Especially since no developer can reproduce.
I have no idea. But I really doubt that at least three different 
people have broken their PHP install in the same way.

[Show Quoted Text - 10 lines]
I tried, but failed. The below is what is in my /usr/share/php5/PEAR/Horde.php

     73          /* Chicken/egg: we must wait until we have basic 
framework setup
     74           * before we can start logging. Otherwise, queue entries. */
     75          if (Horde_Core_Factory_Logger::available()) {
     76              if (empty($GLOBALS['injector'])) {
     77                  // Horde::debug('WTF???');
     78              } else {
     79                   
$GLOBALS['injector']->getInstance('Horde_Log_Logger')->log($event, 
$priority, $options);
     80              }
     81          } else {
     82              Horde_Core_Factory_Logger::queue($event, 
$priority, $options);
     83          }

If I uncomment the line with Horde::debug, it fails in the same way as 
the version from stock Horde_Core-2.4.2. I really have no idea how to 
force a backtrace here. It makes no difference if I use

     76              if (empty($GLOBALS['injector'])) {
or
     76              if (!is_object($GLOBALS['injector'])) {

In both cases a blank page is shown if I open the addressbook and 
leave the Horde::debug line uncommented.
2013-03-10 02:48:10 csoft2k5 (at) gmail (dot) com Comment #18 Reply to this comment
I've alson tried that check and the same thing, horde_debug.txt is 
empty. /tmp directory is writeable by the httpd server, as the file is 
own by apache with 600 permissions.
Now it appears the following error in apache's log:

PHP Fatal error:  ob_start(): Cannot use output buffering in output 
buffering display handlers in /usr/share/pear/Horde.php on line 1522, 
referer: https://mail.autoadria.ro/services/portal/index.php
2013-03-10 01:28:32 Michael Slusarz Comment #17 Reply to this comment
This truly makes zero sense.  Especially since no developer can reproduce.

Only one thing I can think of:
This is being called in a shutdown function so, for some reason, 
$GLOBALS['injector'] has already been destroyed.  But this doesn't 
make any sense because we Horde_Injector doesn't contain a 
__destruct() call.  And the global registry object still exists.

Somebody is going to have to provide some kind of backtrace for us to 
even begin to do anything else with this ticket.  Maybe injector is 
not empty?  So try replacing the empty($GLOBALS['injector']) check 
with a !is_object($GLOBALS['injector']) check.
2013-03-09 21:03:06 arjen+horde (at) de-korte (dot) org Comment #16 Reply to this comment
That makes no sense either. Regardless, don't put it at the 
beginning of the method put it right after line 75 (inside the if 
statement) but before the $GLOBALS['injector']->getInstance(...... 
line.
     73          /* Chicken/egg: we must wait until we have basic 
framework setup
     74           * before we can start logging. Otherwise, queue entries. */
     75          if (Horde_Core_Factory_Logger::available()) {
     76              if (empty($GLOBALS['injector'])) {
     77                  Horde::debug('WTF???');
     78              }
     79               
$GLOBALS['injector']->getInstance('Horde_Log_Logger')->log($event, 
$priority, $options);
     80          } else {
     81              Horde_Core_Factory_Logger::queue($event, 
$priority, $options);
     82          }
Also, make sure your configured tmp directory is writable by the webserver.
# ls -l /tmp/horde_debug.txt
-rw------- 1 wwwrun www 0 Mar  9 19:19 /tmp/horde_debug.txt

I know it is writeable because a left-over Horde::debug statement in 
the ActiveSync code caused /tmp/horde_debug.txt to be spammed with 
messages a few weeks ago.

Now nothing is being logged.
2013-03-09 20:41:20 Michael Rubinsky Comment #15 Reply to this comment
With those lines inserted at the beginning of this function, I can't 
even login to Horde anymore (not even the login screen shows). 
Nothing is logged, not in /tmp/horde_debug.txt, nor in /tmp/horde.log.
That makes no sense either. Regardless, don't put it at the beginning 
of the method put it right after line 75 (inside the if statement) but 
before the $GLOBALS['injector']->getInstance(...... line.

Also, make sure your configured tmp directory is writable by the webserver.
2013-03-09 19:39:17 arjen+horde (at) de-korte (dot) org Comment #14 Reply to this comment
Something along the lines of:

if (empty($GLOBALS['injector'])) {
     Horde::debug('WTF???');
}
With those lines inserted at the beginning of this function, I can't 
even login to Horde anymore (not even the login screen shows). Nothing 
is logged, not in /tmp/horde_debug.txt, nor in /tmp/horde.log.
will log the backtrace in a horde_debug.txt file located in your tmp 
directory. Though like MIchael S. said, the only way it can be empty 
is if PHP is behaving badly.
2013-03-09 19:09:41 Michael Rubinsky Comment #13 Reply to this comment

[Show Quoted Text - 19 lines]
Something along the lines of:

if (empty($GLOBALS['injector'])) {
     Horde::debug('WTF???');
}

will log the backtrace in a horde_debug.txt file located in your tmp 
directory. Though like MIchael S. said, the only way it can be empty 
is if PHP is behaving badly.
2013-03-09 18:31:01 arjen+horde (at) de-korte (dot) org Comment #12 Reply to this comment
Anyway... I can't reproduce with Turba's browse.php.  So you need to 
debug WHY the global injector value is empty (since according to the 
code there appears to be no possible way this could happen).
I'm seeing the same thing happening here too. If I change line 65 in 
/usr/share/php5/PEAR/Horde.php

from
         if (Horde_Core_Factory_Logger::available()) {
to
         if (isset($GLOBALS['injector']) && 
Horde_Core_Factory_Logger::available()) {

all is well again.

This check was performed in Horde_Core-2.4.1, but was removed in 
Horde_Core-2.4.2. So apparently the global injector value can be 
empty. I'd love to provide a backtrace, but I lack the knowledge how 
to. What code needs to be inserted here to provide a backtrace?

I'm using php5-5.3.22 by the way (the current openSUSE package).
2013-03-09 17:40:32 Michael Slusarz Comment #11
Priority ⇒ 1. Low
Reply to this comment
How can it be php messed up, if it used to work with the previous 
version of horde_core package.??
Not sure what this has to do with anything.  Things can be messed up 
and you wouldn't know about it until code triggers it.  So changing 
code that causes it to trigger doesn't mean the new code is broken.

Anyway... I can't reproduce with Turba's browse.php.  So you need to 
debug WHY the global injector value is empty (since according to the 
code there appears to be no possible way this could happen).
2013-03-09 16:18:52 csoft2k5 (at) gmail (dot) com Comment #10 Reply to this comment
Tried all that still no luck. I'm not using APC, only memcached. How 
can it be php messed up, if it used to work with the previous version 
of horde_core package.??
2013-03-09 15:45:30 Michael Slusarz Comment #9 Reply to this comment
Otherwise, this makes absolutely zero sense.  The ONLY way for 
$registry->hordeInit to be non-empty is if it is set in 
Horde_Registry.  And injector is declared (and made global) 40 lines 
above it in that file.  So the other option is that your PHP is really 
messed up (restarting PHP might also be a good idea to clear any 
potential APC related issues).
2013-03-09 15:40:28 Michael Slusarz Comment #8 Reply to this comment
Clear out your cache (Horde_Cache backend).  From command-line:

horde/bin/horde-clear-cache (might have to run as superuser/privileged 
user if your cache backend is owned by a different user than yours)
2013-03-09 15:29:54 csoft2k5 (at) gmail (dot) com Comment #7 Reply to this comment
Doesn't help, still getting a blank page.
2013-03-09 15:19:19 Michael Rubinsky Comment #6 Reply to this comment
In what file is that function located ??  I don't see it in horde.php.
Sorry, it's in Core/Factory/Logger.php. Comment out either line 128 or 
line 148.

2013-03-09 15:14:15 csoft2k5 (at) gmail (dot) com Comment #5 Reply to this comment
In what file is that function located ??  I don't see it in horde.php.
2013-03-09 14:39:05 Michael Rubinsky Comment #4
Assigned to Michael Rubinsky
Assigned to Michael Slusarz
State ⇒ Feedback
Priority ⇒ 2. Medium
Reply to this comment
I'm not seeing this. I've tried all kinds of actions within Turba. Can 
you provide a backtrace?

I have a nagging suspicion that it's being caused by 
Horde_Core_Factory_Logger::processQueue(). If you comment out the 
register_shutdown_function() call, does this go away?


2013-03-09 06:30:29 csoft2k5 (at) gmail (dot) com Comment #3 Reply to this comment
Replacing the horde.php file from horde_core-2.4.1 package seems to 
solve the problem.  So there is something wrong with the changes in   
the latest horde_core package.
2013-03-09 03:52:20 csoft2k5 (at) gmail (dot) com Comment #2 Reply to this comment
Here are some errors in the httpd's log since the update:

[Sat Mar 09 05:18:20 2013] [error] [client xx.xx.xx.xx] PHP Fatal 
error:  Call to a member function getInstance() on a non-object in 
/usr/share/pear/Horde.php on line 76, referer: https://xxx/imp/
[Sat Mar 09 05:18:23 2013] [error] [client xx.xx.xx.xx] PHP Fatal 
error:  Call to a member function getInstance() on a non-object in 
/usr/share/pear/Horde.php on line 76, referer: https://xxx/imp/
[Sat Mar 09 05:18:25 2013] [error] [client xx.xx.xx.xx] PHP Fatal 
error:  Call to a member function getInstance() on a non-object in 
/usr/share/pear/Horde.php on line 76, referer: https://xxx/imp/
[Sat Mar 09 05:18:56 2013] [error] [client xx.xx.xx.xx] PHP Fatal 
error:  Call to a member function getInstance() on a non-object in 
/usr/share/pear/Horde.php on line 76, referer: https://xxx/imp/
[Sat Mar 09 05:21:09 2013] [error] [client xx.xx.xx.xx] PHP Fatal 
error:  Call to a member function getInstance() on a non-object in 
/usr/share/pear/Horde.php on line 76, referer: 
https://mail.autoadria.ro/services/portal/
[Sat Mar 09 05:23:12 2013] [error] [client xx..xx.xx.xx] PHP Fatal 
error:  Call to a member function getInstance() on a non-object in 
/usr/share/pear/Horde.php on line 76, referer: https://xxx/turba/
[Sat Mar 09 05:23:14 2013] [error] [client xx.xx.xx.xx] PHP Fatal 
error:  Call to a member function getInstance() on a non-object in 
/usr/share/pear/Horde.php on line 76, referer: https://xxx/turba/
[Sat Mar 09 05:26:34 2013] [error] [client xx.xx.xx.xx] PHP Fatal 
error:  Call to a member function getInstance() on a non-object in 
/usr/share/pear/Horde.php on line 76, referer: https://xxx/turba/
[Sat Mar 09 05:28:02 2013] [error] [client xx.xx.xx.xx] PHP Fatal 
error:  Call to a member function getInstance() on a non-object in 
/usr/share/pear/Horde.php on line 76, referer: 
https://xxx/services/portal/
[Sat Mar 09 05:28:44 2013] [error] [client xx.xx.xx.xx] PHP Fatal 
error:  Call to a member function getInstance() on a non-object in 
/usr/share/pear/Horde.php on line 76, referer: 
https://xxx/turba/search.php
2013-03-09 03:07:05 csoft2k5 (at) gmail (dot) com Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ Blank page on browsing turba address books
Queue ⇒ Turba
Milestone ⇒
Patch ⇒ No
Reply to this comment
Hi. Since the latest update to horde_core package, I'm getting a blank 
page when I try to browse turba's address books. Other options like 
adding a new contact, searching for one seems to work. Also the 
autocompleter on IMP works too. I'm using a localsql backend for turba 
shares and also I've cleared the browser's cache and the horde cache, 
but still getting a blank page. In logs there is nothing about the 
error.

Saved Queries