Bug #50027 [Csd]: $this becomes a non-object
Edit report at https://bugs.php.net/bug.php?id=50027edit=1
ID: 50027
User updated by:phpbugs at colin dot guthr dot ie
Reported by:phpbugs at colin dot guthr dot ie
Summary:$this becomes a non-object
Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: Mandriva Linux (Cooker x86_64)
PHP Version:5.3.1RC2
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The revision was mentioned a few comments back: r303016
http://svn.php.net/viewvc?view=revisionrevision=303016
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/Zend/zend_gc.c?r1=297307r2=303016pathrev=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.
Previous Comments:
[2011-09-07 23:38:55] 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-01-16 22:10:12] s...@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.
[2010-11-16 11:10:35] 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 :)
[2010-11-16 09:38:23] 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-10 15:44:51] 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
}
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=50027
--
Edit this bug report at https://bugs.php.net/bug.php?id=50027edit=1
Bug #50027 [Com]: $this becomes a non-object
Edit report at http://bugs.php.net/bug.php?id=50027edit=1
ID: 50027
Comment by: phpbugs at colin dot guthr dot ie
Reported by:phpbugs at colin dot guthr dot ie
Summary:$this becomes a non-object
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Mandriva Linux (Cooker x86_64)
PHP Version:5.3.1RC2
Block user comment: N
Private report: N
New Comment:
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 :)
Previous Comments:
[2010-11-16 09:38:23] 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-10 15:44:51] 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-05-15 19:06:58] 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-04-28 10:05:16] ahar...@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-04-28 09:47:53] 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.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=50027
--
Edit this bug report at http://bugs.php.net/bug.php?id=50027edit=1
Bug #50027 [Opn]: $this becomes a non-object
Edit report at http://bugs.php.net/bug.php?id=50027edit=1 ID: 50027 User updated by: phpbugs at colin dot guthr dot ie Reported by: phpbugs at colin dot guthr dot ie Summary: $this becomes a non-object Status: Open Type: Bug Package: Reproducible crash Operating System: Mandriva Linux (Cooker x86_64) PHP Version: 5.3.1RC2 New Comment: Just for reference, I just tested and this bug is still a problem with 5.3.2. Previous Comments: [2010-04-28 10:05:16] ahar...@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-04-28 09:47:53] 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-27 13:08:07] 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-01-04 12:22:00] 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. [2009-12-16 08:53:15] lukas at twobits dot cz I switched the gc off, will provide feedback in about a week. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=50027 -- Edit this bug report at http://bugs.php.net/bug.php?id=50027edit=1
Bug #50027 [Com]: $this becomes a non-object
Edit report at http://bugs.php.net/bug.php?id=50027edit=1 ID: 50027 Comment by: phpbugs at colin dot guthr dot ie Reported by: phpbugs at colin dot guthr dot ie Summary: $this becomes a non-object Status: No Feedback Type: Bug Package: Reproducible crash Operating System: Mandriva Linux (Cooker x86_64) PHP Version: 5.3.1RC2 New Comment: 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 :) Previous Comments: [2010-01-04 12:22:00] 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. [2009-12-16 08:53:15] lukas at twobits dot cz I switched the gc off, will provide feedback in about a week. [2009-12-16 08:11:52] ras...@php.net Does this happen with gc turned off? Try adding: zend.enable_gc = Off to your php.ini file. [2009-12-16 08:09:06] 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-11-12 01:00:02] 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. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=50027 -- Edit this bug report at http://bugs.php.net/bug.php?id=50027edit=1
#50027 [Com]: $this becomes a non-object
ID: 50027 Comment by: phpbugs at colin dot guthr dot ie Reported By: phpbugs at colin dot guthr dot ie Status: Feedback Bug Type: Reproducible crash Operating System: Mandriva Linux (Cooker x86_64) PHP Version: 5.3.1RC2 New Comment: (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. Previous Comments: [2009-11-04 10:40:12] j...@php.net Leave the report in Feedback (requested) status until you have that script around. (do not reply before that ;) [2009-11-04 08:43:49] 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-03 10:57:43] j...@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-10-28 09:05:14] 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). -- Edit this bug report at http://bugs.php.net/?id
#50027 [Fbk-Opn]: $this becomes a non-object
ID: 50027 User updated by: phpbugs at colin dot guthr dot ie Reported By: phpbugs at colin dot guthr dot ie -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Mandriva Linux (Cooker x86_64) PHP Version: 5.3.1RC2 New Comment: 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. Previous Comments: [2009-11-03 10:57:43] j...@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-10-28 09:05:14] 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). -- Edit this bug report at http://bugs.php.net/?id=50027edit=1
#50027 [NEW]: $this becomes a non-object
From: phpbugs at colin dot guthr dot ie Operating system: Mandriva Linux (Cooker x86_64) PHP version: 5.3.1RC2 PHP Bug Type: Reproducible crash Bug description: $this becomes a non-object 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). -- Edit bug report at http://bugs.php.net/?id=50027edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50027r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50027r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50027r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50027r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50027r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50027r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50027r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50027r=needscript Try newer version: http://bugs.php.net/fix.php?id=50027r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50027r=support Expected behavior: http://bugs.php.net/fix.php?id=50027r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50027r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50027r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50027r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50027r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50027r=dst IIS Stability: http://bugs.php.net/fix.php?id=50027r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50027r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50027r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50027r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50027r=mysqlcfg
#45996 [Asn]: libxml2 2.7.1 causes breakage with character data in xml_parse()
ID: 45996 User updated by: phpbugs at colin dot guthr dot ie Reported By: phpbugs at colin dot guthr dot ie Status: Assigned Bug Type: XML related Operating System: Mandriva Linux PHP Version: 5.2.6 Assigned To: rrichards New Comment: If the Fedora packages do not work then this is a RedHat packaging problem and you should complain to them/open a bug etc. etc. Like I say, in Mandriva we made sure we provided packages that worked because they were compiled with expat. Previous Comments: [2009-01-01 19:31:49] alex at peoples dot ru Thanks for advice, but I'm not guru in the Linux, as I haven't cpanel on my server. I tried use 'yum remove' libxml2 and add new, but off course this is stupid and doesn't work. I liked Linux, as the easiest and powerful system, but now, I'm stock. I haven't any idea how I can remove libxml2 and build new system with old one. One idea - change system on Fedora 9, because FC 10 have the same bug with fucking libxml2. Sorry, I was at Data Center 8 hours and I had problem with servers with new system. I don't like updates now... they have bugs every where, and I'm tiered resolve this bugs. Sorry, Have a Happy New Year. I'll never ever will update my systems less when half year. [2008-12-31 15:22:17] scott...@php.net Guys please READ the report, this is a bug in libxml NOT a bug in PHP. [2008-12-31 14:35:13] hougiwro at guerrillamail dot org Why not just fix the bug so that existing installs can pick up a standard update without having to rebuild the program. Not everyone using PHP is necessarily comfortable with recompiling it in order to implement a workaround for a bug. [2008-12-31 13:37:17] phpbugs at colin dot guthr dot ie If you are on a shared host with a fixed PHP version then really the host should be responsible for deploying a well packaged version of PHP. If they are not doing that it is the host that is at fault and you should raise the issue with them. [2008-12-31 00:56:58] mark at mcclusky dot com I understand that there are workarounds to this bug, but for those of us on shared hosts that we can't recompile, this is a colossally frustrating state of affairs. Does anyone in PHP land have any timeline for a fix? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/45996 -- Edit this bug report at http://bugs.php.net/?id=45996edit=1
#45996 [Asn]: libxml2 2.7.1 causes breakage with character data in xml_parse()
ID: 45996 User updated by: phpbugs at colin dot guthr dot ie Reported By: phpbugs at colin dot guthr dot ie Status: Assigned Bug Type: XML related Operating System: Mandriva Linux PHP Version: 5.2.6 Assigned To: rrichards New Comment: If you are on a shared host with a fixed PHP version then really the host should be responsible for deploying a well packaged version of PHP. If they are not doing that it is the host that is at fault and you should raise the issue with them. Previous Comments: [2008-12-31 00:56:58] mark at mcclusky dot com I understand that there are workarounds to this bug, but for those of us on shared hosts that we can't recompile, this is a colossally frustrating state of affairs. Does anyone in PHP land have any timeline for a fix? [2008-12-29 17:02:44] jeffrey dot roberts at ibsgroup dot org For those as challenged as me at determining how to either downgrade libxml2 or recompile with libexpat while using cPANEL (easyapache), here is a link to the details. I confirm that after recompiling it is a workaround for the problem. http://blog.code-head.com/fixing-libxml-php-bug-and-issues-with-html-entities-libexpat First you will need to find out where libexpat is located on your server, it¡¯s probably here: /usr/lib To find out for sure, open this folder (/usr/lib) and look for the file: libexpat.so If you can¡¯t find it, log in as root via SSH and enter: whereis libexpat.so This should list the folder in which libexpat is located. After all this you will need to compile PHP to use libexpat instead of libxml, so go to: /var/cpanel/easy/apache/rawopts/ And create a file and name it ¡°all_php5¡å (no quotes), if there is a file with this name edit it and add these lines to the end of it: ¨Cwith-expat=builtin ¨Cwith-libexpat-dir=/usr/lib (lines start with two dashes ¡°-¡± that are not showing up here for some reason) Remember that depending on where libexpat is located on your server you might need to edit the second line. Now compile Apache and everything should work fine! [2008-12-28 13:37:13] phpbugs at colin dot guthr dot ie While I do not doubt that this is an annoying bug, there are very simple and clear workarounds. I'm really not seeing why everyone is so upset about this. I reported the bug and we fixed the Mandriva package almost immediately with the work around and I'm not aware of any fallout from that change. [2008-12-28 03:55:04] alex at magnet dot ru 4 month!!! This is not serious?! [2008-12-25 02:41:10] gordon at kanazawa-gu dot ac dot jp This issue also affects Moodle backup+restore and HotPot module http://tracker.moodle.org/browse/MDL-17136 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/45996 -- Edit this bug report at http://bugs.php.net/?id=45996edit=1
#45996 [Asn]: libxml2 2.7.1 causes breakage with character data in xml_parse()
ID: 45996 User updated by: phpbugs at colin dot guthr dot ie Reported By: phpbugs at colin dot guthr dot ie Status: Assigned Bug Type: XML related Operating System: Mandriva Linux PHP Version: 5.2.6 Assigned To: rrichards New Comment: While I do not doubt that this is an annoying bug, there are very simple and clear workarounds. I'm really not seeing why everyone is so upset about this. I reported the bug and we fixed the Mandriva package almost immediately with the work around and I'm not aware of any fallout from that change. Previous Comments: [2008-12-28 03:55:04] alex at magnet dot ru 4 month!!! This is not serious?! [2008-12-25 02:41:10] gordon at kanazawa-gu dot ac dot jp This issue also affects Moodle backup+restore and HotPot module http://tracker.moodle.org/browse/MDL-17136 [2008-12-17 15:18:50] valli at icsurselva dot ch Where can I find the libxml2 patch? Does someone have a link to the libxml2 bug reporting tool which describes this issue? [2008-12-17 00:56:14] rricha...@php.net Does no one pay attention to the comments? The fix for this needs to happen on the libxml2 layer. The next version of libxml2 should resolve this and this bug is being kept open only in case some modification to the extension also needs to occur with the fix. [2008-12-17 00:49:19] scott...@php.net Recompile with libexpat or downgrade libxml. One of those will sort you out. A change to libxml will be in the next release, though the patch isn't in their repository yet. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/45996 -- Edit this bug report at http://bugs.php.net/?id=45996edit=1
#45996 [Asn]: libxml2 2.7.1 causes breakage with character data in xml_parse()
ID: 45996 User updated by: phpbugs at colin dot guthr dot ie Reported By: phpbugs at colin dot guthr dot ie Status: Assigned Bug Type: XML related Operating System: Mandriva Linux PHP Version: 5.2.6 Assigned To: rrichards New Comment: To build with expat just read my earlier posts on this bug where I've shown how we did this in our recent Mandriva 2009 release. Previous Comments: [2008-11-21 15:31:40] ajay12006 at gmail dot com I already have libxml 2.7.2 Can anyone help me how to build PHP with libxml2 = 2.6.32 or build ext/xml with expat.? Any link on how to so it? Thanks. [2008-11-20 22:37:34] rcasagraude at interfaces dot fr Confirm : build xml against libexpat workaround this bug [2008-11-05 16:30:35] [EMAIL PROTECTED] just use the example in the manual. Your change simply gets predefined entities working but breaks all other cases. I'm currently looking at getting the change in libxml2 that caused this reverted. The problem stems from the magic needed to emulate expat behavior as its not native in libxml so non-standard use of the libxml sax hooks was needed. [2008-11-05 16:13:17] [EMAIL PROTECTED] Rob, do you have a test case for the regression caused by my test patch, so I can look at that further? [2008-11-04 21:00:18] [EMAIL PROTECTED] This is still being worked on. Currently the only options are to build PHP with libxml2 = 2.6.32 or build ext/xml with expat. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/45996 -- Edit this bug report at http://bugs.php.net/?id=45996edit=1
#46568 [Opn-Csd]: Segfault on 64bit when chaining function calls that generate exceptions
ID: 46568 User updated by: phpbugs at colin dot guthr dot ie Reported By: phpbugs at colin dot guthr dot ie -Status: Open +Status: Closed Bug Type: Scripting Engine problem Operating System: * (64bit) PHP Version: 5.2.7RC3 New Comment: Thank you for your help Mr Rodriguez! The first CFLAGs option was sufficient to not trigger the segv. This is clearly not a problem of PHP and the problem obviously lies with the GCC in Mandriva. I'll raise the bug within our own systems for that. Thanks to everyone for their patience and effort in helping diagnose this issue. Previous Comments: [2008-11-19 05:22:00] crrodriguez at opensuse dot org Yes, it suggest that your compiler optimized badly.. try export CFLAGS=-O2 -fno-strict-aliasing and rebuild. if still crashes... try -O1.. [2008-11-18 21:20:43] phpbugs at colin dot guthr dot ie OK, I repeated the make test sans-debug and it seems that a couple more tests fail under this scenario. http://kenobi.mandriva.com/~colin/php_test_results_20081118_2054.txt The most interesting extra failure is: Bug #30707 (Segmentation fault on exception in method) [Zend/tests/bug30707.phpt] This could perhaps provide some clues? For convenience, here is a diff of non-debug vs. debug: http://kenobi.mandriva.com/~colin/php-make-test.diff.txt [2008-11-18 20:46:09] phpbugs at colin dot guthr dot ie Just tried --enable-debug and when built this way, it does indeed work as expected. Does this suggest anything else I can try to narrow down the problem. I also tried make test and did get several failures. I uploaded the test results to http://kenobi.mandriva.com/~colin/php_test_results_20081118_2006.txt although none of these look particularly relevant. I will do another build sans --enable-debug and see if any different standard tests fail. [2008-11-18 18:11:21] crrodriguez at opensuse dot org Did you built 5.2.7RC3 with --enable-debug ? if not, try that, does it crash anyway ? [2008-11-18 17:36:56] phpbugs at colin dot guthr dot ie Thanks for all the feedback/help. I will have to investigate further. I do not think my system hardware is at fault due to having confirmed on two other machines, although both Mandriva based. This is why I suspected the compiler. I will try and work out more info. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/46568 -- Edit this bug report at http://bugs.php.net/?id=46568edit=1
#46568 [Csd]: Segfault on 64bit when chaining function calls that generate exceptions
ID: 46568 User updated by: phpbugs at colin dot guthr dot ie Reported By: phpbugs at colin dot guthr dot ie Status: Closed Bug Type: Scripting Engine problem Operating System: * (64bit) PHP Version: 5.2.7RC3 New Comment: Actually for clarity in my further dealing with this problem, can you tell me if the OpenSuse builds used -fno-strict-aliasing or not? If it is compiled with -O2 -fstrict-aliasing and does not exhibit the bug it would be easier for me to point the finger at our gcc build. Thanks. Previous Comments: [2008-11-19 09:36:50] phpbugs at colin dot guthr dot ie Thank you for your help Mr Rodriguez! The first CFLAGs option was sufficient to not trigger the segv. This is clearly not a problem of PHP and the problem obviously lies with the GCC in Mandriva. I'll raise the bug within our own systems for that. Thanks to everyone for their patience and effort in helping diagnose this issue. [2008-11-19 05:22:00] crrodriguez at opensuse dot org Yes, it suggest that your compiler optimized badly.. try export CFLAGS=-O2 -fno-strict-aliasing and rebuild. if still crashes... try -O1.. [2008-11-18 21:20:43] phpbugs at colin dot guthr dot ie OK, I repeated the make test sans-debug and it seems that a couple more tests fail under this scenario. http://kenobi.mandriva.com/~colin/php_test_results_20081118_2054.txt The most interesting extra failure is: Bug #30707 (Segmentation fault on exception in method) [Zend/tests/bug30707.phpt] This could perhaps provide some clues? For convenience, here is a diff of non-debug vs. debug: http://kenobi.mandriva.com/~colin/php-make-test.diff.txt [2008-11-18 20:46:09] phpbugs at colin dot guthr dot ie Just tried --enable-debug and when built this way, it does indeed work as expected. Does this suggest anything else I can try to narrow down the problem. I also tried make test and did get several failures. I uploaded the test results to http://kenobi.mandriva.com/~colin/php_test_results_20081118_2006.txt although none of these look particularly relevant. I will do another build sans --enable-debug and see if any different standard tests fail. [2008-11-18 18:11:21] crrodriguez at opensuse dot org Did you built 5.2.7RC3 with --enable-debug ? if not, try that, does it crash anyway ? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/46568 -- Edit this bug report at http://bugs.php.net/?id=46568edit=1
#46568 [Fbk-Opn]: Segfault on 64bit when chaining function calls that generate exceptions
ID: 46568
User updated by: phpbugs at colin dot guthr dot ie
Reported By: phpbugs at colin dot guthr dot ie
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: * (64bit)
PHP Version: 5.2.7RC3
New Comment:
Thanks for all the feedback/help. I will have to investigate further. I
do not think my system hardware is at fault due to having confirmed on
two other machines, although both Mandriva based. This is why I
suspected the compiler.
I will try and work out more info.
Previous Comments:
[2008-11-18 17:23:16] crrodriguez at opensuse dot org
Cannot reproduce,in opensuse 11 64 bit , GCC 4.3.1 either with or
without suhosin.
I suspect either your system or your compiler is doing something wrong.
[2008-11-17 21:51:09] phpbugs at colin dot guthr dot ie
My configure line is just the default. All I did was pass a custom
prefix.
I'll try and find some other 64 bit systems to play on. I should be
able to fire a few different systems into a vm to see if I can reproduce
it with other distros.
[2008-11-17 10:18:57] [EMAIL PROTECTED]
I can not reproduce this within x86_64 Centos 5 using latest PHP_5_2
checkout. Would be nice to know your configure line for PHP too..?
[2008-11-16 08:03:46] bruno at ioda dot net
I've try this on 3 differents openSUSE 10.3 all with the lastest
opensuse build services php version 5.2.6.
And the result was the expected exception
Fatal error: Uncaught exception 'Exception' with message 'Wibble' in
/tmp/bugs.php:10
Stack trace:
#0 /tmp/bugs.php(14): foo-wibble()
#1 /tmp/bugs.php(23): foo-bug()
#2 {main}
thrown in /tmp/bugs.php on line 10
PHP 5.2.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Nov 5 2008
13:42:52)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH
For 10.3 gcc is :
Target: x86_64-suse-linux
Configuré avec: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.2.1
--enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--program-suffix=-4.2 --enable-version-specific-runtime-libs
--without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux
Modèle de thread: posix
version gcc 4.2.1 (SUSE Linux)
I've not yet try on the lastest 11.0 x64 which have the gcc
gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision
135036] (SUSE Linux)
[2008-11-13 22:41:05] phpbugs at colin dot guthr dot ie
Well I've confirmed this problem on three Mandriva systems with
Mandriva packages but for this bug report I built a fresh vanilla
version from the 5.2.7rc3 tarball on my own machine to ensure it was
nothing to do with any additional patches in the Mandriva package
causing the problem.
I do not have access to any non-Mandriva 64 bit build hosts here to do
more tests...
FWIW, the GCC version is 4.3.2.
I can tarball up the installed version if you want to give my build a
run and see if it crashes on your machine. If it does crash then I'd
expect the problem to be related to GCC.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/46568
--
Edit this bug report at http://bugs.php.net/?id=46568edit=1
#46568 [Opn]: Segfault on 64bit when chaining function calls that generate exceptions
ID: 46568 User updated by: phpbugs at colin dot guthr dot ie Reported By: phpbugs at colin dot guthr dot ie Status: Open Bug Type: Scripting Engine problem Operating System: * (64bit) PHP Version: 5.2.7RC3 New Comment: Just tried --enable-debug and when built this way, it does indeed work as expected. Does this suggest anything else I can try to narrow down the problem. I also tried make test and did get several failures. I uploaded the test results to http://kenobi.mandriva.com/~colin/php_test_results_20081118_2006.txt although none of these look particularly relevant. I will do another build sans --enable-debug and see if any different standard tests fail. Previous Comments: [2008-11-18 18:11:21] crrodriguez at opensuse dot org Did you built 5.2.7RC3 with --enable-debug ? if not, try that, does it crash anyway ? [2008-11-18 17:36:56] phpbugs at colin dot guthr dot ie Thanks for all the feedback/help. I will have to investigate further. I do not think my system hardware is at fault due to having confirmed on two other machines, although both Mandriva based. This is why I suspected the compiler. I will try and work out more info. [2008-11-18 17:23:16] crrodriguez at opensuse dot org Cannot reproduce,in opensuse 11 64 bit , GCC 4.3.1 either with or without suhosin. I suspect either your system or your compiler is doing something wrong. [2008-11-17 21:51:09] phpbugs at colin dot guthr dot ie My configure line is just the default. All I did was pass a custom prefix. I'll try and find some other 64 bit systems to play on. I should be able to fire a few different systems into a vm to see if I can reproduce it with other distros. [2008-11-17 10:18:57] [EMAIL PROTECTED] I can not reproduce this within x86_64 Centos 5 using latest PHP_5_2 checkout. Would be nice to know your configure line for PHP too..? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/46568 -- Edit this bug report at http://bugs.php.net/?id=46568edit=1
#46568 [Opn]: Segfault on 64bit when chaining function calls that generate exceptions
ID: 46568 User updated by: phpbugs at colin dot guthr dot ie Reported By: phpbugs at colin dot guthr dot ie Status: Open Bug Type: Scripting Engine problem Operating System: * (64bit) PHP Version: 5.2.7RC3 New Comment: OK, I repeated the make test sans-debug and it seems that a couple more tests fail under this scenario. http://kenobi.mandriva.com/~colin/php_test_results_20081118_2054.txt The most interesting extra failure is: Bug #30707 (Segmentation fault on exception in method) [Zend/tests/bug30707.phpt] This could perhaps provide some clues? For convenience, here is a diff of non-debug vs. debug: http://kenobi.mandriva.com/~colin/php-make-test.diff.txt Previous Comments: [2008-11-18 20:46:09] phpbugs at colin dot guthr dot ie Just tried --enable-debug and when built this way, it does indeed work as expected. Does this suggest anything else I can try to narrow down the problem. I also tried make test and did get several failures. I uploaded the test results to http://kenobi.mandriva.com/~colin/php_test_results_20081118_2006.txt although none of these look particularly relevant. I will do another build sans --enable-debug and see if any different standard tests fail. [2008-11-18 18:11:21] crrodriguez at opensuse dot org Did you built 5.2.7RC3 with --enable-debug ? if not, try that, does it crash anyway ? [2008-11-18 17:36:56] phpbugs at colin dot guthr dot ie Thanks for all the feedback/help. I will have to investigate further. I do not think my system hardware is at fault due to having confirmed on two other machines, although both Mandriva based. This is why I suspected the compiler. I will try and work out more info. [2008-11-18 17:23:16] crrodriguez at opensuse dot org Cannot reproduce,in opensuse 11 64 bit , GCC 4.3.1 either with or without suhosin. I suspect either your system or your compiler is doing something wrong. [2008-11-17 21:51:09] phpbugs at colin dot guthr dot ie My configure line is just the default. All I did was pass a custom prefix. I'll try and find some other 64 bit systems to play on. I should be able to fire a few different systems into a vm to see if I can reproduce it with other distros. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/46568 -- Edit this bug report at http://bugs.php.net/?id=46568edit=1
#46568 [Com]: Segfault on 64bit when chaining function calls that generate exceptions
ID: 46568
Comment by: phpbugs at colin dot guthr dot ie
Reported By: phpbugs at colin dot guthr dot ie
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: * (64bit)
PHP Version: 5.2.7RC3
New Comment:
My configure line is just the default. All I did was pass a custom
prefix.
I'll try and find some other 64 bit systems to play on. I should be
able to fire a few different systems into a vm to see if I can reproduce
it with other distros.
Previous Comments:
[2008-11-17 10:18:57] [EMAIL PROTECTED]
I can not reproduce this within x86_64 Centos 5 using latest PHP_5_2
checkout. Would be nice to know your configure line for PHP too..?
[2008-11-16 08:03:46] bruno at ioda dot net
I've try this on 3 differents openSUSE 10.3 all with the lastest
opensuse build services php version 5.2.6.
And the result was the expected exception
Fatal error: Uncaught exception 'Exception' with message 'Wibble' in
/tmp/bugs.php:10
Stack trace:
#0 /tmp/bugs.php(14): foo-wibble()
#1 /tmp/bugs.php(23): foo-bug()
#2 {main}
thrown in /tmp/bugs.php on line 10
PHP 5.2.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Nov 5 2008
13:42:52)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH
For 10.3 gcc is :
Target: x86_64-suse-linux
Configuré avec: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.2.1
--enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--program-suffix=-4.2 --enable-version-specific-runtime-libs
--without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux
Modèle de thread: posix
version gcc 4.2.1 (SUSE Linux)
I've not yet try on the lastest 11.0 x64 which have the gcc
gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision
135036] (SUSE Linux)
[2008-11-13 22:41:05] phpbugs at colin dot guthr dot ie
Well I've confirmed this problem on three Mandriva systems with
Mandriva packages but for this bug report I built a fresh vanilla
version from the 5.2.7rc3 tarball on my own machine to ensure it was
nothing to do with any additional patches in the Mandriva package
causing the problem.
I do not have access to any non-Mandriva 64 bit build hosts here to do
more tests...
FWIW, the GCC version is 4.3.2.
I can tarball up the installed version if you want to give my build a
run and see if it crashes on your machine. If it does crash then I'd
expect the problem to be related to GCC.
[2008-11-13 22:23:05] [EMAIL PROTECTED]
I can't reproduce it on FreeBSD amd64.
[2008-11-13 16:18:13] phpbugs at colin dot guthr dot ie
Description:
I seem to have uncovered a bug that has been affecting me for a while
(e.g. it affects 5.2.6 as well) but that, until now, I have been able to
work around.
I have confirmed this bug on both 5.2.6 and 5.2.7RC3 on x86_64. I have
confirmed this bug does *not* occur on i586 with these same versions.
The reproduce code has two examples. It should be obvious which is
which ;)
I compiled up a fresh 5.2.7RC3 to produce the below backtrace.
Please remember that this bug affects x86_64 only.
I discovered this when using code in the Zend Framework in which this
scenario crops up in the natural flow of code.
Reproduce code:
---
?php
class foo
{
private function bar($x)
{
echo $x;
}
private function wibble()
{
throw new Exception(Wibble);
}
public function bug()
{
$this-bar($this-wibble());
}
public function nobug()
{
$wibble = $this-wibble();
$this-bar($wibble);
}
}
$foo = new foo;
$foo-bug();
//$foo-nobug();
Expected result:
PHP Fatal error: Uncaught exception 'Exception' with message 'Wibble'
in /home/colin/bug.php:10
Stack trace:
#0 /home/colin/bug.php(14): foo-wibble()
#1 /home/colin/bug.php(23): foo-bug()
#2 {main}
thrown in /home/colin/bug.php on line 10
Actual result:
--
[EMAIL PROTECTED] pfx]$ gdb bin/php
GNU gdb 6.8-2mdv2009.0 (Mandriva Linux release 2009.0)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute
#46568 [NEW]: Segfault on 64bit when chaining function calls that generate exceptions
From: phpbugs at colin dot guthr dot ie
Operating system: Linux
PHP version: 5.2.7RC3
PHP Bug Type: Reproducible crash
Bug description: Segfault on 64bit when chaining function calls that generate
exceptions
Description:
I seem to have uncovered a bug that has been affecting me for a while
(e.g. it affects 5.2.6 as well) but that, until now, I have been able to
work around.
I have confirmed this bug on both 5.2.6 and 5.2.7RC3 on x86_64. I have
confirmed this bug does *not* occur on i586 with these same versions.
The reproduce code has two examples. It should be obvious which is which
;)
I compiled up a fresh 5.2.7RC3 to produce the below backtrace.
Please remember that this bug affects x86_64 only.
I discovered this when using code in the Zend Framework in which this
scenario crops up in the natural flow of code.
Reproduce code:
---
?php
class foo
{
private function bar($x)
{
echo $x;
}
private function wibble()
{
throw new Exception(Wibble);
}
public function bug()
{
$this-bar($this-wibble());
}
public function nobug()
{
$wibble = $this-wibble();
$this-bar($wibble);
}
}
$foo = new foo;
$foo-bug();
//$foo-nobug();
Expected result:
PHP Fatal error: Uncaught exception 'Exception' with message 'Wibble' in
/home/colin/bug.php:10
Stack trace:
#0 /home/colin/bug.php(14): foo-wibble()
#1 /home/colin/bug.php(23): foo-bug()
#2 {main}
thrown in /home/colin/bug.php on line 10
Actual result:
--
[EMAIL PROTECTED] pfx]$ gdb bin/php
GNU gdb 6.8-2mdv2009.0 (Mandriva Linux release 2009.0)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-mandriva-linux-gnu...
(gdb) set args bug.php
(gdb) run
Starting program: /home/colin/php/pfx/bin/php bug.php
[Thread debugging using libthread_db enabled]
[New Thread 0x7f75d9a056f0 (LWP 18074)]
Program received signal SIGSEGV, Segmentation fault.
zend_do_fcall_common_helper_SPEC (execute_data=0x7fffe1a4fbd0) at
/home/colin/php/php-5.2.7RC3/Zend/zend_vm_execute.h:289
289 if (RETURN_VALUE_USED(ctor_opline)) {
Missing debug package(s), you should install: glibc-debug libxml2-debug
zlib-debug
(gdb) thread apply all bt full
Thread 1 (Thread 0x7f75d9a056f0 (LWP 18074)):
#0 zend_do_fcall_common_helper_SPEC (execute_data=0x7fffe1a4fbd0) at
/home/colin/php/php-5.2.7RC3/Zend/zend_vm_execute.h:289
opline = (zend_op *) 0x7f75d9a2a770
original_return_value = (zval **) 0x7fffe1a4fcd0
current_scope = (zend_class_entry *) 0x0
current_this = (zval *) 0x0
return_value_used = 0
should_change_scope = 1 '\001'
#1 0x0064b8a4 in execute (op_array=0x7f75d9a2a108) at
/home/colin/php/php-5.2.7RC3/Zend/zend_vm_execute.h:92
execute_data = {opline = 0x7f75d9a2a770, function_state =
{function_symbol_table = 0x7f75d9a2d470,
function = 0x7f75d9a2a108, reserved = {0x0, 0x7f75d9a2a200, 0x0,
0x7f75d9a2a210}}, fbc = 0x7f75d9a2cb90,
op_array = 0x7f75d9a2a108, object = 0x7f75d9a29928, Ts = 0x7fffe1a4fa80,
CVs = 0x7fffe1a4fa60, original_in_execution = 0 '\0',
symbol_table = 0x9db608, prev_execute_data = 0x0, old_error_reporting =
0x0}
#2 0x006290d1 in zend_execute_scripts (type=8, retval=0x51,
file_count=3)
at /home/colin/php/php-5.2.7RC3/Zend/zend.c:1134
files = {{gp_offset = 40, fp_offset = 0, overflow_arg_area =
0x7fffe1a4fdd0, reg_save_area = 0x7fffe1a4fce0}}
i = 1
file_handle = (zend_file_handle *) 0x7fffe1a52240
#46568 [Opn]: Segfault on 64bit when chaining function calls that generate exceptions
ID: 46568
User updated by: phpbugs at colin dot guthr dot ie
Reported By: phpbugs at colin dot guthr dot ie
Status: Open
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.2.7RC3
New Comment:
Well I've confirmed this problem on three Mandriva systems with
Mandriva packages but for this bug report I built a fresh vanilla
version from the 5.2.7rc3 tarball on my own machine to ensure it was
nothing to do with any additional patches in the Mandriva package
causing the problem.
I do not have access to any non-Mandriva 64 bit build hosts here to do
more tests...
FWIW, the GCC version is 4.3.2.
I can tarball up the installed version if you want to give my build a
run and see if it crashes on your machine. If it does crash then I'd
expect the problem to be related to GCC.
Previous Comments:
[2008-11-13 22:23:05] [EMAIL PROTECTED]
I can't reproduce it on FreeBSD amd64.
[2008-11-13 16:18:13] phpbugs at colin dot guthr dot ie
Description:
I seem to have uncovered a bug that has been affecting me for a while
(e.g. it affects 5.2.6 as well) but that, until now, I have been able to
work around.
I have confirmed this bug on both 5.2.6 and 5.2.7RC3 on x86_64. I have
confirmed this bug does *not* occur on i586 with these same versions.
The reproduce code has two examples. It should be obvious which is
which ;)
I compiled up a fresh 5.2.7RC3 to produce the below backtrace.
Please remember that this bug affects x86_64 only.
I discovered this when using code in the Zend Framework in which this
scenario crops up in the natural flow of code.
Reproduce code:
---
?php
class foo
{
private function bar($x)
{
echo $x;
}
private function wibble()
{
throw new Exception(Wibble);
}
public function bug()
{
$this-bar($this-wibble());
}
public function nobug()
{
$wibble = $this-wibble();
$this-bar($wibble);
}
}
$foo = new foo;
$foo-bug();
//$foo-nobug();
Expected result:
PHP Fatal error: Uncaught exception 'Exception' with message 'Wibble'
in /home/colin/bug.php:10
Stack trace:
#0 /home/colin/bug.php(14): foo-wibble()
#1 /home/colin/bug.php(23): foo-bug()
#2 {main}
thrown in /home/colin/bug.php on line 10
Actual result:
--
[EMAIL PROTECTED] pfx]$ gdb bin/php
GNU gdb 6.8-2mdv2009.0 (Mandriva Linux release 2009.0)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show
copying
and show warranty for details.
This GDB was configured as x86_64-mandriva-linux-gnu...
(gdb) set args bug.php
(gdb) run
Starting program: /home/colin/php/pfx/bin/php bug.php
[Thread debugging using libthread_db enabled]
[New Thread 0x7f75d9a056f0 (LWP 18074)]
Program received signal SIGSEGV, Segmentation fault.
zend_do_fcall_common_helper_SPEC (execute_data=0x7fffe1a4fbd0) at
/home/colin/php/php-5.2.7RC3/Zend/zend_vm_execute.h:289
289 if (RETURN_VALUE_USED(ctor_opline)) {
Missing debug package(s), you should install: glibc-debug libxml2-debug
zlib-debug
(gdb) thread apply all bt full
Thread 1 (Thread 0x7f75d9a056f0 (LWP 18074)):
#0 zend_do_fcall_common_helper_SPEC (execute_data=0x7fffe1a4fbd0) at
/home/colin/php/php-5.2.7RC3/Zend/zend_vm_execute.h:289
opline = (zend_op *) 0x7f75d9a2a770
original_return_value = (zval **) 0x7fffe1a4fcd0
current_scope = (zend_class_entry *) 0x0
current_this = (zval *) 0x0
return_value_used = 0
should_change_scope = 1 '\001'
#1 0x0064b8a4 in execute (op_array=0x7f75d9a2a108) at
/home/colin/php/php-5.2.7RC3/Zend/zend_vm_execute.h:92
execute_data = {opline = 0x7f75d9a2a770, function_state =
{function_symbol_table = 0x7f75d9a2d470,
function = 0x7f75d9a2a108, reserved = {0x0, 0x7f75d9a2a200, 0x0
#45996 [Com]: libxml2 2.7.1 causes breakage with character data in xml_parse()
ID: 45996
Comment by: phpbugs at colin dot guthr dot ie
Reported By: phpbugs at colin dot guthr dot ie
Status: Assigned
Bug Type: XML related
Operating System: Mandriva Linux
PHP Version: 5.2.6
Assigned To: rrichards
New Comment:
Mike, it's fairly easy to recompile PHP with the libexpat library for
the legacy XML parsing functions while keeping libxml2 for the more
modern ones.
We did that in the Mandriva package for our 2009.0 release after I
reported the bug.
See the SPEC file here:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/updates/2009.0/php/current/SPECS/php.spec?revision=291141view=markup
The particular change that worked around it is here:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/updates/2009.0/php/current/SPECS/php.spec?r1=278891r2=281822
I'm sure you can work out how to get the needed patch that is mentioned
by navigating the webcvs :) You should be able to use this to recompile
the CentOS PHP package accordingly.
Hope this helps.
Col
Previous Comments:
[2008-10-15 00:04:01] mike at kogan dot org
I also have run into this - we had some legacy php code on the
xml_parser that was fine on some centos 4 servers with php4 and 5
running apache 1.3. We've been debugging this failure for a day now on
our new centos 5 server running php5 and libxml2 2.7.2, and we confirm
the same problem. The characterHandler is not called for the known
entities so scripts depending on this (rss feed converters etc) emit
flawed html. I agree there's much better ways to parse XML but this is
legacy stuff thats somewhat pervasive and we didn;t choose what these
folks used for their apps.
I'd love to rebuild their server with an older libxml2 but am not sure
how to go backwards without causing some other problem. Customer has
cpanel/whm and all that hooey and I'd rather not create a mess on their
new server.
Hope ya'll fix this soon as it is an issue on the cpanel folks that
have 2.7.2 in their stable branch for centos 5 that is being spread by
their updater.
If someone can give me a pointer that a straightup build and install of
the old release code wont make things worse I'll take a crack at moving
their server back.
[2008-10-08 09:50:16] phpbugs at colin dot guthr dot ie
Yes, I suspect that the comments left by ptn at post dot cz are
incorrect when they say it is fixed in libxml. rrichards has given a
very complete explanation of the problem and it is more fundamental than
a simple bug.
Compiling PHP with libexpat is the correct workaround for now.
[2008-10-08 09:18:54] uraes at hot dot ee
just tried libxml2-2.7.2 and 5.2.6-pl7-gentoo and it is still broken:
Example PHP code:
?
$data=?xml version = '1.0' encoding = 'UTF-8'?
rss version=\2.0\
channel
item
descriptionlt;a
href=quot;http://www.google.comquot;Googlelt;/a/description
/item
/channel
/rss
;
$parser = xml_parser_create('UTF-8');
xml_parser_set_option($parser, XML_OPTION_SKIP_WHITE, 1);
xml_parse_into_struct($parser, $data, $vals, $index);
xml_parser_free($parser);
echo pre;
echo bOriginal XML:/bbr.htmlentities($data);
echo brbrbParsed struct:/bbr;
print_r($vals);
?
.. parsed result is a href=http://www.google.comGoogle/a
[2008-10-07 11:19:33] ptn at post dot cz
this bug seems to be fixed in libxm2-2.7.2
http://svn.gnome.org/viewvc/libxml2?view=revisionrevision=3798
[2008-09-09 23:06:00] phpbugs at colin dot guthr dot ie
Comments by Daniel Veillard on the libxml ML:
The only thing I can think of is that libxml2 doesn't anymore ask
though a SAX callback when looking for entities references if they
are in the predefined set. This comes in essence by an old decision
from the XML working group stating that user definition for those 5
entities could not override the default predefined ones. So I guess
that change is logical. Now what is done on top of SAX to result
in that bug, I don't really know :-\
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/45996
--
Edit this bug report at http://bugs.php.net/?id=45996edit=1
#45996 [Com]: libxml2 2.7.1 causes breakage with character data in xml_parse()
ID: 45996
Comment by: phpbugs at colin dot guthr dot ie
Reported By: phpbugs at colin dot guthr dot ie
Status: Assigned
Bug Type: XML related
Operating System: Mandriva Linux
PHP Version: 5.2.6
Assigned To: rrichards
New Comment:
Yes, I suspect that the comments left by ptn at post dot cz are
incorrect when they say it is fixed in libxml. rrichards has given a
very complete explanation of the problem and it is more fundamental than
a simple bug.
Compiling PHP with libexpat is the correct workaround for now.
Previous Comments:
[2008-10-08 09:18:54] uraes at hot dot ee
just tried libxml2-2.7.2 and 5.2.6-pl7-gentoo and it is still broken:
Example PHP code:
?
$data=?xml version = '1.0' encoding = 'UTF-8'?
rss version=\2.0\
channel
item
descriptionlt;a
href=quot;http://www.google.comquot;Googlelt;/a/description
/item
/channel
/rss
;
$parser = xml_parser_create('UTF-8');
xml_parser_set_option($parser, XML_OPTION_SKIP_WHITE, 1);
xml_parse_into_struct($parser, $data, $vals, $index);
xml_parser_free($parser);
echo pre;
echo bOriginal XML:/bbr.htmlentities($data);
echo brbrbParsed struct:/bbr;
print_r($vals);
?
.. parsed result is a href=http://www.google.comGoogle/a
[2008-10-07 11:19:33] ptn at post dot cz
this bug seems to be fixed in libxm2-2.7.2
http://svn.gnome.org/viewvc/libxml2?view=revisionrevision=3798
[2008-09-09 23:06:00] phpbugs at colin dot guthr dot ie
Comments by Daniel Veillard on the libxml ML:
The only thing I can think of is that libxml2 doesn't anymore ask
though a SAX callback when looking for entities references if they
are in the predefined set. This comes in essence by an old decision
from the XML working group stating that user definition for those 5
entities could not override the default predefined ones. So I guess
that change is logical. Now what is done on top of SAX to result
in that bug, I don't really know :-\
[2008-09-06 15:43:29] [EMAIL PROTECTED]
Assigned to the maintainer (Rob, don't forget to change status too when
you assign something to yourself :)
[2008-09-04 17:29:21] phpbugs at colin dot guthr dot ie
Description:
With libxml2 2.7.1, When using the expat type xml parsing routines in
PHP, the characater data seems to silently drop any encoded text e.g.
gt; lt; and friends.
Please see Mandriva bug for details:
https://qa.mandriva.com/show_bug.cgi?id=43486
And also please note the thread on the libxml mailing list:
http://thread.gmane.org/gmane.comp.gnome.lib.xml.general/14610
And most notably the reply to the above thread:
quote
Can you report this as a PHP bug? It looks like some really old hack
code in the PHP extension in order to mimic some specific expat
functionality. The behavior change you see though resulting from a code
changes in libxml2 is really due to the hackish code in the extension
doing things it wasnt meant to be doing.
/quote
Reproduce code:
---
Please see this code:
https://qa.mandriva.com/attachment.cgi?id=10757
Expected result:
foo
wibble
/foo
Actual result:
--
foo
wibble
/foo
--
Edit this bug report at http://bugs.php.net/?id=45996edit=1
#45996 [Asn]: libxml2 2.7.1 causes breakage with character data in xml_parse()
ID: 45996 User updated by: phpbugs at colin dot guthr dot ie Reported By: phpbugs at colin dot guthr dot ie Status: Assigned Bug Type: XML related Operating System: Mandriva Linux PHP Version: 5.2.6 Assigned To: rrichards New Comment: Comments by Daniel Veillard on the libxml ML: The only thing I can think of is that libxml2 doesn't anymore ask though a SAX callback when looking for entities references if they are in the predefined set. This comes in essence by an old decision from the XML working group stating that user definition for those 5 entities could not override the default predefined ones. So I guess that change is logical. Now what is done on top of SAX to result in that bug, I don't really know :-\ Previous Comments: [2008-09-06 15:43:29] [EMAIL PROTECTED] Assigned to the maintainer (Rob, don't forget to change status too when you assign something to yourself :) [2008-09-04 17:29:21] phpbugs at colin dot guthr dot ie Description: With libxml2 2.7.1, When using the expat type xml parsing routines in PHP, the characater data seems to silently drop any encoded text e.g. gt; lt; and friends. Please see Mandriva bug for details: https://qa.mandriva.com/show_bug.cgi?id=43486 And also please note the thread on the libxml mailing list: http://thread.gmane.org/gmane.comp.gnome.lib.xml.general/14610 And most notably the reply to the above thread: quote Can you report this as a PHP bug? It looks like some really old hack code in the PHP extension in order to mimic some specific expat functionality. The behavior change you see though resulting from a code changes in libxml2 is really due to the hackish code in the extension doing things it wasnt meant to be doing. /quote Reproduce code: --- Please see this code: https://qa.mandriva.com/attachment.cgi?id=10757 Expected result: foo wibble /foo Actual result: -- foo wibble /foo -- Edit this bug report at http://bugs.php.net/?id=45996edit=1
#45996 [NEW]: libxml2 2.7.1 causes breakage with character data in xml_parse()
From: phpbugs at colin dot guthr dot ie Operating system: Mandriva Linux PHP version: 5.2.6 PHP Bug Type: *XML functions Bug description: libxml2 2.7.1 causes breakage with character data in xml_parse() Description: With libxml2 2.7.1, When using the expat type xml parsing routines in PHP, the characater data seems to silently drop any encoded text e.g. gt; lt; and friends. Please see Mandriva bug for details: https://qa.mandriva.com/show_bug.cgi?id=43486 And also please note the thread on the libxml mailing list: http://thread.gmane.org/gmane.comp.gnome.lib.xml.general/14610 And most notably the reply to the above thread: quote Can you report this as a PHP bug? It looks like some really old hack code in the PHP extension in order to mimic some specific expat functionality. The behavior change you see though resulting from a code changes in libxml2 is really due to the hackish code in the extension doing things it wasnt meant to be doing. /quote Reproduce code: --- Please see this code: https://qa.mandriva.com/attachment.cgi?id=10757 Expected result: foo wibble /foo Actual result: -- foo wibble /foo -- Edit bug report at http://bugs.php.net/?id=45996edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45996r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45996r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45996r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45996r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45996r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45996r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45996r=needscript Try newer version:http://bugs.php.net/fix.php?id=45996r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45996r=support Expected behavior:http://bugs.php.net/fix.php?id=45996r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45996r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45996r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45996r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45996r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45996r=dst IIS Stability:http://bugs.php.net/fix.php?id=45996r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45996r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45996r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45996r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45996r=mysqlcfg
