php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #50027 $this becomes a non-object
Submitted: 2009-10-28 09:05 UTC Modified: 2011-09-08 10:31 UTC
Votes:11
Avg. Score:4.1 ± 1.0
Reproduced:7 of 9 (77.8%)
Same Version:2 (28.6%)
Same OS:0 (0.0%)
From: phpbugs at colin dot guthr dot ie Assigned: dmitry (profile)
Status: Closed Package: Scripting Engine problem
PHP Version: 5.3.1RC2 OS: Mandriva Linux (Cooker x86_64)
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: phpbugs at colin dot guthr dot ie
New email:
PHP Version: OS:

 

 [2009-10-28 09:05 UTC] phpbugs at colin dot guthr dot ie
Description:
------------
This is a really hard bug to reproduce (e.g. build a simple test case) but I can reliably do so here with my application. I'll attempt to describe the problem in depth, although I warn in advance that it's a bit of a confusing one.

During a particular request, PHP seems to corrupt itself quite badly which cases $this to become corrupted within an object.

When this happens, is_object($this) still returns true, but any attempt to access a member variable (e.g. $this->mFuncs) will result in the "Notice: Trying to get property of non-object" warning. Similar warning exist when trying to call methods etc.

Once this corruption happens, it will remain until the Apache process is restarted (mpm-prefork) although some requests will succeed (I presume it depends what mpm-preforked httpd handler is used?). When this happens, a much simpler test case (which I'll link to) fails also (i.e. it seems that the initial trigger of this causes it to continue, but the simpler test case itself does not seem enough to trigger it initially).

The trigger case I have is a rather complex Zend Framework application that I sadly cannot share.

I have confirmed this problem is present on 5.3.0 and 5.3.1RC2, so I suspect it's a 5.3.x problem over all. I cannot reproduce the problem on 5.2.11.

All builds use -O0 for optimisations (as higher values have proven to cause problems, particularly on x86_64).

Reproduce code:
---------------
A tarball containing three PHP files: one a UniversalAutoloader structure we use in our projects (it predates spl stuff and actually gives us a different fallback mechanism anyway), and a simple test class that is meant to be autoloaded. Then the test.php file which actually exhibits the bug.

As noted previously however, this test case only *exhibits* this bug if the problem is triggered already by some other code. You can see from the backtrace.txt the effect of it failing. I provide this in the hope that it allows something obvious to jump out at you, but I suspect the problem is really some form of stack frame corruption or similar (possibly due to x86_64 as I've not tested to see if it affects 5.3.1 although I will be able to do so in the coming weeks).

The URL for this bundle is: http://colin.guthr.ie/php-bug.tar

Expected result:
----------------
It should just echo "Foo\n". But as you can see the Notice is triggered and the is_array() check fails (as can be seen, it is impossible for the variable to be anything other than an array).

Actual result:
--------------
*After* triggering the problem, $this becomes a non-object (although in other tests (is_object($this) still returns true).

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-11-03 10:57 UTC] jani@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.


 [2009-11-04 08:43 UTC] phpbugs at colin dot guthr dot ie
I knew you were going to say that Jani :p

As I said on the original mail, even my simple test is not sufficient to trigger this.

Sadly I'm not sure if I can create such a test script, but I will certainly try. It may take me a few days to come up with something and it's most likely that it will not be a simple application (my current trigger case is part of the Zend Framework and I have no real desire to dissect that!)

Give me a week or two.
 [2009-11-04 10:40 UTC] jani@php.net
Leave the report in "Feedback" (requested) status until you have that script around. (do not reply before that ;)
 [2009-11-11 11:36 UTC] phpbugs at colin dot guthr dot ie
(Hopefully this will not reset the Feedback status).

I've tried this on a similar i586 machine and cannot reproduce the problem, this leads me to believe the problem is indeed x86_64 related. I will try and obtain access to another x86_64 machine to reproduce the problem there too.

If the bug status changes, please put it back to Feedback.
 [2009-11-12 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2009-12-16 08:09 UTC] lukas at twobits dot cz
We're affected with the same bug - 5.3.1, Fedora Core 8, 32bit, Apache 2.2.6.

This happens suddenly after few days of normal operation - then some of the Apache requests end up with $this not defined inside an object instance. Normal operation is resumed after Apache is restarted.

We never encountered this problem on 5.3.0 (used for over a month), though I am not saying its not there as lots of our code changed meanwhile as well.
 [2009-12-16 08:11 UTC] rasmus@php.net
Does this happen with gc turned off?

Try adding:

zend.enable_gc = Off

to your php.ini file.
 [2009-12-16 08:53 UTC] lukas at twobits dot cz
I switched the gc off, will provide feedback in about a week.
 [2010-01-04 12:22 UTC] lukas at twobits dot cz
We now have about three weeks of successful operation with zend.enable_gc = Off

I assume it is safe to say that this bug indeed is GC related.
 [2010-04-27 13:08 UTC] phpbugs at colin dot guthr dot ie
I'm curious as to why this bug is set to "No Feedback"... Lukas has provided more information about the topic to nail it down to a Garbage Collection issue.

I will try and upgrade sometime soon on my development machine to see if I can retrigger the problem, but in the meantime, has there been any progress? Are there now some potentially duplicate bugs and even a fix? Does the issue still cause you problems Lukas?

Thanks :)
 [2010-04-28 09:47 UTC] lukas at twobits dot cz
I am unfortunately unable to provide more feedback except that we have never encountered this problem again with GC off. We have now been using 5.3.2. If we decide to test it with the garbage collector one once again, I'll provide some more feedback.
 [2010-04-28 10:05 UTC] aharvey@php.net
-Status: No Feedback +Status: Open
 [2010-04-28 10:05 UTC] aharvey@php.net
The way this bug tracker works is that the bug doesn't get automatically re-opened from the Feedback status when someone posts a comment; it's only if the original reporter or a PHP developer actually resets it to Open.

Reopening, anyway, since feedback was provided.
 [2010-05-15 19:06 UTC] phpbugs at colin dot guthr dot ie
Just for reference, I just tested and this bug is still a problem with 5.3.2.
 [2010-11-10 15:44 UTC] lukas at twobits dot cz
Bad news. Just got the same bug again, with PHP 5.3.3 and GC switched OFF. Again, only one Apache process fails. The process begun failing immediately after Apache restart. A simple reproduce class:

Reproduce code:
---------------
class Test
{

        private $data = NULL;

        public function __construct($data)
        {
                echo "<pre>";
                var_dump($this);
                echo "</pre>";
                $this->data = $data;
        }

        public function getData()
        {
                echo "<pre>";
                var_dump($this);
                echo "</pre>";
                return $this->data;
        }
}

echo "PID: " . getmypid();

$foo = new Test('Hello');

echo $foo->getData();


Correct output:
---------------
PID: 22839
object(Test)#1 (1) {
  ["data":"Test":private]=>
  NULL
}
object(Test)#1 (1) {
  ["data":"Test":private]=>
  string(5) "Hello"
}
Hello

Malfunctioning Apache process output:
-------------------------------------
PID: 22818
object(Test)#1 (1) {
  ["data":"Test":private]=>
  NULL
}
Warning: Attempt to assign property of non-object in /var/www/html/testthis.php on line 16 
object(Test)#1 (1) {
  ["data":"Test":private]=>
  NULL
}
 [2010-11-16 09:38 UTC] bsteinbrink at saltation dot de
We encountered this bug yesterday (we could reproduce it quite easily with our code, but unfortunately we cannot disclose it), debugged it, found out that it was due to the GC corrupting the std_object_handlers prototype and once we knew that, we checked with the svn repo and saw that that was fixed in r303016.

The corruption that happens is that the read_property field of std_object_handlers gets set to NULL, because the GC treated the handler as a zval.

The report from lukas about the failure to set a property seems like an independent bug, as a different field got corrupted (and he had the gc turned off anyway).
 [2010-11-16 11:10 UTC] phpbugs at colin dot guthr dot ie
So far so good! I updated to PHP 5.3.3 again and reproduced the error (and got four nice core dumps), then applied the patch and tried to reproduce again and so far, I'm coreless.

Thanks for highlighting the patch. Just with this bug had lead to more investigations earlier as I've had to jump through hoops to avoid updating to PHP 5.3.x because of this problem. Still hopefully looking good now :)
 [2011-01-16 22:10 UTC] stas@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: stas
 [2011-01-16 22:10 UTC] stas@php.net
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.


 [2011-01-16 22:11 UTC] stas@php.net
-Package: Reproducible crash +Package: Scripting Engine problem -Assigned To: stas +Assigned To: dmitry
 [2011-09-07 23:38 UTC] brian dot feaver at sellingsource dot com
Looking through the SVN log and the change log for releases since this was fixed, 
I can't find when this was released, nor the commit to SVN that fixed it.

What commit fixed it and what release was this fixed in?
 [2011-09-08 10:31 UTC] phpbugs at colin dot guthr dot ie
The revision was mentioned a few comments back: r303016

http://svn.php.net/viewvc?view=revision&revision=303016
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/Zend/zend_gc.c?r1=297307&r2=303016&pathrev=303016


According to the log:
http://svn.php.net/viewvc/php/php-src/tags/php_5_3_4/Zend/zend_gc.c?view=log

This was included in PHP 5.3.4.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Nov 23 08:01:28 2024 UTC