"PHP Fatal error: Cannot access parent:: when current class scope has no parent" in PHP_5_2

I'm not able to reproduce this. Can you give us a piece of code to reproduce this.

I cannot reproduce it either, but just had it happen with PHP_5_1 and eaccelerator (also after updating to HEAD).

What I can say so far: The error

PHP Fatal error:  Cannot access parent:: when current class scope has no parent in /X/inc/MODEL/comments/_comment.class.php on line 113

line 113 is the "parent::" call in this block:

        /**
         * Constructor
         */
        function Comment( $db_row = NULL )
        {
                // Call parent constructor:
                parent::DataObject( 'T_comments', 'comment_', 'comment_ID' );

- If I touch the file, the error does not happen on the next reload

- There's a require_once at the beginning of the file, which requires the file where the parent class resides:

require_once dirname(__FILE__).'/../dataobjects/_dataobject.class.php';

- After the error has been triggered, I commented this line out and got a new "CACHED" for the file, but a totally blank page from PHP! Every page then on that site was blank! There was nothing in the server's error log, but only the "EACCELERATOR hit" entries.

- I've then commented this line out (the file gets required somewhere else before) and restarted Apache. Then the same "parent::"-error occurred with another class file which follows the same scheme (class Item instead of Comment). Commenting the line out there and restarting Apache then, showed up the same error in another class file (Blog). Removing it there then showed a blank page again.

It's definitely related to this "DataObject?" class and the way the subclasses get loaded.

Because the application is quite huge (b2evolution 1.9-dev), I fear this is hard to track down.

But perhaps you can give me some hints what I should try to isolate it.

In fact, the "blank page without an entry in the error log" looks like a fatal error which gets suppressed by "@", and it may in fact be the one in front of "unserialize" in this code part:

$old_callback = ini_get( 'unserialize_callback_func' );
ini_set( 'unserialize_callback_func', 'session_unserialize_callback' );
$this->_data = @unserialize($row->sess_data);
ini_set( 'unserialize_callback_func', $old_callback );

session_unserialize_callback looks like:

function session_unserialize_callback( $classname )
{
	global $model_path, $object_def;

	switch( strtolower($classname) )
	{
		case 'blog':
			require_once $model_path.'collections/_blog.class.php';
			return true;

		case 'collectionsettings':
			require_once $model_path.'collections/_collsettings.class.php';
			return true;

		case 'comment':
			require_once $model_path.'comments/_comment.class.php';
			return true;

		case 'item':
			require_once $model_path.'items/_item.class.php';
			return true;

		case 'group':
			require_once $model_path.'users/_group.class.php';
			return true;

		case 'user':
			require_once $model_path.'users/_user.class.php';
			return true;
	}

	return false;
}

In fact, the Comment object gets stored in the user's session ($row->sess_data) when previewing it and that's the point where I can somehow reproduce it.

1. Restart Apache
2. Display a page with Comments
3. Do the preview
4. When the Comment object taken out of the unserialized Session data gets accessed, it bails out - not during unserializing, but "in the middle of the page".

It does not happen, if there's a Comment being unserialized from session data on the request that caches the Comment (and DataObject?) classes (e.g. have a Comment in session data, restart apache, access page => it displays the preview (and all others) fine afterwards).

Sorry for this "weird" report, but I think more information is better..

I'll look into making a simple test case, if you want - but maybe you know where to look for the bug now already.

My config is quite basic:

eaccelerator.shm_only=1
eaccelerator.debug=1

( The code's project can be viewed here in detail: http://evocms.cvs.sourceforge.net/evocms/b2evolution/blogs/?pathrev=v-1-9 )

Thanks for your patience.. :)

hi eAccelerator theam and blueyed,

i have the same problem whit any mediawiki1.7 installations on debian etch (5-6 installations on x86 and amd64)

the problem is the login button and only the login ;/ and it is random!!

on dey workt it 2-24h on the next dey 2 min... and then come the bug

 Fatal error: Cannot access parent:: when no class scope is active in /usr/share/mediawiki1.7/includes/SkinTemplate.php on line 108

the code snipsel form the SkinTemplate?.php

       function initPage( &$out ) {
                parent::initPage( $out );   // this is line 108
                $this->skinname  = 'monobook';
                $this->stylename = 'monobook';
                $this->template  = 'QuickTemplate';
        }

this is my eaccelerator.ini

 extension=eaccelerator.so
 eaccelerator.shm_size="32"
 eaccelerator.enable="1"
 eaccelerator.optimizer="1"
 eaccelerator.check_mtime="1"
 eaccelerator.debug="0"
 eaccelerator.filter="!*SkinTemplate.php"
 eaccelerator.shm_max="0"
 eaccelerator.shm_ttl="10800"
 eaccelerator.shm_prune_period="0"
 eaccelerator.shm_only="1"
 eaccelerator.compress="1"
 eaccelerator.compress_level="9"
 eaccelerator.allowed_admin_path="/var/www/admin/"

 eaccelerator.keys     = "shm_only"
 eaccelerator.sessions = "shm_only"
 eaccelerator.content  = "shm_only"

eaccelerator.filter="!*SkinTemplate.php"

is to fix the problem temporera

eaccelerator i have testet the curent trunk #285 and branch 0.9.5 and PHP_5_1

on the follow php versions

debian etch/testing x86 amd64
php5-cgi 5.2.0-7
libapache2-mod-php5 5.2.0-7

debian unstable x86
php5-cgi 5.2.0-8

all have the same problem ;/

i have no idea to reproduce this. ;/ it is extrem randomly on low and high last

ps: the php-cgi is runing as fcgid on this test's libapache2-mod-fcgid 2.0-1

sorry no edit button ;/

This is the same bug as we are tracking in bug #199. I'm going to close this bug here because #199 contains more usefull test cases.