#49471 [NEW]: Multiple object selection operators in quoted strings

[tudor at tudorholton dot com]

From: tudor at tudorholton dot com
Operating system: Ubuntu
PHP version:  5.2SVN-2009-09-05 (snap)
PHP Bug Type: Scripting Engine problem
Bug description:  Multiple object selection operators in quoted strings

Description:

This is actually on Ubuntu Jaunty which is PHP version 5.2.6-3ubuntu4.2

Using multiple object access operators in a row inside a double-quoted
string causes the error:
Catchable fatal error: Object of class ... could not be converted to
string

The problem is that the operators are interpreted from left to right and
then converted to string.  The last operation should be that the object is
converted to a string.

This is particularly important when using OO code because frequently the
current object ($this) references another object and then gets an attribute
from that. e.g. $this->that->attribute

Reproduce code:
---
a = new A();
}

function output() {
echo "$this->attr";
}
}

$b = new B();
$b->output();
echo "$b->attr";
echo "$b->a->attr";
?>

Expected result:

Hello B!Hello B!Hello A!

Actual result:
--
Hello B!Hello B!
Catchable fatal error: Object of class A could not be converted to string
in test.php on line 19

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

#42849 [Com]: Configuration File (php.ini) Path incorrect

[headnok at yahoo dot com]

 ID:   42849
 Comment by:   headnok at yahoo dot com
 Reported By:  inglis-php at yahoo dot com dot au
 Status:   No Feedback
 Bug Type: *General Issues
 Operating System: win xp pro
 PHP Version:  5.2.4
 New Comment:

I had the same damn problem and was pulling my hair out for a week. 
Please!!! Either instruct the users to move the php.ini file into the
C:\windows directory your installation instructions or fix the problem! 
Please!!!


Previous Comments:


[2008-12-11 06:22:55] yaddayadda at mailinator dot com

I'm a new user of PHP/MySQL. I installed both and phpMyAdmin with no
deviation from the instructions and could not get phpMyAdmin to work at
all (it could not load the mysql extension). Despite reading numerous
posts about what to uncomment in php.ini and what to add to the PATH,
whatever I did did not seem to have any effect. Only after I ran
phpinfo() did I find out that the path to php.ini was somehow pointing
the Windows folder. I was editing php.ini in C:\PHP. 

There are many, many frustrated students and beginners out there having
this exact issue. They don't know it is a bug. They are told to "just
copy php.ini to your Windows folder" as a fix. I did not want to do this
because I set the PATH to C:\PHP so I knew it should be looking there
and NOT in C:\Windows (because there was no php.ini there, it should
continue looking through the locations specified in PATH). I still do
not know how to change this and ended up moving the file out of
frustration and everything began to work. 

So many people are experiencing this frustration and wasting hours
trying to fix it. Some are even giving up and moving to hosts that
already have PHP installed rather than continue to learn on their own.
If you install PHP to C:\PHP, the php.ini file it looks for should be
there!



[2008-12-01 15:59:02] rafael dot amador at gmail dot com

Bug #39191



[2008-12-01 15:55:46] rafael dot amador at gmail dot com

Bug #37919 PHP < The same bug



[2007-10-13 01:00:01] php-bugs at lists dot php dot net

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



[2007-10-05 15:23:16] j...@php.net

Exactly what does phpinfo() have about php.ini? There are 2 places in
the output, paste both here..(in the very beginning of the output..)




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/42849

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

#48746 [Fbk]: Unable to browse directories within Junction Points

[pajoye]

 ID:   48746
 Updated by:   paj...@php.net
 Reported By:  ddkees at illinois dot edu
 Status:   Feedback
 Bug Type: Directory function related
 Operating System: win32 only - Windows Server 2003
 PHP Version:  5.3.0
 Assigned To:  pajoye
 New Comment:

Please note that it is again a XP/2k3 only issue. Debugging/fixing now.


Previous Comments:


[2009-09-04 17:36:30] paj...@php.net

@shoresofnowhere at gmail dot com

ok, I can reproduce it now. I will come back as soon as I have a fix.



[2009-09-04 17:26:49] paj...@php.net

@shoresofnowhere at gmail dot com

I suppose you mean:
c:\Dir
   |_ one.php
   |_ Dir3 (junction to d:\dir)
  |_ two.php

Using this constellation, here is my output on xp SP3:

C:\mnt>junction dir3
Junction v1.05 - ..
...
C:\mnt\dir3: JUNCTION
   Substitute Name: c:\test

C:\mnt>\test\php53vc6ts\php.exe one.php
bool(true)


Are you sure:
- apache has been restarted after the update?
- the right version is used?

Can you try in CLI as well please?





[2009-09-04 11:44:08] shoresofnowhere at gmail dot com

Sorry but the latest snapshot still has problems:

Dir  directory
one.php  file in dir directory
Dir2 junction in dir to dir3 on another drive
two.php  file in dir3

in one.php:
is_file(./dir2/two.php) returns FALSE!

Working on XP SP3 under Apache 2.2.13



[2009-09-04 08:11:06] mats dot lindh at gmail dot com

Everything seems to work OK with a build from 2009-09-03. Thanks for
fixing the issue!



[2009-09-03 10:10:14] phpstuff at cresstone dot com

I'm getting good test behavior from the that snapshot. More tellingly,
the original script I've been trying to run is now working correctly.

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
http://bugs.php.net/48746

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

#49464 [Opn]: php_sockets build broken

[kalle]

 ID:   49464
 Updated by:   ka...@php.net
 Reported By:  raulsalitrero at gmail dot com
 Status:   Open
 Bug Type: Compile Failure
 Operating System: Windows Xp SP3
 PHP Version:  5.3SVN-2009-09-04 (SVN)
 New Comment:

The fix for this is pretty simple:
http://pastie.org/605649

However this C2491 only occurs when building sockets shared because of
the wrong exporting declarings used


Previous Comments:


[2009-09-04 03:44:59] raulsalitrero at gmail dot com

Description:

php_sockets.dll build is broken in win vc9, with the next error

ext\sockets\sockets.c(327) : error C2491: 'php_sockets_le_socket' :
definition of dllimport function not allowed

tried building the last svn source with the same result.

using vc9 to compile, the error is also observable in the windows
sanpshots compile logs 

the bug was introduced in revision: 287911 - export le_socket from
ext/sockets
changing files:
-/php/php-src/branches/PHP_5_3/ext/sockets/php_sockets.h
-/php/php-src/branches/PHP_5_3/ext/sockets/sockets.c

Reproduce code:
---
use nmake to compile with vc9 compiler

Expected result:

php_sockets.dll is built

Actual result:
--
php_sockets.dll is missing from the result build





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

#49470 [Opn->Ver]: FILTER_SANITIZE_EMAIL does not work

[jani]

 ID:   49470
 Updated by:   j...@php.net
 Reported By:  contact at ghetmedia dot com
-Status:   Open
+Status:   Verified
 Bug Type: Filter related
 Operating System: *
 PHP Version:  5.2SVN-2009-09-04 (snap)


Previous Comments:


[2009-09-04 23:26:46] contact at ghetmedia dot com

Description:

Filter_var and it's flag FILTER_SANITIZE_EMAIL do absolutely nothing.

Reproduce code:
---
echo filter_var('t...@t//est.com', FILTER_SANITIZE_EMAIL);

Expected result:

t...@test.com

Actual result:
--
t...@t//est.com





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

#49470 [NEW]: Filter_var Sanitize Email Absolutely does not work

[contact at ghetmedia dot com]

From: contact at ghetmedia dot com
Operating system: Windows XP
PHP version:  5.2SVN-2009-09-04 (snap)
PHP Bug Type: Filter related
Bug description:  Filter_var Sanitize Email Absolutely does not work

Description:

Filter_var and it's flag FILTER_SANITIZE_EMAIL do absolutely nothing.

Reproduce code:
---
echo filter_var('t...@t//est.com', FILTER_SANITIZE_EMAIL);

Expected result:

t...@test.com

Actual result:
--
t...@t//est.com

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

#39312 [Com]: Cannot install PDO_OCI

[jnichols959 at gmail dot com]

 ID:   39312
 Comment by:   jnichols959 at gmail dot com
 Reported By:  andrew dot nagy at villanova dot edu
 Status:   Assigned
 Bug Type: PDO related
 Operating System: Linux
 PHP Version:  5.2.9
 Assigned To:  sixd
 New Comment:

seems like pdo_oci will configure, compile and run correctly with the
proper environment variables and configure commands everywhere *except*
on mac os x.  the patch suggested in comment
http://bugs.php.net/bug.php?id=39312#c144683 of this bug fixes it on mac
os x (tested with 10.2.0.4 instantclient and os x 10.5.8) and also works
on linux (centos 5.3 x86_64 and 10.2.0.4 instantclient also x86_64).

can someone with access test and hopefully apply the patch so os x
users can use pdo_oci without hacking the configure script?


Previous Comments:


[2009-07-14 14:36:16] cmroddy at gmail dot com

following tony2001's directions exactly i am of course able to 
reproduce this problem. i got the thing to build once a couple of years

ago but haven't succeeded since then. as i recall it took several days

of continuous shell games with the configure script.

it seems there is no one around to maintain PDO_OCI. i can sympathize 
with this. i certainly wouldn't want to maintain it either. but if this

build can't be made to work even given explicit paths to every single 
file it needs, then PDO_OCI needs to be dropped entirely and deleted 
from the documentation.



[2009-03-18 23:06:48] esimard at mediagrif dot com

I will assume that "assigned" means open since this bug doesn't seem
fixed yet.

I tried to install instantclient 10.2.0.4 with php-5.2.9 on RHEL5.

Tried it with the RPMs, didn't work, so I followed the instructions
that other people suggested here on the php.net instantclient page.

I installed the client in /usr/lib/oracle/10.2.0.4/client/
and the sdk in /usr/lib/oracle/10.2.0.4/client/sdk/include/

I tried to configure with the switches: 

--with-oci8=shared,instantclient,/usr/lib/oracle/10.2.0.4/client
--with-pdo-oci=instantclient,/usr/lib/oracle,10.2.0.4

without success, getting the error I'm too dumb to figure out where the
libraries are in your Instant Client install. 

After checking it out with strace, it seems that it tries to find the
files(headers and libs in the wrong directories). Also a import of
ld.so.conf with the libs dir did not help apparently.

So here is what I saw:

stat64("/usr/lib/oracle/include/oracle/10.2.0.4/client/oci.h",
0xbf7f53b8) = -1 ENOENT (No such file or directory)
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
stat64("/usr/lib/oracle/lib/oracle/10.2.0.4/client/include/oci.h",
0xbf7f52e8) = -1 ENOENT (No such file or directory)
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
stat64("/usr/lib/oracle/sdk/include/oci.h", 0xbf7f5218) = -1 ENOENT (No
such file or directory)
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
stat64("/usr/lib/oracle/client/include/oci.h", 0xbf7f5148) = -1 ENOENT
(No such file or directory)

fixed temporary with ln -s /usr/lib/oracle/10.2.0.4/client/sdk/
/usr/lib/oracle/sdk

and

stat64("/usr/lib/oracle/lib/oracle/10.2.0.4/client/lib/libclntsh.so",
0xbfa5a858) = -1 ENOENT (No such file or directory)
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
stat64("/usr/lib/oracle/client/lib/libclntsh.so", 0xbfa5a788) = -1
ENOENT (No such file or directory)
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
stat64("/usr/lib/oracle/libclntsh.so", 0xbfa5a6b8) = -1 ENOENT (No such
file or directory)

fixed temporary with ln -s /usr/lib/oracle/10.2.0.4/client/
/usr/lib/oracle/client

ln -s /usr/lib/oracle/10.2.0.4/client/
/usr/lib/oracle/10.2.0.4/client/lib

which is somewhat ghetto.

I would like to hear if you have a smoother way to do that. If this bug
is not considered open, can someone please email me if you have another
workaround if this comment gets deleted?



[2009-01-29 11:37:33] michael-ring at t-online dot de

I've found a problem under MacOSX, the extension'.so' is hardcoded in
the library detection for pdo_oci. This breaks under MacOSX because
libclntsh has '.dylib' extension instead of '.so'.

To solve this problem the following patch has to be applied. Shall I
open a new bug in order to get this included in upcomming php-Versions?

--- ext/pdo_oci/config.m4.orig  2009-01-28 23:31:07.0
+0100
+++ ext/pdo_oci/config.m4   2009-01-28 23:34:39.0 +0100
@@ -97,11 +97,11 @@
 else
   AC_MSG_ERROR([I'm too dumb to figure out where the include dir
is in your Instant Client install])
 fi
-if test -f
"$PDO_OCI_IC_PREFIX/lib/oracle/$PDO

#48746 [Com]: Unable to browse directories within Junction Points

[phpstuff at cresstone dot com]

 ID:   48746
 Comment by:   phpstuff at cresstone dot com
 Reported By:  ddkees at illinois dot edu
 Status:   Feedback
 Bug Type: Directory function related
 Operating System: win32 only - Windows Server 2003
 PHP Version:  5.3.0
 Assigned To:  pajoye
 New Comment:

Using junctions: is_file and file_exists are giving incorrect behavior
(false on files). is_dir as well, false on directories in the junction
and the junction itself.

The same functions are working well with symlinks.

If you need testing for this, you have mail.


Previous Comments:


[2009-09-04 20:45:25] paj...@php.net

@[4 Sep 8:20pm UTC] phpstuff at cresstone dot com

Using is_dir and is_file or file_exists and the cases you described,
does it work? (I don't think the filetype issue is related to what we
discuss here).



[2009-09-04 20:20:02] phpstuff at cresstone dot com

I was able replicate shoresofnowhere's behavior using windows 7...


I created a junction to a folder on another drive; running is_file() on
a file inside that junction returned false, as did is_dir(). Curious to
see what php thought it was looking at, I tested filetype(), which threw
an error.

I then tested symlinks in the same manner, and got good behavior.
Symlinks seem to be a good workaround for this issue.

Test log follows:


C:\mnt\test>mklink /J junction_otherDrive f:\downloads
Junction created for junction_otherDrive <<===>> f:\downloads

C:\mnt\test>mklink /D symlink_otherDrive f:\downloads
symbolic link created for symlink_otherDrive <<===>> f:\downloads

C:\mnt\test>dir
 Volume in drive C is coreI7_System
 Volume Serial Number is 38E2-2B62

 Directory of C:\mnt\test

2009.09.04  16.05  .
2009.09.04  16.05  ..
2009.09.04  16.05 junction_otherDrive [f:\downloads]
2009.09.04  16.05 symlink_otherDrive [f:\downloads]
   0 File(s)  0 bytes
   4 Dir(s)  30,034,223,104 bytes free

C:\mnt\test>php -r var_dump(filetype('junction_otherdrive'));
PHP Warning:  filetype(): Lstat failed for junction_otherdrive in
Command line code on line 1

Warning: filetype(): Lstat failed for junction_otherdrive in Command
line code on line 1
bool(false)

C:\mnt\test>php -r
var_dump(filetype('junction_otherdrive\php-5.2.0-win32-installer.msi'));
PHP Warning:  filetype(): Lstat failed for
junction_otherdrive\php-5.2.0-win32-installer.msi in Comm
and line code on line 1

Warning: filetype(): Lstat failed for
junction_otherdrive\php-5.2.0-win32-installer.msi in Command l
ine code on line 1
bool(false)

C:\mnt\test>php -r var_dump(filetype('symlink_otherdrive'));
string(3) "dir"

C:\mnt\test>php -r
var_dump(filetype('symlink_otherdrive\php-5.2.0-win32-installer.msi'));
string(4) "file"



[2009-09-04 18:32:33] paj...@php.net

Ignore my last two comments, it works perfectly using what you
describe. I was testing it from another VM where this junction did not
exist.

I added a include 'dir3/two.php' to one.php, two.php being a simple
echo "two.php"
The output:

C:\test>\php53\debug_ts\php.exe -n one.php
two.php
bool(true)

C:\test>junction dir3


C:\test\dir3: JUNCTION
   Substitute Name: e:\test


C:\test>dir dir3
 ...
09/04/2009  07:33 PM24 two.php
   1 File(s) 24 bytes
   2 Dir(s) 202,975,232 bytes free




[2009-09-04 17:50:34] paj...@php.net

Please note that it is again a XP/2k3 only issue. Debugging/fixing now.



[2009-09-04 17:36:30] paj...@php.net

@shoresofnowhere at gmail dot com

ok, I can reproduce it now. I will come back as soon as I have a fix.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/48746

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

#48746 [Fbk]: Unable to browse directories within Junction Points

[pajoye]

 ID:   48746
 Updated by:   paj...@php.net
 Reported By:  ddkees at illinois dot edu
 Status:   Feedback
 Bug Type: Directory function related
 Operating System: win32 only - Windows Server 2003
 PHP Version:  5.3.0
 Assigned To:  pajoye
 New Comment:

@[4 Sep 8:20pm UTC] phpstuff at cresstone dot com

Using is_dir and is_file or file_exists and the cases you described,
does it work? (I don't think the filetype issue is related to what we
discuss here).


Previous Comments:


[2009-09-04 20:20:02] phpstuff at cresstone dot com

I was able replicate shoresofnowhere's behavior using windows 7...


I created a junction to a folder on another drive; running is_file() on
a file inside that junction returned false, as did is_dir(). Curious to
see what php thought it was looking at, I tested filetype(), which threw
an error.

I then tested symlinks in the same manner, and got good behavior.
Symlinks seem to be a good workaround for this issue.

Test log follows:


C:\mnt\test>mklink /J junction_otherDrive f:\downloads
Junction created for junction_otherDrive <<===>> f:\downloads

C:\mnt\test>mklink /D symlink_otherDrive f:\downloads
symbolic link created for symlink_otherDrive <<===>> f:\downloads

C:\mnt\test>dir
 Volume in drive C is coreI7_System
 Volume Serial Number is 38E2-2B62

 Directory of C:\mnt\test

2009.09.04  16.05  .
2009.09.04  16.05  ..
2009.09.04  16.05 junction_otherDrive [f:\downloads]
2009.09.04  16.05 symlink_otherDrive [f:\downloads]
   0 File(s)  0 bytes
   4 Dir(s)  30,034,223,104 bytes free

C:\mnt\test>php -r var_dump(filetype('junction_otherdrive'));
PHP Warning:  filetype(): Lstat failed for junction_otherdrive in
Command line code on line 1

Warning: filetype(): Lstat failed for junction_otherdrive in Command
line code on line 1
bool(false)

C:\mnt\test>php -r
var_dump(filetype('junction_otherdrive\php-5.2.0-win32-installer.msi'));
PHP Warning:  filetype(): Lstat failed for
junction_otherdrive\php-5.2.0-win32-installer.msi in Comm
and line code on line 1

Warning: filetype(): Lstat failed for
junction_otherdrive\php-5.2.0-win32-installer.msi in Command l
ine code on line 1
bool(false)

C:\mnt\test>php -r var_dump(filetype('symlink_otherdrive'));
string(3) "dir"

C:\mnt\test>php -r
var_dump(filetype('symlink_otherdrive\php-5.2.0-win32-installer.msi'));
string(4) "file"



[2009-09-04 18:32:33] paj...@php.net

Ignore my last two comments, it works perfectly using what you
describe. I was testing it from another VM where this junction did not
exist.

I added a include 'dir3/two.php' to one.php, two.php being a simple
echo "two.php"
The output:

C:\test>\php53\debug_ts\php.exe -n one.php
two.php
bool(true)

C:\test>junction dir3


C:\test\dir3: JUNCTION
   Substitute Name: e:\test


C:\test>dir dir3
 ...
09/04/2009  07:33 PM24 two.php
   1 File(s) 24 bytes
   2 Dir(s) 202,975,232 bytes free




[2009-09-04 17:50:34] paj...@php.net

Please note that it is again a XP/2k3 only issue. Debugging/fixing now.



[2009-09-04 17:36:30] paj...@php.net

@shoresofnowhere at gmail dot com

ok, I can reproduce it now. I will come back as soon as I have a fix.



[2009-09-04 17:26:49] paj...@php.net

@shoresofnowhere at gmail dot com

I suppose you mean:
c:\Dir
   |_ one.php
   |_ Dir3 (junction to d:\dir)
  |_ two.php

Using this constellation, here is my output on xp SP3:

C:\mnt>junction dir3
Junction v1.05 - ..
...
C:\mnt\dir3: JUNCTION
   Substitute Name: c:\test

C:\mnt>\test\php53vc6ts\php.exe one.php
bool(true)


Are you sure:
- apache has been restarted after the update?
- the right version is used?

Can you try in CLI as well please?





The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/48746

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

#48746 [Com]: Unable to browse directories within Junction Points

[phpstuff at cresstone dot com]

 ID:   48746
 Comment by:   phpstuff at cresstone dot com
 Reported By:  ddkees at illinois dot edu
 Status:   Feedback
 Bug Type: Directory function related
 Operating System: win32 only - Windows Server 2003
 PHP Version:  5.3.0
 Assigned To:  pajoye
 New Comment:

I was able replicate shoresofnowhere's behavior using windows 7...


I created a junction to a folder on another drive; running is_file() on
a file inside that junction returned false, as did is_dir(). Curious to
see what php thought it was looking at, I tested filetype(), which threw
an error.

I then tested symlinks in the same manner, and got good behavior.
Symlinks seem to be a good workaround for this issue.

Test log follows:


C:\mnt\test>mklink /J junction_otherDrive f:\downloads
Junction created for junction_otherDrive <<===>> f:\downloads

C:\mnt\test>mklink /D symlink_otherDrive f:\downloads
symbolic link created for symlink_otherDrive <<===>> f:\downloads

C:\mnt\test>dir
 Volume in drive C is coreI7_System
 Volume Serial Number is 38E2-2B62

 Directory of C:\mnt\test

2009.09.04  16.05  .
2009.09.04  16.05  ..
2009.09.04  16.05 junction_otherDrive [f:\downloads]
2009.09.04  16.05 symlink_otherDrive [f:\downloads]
   0 File(s)  0 bytes
   4 Dir(s)  30,034,223,104 bytes free

C:\mnt\test>php -r var_dump(filetype('junction_otherdrive'));
PHP Warning:  filetype(): Lstat failed for junction_otherdrive in
Command line code on line 1

Warning: filetype(): Lstat failed for junction_otherdrive in Command
line code on line 1
bool(false)

C:\mnt\test>php -r
var_dump(filetype('junction_otherdrive\php-5.2.0-win32-installer.msi'));
PHP Warning:  filetype(): Lstat failed for
junction_otherdrive\php-5.2.0-win32-installer.msi in Comm
and line code on line 1

Warning: filetype(): Lstat failed for
junction_otherdrive\php-5.2.0-win32-installer.msi in Command l
ine code on line 1
bool(false)

C:\mnt\test>php -r var_dump(filetype('symlink_otherdrive'));
string(3) "dir"

C:\mnt\test>php -r
var_dump(filetype('symlink_otherdrive\php-5.2.0-win32-installer.msi'));
string(4) "file"


Previous Comments:


[2009-09-04 18:32:33] paj...@php.net

Ignore my last two comments, it works perfectly using what you
describe. I was testing it from another VM where this junction did not
exist.

I added a include 'dir3/two.php' to one.php, two.php being a simple
echo "two.php"
The output:

C:\test>\php53\debug_ts\php.exe -n one.php
two.php
bool(true)

C:\test>junction dir3


C:\test\dir3: JUNCTION
   Substitute Name: e:\test


C:\test>dir dir3
 ...
09/04/2009  07:33 PM24 two.php
   1 File(s) 24 bytes
   2 Dir(s) 202,975,232 bytes free




[2009-09-04 17:50:34] paj...@php.net

Please note that it is again a XP/2k3 only issue. Debugging/fixing now.



[2009-09-04 17:36:30] paj...@php.net

@shoresofnowhere at gmail dot com

ok, I can reproduce it now. I will come back as soon as I have a fix.



[2009-09-04 17:26:49] paj...@php.net

@shoresofnowhere at gmail dot com

I suppose you mean:
c:\Dir
   |_ one.php
   |_ Dir3 (junction to d:\dir)
  |_ two.php

Using this constellation, here is my output on xp SP3:

C:\mnt>junction dir3
Junction v1.05 - ..
...
C:\mnt\dir3: JUNCTION
   Substitute Name: c:\test

C:\mnt>\test\php53vc6ts\php.exe one.php
bool(true)


Are you sure:
- apache has been restarted after the update?
- the right version is used?

Can you try in CLI as well please?





[2009-09-04 11:44:08] shoresofnowhere at gmail dot com

Sorry but the latest snapshot still has problems:

Dir  directory
one.php  file in dir directory
Dir2 junction in dir to dir3 on another drive
two.php  file in dir3

in one.php:
is_file(./dir2/two.php) returns FALSE!

Working on XP SP3 under Apache 2.2.13



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/48746

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

#49464 [Opn->Csd]: php_sockets build broken

[pajoye]

 ID:   49464
 Updated by:   paj...@php.net
 Reported By:  raulsalitrero at gmail dot com
-Status:   Open
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: win32 only - Windows Xp SP3
 PHP Version:  5.3SVN-2009-09-04 (SVN)
-Assigned To:  
+Assigned To:  pajoye
 New Comment:

This bug has been fixed in SVN.

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




Previous Comments:


[2009-09-04 19:53:39] s...@php.net

Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=288067
Log: - #49464, fix build



[2009-09-04 15:50:46] raulsalitrero at gmail dot com

i've just tried it, it works now.
thanks.



[2009-09-04 10:26:14] ka...@php.net

The fix for this is pretty simple:
http://pastie.org/605649

However this C2491 only occurs when building sockets shared because of
the wrong exporting declarings used



[2009-09-04 03:44:59] raulsalitrero at gmail dot com

Description:

php_sockets.dll build is broken in win vc9, with the next error

ext\sockets\sockets.c(327) : error C2491: 'php_sockets_le_socket' :
definition of dllimport function not allowed

tried building the last svn source with the same result.

using vc9 to compile, the error is also observable in the windows
sanpshots compile logs 

the bug was introduced in revision: 287911 - export le_socket from
ext/sockets
changing files:
-/php/php-src/branches/PHP_5_3/ext/sockets/php_sockets.h
-/php/php-src/branches/PHP_5_3/ext/sockets/sockets.c

Reproduce code:
---
use nmake to compile with vc9 compiler

Expected result:

php_sockets.dll is built

Actual result:
--
php_sockets.dll is missing from the result build





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

#49469 [NEW]: session.hash_function = sha512 doesnt work

[elfi_47 at gmx dot de]

From: elfi_47 at gmx dot de
Operating system: openSuse 10.3
PHP version:  5.3.0
PHP Bug Type: Session related
Bug description:  session.hash_function = sha512   doesnt work

Description:

php 5.3 ignores "session.hash_function = sha512". it sets automatically
session.hash_function = 0

in hash_algos() sha512 is available.


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

#48668 [Ctl->Csd]: foreach with array will coredump php

[srinatar]

 ID:   48668
 Updated by:   srina...@php.net
 Reported By:  dmda at yandex dot ru
-Status:   Critical
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: Solaris
 PHP Version:  5.3.0RC4
 Assigned To:  dsp
 New Comment:

This bug has been fixed in SVN.

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

this issue is now resolved with dmitry's commit as part of his fix for
bug #46074. 

this below diff fixes this issue:
http://svn.php.net/viewvc?view=revision&revision=287992




Previous Comments:


[2009-08-26 22:42:48] sriram dot natarajan at gmail dot com

Ok, I am back. thanks for suggesting this patches. However, I just
tried your patch and I found that it still crashes in my machine. I will
investigate it further and once I have a patch I will post it here.



[2009-08-18 20:47:38] dmda at yandex dot ru

to demonstrate how it works, I wrote some trivial examples:

1) bad coding practice or misligned memory operations that lead to Bus
Error:

#include "inttypes.h"

typedef struct {
int16_t i;
} s16;

typedef struct {
int32_t i;
} s32;

int main() {
char *c = (char*)malloc(sizeof(s16) + sizeof(s32));
s16* v1 = (void*)(c);
s32* v2 = (void*)((char*)v1 + sizeof(s16));

printf("&v1=%x\n", v1);
printf("&v2=%x\n", v2);
v2->i = 55;
printf("ok\n");
return 0;
}

you'll note that the address of v2 is not aligned to 32bit boundary and
therefore v2->i = 55 will crash:

$gcc a.c -o a
$./a
&v1=208e8
&v2=208ea
Bus Error (core dumped)

2) Fix with MEMORY ALIGNMENT

#include "inttypes.h"

typedef struct {
int16_t i;
} s16;

typedef struct {
int32_t i;
} s32;

#define ALIGNGRANUL 4
#define ALIGN(a) ((a + ALIGNGRANUL - 1) & ~(ALIGNGRANUL - 1))

int main() {
char *c = (char*)malloc(ALIGN(sizeof(s16)) + ALIGN(sizeof(s32)));
s16* v1 = (void*)(c);
s32* v2 = (void*)((char*)v1 + ALIGN(sizeof(s16)));

printf("&v1=%x\n", v1);
printf("&v2=%x\n", v2);
v2->i = 55;
printf("ok\n");
return 0;
}

you'll see that all addresses are properly aligned to 32bit boundary:
$gcc a.c -o a
$./a
&v1=208e8
&v2=208ec
ok


3) a better fix that does not need any knowledge about memory
alignment:

#include "inttypes.h"

typedef struct {
int16_t i;
} s16;

typedef struct {
int32_t i;
} s32;


typedef struct {
   s16 v1;
   s32 v2;
} ss;

int main() {
ss* v = malloc(sizeof(ss));

printf("&v1=%x\n", &v->v1);
printf("&v2=%x\n", &v->v2);
v->v2.i = 55;
printf("ok\n");
return 0;
}

you'll see that it works too:

$gcc a.c -o a
$./a
&v1=208e8
&v2=208ec
ok



so you see this is all around sizeof() :) while actually it's all about
memory alignment.



[2009-08-18 17:42:20] dmda at yandex dot ru

Dear sriram ,

Where did I say that the problem is in allocation size?
Once again, the problem is in the data alignment.
And fixing the code I mentioned, it fixes the Bus error.

diff -U5 ./php-5.3.0/Zend/zend_execute.h
./php-5.3.0D/Zend/zend_execute.h
--- ./php-5.3.0/Zend/zend_execute.h 2009-06-09 05:26:02.0
-0400
+++ ./php-5.3.0D/Zend/zend_execute.h2009-08-18 12:27:18.080008000
-0400
@@ -154,11 +154,11 @@
zend_vm_stack_extend((count) TSRMLS_CC);
\
}   
\
} while (0)
 
 static inline zend_vm_stack zend_vm_stack_new_page(int count) {
-   zend_vm_stack page =
(zend_vm_stack)emalloc(sizeof(*page)+sizeof(page->elements[0])*(count-1));
+   zend_vm_stack page =
(zend_vm_stack)emalloc(ZEND_MM_ALIGNED_SIZE(sizeof(*page))+ZEND_MM_ALIGNED_SIZE(sizeof(page->elements[0]))*(count-1));
 
page->top = page->elements;
page->end = page->elements + count;
page->prev = NULL;
return page;
@@ -217,11 +217,11 @@
 
 static inline void *zend_vm_stack_alloc(size_t size TSRMLS_DC)
 {
void *ret;
 
-   size = (size + (sizeof(void*) - 1)) / sizeof(void*);
+   size = (size + (ZEND_MM_ALIGNED_SIZE(sizeof(void*)) - 1)) /
ZEND_MM_ALIGNED_SIZE(sizeof(void*));
 
ZEND_VM_STACK_GROW_IF_NEEDED((int)size);
ret = (void*)EG(argument_stack)->top;
EG(argument_stack)->top += size;
return ret;
diff -U5 ./php-5.3.0/Zend/zend_opcode.c
./php-5.3.0D/Zend/zend_opcode.c
--- ./php-5.3.0/Zend/zend_opcode.c  2009-06-05 19:20:59.0 -0400
+++ ./php-5.3.0D/Zend/zend_opcode.c 2009-08-18 12:29:21.630007000
-0400
@@ -43,11 +43,11 @@
}
 }
 
 static void op_array_allo

#47230 [NoF->Csd]: Bug with gcc Optimizer on Sparc systems

[srinatar]

 ID:   47230
 Updated by:   srina...@php.net
 Reported By:  lneve at mail dot nih dot gov
-Status:   No Feedback
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: Solaris 10 (completely patched)
 PHP Version:  5.3.0-beta2-dev
 New Comment:

This bug has been fixed in SVN.

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

this issue is not because of a bug with gcc in sparc. sparc requires 
memory accesses to be aligned. however, with php 5.3, zend stack was not
aligned and this was causing php 5.3 to crash on sparc as well as on
irix. 

this issue is now resolved with dmitry's commit as part of his fix for
bug #46074. 

this below diff fixes this issue:
http://svn.php.net/viewvc?view=revision&revision=287992




Previous Comments:


[2009-07-29 21:28:00] lepage at grm dot polymtl dot ca

not able to compile with sun studio to many dependance (libs) need to
be recompile with sun studio.

php5.3-200907282230 still has the same problem.



[2009-07-16 00:45:49] lepage at grm dot polymtl dot ca

URL for sun studio is http://developers.sun.com/sunstudio/

will try it or wait for 5.3.1, when is it scheduled ?



[2009-07-15 08:05:37] sriram dot natarajan at gmail dot com

hi
 please see related bug - http://bugs.php.net/bug.php?id=48668 .

 if you compile with sun studio 12 (which is available for free from
http://www.sun.com/sunstudio , you should not have this problem.

 future releases of php 5.3 should address this issue



[2009-07-14 22:22:03] lepage at grm dot polymtl dot ca

same problem here with php-5.3.0.
on Solaris 10 and gcc 4.3.2



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

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



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/47230

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

#48746 [Fbk]: Unable to browse directories within Junction Points

[pajoye]

 ID:   48746
 Updated by:   paj...@php.net
 Reported By:  ddkees at illinois dot edu
 Status:   Feedback
 Bug Type: Directory function related
 Operating System: win32 only - Windows Server 2003
 PHP Version:  5.3.0
 Assigned To:  pajoye
 New Comment:

Ignore my last two comments, it works perfectly using what you
describe. I was testing it from another VM where this junction did not
exist.

I added a include 'dir3/two.php' to one.php, two.php being a simple
echo "two.php"
The output:

C:\test>\php53\debug_ts\php.exe -n one.php
two.php
bool(true)

C:\test>junction dir3


C:\test\dir3: JUNCTION
   Substitute Name: e:\test


C:\test>dir dir3
 ...
09/04/2009  07:33 PM24 two.php
   1 File(s) 24 bytes
   2 Dir(s) 202,975,232 bytes free



Previous Comments:


[2009-09-04 17:50:34] paj...@php.net

Please note that it is again a XP/2k3 only issue. Debugging/fixing now.



[2009-09-04 17:36:30] paj...@php.net

@shoresofnowhere at gmail dot com

ok, I can reproduce it now. I will come back as soon as I have a fix.



[2009-09-04 17:26:49] paj...@php.net

@shoresofnowhere at gmail dot com

I suppose you mean:
c:\Dir
   |_ one.php
   |_ Dir3 (junction to d:\dir)
  |_ two.php

Using this constellation, here is my output on xp SP3:

C:\mnt>junction dir3
Junction v1.05 - ..
...
C:\mnt\dir3: JUNCTION
   Substitute Name: c:\test

C:\mnt>\test\php53vc6ts\php.exe one.php
bool(true)


Are you sure:
- apache has been restarted after the update?
- the right version is used?

Can you try in CLI as well please?





[2009-09-04 11:44:08] shoresofnowhere at gmail dot com

Sorry but the latest snapshot still has problems:

Dir  directory
one.php  file in dir directory
Dir2 junction in dir to dir3 on another drive
two.php  file in dir3

in one.php:
is_file(./dir2/two.php) returns FALSE!

Working on XP SP3 under Apache 2.2.13



[2009-09-04 08:11:06] mats dot lindh at gmail dot com

Everything seems to work OK with a build from 2009-09-03. Thanks for
fixing the issue!



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/48746

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

#48746 [Fbk]: Unable to browse directories within Junction Points

[pajoye]

 ID:   48746
 Updated by:   paj...@php.net
 Reported By:  ddkees at illinois dot edu
 Status:   Feedback
 Bug Type: Directory function related
 Operating System: win32 only - Windows Server 2003
 PHP Version:  5.3.0
 Assigned To:  pajoye
 New Comment:

@shoresofnowhere at gmail dot com

ok, I can reproduce it now. I will come back as soon as I have a fix.


Previous Comments:


[2009-09-04 17:26:49] paj...@php.net

@shoresofnowhere at gmail dot com

I suppose you mean:
c:\Dir
   |_ one.php
   |_ Dir3 (junction to d:\dir)
  |_ two.php

Using this constellation, here is my output on xp SP3:

C:\mnt>junction dir3
Junction v1.05 - ..
...
C:\mnt\dir3: JUNCTION
   Substitute Name: c:\test

C:\mnt>\test\php53vc6ts\php.exe one.php
bool(true)


Are you sure:
- apache has been restarted after the update?
- the right version is used?

Can you try in CLI as well please?





[2009-09-04 11:44:08] shoresofnowhere at gmail dot com

Sorry but the latest snapshot still has problems:

Dir  directory
one.php  file in dir directory
Dir2 junction in dir to dir3 on another drive
two.php  file in dir3

in one.php:
is_file(./dir2/two.php) returns FALSE!

Working on XP SP3 under Apache 2.2.13



[2009-09-04 08:11:06] mats dot lindh at gmail dot com

Everything seems to work OK with a build from 2009-09-03. Thanks for
fixing the issue!



[2009-09-03 10:10:14] phpstuff at cresstone dot com

I'm getting good test behavior from the that snapshot. More tellingly,
the original script I've been trying to run is now working correctly.

Thanks.



[2009-09-02 23:26:04] paj...@php.net

I can't reproduce the problem with is_dir or is_file behave correctly,
however I think I found the problem and commited a fix.

I can reproduce the scandir one, same fix. I manually launched a build,
you can get the vc9-x86 here: http://is.gd/2OtDf (other snaps should be
online within 15mins).





The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/48746

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

#48746 [Fbk]: Unable to browse directories within Junction Points

[pajoye]

 ID:   48746
 Updated by:   paj...@php.net
 Reported By:  ddkees at illinois dot edu
 Status:   Feedback
 Bug Type: Directory function related
 Operating System: win32 only - Windows Server 2003
 PHP Version:  5.3.0
 Assigned To:  pajoye
 New Comment:

@shoresofnowhere at gmail dot com

I suppose you mean:
c:\Dir
   |_ one.php
   |_ Dir3 (junction to d:\dir)
  |_ two.php

Using this constellation, here is my output on xp SP3:

C:\mnt>junction dir3
Junction v1.05 - ..
...
C:\mnt\dir3: JUNCTION
   Substitute Name: c:\test

C:\mnt>\test\php53vc6ts\php.exe one.php
bool(true)


Are you sure:
- apache has been restarted after the update?
- the right version is used?

Can you try in CLI as well please?




Previous Comments:


[2009-09-04 11:44:08] shoresofnowhere at gmail dot com

Sorry but the latest snapshot still has problems:

Dir  directory
one.php  file in dir directory
Dir2 junction in dir to dir3 on another drive
two.php  file in dir3

in one.php:
is_file(./dir2/two.php) returns FALSE!

Working on XP SP3 under Apache 2.2.13



[2009-09-04 08:11:06] mats dot lindh at gmail dot com

Everything seems to work OK with a build from 2009-09-03. Thanks for
fixing the issue!



[2009-09-03 10:10:14] phpstuff at cresstone dot com

I'm getting good test behavior from the that snapshot. More tellingly,
the original script I've been trying to run is now working correctly.

Thanks.



[2009-09-02 23:26:04] paj...@php.net

I can't reproduce the problem with is_dir or is_file behave correctly,
however I think I found the problem and commited a fix.

I can reproduce the scandir one, same fix. I manually launched a build,
you can get the vc9-x86 here: http://is.gd/2OtDf (other snaps should be
online within 15mins).





[2009-09-02 22:59:59] s...@php.net

Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=287975
Log: - #48746, len includes null already



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/48746

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

#49419 [Opn]: ssl:// wrapper - cannot verify VeriSign certificate chain

[Jacek at jacekk dot info]

 ID:   49419
 User updated by:  Jacek at jacekk dot info
 Reported By:  Jacek at jacekk dot info
 Status:   Open
 Bug Type: OpenSSL related
 Operating System: Ubuntu
 PHP Version:  5.3.0
 New Comment:

> what version have you linked against with your PHP?

I've tested it on PHP linked against OpenSSL 0.9.8g (Ubuntu LTS) and
0.9.8k (Gentoo)

I understand how certificate checking works and I've provided wrong
chain - my bad, however with the file you linked PHP still shows
warnings form the first message.

One more question: must OpenSSL check whole path, if one of
intermediate certificates exists in cafile?


Previous Comments:


[2009-09-04 06:59:44] ryan+phpbugs at sleevi dot com

I was unable to reproduce the "good" OpenSSL output that you described,
using OpenSSL FIPS 1.2. For documentation sake (and because everything
I'm about to explain is relative to that, which is equivalent to 0.9.8f
code more or less), what version have you linked against with your PHP?

Running

openssl s_client -connect www.verisign.com:443 -CAfile chain.pem

I get

CONNECTED(0003)
depth=3 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0
s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/2.5.4.15=V1.0,
Clause
5.(b)/serialNumber=2497886/C=US/postalCode=94043/ST=California/L=Mountain
View/streetAddress=487 East Middlefield Road/O=VeriSign,
Inc./OU=Production Security Services/CN=www.verisign.com
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use
at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended
Validation SSL SGC CA
 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use
at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended
Validation SSL SGC CA
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006
VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public
Primary Certification Authority - G5
 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006
VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public
Primary Certification Authority - G5
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
 3 s:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification
Authority
---

Using the chain file at http://pastebin.com/f16f72c6e and I am able to
use the code without the issues you describe (There is an HTTP 500 error
with the PayPal site, but that demonstrates the connection is
successful). The certificate in this file corresponds to the last
certificate in the chain as supplied by both Verisign and Paypal.

The explanation of "why" this works follows, and is based on the
0.9.8/OpenSSL FIPS Module 1.2 code. While I cannot be certain that this
explanation fully explains your problem, based on those missing pieces
of information, it may shed light on the issues and limitations of the
'cafile' and 'capath' arguments.

I do not believe that what you want to work will work the way you've
described, which is due to OpenSSL limitations.

In the chain file you provided, the two certificates you provided are:
subject= /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006
VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public
Primary Certification Authority - G5
issuer= /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006
VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public
Primary Certification Authority - G5

and

subject= /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of
use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended
Validation SSL CA
issuer= /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006
VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public
Primary Certification Authority - G5


The first certificate in the supplied chain file corresponds to being
the issuer of the certificate at index 1 in the above output from
OpenSSL. Thus, one would expect the chain to go from index 0
(www.verisign.com) -> index 1 (EV SSL SGC CA) -> chain file 0 (Public
Primary CA - G5). As chain file 0 is both a self-signed certificate and
in the trusted list, one would presume the connection is now
trusted/verified.

However, OpenSSL's verify code is set to respect the ordering supplied
by the remote server over the preference of a chain file when used for
certificate path building. The untrusted list of certs receives
precedence when building the chain, with the capath, cafile, and any
other lookups only being consulted to complete any missing parts of the
chain.

This can be found in the OpenSSL sources in crypto/x509/x509_vfy.c
X509_verify_cert. The comment in the code states "if we were passed a
cert ch

#49465 [Opn->Csd]: Soap Segmentation fault with ./configure --with-curlwrappers

[jani]

 ID:   49465
 Updated by:   j...@php.net
 Reported By:  xavier at jvweb dot fr
-Status:   Open
+Status:   Closed
 Bug Type: cURL related
 Operating System: ubuntu hardy amd64
 PHP Version:  5.3.0
 New Comment:

Yes, I was quite sure it would since this was reported earlier few 
times..search helps a lot.. ;)


Previous Comments:


[2009-09-04 12:08:34] xavier at jvweb dot fr

php5.3-200909041030 has solved this problem.

thanks a lot



[2009-09-04 11:23:06] j...@php.net

Please try using this snapshot:

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

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





[2009-09-04 10:19:39] xavier at jvweb dot fr

sorry i'm tired :|

Expected result:

Array
(
[0] => CreateAdspaceResponse CreateAdspace(CreateAdspace
$CreateAdspace)
[1] => CreateProgramApplicationResponse
CreateProgramApplication(CreateProgramApplication
$CreateProgramApplication)
[2] => DeleteAdspaceResponse DeleteAdspace(DeleteAdspace
$DeleteAdspace)
[3] => DeleteProgramApplicationResponse
DeleteProgramApplication(DeleteProgramApplication
$DeleteProgramApplication)
[4] => GetAccountsResponse GetAccounts(GetAccounts $GetAccounts)
[5] => GetAdmediaResponse GetAdmedia(GetAdmedia $GetAdmedia)
[6] => GetAdmediumResponse GetAdmedium(GetAdmedium $GetAdmedium)
[7] => GetAdmediumCategoriesResponse
GetAdmediumCategories(GetAdmediumCategories $GetAdmediumCategories)
[8] => GetAdspaceResponse GetAdspace(GetAdspace $GetAdspace)
[9] => GetAdspacesResponse GetAdspaces(GetAdspaces $GetAdspaces)
[10] => GetBalancesResponse GetBalances(GetBalances $GetBalances)
[11] => GetLeadsResponse GetLeads(GetLeads $GetLeads)
[12] => GetPaymentsResponse GetPayments(GetPayments $GetPayments)
[13] => GetProductResponse GetProduct(GetProduct $GetProduct)
[14] => GetProductsResponse GetProducts(GetProducts $GetProducts)
[15] => GetProfileResponse GetProfile(GetProfile $GetProfile)
[16] => GetProgramResponse GetProgram(GetProgram $GetProgram)
[17] => GetProgramCategoriesResponse
GetProgramCategories(GetProgramCategories $GetProgramCategories)
[18] => GetProgramPromotionsResponse
GetProgramPromotions(GetProgramPromotions $GetProgramPromotions)
[19] => GetProgramsResponse GetPrograms(GetPrograms $GetPrograms)
[20] => GetSalesResponse GetSales(GetSales $GetSales)
[21] => SearchProductsResponse SearchProducts(SearchProducts
$SearchProducts)
[22] => SearchProgramsResponse SearchPrograms(SearchPrograms
$SearchPrograms)
[23] => UpdateAdspaceResponse UpdateAdspace(UpdateAdspace
$UpdateAdspace)
[24] => UpdateProfileResponse UpdateProfile(UpdateProfile
$UpdateProfile)
)

Actual result:
--
Starting program: /usr/src/php/php-5.3.0/sapi/cli/php do.php
[Thread debugging using libthread_db enabled]
[New Thread 0x7f1f1691d700 (LWP 9050)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f1f1691d700 (LWP 9050)]
0x7f1f15c0cb3c in ?? () from /usr/lib/libcurl.so.4
(gdb) bt
#0  0x7f1f15c0cb3c in ?? () from /usr/lib/libcurl.so.4
#1  0x7f1f15c0d853 in ?? () from /usr/lib/libcurl.so.4
#2  0x7f1f15c18d89 in ?? () from /usr/lib/libcurl.so.4
#3  0x7f1f15c2a989 in ?? () from /usr/lib/libcurl.so.4
#4  0x7f1f15c2b01b in curl_multi_perform () from
/usr/lib/libcurl.so.4
#5  0x0048f61d in php_curl_stream_read (stream=0xb81910,
buf=0xb82df0 "", count=8192) at
/usr/src/php/php-5.3.0/ext/curl/streams.c:184
#6  0x005e3640 in php_stream_fill_read_buffer (stream=0xb81910,
size=4000) at /usr/src/php/php-5.3.0/main/streams/streams.c:562
#7  0x005e3809 in _php_stream_read (stream=0xb81910,
buf=0xbbc100 "", size=4000) at
/usr/src/php/php-5.3.0/main/streams/streams.c:605
#8  0x004605d6 in php_libxml_streams_IO_read (context=0xb81910,
buffer=0xbbc100 "", len=4000) at
/usr/src/php/php-5.3.0/ext/libxml/libxml.c:337
#9  0x7f1f143d5dff in xmlParserInputBufferGrow () from
/usr/lib/libxml2.so.2
#10 0x7f1f143aeced in xmlParserInputGrow () from
/usr/lib/libxml2.so.2
#11 0x7f1f143b3392 in ?? () from /usr/lib/libxml2.so.2
#12 0x7f1f143c59fd in xmlParseDocument () from
/usr/lib/libxml2.so.2
#13 0x00506093 in soap_xmlParseFile (filename=0xb80798
"http://api.zanox.com/wsdl";) at
/usr/src/php/php-5.3.0/ext/soap/php_xml.c:100
#14 0x004ebb30 in load_wsdl_ex (this_ptr=0xb7ea80,
struri=0xb80798 "http://api.zanox.com/wsdl";, ctx=0x7fff98d0,
include=0)
at /usr/src/php/php-5.3.0/ext/soap/php_sdl.c:240
#15 0x004eddbc in load_wsdl (this_ptr=0xb7ea80, struri=0xb80798
"http://api.zanox.com/wsdl";) at
/usr/src/php/php-5.3.0/ext/soap/php_sdl.c:654
#16 0x00504f45 in get_sdl (this_ptr=0xb7e

#49468 [NEW]: PHP.net Website Problem

[Jon at cshardware dot com]

From: Jon at cshardware dot com
Operating system: 
PHP version:  5.2.10
PHP Bug Type: *Web Server problem
Bug description:  PHP.net Website Problem

Description:

Every time I try to download the .zip package, I get the "The connection
to the server was reset," error message no matter where I try to download
it from.


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

#49464 [Com]: php_sockets build broken

[raulsalitrero at gmail dot com]

 ID:   49464
 Comment by:   raulsalitrero at gmail dot com
 Reported By:  raulsalitrero at gmail dot com
 Status:   Open
 Bug Type: Compile Failure
 Operating System: win32 only - Windows Xp SP3
 PHP Version:  5.3SVN-2009-09-04 (SVN)
 New Comment:

i've just tried it, it works now.
thanks.


Previous Comments:


[2009-09-04 10:26:14] ka...@php.net

The fix for this is pretty simple:
http://pastie.org/605649

However this C2491 only occurs when building sockets shared because of
the wrong exporting declarings used



[2009-09-04 03:44:59] raulsalitrero at gmail dot com

Description:

php_sockets.dll build is broken in win vc9, with the next error

ext\sockets\sockets.c(327) : error C2491: 'php_sockets_le_socket' :
definition of dllimport function not allowed

tried building the last svn source with the same result.

using vc9 to compile, the error is also observable in the windows
sanpshots compile logs 

the bug was introduced in revision: 287911 - export le_socket from
ext/sockets
changing files:
-/php/php-src/branches/PHP_5_3/ext/sockets/php_sockets.h
-/php/php-src/branches/PHP_5_3/ext/sockets/sockets.c

Reproduce code:
---
use nmake to compile with vc9 compiler

Expected result:

php_sockets.dll is built

Actual result:
--
php_sockets.dll is missing from the result build





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

#49182 [Asn]: PHP CGI always outputs the shebang line

[joey]

 ID:   49182
 Updated by:   j...@php.net
 Reported By:  salsi at icosaedro dot it
 Status:   Assigned
 Bug Type: CGI related
 Operating System: *
 PHP Version:  5.3SVN-2009-09-04 (SVN)
 Assigned To:  iliaa
 New Comment:

Maybe that's a good argument for moving it out of the scanner and back
into the SAPIs? I don't find it difficult to accept the argument that
it's a SAPI-specific behaviour.


Previous Comments:


[2009-09-04 11:22:10] j...@php.net

Ilia's fix for bug #46844 actually broke it.



[2009-09-04 08:35:46] j...@php.net

http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_language_scanner.l?r1=272489&r2=273177
looks like the problem.



[2009-09-04 07:48:19] j...@php.net

Still happens using latest SVN checkout of today.



[2009-09-04 07:41:34] j...@php.net

Still borked.



[2009-09-04 07:34:01] niklas at narhinen dot net

Hi, using php 5.3.0.

my script is:

#!/path/to/php-cgi


and it prints "#!/path/to/php-cgi" on top of the normal phpinfo

Running Debian Etch

This bug needs to be reopened..



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/49182

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

#49225 [Asn->Csd]: OpenSSL.cnf file missing in the extras folder

[pajoye]

 ID:   49225
 Updated by:   paj...@php.net
 Reported By:  ktowery at tucows dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: OpenSSL related
 Operating System: win32 only - Windows XP
 PHP Version:  5.3.0
 Assigned To:  pajoye
 New Comment:

This bug has been fixed in SVN.

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

Fixed in the build boxes.


Previous Comments:


[2009-08-11 15:18:12] ktowery at tucows dot com 

Description:

When downloading the latest stable version of PHP 5.3.0, the extras
folder contains no files.  The file I am looking for is the openssl.cnf
file.  This file is available in the 5.2.10 release and I was wondering
where this file is now located.  It does not seem to be anywhere in the
php download. 

Expected result:

Need to have the openssl.cnf file added back to the extras folder 






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

#49295 [Asn]: stream_socket_client() fails on SSL+async

[frase at cs dot wisc dot edu]

 ID:   49295
 User updated by:  frase at cs dot wisc dot edu
 Reported By:  frase at cs dot wisc dot edu
 Status:   Assigned
 Bug Type: OpenSSL related
 Operating System: Win 2000 Pro SP4
-PHP Version:  5.2.11RC1
+PHP Version:  5.2.11RC2
 Assigned To:  srinatar
 New Comment:

I'm sure this is expected, but the bug remains in 5.2.11RC2.

I also noticed another clue: I mentioned previously that SSL+ASYNC
works once (but not asynchronously) after starting Apache, and then
fails and throws warnings.  It turns out any SSL socket connection will
cause future SSL+ASYNC attempts to do this, even if the first one was
SYNC.  So to get SSL+ASYNC to connect, it must be the very first SSL
socket opened since Apache started.


Previous Comments:


[2009-09-02 14:17:18] frase at cs dot wisc dot edu

Commenting the stream_set_blocking() doesn't change anything for me on
Windows.  SSL+ASYNC still works exactly once (but doesn't actually
connect asynchronously) and then gives the warnings; SSL+SYNC still
works fine, as does TCP+ASYNC.

Thanks for your work on this.  I get complaints about it every week
because if the remote server doesn't respond then our software gets
stuck in the connection phase, and since the connection phase cannot be
made asynchronous, the user is unable to abort it and just has to wait.



[2009-09-02 08:38:01] srina...@php.net

just a follow up note, this issue (async not working consistently with

openssl on windows) has always been the case and this issue has nothing

to do with the fix that went in for bug:48182.



[2009-09-02 08:09:22] srina...@php.net

ok, i was looking into this issue today. the issue is that , 
especially on windows -where sockets are not file descriptors unlike 
in unix, async sockets and openssl works together only if we use BIO 
wrappers provided by openssl module instead of directly accessing 
underlying sockets as file descriptors. 

the possible right way to do this would be to use  to socket wrappers 
provided by  SSL module (known as BIO wrappers which makes it work 
properly on windows).

this will require some amount of fiddling our openssl module. i don't 
think, 5.2 is a good place to do this change.  

for now, commenting this below code should help you to run your script

properly on windows. 
stream_set_blocking($socket, 0);

i will spend more time on this and investigate on the best way to use 
BIO wrappers within existing openssl module say within php 5.3



[2009-08-21 15:05:47] frase at cs dot wisc dot edu

I had a chance to compile and test PHP5.2.11RC1 under Linux this
morning (Ubuntu Jaunty, Apache 2.2.11 from repositories), and these
warnings do not appear, however I noticed another problem.

Although the SSL+async connection is successful and data is returned
under Linux, the socket is not actually opened asynchonously.  The
script blocks until the socket has finished opening, exactly as it does
without the ASYNC flag.  This is also true under Windows, for the first
run -- after that, of course, it returns the errors posted above.



[2009-08-21 01:15:44] srina...@php.net

this issue seems to be happening when this script is executed more than
once and also seems to be happening only on windows. 



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/49295

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

#49467 [NEW]: Errors are logged to syslog using LOG_NOTICE instead of LOG_ERR

[toby dot walsh at fxhome dot com]

From: toby dot walsh at fxhome dot com
Operating system: Linux
PHP version:  5.2.10
PHP Bug Type: Unknown/Other Function
Bug description:  Errors are logged to syslog using LOG_NOTICE instead of 
LOG_ERR

Description:

I'm using "error_log = syslog" in my php.ini to log all errors to syslog.
But the errors end up being logged using the LOG_NOTICE log level instead
of the LOG_ERR level.

I've traced this back to the internal php_log_err function in main/main.c
which uses

php_syslog(LOG_NOTICE, "%.500s", log_message);

when it should probably be using

php_syslog(LOG_ERR, "%.500s", log_message); 

Reproduce code:
---
Set the following directives in php.ini
error_reporting = E_ALL & ~E_NOTICE
log_errors = On
error_log = syslog

Then generate a syntax error with something like


Expected result:

An error message should be logged to syslog with a log level of LOG_ERR

Actual result:
--
The error message is logged, but using a log level of LOG_NOTICE instead
of LOG_ERR

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

#49465 [Fbk->Opn]: Soap Segmentation fault with ./configure --with-curlwrappers

[xavier at jvweb dot fr]

 ID:   49465
 User updated by:  xavier at jvweb dot fr
 Reported By:  xavier at jvweb dot fr
-Status:   Feedback
+Status:   Open
 Bug Type: cURL related
 Operating System: ubuntu hardy amd64
 PHP Version:  5.3.0
 New Comment:

php5.3-200909041030 has solved this problem.

thanks a lot


Previous Comments:


[2009-09-04 11:23:06] j...@php.net

Please try using this snapshot:

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

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





[2009-09-04 10:19:39] xavier at jvweb dot fr

sorry i'm tired :|

Expected result:

Array
(
[0] => CreateAdspaceResponse CreateAdspace(CreateAdspace
$CreateAdspace)
[1] => CreateProgramApplicationResponse
CreateProgramApplication(CreateProgramApplication
$CreateProgramApplication)
[2] => DeleteAdspaceResponse DeleteAdspace(DeleteAdspace
$DeleteAdspace)
[3] => DeleteProgramApplicationResponse
DeleteProgramApplication(DeleteProgramApplication
$DeleteProgramApplication)
[4] => GetAccountsResponse GetAccounts(GetAccounts $GetAccounts)
[5] => GetAdmediaResponse GetAdmedia(GetAdmedia $GetAdmedia)
[6] => GetAdmediumResponse GetAdmedium(GetAdmedium $GetAdmedium)
[7] => GetAdmediumCategoriesResponse
GetAdmediumCategories(GetAdmediumCategories $GetAdmediumCategories)
[8] => GetAdspaceResponse GetAdspace(GetAdspace $GetAdspace)
[9] => GetAdspacesResponse GetAdspaces(GetAdspaces $GetAdspaces)
[10] => GetBalancesResponse GetBalances(GetBalances $GetBalances)
[11] => GetLeadsResponse GetLeads(GetLeads $GetLeads)
[12] => GetPaymentsResponse GetPayments(GetPayments $GetPayments)
[13] => GetProductResponse GetProduct(GetProduct $GetProduct)
[14] => GetProductsResponse GetProducts(GetProducts $GetProducts)
[15] => GetProfileResponse GetProfile(GetProfile $GetProfile)
[16] => GetProgramResponse GetProgram(GetProgram $GetProgram)
[17] => GetProgramCategoriesResponse
GetProgramCategories(GetProgramCategories $GetProgramCategories)
[18] => GetProgramPromotionsResponse
GetProgramPromotions(GetProgramPromotions $GetProgramPromotions)
[19] => GetProgramsResponse GetPrograms(GetPrograms $GetPrograms)
[20] => GetSalesResponse GetSales(GetSales $GetSales)
[21] => SearchProductsResponse SearchProducts(SearchProducts
$SearchProducts)
[22] => SearchProgramsResponse SearchPrograms(SearchPrograms
$SearchPrograms)
[23] => UpdateAdspaceResponse UpdateAdspace(UpdateAdspace
$UpdateAdspace)
[24] => UpdateProfileResponse UpdateProfile(UpdateProfile
$UpdateProfile)
)

Actual result:
--
Starting program: /usr/src/php/php-5.3.0/sapi/cli/php do.php
[Thread debugging using libthread_db enabled]
[New Thread 0x7f1f1691d700 (LWP 9050)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f1f1691d700 (LWP 9050)]
0x7f1f15c0cb3c in ?? () from /usr/lib/libcurl.so.4
(gdb) bt
#0  0x7f1f15c0cb3c in ?? () from /usr/lib/libcurl.so.4
#1  0x7f1f15c0d853 in ?? () from /usr/lib/libcurl.so.4
#2  0x7f1f15c18d89 in ?? () from /usr/lib/libcurl.so.4
#3  0x7f1f15c2a989 in ?? () from /usr/lib/libcurl.so.4
#4  0x7f1f15c2b01b in curl_multi_perform () from
/usr/lib/libcurl.so.4
#5  0x0048f61d in php_curl_stream_read (stream=0xb81910,
buf=0xb82df0 "", count=8192) at
/usr/src/php/php-5.3.0/ext/curl/streams.c:184
#6  0x005e3640 in php_stream_fill_read_buffer (stream=0xb81910,
size=4000) at /usr/src/php/php-5.3.0/main/streams/streams.c:562
#7  0x005e3809 in _php_stream_read (stream=0xb81910,
buf=0xbbc100 "", size=4000) at
/usr/src/php/php-5.3.0/main/streams/streams.c:605
#8  0x004605d6 in php_libxml_streams_IO_read (context=0xb81910,
buffer=0xbbc100 "", len=4000) at
/usr/src/php/php-5.3.0/ext/libxml/libxml.c:337
#9  0x7f1f143d5dff in xmlParserInputBufferGrow () from
/usr/lib/libxml2.so.2
#10 0x7f1f143aeced in xmlParserInputGrow () from
/usr/lib/libxml2.so.2
#11 0x7f1f143b3392 in ?? () from /usr/lib/libxml2.so.2
#12 0x7f1f143c59fd in xmlParseDocument () from
/usr/lib/libxml2.so.2
#13 0x00506093 in soap_xmlParseFile (filename=0xb80798
"http://api.zanox.com/wsdl";) at
/usr/src/php/php-5.3.0/ext/soap/php_xml.c:100
#14 0x004ebb30 in load_wsdl_ex (this_ptr=0xb7ea80,
struri=0xb80798 "http://api.zanox.com/wsdl";, ctx=0x7fff98d0,
include=0)
at /usr/src/php/php-5.3.0/ext/soap/php_sdl.c:240
#15 0x004eddbc in load_wsdl (this_ptr=0xb7ea80, struri=0xb80798
"http://api.zanox.com/wsdl";) at
/usr/src/php/php-5.3.0/ext/soap/php_sdl.c:654
#16 0x00504f45 in get_sdl (this_ptr=0xb7ea80, uri=0xb80798
"http://api.zanox.com/wsdl";, cache_wsdl=0) at
/usr/src/php/php-5.3.0/ext/soap/php_sdl.c:3227
#17 0x004aa2f8 in zim_SoapClient_SoapClient (ht=1,
return_value=0xb7f8b8, return_value_p

#48746 [Com]: Unable to browse directories within Junction Points

[shoresofnowhere at gmail dot com]

 ID:   48746
 Comment by:   shoresofnowhere at gmail dot com
 Reported By:  ddkees at illinois dot edu
 Status:   Feedback
 Bug Type: Directory function related
 Operating System: win32 only - Windows Server 2003
 PHP Version:  5.3.0
 Assigned To:  pajoye
 New Comment:

Sorry but the latest snapshot still has problems:

Dir  directory
one.php  file in dir directory
Dir2 junction in dir to dir3 on another drive
two.php  file in dir3

in one.php:
is_file(./dir2/two.php) returns FALSE!

Working on XP SP3 under Apache 2.2.13


Previous Comments:


[2009-09-04 08:11:06] mats dot lindh at gmail dot com

Everything seems to work OK with a build from 2009-09-03. Thanks for
fixing the issue!



[2009-09-03 10:10:14] phpstuff at cresstone dot com

I'm getting good test behavior from the that snapshot. More tellingly,
the original script I've been trying to run is now working correctly.

Thanks.



[2009-09-02 23:26:04] paj...@php.net

I can't reproduce the problem with is_dir or is_file behave correctly,
however I think I found the problem and commited a fix.

I can reproduce the scandir one, same fix. I manually launched a build,
you can get the vc9-x86 here: http://is.gd/2OtDf (other snaps should be
online within 15mins).





[2009-09-02 22:59:59] s...@php.net

Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=287975
Log: - #48746, len includes null already



[2009-09-02 21:29:08] phpstuff at cresstone dot com

Using Windows 7 x64. It seems all files in my mounted volumes are being
treated as directories. (is_dir returns true, is_file returns false.)
Directory operations pointed at files seem to point back to the root of
the volume.

The following script:
echo "dumping: scandir('mounted_volume')\n";
var_dump(scandir('mounted_volume'));
echo "dumping: scandir('mounted_volume\\file1')\n";
var_dump(scandir('mounted_volume\file1'));

gives this output:



dumping: scandir('mounted_volume')
array(4) {
  [0]=>
  string(12) "$RECYCLE.BIN"
  [1]=>
  string(4) "dir1"
  [2]=>
  string(4) "dir2"
  [3]=>
  string(5) "file1"
}
dumping: scandir('mounted_volume\file1')
array(4) {
  [0]=>
  string(12) "$RECYCLE.BIN"
  [1]=>
  string(4) "dir1"
  [2]=>
  string(4) "dir2"
  [3]=>
  string(5) "file1"
}

Nesting does not seem to matter, eg:
scandir('mounted_volume\dir1\file_in_dir1'); gives the same output


Something else that's interesting... When I create the junction from a
drive letter, eg: "mklink mounted_volume y:" everything works perfectly,
files are files and dirs are dirs. It's only when I use the volume name
in the creation ("mklink /J mounted_volume
\\?\Volume{feeac7c1-2ad0-11de-89bb-001fd0ae05ac}\") that I get this
strange behavior. Bizarre, but I swear I'm not making this up :)



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/48746

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

#49326 [Opn->Fbk]: output_buffering and use_trans_sid can corrupt session

[jani]

 ID:   49326
 Updated by:   j...@php.net
 Reported By:  k dot triendl at m-box dot at
-Status:   Open
+Status:   Feedback
 Bug Type: Output Control
 Operating System: windows xp sp3
 PHP Version:  5.2.10
 New Comment:

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


Previous Comments:


[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:




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 http://bugs.php.net/?id=49326&edit=1

#49098 [Opn]: Using custom session handler causes segfault in session_save_state

[timj]

 ID:   49098
 Updated by:   t...@php.net
 Reported By:  bugs at timj dot co dot uk
 Status:   Open
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  5.2.10
 New Comment:

Further info: the crash does NOT occur if the DSN string is changed to
"mysql://..." instead of "mysqli://..." (this also seemed to be the case
in similar bug #48922)


Previous Comments:


[2009-08-11 22:00:51] t...@php.net

OK, for the record then, that case was reproducible for me with
5.2.11-dev snap 200908101630. Backtrace similar to the first one opening
the bug.



[2009-08-11 05:16:26] j...@php.net

NEVER ever email me privately test cases. Here's the script you sent
me:



Installed PEAR packages to make it happen:
HTTP_Session2  0.7.2   beta
MDB2   2.5.0b2 beta
MDB2_Driver_mysqli 1.5.0b2 beta 
 



[2009-07-29 12:31:10] j...@php.net

And as expected: We really need proper, short, reproducing script. Now
the problem might be anywhere..



[2009-07-29 12:30:18] j...@php.net

In the future: PLEASE add the backtraces in separate comments. Now it's
pretty hard to see which is which. 



[2009-07-29 12:14:23] t...@php.net

N.B. this occurs with both apache2 and CGI SAPIs.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/49098

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

#49462 [Fbk]: Session variables not saved after redirect, session_write_close(), die() used

[jani]

 ID:   49462
 Updated by:   j...@php.net
 Reported By:  greg dot solak at profiletwist dot com
 Status:   Feedback
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  5.3.0
 New Comment:

Also, your example script really can't work since it does not have
session_start() called at all. It's not enough that you say it's there
when it clearly isn't. 


Previous Comments:


[2009-09-04 11:25:33] j...@php.net

Does this happen with PHP 5.2.10 ? (hint: works just fine for me on
several sites without any problems..)



[2009-09-03 23:01:05] greg dot solak at profiletwist dot com

Description:

PHP SESSION variable $_SESSION['user_level'] is not saved after the
page is redirected using header(location: ...). Session_write_close()is
used right before redirect. After redirect die() is called. After a
second attempt at login, everything works!

Reproduce code:
---


// Change session properties
$_SESSION['user_level'] = 7;
// Force session to save changes before redirection
session_write_close(); // REQUIRED
// Regenerate session id for security + fix bug in which some session
variables are lost during redirect
session_regenerate_id(true);
// Redirect to Access main page
header('Location: http://www.domain.com/access/main.php');
die();

?>

Expected result:

At the new page (the one the user was redirected to) the
$SESSION['user_level'] should == 7. However, the session variable was
not saved, as the user is redirected back to the login page. After a
second attempt at logging in, everything works as expected.

Actual result:
--
Redirected back to login page, because when php checked if the user had
the proper credentials

if ($_SESSION['user_level'] != 7) {
 // redirect back to login page
}

Other improtant information: session_start(); is called on every page.





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

#49462 [Opn->Fbk]: Session variables not saved after redirect, session_write_close(), die() used

[jani]

 ID:   49462
 Updated by:   j...@php.net
 Reported By:  greg dot solak at profiletwist dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Session related
 Operating System: Linux
 PHP Version:  5.3.0
 New Comment:

Does this happen with PHP 5.2.10 ? (hint: works just fine for me on
several sites without any problems..)


Previous Comments:


[2009-09-03 23:01:05] greg dot solak at profiletwist dot com

Description:

PHP SESSION variable $_SESSION['user_level'] is not saved after the
page is redirected using header(location: ...). Session_write_close()is
used right before redirect. After redirect die() is called. After a
second attempt at login, everything works!

Reproduce code:
---


// Change session properties
$_SESSION['user_level'] = 7;
// Force session to save changes before redirection
session_write_close(); // REQUIRED
// Regenerate session id for security + fix bug in which some session
variables are lost during redirect
session_regenerate_id(true);
// Redirect to Access main page
header('Location: http://www.domain.com/access/main.php');
die();

?>

Expected result:

At the new page (the one the user was redirected to) the
$SESSION['user_level'] should == 7. However, the session variable was
not saved, as the user is redirected back to the login page. After a
second attempt at logging in, everything works as expected.

Actual result:
--
Redirected back to login page, because when php checked if the user had
the proper credentials

if ($_SESSION['user_level'] != 7) {
 // redirect back to login page
}

Other improtant information: session_start(); is called on every page.





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

#49465 [Opn->Fbk]: Soap Segmentation fault with ./configure --with-curlwrappers

[jani]

 ID:   49465
 Updated by:   j...@php.net
 Reported By:  xavier at jvweb dot fr
-Status:   Open
+Status:   Feedback
 Bug Type: cURL related
 Operating System: ubuntu hardy amd64
 PHP Version:  5.3.0
 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-04 10:19:39] xavier at jvweb dot fr

sorry i'm tired :|

Expected result:

Array
(
[0] => CreateAdspaceResponse CreateAdspace(CreateAdspace
$CreateAdspace)
[1] => CreateProgramApplicationResponse
CreateProgramApplication(CreateProgramApplication
$CreateProgramApplication)
[2] => DeleteAdspaceResponse DeleteAdspace(DeleteAdspace
$DeleteAdspace)
[3] => DeleteProgramApplicationResponse
DeleteProgramApplication(DeleteProgramApplication
$DeleteProgramApplication)
[4] => GetAccountsResponse GetAccounts(GetAccounts $GetAccounts)
[5] => GetAdmediaResponse GetAdmedia(GetAdmedia $GetAdmedia)
[6] => GetAdmediumResponse GetAdmedium(GetAdmedium $GetAdmedium)
[7] => GetAdmediumCategoriesResponse
GetAdmediumCategories(GetAdmediumCategories $GetAdmediumCategories)
[8] => GetAdspaceResponse GetAdspace(GetAdspace $GetAdspace)
[9] => GetAdspacesResponse GetAdspaces(GetAdspaces $GetAdspaces)
[10] => GetBalancesResponse GetBalances(GetBalances $GetBalances)
[11] => GetLeadsResponse GetLeads(GetLeads $GetLeads)
[12] => GetPaymentsResponse GetPayments(GetPayments $GetPayments)
[13] => GetProductResponse GetProduct(GetProduct $GetProduct)
[14] => GetProductsResponse GetProducts(GetProducts $GetProducts)
[15] => GetProfileResponse GetProfile(GetProfile $GetProfile)
[16] => GetProgramResponse GetProgram(GetProgram $GetProgram)
[17] => GetProgramCategoriesResponse
GetProgramCategories(GetProgramCategories $GetProgramCategories)
[18] => GetProgramPromotionsResponse
GetProgramPromotions(GetProgramPromotions $GetProgramPromotions)
[19] => GetProgramsResponse GetPrograms(GetPrograms $GetPrograms)
[20] => GetSalesResponse GetSales(GetSales $GetSales)
[21] => SearchProductsResponse SearchProducts(SearchProducts
$SearchProducts)
[22] => SearchProgramsResponse SearchPrograms(SearchPrograms
$SearchPrograms)
[23] => UpdateAdspaceResponse UpdateAdspace(UpdateAdspace
$UpdateAdspace)
[24] => UpdateProfileResponse UpdateProfile(UpdateProfile
$UpdateProfile)
)

Actual result:
--
Starting program: /usr/src/php/php-5.3.0/sapi/cli/php do.php
[Thread debugging using libthread_db enabled]
[New Thread 0x7f1f1691d700 (LWP 9050)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f1f1691d700 (LWP 9050)]
0x7f1f15c0cb3c in ?? () from /usr/lib/libcurl.so.4
(gdb) bt
#0  0x7f1f15c0cb3c in ?? () from /usr/lib/libcurl.so.4
#1  0x7f1f15c0d853 in ?? () from /usr/lib/libcurl.so.4
#2  0x7f1f15c18d89 in ?? () from /usr/lib/libcurl.so.4
#3  0x7f1f15c2a989 in ?? () from /usr/lib/libcurl.so.4
#4  0x7f1f15c2b01b in curl_multi_perform () from
/usr/lib/libcurl.so.4
#5  0x0048f61d in php_curl_stream_read (stream=0xb81910,
buf=0xb82df0 "", count=8192) at
/usr/src/php/php-5.3.0/ext/curl/streams.c:184
#6  0x005e3640 in php_stream_fill_read_buffer (stream=0xb81910,
size=4000) at /usr/src/php/php-5.3.0/main/streams/streams.c:562
#7  0x005e3809 in _php_stream_read (stream=0xb81910,
buf=0xbbc100 "", size=4000) at
/usr/src/php/php-5.3.0/main/streams/streams.c:605
#8  0x004605d6 in php_libxml_streams_IO_read (context=0xb81910,
buffer=0xbbc100 "", len=4000) at
/usr/src/php/php-5.3.0/ext/libxml/libxml.c:337
#9  0x7f1f143d5dff in xmlParserInputBufferGrow () from
/usr/lib/libxml2.so.2
#10 0x7f1f143aeced in xmlParserInputGrow () from
/usr/lib/libxml2.so.2
#11 0x7f1f143b3392 in ?? () from /usr/lib/libxml2.so.2
#12 0x7f1f143c59fd in xmlParseDocument () from
/usr/lib/libxml2.so.2
#13 0x00506093 in soap_xmlParseFile (filename=0xb80798
"http://api.zanox.com/wsdl";) at
/usr/src/php/php-5.3.0/ext/soap/php_xml.c:100
#14 0x004ebb30 in load_wsdl_ex (this_ptr=0xb7ea80,
struri=0xb80798 "http://api.zanox.com/wsdl";, ctx=0x7fff98d0,
include=0)
at /usr/src/php/php-5.3.0/ext/soap/php_sdl.c:240
#15 0x004eddbc in load_wsdl (this_ptr=0xb7ea80, struri=0xb80798
"http://api.zanox.com/wsdl";) at
/usr/src/php/php-5.3.0/ext/soap/php_sdl.c:654
#16 0x00504f45 in get_sdl (this_ptr=0xb7ea80, uri=0xb80798
"http://api.zanox.com/wsdl";, cache_wsdl=0) at
/usr/src/php/php-5.3.0/ext/soap/php_sdl.c:3227
#17 0x004aa2f8 in zim_SoapClient_SoapClient (ht=1,
return_value=0xb7f8b8, return_value_ptr=0x0, this_ptr=0xb7ea80,
return_value_used=0)
at /usr/src/php/php-5.3.0/ext/soap/soap.c:2671
#18 0x0066adc4 in zend_do_fcall_common_helper_SPEC
(execute_data=0x7f1f16

#49182 [Ver->Asn]: PHP CGI always outputs the shebang line

[jani]

 ID:   49182
 Updated by:   j...@php.net
 Reported By:  salsi at icosaedro dot it
-Status:   Verified
+Status:   Assigned
 Bug Type: CGI related
 Operating System: *
 PHP Version:  5.3SVN-2009-09-04 (SVN)
-Assigned To:  
+Assigned To:  iliaa
 New Comment:

Ilia's fix for bug #46844 actually broke it.


Previous Comments:


[2009-09-04 08:35:46] j...@php.net

http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_language_scanner.l?r1=272489&r2=273177
looks like the problem.



[2009-09-04 07:48:19] j...@php.net

Still happens using latest SVN checkout of today.



[2009-09-04 07:41:34] j...@php.net

Still borked.



[2009-09-04 07:34:01] niklas at narhinen dot net

Hi, using php 5.3.0.

my script is:

#!/path/to/php-cgi


and it prints "#!/path/to/php-cgi" on top of the normal phpinfo

Running Debian Etch

This bug needs to be reopened..



[2009-08-09 09:51:26] salsi at icosaedro dot it

I also noted that the CGI version considers the shebang line as
"generated output", and then namespace declarations are not allowed. For
example:

#!/usr/local/php-5.3.0/bin/php-cgi -c /home/salsi/php530/php.ini


tells

Fatal error:  Namespace declaration statement has to be the very first
statement in the script in /home/salsi/php530/test.php on line 3

The CLI version /usr/local/php-5.3.0/bin/php instead works as expected
and the  shebang line is not displayed.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/49182

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

#49362 [Csd]: Deprecated php.ini options warnings output even with display_errors=off

[jani]

 ID:   49362
 Updated by:   j...@php.net
 Reported By:  tomas dot hlavacek at firma dot volny dot cz
 Status:   Closed
 Bug Type: PHP options/info functions
 Operating System: *
 PHP Version:  5.3, 6
 Assigned To:  kalle
 New Comment:

Fixed.


Previous Comments:


[2009-09-03 21:26:00] j...@php.net

For 6: change the error reporting to E_ERROR
For 5.3: change them to E_DEPRECATED (and only really shown when that
is 
set)



[2009-09-02 16:25:22] romanf at trash dot net

Will this be fixed in 5.3? Or only in 6?

-Roman



[2009-08-26 11:08:41] j...@php.net

Correction: E_ERROR of course. :)



[2009-08-26 11:08:07] j...@php.net

And in HEAD these should be E_FATAL errors.



[2009-08-26 09:59:19] tomas dot hlavacek at firma dot volny dot cz

Yes, true. What Error Level Constant is used for showing deprecated ini
settings then?



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/49362

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

#49362 [Asn->Csd]: Deprecated php.ini options warnings output even with display_errors=off

[jani]

 ID:   49362
 Updated by:   j...@php.net
 Reported By:  tomas dot hlavacek at firma dot volny dot cz
-Status:   Assigned
+Status:   Closed
 Bug Type: PHP options/info functions
 Operating System: *
 PHP Version:  5.3, 6
 Assigned To:  kalle


Previous Comments:


[2009-09-03 21:26:00] j...@php.net

For 6: change the error reporting to E_ERROR
For 5.3: change them to E_DEPRECATED (and only really shown when that
is 
set)



[2009-09-02 16:25:22] romanf at trash dot net

Will this be fixed in 5.3? Or only in 6?

-Roman



[2009-08-26 11:08:41] j...@php.net

Correction: E_ERROR of course. :)



[2009-08-26 11:08:07] j...@php.net

And in HEAD these should be E_FATAL errors.



[2009-08-26 09:59:19] tomas dot hlavacek at firma dot volny dot cz

Yes, true. What Error Level Constant is used for showing deprecated ini
settings then?



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/49362

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

#49465 [Opn]: Soap Segmentation fault with ./configure --with-curlwrappers

[xavier at jvweb dot fr]

 ID:   49465
 User updated by:  xavier at jvweb dot fr
 Reported By:  xavier at jvweb dot fr
 Status:   Open
 Bug Type: cURL related
 Operating System: ubuntu hardy amd64
 PHP Version:  5.3.0
 New Comment:

sorry i'm tired :|

Expected result:

Array
(
[0] => CreateAdspaceResponse CreateAdspace(CreateAdspace
$CreateAdspace)
[1] => CreateProgramApplicationResponse
CreateProgramApplication(CreateProgramApplication
$CreateProgramApplication)
[2] => DeleteAdspaceResponse DeleteAdspace(DeleteAdspace
$DeleteAdspace)
[3] => DeleteProgramApplicationResponse
DeleteProgramApplication(DeleteProgramApplication
$DeleteProgramApplication)
[4] => GetAccountsResponse GetAccounts(GetAccounts $GetAccounts)
[5] => GetAdmediaResponse GetAdmedia(GetAdmedia $GetAdmedia)
[6] => GetAdmediumResponse GetAdmedium(GetAdmedium $GetAdmedium)
[7] => GetAdmediumCategoriesResponse
GetAdmediumCategories(GetAdmediumCategories $GetAdmediumCategories)
[8] => GetAdspaceResponse GetAdspace(GetAdspace $GetAdspace)
[9] => GetAdspacesResponse GetAdspaces(GetAdspaces $GetAdspaces)
[10] => GetBalancesResponse GetBalances(GetBalances $GetBalances)
[11] => GetLeadsResponse GetLeads(GetLeads $GetLeads)
[12] => GetPaymentsResponse GetPayments(GetPayments $GetPayments)
[13] => GetProductResponse GetProduct(GetProduct $GetProduct)
[14] => GetProductsResponse GetProducts(GetProducts $GetProducts)
[15] => GetProfileResponse GetProfile(GetProfile $GetProfile)
[16] => GetProgramResponse GetProgram(GetProgram $GetProgram)
[17] => GetProgramCategoriesResponse
GetProgramCategories(GetProgramCategories $GetProgramCategories)
[18] => GetProgramPromotionsResponse
GetProgramPromotions(GetProgramPromotions $GetProgramPromotions)
[19] => GetProgramsResponse GetPrograms(GetPrograms $GetPrograms)
[20] => GetSalesResponse GetSales(GetSales $GetSales)
[21] => SearchProductsResponse SearchProducts(SearchProducts
$SearchProducts)
[22] => SearchProgramsResponse SearchPrograms(SearchPrograms
$SearchPrograms)
[23] => UpdateAdspaceResponse UpdateAdspace(UpdateAdspace
$UpdateAdspace)
[24] => UpdateProfileResponse UpdateProfile(UpdateProfile
$UpdateProfile)
)

Actual result:
--
Starting program: /usr/src/php/php-5.3.0/sapi/cli/php do.php
[Thread debugging using libthread_db enabled]
[New Thread 0x7f1f1691d700 (LWP 9050)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f1f1691d700 (LWP 9050)]
0x7f1f15c0cb3c in ?? () from /usr/lib/libcurl.so.4
(gdb) bt
#0  0x7f1f15c0cb3c in ?? () from /usr/lib/libcurl.so.4
#1  0x7f1f15c0d853 in ?? () from /usr/lib/libcurl.so.4
#2  0x7f1f15c18d89 in ?? () from /usr/lib/libcurl.so.4
#3  0x7f1f15c2a989 in ?? () from /usr/lib/libcurl.so.4
#4  0x7f1f15c2b01b in curl_multi_perform () from
/usr/lib/libcurl.so.4
#5  0x0048f61d in php_curl_stream_read (stream=0xb81910,
buf=0xb82df0 "", count=8192) at
/usr/src/php/php-5.3.0/ext/curl/streams.c:184
#6  0x005e3640 in php_stream_fill_read_buffer (stream=0xb81910,
size=4000) at /usr/src/php/php-5.3.0/main/streams/streams.c:562
#7  0x005e3809 in _php_stream_read (stream=0xb81910,
buf=0xbbc100 "", size=4000) at
/usr/src/php/php-5.3.0/main/streams/streams.c:605
#8  0x004605d6 in php_libxml_streams_IO_read (context=0xb81910,
buffer=0xbbc100 "", len=4000) at
/usr/src/php/php-5.3.0/ext/libxml/libxml.c:337
#9  0x7f1f143d5dff in xmlParserInputBufferGrow () from
/usr/lib/libxml2.so.2
#10 0x7f1f143aeced in xmlParserInputGrow () from
/usr/lib/libxml2.so.2
#11 0x7f1f143b3392 in ?? () from /usr/lib/libxml2.so.2
#12 0x7f1f143c59fd in xmlParseDocument () from
/usr/lib/libxml2.so.2
#13 0x00506093 in soap_xmlParseFile (filename=0xb80798
"http://api.zanox.com/wsdl";) at
/usr/src/php/php-5.3.0/ext/soap/php_xml.c:100
#14 0x004ebb30 in load_wsdl_ex (this_ptr=0xb7ea80,
struri=0xb80798 "http://api.zanox.com/wsdl";, ctx=0x7fff98d0,
include=0)
at /usr/src/php/php-5.3.0/ext/soap/php_sdl.c:240
#15 0x004eddbc in load_wsdl (this_ptr=0xb7ea80, struri=0xb80798
"http://api.zanox.com/wsdl";) at
/usr/src/php/php-5.3.0/ext/soap/php_sdl.c:654
#16 0x00504f45 in get_sdl (this_ptr=0xb7ea80, uri=0xb80798
"http://api.zanox.com/wsdl";, cache_wsdl=0) at
/usr/src/php/php-5.3.0/ext/soap/php_sdl.c:3227
#17 0x004aa2f8 in zim_SoapClient_SoapClient (ht=1,
return_value=0xb7f8b8, return_value_ptr=0x0, this_ptr=0xb7ea80,
return_value_used=0)
at /usr/src/php/php-5.3.0/ext/soap/soap.c:2671
#18 0x0066adc4 in zend_do_fcall_common_helper_SPEC
(execute_data=0x7f1f1680c090) at
/usr/src/php/php-5.3.0/Zend/zend_vm_execute.h:313
#19 0x0066bba8 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7f1f1680c090) at
/usr/src/php/php-5.3.0/Zend/zend_vm_execute.h:422
#20 0x0066a018 in execute (op_array=0xb7f710) at
/usr/src/php/php-5.3.0/Zend/

#49465 [Opn]: Soap Segmentation fault with ./configure --with-curlwrappers

[xavier at jvweb dot fr]

 ID:   49465
 User updated by:  xavier at jvweb dot fr
 Reported By:  xavier at jvweb dot fr
 Status:   Open
 Bug Type: cURL related
 Operating System: ubuntu hardy amd64
 PHP Version:  5.3.0
 New Comment:

oups, got midle click pb:
Actual result:
--
>__getFunctions());'
Array
(
[0] => CreateAdspaceResponse CreateAdspace(CreateAdspace
$CreateAdspace)
[1] => CreateProgramApplicationResponse
CreateProgramApplication(CreateProgramApplication
$CreateProgramApplication)
[2] => DeleteAdspaceResponse DeleteAdspace(DeleteAdspace
$DeleteAdspace)
[3] => DeleteProgramApplicationResponse
DeleteProgramApplication(DeleteProgramApplication
$DeleteProgramApplication)
[4] => GetAccountsResponse GetAccounts(GetAccounts $GetAccounts)
[5] => GetAdmediaResponse GetAdmedia(GetAdmedia $GetAdmedia)
[6] => GetAdmediumResponse GetAdmedium(GetAdmedium $GetAdmedium)
[7] => GetAdmediumCategoriesResponse
GetAdmediumCategories(GetAdmediumCategories $GetAdmediumCategories)
[8] => GetAdspaceResponse GetAdspace(GetAdspace $GetAdspace)
[9] => GetAdspacesResponse GetAdspaces(GetAdspaces $GetAdspaces)
[10] => GetBalancesResponse GetBalances(GetBalances $GetBalances)
[11] => GetLeadsResponse GetLeads(GetLeads $GetLeads)
[12] => GetPaymentsResponse GetPayments(GetPayments $GetPayments)
[13] => GetProductResponse GetProduct(GetProduct $GetProduct)
[14] => GetProductsResponse GetProducts(GetProducts $GetProducts)
[15] => GetProfileResponse GetProfile(GetProfile $GetProfile)
[16] => GetProgramResponse GetProgram(GetProgram $GetProgram)
[17] => GetProgramCategoriesResponse
GetProgramCategories(GetProgramCategories $GetProgramCategories)
[18] => GetProgramPromotionsResponse
GetProgramPromotions(GetProgramPromotions $GetProgramPromotions)
[19] => GetProgramsResponse GetPrograms(GetPrograms $GetPrograms)
[20] => GetSalesResponse GetSales(GetSales $GetSales)
[21] => SearchProductsResponse SearchProducts(SearchProducts
$SearchProducts)
[22] => SearchProgramsResponse SearchPrograms(SearchPrograms
$SearchPrograms)
[23] => UpdateAdspaceResponse UpdateAdspace(UpdateAdspace
$UpdateAdspace)
[24] => UpdateProfileResponse UpdateProfile(UpdateProfile
$UpdateProfile)
)


Previous Comments:


[2009-09-04 10:10:18] xavier at jvweb dot fr

Description:

A wsdl load via the SoapClient object generate a segmentation fault
with curl wrappers enabled

Reproduce code:
---
http://api.zanox.com/wsdl";); 

print_r($s->__getFunctions());
?>


./configure \
--prefix=/usr \
--disable-all \
--enable-soap \
--enable-libxml \
--with-curl \
--with-curlwrappers \



gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-mpfr --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu4)


Expected result:

Starting program: /usr/src/php/php-5.3.0/sapi/cli/php do.php
[Thread debugging using libthread_db enabled]
[New Thread 0x7f1f1691d700 (LWP 9050)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f1f1691d700 (LWP 9050)]
0x7f1f15c0cb3c in ?? () from /usr/lib/libcurl.so.4
(gdb) bt
#0  0x7f1f15c0cb3c in ?? () from /usr/lib/libcurl.so.4
#1  0x7f1f15c0d853 in ?? () from /usr/lib/libcurl.so.4
#2  0x7f1f15c18d89 in ?? () from /usr/lib/libcurl.so.4
#3  0x7f1f15c2a989 in ?? () from /usr/lib/libcurl.so.4
#4  0x7f1f15c2b01b in curl_multi_perform () from
/usr/lib/libcurl.so.4
#5  0x0048f61d in php_curl_stream_read (stream=0xb81910,
buf=0xb82df0 "", count=8192) at
/usr/src/php/php-5.3.0/ext/curl/streams.c:184
#6  0x005e3640 in php_stream_fill_read_buffer (stream=0xb81910,
size=4000) at /usr/src/php/php-5.3.0/main/streams/streams.c:562
#7  0x005e3809 in _php_stream_read (stream=0xb81910,
buf=0xbbc100 "", size=4000) at
/usr/src/php/php-5.3.0/main/streams/streams.c:605
#8  0x004605d6 in php_libxml_streams_IO_read (context=0xb81910,
buffer=0xbbc100 "", len=4000) at
/usr/src/php/php-5.3.0/ext/libxml/libxml.c:337
#9  0x7f1f143d5dff in xmlParserInputBufferGrow () from
/usr/lib/libxml2.so.2
#10 0x7f1f143aeced in xmlParserInputGrow () from
/usr/lib/libxml2.so.2
#11 0x7f1f143b3392 in ?? () from /usr/lib/libxml2.so.2
#12 0x7f1f143c59fd in xmlParseDocument () from
/usr/lib/libxml2.so.2
#13 0x00506093 in soap_xmlParseFile (filename=0xb80798
"http://api.zanox.com/wsdl";) at
/usr/src/php/php-

#49465 [NEW]: Soap Segmentation fault with ./configure --with-curlwrappers

[xavier at jvweb dot fr]

From: xavier at jvweb dot fr
Operating system: ubuntu hardy amd64
PHP version:  5.3.0
PHP Bug Type: cURL related
Bug description:  Soap Segmentation fault with ./configure --with-curlwrappers

Description:

A wsdl load via the SoapClient object generate a segmentation fault with
curl wrappers enabled

Reproduce code:
---
http://api.zanox.com/wsdl";); 

print_r($s->__getFunctions());
?>


./configure \
--prefix=/usr \
--disable-all \
--enable-soap \
--enable-libxml \
--with-curl \
--with-curlwrappers \



gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-mpfr --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu4)


Expected result:

Starting program: /usr/src/php/php-5.3.0/sapi/cli/php do.php
[Thread debugging using libthread_db enabled]
[New Thread 0x7f1f1691d700 (LWP 9050)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f1f1691d700 (LWP 9050)]
0x7f1f15c0cb3c in ?? () from /usr/lib/libcurl.so.4
(gdb) bt
#0  0x7f1f15c0cb3c in ?? () from /usr/lib/libcurl.so.4
#1  0x7f1f15c0d853 in ?? () from /usr/lib/libcurl.so.4
#2  0x7f1f15c18d89 in ?? () from /usr/lib/libcurl.so.4
#3  0x7f1f15c2a989 in ?? () from /usr/lib/libcurl.so.4
#4  0x7f1f15c2b01b in curl_multi_perform () from
/usr/lib/libcurl.so.4
#5  0x0048f61d in php_curl_stream_read (stream=0xb81910,
buf=0xb82df0 "", count=8192) at
/usr/src/php/php-5.3.0/ext/curl/streams.c:184
#6  0x005e3640 in php_stream_fill_read_buffer (stream=0xb81910,
size=4000) at /usr/src/php/php-5.3.0/main/streams/streams.c:562
#7  0x005e3809 in _php_stream_read (stream=0xb81910, buf=0xbbc100
"", size=4000) at /usr/src/php/php-5.3.0/main/streams/streams.c:605
#8  0x004605d6 in php_libxml_streams_IO_read (context=0xb81910,
buffer=0xbbc100 "", len=4000) at
/usr/src/php/php-5.3.0/ext/libxml/libxml.c:337
#9  0x7f1f143d5dff in xmlParserInputBufferGrow () from
/usr/lib/libxml2.so.2
#10 0x7f1f143aeced in xmlParserInputGrow () from
/usr/lib/libxml2.so.2
#11 0x7f1f143b3392 in ?? () from /usr/lib/libxml2.so.2
#12 0x7f1f143c59fd in xmlParseDocument () from /usr/lib/libxml2.so.2
#13 0x00506093 in soap_xmlParseFile (filename=0xb80798
"http://api.zanox.com/wsdl";) at
/usr/src/php/php-5.3.0/ext/soap/php_xml.c:100
#14 0x004ebb30 in load_wsdl_ex (this_ptr=0xb7ea80, struri=0xb80798
"http://api.zanox.com/wsdl";, ctx=0x7fff98d0, include=0)
at /usr/src/php/php-5.3.0/ext/soap/php_sdl.c:240
#15 0x004eddbc in load_wsdl (this_ptr=0xb7ea80, struri=0xb80798
"http://api.zanox.com/wsdl";) at
/usr/src/php/php-5.3.0/ext/soap/php_sdl.c:654
#16 0x00504f45 in get_sdl (this_ptr=0xb7ea80, uri=0xb80798
"http://api.zanox.com/wsdl";, cache_wsdl=0) at
/usr/src/php/php-5.3.0/ext/soap/php_sdl.c:3227
#17 0x004aa2f8 in zim_SoapClient_SoapClient (ht=1,
return_value=0xb7f8b8, return_value_ptr=0x0, this_ptr=0xb7ea80,
return_value_used=0)
at /usr/src/php/php-5.3.0/ext/soap/soap.c:2671
#18 0x0066adc4 in zend_do_fcall_common_helper_SPEC
(execute_data=0x7f1f1680c090) at
/usr/src/php/php-5.3.0/Zend/zend_vm_execute.h:313
#19 0x0066bba8 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7f1f1680c090) at
/usr/src/php/php-5.3.0/Zend/zend_vm_execute.h:422
#20 0x0066a018 in execute (op_array=0xb7f710) at
/usr/src/php/php-5.3.0/Zend/zend_vm_execute.h:104
#21 0x0063b268 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/php/php-5.3.0/Zend/zend.c:1188
#22 0x005c9994 in php_execute_script (primary_file=0x7fffd7e0)
at /usr/src/php/php-5.3.0/main/main.c:2196
#23 0x0071e345 in main (argc=2, argv=0x7fffda48) at
/usr/src/php/php-5.3.0/sapi/cli/php_cli.c:1188


Actual result:
--
Starting program: /usr/src/php/php-5.3.0/sapi/cli/php do.php
[Thread debugging using libthread_db enabled]
[New Thread 0x7f1f1691d700 (LWP 9050)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f1f1691d700 (LWP 9050)]
0x7f1f15c0cb3c in ?? () from /usr/lib/libcurl.so.4
(gdb) bt
#0  0x7f1f15c0cb3c in ?? () from /usr/lib/libcurl.so.4
#1  0x7f1f15c0d853 in ?? () from /usr/lib/libcurl.so.4
#2  0x7f1f15c18d89 in ?? () from /usr/lib/libcurl.so.4
#3  0x7f1f15c2a989 in ?? () from /usr/lib/libcurl.so.4
#4  0x7f1f15c2b01b in curl_multi_perform () from
/usr/lib/libcurl.so.4
#5  0x0048f61d in php_curl_stream_read (stream=0xb81910,
buf=0xb82df0 "", count=8192) at
/u

#49447 [Asn->Csd]: php engine need to correctly check for socket API return status on windows

[srinatar]

 ID:   49447
 Updated by:   srina...@php.net
 Reported By:  sriram dot natarajan at gmail dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: Sockets related
 Operating System: win32 only - windows xp
 PHP Version:  5.3.0
 Assigned To:  srinatar
 New Comment:

This bug has been fixed in SVN.

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

fix for this issue has been integrated


Previous Comments:


[2009-09-04 07:59:49] s...@php.net

Automatic comment from SVN on behalf of srinatar
Revision: http://svn.php.net/viewvc/?view=revision&revision=288034
Log: - Fixed bug #49447 (php engine need to correctly check for socket
API
  return status on windows). (Sriram Natarajan)



[2009-09-03 01:39:46] srina...@php.net

here is the patch to address this issue. 

Index: ext/openssl/xp_ssl.c
===
--- ext/openssl/xp_ssl.c(revision 287975)
+++ ext/openssl/xp_ssl.c(working copy)
@@ -259,6 +259,10 @@
SSL_CTX_free(sslsock->ctx);
sslsock->ctx = NULL;
}
+#ifdef PHP_WIN32
+   if (sslsock->s.socket == -1)
+   sslsock->s.socket = SOCK_ERR;
+#endif
if (sslsock->s.socket != SOCK_ERR) {
 #ifdef PHP_WIN32
/* prevent more data from coming in */
Index: ext/ftp/ftp.c
===
--- ext/ftp/ftp.c   (revision 287975)
+++ ext/ftp/ftp.c   (working copy)
@@ -147,7 +147,7 @@
 
size = sizeof(ftp->localaddr);
memset(&ftp->localaddr, 0, size);
-   if (getsockname(ftp->fd, (struct sockaddr*) &ftp->localaddr, &size)
== -1) {
+   if (getsockname(ftp->fd, (struct sockaddr*) &ftp->localaddr, &size)
!= 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "getsockname 
failed: %s
(%d)", strerror(errno), errno);
goto bail;
}
@@ -1387,7 +1387,7 @@
 
sa = (struct sockaddr *) &ftp->localaddr;
/* bind/listen */
-   if ((fd = socket(sa->sa_family, SOCK_STREAM, 0)) == -1) {
+   if ((fd = socket(sa->sa_family, SOCK_STREAM, 0)) == SOCK_ERR) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "socket() failed: %s
(%d)", strerror(errno), errno);
goto bail;
}
@@ -1420,17 +1420,17 @@
php_any_addr(sa->sa_family, &addr, 0);
size = php_sockaddr_size(&addr);
 
-   if (bind(fd, (struct sockaddr*) &addr, size) == -1) {
+   if (bind(fd, (struct sockaddr*) &addr, size) != 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "bind() failed: %s
(%d)", strerror(errno), errno);
goto bail;
}
 
-   if (getsockname(fd, (struct sockaddr*) &addr, &size) == -1) {
+   if (getsockname(fd, (struct sockaddr*) &addr, &size) != 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "getsockname() 
failed:
%s (%d)", strerror(errno), errno);
goto bail;
}
 
-   if (listen(fd, 5) == -1) {
+   if (listen(fd, 5) != 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "listen() failed: %s
(%d)", strerror(errno), errno);
goto bail;
}
Index: ext/sockets/sockets.c
===
--- ext/sockets/sockets.c   (revision 287975)
+++ ext/sockets/sockets.c   (working copy)
@@ -370,14 +370,14 @@
 
sock->type = PF_INET;
 
-   if (bind(sock->bsd_socket, (struct sockaddr *)&la, sizeof(la)) < 0)
{
+   if (bind(sock->bsd_socket, (struct sockaddr *)&la, sizeof(la)) != 0)
{
PHP_SOCKET_ERROR(sock, "unable to bind to given address", 
errno);
close(sock->bsd_socket);
efree(sock);
return 0;
}
 
-   if (listen(sock->bsd_socket, backlog) < 0) {
+   if (listen(sock->bsd_socket, backlog) != 0) {
PHP_SOCKET_ERROR(sock, "unable to listen on socket", errno);
close(sock->bsd_socket);
efree(sock);
Index: main/network.c
===
--- main/network.c  (revision 287975)
+++ main/network.c  (working copy)
@@ -314,7 +314,7 @@
 
SET_SOCKET_BLOCKING_MODE(sockfd, orig_flags);

-   if ((n = connect(sockfd, addr, addrlen)) < 0) {
+   if ((n = connect(sockfd, addr, addrlen)) != 0) {
error = php_socket_errno();
 
if (error_code) {
@@ -348,7 +348,7 @@
   BSD-derived systems set errno correctly
  

#49182 [Ver]: PHP CGI always outputs the shebang line

[joey]

 ID:   49182
 Updated by:   j...@php.net
 Reported By:  salsi at icosaedro dot it
 Status:   Verified
 Bug Type: CGI related
 Operating System: *
 PHP Version:  5.3SVN-2009-09-04 (SVN)
 New Comment:

http://svn.php.net/viewvc/php/php-src/trunk/Zend/zend_language_scanner.l?r1=272489&r2=273177
looks like the problem.


Previous Comments:


[2009-09-04 07:48:19] j...@php.net

Still happens using latest SVN checkout of today.



[2009-09-04 07:41:34] j...@php.net

Still borked.



[2009-09-04 07:34:01] niklas at narhinen dot net

Hi, using php 5.3.0.

my script is:

#!/path/to/php-cgi


and it prints "#!/path/to/php-cgi" on top of the normal phpinfo

Running Debian Etch

This bug needs to be reopened..



[2009-08-09 09:51:26] salsi at icosaedro dot it

I also noted that the CGI version considers the shebang line as
"generated output", and then namespace declarations are not allowed. For
example:

#!/usr/local/php-5.3.0/bin/php-cgi -c /home/salsi/php530/php.ini


tells

Fatal error:  Namespace declaration statement has to be the very first
statement in the script in /home/salsi/php530/test.php on line 3

The CLI version /usr/local/php-5.3.0/bin/php instead works as expected
and the  shebang line is not displayed.



[2009-08-06 20:45:08] salsi at icosaedro dot it

I'm using Apache 2.2.8 + suexec without any support for PHP (it
executes only CGI programs) and all worked well with PHP 5.2.5 I used
until now. But this should not care, as in my opinion the shebang should
not be displayed once the script has been detected to be executed as a
program.

I configured PHP as follows:

./configure \
--disable-all \
--prefix=/usr/local/php-5.3.0 \
--exec-prefix=/usr/local/php-5.3.0 \
--disable-rpath \
--disable-ipv6 \
--enable-ftp=shared \
--enable-sockets=shared \
--enable-tokenizer \
--with-gnu-ld=shared \
--with-pgsql=shared \
--enable-session \
--enable-posix \
--with-pcre-regex \
--enable-mbstring=all \
--enable-mbregex \
--enable-libxml \
--enable-xml \
--enable-dom \
--enable-pdo

I can also confirm that with the old version of PHP the shebang line
did not came out under Apache and neither did it under the command line.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/49182

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

#48746 [Com]: Unable to browse directories within Junction Points

[mats dot lindh at gmail dot com]

 ID:   48746
 Comment by:   mats dot lindh at gmail dot com
 Reported By:  ddkees at illinois dot edu
 Status:   Feedback
 Bug Type: Directory function related
 Operating System: win32 only - Windows Server 2003
 PHP Version:  5.3.0
 Assigned To:  pajoye
 New Comment:

Everything seems to work OK with a build from 2009-09-03. Thanks for
fixing the issue!


Previous Comments:


[2009-09-03 10:10:14] phpstuff at cresstone dot com

I'm getting good test behavior from the that snapshot. More tellingly,
the original script I've been trying to run is now working correctly.

Thanks.



[2009-09-02 23:26:04] paj...@php.net

I can't reproduce the problem with is_dir or is_file behave correctly,
however I think I found the problem and commited a fix.

I can reproduce the scandir one, same fix. I manually launched a build,
you can get the vc9-x86 here: http://is.gd/2OtDf (other snaps should be
online within 15mins).





[2009-09-02 22:59:59] s...@php.net

Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=287975
Log: - #48746, len includes null already



[2009-09-02 21:29:08] phpstuff at cresstone dot com

Using Windows 7 x64. It seems all files in my mounted volumes are being
treated as directories. (is_dir returns true, is_file returns false.)
Directory operations pointed at files seem to point back to the root of
the volume.

The following script:
echo "dumping: scandir('mounted_volume')\n";
var_dump(scandir('mounted_volume'));
echo "dumping: scandir('mounted_volume\\file1')\n";
var_dump(scandir('mounted_volume\file1'));

gives this output:



dumping: scandir('mounted_volume')
array(4) {
  [0]=>
  string(12) "$RECYCLE.BIN"
  [1]=>
  string(4) "dir1"
  [2]=>
  string(4) "dir2"
  [3]=>
  string(5) "file1"
}
dumping: scandir('mounted_volume\file1')
array(4) {
  [0]=>
  string(12) "$RECYCLE.BIN"
  [1]=>
  string(4) "dir1"
  [2]=>
  string(4) "dir2"
  [3]=>
  string(5) "file1"
}

Nesting does not seem to matter, eg:
scandir('mounted_volume\dir1\file_in_dir1'); gives the same output


Something else that's interesting... When I create the junction from a
drive letter, eg: "mklink mounted_volume y:" everything works perfectly,
files are files and dirs are dirs. It's only when I use the volume name
in the creation ("mklink /J mounted_volume
\\?\Volume{feeac7c1-2ad0-11de-89bb-001fd0ae05ac}\") that I get this
strange behavior. Bizarre, but I swear I'm not making this up :)



[2009-09-02 10:35:32] paj...@php.net

Can't reproduce here. Which OS are you using for this test?



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/48746

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

#49182 [Ver]: PHP CGI always outputs the shebang line

[jani]

 ID:   49182
 Updated by:   j...@php.net
 Reported By:  salsi at icosaedro dot it
 Status:   Verified
 Bug Type: CGI related
 Operating System: *
 PHP Version:  5.3SVN-2009-09-04 (SVN)
 New Comment:

Still happens using latest SVN checkout of today.


Previous Comments:


[2009-09-04 07:41:34] j...@php.net

Still borked.



[2009-09-04 07:34:01] niklas at narhinen dot net

Hi, using php 5.3.0.

my script is:

#!/path/to/php-cgi


and it prints "#!/path/to/php-cgi" on top of the normal phpinfo

Running Debian Etch

This bug needs to be reopened..



[2009-08-09 09:51:26] salsi at icosaedro dot it

I also noted that the CGI version considers the shebang line as
"generated output", and then namespace declarations are not allowed. For
example:

#!/usr/local/php-5.3.0/bin/php-cgi -c /home/salsi/php530/php.ini


tells

Fatal error:  Namespace declaration statement has to be the very first
statement in the script in /home/salsi/php530/test.php on line 3

The CLI version /usr/local/php-5.3.0/bin/php instead works as expected
and the  shebang line is not displayed.



[2009-08-06 20:45:08] salsi at icosaedro dot it

I'm using Apache 2.2.8 + suexec without any support for PHP (it
executes only CGI programs) and all worked well with PHP 5.2.5 I used
until now. But this should not care, as in my opinion the shebang should
not be displayed once the script has been detected to be executed as a
program.

I configured PHP as follows:

./configure \
--disable-all \
--prefix=/usr/local/php-5.3.0 \
--exec-prefix=/usr/local/php-5.3.0 \
--disable-rpath \
--disable-ipv6 \
--enable-ftp=shared \
--enable-sockets=shared \
--enable-tokenizer \
--with-gnu-ld=shared \
--with-pgsql=shared \
--enable-session \
--enable-posix \
--with-pcre-regex \
--enable-mbstring=all \
--enable-mbregex \
--enable-libxml \
--enable-xml \
--enable-dom \
--enable-pdo

I can also confirm that with the old version of PHP the shebang line
did not came out under Apache and neither did it under the command line.



[2009-08-06 20:01:38] j...@php.net

What webserver? How did you configure PHP into it? 



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/49182

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

#42886 [Bgs]: openssl_x509_checkpurpose returns int(0) on valid public certificate

[tokul at users dot sourceforge dot net]

 ID:   42886
 User updated by:  tokul at users dot sourceforge dot net
 Reported By:  tokul at users dot sourceforge dot net
 Status:   Bogus
 Bug Type: OpenSSL related
 Operating System: Linux Debian Etch
 PHP Version:  5CVS-2008-11-01
 Assigned To:  pajoye
 New Comment:

I don't agree that bug is bogus.

1. /usr/bin/openssl works without any chain certificate arguments.
2. how am I supposed to know all chained certificates and why do I have
to go through all the trouble of getting them in order to check
certificates. function should use trusted system certificates like
/usr/bin/openssl does (if /usr/bin/openssl does it).
3. Bug report also states that function returns integer value when one
part of documentation states that it should return boolean or different
integer value.

Even if bug report is bogus, documentation is still broken.


Previous Comments:


[2009-09-04 06:40:23] paj...@php.net

@ryan+phpbugs at sleevi dot com

Thanks for the detailed explanation. And you are right about the
conclusions. That's also not something we should try to change from PHP
(if there was a bug), that's openssl's job.



[2009-09-04 05:06:16] ryan+phpbugs at sleevi dot com

The problem is not resolved in PHP 5.2.6, provided you call it
correctly.

openssl_x509_checkpurpose expects to be able to build a full chain of
certificates to verify its purpose. Furthermore, it expects there to be
a trusted certificate as part of the chain.

When invoked as 

var_dump(openssl_x509_checkpurpose(file_get_contents('./certfile.pem').
X509_PURPOSE_SMIME_SIGN));

this fails, because a chain cannot properly be built to a trusted
root.

My test case involved:
  - Obtaining Using the Thawte intermediate and root certificates,
obtained via http://www.thawte.com/repository/index.html 
  - Copying the contents of the Thawte Personal Freemail Issuing CA and
Thawte Personal Freemail CA PEM files from that list into a new file,
called 'chain.pem'. The certs were simply appended one after the other
  - Setting the system time to be during the validity period of the
certificate (2007-10-10 00:00:00 GMT)
  - executing as
var_dump(openssl_x509_checkpurpose(file_get_contents('./certfile.pem').
X509_PURPOSE_SMIME_SIGN, array('./chain.pem'));
  - I received int(1) as the result

I do not believe the reporter's initial case should be supported.
Purpose checking requires checking each of the CAs that issued the
certificate to make sure there are no purpose constraints. The absence
of the CA certificates makes this impossible, hence the failure.

If one wishes to obtain any X509 certificate extensions for a single
certificate, openssl_x509_parse is able to provide this information.
However, it should not be treated as authoritative, as it does not
reflect the full chain policy being enforced for that certificate.

My OpenSSL version was 0.9.8f, running Linux kernel 2.6.14.6 and PHP
5.2.6. While these versions do differ from the original submission, with
the above explanation, it should provide enough information to see if
this does resolve the situation with purpose verification.



[2008-11-18 10:09:50] paj...@php.net

It seems to be a bug in the openssl directly. I have tried with many
different certs and many failed (including the one available in the
openssl's demo directory).

I have to work on other things now, the fix may require to duplicate
the x509_verify_cert code (partially or completely).

tested with 0.98g and 0.9.8i



[2008-11-01 21:13:07] tokul at users dot sourceforge dot net

php 5.2-200811011530

Test result is the same. It is impossible to verify purpose of
certificate, because function returns integer value which is evaluated
as false even when certificate can be used for SMIME signatures.

I don't know options that Thawte used to generate certificate. I've
accepted default options with 2048-bit encryption for Mozilla
Firefox/Thunderbird.

Here goes already expired certificate used for initial bug report.

-BEGIN CERTIFICATE-
MIIC8DCCAlmgAwIBAgIQS8GxvbV7pghz0FD/I7rVVjANBgkqhkiG9w0BAQUFADBi
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg
Q0EwHhcNMDcwMjI0MDYyMzA0WhcNMDgwMjI0MDYyMzA0WjBNMR8wHQYDVQQDExZU
aGF3dGUgRnJlZW1haWwgTWVtYmVyMSowKAYJKoZIhvcNAQkBFht0b2t1bEB1c2Vy
cy5zb3VyY2Vmb3JnZS5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDQALcUK5moBKz5tHqYcquqb8seEKgzDbFJ3Nko8VEyVy1vnwKtHkNeXuMv1mbH
2dhkvI2JtWpNte36bzLErQHzZhnehAdRb3RIlLrASxkn4btidkWasYjqhtMI1sGL
D+7wFdC4rSfdYwRUto8zrB5FeoNakJre8gmljqwm18fh5ZMsiWboXdKVVCa8ALBk
P5dZ7gYElfNj3FJSjqo0Efs5yQn8EsY+uDNTH+y8HE5Sqq0mkuLw/7WIO5PCsQAF
xTsEo2dqnj3us9KGgNGkR4JRp17NPfNofLs26w

#49182 [NoF->Ver]: PHP CGI always outputs the shebang line

[jani]

 ID:   49182
 Updated by:   j...@php.net
 Reported By:  salsi at icosaedro dot it
-Status:   No Feedback
+Status:   Verified
 Bug Type: CGI related
-Operating System: Slackware 12.0
+Operating System: *
-PHP Version:  5.3SVN-2009-08-06 (SVN)
+PHP Version:  5.3SVN-2009-09-04 (SVN)
 New Comment:

Still borked.


Previous Comments:


[2009-09-04 07:34:01] niklas at narhinen dot net

Hi, using php 5.3.0.

my script is:

#!/path/to/php-cgi


and it prints "#!/path/to/php-cgi" on top of the normal phpinfo

Running Debian Etch

This bug needs to be reopened..



[2009-08-14 01:00:02] php-bugs at lists dot php dot net

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



[2009-08-09 09:51:26] salsi at icosaedro dot it

I also noted that the CGI version considers the shebang line as
"generated output", and then namespace declarations are not allowed. For
example:

#!/usr/local/php-5.3.0/bin/php-cgi -c /home/salsi/php530/php.ini


tells

Fatal error:  Namespace declaration statement has to be the very first
statement in the script in /home/salsi/php530/test.php on line 3

The CLI version /usr/local/php-5.3.0/bin/php instead works as expected
and the  shebang line is not displayed.



[2009-08-06 20:45:08] salsi at icosaedro dot it

I'm using Apache 2.2.8 + suexec without any support for PHP (it
executes only CGI programs) and all worked well with PHP 5.2.5 I used
until now. But this should not care, as in my opinion the shebang should
not be displayed once the script has been detected to be executed as a
program.

I configured PHP as follows:

./configure \
--disable-all \
--prefix=/usr/local/php-5.3.0 \
--exec-prefix=/usr/local/php-5.3.0 \
--disable-rpath \
--disable-ipv6 \
--enable-ftp=shared \
--enable-sockets=shared \
--enable-tokenizer \
--with-gnu-ld=shared \
--with-pgsql=shared \
--enable-session \
--enable-posix \
--with-pcre-regex \
--enable-mbstring=all \
--enable-mbregex \
--enable-libxml \
--enable-xml \
--enable-dom \
--enable-pdo

I can also confirm that with the old version of PHP the shebang line
did not came out under Apache and neither did it under the command line.



[2009-08-06 20:01:38] j...@php.net

What webserver? How did you configure PHP into it? 



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/49182

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

#49182 [Com]: PHP CGI always outputs the shebang line

[niklas at narhinen dot net]

 ID:   49182
 Comment by:   niklas at narhinen dot net
 Reported By:  salsi at icosaedro dot it
 Status:   No Feedback
 Bug Type: CGI related
 Operating System: Slackware 12.0
 PHP Version:  5.3SVN-2009-08-06 (SVN)
 New Comment:

Hi, using php 5.3.0.

my script is:

#!/path/to/php-cgi


and it prints "#!/path/to/php-cgi" on top of the normal phpinfo

Running Debian Etch

This bug needs to be reopened..


Previous Comments:


[2009-08-14 01:00:02] php-bugs at lists dot php dot net

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



[2009-08-09 09:51:26] salsi at icosaedro dot it

I also noted that the CGI version considers the shebang line as
"generated output", and then namespace declarations are not allowed. For
example:

#!/usr/local/php-5.3.0/bin/php-cgi -c /home/salsi/php530/php.ini


tells

Fatal error:  Namespace declaration statement has to be the very first
statement in the script in /home/salsi/php530/test.php on line 3

The CLI version /usr/local/php-5.3.0/bin/php instead works as expected
and the  shebang line is not displayed.



[2009-08-06 20:45:08] salsi at icosaedro dot it

I'm using Apache 2.2.8 + suexec without any support for PHP (it
executes only CGI programs) and all worked well with PHP 5.2.5 I used
until now. But this should not care, as in my opinion the shebang should
not be displayed once the script has been detected to be executed as a
program.

I configured PHP as follows:

./configure \
--disable-all \
--prefix=/usr/local/php-5.3.0 \
--exec-prefix=/usr/local/php-5.3.0 \
--disable-rpath \
--disable-ipv6 \
--enable-ftp=shared \
--enable-sockets=shared \
--enable-tokenizer \
--with-gnu-ld=shared \
--with-pgsql=shared \
--enable-session \
--enable-posix \
--with-pcre-regex \
--enable-mbstring=all \
--enable-mbregex \
--enable-libxml \
--enable-xml \
--enable-dom \
--enable-pdo

I can also confirm that with the old version of PHP the shebang line
did not came out under Apache and neither did it under the command line.



[2009-08-06 20:01:38] j...@php.net

What webserver? How did you configure PHP into it? 



[2009-08-06 18:59:41] salsi at icosaedro dot it

Description:

Executing any PHP CGI script always results in the shebang line being
displayed along the correct HTML code of the WEB page.
This happens with and without the --enable-discard-path configuration
flag (although I'm not really sure this flag be realted to the issue or
not).

Reproduce code:
---
#!/usr/local/php-5.3.0/bin/php-cgi -c /home/salsi/php530/php.ini



Expected result:

$ ./shebang.php 
X-Powered-By: PHP/5.3.1-dev
Content-type: text/html

5.3.1-dev

Actual result:
--
$ ./shebang.php 
X-Powered-By: PHP/5.3.1-dev
Content-type: text/html

#!/usr/local/php-5.3.0/bin/php-cgi -c /home/salsi/php530/php.ini
5.3.1-dev





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

#47236 [Com]: Server Cert not captured when using TLS

[ryan+phpbugs at sleevi dot com]

 ID:   47236
 Comment by:   ryan+phpbugs at sleevi dot com
 Reported By:  BenBE at geshi dot org
 Status:   Verified
 Bug Type: OpenSSL related
 Operating System: *
 PHP Version:  5.*, 6CVS (2009-01-31)
 New Comment:

This is a documentation bug. I am unable to find any documentation that
explicitly states the wrapper for SSL (v2 | v3) and TLS (v1), in
addition to HTTPS and FTPS, is always 'SSL'

The documentation at
http://us.php.net/manual/en/function.stream-context-set-option.php
simply states you must supply 'wrapper', but
http://us.php.net/manual/en/context.ssl.php fails to explicitly state
that the 'wrapper' value is 'ssl' (although one may infer from the
title)

Below is the proper code, which makes a distinction between the wrapper
(used to set/retrieve options) and the mode (or protocol, which can be
'ssl', 'tls', 'sslv2' or 'sslv3' as documented at
http://us.php.net/manual/en/transports.inet.php )

http://bugs.php.net/?id=47236&edit=1