#47638 [Opn]: Random fatal error while using callback through array_udiff_assoc
ID: 47638
Updated by: fel...@php.net
Reported By: luke at cywh dot com
Status: Open
Bug Type: *Compile Issues
Operating System: Linux, Mac OS X
PHP Version: 5.2.9
New Comment:
I can't reproduce it.
Previous Comments:
[2009-03-12 17:02:10] luke at cywh dot com
Description:
When making a callback through array_udiff_assoc to a static function
this fatal error is produced, but randomly:
Fatal error: Non-static method (null)::(null)() cannot be called
statically in /opt/local/apache2/htdocs/site/cc.php on line 12
This error only occurs about 1/3 of the time or less, and usually
seems to happen right after saving a file. At first I thought it was
an eAccelerator issue as I could product this error almost every time
after re-saving the file (with or without changes), but I was also
able to reproduce this on my MacBook which I had installed the 5.2
branch on without any cache engines.
On a stock PHP installation with no extras it is mighty difficult to
reproduce this error. I was able to make it occur several times if I
refreshed the page 5-20 times after saving.
In the callback I'm referencing the function as a string:
"XC::greaterthan". I *think* using array('XC', 'greaterthan') corrects
the problem, but I am unsure as this error seems to occur completely
at random, and I have yet to have a 100% solid way of reproducing it.
The code below is the best way I was able to reproduce the occurrence.
Reproduce code:
---
class XC {
static public function greaterthan($value1, $value2) {
return $value1 > $value2;
}
}
class test {
function tester($num1, $num2) {
var_dump(array_intersect(
array_keys(
array_udiff_assoc(array('if' => $num1),
array('if' => $num2),
'XC::greaterthan')
), array('if')
));
}
}
$t = new test();
for($i=0; $i<10; $i++) {
$num1 = mt_rand(1, 100);
$num2 = mt_rand(1, 100);
$t->tester($num1, $num2);
}
Expected result:
No fatal error, just var dumps.
Actual result:
--
Fatal error: Non-static method (null)::(null)() cannot be called
statically in /opt/local/apache2/htdocs/site/cc.php on line 12
(Which points to the array_udiff_assoc function)
--
Edit this bug report at http://bugs.php.net/?id=47638&edit=1
#47042 [Fbk->Opn]: php cgi sapi is incorrectly removing the SCRIPT_FILENAME for non apache
ID: 47042
User updated by: sriram dot natarajan at sun dot com
Reported By: sriram dot natarajan at sun dot com
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: linux , solaris
PHP Version: 5.2.9
New Comment:
hi
this fix is not available with the latest php snapshot. my latest
patch needs to be looked into and considered fixing it for 5.3 as well
as 5.2.9
[sn123...@samp]'php5'>diff -u php-5.2.9/sapi/cgi/cgi_main.c.ORIG
php-5.2.9/sapi/cgi/cgi_main.c
--- php-5.2.9/sapi/cgi/cgi_main.c.ORIG Sat Feb 28 00:44:54 2009
+++ php-5.2.9/sapi/cgi/cgi_main.c Sat Feb 28 00:46:00 2009
@@ -961,7 +961,8 @@
}
if (env_path_translated != NULL &&
env_redirect_url != NULL &&
- orig_script_filename != NULL &&
script_path_translated != NULL) {
+ env_path_translated !=
script_path_translated &&
+ strcmp(env_path_translated,
script_path_translated) != 0) {
/*
pretty much apache specific. If we
have a redirect_url
then our script_filename and
script_name point to the
thanks
sriram
Previous Comments:
[2009-03-10 10:43:09] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-03-03 09:56:55] sriram dot natarajan at sun dot com
i have tested this patch with apache 2.0 and 2.2 configurations within
cgi and was able to get applications like joomla working fine.
can some one kindly look into the attached patch and provide your
feedback
thanks
[2009-02-28 09:18:55] sriram dot natarajan at sun dot com
Hi
php cgi module assumes that if redirect_uri is set , the request must
be from apache and throws away the script_name value and assigns
path_translated value to script name.
this is because, in cgi environment, apache sets the SCRIPT_NAME to
the location of the php-cgi binary and keeping the PATH_INFO variable to
point to the requested php script. this is very unique only to apache.
this crude test condition for apache is affecting sun web server
executing in fastcgi mode where in it looses the script_name value and
ends up returning with 'no input file specified'.
this happens only for sun web server and not for lighttpd because
lighttpd does not set redirect_uri when requested for index.php.
based on this analysis , earlier, i provided a patch to address this
issue . however, i overlooked the obvious and ended up breaking apache
in cgi mode.
because of this, a separate bug : http://bugs.php.net/bug.php?id=47149
has been filed and my suggested patch was reverted.
my sincere apology on providing this obviously broken patch and wasting
some of your time.
pl. find attached a below patch that should do the right thing.
what we want to do is
a) compare whether the script path is different from path translated
since we know that apache by default sets the script name to point to
the location of cgi binary and not the requested uri
[sn123...@samp]'php5'>diff -u php-5.2.9/sapi/cgi/cgi_main.c.ORIG
php-5.2.9/sapi/cgi/cgi_main.c
--- php-5.2.9/sapi/cgi/cgi_main.c.ORIG Sat Feb 28 00:44:54 2009
+++ php-5.2.9/sapi/cgi/cgi_main.c Sat Feb 28 00:46:00 2009
@@ -961,7 +961,8 @@
}
if (env_path_translated != NULL &&
env_redirect_url != NULL &&
- orig_script_filename != NULL &&
script_path_translated != NULL) {
+ env_path_translated !=
script_path_translated &&
+ strcmp(env_path_translated,
script_path_translated) != 0) {
/*
pretty much apache specific. If we
have a redirect_url
then our script_filename and
script_name point to the
[2009-01-11 11:13:02] d...@php.net
This bug has been fixed in CVS.
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.
[2009-01-08 22:19:12] sriram dot natarajan at sun dot com
previous patch had whitespaces instead of tabs causing the patch to
appear distorted.
posting a same patch with this issue addressed
--- sapi/cgi/cgi_main.c.ORIGThu Jan 8 14:18:25 2009
+++ sapi/cgi/cgi_main.c Thu Jan 8 14:18:31
#47639 [Opn->Csd]: pg_copy_from: WARNING: nonstandard use of \\ in a string literal
ID: 47639 Updated by: il...@php.net Reported By: thuejk at gmail dot com -Status: Open +Status: Closed Bug Type: PostgreSQL related Operating System: Linux PHP Version: 5.2.9 New Comment: This bug has been fixed in CVS. 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. Previous Comments: [2009-03-12 18:46:23] thuejk at gmail dot com Description: Whenever I use pg_copy_from() I get an error in /var/log/postgresql/postgresql-8.3-main.log : 2009-03-12 19:43:12 CET WARNING: nonstandard use of \\ in a string literal at character 82 2009-03-12 19:43:12 CET HINT: Use the escape string syntax for backslashes, e.g., E'\\'. This is caused by pg_copy_from(), which in pgsql.c does something like the following: spprintf(&query, 0, "COPY \"%s\" FROM STDIN DELIMITERS '%c' WITH NULL AS '%s'", table_name, *pg_delim, "N"); If I pass the optional custom NULL indicator arg to pg_copy_from, ie replace "N" with for example "NULL", then the error goes away. Reproduce code: --- pg_query($db->connection, "CREATE TABLE test(a INT)"); pg_copy_from($db->connection, "test", Array(1)); -- Edit this bug report at http://bugs.php.net/?id=47639&edit=1
#47633 [Opn]: Bcmath precision issue
ID: 47633 User updated by: k1ngrs at ntlworld dot com Reported By: k1ngrs at ntlworld dot com Status: Open Bug Type: BC math related Operating System: Windows XP Pro SP2 PHP Version: 5.2.9 New Comment: I think I have uncovered the reason for the issue and that is that the function expects a string and I have passed a floating point number which OK to a point. Once you go smaller than 0.0001 you transfer a scientific notation to the function that does not compute. So the answer is to convert it first using number_format. Regards Rob Previous Comments: [2009-03-12 11:59:00] k1ngrs at ntlworld dot com Description: The bcmath commands do not seem to work for numbers smaller than 0.0001 for exmaple if you add 0.1 and 0.1 the result is zero. Even setting the bcscale beforehand does not fix the issue. Reproduce code: --- Expected result: 1. 0.00011 + 0.00011 = 0.000220 2. 0.1 + 0.1 = 0.2 3. 0.1 - 0.05 = 0.05 Actual result: -- 1. 0.00011 + 0.00011 = 0.000220 OK 2. 0.1 + 0.1 = 0.00 Wrong 3. 0.1 - 0.05 = 0.00 Wrong -- Edit this bug report at http://bugs.php.net/?id=47633&edit=1
#41597 [Com]: "make test" is failed, because many php process is created.
ID: 41597 Comment by: johnson dot c dot hays at census dot gov Reported By: h-nisimu at pd dot jp dot nec dot com Status: No Feedback Bug Type: *Compile Issues Operating System: Solaris 9 PHP Version: 5.2.3 New Comment: Hi, Tried compilinging php with a new version of apache 2.2.11, and installed gnu sed, awk, and make. My issue went away. When I test, I do not get multiple spawning processes. FYI - I had to compile apr and apr-util to get php 5.2.8 running on apache 2.2.11 on Solaris 8. I had used the pre-compiled versions and they caused the install to fail. Johnson Hays Previous Comments: [2009-03-11 16:55:09] johnson dot c dot hays at census dot gov Hi, I am having the same issue. I am building php 5.2.8 on Solaris 8. When the make test runs the sapi/cgi/tests/ the test spawns hundres of php scripts and I am forced to kill the tests. Was there ever a resolution to this issue? Thank you for your time. Here is my configure script switches: ./configure --enable-debug --with-apxs2=/usr/local/apache2/bin/apxs \ --with-mysql=/usr/local/mysql --with-iconv=/usr/local \ --with-gd=/usr/local --with-jpeg-dir=/usr/local --with-png-dir=/usr/local \ --with-zlib-dir=/usr/local --with-xpm-dir=/usr/local \ --with-freetype-dir=/usr/local --with-ldap=/usr/local --enable-mbstring Here are the packages already installed: SMCR VERSION: 2.7.1 SMCap2211 VERSION: 2.2.11 SMCapr VERSION: 1.2.2 SMCaprutil VERSION: 1.2.2 SMCautoc VERSION: 2.62 SMCautom VERSION: 1.10.2 SMCbison VERSION: 2.3 SMCcairo VERSION: 1.4.10 SMCdb VERSION: 4.2.52.NC SMCexpat VERSION: 2.0.1 SMCflex VERSION: 2.5.4a SMCfontc VERSION: 2.4.2 SMCftype VERSION: 2.3.1 SMCgawk VERSION: 3.1.6 SMCgcc VERSION: 3.4.6 SMCgd VERSION: 2.0.35 SMCgdbm VERSION: 1.8.3 SMCglib VERSION: 2.14.1 SMCiconv VERSION: 1.8 SMCjpeg VERSION: 6b SMClgcc VERSION: 3.4.6 SMClibpng VERSION: 1.2.26 SMCliconv VERSION: 1.11 SMClintl VERSION: 3.4.0 SMClxml2 VERSION: 2.6.31 SMCmake VERSION: 3.81 SMCmysql VERSION: 5.0.51 SMCncurs VERSION: 5.6 SMCntp VERSION: 4.2.0 SMColdap VERSION: 2.3.35 SMCosl98d VERSION: 0.9.8d SMCossh44p1 VERSION: 4.4p1 SMCpango VERSION: 1.18.2 SMCperl VERSION: 5.8.8 SMCpopt VERSION: 1.14 SMCreadl VERSION: 5.2 SMCrsync VERSION: 2.6.2 SMCsamba VERSION: 3.0.10 SMCsasl VERSION: 2.1.21 SMCsudo VERSION: 1.6.7p5 SMCtar VERSION: 1.16 SMCtcl VERSION: 8.5.3 SMCtk VERSION: 8.5.3 SMCxpm VERSION: 3.4k SMCxrend VERSION: 0.8.3 SMCzlib VERSION: 1.2.3 Johnson Hays johnson.c.hays at census.gov [2007-11-13 10:00:13] strube at physik3 dot gwdg dot de This bug is still present in php-5.2.5 with Solaris 9 (SPARC). As soon as "make test" reaches the sapi/cgi tests, many php-cgi processes are spawned recursively, apparently without end, almost blocking the whole machine. I have not tested php-5 versions beside 5.2.3 and 5.2.5. The bug never occurred with any php-4 versions. Compiler: Sun Forte 7 (C 5.4); Make: Solaris make; Configure command: env CC=/opt/SUNWspro/bin/cc CFLAGS=-xO2 ./configure --enable-discard-path --enable-force-cgi-redirect --with-ndbm --enable-dba --with-db2=/opt/dpiwww/apache --with-mysql=/opt/dpiwww/mysql --enable-sysvsem --enable-sysvshm --with-exec-dir=/opt/dpiwww/php5/bin --with-config-file-path=/opt/dpiwww/php5/lib --prefix=/opt/dpiwww/php5 --disable-debug --with-zlib --with-bz2 --with-gd --with-jpeg-dir=/usr/sfw --with-png-dir=/usr/sfw --with-xpm-dir=/usr/openwin --with-freetype-dir=/usr/sfw --enable-gd-native-ttf --with-gettext --disable-libxml --disable-dom --disable-simplexml --disable-xml --disable-xmlreader --disable-xmlwriter --without-pear [2007-06-13 01:00:00] 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". [2007-06-08 20:06:37] jhagan at binghamton dot edu I just recently ran into this same problem on a Solaris 8 box. My configure looks like this: ./configure --prefix=/local/apps/php/php-5.2.3 --with-config-file-path=/local/apps/php --with-ldap=/local/apps/ldap/openldap-2.3.11 --with-mysql=/usr/local/mysql --with-mcal=/local/apps/mcal --with-gd --with-jpeg-dir=/usr/local --with-libxml-dir=/local/apps/libxml --with-png-dir=/usr/local --with-zlib --with-zlib-dir=/usr/local --with-pear --enable-discard-path "make t
#28038 [Com]: Sent incorrect RCPT TO commands to SMTP server
ID: 28038
Comment by: feamsr00 at feamsternet dot net
Reported By: jordi at jcanals dot net
Status: Open
Bug Type: Mail related
Operating System: win32 only
PHP Version: 5CVS, 6CVS (2008-10-24)
New Comment:
exact same here *bump*
PHP 5.2.8 (cli) (built: Feb 4 2009 17:55:55)
Microsoft Windows XP [Version 5.1.2600]
Previous Comments:
[2009-02-24 23:25:22] mark at lbisat dot com
By modifying the following in PHP.ini
[mail function]
sendmail_from = em...@domain.com
It fixed the issue for me on Windows 2003 Server SP2.
[2009-02-19 19:39:06] alexcomboy at hotmail dot co dot uk
It does not work with this either:
Windows XP SP2 or SP3, IIS 5.1, PHP 5.2.8
[2009-01-19 21:20:39] abba000 at o2 dot pl
4 years have passed and nothing... What the hell? This is really
important! Anybody knows how to fix it?
[2009-01-12 11:49:18] julioworld at hotmail dot com
I also had this problem and I solved it by adding this line in the
php.ini in the section [mail function]:
[mail function]
sendmail_from = em...@domain.com
[2009-01-06 19:41:42] ghooey at gmail dot com
Unlike with a linux server the email address in
ini_set('sendmail_from', 'm...@domain.com); has to be a valid email
address
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/28038
--
Edit this bug report at http://bugs.php.net/?id=28038&edit=1
#47639 [NEW]: pg_copy_from: WARNING: nonstandard use of \\ in a string literal
From: thuejk at gmail dot com Operating system: Linux PHP version: 5.2.9 PHP Bug Type: PostgreSQL related Bug description: pg_copy_from: WARNING: nonstandard use of \\ in a string literal Description: Whenever I use pg_copy_from() I get an error in /var/log/postgresql/postgresql-8.3-main.log : 2009-03-12 19:43:12 CET WARNING: nonstandard use of \\ in a string literal at character 82 2009-03-12 19:43:12 CET HINT: Use the escape string syntax for backslashes, e.g., E'\\'. This is caused by pg_copy_from(), which in pgsql.c does something like the following: spprintf(&query, 0, "COPY \"%s\" FROM STDIN DELIMITERS '%c' WITH NULL AS '%s'", table_name, *pg_delim, "N"); If I pass the optional custom NULL indicator arg to pg_copy_from, ie replace "N" with for example "NULL", then the error goes away. Reproduce code: --- pg_query($db->connection, "CREATE TABLE test(a INT)"); pg_copy_from($db->connection, "test", Array(1)); -- Edit bug report at http://bugs.php.net/?id=47639&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47639&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47639&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47639&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47639&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47639&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47639&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47639&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47639&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47639&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47639&r=support Expected behavior: http://bugs.php.net/fix.php?id=47639&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47639&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47639&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47639&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47639&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47639&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47639&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47639&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47639&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47639&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47639&r=mysqlcfg
#47480 [Opn->Bgs]: preg_replace with "/i" is not case insensitive
ID: 47480 Updated by: nlop...@php.net Reported By: sehh at ionos dot gr -Status: Open +Status: Bogus Bug Type: PCRE related Operating System: Linux PHP Version: 5.2.8 New Comment: not an issue in php. check the unicode standard. Previous Comments: [2009-03-12 09:39:51] sehh at ionos dot gr Do you think it would be better if I contacted the developers of the PCRE library at http://www.pcre.org/ ? Maybe submitting a patch or bug report to them would cover a lot more open source projects, instead of patching the PCRE library used by php only. [2009-03-09 17:20:56] mmcnickle at gmail dot com It wouldn't be impossible, no. But to someone without detailed knowledge of Greek it would be. The unicode.org article on regular expressions [1] has this to say: "All of the above deals with a default specification for a regular expression. However, a regular expression engine also may want to support tailored specifications, typically tailored for a particular language or locale. This may be important when the regular expression engine is being used by end-users instead of programmers, such as in a word-processor allowing some level of regular expressions in searching." Earlier in the document it says about how basic regex engines are only required to include the basic unicode uppercase/lowercase matching. Looking though the source code of the PRCE library, it does seem possible to generate locale-specific character tables; this may be an avenue to look into. Perhaps the best thing to do would be to drop a message in the internationalization mailing list (http://marc.info/?l=php-i18n) and see what they have to say. [1] http://unicode.org/reports/tr18/#Tailored_Support [2009-03-09 16:01:59] sehh at ionos dot gr Indeed thats far from ideal, its impossible from my development point of view to re-write every single accented character with its possible equivalent for the entire string, for every string in the regex. For example, this: /Âáëâßäåò åéóáãùãÞò-åîáãùãÞò/i Would become a monster like this: /Âáëâ[É|ß|º]ä[Å|å|¸]ò åéóáãùã[Ç|Þ|¹]ò-åîáãùã[Ç|Þ|¹]ò/i We would need a regex to create the regex! or at least a text search/replace method in PHP. Are you sure its impossible to add a few exceptions within the PCRE library? [2009-03-09 15:25:51] mmcnickle at gmail dot com Yes, unfortunately trying to include locale and language specific cases is next to impossible for regular expression engine developers. The best that can be done, though far from ideal, is for the user to try to take these changes into account when they are crafting the regex: $target1 = "ÊÉÍÇÔ[Ç|Þ]ÑÁ"; // Greek; $target1 = "Stra[ss|ß]ebahn" // German [2009-03-09 15:00:25] sehh at ionos dot gr I forgot the capital accented characters, so the above should read: "Ç" == "Þ" == "ç" == "¹" "Á" == "Ü" == "á" == "¶" etc.. Remember that in Greek, the accent may be omitted from capital letters or may be included for the first letter only. So that should produce proper case-insensitive results. 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/47480 -- Edit this bug report at http://bugs.php.net/?id=47480&edit=1
#45684 [Com]: A request for foreach to be key-type agnostic.
ID: 45684
Comment by: fqqdk at freemail dot hu
Reported By: puts dot email at gmail dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: N/A
PHP Version: 5.3.0alpha1
New Comment:
I don't see why ArrayAccess can allow objects (or anything) as array
keys, and Iterator doesn't. This is inconsistent.
Previous Comments:
[2008-08-02 00:57:22] puts dot email at gmail dot com
Description:
A request for foreach to be key-type agnostic (ideally, assoc's would
be) so that the following is possible:
key);
return $this->val[$offset];
}
public function offsetSet($key, $val) {
$offset = array_search($key, $this->key);
if ($offset === false) {
$this->key[] = $key;
$this->val[] = $val;
} else {
$this->val[$offset] = $val;
}
}
public function offsetExists($key) {
return in_array($key, $this->key);
}
public function offsetUnset($key) {
$offset = array_search($key, $this->key);
unset($this->key[$offset], $this->val[$offset]);
}
public function rewind() {
reset($this->key);
reset($this->val);
}
public function key() {
return current($this->key);
}
public function current() {
return current($this->val);
}
public function next() {
next($this->key);
return next($this->val);
}
public function valid() {
return is_int(key($this->key));
}
}
$h = new hash;
$o0 = new stdclass;
$o1 = new stdclass;
$o2 = new stdclass;
$o3 = new stdclass;
foreach (array($o0, $o1, $o2, $o3) as $i => $o) {
$o->name = "o" . $i;
}
$h[$o0] = $o1;
$h[$o1] = $o2;
$h[$o2] = $o3;
foreach ($h as $key => $val) {}
?>
Reproduce code:
---
See description.
Expected result:
foreach ($h as $key => $val) {
# $key === $o[012]
# $val === $o[123]
}
Actual result:
--
foreach ($h as $key => $val) {
# Warning: Illegal type returned from Hash::key()
# $key === 0
# $val === $o[123]
}
--
Edit this bug report at http://bugs.php.net/?id=45684&edit=1
#47638 [NEW]: Random fatal error while using callback through array_udiff_assoc
From: luke at cywh dot com
Operating system: Linux, Mac OS X
PHP version: 5.2.9
PHP Bug Type: *Compile Issues
Bug description: Random fatal error while using callback through
array_udiff_assoc
Description:
When making a callback through array_udiff_assoc to a static function
this fatal error is produced, but randomly:
Fatal error: Non-static method (null)::(null)() cannot be called
statically in /opt/local/apache2/htdocs/site/cc.php on line 12
This error only occurs about 1/3 of the time or less, and usually
seems to happen right after saving a file. At first I thought it was
an eAccelerator issue as I could product this error almost every time
after re-saving the file (with or without changes), but I was also
able to reproduce this on my MacBook which I had installed the 5.2
branch on without any cache engines.
On a stock PHP installation with no extras it is mighty difficult to
reproduce this error. I was able to make it occur several times if I
refreshed the page 5-20 times after saving.
In the callback I'm referencing the function as a string:
"XC::greaterthan". I *think* using array('XC', 'greaterthan') corrects
the problem, but I am unsure as this error seems to occur completely
at random, and I have yet to have a 100% solid way of reproducing it.
The code below is the best way I was able to reproduce the occurrence.
Reproduce code:
---
class XC {
static public function greaterthan($value1, $value2) {
return $value1 > $value2;
}
}
class test {
function tester($num1, $num2) {
var_dump(array_intersect(
array_keys(
array_udiff_assoc(array('if' => $num1),
array('if' => $num2),
'XC::greaterthan')
), array('if')
));
}
}
$t = new test();
for($i=0; $i<10; $i++) {
$num1 = mt_rand(1, 100);
$num2 = mt_rand(1, 100);
$t->tester($num1, $num2);
}
Expected result:
No fatal error, just var dumps.
Actual result:
--
Fatal error: Non-static method (null)::(null)() cannot be called
statically in /opt/local/apache2/htdocs/site/cc.php on line 12
(Which points to the array_udiff_assoc function)
--
Edit bug report at http://bugs.php.net/?id=47638&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47638&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47638&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47638&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47638&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47638&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47638&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47638&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47638&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47638&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47638&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47638&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47638&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47638&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47638&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47638&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47638&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47638&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47638&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47638&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47638&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47638&r=mysqlcfg
#47636 [NEW]: Warning: ftp_put(....): failed to open stream "File too large"
From: password12345 at inwind dot it
Operating system: Debian
PHP version: 5.2.9
PHP Bug Type: FTP related
Bug description: Warning: ftp_put(): failed to open stream "File too large"
Description:
The file size is 2G.
Reproduce code:
---
$t=ftp_connect($ftp_server);
Echo "Logging...\n";
$ft=ftp_login($t,$ftp_user,$ftp_pass);
if (( !$t) || (!$ft)) {
echo "La connessione FTP è fallita a $ftp_server per l'utente
$ftp_user\n";
die;
} else
echo "Connesso a $ftp_server con utente $ftp_user\n";
ftp_chdir($t,"/$pathremote/bk".$act);
echo "/$pathremote/bk".$act."\n";
ftp_mkdir($t,"$name");
ftp_chdir($t,"$name");
if ($dir = @opendir("../ftp")) {
echo "Transfer $dir\n";
while ( ($file=readdir($dir))!==false ) {
if (!is_file("$path/$file") ) continue;
$trans++;
if (!ftp_put($t,$file,"$path/$file",FTP_BINARY))
echo "\nErrore put ftp file: $path/$file to
/$pathremote/bk$act/$name/\n\n";
//die("\nErrore ftp!\n\n");
else {
echo "Puting file: $path/$file to /$pathremote/bk$act/$name/\n";
exec("rm -f $path/$file");
}
}
closedir($dir);
}
--
Edit bug report at http://bugs.php.net/?id=47636&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47636&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47636&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47636&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47636&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47636&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47636&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47636&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47636&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47636&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47636&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47636&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47636&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47636&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47636&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47636&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47636&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47636&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47636&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47636&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47636&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47636&r=mysqlcfg
#46888 [Com]: copy() : safe_mode / allow_url_fopen
ID: 46888 Comment by: fuxa_kos at unihost dot cz Reported By: php at degoulet dot net Status: Open Bug Type: Safe Mode/open_basedir Operating System: Fedora Core PHP Version: 5.2.8 New Comment: problem still in 5.2.9 Previous Comments: [2008-12-17 15:22:50] php at degoulet dot net thanks : this workaround works fine ! [2008-12-17 14:58:32] christian at elmerot dot se The following patch restores part of behaviour from 5.2.6 yet has an extra check to see if the URL contains "../" which is where the removal came from. It is not a 100% correct "fix" in that it still allows for unknown URL vectors to bypass safe_mode, however, it is less broken this way for us. Perhaps the patch will help someone else. Remember, this is a safe_mode bypass issue that was fixed and the underlying cause (URLs: http: mapping to a local file incorrectly) looks to me unfixed. To me it looks as if safe_mode fails in this case but it also do no "extra" harm that won't be allowed with safe_mode disabled. Have I missed something? diff -Nur php-5.2.8/main/safe_mode.c php-5.2.8_1/main/safe_mode.c --- php-5.2.8/main/safe_mode.c 2008-07-24 18:01:59.0 +0200 +++ php-5.2.8_1/main/safe_mode.c2008-12-17 15:01:07.502862702 +0100 @@ -52,6 +52,7 @@ long uid=0L, gid=0L, duid=0L, dgid=0L; char path[MAXPATHLEN]; char *s, filenamecopy[MAXPATHLEN]; + php_stream_wrapper *wrapper = NULL; TSRMLS_FETCH(); path[0] = '\0'; @@ -72,6 +73,15 @@ mode = CHECKUID_CHECK_FILE_AND_DIR; } } + + /* +* If given filepath is a URL, allow - safe mode stuff +* related to URL's is checked in individual functions +* Possibly/likely allows for safe_mode bypass!!! +*/ + wrapper = php_stream_locate_url_wrapper(filename, NULL, STREAM_LOCATE_WRAPPERS_ONLY TSRMLS_CC); + if ((wrapper != NULL) && (strstr(filename, "..\/") == NULL)) + return 1; /* First we see if the file is owned by the same user... * If that fails, passthrough and check directory... [2008-12-17 14:44:14] php at degoulet dot net error msg : Warning: copy(): Unable to access http://www.x.com/testcopy/nok.jpg in //test.php [2008-12-17 14:17:58] php at degoulet dot net Description: copy() does not use the allow_url_fopen status ? Reproduce code: --- http://www.xx.com/testcopy/nok.jpg";, "nok_copy.jpg"); ?> Expected result: works fine in php 5.2.6 : with allow_url_fopen = On & safe_mode = On doesn't work with the same config php 5.2.8 now, it works only if safe_mode off ? -- Edit this bug report at http://bugs.php.net/?id=46888&edit=1
#47631 [Bgs]: Space missing in export query
ID: 47631 User updated by: rpaccard at roproductions dot com Reported By: rpaccard at roproductions dot com Status: Bogus Bug Type: MySQL related Operating System: Linux 2.6.18-92 PHP Version: 5.1.6 New Comment: My apologies, I followed a link called "bug report" in the phpMyAdmin 2.8.2.4 Documentation but it leads to php.net. Sorry for the inconvenience. Previous Comments: [2009-03-12 13:08:10] scott...@php.net Sounds like you're reporting a bug in a piece of software that isn't PHP. [2009-03-12 13:01:02] rpaccard at roproductions dot com Sorry I don't have any code to provide. It's when I use the "Copy table to (database.table):" command that it happens. [2009-03-12 12:09:03] scott...@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 , 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-03-12 09:02:00] rpaccard at roproductions dot com Description: The system I use runs PHP 5.1.6 and I have no power over this! When using the copy table feature, the CREATE TABLE query is missing a space and causes it to fail. There should be a space before "DEFAUlT CHARSET". Reproduce code: --- ENGINE = MYISAM AUTO_INCREMENT = 892DEFAULT CHARSET = utf8 PACK_KEYS =0 Expected result: Copy structure et data of table to a new one Actual result: -- MySQL said: #1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '892DEFAULT CHARSET = utf8 PACK_KEYS =0' at line 21 -- Edit this bug report at http://bugs.php.net/?id=47631&edit=1
#47631 [Opn->Bgs]: Space missing in export query
ID: 47631 Updated by: scott...@php.net Reported By: rpaccard at roproductions dot com -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: Linux 2.6.18-92 PHP Version: 5.1.6 New Comment: Sounds like you're reporting a bug in a piece of software that isn't PHP. Previous Comments: [2009-03-12 13:01:02] rpaccard at roproductions dot com Sorry I don't have any code to provide. It's when I use the "Copy table to (database.table):" command that it happens. [2009-03-12 12:09:03] scott...@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 , 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-03-12 09:02:00] rpaccard at roproductions dot com Description: The system I use runs PHP 5.1.6 and I have no power over this! When using the copy table feature, the CREATE TABLE query is missing a space and causes it to fail. There should be a space before "DEFAUlT CHARSET". Reproduce code: --- ENGINE = MYISAM AUTO_INCREMENT = 892DEFAULT CHARSET = utf8 PACK_KEYS =0 Expected result: Copy structure et data of table to a new one Actual result: -- MySQL said: #1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '892DEFAULT CHARSET = utf8 PACK_KEYS =0' at line 21 -- Edit this bug report at http://bugs.php.net/?id=47631&edit=1
#47630 [Com]: Unknown error using fsockopen() when with php-cgi through php cli
ID: 47630
Comment by: metala at metala dot org
Reported By: metala at metala dot org
Status: Open
Bug Type: Network related
Operating System: Windows XP SP2
PHP Version: 5.2.9
New Comment:
I tested it on another Windows XP machine and got the same result.
On the other hand with Debian GNU/Linux Squeeze I have no problems.
Previous Comments:
[2009-03-12 06:06:29] metala at metala dot org
Description:
The problem persists in 5.2.6, 5.2.9 and 5.2.9-1 in Windows only.
I have 2 script files, a parent.php and a child.php. The parent.php,
which is running in CLI, starts the child.php with php-cgi.exe.
fsockopen(), or any other network function fails.
Reproduce code:
---
parent.php
dirname(__FILE__).'\\child.php',
);
$descriptorspec = array(
0 => array("pipe", "r"),
1 => array("pipe", "w"),
2 => array("pipe", "w"),
);
$procName = 'php-cgi';
$proc = proc_open($procName, $descriptorspec, $pipes, null, $env,
array('bypass_shell' => true));
$read = array($pipes[1]);
stream_select($read, $null = array(), $null = array(), 100);
echo fread($read[0], 1024);
child.php
php parent.php
X-Powered-By: PHP/5.2.9-1
Content-type: text/html
Warning: fsockopen() [function.fsockopen]: unable to connect to 127.0.0.1:445 (Unknown error) in
H:\test\php\child.p
hp on line 2
int(0)
string(0) ""
--
Edit this bug report at http://bugs.php.net/?id=47630&edit=1
#47631 [Fbk->Opn]: Space missing in export query
ID: 47631 User updated by: rpaccard at roproductions dot com Reported By: rpaccard at roproductions dot com -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: Linux 2.6.18-92 -PHP Version: 5.2.9 +PHP Version: 5.1.6 New Comment: Sorry I don't have any code to provide. It's when I use the "Copy table to (database.table):" command that it happens. Previous Comments: [2009-03-12 12:09:03] scott...@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 , 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-03-12 09:02:00] rpaccard at roproductions dot com Description: The system I use runs PHP 5.1.6 and I have no power over this! When using the copy table feature, the CREATE TABLE query is missing a space and causes it to fail. There should be a space before "DEFAUlT CHARSET". Reproduce code: --- ENGINE = MYISAM AUTO_INCREMENT = 892DEFAULT CHARSET = utf8 PACK_KEYS =0 Expected result: Copy structure et data of table to a new one Actual result: -- MySQL said: #1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '892DEFAULT CHARSET = utf8 PACK_KEYS =0' at line 21 -- Edit this bug report at http://bugs.php.net/?id=47631&edit=1
#47631 [Opn->Fbk]: Space missing in export query
ID: 47631 Updated by: scott...@php.net Reported By: rpaccard at roproductions dot com -Status: Open +Status: Feedback Bug Type: MySQL related Operating System: Linux 2.6.18-92 PHP Version: 5.2.9 New Comment: 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 , 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. Previous Comments: [2009-03-12 09:02:00] rpaccard at roproductions dot com Description: The system I use runs PHP 5.1.6 and I have no power over this! When using the copy table feature, the CREATE TABLE query is missing a space and causes it to fail. There should be a space before "DEFAUlT CHARSET". Reproduce code: --- ENGINE = MYISAM AUTO_INCREMENT = 892DEFAULT CHARSET = utf8 PACK_KEYS =0 Expected result: Copy structure et data of table to a new one Actual result: -- MySQL said: #1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '892DEFAULT CHARSET = utf8 PACK_KEYS =0' at line 21 -- Edit this bug report at http://bugs.php.net/?id=47631&edit=1
#47633 [NEW]: Bcmath precision issue
From: k1ngrs at ntlworld dot com Operating system: Windows XP Pro SP2 PHP version: 5.2.9 PHP Bug Type: BC math related Bug description: Bcmath precision issue Description: The bcmath commands do not seem to work for numbers smaller than 0.0001 for exmaple if you add 0.1 and 0.1 the result is zero. Even setting the bcscale beforehand does not fix the issue. Reproduce code: --- Expected result: 1. 0.00011 + 0.00011 = 0.000220 2. 0.1 + 0.1 = 0.2 3. 0.1 - 0.05 = 0.05 Actual result: -- 1. 0.00011 + 0.00011 = 0.000220 OK 2. 0.1 + 0.1 = 0.00 Wrong 3. 0.1 - 0.05 = 0.00 Wrong -- Edit bug report at http://bugs.php.net/?id=47633&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47633&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47633&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47633&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47633&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47633&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47633&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47633&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47633&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47633&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47633&r=support Expected behavior: http://bugs.php.net/fix.php?id=47633&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47633&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47633&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47633&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47633&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47633&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47633&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47633&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47633&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47633&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47633&r=mysqlcfg
#47480 [Opn]: preg_replace with "/i" is not case insensitive
ID: 47480 User updated by: sehh at ionos dot gr Reported By: sehh at ionos dot gr Status: Open Bug Type: PCRE related Operating System: Linux PHP Version: 5.2.8 New Comment: Do you think it would be better if I contacted the developers of the PCRE library at http://www.pcre.org/ ? Maybe submitting a patch or bug report to them would cover a lot more open source projects, instead of patching the PCRE library used by php only. Previous Comments: [2009-03-09 17:20:56] mmcnickle at gmail dot com It wouldn't be impossible, no. But to someone without detailed knowledge of Greek it would be. The unicode.org article on regular expressions [1] has this to say: "All of the above deals with a default specification for a regular expression. However, a regular expression engine also may want to support tailored specifications, typically tailored for a particular language or locale. This may be important when the regular expression engine is being used by end-users instead of programmers, such as in a word-processor allowing some level of regular expressions in searching." Earlier in the document it says about how basic regex engines are only required to include the basic unicode uppercase/lowercase matching. Looking though the source code of the PRCE library, it does seem possible to generate locale-specific character tables; this may be an avenue to look into. Perhaps the best thing to do would be to drop a message in the internationalization mailing list (http://marc.info/?l=php-i18n) and see what they have to say. [1] http://unicode.org/reports/tr18/#Tailored_Support [2009-03-09 16:01:59] sehh at ionos dot gr Indeed thats far from ideal, its impossible from my development point of view to re-write every single accented character with its possible equivalent for the entire string, for every string in the regex. For example, this: /Âáëâßäåò åéóáãùãÞò-åîáãùãÞò/i Would become a monster like this: /Âáëâ[É|ß|º]ä[Å|å|¸]ò åéóáãùã[Ç|Þ|¹]ò-åîáãùã[Ç|Þ|¹]ò/i We would need a regex to create the regex! or at least a text search/replace method in PHP. Are you sure its impossible to add a few exceptions within the PCRE library? [2009-03-09 15:25:51] mmcnickle at gmail dot com Yes, unfortunately trying to include locale and language specific cases is next to impossible for regular expression engine developers. The best that can be done, though far from ideal, is for the user to try to take these changes into account when they are crafting the regex: $target1 = "ÊÉÍÇÔ[Ç|Þ]ÑÁ"; // Greek; $target1 = "Stra[ss|ß]ebahn" // German [2009-03-09 15:00:25] sehh at ionos dot gr I forgot the capital accented characters, so the above should read: "Ç" == "Þ" == "ç" == "¹" "Á" == "Ü" == "á" == "¶" etc.. Remember that in Greek, the accent may be omitted from capital letters or may be included for the first letter only. So that should produce proper case-insensitive results. [2009-03-09 14:54:32] sehh at ionos dot gr The PCRE library is wrong then. "Ç" is correctly defined in Unicode as "ç", but the library should also understand the meaning of "Ç" == "Þ" == "ç". This counts for all Greek accents: "Á" == "Ü" == "á" etc... Otherwise, the parameter "/i" is useless for the Greek language and thats why the current implementation does not work for Greek. Thank you for taking the time to look into this issue, much appreciated. 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/47480 -- Edit this bug report at http://bugs.php.net/?id=47480&edit=1
#47631 [NEW]: Space missing in export query
From: rpaccard at roproductions dot com Operating system: Linux 2.6.18-92 PHP version: 5.2.9 PHP Bug Type: MySQL related Bug description: Space missing in export query Description: The system I use runs PHP 5.1.6 and I have no power over this! When using the copy table feature, the CREATE TABLE query is missing a space and causes it to fail. There should be a space before "DEFAUlT CHARSET". Reproduce code: --- ENGINE = MYISAM AUTO_INCREMENT = 892DEFAULT CHARSET = utf8 PACK_KEYS =0 Expected result: Copy structure et data of table to a new one Actual result: -- MySQL said: #1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '892DEFAULT CHARSET = utf8 PACK_KEYS =0' at line 21 -- Edit bug report at http://bugs.php.net/?id=47631&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47631&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47631&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47631&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47631&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47631&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47631&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47631&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47631&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47631&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47631&r=support Expected behavior: http://bugs.php.net/fix.php?id=47631&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47631&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47631&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47631&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47631&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47631&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47631&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47631&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47631&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47631&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47631&r=mysqlcfg
#40479 [Com]: zend_mm_heap corrupted
ID: 40479 Comment by: john dot glazebrook at guava dot com Reported By: rrossi at maggioli dot it Status: No Feedback Bug Type: Reproducible crash Operating System: Suse Linux 9.0 PHP Version: 5.2.1 New Comment: I'm surprised this isn't being talked about more. I see it occasionally, and I am using Zend Framework. Why don't other people using ZF see it? Previous Comments: [2009-03-12 07:52:07] laurynas dot butkus at gmail dot com Soletan, thanks for advice but it seems that Suhosin is not 100% solution. We are running Ubuntu Hardy (8.04 LTS) server, 32bit. Using standard PHP 5.2.4 Apache2 module package which already includes Suhosin patch. We still experience this bug... [2009-03-06 14:22:25] soletan at toxa dot de Ran into the same problem and read most of the posts in this report. Well, I don't expect PHP developers to ever find this bug. Don't you get annoyed by template-driven posts asking for information they can't use? HERE COMES MY ADVICE: Reading hints on expecting a race condition lead me to installing suhosin, which is an extension to PHP increasing its integrity and security. Guess what, it helped me out of this trouble. This is no ad, so I won't provide a link here. Just google the name ... Maybe PHP developers shouldn't use templates requesting tons of backtracks providing obviously useless information, but invest some time in revising observers for the internal memory management of PHP as this is obviously causing the trouble. [2009-03-03 11:22:34] hakan dot koseoglu at gmail dot com The same problem appears from a allegedly successful compilation op PHP 5.2.9 on RHEL5 64 bit using -m32 CFLAG so that the binaries are 32 bit. The compilation appears to complete successfully: Apache 2.0.59 compiled w/o any problems with the following configure and it works fine. ./configure --prefix=/apps/apache2 --with-expat=builtin PHP is configured with the following options: ./configure --with-apxs2=/apps/apache2/bin/apxs --build=i386-redhat-linux --with-pic --with-gd --with-zlib --with-config-file-path=/apps/apache2/conf --with-libdir=/lib/ --enable-debug And after the successful run, make test was run with the following errors: [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-tests.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x08c71270 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:144, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0xD03365E6) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x097cdd80 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x512474AC) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x097cdb78 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x512474AC) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x097cd9ac status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x512474AC) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' /apps/source/php-5.2.9/main/streams/plain_wrapper.c(160) : Freeing 0x097CD9AC (108 bytes), script=/apps/source/php-5.2.9/run-test-info .php /apps/source/php-5.2.9/ext/standard/php_fopen_wrapper.c(312) : Actual location (location was relayed) Last leak repeated 2 times === Total 3 memory leaks detected === [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-tests.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x08c734c4 status: Beginning: OK (allocated on /apps/source/php-5.2.9/m
#40479 [Com]: zend_mm_heap corrupted
ID: 40479 Comment by: laurynas dot butkus at gmail dot com Reported By: rrossi at maggioli dot it Status: No Feedback Bug Type: Reproducible crash Operating System: Suse Linux 9.0 PHP Version: 5.2.1 New Comment: Soletan, thanks for advice but it seems that Suhosin is not 100% solution. We are running Ubuntu Hardy (8.04 LTS) server, 32bit. Using standard PHP 5.2.4 Apache2 module package which already includes Suhosin patch. We still experience this bug... Previous Comments: [2009-03-06 14:22:25] soletan at toxa dot de Ran into the same problem and read most of the posts in this report. Well, I don't expect PHP developers to ever find this bug. Don't you get annoyed by template-driven posts asking for information they can't use? HERE COMES MY ADVICE: Reading hints on expecting a race condition lead me to installing suhosin, which is an extension to PHP increasing its integrity and security. Guess what, it helped me out of this trouble. This is no ad, so I won't provide a link here. Just google the name ... Maybe PHP developers shouldn't use templates requesting tons of backtracks providing obviously useless information, but invest some time in revising observers for the internal memory management of PHP as this is obviously causing the trouble. [2009-03-03 11:22:34] hakan dot koseoglu at gmail dot com The same problem appears from a allegedly successful compilation op PHP 5.2.9 on RHEL5 64 bit using -m32 CFLAG so that the binaries are 32 bit. The compilation appears to complete successfully: Apache 2.0.59 compiled w/o any problems with the following configure and it works fine. ./configure --prefix=/apps/apache2 --with-expat=builtin PHP is configured with the following options: ./configure --with-apxs2=/apps/apache2/bin/apxs --build=i386-redhat-linux --with-pic --with-gd --with-zlib --with-config-file-path=/apps/apache2/conf --with-libdir=/lib/ --enable-debug And after the successful run, make test was run with the following errors: [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-tests.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x08c71270 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:144, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0xD03365E6) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x097cdd80 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x512474AC) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x097cdb78 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x512474AC) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x097cd9ac status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:160, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0x512474AC) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-test-info.php' /apps/source/php-5.2.9/main/streams/plain_wrapper.c(160) : Freeing 0x097CD9AC (108 bytes), script=/apps/source/php-5.2.9/run-test-info .php /apps/source/php-5.2.9/ext/standard/php_fopen_wrapper.c(312) : Actual location (location was relayed) Last leak repeated 2 times === Total 3 memory leaks detected === [Tue Mar 3 11:16:22 2009] Script: '/apps/source/php-5.2.9/run-tests.php' --- /apps/source/php-5.2.9/main/streams/plain_wrapper.c(421) : Block 0x08c734c4 status: Beginning: OK (allocated on /apps/source/php-5.2.9/main/streams/plain_wrapper.c:292, 108 bytes) Start: OK End: Overflown (magic=0x instead of 0xD03365E6) At least 4 bytes overflown --- [Tue Mar 3 11:16:22 2009] Script: '-' -
