Bug #64587 [Opn->Nab]: Bug in a determinated second...

[rasmus]

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

 ID: 64587
 Updated by: ras...@php.net
 Reported by:costanzo_pablo at hotmail dot com
 Summary:Bug in a determinated second...
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Date/time related
 Operating System:   All
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Well, regardless of the timezone. You have obviously discovered DST in whatever 
timezone you are in. This is not a bug.


Previous Comments:

[2013-04-05 05:13:50] ras...@php.net

Which timezone?


[2013-04-05 05:10:21] costanzo_pablo at hotmail dot com

Description:

Date timestamp 1363485599 is little than 1363485600

But... when run date function... 1363485600 is greater than 1363485599

1363485599 = 16/03/2013 23:59:59
1363485600 = 16/03/2013 23:00:00

Test script:
---
'.date("d/m/Y H:i:s", 1363485600);
?>

And when execute it...

16/03/2013 23:59:59
16/03/2013 23:00:00

1363485"599"<1363485"600"







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

Bug #64587 [Opn]: Bug in a determinated second...

[rasmus]

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

 ID: 64587
 Updated by: ras...@php.net
 Reported by:costanzo_pablo at hotmail dot com
 Summary:Bug in a determinated second...
 Status: Open
 Type:   Bug
 Package:Date/time related
 Operating System:   All
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Which timezone?


Previous Comments:

[2013-04-05 05:10:21] costanzo_pablo at hotmail dot com

Description:

Date timestamp 1363485599 is little than 1363485600

But... when run date function... 1363485600 is greater than 1363485599

1363485599 = 16/03/2013 23:59:59
1363485600 = 16/03/2013 23:00:00

Test script:
---
'.date("d/m/Y H:i:s", 1363485600);
?>

And when execute it...

16/03/2013 23:59:59
16/03/2013 23:00:00

1363485"599"<1363485"600"







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

[PHP-BUG] Bug #64587 [NEW]: Bug in a determinated second...

[costanzo_pablo at hotmail dot com]

From: costanzo_pablo at hotmail dot com
Operating system: All
PHP version:  Irrelevant
Package:  Date/time related
Bug Type: Bug
Bug description:Bug in a determinated second...

Description:

Date timestamp 1363485599 is little than 1363485600

But... when run date function... 1363485600 is greater than 1363485599

1363485599 = 16/03/2013 23:59:59
1363485600 = 16/03/2013 23:00:00

Test script:
---
'.date("d/m/Y H:i:s",
1363485600);
?>

And when execute it...

16/03/2013 23:59:59
16/03/2013 23:00:00

1363485"599"<1363485"600"


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

Bug #64577 [Opn->Csd]: die or exit on solaris leaves open file descriptors

[rasmus]

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

 ID: 64577
 Updated by: ras...@php.net
 Reported by:davek at gamehouse dot com
 Summary:die or exit on solaris leaves open file descriptors
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Apache2 related
 Operating System:   solaris 11
 PHP Version:5.4.13
-Assigned To:
+Assigned To:rasmus
 Block user comment: N
 Private report: N

 New Comment:

volatile patch committed - will be in the next batch of releases


Previous Comments:

[2013-04-04 20:56:28] davek at gamehouse dot com

Resolved:

  Worked with our hosting company, joyent, on this.  It was pointed out that 
they had 
solved this issue about two years ago (https://bugs.php.net/bug.php?id=47675).  
I had 
found that bug report before creating this one as I saw that the code change 
had been 
added. However... 

I didn't see this at first but looking more closely, when I look at my version 
of 
main.c, old_cwd_fd is declared without the 'volatile' modifier.   After reading 
up on 
setjmp/longjmp and the use of volatile, I added it in, re-compiled and the 
issue is 
resolved.   It's clear in bug 47675 that the volatile modifier is there however 
it's 
not been added into the code repository.  Will this be added?


[2013-04-03 21:00:19] davek at gamehouse dot com

I build php 5.4.13 and re-ran the test.  Same result: open FD's accumulate.


[2013-04-03 19:02:20] davek at gamehouse dot com

this may be related to https://bugs.php.net/bug.php?id=47675 
and https://bugs.php.net/bug.php?id=60978

I'll verify that I can reproduce the issue with php 5.4


[2013-04-03 18:59:08] davek at gamehouse dot com

Description:

apache 2.4.3 : mod_prefork, keepAlive = Off
php 5.3.23 : ../php-5.3.23/configure' 
'--prefix=/opt/ghc/services/php/php5.3.23' 
'--with-apxs2=/opt/ghc/services/apache/apache2.4.3-php/bin/apxs' '--with-config-
file-path=/opt/ghc/services/php/php5.3.23/lib' '--disable-all'

phpinfo.php:

 ./bin/httpd -X &
server> pfiles $(pgrep httpd) |awk '{print $1}' |grep ^[[:digit:]] |wc -l
12

server> pfiles $(pgrep httpd) 
25087:  ./bin/httpd -X -f /opt/ghc/conf/php_conf/conf/httpd.conf
  Current rlimit: 1024 file descriptors
   0: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
  O_RDWR|O_NOCTTY|O_LARGEFILE
  /dev/pts/1
  offset:320891
   1: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
  O_RDWR|O_NOCTTY|O_LARGEFILE
  /dev/pts/1
  offset:320891
   2: S_IFREG mode:0644 dev:90,65567 ino:99347 uid:0 gid:0 size:5322
  O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
  /opt/ghc/conf/php_conf/logs/error_log
  offset:5322
   3: S_IFSOCK mode:0666 dev:540,0 ino:10 uid:0 gid:0 size:0
  O_RDWR FD_CLOEXEC
SOCK_STREAM
SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(128000)
sockname: AF_INET 192.168.27.57  port: 80
   4: S_IFDOOR mode:0444 dev:542,0 ino:90 uid:0 gid:0 size:0
  O_RDONLY|O_LARGEFILE FD_CLOEXEC  door to nscd[9126]
  /var/run/name_service_door
   5: S_IFIFO mode: dev:530,0 ino:21648220 uid:0 gid:0 size:0
  O_RDWR|O_NONBLOCK FD_CLOEXEC
   6: S_IFIFO mode: dev:530,0 ino:21648220 uid:0 gid:0 size:0
  O_RDWR FD_CLOEXEC
   7: S_IFREG mode:0644 dev:90,65567 ino:97687 uid:0 gid:0 size:0
  O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC
  /opt/ghc/conf/php_conf/logs/access_log
  offset:0
   8: S_IFIFO mode: dev:530,0 ino:21648221 uid:0 gid:0 size:0
  O_RDWR FD_CLOEXEC
   9: S_IFPORT mode: dev:543,0 uid:103 gid:1 size:0
  10: S_IFIFO mode: dev:530,0 ino:21648222 uid:0 gid:0 size:0
  O_RDWR


client> curl http://server/phpinfo.php


server> pfiles $(pgrep httpd) |awk '{print $1}' |grep ^[[:digit:]] |wc -l
13

server> pfiles $(pgrep httpd) 
25087:  ./bin/httpd -X -f /opt/ghc/conf/php_conf/conf/httpd.conf
  Current rlimit: 1024 file descriptors
   0: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
  O_RDWR|O_NOCTTY|O_LARGEFILE
  /dev/pts/1
  offset:324283
   1: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
  O_RDWR|O_NOCTTY|O_LARGEFILE
  /dev/pts/1
  offset:324283
   2: S_IFREG mode:0644 dev:90,65567 ino:99347 uid:0 gid:0 size:5322
  O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
  /opt/ghc/conf/php_conf/logs/error_log
  offset:5322
   3: S_IFSOCK mode:0666 dev:540,0 ino:10 uid:0 gid:0 size:0
  O_RDWR FD_CLOEXEC
SOCK_STREAM
SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(128000)
sockname: AF_INET 192.168.27.57  port: 80
   4: S_IFDOOR mode:0444 dev:542,0

Bug #47675 [ReO->Csd]: File descriptor leaked due to HAVE_BROKEN_GETCWD

[rasmus]

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

 ID: 47675
 Updated by: ras...@php.net
 Reported by:cs at ecn dot purdue dot edu
 Summary:File descriptor leaked due to HAVE_BROKEN_GETCWD
-Status: Re-Opened
+Status: Closed
 Type:   Bug
 Package:Apache2 related
 Operating System:   Solaris 10
 PHP Version:5.2.9
-Assigned To:
+Assigned To:rasmus
 Block user comment: N
 Private report: N

 New Comment:

Will be in the next batch of releases


Previous Comments:

[2013-04-04 20:56:28] davek at gamehouse dot com

Related To: Bug #64577


[2011-09-28 00:58:18] jsjoh...@php.net

I've heard that this was fixed in PHP 5.3.5. It's not listed in the release 
notes 
from what I can see, so can someone confirm if 5.3.5 addresses this issue?


[2011-05-18 18:23:29] pyorke at joyent dot com

This still broken in PHP 5.3.3

When is it going to be fixed


[2010-08-08 10:20:55] php at marino dot st

I've been trying to track down this file descriptor leakage problem for months. 
 I was stuck on 5.2.8 because of it.  I confirm that the issue is specifically 
with Solaris 10.  I have opensolaris sxce nevada 130 locally and I've not seen 
FD leakage on it.

I confirm that patch suggested by bryan at stansell dot org seemed to correct 
the problem.  FYI, PHP was spawned and remains persistent for use with the 
Litespeed web server (uses the LSAPI interface), so it would run out of file 
descriptors between 1 and 12 hours on my site.  It's a bit disappointing that 
this error has been present for 5 releases and was never fixed.


[2010-01-12 15:40:45] bryan at stansell dot org

I finally got a chance to test a theory.  Looks like the volatile attribute 
fixed things for me.

#if HAVE_BROKEN_GETCWD
volatile int old_cwd_fd = -1;
#else

Once I added that, the setjmp/longjmp worked as expected.  I got the idea from 
the manpage on Solaris:

 The values of register and  automatic  variables  are  unde-
 fined.  Register  or automatic variables whose value must be
 relied upon must be declared as volatile.

Perhaps it's a gcc/gas/Solaris/x86 optimization somewhere that overlooked the 
case, but this is a workaround.  Of course, undefining HAVE_BROKEN_GETCWD for 
Solaris also works, if you have a web tree that isn't restricted in some way.




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


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

Bug #64584 [Opn->Nab]: Content-length is correct, but data truncated in php://input

[rasmus]

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

 ID: 64584
 Updated by: ras...@php.net
 Reported by:viraj dot kanwade at snstech dot com
 Summary:Content-length is correct, but data truncated in
 php://input
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:HTTP related
 Operating System:   Centos
 PHP Version:5.3.23
 Block user comment: N
 Private report: N

 New Comment:

$_SERVER['Content-Length'] is set by the web server and tends to come directly 
from the Content-Length header the client sends. If the client aborts before 
sending all the data the web server is not going to adjust this value. This is 
quite normal. You can check the connection status to see if the client aborted 
mid-request on you. See 
http://php.net/manual/en/features.connection-handling.php


Previous Comments:

[2013-04-04 17:12:24] viraj dot kanwade at snstech dot com

Description:

We use PHP 5.3.14

Sometimes ajax post to a PHP page, results in $_SERVER content-length to be set 
correctly, but the $_POST does not have all data. I have also tested 
php://input 
to see if the data was received. But the data was truncated. This is NOT a file 
upload.

The data could be of 1000-5000 chars. But only 400-600 chars are received.

This is intermittent.

Could be similar to https://bugs.php.net/bug.php?id=22427

Expected result:

The post values submitted by ajax request should be available in $_POST.

Actual result:
--
The post value is truncated.






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

Req #53713 [Com]: Add sqlite3 session handler

[dan dot latter at gmail dot com]

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

 ID: 53713
 Comment by: dan dot latter at gmail dot com
 Reported by:jinmoku at hotmail dot com
 Summary:Add sqlite3 session handler
 Status: Assigned
 Type:   Feature/Change Request
 Package:SQLite related
 PHP Version:5.3.5
 Assigned To:scottmac
 Block user comment: N
 Private report: N

 New Comment:

Hi,

Any news on this? Just updated to 5.4 to update to new session shizzle and docs 
have lead me here as I needed a handler for sqlite3.

thanks


Previous Comments:

[2012-06-29 14:52:00] colin at viebrock dot ca

This isn't in 5.4.4 as of yet, is it?


[2011-08-01 05:15:27] crrodriguez at opensuse dot org

I have reviewed this patch, ACKed, fixed build in Unix (broken #if) and 
config0.m4

also added IF NOT EXISTS to the table creation routine.

Looks good =)


[2011-04-30 04:05:54] jinmoku at hotmail dot com

Added patch


[2011-01-11 15:43:38] jinmoku at hotmail dot com

Description:

ext/sqlite will disappear soon, it's seem good to add support for sqlite3 
session handler (merge ext/sqlite/sess_sqlite.c)
;)

Test script:
---
session_module_name('sqlite3');

Actual result:
--
Warning: session_module_name(): Cannot find named PHP session module (sqlite3)






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

Bug #62886 [Com]: PHP-FPM may segfault/hang on startup

[zakrzewskim at wp dot pl]

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

 ID: 62886
 Comment by: zakrzewskim at wp dot pl
 Reported by:pierre at archlinux dot de
 Summary:PHP-FPM may segfault/hang on startup
 Status: Closed
 Type:   Bug
 Package:FPM related
 Operating System:   Arch Linux
 PHP Version:5.4.6
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

Same to me:

[04-Apr-2013 22:38:37] ERROR: unable to read what child say: Bad file 
descriptor (9)
[04-Apr-2013 22:38:55] ERROR: unable to read what child say: Bad file 
descriptor (9)
[04-Apr-2013 22:38:55] ERROR: unable to read what child say: Bad file 
descriptor (9)
[04-Apr-2013 22:38:55] ERROR: unable to read what child say: Bad file 
descriptor (9)
[04-Apr-2013 22:38:55] ERROR: unable to read what child say: Bad file 
descriptor (9)
[04-Apr-2013 22:38:55] ERROR: unable to read what child say: Bad file 
descriptor (9)
[04-Apr-2013 22:38:55] ERROR: unable to read what child say: Bad file 
descriptor (9)

php-fpm[19644]: segfault at 7fff30199fe0 ip 00574e30 sp 
7fff30199fb0 error 6 in php-fpm[40+32a000]
php-fpm[18003]: segfault at 7fff30199fe0 ip 00574e30 sp 
7fff30199fb0 error 6 in php-fpm[40+32a000]
php-fpm[9699]: segfault at 7fff30199fe0 ip 00574e30 sp 7fff30199fb0 
error 6 in php-fpm[40+32a000]
php-fpm[17649]: segfault at 7fff30199fe0 ip 00574e30 sp 
7fff30199fb0 error 6 in php-fpm[40+32a000]
php-fpm[13203]: segfault at 7fff30199fe0 ip 00574e30 sp 
7fff30199fb0 error 6 in php-fpm[40+32a000]
php-fpm[21313]: segfault at 7ffeff931fa0 ip 00574e30 sp 
7ffeff931f70 error 6 in php-fpm[40+32a000]
php-fpm[4705]: segfault at 7fff84be5fa0 ip 00574e30 sp 7fff84be5f70 
error 6 in php-fpm[40+32a000]
php-fpm[24508]: segfault at 7fff84be5fa0 ip 00574e30 sp 
7fff84be5f70 error 6 in php-fpm[40+32a000]

[root@onlinecity /]# php -v
PHP 5.4.13 (cli) (built: Mar 14 2013 09:15:29)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
with the ionCube PHP Loader v4.2.2, Copyright (c) 2002-2012, by ionCube 
Ltd., and
with SourceGuardian v9.0.4, Copyright (c) 2000-2012, by Inovica Ltd.

rpm -qi php
Name: php  Relocations: (not relocatable)
Version : 5.4.13Vendor: Remi Collet
Release : 1.el5.remiBuild Date: czw 14 mar 2013 
09:27:38 CET
Install Date: sob 16 mar 2013 18:44:01 CET  Build Host: 
dixsept.famillecollet.com
Group   : Development/Languages Source RPM: 
php-5.4.13-1.el5.remi.src.rpm
Size: 9294225  License: PHP and Zend and BSD
Signature   : DSA/SHA1, czw 14 mar 2013 09:45:45 CET, Key ID 004e6f4700f97f56
Packager: http://blog.famillecollet.com/
URL : http://www.php.net/
Summary : Osadzany w HTML-u język skryptowy PHP (PHP: preprocesor 
hipertekstu).
Description :
PHP is an HTML-embedded scripting language. PHP attempts to make it
easy for developers to write dynamically generated webpages. PHP also
offers built-in database integration for several commercial and
non-commercial database management systems, so writing a
database-enabled webpage with PHP is fairly simple. The most common
use of PHP coding is probably as a replacement for CGI scripts.

The php package contains the module which adds support for the PHP
language to Apache HTTP Server.


Previous Comments:

[2013-03-19 12:28:56] anonymousdude at gmail dot com

[19-Mar-2013 08:22:54] NOTICE: Reloading in progress ...
[19-Mar-2013 08:22:54] ERROR: unable to read what child say: Bad file 
descriptor 
(9)
[19-Mar-2013 08:22:54] ERROR: unable to read what child say: Bad file 
descriptor 
(9)
[19-Mar-2013 08:22:54] ERROR: unable to read what child say: Bad file 
descriptor 
(9)
[19-Mar-2013 08:22:54] ERROR: unable to read what child say: Bad file 
descriptor 
(9)
[19-Mar-2013 08:22:54] ERROR: unable to read what child say: Bad file 
descriptor 
(9)
[19-Mar-2013 08:22:54] ERROR: unable to read what child say: Bad file 
descriptor 
(9)
[19-Mar-2013 08:22:54] NOTICE: reloading: execvp("php-fpm", {"php-fpm", "--
daemonize"})
[19-Mar-2013 08:22:55] NOTICE: using inherited socket fd=7, "127.0.0.1:9000"
[19-Mar-2013 08:22:55] NOTICE: using inherited socket fd=7, "127.0.0.1:9000"
[19-Mar-2013 08:22:55] NOTICE: fpm is running, pid 25134
[19-Mar-2013 08:22:55] NOTICE: ready to handle connections
[root@ID11878 php-fpm]#
[root@ID11878 php-fpm]# php -v
PHP 5.4.13 (cli) (built: Mar 14 2013 08:57:49)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies


[2012-10-23 12:23:54] slim at inbox dot lv

did

Bug #64577 [Opn]: die or exit on solaris leaves open file descriptors

[davek at gamehouse dot com]

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

 ID: 64577
 User updated by:davek at gamehouse dot com
 Reported by:davek at gamehouse dot com
 Summary:die or exit on solaris leaves open file descriptors
 Status: Open
 Type:   Bug
 Package:Apache2 related
 Operating System:   solaris 11
-PHP Version:5.3.23
+PHP Version:5.4.13
 Block user comment: N
 Private report: N

 New Comment:

Resolved:

  Worked with our hosting company, joyent, on this.  It was pointed out that 
they had 
solved this issue about two years ago (https://bugs.php.net/bug.php?id=47675).  
I had 
found that bug report before creating this one as I saw that the code change 
had been 
added. However... 

I didn't see this at first but looking more closely, when I look at my version 
of 
main.c, old_cwd_fd is declared without the 'volatile' modifier.   After reading 
up on 
setjmp/longjmp and the use of volatile, I added it in, re-compiled and the 
issue is 
resolved.   It's clear in bug 47675 that the volatile modifier is there however 
it's 
not been added into the code repository.  Will this be added?


Previous Comments:

[2013-04-03 21:00:19] davek at gamehouse dot com

I build php 5.4.13 and re-ran the test.  Same result: open FD's accumulate.


[2013-04-03 19:02:20] davek at gamehouse dot com

this may be related to https://bugs.php.net/bug.php?id=47675 
and https://bugs.php.net/bug.php?id=60978

I'll verify that I can reproduce the issue with php 5.4


[2013-04-03 18:59:08] davek at gamehouse dot com

Description:

apache 2.4.3 : mod_prefork, keepAlive = Off
php 5.3.23 : ../php-5.3.23/configure' 
'--prefix=/opt/ghc/services/php/php5.3.23' 
'--with-apxs2=/opt/ghc/services/apache/apache2.4.3-php/bin/apxs' '--with-config-
file-path=/opt/ghc/services/php/php5.3.23/lib' '--disable-all'

phpinfo.php:

 ./bin/httpd -X &
server> pfiles $(pgrep httpd) |awk '{print $1}' |grep ^[[:digit:]] |wc -l
12

server> pfiles $(pgrep httpd) 
25087:  ./bin/httpd -X -f /opt/ghc/conf/php_conf/conf/httpd.conf
  Current rlimit: 1024 file descriptors
   0: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
  O_RDWR|O_NOCTTY|O_LARGEFILE
  /dev/pts/1
  offset:320891
   1: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
  O_RDWR|O_NOCTTY|O_LARGEFILE
  /dev/pts/1
  offset:320891
   2: S_IFREG mode:0644 dev:90,65567 ino:99347 uid:0 gid:0 size:5322
  O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
  /opt/ghc/conf/php_conf/logs/error_log
  offset:5322
   3: S_IFSOCK mode:0666 dev:540,0 ino:10 uid:0 gid:0 size:0
  O_RDWR FD_CLOEXEC
SOCK_STREAM
SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(128000)
sockname: AF_INET 192.168.27.57  port: 80
   4: S_IFDOOR mode:0444 dev:542,0 ino:90 uid:0 gid:0 size:0
  O_RDONLY|O_LARGEFILE FD_CLOEXEC  door to nscd[9126]
  /var/run/name_service_door
   5: S_IFIFO mode: dev:530,0 ino:21648220 uid:0 gid:0 size:0
  O_RDWR|O_NONBLOCK FD_CLOEXEC
   6: S_IFIFO mode: dev:530,0 ino:21648220 uid:0 gid:0 size:0
  O_RDWR FD_CLOEXEC
   7: S_IFREG mode:0644 dev:90,65567 ino:97687 uid:0 gid:0 size:0
  O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC
  /opt/ghc/conf/php_conf/logs/access_log
  offset:0
   8: S_IFIFO mode: dev:530,0 ino:21648221 uid:0 gid:0 size:0
  O_RDWR FD_CLOEXEC
   9: S_IFPORT mode: dev:543,0 uid:103 gid:1 size:0
  10: S_IFIFO mode: dev:530,0 ino:21648222 uid:0 gid:0 size:0
  O_RDWR


client> curl http://server/phpinfo.php


server> pfiles $(pgrep httpd) |awk '{print $1}' |grep ^[[:digit:]] |wc -l
13

server> pfiles $(pgrep httpd) 
25087:  ./bin/httpd -X -f /opt/ghc/conf/php_conf/conf/httpd.conf
  Current rlimit: 1024 file descriptors
   0: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
  O_RDWR|O_NOCTTY|O_LARGEFILE
  /dev/pts/1
  offset:324283
   1: S_IFCHR mode:0620 dev:533,11 ino:920560006 uid:0 gid:7 rdev:6,1
  O_RDWR|O_NOCTTY|O_LARGEFILE
  /dev/pts/1
  offset:324283
   2: S_IFREG mode:0644 dev:90,65567 ino:99347 uid:0 gid:0 size:5322
  O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
  /opt/ghc/conf/php_conf/logs/error_log
  offset:5322
   3: S_IFSOCK mode:0666 dev:540,0 ino:10 uid:0 gid:0 size:0
  O_RDWR FD_CLOEXEC
SOCK_STREAM
SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(128000)
sockname: AF_INET 192.168.27.57  port: 80
   4: S_IFDOOR mode:0444 dev:542,0 ino:90 uid:0 gid:0 size:0
  O_RDONLY|O_LARGEFILE FD_CLOEXEC  door to nscd[9126]
  /var/run/name_service_door
   5: S_IFIFO mode: dev:530,0 ino:21648220 uid:0 gid:0 size:0
  O_RDWR|O_NONBLOCK FD_CLOEXEC
   6: S_

Bug #61777 [Com]: Cannot bind parameters with pdo_odbc and SQL Server Native Client 11.0

[me at andrewkehrig dot com]

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

 ID: 61777
 Comment by: me at andrewkehrig dot com
 Reported by:frozen at frozen-solid dot net
 Summary:Cannot bind parameters with pdo_odbc and SQL Server
 Native Client 11.0
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   Ubuntu 12.04
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

I can verify this bug still occurs on php 5.3.19 and php 5.4.6 as well.

php 5.3.19 running on Windows experiences a slightly different version of this 
problem when talking to SQL Server via ODBC: bound parameters work, as long as 
you're not comparing them directly to date datatype columns (date, timestamp, 
etc) - if you are, you have to cast them manually from varchar to date, or if 
you're using a stored procedure with input parameters you have to set any date 
input parameters to varchar and allow the server to infer the datatype 
conversion when comparing the input parameter(a varchar holding a date, 
timestamp, etc) to an actual date,timestamp,etc column.


Previous Comments:

[2013-01-30 00:43:04] paul dot posts at gmail dot com

Can confirm that patches in bug 50444 correct this issue for me as well.


[2012-10-18 17:05:26] kraven at kraven dot org

I believe this is related to the SQLLEN.  PHP bug 5044 has a patch.

MS bug here where developer says its SQLLEN:
http://connect.microsoft.com/SQLServer/feedback/details/737751/cannot-bind-
parameters-with-php-pdo-odbc-and-sql-native-client-11-0

I applied the patches in bug 50444 and now it's working for me.


[2012-05-15 18:59:11] burnhamrobertp at gmail dot com

Debian Squeeze 2.6.32-5-amd64
PHP 5.3.3 (also reproducible under PHP 5.4.0-3)

The test case and error information are exactly the same.


[2012-04-19 18:45:03] frozen at frozen-solid dot net

Description:

When trying to bind parameters to a prepared statement, bindValue() and 
bindParam() both return false with the error code HY004, [SQL Server Native 
Client 
11.0]Invalid SQL data type (SQLBindParameter[0] at /build/buildd/php5-
5.3.10/ext/pdo_odbc/odbc_stmt.c:379)

It does not matter whether you pass in PDO::PARAM_STR or PARAM_INT or no data 
type 
specification, the error is the same every time.

Using parameters with odbc_connect() and odbc_prepare() work as expected, so 
the 
issue is directly related to PDO, not to ODBC or Microsoft's driver.

Test script:
---
$db = new PDO('odbc:sqltest', 'wwwuser', 'btsb');

$strSql = 'select top 10 * from oltmaster where titleno = :no';

$q = $db->prepare($strSql);

var_dump($q->bindValue(':no', '029803'));
var_dump($q->errorInfo());

Expected result:

boolean true

array
  0 => string '' (length=0)
  1 => int 0
  2 => string ' ((null)[0] at (null):0)' (length=24)
  3 => string '' (length=0)

Actual result:
--
boolean false

array
  0 => string 'HY004' (length=5)
  1 => int 0
  2 => string '[Microsoft][SQL Server Native Client 11.0]Invalid SQL data type 
(SQLBindParameter[0] at 
/build/buildd/php5-5.3.10/ext/pdo_odbc/odbc_stmt.c:379)' 
(length=143)
  3 => string 'HY004' (length=5)







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

Bug #63520 [Com]: JSON extension includes a problematic license statement

[b dot eltzner at gmx dot de]

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

 ID: 63520
 Comment by: b dot eltzner at gmx dot de
 Reported by:kaplan at debian dot org
 Summary:JSON extension includes a problematic license
 statement
 Status: Assigned
 Type:   Bug
 Package:JSON related
 PHP Version:Irrelevant
 Assigned To:remi
 Block user comment: N
 Private report: N

 New Comment:

I am not a native speaker. This comment is not supposed to be rude or insult 
anybody.

I would like to make the problem clearer:

*The "json license" affecting /ext/json/JSON_parser.c and 
/ext/json/utf8_decode.c is regarded non-free by GNU/FSF, Debian, Fedora, Red 
Hat and Google and is not approved by OSI. This is not at all the same as "Free 
but incompatible with GPL", which is the category in which the FSF lists the 
php license.

*The morality clause "The Software shall be used for Good, not Evil." violates 
software freedom 0 and point 6 of the open source definition and the license 
will therefore _never_ be free or open source by definition. This is not a 
license "some fanatics don't like", it is a manifestly proprietary license.

*The original author of the license has purposely chosen this form of license 
to trick open source projects into mistaking it as an open source license. He 
did this to prove the point that "those open source guys are entitled kids" and 
plays the issue for amusement: http://www.youtube.com/watch?v=-hCimLnIsDA

*With the non-free files, PHP cannot be distributed unmodified as free software 
by downstream projects.

Note that I don't say "Throw that stuff out11" It goes without saying that 
you can distribute the result of your work under whatever licenses you like, 
open source or not. However, if you want PHP to be easily distributable as free 
and open source software by downstream projects, I am sure they would be 
enormously relieved, if you provided them with a simple way to exclude the 
non-free files without breaking too much functionality.


Previous Comments:

[2012-11-23 13:33:42] r...@php.net

A patch proposed in https://bugs.php.net/63588 makes "json_encode" really free.


[2012-11-15 18:09:30] ras...@php.net

I am not saying it isn't a tricky license clause to deal with and it would be 
better if it wasn't there. However, I am also not keen on spending resources on 
rewriting code for this reason. If someone supplies a functionally equivalent 
replacement, we will have a look at it. But as far as I am concerned, license-
wise the terms Good and Evil are not legal terms. These are more subjective 
self-describing terms and since I deem PHP's use of the code as "Good" then we 
comply with the license. Could others perhaps use PHP and thus the code for 
"Evil" and therefore not comply with the license? Sure, but there are many 
things people can do with our code that is either against the various licenses 
involved or even illegal criminally. It is something we cannot control.


[2012-11-15 18:01:24] paj...@php.net

More seriously, as soon as the license is changed upstream, we will merge it. 
But 
we won't be able to do anything before.


[2012-11-15 18:00:52] paj...@php.net

well, the FSF does not like the PHP license either. Nothing worries me here :)


[2012-11-15 17:58:38] ansgar at debian dot org

I just want to note that the FSF[1] and other distributions like Fedora also 
think this license is bad[2].

  [1] 
  [2] , look for 
"JSON License"

So this is not a problem for just Debian.

Ansgar




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


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

[PHP-BUG] Bug #64584 [NEW]: Content-length is correct, but data truncated in php://input

[viraj dot kanwade at snstech dot com]

From: viraj dot kanwade at snstech dot com
Operating system: Centos
PHP version:  5.3.23
Package:  HTTP related
Bug Type: Bug
Bug description:Content-length is correct, but data truncated in php://input

Description:

We use PHP 5.3.14

Sometimes ajax post to a PHP page, results in $_SERVER content-length to be
set 
correctly, but the $_POST does not have all data. I have also tested
php://input 
to see if the data was received. But the data was truncated. This is NOT a
file 
upload.

The data could be of 1000-5000 chars. But only 400-600 chars are received.

This is intermittent.

Could be similar to https://bugs.php.net/bug.php?id=22427

Expected result:

The post values submitted by ajax request should be available in $_POST.

Actual result:
--
The post value is truncated.

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

Bug #63863 [Com]: DateTime:setDate() date not used after modify("last day of...")

[armin at fruux dot com]

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

 ID: 63863
 Comment by: armin at fruux dot com
 Reported by:brian dot feaver at sellingsource dot com
 Summary:DateTime:setDate() date not used after modify("last
 day of...")
 Status: Open
 Type:   Bug
 Package:Date/time related
 Operating System:   Mac OS X
 PHP Version:5.3.20
 Block user comment: N
 Private report: N

 New Comment:

Besides from being able to reproduce this completely, it also happens
when using setTimestamp(), as the day keeps being 'last day of month'.

PHP version: 5.4.9
OS: Mac OS X


Test script:

modify("last day of last month");
var_dump($date->format('Y-m-d')); // correctly last day of Feb

$date->setTimestamp(1327881600); // 2012-01-30
var_dump($date->format('Y-m-d')); // incorrect date

$date->modify('2012-01-30');
var_dump($date->format('Y-m-d')); // does set correct date


Previous Comments:

[2012-12-27 18:52:32] brian dot feaver at sellingsource dot com

Description:

When modifying a DateTime object with modify("last day of last month") syntax 
and 
followed by a setDate(), the date portion of setDate() is ignored. It modifies 
the 
year and the month, but continues to set the day portion to the last day of the 
month.

If modify() is called with the absolute date instead of setDate(), it correctly 
sets the date.

Test script:
---
modify("last day of last month");
var_dump($date->format('Y-m-d')); // correctly last day of Feb

$date->setDate(2012, 1, 30);
var_dump($date->format('Y-m-d')); // incorrect date

$date->modify('2012-01-30');
var_dump($date->format('Y-m-d')); // does set correct date


Expected result:

string(10) "2012-02-29"
string(10) "2012-01-30"
string(10) "2012-01-30"

Actual result:
--
string(10) "2012-02-29"
string(10) "2012-01-31"
string(10) "2012-01-30"






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

Bug #64582 [Opn]: file_get_contents() handles redirects wrong

[spam2 at rhsoft dot net]

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

 ID: 64582
 User updated by:spam2 at rhsoft dot net
 Reported by:spam2 at rhsoft dot net
 Summary:file_get_contents() handles redirects wrong
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.13
 Block user comment: N
 Private report: N

 New Comment:

i know that, but it is not that easy to generate everytime a full qualified URL 
and since any other http-client translates the ../ PHP should act the same way


Previous Comments:

[2013-04-04 15:53:58] johan...@php.net

RFC 2616 Section 14.30 requires "a single absolute URI." for the location 
header. Any relative location is not standards compliant.


[2013-04-04 14:55:58] spam2 at rhsoft dot net

Description:

[line "182"] [id "950103"] [msg "path traversal attack"] [data "../"] [hostname 
"test.test.rh"] [uri "/contentlounge/updateservice/cms_demo/cms//../cms.php"] 
[unique_id "UV2MrQoAAGMAAE356XkF"]


in the folder /cms is a simple index.php with header('Location: ../cms.php');
every normal browser translates path and does not trigger modsec
php triggers the "path traversal"-rule


Expected result:

call the URL /contentlounge/updateservice/cms_demo/cms/cms.php

Actual result:
--
calling the URL /contentlounge/updateservice/cms_demo/cms//../cms.php






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

Bug #64582 [Opn]: file_get_contents() handles redirects wrong

[johannes]

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

 ID: 64582
 Updated by: johan...@php.net
 Reported by:spam2 at rhsoft dot net
 Summary:file_get_contents() handles redirects wrong
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.4.13
 Block user comment: N
 Private report: N

 New Comment:

RFC 2616 Section 14.30 requires "a single absolute URI." for the location 
header. Any relative location is not standards compliant.


Previous Comments:

[2013-04-04 14:55:58] spam2 at rhsoft dot net

Description:

[line "182"] [id "950103"] [msg "path traversal attack"] [data "../"] [hostname 
"test.test.rh"] [uri "/contentlounge/updateservice/cms_demo/cms//../cms.php"] 
[unique_id "UV2MrQoAAGMAAE356XkF"]


in the folder /cms is a simple index.php with header('Location: ../cms.php');
every normal browser translates path and does not trigger modsec
php triggers the "path traversal"-rule


Expected result:

call the URL /contentlounge/updateservice/cms_demo/cms/cms.php

Actual result:
--
calling the URL /contentlounge/updateservice/cms_demo/cms//../cms.php






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

Req #19621 [Csd]: Math needs a "sign()" function

[johannes]

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

 ID: 19621
 Updated by: johan...@php.net
 Reported by:bill at softky dot com
 Summary:Math needs a "sign()" function
 Status: Closed
 Type:   Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
 Operating System:   Mandrake linux
 PHP Version:4.2.0
-Assigned To:
+Assigned To:johannes
 Block user comment: N
 Private report: N

 New Comment:

For usort() this is not needed. function($a,$b) { return $a['age'] - $b['age']; 
} is fine.


Previous Comments:

[2013-04-04 15:22:54] php at yopmail dot com

sign is very usefull in usort function
exemple :

"John","age"=>20],
["name"=>"Jack","age"=>30],
["name"=>"Paul","age"=>25],
]

usort($people,function($a, $b){
 return sign($a['age'] - $b['age']);
});
?>


[2011-09-26 14:30:22] tom at kera dot name

Patrick, adding a new library function _absolutely_ breaks BC.

For example:



Do you want every script that declares a function `sign` to suddenly not work 
any more? How would this *not* be a compatibility issue?


[2011-04-09 16:51:11] bogdan at moongate dot ro

Seconded. I've always rolled my own in PHP, but this is typically used in small 
loops executed a lot, so moving this logic into the PHP core would probably 
make a difference. If you're concerned sign() might already be used by various 
existing scripts, why not implement is as the more math-like sgn()?


[2011-02-25 10:14:51] patrick at ibuildings dot nl

I also searched for a sign() function and ended up here. But I disagree with 
Andrey's arguments not to include it into PHP.

Since when is it a policy to *not* include a function, simply because it does 
not exist in a number of other languages? Doesn't PHP have its own 'vision'? 
Secondly, a new function should not break BC.

As Bill stated, it would complement the abs() function and make the Math list a 
more complete list, even though it's a simple function. It seems a better idea 
to me to add "sign()" then let's say "goto".


[2002-10-03 02:32:28] and...@php.net

Quick search showed that there is no well know scripting language that has such 
function. C++/C# has this but they are not scripting languages.
The following code does the same. Also we have to think about BC(backward 
compatibility) with older scripts.
function sign($x){
 return (int)((abs($x)-$x)? -1:$x>0);
}

Thank you for you suggestion.





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


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

Req #19621 [Com]: Math needs a "sign()" function

[php at yopmail dot com]

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

 ID: 19621
 Comment by: php at yopmail dot com
 Reported by:bill at softky dot com
 Summary:Math needs a "sign()" function
 Status: Closed
 Type:   Feature/Change Request
 Package:Feature/Change Request
 Operating System:   Mandrake linux
 PHP Version:4.2.0
 Block user comment: N
 Private report: N

 New Comment:

sign is very usefull in usort function
exemple :

"John","age"=>20],
["name"=>"Jack","age"=>30],
["name"=>"Paul","age"=>25],
]

usort($people,function($a, $b){
 return sign($a['age'] - $b['age']);
});
?>


Previous Comments:

[2011-09-26 14:30:22] tom at kera dot name

Patrick, adding a new library function _absolutely_ breaks BC.

For example:



Do you want every script that declares a function `sign` to suddenly not work 
any more? How would this *not* be a compatibility issue?


[2011-04-09 16:51:11] bogdan at moongate dot ro

Seconded. I've always rolled my own in PHP, but this is typically used in small 
loops executed a lot, so moving this logic into the PHP core would probably 
make a difference. If you're concerned sign() might already be used by various 
existing scripts, why not implement is as the more math-like sgn()?


[2011-02-25 10:14:51] patrick at ibuildings dot nl

I also searched for a sign() function and ended up here. But I disagree with 
Andrey's arguments not to include it into PHP.

Since when is it a policy to *not* include a function, simply because it does 
not exist in a number of other languages? Doesn't PHP have its own 'vision'? 
Secondly, a new function should not break BC.

As Bill stated, it would complement the abs() function and make the Math list a 
more complete list, even though it's a simple function. It seems a better idea 
to me to add "sign()" then let's say "goto".


[2002-10-03 02:32:28] and...@php.net

Quick search showed that there is no well know scripting language that has such 
function. C++/C# has this but they are not scripting languages.
The following code does the same. Also we have to think about BC(backward 
compatibility) with older scripts.
function sign($x){
 return (int)((abs($x)-$x)? -1:$x>0);
}

Thank you for you suggestion.



[2002-09-26 13:52:07] bill at softky dot com

The wonderful math-function list is missing a very important and simple 
function: sign().  The is the comlpementof abs(), and together with abs() 
allows you to separate the magnitude and sign of a number, e.g. for graphing 
purposes (it's hard to graph a negative number of pixels, and displaying money 
as "$-99" looks dumb). 

It's a one-line function, so I've already written my own, but it really ought 
to be built-in. 

Thanks!





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

[PHP-BUG] Bug #64582 [NEW]: file_get_contents() handles redirects wrong

[spam2 at rhsoft dot net]

From: spam2 at rhsoft dot net
Operating system: Linux
PHP version:  5.4.13
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:file_get_contents() handles redirects wrong

Description:

[line "182"] [id "950103"] [msg "path traversal attack"] [data "../"]
[hostname "test.test.rh"] [uri
"/contentlounge/updateservice/cms_demo/cms//../cms.php"] [unique_id
"UV2MrQoAAGMAAE356XkF"]


in the folder /cms is a simple index.php with header('Location:
../cms.php');
every normal browser translates path and does not trigger modsec
php triggers the "path traversal"-rule


Expected result:

call the URL /contentlounge/updateservice/cms_demo/cms/cms.php

Actual result:
--
calling the URL /contentlounge/updateservice/cms_demo/cms//../cms.php

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

Bug #44337 [Com]: PDO::FETCH_CLASS and visibility private (private constructor, private property)

[technik at thomas-heuer dot eu]

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

 ID: 44337
 Comment by: technik at thomas-heuer dot eu
 Reported by:uwendel at mysql dot com
 Summary:PDO::FETCH_CLASS and visibility private (private
 constructor, private property)
 Status: No Feedback
 Type:   Bug
 Package:PDO related
 Operating System:   *
 PHP Version:5.2CVS-2008-03-05 (CVS)
 Block user comment: N
 Private report: N

 New Comment:

This bug is still open;

$ php --version
PHP 5.3.10-1ubuntu3.6 with Suhosin-Patch (cli) (built: Mar 11 2013 14:31:48)


Complete test case follows.

test database:
-

CREATE DATABASE `test` DEFAULT CHARACTER SET utf8 COLLATE=utf8_unicode_ci;
USE `test`;

CREATE TABLE IF NOT EXISTS `test` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `value` varchar(255) COLLATE utf8_unicode_ci NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

INSERT INTO `test` (`id`, `value`) VALUES
(1, 'Some'),
(2, 'test'),
(3, 'entries'),
(4, 'in'),
(5, 'this'),
(6, 'database.');
-

example code:
-
$db = new PDO( 'mysql:host=localhost;port=3306;dbname=test;', 'root', 
'PASSWORD', array( PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8' ) );

class IdObject
{
private $id;
private $value;

public function setId( $id )
{
$this->id = (int) $id;
}

public function setValue( $value )
{
$this->value = $value . ' (via setter)';
}
}

$stmt = $db->prepare( 'SELECT `id`, `value` FROM `test`;' );
$stmt->execute();
$stmt->setFetchMode( PDO::FETCH_CLASS|PDO::FETCH_PROPS_LATE, 'IdObject' );
$objects = array();
while( $row = $stmt->fetch() )
{
$objects[] = $row;
}
var_dump( $objects );
-

example output:
-
object(IdObject)#3 (2) {
["id":"IdObject":private]=>
string(1) "1"
["value":"IdObject":private]=>
string(4) "Some"
}
-

As you can see, the private members were set without using the setter as 
expected. Even if you set up a magic method `__set()` it won't get used.

The same is true when using private constructors (objects are still 
initialized) or protected members or constructors.


Previous Comments:

[2012-08-09 18:32:45] Stephen dot Reay at me dot com

This bug still exists in PHP 5.3 - what extra information is required for this 
to 
be fixed?


[2009-05-03 01:00:11] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


[2009-04-25 14:56:12] j...@php.net

Why is this here? You should discuss stuff on the mailing lists, nobody 
seems to read the bug reports (who actually know the stuff..).


[2008-03-05 15:29:34] uwendel at mysql dot com

Description:

Please clearify if any of the following is a bug or a feature.

1) PDO::FETCH_CLASS and private constructor

PDO ignores the visibility "private" of a constructor and creates objects of 
the requested type when using PDO::FETCH_CLASS and PDOStatement->fetch().

Create a class with a private constructor and try to create an object of the 
class from somewhere outside of the class. PHP will print a fatal error as 
expected.

class private_constructor {
  private function __construct()
}
$obj = new private_constructor() --> Fatal error (OK)

Use PDOStatement->setFetchMode() to make PDO return objects of the type 
"private_constructor" when fetching results. setFetchMode() will return true 
and PDOStatement->fetch() will return objects of the type 
"private_constructor". In other words: PDO will ignore the visibility of the 
constructor and behave as if PDO would be a part of the class 
"private_constructor"

2) PDO::FETCH_CLASS and private properties

Something similar happens if you make PDO instantiate a class with private 
properties which have the same name as column in the result set. PDO does not 
bother about private and fills the appropriate properties with values from the 
result set.



Reproduce code:
---
 1 - private constructor -


php -r '$db = new PDO("sqlite:/tmp/foo"); $db->exec("DROP TABLE test"); 
$db->exec("CREATE TABLE test (id INT)"); $db->exec("INSERT INTO test(id) VALUES 
(1)"); $stmt = $db->prepare("SELECT id FROM test"); class private_constructor { 
public static $calls = 0; private function __construct() { 
printf("private_constructor: %d\

Bug #63709 [Com]: flock() doesn't trigger mandatory locks on linux

[mi+php at aldan dot algebra dot com]

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

 ID: 63709
 Comment by: mi+php at aldan dot algebra dot com
 Reported by:eric dot saintetienne at gmail dot com
 Summary:flock() doesn't trigger mandatory locks on linux
 Status: Analyzed
 Type:   Bug
 Package:Filesystem function related
 Operating System:   Linux
 PHP Version:5.3.19
 Block user comment: N
 Private report: N

 New Comment:

Eric, I'm confused. Are you saying, the problem I am illustrating with my test 
case is different? Should I file a separate bug-report?


Previous Comments:

[2013-04-04 08:32:28] eric dot saintetienne at gmail dot com

I appreciate your code and efforts but please stay focus on the topic: 
MANDATORY 
locks only. The issue is that PHP doesn't provide a standard way of triggering 
a 
mandatory lock.

MANDATORY locks are specific to Linux and occurs on a volume that is mounted 
with the "-o mand" mount flag.
ADVISORY locks exist on any system via flock() or lockf() calls and are not the 
subject of this thread.

Now I'm speaking to PHP developpers: how do you plan to fill in the gap?

Thanks


[2013-04-04 01:49:17] mi+php at aldan dot algebra dot com

This is my test case:



Running TWO of the above in parallel:
% ( php t.php < /dev/null & php t.php < /dev/null )  >& l
I see BOTH of them claim to have "successfully" gotten the lock:
% cat l
[1] 26815
t.php: 26815 21:48:34 /tmp/distd.pid successfully locked
t.php: 26814 21:48:34 /tmp/distd.pid successfully locked
t.php: 26815 21:48:37 exiting in peace
t.php: 26814 21:48:37 exiting in peace


[2013-04-02 07:58:42] eric dot saintetienne at gmail dot com

I hope we're still speaking of MANDATORY locks (the ones provided by "mount -o 
mand") and not standard file locks? Other locks (advisory) behave as expected.

So what's the solution you chose to allow locking a file with a MANDATORY lock 
using PHP?


[2013-04-01 23:01:23] mi+php at aldan dot algebra dot com

I am puzzled, what can the current behavior be possibly used for?

If the lock is not really locking (and it does not -- neither on Linux nor on 
FreeBSD), then why bother with it at all? And if nobody bothers, then why not 
fix it properly?

BTW, at least, on BSD the different locking mechanisms create compatible locks:

 The flock(), fcntl(2), and lockf(3) locks are compatible.
 Processes using different locking interfaces can cooperate
 over the same file safely. However, only one of such interfaces
 should be used within the same process.  If a file is locked by
 a process through flock(), any record within the file will be
 seen as locked from the viewpoint of another process using
 fcntl(2) or lockf(3), and vice versa.


[2012-12-07 09:43:12] eric dot saintetienne at gmail dot com

You're right, Python is smart and the trick is simple: fnctl module functions 
are coded such that they detect the type of the object they're given as 
argument. If it's an integer they assume it is a file descriptor otherwise they 
call its fileno() method to retrieve the file descriptor integer.

So it's a matter of adding your own fileno() method to the PHP standard file 
object and making the dio_* routines calling it, when not provided with an 
integer.

Does that makes sense to you?

It's a suggestion, at the end of the day it's your decision of how to handle 
this issue, even though it seems to, I'm actually not pushing to get direct io 
integrated at any cost (I don't have any stake) but I just feel it's the way to 
go.




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


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

Req #35746 [Opn->Csd]: Comparison of scalars & non-scalars w/o typecast should generate an error

[nikic]

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

 ID: 35746
 Updated by: ni...@php.net
 Reported by:schapht at verizon dot net
 Summary:Comparison of scalars & non-scalars w/o typecast
 should generate an error
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
-Package:Feature/Change Request
+Package:*General Issues
 Operating System:   Mac OS 10.4.3
 PHP Version:5.1.1
-Assigned To:
+Assigned To:nikic
 Block user comment: N
 Private report: N

 New Comment:

Not sure since when, but currently this is generating a "Object of class A 
could not be converted to int" notice => Closed :)


Previous Comments:

[2005-12-20 16:05:21] schapht at verizon dot net

Description:

When developing I find that comparison of a scalar and non-scalar is often 
unintentional and usually indicates a mistake elsewhere in the program.

It would be nice if comparing scalars and non-scalars generated a low-priority 
error message.

Reproduce code:
---
 $b;
?>

Expected result:

Notice: Comparison of scalar and non-scalar without a typecast. in test.php on 
line 8
1

Actual result:
--
1






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

Bug #64580 [Com]: sort() triggers type-conversion notice

[hanskrentel at yahoo dot de]

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

 ID: 64580
 Comment by: hanskrentel at yahoo dot de
 Reported by:hanskrentel at yahoo dot de
 Summary:sort() triggers type-conversion notice
 Status: Not a bug
 Type:   Bug
 Package:Arrays related
 PHP Version:5.4.13
 Block user comment: N
 Private report: N

 New Comment:

The `sort()` function explicitly states:

> don't change types

If no types are changed, why do I get a type conversion notice?

I can understand that for comparing those values, a sort-value of each 
array member must be obtained to create to do sorting, however, 
as long as the sort is successful, this should not create any notices.


Previous Comments:

[2013-04-04 12:47:18] ni...@php.net

Nothing to do with sort() this is just the usual behavior of the "<" operator. 
Try doing just "1 < new stdClass" and you'll get the same notice.


[2013-04-04 12:43:42] hanskrentel at yahoo dot de

Description:

Under specific circumstances the sort() function with the `SORT_REGULAR` sort-
flag triggers type-conversion notices even it is documented that no type-
conversion is done[1]:

> SORT_REGULAR - compare items normally (don't change types)

This notice is *only* given if an object value is sorted with an integer or 
float. 

The notices for these two cases are as following:

> Notice: Object of class stdClass could not be converted to int

> Notice: Object of class stdClass could not be converted to double

Those errors are triggered in /Zend (lxr search http://goo.gl/Zu7Zl).

The sort() function returns TRUE despite the Notice and as far I was able to 
find out, the sorting is done, so this looks correct to me.

Also this error only happens with sorting objects with integers and floats. I 
also tested against NULL, boolean (TRUE/FALSE), string, array, object and 
resource and these did not trigger the notice.

I would not classify this as documentation bug because these are very specific 
circumstances which makes me assume that this is not the intended behavior.

Something might have been just overlooked for these two cases with 
`SORT_REGULAR`.

It should be said that there are related issues documented in #54980 and 
#54259 over which I originally stumbled. 

[1] http://php.net/sort


Test script:
---
 'value']];
sort($subject);


Actual result:
--
Notice: Object of class stdClass could not be converted to int in [...] on line 
3






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

Bug #64580 [Opn->Nab]: sort() triggers type-conversion notice

[nikic]

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

 ID: 64580
 Updated by: ni...@php.net
 Reported by:hanskrentel at yahoo dot de
 Summary:sort() triggers type-conversion notice
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:Arrays related
 PHP Version:5.4.13
 Block user comment: N
 Private report: N

 New Comment:

Nothing to do with sort() this is just the usual behavior of the "<" operator. 
Try doing just "1 < new stdClass" and you'll get the same notice.


Previous Comments:

[2013-04-04 12:43:42] hanskrentel at yahoo dot de

Description:

Under specific circumstances the sort() function with the `SORT_REGULAR` sort-
flag triggers type-conversion notices even it is documented that no type-
conversion is done[1]:

> SORT_REGULAR - compare items normally (don't change types)

This notice is *only* given if an object value is sorted with an integer or 
float. 

The notices for these two cases are as following:

> Notice: Object of class stdClass could not be converted to int

> Notice: Object of class stdClass could not be converted to double

Those errors are triggered in /Zend (lxr search http://goo.gl/Zu7Zl).

The sort() function returns TRUE despite the Notice and as far I was able to 
find out, the sorting is done, so this looks correct to me.

Also this error only happens with sorting objects with integers and floats. I 
also tested against NULL, boolean (TRUE/FALSE), string, array, object and 
resource and these did not trigger the notice.

I would not classify this as documentation bug because these are very specific 
circumstances which makes me assume that this is not the intended behavior.

Something might have been just overlooked for these two cases with 
`SORT_REGULAR`.

It should be said that there are related issues documented in #54980 and 
#54259 over which I originally stumbled. 

[1] http://php.net/sort


Test script:
---
 'value']];
sort($subject);


Actual result:
--
Notice: Object of class stdClass could not be converted to int in [...] on line 
3






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

[PHP-BUG] Bug #64580 [NEW]: sort() triggers type-conversion notice

[hanskrentel at yahoo dot de]

From: hanskrentel at yahoo dot de
Operating system: 
PHP version:  5.4.13
Package:  Arrays related
Bug Type: Bug
Bug description:sort() triggers type-conversion notice

Description:

Under specific circumstances the sort() function with the `SORT_REGULAR`
sort-
flag triggers type-conversion notices even it is documented that no type-
conversion is done[1]:

> SORT_REGULAR - compare items normally (don't change types)

This notice is *only* given if an object value is sorted with an integer or

float. 

The notices for these two cases are as following:

> Notice: Object of class stdClass could not be converted to int

> Notice: Object of class stdClass could not be converted to double

Those errors are triggered in /Zend (lxr search http://goo.gl/Zu7Zl).

The sort() function returns TRUE despite the Notice and as far I was able
to 
find out, the sorting is done, so this looks correct to me.

Also this error only happens with sorting objects with integers and floats.
I 
also tested against NULL, boolean (TRUE/FALSE), string, array, object and 
resource and these did not trigger the notice.

I would not classify this as documentation bug because these are very
specific 
circumstances which makes me assume that this is not the intended
behavior.

Something might have been just overlooked for these two cases with 
`SORT_REGULAR`.

It should be said that there are related issues documented in #54980 and 
#54259 over which I originally stumbled. 

[1] http://php.net/sort


Test script:
---
 'value']];
sort($subject);


Actual result:
--
Notice: Object of class stdClass could not be converted to int in [...] on
line 3

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

Bug #63709 [Ana]: flock() doesn't trigger mandatory locks on linux

[eric dot saintetienne at gmail dot com]

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

 ID: 63709
 User updated by:eric dot saintetienne at gmail dot com
 Reported by:eric dot saintetienne at gmail dot com
 Summary:flock() doesn't trigger mandatory locks on linux
 Status: Analyzed
 Type:   Bug
 Package:Filesystem function related
 Operating System:   Linux
 PHP Version:5.3.19
 Block user comment: N
 Private report: N

 New Comment:

I appreciate your code and efforts but please stay focus on the topic: 
MANDATORY 
locks only. The issue is that PHP doesn't provide a standard way of triggering 
a 
mandatory lock.

MANDATORY locks are specific to Linux and occurs on a volume that is mounted 
with the "-o mand" mount flag.
ADVISORY locks exist on any system via flock() or lockf() calls and are not the 
subject of this thread.

Now I'm speaking to PHP developpers: how do you plan to fill in the gap?

Thanks


Previous Comments:

[2013-04-04 01:49:17] mi+php at aldan dot algebra dot com

This is my test case:



Running TWO of the above in parallel:
% ( php t.php < /dev/null & php t.php < /dev/null )  >& l
I see BOTH of them claim to have "successfully" gotten the lock:
% cat l
[1] 26815
t.php: 26815 21:48:34 /tmp/distd.pid successfully locked
t.php: 26814 21:48:34 /tmp/distd.pid successfully locked
t.php: 26815 21:48:37 exiting in peace
t.php: 26814 21:48:37 exiting in peace


[2013-04-02 07:58:42] eric dot saintetienne at gmail dot com

I hope we're still speaking of MANDATORY locks (the ones provided by "mount -o 
mand") and not standard file locks? Other locks (advisory) behave as expected.

So what's the solution you chose to allow locking a file with a MANDATORY lock 
using PHP?


[2013-04-01 23:01:23] mi+php at aldan dot algebra dot com

I am puzzled, what can the current behavior be possibly used for?

If the lock is not really locking (and it does not -- neither on Linux nor on 
FreeBSD), then why bother with it at all? And if nobody bothers, then why not 
fix it properly?

BTW, at least, on BSD the different locking mechanisms create compatible locks:

 The flock(), fcntl(2), and lockf(3) locks are compatible.
 Processes using different locking interfaces can cooperate
 over the same file safely. However, only one of such interfaces
 should be used within the same process.  If a file is locked by
 a process through flock(), any record within the file will be
 seen as locked from the viewpoint of another process using
 fcntl(2) or lockf(3), and vice versa.


[2012-12-07 09:43:12] eric dot saintetienne at gmail dot com

You're right, Python is smart and the trick is simple: fnctl module functions 
are coded such that they detect the type of the object they're given as 
argument. If it's an integer they assume it is a file descriptor otherwise they 
call its fileno() method to retrieve the file descriptor integer.

So it's a matter of adding your own fileno() method to the PHP standard file 
object and making the dio_* routines calling it, when not provided with an 
integer.

Does that makes sense to you?

It's a suggestion, at the end of the day it's your decision of how to handle 
this issue, even though it seems to, I'm actually not pushing to get direct io 
integrated at any cost (I don't have any stake) but I just feel it's the way to 
go.


[2012-12-07 09:08:01] ahar...@php.net

That's true, but they're still somewhat interchangeable in Python — higher 
level file objects returned by open() work with fcntl methods. That wouldn't be 
the case if we bundled dio without further work.




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


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