Bug #51274 [Opn->Fbk]: Integer overflow does not cast as float

[aharvey]

Edit report at http://bugs.php.net/bug.php?id=51274&edit=1

 ID:   51274
 Updated by:   ahar...@php.net
 Reported by:  cduncan at regatta dot com
 Summary:  Integer overflow does not cast as float
-Status:   Open
+Status:   Feedback
 Type: Bug
 Package:  *General Issues
 Operating System: Linux
 PHP Version:  5.3.2

 New Comment:

I can't really see any way this could occur other than your server

having a 64-bit install of Linux on it. What distribution is the

server running, what does "uname -m" output, and what does configure

say the host and target system types are?



(Side note: the manual could admittedly be a bit clearer on this;

although the fact integer size differs on different platforms is

mentioned, it might be useful if the Integer Overflow section

actually reiterated it. I'll see about updating it.)


Previous Comments:

[2010-03-26 06:21:39] ssufficool at gmail dot com

64 bit ubuntu 10.04 PHP 5.3 SVN:

int(2147483647)

int(2147483648)



32 bit machine and OS PHP 5.2.10:

int(2147483647)

float(2147483648)


[2010-03-11 19:05:31] cduncan at regatta dot com

64bit machine, 32bit OS.

Also, wouldn't we expect a 64bit to return:



int(2147483647)

int(2147483648)


[2010-03-11 17:58:30] j...@php.net

Could it possibly be that you're running this on 64bit machine? :)


[2010-03-11 15:15:38] cduncan at regatta dot com

Description:

The manual (http://php.net/manual/pl/language.types.integer.php)
includes the following segment to cover integer overflow:







However when I try this on my recently upgraded server they are both
output as int(2147483647)

Test script:
---
$large_number =  2147483647;

var_dump($large_number);



$large_number =  2147483648;

var_dump($large_number);



Expected result:

I expect to see;



int(2147483647)

float(2147483648)



As I do on my box running 5.3.1



Actual result:
--
int(2147483647)

int(2147483647)








-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51274&edit=1

Bug #51274 [Com]: Integer overflow does not cast as float

[ssufficool at gmail dot com]

Edit report at http://bugs.php.net/bug.php?id=51274&edit=1

 ID:   51274
 Comment by:   ssufficool at gmail dot com
 Reported by:  cduncan at regatta dot com
 Summary:  Integer overflow does not cast as float
 Status:   Open
 Type: Bug
 Package:  *General Issues
 Operating System: Linux
 PHP Version:  5.3.2

 New Comment:

64 bit ubuntu 10.04 PHP 5.3 SVN:

int(2147483647)

int(2147483648)



32 bit machine and OS PHP 5.2.10:

int(2147483647)

float(2147483648)


Previous Comments:

[2010-03-11 19:05:31] cduncan at regatta dot com

64bit machine, 32bit OS.

Also, wouldn't we expect a 64bit to return:



int(2147483647)

int(2147483648)


[2010-03-11 17:58:30] j...@php.net

Could it possibly be that you're running this on 64bit machine? :)


[2010-03-11 15:15:38] cduncan at regatta dot com

Description:

The manual (http://php.net/manual/pl/language.types.integer.php)
includes the following segment to cover integer overflow:







However when I try this on my recently upgraded server they are both
output as int(2147483647)

Test script:
---
$large_number =  2147483647;

var_dump($large_number);



$large_number =  2147483648;

var_dump($large_number);



Expected result:

I expect to see;



int(2147483647)

float(2147483648)



As I do on my box running 5.3.1



Actual result:
--
int(2147483647)

int(2147483647)








-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51274&edit=1

Bug #51393 [Asn->Csd]: DateTime::createFromFormat() fails if format string contains timezone

[aharvey]

Edit report at http://bugs.php.net/bug.php?id=51393&edit=1

 ID:   51393
 Updated by:   ahar...@php.net
 Reported by:  jo at feuersee dot de
 Summary:  DateTime::createFromFormat() fails if format string
   contains timezone
-Status:   Assigned
+Status:   Closed
 Type: Bug
 Package:  Date/time related
 Operating System: Linux
 PHP Version:  5.3.2
 Assigned To:  aharvey

 New Comment:

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.




Previous Comments:

[2010-03-26 05:31:29] ahar...@php.net

Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&revision=296828
Log: Fixed bug #51393 (DateTime::createFromFormat() fails if format
string contains timezone).


[2010-03-25 21:19:03] jo at feuersee dot de

Description:

I was trying to process Apache logfiles with PHP. The default LogFormat
timestamp

%t translates to '[d/M/Y:H:i:s O]' in date() notation.

PHP fails to create DateTime instances if the format argument contains
timezone

placeholders like O P e



I am aware of the 3rd parameter of DateTime::createFromFormat() to pass
timezone

information. 

- the documentation says 'Format accepted by date()'

- DateTime is supposed to help parsing datetime formats, not to restrict

Test script:
---
$dt = DateTime::createFromFormat('[d/M/Y:H:i:s O]',
'[13/Mar/1969:23:40:00 +0100]');

print($dt->format('c'));

Expected result:

1969-03-13T23:40:00+01:00

Actual result:
--
Fatal error: Call to a member function format() on a non-object






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51393&edit=1

Bug #51393 [Opn->Asn]: DateTime::createFromFormat() fails if format string contains timezone

[aharvey]

Edit report at http://bugs.php.net/bug.php?id=51393&edit=1

 ID:   51393
 Updated by:   ahar...@php.net
 Reported by:  jo at feuersee dot de
 Summary:  DateTime::createFromFormat() fails if format string
   contains timezone
-Status:   Open
+Status:   Assigned
 Type: Bug
 Package:  Date/time related
 Operating System: Linux
 PHP Version:  5.3.2
-Assigned To:  
+Assigned To:  aharvey



Previous Comments:

[2010-03-25 21:19:03] jo at feuersee dot de

Description:

I was trying to process Apache logfiles with PHP. The default LogFormat
timestamp

%t translates to '[d/M/Y:H:i:s O]' in date() notation.

PHP fails to create DateTime instances if the format argument contains
timezone

placeholders like O P e



I am aware of the 3rd parameter of DateTime::createFromFormat() to pass
timezone

information. 

- the documentation says 'Format accepted by date()'

- DateTime is supposed to help parsing datetime formats, not to restrict

Test script:
---
$dt = DateTime::createFromFormat('[d/M/Y:H:i:s O]',
'[13/Mar/1969:23:40:00 +0100]');

print($dt->format('c'));

Expected result:

1969-03-13T23:40:00+01:00

Actual result:
--
Fatal error: Call to a member function format() on a non-object






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51393&edit=1

Bug #51396 [Opn->Fbk]: Math is Unreliable

[aharvey]

Edit report at http://bugs.php.net/bug.php?id=51396&edit=1

 ID:   51396
 Updated by:   ahar...@php.net
 Reported by:  codeslinger at compsalot dot com
 Summary:  Math is Unreliable
-Status:   Open
+Status:   Feedback
 Type: Bug
 Package:  Math related
 Operating System: any
 PHP Version:  Irrelevant

 New Comment:

It looks like the Web server you've posted the sample code to is

interpreting the PHP files, so it's impossible to get the source.

If you could upload the files with an extension that's not being

handled by your PHP module, that would be handy.



If there's any chance of a more minimal test case, that would also

be rather useful.



Finally, without wanting to sound overly snarky, that description

was about 1200 words too long and infinitely too overwrought.

Brevity is appreciated.


Previous Comments:

[2010-03-26 00:36:48] codeslinger at compsalot dot com

Description:

is math accuracy important?

no I am not talking about round-off errors.  I am talking about the fact
that most of the time, php correctly says that 2+2 = 4, but that
sometimes it says that 2+2 = 0.



What if your paycheck was being printed by a php program and you
discovered that the math is inaccurate, would you care then?



I ask these questions because I previously reported this bug because it
occurred in a billing system that I wrote, but nobody considered that
bug important enough to pursue it.  Too complex, too hard to reproduce. 
whatever.



Well, I have now encountered this bug again, with a much simpler
program.  and this program demonstrates that math in php is completely
and totally untrustworthy.  Does anyone care that fundamental
functionality is unreliable?  What good is a programming language that
can't do math?



php passes trivial math tests just fine; it's only when you use it in
complex real-world ways that it starts failing.  No these aren't binary
base conversion errors, I'm guessing that this is memory corruption, so
far I've only observed it with thousands of calculations.  But the
trivial programs I wrote in an attempt to reproduce the problem never
succeeded in failing.  I can only get it to fail when I'm doing
real-world / complex stuff



Characteristics:

This is not a bug in the php program; under specific conditions -
described below - the php program does run correctly.



The main problem occurs when a float is converted to a string by a
program that makes heavy use of arrays.



It's not an out of memory condition, I have successfully stress tested
an array with one million items, but I am seeing it fail with only a
thousand items.



When it fails, the failure it totally repeatable, it always fails in
exactly the same place in exactly the same way.  And yet there is no
discernible pattern to the failure, the trigger condition is
unpredictable, it seems to depend on the actual data values.



It is not a hardware issue, this has been observed on multiple machines.
 Also my main computer has had extensive memory diagnostic and hard disk
tests run on it without finding any problems.



It is not operating system specific, this failure has been observed on
both Linux and Windows.



It is not an FDIV bug.  This Pentium chip is verified to not have that
bug.



Different versions of php are triggered by different sequences of
events.  But all of them fail in some way.



I have two programs, both of which fail, but the specifics of the
failure vary depending on which version of php they are being run on.



One program is a billing system, it is large and complex and proprietary
and the data is confidential and it uses several external libraries. The
other program generates a Koch Snowflake (a type of graphics fractal). 
It is small and has no required dependencies and I am happy to make it's
source code available.



Both fail with the same or similar math errors but the behavior is not
identical.



The billing system *appears* to run fine on Windows PHP 5.2.5 (standard
build as provided by php.net).  The billing system is in daily use and
no errors have been reported... so far...



At one point it was decided to upgrade to PHP 5.2.9 (standard build from
php.net).  The billing system passed the preliminary testing with dummy
data and the php upgrade was deployed to the field.  



Result:  Can you spell NIGHTMARE?!!!  I knew you could...  

Many instances of invalid statements being created.  The math errors
were repeatable.  We are talking simple arithmetic about 90 percent of
it is just adding, with a few multiplications.  This was entered as bug
#47716 



Everyone was downgraded back to php 5.2.5  and the bug report was blown
off.



I also confirmed that the bug existed in 5.2.11

I  assumed that the bug did not exist in 5.2.5



An attempt was made to test 3.x but that was impossible because the
billing system requires various l

Bug #50976 [Com]: Soap headers Authorization not allowed

[bfra...@php.net]

Edit report at http://bugs.php.net/bug.php?id=50976&edit=1

 ID:  50976
 Comment by:  bfra...@php.net
 Reported by: bfra...@php.net
 Summary: Soap headers Authorization not allowed
 Status:  Assigned
 Type:Bug
 Package: SOAP related
 PHP Version: 5.3.1
 Assigned To: dmitry

 New Comment:

I am removing oauthsoapsample.php.txt as there was bad code in that and
mail asked me to remove it.



I have added:



http://www.brianfrance.com/software/php/soap_http_headers/phpsample.zip



which has multiple scripts that show the problem.


Previous Comments:

[2010-02-09 17:08:24] bfra...@php.net

Description:

http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/soap/php_http.c?r1=266886&r2=266885&pathrev=266886



This patch adds support to add headers into the http context, but
doesn't allow the Authorization header for some reason.



I added a patch to our 5.2 build that would add all headers in the http
context and remove that patch in 5.3 because I noticed the above patch. 
Somebody at work is needing to add Authorization header to get OAuth
stuff working, but for some reason it is not allowed.



Here is a patch that will allow the Authorization header:



http://www.brianfrance.com/software/php/soap_http_headers/soap_http_headers.diff

Reproduce code:
---
Here is an example script that requires the Authorization when used for
the OAuth stuff.



http://www.brianfrance.com/software/php/soap_http_headers/oauthsoapsample.php.txt







-- 
Edit this bug report at http://bugs.php.net/bug.php?id=50976&edit=1

[PHP-BUG] Bug #51396 [NEW]: Math is Unreliable

[codeslinger at compsalot dot com]

From: 
Operating system: any
PHP version:  Irrelevant
Package:  Math related
Bug Type: Bug
Bug description:Math is Unreliable

Description:

is math accuracy important?

no I am not talking about round-off errors.  I am talking about the fact
that most of the time, php correctly says that 2+2 = 4, but that sometimes
it says that 2+2 = 0.



What if your paycheck was being printed by a php program and you discovered
that the math is inaccurate, would you care then?



I ask these questions because I previously reported this bug because it
occurred in a billing system that I wrote, but nobody considered that bug
important enough to pursue it.  Too complex, too hard to reproduce. 
whatever.



Well, I have now encountered this bug again, with a much simpler program. 
and this program demonstrates that math in php is completely and totally
untrustworthy.  Does anyone care that fundamental functionality is
unreliable?  What good is a programming language that can't do math?



php passes trivial math tests just fine; it's only when you use it in
complex real-world ways that it starts failing.  No these aren't binary
base conversion errors, I'm guessing that this is memory corruption, so far
I've only observed it with thousands of calculations.  But the trivial
programs I wrote in an attempt to reproduce the problem never succeeded in
failing.  I can only get it to fail when I'm doing real-world / complex
stuff



Characteristics:

This is not a bug in the php program; under specific conditions - described
below - the php program does run correctly.



The main problem occurs when a float is converted to a string by a program
that makes heavy use of arrays.



It's not an out of memory condition, I have successfully stress tested an
array with one million items, but I am seeing it fail with only a thousand
items.



When it fails, the failure it totally repeatable, it always fails in
exactly the same place in exactly the same way.  And yet there is no
discernible pattern to the failure, the trigger condition is unpredictable,
it seems to depend on the actual data values.



It is not a hardware issue, this has been observed on multiple machines. 
Also my main computer has had extensive memory diagnostic and hard disk
tests run on it without finding any problems.



It is not operating system specific, this failure has been observed on both
Linux and Windows.



It is not an FDIV bug.  This Pentium chip is verified to not have that
bug.



Different versions of php are triggered by different sequences of events. 
But all of them fail in some way.



I have two programs, both of which fail, but the specifics of the failure
vary depending on which version of php they are being run on.



One program is a billing system, it is large and complex and proprietary
and the data is confidential and it uses several external libraries. The
other program generates a Koch Snowflake (a type of graphics fractal).  It
is small and has no required dependencies and I am happy to make it's
source code available.



Both fail with the same or similar math errors but the behavior is not
identical.



The billing system *appears* to run fine on Windows PHP 5.2.5 (standard
build as provided by php.net).  The billing system is in daily use and no
errors have been reported... so far...



At one point it was decided to upgrade to PHP 5.2.9 (standard build from
php.net).  The billing system passed the preliminary testing with dummy
data and the php upgrade was deployed to the field.  



Result:  Can you spell NIGHTMARE?!!!  I knew you could...  

Many instances of invalid statements being created.  The math errors were
repeatable.  We are talking simple arithmetic about 90 percent of it is
just adding, with a few multiplications.  This was entered as bug #47716 



Everyone was downgraded back to php 5.2.5  and the bug report was blown
off.



I also confirmed that the bug existed in 5.2.11

I  assumed that the bug did not exist in 5.2.5



An attempt was made to test 3.x but that was impossible because the billing
system requires various libraries which are not available for version 3 of
php.

And that is where things have sat until now.



New program, Koch Snowflake generator.

I'm doing some experiments with 3d graphics.  This was written as a study
in how to do it.  I ran into exactly the same math -- string conversion
bug, that the billing system ran into.



But the Koch Snowflake program Fails on Ubuntu Linux with php 5.2.4!!!



What triggers this bug is a very complex unpredictable sequence of events. 
And yet the failure is totally repeatable.  Being a fractal, it has an
outer loop of iterations which determine the complexity of the object. 
When I run 4 outer loops the program works fine, when I run 6 outer loops
the program also works fine -- thus proving that it is not running out of
memory.  But when I run 5 outer loops the program fails and it always fails
at item 7747.



But w

Bug #51216 [Com]: Segmentation fault when compiling PHP with PHAR

[mm_half3 at yahoo dot com]

Edit report at http://bugs.php.net/bug.php?id=51216&edit=1

 ID:   51216
 Comment by:   mm_half3 at yahoo dot com
 Reported by:  dtm2mcs at gmail dot com
 Summary:  Segmentation fault when compiling PHP with PHAR
 Status:   Open
 Type: Bug
 Package:  PHAR related
 Operating System: Ubuntu 6.04 + CentOS 5.4
 PHP Version:  5.3.2

 New Comment:

For what it is worth, I had the same issue on Solaris 10 sparc,
compiling with gcc-4.3.1, and php-5.32 (tried with stable release and
latest development src).   Further research found other solaris types
getting segmentation faults during php 5.2.xx make test, see
http://bugs.php.net/bug.php?id=47824&edit=1 .  Which I also could
reproduce.  Setting CFLAGS=-O1, got php5.32 to compile and make test
successfully with phar, and 5.2.xx to compile without fatal errors.  The
seg fault is probably not a php issue, but something in the gcc version.
 The make test looks like all the tests run, but there is an issue when
the Test Summary is done for both:



WARNED TEST SUMMARY

-

via [ext/pdo_sqlite/tests/common.phpt]

SQLite PDO Common: Bug #34630 (inserting streams as LOBs)
[ext/pdo_sqlite/tests/bug_34630.phpt] (warn: XFAIL section but test
passes)

via [ext/sqlite/tests/pdo/common.phpt]

SQLite2 PDO Common: Bug #34630 (inserting streams as LOBs)
[ext/sqlite/tests/pdo/bug_34630.phpt] (warn: XFAIL section but test
passes)

=



You may have found a problem in PHP.

We would like to send this report automatically to the

PHP QA team, to give us a better understanding of how

the test cases are doing. If you don't want to send it

immediately, you can choose "s" to save the report to

a file that you can send us later.

Do you want to send this report now? [Yns]: s

Please send /tmp/php-5.3.2/php_test_results_20100325_2040.txt to
qa-repo...@lists.php.net manually, thank you.


Previous Comments:

[2010-03-24 17:51:27] paul at boxuk dot com

i can also reproduce this, i believe it's something to do with the fix
for bug 

#50829



amended that bug with the details


[2010-03-22 11:32:02] creatorbri at gmail dot com

I have the same problem when attempting to compile PHP 5.3.2. Details:



PHP Version:

PHP 5.3.2 - I downloaded the "stable" release dated "04 Mar 2010"
directly from 

one of the usual php.net mirrors



Platform:

Ubuntu 9.10 Karmic Koala x64

[Asus G60Jx-RBBx05 - Core i5-430 2.26 GHz 4.0 GB RAM]



Configure Options:

./configure --prefix=PREFIX --with-apxs2=/usr/bin/apxs2
--with-mysql=/usr --

with-mysqli=/usr/bin/mysql_config --with-pgsql=/usr --with-tidy=/usr
--with-

curl=/usr/bin --with-curlwrappers --with-openssl-dir=/usr
--with-zlib-dir=/usr -

-enable-mbstring --with-xpm-dir=/usr --with-pdo-pgsql=/usr
--with-pdo-mysql=/usr 

--with-xsl=/usr --with-ldap --with-xmlrpc --with-iconv-dir=/usr
--with-snmp=/usr 

--enable-exif --enable-calendar --with-bz2=/usr --with-mcrypt=/usr
--with-gd --

with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/usr
--with-freetype-

dir=/usr --enable-mbstring --enable-zip --with-pear



ERROR:

ext/sqlite3/libsqlite/.libs/sqlite3.o: In function `memset':

/usr/include/bits/string3.h:82: warning: memset used with constant zero
length 

parameter; this could be due to transposed parameters

Generating phar.php

Segmentation fault

make: *** [ext/phar/phar.php] Error 139


[2010-03-16 16:22:12] vnegrier at optilian dot com

Not PHAR related, this is actually the php-cli binary segfaulting during
the make process.



Here is a trace :



0x0839c8f4 in zend_startup_module_ex (module=0x8732210,
tsrm_ls=0x8712070)

at /usr/src/php-5.3.2/Zend/zend_API.c:1618

1618EG(current_module) = NULL;

(gdb) where

#0  0x0839c8f4 in zend_startup_module_ex (module=0x8732210,
tsrm_ls=0x8712070)

at /usr/src/php-5.3.2/Zend/zend_API.c:1618

#1  0x083a177a in zend_hash_apply (ht=0x8711460,

apply_func=0x839c850 , tsrm_ls=0x8712070)

at /usr/src/php-5.3.2/Zend/zend_hash.c:673

#2  0x0839c75a in zend_startup_modules (tsrm_ls=0x8712070)

at /usr/src/php-5.3.2/Zend/zend_API.c:1662

#3  0x083372f0 in php_module_startup (sf=0x86f82c0,
additional_modules=0x0,

num_additional_modules=0) at /usr/src/php-5.3.2/main/main.c:2022

#4  0x084299f1 in php_cli_startup (sapi_module=0x86f82c0)

at /usr/src/php-5.3.2/sapi/cli/php_cli.c:401

#5  0x0842a32c in main (argc=1, argv=0xbfffcf74)

at /usr/src/php-5.3.2/sapi/cli/php_cli.c:775



This was reproduced on debian 5.0.4 x86


[2010-03-12 11:39:22] jedibc at free dot fr

Same i

Bug #51395 [Opn->Bgs]: implemeting an interface causes class not found

[johannes]

Edit report at http://bugs.php.net/bug.php?id=51395&edit=1

 ID:   51395
 Updated by:   johan...@php.net
 Reported by:  johnston dot joshua at gmail dot com
 Summary:  implemeting an interface causes class not found
-Status:   Open
+Status:   Bogus
 Type: Bug
 Package:  Scripting Engine problem
 Operating System: OS X, FreeBSD
 PHP Version:  5.3.2

 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

This is a documented limitation of the object implementation and the way
we do object binding.


Previous Comments:

[2010-03-25 23:12:27] johnston dot joshua at gmail dot com

Description:

Normally you can declare classes in any order inside of a php file. When
one of your classes implements an interface, php will throw a fatal
error about class not found if the class is declared in the wrong
order.



If you remove the implements clause then order does not matter.



php bug http://bugs.php.net/bug.php?id=39758 also shows this and the
reply from dmitry was:



PHP always declares classes those implement interfaces at run-time. So
in your example you cannot declare "Bar" because "Foo" is not declared
yet.

Your report may be categorised as "feature request", but it cannot be
fixed in 5.2.* anyway, because of binary compatibility.





Just because the internals handle things in a certain order does not
mean that php should exhibit contradicting behavior based on valid class
definitions.

Test script:
---
test.php





test2.php



Expected result:

test.php:

no output



test2.php:

no output

Actual result:
--
jjohnston:~$ php test.php 

PHP Fatal error:  Class 'Two' not found in /Users/jjohnston/test.php on
line 2



Fatal error: Class 'Two' not found in /Users/jjohnston/test.php on line
2



jjohnston:~$ php test2.php






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51395&edit=1

Bug #36073 [Wfx]: Source-compiled MySQL on x86_64 causes PHP configure failure

[chris at spawnordie dot com]

Edit report at http://bugs.php.net/bug.php?id=36073&edit=1

 ID:   36073
 User updated by:  chris at spawnordie dot com
 Reported by:  chris at spawnordie dot com
 Summary:  Source-compiled MySQL on x86_64 causes PHP configure
   failure
 Status:   Wont fix
 Type: Bug
 Package:  Compile Failure
 Operating System: Linux/Any
 PHP Version:  5.1.2

 New Comment:

Other than the bug reviewer just being a flat-out ass...



It is still a bug in PHP.  The PHP configure process honors the
"--with-libdir" 

value for PostgreSQL and many, many other packages, but NOT for its
check of 

MySQL.  It is NOT a bug in MySQL, which installs its libraries in lib64,
just 

like every other application that is compiled for 64bit OS.  But PHP
somehow 

"magically" knows how to find all of those other applications.  At the
very 

least, it is an inconsistency that could have been cleaned up with 15
minutes of 

effort by the PHP team when I reported the bug 4 years ago!



And, based on the fact that I provided a work-around, it should have
been clear 

that I did, in fact, know what I was doing.  Maybe my feelings were a
little 

hurt, but there's no excuse for the rudeness this bug reviewer showed. 
I 

sincerely hope that he/she is no longer in that role -- or doing
anything that 

requires using any level of tact with actual people -- because he/she is
just a 

jerk and is in serious need of therapy.  Maybe he/she didn't get hugged
as a 

child and is displaying a superiority complex to cover up low
self-esteem and 

fear of being hurt.  But I digress.


Previous Comments:

[2010-03-25 18:32:22] michael at michaelsnet dot us

IMHO this is a documentation bug.  Consider adding a README.64bit file
containing this information and other relevant information.


[2006-01-18 23:53:50] sni...@php.net

Works fine for me.

Hint: Don't try building Mysql yourself if you don't know how to do it
properly. Use the binary packages provided by MySQL.

And last but not least: report this to MySQL. It's not our fault if they
do things wrong.


[2006-01-18 22:14:10] chris at spawnordie dot com

Description:

Please accept my apologies if this is already reported - I searched and
didn't find it.



When configuring PHP for x86_64, it is necessary to use:

--with-libdir=lib64



When you compile MySQL from source, it does not place its files in
lib64, but rather lib.



MySQL was configured using:

--prefix=/usr/local/mysql



Configuring PHP using:

--with-mysql=/usr/local/mysql

fails with this:

checking for MySQL support... yes

checking for specified location of the MySQL UNIX socket... no

checking for MySQL UNIX socket location... no

configure: error: Cannot find libmysqlclient under /usr/local/mysql.

Note that the MySQL client library is not bundled anymore!



This fixes the problem:

cd /usr/local/mysql

ln -s lib lib64



When PHP is configured using --with-mysql= and
--with-libdir=, it should search / and then
/lib

Reproduce code:
---
./configure --with-mysql= when MySQL is compiled from
source code

Expected result:

successful configure

Actual result:
--
configure fails with:

checking for MySQL support... yes

checking for specified location of the MySQL UNIX socket... no

checking for MySQL UNIX socket location... no

configure: error: Cannot find libmysqlclient under /usr/local/mysql.

Note that the MySQL client library is not bundled anymore!








-- 
Edit this bug report at http://bugs.php.net/bug.php?id=36073&edit=1

[PHP-BUG] Bug #51395 [NEW]: implemeting an interface causes class not found

[johnston dot joshua at gmail dot com]

From: 
Operating system: OS X, FreeBSD
PHP version:  5.3.2
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:implemeting an interface causes class not found

Description:

Normally you can declare classes in any order inside of a php file. When
one of your classes implements an interface, php will throw a fatal error
about class not found if the class is declared in the wrong order.



If you remove the implements clause then order does not matter.



php bug http://bugs.php.net/bug.php?id=39758 also shows this and the reply
from dmitry was:



PHP always declares classes those implement interfaces at run-time. So in
your example you cannot declare "Bar" because "Foo" is not declared yet.

Your report may be categorised as "feature request", but it cannot be fixed
in 5.2.* anyway, because of binary compatibility.





Just because the internals handle things in a certain order does not mean
that php should exhibit contradicting behavior based on valid class
definitions.

Test script:
---
test.php





test2.php



Expected result:

test.php:

no output



test2.php:

no output

Actual result:
--
jjohnston:~$ php test.php 

PHP Fatal error:  Class 'Two' not found in /Users/jjohnston/test.php on
line 2



Fatal error: Class 'Two' not found in /Users/jjohnston/test.php on line 2



jjohnston:~$ php test2.php

-- 
Edit bug report at http://bugs.php.net/bug.php?id=51395&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51395&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51395&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51395&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51395&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=51395&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51395&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=51395&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=51395&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=51395&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=51395&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=51395&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=51395&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=51395&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51395&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=51395&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51395&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=51395&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=51395&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=51395&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=51395&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=51395&r=mysqlcfg

Bug #32101 [NoF]: Exception in unknown on line 0 when throwing exception inside exception handler

[stas]

Edit report at http://bugs.php.net/bug.php?id=32101&edit=1

 ID:   32101
 Updated by:   s...@php.net
 Reported by:  ceefour at gauldong dot net
 Summary:  Exception in unknown on line 0 when throwing exception
   inside exception handler
 Status:   No Feedback
 Type: Bug
 Package:  Scripting Engine problem
 Operating System: *
 PHP Version:  5CVS-2005-02-15

 New Comment:

Maybe related to Bug #51394


Previous Comments:

[2007-10-30 01:00:01] 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-10-22 08:48:40] j...@php.net

Does this still happen using latest CVS snapshot/checkout of PHP 5.2
branch?


[2007-10-22 08:47:25] j...@php.net

See also bug #43016




[2007-10-18 11:26:41] ceefour at gauldong dot net

You know, "complicated" stack traces like the one you get in Java would
be much more helpful than this message. Or the one in Erlang. Or in Ruby
with Rails.


[2007-10-18 10:39:04] gerrit dot boettcher at gmail dot com

Got the same Problem with the ErrorHandler

Just in win32. In Linux this works great.



SourceCode:

---

--- header.php (Load before any output started or other PHP files
loaded)

set_error_handler(array('main','handleError'), E_ALL);



--- main.class.php

final class main {

   [...]

public static function handleError($errorNo, $message, $filename,
$lineNo) {

$errReport = error_reporting();



if ($errReport != 0) {

if ($errorNo != 8) {

$type = 'error';

switch ($errorNo) {

case 2: $type = 'warning';

break;

}



throw new SystemException('PHP '.$type.' in 
file '.$filename.'
('.$lineNo.'): '.$message, 0);

}

}

}

   [...]

}



--- systemexception.class.php (loaded before main.class.php)

require_once('exceptions/printableexception.class.php');

class SystemException extends Exception implements PrintableException {

[...]

public function show() {

echo '...[...template...]...';

}

[...]

}



--- printableexception.class.php

interface PrintableException {

public function show();

}

--- EOF --



On Linux Systems: anything works great!

On Windows Systems: Exception thrown without a stack frame in Unknown on
line 0




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=32101


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=32101&edit=1

[PHP-BUG] Bug #51394 [NEW]: Error line reported incorrectly iif error handler throws an exception

[stas at zend dot com]

From: 
Operating system: *
PHP version:  5.3SVN-2010-03-25 (SVN)
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:Error line reported incorrectly iif error handler throws an 
exception

Description:

The test script code produces the following error:



[25-Mar-2010 13:25:29] PHP Fatal error:  Function name must be a string in
test.php on line 0



This is because there's actually two errors:

1. Undefined $empty notice

2. Function name must be string - fatal error



When error (1) is processed, due to the exception opline_ptr is set to the
exception handler opcode, so when the engine wants to report error (2) it
doesn't have proper opline_ptr to report the error. 

Test script:
---
http://bugs.php.net/bug.php?id=51394&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51394&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51394&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51394&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51394&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=51394&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51394&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=51394&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=51394&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=51394&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=51394&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=51394&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=51394&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=51394&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51394&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=51394&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51394&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=51394&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=51394&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=51394&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=51394&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=51394&r=mysqlcfg

[PHP-BUG] Bug #51393 [NEW]: DateTime::createFromFormat() fails if format string contains timezone

[jo at feuersee dot de]

From: 
Operating system: Linux
PHP version:  5.3.2
Package:  Date/time related
Bug Type: Bug
Bug description:DateTime::createFromFormat() fails if format string contains 
timezone

Description:

I was trying to process Apache logfiles with PHP. The default LogFormat
timestamp

%t translates to '[d/M/Y:H:i:s O]' in date() notation.

PHP fails to create DateTime instances if the format argument contains
timezone

placeholders like O P e



I am aware of the 3rd parameter of DateTime::createFromFormat() to pass
timezone

information. 

- the documentation says 'Format accepted by date()'

- DateTime is supposed to help parsing datetime formats, not to restrict

Test script:
---
$dt = DateTime::createFromFormat('[d/M/Y:H:i:s O]', '[13/Mar/1969:23:40:00
+0100]');

print($dt->format('c'));

Expected result:

1969-03-13T23:40:00+01:00

Actual result:
--
Fatal error: Call to a member function format() on a non-object

-- 
Edit bug report at http://bugs.php.net/bug.php?id=51393&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51393&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51393&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51393&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51393&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=51393&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51393&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=51393&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=51393&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=51393&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=51393&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=51393&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=51393&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=51393&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51393&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=51393&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51393&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=51393&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=51393&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=51393&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=51393&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=51393&r=mysqlcfg

Bug #50584 [Opn->Asn]: Windows installer does not configure Apache in silent mode

[jmertic]

Edit report at http://bugs.php.net/bug.php?id=50584&edit=1

 ID:   50584
 Updated by:   jmer...@php.net
 Reported by:  mkucej at yahoo dot com
 Summary:  Windows installer does not configure Apache in silent
   mode
-Status:   Open
+Status:   Assigned
 Type: Bug
 Package:  Windows Installer
 Operating System: Windows XP SP2
 PHP Version:  5.3.1
-Assigned To:  
+Assigned To:  jmertic



Previous Comments:

[2009-12-26 23:52:13] mkucej at yahoo dot com

Description:

Windows installer does not configure Apache in silent mode. It will
insert the following into the httpd.conf:



#BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL

#END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL



This happens only in the silent mode.

Reproduce code:
---
msiexec /I php.msi /qn+ INSTALLDIR="C:\Program Files\PHP"
APACHEDIR="C:\Program Files\Apache Software Foundation\Apache2.2\conf\"
ADDLOCAL=ScriptExecutable,cgi,apache22,ext_php_pdo_sqlite /L c:\log.txt

Actual result:
--
#BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL

#END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=50584&edit=1

Bug #50455 [Asn->Bgs]: After installing PHP, I see "php fatal error related to include_path"

[jmertic]

Edit report at http://bugs.php.net/bug.php?id=50455&edit=1

 ID:   50455
 Updated by:   jmer...@php.net
 Reported by:  nevasha at rocketmail dot com
 Summary:  After installing PHP, I see "php fatal error related
   to include_path"
-Status:   Assigned
+Status:   Bogus
 Type: Bug
 Package:  Windows Installer
 Operating System: Windows XP Professional sp 2
 PHP Version:  5.3.1
 Assigned To:  jmertic

 New Comment:

Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.




Previous Comments:

[2009-12-11 23:53:36] nevasha at rocketmail dot com

I also notice with the same installation if I set to include one of the


dynamic extensions with the following configuration:



extension_dir="D:\Tools\PHP\ext"

extension=php_bz2.dll



I see the following fatal error any time I invoked php-win.exe or 

php.exe:



CLI has encountered a problem and needs to close.  We are sorry for the


inconvenience.



It doesn't matter which dynamic extension I include this error occurs 

every time. Yes the files that are specified in the dynamic extension do


exist.


[2009-12-11 22:48:37] nevasha at rocketmail dot com

Description:

I installed PHP 5.3.1 using windows installer and following the 

installation guide. After running the modified go-pear.bat (the 

modification needed was: %PHP_BIN% -d phar.require_hash=0 PEAR\go-

pear.phar) I see that php.ini has been correctly updated with:



;* Added by go-pear

include_path=".;D:\Tools\PHP\pear"

;*



However when I run php-win.exe I see the following error message in 

the log file:



PHP Fatal error:  Unknown: Failed opening required '-' 

(include_path='.;D:\Tools\PHP\pear') in Unknown on line 0





Actual result:
--
However when I run php-win.exe I see the following error message in the


log file:



PHP Fatal error:  Unknown: Failed opening required '-' 

(include_path='.;D:\Tools\PHP\pear') in Unknown on line 0








-- 
Edit this bug report at http://bugs.php.net/bug.php?id=50455&edit=1

Bug #50394 [Com]: Reference argument converted to value in __call

[enverhan222 at hotmail dot com]

Edit report at http://bugs.php.net/bug.php?id=50394&edit=1

 ID:   50394
 Comment by:   enverhan222 at hotmail dot com
 Reported by:  tstarling at wikimedia dot org
 Summary:  Reference argument converted to value in __call
 Status:   Closed
 Type: Bug
 Package:  Scripting Engine problem
 Operating System: Linux
 PHP Version:  5.3.1

 New Comment:

http://www.facebook.com/sharer.php";>Paylaşhttp://static.ak.fbcdn.net/connect.php/js/FB.Share";
type="text/javascript">


Previous Comments:

[2010-03-21 22:01:32] tstarling at wikimedia dot org

This bug was fixed in 5.3.2. The problem you reported on mediawiki.org
was not a PHP bug.


[2010-03-21 21:57:04] spam dot here at verizon dot net

Mediawiki still reports that the problem still exists.



http://www.mediawiki.org/wiki/Project:Support_desk#PHP_5.3_Problem_Still_Exists



And it is still in their install document.



http://www.mediawiki.org/wiki/Installation



"PHP version 5.1 or later (5.2.x recommended). PHP 5.3.1 is incompatible
with MediaWiki due to a bug."


[2009-12-18 19:20:33] s...@php.net

Automatic comment from SVN on behalf of stas
Revision: http://svn.php.net/viewvc/?view=revision&revision=292296
Log: Fixed bug #50394 (Reference argument converted to value in __call)


[2009-12-18 19:13:37] 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.

fixed, thanks


[2009-12-18 19:12:12] s...@php.net

Automatic comment from SVN on behalf of stas
Revision: http://svn.php.net/viewvc/?view=revision&revision=292295
Log: fix regression bug #50394: Reference argument converted to value in
__call




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=50394


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=50394&edit=1

Bug #50765 [Asn->Csd]: Error message executing php - oci.dll was not found

[jmertic]

Edit report at http://bugs.php.net/bug.php?id=50765&edit=1

 ID:   50765
 Updated by:   jmer...@php.net
 Reported by:  andreas dot mohr at teraport dot de
 Summary:  Error message executing php - oci.dll was not found
-Status:   Assigned
+Status:   Closed
 Type: Bug
 Package:  Windows Installer
 Operating System: Windows Server 2006 64bit
 PHP Version:  5.3.1
 Assigned To:  jmertic

 New Comment:

Verified that pdo_oci extension is not included by default in PHP 5.3.2
installer


Previous Comments:

[2010-01-25 08:52:37] paj...@php.net

John, can you disable oci by default please?



Alternatively we could add a dep. I'm not sure if oracle has a MSI for
the instant client, so we could detect it.


[2010-01-15 12:21:05] paj...@php.net

Agreed, it should not even be installed by default.


[2010-01-15 12:15:34] andreas dot mohr at teraport dot de

As mentioned: my problem is actually solved. Nevertheless i consider
this to be a bug during installation.



If PDO extension for oracle is installed, the dependancy from oci.dll

should be taken care of or informed about during installation.

If installation is an update and if pdo for oracle is NOT previously

installed, do not install it (disable preset in installation  because
dependancy raises an error).


[2010-01-15 12:12:26] andreas dot mohr at teraport dot de

Description:

Pre-Installed php 5.2.11 running without error messages.

- Initially no oracle extensions were installed



After Updating to 5.3.1, running any php command in command window
produces the error message "The application has failed to start because
oci.dll was not found. Re-Installing the application might solve the
"...



Reinstalled using php-5.3.1-nts-Win32-VC9-x86.msi...

...with Oracle 10 extension. Did not fix the issue...

Result: error now occurs twice when running the php version check 

Reinstalled once more...

...with 11g Extension. Did not fix the issue...

Result: error occurs three times

- disabled all extensions containing "oci" in php.ini. Found additional
extension extension=php_pdo_oci.dll



In previous versions, when PDO extensions are installed no dependancy
issues occured when the database (or client) behind the extension was
not installed.

The necessity to install an oracle client with PHP 5.3.1 is not well
documented.



So the problem is actually solved.



If PDO extension for oracle is installed, the dependancy from oci.dll
should be taken care of or informed about during installation.

If installation is an update and if pdo for oracle is NOT previously
installed, do not install it.

 

Reproduce code:
---
In php.ini of a running PHP 5.2.11, only have pdo extensions for mysql
installed.



Update an installed PHP 5.2.11 to 5.3.1 (with or without oracle
extensions) using the windows installer and run
c:\your-path-to-php\php-cgi.exe -v in the command prompt. 



Note: pdo extension is installed (because pdo was previously
installed?). Unfolding the tree reveals that the feature is fully
installed, including PDO for Oracle 10g client and above. There is no
awareness of this. 





Expected result:

Execute php after Update without an error message. 



Actual result:
--
The version info is correctly displayed - following an error message.
"The application has failed to start because oci.dll was not found.
Re-installing the application might solve the problem."






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=50765&edit=1

Bug #49570 [Com]: $_POST is empty with large file uploads

[erikvernsmith at yahoo dot com]

Edit report at http://bugs.php.net/bug.php?id=49570&edit=1

 ID:   49570
 Comment by:   erikvernsmith at yahoo dot com
 Reported by:  erikvernsmith at yahoo dot com
 Summary:  $_POST is empty with large file uploads
 Status:   No Feedback
 Type: Bug
 Package:  Filesystem function related
 Operating System: Mac OS 10.6.1
 PHP Version:  5.3.0

 New Comment:

Check ALL of these settings in php.ini

file_uploads

upload_max_filesize

max_input_time

memory_limit

max_execution_time

post_max_size


Previous Comments:

[2009-12-07 13:12:03] erikvernsmith at yahoo dot com

Have you enabled error reporting? 

Yes.



Do you get any errors in the error log? 

I only get one error, Undefined index: mytitle in myfile.php on line 3



Could the script stop because the max execution time expires?

No, the max execution time is set to 60 seconds in php.ini



How long does it take for the script to stop?

The script is running on localhost and appears to be almost 

instantaneous.



Does the script works fine other than that $_POST and $_FILES are 

empty?

Yes



Further information:

I have now upgraded to Mac OS 10.6.2, Apache 2.2.14 and PHP 5.3.1 and 

I am still experiencing this problem.


[2009-10-01 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".


[2009-09-23 15:56:51] sjo...@php.net

Thank you for your bug report.



To properly diagnose the problem, we need some more information from
you. Have you enabled error reporting? Do you get any errors in the
error log? Could the script stop because the max execution time expires?
How long does it take for the script to stop? Does the script works fine
other than that $_POST and $_FILES are empty?


[2009-09-16 13:48:18] erikvernsmith at yahoo dot com

Description:

I set upload_max_filesize in php.ini to 64M



I'm using a simple html form to post/upload a file to a simple php
script. If I upload files smaller than 8MB everything works fine. If I
upload a file larger than 8MB, print_r( $_POST ) and print_r( $_FILES )
are empty.



Important note: 8MB is not a magic number. On my localhost 10MB files do
upload, but 50MB files do not. 8MB files will not work on my remote
website, but 7MB files will work.





Reproduce code:
---
complete HTML file:







Choose a file to upload: 









complete PHP file:



';

echo $_POST['mytitle'];

echo '';

print_r( $_POST );

echo '';

print_r( $_FILES );

?>



Expected result:

I expect the $_POST and $_FILES arrays to have contents, like this:



testing123



junkjunk and more junk



Array ( [mytitle] => junkjunk and more junk )



Array ( [uploadedfile] => Array ( [name] => junk.bin [type] =>
application/macbinary [tmp_name] => /private/var/tmp/php0tupN2 [error]
=> 0 [size] => 10485760 ) ) 

Actual result:
--
The $_POST and $_FILES arrays are empty, like this:



testing123







Array ( )



Array ( ) 






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=49570&edit=1

Bug #48615 [Asn->Csd]: Will not install. Exits with error 2711

[jmertic]

Edit report at http://bugs.php.net/bug.php?id=48615&edit=1

 ID:   48615
 Updated by:   jmer...@php.net
 Reported by:  codeblock at eighthbit dot net
 Summary:  Will not install. Exits with error 2711
-Status:   Assigned
+Status:   Closed
 Type: Bug
 Package:  Windows Installer
 Operating System: Windows XP
 PHP Version:  6CVS-2009-06-20 (snap)
 Assigned To:  jmertic

 New Comment:

Closing since 6.0 as we knew it is gone and the snaps are down.


Previous Comments:

[2010-01-01 15:47:54] uwe_markus at hotmail dot com

=== Verbose logging started: 01.01.2010  16:42:56  Build type: SHIP 

UNICODE 5.00.7600.00  Calling process: C:\Windows\system32\msiexec.exe 

===

MSI (c) (0C:44) [16:42:56:672]: Font created.  Charset: Req=0, Ret=0, 

Font: Req=MS Shell Dlg, Ret=MS Shell Dlg



MSI (c) (0C:44) [16:42:56:672]: Font created.  Charset: Req=0, Ret=0, 

Font: Req=MS Shell Dlg, Ret=MS Shell Dlg



MSI (c) (0C:A0) [16:42:56:703]: Resetting cached policy values

MSI (c) (0C:A0) [16:42:56:703]: Machine policy value 'Debug' is 0

MSI (c) (0C:A0) [16:42:56:703]: *** RunEngine:

   *** Product: php-5.3-nts-win32-VC9-x64-latest.msi

   *** Action: 

   *** CommandLine: **

MSI (c) (0C:A0) [16:42:56:703]: Machine policy value 

'DisableUserInstalls' is 0

MSI (c) (0C:A0) [16:42:56:719]: Note: 1: 1402 2: 

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\E

xplorer 3: 2 

MSI (c) (0C:A0) [16:42:56:719]: SOFTWARE RESTRICTION POLICY: Verifying 

package --> 'C:\Users\Administrator\Desktop\PHP\php-5.3-nts-win32-VC9-

x64-latest.msi' against software restriction policy

MSI (c) (0C:A0) [16:42:56:719]: Note: 1: 2262 2: DigitalSignature 3: -

2147287038 

MSI (c) (0C:A0) [16:42:56:719]: SOFTWARE RESTRICTION POLICY: 

C:\Users\Administrator\Desktop\PHP\php-5.3-nts-win32-VC9-x64-

latest.msi is not digitally signed

MSI (c) (0C:A0) [16:42:56:719]: SOFTWARE RESTRICTION POLICY: 

C:\Users\Administrator\Desktop\PHP\php-5.3-nts-win32-VC9-x64-

latest.msi is permitted to run at the 'unrestricted' authorization 

level.

MSI (c) (0C:A0) [16:42:56:719]: Cloaking enabled.

MSI (c) (0C:A0) [16:42:56:719]: Attempting to enable all disabled 

privileges before calling Install on Server

MSI (c) (0C:A0) [16:42:56:734]: End dialog not enabled

MSI (c) (0C:A0) [16:42:56:734]: Original package ==> 

C:\Users\Administrator\Desktop\PHP\php-5.3-nts-win32-VC9-x64-

latest.msi

MSI (c) (0C:A0) [16:42:56:734]: Package we're running from ==> 

C:\Users\Administrator\Desktop\PHP\php-5.3-nts-win32-VC9-x64-

latest.msi

MSI (c) (0C:A0) [16:42:56:734]: APPCOMPAT: Compatibility mode property 

overrides found.

MSI (c) (0C:A0) [16:42:56:734]: APPCOMPAT: looking for appcompat 

database entry with ProductCode '{C9E68706-081D-4302-8EED-

309849864DA7}'.

MSI (c) (0C:A0) [16:42:56:734]: APPCOMPAT: no matching ProductCode 

found in database.

MSI (c) (0C:A0) [16:42:56:750]: MSCOREE not loaded loading copy from 

system32

MSI (c) (0C:A0) [16:42:56:750]: Machine policy value 

'TransformsSecure' is 1

MSI (c) (0C:A0) [16:42:56:750]: Machine policy value 'DisablePatch' is 

0

MSI (c) (0C:A0) [16:42:56:750]: Machine policy value 

'AllowLockdownPatch' is 0

MSI (c) (0C:A0) [16:42:56:750]: Machine policy value 

'DisableLUAPatching' is 0

MSI (c) (0C:A0) [16:42:56:750]: Machine policy value 

'DisableFlyWeightPatching' is 0

MSI (c) (0C:A0) [16:42:56:750]: APPCOMPAT: looking for appcompat 

database entry with ProductCode '{C9E68706-081D-4302-8EED-

309849864DA7}'.

MSI (c) (0C:A0) [16:42:56:750]: APPCOMPAT: no matching ProductCode 

found in database.

MSI (c) (0C:A0) [16:42:56:750]: Transforms are not secure.

MSI (c) (0C:A0) [16:42:56:750]: PROPERTY CHANGE: Adding 

MsiLogFileLocation property. Its value is 

'C:\Users\Administrator\Desktop\PHP\error.log'.

MSI (c) (0C:A0) [16:42:56:750]: Command Line: 

CURRENTDIRECTORY=C:\Users\Administrator\Desktop\PHP CLIENTUILEVEL=0 

CLIENTPROCESSID=2572 

MSI (c) (0C:A0) [16:42:56:750]: PROPERTY CHANGE: Adding PackageCode 

property. Its value is '{DC36AD73-169E-41EC-8C45-016D75DA70E4}'.

MSI (c) (0C:A0) [16:42:56:750]: Product Code passed to 

Engine.Initialize:   ''

MSI (c) (0C:A0) [16:42:56:750]: Product Code from property table 

before transforms: '{C9E68706-081D-4302-8EED-309849864DA7}'

MSI (c) (0C:A0) [16:42:56:750]: Product Code from property table after 

transforms:  '{C9E68706-081D-4302-8EED-309849864DA7}'

MSI (c) (0C:A0) [16:42:56:750]: Product not registered: beginning 

first-time install

MSI (c) (0C:A0) [16:42:56:750]: PROPERTY CHANGE: Adding ProductState 

property. Its value is '-1'.

MSI (c) (0C:A0) [16:42:56:750]: Entering 

CMsiConfigurationManager::SetLastUsedSource.

MSI (c) (0C:A0) [16:42:56:750]: User policy value 'SearchOrder' is 

'nmu'

MSI (c) (0C:A0) [16:42:56:750]: Ad

Bug #50455 [Opn->Asn]: After installing PHP, I see "php fatal error related to include_path"

[jmertic]

Edit report at http://bugs.php.net/bug.php?id=50455&edit=1

 ID:   50455
 Updated by:   jmer...@php.net
 Reported by:  nevasha at rocketmail dot com
 Summary:  After installing PHP, I see "php fatal error related
   to include_path"
-Status:   Open
+Status:   Assigned
 Type: Bug
 Package:  Windows Installer
 Operating System: Windows XP Professional sp 2
 PHP Version:  5.3.1
-Assigned To:  
+Assigned To:  jmertic



Previous Comments:

[2009-12-11 23:53:36] nevasha at rocketmail dot com

I also notice with the same installation if I set to include one of the


dynamic extensions with the following configuration:



extension_dir="D:\Tools\PHP\ext"

extension=php_bz2.dll



I see the following fatal error any time I invoked php-win.exe or 

php.exe:



CLI has encountered a problem and needs to close.  We are sorry for the


inconvenience.



It doesn't matter which dynamic extension I include this error occurs 

every time. Yes the files that are specified in the dynamic extension do


exist.


[2009-12-11 22:48:37] nevasha at rocketmail dot com

Description:

I installed PHP 5.3.1 using windows installer and following the 

installation guide. After running the modified go-pear.bat (the 

modification needed was: %PHP_BIN% -d phar.require_hash=0 PEAR\go-

pear.phar) I see that php.ini has been correctly updated with:



;* Added by go-pear

include_path=".;D:\Tools\PHP\pear"

;*



However when I run php-win.exe I see the following error message in 

the log file:



PHP Fatal error:  Unknown: Failed opening required '-' 

(include_path='.;D:\Tools\PHP\pear') in Unknown on line 0





Actual result:
--
However when I run php-win.exe I see the following error message in the


log file:



PHP Fatal error:  Unknown: Failed opening required '-' 

(include_path='.;D:\Tools\PHP\pear') in Unknown on line 0








-- 
Edit this bug report at http://bugs.php.net/bug.php?id=50455&edit=1

Bug #50527 [Opn->Asn]: In the setup code file use of \\localhost\Admin$ creates problem

[jmertic]

Edit report at http://bugs.php.net/bug.php?id=50527&edit=1

 ID:   50527
 Updated by:   jmer...@php.net
 Reported by:  don dot raman at microsoft dot com
 Summary:  In the setup code file use of \\localhost\Admin$
   creates problem
-Status:   Open
+Status:   Assigned
 Type: Bug
 Package:  Windows Installer
 Operating System: Windows
 PHP Version:  5.2.12
-Assigned To:  
+Assigned To:  jmertic



Previous Comments:

[2009-12-18 23:33:39] don dot raman at microsoft dot com

Description:

The PHP MSI while configuring IIS FastCGI on 64 bit machine uses
\\localhost\Admin$ to overcome SYSWOW64 redirection. I have found
machine where \\localhost\Admin$ is not reachable. This fails running of
fcgiext.js script which means the FastCGI script mapping is missing on
those machine. This leads to a bad user experience.



Another thing to note that this is happening with PHP5.3.1 MSI too. So
this should be fixed at both the place.

Reproduce code:
---
There is no code to reproduce this error as the bug is in Windows MSI.

Expected result:

MSI while selected to configure IIS FastCGI should do the script mapping
and add index.php to default document list.

Actual result:
--
Script mapping as well as index.php in default document missing.






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=50527&edit=1

Bug #50583 [Opn->Asn]: PHP Installer needs to support side by side installlation

[jmertic]

Edit report at http://bugs.php.net/bug.php?id=50583&edit=1

 ID:   50583
 Updated by:   jmer...@php.net
 Reported by:  ksingla at microsoft dot com
 Summary:  PHP Installer needs to support side by side
   installlation
-Status:   Open
+Status:   Assigned
 Type: Bug
 Package:  Windows Installer
 Operating System: Windows
 PHP Version:  5.3.1
-Assigned To:  
+Assigned To:  jmertic

 New Comment:

Currently assessing whether we can do this across all SAPIs or not.


Previous Comments:

[2010-01-21 21:21:15] ruslany at microsoft dot com

In addition to that it would be nice if PHP installer allowed user to
choose whether to upgrade an existing PHP installation or install a new
version side by side. For example, on the very first page of the
installer there can be options presented:



1. Upgrade existing installation

2. Install side-by-side and make this a default version

3. Install side-by-side but keep existing version as a default.



In case of installing on IIS that would mean:

In #1 the installer will upgrade the PHP installation as it does today.




In #2 the installer will install binaries into a new folder and then
configure FastCGI handler mapping on a server level and make it the top
in the handler mapping list so that it is used by all sites.



In #3 the installer will install binaries into a new folder, configure
FastCGI handler mapping, but will not re-order the existing FastCGI
handler mapping so that previosly installed PHP vesion is still used.


[2009-12-26 23:28:17] ksingla at microsoft dot com

Description:

In order to support side-by-side installation of PHP 5.2 and 5.3 by 
Microsoft Web Platform Installer, PHP installer needs to support side by
side setup. To get to a version specific installation, I think following
changes will be required



a. Currently, PHP is installed to %PROGRAMFILES(X86)%\PHP or
%PROGRAMFILES%\PHP. This should change to
%PROGRAMFILES(X86)%\PHP\ or %PROGRAMFILES%\PHP\



b. Currently PHP sets the following registry keys: 

   i.   HKLM\SOFTWARE\Wow6432Node\PHP on 64-bit systems.

   ii.  HKLM\SOFTWARE\PHP on 32-bit systemsc.

Change the registry keys to: 

   i.   HKLM\SOFTWARE\Wow6432Node\PHP\ on 64-bit systems.

   ii.  HKLM\SOFTWARE\PHP on 32-bit systems\d. Set an
environment variable called PHPLOC with the path to the latest installed
PHP 



c. When IIS-FastCGI install is selected, installer should let users add
the PHP handler at site or application level as well so that a
particular PHP version can be used for that site or application.
Currently the handler is always added at the server level.







-- 
Edit this bug report at http://bugs.php.net/bug.php?id=50583&edit=1

Bug #50592 [Opn->Csd]: Windows 2003 X64 VC9 INSTALLER MSI not working

[jmertic]

Edit report at http://bugs.php.net/bug.php?id=50592&edit=1

 ID:   50592
 Updated by:   jmer...@php.net
 Reported by:  giz02 at msn dot com
 Summary:  Windows 2003 X64 VC9 INSTALLER MSI not working
-Status:   Open
+Status:   Closed
 Type: Bug
 Package:  Windows Installer
 Operating System: Windows 2003 x64
 PHP Version:  5.3SVN-2009-12-28 (snap)
-Assigned To:  
+Assigned To:  jmertic

 New Comment:

Problem with snaps build system, which is currently turned off.


Previous Comments:

[2009-12-28 14:38:01] giz02 at msn dot com

Description:

Windows 2003 X64 "php-5.3-win32-VC9-x64-latest.msi" is only 852KB.
Installer fails during installation at step n ("   ")

The 'installer' versions for the Windows x86 packages are very close in
size to the 'non-installer/zip' versions.  I am not sure why this one is
so small - I'm suspicious that perhaps the php binaries were ommitted
from the build.

Reproduce code:
---
Not applicable

Expected result:

Not applicable

Actual result:
--
Not applicable






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=50592&edit=1

Bug #36073 [Com]: Source-compiled MySQL on x86_64 causes PHP configure failure

[michael at michaelsnet dot us]

Edit report at http://bugs.php.net/bug.php?id=36073&edit=1

 ID:   36073
 Comment by:   michael at michaelsnet dot us
 Reported by:  chris at spawnordie dot com
 Summary:  Source-compiled MySQL on x86_64 causes PHP configure
   failure
 Status:   Wont fix
 Type: Bug
 Package:  Compile Failure
 Operating System: Linux/Any
 PHP Version:  5.1.2

 New Comment:

IMHO this is a documentation bug.  Consider adding a README.64bit file
containing this information and other relevant information.


Previous Comments:

[2006-01-18 23:53:50] sni...@php.net

Works fine for me.

Hint: Don't try building Mysql yourself if you don't know how to do it
properly. Use the binary packages provided by MySQL.

And last but not least: report this to MySQL. It's not our fault if they
do things wrong.


[2006-01-18 22:14:10] chris at spawnordie dot com

Description:

Please accept my apologies if this is already reported - I searched and
didn't find it.



When configuring PHP for x86_64, it is necessary to use:

--with-libdir=lib64



When you compile MySQL from source, it does not place its files in
lib64, but rather lib.



MySQL was configured using:

--prefix=/usr/local/mysql



Configuring PHP using:

--with-mysql=/usr/local/mysql

fails with this:

checking for MySQL support... yes

checking for specified location of the MySQL UNIX socket... no

checking for MySQL UNIX socket location... no

configure: error: Cannot find libmysqlclient under /usr/local/mysql.

Note that the MySQL client library is not bundled anymore!



This fixes the problem:

cd /usr/local/mysql

ln -s lib lib64



When PHP is configured using --with-mysql= and
--with-libdir=, it should search / and then
/lib

Reproduce code:
---
./configure --with-mysql= when MySQL is compiled from
source code

Expected result:

successful configure

Actual result:
--
configure fails with:

checking for MySQL support... yes

checking for specified location of the MySQL UNIX socket... no

checking for MySQL UNIX socket location... no

configure: error: Cannot find libmysqlclient under /usr/local/mysql.

Note that the MySQL client library is not bundled anymore!








-- 
Edit this bug report at http://bugs.php.net/bug.php?id=36073&edit=1

Bug #51382 [Com]: session_start() blocks execution

[abca_b_cabcom at hotmail dot com]

Edit report at http://bugs.php.net/bug.php?id=51382&edit=1

 ID:   51382
 Comment by:   abca_b_cabcom at hotmail dot com
 Reported by:  info at lategoodbye dot de
 Summary:  session_start() blocks execution
 Status:   Open
 Type: Bug
 Package:  Session related
 Operating System: Linux 2.4.35.4 mips
 PHP Version:  5.3.2

 New Comment:

Maybe you can post your backtrace result here first, i just guess it is
a compiler error, cause php_combined_lcg function should have no error.


Previous Comments:

[2010-03-25 15:11:53] info at lategoodbye dot de

May be i expressed myself bad about the option session.gc_divisor.
Setting the option to 10 is nearly like disabling garbage
collection. The chance to reproduce the problem is very, very low but
possible.



How can i findout that it's a compile error?



Nevertheless i will make the backtrace.


[2010-03-25 08:47:54] abca_b_cabcom at hotmail dot com

>From you description I traced back to the line 1475 in
./etc/session/session.c,

it is the only line which will be affect by the php.ini variable
session.gc_divisor you describe.



The line is show below:

nrand = (int) ((float) PS(gc_divisor) * php_combined_lcg(TSRMLS_C));



So, I think it may be a compiling error.


[2010-03-24 19:04:24] ras...@php.net

One way to figure that out is to attach gdb to a hanging fcgi process
and get a 

backtrace (bt) from gdb which should show where it is stuck.


[2010-03-24 18:44:22] info at lategoodbye dot de

Description:

Hi, i'm running PHP 5.3.2 via FastCGI with lighttpd 1.4.25 and uclibc
0.9.29. I experienced that after a period of time, all session driven
pages hang and deliver no content to the client. But all static content
like images are accessible. Below i appended a little script, how the
problem can be reproduced.



Here are the options from the php.ini:



session.save_handler = files

session.save_path = "/tmp"

session.gc_probability = 1

session.gc_divisor = 100

session.gc_maxlifetime = 1440



Here is the configure line:



'./configure' '--target=mipsel-linux' '--host=mipsel-linux'
'--build=i486-linux-gnu' '--program-prefix=' '--program-suffix='
'--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin'
'--sbindir=/usr/sbin' '--libexecdir=/usr/lib' '--sysconfdir=/etc'
'--datadir=/usr/share' '--localstatedir=/var' '--mandir=/usr/man'
'--infodir=/usr/info' '--disable-nls' '--enable-shared'
'--disable-static' '--disable-rpath' '--disable-debug' '--without-pear'
'--with-config-file-path=/etc' '--enable-magic-quotes'
'--disable-short-tags' '--without-gettext' '--disable-simplexml'
'--with-zlib=/home/10_openwrt/staging_dir/mipsel/usr'
'--with-zlib-dir=/home/10_openwrt/staging_dir/mipsel/usr'
'--with-pcre-regex=/home/10_openwrt/staging_dir/mipsel/usr'
'--disable-phar' '--enable-ctype=shared' '--without-curl'
'--disable-fileinfo' '--disable-dom' '--disable-exif' '--disable-ftp'
'--without-gd' '--without-gmp' '--disable-hash' '--without-iconv'
'--enable-json=shared' '--without-ldap' '--disable-mbstring'
'--without-mcrypt' '--without-mysql' '--without-openssl'
'--enable-pdo=shared' '--without-pdo-mysql' '--without-pdo-pgsql'
'--with-pdo-sqlite=shared,/home/10_openwrt/staging_dir/mipsel/usr'
'--without-pgsql' '--enable-session=shared' '--disable-soap'
'--enable-sockets=shared' '--without-sqlite'
'--with-sqlite3=shared,/home/10_openwrt/staging_dir/mipsel/usr'
'--disable-tokenizer'
'--enable-xml=shared,/home/10_openwrt/staging_dir/mipsel/usr'
'--with-libexpat-dir=/home/10_openwrt/staging_dir/mipsel/usr'
'--disable-xmlreader' '--disable-xmlwriter' '--disable-apc'
'--disable-filter' '--disable-libxml' '--enable-sysvsem'
'--enable-sysvshm' '--enable-sysvmsg' '--enable-pcntl' '--disable-cli'
'--enable-cgi'



The filesystem behind /tmp is tmpfs.



After that i played a little bit with option session.gc_divisor. If i
set the option to 2, then the problem happend immediately. But if i set
the option to 10, the problem is not reproducable.



Is this a dead lock caused by the session garbage collector?

Test script:
---


Content

Expected result:

PHP delivers "Content" to the browser.

Actual result:
--
The browser didn't get "Content" and wait for a response.






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51382&edit=1

Req #51391 [Opn->Bgs]: Static methods called as self::fun() always resolve to class of its declaration

[aharvey]

Edit report at http://bugs.php.net/bug.php?id=51391&edit=1

 ID:   51391
 Updated by:   ahar...@php.net
 Reported by:  byoung at bigbluehat dot com
 Summary:  Static methods called as self::fun() always resolve to
   class of its declaration
-Status:   Open
+Status:   Bogus
 Type: Feature/Change Request
 Package:  Class/Object related
 Operating System: Mac OS X
 PHP Version:  5.3.2

 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

You need to use Late Static Binding: see the manual at
http://php.net/lsb for more details.


Previous Comments:

[2010-03-25 16:15:33] byoung at bigbluehat dot com

Description:

Static methods called using self::fun() resolve the parent class's
method even called from the child class. Sample code provided here (and
below):

http://www.php.net/manual/en/language.oop5.paamayim-nekudotayim.php#49541

Test script:
---


Expected result:

Expected behavior is to output "doing something with subclass."

Actual result:
--
Output is currently (in PHP 5.3.2) "doing something with superclass"!






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51391&edit=1

[PHP-BUG] Req #51391 [NEW]: Static methods called as self::fun() always resolve to class of its declaration

[byoung at bigbluehat dot com]

From: 
Operating system: Mac OS X
PHP version:  5.3.2
Package:  Class/Object related
Bug Type: Feature/Change Request
Bug description:Static methods called as self::fun() always resolve to class of 
its declaration

Description:

Static methods called using self::fun() resolve the parent class's method
even called from the child class. Sample code provided here (and below):

http://www.php.net/manual/en/language.oop5.paamayim-nekudotayim.php#49541

Test script:
---


Expected result:

Expected behavior is to output "doing something with subclass."

Actual result:
--
Output is currently (in PHP 5.3.2) "doing something with superclass"!

-- 
Edit bug report at http://bugs.php.net/bug.php?id=51391&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51391&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51391&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51391&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51391&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=51391&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51391&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=51391&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=51391&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=51391&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=51391&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=51391&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=51391&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=51391&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51391&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=51391&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51391&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=51391&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=51391&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=51391&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=51391&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=51391&r=mysqlcfg

Bug #49323 [Com]: json_decode escaped character weirdness

[dmitry dot dulepov at gmail dot com]

Edit report at http://bugs.php.net/bug.php?id=49323&edit=1

 ID:   49323
 Comment by:   dmitry dot dulepov at gmail dot com
 Reported by:  paul dot wieland at port80ware dot com
 Summary:  json_decode escaped character weirdness
 Status:   Bogus
 Type: Bug
 Package:  JSON related
 Operating System: Linux / OSX
 PHP Version:  5.3.0

 New Comment:

I appologize. The problem was elsewhere. Sorry for the trouble.


Previous Comments:

[2010-03-25 13:58:12] paul dot wieland at port80ware dot com

It definitely works just fine in FireFox. The entire project I was
working on 

(which prompted this bug post) was tested with FF and everything worked
fine.


[2010-03-25 13:51:23] ras...@php.net

No, I wouldn't suggest you do that.  It works perfectly fine in Firefox.
 Check 

your own code.  I wrote a quick check to make sure it works in FF. 
Point your 

browser at:



http://progphp.com/test.html



Then do a view-source to see what I am doing.


[2010-03-25 13:35:00] dmitry dot dulepov at gmail dot com

Ok, I see the point... However FireFox does not like that escaping. So
any AJAX 

applications that use this generated JSON do not work in FireFox. It is
enough to 

have \/ in JSON to cause JavaScript error in FireFox. Should I report
the bug to 

FireFox than?


[2010-03-25 13:22:46] ras...@php.net

dmitry, I don't understand your last comment.  Of course / is escaped in
the 

json encoded string.  According to the spec it is supposed to be.  The
important 

part is that when you json_decode() it it comes back without the \ which
it 

does:



> php -v

PHP 5.3.3-dev (cli) (built: Feb 10 2010 10:53:36) 



> php -a

php > $enc = json_encode(array('test' => 'hello/world'));

php > echo $enc;

{"test":"hello\/world"}

php > var_dump(json_decode($enc));

object(stdClass)#1 (1) {

  ["test"]=>

  string(11) "hello/world"

}


[2010-03-25 12:49:26] dmitry dot dulepov at gmail dot com

No, it is definitely NOT fixed.



php -v says:

=

PHP 5.3.1 (cli) (built: Feb 15 2010 17:30:23) 

Copyright (c) 1997-2009 The PHP Group

Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies

=



Test file:

=

 'hello/world')) . chr(10);

=



Result:

=

{"test":"hello\/world"}

=




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=49323


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=49323&edit=1

Req #51390 [Asn->Bgs]: need PHP APC binaries for 5.2.13

[pajoye]

Edit report at http://bugs.php.net/bug.php?id=51390&edit=1

 ID:   51390
 Updated by:   paj...@php.net
 Reported by:  t_wiedmann at t-online dot de
 Summary:  need PHP APC binaries for 5.2.13
-Status:   Assigned
+Status:   Bogus
 Type: Feature/Change Request
 Package:  *Extensibility Functions
 Operating System: Windows XP
 PHP Version:  5.2.13
 Assigned To:  pajoye

 New Comment:

There is no bug (and certainly not in php :). And yes, the 5.2 bins work
for anything after 5.2.6.


Previous Comments:

[2010-03-25 15:25:43] johan...@php.net

the 5.2.9 build should in theory work, pierre can you update anyways?


[2010-03-25 15:09:28] t_wiedmann at t-online dot de

Description:

Hi,



I need php_apc.dll binaries for PHP 5.2.13. On
http://downloads.php.net/pierre/ the lastest version is 5.2.9.



Many thanks!



Thomas

Expected result:

php_apc.dll binaries for PHP 5.2.13







-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51390&edit=1

Req #51390 [Opn]: need PHP APC binaries for 5.2.13

[johannes]

Edit report at http://bugs.php.net/bug.php?id=51390&edit=1

 ID:   51390
 Updated by:   johan...@php.net
 Reported by:  t_wiedmann at t-online dot de
 Summary:  need PHP APC binaries for 5.2.13
 Status:   Open
 Type: Feature/Change Request
 Package:  *Extensibility Functions
 Operating System: Windows XP
 PHP Version:  5.2.13
-Assigned To:  
+Assigned To:  pajoye

 New Comment:

the 5.2.9 build should in theory work, pierre can you update anyways?


Previous Comments:

[2010-03-25 15:09:28] t_wiedmann at t-online dot de

Description:

Hi,



I need php_apc.dll binaries for PHP 5.2.13. On
http://downloads.php.net/pierre/ the lastest version is 5.2.9.



Many thanks!



Thomas

Expected result:

php_apc.dll binaries for PHP 5.2.13







-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51390&edit=1

Bug #51382 [Opn]: session_start() blocks execution

[info at lategoodbye dot de]

Edit report at http://bugs.php.net/bug.php?id=51382&edit=1

 ID:   51382
 User updated by:  info at lategoodbye dot de
 Reported by:  info at lategoodbye dot de
 Summary:  session_start() blocks execution
 Status:   Open
 Type: Bug
 Package:  Session related
 Operating System: Linux 2.4.35.4 mips
 PHP Version:  5.3.2

 New Comment:

May be i expressed myself bad about the option session.gc_divisor.
Setting the option to 10 is nearly like disabling garbage
collection. The chance to reproduce the problem is very, very low but
possible.



How can i findout that it's a compile error?



Nevertheless i will make the backtrace.


Previous Comments:

[2010-03-25 08:47:54] abca_b_cabcom at hotmail dot com

>From you description I traced back to the line 1475 in
./etc/session/session.c,

it is the only line which will be affect by the php.ini variable
session.gc_divisor you describe.



The line is show below:

nrand = (int) ((float) PS(gc_divisor) * php_combined_lcg(TSRMLS_C));



So, I think it may be a compiling error.


[2010-03-24 19:04:24] ras...@php.net

One way to figure that out is to attach gdb to a hanging fcgi process
and get a 

backtrace (bt) from gdb which should show where it is stuck.


[2010-03-24 18:44:22] info at lategoodbye dot de

Description:

Hi, i'm running PHP 5.3.2 via FastCGI with lighttpd 1.4.25 and uclibc
0.9.29. I experienced that after a period of time, all session driven
pages hang and deliver no content to the client. But all static content
like images are accessible. Below i appended a little script, how the
problem can be reproduced.



Here are the options from the php.ini:



session.save_handler = files

session.save_path = "/tmp"

session.gc_probability = 1

session.gc_divisor = 100

session.gc_maxlifetime = 1440



Here is the configure line:



'./configure' '--target=mipsel-linux' '--host=mipsel-linux'
'--build=i486-linux-gnu' '--program-prefix=' '--program-suffix='
'--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin'
'--sbindir=/usr/sbin' '--libexecdir=/usr/lib' '--sysconfdir=/etc'
'--datadir=/usr/share' '--localstatedir=/var' '--mandir=/usr/man'
'--infodir=/usr/info' '--disable-nls' '--enable-shared'
'--disable-static' '--disable-rpath' '--disable-debug' '--without-pear'
'--with-config-file-path=/etc' '--enable-magic-quotes'
'--disable-short-tags' '--without-gettext' '--disable-simplexml'
'--with-zlib=/home/10_openwrt/staging_dir/mipsel/usr'
'--with-zlib-dir=/home/10_openwrt/staging_dir/mipsel/usr'
'--with-pcre-regex=/home/10_openwrt/staging_dir/mipsel/usr'
'--disable-phar' '--enable-ctype=shared' '--without-curl'
'--disable-fileinfo' '--disable-dom' '--disable-exif' '--disable-ftp'
'--without-gd' '--without-gmp' '--disable-hash' '--without-iconv'
'--enable-json=shared' '--without-ldap' '--disable-mbstring'
'--without-mcrypt' '--without-mysql' '--without-openssl'
'--enable-pdo=shared' '--without-pdo-mysql' '--without-pdo-pgsql'
'--with-pdo-sqlite=shared,/home/10_openwrt/staging_dir/mipsel/usr'
'--without-pgsql' '--enable-session=shared' '--disable-soap'
'--enable-sockets=shared' '--without-sqlite'
'--with-sqlite3=shared,/home/10_openwrt/staging_dir/mipsel/usr'
'--disable-tokenizer'
'--enable-xml=shared,/home/10_openwrt/staging_dir/mipsel/usr'
'--with-libexpat-dir=/home/10_openwrt/staging_dir/mipsel/usr'
'--disable-xmlreader' '--disable-xmlwriter' '--disable-apc'
'--disable-filter' '--disable-libxml' '--enable-sysvsem'
'--enable-sysvshm' '--enable-sysvmsg' '--enable-pcntl' '--disable-cli'
'--enable-cgi'



The filesystem behind /tmp is tmpfs.



After that i played a little bit with option session.gc_divisor. If i
set the option to 2, then the problem happend immediately. But if i set
the option to 10, the problem is not reproducable.



Is this a dead lock caused by the session garbage collector?

Test script:
---


Content

Expected result:

PHP delivers "Content" to the browser.

Actual result:
--
The browser didn't get "Content" and wait for a response.






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51382&edit=1

[PHP-BUG] Req #51390 [NEW]: need PHP APC binaries for 5.2.13

[t_wiedmann at t-online dot de]

From: 
Operating system: Windows XP
PHP version:  5.2.13
Package:  *Extensibility Functions
Bug Type: Feature/Change Request
Bug description:need PHP APC binaries for 5.2.13

Description:

Hi,



I need php_apc.dll binaries for PHP 5.2.13. On
http://downloads.php.net/pierre/ the lastest version is 5.2.9.



Many thanks!



Thomas

Expected result:

php_apc.dll binaries for PHP 5.2.13


-- 
Edit bug report at http://bugs.php.net/bug.php?id=51390&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51390&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51390&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51390&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51390&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=51390&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51390&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=51390&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=51390&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=51390&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=51390&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=51390&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=51390&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=51390&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51390&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=51390&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51390&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=51390&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=51390&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=51390&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=51390&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=51390&r=mysqlcfg

Bug #27051 [Fbk->Tbd]: Impersonation with FastCGI does not EXEC process as impersonated user

[pajoye]

Edit report at http://bugs.php.net/bug.php?id=27051&edit=1

 ID:   27051
 Updated by:   paj...@php.net
 Reported by:  ghoffer at globalscape dot com
 Summary:  Impersonation with FastCGI does not EXEC process as
   impersonated user
-Status:   Feedback
+Status:   To be documented
 Type: Bug
 Package:  CGI related
 Operating System: Windows
 PHP Version:  5.3
-Assigned To:  pajoye
+Assigned To:  

 New Comment:

Ah nice, so another useful entry to add to the documentation, thanks for
investigating it and report it back! :)


Previous Comments:

[2010-03-25 13:08:22] heer2351 at zonnet dot nl

Located the problem and have been able to fix it.



I am using a special user for my Application Pool (say AppPoolUser), so
PHP runs as this user. The new exec function uses CreateProcessAsUser()
with impersonation. This means that the AppPoolUser must have the right
to change the process level token.



You can assign this right to the user in the "Local Security Settings"
-> User Rights Assignment.



I have granted my AppPoolUser the "Replace a process level token"
setting -> fork error has gone.



Thought this might be useful information, so access is required to
cmd.exe but in addition the "Replace a process level token" setting.


[2010-03-25 00:45:36] paj...@php.net

I will repeat a last time :) It does work here using IIS6 and the exact
same windows version of FastCGI. The other users with issues with that
have solved the problem as well using latest 5.3 and the right
configuration.



There are differences between 5.2 and 5.3, a lot. One of them is a
working impersonation (which is not only about exec).


[2010-03-25 00:40:55] heer2351 at zonnet dot nl

Thanks for your help. I think there are still more people with the same
problem. I will try to find a solution and will post here if I find
one.

For now I stick with 5.2.13



I am not convinced it is a config problem. Will dig into SVN and find
what the difference is between the two versions.


[2010-03-25 00:30:20] paj...@php.net

I don't know either and hard to say why it does not work for you but for
us (same config).



I feel like you actually configure it wrong. impersonation in 5.2 was
not fully working and was not doing the right thing (not only for
exec&co).



I can't help further without more details about how you configure the
impersonation or having a remote access to debug.


[2010-03-25 00:17:50] heer2351 at zonnet dot nl

Changed to your suggestion with \\, same error.



Changed to 5.2.13 ran my version and your version both echo the correct
username.




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=27051


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=27051&edit=1

Bug #49323 [Com]: json_decode escaped character weirdness

[paul dot wieland at port80ware dot com]

Edit report at http://bugs.php.net/bug.php?id=49323&edit=1

 ID:   49323
 Comment by:   paul dot wieland at port80ware dot com
 Reported by:  paul dot wieland at port80ware dot com
 Summary:  json_decode escaped character weirdness
 Status:   Bogus
 Type: Bug
 Package:  JSON related
 Operating System: Linux / OSX
 PHP Version:  5.3.0

 New Comment:

It definitely works just fine in FireFox. The entire project I was
working on 

(which prompted this bug post) was tested with FF and everything worked
fine.


Previous Comments:

[2010-03-25 13:51:23] ras...@php.net

No, I wouldn't suggest you do that.  It works perfectly fine in Firefox.
 Check 

your own code.  I wrote a quick check to make sure it works in FF. 
Point your 

browser at:



http://progphp.com/test.html



Then do a view-source to see what I am doing.


[2010-03-25 13:35:00] dmitry dot dulepov at gmail dot com

Ok, I see the point... However FireFox does not like that escaping. So
any AJAX 

applications that use this generated JSON do not work in FireFox. It is
enough to 

have \/ in JSON to cause JavaScript error in FireFox. Should I report
the bug to 

FireFox than?


[2010-03-25 13:22:46] ras...@php.net

dmitry, I don't understand your last comment.  Of course / is escaped in
the 

json encoded string.  According to the spec it is supposed to be.  The
important 

part is that when you json_decode() it it comes back without the \ which
it 

does:



> php -v

PHP 5.3.3-dev (cli) (built: Feb 10 2010 10:53:36) 



> php -a

php > $enc = json_encode(array('test' => 'hello/world'));

php > echo $enc;

{"test":"hello\/world"}

php > var_dump(json_decode($enc));

object(stdClass)#1 (1) {

  ["test"]=>

  string(11) "hello/world"

}


[2010-03-25 12:49:26] dmitry dot dulepov at gmail dot com

No, it is definitely NOT fixed.



php -v says:

=

PHP 5.3.1 (cli) (built: Feb 15 2010 17:30:23) 

Copyright (c) 1997-2009 The PHP Group

Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies

=



Test file:

=

 'hello/world')) . chr(10);

=



Result:

=

{"test":"hello\/world"}

=


[2009-08-22 10:11:12] scott...@php.net

Definitely fixed in 5.3



scott-mbp:~ scott$ php /tmp/test.php

string(10) "Black/Gray"

string(10) "Black/Gray"






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=49323


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=49323&edit=1

Bug #49323 [Bgs]: json_decode escaped character weirdness

[rasmus]

Edit report at http://bugs.php.net/bug.php?id=49323&edit=1

 ID:   49323
 Updated by:   ras...@php.net
 Reported by:  paul dot wieland at port80ware dot com
 Summary:  json_decode escaped character weirdness
 Status:   Bogus
 Type: Bug
 Package:  JSON related
 Operating System: Linux / OSX
 PHP Version:  5.3.0

 New Comment:

No, I wouldn't suggest you do that.  It works perfectly fine in Firefox.
 Check 

your own code.  I wrote a quick check to make sure it works in FF. 
Point your 

browser at:



http://progphp.com/test.html



Then do a view-source to see what I am doing.


Previous Comments:

[2010-03-25 13:35:00] dmitry dot dulepov at gmail dot com

Ok, I see the point... However FireFox does not like that escaping. So
any AJAX 

applications that use this generated JSON do not work in FireFox. It is
enough to 

have \/ in JSON to cause JavaScript error in FireFox. Should I report
the bug to 

FireFox than?


[2010-03-25 13:22:46] ras...@php.net

dmitry, I don't understand your last comment.  Of course / is escaped in
the 

json encoded string.  According to the spec it is supposed to be.  The
important 

part is that when you json_decode() it it comes back without the \ which
it 

does:



> php -v

PHP 5.3.3-dev (cli) (built: Feb 10 2010 10:53:36) 



> php -a

php > $enc = json_encode(array('test' => 'hello/world'));

php > echo $enc;

{"test":"hello\/world"}

php > var_dump(json_decode($enc));

object(stdClass)#1 (1) {

  ["test"]=>

  string(11) "hello/world"

}


[2010-03-25 12:49:26] dmitry dot dulepov at gmail dot com

No, it is definitely NOT fixed.



php -v says:

=

PHP 5.3.1 (cli) (built: Feb 15 2010 17:30:23) 

Copyright (c) 1997-2009 The PHP Group

Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies

=



Test file:

=

 'hello/world')) . chr(10);

=



Result:

=

{"test":"hello\/world"}

=


[2009-08-22 10:11:12] scott...@php.net

Definitely fixed in 5.3



scott-mbp:~ scott$ php /tmp/test.php

string(10) "Black/Gray"

string(10) "Black/Gray"




[2009-08-21 19:35:42] paul dot wieland at port80ware dot com

Very sorry, the virtualhost I was using was not configured to use 

version 5.3.0 - it is using 5.2.1 instead



So I am not sure if this is an old problem with 5.2.1 that has been 

solved, or it still exists with 5.3.0




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=49323


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=49323&edit=1

Bug #47314 [Com]: SoapClient leave tcp connections in "time_wait"

[bernd dot ott at k-m dot info]

Edit report at http://bugs.php.net/bug.php?id=47314&edit=1

 ID:   47314
 Comment by:   bernd dot ott at k-m dot info
 Reported by:  bernd dot ott at k-m dot info
 Summary:  SoapClient leave tcp connections in "time_wait"
 Status:   Assigned
 Type: Bug
 Package:  SOAP related
 Operating System: Windows
 PHP Version:  5.2CVS-2009-02-05 (snap)
 Assigned To:  dmitry

 New Comment:

Maybe this will Help to solve the problem:

http://httpd.apache.org/docs/1.3/misc/fin_wait_2.html


Previous Comments:

[2009-07-20 11:20:09] m dot stach at ewerk dot com

We are experiencing the same problem. We use Debian Etch (64 bit) in 

combination with Sun Glassfish 2.1 on separate servers.


[2009-05-05 09:08:48] bernd dot ott at k-m dot info

I don't have the ipv6 Stack installed (on any machine).


[2009-05-02 02:49:52] j...@php.net

But did you do what Pierre asked above ? The hosts thing..


[2009-03-02 08:34:22] bernd dot ott at k-m dot info

i created the sample on a old xp machine with apache 2.2 installed.



i have tested the webservice with different Clients made with different
languages. no other client keep the connections in "time_wait".


[2009-02-23 11:21:16] paj...@php.net

Do you have IPv6 installed (by default on Vista or later, needs an extra
package for XP/2k). If yes, edit:



C:\windows\system32\drivers\etc\hosts



and comment the following line:



::1 localhost



becomes:



#::1 localhost



Restart the web server and test again.




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=47314


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=47314&edit=1

Bug #49323 [Com]: json_decode escaped character weirdness

[dmitry dot dulepov at gmail dot com]

Edit report at http://bugs.php.net/bug.php?id=49323&edit=1

 ID:   49323
 Comment by:   dmitry dot dulepov at gmail dot com
 Reported by:  paul dot wieland at port80ware dot com
 Summary:  json_decode escaped character weirdness
 Status:   Bogus
 Type: Bug
 Package:  JSON related
 Operating System: Linux / OSX
 PHP Version:  5.3.0

 New Comment:

Ok, I see the point... However FireFox does not like that escaping. So
any AJAX 

applications that use this generated JSON do not work in FireFox. It is
enough to 

have \/ in JSON to cause JavaScript error in FireFox. Should I report
the bug to 

FireFox than?


Previous Comments:

[2010-03-25 13:22:46] ras...@php.net

dmitry, I don't understand your last comment.  Of course / is escaped in
the 

json encoded string.  According to the spec it is supposed to be.  The
important 

part is that when you json_decode() it it comes back without the \ which
it 

does:



> php -v

PHP 5.3.3-dev (cli) (built: Feb 10 2010 10:53:36) 



> php -a

php > $enc = json_encode(array('test' => 'hello/world'));

php > echo $enc;

{"test":"hello\/world"}

php > var_dump(json_decode($enc));

object(stdClass)#1 (1) {

  ["test"]=>

  string(11) "hello/world"

}


[2010-03-25 12:49:26] dmitry dot dulepov at gmail dot com

No, it is definitely NOT fixed.



php -v says:

=

PHP 5.3.1 (cli) (built: Feb 15 2010 17:30:23) 

Copyright (c) 1997-2009 The PHP Group

Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies

=



Test file:

=

 'hello/world')) . chr(10);

=



Result:

=

{"test":"hello\/world"}

=


[2009-08-22 10:11:12] scott...@php.net

Definitely fixed in 5.3



scott-mbp:~ scott$ php /tmp/test.php

string(10) "Black/Gray"

string(10) "Black/Gray"




[2009-08-21 19:35:42] paul dot wieland at port80ware dot com

Very sorry, the virtualhost I was using was not configured to use 

version 5.3.0 - it is using 5.2.1 instead



So I am not sure if this is an old problem with 5.2.1 that has been 

solved, or it still exists with 5.3.0


[2009-08-21 19:31:12] paul dot wieland at port80ware dot com

Description:

json_encode is not removing the backslash from escaped forward slashes 

in my strings. It works fine on several machines running 5.2.x, but on 

one new machine running php 5.3.0 it returns the wrong result.

Reproduce code:
---
$my_string = 'Black/Gray';

var_dump($my_string);

var_dump(

json_decode(

json_encode($my_string)

)

);



Expected result:

string(10) "Black/Gray"

string(10) "Black/Gray"

Actual result:
--
string(10) "Black/Gray"

string(11) "Black\/Gray"






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=49323&edit=1

Req #51389 [Opn->Asn]: Implement DOMDocument::renameNode()

[johannes]

Edit report at http://bugs.php.net/bug.php?id=51389&edit=1

 ID:  51389
 Updated by:  johan...@php.net
 Reported by: romain dot lalaut at laposte dot net
 Summary: Implement DOMDocument::renameNode()
-Status:  Open
+Status:  Assigned
 Type:Feature/Change Request
 Package: DOM XML related
 PHP Version: 5.3.2
-Assigned To: 
+Assigned To: rrichards



Previous Comments:

[2010-03-25 12:09:25] romain dot lalaut at laposte dot net

Description:

The current DOM implementation doesn't provide the
DOMDocument::renameNode() introduced in DOM Level 3 .

Could this be implemented ?







-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51389&edit=1

Bug #51184 [Opn->Fbk]: DateInterval has incorrect days property on windows

[kalle]

Edit report at http://bugs.php.net/bug.php?id=51184&edit=1

 ID:   51184
 Updated by:   ka...@php.net
 Reported by:  s...@php.net
 Summary:  DateInterval has incorrect days property on windows
-Status:   Open
+Status:   Feedback
 Type: Bug
 Package:  Date/time related
 Operating System: Windows
 PHP Version:  5.3.2RC3

 New Comment:

Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

Derick fixed #49778, did that fix the issue?


Previous Comments:

[2010-03-02 13:41:41] s...@php.net

Description:

On Windows, no matter what the dates are, the "days" property of the
DateInterval object returned by DateTime::diff() is always 6015.



Might be related to http://bugs.php.net/bug.php?id=49778 and
http://bugs.php.net/bug.php?id=49081

Test script:
---
$start = new DateTime('2010-06-06'); 

$end   = new DateTime('2011-02-04'); 

echo $start->diff($end)->days;



$start = new DateTime('2005-01-01'); 

echo $start->diff($end)->days;

Expected result:

The right number of days, or at least always 42 :)

Actual result:
--
6015, always.






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51184&edit=1

Bug #51187 [Csd->Dup]: Segmentation fault with Zend_Form/Zend_View

[kalle]

Edit report at http://bugs.php.net/bug.php?id=51187&edit=1

 ID:   51187
 Updated by:   ka...@php.net
 Reported by:  bostjan at a2o dot si
 Summary:  Segmentation fault with Zend_Form/Zend_View
-Status:   Closed
+Status:   Duplicate
 Type: Bug
 Package:  Reproducible crash
 Operating System: Linux
 PHP Version:  Irrelevant
-Assigned To:  kalle
+Assigned To:  



Previous Comments:

[2010-03-25 13:23:11] ka...@php.net

Can you check if the crash is either one of those described in #46156
and its comments? If its not then please add a comment with how to
reproduce it so we have one report with all possible cases we can find.


[2010-03-03 13:58:38] bostjan at a2o dot si

:) Code was fixed imediately because segfaults were persistent and thus
development stopped.



It still is a PHP crashing bug though (and ZF inconvenience bug if there
is such a thing).


[2010-03-03 13:32:06] weierophin...@php.net

I understand completely what's happening -- you set the value of the
object to 

the object itself; when rendering, it then attempts to cast the value to
a 

string, which means casting the object to a string... which means
rendering the 

element, which will in turn need to cast the value to a string. It's
indeed 

recursion.



I can potentially put in some recursion detection in ZF; I'm not sure if
the PHP 

team wants to investigate the segfault, however.



Personally, though, I'd consider fixing the code instead, to ensure
you're not 

overwriting the value passed to the function (which is the real error
here).


[2010-03-03 04:54:53] ahar...@php.net

You can find instructions on generating a backtrace at
http://bugs.php.net/bugs-

generating-backtrace.php.


[2010-03-03 04:33:33] bostjan at a2o dot si

It most certainly is an endless recursion, though it should only lead to
memory limit error.



How do I acquire a stack track?




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=51187


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51187&edit=1

Bug #51187 [Opn->Csd]: Segmentation fault with Zend_Form/Zend_View

[kalle]

Edit report at http://bugs.php.net/bug.php?id=51187&edit=1

 ID:   51187
 Updated by:   ka...@php.net
 Reported by:  bostjan at a2o dot si
 Summary:  Segmentation fault with Zend_Form/Zend_View
-Status:   Open
+Status:   Closed
 Type: Bug
 Package:  Reproducible crash
 Operating System: Linux
 PHP Version:  Irrelevant
-Assigned To:  
+Assigned To:  kalle

 New Comment:

Can you check if the crash is either one of those described in #46156
and its comments? If its not then please add a comment with how to
reproduce it so we have one report with all possible cases we can find.


Previous Comments:

[2010-03-03 13:58:38] bostjan at a2o dot si

:) Code was fixed imediately because segfaults were persistent and thus
development stopped.



It still is a PHP crashing bug though (and ZF inconvenience bug if there
is such a thing).


[2010-03-03 13:32:06] weierophin...@php.net

I understand completely what's happening -- you set the value of the
object to 

the object itself; when rendering, it then attempts to cast the value to
a 

string, which means casting the object to a string... which means
rendering the 

element, which will in turn need to cast the value to a string. It's
indeed 

recursion.



I can potentially put in some recursion detection in ZF; I'm not sure if
the PHP 

team wants to investigate the segfault, however.



Personally, though, I'd consider fixing the code instead, to ensure
you're not 

overwriting the value passed to the function (which is the real error
here).


[2010-03-03 04:54:53] ahar...@php.net

You can find instructions on generating a backtrace at
http://bugs.php.net/bugs-

generating-backtrace.php.


[2010-03-03 04:33:33] bostjan at a2o dot si

It most certainly is an endless recursion, though it should only lead to
memory limit error.



How do I acquire a stack track?


[2010-03-03 00:37:52] johan...@php.net

I assume this is an endless recursion, can you please provide a
stacktrack?




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=51187


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51187&edit=1

Bug #49323 [Bgs]: json_decode escaped character weirdness

[rasmus]

Edit report at http://bugs.php.net/bug.php?id=49323&edit=1

 ID:   49323
 Updated by:   ras...@php.net
 Reported by:  paul dot wieland at port80ware dot com
 Summary:  json_decode escaped character weirdness
 Status:   Bogus
 Type: Bug
 Package:  JSON related
 Operating System: Linux / OSX
 PHP Version:  5.3.0

 New Comment:

dmitry, I don't understand your last comment.  Of course / is escaped in
the 

json encoded string.  According to the spec it is supposed to be.  The
important 

part is that when you json_decode() it it comes back without the \ which
it 

does:



> php -v

PHP 5.3.3-dev (cli) (built: Feb 10 2010 10:53:36) 



> php -a

php > $enc = json_encode(array('test' => 'hello/world'));

php > echo $enc;

{"test":"hello\/world"}

php > var_dump(json_decode($enc));

object(stdClass)#1 (1) {

  ["test"]=>

  string(11) "hello/world"

}


Previous Comments:

[2010-03-25 12:49:26] dmitry dot dulepov at gmail dot com

No, it is definitely NOT fixed.



php -v says:

=

PHP 5.3.1 (cli) (built: Feb 15 2010 17:30:23) 

Copyright (c) 1997-2009 The PHP Group

Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies

=



Test file:

=

 'hello/world')) . chr(10);

=



Result:

=

{"test":"hello\/world"}

=


[2009-08-22 10:11:12] scott...@php.net

Definitely fixed in 5.3



scott-mbp:~ scott$ php /tmp/test.php

string(10) "Black/Gray"

string(10) "Black/Gray"




[2009-08-21 19:35:42] paul dot wieland at port80ware dot com

Very sorry, the virtualhost I was using was not configured to use 

version 5.3.0 - it is using 5.2.1 instead



So I am not sure if this is an old problem with 5.2.1 that has been 

solved, or it still exists with 5.3.0


[2009-08-21 19:31:12] paul dot wieland at port80ware dot com

Description:

json_encode is not removing the backslash from escaped forward slashes 

in my strings. It works fine on several machines running 5.2.x, but on 

one new machine running php 5.3.0 it returns the wrong result.

Reproduce code:
---
$my_string = 'Black/Gray';

var_dump($my_string);

var_dump(

json_decode(

json_encode($my_string)

)

);



Expected result:

string(10) "Black/Gray"

string(10) "Black/Gray"

Actual result:
--
string(10) "Black/Gray"

string(11) "Black\/Gray"






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=49323&edit=1

Bug #27051 [Com]: Impersonation with FastCGI does not EXEC process as impersonated user

[heer2351 at zonnet dot nl]

Edit report at http://bugs.php.net/bug.php?id=27051&edit=1

 ID:   27051
 Comment by:   heer2351 at zonnet dot nl
 Reported by:  ghoffer at globalscape dot com
 Summary:  Impersonation with FastCGI does not EXEC process as
   impersonated user
 Status:   Feedback
 Type: Bug
 Package:  CGI related
 Operating System: Windows
 PHP Version:  5.3
 Assigned To:  pajoye

 New Comment:

Located the problem and have been able to fix it.



I am using a special user for my Application Pool (say AppPoolUser), so
PHP runs as this user. The new exec function uses CreateProcessAsUser()
with impersonation. This means that the AppPoolUser must have the right
to change the process level token.



You can assign this right to the user in the "Local Security Settings"
-> User Rights Assignment.



I have granted my AppPoolUser the "Replace a process level token"
setting -> fork error has gone.



Thought this might be useful information, so access is required to
cmd.exe but in addition the "Replace a process level token" setting.


Previous Comments:

[2010-03-25 00:45:36] paj...@php.net

I will repeat a last time :) It does work here using IIS6 and the exact
same windows version of FastCGI. The other users with issues with that
have solved the problem as well using latest 5.3 and the right
configuration.



There are differences between 5.2 and 5.3, a lot. One of them is a
working impersonation (which is not only about exec).


[2010-03-25 00:40:55] heer2351 at zonnet dot nl

Thanks for your help. I think there are still more people with the same
problem. I will try to find a solution and will post here if I find
one.

For now I stick with 5.2.13



I am not convinced it is a config problem. Will dig into SVN and find
what the difference is between the two versions.


[2010-03-25 00:30:20] paj...@php.net

I don't know either and hard to say why it does not work for you but for
us (same config).



I feel like you actually configure it wrong. impersonation in 5.2 was
not fully working and was not doing the right thing (not only for
exec&co).



I can't help further without more details about how you configure the
impersonation or having a remote access to debug.


[2010-03-25 00:17:50] heer2351 at zonnet dot nl

Changed to your suggestion with \\, same error.



Changed to 5.2.13 ran my version and your version both echo the correct
username.


[2010-03-25 00:13:31] heer2351 at zonnet dot nl

What I do not understand is that 5.2.13 works and 5.3.2 (or 5.3.3) does
not work with the same configuration.




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=27051


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=27051&edit=1

Bug #49323 [Com]: json_decode escaped character weirdness

[dmitry dot dulepov at gmail dot com]

Edit report at http://bugs.php.net/bug.php?id=49323&edit=1

 ID:   49323
 Comment by:   dmitry dot dulepov at gmail dot com
 Reported by:  paul dot wieland at port80ware dot com
 Summary:  json_decode escaped character weirdness
 Status:   Bogus
 Type: Bug
 Package:  JSON related
 Operating System: Linux / OSX
 PHP Version:  5.3.0

 New Comment:

No, it is definitely NOT fixed.



php -v says:

=

PHP 5.3.1 (cli) (built: Feb 15 2010 17:30:23) 

Copyright (c) 1997-2009 The PHP Group

Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies

=



Test file:

=

 'hello/world')) . chr(10);

=



Result:

=

{"test":"hello\/world"}

=


Previous Comments:

[2009-08-22 10:11:12] scott...@php.net

Definitely fixed in 5.3



scott-mbp:~ scott$ php /tmp/test.php

string(10) "Black/Gray"

string(10) "Black/Gray"




[2009-08-21 19:35:42] paul dot wieland at port80ware dot com

Very sorry, the virtualhost I was using was not configured to use 

version 5.3.0 - it is using 5.2.1 instead



So I am not sure if this is an old problem with 5.2.1 that has been 

solved, or it still exists with 5.3.0


[2009-08-21 19:31:12] paul dot wieland at port80ware dot com

Description:

json_encode is not removing the backslash from escaped forward slashes 

in my strings. It works fine on several machines running 5.2.x, but on 

one new machine running php 5.3.0 it returns the wrong result.

Reproduce code:
---
$my_string = 'Black/Gray';

var_dump($my_string);

var_dump(

json_decode(

json_encode($my_string)

)

);



Expected result:

string(10) "Black/Gray"

string(10) "Black/Gray"

Actual result:
--
string(10) "Black/Gray"

string(11) "Black\/Gray"






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=49323&edit=1

Bug #51354 [Opn]: Random string data returned for timestamp odbc field

[felipe]

Edit report at http://bugs.php.net/bug.php?id=51354&edit=1

 ID:   51354
 Updated by:   fel...@php.net
 Reported by:  andrew dot coulton at proscenia dot co dot uk
 Summary:  Random string data returned for timestamp odbc field
 Status:   Open
 Type: Bug
 Package:  ODBC related
 Operating System: Windows Vista/Apache 2.2.11
 PHP Version:  5.2.13

 New Comment:

Hi. I can't reproduce it using MySQL Driver. So, probably this is a Sage
driver issue.


Previous Comments:

[2010-03-23 02:03:16] andrew dot coulton at proscenia dot co dot uk

Description:

Using the Sage Line 50 ODBC driver (v15 or v16), when selecting a table
containing timestamp column values odbc returns a string type variable
containing random data - consistent for all rows in the resultset and
occasionally between requests but changing at random. This applies
whether using PDO or odbc_ functions.



Including an ISO 8601 timestamp value as a WHERE condition performs as
expected, so this appears to be a problem with the retrieval of a
resultset.



Additionally, calling odbc_field_type() on the column crashes php (valid
results are returned for other columns, including date values but not
timestamps, in the dataset). It appears this may be a result of the data
type not appearing in the table returned by odbc_gettypeinfo?



PHP is running as an apache module. Extensions enabled:

-php_mssql.dll

-php_mysql.dll

-php_apc.dll

-php_apd.dll

-php_gd2.dll

-php_uploadprogress.dll

-php_pdo.dll

-php_pdo_mysql.dll

-php_pdo_odbc.dll



ODBC settings:

odbc.allow_persistent = On

odbc.check_persistent = On

odbc.max_persistent = -1

odbc.max_links = -1

odbc.defaultlrl = 4096

odbc.defaultbinmode = 1



I can access the tables with the correct timestamps showing through ODBC
in Access and through ADO in a Delphi application.

Test script:
---
$conn= new PDO("odbc:DSN=SageLine50v16;Uid=manager;Pwd=");

$result=$conn->query("SELECT DATE, RECORD_CREATE_DATE 

  FROM AUDIT_JOURNAL 

  WHERE RECORD_CREATE_DATE>='2010-03-22
12:19:00'");



echo "Query Result\n";

if ($result) {

var_dump($result->fetch());

}

  

$connection = odbc_connect('SageLine50v16','manager','');

$result=odbc_columns($connection, "%", "%", "AUDIT_JOURNAL", 

 "RECORD_CREATE_DATE");



echo "RECORD_CREATE_DATE ";

print_r(odbc_fetch_array($result));



echo "DATE ";

$result=odbc_columns($connection, "%", "%", "AUDIT_JOURNAL", "DATE");

print_r(odbc_fetch_array($result));



$result= odbc_gettypeinfo($connection);

echo "TypeInfo\n";

odbc_result_all($result);



$result=odbc_exec($connection, "SELECT DATE, RECORD_CREATE_DATE 

  FROM AUDIT_JOURNAL;");

echo "Field Name\tType\n";

echo odbc_field_name($result, 1),"\t\t",odbc_field_type($result, 1);



/* The following causes php to terminate unexpectedly */

//echo odbc_field_name($result, 2),"\t\t\t",odbc_field_type($result, 2);

Expected result:

Expect to see:

- result array with a valid timestamp in RECORD_CREATE_DATE rather than
mangled string.

- A non-null TYPE_NAME key in the odbc_columns() return value for the
RECORD_CREATE_DATE field.

- Presumably, a value in the data type table returned by
odbc_gettypeinfo corresponding to data type #11 - there is no row for
this though notably #9 maps to the DATE type and #10 to TIME, so #11
would fit as Timestamp?

- A return value for the odbc_field_type for the RECORD_CREATE_DATE
column.

Actual result:
--
Query Result

array() { /*numeric keys removed*/

  ["DATE"]=>

  string(10) "2010-03-22"

  ["RECORD_CREATE_DATE"]=>

  string(19) "�p�y��9������wW"

}



RECORD_CREATE_DATE Array

(

[TABLE_QUALIFIER] => 

[TABLE_OWNER] => 

[TABLE_NAME] => AUDIT_JOURNAL

[COLUMN_NAME] => RECORD_CREATE_DATE

[DATA_TYPE] => 11

[TYPE_NAME] => 

[PRECISION] => 0

[LENGTH] => 8

[SCALE] => 0

[RADIX] => 10

[NULLABLE] => 0

[REMARKS] => Date and time when the record was created.

)

DATE Array

(

[TABLE_QUALIFIER] => 

[TABLE_OWNER] => 

[TABLE_NAME] => AUDIT_JOURNAL

[COLUMN_NAME] => DATE

[DATA_TYPE] => 9

[TYPE_NAME] => DATE

[PRECISION] => 10

[LENGTH] => 2

[SCALE] => 0

[RADIX] => 10

[NULLABLE] => 0

[REMARKS] => Transaction date

)

TypeInfo

TYPE_NAME   DATA_TYPE   PRECISION   LITERAL_PREFIX  LITERAL_SUFFIX  
CREATE_PARAMS   NULLABLECASE_SENSITIVE  SEARCHABLE  
UNSIGNED_ATTRIBUTE  MONEY   AUTO_INCREMENT  LOCAL_TYPE_NAME

CHAR1   0   "   "   NULL1   1   3   1   
0   0   NULL

VARCHAR 12  0   "   "   NULL1   1   3   1   
0   0   NULL

LONG VARCHAR-1  0   "  

Bug #39312 [Asn->Fbk]: Cannot install PDO_OCI

[kalle]

Edit report at http://bugs.php.net/bug.php?id=39312&edit=1

 ID:   39312
 Updated by:   ka...@php.net
 Reported by:  andrew dot nagy at villanova dot edu
 Summary:  Cannot install PDO_OCI
-Status:   Assigned
+Status:   Feedback
 Type: Bug
 Package:  PDO related
 Operating System: Linux
 PHP Version:  5.2.9
 Assigned To:  sixd

 New Comment:

Please try using this snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/




Previous Comments:

[2010-03-16 20:54:32] jbrauer at llu dot edu

I got it to build on Redhat using the instantclient RPM.  Here's what I
did.



manually added the following to config.m4 to allow for Oracle instant
client 

11.1

(stolen from matts at iastate above)

@@ -7,6 +7,8 @@

   if test -s "$PDO_OCI_DIR/orainst/unix.rgs"; then

 PDO_OCI_VERSION=`grep '"ocommon"' $PDO_OCI_DIR/orainst/unix.rgs |
sed 's/[ 

][ ]*/:/g' | cut -d: -f 6 | cut -c 2-4`

 test -z "$PDO_OCI_VERSION" && PDO_OCI_VERSION=7.3

+  elif test -f $PDO_OCI_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.11.1;
then

+PDO_OCI_VERSION=11.1

   elif test -f $PDO_OCI_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.10.1;
then

 PDO_OCI_VERSION=10.1

   elif test -f $PDO_OCI_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then



AND



@@ -119,6 +126,9 @@

 10.2)

   PHP_ADD_LIBRARY(clntsh, 1, PDO_OCI_SHARED_LIBADD)

   ;;

+11.1)

+  dnl PHP_ADD_LIBRARY(clntsh, 1, PDO_OCI_SHARED_LIBADD)

+  ;;

 *)

   AC_MSG_ERROR(Unsupported Oracle version! $PDO_OCI_VERSION)

   ;;



if you have instant client of lower version its not needed.



Then I re phpize 'd it. and ran configure:

(esimard at mediagrif dot com)'s strace showed me the only dir I needed
was /usr



./configure --with-pdo-oci=instantclient,/usr,11.1.0.1



configure, make and make install completed successfully


[2009-09-16 21:15:51] matts at iastate dot edu

Since the above messed up the formatting, I'll keep a copy of the patch
here for the meantime:



http://booster.agron.iastate.edu/mattsteven/oci_patch_jaunty.patch


[2009-09-16 21:13:02] matts at iastate dot edu

Here is a patch which will let you build the pdo_oci lib with the
instant client on debian or ubuntu systems.  Save the contents to
oci_patch.txt, and then run it against your config.m4 file like so:



cd PDO_OCI-1.0 && patch -p0 < /path/to/oci_patch.txt



=



### Eclipse Workspace Patch 1.0

#P pdo_oci

Index: config.m4

===

--- config.m4   (revision 141)

+++ config.m4   (working copy)

@@ -7,6 +7,8 @@

   if test -s "$PDO_OCI_DIR/orainst/unix.rgs"; then

 PDO_OCI_VERSION=`grep '"ocommon"' $PDO_OCI_DIR/orainst/unix.rgs |
sed 's/[ ][ ]*/:/g' | cut -d: -f 6 | cut -c 2-4`

 test -z "$PDO_OCI_VERSION" && PDO_OCI_VERSION=7.3

+  elif test -f $PDO_OCI_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.11.1;
then

+PDO_OCI_VERSION=11.1

   elif test -f $PDO_OCI_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.10.1;
then

 PDO_OCI_VERSION=10.1

   elif test -f $PDO_OCI_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then

@@ -57,14 +59,19 @@

 AC_MSG_CHECKING([for oci.h])

 if test -f
$PDO_OCI_IC_PREFIX/include/oracle/$PDO_OCI_IC_VERS/client/oci.h ; then

  
PHP_ADD_INCLUDE($PDO_OCI_IC_PREFIX/include/oracle/$PDO_OCI_IC_VERS/client)

+ 
PDO_OCI_LIB_DIR="$PDO_OCI_IC_PREFIX/lib/oracle/$PDO_OCI_IC_VERS/client/lib"

  
AC_MSG_RESULT($PDO_OCI_IC_PREFIX/include/oracle/$PDO_OCI_IC_VERS/client)

 elif test -f
$PDO_OCI_IC_PREFIX/lib/oracle/$PDO_OCI_IC_VERS/client/include/oci.h ;
then

  
PHP_ADD_INCLUDE($PDO_OCI_IC_PREFIX/lib/oracle/$PDO_OCI_IC_VERS/client/include)

+ 
PDO_OCI_LIB_DIR="$PDO_OCI_IC_PREFIX/lib/oracle/$PDO_OCI_IC_VERS/client/lib"

  
AC_MSG_RESULT($PDO_OCI_IC_PREFIX/lib/oracle/$PDO_OCI_IC_VERS/client/include)

+elif test -f $PDO_OCI_IC_PREFIX/sdk/include/oci.h ; then

+  PHP_ADD_INCLUDE($PDO_OCI_IC_PREFIX/sdk/include)

+  AC_MSG_RESULT($PDO_OCI_IC_PREFIX/sdk/include)

+  PDO_OCI_LIB_DIR="$PDO_OCI_IC_PREFIX"

 else

   AC_MSG_ERROR([I'm too dumb to figure out where the include dir is
in your instant client install])

 fi

-   
PDO_OCI_LIB_DIR="$PDO_OCI_IC_PREFIX/lib/oracle/$PDO_OCI_IC_VERS/client/lib"

 PDO_OCI_VERSION="`echo $PDO_OCI_IC_VERS | cut -d. -f1-2`"

   else

 if test -d "$PDO_OCI_DIR/rdbms/public"; then

@@ -119,6 +126,9 @@

 10.2)

   PHP_ADD_LIBRARY(clntsh, 1, PDO_OCI_SHARED_LIBADD)

   ;;

+11.1)

+  dnl PHP_ADD_LIBRARY(clntsh, 1, PDO_OCI_SHARED_LIBADD)

+  ;;

 *)

   AC_MSG_ERROR(Unsupported Oracle version! $PDO_OCI_VERSION)

   ;;

@@ -176,22 +1

[PHP-BUG] Req #51389 [NEW]: Implement DOMDocument::renameNode()

[romain dot lalaut at laposte dot net]

From: 
Operating system: 
PHP version:  5.3.2
Package:  DOM XML related
Bug Type: Feature/Change Request
Bug description:Implement DOMDocument::renameNode()

Description:

The current DOM implementation doesn't provide the
DOMDocument::renameNode() introduced in DOM Level 3 .

Could this be implemented ?


-- 
Edit bug report at http://bugs.php.net/bug.php?id=51389&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51389&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51389&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51389&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51389&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=51389&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51389&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=51389&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=51389&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=51389&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=51389&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=51389&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=51389&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=51389&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51389&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=51389&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51389&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=51389&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=51389&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=51389&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=51389&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=51389&r=mysqlcfg

Bug #51263 [Opn->Csd]: imagettftext and rotated text uses wrong baseline (regression)

[tabe]

Edit report at http://bugs.php.net/bug.php?id=51263&edit=1

 ID:  51263
 Updated by:  t...@php.net
 Reported by: cschneid at cschneid dot com
 Summary: imagettftext and rotated text uses wrong baseline
  (regression)
-Status:  Open
+Status:  Closed
 Type:Bug
 Package: GD related
 PHP Version: 5.3.2
-Assigned To: 
+Assigned To: tabe

 New Comment:

Hi cschneid,



Thanks for your patch. Applied.


Previous Comments:

[2010-03-24 05:12:21] t...@php.net

Automatic comment from SVN on behalf of tabe
Revision: http://svn.php.net/viewvc/?view=revision&revision=296693
Log: Fixed bug #51263 (imagettftext and rotated text uses wrong
baseline)


[2010-03-10 15:56:25] cschneid at cschneid dot com

Description:

imagettftext and rotated text by e.g. 90 degrees aligns text on top of
characters instead of baseline.



The regression was introduced with commit

r293268  | tabe   | 2010-01-08 13:18:52 | Bug #49600 (imageTTFText
text shifted right) - fix difference of horizontal position between
imagettftext() and imagettfbbox()



Test script:
---
http://bugs.php.net/bug.php?id=51263&edit=1

Bug #51386 [Opn->Asn]: mysql tries to allocate 4294967296 bytes when fetching longtext via mysqli

[johannes]

Edit report at http://bugs.php.net/bug.php?id=51386&edit=1

 ID:   51386
 Updated by:   johan...@php.net
 Reported by:  rellig at minad dot de
 Summary:  mysql tries to allocate 4294967296 bytes when fetching
   longtext via mysqli
-Status:   Open
+Status:   Assigned
 Type: Bug
 Package:  MySQLi related
 Operating System: gentoo
 PHP Version:  5.2.13
-Assigned To:  
+Assigned To:  mysql



Previous Comments:

[2010-03-25 08:19:55] rellig at minad dot de

Description:

I wanted to fetch some lines in a php script via
mysqli-prepared-statement and got this

error:

Allowed memory size of 134217728 bytes exhausted (tried to allocate
4294967296 bytes)

I was confused because php reportet that this error occured at
bind_result.

After some time I figured out that it works when I turn one field with
LONGTEXT type to

VARCHAR, for example.



here is a link to my php-script:

http://paste.minad.de/?nid=216





you can look at http://bugs.mysql.com/bug.php?id=52234 too.









-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51386&edit=1

Bug #51388 [Bgs]: Cannot view a php file

[aharvey]

Edit report at http://bugs.php.net/bug.php?id=51388&edit=1

 ID:   51388
 Updated by:   ahar...@php.net
 Reported by:  elindr10 at yahoo dot com
 Summary:  Cannot view a php file
 Status:   Bogus
 Type: Bug
 Package:  Unknown/Other Function
 Operating System: Windows Vista
 PHP Version:  5.3.2

 New Comment:

The php-webmaster mailing list is not for PHP support. php-general or

php-install might be more appropriate. At any rate, please look at

the aforementioned list of support options at

http://www.php.net/support.php and choose one that suits you.


Previous Comments:

[2010-03-25 09:43:51] elindr10 at yahoo dot com

I'm really sorry for submitting another report. Okay, thanks for telling
me. Err, I can't find where I can see my problem. Can I send a mail to
php-webmas...@lists.php.net regarding my problem? Again, sorry for this.


[2010-03-25 09:40:47] ahar...@php.net

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

Please don't submit the same issue more than once, particularly when
it's not 

actually a PHP bug in the first place.


[2010-03-25 09:36:47] elindr10 at yahoo dot com

Description:

I have installed Apache 2.2.15 and PHP 5.3.2 on my computer.



When I view a sample php file with a code like this
http://dl.dropbox.com/u/1819636/SnagIt/ElindrPhoto_0007.png a window
pops up which lets me choose a program to use to open the php file. But
it should not be like that, I should see the test PHP page.



What's the problem? What should I do to fix this? hmm.









-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51388&edit=1

Bug #51388 [Bgs]: Cannot view a php file

[elindr10 at yahoo dot com]

Edit report at http://bugs.php.net/bug.php?id=51388&edit=1

 ID:   51388
 User updated by:  elindr10 at yahoo dot com
 Reported by:  elindr10 at yahoo dot com
 Summary:  Cannot view a php file
 Status:   Bogus
 Type: Bug
 Package:  Unknown/Other Function
 Operating System: Windows Vista
 PHP Version:  5.3.2

 New Comment:

I'm really sorry for submitting another report. Okay, thanks for telling
me. Err, I can't find where I can see my problem. Can I send a mail to
php-webmas...@lists.php.net regarding my problem? Again, sorry for this.


Previous Comments:

[2010-03-25 09:40:47] ahar...@php.net

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

Please don't submit the same issue more than once, particularly when
it's not 

actually a PHP bug in the first place.


[2010-03-25 09:36:47] elindr10 at yahoo dot com

Description:

I have installed Apache 2.2.15 and PHP 5.3.2 on my computer.



When I view a sample php file with a code like this
http://dl.dropbox.com/u/1819636/SnagIt/ElindrPhoto_0007.png a window
pops up which lets me choose a program to use to open the php file. But
it should not be like that, I should see the test PHP page.



What's the problem? What should I do to fix this? hmm.









-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51388&edit=1

Bug #51388 [Opn->Bgs]: Cannot view a php file

[aharvey]

Edit report at http://bugs.php.net/bug.php?id=51388&edit=1

 ID:   51388
 Updated by:   ahar...@php.net
 Reported by:  elindr10 at yahoo dot com
 Summary:  Cannot view a php file
-Status:   Open
+Status:   Bogus
 Type: Bug
 Package:  Unknown/Other Function
 Operating System: Windows Vista
 PHP Version:  5.3.2

 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

Please don't submit the same issue more than once, particularly when
it's not 

actually a PHP bug in the first place.


Previous Comments:

[2010-03-25 09:36:47] elindr10 at yahoo dot com

Description:

I have installed Apache 2.2.15 and PHP 5.3.2 on my computer.



When I view a sample php file with a code like this
http://dl.dropbox.com/u/1819636/SnagIt/ElindrPhoto_0007.png a window
pops up which lets me choose a program to use to open the php file. But
it should not be like that, I should see the test PHP page.



What's the problem? What should I do to fix this? hmm.









-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51388&edit=1

[PHP-BUG] Bug #51388 [NEW]: Cannot view a php file

[elindr10 at yahoo dot com]

From: 
Operating system: Windows Vista
PHP version:  5.3.2
Package:  Unknown/Other Function
Bug Type: Bug
Bug description:Cannot view a php file

Description:

I have installed Apache 2.2.15 and PHP 5.3.2 on my computer.



When I view a sample php file with a code like this
http://dl.dropbox.com/u/1819636/SnagIt/ElindrPhoto_0007.png a window pops
up which lets me choose a program to use to open the php file. But it
should not be like that, I should see the test PHP page.



What's the problem? What should I do to fix this? hmm.




-- 
Edit bug report at http://bugs.php.net/bug.php?id=51388&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51388&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51388&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51388&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51388&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=51388&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51388&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=51388&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=51388&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=51388&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=51388&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=51388&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=51388&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=51388&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51388&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=51388&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51388&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=51388&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=51388&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=51388&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=51388&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=51388&r=mysqlcfg

Bug #51387 [Opn->Bgs]: Cannot view a php file

[aharvey]

Edit report at http://bugs.php.net/bug.php?id=51387&edit=1

 ID:   51387
 Updated by:   ahar...@php.net
 Reported by:  elindr10 at yahoo dot com
 Summary:  Cannot view a php file
-Status:   Open
+Status:   Bogus
 Type: Bug
 Package:  Unknown/Other Function
 Operating System: Windows Vista
 PHP Version:  5.3.2

 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.




Previous Comments:

[2010-03-25 09:33:34] elindr10 at yahoo dot com

Description:

I have installed Apache 2.2.15 and PHP 5.3.2 on my computer.



When I view a sample php file with a code like this
http://dl.dropbox.com/u/1819636/SnagIt/ElindrPhoto_0007.png, a window
pops up which lets me choose a program to use to open the php file. But
it should not be like that, I should see the test PHP page.



What's the problem? What should I do to fix this? hmm.







-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51387&edit=1

[PHP-BUG] Bug #51387 [NEW]: Cannot view a php file

[elindr10 at yahoo dot com]

From: 
Operating system: Windows Vista
PHP version:  5.3.2
Package:  Unknown/Other Function
Bug Type: Bug
Bug description:Cannot view a php file

Description:

I have installed Apache 2.2.15 and PHP 5.3.2 on my computer.



When I view a sample php file with a code like this
http://dl.dropbox.com/u/1819636/SnagIt/ElindrPhoto_0007.png, a window pops
up which lets me choose a program to use to open the php file. But it
should not be like that, I should see the test PHP page.



What's the problem? What should I do to fix this? hmm.


-- 
Edit bug report at http://bugs.php.net/bug.php?id=51387&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51387&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51387&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51387&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51387&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=51387&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51387&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=51387&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=51387&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=51387&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=51387&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=51387&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=51387&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=51387&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51387&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=51387&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51387&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=51387&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=51387&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=51387&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=51387&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=51387&r=mysqlcfg

Bug #51382 [Com]: session_start() blocks execution

[abca_b_cabcom at hotmail dot com]

Edit report at http://bugs.php.net/bug.php?id=51382&edit=1

 ID:   51382
 Comment by:   abca_b_cabcom at hotmail dot com
 Reported by:  info at lategoodbye dot de
 Summary:  session_start() blocks execution
 Status:   Open
 Type: Bug
 Package:  Session related
 Operating System: Linux 2.4.35.4 mips
 PHP Version:  5.3.2

 New Comment:

>From you description I traced back to the line 1475 in
./etc/session/session.c,

it is the only line which will be affect by the php.ini variable
session.gc_divisor you describe.



The line is show below:

nrand = (int) ((float) PS(gc_divisor) * php_combined_lcg(TSRMLS_C));



So, I think it may be a compiling error.


Previous Comments:

[2010-03-24 19:04:24] ras...@php.net

One way to figure that out is to attach gdb to a hanging fcgi process
and get a 

backtrace (bt) from gdb which should show where it is stuck.


[2010-03-24 18:44:22] info at lategoodbye dot de

Description:

Hi, i'm running PHP 5.3.2 via FastCGI with lighttpd 1.4.25 and uclibc
0.9.29. I experienced that after a period of time, all session driven
pages hang and deliver no content to the client. But all static content
like images are accessible. Below i appended a little script, how the
problem can be reproduced.



Here are the options from the php.ini:



session.save_handler = files

session.save_path = "/tmp"

session.gc_probability = 1

session.gc_divisor = 100

session.gc_maxlifetime = 1440



Here is the configure line:



'./configure' '--target=mipsel-linux' '--host=mipsel-linux'
'--build=i486-linux-gnu' '--program-prefix=' '--program-suffix='
'--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin'
'--sbindir=/usr/sbin' '--libexecdir=/usr/lib' '--sysconfdir=/etc'
'--datadir=/usr/share' '--localstatedir=/var' '--mandir=/usr/man'
'--infodir=/usr/info' '--disable-nls' '--enable-shared'
'--disable-static' '--disable-rpath' '--disable-debug' '--without-pear'
'--with-config-file-path=/etc' '--enable-magic-quotes'
'--disable-short-tags' '--without-gettext' '--disable-simplexml'
'--with-zlib=/home/10_openwrt/staging_dir/mipsel/usr'
'--with-zlib-dir=/home/10_openwrt/staging_dir/mipsel/usr'
'--with-pcre-regex=/home/10_openwrt/staging_dir/mipsel/usr'
'--disable-phar' '--enable-ctype=shared' '--without-curl'
'--disable-fileinfo' '--disable-dom' '--disable-exif' '--disable-ftp'
'--without-gd' '--without-gmp' '--disable-hash' '--without-iconv'
'--enable-json=shared' '--without-ldap' '--disable-mbstring'
'--without-mcrypt' '--without-mysql' '--without-openssl'
'--enable-pdo=shared' '--without-pdo-mysql' '--without-pdo-pgsql'
'--with-pdo-sqlite=shared,/home/10_openwrt/staging_dir/mipsel/usr'
'--without-pgsql' '--enable-session=shared' '--disable-soap'
'--enable-sockets=shared' '--without-sqlite'
'--with-sqlite3=shared,/home/10_openwrt/staging_dir/mipsel/usr'
'--disable-tokenizer'
'--enable-xml=shared,/home/10_openwrt/staging_dir/mipsel/usr'
'--with-libexpat-dir=/home/10_openwrt/staging_dir/mipsel/usr'
'--disable-xmlreader' '--disable-xmlwriter' '--disable-apc'
'--disable-filter' '--disable-libxml' '--enable-sysvsem'
'--enable-sysvshm' '--enable-sysvmsg' '--enable-pcntl' '--disable-cli'
'--enable-cgi'



The filesystem behind /tmp is tmpfs.



After that i played a little bit with option session.gc_divisor. If i
set the option to 2, then the problem happend immediately. But if i set
the option to 10, the problem is not reproducable.



Is this a dead lock caused by the session garbage collector?

Test script:
---


Content

Expected result:

PHP delivers "Content" to the browser.

Actual result:
--
The browser didn't get "Content" and wait for a response.






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=51382&edit=1

[PHP-BUG] Bug #51386 [NEW]: mysql tries to allocate 4294967296 bytes when fetching longtext via mysqli

[rellig at minad dot de]

From: 
Operating system: gentoo
PHP version:  5.2.13
Package:  MySQLi related
Bug Type: Bug
Bug description:mysql tries to allocate 4294967296 bytes when fetching longtext 
via mysqli

Description:

I wanted to fetch some lines in a php script via mysqli-prepared-statement
and got this

error:

Allowed memory size of 134217728 bytes exhausted (tried to allocate
4294967296 bytes)

I was confused because php reportet that this error occured at
bind_result.

After some time I figured out that it works when I turn one field with
LONGTEXT type to

VARCHAR, for example.



here is a link to my php-script:

http://paste.minad.de/?nid=216





you can look at http://bugs.mysql.com/bug.php?id=52234 too.




-- 
Edit bug report at http://bugs.php.net/bug.php?id=51386&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51386&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51386&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51386&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51386&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=51386&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51386&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=51386&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=51386&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=51386&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=51386&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=51386&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=51386&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=51386&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51386&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=51386&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51386&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=51386&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=51386&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=51386&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=51386&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=51386&r=mysqlcfg