Bug #61045 [Com]: fpm don't send error log to fastcgi clients(nginx)

[bitmand at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=61045edit=1

 ID: 61045
 Comment by: bitmand at gmail dot com
 Reported by:lxlight at gmail dot com
 Summary:fpm don't send error log to fastcgi clients(nginx)
 Status: Assigned
 Type:   Bug
 Package:FPM related
 Operating System:   Linux
 PHP Version:5.3.10
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

Same here on 5.3.9 and .10 on apache. Errors used to go to apache error log, 
but 
after 5.3.9 nothing gets logged.

I wonder if the change is actually by design, according to the php-fpm 
documentation for catch_workers_output is states that If not set, stdout and 
stderr will be redirected to /dev/null according to FastCGI specs.

But it would definitely be great with and option to throw errors to stderr 
again.


Previous Comments:

[2012-03-28 14:45:25] kustodian at gmail dot com

Exact same problem on Centos 6.2 with a custom build PHP 5.3.10. I reverted 
back to 5.3.8 since I need to have PHP errors in the Nginx error.log.


[2012-03-23 15:34:49] hugo at barafranca dot com

Me too, on FreeBSD 7.3 with nginx-1.0.14,1 and php5-5.3.10.


[2012-03-15 06:38:22] prinbra at gmail dot com

in fact, set display_errors to On, we can still view the error message, but the 
message didn't go to nginx error log when display_errors is set to Off.
test confirmed that the same setting works fine on php 5.3.8


[2012-03-07 17:42:13] ben dot lemasurier at gmail dot com

confirmed on php v5.3.10


[2012-03-04 18:19:04] ewgraf at gmail dot com

Add patch for 5.3.10.

It simple, not so right, because I think this functionality need move to 
zlog_ex, 
but it works for me.

If anybody can review it and test, would be nice.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=61045


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61045edit=1

Bug #61463 [Com]: cant import schema when using https soapservice

[markus dot rietzler at rzf dot fin-nrw dot de]

Edit report at https://bugs.php.net/bug.php?id=61463edit=1

 ID: 61463
 Comment by: markus dot rietzler at rzf dot fin-nrw dot de
 Reported by:markus dot rietzler at rzf dot fin-nrw dot de
 Summary:cant import schema when using https soapservice
 Status: Open
 Type:   Bug
 Package:SOAP related
 Operating System:   linux
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

nope, proxy_port makes no difference. i wonder whether it is ok to have a mix 
of https and http in schema. maybe a misconfiguration of the service provider 
for this soap service.
but: it has worked with php 5.3.3 and with 5.3.10 it don't work anymore


Previous Comments:

[2012-03-29 00:54:15] jingshangmingzi at gmail dot com

The proxy_port parameter has to be an integer.
I think you'll have to use 'proxy_port' = 8080


[2012-03-21 12:33:32] markus dot rietzler at rzf dot fin-nrw dot de

Description:

here is my problem: i want to access a soap-service via 
https://connect.example.com/portal/portal?wsdl 

with php 5.3.3 my script worked, with 5.3.10 it does not work anymore.

in the xml returned:

service name=PortalService
port name=PortalPort binding=tns:PortalPortBinding
soap:address location=http://connect.example.com:80/portal/portal/
/port
/service
/definitions

so there is a http and not a https location. is this wrong?
i am not sure, whether this should work in general (using https but with a 
http-location). we use a soapservice from an extern service provider which 
requires us to use https for the calls.

in my php script i used

$client = new SoapClient('https://connect.example.com/portal/portal?wsdl',
array(  'proxy_host' = 'myproxy',
'proxy_port' = '8080',
'trace' = 1,
'exceptions' = 1,
// actual use https-endpoint
'location' = 'https://connect.juris.de/jportal/ws/fvportalnrw'
));


with php 5.3.3 i could create the soapclient and do my requests. the wsdl is 
downloaded and cached in /tmp. with php 5.3.10 i get:

PHP Fatal error:  SOAP-ERROR: Parsing Schema: can't import schema from 
'http://connect.example.com:80/portal/portal?xsd=1' in ./t.php on line 9
PHP Fatal error:  Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing 
Schema: can't import schema from 
'http://connect.example.com:80/portal/portal?xsd=1' in ./t2.php:9

so the schema could not be downloaded! 

what's wrong here? was it a bug in 5.3.3 - and it should not have worked there 
- or is it a bug in 5.3.10 (same for 5.3.8). 

if i used php 5.3.3 to access the service, a wsdl is cached in /tmp and then i 
can call the script with php 5.3.10.




Test script:
---
?php
$client = new SoapClient('https://connect.example.com/portal/portal?wsdl',
array(  'proxy_host' = 'myproxy',
'proxy_port' = '8080',
'trace' = 1,
'exceptions' = 1,
// actual use https-endpoint
'location' = 'https://connect.juris.de/jportal/ws/fvportalnrw'
));
print_r($client);
?

Expected result:

SoapClient Object
(
[_proxy_host] = myproxy
[_proxy_port] = 8080
[trace] = 1
[_soap_version] = 1
[sdl] = Resource id #9
)


Actual result:
--
PHP Fatal error:  SOAP-ERROR: Parsing Schema: can't import schema from 
'http://connect.example.com:80/portal/portal?xsd=1' in ./t.php on line 9
PHP Fatal error:  Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing 
Schema: can't import schema from 
'http://connect.example.com:80/portal/portal?xsd=1' in ./t2.php:9






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61463edit=1

[PHP-BUG] Bug #61551 [NEW]: dynamic linker says libnnz11.so not found

[jm at trash-mail dot com]

From: 
Operating system: linux x64
PHP version:  Irrelevant
Package:  OCI8 related
Bug Type: Bug
Bug description:dynamic linker says libnnz11.so not found

Description:

Installed Oracle instantclient from RPM:

/usr/lib/oracle/11.2/client64/lib looks like this:

libclntsh.so
libclntsh.so.11.1
libnnz11.so
libocci.so
libocci.so.11.1
libociei.so
libocijdbc11.so
ojdbc5.jar
ojdbc6.jar
ottclasses.zip
xstreams.jar

configuring and compiling oci8 results in 
# ldd modules/oci8.so
...
libnnz11.so = not found
...

even though libnnz11.so is present in the above listing.

What helps is this:

--- config.m4.old   2012-03-29 10:31:58.0 +0200
+++ config.m4   2012-03-29 10:31:43.0 +0200
@@ -321,6 +321,7 @@

 AC_OCI8IC_VERSION($PHP_OCI8_INSTANT_CLIENT)
 PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD)
+PHP_ADD_LIBRARY(nnz11, 1, OCI8_SHARED_LIBADD)
 PHP_ADD_LIBPATH($PHP_OCI8_INSTANT_CLIENT, OCI8_SHARED_LIBADD)

 AC_DEFINE(HAVE_OCI_INSTANT_CLIENT,1,[ ])

-- # ldd modules/oci8.so
linux-vdso.so.1 =  (0x7fff9efc5000)
libclntsh.so.11.1 =
/usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 (0x7f2b4f24c000)
libnnz11.so = /usr/lib/oracle/11.2/client64/lib/libnnz11.so
(0x7f2b4ee7f000)
libc.so.6 = /lib64/libc.so.6 (0x7f2b4eaef000)
libdl.so.2 = /lib64/libdl.so.2 (0x7f2b4e8eb000)
libm.so.6 = /lib64/libm.so.6 (0x7f2b4e694000)
libpthread.so.0 = /lib64/libpthread.so.0 (0x7f2b4e477000)
libnsl.so.1 = /lib64/libnsl.so.1 (0x7f2b4e25f000)
libaio.so.1 = /lib64/libaio.so.1 (0x7f2b4e05c000)
/lib64/ld-linux-x86-64.so.2 (0x7f2b51d11000)

\o/


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

Req #26432 [Opn-Wfx]: using use_trans_sid with two sessions is no-go

[yohgaki]

Edit report at https://bugs.php.net/bug.php?id=26432edit=1

 ID: 26432
 Updated by: yohg...@php.net
 Reported by:kenneths at stud dot cs dot uit dot no
 Summary:using use_trans_sid with two sessions is no-go
-Status: Open
+Status: Wont fix
 Type:   Feature/Change Request
 Package:Session related
 Operating System:   linux
 PHP Version:4.3.2
 Block user comment: N
 Private report: N



Previous Comments:

[2003-11-27 04:43:33] kenneths at stud dot cs dot uit dot no

Hmm, well its a fine line between a bug and a feature request in this case. It 
does brake a site if youre not aware of it. It broke mine and I wasnt aware of 
it because it only happened in the forum.


[2003-11-27 04:24:42] kenneths at stud dot cs dot uit dot no

Description:

If you enable session.using use_trans_sid, and have two different sessions 
(different name), like if you have a site session and a phpbb session, the url 
gets invalid.

PHP does not recognize that there are two sessions to append to the url and 
prefix both of them with ?. This makes the url like this: 
index.php?sess_name=xxx?=sess_name2=xxx. This is ofcourse invalid and php 
doesnt recognize either of those sessions.

Reproduce code:
---
above

Expected result:

Recognize multiple sessions and put the correct argument delimiter inbetweeen 
(amp; or so)

Actual result:
--
...






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=26432edit=1

Bug #49326 [Opn-Fbk]: output_buffering can break unsecure transparent automatic SID adding

[yohgaki]

Edit report at https://bugs.php.net/bug.php?id=49326edit=1

 ID: 49326
 Updated by: yohg...@php.net
 Reported by:k dot triendl at m-box dot at
 Summary:output_buffering can break unsecure transparent
 automatic SID adding
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Session related
 Operating System:   windows xp sp3
 PHP Version:5.2.10
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

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

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




Previous Comments:

[2009-09-18 14:07:37] k dot triendl at m-box dot at

Well, this is no satisfactory answer, I feel.

There are situations where cookies can't be used; cookies are bound to a path. 
If one sets them for the root '/' then the session information is valid for the 
whole path. No other session can be created without destroying the old one. 
Users wouldn't be able to login into different databases at the same time or 
with different user credentials.
Also, I don't see so much the security risk with SIDs in URLs as information 
via our application is read-only to the public and will be changed only in 
intranets. Additionally, sessions are time-limited.

No matter the security risks it should be up to the application to decide 
whether it matters or not. Cookies have their own flaws.
PHP offers the feature to append the SID automatically and therefore I'm urging 
that this bug gets fixed (php 5.3.x might have the same bug), otherwise the 
feature should be deprecated.

Adding the SID manually is a tedious and error-prone work.


[2009-09-16 08:02:00] j...@php.net

You should really add the SID manually anyway, using 
session.use_trans_sid should be avoided always when your site is 
anything else but some intranet. (might be fixed, propably won't be 
ever)


[2009-09-15 14:41:46] k dot triendl at m-box dot at

Reproduce code:
---
I've prepared a test case without external requirements:
http://www.m-box.at/phpbug_49326/phpbug_49326.php.txt
http://www.m-box.at/phpbug_49326/phpbug_49326.html.inc

phpbug_49326.php.txt is the php script, remove the .txt extension;
phpbug_49326.html.inc is the file included by the php script.
Be sure to set 'output_buffering' to 4096 in the php.ini or the .htaccess file.

Expected result:

correct link to 'Impressum':
a 
href=imprint.m-box?setmgrname=mboxobjamp;fcardid=4amp;reffcardid=3amp;PHPSESSID=bouq4a3sddqfeqp4hrobr4bur0Impressum/a

Actual result:
--
incorrect link to 'Impressum':
a 
href=imprint.m-box?setmgrname=mboxobjamp;fcardid=4amp;reffcardid=3?PHPSESSID=bouq4a3sddqfeqp4hrobr4bur0Impressum/a


[2009-09-04 11:41:36] j...@php.net

Please provide a proper test case which does not have any external requirements.


[2009-08-21 21:46:10] k dot triendl at m-box dot at

Description:

If output_buffering is set to 4096 and session.use_trans_sid is used, the 
output may be broken:

a href=index.php?PHPSESSID=fa562d5bb14df890e6db68627ea76442


I've found that the same bug was reported in 2003 for php-4.3.8 (which was 
fixed back then) and filed under #29333: http://bugs.php.net/bug.php?id=29333.
The problem is reproducable with the code that Alan has still on his website.

I hope it's ok to refer to bug #29333.

Reproduce code:
---
As described in #29333

Expected result:

As described in #29333

Actual result:
--
As described in #29333






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=49326edit=1

Req #41082 [Opn-Fbk]: url_rewriter.tags are wrong

[yohgaki]

Edit report at https://bugs.php.net/bug.php?id=41082edit=1

 ID: 41082
 Updated by: yohg...@php.net
 Reported by:der-coole-carl at gmx dot net
 Summary:url_rewriter.tags are wrong
-Status: Open
+Status: Feedback
 Type:   Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
 PHP Version:5.2.1
 Block user comment: N
 Private report: N

 New Comment:

Do you still want this feature?


Previous Comments:

[2007-04-14 00:21:27] der-coole-carl at gmx dot net

Description:

it would be good if you can change
url_rewriter.tags   from 
a=href,area=href,frame=src,input=src,form=,fieldset=

to
a=href,area=href,frame=src,input=src,form=action,fieldset=

if i use session_use_trans_sid it doesn't put the SID in my forms.. that's 
maybe you forgot the form=_action_

i don't know if it matters:
i use: ob_start(ob_gzhandler); to compress my code.. maybe this is relevant

Reproduce code:
---
?php
ini_set('session.use_trans_sid', 1);
?
form action=test.php method=post
input type=submit
/form


in this example the user have to deactivate cookies


Expected result:

i expect that the target url will be: test.php?phpsessid=1234

Actual result:
--
actual the target url is test.php






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=41082edit=1

Req #31369 [Asn-Wfx]: session_destroy() and/or session_write_close() should unregister URL handler

[yohgaki]

Edit report at https://bugs.php.net/bug.php?id=31369edit=1

 ID: 31369
 Updated by: yohg...@php.net
 Reported by:baafie at planet dot nl
 Summary:session_destroy() and/or session_write_close()
 should unregister URL handler
-Status: Assigned
+Status: Wont fix
 Type:   Feature/Change Request
 Package:Session related
 Operating System:   Linux Red hat 9 -2.4.20
 PHP Version:4.3.10
 Assigned To:sas
 Block user comment: N
 Private report: N

 New Comment:

We are sorry, but we can not support PHP 4 related problems anymore.




Previous Comments:

[2005-01-17 18:38:51] sni...@php.net

Assigning to the author of ext/session who can explain this / change it if he 
wishes.



[2005-01-17 02:38:09] destes at ix dot netcom dot com

This is a potential security issue, since I read the manual as describing the 
behavior this bug expects (whereas the experienced behavior is very different). 
 The ability to keep session data private (especially SIDs) is very important 
and I don't think the developers intended trans-sid to extend beyond the use of 
sessions in a script (i.e., beyond where the session has been destroyed).

On a sidenote, you can avoid having trans-sid append your links by using 
absolute (rather than relative) URLs.

I recommend that the original submitter changes this back from Bogus, 
absolutely zero explanation was given as to why this isn't a bug, and I 
(personally) happen to disagree.

-Steve


[2004-12-31 16:33:49] baafie at planet dot nl

Description:

According to the php manual, session_start() will register internal output 
handler for URL rewriting when trans-sid is enabled. Should session_destroy() 
and/or session_write_close() not unregister this handler?

Reproduce code:
---
?php

ini_set ('session.use_trans_sid','1');
session_start();

echo 'a href=index.phpa page/a\n';
session_destroy();
echo 'a href=index.phpa page/a';

?

Expected result:

Only the link that was printed before session_destroy() should contain the 
session ID:

a href=index.php?PHPSESSID=2382309823823...a page/a
a href=index.phpa page/a

Actual result:
--
Both URLs contain the session ID;

a href=index.php?PHPSESSID=2382309823823...a page/a
a href=index.php?PHPSESSID=2382309823823...a page/a






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=31369edit=1

Req #41082 [Com]: url_rewriter.tags are wrong

[der-coole-carl at gmx dot net]

Edit report at https://bugs.php.net/bug.php?id=41082edit=1

 ID: 41082
 Comment by: der-coole-carl at gmx dot net
 Reported by:der-coole-carl at gmx dot net
 Summary:url_rewriter.tags are wrong
 Status: Feedback
 Type:   Feature/Change Request
 Package:*General Issues
 PHP Version:5.2.1
 Block user comment: N
 Private report: N

 New Comment:

No, today I think this whole feature is bad.


Previous Comments:

[2012-03-29 09:27:53] yohg...@php.net

Do you still want this feature?


[2007-04-14 00:21:27] der-coole-carl at gmx dot net

Description:

it would be good if you can change
url_rewriter.tags   from 
a=href,area=href,frame=src,input=src,form=,fieldset=

to
a=href,area=href,frame=src,input=src,form=action,fieldset=

if i use session_use_trans_sid it doesn't put the SID in my forms.. that's 
maybe you forgot the form=_action_

i don't know if it matters:
i use: ob_start(ob_gzhandler); to compress my code.. maybe this is relevant

Reproduce code:
---
?php
ini_set('session.use_trans_sid', 1);
?
form action=test.php method=post
input type=submit
/form


in this example the user have to deactivate cookies


Expected result:

i expect that the target url will be: test.php?phpsessid=1234

Actual result:
--
actual the target url is test.php






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=41082edit=1

Bug #61045 [Com]: fpm don't send error log to fastcgi clients(nginx)

[kustodian at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=61045edit=1

 ID: 61045
 Comment by: kustodian at gmail dot com
 Reported by:lxlight at gmail dot com
 Summary:fpm don't send error log to fastcgi clients(nginx)
 Status: Assigned
 Type:   Bug
 Package:FPM related
 Operating System:   Linux
 PHP Version:5.3.10
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

I wouldn't mind that change, but setting catch_workers_output = yes doesn't 
work for me with PHP 5.3.10 and Nginx 1.0.14 on Centos 6.2.


Previous Comments:

[2012-03-29 08:10:55] bitmand at gmail dot com

Same here on 5.3.9 and .10 on apache. Errors used to go to apache error log, 
but 
after 5.3.9 nothing gets logged.

I wonder if the change is actually by design, according to the php-fpm 
documentation for catch_workers_output is states that If not set, stdout and 
stderr will be redirected to /dev/null according to FastCGI specs.

But it would definitely be great with and option to throw errors to stderr 
again.


[2012-03-28 14:45:25] kustodian at gmail dot com

Exact same problem on Centos 6.2 with a custom build PHP 5.3.10. I reverted 
back to 5.3.8 since I need to have PHP errors in the Nginx error.log.


[2012-03-23 15:34:49] hugo at barafranca dot com

Me too, on FreeBSD 7.3 with nginx-1.0.14,1 and php5-5.3.10.


[2012-03-15 06:38:22] prinbra at gmail dot com

in fact, set display_errors to On, we can still view the error message, but the 
message didn't go to nginx error log when display_errors is set to Off.
test confirmed that the same setting works fine on php 5.3.8


[2012-03-07 17:42:13] ben dot lemasurier at gmail dot com

confirmed on php v5.3.10




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=61045


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61045edit=1

Req #47570 [Opn-Asn]: libpq's PG_VERSION should be exported to userland

[yohgaki]

Edit report at https://bugs.php.net/bug.php?id=47570edit=1

 ID: 47570
 Updated by: yohg...@php.net
 Reported by:php at benjaminschulz dot com
 Summary:libpq's PG_VERSION should be exported to userland
-Status: Open
+Status: Assigned
 Type:   Feature/Change Request
 Package:PostgreSQL related
 Operating System:   any
 PHP Version:5.3.0beta1
-Assigned To:
+Assigned To:yohgaki
 Block user comment: N
 Private report: N



Previous Comments:

[2009-03-05 10:27:30] php at benjaminschulz dot com

Description:

Without a valid connection there is no way to check for the libpq-
Version ext/pgsql was built against because PG_VERSION is not exported 
to userland code. A PGSQL_LIBPQ_VERSION or something would be nice. I 
know that PG_VERSION is inserted as client into the array from 
pg_version() but that would require an established connection. 







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=47570edit=1

Bug #60187 [Opn-Asn]: pgsql module returns strings from SELECT queries for each unempty field

[yohgaki]

Edit report at https://bugs.php.net/bug.php?id=60187edit=1

 ID: 60187
 Updated by: yohg...@php.net
 Reported by:gatekeeper dot mail at gmail dot com
 Summary:pgsql module returns strings from SELECT queries for
 each unempty field
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:PostgreSQL related
 Operating System:   SuSE Linux 11 SP1
 PHP Version:5.3.8
-Assigned To:
+Assigned To:yohgaki
 Block user comment: N
 Private report: N



Previous Comments:

[2012-01-27 03:35:46] morphunreal at gmail dot com

same patch that I have created for bug #47051 (except that issue was from 2009).

for backwards compatibility i have had to add the options 
pgsql.convert_boolean_type  pgsql.convert_integer_type


to test / use-
- get current source for php/ext/pgsql
- apply patch
- phpize
- ./configure --with-pgsql=/path/to/pgsql/c-api
- make
- stop web server
- copy modules/pgsql.so over existing one
- add to /etc/php.d/pgsql.conf
pgsql.convert_boolean_type = 1
pgsql.convert_integer_type = 1
- start web server


[2011-11-01 10:47:13] gatekeeper dot mail at gmail dot com

Description:

pgsql modules returns all non-null values as String type data instead of 
corresponding php datatype when applicable. PDO is not affected though. 

Test script:
---
# CREATE TABLE netusers (id bigserial NOT NULL, firstname character varying NOT 
NULL, middlename character varying NOT NULL DEFAULT ''::character varying, 
lastname character varying NOT NULL DEFAULT ''::character varying, company_id 
integer NOT NULL DEFAULT 0, department_id integer NOT NULL DEFAULT 0, 
connect_date date NOT NULL DEFAULT now(), disconnect_date date, login character 
varying NOT NULL DEFAULT ''::character varying, password character varying NOT 
NULL DEFAULT ''::character varying, email text NOT NULL DEFAULT ''::character 
varying, email_alias text NOT NULL DEFAULT ''::character varying, computer 
character varying NOT NULL DEFAULT ''::character varying, ipaddr bigint NOT 
NULL DEFAULT 0, macaddr bigint NOT NULL DEFAULT 0, inet_date date, phone_local 
text NOT NULL DEFAULT ''::text, phone_global text NOT NULL DEFAULT ''::text, 
comment text, cable_id bigint NOT NULL DEFAULT 0, CONSTRAINT netusers_pk 
PRIMARY KEY (id )) WITH (OIDS=FALSE);
# Put a row into that table with some random (but according to columns' 
datatype) data
?php
$dsn = 'pgsql:host=host;port=5432;dbname=testdb';
$username = 'test';
$password = 'testpw';

$conn = new PDO($dsn, $username, $password);
$stmt = $conn-query('select * from netusers');
$o = $stmt-fetchObject();
//This gets appropriate datatypes for all non-null fields (int for int, string 
for string etc... Except (hell yeah!) arrays)
var_dump($o);
//*
$conn2 = pg_connect(host=host port=5432 dbname=testdb user=test 
password=testpw);
$stmt2 = pg_query($conn2, SELECT * FROM netusers);
$o2 = pg_fetch_object($stmt2);
//This gets an object with every non-null property having datatype string
var_dump($o2);


Expected result:

# This is the PDO output part of the test script
object(stdClass)#3 (20) {
  [id]=
  int(0)
  [firstname]=
  string(3) asd
  [middlename]=
  string(7) dasfsdf
  [lastname]=
  string(8) sdafdsdf
  [company_id]=
  int(0)
  [department_id]=
  int(0)
  [connect_date]=
  string(10) 2011-10-28
  [disconnect_date]=
  NULL
  [login]=
  string(6) asfdfg
  [password]=
  string(6) dfsdfg
  [email]=
  string(22) cvbcvb...@xcvxcvxcv.as
  [email_alias]=
  string(0) 
  [computer]=
  string(5) sdasd
  [ipaddr]=
  int(0)
  [macaddr]=
  int(0)
  [inet_date]=
  NULL
  [phone_local]=
  string(6) 234234
  [phone_global]=
  string(0) 
  [comment]=
  string(14) svsdfgsdfgsdfg
  [cable_id]=
  int(0)
}


Actual result:
--
# This is the PGSQL output part of the test script
object(stdClass)#4 (20) {
  [id]=
  string(1) 0
  [firstname]=
  string(3) asd
  [middlename]=
  string(7) dasfsdf
  [lastname]=
  string(8) sdafdsdf
  [company_id]=
  string(1) 0
  [department_id]=
  string(1) 0
  [connect_date]=
  string(10) 2011-10-28
  [disconnect_date]=
  NULL
  [login]=
  string(6) asfdfg
  [password]=
  string(6) dfsdfg
  [email]=
  string(22) cvbcvb...@xcvxcvxcv.as
  [email_alias]=
  string(0) 
  [computer]=
  string(5) sdasd
  [ipaddr]=
  string(1) 0
  [macaddr]=
  string(1) 0
  [inet_date]=
  NULL
  [phone_local]=
  string(6) 234234
  [phone_global]=
  string(0) 
  [comment]=
  string(14) svsdfgsdfgsdfg
  [cable_id]=
  string(1) 0
}







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60187edit=1

Req #47051 [Opn-Asn]: pg_fetch_object does not convert to literal PHP booleans

[yohgaki]

Edit report at https://bugs.php.net/bug.php?id=47051edit=1

 ID: 47051
 Updated by: yohg...@php.net
 Reported by:germ dot van dot eck at gmail dot com
 Summary:pg_fetch_object does not convert to literal PHP
 booleans
-Status: Open
+Status: Assigned
 Type:   Feature/Change Request
 Package:PostgreSQL related
 Operating System:   Linux, Ubuntu 8.04
 PHP Version:5.2.8
-Assigned To:
+Assigned To:yohgaki
 Block user comment: N
 Private report: N



Previous Comments:

[2012-01-26 13:17:45] morphunreal at gmail dot com

I have created  submitted a patch that allows pgsql to return booleans and 
integers for all fetches.

to test / use-
- get current source for php/ext/pgsql
- apply patch
- phpize
- ./configure --with-pgsql=/path/to/pgsql/c-api
- make
- stop web server
- copy modules/pgsql.so over existing one
- add to /etc/php.d/pgsql.conf
pgsql.convert_boolean_type = 1
pgsql.convert_integer_type = 1
- start web server


[2009-01-11 01:05:09] fel...@php.net

This isn't a bug, it's only as pgsql works.

Moved to Feature/Change request.


[2009-01-09 13:30:24] germ dot van dot eck at gmail dot com

I did not complete my sentence...
This causes that postgresql.
should be
This causes that postgresql's booleans are not very usable in PHP.


[2009-01-09 13:24:51] germ dot van dot eck at gmail dot com

Description:

Postgresql booleans are internally stored as either 'f' or 't' (False or True).
On retrieval using pg_fetch_object, they are simply retrieved as PHP strings, 
rather than either 0 or 1, or even better, false or true.
This causes that postgresql.
I am not sure, but I think in the data returned by the server, there is 
metadata explaining the field types and so they could be automatically 
converted to PHP bools.
This is from a bugreport and related forum topic that was made for the 
CodeIgniter framework.
Bugreport (slighly unrelated CI bug, but this issue was discussed in the 
comments):
http://codeigniter.com/bug_tracker/bug/6303/
Forum topic:
http://codeigniter.com/forums/viewthread/101001/


Reproduce code:
---
?php
$conn_string = host=testserver dbname=testdb user=foo password=bar;
$dbconn = pg_connect($conn_string);
pg_query('CREATE TABLE test(test boolean)');
pg_query('INSERT INTO test(test) VALUES(TRUE)');
$res = pg_query('SELECT * FROM test');
$obj = pg_fetch_object($res);
echo \n.$obj-test.\n;
pg_query('DROP TABLE test');
?


Expected result:

1

Actual result:
--
t






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=47051edit=1

Req #42398 [Opn-Asn]: pg_(p)connect produces uninformative error messages

[yohgaki]

Edit report at https://bugs.php.net/bug.php?id=42398edit=1

 ID: 42398
 Updated by: yohg...@php.net
 Reported by:webmaster at touchingvirus dot net
 Summary:pg_(p)connect produces uninformative error messages
-Status: Open
+Status: Assigned
 Type:   Feature/Change Request
 Package:PostgreSQL related
 Operating System:   Windows
 PHP Version:5.2.3
-Assigned To:
+Assigned To:yohgaki
 Block user comment: N
 Private report: N



Previous Comments:

[2007-08-23 13:45:39] webmaster at touchingvirus dot net

Description:

When connecting to a pgSQL server (I use 8.2) with a wrong username, password 
or port in the connection string, the error given is really uninformative to 
the user and actually suggests a problem with the postgreSQL server:

Unable to connect to PostgreSQL server: server closed the connection 
unexpectedly This probably means the server terminated abnormally before or 
while processing the request.

The server didn't terminate  the connection was refused/aborted

Expected result:

To be honest, I expected an error that was similar to that of mySQL - though I 
know that is because mySQL actually produces good error messages =)

e.g.

Access denied for: root@localhost (Using Password: YES)


The psql binary errors with the expect errors like:

psql: FATAL:  password authentication failed for user root









-- 
Edit this bug report at https://bugs.php.net/bug.php?id=42398edit=1

Bug #50524 [Com]: proc_open is using a wrong initial working dir

[axel at zehden dot net]

Edit report at https://bugs.php.net/bug.php?id=50524edit=1

 ID: 50524
 Comment by: axel at zehden dot net
 Reported by:carsten_sttgt at gmx dot de
 Summary:proc_open is using a wrong initial working dir
 Status: Closed
 Type:   Bug
 Package:Program Execution
 Operating System:   win32 only
 PHP Version:5.3.1
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

I have exactly this buggy behavior in my actual PHP 5.3.10 on Ubuntu.

With cwd parameter NULL, I get a wrong working dir.
This did not happen in the PHP 5.2, I used before.


Previous Comments:

[2010-09-08 10:35:16] paj...@php.net

This bug has been fixed in SVN.

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




[2010-09-08 10:34:59] paj...@php.net

Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=303163
Log: - Fix #50524, proc_open should respect cwd as it does on other platforms


[2009-12-23 15:16:41] paj...@php.net

Agreed, it should behave the same.


[2009-12-23 14:22:30] carsten_sttgt at gmx dot de

 This is expected,

No, a different behavior on Linux/BSD/OS X and Windows is not expected.

(and also between proc_open and the other program execution functions)


 as also noted in the manual on the proc_open() page for the $cwd parameter.

Well,
 or NULL  if you want to use the default value
 (the working dir of the current PHP process)

If you really test the script yourself, you can see that getcwd() is returning 
the correct working dir of the current PHP process, but proc_open is using 
something else.


 then on Windows atleast

This have nothing to do with Windows. Only a wrong usage of CreateProcess from 
the PHP developers in this case (lpCurrentDirectory is not set to the value of 
getcwd).


[2009-12-23 13:56:25] ka...@php.net

This is expected, as also noted in the manual on the proc_open() page for the 
$cwd parameter. If NULL is supplied to $cwd, then on Windows atleast the 
directory where the PHP script interpreter is located is the cwd.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=50524


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=50524edit=1

Bug #51946 [Opn-Fbk]: Segmentation Faults on postgres use in session handler.

[yohgaki]

Edit report at https://bugs.php.net/bug.php?id=51946edit=1

 ID: 51946
 Updated by: yohg...@php.net
 Reported by:justin_burger at adp dot com
 Summary:Segmentation Faults on postgres  use in session
 handler.
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:PostgreSQL related
 Operating System:   CentOS release 5.4 (Final)
 PHP Version:5.2.13
 Block user comment: N
 Private report: N

 New Comment:

Do you still have this issue with 5.3?

Could you paste your session save handler code somehere? (e.g. gist.github.com )


Previous Comments:

[2010-08-02 17:21:21] miroslav dot zacek at skype dot net

Forget my comment please,it is a different problem.


[2010-07-23 14:06:37] miroslav dot zacek at skype dot net

I think it is the same bug as #52389 I've reported recently (with patch).


[2010-06-03 19:50:24] justin_burger at adp dot com

This now seems isolated to the session handler use of postgres.


[2010-06-03 19:49:09] justin_burger at adp dot com

I've done more research and confirmed that I can ONLY reproduce this when using 
postgres as part of session management. executing the exact same SQL outside of 
a 
session handler does not cause the fault.


[2010-06-02 23:22:56] justin_burger at adp dot com

PG Version =8.3.9 

Your right, it looks like it's not happening 100% of the time during the 
pg_connect. I created a somewhat simple script which causes the fault on every 
other request. I am able to reproduce this on two different servers. both 
running 5.2.13 with the 8.3.9 version of postgres.

Code to reproduce: http://pastebin.com/nfNJeyMw

Running this script gives me the following backtrace:
Core was generated by `/opt/adp/httpd/bin/httpd -X'.
Program terminated with signal 11, Segmentation fault.
#0  0x2ac7d6ee1c20 in zend_mm_search_large_block (heap=0x151bdd50, size=24) 
at /usr/src/debug/php-5.2.13/Zend/zend_alloc.c:1753
1753if (ZEND_MM_FREE_BLOCK_SIZE(p)  
ZEND_MM_FREE_BLOCK_SIZE(best_fit)) {
(gdb) bt
#0  0x2ac7d6ee1c20 in zend_mm_search_large_block (heap=0x151bdd50, size=24) 
at /usr/src/debug/php-5.2.13/Zend/zend_alloc.c:1753
#1  _zend_mm_alloc_int (heap=0x151bdd50, size=24) at 
/usr/src/debug/php-5.2.13/Zend/zend_alloc.c:1812
#2  0x2ac7dcdd8e80 in zif_pg_query (ht=value optimized out, 
return_value=0x15671350, return_value_ptr=value optimized out,
this_ptr=value optimized out, return_value_used=value optimized out) at 
/usr/src/debug/php-5.2.13/ext/pgsql/pgsql.c:1184
#3  0x2ac7d6f1d582 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x7fff68c97af0) at 
/usr/src/debug/php-5.2.13/Zend/zend_vm_execute.h:200
#4  0x2ac7d6f1c73c in execute (op_array=0x155df890) at 
/usr/src/debug/php-5.2.13/Zend/zend_vm_execute.h:92
#5  0x2ac7d6ef1299 in zend_call_function (fci=0x7fff68c97cd0, 
fci_cache=value optimized out) at 
/usr/src/debug/php-5.2.13/Zend/zend_execute_API.c:1039
#6  0x2ac7d6ef2386 in call_user_function_ex (function_table=value 
optimized out, object_pp=value optimized out, 
function_name=0x7274732061206e69,
retval_ptr_ptr=0x1541dda0, param_count=1, params=0x0, no_separation=1, 
symbol_table=0x0) at /usr/src/debug/php-5.2.13/Zend/zend_execute_API.c:640
#7  0x2ac7d6ef2406 in call_user_function (function_table=0x151bd640, 
object_pp=0x0, function_name=0x15421298, retval_ptr=0x15642688, param_count=2,
params=0x7fff68c97dc0) at 
/usr/src/debug/php-5.2.13/Zend/zend_execute_API.c:613
#8  0x2ac7d6da5e25 in ps_call_handler (func=0x15421298, argc=2, 
argv=0x7fff68c97dc0) at /usr/src/debug/php-5.2.13/ext/session/mod_user.c:53
#9  0x2ac7d6da6099 in ps_write_user (mod_data=value optimized out, 
key=0x1560c698 6c4u9vvv7b2hb5jh1bgg3916m6,
val=0x156700a8 
CONNECTION_ID|s:2:\QA\;USER_OBJECT|s:3667:\O:4:\user\:22:{s:17:\, 
vallen=3712)
at /usr/src/debug/php-5.2.13/ext/session/mod_user.c:141
#10 0x2ac7d6da2022 in php_session_save_current_state () at 
/usr/src/debug/php-5.2.13/ext/session/session.c:550
#11 php_session_flush () at /usr/src/debug/php-5.2.13/ext/session/session.c:1407
#12 0x2ac7d6da22e9 in zm_deactivate_session (type=354147664, 
module_number=5) at /usr/src/debug/php-5.2.13/ext/session/session.c:2015
#13 0x2ac7d6efddfc in module_registry_cleanup (module=value optimized 
out) at /usr/src/debug/php-5.2.13/Zend/zend_API.c:1976
#14 0x2ac7d6f06d84 in zend_hash_reverse_apply (ht=0x2ac7d74abb00, 
apply_func=0x2ac7d6efdde0 module_registry_cleanup)
at /usr/src/debug/php-5.2.13/Zend/zend_hash.c:755
#15 0x2ac7d6efc47d 

Bug #40544 [Opn]: PostgreSQL connection hangs after die()

[yohgaki]

Edit report at https://bugs.php.net/bug.php?id=40544edit=1

 ID: 40544
 Updated by: yohg...@php.net
 Reported by:kees at tweakers dot net
 Summary:PostgreSQL connection hangs after die()
 Status: Open
 Type:   Bug
 Package:PostgreSQL related
 Operating System:   Linux (Debian)
 PHP Version:5.2CVS-2008-10-31
 Block user comment: N
 Private report: N

 New Comment:

Old problem, but I suppose this hasn't changed. 
I prefer to leave this issue as I wrote 5 years ago.

Any comments?


Previous Comments:

[2008-10-31 10:04:07] kees at tweakers dot net

Using the latest snapshots results in the same behaviour; the script hangs and 
the connection stays open.


[2007-04-05 07:48:28] tony2...@php.net

'Rollback on shutdown' is like 'Don't flush buffer before closing file'.
I disagree, you need to commit everything explicitly.
If you didn't commit the transaction, it should be rolled back.



[2007-04-05 01:28:11] yohgaki at ohgaki dot net

 And that's something I would call expected, because rollback on
 shutdown is much safer than commit on shutdown.

As I wrote, under normal condition, current code(commit on shutdown) does make 
more sense than rollback on shutdown because PostgreSQL supports async query.

'Rollback on shutdown' is like 'Don't flush buffer before closing file'. It 
does not acceptable for most people. (And more efficient if it finish pending 
query at shutdown, too. If you are curious, take some simple benchmarks)

However, under shared environment, it is not acceptable to consume all 
connection by COPY FROM SDTIN. It is better to have a way to avoid such action.

There are 2 options:

1) Leave it alone (and make DoS possible under shared environment)

2) Give administrators a option that cancel current and pending async query.

I prefer first option. I'll ask PostgreSQL developer if it's possible to have 
GRANT option for COPY in the future.


[2007-03-09 10:11:12] tony2...@php.net

By calling PQcanel() before clean up resource, all async query which
is not finished yet will be discarded instead of finishing its query. 

And that's something I would call expected, because rollback on shutdown is 
much safer than commit on shutdown.

I'll add new ini option that enables PQcancel() in list_entry_destructor. Any 
comments?

More INI options? No, thanks.


[2007-03-08 04:24:24] yohgaki at ohgaki dot net

I didn't look the backtrace carefully. It stops when PQclear() is called on the 
backtrace, while my PHP 5.2 stopeed at PQgetReuslt(). (Both of them are called 
when request is shutting down)

For at least PHP 5.2, it would be solved by calling PQcanel() when cleaning up 
resource, but with compatibility issue. By calling PQcanel() before clean up 
resource, all async query which is not finished yet will be discarded instead 
of finishing its query. 

I'll add new ini option that enables PQcancel() in list_entry_destructor. Any 
comments?




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=40544


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=40544edit=1

Req #48588 [Opn-Wfx]: pg_query_params doesn't accept ORDER BY parameter

[yohgaki]

Edit report at https://bugs.php.net/bug.php?id=48588edit=1

 ID: 48588
 Updated by: yohg...@php.net
 Reported by:jake_lake at selinc dot com
 Summary:pg_query_params doesn't accept ORDER BY parameter
-Status: Open
+Status: Wont fix
 Type:   Feature/Change Request
 Package:PostgreSQL related
 Operating System:   Ubuntu 8.10
 PHP Version:5.2.9
 Block user comment: N
 Private report: N

 New Comment:

This is not a pgsql modules behavior, but postgresql.
Please ask PostgreSQL project, if you would like change this behavior.


Previous Comments:

[2009-06-24 17:50:38] sjoerd-php at linuxonly dot nl

Thank you for your bug report.

It would be nice if your example worked, but there are some problems about the 
implementation.

In your example query, both the value for $1 and for $2 are properly escaped. 
The strings passed to pg_send_query_params() are quoted and pasted in the 
query. This results in the following query:
SELECT * FROM php_bug WHERE name LIKE '%o%' ORDER BY 
'doesnt_exist_and_should_be_an_sql_error'

Now, in order for the behavior to change as you want, the second parameter, $2, 
should not be escaped. In general, any parameter which is part of an ORDER BY 
clause should not be escaped. However, this means that pg_send_query_params() 
needs to parse the query, just to insert the variables. This is error-prone, 
slow, inconsistent and it may still not satisfy everybody.

So while I acknowledge that it would be nice if it worked like you say, it is 
hard for PHP to know whether your parameter is a string expression or a table 
name.


[2009-06-17 17:00:43] jake_lake at selinc dot com

Description:

In attempting to use the pg_query_params function, it came to my attention that 
trying to use an ORDER BY with a parameter fails.  After searching high and low 
I finally found someone else with the same issue.  It was reported in Bug # 
45101 and I believe falsely written-off as bogus.

In the bug report Alan writes,  I've looked at the pg_trace() output and it 
appears to be doing the right thing. All I can assume is that the parameter is 
being converted to a TRUE for an ORDER BY, and so the database happily accepts 
'ORDER BY 1'.  

This makes sense as then the query should run fine using the 1 as the column 
number and selecting the first column number from the table to order on.

However, the given response by hholz...@php.net does not make any sense.  If 
the expression were to truly be evaluated using a constant string, PGSQL would 
return an error as strings cannot be in the ORDER BY clause, only column 
headers and integers representing the column # wanted to order on.

Therefore, it seems as Alan was more on the right track assuming that for some 
reason the input value is being converted to TRUE or 1.  This must surely be 
faulty behaviour as it essentially is ignoring any parameter assigned to ORDER 
BY and throwing out that part of the clause all together.  

If, however, this is the designed behaviour of this function, it should at 
least be documented so that others do not get caught up debugging for hours 
over this silly thing!


Reproduce code:
---
#!/opt/php/bin/php
?php
/*
create table php_bug (id integer, name varchar(255));
insert into php_bug values (1, 'one');
insert into php_bug values (2, 'two');
insert into php_bug values (3, 'three');
insert into php_bug values (4, 'four');
insert into php_bug values (5, 'five');
 */

$conn = pg_connect('host=localhost dbname=test port=5432 user=web');

$sql = 'SELECT * FROM php_bug WHERE name LIKE $1 ORDER BY $2';
$params = array('%o%', 'doesnt_exist_and_should_be_an_sql_error');

if (! pg_connection_busy($conn)) pg_send_query_params($conn, $sql,
$params);

$res = pg_get_result($conn);

while($row = pg_fetch_assoc($res))
echo {$row['id']} - {$row['name']}\n;

?

Expected result:

If passing as constant string like hholz...@php.net claims:
ERROR:  non-integer constant in ORDER BY

If passing as column header that doesn't exist:
ERROR:  column doesnt_exist_and_should_be_an_sql_error does not exist
LINE 11:   ORDER BY doesnt_exist_and_should_be_an_sql_error;
   ^



Actual result:
--
1 - one
2 - two
4 - four






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=48588edit=1

Bug #60718 [Opn-Asn]: pgsql extension no longer compiles

[yohgaki]

Edit report at https://bugs.php.net/bug.php?id=60718edit=1

 ID: 60718
 Updated by: yohg...@php.net
 Reported by:long at ku dot edu
 Summary:pgsql extension no longer compiles
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:Compile Failure
 Operating System:   Red Hat Enterprise Linux AS rele
 PHP Version:5.3.9
-Assigned To:
+Assigned To:yohgaki
 Block user comment: N
 Private report: N

 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/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

It's an unsupported version, but I'll look into.


Previous Comments:

[2012-03-29 11:07:18] yohg...@ohgaki.net@php.net

Automatic comment on behalf of yohg...@ohgaki.net
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=931831bf75d645bdb9f079793b0224bb4843a7a3
Log: Fixed bug #60718 Complie problem with libpq (PostgreSQL 7.3 or less)


[2012-03-29 11:07:17] yohg...@ohgaki.net@php.net

Automatic comment on behalf of yohg...@ohgaki.net
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=8449e0ca89d77fb20ac3326a0cf574ae2d13676c
Log: Fixed bug #60718 Complie problem with libpq (PostgreSQL 7.3 or less)


[2012-01-11 17:44:34] long at ku dot edu

rh-postgresql-devel-7.3.21-3


[2012-01-11 17:43:23] paj...@php.net

Which version of the libpg do you have?


[2012-01-11 17:32:26] long at ku dot edu

Description:

Somewhere between 5.3.6 and 5.3.9 the pgsql extension lost the ability to be 
compiled on systems using older versions of postgresql.  Here is my configure 
line:

#! /bin/sh
#
# Created by configure

CFLAGS='-O3' \
CXXFLAGS='-O3' \
LIBS='-lssl -lncurses' \
'./configure' \
'--enable-discard-path' \
'--with-openssl=shared' \
'--with-zlib=shared' \
'--enable-bcmath' \
'--with-bz2=shared' \
'--enable-calendar' \
'--with-curl=shared' \
'--enable-dba=shared' \
'--with-gdbm=shared' \
'--with-db4=shared' \
'--enable-dbase' \
'--enable-exif' \
'--enable-ftp' \
'--with-gd=shared' \
'--enable-gd-native-ttf' \
'--enable-gd-jis-conv' \
'--with-gettext=shared' \
'--with-gmp=shared' \
'--with-imap=shared' \
'--with-kerberos' \
'--with-imap-ssl' \
'--with-ldap' \
'--enable-mbstring' \
'--with-mysql=/usr' \
'--with-ncurses=shared' \
'--with-oci8' \
'--with-pspell=shared' \
'--with-readline=shared' \
'--enable-shmop' \
'--with-snmp=shared' \
'--enable-sockets' \
'--with-sqlite=shared' \
'--enable-sysvmsg' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-wddx' \
'--with-freetype-dir' \
'--with-jpeg-dir' \
'--with-xpm-dir' \
'--with-apxs2=/usr/local/apache/bin/apxs' \
'--with-mysqli' \
'--enable-pdo=shared' \
'--with-pdo-mysql=shared' \
'--with-pdo-oci=shared' \
'--with-pdo-sqlite=shared' \
'--with-tidy' \
'--enable-soap=shared' \
'--enable-zip' \
'--with-pgsql' \
$@

When I run make I get:

/bin/sh /home/long/src/php-5.3.9-ap2/libtool --silent --preserve-dup-deps 
--mode=compile gcc  -Iext/pgsql/ -I/home/long/src/php-5.3.9-ap2/ext/pgsql/ 
-DPHP_ATOM_INC -I/home/long/src/php-5.3.9-ap2/include 
-I/home/long/src/php-5.3.9-ap2/main -I/home/long/src/php-5.3.9-ap2 
-I/home/long/src/php-5.3.9-ap2/ext/date/lib 
-I/home/long/src/php-5.3.9-ap2/ext/ereg/regex -I/usr/local/include/libxml2 
-I/usr/kerberos/include -I/usr/X11R6/include -I/usr/include/freetype2 
-I/usr/include/imap -I/home/long/src/php-5.3.9-ap2/ext/mbstring/oniguruma 
-I/home/long/src/php-5.3.9-ap2/ext/mbstring/libmbfl 
-I/home/long/src/php-5.3.9-ap2/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql 
-I/apps/oracle/OraHome1/rdbms/public -I/apps/oracle/OraHome1/rdbms/demo 
-I/home/long/src/php-5.3.9-ap2/ext/sqlite3/libsqlite -I/usr/include/pspell 
-I/usr/local/include -I/home/long/src/php-5.3.9-ap2/TSRM 
-I/home/long/src/php-5.3.9-ap2/Zend-I/usr/include -O3  -prefer-non-pic -c 
/home/long/src/php-5.3.9-ap2/ext/pgsql/pgsql.c -o ext/pgsql/pgsql.lo 
/home/long/src/php-5.3.9-ap2/ext/pgsql/pgsql.c: In function `zif_pg_get_notify':
/home/long/src/php-5.3.9-ap2/ext/pgsql/pgsql.c:4810: structure has no member 
named `extra'
/home/long/src/php-5.3.9-ap2/ext/pgsql/pgsql.c:4821: structure has no member 
named `extra'
make: *** [ext/pgsql/pgsql.lo] Error 1
[long@wbtstap php-5.3.9-ap2]$ 


Test script:
---
n/a


Expected result:

pgsql extension should still compile


Actual result:
--
does not compile

Bug #61551 [Opn-Asn]: dynamic linker says libnnz11.so not found

[johannes]

Edit report at https://bugs.php.net/bug.php?id=61551edit=1

 ID: 61551
 Updated by: johan...@php.net
 Reported by:jm at trash-mail dot com
 Summary:dynamic linker says libnnz11.so not found
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:OCI8 related
 Operating System:   linux x64
 PHP Version:Irrelevant
-Assigned To:
+Assigned To:sixd
 Block user comment: N
 Private report: N



Previous Comments:

[2012-03-29 09:04:00] jm at trash-mail dot com

Description:

Installed Oracle instantclient from RPM:

/usr/lib/oracle/11.2/client64/lib looks like this:

libclntsh.so
libclntsh.so.11.1
libnnz11.so
libocci.so
libocci.so.11.1
libociei.so
libocijdbc11.so
ojdbc5.jar
ojdbc6.jar
ottclasses.zip
xstreams.jar

configuring and compiling oci8 results in 
# ldd modules/oci8.so
...
libnnz11.so = not found
...

even though libnnz11.so is present in the above listing.

What helps is this:

--- config.m4.old   2012-03-29 10:31:58.0 +0200
+++ config.m4   2012-03-29 10:31:43.0 +0200
@@ -321,6 +321,7 @@

 AC_OCI8IC_VERSION($PHP_OCI8_INSTANT_CLIENT)
 PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD)
+PHP_ADD_LIBRARY(nnz11, 1, OCI8_SHARED_LIBADD)
 PHP_ADD_LIBPATH($PHP_OCI8_INSTANT_CLIENT, OCI8_SHARED_LIBADD)

 AC_DEFINE(HAVE_OCI_INSTANT_CLIENT,1,[ ])

-- # ldd modules/oci8.so
linux-vdso.so.1 =  (0x7fff9efc5000)
libclntsh.so.11.1 = 
/usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 (0x7f2b4f24c000)
libnnz11.so = /usr/lib/oracle/11.2/client64/lib/libnnz11.so 
(0x7f2b4ee7f000)
libc.so.6 = /lib64/libc.so.6 (0x7f2b4eaef000)
libdl.so.2 = /lib64/libdl.so.2 (0x7f2b4e8eb000)
libm.so.6 = /lib64/libm.so.6 (0x7f2b4e694000)
libpthread.so.0 = /lib64/libpthread.so.0 (0x7f2b4e477000)
libnsl.so.1 = /lib64/libnsl.so.1 (0x7f2b4e25f000)
libaio.so.1 = /lib64/libaio.so.1 (0x7f2b4e05c000)
/lib64/ld-linux-x86-64.so.2 (0x7f2b51d11000)

\o/







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61551edit=1

Bug #61540 [Opn-Nab]: array_diff has problem when in second array is entry with null value

[johannes]

Edit report at https://bugs.php.net/bug.php?id=61540edit=1

 ID: 61540
 Updated by: johan...@php.net
 Reported by:pfraszczak at power dot com dot pl
 Summary:array_diff has problem when in second array is entry
 with null value
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Arrays related
 Operating System:   ubuntu
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 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:

[2012-03-29 04:24:54] reeze dot xia at gmail dot com

Hi pfraszczak:
This is NOT a bug. 
because  == NULL  = TRUE. 

if we change the test script to :

$a = array('street'='not-null-equal-value','number'='n1');
$b = array('street'='b1','number'='n1','test'=null);
var_dump(array_diff($a,$b));

you will get the right result.


[2012-03-28 10:27:18] pfraszczak at power dot com dot pl

Changed package


[2012-03-28 10:23:25] pfraszczak at power dot com dot pl

Description:

I notice that array_diff return empty array when in second array we have entry 
with null value. When i removed entry with test key - everything works fine.

Moreover it seems that null values in $a array don't brake array_diff

Test script:
---
$a = array('street'='','number'='n1');
$b = array('street'='b1','number'='n1','test'=null);
var_dump(array_diff($a,$b));


Expected result:

array(1) {
  [street]=
  string(0) 
}

Actual result:
--
array(0) {
}







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61540edit=1

Bug #54254 [Com]: cal_from_jd returns month = 6 when there is only one Adar

[info at woordengeschrift dot nl]

Edit report at https://bugs.php.net/bug.php?id=54254edit=1

 ID: 54254
 Comment by: info at woordengeschrift dot nl
 Reported by:asphp at dsgml dot com
 Summary:cal_from_jd returns month = 6 when there is only one
 Adar
 Status: Open
 Type:   Bug
 Package:Calendar related
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

In leap years, there is only the unnumbered month of Adar.
Numbered Adars only occur in leap years: Adar_I (the actual leap month),
followed by Adar_II.


Previous Comments:

[2011-03-15 09:53:50] asphp at dsgml dot com

Description:

cal_from_jd() returns 6 for Adar when there is only one Adar, (it should return 
7, since if there is only one Adar it's AdarII).

It also says AdarI, which is wrong (it should be either Adar or at least 
AdarII).

Furthermore the cal_days_in_month() (correctly) only works with month 7, and 
not 6 as returned by cal_from_jd.

Test script:
---
?
print_r(cal_from_jd(2456005, CAL_JEWISH));
echo cal_days_in_month(CAL_JEWISH, 6, 5772) . \n;
echo cal_days_in_month(CAL_JEWISH, 7, 5772) . \n;
?


Expected result:

The month in cal_from_jd should be 7.

The second two lines demonstrate how cal_days_in_month also expects the month 
to be 7.

Actual result:
--
Array
(
[date] = 6/24/5772
[month] = 6
[day] = 24
[year] = 5772
[dow] = 0
[abbrevdayname] = Sun
[dayname] = Sunday
[abbrevmonth] = AdarI
[monthname] = AdarI
)
0
29







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=54254edit=1

Bug #54254 [Com]: cal_from_jd returns month = 6 when there is only one Adar

[info at woordengeschrift dot nl]

Edit report at https://bugs.php.net/bug.php?id=54254edit=1

 ID: 54254
 Comment by: info at woordengeschrift dot nl
 Reported by:asphp at dsgml dot com
 Summary:cal_from_jd returns month = 6 when there is only one
 Adar
 Status: Open
 Type:   Bug
 Package:Calendar related
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

In NON-leap years, there is only the unnumbered month of Adar.


Previous Comments:

[2012-03-29 12:09:41] info at woordengeschrift dot nl

In leap years, there is only the unnumbered month of Adar.
Numbered Adars only occur in leap years: Adar_I (the actual leap month),
followed by Adar_II.


[2011-03-15 09:53:50] asphp at dsgml dot com

Description:

cal_from_jd() returns 6 for Adar when there is only one Adar, (it should return 
7, since if there is only one Adar it's AdarII).

It also says AdarI, which is wrong (it should be either Adar or at least 
AdarII).

Furthermore the cal_days_in_month() (correctly) only works with month 7, and 
not 6 as returned by cal_from_jd.

Test script:
---
?
print_r(cal_from_jd(2456005, CAL_JEWISH));
echo cal_days_in_month(CAL_JEWISH, 6, 5772) . \n;
echo cal_days_in_month(CAL_JEWISH, 7, 5772) . \n;
?


Expected result:

The month in cal_from_jd should be 7.

The second two lines demonstrate how cal_days_in_month also expects the month 
to be 7.

Actual result:
--
Array
(
[date] = 6/24/5772
[month] = 6
[day] = 24
[year] = 5772
[dow] = 0
[abbrevdayname] = Sun
[dayname] = Sunday
[abbrevmonth] = AdarI
[monthname] = AdarI
)
0
29







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=54254edit=1

Bug #61529 [PATCH]: Parsing error

[larue...@php.net]

Edit report at https://bugs.php.net/bug.php?id=61529edit=1

 ID: 61529
 Patch added by: larue...@php.net
 Reported by:asserte at gmail dot com
 Summary:Parsing error
 Status: Verified
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.1RC/5.5.0-dev
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: bug61529.patch
Revision:   1333025364
URL:
https://bugs.php.net/patch-display.php?bug=61529patch=bug61529.patchrevision=1333025364


Previous Comments:

[2012-03-28 08:51:33] yohg...@php.net

Verified.

$ php -r '1  unset($var[a]);'

is enough.

--
[yohgaki@dev php-src]$ ./sapi/cli/php -v
PHP 5.5.0-dev (cli) (built: Mar 28 2012 17:33:51) (DEBUG)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

[yohgaki@dev php-src]$ ./sapi/cli/php -r 'unset($var[a]);'
[yohgaki@dev php-src]$ ./sapi/cli/php -r '1  unset($var[a]);'

Parse error: syntax error, unexpected 'unset' (T_UNSET) in Command line code on 
line 1
--


[2012-03-27 13:49:14] asserte at gmail dot com

Move to SE problems


[2012-03-27 13:45:26] asserte at gmail dot com

Description:

isset()  unset()

PHP Parse error:  syntax error, unexpected 'unset' (T_UNSET), expecting ')' in 
/tmp/isset.php on line 4

Tested on PHP 5.4.0-3 (cli) (built: Mar 22 2012 07:59:57) 


Test script:
---
$ cat /tmp/isset.php
  1 ?php
  2 
  3 $entity = array('id' = 1, 'name' = 'example');
  4 isset( $entity['id'] )  unset( $entity['id'] );

$ php /tmp/isset.php
PHP Parse error:  syntax error, unexpected 'unset' (T_UNSET), expecting ')' in 
/tmp/isset.php on line 3

Expected result:

unset should works.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61529edit=1

Bug #61529 [Com]: Parsing error

[larue...@php.net]

Edit report at https://bugs.php.net/bug.php?id=61529edit=1

 ID: 61529
 Comment by: larue...@php.net
 Reported by:asserte at gmail dot com
 Summary:Parsing error
 Status: Verified
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.1RC/5.5.0-dev
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

Dmitry, could you review my patch for this bug plz?  thanks


Previous Comments:

[2012-03-29 12:49:24] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61529.patch
Revision:   1333025364
URL:
https://bugs.php.net/patch-display.php?bug=61529patch=bug61529.patchrevision=1333025364


[2012-03-28 08:51:33] yohg...@php.net

Verified.

$ php -r '1  unset($var[a]);'

is enough.

--
[yohgaki@dev php-src]$ ./sapi/cli/php -v
PHP 5.5.0-dev (cli) (built: Mar 28 2012 17:33:51) (DEBUG)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

[yohgaki@dev php-src]$ ./sapi/cli/php -r 'unset($var[a]);'
[yohgaki@dev php-src]$ ./sapi/cli/php -r '1  unset($var[a]);'

Parse error: syntax error, unexpected 'unset' (T_UNSET) in Command line code on 
line 1
--


[2012-03-27 13:49:14] asserte at gmail dot com

Move to SE problems


[2012-03-27 13:45:26] asserte at gmail dot com

Description:

isset()  unset()

PHP Parse error:  syntax error, unexpected 'unset' (T_UNSET), expecting ')' in 
/tmp/isset.php on line 4

Tested on PHP 5.4.0-3 (cli) (built: Mar 22 2012 07:59:57) 


Test script:
---
$ cat /tmp/isset.php
  1 ?php
  2 
  3 $entity = array('id' = 1, 'name' = 'example');
  4 isset( $entity['id'] )  unset( $entity['id'] );

$ php /tmp/isset.php
PHP Parse error:  syntax error, unexpected 'unset' (T_UNSET), expecting ')' in 
/tmp/isset.php on line 3

Expected result:

unset should works.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61529edit=1

Bug #61529 [PATCH]: Parsing error

[larue...@php.net]

Edit report at https://bugs.php.net/bug.php?id=61529edit=1

 ID: 61529
 Patch added by: larue...@php.net
 Reported by:asserte at gmail dot com
 Summary:Parsing error
 Status: Verified
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.1RC/5.5.0-dev
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

The following patch has been added/updated:

Patch Name: bug61529.phpt
Revision:   1333025478
URL:
https://bugs.php.net/patch-display.php?bug=61529patch=bug61529.phptrevision=1333025478


Previous Comments:

[2012-03-29 12:49:51] larue...@php.net

Dmitry, could you review my patch for this bug plz?  thanks


[2012-03-29 12:49:24] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61529.patch
Revision:   1333025364
URL:
https://bugs.php.net/patch-display.php?bug=61529patch=bug61529.patchrevision=1333025364


[2012-03-28 08:51:33] yohg...@php.net

Verified.

$ php -r '1  unset($var[a]);'

is enough.

--
[yohgaki@dev php-src]$ ./sapi/cli/php -v
PHP 5.5.0-dev (cli) (built: Mar 28 2012 17:33:51) (DEBUG)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

[yohgaki@dev php-src]$ ./sapi/cli/php -r 'unset($var[a]);'
[yohgaki@dev php-src]$ ./sapi/cli/php -r '1  unset($var[a]);'

Parse error: syntax error, unexpected 'unset' (T_UNSET) in Command line code on 
line 1
--


[2012-03-27 13:49:14] asserte at gmail dot com

Move to SE problems


[2012-03-27 13:45:26] asserte at gmail dot com

Description:

isset()  unset()

PHP Parse error:  syntax error, unexpected 'unset' (T_UNSET), expecting ')' in 
/tmp/isset.php on line 4

Tested on PHP 5.4.0-3 (cli) (built: Mar 22 2012 07:59:57) 


Test script:
---
$ cat /tmp/isset.php
  1 ?php
  2 
  3 $entity = array('id' = 1, 'name' = 'example');
  4 isset( $entity['id'] )  unset( $entity['id'] );

$ php /tmp/isset.php
PHP Parse error:  syntax error, unexpected 'unset' (T_UNSET), expecting ')' in 
/tmp/isset.php on line 3

Expected result:

unset should works.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61529edit=1

Bug #61529 [Ver]: Parsing error

[laruence]

Edit report at https://bugs.php.net/bug.php?id=61529edit=1

 ID: 61529
 Updated by: larue...@php.net
 Reported by:asserte at gmail dot com
 Summary:Parsing error
 Status: Verified
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.1RC/5.5.0-dev
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

oh, the patch is based on trunk.


Previous Comments:

[2012-03-29 12:51:18] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61529.phpt
Revision:   1333025478
URL:
https://bugs.php.net/patch-display.php?bug=61529patch=bug61529.phptrevision=1333025478


[2012-03-29 12:49:51] larue...@php.net

Dmitry, could you review my patch for this bug plz?  thanks


[2012-03-29 12:49:24] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61529.patch
Revision:   1333025364
URL:
https://bugs.php.net/patch-display.php?bug=61529patch=bug61529.patchrevision=1333025364


[2012-03-28 08:51:33] yohg...@php.net

Verified.

$ php -r '1  unset($var[a]);'

is enough.

--
[yohgaki@dev php-src]$ ./sapi/cli/php -v
PHP 5.5.0-dev (cli) (built: Mar 28 2012 17:33:51) (DEBUG)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

[yohgaki@dev php-src]$ ./sapi/cli/php -r 'unset($var[a]);'
[yohgaki@dev php-src]$ ./sapi/cli/php -r '1  unset($var[a]);'

Parse error: syntax error, unexpected 'unset' (T_UNSET) in Command line code on 
line 1
--


[2012-03-27 13:49:14] asserte at gmail dot com

Move to SE problems




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=61529


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61529edit=1

Bug #61529 [Com]: Parsing error

[reeze dot xia at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=61529edit=1

 ID: 61529
 Comment by: reeze dot xia at gmail dot com
 Reported by:asserte at gmail dot com
 Summary:Parsing error
 Status: Verified
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.1RC/5.5.0-dev
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

unset() is like echo These are language constuct, Both of them are not 
expression in PHP, so code like this:

$c = 1  echo 3;

IS NOT VALID script too;

Those language construct are unticked_statement @see 
Zend/zend_language_parser.y.
if,switch, do while and etc they all.

So from now on, This is not a bug.

Maybe we could make unset() a normal expression. I don't know how this decision 
made, maybe we can discuss it in maillist.


Previous Comments:

[2012-03-29 12:53:18] larue...@php.net

oh, the patch is based on trunk.


[2012-03-29 12:51:18] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61529.phpt
Revision:   1333025478
URL:
https://bugs.php.net/patch-display.php?bug=61529patch=bug61529.phptrevision=1333025478


[2012-03-29 12:49:51] larue...@php.net

Dmitry, could you review my patch for this bug plz?  thanks


[2012-03-29 12:49:24] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61529.patch
Revision:   1333025364
URL:
https://bugs.php.net/patch-display.php?bug=61529patch=bug61529.patchrevision=1333025364


[2012-03-28 08:51:33] yohg...@php.net

Verified.

$ php -r '1  unset($var[a]);'

is enough.

--
[yohgaki@dev php-src]$ ./sapi/cli/php -v
PHP 5.5.0-dev (cli) (built: Mar 28 2012 17:33:51) (DEBUG)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

[yohgaki@dev php-src]$ ./sapi/cli/php -r 'unset($var[a]);'
[yohgaki@dev php-src]$ ./sapi/cli/php -r '1  unset($var[a]);'

Parse error: syntax error, unexpected 'unset' (T_UNSET) in Command line code on 
line 1
--




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=61529


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61529edit=1

Bug-Req #61529 [Ver]: Make unset() an expression

[nikic]

Edit report at https://bugs.php.net/bug.php?id=61529edit=1

 ID: 61529
 Updated by: ni...@php.net
 Reported by:asserte at gmail dot com
-Summary:Parsing error
+Summary:Make unset() an expression
 Status: Verified
-Type:   Bug
+Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.1RC/5.5.0-dev
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

unset() is a statement, not an expression. So you obviously can't use it in an 
expression context. Changing buy type to Feature Request.

In my eyes the behavior *should not* be changed. unset() does not have a 
meaningful return value and as such should not be allowed in an expression 
context.


Previous Comments:

[2012-03-29 13:07:36] reeze dot xia at gmail dot com

unset() is like echo These are language constuct, Both of them are not 
expression in PHP, so code like this:

$c = 1  echo 3;

IS NOT VALID script too;

Those language construct are unticked_statement @see 
Zend/zend_language_parser.y.
if,switch, do while and etc they all.

So from now on, This is not a bug.

Maybe we could make unset() a normal expression. I don't know how this decision 
made, maybe we can discuss it in maillist.


[2012-03-29 12:53:18] larue...@php.net

oh, the patch is based on trunk.


[2012-03-29 12:51:18] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61529.phpt
Revision:   1333025478
URL:
https://bugs.php.net/patch-display.php?bug=61529patch=bug61529.phptrevision=1333025478


[2012-03-29 12:49:51] larue...@php.net

Dmitry, could you review my patch for this bug plz?  thanks


[2012-03-29 12:49:24] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61529.patch
Revision:   1333025364
URL:
https://bugs.php.net/patch-display.php?bug=61529patch=bug61529.patchrevision=1333025364




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=61529


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61529edit=1

Bug #54440 [Com]: libxml extension ignores default context

[sh...@php.net]

Edit report at https://bugs.php.net/bug.php?id=54440edit=1

 ID: 54440
 Comment by: sh...@php.net
 Reported by:jpa...@php.net
 Summary:libxml extension ignores default context
 Status: Closed
 Type:   Bug
 Package:Streams related
 Operating System:   *nix
 PHP Version:5.3.6
 Assigned To:cataphract
 Block user comment: N
 Private report: N

 New Comment:

Reproduced segfault on all 3 branches (debug build on amd64): 
/home/conf/php5.3/Zend/zend_hash.c(979) : ht=0x2de6a50 is already destroyed

Please also look at: http://ci.qa.php.net/job/php-src-trunk-matrix-
build/architecture=x86,os=linux-debian-6.0/lastCompletedBuild/testReport/php-
src.ext.libxml/tests/004_phpt___libxml_set_streams_context__/

and 

http://ci.qa.php.net/job/php-src-trunk-matrix-
build/architecture=x86,os=linux-debian-6.0/lastCompletedBuild/testReport/php-
src.ext.libxml/tests/bug54440_phpt___Bug__54440__libxml_extension_ignores_defaul
t
_context/


Previous Comments:

[2011-04-09 20:32:57] cataphr...@php.net

Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=310109
Log: - Fixed bug #54440: libxml extension ignores default context.


[2011-04-04 00:36:28] cataphr...@php.net

Obviously the patch wasn't meant to be attached here. Sorry.


[2011-04-04 00:32:46] cataphr...@php.net

The following patch has been added/updated:

Patch Name: libxslt_54440.patch
Revision:   1301869965
URL:
http://bugs.php.net/patch-display.php?bug=54440patch=libxslt_54440.patchrevision=1301869965


[2011-04-01 11:45:40] jpa...@php.net

See also #52926


[2011-04-01 11:43:32] jpa...@php.net

Description:

stream_context_set_default() doesn't publish the context to all PHP extension.

Example is ext/libxml that doesn't recognize the context.

Test script:
---
stream_context_set_default(array('http'=array('proxy'='my_proxy_url')));

$x = simplexml_load_file('http://some_resource');

Expected result:

The resource gets loaded through the HTTP proxy

Actual result:
--
The resource is not loaded through the HTTP proxy.
For this to work, we have to use :

$ctx = stream_context_create(array('http'=array('proxy'='my_proxy_url')));
libxml_set_streams_context($ctx); // userland manual bind

$x = simplexml_load_file('http://some_resource');






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=54440edit=1

Req #61529 [Ver]: Make unset() an expression

[laruence]

Edit report at https://bugs.php.net/bug.php?id=61529edit=1

 ID: 61529
 Updated by: larue...@php.net
 Reported by:asserte at gmail dot com
 Summary:Make unset() an expression
 Status: Verified
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.1RC/5.5.0-dev
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

@nikic thinking of isset, include. :)


Previous Comments:

[2012-03-29 13:28:04] ni...@php.net

unset() is a statement, not an expression. So you obviously can't use it in an 
expression context. Changing buy type to Feature Request.

In my eyes the behavior *should not* be changed. unset() does not have a 
meaningful return value and as such should not be allowed in an expression 
context.


[2012-03-29 13:07:36] reeze dot xia at gmail dot com

unset() is like echo These are language constuct, Both of them are not 
expression in PHP, so code like this:

$c = 1  echo 3;

IS NOT VALID script too;

Those language construct are unticked_statement @see 
Zend/zend_language_parser.y.
if,switch, do while and etc they all.

So from now on, This is not a bug.

Maybe we could make unset() a normal expression. I don't know how this decision 
made, maybe we can discuss it in maillist.


[2012-03-29 12:53:18] larue...@php.net

oh, the patch is based on trunk.


[2012-03-29 12:51:18] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61529.phpt
Revision:   1333025478
URL:
https://bugs.php.net/patch-display.php?bug=61529patch=bug61529.phptrevision=1333025478


[2012-03-29 12:49:51] larue...@php.net

Dmitry, could you review my patch for this bug plz?  thanks




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=61529


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61529edit=1

Req #61529 [Ver]: Make unset() an expression

[laruence]

Edit report at https://bugs.php.net/bug.php?id=61529edit=1

 ID: 61529
 Updated by: larue...@php.net
 Reported by:asserte at gmail dot com
 Summary:Make unset() an expression
 Status: Verified
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.1RC/5.5.0-dev
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

@nikic thinking of isset, include. :)


Previous Comments:

[2012-03-29 14:59:27] larue...@php.net

@nikic thinking of isset, include. :)


[2012-03-29 13:28:04] ni...@php.net

unset() is a statement, not an expression. So you obviously can't use it in an 
expression context. Changing buy type to Feature Request.

In my eyes the behavior *should not* be changed. unset() does not have a 
meaningful return value and as such should not be allowed in an expression 
context.


[2012-03-29 13:07:36] reeze dot xia at gmail dot com

unset() is like echo These are language constuct, Both of them are not 
expression in PHP, so code like this:

$c = 1  echo 3;

IS NOT VALID script too;

Those language construct are unticked_statement @see 
Zend/zend_language_parser.y.
if,switch, do while and etc they all.

So from now on, This is not a bug.

Maybe we could make unset() a normal expression. I don't know how this decision 
made, maybe we can discuss it in maillist.


[2012-03-29 12:53:18] larue...@php.net

oh, the patch is based on trunk.


[2012-03-29 12:51:18] larue...@php.net

The following patch has been added/updated:

Patch Name: bug61529.phpt
Revision:   1333025478
URL:
https://bugs.php.net/patch-display.php?bug=61529patch=bug61529.phptrevision=1333025478




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=61529


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61529edit=1

Bug #61551 [Asn-Fbk]: dynamic linker says libnnz11.so not found

[sixd]

Edit report at https://bugs.php.net/bug.php?id=61551edit=1

 ID: 61551
 Updated by: s...@php.net
 Reported by:jm at trash-mail dot com
 Summary:dynamic linker says libnnz11.so not found
-Status: Assigned
+Status: Feedback
 Type:   Bug
 Package:OCI8 related
 Operating System:   linux x64
 PHP Version:Irrelevant
 Assigned To:sixd
 Block user comment: N
 Private report: N

 New Comment:

What operating system and version are you using?
What version of Instant Client are you using?
What is your 'configure' line?


Previous Comments:

[2012-03-29 09:04:00] jm at trash-mail dot com

Description:

Installed Oracle instantclient from RPM:

/usr/lib/oracle/11.2/client64/lib looks like this:

libclntsh.so
libclntsh.so.11.1
libnnz11.so
libocci.so
libocci.so.11.1
libociei.so
libocijdbc11.so
ojdbc5.jar
ojdbc6.jar
ottclasses.zip
xstreams.jar

configuring and compiling oci8 results in 
# ldd modules/oci8.so
...
libnnz11.so = not found
...

even though libnnz11.so is present in the above listing.

What helps is this:

--- config.m4.old   2012-03-29 10:31:58.0 +0200
+++ config.m4   2012-03-29 10:31:43.0 +0200
@@ -321,6 +321,7 @@

 AC_OCI8IC_VERSION($PHP_OCI8_INSTANT_CLIENT)
 PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD)
+PHP_ADD_LIBRARY(nnz11, 1, OCI8_SHARED_LIBADD)
 PHP_ADD_LIBPATH($PHP_OCI8_INSTANT_CLIENT, OCI8_SHARED_LIBADD)

 AC_DEFINE(HAVE_OCI_INSTANT_CLIENT,1,[ ])

-- # ldd modules/oci8.so
linux-vdso.so.1 =  (0x7fff9efc5000)
libclntsh.so.11.1 = 
/usr/lib/oracle/11.2/client64/lib/libclntsh.so.11.1 (0x7f2b4f24c000)
libnnz11.so = /usr/lib/oracle/11.2/client64/lib/libnnz11.so 
(0x7f2b4ee7f000)
libc.so.6 = /lib64/libc.so.6 (0x7f2b4eaef000)
libdl.so.2 = /lib64/libdl.so.2 (0x7f2b4e8eb000)
libm.so.6 = /lib64/libm.so.6 (0x7f2b4e694000)
libpthread.so.0 = /lib64/libpthread.so.0 (0x7f2b4e477000)
libnsl.so.1 = /lib64/libnsl.so.1 (0x7f2b4e25f000)
libaio.so.1 = /lib64/libaio.so.1 (0x7f2b4e05c000)
/lib64/ld-linux-x86-64.so.2 (0x7f2b51d11000)

\o/







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61551edit=1

Bug #53289 [Com]: about __destruct

[php dot net at doppy dot nl]

Edit report at https://bugs.php.net/bug.php?id=53289edit=1

 ID: 53289
 Comment by: php dot net at doppy dot nl
 Reported by:asersz at gmail dot com
 Summary:about __destruct
 Status: Feedback
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows 7
 PHP Version:5.2.14
 Block user comment: N
 Private report: N

 New Comment:

I'm unable to reproduce any error's or a white screen.
Code looks fine, although it is a bit of a strange construction.

Recommend closing this bug as not a bug as it has been open for 1,5 years now.


Previous Comments:

[2010-11-10 23:37:44] fel...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.

I can't reproduce any problem with this test script.


[2010-11-10 09:25:36] asersz at gmail dot com

Description:

I am not good at english.. 

Read the following code ..

An error occurs when you run it..
(there will be white-screen in my codes.)



Chinese :
如果你能看懂中文.那最好不过了. 
上面的代码我认为__destruct被继承之后, 
会导致下面两个类的对象在释放时出现无法找到static 
$childs的错误. 但是在我的代码里面他确实没有出现这个错误, 
反而运行了很久之后出现了白屏. 看上去很像一个死循环.


Test script:
---
error_reporting(E_ALL);
ini_set('display_errors', 'on');

abstract class Father {
   private static $childs = array();

   public static function getChild( $child ) {
   if (!array_key_exists($child, self::$childs)) {
   self::$childs[$child] = new $child;
   }
   return self::$childs[$child];
   }

   public function __destruct() {
   foreach (self::$childs as $i = $child) {
self::$childs[$i] = $child = null;
   }
   }
}

class Child1 extends Father {}
class Child2 extends Father {}

$child1 = Father::getChild('Child1');
$child2 = Father::getChild('Child2');







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=53289edit=1

Bug #61529 [Ver]: Parsing error while use unset with boolean and

[laruence]

Edit report at https://bugs.php.net/bug.php?id=61529edit=1

 ID: 61529
 Updated by: larue...@php.net
 Reported by:asserte at gmail dot com
 Summary:Parsing error while use unset with boolean and
 Status: Verified
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.1RC/5.5.0-dev
 Assigned To:dmitry
 Block user comment: N
 Private report: N

 New Comment:

@nikic @reeze, after a deep thought,  I realize that I was wrong. yes, to fix 
this 
we should make unset return something.. 

so, mark it as a req , 
thanks


Previous Comments:

[2012-03-29 14:59:36] larue...@php.net

@nikic thinking of isset, include. :)


[2012-03-29 14:59:27] larue...@php.net

@nikic thinking of isset, include. :)


[2012-03-29 13:28:04] ni...@php.net

unset() is a statement, not an expression. So you obviously can't use it in an 
expression context. Changing buy type to Feature Request.

In my eyes the behavior *should not* be changed. unset() does not have a 
meaningful return value and as such should not be allowed in an expression 
context.


[2012-03-29 13:07:36] reeze dot xia at gmail dot com

unset() is like echo These are language constuct, Both of them are not 
expression in PHP, so code like this:

$c = 1  echo 3;

IS NOT VALID script too;

Those language construct are unticked_statement @see 
Zend/zend_language_parser.y.
if,switch, do while and etc they all.

So from now on, This is not a bug.

Maybe we could make unset() a normal expression. I don't know how this decision 
made, maybe we can discuss it in maillist.


[2012-03-29 12:53:18] larue...@php.net

oh, the patch is based on trunk.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=61529


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61529edit=1

Doc-Bug #61554 [Opn]: ReflectionClass::getTraits does not return inherited traits

[afredmyers at gmail dot com]

Edit report at https://bugs.php.net/bug.php?id=61554edit=1

 ID: 61554
 User updated by:afredmyers at gmail dot com
 Reported by:afredmyers at gmail dot com
 Summary:ReflectionClass::getTraits does not return inherited
 traits
 Status: Open
-Type:   Documentation Problem
+Type:   Bug
 Package:Reflection related
 Operating System:   Ubuntu 11.10
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

whoops, changed bug type from Documentation Type to Bug


Previous Comments:

[2012-03-29 16:52:34] afredmyers at gmail dot com

Description:

---
From manual page: 
http://www.php.net/reflectionclass.gettraits#refsect1-reflectionclass.gettraits-returnvalues
---
ReflectionClass::getTraits() does not return traits inherited from ancestor 
classes.

Test script:
---
trait Balding {
  public function loseHair(){
echo get_class($this) .  is losing his hair!\n\n;
  }
}

class Father {
  use Balding;
}

class Son extends Father {}

$Son = new Son;
$Son-loseHair();

$Reflect = new ReflectionClass($Son);
print_r($Reflect-getTraits());

Expected result:

Son is losing his hair!

Array
(
  [Balding] = ReflectionClass Object
  (
[name] = Balding
  )
)

Actual result:
--
Son is losing his hair!

Array
(
)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61554edit=1

[PHP-BUG] Bug #61555 [NEW]: Invalid key in Reflection class

[tlr at seegno dot com]

From: 
Operating system: CentOS 6.2
PHP version:  5.4.0
Package:  Reflection related
Bug Type: Bug
Bug description:Invalid key in Reflection class 

Description:

When creating a new Reflection object the key name displays a weird
character.

Expected result:

ReflectionClass Object
 ([name] = Symfony\Bundle\FrameworkBundle\EventListener\SessionListener)


Actual result:
--
ReflectionClass Object
 ([namei˜¥] =
Symfony\Bundle\FrameworkBundle\EventListener\SessionListener)

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

Bug #61555 [Opn-Csd]: Invalid key in Reflection class

[tlr at seegno dot com]

Edit report at https://bugs.php.net/bug.php?id=61555edit=1

 ID: 61555
 User updated by:tlr at seegno dot com
 Reported by:tlr at seegno dot com
 Summary:Invalid key in Reflection class
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Reflection related
 Operating System:   CentOS 6.2
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

It appears it has to do with the version installed: 
http://blog.famillecollet.com/pages/Config-en


Previous Comments:

[2012-03-29 18:05:56] tlr at seegno dot com

Description:

When creating a new Reflection object the key name displays a weird character.

Expected result:

ReflectionClass Object
 ([name] = Symfony\Bundle\FrameworkBundle\EventListener\SessionListener)


Actual result:
--
ReflectionClass Object
 ([namei˜¥] = Symfony\Bundle\FrameworkBundle\EventListener\SessionListener)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61555edit=1

Bug #54254 [Opn]: cal_from_jd returns month = 6 when there is only one Adar

[asphp at dsgml dot com]

Edit report at https://bugs.php.net/bug.php?id=54254edit=1

 ID: 54254
 User updated by:asphp at dsgml dot com
 Reported by:asphp at dsgml dot com
 Summary:cal_from_jd returns month = 6 when there is only one
 Adar
 Status: Open
 Type:   Bug
 Package:Calendar related
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

woordengeschrift you misunderstand the Hebrew calendar.

In non-leap years there is a gap, the calendar months go: 4,5,7,8 - month 6 is 
skipped. Unfortunately PHP does 4,5,6,8 - it skips month 7 instead of 6 which 
is incorrect.

In a leap year it is AdarI that is added - AdarII is the same as Adar. Yes, I 
know you would expect the second one to be the extra, but that's not how the 
calendar works.


Previous Comments:

[2012-03-29 12:13:03] info at woordengeschrift dot nl

In NON-leap years, there is only the unnumbered month of Adar.


[2012-03-29 12:09:41] info at woordengeschrift dot nl

In leap years, there is only the unnumbered month of Adar.
Numbered Adars only occur in leap years: Adar_I (the actual leap month),
followed by Adar_II.


[2011-03-15 09:53:50] asphp at dsgml dot com

Description:

cal_from_jd() returns 6 for Adar when there is only one Adar, (it should return 
7, since if there is only one Adar it's AdarII).

It also says AdarI, which is wrong (it should be either Adar or at least 
AdarII).

Furthermore the cal_days_in_month() (correctly) only works with month 7, and 
not 6 as returned by cal_from_jd.

Test script:
---
?
print_r(cal_from_jd(2456005, CAL_JEWISH));
echo cal_days_in_month(CAL_JEWISH, 6, 5772) . \n;
echo cal_days_in_month(CAL_JEWISH, 7, 5772) . \n;
?


Expected result:

The month in cal_from_jd should be 7.

The second two lines demonstrate how cal_days_in_month also expects the month 
to be 7.

Actual result:
--
Array
(
[date] = 6/24/5772
[month] = 6
[day] = 24
[year] = 5772
[dow] = 0
[abbrevdayname] = Sun
[dayname] = Sunday
[abbrevmonth] = AdarI
[monthname] = AdarI
)
0
29







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=54254edit=1

Bug #60106 [Com]: stream_socket_server + long unix socket path = 'Unknown error'

[sh...@php.net]

Edit report at https://bugs.php.net/bug.php?id=60106edit=1

 ID: 60106
 Comment by: sh...@php.net
 Reported by:tyr...@php.net
 Summary:stream_socket_server + long unix socket path =
 'Unknown error'
 Status: Closed
 Type:   Bug
 Package:Streams related
 Operating System:   linux debian squeeze 64 bit
 PHP Version:5.4.0beta2
 Assigned To:iliaa
 Block user comment: N
 Private report: N

 New Comment:

ext/standard/tests/streams/bug60106.phpt fails for me on all 3 branches.
Please, look also at http://ci.qa.php.net/job/php-src-trunk-matrix-
build/architecture=x86,os=linux-debian-6.0/lastCompletedBuild/testReport/php-
src.ext.standard.tests/streams/bug60106_phpt___Bug_60106__stream_socket_server_si
lently_truncates_long_unix_socket_paths_/


Previous Comments:

[2012-03-29 04:23:44] a...@php.net

Automatic comment on behalf of ab
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=da85d5b4a00943a267db910299bdaee04c081c25
Log: Fix bug #61518 skip on windows, fix on linux - 
ext/standard/tests/streams/bug60106.phpt


[2012-03-27 17:26:07] a...@php.net

Automatic comment on behalf of ab
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=da85d5b4a00943a267db910299bdaee04c081c25
Log: Fix bug #61518 skip on windows, fix on linux - 
ext/standard/tests/streams/bug60106.phpt


[2012-03-03 20:36:11] il...@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/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




[2012-03-03 20:36:07] il...@php.net

Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=323852
Log: Fixed bug #60106 (stream_socket_server silently truncates long unix socket 
paths)


[2011-10-22 10:49:25] larue...@php.net

the limition is in socket self, not php, yes PHP can increase the limition, but 
I 
am afraid it dosen't work too.

but maybe we can throw warning when truncation occurring.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=60106


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60106edit=1

Bug #61555 [Csd-Nab]: Invalid key in Reflection class

[cataphract]

Edit report at https://bugs.php.net/bug.php?id=61555edit=1

 ID: 61555
 Updated by: cataphr...@php.net
 Reported by:tlr at seegno dot com
 Summary:Invalid key in Reflection class
-Status: Closed
+Status: Not a bug
 Type:   Bug
 Package:Reflection related
 Operating System:   CentOS 6.2
 PHP Version:5.4.0
 Block user comment: N
 Private report: N



Previous Comments:

[2012-03-29 18:24:41] tlr at seegno dot com

It appears it has to do with the version installed: 
http://blog.famillecollet.com/pages/Config-en


[2012-03-29 18:05:56] tlr at seegno dot com

Description:

When creating a new Reflection object the key name displays a weird character.

Expected result:

ReflectionClass Object
 ([name] = Symfony\Bundle\FrameworkBundle\EventListener\SessionListener)


Actual result:
--
ReflectionClass Object
 ([namei˜¥] = Symfony\Bundle\FrameworkBundle\EventListener\SessionListener)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61555edit=1

[PHP-BUG] Bug #61556 [NEW]: display_errors=stderr is treated as display_errors=on

[peaceable_whale at hotmail dot com]

From: 
Operating system: Windows Server 2008 R2
PHP version:  5.4.0
Package:  PHP options/info functions
Bug Type: Bug
Bug description:display_errors=stderr is treated as display_errors=on

Description:

PHP 5.4.0 running on IIS 7.5, of which the stderrMode setting has been
ReturnStdErrIn500. A 500 response is expected when display_errors is set to
stderr. However, a 200 response with error message is returned and instead
of stderr, on is displayed in phpinfo.


Test script:
---
1. Set display_errors=stderr
2. Access a malformed php script
3. Look at the HTTP response code and phpinfo

Expected result:

A HTTP 500 response with error message is returned

Actual result:
--
A HTTP 200 response with error message is returned

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

[PHP-BUG] Bug #61557 [NEW]: Crasher (SIGSEGV) bug in tt-rss backend.php

[ond...@php.net]

From: ondrej
Operating system: Linux i386
PHP version:  5.4.0
Package:  *XML functions
Bug Type: Bug
Bug description:Crasher (SIGSEGV) bug in tt-rss backend.php

Description:

Long description can be found here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666200

The trace ends with:

#0  zend_llist_add_element (l=0xbf96013c, element=0x9e961d0)
at
/build/buildd-php5_5.4.0-3-i386-2XGvJx/php5-5.4.0/Zend/zend_llist.c:39


Expected result:

Not crash

Actual result:
--
http://bugs.debian.org/cgi-bin/bugreport.cgi?
msg=45;filename=backtrace2;att=1;bug=666200

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

[PHP-BUG] Bug #61558 [NEW]: Runaway spawning of children after pipe error

[phpbug2012 at tgabber dot mine dot nu]

From: 
Operating system: Debian Linux
PHP version:  5.3.10
Package:  FPM related
Bug Type: Bug
Bug description:Runaway spawning of children after pipe error

Description:

Relevant software versions

Linux 2.6.32-5-amd64
Server Version: Apache/2.2.16 (Debian) DAV/2 mod_fastcgi/2.4.6
PHP Version 5.3.10-1~dotdeb.1
APC Version 3.1.9

Background

This is a lightly-loaded webserver running around 40 virtual hosts that
experiences occasional traffic spikes. Around 20 virtual hosts use php and
have one fpm pool each to run php under their own user, configured as
ondemand so that they have no fpm processes running when they are not
serving pages. Generally there are between 1 and 5 fpm processes running in
total at any one time, rising to maybe 20 to 30 when a spike of traffic
comes in.

Error

I became aware of the problem after a service monitor reported that
websites were no longer being served. Checking, I found that that php-fpm
had crashed. Time since the last restart of php-fpm when the error occured
was about 2 days 4 hours, with around 2.5million php requests served. The
APC cache of 128Mb was about three-quarters full.

Looking back through the logs, this is what I found. The problem appears to
start at 18:55:32 when php-fpm was unable to read a pipe. I have no idea
what caused this initial error, looking back through other logs I could not
see any abnormal web requests around this time.

Mar 24 18:55:32 banana php-fpm[21906]: [ERROR] unable to read what child
say: Bad file descriptor (9)
Mar 24 18:55:32 banana php-fpm[21906]: [ERROR] unable to read what child
say: Bad file descriptor (9)

There were no further fpm messages in the log until those shown below. This
is the most worrying aspect of this bug as basically fpm seems to have gone
into meltdown, continually spawning a process (and using almost all
available cpu).


Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 9
exited with code 0 after 0.002001 seconds from start
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22230
started
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22230
exited with code 0 after 0.001790 seconds from start
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22231
started
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22231
exited with code 0 after 0.001694 seconds from start
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22232
started
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22232
exited with code 0 after 0.001692 seconds from start
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22233
started
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22233
exited with code 0 after 0.001685 seconds from start
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22234
started
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22234
exited with code 0 after 0.001683 seconds from start
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22235
started
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22235
exited with code 0 after 0.001659 seconds from start
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22236
started
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22236
exited with code 0 after 0.001677 seconds from start
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22237
started
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22237
exited with code 0 after 0.001652 seconds from start
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22238
started
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22238
exited with code 0 after 0.001661 seconds from start
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22239
started
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22239
exited with code 0 after 0.001653 seconds from start
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22240
started
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22240
exited with code 0 after 0.001667 seconds from start
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22241
started
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22241
exited with code 0 after 0.001638 seconds from start
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22242
started
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22242
exited with code 0 after 0.001669 seconds from start
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22243
started
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22243
exited with code 0 after 0.001660 seconds from start
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22244
started
Mar 24 18:56:48 banana php-fpm[21906]: [NOTICE] [pool ci] child 22244
exited 

Bug #51159 [Opn-Fbk]: session_set_save_handler Memory Corruption

[arpad]

Edit report at https://bugs.php.net/bug.php?id=51159edit=1

 ID: 51159
 Updated by: ar...@php.net
 Reported by:achristianson at yakabod dot com
 Summary:session_set_save_handler Memory Corruption
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   CentOS 5.4
 PHP Version:5.3.1
 Block user comment: N
 Private report: N

 New Comment:

The reproduce code correctly gives a fatal error (Fatal error: Cannot access 
self:: when no class scope is active and no crash) in the current 5.3 branch 
and trunk. Changing it to a normal variable assignment works fine.

Please let us know if you can reproduce this bug with another script without 
this error, or a current PHP version.


Previous Comments:

[2011-01-27 22:23:21] sa at yakabod dot com

Any chance someone can take a look at this issue that is now approaching 1 year 
in the queue.  We have recently reproduced it on PHP 5.3.4 on CentOS 5.5.  We 
are 
willing to help out with debugging.  Thanks.


[2010-05-26 19:37:14] info at das-peter dot ch

Hi there,

can confirm this behavior with gc enabled/disabled.
My current installation:
php 5.3.2 for win x86 [API220090626,TS,VC6 ]
Compiler VC6, thread safe

Run under Apache 2.2

Cheers,
Peter


[2010-03-01 12:46:00] achristianson at yakabod dot com

We tried with GC off and we get the same result.


[2010-02-28 16:52:02] j...@php.net

Try turn garbage collection of so we know if it's that.. zend.enable_gc = off, 
IIRC. :)


[2010-02-26 19:08:01] achristianson at yakabod dot com

We tried this with Zend MM and garbage collection turned on and off. No 
change in result.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=51159


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=51159edit=1

Bug #61336 [Opn]: file_get_contents() no longer returns false on 4xx responses

[ramsey]

Edit report at https://bugs.php.net/bug.php?id=61336edit=1

 ID: 61336
 Updated by: ram...@php.net
 Reported by:ram...@php.net
 Summary:file_get_contents() no longer returns false on 4xx
 responses
 Status: Open
 Type:   Bug
 Package:Filesystem function related
 Operating System:   CentOS 6.2
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

On that same Debian 6.0.4 VM (using VirtualBox), I built PHP from the latest 
checkout of the PHP-5.4 branch. `php --version` gives me the following version 
line: PHP 5.4.1RC1-dev (cli) (built: Mar 29 2012 18:34:37)

When I run my test script with this build of PHP, I am still having the same 
problem.


Previous Comments:

[2012-03-13 20:24:57] ram...@php.net

I've just tried this on a clean Debian 6.0.4 virtual machine, and I'm having 
the 
same problem there (I've tried even with ignore_errors set to false).

Here are the PHP build notes for my Debian installation: 
http://pastie.org/3588244


[2012-03-13 15:20:20] ram...@php.net

I'm still seeing the problem with ignore_errors set to false. See below for how 
I'm setting ignore_errors. For full details on how my environment is set up, 
you 
can refer to http://benramsey.com/blog/2012/03/build-php-54-on-centos-62/.


?php

$context = stream_context_create(array(
'http' = array(
'ignore_errors' = false
)
));

$response = 
file_get_contents('http://us3.php.net/manual/en/function.foobar.php', false, 
$context);

var_dump($http_response_header);
var_dump($response);


[2012-03-10 14:21:41] cataphr...@php.net

I can't reproduce this. Probably the default context has ignore_errors on. 
Verify that it doesn't and try to pass a context that has ignore_errors set to 
false.


[2012-03-09 22:41:50] s...@php.net

Just for the record, repro script works for me on Windows / 5.4.0 VC9 NTS


[2012-03-09 21:59:47] ram...@php.net

Description:

In PHP 5.3, file_get_contents() returns false on 4xx responses. In PHP 5.4, 
file_get_contents() is returning the actual response body, rather than false.

Test script:
---
?php

$response = 
file_get_contents('http://us3.php.net/manual/en/function.foobar.php');

var_dump($http_response_header);
var_dump($response);

Expected result:

With warnings turned on, this is what I get in PHP 5.3 and what I expect to see 
in PHP 5.4:

PHP Warning:  
file_get_contents(http://us3.php.net/manual/en/function.foobar.php): failed to 
open stream: HTTP request failed! HTTP/1.0 404 Not Found
 in /Users/ramsey/Desktop/file_get_contents.php on line 3
PHP Stack trace:
PHP   1. {main}() /Users/ramsey/Desktop/file_get_contents.php:0
PHP   2. file_get_contents() /Users/ramsey/Desktop/file_get_contents.php:3
array(11) {
  [0]=
  string(22) HTTP/1.0 404 Not Found
  [1]=
  string(35) Date: Fri, 09 Mar 2012 21:57:32 GMT
  [2]=
  string(29) Server: Apache/2.2.3 (CentOS)
  [3]=
  string(23) X-Powered-By: PHP/5.3.2
  [4]=
  string(20) Content-language: en
  [5]=
  string(88) Set-Cookie: LAST_LANG=en; expires=Sat, 09-Mar-2013 21:57:32 GMT; 
path=/; domain=.php.net
  [6]=
  string(102) Set-Cookie: COUNTRY=USA%2C64.2.187.194; expires=Fri, 16-Mar-2012 
21:57:32 GMT; path=/; domain=.php.net
  [7]=
  string(21) Status: 404 Not Found
  [8]=
  string(20) Content-Length: 4219
  [9]=
  string(17) Connection: close
  [10]=
  string(37) Content-Type: text/html;charset=utf-8
}
bool(false)

Actual result:
--
array(11) {
  [0]=
  string(22) HTTP/1.1 404 Not Found
  [1]=
  string(35) Date: Fri, 09 Mar 2012 21:58:44 GMT
  [2]=
  string(29) Server: Apache/2.2.3 (CentOS)
  [3]=
  string(23) X-Powered-By: PHP/5.3.2
  [4]=
  string(20) Content-language: en
  [5]=
  string(88) Set-Cookie: LAST_LANG=en; expires=Sat, 09-Mar-2013 21:58:44 GMT; 
path=/; domain=.php.net
  [6]=
  string(102) Set-Cookie: COUNTRY=USA%2C64.2.187.194; expires=Fri, 16-Mar-2012 
21:58:44 GMT; path=/; domain=.php.net
  [7]=
  string(21) Status: 404 Not Found
  [8]=
  string(20) Content-Length: 4219
  [9]=
  string(17) Connection: close
  [10]=
  string(37) Content-Type: text/html;charset=utf-8
}
string(4219) !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
  http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en lang=en
head
 titlePHP: 404 Not Found/title
 style type=text/css media=all
  @import url(/styles/site.css);
  @import url(/styles/mirror.css);

...

The rest of the HTML output from the php.net 404 page.

[PHP-BUG] Bug #61559 [NEW]: Test Bug - ext/standard/tests/streams/bug61115-1

[mattfic...@php.net]

From: mattficken
Operating system: Windows
PHP version:  5.4.0
Package:  Testing related
Bug Type: Bug
Bug description:Test Bug - ext/standard/tests/streams/bug61115-1

Description:

Looks like this is a test bug, with the fatal error message text being
slightly different than expected.

Might have to fork test into Windows and non-Windows tests.

Test Diff
001+ Fatal error: Allowed memory size of 134217728 bytes exhausted (tried
to allocate 2147483647 bytes) in
C:\php-sdk\0cf70b1\php-test-pack-5.4.1RC1-dev\ext\standard\tests\streams\bug61115-1.php
on line 5
001- Fatal error: Allowed memory size of %d bytes exhausted at %s:%d (tried
to allocate %d bytes) in %s on line %d

Test script:
---
see ext/standard/tests/streams/bug61115-1.phpt

Expected result:

Pass
--
Fatal error: Allowed memory size of %d bytes exhausted at %s:%d (tried to
allocate %d bytes) in %s on line %d

Actual result:
--
Fail
--
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 2147483647 bytes) in
C:\php-sdk\0cf70b1\php-test-pack-5.4.1RC1-dev\ext\standard\tests\streams\bug61115-1.php
on line 5

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

Bug #61336 [Opn]: file_get_contents() no longer returns false on 4xx responses

[ramsey]

Edit report at https://bugs.php.net/bug.php?id=61336edit=1

 ID: 61336
 Updated by: ram...@php.net
 Reported by:ram...@php.net
 Summary:file_get_contents() no longer returns false on 4xx
 responses
 Status: Open
 Type:   Bug
 Package:Filesystem function related
 Operating System:   CentOS 6.2
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

I've just checked out the PHP-5.3 branch on the same environments and built it 
with exactly the same config values as my 5.4 builds. `php --version` shows me 
this: PHP 5.3.11-dev (cli) (built: Mar 29 2012 19:12:58)

It appears that I'm having the exact same problem with the latest checkout from 
PHP 5.3 in these same two environments (Debian 6.0.4 and CentOS 6.2). Either I 
have a problem in both of these environments, or the code that is broken in 5.4 
has recently been merged to 5.3. Unfortunately, others that I have asked to 
test this cannot reproduce it in their environments, so that points to a 
problem with my environment. Any help identifying that problem is greatly 
appreciated. I have posted detailed instructions on exactly what I have done to 
set up each environment.


Previous Comments:

[2012-03-29 22:42:48] ram...@php.net

On that same Debian 6.0.4 VM (using VirtualBox), I built PHP from the latest 
checkout of the PHP-5.4 branch. `php --version` gives me the following version 
line: PHP 5.4.1RC1-dev (cli) (built: Mar 29 2012 18:34:37)

When I run my test script with this build of PHP, I am still having the same 
problem.


[2012-03-13 20:24:57] ram...@php.net

I've just tried this on a clean Debian 6.0.4 virtual machine, and I'm having 
the 
same problem there (I've tried even with ignore_errors set to false).

Here are the PHP build notes for my Debian installation: 
http://pastie.org/3588244


[2012-03-13 15:20:20] ram...@php.net

I'm still seeing the problem with ignore_errors set to false. See below for how 
I'm setting ignore_errors. For full details on how my environment is set up, 
you 
can refer to http://benramsey.com/blog/2012/03/build-php-54-on-centos-62/.


?php

$context = stream_context_create(array(
'http' = array(
'ignore_errors' = false
)
));

$response = 
file_get_contents('http://us3.php.net/manual/en/function.foobar.php', false, 
$context);

var_dump($http_response_header);
var_dump($response);


[2012-03-10 14:21:41] cataphr...@php.net

I can't reproduce this. Probably the default context has ignore_errors on. 
Verify that it doesn't and try to pass a context that has ignore_errors set to 
false.


[2012-03-09 22:41:50] s...@php.net

Just for the record, repro script works for me on Windows / 5.4.0 VC9 NTS




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=61336


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61336edit=1

Bug #61559 [Opn-Csd]: Test Bug - ext/standard/tests/streams/bug61115-1

[shein]

Edit report at https://bugs.php.net/bug.php?id=61559edit=1

 ID: 61559
 Updated by: sh...@php.net
 Reported by:mattfic...@php.net
 Summary:Test Bug - ext/standard/tests/streams/bug61115-1
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Testing related
 Operating System:   Windows
 PHP Version:5.4.0
-Assigned To:
+Assigned To:shein
 Block user comment: N
 Private report: N

 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/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

Please, update, it should be fixed: http://git.php.net/?p=php-
src.git;a=blobdiff;f=ext/standard/tests/streams/bug61115-
1.phpt;h=573496edf0e2dbf0a77dc771f77c815098002a6f;hp=43c54b497423cfb7c21b0a2a4e8b
5e769d41956e;hb=e1352b04165142c945d1fc98c0bcd0b85c3f659d;hpb=55b1e612421c52ea0bb8
a3772095c5bbd62045db


Previous Comments:

[2012-03-29 22:45:01] mattfic...@php.net

Description:

Looks like this is a test bug, with the fatal error message text being slightly 
different than expected.

Might have to fork test into Windows and non-Windows tests.

Test Diff
001+ Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to 
allocate 2147483647 bytes) in 
C:\php-sdk\0cf70b1\php-test-pack-5.4.1RC1-dev\ext\standard\tests\streams\bug61115-1.php
 on line 5
001- Fatal error: Allowed memory size of %d bytes exhausted at %s:%d (tried to 
allocate %d bytes) in %s on line %d

Test script:
---
see ext/standard/tests/streams/bug61115-1.phpt

Expected result:

Pass
--
Fatal error: Allowed memory size of %d bytes exhausted at %s:%d (tried to 
allocate %d bytes) in %s on line %d

Actual result:
--
Fail
--
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to 
allocate 2147483647 bytes) in 
C:\php-sdk\0cf70b1\php-test-pack-5.4.1RC1-dev\ext\standard\tests\streams\bug61115-1.php
 on line 5






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61559edit=1

Bug #25876 [Com]: session_start(): Failed to initialize storage module

[ronniebasak22 at rediffmail dot com]

Edit report at https://bugs.php.net/bug.php?id=25876edit=1

 ID: 25876
 Comment by: ronniebasak22 at rediffmail dot com
 Reported by:golden at riscom dot com
 Summary:session_start(): Failed to initialize storage module
 Status: No Feedback
 Type:   Bug
 Package:Session related
 Operating System:   freebsd 4.8
 PHP Version:4.3.9-4.3.10
 Block user comment: N
 Private report: N

 New Comment:

Here I'm PAMP user,
I am getting it everywhere, from PhpMyAdmin to E107...
whenever calls to session_start()

Fatal Error: function session start [a href='function.session.start'] Failed 
to initialize storage module user (C:\xxx\temp) on setup.php on line 82

But same is working on my hosting with exactly same php, mysql and apache 
version running

Apache 2.2.2 DAV/2 PHP 5.2.2 ZEND 2.2.0

I think only with Apache it has been seen


Previous Comments:

[2011-08-12 12:58:10] okasion at gmail dot com

Hi, I know this problem refers to FreeBSD minor to version 5.x and PHP minor to 
version 5.x, but I want you guys to know that I solved this problem on FreeBSD 
8.0 Release by uncommenting in your php.ini file:
session.save_path = /tmp


[2011-07-12 03:19:24] shappen at gmail dot com

I still have this problem, when i use php5.3.6 and phpmyadmin3.4.3.1.
And i have changed the php.ini session.save_path configuration to  /tmp
.


[2011-03-03 12:18:10] comments at htmlcompressor dot com

If you are gettin the following error:

Fatal error: session_start(): Failed to initialize storage module: files 
(path: ) in


Make sure that you have setup the session save path in your php.ini:

session.save_path = /tmp

which seems to be disabled by default.


[2009-11-05 13:32:03] gonzalo4 at gmail dot com

I have the same problem:

Fatal error: session_start(): Failed to initialize storage module: files 
(path: ) in

and i've put this line:

ini_set(session.save_handler, files);

and nothing happens.

i'm using IIS 6.0 and PHP 5.2.11


[2008-06-23 15:07:22] james at dunmore dot me dot uk

I use DB for sessions, and had the problem with session_destory (followed by 
session_start) as well.

I had this code in a prepend-db file:

$GLOBALS[mysql_session_handler] = new mysql_session_handler;
session_set_save_handler(

array($GLOBALS[mysql_session_handler],'mysql_session_open'),

array($GLOBALS[mysql_session_handler],'mysql_session_close'),

array($GLOBALS[mysql_session_handler],'mysql_session_read'),

array($GLOBALS[mysql_session_handler],'mysql_session_write'),

array($GLOBALS[mysql_session_handler],'mysql_session_destroy'),

array($GLOBALS[mysql_session_handler],'mysql_session_gc')
);

=

So instead, I put that inside the class as a static function (the in the 
prepend, called that static function, mysql_session_handler::setHandler();) , 
then called it again after session destroy. i.e.

session_destroy();

mysql_session_handler::setHandler();


Problem sovled  - well, it's not, session_destroy should not destroy the save 
handler




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=25876


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=25876edit=1

Bug #60718 [Asn-Csd]: pgsql extension no longer compiles

[yohgaki]

Edit report at https://bugs.php.net/bug.php?id=60718edit=1

 ID: 60718
 Updated by: yohg...@php.net
 Reported by:long at ku dot edu
 Summary:pgsql extension no longer compiles
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Compile Failure
 Operating System:   Red Hat Enterprise Linux AS rele
 PHP Version:5.3.9
 Assigned To:yohgaki
 Block user comment: N
 Private report: N

 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/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2012-03-29 13:35:25] yohg...@ohgaki.net@php.net

Automatic comment on behalf of yohg...@ohgaki.net
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=8449e0ca89d77fb20ac3326a0cf574ae2d13676c
Log: Fixed bug #60718 Complie problem with libpq (PostgreSQL 7.3 or less)


[2012-03-29 11:07:53] yohg...@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/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

It's an unsupported version, but I'll look into.


[2012-03-29 11:07:18] yohg...@ohgaki.net@php.net

Automatic comment on behalf of yohg...@ohgaki.net
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=931831bf75d645bdb9f079793b0224bb4843a7a3
Log: Fixed bug #60718 Complie problem with libpq (PostgreSQL 7.3 or less)


[2012-03-29 11:07:17] yohg...@ohgaki.net@php.net

Automatic comment on behalf of yohg...@ohgaki.net
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=8449e0ca89d77fb20ac3326a0cf574ae2d13676c
Log: Fixed bug #60718 Complie problem with libpq (PostgreSQL 7.3 or less)


[2012-01-11 17:44:34] long at ku dot edu

rh-postgresql-devel-7.3.21-3




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=60718


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=60718edit=1

Bug #61554 [Opn-Nab]: ReflectionClass::getTraits does not return inherited traits

[aharvey]

Edit report at https://bugs.php.net/bug.php?id=61554edit=1

 ID: 61554
 Updated by: ahar...@php.net
 Reported by:afredmyers at gmail dot com
 Summary:ReflectionClass::getTraits does not return inherited
 traits
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Reflection related
 Operating System:   Ubuntu 11.10
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

The current behaviour is correct. Traits are outside the inheritance system: 
the 
parent class is effectively defined by the composition of its own 
methods/properties and any traits it uses, so trait usage is not actually 
inherited. Furthermore, it doesn't really make sense to reflect trait usage 
down 
the class hierarchy because the same trait may be used more than once within a 
class hierarchy.


Previous Comments:

[2012-03-29 16:59:20] afredmyers at gmail dot com

whoops, changed bug type from Documentation Type to Bug


[2012-03-29 16:52:34] afredmyers at gmail dot com

Description:

---
From manual page: 
http://www.php.net/reflectionclass.gettraits#refsect1-reflectionclass.gettraits-returnvalues
---
ReflectionClass::getTraits() does not return traits inherited from ancestor 
classes.

Test script:
---
trait Balding {
  public function loseHair(){
echo get_class($this) .  is losing his hair!\n\n;
  }
}

class Father {
  use Balding;
}

class Son extends Father {}

$Son = new Son;
$Son-loseHair();

$Reflect = new ReflectionClass($Son);
print_r($Reflect-getTraits());

Expected result:

Son is losing his hair!

Array
(
  [Balding] = ReflectionClass Object
  (
[name] = Balding
  )
)

Actual result:
--
Son is losing his hair!

Array
(
)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61554edit=1