Bug #65460 [Com]: PHP 5.4.18 fails to compile with Apache 2.4.6

[ben dot harper at rackspace dot com]

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

 ID: 65460
 Comment by:     ben dot harper at rackspace dot com
 Reported by:stu at coe dot uky dot edu
 Summary:PHP 5.4.18 fails to compile with Apache 2.4.6
 Status: Assigned
 Type:   Bug
 Package:Compile Failure
 Operating System:   Slackware64 14.0
 PHP Version:5.4.18
 Assigned To:stas
 Block user comment: N
 Private report: N

 New Comment:

Like giamteckchoon, I did not get this error with this solution on RHEL 6, but 
not RHEL 5.  I get the following error:

+ rm Zend/zend_language_parser.c Zend/zend_language_parser.h 
Zend/zend_ini_parser.c Zend/zend_ini_parser.h
+ ./genfiles   
Zend/zend_language_parser.y:50.1-5: invalid directive: `%code' 
Zend/zend_language_parser.y:50.7-14: syntax error, unexpected identifier   

I updated the patch to the following to get around this error:

$ cat SOURCES/php-5.4.18-bison.patch 
diff --git a/Zend/zend_language_parser.y b/Zend/zend_language_parser.y
index ccbc9b1..6a9a24a 100644
--- a/Zend/zend_language_parser.y
+++ b/Zend/zend_language_parser.y
@@ -41,17 +41,19 @@ static YYSIZE_T zend_yytnamerr(char*, const char*);
 
 #define YYERROR_VERBOSE
 #define YYSTYPE znode
-#ifdef ZTS
-# define YYPARSE_PARAM tsrm_ls
-# define YYLEX_PARAM tsrm_ls
-#endif
-
 
 %}
 
 %pure_parser
 %expect 3
 
+%{
+#ifdef ZTS
+# define YYPARSE_PARAM tsrm_ls
+# define YYLEX_PARAM tsrm_ls
+#endif
+%}
+
 %token END 0 "end of file"
 %left T_INCLUDE T_INCLUDE_ONCE T_EVAL T_REQUIRE T_REQUIRE_ONCE
 %token T_INCLUDE  "include (T_INCLUDE)"


Does this change seem sane?


Previous Comments:

[2013-08-19 17:46:04] s...@php.net

OK, looks like the patch for bug #64503 should be applied to 5.4 too for it to 
work with bison 2.7.


[2013-08-19 13:48:16] stu at coe dot uky dot edu

Applying the patch (at 
https://bugs.php.net/patch-display.php?bug_id=64503&patch=bison_build_2.patch&revision=latest)
 and doing the other steps:
rm Zend/zend_{language,ini}_parser.[ch]
./genfiles
fixed the problem.

FYI Slackware 14.0 ships with bison (GNU Bison) 2.5.1

Thanks to all!


[2013-08-19 12:05:32] r...@php.net

I think this is the same issue than #64503, caused by the switch from Bison 2.3 
to 2.7, used to generate the parser.

Notice : the fix for this issue have only been applied in 5.5 tree.


[2013-08-19 07:37:04] m...@php.net

Sorry for not being explicit enough!

I can reproduce with 

$ ./configure --enable-maintainer-zts --disable-all --prefix=$(pwd)/usr 

so, enabling ZTS should cause the issue.


[2013-08-19 07:10:26] s...@php.net

Mike, so which options should I use to reproduce it? Because I used with-apxs2 
and it worked fine. Should apache be built with some special options? IIRC, it 
usually does not build ZTS version, so what is the config for you that doesn't 
work?




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

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


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

Bug #65460 [Com]: PHP 5.4.18 fails to compile with Apache 2.4.6

[ben dot harper at rackspace dot com]

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

 ID: 65460
 Comment by:     ben dot harper at rackspace dot com
 Reported by:stu at coe dot uky dot edu
 Summary:PHP 5.4.18 fails to compile with Apache 2.4.6
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   Slackware64 14.0
 PHP Version:5.4.18
 Block user comment: N
 Private report: N

 New Comment:

I am running into this same error on RHEL 5 with Apache 2.2.3 and RHEL 6 with 
2.2.15.  Same config on both but slightly different error:

%configure \
--cache-file=../config.cache \
--with-libdir=%{_lib} \
--with-config-file-path=%{_sysconfdir} \
--with-config-file-scan-dir=%{_sysconfdir}/php.d \
--disable-debug \
--with-pic \
--disable-rpath \
--without-pear \
--with-bz2 \
--with-exec-dir=%{_bindir} \
--with-freetype-dir=%{_prefix} \
--with-png-dir=%{_prefix} \
--with-xpm-dir=%{_prefix} \
--enable-gd-native-ttf \
--with-t1lib=%{_prefix} \
--without-gdbm \
--with-gettext \
--with-gmp \
--with-iconv \
--with-jpeg-dir=%{_prefix} \
--with-openssl \
--with-pcre-regex \
--with-zlib \
--with-layout=GNU \
--enable-exif \
--enable-ftp \
--enable-magic-quotes \
--enable-sockets \
--with-kerberos \
--enable-ucd-snmp-hack \
--enable-shmop \
--enable-calendar \
--with-libxml-dir=%{_prefix} \
--enable-xml \
--with-system-tzdata \
--with-mhash \

Error in RHEL 5:

In file included from /builddir/build/BUILD/php-
5.4.18/ext/standard/basic_functions.c:48:
/builddir/build/BUILD/php-5.4.18/Zend/zend_language_parser.h:327: error: 
conflicting types for 'zendparse'
/builddir/build/BUILD/php-5.4.18/Zend/zend_globals_macros.h:35: error: previous 
declaration of 'zendparse' was here
/bin/sh /builddir/build/BUILD/php-5.4.18/build-ztscli/libtool --silent --
preserve-dup-deps --mode=compile /builddir/build/BUILD/php-5.4.18/build-
ztscli/meta_ccld  -Iext/standard/ -I/builddir/build/BUILD/php-
5.4.18/ext/standard/ -DPHP_ATOM_INC -I/builddir/build/BUILD/php-5.4.18/build-
ztscli/include -I/builddir/build/BUILD/php-5.4.18/build-ztscli/main -
I/builddir/build/BUILD/php-5.4.18 -I/builddir/build/BUILD/php-5.4.18/build-
ztscli/ext/date/lib -I/builddir/build/BUILD/php-5.4.18/ext/date/lib -
I/builddir/build/BUILD/php-5.4.18/ext/ereg/regex -I/usr/include/libxml2 -
I/usr/kerberos/include -I/usr/include/enchant -I/usr/include/freetype2 -
I/usr/include/imap -I/usr/lib/firebird/include -I/builddir/build/BUILD/php-
5.4.18/ext/mbstring/oniguruma -I/builddir/build/BUILD/php-5.4.18/build-
ztscli/ext/mbstring/oniguruma -I/builddir/build/BUILD/php-
5.4.18/ext/mbstring/libmbfl -I/builddir/build/BUILD/php-5.4.18/build-
ztscli/ext/mbstring/libmbfl -I/builddir/build/BUILD/php-
5.4.18/ext/mbstring/libmbfl/mbfl -I/builddir/build/BUILD/php-5.4.18/build-
ztscli/ext/mbstring/libmbfl/mbfl -I/usr/include/pspell -
I/builddir/build/BUILD/php-5.4.18/build-ztscli/TSRM -I/builddir/build/BUILD/php-
5.4.18/build-ztscli/Zend -I/builddir/build/BUILD/php-5.4.18/main -
I/builddir/build/BUILD/php-5.4.18/Zend -I/builddir/build/BUILD/php-5.4.18/TSRM -
I/builddir/build/BUILD/php-5.4.18/build-ztscli/  -D_REENTRANT  -I/usr/include -
O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --
param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-
tables -fno-strict-aliasing -Wno-pointer-sign -fvisibility=hidden -pthread 
-DZTS  
-c /builddir/build/BUILD/php-5.4.18/ext/standard/filestat.c -o 
ext/standard/filestat.lo 
make: *** [ext/standard/basic_functions.lo] Error 1
make: *** Waiting for unfinished jobs
/builddir/build/BUILD/php-5.4.18/ext/standard/array.c: In function 
'php_array_diff':
/builddir/build/BUILD/php-5.4.18/ext/standard/array.c:3418: warning: 
'fci_key_cache' may be used uninitialized in this function
/builddir/build/BUILD/php-5.4.18/ext/standard/array.c:3417: warning: 'fci_key' 
may be used uninitialized in this function
/builddir/build/BUILD/php-5.4.18/ext/standard/array.c: In function 
'php_array_intersect':
/builddir/build/BUILD/php-5.4.18/ext/standard/array.c:3000: warning: 
'fci_key_cache' may be used uninitialized in this function
/builddir/build/BUILD/php-5.4.18/ext/standard/array.c:2999: warning: 'fci_key' 
may be used uninitialized in this function
error: Bad exit status from /var/tmp/rpm-tmp.71866 (%build)
Bad exit status from /var/tmp/rpm-tmp.71866 (%build)
RPM build errors:
Child return code was: 1

Error in RHEL 6:

In file included from /builddir/build/BUILD/php-
5.4.18/ext/standard/basic_functions.c:49:
/builddir/build/BUILD/php-5.4.18/Zend/zend_language_parser.h:

Req #65386 [Com]: [summary] disable_functions / enable_functions / virtualhost...

[ben dot rubson at gmail dot com]

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

 ID: 65386
 Comment by:     ben dot rubson at gmail dot com
 Reported by:    ben dot rubson at gmail dot com
 Summary:[summary] disable_functions / enable_functions /
 virtualhost...
 Status: Open
 Type:   Feature/Change Request
 Package:PHP options/info functions
 PHP Version:5.4.17
 Block user comment: N
 Private report: N

 New Comment:

Another interesting feature would be the support of wildcards
in disable_functions directive.

To disable the 21 PCNTL functions, instead of having to write :
"disable_functions = pcntl_alarm,pcntl_fork,pcntl_waitpid,..."

We would be able to write :
"disable_functions = pcntl_*"

Thanks !


Previous Comments:
----
[2013-08-03 15:56:12] ben dot rubson at gmail dot com

Related To: Bug #65351

----
[2013-08-03 15:55:54] ben dot rubson at gmail dot com

Related To: Bug #54239

----
[2013-08-03 15:55:43] ben dot rubson at gmail dot com

Related To: Bug #52325

----
[2013-08-03 15:55:31] ben dot rubson at gmail dot com

Related To: Bug #13833

----
[2013-08-03 15:55:09] ben dot rubson at gmail dot com

Related To: Bug #65289




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

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


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

Req #52325 [Com]: multiple php.ini with mod_php5 allusive or impossible

[ben dot rubson at gmail dot com]

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

 ID: 52325
 Comment by:     ben dot rubson at gmail dot com
 Reported by:admin at digibase dot ca
 Summary:multiple php.ini with mod_php5 allusive or
 impossible
 Status: Open
 Type:   Feature/Change Request
 Package:PHP options/info functions
 Operating System:   Linux
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

See summary bug #65386


Previous Comments:

[2010-07-13 10:31:42] admin at digibase dot ca

Just as clarification:

in my test cases,
On one "restricted" vhost with options set via php.ini:
On a "less restricted" vhost with options set via php.ini:

these lines should be regarded as:

On one "restricted" vhost with options set via 
/etc/php/profiles/default/php.ini:
On a "less restricted" vhost with options set via 
/etc/php/profiles/approved/php.ini:


[2010-07-13 10:22:46] admin at digibase dot ca

Description:

Greetings,

I have noticed that under apache, setting php.ini-only directives (such as 
disable_functions - which is not accepted in httpd.conf) per virtual host can 
only be done by installing php with something like suPHP. This is not a 
desirable configuration in most cases when php is already installed as mod_php4 
or mod_php5.

Furthermore, for loading php.ini files, PHPRC environment variable seems to be 
ignored, as well, PHPINIDir only is accepted once per apache configuration, 
even in completely different vhost blocks.

I run a shared hosting infastructure for special project sites, Now, I would 
like to have a default, restricted PHP configuration, then under certain 
virtual host blocks (for example, for users I approve) set up "less restricted" 
php.ini files for those accounts.

Also, there are several internally run sites that need a very loose setup but I 
would not want regular users having that setup for themselves.

The issue at the moment is for many options, PHP does not accept more than one 
setup per server (oncemore, in the case of disable_functions).

Test script:
---


Expected result:

On one "restricted" vhost with options set via php.ini:
The script should return that the system() function is disabled.

On a "less restricted" vhost with options set via php.ini:
The script should execute the system() call. 

Actual result:
--
Either:

On one "restricted" vhost with options set via php.ini:
The script returns that the system() function is disabled.

On a "less restricted" vhost with options set via php.ini:
The script returns that the system() function is disabled.

Or:

On one "restricted" vhost with options set via php.ini:
The script executes the system() call. 

On a "less restricted" vhost with options set via php.ini:
The script executes the system() call. 







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

Req #65351 [Com]: enable_functions directive

[ben dot rubson at gmail dot com]

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

 ID: 65351
 Comment by:     ben dot rubson at gmail dot com
 Reported by:az9901 at gmail dot com
 Summary:enable_functions directive
 Status: Open
 Type:   Feature/Change Request
 Package:PHP options/info functions
 PHP Version:5.4.17
 Block user comment: N
 Private report: N

 New Comment:

See summary bug #65386


Previous Comments:

[2013-07-29 09:57:55] az9901 at gmail dot com

In addition to the fact that "disable_functions" in a virtualhost
context does not semm to overwrite global setting but to complete it,
functions which have been disabled in a virtualhost context still work.

For example, phpinfo() shows that syslog function is disabled
(according to specific virtualhost setting
"php_admin_value disable_functions syslog"),
but syslog can still be used in PHP code.


[2013-07-29 06:14:44] az9901 at gmail dot com

According to the tests I did, "php_admin_value disable_functions"
does not overwrite / redefine the global list, but complete it.

I think that having the ability to declare white lists
would make functions management easier.

For example, let's assume we have excluded 40 functions globally !
We need the exec function in one of our virtualhosts.
Instead of having to re-declare 39 functions in the virtualhost
(which does not seem to work), we would simply have to make declare :
"php_admin_value enable_functions exec"

Easier to manage, especially for envs with several / many virualhosts.
And so it would make the functions' management more secure.

Thank you very much !


[2013-07-28 23:39:46] yohg...@php.net

Rather than mixing white and black list, redefine black list for certain 
virtual 
hosts.

Users may use multiple php_admin_flag/value for the same setting to override 
previous definitions in server contexts.


[2013-07-28 19:31:19] az9901 at gmail dot com

What I tried to do :

Keep a global (CG) array of pointers to the original functions
for the ones which have been disabled
(in the zend_API.c file, zend_disable_function function) ;

Move functions' pointer to their original version for re-enabled ones
(in the mod_php5.c file, send_php function).

But I did not manage to get it working.
And I don't know if it's the right way to implement it.

Thank you !


[2013-07-28 19:18:34] az9901 at gmail dot com

Description:


Hello,

I tried all the WE to implement enable_functions directive, but without 
success...

Goal is to re-enable some functions in a specific Apache virtualhost which 
would 
have been disabled globally.
We would then be able to be very restrictive in the global php.ini 
configuration 
file and allow some specific functions in some of the virtualhosts using 
"php_admin_value enable_functions ...".

Could you please implement it ?

Thank you very much !

Best regards,

Ben








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

Req #54239 [Com]: disable_functions tightening like open_basedir

[ben dot rubson at gmail dot com]

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

 ID: 54239
 Comment by:     ben dot rubson at gmail dot com
 Reported by:naox at o2 dot pl
 Summary:disable_functions tightening like open_basedir
 Status: Open
 Type:   Feature/Change Request
 Package:PHP options/info functions
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

See summary bug #65386


Previous Comments:

[2011-04-26 05:38:47] fg345twrg at gmail dot com

Making disable_functions INI_ALL and allowing it to set only if previously 
empty 
would be good start. Tightening would be perfect.


[2011-04-26 00:30:54] naox at o2 dot pl

allow disable_functions tightening like open_basedir :(


[2011-03-13 05:33:28] naox at o2 dot pl

Description:

http://php.net/manual/en/ini.core.php

disable_functions is php.ini only

open_basedir is PHP_INI_ALL - because next change can only append to 
open_basedir 
path, never take something back. Disable_functions should work the same way! It 
should be PHP_INI_ALL and allowing adding functions, but never taking those 
back. 
This allong open_basedir and prepend could make handy to make privledge 
separation 
for multiple sites but wihtout multiple php.ini








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

Req #13833 [Com]: Allow tightening disable_functions (like open_basedir)

[ben dot rubson at gmail dot com]

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

 ID: 13833
 Comment by:     ben dot rubson at gmail dot com
 Reported by:joseph dot blythe at binarylogic dot com dot au
 Summary:Allow tightening disable_functions (like
 open_basedir)
 Status: Open
 Type:   Feature/Change Request
 Package:PHP options/info functions
 Operating System:   *
 PHP Version:*
 Block user comment: N
 Private report: N

 New Comment:

See summary bug #65386


Previous Comments:

[2010-12-17 14:14:19] j...@php.net

See also bug #32805


[2001-10-26 03:24:20] der...@php.net

This is not a bug, but it is supposed to work like that.
Making it a feature request, as there was some talk about this on the php 
developers mailinglist.

Derick


[2001-10-25 22:23:53] joseph dot blythe at binarylogic dot com dot au

btw: Apache/1.3.22


[2001-10-25 22:21:11] joseph dot blythe at binarylogic dot com dot au

When set from inside httpd.conf I had it between a  directive inside 
a virtual host.

 php_admin_value disable_functions phpinfo
 
Doesn't actually disable the function for that host even though calling up 
phpinfo (which should be disabled) shows that phpinfo is disabled. Setting it 
in the php.ini works fine.





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

Req #24702 [Com]: disable_functions + httpd.conf should not set value

[ben dot rubson at gmail dot com]

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

 ID: 24702
 Comment by:     ben dot rubson at gmail dot com
 Reported by:philip at cornado dot com
 Summary:disable_functions + httpd.conf should not set value
 Status: Open
 Type:   Feature/Change Request
 Package:Feature/Change Request
 Operating System:   linux
 PHP Version:4.3.3RC1
 Block user comment: N
 Private report: N

 New Comment:

See summary bug #65386


Previous Comments:

[2004-02-03 07:27:55] anonymous at internet dot com

same problem in version 4.3.4 (final).


[2003-07-18 03:24:13] philip at cornado dot com

Description:

As we all know, setting disable_functions and disable_classes is not possible 
in httpd.conf as they are special case PHP_INI_SYSTEM directives, but doing so 
still emits a local value even knowing it has no meaning.  In otherwords, 
setting disable_* in httpd.conf should not affect the local ini value as it 
does currently.

Note: As expected, setting via ini_set() or .htaccess does not affect the value.

Reproduce code:
---
In httpd.conf:
php_admin_value disable_functions "mail"

PHP:
echo ini_get('disable_functions');


Expected result:

no value

Actual result:
--
mail






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

[PHP-BUG] Req #65386 [NEW]: [summary] disable_functions / enable_functions / virtualhost...

[ben dot rubson at gmail dot com]

From: ben dot rubson at gmail dot com
Operating system: 
PHP version:  5.4.17
Package:  PHP options/info functions
Bug Type: Feature/Change Request
Bug description:[summary] disable_functions / enable_functions / virtualhost...

Description:

Hello,

I open this bug to summarize findings / requests
around disable_functions directive.

1 - Bug
"php_admin_value disable_functions" should not
affect the local ini value.
bug #24702
bug #65289

2 - Request
"php_admin_value disable_functions" should
be able to disable functions.
bug #13833
bug #52325
bug #54239

3 - Request
"php_admin_value enable_functions" should
re-enable disabled functions.
bug #65351

To sum up, could you make disable_functions
a PHP_INI_SYSTEM directive ?
Could you also implement enable_functions
as a PHP_INI_SYSTEM directive ?

We would then be able to fine tune each
Apache virtualhost independently, securely.

Thank you very much !


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

Req #51595 [Com]: passing ini settings via FASTCGI parameters

[ben at indietorrent dot org]

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

 ID: 51595
 Comment by:     ben at indietorrent dot org
 Reported by:f...@php.net
 Summary:passing ini settings via FASTCGI parameters
 Status: Closed
 Type:   Feature/Change Request
 Package:FPM related
 Operating System:   any
 PHP Version:trunk
 Assigned To:fat
 Block user comment: N
 Private report: N

 New Comment:

I, too, have noticed that PHP configuration directives that are defined like 
this, within an nginx "location{}" block

fastcgi_param PHP_VALUE "
error_reporting=6143
log_errors=On
";

are not effective. The values are propagated to the effective environment 
variables, though, as evidenced by the fact that the values appear in the 
$_SERVER["PHP_VALUE"] superglobal.

Will this ever work? Or is it simply not possible to achieve this with PHP's 
CGI 
executable (instead of, for example, php-fpm)?


Previous Comments:

[2011-10-24 14:06:56] info at breakdev dot com

it doesn't work with nginx anf php5-cgi spawn:

nginx version: nginx/0.7.67
PHP 5.3.8-1~dotdeb.1 with Suhosin-Patch (cli) (built: Aug 26 2011 12:46:54) 

I used this line in the nginx.conf:
fastcgi_param PHP_ADMIN_VALUE open_basedir=/home/www/docs

so there was set
$_SERVER['PHP_ADMIN_VALUE']="open_basedir=/home/www/docs"


[2011-08-21 18:06:17] f...@php.net

Yes it's been integrated into FPM since 5.3.3 I think. In all the cases, it 
works 
with php 5.3.7


[2011-08-21 17:40:43] ywarnier at beeznest dot org

Hi guys, has this been sent to any stable release of PHP? I can't find it in 
any part of http://www.php.net/ChangeLog-5.php#5.3.7


[2010-04-23 19:15:58] f...@php.net

This bug has been fixed in SVN.

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

It's been commited in revision 298383

In fastcgi headers, only unique values can be passed. So you have to 
concatenate 
differentes value in one and 
separate them with a new line character (\n).

For exemple in nginx, it could be done this way:

  set $php_value "pcre.backtrack_limit=424242";
  set $php_value "$php_value \n pcre.recursion_limit=9";
  fastcgi_param  PHP_VALUE $php_value;

  fastcgi_param  PHP_ADMIN_VALUE "open_basedir=/var/www/htdocs";


In lighttpd, it seems there is no options to pass custom headers :/


[2010-04-23 18:06:04] f...@php.net

Automatic comment from SVN on behalf of fat
Revision: http://svn.php.net/viewvc/?view=revision&revision=298383
Log: Add PHP_VALUE and PHP_ADMIN_VALUE interpretation from fastcgi headers.
It works as php_value and php_admin_value from the main conf file or apache 
sapi.

See bug (request) #51595




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

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


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

Bug #48528 [Com]: mysqlnd causes PDO/MySQLi to leak memory

[ben at ajmadison dot com]

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

 ID: 48528
 Comment by:     ben at ajmadison dot com
 Reported by:bugs dot php dot net at moesen dot nu
 Summary:mysqlnd causes PDO/MySQLi to leak memory
 Status: Closed
 Type:   Bug
 Package:MySQL related
 Operating System:   Linux 2.6
 PHP Version:5.3CVS-2009-06-11 (snap)
 Block user comment: N
 Private report: N

 New Comment:

The answer is not 100% correct.

It is true that libmysqlclient hides the amount of allocted memory, while 
mysqlnd shows up in PHP.

Here are the results I obtained using the latest PHP 5.5.1 build.

When measured by "ps aux|grep php|grep mysql" though, mysqlnd memory usage 
keeps climbing during loop iteration, getting to over 5 times the amount of 
memory allocated during mysql_query. libmysqlclient memory usage only goes up 
while  mysql_query is running, and stays constant during iteration.

Why does mysqlnd use so much more memory than lilbmysqlclient, as reported by: 
"ps aux|grep php|grep mysql"? Why does iterating throught he loop use 5 times+ 
the memory of mysql_query?


Previous Comments:

[2009-11-03 09:45:19] u...@php.net

Duplicate of http://bugs.php.net/bug.php?id=48343 - there is no leak, mysqlnd 
and libmysql work differently. 


[2009-10-30 12:32:15] guenter at grodotzki dot ph

same problem here, though with the normal mysql_query + mysql_fetch* functions


[2009-06-20 01:00:00] php-bugs at lists dot php dot net

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


[2009-06-16 08:31:16] bugs dot php dot net at moesen dot nu

> libmysql's allocations are hidden.
OK, that explains the numbers. Thanks.

> Do you really get OOM with mysqlnd?
Yes, for the same dataset.

> as you can see the memory usage with USE_RESULT doesn't jump
Thanks for that pointer. I completely missed it in the documentation, and since 
we never had any problems before switching over to 5.3, I never needed it. The 
human equivalent of lazy evaluation, I guess.

So if I understand it correctly, libmysql is not subject to PHP's memory limit, 
whereas mysqlnd is?


[2009-06-12 07:36:09] and...@php.net

Do you really get OOM with mysqlnd? memory_get_usage() is constant with 
libmysql because libmysql allocates its memory with malloc while Zend and all 
PHP functions mostly use emalloc. emalloc counts the allocated memory. 
libmysql's allocations are hidden.
I tried your script, created a simple table with the same name and 
- int
- double
- varchar
- decimal
columns.
I have 33 rows. Here is the output when the data is fetched with 
MYSQLI_STORE_RESULT, which is the default:
361756 <- before $result = $db->query
366384
366656
366928
367200
367472
367744
368016
368288
368560
368832
369104
369376
369648
369920
370192
370464
370736
371008
371280
371552
371824
372096
372368
372640
372912
373184
373456
373728
374000
374272
374544
374816
375088
362840 <- this is the result after I do $result->free_result(), which means 
that the memory doesn't leak. Most of it is reclaimed. It can be that Zend also 
cache some zvals in its zval cache, which means that memory has not leaked and 
is there for further usage. 

Here is with MYSQLI_USE_RESULT:
361756  <- before $result = $db->query
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
365764
362840 <- After $result->free_result()

So, as you can see the memory usage with USE_RESULT doesn't jump, for a reaon. 
Because data is not stored on the client side. With libmysql you cannot see it, 
but the usage is there.






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

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


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

Bug #61266 [Com]: pg_affected_rows inconsistent behavior (depends on PostgreSQL server version)

[ben dot pineau at gmail dot com]

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

 ID: 61266
 Comment by:     ben dot pineau at gmail dot com
 Reported by:    ben dot pineau at gmail dot com
 Summary:pg_affected_rows inconsistent behavior (depends on
 PostgreSQL server version)
 Status: Re-Opened
 Type:   Bug
 Package:PostgreSQL related
 Operating System:   all
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

We had code using pg_affected_rows() to detect if the previous query was a 
simple SELECT or a DML.
Yes, that's dumb and our code was fixed since then ;) I understand there may 
not be that many other persons affected.

Right, I also think the documentation deserves an update (including the case 
reported by b...@php.net).


Previous Comments:

[2013-06-26 22:06:48] yohg...@php.net

I guess no one was used pg_affected_rows() for SELECT query before PostgreSQL 
9.0.

Thank you for the patch, but I think it's nice to keep new behavior and 
document 
it.

Any comments?


[2013-03-26 17:17:46] b...@php.net

It's actually possible that a writing command produces a result set (which can 
differ in the number of affected / returned rows):
Simple example would be:
INSERT INTO foo (bar, baz)
VALUES (DEFAULT, 'bang')
RETURNING (bar);

Therefore i don't see this has having only a low impact.


[2012-03-08 08:31:22] cataphr...@php.net

I don't think PHP should apply compatibility shims on top of libpq, especially 
when the new functionality has low impact and actually adds functionality. The 
case for your PDO bug report, however, is much more compelling.

----
[2012-03-03 13:42:36] ben dot pineau at gmail dot com

Description:

According to the manual, pg_affected_rows should returns "the number of tuples 
(instances/records/rows) affected by INSERT, UPDATE, and DELETE queries.". The 
manual details : "The number of rows affected by the query. If no tuple is 
affected, it will return 0.".

PHP pg_affected_rows uses libpq's PQcmdTuples() to implement this:

  PHP_FUNCTION(pg_affected_rows)
  {
 
php_pgsql_get_result_info(INTERNAL_FUNCTION_PARAM_PASSTHRU,PHP_PG_CMD_TUPLES);
  }

  static void php_pgsql_get_result_info(INTERNAL_FUNCTION_PARAMETERS, int 
entry_type)
  {
  [...]
case PHP_PG_CMD_TUPLES:
Z_LVAL_P(return_value) = atoi(PQcmdTuples(pgsql_result));

But server's answers to PQcmdTuples() commands changed since PostgreSQL 9.0. 
When executed after a SELECT, PostgreSQL < 9.0 returned 0 (as in "0 rows were 
affected"); starting with PostgreSQL 9.0, the server returns the number of 
SELECTed rows.

See how the PQcmdTuples documentation was updated after pg 9:
http://www.postgresql.org/docs/8.4/interactive/libpq-exec.html#LIBPQ-EXEC-
SELECT-INFO
http://www.postgresql.org/docs/9.1/interactive/libpq-exec.html#LIBPQ-EXEC-
SELECT-INFO

PostgreSQL C API doesn't actually offers a "tell me how many rows were 
written/modified" function.  But we can restore the previous pg_affected_rows 
behavior, and enjoy consistent results no matter which server version we run 
against, by unconditionally returning 0 after a SELECT.

This is what the attached patch does, identifying the SELECT with 
PQresultStatus() value (which returns PGRES_COMMAND_OK after a successful DML, 
as opposed to PGRES_TUPLES_OK after a SELECT, etc).

If you ask so, I can also provide an alternative patch (which tests the string 
returned by PQcmdStatus(), a bit ugly imo) and/or an unit test script for PHP's 
test framework.


Test script:
---
// Bug on a PostgreSQL >= 9.0 server, ok on older versions.
$dbh = pg_pconnect("dbname=postgres host=localhost user=postgres port=5432");
$q = pg_query($dbh, "SELECT * from generate_series(1, 42);");
var_dump(pg_affected_rows($q));

Expected result:

int(0)

Actual result:
--
int(42)






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

Bug #53140 [Com]: PHP-CGI (FastCGI IIS) crashes when creating DOTNET instance every second time

[ben at imperialwebdesigns dot com]

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

 ID: 53140
 Comment by:     ben at imperialwebdesigns dot com
 Reported by:jeyb88 at gmail dot com
 Summary:PHP-CGI (FastCGI IIS) crashes when creating DOTNET
 instance every second time
 Status: Open
 Type:   Bug
 Package:COM related
 Operating System:   XP, Vista, Win 7,Win Server 2008
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

Any update on getting this resolved?


Previous Comments:

[2013-01-08 15:08:16] johnphayes at gmail dot com

You may be able to fix this issue by recompiling PHP with the 

void php_com_dotnet_mshutdown()

defined in /ext/com_dotnet/com_dotnet.c. IIRC the problem was that that 
function 
was removed in this revision: 

http://svn.php.net/viewvc/php/php-src/trunk/ext/com_dotnet/com_dotnet.c?
r1=137794&r2=146718. 

So if you can download the latest source, put that function back into 
com_dotnet.c, and recompile you should be good to go.


[2013-01-08 09:35:22] xandra_18ro at yahoo dot com

Is there a hotfix for this problem? Or a workaround perhaps.
thanks!


[2012-03-26 16:18:30] andrew dot king at simail dot co dot uk

I can confirm that this problem also exists on PHP 5.3.2 on Windows Server 2003 
32-bit with IIS running FastCGI. Problem also occurs on WAMP server, Windows 7 
64-bit running PHP 5.3.8, Apache 2.2.21 with PHP loaded as a module, not CGI.


[2011-08-24 17:02:08] johnphayes at gmail dot com

Here is the Application Event log entry in Windows Server 2003 when this crash 
occurs in my test case above:

Source: .NET Runtime 2.0 Error

Description:
Faulting application httpd.exe, version 2.2.19.0, stamp 4dd6eda8, faulting 
module 
php5ts.dll, version 5.2.17.17, stamp 4d25fb49, debug? 0, fault address 
0x000ea66d.

This source is a little odd, because I have .NET 4.0 Runtime installed. Note 
that although I have PHP 5.2.17 installed at the moment, I have experienced 
this 
with 5.3 as well.


[2011-08-24 16:23:21] johnphayes at gmail dot com

Can this bug's summary be edited to remove "(FastCGI IIS)?" My comment above 
shows 
that it can be reproduced under Apache as an Apache handler as well.




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

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


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

Bug #63413 [Com]: Intermittent warning and fatal error on require() statement

[ben at indietorrent dot org]

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

 ID: 63413
 Comment by:     ben at indietorrent dot org
 Reported by:    ben at indietorrent dot org
 Summary:Intermittent warning and fatal error on require()
 statement
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows 7 x64
 PHP Version:5.4.8
 Block user comment: N
 Private report: N

 New Comment:

@giunta dot gaetano at gmail dot com:

I can't thank you enough; your insightful comments reveal the "missing link": 
NTFS junction points. I didn't think they were relevant until reading your 
comments.

In my comment dated [2012-11-16 16:29 UTC], I stated that I setup a virtual 
machine with the same WAMP stack components that are installed on the "problem" 
machines, but that I was unable to reproduce the problem. Well, I forgot to 
configure the site-root as an NTFS junction point in those tests.

As soon as I changed the site-root from a regular directory to an NTFS function 
point, I was able to reproduce the problem almost immediately.

As stated in my previous comments, concurrency seems to be a factor in how 
likely the failures are to occur. Unfortunately, this fact may point to a 
race-condition.

It seems safe to say that include() and require() do not perform reliably 
across NTFS junction points.

Whether or not the same root cause is behind the NFS problems on Linux remains 
to be seen.


Previous Comments:

[2013-02-14 10:11:41] giunta dot gaetano at gmail dot com

Btw, did some testing on my rig: win7 64bit, apache 2.4.3/vc10 from Apache 
Lounge, php 5.3.20/vc9.

Using the test scripts provided above, and "ab" hitting them 100 times in a row 
with concurrency ranging from 1 to 64.

When no NTFS junctions in use => no sign of errors whatsoever

When an NTFS junction in use => one or two php errors do happen, across the 
whole test (127k requests).

NB: just accessing the main file over the junction is ok. The problems happen 
then the "require" call is for a file over in the junction-ed directory


[2013-02-13 17:34:19] giunta dot gaetano at gmail dot com

A behaviour which has been puzzling me and that might (or not) be related: we 
also have some failing code which assumes that filemtime should not be zero 
(for an existing file). This is generally happening on Linux servers at 
customers (php in mode_prefork), at times of high load, for nfs-mounted files

--------
[2012-11-16 16:29:11] ben at indietorrent dot org

Additional testing indicates that this problem is likely related to a specific 
piece of software that has been installed on the affected machines, and not PHP 
or the manner in which it is integrated with Apache.

I tested the steps-to-reproduce with the exact same project/code-base on a LAMP 
stack (Ubuntu 12.04 + Apache 2.2.22 + MySQL 5.5.24 + PHP 5.3.10) and cannot 
reproduce the issue, no matter how hard I hammer the server with requests.

As mentioned previously, I am unable to reproduce this issue with a comparable 
stack on Mac OS 10.8, either.

These facts pointed to a Windows-specific cause, perhaps related to Apache's 
"winnt" MPM, so I setup a VM with a pristine Windows 7 x86 installation. I 
installed the same stack components as are installed on the computers on which 
this issue occurs. Yet, after several hours of hammering the server with 
constant page-requests, not a single error has been registered in PHP's error 
log.

If at any point I'm able to determine which software causes this issue, I will 
post my findings here.

--------
[2012-11-05 15:45:02] ben at indietorrent dot org

Another update.

I began to suspect that this is a thread-safety issue, so I downloaded the 
latest non-thread-safe version of PHP and configured Apache to serve PHP files 
via Fast-CGI (mod_fcgid).

To my surprise, this problem still occurs, and it seems to be worse with 
Fast-CGI than with Mod-PHP.

Also, I tried to reproduce the problem on a Mac with Mac OS 10.8 and a fairly 
modern MAMP installation that runs PHP via Mod-PHP. No matter how hard I 
hammered on Apache, these spurious require() failures did not occur.

--------
[2012-11-01 21:07:42] ben at indietorrent dot org

It occurred to me to examine Apache's internal error log for entries that 
correspond to those in PHP's error log when this occurs. I noticed what may be 
an important clue.

Sample entries in PHP's error log:

---
[01-Nov-2012 13:29:41 America/New_York] PHP W

Bug #41078 [Com]: Its not possible to call Static dotNet Classes with dotnet

[ben at nullcreations dot net]

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

 ID: 41078
 Comment by:     ben at nullcreations dot net
 Reported by:mail at brutos dot org
 Summary:Its not possible to call Static dotNet Classes with
 dotnet
 Status: Assigned
 Type:   Bug
 Package:COM related
 Operating System:   Windows Vista Ultimate x86
 PHP Version:5CVS-2007-04-13 (snap)
 Assigned To:wez
 Block user comment: N
 Private report: N

 New Comment:

Reproduced in Windows 7 using php 5.4.9


Previous Comments:

[2007-04-13 17:45:35] mail at brutos dot org

Description:

You can call non static classes like
System.Collections.Stack
or
System.Text.StringBuilder

But no static classes like System.Console.

Reproduce code:
---
WriteLine("Hello World!");
?>

Expected result:

Hello World!

Actual result:
--
Fatal error: Uncaught exception 'com_exception' with message 'Failed to instanti
ate .Net object [CreateInstance] [0x80131513] ' in 
C:\Users\Brutos\Desktop\test.php:2
Stack trace:
#0 C:\Users\Brutos\Desktop\test.php(2): dotnet->dotnet('mscorlib', 
'System.Console')
#1 {main}
  thrown in C:\Users\Brutos\Desktop\test.php on line 2






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

Bug #50473 [Com]: static dotnet classes can't be called

[ben at nullcreations dot net]

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

 ID: 50473
 Comment by:     ben at nullcreations dot net
 Reported by:zelnaga at gmail dot com
 Summary:static dotnet classes can't be called
 Status: Open
 Type:   Bug
 Package:COM related
 Operating System:   Windows XP
 PHP Version:5.3.1
 Block user comment: N
 Private report: N

 New Comment:

Reproduced in php 5.4.9 on Windows 7.


Previous Comments:

[2010-04-14 11:06:01] pawel at atisoft dot poznan dot pl

Reproduced in PHP 5.3.2
Same error while trying to instantiate other classes from mscorlib


[2009-12-14 23:20:47] zelnaga at gmail dot com

Description:

$test = new DOTNET('mscorlib', 'System.IO.File');

That yields a "Fatal error: Uncaught exception 'com_exception' with message 
'Failed to instantiate .Net object [CreateInstance] [0x80131513] '" error.  Per 
the comments on php.net/class.dotnet, I thought this might work, instead, but 
it doesn't:

$test = new DOTNET('mscorlib, Version=2.0.0.0, Culture=neutral, 
PublicKeyToken=b77a5c561934e089, processorArchitecture=x86', 'System.IO.File');

The example on php.net, however, does work:

$test = new DOTNET('mscorlib', 'System.Collections.Stack');

I think what the problem really is is this: System.IO.File is a static class.  
It's not intended to be instantiated whereas System.Collections.Stack is.  In 
light of this, I think either the ability to call methods within static dotnet 
classes ought to be added or, failing that, a note should be added to the 
documentation stating that only instantiatable classes can be used with the 
DOTNET object.

Reproduce code:
---
$test = new DOTNET('mscorlib', 'System.IO.File');

Expected result:

(nothing)

Actual result:
--
Fatal error: Uncaught exception 'com_exception' with message 'Failed to 
instantiate .Net object [CreateInstance] [0x80131513] ' in C:\path\to\test.php:3
Stack trace:
#0 C:\path\to\test.php(3): dotnet->dotnet('mscorlib, Versi...
', 'System.IO.File')
#1 {main}
  thrown in C:\path\to\test.php on line 3






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

Bug #63413 [Com]: Intermittent warning and fatal error on require() statement

[ben at indietorrent dot org]

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

 ID: 63413
 Comment by:     ben at indietorrent dot org
 Reported by:    ben at indietorrent dot org
 Summary:Intermittent warning and fatal error on require()
 statement
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows 7 x64
 PHP Version:5.4.8
 Block user comment: N
 Private report: N

 New Comment:

Additional testing indicates that this problem is likely related to a specific 
piece of software that has been installed on the affected machines, and not PHP 
or the manner in which it is integrated with Apache.

I tested the steps-to-reproduce with the exact same project/code-base on a LAMP 
stack (Ubuntu 12.04 + Apache 2.2.22 + MySQL 5.5.24 + PHP 5.3.10) and cannot 
reproduce the issue, no matter how hard I hammer the server with requests.

As mentioned previously, I am unable to reproduce this issue with a comparable 
stack on Mac OS 10.8, either.

These facts pointed to a Windows-specific cause, perhaps related to Apache's 
"winnt" MPM, so I setup a VM with a pristine Windows 7 x86 installation. I 
installed the same stack components as are installed on the computers on which 
this issue occurs. Yet, after several hours of hammering the server with 
constant page-requests, not a single error has been registered in PHP's error 
log.

If at any point I'm able to determine which software causes this issue, I will 
post my findings here.


Previous Comments:
--------
[2012-11-05 15:45:02] ben at indietorrent dot org

Another update.

I began to suspect that this is a thread-safety issue, so I downloaded the 
latest non-thread-safe version of PHP and configured Apache to serve PHP files 
via Fast-CGI (mod_fcgid).

To my surprise, this problem still occurs, and it seems to be worse with 
Fast-CGI than with Mod-PHP.

Also, I tried to reproduce the problem on a Mac with Mac OS 10.8 and a fairly 
modern MAMP installation that runs PHP via Mod-PHP. No matter how hard I 
hammered on Apache, these spurious require() failures did not occur.

--------
[2012-11-01 21:07:42] ben at indietorrent dot org

It occurred to me to examine Apache's internal error log for entries that 
correspond to those in PHP's error log when this occurs. I noticed what may be 
an important clue.

Sample entries in PHP's error log:

---
[01-Nov-2012 13:29:41 America/New_York] PHP Warning:  
require(../include/global.inc.php): failed to open stream: No such file or 
directory in C:\Users\Ben\Documents\Projects\project 
Testing\project-svn\trunk\public\auxiliary\css.php on line 5

[01-Nov-2012 13:29:41 America/New_York] PHP Fatal error:  require(): Failed 
opening required '../include/global.inc.php' (include_path='.;C:\Program 
Files\php\includes;C:\Program Files\php\PEAR\pear') in 
C:\Users\Ben\Documents\Projects\project 
Testing\project-svn\trunk\public\auxiliary\css.php on line 5

[01-Nov-2012 13:29:43 America/New_York] PHP Warning:  
require(C:/Users/Ben/Documents/Apache/project/protected/constants.inc.php): 
failed to open stream: No such file or directory in 
C:\Users\Ben\Documents\Projects\project 
Testing\project-svn\trunk\public\include\global.inc.php on line 18

[01-Nov-2012 13:29:43 America/New_York] PHP Fatal error:  require(): Failed 
opening required 
'C:/Users/Ben/Documents/Apache/project/protected/constants.inc.php' 
(include_path='.;C:\Program Files\php\includes;C:\Program Files\php\PEAR\pear') 
in C:\Users\Ben\Documents\Projects\project 
Testing\project-svn\trunk\public\include\global.inc.php on line 18
---

Roughly-corresponding entries in Apache's error log:

---
[Thu Nov 01 13:29:21.235844 2012] [core:error] [pid 6780:tid 1136] (OS 32)The 
process cannot access the file because it is being used by another process.  : 
[client 10.0.1.57:65162] AH00127: Cannot map GET 
/project/public/js/jquery.accordion.js HTTP/1.1 to file, referer: 
https://ben-pc/project/public/company/history/
[Thu Nov 01 13:29:41.141441 2012] [core:error] [pid 6780:tid 1128] (OS 32)The 
process cannot access the file because it is being used by another process.  : 
[client 10.0.1.57:65204] AH00127: Cannot map GET 
/project/public/common/js/libs/modernizr-2.5.3.min.js HTTP/1.1 to file, 
referer: https://ben-pc/project/public/contact/service-inquiry/
---

While I don't see any direct correlation between the files cited in PHP's error 
log and those cited in Apache's error log, the message "(OS 32)The process 
cannot access the file because it is being used by another process" seems very 
relevant to the observed behavior in PHP.

T

Bug #63413 [Com]: Intermittent warning and fatal error on require() statement

[ben at indietorrent dot org]

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

 ID: 63413
 Comment by:     ben at indietorrent dot org
 Reported by:    ben at indietorrent dot org
 Summary:Intermittent warning and fatal error on require()
 statement
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows 7 x64
 PHP Version:5.4.8
 Block user comment: N
 Private report: N

 New Comment:

Another update.

I began to suspect that this is a thread-safety issue, so I downloaded the 
latest non-thread-safe version of PHP and configured Apache to serve PHP files 
via Fast-CGI (mod_fcgid).

To my surprise, this problem still occurs, and it seems to be worse with 
Fast-CGI than with Mod-PHP.

Also, I tried to reproduce the problem on a Mac with Mac OS 10.8 and a fairly 
modern MAMP installation that runs PHP via Mod-PHP. No matter how hard I 
hammered on Apache, these spurious require() failures did not occur.


Previous Comments:

[2012-11-01 21:07:42] ben at indietorrent dot org

It occurred to me to examine Apache's internal error log for entries that 
correspond to those in PHP's error log when this occurs. I noticed what may be 
an important clue.

Sample entries in PHP's error log:

---
[01-Nov-2012 13:29:41 America/New_York] PHP Warning:  
require(../include/global.inc.php): failed to open stream: No such file or 
directory in C:\Users\Ben\Documents\Projects\project 
Testing\project-svn\trunk\public\auxiliary\css.php on line 5

[01-Nov-2012 13:29:41 America/New_York] PHP Fatal error:  require(): Failed 
opening required '../include/global.inc.php' (include_path='.;C:\Program 
Files\php\includes;C:\Program Files\php\PEAR\pear') in 
C:\Users\Ben\Documents\Projects\project 
Testing\project-svn\trunk\public\auxiliary\css.php on line 5

[01-Nov-2012 13:29:43 America/New_York] PHP Warning:  
require(C:/Users/Ben/Documents/Apache/project/protected/constants.inc.php): 
failed to open stream: No such file or directory in 
C:\Users\Ben\Documents\Projects\project 
Testing\project-svn\trunk\public\include\global.inc.php on line 18

[01-Nov-2012 13:29:43 America/New_York] PHP Fatal error:  require(): Failed 
opening required 
'C:/Users/Ben/Documents/Apache/project/protected/constants.inc.php' 
(include_path='.;C:\Program Files\php\includes;C:\Program Files\php\PEAR\pear') 
in C:\Users\Ben\Documents\Projects\project 
Testing\project-svn\trunk\public\include\global.inc.php on line 18
---

Roughly-corresponding entries in Apache's error log:

---
[Thu Nov 01 13:29:21.235844 2012] [core:error] [pid 6780:tid 1136] (OS 32)The 
process cannot access the file because it is being used by another process.  : 
[client 10.0.1.57:65162] AH00127: Cannot map GET 
/project/public/js/jquery.accordion.js HTTP/1.1 to file, referer: 
https://ben-pc/project/public/company/history/
[Thu Nov 01 13:29:41.141441 2012] [core:error] [pid 6780:tid 1128] (OS 32)The 
process cannot access the file because it is being used by another process.  : 
[client 10.0.1.57:65204] AH00127: Cannot map GET 
/project/public/common/js/libs/modernizr-2.5.3.min.js HTTP/1.1 to file, 
referer: https://ben-pc/project/public/contact/service-inquiry/
---

While I don't see any direct correlation between the files cited in PHP's error 
log and those cited in Apache's error log, the message "(OS 32)The process 
cannot access the file because it is being used by another process" seems very 
relevant to the observed behavior in PHP.

This observation inspired me to create a very simple test script which, much to 
my surprise, enables me to produce this issue at will. I was able to reproduce 
the issue in Windows' Safe Mode, too, which seems to eliminate virus scanners, 
filter drivers, and other similar causes.

The key to reproducing this issue is making as many requests per unit of time 
as possible. In other words, holding-down the browser's refresh key (e.g., 
Ctrl+R or F5) for some period of time eventually causes require() failures to 
be logged.

Here's the script:



The contents of "require-test-include.php" are probably largely irrelevant, but 
I'm using the following:



A sample excerpt from PHP's error log contains entries such as the following:

---
[01-Nov-2012 16:01:53 America/New_York] PHP Warning:  
require(C:/Users/Ben/Documents/Apache/require-test-include.php): failed to open 
stream: No such file or directory in 
C:\Users\Ben\Documents\Apache\require-test.php on line 8

[01-Nov-2012 16:01:53 America/New_York] PHP Fatal error:  require(): Failed 
opening required 'C:/Users/Ben/Documents/Apache/require-test-include.php' 
(inclu

Bug #63413 [Opn]: Intermittent warning and fatal error on require() statement

[ben at indietorrent dot org]

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

 ID: 63413
 User updated by:    ben at indietorrent dot org
 Reported by:    ben at indietorrent dot org
 Summary:Intermittent warning and fatal error on require()
 statement
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows 7 x64
 PHP Version:5.4.8
 Block user comment: N
 Private report: N

 New Comment:

It occurred to me to examine Apache's internal error log for entries that 
correspond to those in PHP's error log when this occurs. I noticed what may be 
an important clue.

Sample entries in PHP's error log:

---
[01-Nov-2012 13:29:41 America/New_York] PHP Warning:  
require(../include/global.inc.php): failed to open stream: No such file or 
directory in C:\Users\Ben\Documents\Projects\project 
Testing\project-svn\trunk\public\auxiliary\css.php on line 5

[01-Nov-2012 13:29:41 America/New_York] PHP Fatal error:  require(): Failed 
opening required '../include/global.inc.php' (include_path='.;C:\Program 
Files\php\includes;C:\Program Files\php\PEAR\pear') in 
C:\Users\Ben\Documents\Projects\project 
Testing\project-svn\trunk\public\auxiliary\css.php on line 5

[01-Nov-2012 13:29:43 America/New_York] PHP Warning:  
require(C:/Users/Ben/Documents/Apache/project/protected/constants.inc.php): 
failed to open stream: No such file or directory in 
C:\Users\Ben\Documents\Projects\project 
Testing\project-svn\trunk\public\include\global.inc.php on line 18

[01-Nov-2012 13:29:43 America/New_York] PHP Fatal error:  require(): Failed 
opening required 
'C:/Users/Ben/Documents/Apache/project/protected/constants.inc.php' 
(include_path='.;C:\Program Files\php\includes;C:\Program Files\php\PEAR\pear') 
in C:\Users\Ben\Documents\Projects\project 
Testing\project-svn\trunk\public\include\global.inc.php on line 18
---

Roughly-corresponding entries in Apache's error log:

---
[Thu Nov 01 13:29:21.235844 2012] [core:error] [pid 6780:tid 1136] (OS 32)The 
process cannot access the file because it is being used by another process.  : 
[client 10.0.1.57:65162] AH00127: Cannot map GET 
/project/public/js/jquery.accordion.js HTTP/1.1 to file, referer: 
https://ben-pc/project/public/company/history/
[Thu Nov 01 13:29:41.141441 2012] [core:error] [pid 6780:tid 1128] (OS 32)The 
process cannot access the file because it is being used by another process.  : 
[client 10.0.1.57:65204] AH00127: Cannot map GET 
/project/public/common/js/libs/modernizr-2.5.3.min.js HTTP/1.1 to file, 
referer: https://ben-pc/project/public/contact/service-inquiry/
---

While I don't see any direct correlation between the files cited in PHP's error 
log and those cited in Apache's error log, the message "(OS 32)The process 
cannot access the file because it is being used by another process" seems very 
relevant to the observed behavior in PHP.

This observation inspired me to create a very simple test script which, much to 
my surprise, enables me to produce this issue at will. I was able to reproduce 
the issue in Windows' Safe Mode, too, which seems to eliminate virus scanners, 
filter drivers, and other similar causes.

The key to reproducing this issue is making as many requests per unit of time 
as possible. In other words, holding-down the browser's refresh key (e.g., 
Ctrl+R or F5) for some period of time eventually causes require() failures to 
be logged.

Here's the script:



The contents of "require-test-include.php" are probably largely irrelevant, but 
I'm using the following:



A sample excerpt from PHP's error log contains entries such as the following:

---
[01-Nov-2012 16:01:53 America/New_York] PHP Warning:  
require(C:/Users/Ben/Documents/Apache/require-test-include.php): failed to open 
stream: No such file or directory in 
C:\Users\Ben\Documents\Apache\require-test.php on line 8

[01-Nov-2012 16:01:53 America/New_York] PHP Fatal error:  require(): Failed 
opening required 'C:/Users/Ben/Documents/Apache/require-test-include.php' 
(include_path='.;C:\Program Files\php\includes;C:\Program Files\php\PEAR\pear') 
in C:\Users\Ben\Documents\Apache\require-test.php on line 8
---

Apache's error log fills-up with entries such as the following (I've included 
six lines to demonstrate the timestamp variances):

---
[Thu Nov 01 15:59:02.327506 2012] [core:error] [pid 4420:tid 1040] (OS 32)The 
process cannot access the file because it is being used by another process.  : 
[client 10.0.1.57:62710] AH00127: Cannot map GET /require-test.php HTTP/1.1 to 
file
[Thu Nov 01 15:59:02.389509 2012] [core:error] [pid 4420:tid 1040] (OS 32)The 
process cannot access 

[PHP-BUG] Bug #63413 [NEW]: Intermittent warning and fatal error on require() statement

[ben at indietorrent dot org]

From: ben at indietorrent dot org
Operating system: Windows 7 x64
PHP version:  5.4.8
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:Intermittent warning and fatal error on require() statement

Description:

I observe erratic behavior relating to require() statements. The files that
are being required are static (they are not created or destroyed during
script execution), so there should be no reason that they are required
successfully the vast majority of the time, but fail to be required some
small percentage of the time.

It bears mention that I am also wrapping the calls to require() in calls to
file_exists(). It seems that while file_exists() always returns true (the
require() statements are always executed), the calls to require() fail
intermittently with "PHP Warning: Unknown: failed to open stream: No such
file or directory" and then "PHP Fatal error: Unknown: Failed opening
required".

The symptoms of this issue are very similar to those described in
https://bugs.php.net/bug.php?id=49012 ("Spurious fatal error on require()
statement"), but I don't know whether the root cause is the same or not.

I have confirmed that this problem occurs on several different computers,
no two of which have the exact same OS or *AMP stack component versions.
For this reason, I do not believe this issue to be due to failing hardware,
a corrupt operating system, or similar.

I should note also that in PHP 5.2 and 5.3, the offending line number was
always zero (0). Unless line number zero has some special meaning in PHP,
this seems like a bug in itself. In any case, in PHP 5.4.8, the line number
is non-zero *usually* (but not always), and seems to be accurate. (I have
not tested with any PHP version before 5.2 or between 5.3 and 5.4.8.)

I have not installed any third-party extensions and am using a pristine
5.4.8 installation. PHP is running via Apache's mod_php module. php.ini is
relatively untouched; the only changes I made were to enable some of the
modules that are disabled by default (I can list them if it's relevant).

Unfortunately, I am unable to reproduce this issue at will, because it
occurs completely sporadically.

That said, the problem occurs quite frequently, so, if a developer is able
to provide specific debugging instructions, it should be easy enough for me
to capture the relevant information. By "quite frequently", I mean every
couple of minutes during normal browsing.

Also, I have used Firefox's handy "Reload Tab Every..." context menu
feature to reload an affected page every 1 second for 10 minutes straight
and the issue occurred only twice. This seems to indicate that the issue
does not necessarily occur some percentage of the time (+/- variance), but
rather, it occurs when more complex conditions are met. For whatever
reason, the issue occurs most frequently when I make several concurrent
requests to the affected URLs/files, and I navigate to various URLs before
each page has loaded fully.

Strangely enough, if I let the auto-refresh test run long enough (this run,
it took more than 30 minutes of refreshing every second), the specific
error messages change (the location of the failed require statements
change), but their nature is always the same: failed require() statements
due to variations of "file not found".

Also, the issue seems most likely to occur when the Web-server (Apache in
this case) has been sitting idle for some period of time (e.g., 10 or more
minutes). Oftentimes, if I have been away from the computer and refresh an
affected page when I return, the issue occurs. Could this behavior point to
memory managment or caching?

The code-base that causes this issue is shared across several different
production websites, all of which run on various GNU/Linux distributions.
With Ubuntu 10.04 + Apache 2.2.14 + mod_php + PHP 5.3.2, I do not observe
the issue at all. On another identically-configured server, the only
difference being Fast-CGI (fcgid) instead of mod_php, I do observe the
issue, but its manifestation is slightly different than on Windows with
mod_php. (I'm happy to provide details regarding the differences.)

I find it particularly strange that the messages and specific points of
failure change over time. The first log entry (made only a few seconds
after Apache was started) makes no sense; there is no file mentioned, and
the line number is zero:


[29-Oct-2012 15:30:29 America/New_York] PHP Warning:  Unknown: failed to
open stream: No such file or directory in Unknown on line 0


At least the related fatal error mentions a file:


[29-Oct-2012 15:30:29 America/New_York] PHP Fatal error:  Unknown: Failed
opening required
'C:/Users/Ben/Documents/Apache/project/public/auxiliary/css.php'
(include_path='.;C:\Program Files\php\includes;C:\Program
Files\php\PEAR

Bug #62942 [Opn]: Setting CURLOPT_COOKIE with curl_setopt_array problem

[ben at blinkmobile dot com dot au]

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

 ID: 62942
 User updated by:    ben at blinkmobile dot com dot au
 Reported by:    ben at blinkmobile dot com dot au
 Summary:Setting CURLOPT_COOKIE with curl_setopt_array
 problem
 Status: Open
 Type:   Bug
 Package:cURL related
 PHP Version:5.3.16
 Block user comment: N
 Private report: N

 New Comment:

Thanks Laruence. Is this documented anywhere? I couldn't find it.

Also, it appears that curl_setopt isn't enforcing the exclusivity. The 
following 
2 tests both attach $cookies fine on PHP 5.3.15:

$cookies = 'a=b';

$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, 'http://...');
curl_setopt($ch, CURLOPT_COOKIE, $cookies);
curl_setopt($ch, CURLOPT_COOKIEFILE, '');
curl_setopt($ch, CURLOPT_COOKIEJAR, '');
curl_setopt($ch, CURLOPT_HEADER, true);

curl_exec($ch);
curl_close($ch);


$cookies = 'a=b';

$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, 'http://...');
curl_setopt($ch, CURLOPT_COOKIEFILE, '');
curl_setopt($ch, CURLOPT_COOKIEJAR, '');
curl_setopt($ch, CURLOPT_HEADER, true);
curl_setopt($ch, CURLOPT_COOKIE, $cookies);

curl_exec($ch);
curl_close($ch);


I notice that the curl library between my tests was upgraded from 7.19.7 to 
7.24.0. Perhaps it was this and not https://bugs.php.net/bug.php?id=61948 ?

If there is documentation for this exclusivity it would be good to include a 
link 
here and on http://au2.php.net/manual/en/function.curl-setopt.php and 
http://au2.php.net/manual/en/function.curl-setopt-array.php because people's 
existing (however incorrect) code might break when they upgrade PHP or CURL.


Previous Comments:

[2012-08-27 02:55:28] larue...@php.net

it's not a bug, cookie_*** options are exclusive


[2012-08-27 01:53:39] ben at blinkmobile dot com dot au

Description:

Setting CURLOPT_COOKIE with curl_setopt_array must be done before setting 
CURLOPT_COOKIEFILE or CURLOPT_COOKIEJAR.

I'm not sure if this is a bug, however I can't find documentation explaining 
that 
when using curl_setopt_array you need to set options in a particular order.

It was working in PHP 5.3.13, however fails in 5.3.14 + 5.3.15

A change that could have caused this is https://bugs.php.net/bug.php?id=61948

Test script:
---
$cookies = 'a=b';

// the following correctly attaches $cookies in PHP 5.3.13 but not PHP 5.3.14+
$options = array(

CURLOPT_URL => 'http://...',
CURLOPT_COOKIEFILE => '',
CURLOPT_COOKIEJAR => '',
CURLOPT_HEADER => true,
CURLOPT_COOKIE => $cookies,
);


$ch = curl_init();
curl_setopt_array($ch, $options);
curl_exec($ch);
curl_close($ch);


// the following attaches $cookies correctly for all versions I have tested
$options = array(

CURLOPT_URL => 'http://...',
CURLOPT_COOKIE => $cookies,
CURLOPT_COOKIEFILE => '',
CURLOPT_COOKIEJAR => '',
CURLOPT_HEADER => true,
);


$ch = curl_init();
curl_setopt_array($ch, $options);
curl_exec($ch);
curl_close($ch);







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

[PHP-BUG] Bug #62942 [NEW]: Setting CURLOPT_COOKIE with curl_setopt_array problem

[ben at blinkmobile dot com dot au]

From: ben at blinkmobile dot com dot au
Operating system: 
PHP version:  5.3.16
Package:  cURL related
Bug Type: Bug
Bug description:Setting CURLOPT_COOKIE with curl_setopt_array problem

Description:

Setting CURLOPT_COOKIE with curl_setopt_array must be done before setting 
CURLOPT_COOKIEFILE or CURLOPT_COOKIEJAR.

I'm not sure if this is a bug, however I can't find documentation
explaining that 
when using curl_setopt_array you need to set options in a particular
order.

It was working in PHP 5.3.13, however fails in 5.3.14 + 5.3.15

A change that could have caused this is
https://bugs.php.net/bug.php?id=61948

Test script:
---
$cookies = 'a=b';

// the following correctly attaches $cookies in PHP 5.3.13 but not PHP
5.3.14+
$options = array(

CURLOPT_URL => 'http://...',
CURLOPT_COOKIEFILE => '',
CURLOPT_COOKIEJAR => '',
CURLOPT_HEADER => true,
CURLOPT_COOKIE => $cookies,
);


$ch = curl_init();
curl_setopt_array($ch, $options);
curl_exec($ch);
curl_close($ch);


// the following attaches $cookies correctly for all versions I have
tested
$options = array(

CURLOPT_URL => 'http://...',
CURLOPT_COOKIE => $cookies,
CURLOPT_COOKIEFILE => '',
CURLOPT_COOKIEJAR => '',
CURLOPT_HEADER => true,
);


$ch = curl_init();
curl_setopt_array($ch, $options);
curl_exec($ch);
curl_close($ch);


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

Bug #61246 [Com]: Error when running PHP-FPM

[ben at customerparadigm dot com]

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

 ID: 61246
 Comment by:     ben at customerparadigm dot com
 Reported by:osmanungur at gmail dot com
 Summary:Error when running PHP-FPM
 Status: Open
 Type:   Bug
 Package:FPM related
 Operating System:   Mac Os X 10.7.3
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

Hello,
I am currently running the following setup for PHP:
  --configure-options [--with-libdir=lib64 --with-gd --enable-fpm --with-mcrypt 
-
-with-curl --with-mysql --with-pdo-mysql]
  --version   [5.4.0]
  --vernum[50400]
I checked out the following APC revision: 324292
>From there I recompiled, and re-installed APC. 
Finally, restarted php-fpm and everything is working fine so far!

--Ben Korn


Previous Comments:

[2012-03-13 15:25:59] gonperes at gmail dot com

Greetings.

I just downloaded latest dev version (5.4.1RC1-dev) and i'm still having this 
problem: Starting php-fpm *** glibc detected *** /usr/local/sbin/php-fpm: 
free(): invalid pointer: 0x2aedda63c698 ***
(...) and a bunch of lines after this (...)

Everything seems to be working though. It's just this annoying error message.

My setup:
'./configure' '--enable-fpm' '--with-fpm-user=www-data' '--with-fpm-group=www-
data' '--with-curl' '--with-gd' '--with-jpeg-dir' '--with-freetype-dir' '--
enable-gd-native-ttf' '--with-mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with-
pear' '--enable-soap' '--with-imap' '--with-imap-ssl' '--with-kerberos' '--
disable-pdo' '--with-zlib' '--with-openssl' '--enable-zip'
make
make install
pecl install apc

Cheers!


[2012-03-12 15:34:22] Jared dot Williams1 at ntlworld dot com

Problem seems fixed in r324146


[2012-03-10 14:01:34] Jared dot Williams1 at ntlworld dot com

Actually r323587 is fine too it seems, but r323990 introduces the problem.


[2012-03-10 13:49:06] Jared dot Williams1 at ntlworld dot com

svn head (currently r324037) contains this problem.

Reverted back to r316786 which doesn't.


[2012-03-09 23:38:04] dancom96 at gmail dot com

I copy pasted the wrong link in my last comment, but the latest SVN APC seems 
to 
be broken again. I compiled with SVN APC a couple days ago and it worked fine; 
but 
today I redownloaded it and recompiled, and I now have the same error once 
again.




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

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


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

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

[ben dot lemasurier at gmail dot com]

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

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

 New Comment:

confirmed on php v5.3.10


Previous Comments:

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

Add patch for 5.3.10.

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

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


[2012-02-13 19:43:05] me at nicholassavilerobinson dot com

I confirm this deficiency: php5-fpm 5.3.9+ prevents fpm passing error_log 
output  
to the web server's error log via SAPI. 

I encounter this issue using nginx 1.0.11, but it is also present with older 
nginx releases. The problem is encountered even with 777 permissions on the 
logs. If I roll back to php5-fpm_5.3.8 (keeping the same configs), it starts 
working again. I would like fpm STDERR to output to the virtual host's error 
log 
(this was the default behavior before).

A sample php.ini/php-fpm.conf is attached:

/etc/php5/fpm/php.ini

[PHP]
engine = On
short_open_tag = Off
asp_tags = Off
precision = 14
y2k_compliance = On
output_buffering = 4096
zlib.output_compression = Off
implicit_flush = Off
unserialize_callback_func =
serialize_precision = 17
allow_call_time_pass_reference = Off
safe_mode = Off
safe_mode_gid = Off
safe_mode_include_dir =
safe_mode_exec_dir =
safe_mode_allowed_env_vars = PHP_
safe_mode_protected_env_vars = LD_LIBRARY_PATH
disable_functions =
disable_classes =
expose_php = On
max_execution_time = 30
max_input_time = 60
memory_limit = 128M
error_reporting = E_ALL & ~E_DEPRECATED
display_errors = Off
display_startup_errors = Off
log_errors = On
log_errors_max_len = 1024
ignore_repeated_errors = Off
ignore_repeated_source = Off
report_memleaks = On
track_errors = Off
html_errors = Off
variables_order = "GPCS"
request_order = "GP"
register_globals = Off
register_long_arrays = Off
register_argc_argv = Off
auto_globals_jit = On
post_max_size = 8M
magic_quotes_gpc = Off
magic_quotes_runtime = Off
magic_quotes_sybase = Off
auto_prepend_file =
auto_append_file =
default_mimetype = "text/html"
doc_root =
user_dir =
enable_dl = Off
file_uploads = On
upload_max_filesize = 2M
max_file_uploads = 20
allow_url_fopen = On
allow_url_include = Off
default_socket_timeout = 60


/etc/php5/fpm/php-fpm.conf:

[global]
pid = /var/run/php5-fpm.pid
error_log = /var/log/php5-fpm.log
[www]
listen = /tmp/fcgi.socket
user = www-data
group = www-data
pm = dynamic
pm.max_children = 50
pm.start_servers = 25
pm.min_spare_servers = 5
pm.max_spare_servers = 35
pm.max_requests = 500
pm.status_path = /status
ping.path = /ping
ping.response = Ok
slowlog = log/$pool.log.slow
chdir = /


[2012-02-10 14:27:29] lxlight at gmail dot com

Description:

Since php 5.3.9 released with any variation of config parameters php-fpm don't 
send php script errors/warnings to nginx. Reading logs on one frontend which 
contains get request, referrer, backend host is very simply. Pleas add the 
ability to send stderr to frontend when error_log is undefined.







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

[PHP-BUG] Bug #61267 [NEW]: pdo_pgsql's PDO::exec() returns the number of SELECTed rows on postgresql >= 9.

[ben dot pineau at gmail dot com]

From: 
Operating system: all
PHP version:  Irrelevant
Package:  PDO related
Bug Type: Bug
Bug description:pdo_pgsql's PDO::exec() returns the number of SELECTed rows on 
postgresql >= 9.

Description:

After executing a SELECT statement, PDO::exec() -using the pdo_pgsql driver
and 
running against a PostgreSQL server older than 9.0- will always returns 0,
as 
does the pdo_mysql and pdo_sqlite drivers. ie. this is the exepected
behaviour 
(though to be precise, the PDO::exec() documentation stipulate :
"PDO::exec() 
does not return results from a SELECT statement.").

But when executed against a PostgreSQL >= 9.0 server, this very same php
client 
and select statement will return the number of selected rows. This is due
to a 
server side change in how PostgreSQL servers answers to libpqs's
PQcmdTuples() 
commands (PQcmdTuples() being used as the PDO::exec() return value, via 
pdo_pgsql pgsql_handle_doer() function).

This server-side change is visible by comparing this command's
documentation for 
different PostgreSQL versions :
http://www.postgresql.org/docs/8.4/interactive/libpq-exec.html#LIBPQ-EXEC-
SELECT-INFO
http://www.postgresql.org/docs/9.1/interactive/libpq-exec.html#LIBPQ-EXEC-
SELECT-INFO
See also the bug in pg_affected_rows https://bugs.php.net/bug.php?id=61266
I 
just reported.

The attached patch does check whether the PDO::exec() param was a
(successful) 
DML statement before using PQcmdTuples() to return the number of affected
rows. 
Also attached, a test script for PHP's unit test infrastructure.


Test script:
---
// Bugs on PostgreSQL >= 9.0 server (but ok on previous versions)
$dbh = new PDO("pgsql:dbname=postgres ;host=localhost", 'postgres'); 
var_dump($dbh->exec("SELECT * from generate_series(1, 42);"));

Expected result:

int(0)

Actual result:
--
int(42)

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

[PHP-BUG] Bug #61266 [NEW]: pg_affected_rows inconsistent behavior (depends on PostgreSQL server version)

[ben dot pineau at gmail dot com]

From: 
Operating system: all
PHP version:  Irrelevant
Package:  PostgreSQL related
Bug Type: Bug
Bug description:pg_affected_rows inconsistent behavior (depends on PostgreSQL 
server version)

Description:

According to the manual, pg_affected_rows should returns "the number of
tuples 
(instances/records/rows) affected by INSERT, UPDATE, and DELETE queries.".
The 
manual details : "The number of rows affected by the query. If no tuple is

affected, it will return 0.".

PHP pg_affected_rows uses libpq's PQcmdTuples() to implement this:

  PHP_FUNCTION(pg_affected_rows)
  {
 
php_pgsql_get_result_info(INTERNAL_FUNCTION_PARAM_PASSTHRU,PHP_PG_CMD_TUPLES);
  }

  static void php_pgsql_get_result_info(INTERNAL_FUNCTION_PARAMETERS, int 
entry_type)
  {
  [...]
case PHP_PG_CMD_TUPLES:
Z_LVAL_P(return_value) = atoi(PQcmdTuples(pgsql_result));

But server's answers to PQcmdTuples() commands changed since PostgreSQL
9.0. 
When executed after a SELECT, PostgreSQL < 9.0 returned 0 (as in "0 rows
were 
affected"); starting with PostgreSQL 9.0, the server returns the number of

SELECTed rows.

See how the PQcmdTuples documentation was updated after pg 9:
http://www.postgresql.org/docs/8.4/interactive/libpq-exec.html#LIBPQ-EXEC-
SELECT-INFO
http://www.postgresql.org/docs/9.1/interactive/libpq-exec.html#LIBPQ-EXEC-
SELECT-INFO

PostgreSQL C API doesn't actually offers a "tell me how many rows were 
written/modified" function.  But we can restore the previous
pg_affected_rows 
behavior, and enjoy consistent results no matter which server version we
run 
against, by unconditionally returning 0 after a SELECT.

This is what the attached patch does, identifying the SELECT with 
PQresultStatus() value (which returns PGRES_COMMAND_OK after a successful
DML, 
as opposed to PGRES_TUPLES_OK after a SELECT, etc).

If you ask so, I can also provide an alternative patch (which tests the
string 
returned by PQcmdStatus(), a bit ugly imo) and/or an unit test script for
PHP's 
test framework.


Test script:
---
// Bug on a PostgreSQL >= 9.0 server, ok on older versions.
$dbh = pg_pconnect("dbname=postgres host=localhost user=postgres
port=5432");
$q = pg_query($dbh, "SELECT * from generate_series(1, 42);");
var_dump(pg_affected_rows($q));

Expected result:

int(0)

Actual result:
--
int(42)

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

[PHP-BUG] Req #61105 [NEW]: Support Soap 1.2 SoapFault Reason Text lang attribute

[ben dot davies at boxuk dot com]

From: 
Operating system: All
PHP version:  Irrelevant
Package:  SOAP related
Bug Type: Feature/Change Request
Bug description:Support Soap 1.2 SoapFault Reason Text lang attribute

Description:

Using soap version 1.2, SoapFaults with Reasons are not currently schema 
compliant.
See
http://www.w3.org/TR/soap12-part1/#reasontextelement

Reason > Text should have a mandatory attribute lang.
see http://www.w3.org/TR/soap12-part1/#reasontextelement

This has been marked in the source since 2004 as a TODO.
see
http://svn.php.net/viewvc/php/php-src/trunk/ext/soap/php_packet_soap.c?
view=markup line 221.


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

Bug #48460 [NoF->Csd]: Referencing an object property causes behaviour change after clone

[ben at last dot fm]

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

 ID: 48460
 User updated by:    ben at last dot fm
 Reported by:    ben at last dot fm
 Summary:Referencing an object property causes behaviour
 change after clone
-Status: No Feedback
+Status: Closed
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Linux
 PHP Version:5.2.9
 Block user comment: N
 Private report: N

 New Comment:

Sorry matteo, that's not got anything to do with the bug I was reporting. Your 
example doesn't include setting a reference, so it's not the same bug.

I can confirm this bug still exists in PHP 5.3.5.

Here is a real minimal test case:


class A { var $p; }
$a = new A;
$a->p = 'expected';
$x =& $a->p;
$b = clone $a;
$a->p = 'unexpected;
echo $b->p; // prints 'unexpected'; b is sharing references with a, due to an 
inbound reference from outside, so clone behaviour changes for that property.

You can also cause clone behaviour to change using the following highly bizarre 
incantation:

$a = new A;
$a->p =& $a->p; // turn the property into a reference with a refcount of 1.
$b = clone $a;
$a->p = 1;
$b->p = 2;
echo $a->p; // gives 2.


Previous Comments:

[2012-01-11 14:06:16] matteopuppis at gmail dot com

More simple code:
test[0] = 'pippo';
$b = clone $a;
$b->test[0] = 'pluto';
echo ($a->test[0].'');

$c = new Obj();
$c->test[0]->prova = 'pippo';
$d = clone $c;
$d->test[0]->prova = 'pluto';
echo ($c->test[0]->prova);
?>

Expected result: "pippo pippo"
Actual result: "pippo pluto"


[2009-09-26 01:00:03] php-bugs at lists dot php dot net

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


[2009-09-18 19:01:59] 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-06-03 15:26:16] ben at last dot fm

Hmm.

The bug is that you can alter the behaviour of clone (that is, force $d-
>list to be copied-by-reference instead of copied-by-value) merely by 
creating any other reference to $a->list. 'clone' is, therefore, the 
only language construct (that I know of) which is capable of this, and 
is NOT the same as "$b = new A; $b->list = $a->list". 

There is in fact no way to tell whether a property is a reference or not 
without cloning the entire object and seeing what happens when you 
change the clone's property; or by forcibly unsetting and resetting the 
property.


[2009-06-03 13:54:41] col...@php.net

This is quite expected, that's basically the same as:

$a = array(2);
$d = &$a[0];

$a_copy = $a;
$a_copy[0]++;

echo $a[0],$d; // 3 3

You can do a deep copy using the __clone hook.

OTOH I'm not sure if clone shouldn't separate the properties directly, instead 
of simply assigning them.






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

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


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

Req #32100 [Com]: Request 'finally' support for exceptions

[ben at last dot fm]

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

 ID: 32100
 Comment by:     ben at last dot fm
 Reported by:ceefour at gauldong dot net
 Summary:Request 'finally' support for exceptions
 Status: Closed
 Type:   Feature/Change Request
 Package:Feature/Change Request
 Operating System:   *
 PHP Version:5.*
 Block user comment: N
 Private report: N

 New Comment:

"finally" would be a majorly beneficial addition to the language. It's 
something 
we yearn for here at last.fm.


Previous Comments:

[2011-12-05 17:55:43] php dot net at kenman dot net

+1

>From Zeev, in the 2000 discussion:

> try..finally doesn't make much sense in the context of PHP [...] Nobody has 
> ever 
asked for this in the past either.

Those days are long past, please take this bug report's comments as a sign that 
this *does* now make sense for PHP.


[2011-12-05 15:53:28] topaz dot php dot bugs at lt3 dot us

Ugly workaround hack time!

(This is not a substitute for a real language feature!)

Mix and match with try/catch blocks as necessary.

invoke();

  print "Example 1 ended normally.\n";
}

function example2()
{
  $finally = new Finally("example_finally");
  print "Throwing exception!\n";
  throw new Exception("Something exceptional happened!");
  $finally->invoke();

  print "Example 2 ended normally.\n";
}


// Test harness

print "Example 1...\n";
try
{
  example1();
}
catch (Exception $e)
{
  print "Example 1 threw an exception!\n";
}

print "\nExample 2...\n";
try
{
  example2();
}
catch (Exception $e)
{
  print "Example 2 threw an exception!\n";
}


// Implementation of the Finally class

class Finally
{
  private $_callback = NULL;
  private $_args = array();

  function __construct($callback, array $args = array())
  {
if (!is_callable($callback))
{
  throw new Exception("Callback was not callable!");
}

$this->_callback = $callback;
$this->_args = $args;
  }

  public function invoke()
  {
if ($this->_callback)
{
  call_user_func_array($this->_callback, $args);
  $this->_callback = NULL;
  $this->_args = array();
}
  }

  function __destruct()
  {
$this->invoke();
  }
}


[2011-11-18 00:25:23] chiestand at salk dot edu

First, thank you everyone who has contributed to this bug report thread. Your 
insights have been incredibly useful.

I too vote for inclusion of "finally" into PHP. In my own particular situation 
I was 
able to solve my problem using Stroustrup's RAII pattern (thank you btsai). But 
I can 
imagine that in some cases creating a class for every resource used might be 
inconvenient.

I think ceefour really summed it up nicely back in 2005 with even more-ancient 
wisdom: "Be conservative with what you emit and be liberal with what you 
accept". 
Provide the tool, and let the coder decide what pattern to use.


[2011-09-07 14:49:08] viktor at zuiderkwast dot se

The same problem exists in C++, which also lacks the finally clause. The 
standard way to solve the resource allocation problem in C++ is instead by 
using the RAII design pattern.

As noted in Wikipedia on RAII, "In this language, the only code that can be 
guaranteed to be executed after an exception is thrown are the destructors of 
objects residing on the stack.". The same is valid for PHP (although the 
objects are reference-counted instead of being allocated on the stack). The 
destructor is guarranteed to be called as soon as all references to the object 
run out of scope, so the RAII is effectively usable in PHP.

So, the code you would put in the finally clause in Java etc has to be put in a 
destructor of some object instead. Then, when a return or a or an uncatched 
exception occurs inside a try block, and there are no other references to the 
object, the destructor will be called at this point to free the resources.

In my optinion, the finally clause is a more elegant solution, although it 
might be *too sophisticated* for PHP...


[2011-07-25 03:27:14] ninzya at inbox dot lv

++finally




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

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


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

[PHP-BUG] Req #55163 [NEW]: Retain EXIF data in images

[ben at bentadiar dot co dot uk]

From: 
Operating system: All
PHP version:  5.3.6
Package:  GD related
Bug Type: Feature/Change Request
Bug description:Retain EXIF data in images

Description:

When using GD library functions, the EXIF data is stripped from images. It
would be useful to retain this information and implement a strip function,
similar to Imagick::stripImage(), for cases where this data is not
required.

Expected result:

Image with EXIF data intact

Actual result:
--
Image with EXIF data stripped

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

[PHP-BUG] Bug #53518 [NEW]: pclose and proc_close do not return values for use with pcntl_wifexited

[ben dot spencer at digitalwindow dot com]

From: 
Operating system: Linux
PHP version:  5.3SVN-2010-12-10 (SVN)
Package:  Program Execution
Bug Type: Bug
Bug description:pclose and proc_close do not return values for use with 
pcntl_wifexited

Description:

The manual for pclose and proc_close states:



Note: Unix Only:



proc_close() is internally implemented using the waitpid(3) system call. To
obtain the real exit status code the pcntl_wexitstatus() function should be
used.



However, they in fact return the real exit code directly.  This makes it
impossible to tell whether a program exited normally or was killed by a
signal.



Test script:
---
http://www.pastie.org/1364987

Expected result:

Testing command: false



pclose test:

status value: int(256)

pcntl_wifexited: bool(true)

pcntl_wexitstatus: int(1)

pcntl_wifsignaled: bool(false)

pcntl_wtermsig: int(0)



proc_close test:

status value: int(256)

pcntl_wifexited: bool(true)

pcntl_wexitstatus: int(1)

pcntl_wifsignaled: bool(false)

pcntl_wtermsig: int(0)





Testing command: kill -1 $$



pclose test:

status value: int(1)

pcntl_wifexited: bool(false)

pcntl_wexitstatus: int(0)

pcntl_wifsignaled: bool(true)

pcntl_wtermsig: int(1)





proc_close test:

status value: int(1)

pcntl_wifexited: bool(false)

pcntl_wexitstatus: int(0)

pcntl_wifsignaled: bool(true)

pcntl_wtermsig: int(1)

Actual result:
--
Testing command: false



pclose test:

status value: int(1)

pcntl_wifexited: bool(false)

pcntl_wexitstatus: int(0)

pcntl_wifsignaled: bool(true)

pcntl_wtermsig: int(1)





proc_close test:

status value: int(1)

pcntl_wifexited: bool(false)

pcntl_wexitstatus: int(0)

pcntl_wifsignaled: bool(true)

pcntl_wtermsig: int(1)





Testing command: kill -1 $$



pclose test:

status value: int(1)

pcntl_wifexited: bool(false)

pcntl_wexitstatus: int(0)

pcntl_wifsignaled: bool(true)

pcntl_wtermsig: int(1)





proc_close test:

status value: int(1)

pcntl_wifexited: bool(false)

pcntl_wexitstatus: int(0)

pcntl_wifsignaled: bool(true)

pcntl_wtermsig: int(1)



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

Bug #34972 [Com]: STDIN won't allow nonblocking.

[me at ben-xo dot com]

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

 ID: 34972
 Comment by: me at ben-xo dot com
 Reported by:VJTD3 at VJTD3 dot com
 Summary:STDIN won't allow nonblocking.
 Status: Assigned
 Type:   Bug
 Package:Streams related
 Operating System:   win32 only
 PHP Version:5.2CVS-2008-07-15
 Assigned To:pajoye
 Block user comment: N

 New Comment:

Experiencing this issue on Win 32 with PHP 5.3.2.
stream_set_blocking(STDIN, 0) 

('correctly') returns false and does not allow non-blocking. Also
experiencing 

issues using stream_select() on STDIN. STDIN always comes back as ready
for 

reading, but reading from it blocks.


Previous Comments:

[2010-02-26 01:47:14] joseph at none-yo-business dot com

Hope this helps someone else, but the workaround I had to do was to
fread(stdin) from another script, output to a temp file, then use output
in my other script. 



Yeah its ugly, but at least I have an interactive shell (or should that
be shells :)



Dear PHP developers. I love php. Its the glue that holds everything I do
together Please take this in the best way possible, WTF? This bug
should not be there... And 4 years after the fact?! Please help me love
PHP even more, and fix this bug.


[2009-11-14 15:31:44] raskin at aoeu dot ru

Confirmed on Nov 14th, 2009 with PHP 5.2.11 on WinXp

Yet no useful fix. Linux (Ubuntu 9.10 is just fine)


[2009-07-22 22:58:50] xektrum at gmail dot com

I can confirm this bug affects PHP 5.3.0. today at July 22 2009 almost 4
years from its submittion and still no fix.



This is very important since you can't create a really interactive CLI
application with this issue, and stops developers from choosing PHP to
theirs CLI/CMD/Console application (Although this could affect PHP-GTK
users and developers)



Hope this fix soon



Regards


[2009-04-16 17:48:36] frase at cs dot wisc dot edu

I'm having the same trouble.



With php-5.3.0-beta1 on Linux it works fine, both on STDIN and on
fopen('/dev/ttyS0').  stream_set_blocking() returns true,
stream_get_meta_data() confirms, and the stream behaves as if
non-blocking.



But with php-5.2.9 on Windows 2000 it doesn't work for either STDIN or
the serial port (COM1 instead of /dev/ttyS0).  stream_set_blocking()
returns false, stream_get_meta_data() shows blocking, and the streams do
in fact block.  I also tried stream_set_timeout() with a tiny value, to
simulate the effect, but that also returns false and doesn't work.


[2008-10-24 16:11:54] j...@php.net

Assigned to the windows port maintainer.




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

http://bugs.php.net/bug.php?id=34972


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

Bug #52529 [Asn]: PDO+Mysqlnd MYSQL_ATTR_COMPRESS undefined

[ben at blazely dot com]

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

 ID: 52529
 User updated by:    ben at blazely dot com
 Reported by:    ben at blazely dot com
 Summary:PDO+Mysqlnd MYSQL_ATTR_COMPRESS undefined
 Status: Assigned
 Type:   Bug
 Package:PDO related
 Operating System:   Ubuntu 10.04
 PHP Version:5.3SVN-2010-08-04 (snap)
 Assigned To:mysql
 Block user comment: N

 New Comment:

I was aware that pdo_mysql did not support compression, however I
thought that it was added in 5.3.2? I'm using 5.3.3. 



Was this not the case? If not then the documentation below may need to
be changed as I found it a little misleading.



From: http://www.php.net/manual/en/mysqlnd.overview.php



Compressed Protocol Support



As of PHP 5.3.2 MySQL Native Driver supports the compressed client
server protocol. MySQL Native Driver did not support this in 5.3.0 and
5.3.1. Extensions such as ext/mysql, ext/mysqli, PDO_MYSQL, that are
configured to use MySQL Native Driver, can also take advantage of this
feature.


Previous Comments:

[2010-08-04 11:14:39] ka...@php.net

Its currently known as indicated in the sources that compression is
unavailable in mysqlnd



Assigned to the mysql team


[2010-08-04 03:02:07] ben at blazely dot com

Description:

Client compression support was added to mysqlnd in php 5.3.3. PDO_mysql
should now be able to use it.



However the constant MYSQL_ATTR_COMPRESS is undefined in the PDO class
when compiling using the following (bare minimum) config:



./configure --with-pdo-mysql=mysqlnd --with-mysql=mysqlnd



Due to how recent this addition is, I can find no further information on
php.net/google/anywhere...



There are also some confusing (and useless?) switches in configure for
mysqlnd compression that seem counter-intuitive.



--disable-mysqlnd-compression-support

Enable support for the MySQL compressed
protocol in mysqlnd

--with-zlib-dir[=DIR]   mysqlnd: Set the path to libz install
prefix



When configure runs, it says that it has disabled mysqlnd compression
support, however phpinfo() (post compile) shows that compression is
available and that pdo_mysql is using mysqlnd. 



--



mysql



MySQL Support => enabled

Active Persistent Links => 0

Active Links => 0

Client API version => mysqlnd 5.0.7-dev - 091210 - $Revision: 300533 



--



mysqlnd



mysqlnd => enabled

Version => mysqlnd 5.0.7-dev - 091210 - $Revision: 300533 $

Compression => supported

SSL => supported

Command buffer size => 4096

Read buffer size => 32768

Read timeout => 31536000

Collecting statistics => Yes

Collecting memory statistics => No



--



PDO



PDO support => enabled

PDO drivers => sqlite, sqlite2, mysql



pdo_mysql



PDO Driver for MySQL => enabled

Client API version => mysqlnd 5.0.7-dev - 091210 - $Revision: 300533 $





Test script:
---
 true

)

);

  } catch (PDOException $o_e) {

 print $o_e->getMessage();

  }

Expected result:

No output, DB connection established, client compression enabled.

Actual result:
--
Error as follows:

Fatal error: Undefined class constant 'MYSQL_ATTR_COMPRESS' in test.php
on line 15






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

[PHP-BUG] Bug #52529 [NEW]: PDO+Mysqlnd MYSQL_ATTR_COMPRESS undefined

[ben at blazely dot com]

From: 
Operating system: Ubuntu 10.04
PHP version:  5.3SVN-2010-08-04 (snap)
Package:  PDO related
Bug Type: Bug
Bug description:PDO+Mysqlnd MYSQL_ATTR_COMPRESS undefined

Description:

Client compression support was added to mysqlnd in php 5.3.3. PDO_mysql
should now be able to use it.



However the constant MYSQL_ATTR_COMPRESS is undefined in the PDO class when
compiling using the following (bare minimum) config:



./configure --with-pdo-mysql=mysqlnd --with-mysql=mysqlnd



Due to how recent this addition is, I can find no further information on
php.net/google/anywhere...



There are also some confusing (and useless?) switches in configure for
mysqlnd compression that seem counter-intuitive.



--disable-mysqlnd-compression-support

Enable support for the MySQL compressed
protocol in mysqlnd

--with-zlib-dir[=DIR]   mysqlnd: Set the path to libz install prefix



When configure runs, it says that it has disabled mysqlnd compression
support, however phpinfo() (post compile) shows that compression is
available and that pdo_mysql is using mysqlnd. 



--



mysql



MySQL Support => enabled

Active Persistent Links => 0

Active Links => 0

Client API version => mysqlnd 5.0.7-dev - 091210 - $Revision: 300533 



--



mysqlnd



mysqlnd => enabled

Version => mysqlnd 5.0.7-dev - 091210 - $Revision: 300533 $

Compression => supported

SSL => supported

Command buffer size => 4096

Read buffer size => 32768

Read timeout => 31536000

Collecting statistics => Yes

Collecting memory statistics => No



--



PDO



PDO support => enabled

PDO drivers => sqlite, sqlite2, mysql



pdo_mysql



PDO Driver for MySQL => enabled

Client API version => mysqlnd 5.0.7-dev - 091210 - $Revision: 300533 $





Test script:
---
 true

)

);

  } catch (PDOException $o_e) {

 print $o_e->getMessage();

  }

Expected result:

No output, DB connection established, client compression enabled.

Actual result:
--
Error as follows:

Fatal error: Undefined class constant 'MYSQL_ATTR_COMPRESS' in test.php on
line 15

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

[PHP-BUG] Bug #52454 [NEW]: Relative dates and getTimestamp increments by one day

[ben dot davies at stickyeyes dot com]

From: 
Operating system: Windows 7 Professional
PHP version:  5.3.3
Package:  Date/time related
Bug Type: Bug
Bug description:Relative dates and getTimestamp increments by one day

Description:

If you create a DateTime object using a relative date string of "this week
+6 days", when calling getTimestamp on the datetime object, the date is
mysteriously increments by one day. However, if you seperately modify the
datetime using 'this week', then '+6 days', it works correctly.



Where is the additional day comeing from, and why is it only applied when
calling format('U') DOESNT increment the datetime by 1 day. Wierd!



Here is a work around:



$endOfWeek = new DateTime();

$endOfWeek->modify('this week');

$endOfWeek->modify('+6 days');



echo $endOfWeek->format('Y-m-d H:m:s')."\n";

echo $endOfWeek->format('U')."\n";



/* Thar she blows! */

echo $endOfWeek->getTimestamp()."\n";



echo $endOfWeek->format('Y-m-d H:m:s')."\n";

Test script:
---
$endOfWeek = new DateTime();

$endOfWeek->modify('this week +6 days');



echo $endOfWeek->format('Y-m-d H:m:s')."\n";

echo $endOfWeek->format('U')."\n";



/* Thar she blows! */

echo $endOfWeek->getTimestamp()."\n";



echo $endOfWeek->format('Y-m-d H:m:s')."\n";



Expected result:

DateTime should stay the same after a call to getTimestamp (surely
getTimestamp should be safe from side effects)


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

Bug #52339 [Com]: SPL autoloader breaks class_exists()

[dangerous dot ben at gmail dot com]

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

 ID:   52339
 Comment by:   dangerous dot ben at gmail dot com
 Reported by:  dangerous dot ben at gmail dot com
 Summary:  SPL autoloader breaks class_exists()
 Status:   Bogus
 Type: Bug
 Package:  SPL related
 Operating System: any (debian)
 PHP Version:  5.3.3RC2

 New Comment:

I beg to differ.  As you say, class_exists() attempts to autoload if
there second param is true, but if autoloading fails it should simply
return false as usual rather than throw an exception.  Otherwise it is
rather useless.



The fact that this only occurs when there isn't another autoloader in
the stack should make it clear that this is a bug.  For example, the
following code does not throw an exception:



spl_autoload_register();

spl_autoload_register(function(){});

class_exists('foo\bar');


Previous Comments:

[2010-07-15 05:11:04] ka...@php.net

You are calling class_exists() with just a class name, which leaves the
second parameter ($autoload) set to true, which then invokes SPL and
throws the exception, so no bug here


[2010-07-14 21:54:08] dangerous dot ben at gmail dot com

On further investigation, it appears that the error is meant to happen
only if spl_autoload is called directly, and not via spl_autoload_call. 
Unfortunately when spl_autoload is the only autoloader in the stack it
gets called directly and spl_autoload_call doesn't get a look in.


[2010-07-14 21:31:46] dangerous dot ben at gmail dot com

Description:

Using PHP 5.3 from svn.



When SPL's default autoloader is the only loader in the stack it
triggers an error or throws an exception when it can't find a class. 
This means that you get an exception when calling class_exists() for a
class that doesn't exist.  This behaviour seems pointless anyway since
PHP will trigger its own fatal error if the class still doesn't exist
after attempting to autoload, so the attached patch simply removes it.





Test script:
---
spl_autoload_register();

class_exists('foo\bar');



Expected result:

No error



Actual result:
--
b...@arctor:~/src/php-5.3$ sapi/cli/php ~/code/cram/test.php 

PHP Fatal error:  Uncaught exception 'LogicException' with message
'Class foo\bar could not be loaded' in /home/ben/code/cram/test.php:4

Stack trace:

#0 [internal function]: spl_autoload('foo\bar')

#1 /home/ben/code/cram/test.php(4): class_exists('foo\bar')

#2 {main}

  thrown in /home/ben/code/cram/test.php on line 4








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

Bug #52339 [Com]: SPL autoloader breaks class_exists()

[dangerous dot ben at gmail dot com]

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

 ID:   52339
 Comment by:   dangerous dot ben at gmail dot com
 Reported by:  dangerous dot ben at gmail dot com
 Summary:  SPL autoloader breaks class_exists()
 Status:   Open
 Type: Bug
 Package:  SPL related
 Operating System: any (debian)
 PHP Version:  5.3.3RC2

 New Comment:

On further investigation, it appears that the error is meant to happen
only if spl_autoload is called directly, and not via spl_autoload_call. 
Unfortunately when spl_autoload is the only autoloader in the stack it
gets called directly and spl_autoload_call doesn't get a look in.


Previous Comments:

[2010-07-14 21:31:46] dangerous dot ben at gmail dot com

Description:

Using PHP 5.3 from svn.



When SPL's default autoloader is the only loader in the stack it
triggers an error or throws an exception when it can't find a class. 
This means that you get an exception when calling class_exists() for a
class that doesn't exist.  This behaviour seems pointless anyway since
PHP will trigger its own fatal error if the class still doesn't exist
after attempting to autoload, so the attached patch simply removes it.





Test script:
---
spl_autoload_register();

class_exists('foo\bar');



Expected result:

No error



Actual result:
--
b...@arctor:~/src/php-5.3$ sapi/cli/php ~/code/cram/test.php 

PHP Fatal error:  Uncaught exception 'LogicException' with message
'Class foo\bar could not be loaded' in /home/ben/code/cram/test.php:4

Stack trace:

#0 [internal function]: spl_autoload('foo\bar')

#1 /home/ben/code/cram/test.php(4): class_exists('foo\bar')

#2 {main}

  thrown in /home/ben/code/cram/test.php on line 4








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

[PHP-BUG] Bug #52339 [NEW]: SPL autoloader breaks class_exists()

[dangerous dot ben at gmail dot com]

From: 
Operating system: any (debian)
PHP version:  5.3.3RC2
Package:  SPL related
Bug Type: Bug
Bug description:SPL autoloader breaks class_exists()

Description:

Using PHP 5.3 from svn.



When SPL's default autoloader is the only loader in the stack it triggers
an error or throws an exception when it can't find a class.  This means
that you get an exception when calling class_exists() for a class that
doesn't exist.  This behaviour seems pointless anyway since PHP will
trigger its own fatal error if the class still doesn't exist after
attempting to autoload, so the attached patch simply removes it.





Test script:
---
spl_autoload_register();

class_exists('foo\bar');



Expected result:

No error



Actual result:
--
b...@arctor:~/src/php-5.3$ sapi/cli/php ~/code/cram/test.php 

PHP Fatal error:  Uncaught exception 'LogicException' with message 'Class
foo\bar could not be loaded' in /home/ben/code/cram/test.php:4

Stack trace:

#0 [internal function]: spl_autoload('foo\bar')

#1 /home/ben/code/cram/test.php(4): class_exists('foo\bar')

#2 {main}

  thrown in /home/ben/code/cram/test.php on line 4



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

Bug #48610 [Com]: Accessing ssl:// results in immediate "SSL: connection timeout" error

[ben at sixg dot com]

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

 ID:   48610
 Comment by:       ben at sixg dot com
 Reported by:  arkadi at hosting dot lv
 Summary:  Accessing ssl:// results in immediate "SSL: connection
   timeout" error
 Status:   Bogus
 Type: Bug
 Package:  Streams related
 Operating System: Linux
 PHP Version:  5.2.10

 New Comment:

We're seeing this with PHP 5.2.12 on Red Hat 5.4.  (It's a Rackspace
build of PHP 

rather than a Red Hat build, but I'd expect that it was built with RH5's
gcc, so 

probably RH's gcc-4.1.2-46 or so.)



This is not bogus.  Even if it's a GCC bug, if it's present in GCC 4.3,
it's not 

likely to be fixed any time soon on that side.  Can't PHP work around
it?



Arkadi, did you end up patching your xp_ssl.c to work around this, or
did you find 

a version of GCC that doesn't have the bug?


Previous Comments:

[2009-06-25 20:43:02] arkadi at hosting dot lv

It is a GCC -fpmath=sse bug (i486-linux-gnu 4.3.2 [Debian 4.3.2-1.1)]
that miscompiles

timeout -= (tve.tv_sec + (float) tve.tv_usec / 100) -

(tvs.tv_sec+ (float) tvs.tv_usec / 100);

from xp_ssl.c.


[2009-06-19 18:38:37] arkadi at hosting dot lv

Description:

The problem was already reported in bug #47791 but the bug was closed as
Bogus. This is also probably related to bug #45016.

When trying to establish SSL connection the "SSL: connection timeout"
error is raised _immediately_ regardless of timeout specified.

You can try to access the script running on PHP 4.4.9

http://iron.hosting.lv/ssl.php - that produces correct result - an XML
fragment

and PHP 5.2.10

http://iron-php5.hosting.lv/ssl.php

which immediately prints (0).



Stracing the process shows that connection is established and initial
SSL negotiation packet is sent, but then it waits less than a second for
the reply (which is not arriving in such short time), then connection is
closed.



I believe the problem appeared after 5.2.6, and definitely present in
5.2.9.

Reproduce code:
---
\n";

} else {

$out = "GET /PartnerWS/OCTA/PArtner/PremiumCalculator.asmx?WSDL
HTTP/1.1\r\n";

$out .= "Host: polise.if.lv\r\n";

$out .= "Connection: Close\r\n\r\n";

fwrite($fp, $out);

while (!feof($fp)) {

echo fgets($fp, 128);

}

fclose($fp);

}

?>

Expected result:

XML fragment fetched from remote server

Actual result:
--
(0)






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

#49816 [Com]: output corruption using flush

[ben at xnode dot org]

 ID:   49816
 Comment by:   ben at xnode dot org
 Reported By:  paul at wcclan dot net
 Status:   Assigned
 Bug Type: Apache2 related
 Operating System: *
 PHP Version:  5.*
 Assigned To:  johannes
 New Comment:

Still experiencing this issue with PHP 5.3.1 and Apache 2.2.14. Quite
annoying as it means either not being able to use Flush (which isn't an
option for some apps) or not being able to use compression.


Previous Comments:


[2009-11-19 15:59:01] j...@php.net

Unfortunately flush() with apache2handler SAPI will also disable
compression. Like I've said in the commit it's temporary "fix" to at
least keep things working. The real fix requires doing MFH of new output
buffering code where this works fine.

Johannes, please reply, I've asked you several times now whether I can
merge the new and working output buffering code from HEAD (like I
already suggested before 5.3.0 was released!).



[2009-11-18 21:19:12] paul at wcclan dot net

I might be reading this wrong, but aren't you just opting not to
compress with this code? If so, how do you explain that compression
worked fine before 5.2.11? If I am reading it wrong, great job on the
fix :)



[2009-11-15 00:13:20] s...@php.net

Automatic comment from SVN on behalf of jani
Revision: http://svn.php.net/viewvc/?view=revision&revision=290765
Log: - Temporary hack to fix bug #49816 (works fine in HEAD which has
working output buffering..)



[2009-11-14 22:28:40] j...@php.net

Caused by fixing bug #49248 and does not happen with HEAD.



[2009-10-26 13:05:08] j...@php.net

At least you can disable zlib compression in script now.. :/
See bug #49248, fix for that borked the compression on Apache if you
use flush(). 



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

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

#50268 [Asn]: PHP doesn't start: ntwdblib.dll not found

[ben dot arnold dot spam at hotmail dot com]

 ID:   50268
 User updated by:  ben dot arnold dot spam at hotmail dot com
 Reported By:  ben dot arnold dot spam at hotmail dot com
 Status:   Assigned
 Bug Type: Windows Installer
 Operating System: Windows Vista
 PHP Version:  5.3.1
 Assigned To:  pajoye
 New Comment:

Thanks for the speedy response!

I just commented out "extension=php_mssql.dll" and it all works
perfectly now. Apache starts and I have "hello world" up and running.


Previous Comments:


[2009-11-23 09:08:27] paj...@php.net

Do you need the mssql extension? If not simply comment out the mssql
lines in your php.ini.

I'll look into this problem (not sure why it did not install it).

----

[2009-11-23 08:47:13] ben dot arnold dot spam at hotmail dot com

Any suggestions for a workaround would be much appreciated.

As it stands I am not able to install PHP at all!

----

[2009-11-23 08:40:41] ben dot arnold dot spam at hotmail dot com

Description:

I am running Apache 2.2.14. I do not have a database installed.


What I did:

1. Downloaded latest version of PHP (php-5.3.1-Win32-VC6-x86.msi)
2. Ran the installer using default values except:
* Web server: Apache 2.2.x Module
* Apache configuration directory: C:\Program Files\Apache Software
Foundation\Apache2.2\conf\
3. Tried to start Apache.
4. Tried to run PHP by entering "php" in a command window.


What happened:

1. Apache failed to start. A dialogue box says "The requested operation
has failed" and Windows error reporting kicked in. There is no error in
Apache's error.log.
2. When I tried to start php I get an error dialogue box titled
"php.exe - Unable To Locate Component". The text of the box is:

This application has failed to start because ntwdblib.dll was not
found. Re-installing the application may fix this problem.


What I expected to happen:

1. I expected that Apache would start with PHP loaded as a module. I
expected to be able to put a php file in my htdocs directory and that I
could get it to display a Hello World message when I requested it
through Apache.

2. I expected PHP to display usage information when run from the
commandline.


I have tried uninstalling PHP, downloading the installer again and
reinstalling but I have the same problem.

When I uninstall PHP Apache works normally again.

I have Googled this error message and seen various people report that
it is connected to a database misconfiguration. I currently do not have
a database installed and have done nothing to configure one in PHP. All
my configuration steps are listed above.

I am unable to "copy ntwdblib.dll from MSSQL 2000" as suggested in bug
#38849 because I do not have MSSQL installed. In any case that bug looks
like it is related to a different problem (I am not trying to connect to
a database I am just trying to launch PHP).







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

#50268 [Opn]: PHP doesn't start: ntwdblib.dll not found

[ben dot arnold dot spam at hotmail dot com]

 ID:   50268
 User updated by:  ben dot arnold dot spam at hotmail dot com
 Reported By:  ben dot arnold dot spam at hotmail dot com
 Status:   Open
 Bug Type: Windows Installer
 Operating System: Windows Vista
 PHP Version:  5.3.1
 New Comment:

Any suggestions for a workaround would be much appreciated.

As it stands I am not able to install PHP at all!


Previous Comments:


[2009-11-23 08:40:41] ben dot arnold dot spam at hotmail dot com

Description:

I am running Apache 2.2.14. I do not have a database installed.


What I did:

1. Downloaded latest version of PHP (php-5.3.1-Win32-VC6-x86.msi)
2. Ran the installer using default values except:
* Web server: Apache 2.2.x Module
* Apache configuration directory: C:\Program Files\Apache Software
Foundation\Apache2.2\conf\
3. Tried to start Apache.
4. Tried to run PHP by entering "php" in a command window.


What happened:

1. Apache failed to start. A dialogue box says "The requested operation
has failed" and Windows error reporting kicked in. There is no error in
Apache's error.log.
2. When I tried to start php I get an error dialogue box titled
"php.exe - Unable To Locate Component". The text of the box is:

This application has failed to start because ntwdblib.dll was not
found. Re-installing the application may fix this problem.


What I expected to happen:

1. I expected that Apache would start with PHP loaded as a module. I
expected to be able to put a php file in my htdocs directory and that I
could get it to display a Hello World message when I requested it
through Apache.

2. I expected PHP to display usage information when run from the
commandline.


I have tried uninstalling PHP, downloading the installer again and
reinstalling but I have the same problem.

When I uninstall PHP Apache works normally again.

I have Googled this error message and seen various people report that
it is connected to a database misconfiguration. I currently do not have
a database installed and have done nothing to configure one in PHP. All
my configuration steps are listed above.

I am unable to "copy ntwdblib.dll from MSSQL 2000" as suggested in bug
#38849 because I do not have MSSQL installed. In any case that bug looks
like it is related to a different problem (I am not trying to connect to
a database I am just trying to launch PHP).







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

#50268 [NEW]: PHP doesn't start: ntwdblib.dll not found

[ben dot arnold dot spam at hotmail dot com]

From: ben dot arnold dot spam at hotmail dot com
Operating system: Windows Vista
PHP version:  5.3.1
PHP Bug Type: Windows Installer
Bug description:  PHP doesn't start: ntwdblib.dll not found

Description:

I am running Apache 2.2.14. I do not have a database installed.


What I did:

1. Downloaded latest version of PHP (php-5.3.1-Win32-VC6-x86.msi)
2. Ran the installer using default values except:
* Web server: Apache 2.2.x Module
* Apache configuration directory: C:\Program Files\Apache Software
Foundation\Apache2.2\conf\
3. Tried to start Apache.
4. Tried to run PHP by entering "php" in a command window.


What happened:

1. Apache failed to start. A dialogue box says "The requested operation
has failed" and Windows error reporting kicked in. There is no error in
Apache's error.log.
2. When I tried to start php I get an error dialogue box titled "php.exe -
Unable To Locate Component". The text of the box is:

This application has failed to start because ntwdblib.dll was not found.
Re-installing the application may fix this problem.


What I expected to happen:

1. I expected that Apache would start with PHP loaded as a module. I
expected to be able to put a php file in my htdocs directory and that I
could get it to display a Hello World message when I requested it through
Apache.

2. I expected PHP to display usage information when run from the
commandline.


I have tried uninstalling PHP, downloading the installer again and
reinstalling but I have the same problem.

When I uninstall PHP Apache works normally again.

I have Googled this error message and seen various people report that it
is connected to a database misconfiguration. I currently do not have a
database installed and have done nothing to configure one in PHP. All my
configuration steps are listed above.

I am unable to "copy ntwdblib.dll from MSSQL 2000" as suggested in bug
#38849 because I do not have MSSQL installed. In any case that bug looks
like it is related to a different problem (I am not trying to connect to a
database I am just trying to launch PHP).



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

#50112 [Asn]: compile error with Non-Engish Operating system

[ben dot yan at msn dot com]

 ID:   50112
 User updated by:  ben dot yan at msn dot com
 Reported By:  ben dot yan at msn dot com
 Status:   Assigned
 Bug Type: Compile Failure
 Operating System: Windows
 PHP Version:  5.3.0
 Assigned To:  pajoye
 New Comment:

First Sorry for the bug title. 

The VC++ and OS are English edition. But the "Regional and Language
Options" are as follows:
[Standards and formats]: Chinese (PRC)
[Location]: China
[Language for non-Unicode programs]: Chinese (PRC)


Previous Comments:


[2009-11-07 12:22:39] paj...@php.net

I can't test what's wrong but I don't see either why this language
setting could affect anything. I have to setup a VM with Chinese to
reproduce this problem (works just fine with Russian, German, French or
Spanish).

----

[2009-11-07 10:48:58] ben dot yan at msn dot com

Description:

ext\standard\browscap.c : warning C4819: The file contains a character
that cannot be represented in the current code page (936). Save the file
in Unicode format to prevent data loss
ext\standard\browscap.c(61) : error C2001: newline in constant
ext\standard\browscap.c(62) : warning C4305: '=' : truncation from
'int' to 'char'
ext\standard\browscap.c(62) : error C2146: syntax error : missing ';'
before identifier 't'
ext\standard\browscap.c(89) : error C2001: newline in constant
ext\standard\browscap.c(90) : error C2146: syntax error : missing ':'
before identifier 't'
ext\standard\browscap.c(91) : error C2001: newline in constant
ext\standard\browscap.c(92) : warning C4305: '=' : truncation from
'int' to 'char'
ext\standard\browscap.c(92) : error C2143: syntax error : missing ';'
before 'break'
ext\standard\browscap.c(100) : error C2001: newline in constant
ext\standard\browscap.c(102) : warning C4305: '=' : truncation from
'int' to 'char'
ext\standard\browscap.c(102) : error C2146: syntax error : missing ';'
before identifier 't'
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
9.0\VC\Bin\cl.exe"' : return code '0x2'
Stop.

Reproduce code:
---
setting: 
[Control Panel]->[Regional and Language Options]->[Advanced]->[Language
for non-Unicode programs] 

if ($select == "English (United States)") {
// compile successfully. :)
} else if ($select == "Chinese (PRC)"){
// compile error! :(
}

OS: Windows XP Home
IDE: VC++ 2008 Express + SDK v6.1
PHP: 5.3.0

Expected result:

compile successfully

Actual result:
--
compile error





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

#50112 [NEW]: compile error with Non-Engish Operating system

[ben dot yan at msn dot com]

From: ben dot yan at msn dot com
Operating system: Windows
PHP version:  5.3.0
PHP Bug Type: Compile Failure
Bug description:  compile error with Non-Engish Operating system

Description:

ext\standard\browscap.c : warning C4819: The file contains a character
that cannot be represented in the current code page (936). Save the file in
Unicode format to prevent data loss
ext\standard\browscap.c(61) : error C2001: newline in constant
ext\standard\browscap.c(62) : warning C4305: '=' : truncation from 'int'
to 'char'
ext\standard\browscap.c(62) : error C2146: syntax error : missing ';'
before identifier 't'
ext\standard\browscap.c(89) : error C2001: newline in constant
ext\standard\browscap.c(90) : error C2146: syntax error : missing ':'
before identifier 't'
ext\standard\browscap.c(91) : error C2001: newline in constant
ext\standard\browscap.c(92) : warning C4305: '=' : truncation from 'int'
to 'char'
ext\standard\browscap.c(92) : error C2143: syntax error : missing ';'
before 'break'
ext\standard\browscap.c(100) : error C2001: newline in constant
ext\standard\browscap.c(102) : warning C4305: '=' : truncation from 'int'
to 'char'
ext\standard\browscap.c(102) : error C2146: syntax error : missing ';'
before identifier 't'
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
9.0\VC\Bin\cl.exe"' : return code '0x2'
Stop.

Reproduce code:
---
setting: 
[Control Panel]->[Regional and Language Options]->[Advanced]->[Language
for non-Unicode programs] 

if ($select == "English (United States)") {
// compile successfully. :)
} else if ($select == "Chinese (PRC)"){
// compile error! :(
}

OS: Windows XP Home
IDE: VC++ 2008 Express + SDK v6.1
PHP: 5.3.0

Expected result:

compile successfully

Actual result:
--
compile error

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

#49985 [Com]: pdo_pgsql prepare() re-use previous aborted transaction

[ben dot pineau at gmail dot com]

 ID:   49985
 Comment by:   ben dot pineau at gmail dot com
 Reported By:  ben dot pineau at gmail dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: Linux
 PHP Version:  5.2.11
 New Comment:

About the difference when running prepare+execute in a separate
function: we just get the same stmt pointer address in this case
(vs. a different pointer address when running everything in the 
same context). Thus stmt_name remains identical among successive
calls, stmt_name being just set as
spprintf(&S->stmt_name, 0, "pdo_pgsql_stmt_%08x", (unsigned int)stmt);
This explains why prepare() fails in the first case and succeed
in the other.

Anyway, here is a patch (against PHP_5_2 svn branch's head as of now) 
using savepoints around PQprepare attempts so we DEALLOCATE + retry 
without silently killing the current transaction, if/when the first 
prepare fails with code 42P05. 

Savepoints support started with pg 8.0 and I didn't ifdefed/autoconf
checked for this (will do if you ask); the patch will probably be
mangled by the bugrackers autowrapping (if so, please find a copy
at http://zouh.org/ben/various/pgsql_statement.c.diff ).

Index: pgsql_statement.c
===
--- pgsql_statement.c   (revision 289910)
+++ pgsql_statement.c   (working copy)
@@ -134,6 +134,14 @@
/* using a prepared statement */

if (!S->is_prepared) {
+   /* don't break the whole current transaction
when the first
+* prepare tentative fails (happens when the
prepared statement
+* already exists). ignore those SAVEPOINT
queries results because 
+* we don't care (may be outside
transaction?).
+*/
+   char buf[100]; /* stmt_name ==
"pdo_pgsql_cursor_%08x" */
+   snprintf(buf, sizeof(buf), "SAVEPOINT %s",
S->stmt_name);
+   PQexec(H->server, buf);
 stmt_retry:
/* we deferred the prepare until now, because
we didn't
 * know anything about the parameter types; now
we do */
@@ -153,12 +161,14 @@
/* 42P05 means that the
prepared statement already existed. this can happen if you use
 * a connection pooling
software line pgpool which doesn't close the db-connection once
 * php disconnects. if php dies
(no chance to run RSHUTDOWN) during execution it has no
-* chance to DEALLOCATE the
prepared statements it has created. so, if we hit a 42P05 we 
-* deallocate it and retry ONCE
(thies 2005.12.15)
+* chance to DEALLOCATE the
prepared statements it has created. Also happens if we tried
+* to DEALLOCATE the same
statement name in an aborted transaction. so, if we hit a 42P05
+* we deallocate it and retry
ONCE (thies 2005.12.15)
 */
if (!strcmp(sqlstate, "42P05"))
{
-   char buf[100]; /*
stmt_name == "pdo_pgsql_cursor_%08x" */
PGresult *res;
+   snprintf(buf,
sizeof(buf), "ROLLBACK TO SAVEPOINT %s", S->stmt_name);
+   PQexec(H->server,
buf);
snprintf(buf,
sizeof(buf), "DEALLOCATE %s", S->stmt_name);
res = PQexec(H->server,
buf);
if (res) {
@@ -166,11 +176,15 @@
}
goto stmt_retry;
} else {
+   snprintf(buf,
sizeof(buf), "RELEASE SAVEPOINT %s", S->stmt_name);
+   PQexec(H->server,
buf);
   
pdo_pgsql_error_stmt(stmt, status, sqlstate);
return 0;
}
}
}
+   snprintf(buf, sizeof(buf), "RELEASE SAVEPOINT
%s", S->stmt_name);
+   PQexec(H->server, buf);
}
S->result = PQexecPrepared(H->server, S->stmt_name,
    stmt->boun

#49985 [Com]: pdo_pgsql prepare() re-use previous aborted transaction

[ben dot pineau at gmail dot com]

 ID:   49985
 Comment by:   ben dot pineau at gmail dot com
 Reported By:  ben dot pineau at gmail dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: Linux
 PHP Version:  5.2.11
 New Comment:

Look at the PostgreSQL logs above (running the provided test case
with log_statement='all' and log_min_messages='INFO'), keeping
in mind that:
- PostgreSQL automatically abort transactions when something fails.
- PostgreSQL does maintains prepared statements outside transaction
  context. Prepared statements survive a rollback/abort, and last
  for the duration of the current database session.
- It seems that when executed in another function/context than 
  PDO::beginTransaction, PDO tries to DEALLOCATE right after the
  first transaction failure (vs. after the next BEGIN statement
  when in same context).

Therefore we have the following flow:

BEGIN;
  -- PDO successfully prepare the statement
  PREPARE prep_statement_1 AS ...;

  -- We execute a bogus statement that cause pg to automatically
  -- abort the current transaction. PDO raise a proper exception
  EXECUTE prep_statement_1;

  -- This fails because we're in aborted transaction;
  -- The prepared statement is thus left allocated.
  DEALLOCATE prep_statement_1;
ROLLBACK;

-- And then we loop with
BEGIN;
  -- This prep statement already exists (PDO failed to clean it)
  -- so this fails and pg automatically abort this new transaction.
  PREPARE prep_statement_1 AS ...;

  -- Given the above failure, PDO tries again to clean up the
  -- prepared stmt which will fail again.
  -- Hence PDO raising a "current transaction is aborted" exception.
  DEALLOCATE prep_statement_1;
ROLLBACK;


Surprisingly, when we call prepare() inline like this:
try {
$cnx->beginTransaction();
$stmt = $cnx->prepare($sql);
$stmt->execute();

instead of that :

function qexec(&$pdo, $sql) {
$stmt = $pdo->prepare($sql);
$stmt->execute();
}
try {
$cnx->beginTransaction();
qexec($cnx, $sql);

we do get a different (and preferable) behaviour:
BEGIN -> PREPARE -> EXECUTE -> ROLLBACK
  -> BEGIN -> DEALLOCATE -> PREPARE -> EXECUTE -> ROLLBACK
  -> BEGIN -> DEALLOCATE -> PREPARE -> EXECUTE -> ROLLBACK -> ...

vs.
BEGIN -> PREPARE -> EXECUTE -> DEALLOCATE -> ROLLBACK
  -> BEGIN -> PREPARE (-> EXECUTE) -> DEALLOCATE -> ROLLBACK
  -> BEGIN -> PREPARE (-> EXECUTE) -> DEALLOCATE -> ROLLBACK -> ...


Granted, preparing the same exact statement in loop (rather than
once then using varying parameters) is dumb, but...

PostgreSQL logs from the provided test case:
Oct 24 15:29:15 dev postgres[26864]: [5-1] LOG:  statement: BEGIN
Oct 24 15:29:15 dev postgres[26864]: [6-1] LOG:  execute
pdo_pgsql_stmt_01ef7698: INSERT INTO test (a) VALUES (1)
Oct 24 15:29:15 dev postgres[26864]: [7-1] ERROR:  duplicate key value
violates unique constraint "test_pkey"
Oct 24 15:29:15 dev postgres[26864]: [7-2] STATEMENT:  INSERT INTO test
(a) VALUES (1)
Oct 24 15:29:15 dev postgres[26864]: [8-1] LOG:  statement: DEALLOCATE
pdo_pgsql_stmt_01ef7698
Oct 24 15:29:15 dev postgres[26864]: [9-1] ERROR:  current transaction
is aborted, commands ignored until end of transaction block
Oct 24 15:29:15 dev postgres[26864]: [9-2] STATEMENT:  DEALLOCATE
pdo_pgsql_stmt_01ef7698
Oct 24 15:29:15 dev postgres[26864]: [10-1] LOG:  statement: ROLLBACK
Oct 24 15:29:15 dev postgres[26864]: [11-1] LOG:  statement: BEGIN
Oct 24 15:29:15 dev postgres[26864]: [12-1] ERROR:  prepared statement
"pdo_pgsql_stmt_01ef7698" already exists
Oct 24 15:29:15 dev postgres[26864]: [12-2] STATEMENT:  INSERT INTO
test (a) VALUES (1)
Oct 24 15:29:15 dev postgres[26864]: [13-1] LOG:  statement: DEALLOCATE
pdo_pgsql_stmt_01ef7698
Oct 24 15:29:15 dev postgres[26864]: [14-1] ERROR:  current transaction
is aborted, commands ignored until end of transaction block
Oct 24 15:29:15 dev postgres[26864]: [14-2] STATEMENT:  DEALLOCATE
pdo_pgsql_stmt_01ef7698
Oct 24 15:29:15 dev postgres[26864]: [15-1] ERROR:  current transaction
is aborted, commands ignored until end of transaction block
Oct 24 15:29:15 dev postgres[26864]: [15-2] STATEMENT:  INSERT INTO
test (a) VALUES (1)
Oct 24 15:29:15 dev postgres[26864]: [16-1] LOG:  statement: ROLLBACK
Oct 24 15:29:15 dev postgres[26864]: [17-1] LOG:  statement: BEGIN
Oct 24 15:29:15 dev postgres[26864]: [18-1] ERROR:  prepared statement
"pdo_pgsql_stmt_01ef7698" already exists
Oct 24 15:29:15 dev postgres[26864]: [18-2] STATEMENT:  INSERT INTO
test (a) VALUES (1)
Oct 24 15:29:15 dev postgres[26864]: [19-1] LOG:  statement: DEALLOCATE
pdo_pgsql_stmt_01ef7698
Oct 24 15:29:15 dev postgres[26864]: [20-1] ERROR:  current transaction
is aborted, commands ignored until end of transaction block
Oct 24 15:29:15 dev postgres[26864]: [20-2] STAT

#49985 [NEW]: pdo_pgsql prepare() re-use previous aborted transaction

[ben dot pineau at gmail dot com]

From: ben dot pineau at gmail dot com
Operating system: Linux
PHP version:  5.2.11
PHP Bug Type: PDO related
Bug description:  pdo_pgsql prepare() re-use previous aborted transaction

Description:

When prepar()ing a statement in a separate function, pdo_pgsql behaves as
if we hadn't rollbacked and started a new transaction.

But no such problem when either :
- we use another pdo driver (tested with sqlite)
- prepare() call is inlined in the same code block as beginTransaction
(rather than in a distinct function)
- the function contains a straigth "query()" instead of prepare() +
execute()

Reproduced with both php-5.2.6 and php-5.2.11, PostgreSQL 8.3.8.


Reproduce code:
---
/*
 * CREATE TABLE test (a SERIAL PRIMARY KEY);
 * INSERT INTO test VALUES (1);
 */

$cnx = new PDO('pgsql:dbname=testbase;host=localhost', 'postgres','');
$cnx->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

$sql = "INSERT INTO test (a) VALUES (1)";

function prepare_and_exec_query(&$pdo, $sql)
{
$stmt = $pdo->prepare($sql);
$stmt->execute();
}

for ($i = 0; $i < 3; $i++) {
try {
$cnx->beginTransaction();
prepare_and_exec_query($cnx, $sql);
$cnx->commit();
} catch (Exception $e) {
echo "Error: " . $e->getMessage() . "\n";
if (true === $cnx->rollback()) echo "rollbacked ok\n";
}
}


Expected result:

Error: SQLSTATE[23505]: Unique violation: 7 ERROR:  duplicate key value
violates unique constraint "test_pkey"
rollbacked ok
Error: SQLSTATE[23505]: Unique violation: 7 ERROR:  duplicate key value
violates unique constraint "test_pkey"
rollbacked ok
Error: SQLSTATE[23505]: Unique violation: 7 ERROR:  duplicate key value
violates unique constraint "test_pkey"
rollbacked ok

Actual result:
--
Error: SQLSTATE[23505]: Unique violation: 7 ERROR:  duplicate key value
violates unique constraint "test_pkey"
rollbacked ok
Error: SQLSTATE[25P02]: In failed sql transaction: 7 ERROR:  current
transaction is aborted, commands ignored until end of transaction block
rollbacked ok
Error: SQLSTATE[25P02]: In failed sql transaction: 7 ERROR:  current
transaction is aborted, commands ignored until end of transaction block
rollbacked ok

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

#49616 [Opn->Csd]: Impossible to increase SOMAXCONN

[ben at realitychecknetwork dot com]

 ID:   49616
 User updated by:  ben at realitychecknetwork dot com
 Reported By:  ben at realitychecknetwork dot com
-Status:   Open
+Status:   Closed
 Bug Type: Feature/Change Request
 Operating System: Linux 2.6.18
 PHP Version:  5.2.11
 New Comment:

In CentOS5.3 its actually : /usr/include/linux/socket.h

Thanks, that did the trick.

Replace:

/* Maximum queue length specifiable by listen.  */
#define SOMAXCONN   128

With:

/* Maximum queue length specifiable by listen.  */
#define SOMAXCONN   2048

Then recompile PHP


Previous Comments:


[2009-09-22 09:38:30] sjo...@php.net

PHP uses the SOMAXCONN from sys/socket.h at compile time.



[2009-09-21 20:22:24] ben at realitychecknetwork dot com

Description:

Impossible to increase SOMAXCONN value by updating system OS variable.
PHP must be compiled with --enable-sockets for this bug to be produced.

OS setting updated with:

# sysctl -w net.core.somaxconn=2048
net.core.somaxconn = 2048

PHP will always return 128 for SOMAXCONN and will not respect the OS
setting. Additionally, it will ignore a define statement in PHP code and
return 128 as well.

Reproduce code:
---
define("SOMAXCONN", 2048);
echo SOMAXCONN;


Expected result:

Should return 2048

Actual result:
--
Returns 128





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

#49616 [NEW]: Impossible to increase SOMAXCONN

[ben at realitychecknetwork dot com]

From: ben at realitychecknetwork dot com
Operating system: Linux 2.6.18
PHP version:  5.2.11
PHP Bug Type: Sockets related
Bug description:  Impossible to increase SOMAXCONN

Description:

Impossible to increase SOMAXCONN value by updating system OS variable. PHP
must be compiled with --enable-sockets for this bug to be produced.

OS setting updated with:

# sysctl -w net.core.somaxconn=2048
net.core.somaxconn = 2048

PHP will always return 128 for SOMAXCONN and will not respect the OS
setting. Additionally, it will ignore a define statement in PHP code and
return 128 as well.

Reproduce code:
---
define("SOMAXCONN", 2048);
echo SOMAXCONN;


Expected result:

Should return 2048

Actual result:
--
Returns 128

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

#48874 [NEW]: Sample php.ini misleading include reference to php_zip.dll

[ben at imperialwebdesigns dot com]

From: ben at imperialwebdesigns dot com
Operating system: Windows 2003 Server
PHP version:  5.3.0
PHP Bug Type: Zip Related
Bug description:  Sample php.ini misleading include reference to php_zip.dll

Description:

The sample INI files distributed with PHP 5.3.0 for windows references
php_zip.dll in the extensions section.  This extension appears to be
compiled into the core so this line is misleading.

Specifically the line is:
;extension=php_zip.dll


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

#35793 [Com]: General error: 2050

[ben at ecoland dot com dot au]

 ID:   35793
 Comment by:   ben at ecoland dot com dot au
 Reported By:  deadman_great at mail dot ru
 Status:   No Feedback
 Bug Type: PDO related
 Operating System: RH Fedora Core 2
 PHP Version:  5CVS-2005-12-25 (snap)
 Assigned To:  Wez
 New Comment:

This needs to be fixed - C'mon guys.

I'm using PHP under CentOS 5.0 and shocked it exists


Previous Comments:


[2009-04-29 17:15:02] brice dot laurencin at gmail dot com

I ran against the very bug just now. I lost half a day with a bug
referenced 3 years and a half ago. Nice.
And more, just a simple affectation ain't possible? What?!?

I hate PHP more and more every day.

/rant OFF

The bug didn't occurred on Ubuntu Jaunty (PHP 5.2.6), it smashed me on
the Red Hat 4.1.1-52 (PHP 5.1.6) production server.



[2009-03-26 15:00:18] maxlemans at free dot fr

The problem seems to be still unsolved. I reproduced it today when
using the statement variable twice or more for different queries

Code :

// Request writting
$strSQL = " 
SELECT  id
FROMmybase.mytable
";

// Request running 
$objStatement = $oPDO->query($strSQL);

// Results browsing
while ($arrRow = $objStatement->fetch(PDO::FETCH_NUM))
{
array_push($arrData, $arrRow[0]);
}

// Cursor closing
$objStatement->closeCursor();


// Request writting
$strSQL = " 
SELECT  id
FROMmybase.myOTHERtable
";

// Request running 
$objStatement = $oPDO->query($strSQL);

// Results browsing
while ($arrRow = $objStatement->fetch(PDO::FETCH_NUM))
{
array_push($arrData, $arrRow[0]);
}

// Cursor closing
$objStatement->closeCursor();


To solve this problem I use the following after
$objStatement->closeCursor() :

unset($objStatement);

As $objStatement is affected an new PDOStatement instance, I think it
would be nice if PHP could remove the previous PDOStatement instance as
it is no longer usable.



[2008-10-30 05:35:13] post-christian at freenet dot de

I think we need to rethink about how mysql works. If you don't use
mysql_stmt_store_result(), which make sense when loading long data,
mysql seems to allow only one active statement per connection. puhh.
hard to believe but could be true. I'm having the same problem with a
mysql driver for perl.



[2008-10-21 06:20:08] vishalraj82 at gmail dot com

I guess this is a problem with pdo.
When you connect to localhost using pdo, fire a query and store the
result in variable, the variable needs to be reset before it can be
reused, given that mysql resids on a remote server and not on
localhost.

$conn = new PDO("localhost"
$sql1 = "SELECT * from TEST";
$res = $conn->query($sql1);
...
...


$sql2 = "SELECT * from MYTAB";
$res = $conn->query($sql2); // In this line you will get mysql general
error if $res has not been reset before being used again



[2008-08-19 16:06:01] baptiste dot place at utopiaweb dot fr

Got the same error with second statement of a function.
Worked fine on winXP xampp, PHP 5.2.6, MySql 5.0.51b.

Deployed on a debian server with PHP 5.2.0-8 and MySQL 5.0.32, the code
threw this error.

Made it work with michal vrchota's solution, thanks a lot.



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

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

#48548 [Com]: file_exists() returns false on paths using ../ in middle

[ben at nurfuerspam dot de]

 ID:   48548
 Comment by:   ben at nurfuerspam dot de
 Reported By:  adam at e-nition dot com
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Linux
 PHP Version:  5.2.9
 New Comment:

This is actually not a bug, as the path cannot be traversed on a
filesystem either.
Just try it in any *nix shell for yourself:
When you call "cd fake_dir/../" you'd expect to cut off the fakepath
and stay in the same directory, but you'll get a "No such file or
directory" error instead as there is no fake_dir that could be resolved.


Previous Comments:


[2009-06-14 16:23:50] adam at e-nition dot com

Description:

The file_exists() function returns false on files that do exist but use
a directory traversal in the path. Not at the start of the path, I mean
in the middle of the path. (This type of path works fine on the include
function)

Works fine on windows apache2.2.11 php5.2.9



Reproduce code:
---
(Example based on a file called 'real_file.php' being placed in a
directory called 'real_dir')

$test_path = 'real_dir/fake_dir/../real_file.php',

if (file_exists($test_path)) {
echo 'File does exist';
echo (@include($test_path)) ? 'File included' : 'File NOT
included';
} else {
echo 'File does Not exist';
echo (@include($test_path)) ? 'File included' : 'File NOT
included';
}

Expected result:

File does exist
File included

Actual result:
--
File does NOT exist
File included





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

#45245 [Com]: IIS Worker process closes upon login

[ben at hobbesnet dot net]

 ID:   45245
 Comment by:   ben at hobbesnet dot net
 Reported By:  alexdykes at gmail dot com
 Status:   No Feedback
 Bug Type: IIS related
 Operating System: Windows Home Server (Server 2k3)
 PHP Version:  5.2.6
 New Comment:

Also experiencing this, using PHP 5.2.9.
The script I'm [attempting to] work with is phpMyAdmin.

I will try and generate a backtrace, and post it here.


Previous Comments:


[2008-08-22 01:00:00] php-bugs at lists dot php dot net

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



[2008-08-14 18:00:48] j...@php.net

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

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





[2008-06-12 12:50:03] alexdykes at gmail dot com

Actually running 5.2.5 still generates the crash every other login or
so, however it only needs to be dismissed once as opposed to the 3-4
times on 5.2.6.



[2008-06-12 11:04:33] alexdykes at gmail dot com

Description:

When using Windows Home Server, PHP 5.2.6 crashes the IIS Worker
Process, with exactly the same error in the event manager as shown in
this bug: 38111

Windows Home Server is based on Server 2003 SP2 SBS and runs IIS6.  I
installed 5.2.5 and the problem went away.  The install was a manual
install from the zip files in both cases.  Even though 5.2.6 would
produce crashes it would continue to function.






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

#48460 [Opn]: Referencing an object property causes behaviour change after clone

[ben at last dot fm]

 ID:   48460
 User updated by:  ben at last dot fm
 Reported By:  ben at last dot fm
 Status:   Open
 Bug Type: Variables related
 Operating System: Linux
 PHP Version:  5.2.9
 New Comment:

Hmm.

The bug is that you can alter the behaviour of clone (that is, force
$d-
>list to be copied-by-reference instead of copied-by-value) merely by 
creating any other reference to $a->list. 'clone' is, therefore, the 
only language construct (that I know of) which is capable of this, and

is NOT the same as "$b = new A; $b->list = $a->list". 

There is in fact no way to tell whether a property is a reference or
not 
without cloning the entire object and seeing what happens when you 
change the clone's property; or by forcibly unsetting and resetting the

property.


Previous Comments:


[2009-06-03 13:54:41] col...@php.net

This is quite expected, that's basically the same as:

$a = array(2);
$d = &$a[0];

$a_copy = $a;
$a_copy[0]++;

echo $a[0],$d; // 3 3

You can do a deep copy using the __clone hook.

OTOH I'm not sure if clone shouldn't separate the properties directly,
instead of simply assigning them.



----

[2009-06-03 13:34:44] ben at last dot fm

Sorry, put this in the wrong category.

----

[2009-06-03 13:32:35] ben at last dot fm

More minimal test case:

list = 1;

$b = clone $a;
$link =& $a->p;
unset($link);
$c = clone $a;
$link =& $a->p;
$d = clone $a;
unset($link);
$e = clone $a;

$b->p = 2;
$c->p = 3;
$d->p = 4;
$e->p = 5;

echo "$a->p\n$b->p\n$c->p\n$d->p\n$e->p\n";



[2009-06-03 13:29:02] ben at last dot fm

Description:

If you create a reference to a property of an object, then clone 
the object, the reference will become bi-directional and the property 
will no longer behave like a property.

This does not happen if you create, then destroy, the reference BEFORE

cloning. 

This persists even if you unset the reference AFTER cloning.

Reproduce code:
---
list = array( 1, 1, 1, 1, 1 );

$b = clone $a;
$link =& $a->list;
unset($link);
$c = clone $a;
$link =& $a->list;
$d = clone $a;
unset($link);
$e = clone $a;

$b->list = array(2,2,2,2,2);
$c->list = array(3,3,3,3,3);
$d->list = array(4,4,4,4,4);
$e->list = array(5,5,5,5,5);

echo "$a\n$b\n$c\n$d\n$e\n";

Expected result:

{1}
{2}
{3}
{4}
{5}

Actual result:
--
{5}
{2}
{3}
{5}
{5}





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

#48460 [Opn]: Referencing an object property causes behaviour change after clone

[ben at last dot fm]

 ID:   48460
 User updated by:  ben at last dot fm
 Reported By:  ben at last dot fm
 Status:   Open
-Bug Type: Arrays related
+Bug Type: Variables related
 Operating System: Linux
 PHP Version:  5.2.9
 New Comment:

Sorry, put this in the wrong category.


Previous Comments:


[2009-06-03 13:32:35] ben at last dot fm

More minimal test case:

list = 1;

$b = clone $a;
$link =& $a->p;
unset($link);
$c = clone $a;
$link =& $a->p;
$d = clone $a;
unset($link);
$e = clone $a;

$b->p = 2;
$c->p = 3;
$d->p = 4;
$e->p = 5;

echo "$a->p\n$b->p\n$c->p\n$d->p\n$e->p\n";

----

[2009-06-03 13:29:02] ben at last dot fm

Description:

If you create a reference to a property of an object, then clone 
the object, the reference will become bi-directional and the property 
will no longer behave like a property.

This does not happen if you create, then destroy, the reference BEFORE

cloning. 

This persists even if you unset the reference AFTER cloning.

Reproduce code:
---
list = array( 1, 1, 1, 1, 1 );

$b = clone $a;
$link =& $a->list;
unset($link);
$c = clone $a;
$link =& $a->list;
$d = clone $a;
unset($link);
$e = clone $a;

$b->list = array(2,2,2,2,2);
$c->list = array(3,3,3,3,3);
$d->list = array(4,4,4,4,4);
$e->list = array(5,5,5,5,5);

echo "$a\n$b\n$c\n$d\n$e\n";

Expected result:

{1}
{2}
{3}
{4}
{5}

Actual result:
--
{5}
{2}
{3}
{5}
{5}





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

#48460 [Opn]: Referencing an object property causes behaviour change after clone

[ben at last dot fm]

 ID:   48460
 User updated by:  ben at last dot fm
 Reported By:  ben at last dot fm
 Status:   Open
 Bug Type: Arrays related
 Operating System: Linux
 PHP Version:  5.2.9
 New Comment:

More minimal test case:

list = 1;

$b = clone $a;
$link =& $a->p;
unset($link);
$c = clone $a;
$link =& $a->p;
$d = clone $a;
unset($link);
$e = clone $a;

$b->p = 2;
$c->p = 3;
$d->p = 4;
$e->p = 5;

echo "$a->p\n$b->p\n$c->p\n$d->p\n$e->p\n";


Previous Comments:
----

[2009-06-03 13:29:02] ben at last dot fm

Description:

If you create a reference to a property of an object, then clone 
the object, the reference will become bi-directional and the property 
will no longer behave like a property.

This does not happen if you create, then destroy, the reference BEFORE

cloning. 

This persists even if you unset the reference AFTER cloning.

Reproduce code:
---
list = array( 1, 1, 1, 1, 1 );

$b = clone $a;
$link =& $a->list;
unset($link);
$c = clone $a;
$link =& $a->list;
$d = clone $a;
unset($link);
$e = clone $a;

$b->list = array(2,2,2,2,2);
$c->list = array(3,3,3,3,3);
$d->list = array(4,4,4,4,4);
$e->list = array(5,5,5,5,5);

echo "$a\n$b\n$c\n$d\n$e\n";

Expected result:

{1}
{2}
{3}
{4}
{5}

Actual result:
--
{5}
{2}
{3}
{5}
{5}





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

#48460 [NEW]: Referencing an object property causes behaviour change after clone

[ben at last dot fm]

From: ben at last dot fm
Operating system: Linux
PHP version:  5.2.9
PHP Bug Type: Arrays related
Bug description:  Referencing an object property causes behaviour change after 
clone

Description:

If you create a reference to a property of an object, then clone 
the object, the reference will become bi-directional and the property 
will no longer behave like a property.

This does not happen if you create, then destroy, the reference BEFORE 
cloning. 

This persists even if you unset the reference AFTER cloning.

Reproduce code:
---
list = array( 1, 1, 1, 1, 1 );

$b = clone $a;
$link =& $a->list;
unset($link);
$c = clone $a;
$link =& $a->list;
$d = clone $a;
unset($link);
$e = clone $a;

$b->list = array(2,2,2,2,2);
$c->list = array(3,3,3,3,3);
$d->list = array(4,4,4,4,4);
$e->list = array(5,5,5,5,5);

echo "$a\n$b\n$c\n$d\n$e\n";

Expected result:

{1}
{2}
{3}
{4}
{5}

Actual result:
--
{5}
{2}
{3}
{5}
{5}

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

#47459 [Fbk->Csd]: blank page: due to having function in PHP page

[ben dot keen at gmail dot com]

 ID:   47459
 User updated by:  ben dot keen at gmail dot com
 Reported By:  ben dot keen at gmail dot com
-Status:   Feedback
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: Linux
 PHP Version:  5.2.8
 New Comment:

Closed.


Previous Comments:


[2009-02-20 21:21:11] ben dot keen at gmail dot com

Apologies, I don't think that is a bug. There's something wonky going
on on the server. Now even this isn't working:





[2009-02-20 13:16:59] j...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.





[2009-02-20 07:11:28] ben dot keen at gmail dot com

Description:

This was actually found on 5.2.8, the current main PHP release (not
sure why it's not listed in the PHP version dropdown on the bug report
page... ??)

The problem is this: I'm importing a number of PHP files with
require_once() into a main page but I get a blank page. I debugged it
down to two lines of code in one of the files file that is being
included. These two lines are inside a function that is NOT called,
however.

  if (!$something)
ft_handle_error("one" . "two" . "three", mysql_error());

When I comment these two lines out, the page loads fine. No errors,
notifications or warnings are displayed. When I remove one (any) of the
strings being concatenated in the first function parameter, the page
loads fine. In other words, when I change the lines to any of these, the
page loads fine:

  if (!$something)
ft_handle_error("two" . "three", mysql_error());

As does:

  if (!$something)
ft_handle_error("one" . "three", mysql_error());

As does:

  if (!$something)
ft_handle_error("one" . "two", mysql_error());

Two final things to mention: when I remove the second mysql_error()
parameter but keep all three strings being concatenated in the first
parameter, the page loads. Also, when I remove the if (!$something)
condition and keep all three strings being concatenated again, it also
works fine. The actual strings being concatenated don't seem to make any
difference.

I'm well beyond confused. Debugging tips?

Reproduce code:
---
  if (!$something)
ft_handle_error("one" . "two" . "three", mysql_error());


Expected result:

The page should load for ANY of the lines of PHP code mentioned.






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

#47459 [Com]: blank page: due to having function in PHP page

[ben dot keen at gmail dot com]

 ID:   47459
 Comment by:   ben dot keen at gmail dot com
 Reported By:  ben dot keen at gmail dot com
 Status:   Feedback
 Bug Type: Reproducible crash
 Operating System: Linux
 PHP Version:  5.2.8
 New Comment:

Apologies, I don't think that is a bug. There's something wonky going
on on the server. Now even this isn't working:




Previous Comments:


[2009-02-20 13:16:59] j...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.





[2009-02-20 07:11:28] ben dot keen at gmail dot com

Description:

This was actually found on 5.2.8, the current main PHP release (not
sure why it's not listed in the PHP version dropdown on the bug report
page... ??)

The problem is this: I'm importing a number of PHP files with
require_once() into a main page but I get a blank page. I debugged it
down to two lines of code in one of the files file that is being
included. These two lines are inside a function that is NOT called,
however.

  if (!$something)
ft_handle_error("one" . "two" . "three", mysql_error());

When I comment these two lines out, the page loads fine. No errors,
notifications or warnings are displayed. When I remove one (any) of the
strings being concatenated in the first function parameter, the page
loads fine. In other words, when I change the lines to any of these, the
page loads fine:

  if (!$something)
ft_handle_error("two" . "three", mysql_error());

As does:

  if (!$something)
ft_handle_error("one" . "three", mysql_error());

As does:

  if (!$something)
ft_handle_error("one" . "two", mysql_error());

Two final things to mention: when I remove the second mysql_error()
parameter but keep all three strings being concatenated in the first
parameter, the page loads. Also, when I remove the if (!$something)
condition and keep all three strings being concatenated again, it also
works fine. The actual strings being concatenated don't seem to make any
difference.

I'm well beyond confused. Debugging tips?

Reproduce code:
---
  if (!$something)
ft_handle_error("one" . "two" . "three", mysql_error());


Expected result:

The page should load for ANY of the lines of PHP code mentioned.






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

#47459 [NEW]: blank page: due to having function in PHP page

[ben dot keen at gmail dot com]

From: ben dot keen at gmail dot com
Operating system: Linux
PHP version:  5.3.0beta1
PHP Bug Type: Reproducible crash
Bug description:  blank page: due to having function in PHP page

Description:

This was actually found on 5.2.8, the current main PHP release (not sure
why it's not listed in the PHP version dropdown on the bug report page...
??)

The problem is this: I'm importing a number of PHP files with
require_once() into a main page but I get a blank page. I debugged it down
to two lines of code in one of the files file that is being included. These
two lines are inside a function that is NOT called, however.

  if (!$something)
ft_handle_error("one" . "two" . "three", mysql_error());

When I comment these two lines out, the page loads fine. No errors,
notifications or warnings are displayed. When I remove one (any) of the
strings being concatenated in the first function parameter, the page loads
fine. In other words, when I change the lines to any of these, the page
loads fine:

  if (!$something)
ft_handle_error("two" . "three", mysql_error());

As does:

  if (!$something)
ft_handle_error("one" . "three", mysql_error());

As does:

  if (!$something)
ft_handle_error("one" . "two", mysql_error());

Two final things to mention: when I remove the second mysql_error()
parameter but keep all three strings being concatenated in the first
parameter, the page loads. Also, when I remove the if (!$something)
condition and keep all three strings being concatenated again, it also
works fine. The actual strings being concatenated don't seem to make any
difference.

I'm well beyond confused. Debugging tips?

Reproduce code:
---
  if (!$something)
ft_handle_error("one" . "two" . "three", mysql_error());


Expected result:

The page should load for ANY of the lines of PHP code mentioned.


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

#46918 [NEW]: imap_rfc822_parse_adrlist host part not filled in correctly

[ben at altesco dot nl]

From: ben at altesco dot nl
Operating system: FreeBSD 7
PHP version:  5.2.8
PHP Bug Type: IMAP related
Bug description:  imap_rfc822_parse_adrlist host part not filled in correctly

Description:

Since upgrading from php 5.2.6 to php 5.2.8 I have a problem with 
imap_rfc822_parse_adrlist. When I run the example given on the manual 
page at http://nl3.php.net/imap_rfc822_parse_adrlist, the host part 
sometimes returns junk.


Reproduce code:
---
$adds = 'ian eiloart ,
  sh...@example.ac.uk,
  blobby,
  "ian,eiloart",
  <@example.com:f...@example.ac.uk>,
  f...@#,
  i...@-example.com,
  i...@one@two';
$add_arr = imap_rfc822_parse_adrlist($adds, 'example.com');
var_export ($add_arr);

Expected result:

...
2 =>
class stdClass {
  var $mailbox = 'blobby';
  var $host = 'example.ac.uk';
},
...


Actual result:
--
...
2 =>
stdClass::__set_state(array(
   'mailbox' => 'blobby',
   'host' => 'p?a(',
)),
...


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

#46511 [Bgs]: arg list too long when compiling many modules

[ben dot lentz at gmail dot com]

 ID:   46511
 User updated by:  ben dot lentz at gmail dot com
 Reported By:  ben dot lentz at gmail dot com
 Status:   Bogus
 Bug Type: Compile Failure
 Operating System: AIX 5.3.8.2
 PHP Version:  5.2.6
 New Comment:

I had  the right versions of GNU sed and tried changing my shell to the
latest version of bash.

No dice.

Simply put, enabling every php extension that I needed to build was not
possible because of this issue. I received absolutely no help from
filing this bug report as it was simply slapped with "Bogus" and no
attention was paid to it.

My workaround was to compile as many extensions as I possibly could as
shared modules, disabling everything that couldn't be built
--with-EXTENSION=shared. Then, I rebuilt again, disabling everything 
that could be shared, and enabling everything that couldn't be shared.

Once the two halves were smushed together, I had a working PHP
install.

This doesn't begin to address the third build I'll have to do t o get
the CLI SAPI *AND* the Apache shared module.

I still maintain that the build system provided with PHP is woefully
inadequate and I would be willing to provide testing and more feedback
if someone from the PHP team is willing to listen.

It seems ridiculous that I can't do one build with CLI, Apache2, and
all modules without the system collapsing in on itself.

./configure \
--prefix=/opt/local \
--with-config-file-path=/opt/local/etc
\
--disable-bcmath \
--enable-calendar \
--disable-dbase \
--disable-dom \
--enable-exif \
--enable-ftp \
--enable-pcntl \
--enable-shmop \
--enable-sockets \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--enable-wddx \
--disable-xmlreader \
--disable-xmlwriter \
--with-bz2=/opt/local \
--with-curl=/opt/local \
--with-gettext=/opt/local \
--with-gmp=/opt/local \
--with-iconv-dir=/opt/local \
--with-libxml-dir=/opt/local \
--with-openssl=/opt/local \
--with-openssl-dir=/opt/local \
--with-pspell=/opt/local \
--with-zlib=/opt/local \
--with-zlib-dir=/opt/local \
--without-db4 \
--without-gd \
--without-gdbm \
--without-imap-ssl \
--without-imap \
--without-kerberos \
--without-ldap-sasl \
--without-ldap \
--without-libmbfl \
--without-mcrypt \
--without-mhash \
--without-mm \
--without-mysql \
--without-mysqli \
--without-ncurses \
--without-pdo-mysql \
--without-pdo-odbc \
--without-readline \
--without-snmp \
--without-unixODBC \
--without-xsl
make
make install
make clean
./configure \
--prefix=/opt/local \
--with-config-file-path=/opt/local/etc
\
--enable-bcmath=shared \
--disable-calendar \
--enable-dba=shared \
--enable-dbase=shared \
--enable-dom=shared \
--disable-exif \
--disable-ftp \
--disable-pcntl \
--disable-shmop \
--disable-sockets \
--disable-sysvmsg \
--disable-sysvsem \
--disable-sysvshm \
   

#46742 [NEW]: is_numeric function not working as per "common sense"

[ben at ajmadison dot com]

From: ben at ajmadison dot com
Operating system: any
PHP version:  5.2.6
PHP Bug Type: Feature/Change Request
Bug description:  is_numeric function not working as per "common sense"

Description:

is_numeric("1343.32") returns true, but is_numeric("1,343.32") returns
false. Since the comma is used just for visual representation, the number
represented is still numeric and is_numeric function should return true.

Reproduce code:
---
echo is_numeric("1,343.32");

Expected result:

true

Actual result:
--
false

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

#46511 [Bgs]: arg list too long when compiling many modules

[ben dot lentz at gmail dot com]

 ID:   46511
 User updated by:  ben dot lentz at gmail dot com
 Reported By:  ben dot lentz at gmail dot com
 Status:   Bogus
 Bug Type: Compile Failure
 Operating System: AIX 5.3.8.2
 PHP Version:  5.2.6
 New Comment:

I've tried a few other things. Now I'm getting:

make: execvp: /bin/sh: The parameter or environment lists are too long.


Previous Comments:


[2008-11-07 01:55:53] ben dot lentz at gmail dot com

I'm afraid not. As I wrote:

> Compiling php-5.2.6 using gcc with IBM's linker, and GNU tools
(coreutils/findutils/*sed*

I've installed GNU sed 4.1.5 into /opt/local/bin, prefixed
/opt/local/bin in my PATH, verified with 'which sed', and rebuilt from
scratch. Same result.

Also, the build completes with less modules enabled, regardless of the
sed version.



[2008-11-06 23:08:50] [EMAIL PROTECTED]

Due to a bug in the installed sed on your system the build
fails. Install GNU sed and it should be okay.
 
Thank you for your interest in PHP.



--------

[2008-11-06 19:01:24] ben dot lentz at gmail dot com

Description:

Compiling php-5.2.6 using gcc with IBM's linker, and GNU tools
(coreutils/findutils/sed/awk/grep/automake/autoconf/etc.) with many
modules results in an arg list too long error from /bin/sh (ksh).
Reducing the number of modules included in the build results in a
successful build.

I have tried manually changing the Makefile from SHELL=/bin/sh to
SHELL=/opt/local/bin/bash (GNU bash 3.2.0), but this results in a
different error from the build... something about an unmatched backtick
'`.'

I have tried building some of these modules with=shared,$WHERE but it
didn't help.

I've examined the resulting Makefile and the PHP_GLOBAL_OBJS is so huge
that it crashes IBM's vi (Line too long for current screen size.). I
suspect here in lies the problem.

grep '^PHP_GLOBAL_OBJS' Makefile | wc
   1 587   17353

I have tried both the release php-5.2.6 and php5.2-200811061730, and
the failure was the same in both cases.

If someone could throw together a patch for the Makefile or configure
script, I would be very grateful. Or, if there's a way to build this
differently (sets of modules at a time or something), I would be
grateful for some pointers. 

Thanks

Reproduce code:
---
./configure \
--prefix=$WHERE \
--enable-shared=yes \
--enable-static=no \
--with-libxml-dir=$WHERE \
--with-openssl=$WHERE \
--with-openssl-dir=$WHERE \
--with-mysql=$WHERE \
--with-mysql-sock=$WHERE/var/lib/mysql/mysql.sock \
--with-kerberos=$WHERE \
--with-zlib=$WHERE \
--with-zlib-dir=$WHERE \
--with-bz2=$WHERE \
--with-curl=$WHERE \
--with-gdbm=$WHERE \
--with-db4=$WHERE \
--with-gd=$WHERE \
--with-jpeg-dir=$WHERE \
--with-png-dir=$WHERE \
--with-freetype-dir=$WHERE \
--with-gettext=$WHERE \
--with-imap=$WHERE \
--with-imap-ssl=$WHERE \
--with-ldap=$WHERE \
--with-ldap-sasl=$WHERE \
--with-mm=$WHERE \
--with-libexpat-dir=$WHERE \
--with-iconv=$WHERE \
--with-iconv-dir=$WHERE \
--with-xsl=$WHERE \
--enable-calendar \
--enable-sockets \
--enable-bcmath \
--enable-ftp \
--with-gmp=$WHERE \
--with-pspell=$WHERE \
--with-snmp=$WHERE \
--enable-mbstring \
--with-readline=$WHERE \
--enable-soap \
--enable-wddx \
--enable-zip \
--enable-shmop \
--enable-pcntl \
--enable-exif
make

Expected result:

A successful build of php-cli.

Actual result:
--
>From ksh:
 main/internal_functions.lo -lcrypt -lc-client -lz -lexslt
-lexpat -lexpat -lmm -lhistory -lreadline -lncurses -laspell -lpspell
-lrt -lmysqlclient -lldap -llber -lssl -lcrypto -lcrypt -lpam -liconv
-liconv -lgmp -lintl -lgd -lfreetype -lpng -lz -ljpeg -lssl -lcrypto
-ldb-4.6 -lgdbm -lcurl -lbz2 -lz -lssl -lcrypto -lm -lssl -lcrypto
-lxml2 -lz -liconv -lm -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lcurl
-lssl -lcrypto -llber -lldap -lz -lxml2 -lz -liconv -lm -lgssapi_krb5
-lkrb5 -lk5crypto -lcom_err -lxml2 -lz -liconv -lm -lnetsnmp -lxml2 -lz
-liconv -lm -lxml2 -lz -liconv -lm -lxml2 -lz -liconv -lm -lxslt -lxml2
-lz -liconv -lm -lcrypt  -o sapi/cgi/php-cgi
make: execvp: /bin/sh: Arg list too long
make: *** [sapi/cgi/php-cgi] Error 127

>From bash:
 main/internal_functions.lo -lcrypt -lc-client -lz -lexslt
-lexpat -lexpat -lmm -lhistory -lreadline -lncurses -laspell -lpspell
-lrt -lmysqlclient -lldap -llber -lssl -lcrypto -lcrypt -lpam -li

#46575 [NEW]: NULL comparison when using "not in" not consistent with Windows SQL

[ben at thelocust dot org]

From: ben at thelocust dot org
Operating system: Linux and Windows
PHP version:  5.2.6
PHP Bug Type: MSSQL related
Bug description:  NULL comparison when using "not in" not consistent with 
Windows SQL

Description:

When querying a MSSQL database table, and using the "not in" syntax, PHP's
mssql_query will also return rows with NULL in the field specified.



Reproduce code:
---
SQL Server 2000 or 2005

Table "test"
test_id (int)  test_name (vchar)test_number (int)
1  Foo  1
2  Bar  2
3 3
4  Baz  

$sql = "select test_id from test where test_number not in (1,2)";
$res = mssql_query($sql);
while ($row = mssql_fetch_array($res)) {
?>

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

#46511 [Bgs]: arg list too long when compiling many modules

[ben dot lentz at gmail dot com]

 ID:   46511
 User updated by:  ben dot lentz at gmail dot com
 Reported By:  ben dot lentz at gmail dot com
 Status:   Bogus
 Bug Type: Compile Failure
 Operating System: AIX 5.3.8.2
 PHP Version:  5.2.6
 New Comment:

I'm afraid not. As I wrote:

> Compiling php-5.2.6 using gcc with IBM's linker, and GNU tools
(coreutils/findutils/*sed*

I've installed GNU sed 4.1.5 into /opt/local/bin, prefixed
/opt/local/bin in my PATH, verified with 'which sed', and rebuilt from
scratch. Same result.

Also, the build completes with less modules enabled, regardless of the
sed version.


Previous Comments:


[2008-11-06 23:08:50] [EMAIL PROTECTED]

Due to a bug in the installed sed on your system the build
fails. Install GNU sed and it should be okay.
 
Thank you for your interest in PHP.



----

[2008-11-06 19:01:24] ben dot lentz at gmail dot com

Description:

Compiling php-5.2.6 using gcc with IBM's linker, and GNU tools
(coreutils/findutils/sed/awk/grep/automake/autoconf/etc.) with many
modules results in an arg list too long error from /bin/sh (ksh).
Reducing the number of modules included in the build results in a
successful build.

I have tried manually changing the Makefile from SHELL=/bin/sh to
SHELL=/opt/local/bin/bash (GNU bash 3.2.0), but this results in a
different error from the build... something about an unmatched backtick
'`.'

I have tried building some of these modules with=shared,$WHERE but it
didn't help.

I've examined the resulting Makefile and the PHP_GLOBAL_OBJS is so huge
that it crashes IBM's vi (Line too long for current screen size.). I
suspect here in lies the problem.

grep '^PHP_GLOBAL_OBJS' Makefile | wc
   1 587   17353

I have tried both the release php-5.2.6 and php5.2-200811061730, and
the failure was the same in both cases.

If someone could throw together a patch for the Makefile or configure
script, I would be very grateful. Or, if there's a way to build this
differently (sets of modules at a time or something), I would be
grateful for some pointers. 

Thanks

Reproduce code:
---
./configure \
--prefix=$WHERE \
--enable-shared=yes \
--enable-static=no \
--with-libxml-dir=$WHERE \
--with-openssl=$WHERE \
--with-openssl-dir=$WHERE \
--with-mysql=$WHERE \
--with-mysql-sock=$WHERE/var/lib/mysql/mysql.sock \
--with-kerberos=$WHERE \
--with-zlib=$WHERE \
--with-zlib-dir=$WHERE \
--with-bz2=$WHERE \
--with-curl=$WHERE \
--with-gdbm=$WHERE \
--with-db4=$WHERE \
--with-gd=$WHERE \
--with-jpeg-dir=$WHERE \
--with-png-dir=$WHERE \
--with-freetype-dir=$WHERE \
--with-gettext=$WHERE \
--with-imap=$WHERE \
--with-imap-ssl=$WHERE \
--with-ldap=$WHERE \
--with-ldap-sasl=$WHERE \
--with-mm=$WHERE \
--with-libexpat-dir=$WHERE \
--with-iconv=$WHERE \
--with-iconv-dir=$WHERE \
--with-xsl=$WHERE \
--enable-calendar \
--enable-sockets \
--enable-bcmath \
--enable-ftp \
--with-gmp=$WHERE \
--with-pspell=$WHERE \
--with-snmp=$WHERE \
--enable-mbstring \
--with-readline=$WHERE \
--enable-soap \
--enable-wddx \
--enable-zip \
--enable-shmop \
--enable-pcntl \
--enable-exif
make

Expected result:

A successful build of php-cli.

Actual result:
--
>From ksh:
 main/internal_functions.lo -lcrypt -lc-client -lz -lexslt
-lexpat -lexpat -lmm -lhistory -lreadline -lncurses -laspell -lpspell
-lrt -lmysqlclient -lldap -llber -lssl -lcrypto -lcrypt -lpam -liconv
-liconv -lgmp -lintl -lgd -lfreetype -lpng -lz -ljpeg -lssl -lcrypto
-ldb-4.6 -lgdbm -lcurl -lbz2 -lz -lssl -lcrypto -lm -lssl -lcrypto
-lxml2 -lz -liconv -lm -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lcurl
-lssl -lcrypto -llber -lldap -lz -lxml2 -lz -liconv -lm -lgssapi_krb5
-lkrb5 -lk5crypto -lcom_err -lxml2 -lz -liconv -lm -lnetsnmp -lxml2 -lz
-liconv -lm -lxml2 -lz -liconv -lm -lxml2 -lz -liconv -lm -lxslt -lxml2
-lz -liconv -lm -lcrypt  -o sapi/cgi/php-cgi
make: execvp: /bin/sh: Arg list too long
make: *** [sapi/cgi/php-cgi] Error 127

>From bash:
 main/internal_functions.lo -lcrypt -lc-client -lz -lexslt
-lexpat -lexpat -lmm -lhistory -lreadline -lncurses -laspell -lpspell
-lrt -lmysqlclient -lldap -llber -lssl -lcrypto -lcrypt -lpam -liconv
-liconv -lgmp -lintl -lgd -lfreetype -lpng -lz -ljpeg -lssl -lcrypto
-ldb-4.6 -lgdbm -lcurl -lbz2 -lz -lssl -lcrypto -lm -lssl -lcrypto
-lxml2 -lz -liconv -lm -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lcurl
-lssl -lcrypto -llber -lldap -lz -lxml2 -

#46511 [NEW]: arg list too long when compiling many modules

[ben dot lentz at gmail dot com]

From: ben dot lentz at gmail dot com
Operating system: AIX 5.3.8.2
PHP version:  5.2.6
PHP Bug Type: Compile Failure
Bug description:  arg list too long when compiling many modules

Description:

Compiling php-5.2.6 using gcc with IBM's linker, and GNU tools
(coreutils/findutils/sed/awk/grep/automake/autoconf/etc.) with many modules
results in an arg list too long error from /bin/sh (ksh). Reducing the
number of modules included in the build results in a successful build.

I have tried manually changing the Makefile from SHELL=/bin/sh to
SHELL=/opt/local/bin/bash (GNU bash 3.2.0), but this results in a different
error from the build... something about an unmatched backtick '`.'

I have tried building some of these modules with=shared,$WHERE but it
didn't help.

I've examined the resulting Makefile and the PHP_GLOBAL_OBJS is so huge
that it crashes IBM's vi (Line too long for current screen size.). I
suspect here in lies the problem.

grep '^PHP_GLOBAL_OBJS' Makefile | wc
   1 587   17353

I have tried both the release php-5.2.6 and php5.2-200811061730, and the
failure was the same in both cases.

If someone could throw together a patch for the Makefile or configure
script, I would be very grateful. Or, if there's a way to build this
differently (sets of modules at a time or something), I would be grateful
for some pointers. 

Thanks

Reproduce code:
---
./configure \
--prefix=$WHERE \
--enable-shared=yes \
--enable-static=no \
--with-libxml-dir=$WHERE \
--with-openssl=$WHERE \
--with-openssl-dir=$WHERE \
--with-mysql=$WHERE \
--with-mysql-sock=$WHERE/var/lib/mysql/mysql.sock \
--with-kerberos=$WHERE \
--with-zlib=$WHERE \
--with-zlib-dir=$WHERE \
--with-bz2=$WHERE \
--with-curl=$WHERE \
--with-gdbm=$WHERE \
--with-db4=$WHERE \
--with-gd=$WHERE \
--with-jpeg-dir=$WHERE \
--with-png-dir=$WHERE \
--with-freetype-dir=$WHERE \
--with-gettext=$WHERE \
--with-imap=$WHERE \
--with-imap-ssl=$WHERE \
--with-ldap=$WHERE \
--with-ldap-sasl=$WHERE \
--with-mm=$WHERE \
--with-libexpat-dir=$WHERE \
--with-iconv=$WHERE \
--with-iconv-dir=$WHERE \
--with-xsl=$WHERE \
--enable-calendar \
--enable-sockets \
--enable-bcmath \
--enable-ftp \
--with-gmp=$WHERE \
--with-pspell=$WHERE \
--with-snmp=$WHERE \
--enable-mbstring \
--with-readline=$WHERE \
--enable-soap \
--enable-wddx \
--enable-zip \
--enable-shmop \
--enable-pcntl \
--enable-exif
make

Expected result:

A successful build of php-cli.

Actual result:
--
>From ksh:
 main/internal_functions.lo -lcrypt -lc-client -lz -lexslt -lexpat
-lexpat -lmm -lhistory -lreadline -lncurses -laspell -lpspell -lrt
-lmysqlclient -lldap -llber -lssl -lcrypto -lcrypt -lpam -liconv -liconv
-lgmp -lintl -lgd -lfreetype -lpng -lz -ljpeg -lssl -lcrypto -ldb-4.6
-lgdbm -lcurl -lbz2 -lz -lssl -lcrypto -lm -lssl -lcrypto -lxml2 -lz
-liconv -lm -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lcurl -lssl -lcrypto
-llber -lldap -lz -lxml2 -lz -liconv -lm -lgssapi_krb5 -lkrb5 -lk5crypto
-lcom_err -lxml2 -lz -liconv -lm -lnetsnmp -lxml2 -lz -liconv -lm -lxml2
-lz -liconv -lm -lxml2 -lz -liconv -lm -lxslt -lxml2 -lz -liconv -lm
-lcrypt  -o sapi/cgi/php-cgi
make: execvp: /bin/sh: Arg list too long
make: *** [sapi/cgi/php-cgi] Error 127

>From bash:
 main/internal_functions.lo -lcrypt -lc-client -lz -lexslt -lexpat
-lexpat -lmm -lhistory -lreadline -lncurses -laspell -lpspell -lrt
-lmysqlclient -lldap -llber -lssl -lcrypto -lcrypt -lpam -liconv -liconv
-lgmp -lintl -lgd -lfreetype -lpng -lz -ljpeg -lssl -lcrypto -ldb-4.6
-lgdbm -lcurl -lbz2 -lz -lssl -lcrypto -lm -lssl -lcrypto -lxml2 -lz
-liconv -lm -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lcurl -lssl -lcrypto
-llber -lldap -lz -lxml2 -lz -liconv -lm -lgssapi_krb5 -lkrb5 -lk5crypto
-lcom_err -lxml2 -lz -liconv -lm -lnetsnmp -lxml2 -lz -liconv -lm -lxml2
-lz -liconv -lm -lxml2 -lz -liconv -lm -lxslt -lxml2 -lz -liconv -lm
-lcrypt  -o sapi/cgi/php-cgi
make: execvp: /opt/local/bin/bash: Arg list too long
make: *** [sapi/cgi/php-cgi] Error 127

-- 
Edit bug report at http://bugs.php.net/?id=46511&edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46511&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46511&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46511&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46511&r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=46511&r=needdocs
Fixed in relea

#46017 [NEW]: Make C-Like Macros for PHP

[ben at umingo dot de]

From: ben at umingo dot de
Operating system: Windows
PHP version:  5.2.6
PHP Bug Type: Feature/Change Request
Bug description:  Make C-Like Macros for PHP

Description:

Hello people, i want to ask you for macros for PHP. 
Main purpose is to switch projects between testing, developing and
production state without performance penalties.

All these runtime if's could be skipped and that is jsut one example. 

It just gives you some more options
I really miss macros from C and C++ days ...

another useful example is for logging, 
I dont want to write a __LINE__ and __FILE__ everytime i log something. 
It would be much nicer to use a macro that will expand my logfunction with
these parameters before compiling ... you know what i mean

The bigger the project the bigger the effect of compiling times and
execution times ... This could really be a speedup and at all nobody is
forced to use macros.

(in case php scripts are cached and precompiled)




Reproduce code:
---
//projectstate 
//0 testing
//1 developing
//2 production
#define projectstate = 0

//some code ...

#if projectstate == 0
 //write some log, some output or whatever
}
#endif

//some other code

Expected result:

With macros, the code would be just 

//some code ...
//some other code...

Actual result:
--
Without macros, the code would be 

//some code
//an if-querry for projectstate
//some hundred lines of code to parse and evaluate
//endif
//some other code

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

#45953 [NEW]: Sign-Bit Manipulating is buggy

[ben at umingo dot de]

From: ben at umingo dot de
Operating system: Windows XP 32Bit
PHP version:  5.2.6
PHP Bug Type: Output Control
Bug description:  Sign-Bit Manipulating is buggy

Description:

Problem is with sign bit. 
If i have 0x81234567 then first bit is set to 1 (sign bit).
I would expect that number to be negative, as all integers are signed 32
bit integers. 
If i echo that number, it is positive!
If i compute something with this number, it turns negative!

I have a standard PHP 5.2.6 Version and did not modify anything at it.



Reproduce code:
---
";
echo (0x81234567 | 0x81234567); //result is negative
echo "";
echo (0x81234567 );//result is positive

echo "without sign bit ";
//WORKS
echo (0x71234567 | 0x71234567);
echo "";
echo (0x71234567 );
?>

Expected result:

with sign bit 
-2128394905
-2128394905
without sign bit 
1898136935
1898136935


Actual result:
--
with sign bit 
-2128394905
2166572391
without sign bit 
1898136935
1898136935


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

#43983 [Com]: Weird referencing with stdClass objects

[ben at mailinator dot com]

 ID:  43983
 Comment by:  ben at mailinator dot com
 Reported By: rubens21 at gmail dot com
 Status:  Open
 Bug Type:Scripting Engine problem
 PHP Version: 5.2.5
 New Comment:

How is this weird?  $test is an object.  You store a reference to
$test, 
and then you modify $test.  Since you only stored a reference to the 
original object, of course you will see the new value when you print
out 
the reference.

This changed between PHP4 and PHP5.  PHP4 stores a copy rather than a 
reference.  If you are looking for the PHP4 behavior, you can use the 
"clone" keyword.  e.g. $Objeto->valorDeTeste[] = clone $test;


Previous Comments:


[2008-02-24 20:17:54] rubens21 at gmail dot com

I'm sorry, 'The same' = 'The same problem'

CODE:
$test = new stdClass();
$Objeto = new stdClass();

$test->valor = "The first value";
$Objeto->valorDeTeste[] = $test;

$test->valor = "The second value";

echo "";
print_r($Objeto->valorDeTeste);
echo "";
var_dump($Objeto->valorDeTeste);
echo "";








Array
(
[0] => stdClass Object
(
[valor] => The second value
)

)

array(1) {
  [0]=>
  object(stdClass)#1 (1) {
["valor"]=>
string(16) "The second value"
  }
}



[2008-02-24 19:44:21] [EMAIL PROTECTED]

That's impossible, the output of var_dump() differs a LOT from
print_r(). So can you please really test it?



[2008-02-23 17:04:12] rubens21 at gmail dot com

"What does it output when you replace print_r() with var_dump() ?"

R: The same



[2008-02-01 22:28:15] [EMAIL PROTECTED]

What does it output when you replace print_r() with var_dump() ?



[2008-01-30 15:40:53] rubens21 at gmail dot com

This example is more simple:

$test = new stdClass();
$Objeto = new stdClass();

$test->valor = "The first value";
$Objeto->valorDeTeste[] = $test;

$test->valor = "The second value";
print_r($Objeto->valorDeTeste);


Expected:
Array
(
[0] => stdClass Object
(
[valor] => The first value
)

)

Actual

Array
(
[0] => stdClass Object
(
[valor] => The second value
)

)



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

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

#41997 [Com]: pdo_mysql: stored procedure call returning single rowset blocks future queries

[ben at stickyeyes dot com]

 ID:   41997
 Comment by:   ben at stickyeyes dot com
 Reported By:  nitel_defect at yahoo dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: Windows XP SP2
 PHP Version:  5.2.3
 New Comment:

Just to add to this bug, I too experience this problem when trying to
execute two stored procedures, one after the other. 

Unfortunately, the only work around I could get working, was to create
a new PDO object for each query (attempting to clone an existing PDO
object caused Apache to crash, but thats another bug for another
day...)

Sucks, but it works.

Apache/2.2.4 (Win32) PHP/5.2.3
PDO Driver for MySQL, client library version5.0.37
MySQL 5.1.22


Previous Comments:


[2008-01-22 13:28:59] [EMAIL PROTECTED]

Reclassified: mysql -> pdo



[2007-08-21 00:08:52] marpiotr at gmail dot com

i seem to have the same problem on 5.1.6 on Fedora Core 6



[2007-07-16 18:06:49] nitel_defect at yahoo dot com

http://www.kpsol.ro/php_pdo_mysql.dll



[2007-07-16 17:30:00] temposeb at free dot fr

I encounter exactly the same bug for many months.
Environment : Win2000 Pro SP4, Apache 2.2, PHP 5.2.4-dev (Build Date
Jul 11 2007 20:03:23), MySQL 5.1.20-beta-community-nt-debug (same thing
with MySQL 5.0.x).
nitel_defect, where can we find the hacked DLL ?
http://source.hackthissite.org/svn/trunk/PDO/php_pdo_mysql.dll is
actually DOWN. Thx.



[2007-07-15 06:53:01] nitel_defect at yahoo dot com

Description:

The code below calls a stored procedure that fethches the whole tree in
a father-son system roles hierarchy.
In the end, the stored procedure selects everything from a temp table,
so that's our result set.
PDO::MYSQL_ATTR_USE_BUFFERED_QUERY is on by default.
After running the call statement, all the result rows are returned
correctly but any future query (not only other calls, all queries) fail
with the message you see below.
For the time being I replicated the code I needed in PHP, but it's
frustrating not to be able to run SPs...
I tested the library found here:
http://source.hackthissite.org/svn/trunk/PDO/php_pdo_mysql.dll
and this bug was gone. But there is no source code for this modified
library and its size is much smaller so I don't quite trust it.
Uhm... help?

Reproduce code:
---
query("call getParentRoles('admin')");
do {
$rows = $st->fetchAll(PDO::FETCH_ASSOC);
} while ($st->nextRowset());
$st->closeCursor();
var_dump($db->errorInfo());
echo '';
$st = $db->query("SELECT * FROM user");
var_dump($db->errorInfo());

Expected result:

array(1) { [0]=>  string(5) "0" }
array(1) { [0]=>  string(5) "0" }

Actual result:
--
array(1) { [0]=>  string(5) "0" }
array(3) { [0]=> string(5) "HY000" [1]=> int(2014) [2]=> string(269)
"Cannot execute queries while other unbuffered queries are active.
Consider using PDOStatement::fetchAll(). Alternatively, if your code is
only ever going to run against mysql, you may enable query buffering by
setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute." } 





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

#42920 [Fbk->Csd]: glibc memory errors in fastcgi mode

[ben dot lavender at mcdean-europe dot com]

 ID:   42920
 User updated by:  ben dot lavender at mcdean-europe dot com
 Reported By:  ben dot lavender at mcdean-europe dot com
-Status:   Feedback
+Status:   Closed
 Bug Type: Reproducible crash
 Operating System: RHEL5
 PHP Version:  5.2.4
 New Comment:

I seem to have been able to track this down to a rogue PECL module that
was compiled for 5.1.6.


Previous Comments:


[2007-10-11 13:33:09] [EMAIL PROTECTED]

Can you reproduce this with non-patched PHP and without loading ANY
Zend extensions (like apc/apd/zend optimizer/etc).. ?



[2007-10-10 17:32:57] ben dot lavender at mcdean-europe dot com

Description:

Running PHP 5.2.4 in FastCGI mode results in recurring crashes.  These
happen both with and without APC, with or without APD (I'm not trying to
use both at once, of course).  Once a crash happens, the process will
continue to crash over and over on any page request.  

With APD installed, crashes are reported and I'm attaching an APD stack
trace here.  Without APD, FastCGI simply catches the failure and
restarts the process--sometimes a page is not even missed by the end
user, but sometimes it is.

I'm using PHP 5.2.4, slightly patched; it's based on the RHEL 5.1.6
RPM.  I can provide an SRPM of the version of PHP I'm using; apd is
installed with pecl.

Reproduce code:
---
We are using a rather massive Drupal installation (600k+ lines of
code).  It would obviously be impractical to post all of this. 
Furthermore, reproducing the problem is an irregular process--I simply
keep hitting refresh until it happens.  Using multiple browsers speeds
the process, as long as php doesn't start waiting on the database.  

After a failure, phpinfo() will display the problem over and over.

Expected result:

PHP in FastCGI mode would not eventually fail.

Actual result:
--
Without APD, FastCGI spits out messages about restarting the process,
and there's nothing interesting to see.


With APD, the apache log files end up with entries like these.  The
client is 127.0.0.1 as this is a staging server and the load balance
proxy is on the same box for testing.

*** glibc detected *** /usr/bin/php-cgi: malloc(): memory corruption:
0xb7fc8008 ***
=== Backtrace: =
/lib/libc.so.6[0x4d03168b]
/lib/libc.so.6(__libc_malloc+0x7e)[0x4d032dae]
/usr/bin/php-cgi(zend_hash_sort+0x3b)[0x82119db]
/usr/bin/php-cgi(zend_ini_sort_entries+0x42)[0x82197c2]
/usr/bin/php-cgi(php_print_info+0x77)[0x8169337]
/usr/bin/php-cgi(zif_phpinfo+0x6d)[0x816a64d]
/usr/bin/php-cgi(execute_internal+0x51)[0x8224f71]
/usr/lib/php/modules/apd.so(apd_execute_internal+0x74)[0x113404]
/usr/bin/php-cgi[0x82279d2]
/usr/bin/php-cgi(execute+0x15d)[0x8226a3d]
/usr/lib/php/modules/apd.so(apd_execute+0x64)[0x113494]
/usr/bin/php-cgi(zend_execute_scripts+0x1ba)[0x8205cea]
/usr/bin/php-cgi(php_execute_script+0x1f3)[0x81bf003]
/usr/bin/php-cgi(main+0x11d9)[0x828d899]
/lib/libc.so.6(__libc_start_main+0xdc)[0x4cfe0dec]
/usr/bin/php-cgi[0x8077df1]
.. *memory map snipped* ..
[Wed Oct 10 20:18:26 2007] [error] [client 127.0.0.1] (104)Connection
reset by peer: FastCGI: comm with server "/var/www/cgi-bin/php-wrapper"
aborted: read failed
[Wed Oct 10 20:18:26 2007] [error] [client 127.0.0.1] FastCGI:
incomplete headers (0 bytes) received from server
"/var/www/cgi-bin/php-wrapper"


*** glibc detected *** /usr/bin/php-cgi: malloc(): memory corruption:
0xb7fc8008 ***
=== Backtrace: =
/lib/libc.so.6[0x4d03168b]
/lib/libc.so.6(__libc_malloc+0x7e)[0x4d032dae]
/usr/bin/php-cgi(_zend_hash_add_or_update+0x26b)[0x821224b]
/usr/lib/php/modules/apd.so[0x112872]
/usr/lib/php/modules/apd.so(apd_execute+0x56)[0x113486]
/usr/bin/php-cgi(zend_execute_scripts+0x1ba)[0x8205cea]
/usr/bin/php-cgi(php_execute_script+0x1f3)[0x81bf003]
/usr/bin/php-cgi(main+0x11d9)[0x828d899]
/lib/libc.so.6(__libc_start_main+0xdc)[0x4cfe0dec]
/usr/bin/php-cgi[0x8077df1]
* memory map snipped *
[Wed Oct 10 20:14:05 2007] [error] [client 127.0.0.1] (104)Connection
reset by peer: FastCGI: comm with server "/var/www/cgi-bin/php-wrapper"
aborted: read failed
[Wed Oct 10 20:14:05 2007] [error] [client 127.0.0.1] FastCGI:
incomplete headers (0 bytes) received from server
"/var/www/cgi-bin/php-wrapper"


*** glibc detected *** /usr/bin/php-cgi: double free or corruption
(!prev): 0x09fe0108 ***
=== Backtrace: =
/lib/libc.so.6[0x4d030f7d]
/lib/libc.so.6(cfree+0x90)[0x4d0345d0]
/lib/libc.so.6(fclose+0x134)[0x4d0202d4]
/usr/lib/php/modules/apd.so(zm_deactivate_apd+0x2c)[0xee19cc]
/usr/bin/php-cgi(module_registry_cleanup+0x20)[0x82079d0]
/usr/bin/php-cgi(zend_hash_apply+0x4c)[0x821086c]
/usr/bin/php-cgi(zend_deactivate_modules+0x61)[0x8205f41]
/usr/bin/php-cgi(php_request_shutdow

#42920 [NEW]: glibc memory errors in fastcgi mode

[ben dot lavender at mcdean-europe dot com]

From: ben dot lavender at mcdean-europe dot com
Operating system: RHEL5
PHP version:  5.2.4
PHP Bug Type: Reproducible crash
Bug description:  glibc memory errors in fastcgi mode

Description:

Running PHP 5.2.4 in FastCGI mode results in recurring crashes.  These
happen both with and without APC, with or without APD (I'm not trying to
use both at once, of course).  Once a crash happens, the process will
continue to crash over and over on any page request.  

With APD installed, crashes are reported and I'm attaching an APD stack
trace here.  Without APD, FastCGI simply catches the failure and restarts
the process--sometimes a page is not even missed by the end user, but
sometimes it is.

I'm using PHP 5.2.4, slightly patched; it's based on the RHEL 5.1.6 RPM. 
I can provide an SRPM of the version of PHP I'm using; apd is installed
with pecl.

Reproduce code:
---
We are using a rather massive Drupal installation (600k+ lines of code). 
It would obviously be impractical to post all of this.  Furthermore,
reproducing the problem is an irregular process--I simply keep hitting
refresh until it happens.  Using multiple browsers speeds the process, as
long as php doesn't start waiting on the database.  

After a failure, phpinfo() will display the problem over and over.

Expected result:

PHP in FastCGI mode would not eventually fail.

Actual result:
--
Without APD, FastCGI spits out messages about restarting the process, and
there's nothing interesting to see.


With APD, the apache log files end up with entries like these.  The client
is 127.0.0.1 as this is a staging server and the load balance proxy is on
the same box for testing.

*** glibc detected *** /usr/bin/php-cgi: malloc(): memory corruption:
0xb7fc8008 ***
=== Backtrace: =
/lib/libc.so.6[0x4d03168b]
/lib/libc.so.6(__libc_malloc+0x7e)[0x4d032dae]
/usr/bin/php-cgi(zend_hash_sort+0x3b)[0x82119db]
/usr/bin/php-cgi(zend_ini_sort_entries+0x42)[0x82197c2]
/usr/bin/php-cgi(php_print_info+0x77)[0x8169337]
/usr/bin/php-cgi(zif_phpinfo+0x6d)[0x816a64d]
/usr/bin/php-cgi(execute_internal+0x51)[0x8224f71]
/usr/lib/php/modules/apd.so(apd_execute_internal+0x74)[0x113404]
/usr/bin/php-cgi[0x82279d2]
/usr/bin/php-cgi(execute+0x15d)[0x8226a3d]
/usr/lib/php/modules/apd.so(apd_execute+0x64)[0x113494]
/usr/bin/php-cgi(zend_execute_scripts+0x1ba)[0x8205cea]
/usr/bin/php-cgi(php_execute_script+0x1f3)[0x81bf003]
/usr/bin/php-cgi(main+0x11d9)[0x828d899]
/lib/libc.so.6(__libc_start_main+0xdc)[0x4cfe0dec]
/usr/bin/php-cgi[0x8077df1]
.. *memory map snipped* ..
[Wed Oct 10 20:18:26 2007] [error] [client 127.0.0.1] (104)Connection
reset by peer: FastCGI: comm with server "/var/www/cgi-bin/php-wrapper"
aborted: read failed
[Wed Oct 10 20:18:26 2007] [error] [client 127.0.0.1] FastCGI: incomplete
headers (0 bytes) received from server "/var/www/cgi-bin/php-wrapper"


*** glibc detected *** /usr/bin/php-cgi: malloc(): memory corruption:
0xb7fc8008 ***
=== Backtrace: =
/lib/libc.so.6[0x4d03168b]
/lib/libc.so.6(__libc_malloc+0x7e)[0x4d032dae]
/usr/bin/php-cgi(_zend_hash_add_or_update+0x26b)[0x821224b]
/usr/lib/php/modules/apd.so[0x112872]
/usr/lib/php/modules/apd.so(apd_execute+0x56)[0x113486]
/usr/bin/php-cgi(zend_execute_scripts+0x1ba)[0x8205cea]
/usr/bin/php-cgi(php_execute_script+0x1f3)[0x81bf003]
/usr/bin/php-cgi(main+0x11d9)[0x828d899]
/lib/libc.so.6(__libc_start_main+0xdc)[0x4cfe0dec]
/usr/bin/php-cgi[0x8077df1]
* memory map snipped *
[Wed Oct 10 20:14:05 2007] [error] [client 127.0.0.1] (104)Connection
reset by peer: FastCGI: comm with server "/var/www/cgi-bin/php-wrapper"
aborted: read failed
[Wed Oct 10 20:14:05 2007] [error] [client 127.0.0.1] FastCGI: incomplete
headers (0 bytes) received from server "/var/www/cgi-bin/php-wrapper"


*** glibc detected *** /usr/bin/php-cgi: double free or corruption
(!prev): 0x09fe0108 ***
=== Backtrace: =
/lib/libc.so.6[0x4d030f7d]
/lib/libc.so.6(cfree+0x90)[0x4d0345d0]
/lib/libc.so.6(fclose+0x134)[0x4d0202d4]
/usr/lib/php/modules/apd.so(zm_deactivate_apd+0x2c)[0xee19cc]
/usr/bin/php-cgi(module_registry_cleanup+0x20)[0x82079d0]
/usr/bin/php-cgi(zend_hash_apply+0x4c)[0x821086c]
/usr/bin/php-cgi(zend_deactivate_modules+0x61)[0x8205f41]
/usr/bin/php-cgi(php_request_shutdown+0x2ba)[0x81bfb1a]
/usr/bin/php-cgi(main+0x120e)[0x828d8ce]
/lib/libc.so.6(__libc_start_main+0xdc)[0x4cfe0dec]
/usr/bin/php-cgi[0x8077df1]

*** glibc detected *** /usr/bin/php-cgi: double free or corruption
(!prev): 0x0a3c6c48 ***
=== Backtrace: =
/lib/libc.so.6[0x4d030f7d]
/lib/libc.so.6(cfree+0x90)[0x4d0345d0]
/lib/libc.so.6(fclose+0x134)[0x4d0202d4]
/usr/lib/php/modules/apd.so(zm_deactivate_apd+0x2c)[0x2fc9cc]
/usr/bin/php-cgi(module_registry_cleanup+0x20)[0x82079d0]
/usr/bin/php-cgi(zend_hash_apply+0x4c)[0x821086c]
/usr/bin/php-cgi(zend_deactivate_modules+0x61)[0x8205f41]
/u

#22427 [Com]: Missing Form Post Data

[ben at hceo dot co dot uk]

 ID:   22427
 Comment by:   ben at hceo dot co dot uk
 Reported By:  jroland at uow dot edu dot au
 Status:   No Feedback
 Bug Type: *General Issues
 Operating System: Windows XP / 2000
 PHP Version:  4.2.3
 New Comment:

Hi,  

I found the same POST problem.  I have a login form and it works fine
on FireFox and IE 6.0.3790, but not on IE 6.0.2800.  If the username and
password are all one word it works fine on IE 6.0.2800 but if it is made
of 2 or more words it only posts the variables once in every 10 or so
posts.

I read that this problem can be got around by using .htm extension
rather than .php - to get around this I changed the httpd.conf file to
read:

AddType application/x-httpd-php .php .htm

I then changed the extension of my login file to .htm and this seems to
work ok.


Previous Comments:


[2007-07-04 06:05:46] ads at alex4all dot com

I just want to say Thanks a lot for comment called ([27 Mar 2003 2:08am
UTC] sendoffer at ukr dot net); because my problem solved for same
issue.

BR, Ali



[2007-06-13 22:27:20] relisys002 at yahoo dot com

As a follow-up to my post yesterday, it appears as though the firewall
software we have on our Windows machine (Comodo Firewall) was the cause
of the problem. Using the Windows firewall didn't cause any problems.
This may not be the case in for the other people with problems but I
thought I would at least post the resolution to mine.

I would recommend that everyone disable all firewall and security
software if they are experiencing this problem.



[2007-06-12 21:29:21] relisys002 at yahoo dot com

Just came across the same problem myself last week.
PHP 5.1.6
Apache 2.0.59
FreeBSD 6.1-RELEASE-p11

EVERY browser I have tried in Windows fails to work past a request size
of about 1450 bytes. I have tested IE 6.0, FF 2.0.0.3 and Safari Beta 3.
PHP still returns the requests size via getenv("CONTENT_LENGTH") but
both $_POST and $_GET are empty.

When I try the EXACT same page on the EXACT same server with both FF
2.0.0.3 and Safari 2.0.4(419.3) I have no problems submitting however
much data I want. Here's my test form:

/ CODE -/

TEST














/ CODE -/

I get the same result with and without the enctype. I can't believe
nobody has found a solution for this yet. If somebody has, please post
it here or email me and I will.



[2007-05-10 09:15:10] tnieto at greenbit dot es

I have experienced this issue also.

My environment is:

- php 4.4.2 as a module
- Apache 1.3
- Windows 2000 Server

When I send a form with a text area using POST i don't receive any
data.

In my case, it was because I was sending de form using a Javascript
code:

  function newitem(tipus)
  {
var accion;
if (tipus == 1)
{
  accion = 
document.mailing.action="pre_mailingsmanuals.php";
}
else
{
  accion = 
document.mailing.action="env_mailingsmanuals.php";
}
document.mailing.action=accion;
document.mailing.submit();
  } 

The input was specified as a button: http://www.thescripts.com/forum/thread4451.html - which covers my issue,
and I have implemented the solution by checking for
(isset($_POST['submit']) || isset($_POST['submit_x'])) to check whether
my submit button has been clicked. Note that is an underscore, not a
'.'.

The solution works for GET method as well, if you are using that. If
you submit a form with a 'submit' image button using GET, the browser
URL shows submit.x=aa&submit.y=bb where aa and bb are the coordinates
within the button image of where you clicked, but you should still check
for $_GET['submit_x'] NOT $_GET['submit.x'].
 
As discussed in the above referred forum log this is an issue affecting
Internet Explorer, Netscape and Opera, and maybe other browsers, and
seems to be a simple failure to conform to the HTML standard for
handling forms.

Hope this helps someone.

Andy



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

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

#42265 [NEW]: preg match error ()

[ben at crabb dot com]

From: ben at crabb dot com
Operating system: FreeBSD6.1
PHP version:  5CVS-2007-08-10 (snap)
PHP Bug Type: Apache2 related
Bug description:  preg match error ()

Description:

I have installed apache22 and php5.2.3 / mod_php5 but I cannot get apache
to render php on this box. I have checked that the module is called in
httpd.conf and also that I have extension=pcre.so in the php.ini but I'm
still getting 
Fatal error: Call to undefined function preg_match() in
/usr/home/www/phpadmin/phpMyAdmin-2.6.1/libraries/defines.lib.php on line
36
Whenever I try to load phpMyAdmin

I haven't tried rendering other php files yet as I've been trying to iron
this one out for the past few hours.

Help?


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

#39130 [NoF->Opn]: Compile failure with the compiler of VC++ 2005

[ben dot yan at msn dot com]

 ID:   39130
 User updated by:  ben dot yan at msn dot com
 Reported By:  ben dot yan at msn dot com
-Status:   No Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: Windows
 PHP Version:  5.2.2
 Assigned To:  wez
 New Comment:

hi,
I recompile eAccelerator v0.9.4(http://www.eaccelerator.net/) with the
latest PHP(http://snaps.php.net/php5.2-latest.tar.gz), but the same
problems are still there.


Previous Comments:


[2007-07-22 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-07-14 10:08:28] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows (zip):
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

For Windows (installer):

  http://snaps.php.net/win32/php5.2-win32-installer-latest.msi





[2007-06-15 12:47:02] grotaiche at hotmail dot com

Yeah, I have the same problem too. I recompile my extension with VS
2005 for every PHP release and I have had the problem for a while.
Commenting the #define _USE_32BIT_TIME_T 1 line is not very difficult
but it is a by-pass ; a more viable solution would be appreciated :)
Thanks !



[2007-06-02 10:52:53] cxd at webpan dot com

Trying to compile a module for PHP 5.2.3 with VC++ 2005 SP1 I also get
tons of error like:

error C2466: cannot allocate an array of constant size 0

This module (eAccelerator for Windows) compiled fine with VC++ 2005 SP1
and PHP 5.2.2.

The following might explain the cause of the problem (not sure?) that
was (re)introduced with 523( again my module compiles great with PHP 522
& VC++ 2005):

--
deprecated "default to int" rule: 

Pre-standard C++ (and all C variants predating C99), use the "default
to int" rule when
declarations of functions and variables do not contain an explicit
datatype. 
This behavior is maintained in Visual C++ 6.0 as the following
declarations show: 


const x=0; //implicit int
static num; // implicit int
myfunc(void *ptr); //implicit return type int

In Visual Studio 2005, you have to specify the datatype explicitly:
const int x=0; static int num; int myfunc(void *ptr); 

Hope this helps...



[2007-05-19 18:24:06] [EMAIL PROTECTED]

Wez, you never got to the company laptop..? Or was it stolen? :D



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

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

#41898 [Fbk->Csd]: mysqli_* functions missing

[ben at popator dot com]

 ID:   41898
 User updated by:  ben at popator dot com
 Reported By:  ben at popator dot com
-Status:   Feedback
+Status:   Closed
 Bug Type: MySQLi related
 Operating System: CentOS 4.5 x86_64
 PHP Version:  5.2.3
 New Comment:

Bogus bug. User error.


Previous Comments:


[2007-07-05 13:54:57] [EMAIL PROTECTED]

Cannot reproduce.
Try to remove all the configure options and leave only --with-mysqli
and then add options one by one to see which one causes the problem.



[2007-07-05 01:09:04] ben at popator dot com

Description:

PHP 5.2.3 fails to implement mysqli functions in conjunction with
mysql.

phpinfo() reports MySQL and MySQLi as being available.

Attempted workarounds as detailed at
http://www.kofler.cc/forum/forumthread.php?rootID=3571 without any
success.

MySQL Version: 4.1.21

Configure:
'./configure' '--enable-pic' '--with-libdir=lib64'
'--prefix=/usr/local' '--with-xml' '--enable-bcmath' '--enable-calendar'
'--with-curl' '--with-dom' '--with-dom-xslt' '--with-dom-exslt'
'--enable-exif' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local'
'--with-png-dir=/usr' '--with-xpm-dir=/usr/X11R6' '--with-gettext'
'--with-iconv' '--with-imap=/usr/local/imap-2004g' '--enable-mbstring'
'--enable-mbstr-enc-trans' '--enable-mbregex' '--with-mcrypt'
'--with-mhash' '--enable-magic-quotes' '--with-mysql=/usr'
'--with-mysqli=/usr/bin/mysql_config' '--with-snmp'
'--enable-ucd-snmp-hack' '--with-openssl' '--with-pear' '--with-pspell'
'--enable-sockets' '--enable-track-vars' '--with-ttf'
'--with-freetype-dir=/usr' '--enable-gd-native-ttf' '--enable-wddx'
'--with-xmlrpc' '--with-zip' '--with-zlib' '--prefix=/usr/local/php5'
'--exec-prefix=/usr/local/php5' '--program-suffix=5'
'--enable-force-cgi-redirect' '--disable-discard-path'
'--with-pdo-mysql'

Reproduce code:
---
http://bugs.php.net/?id=41898&edit=1

#41898 [NEW]: mysqli_* functions missing

[ben at popator dot com]

From: ben at popator dot com
Operating system: CentOS 4.5 x86_64
PHP version:  5.2.3
PHP Bug Type: MySQLi related
Bug description:  mysqli_* functions missing

Description:

PHP 5.2.3 fails to implement mysqli functions in conjunction with mysql.

phpinfo() reports MySQL and MySQLi as being available.

Attempted workarounds as detailed at
http://www.kofler.cc/forum/forumthread.php?rootID=3571 without any
success.

MySQL Version: 4.1.21

Configure:
'./configure' '--enable-pic' '--with-libdir=lib64' '--prefix=/usr/local'
'--with-xml' '--enable-bcmath' '--enable-calendar' '--with-curl'
'--with-dom' '--with-dom-xslt' '--with-dom-exslt' '--enable-exif'
'--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local'
'--with-png-dir=/usr' '--with-xpm-dir=/usr/X11R6' '--with-gettext'
'--with-iconv' '--with-imap=/usr/local/imap-2004g' '--enable-mbstring'
'--enable-mbstr-enc-trans' '--enable-mbregex' '--with-mcrypt'
'--with-mhash' '--enable-magic-quotes' '--with-mysql=/usr'
'--with-mysqli=/usr/bin/mysql_config' '--with-snmp'
'--enable-ucd-snmp-hack' '--with-openssl' '--with-pear' '--with-pspell'
'--enable-sockets' '--enable-track-vars' '--with-ttf'
'--with-freetype-dir=/usr' '--enable-gd-native-ttf' '--enable-wddx'
'--with-xmlrpc' '--with-zip' '--with-zlib' '--prefix=/usr/local/php5'
'--exec-prefix=/usr/local/php5' '--program-suffix=5'
'--enable-force-cgi-redirect' '--disable-discard-path' '--with-pdo-mysql'

Reproduce code:
---
http://bugs.php.net/?id=41898&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41898&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41898&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41898&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41898&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41898&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41898&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41898&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41898&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41898&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41898&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41898&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41898&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41898&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41898&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41898&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41898&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41898&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41898&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41898&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41898&r=mysqlcfg

#39130 [NoF->Opn]: Compile failure with the compiler of VC++ 2005

[ben dot yan at msn dot com]

 ID:   39130
 User updated by:  ben dot yan at msn dot com
 Reported By:  ben dot yan at msn dot com
-Status:   No Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: Windows
-PHP Version:  5.2.0RC5
+PHP Version:  5.2
 Assigned To:  wez
 New Comment:

I tried PHP5.2.2, but the problem is still there. :(


Previous Comments:


[2007-04-14 05:00:20] dmain at themainfamily dot net

If I move this change, then the compiler errors are gone.  I still have
another separate issue with compilation though.


This would induce the compile error. and if 

#include 

BEHIND the 

#ifdef ZEND_WIN32
# include "zend_config.w32.h"
# define ZEND_PATHS_SEPARATOR   ';'
#elif defined(XXX)
...
#endif

,it will be ok.



[2007-04-14 04:53:41] dmain at themainfamily dot net

This is my output when compiling a simple dll extension using the
sample source code in the online documentation.



1>-- Build started: Project: Win32_SystemCalls, Configuration:
Release_TS Win32 --
1>Compiling...
1>Source1.c
1>C:\Program Files\Microsoft Visual Studio
8\VC\include\sys/stat.inl(44) : error C2466: cannot allocate an array of
constant size 0
1>C:\Program Files\Microsoft Visual Studio
8\VC\include\sys/stat.inl(49) : error C2466: cannot allocate an array of
constant size 0
1>c:\projects\phpextensions\php-5.2.1\tsrm\tsrm_config_common.h(4) :
fatal error C1017: invalid integer constant expression
1>Build log was saved at
"file://c:\Projects\PhpExtensions\php-5.2.1\ext\Win32_SystemCalls\Release_TS\BuildLog.htm"
1>Win32_SystemCalls - 3 error(s), 0 warning(s)
== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped
==



[2007-01-15 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-01-07 18:23:35] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip





[2006-11-04 15:27:35] sailormax at inbox dot lv

I have same error while trying compile my module. With previous PHP all
was fine.
With 5.2.0 all fine too, if comment 2 lines at config.w32.h:
#define _USE_32BIT_TIME_T 1
#define HAVE_STDLIB_H 1

used VC++ 2005 Express Edition



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

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

#41368 [NEW]: ADODB.Recordset ActiveConnection property - can't set with PHP 5.2.1+

[ben dot crum at colony101uk dot com]

From: ben dot crum at colony101uk dot com
Operating system: Windows XP SP2
PHP version:  5.2.2
PHP Bug Type: COM related
Bug description:  ADODB.Recordset ActiveConnection property - can't set with 
PHP 5.2.1+

Description:

This seems similar to Bug #22162 - Program performs "illegal operation",
but that was for PHP 4.3.1-dev.

I originally had PHP 5.1.6 installed on my PC and had written a few
scripts using ADODB Connections and Recordsets.  These ran fine as web
pages served by Apache's HTTP Server v2.0.

I upgraded to PHP 5.2.2 using the MSI and my scripts reported errors for
the same line of code.


Overwriting the contents of my C:\PHP\ folder with the contents of the PHP
5.2.0 Zip file, I do NOT get these errors when running my scripts as web
pages through Apache or from the command line (i.e. "php.exe
c:\Web\simple.php").

If I overwrite the contents of my C:\PHP\ folder with the PHP 5.2.1 or
5.2.2 Zip files I get the error mentioned above when running them through
Apache or from the command line.

Reproduce code:
---
Here is a simple sample that works with PHP 5.2.0, but breaks for me when
using PHP 5.2.1+:

--
ActiveConnection = 'PROVIDER=SQLOLEDB; DATA SOURCE=(local); UID=sa;
PWD=password; INITIAL CATALOG=myDB';
$rs->CursorLocation = 3;
$rs->Source = 'SELECT * FROM [myTable]';
$rs->Open();

if ( $rs->EoF )
{
print( '- No records returned. -' );
}
else
{
print( 'Returned records: ' . $rs->RecordCount );
}

$rs->Close();
$rs = NULL;

?>
--

Expected result:

This is the error I get on lines that set an ADODB.Recordset object's
.ActiveConnection property:

Fatal error: Uncaught exception 'com_exception' with message
'Source: ProviderDescription: Type mismatch.' in
C:\Web\simple.php:4 Stack trace: #0 C:\Web\simple.php(4): unknown() #1
{main} thrown in C:\Web\simple.php on line 4

Actual result:
--
I don't think it's the objects and their properties coz this works as a
VBScript (.vbs) file (no hissing please!):

--
OPTION EXPLICIT

DIM rs

SET rs = CreateObject("ADODB.Recordset")
rs.ActiveConnection = "PROVIDER=SQLOLEDB; DATA SOURCE=(local); UID=sa;
PWD=password; INITIAL CATALOG=myDB"
rs.CursorLocation = 3
rs.Source = "SELECT * FROM [myTable]"
rs.Open

IF ( rs.EoF ) THEN
WScript.Echo( "- No records returned. -" )
ELSE
WScript.Echo( "Returned records: " & rs.RecordCount )
END IF

rs.Close
SET rs = Nothing
--


It looks to me that after 5.2.0, PHP no longer lets you set the
.ActiveConnection of an ADODB.Recordset (or I've just messed up my PHP
folder...).

Thanks for your help.

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

#40749 [Fbk->Opn]: pack and unpack erroneous behavior on 64bits hosts

[ben at ateor dot com]

 ID:   40749
 User updated by:  ben at ateor dot com
 Reported By:  ben at ateor dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: OpenBSD amd64 and sparc64
 PHP Version:  5.2.1
 Assigned To:  iliaa
 New Comment:

Fix the problem for me, thanks. 
(ps: meanwhile, I can't verify there's no regressions, given how the
testsuite has changed).


Previous Comments:


[2007-04-03 22:00:45] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip





[2007-03-16 14:03:01] martin at netimage dot dk

It appears that the sign bit is taken from LSB instead of MSB

> php -r 'print_r( unpack('N',pack('N',127)));'
Array
(
[1] => 127
)

> php -r 'print_r( unpack('N',pack('N',128)));'
Array
(
[1] => -2147483520
)

The last number is 2's complement of -128 for 32 bit integers

Cheers



[2007-03-14 20:57:41] pz at mysqlperformanceblog dot com

In any case if you call it bug or a feature this is serious behavior
change for something which a lot of people could be depending on. 

It breaks in MySQL 5.2.0 -> 5.2.1  which is minor version upgrade.



[2007-03-09 09:06:47] windeler at mediafinanz dot de

Here is another example of a problem with unpack on 64bit systems. It
worked in 5.1.6, but with 5.2.1 the results are bogus.

The expected value from the file content is 200, but PHP says
-2147483448 when I echo $a['i'].





[2007-03-07 17:12:58] ben at ateor dot com

Description:

This is a follow-up on #40543 (http://bugs.php.net/bug.php?id=40543,
since
that bug is closed, I can't add comments). 
Please note : it's not identical to #4053 (other weird behaviors 
are demonstrated).

Iliaa,
Not sure why you suggest to use little endian or host conversions
routines,
but in my standpoint if you reverse twice a number's byte ordering
then you should get the original number back (assuming the number
don't
overflows php's internals).

At least, that's the standard behavior for perl and python.

Beside, I can't see why php should handles those endianness
conversions
differently on an i386 (32 bits) and on an x86_64 (64 bits), both
having the same byte order.

The following on a 64bit, little endian host :
x86_64$ uname -mprsv
OpenBSD 4.0 GENERIC#0 amd64 AMD Sempron(tm) Processor 3400+

x86_64$ perl -e 'print unpack("N", pack("N", 41445)) ."\n"'
41445

x86_64$ python
Python 2.4.3 (#1, Sep  6 2006, 20:33:08)
[GCC 3.3.5 (propolice)] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
>>> from struct import *
>>> unpack('>L', pack('>L', 41445))
(41445L,)

And, indeed :
#include 
#include 
int main(void)
{
u_int32_t x, y, z; /* 32 bits unsigned longs */
x = 41445;
/* conv host (little) to network (big endian) long : pack("N",
41445) */
y = htonl(x);
/* conv network (big endian) to host (little) long :
unpack("N", ...) */
z = ntohl(y);
printf("Host : %li\nBig : %li\nHost : %li\n", x, y, z);
return 0;
}

x86_64$ gcc conv.c -o conv ; ./conv
Host : 41445
Big : -442433536
Host : 41445

But still (PHP 5.2.2-dev (cli) (built: Feb 27 2007 22:10:11)) :
x86_64$ php -r 'print_r(unpack("N", pack("N", 41445)));'
Array
(
[1] => -2147442203
)

While on a plain old x86 little endian host (PHP 4.4.0), we get
a different result :
i386_32$ uname -mprsv
OpenBSD 3.9 GENERIC#0 i386 Intel(R) Pentium(R) 4 CPU 1.70GHz
("GenuineIntel" 686-class)
i386_32$ php -r 'print_r(unpack("N", pack("N", 41445)));'
Array
(
[1] => 41445
)

Still on the 64 bits little endian host :
x86_64$ php -r '$a = unpack("N", pack("N", 65536));
printf("$a[1]\n");'
65536   # Ok
x86_64$ php -r '$a = unpack("N", pack("N", 65535));
printf("$a[1]\n");'
-2147418113 # Weird

x86_64$ php -r '$a = unpack("N", pack("N", 0x1234)); printf("0x%x\n",
$a[1]);'
0x1234 # Ok
x86_64$ php -r '$a = unpack("L", pack("N", 0x1234)); printf("0x%x\n",
$a[1]);'
0x3412 # Ok
x86_64$ php -r '$a = u

#40749 [NEW]: pack and unpack erroneous behavior on 64bits hosts

[ben at ateor dot com]

From: ben at ateor dot com
Operating system: OpenBSD amd64 and sparc64
PHP version:  5.2.1
PHP Bug Type: Reproducible crash
Bug description:  pack and unpack erroneous behavior on 64bits hosts

Description:

This is a follow-up on #40543 (http://bugs.php.net/bug.php?id=40543,
since
that bug is closed, I can't add comments). 
Please note : it's not identical to #4053 (other weird behaviors 
are demonstrated).

Iliaa,
Not sure why you suggest to use little endian or host conversions
routines,
but in my standpoint if you reverse twice a number's byte ordering
then you should get the original number back (assuming the number don't
overflows php's internals).

At least, that's the standard behavior for perl and python.

Beside, I can't see why php should handles those endianness conversions
differently on an i386 (32 bits) and on an x86_64 (64 bits), both
having the same byte order.

The following on a 64bit, little endian host :
x86_64$ uname -mprsv
OpenBSD 4.0 GENERIC#0 amd64 AMD Sempron(tm) Processor 3400+

x86_64$ perl -e 'print unpack("N", pack("N", 41445)) ."\n"'
41445

x86_64$ python
Python 2.4.3 (#1, Sep  6 2006, 20:33:08)
[GCC 3.3.5 (propolice)] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
>>> from struct import *
>>> unpack('>L', pack('>L', 41445))
(41445L,)

And, indeed :
#include 
#include 
int main(void)
{
u_int32_t x, y, z; /* 32 bits unsigned longs */
x = 41445;
/* conv host (little) to network (big endian) long : pack("N",
41445) */
y = htonl(x);
/* conv network (big endian) to host (little) long : unpack("N",
...) */
z = ntohl(y);
printf("Host : %li\nBig : %li\nHost : %li\n", x, y, z);
return 0;
}

x86_64$ gcc conv.c -o conv ; ./conv
Host : 41445
Big : -442433536
Host : 41445

But still (PHP 5.2.2-dev (cli) (built: Feb 27 2007 22:10:11)) :
x86_64$ php -r 'print_r(unpack("N", pack("N", 41445)));'
Array
(
[1] => -2147442203
)

While on a plain old x86 little endian host (PHP 4.4.0), we get
a different result :
i386_32$ uname -mprsv
OpenBSD 3.9 GENERIC#0 i386 Intel(R) Pentium(R) 4 CPU 1.70GHz
("GenuineIntel" 686-class)
i386_32$ php -r 'print_r(unpack("N", pack("N", 41445)));'
Array
(
[1] => 41445
)

Still on the 64 bits little endian host :
x86_64$ php -r '$a = unpack("N", pack("N", 65536)); printf("$a[1]\n");'
65536   # Ok
x86_64$ php -r '$a = unpack("N", pack("N", 65535)); printf("$a[1]\n");'
-2147418113 # Weird

x86_64$ php -r '$a = unpack("N", pack("N", 0x1234)); printf("0x%x\n",
$a[1]);'
0x1234 # Ok
x86_64$ php -r '$a = unpack("L", pack("N", 0x1234)); printf("0x%x\n",
$a[1]);'
0x3412 # Ok
x86_64$ php -r '$a = unpack("L", pack("L", 0x)); printf("0x%x\n",
$a[1]);'
0x # Ok
x86_64$ php -r '$a = unpack("N", pack("N", 0x)); printf("0x%x\n",
$a[1]);'
0x8000 # The doc says "N" gives you "always 32 bit", and we
get
   # 8 bytes. No wonder why we overflow.
x86_64$ php -r '$a = unpack("N", pack("N", 0xff )); printf("0x%x\n",
$a[1]);'
0x80ff # Same. Don't tell me 0xff is too large.

And now, all the following tests are on a 64 bits _big endian_ host
(sparc64, running php-5.2.1) :
sparc64$ uname -mprsv
OpenBSD 3.8 GENERIC#607 sparc64 SUNW,UltraSPARC-IIi @ 440 MHz, version 0
FPU
sparc64$ php -r '$a = unpack("N", pack("N", 0x)); printf("0x%x\n",
$a[1]);'
0x # Ok
# The same, but prefixing  to the argument :
sparc64$ php -r '$a = unpack("N", pack("N", 0x)); printf("0x%x\n",
$a[1]);'
0x8000
# Weird (and with "N", we stayed on the host byte order this time).
# Shouldn't 0x == 0x, even on big endian ? Apparently, yes :
sparc64$ php -r 'printf("0x%x\n", 0x);'
0x

# Also, look at this :
sparc64$ php -r '$a = unpack("N", pack("N", 41445)); printf("$a[1]\n");'
41445
# And now let's just remove the line feed (\n) from the above printf :
sparc64$ php -r '$a = unpack("N", pack("N", 41445)); printf("$a[1]");'
-2147442203

# Same for 2^16 -1 / 65535 / 0xfff :
sparc64$ php -r '$a = unpack("N", pack("N", 65535)); printf("$a[1]\n");'
65535

#40461 [NEW]: Test for #39602 fails bogusly

[ben at qolc dot net]

From: ben at qolc dot net
Operating system: Linux RedHat AS 4
PHP version:  5.2.1
PHP Bug Type: *Compile Issues
Bug description:  Test for #39602 fails bogusly

Description:

I had a number of 'make test' failures from 5.2.1, but the one for bug
#39602 concerned me so I checked it out. Running 
sapi/cli/php Zend/tests/bug39602.php
prints "ok", which seems to suggest that the test does NOT fail, so why is
it being reported as a failure? 

I don't know how the test framework works or how to increase the
verbosity; if you need any more info just let me know how to get it...



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

#34636 [Com]: cannot find -lgcrypt

[ben at qolc dot net]

 ID:   34636
 Comment by:   ben at qolc dot net
 Reported By:  webmaster at sunshinearcade dot com
 Status:   No Feedback
 Bug Type: Compile Failure
 Operating System: Fedora Core 3
 PHP Version:  5.0.5
 New Comment:

I hit this bug too, building 5.2.1 on RHEL 4. I think the configure
script should test for that library if --with-xsl is specified; many
distributions have separate packages for the runtime and compiletime
parts of libraries.


Previous Comments:


[2005-10-12 17:03:08] phpbugrep-20050921 at pgregg dot com

This is due to an unresolved dependency in RHEL 4 and FC.

resolve with:
root/pts/3-/mnt/RedHat/RPMS-178#->rpm -i
libgpg-error-devel-1.0-1.i386.rpm libgcrypt-devel-1.2.0-3.i386.rpm

Or whatever versions came with your RedHat CDs

PHP will then make cleanly.

Paul Gregg



[2005-10-04 01:00:03] 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".



[2005-09-26 08:49:45] [EMAIL PROTECTED]

Something you're building against needs libgcrypt (no idea why, but
this
seems to be a rather common FC problem). Try running this:

up2date libgcrypt-devel

(if this doesn't work, you may need to fetch an RPM of libgcrypt from
www.rpmfind.net).

And then compile again.



[2005-09-26 01:26:45] webmaster at sunshinearcade dot com

Description:

make and make install produce error stating ld could not find lgcrypt

PHP 5.0.5
Fedora Core 3
Apache 2.0.54
MySQL 4.1.14

Reproduce code:
---
 ./configure --with-apxs2=/usr/local/apache2/bin/apxs
--with-mysqli=/usr/local/mysql/bin --with-xsl=/usr/lib


Actual result:
--
Zend/zend_execute.lo sapi/cli/php_cli.lo sapi/cli/getopt.lo
main/internal_functions_cli.lo -lcrypt -lexslt -lcrypt -lresolv -lm
-ldl -lnsl -lxml2 -lz -lm -lxml2 -lz -lm -lmysqlclient -lz -lcrypt
-lnsl -lm -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm -lxslt -lxml2 -lz -lm
-lcrypt  -o sapi/cli/php
/usr/bin/ld: cannot find -lgcrypt
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1






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

#40274 [Asn]: Sessions fail with numeric root keys

[ben at vanilla dot net]

 ID:   40274
 User updated by:  ben at vanilla dot net
 Reported By:  ben at vanilla dot net
 Status:   Assigned
 Bug Type: Session related
 Operating System: FreeBSD 6.2
 PHP Version:  5.2.0
 Assigned To:  iliaa
 New Comment:

register_globals is set to Off anyway in php.ini file so 
whilst it sounded like a good idea, its unfortunately not a 
fix for this issue.


Previous Comments:


[2007-02-02 18:57:13] jhansen at unitedmcgill dot com

I had a similar issue on a gentoo box (I could not make changes to
session variables), and came across this blog post:
http://bloggingabout.net/blogs/ramon/archive/2006/10/27/Weird-php-session-behaviour.aspx

Sure enough, turning off register globals fixed the problem for me.
iliaa: Could this be related?



[2007-01-29 13:48:23] ben at vanilla dot net

Juts noticed this is the same with numeric strings and 
ordinary numeric keys.



[2007-01-29 13:40:28] ben at vanilla dot net

Description:

If you set a session variable with the root key as a numeric 
string it fails to save. It also fails to save anything else 
in the array after the numeric rook key string.

This was via FCGI with lighttpd, but also reproduced on Debian 
etch with apache2.

Reproduce code:
---
Set a session :-



Session Set:



Read it :-



Session Read:



Expected result:

I would expect to see the same details in the session from the 
second piece of code as output from the first. :-

Session Read:
Array
(
[Test1] => This should be ok
[123] => Array
(
[test] => This is a test
)

[Test2] => This is not saved
)

Actual result:
--
Session Read:
Array
(
[Test1] => This should be ok
)





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

#40274 [Opn]: Sessions fail with numeric root keys

[ben at vanilla dot net]

 ID:   40274
 User updated by:  ben at vanilla dot net
-Summary:  Sessions fail with numeric string root keys
 Reported By:  ben at vanilla dot net
 Status:   Open
 Bug Type: *Web Server problem
 Operating System: FreeBSD 6.2
 PHP Version:  5.2.0
 New Comment:

Juts noticed this is the same with numeric strings and 
ordinary numeric keys.


Previous Comments:


[2007-01-29 13:40:28] ben at vanilla dot net

Description:

If you set a session variable with the root key as a numeric 
string it fails to save. It also fails to save anything else 
in the array after the numeric rook key string.

This was via FCGI with lighttpd, but also reproduced on Debian 
etch with apache2.

Reproduce code:
---
Set a session :-



Session Set:



Read it :-



Session Read:



Expected result:

I would expect to see the same details in the session from the 
second piece of code as output from the first. :-

Session Read:
Array
(
[Test1] => This should be ok
[123] => Array
(
[test] => This is a test
)

[Test2] => This is not saved
)

Actual result:
--
Session Read:
Array
(
[Test1] => This should be ok
)





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

#40274 [NEW]: Sessions fail with numeric string root keys

[ben at vanilla dot net]

From: ben at vanilla dot net
Operating system: FreeBSD 6.2
PHP version:  5.2.0
PHP Bug Type: *Web Server problem
Bug description:  Sessions fail with numeric string root keys

Description:

If you set a session variable with the root key as a numeric 
string it fails to save. It also fails to save anything else 
in the array after the numeric rook key string.

This was via FCGI with lighttpd, but also reproduced on Debian 
etch with apache2.

Reproduce code:
---
Set a session :-



Session Set:



Read it :-



Session Read:



Expected result:

I would expect to see the same details in the session from the 
second piece of code as output from the first. :-

Session Read:
Array
(
[Test1] => This should be ok
[123] => Array
(
[test] => This is a test
)

[Test2] => This is not saved
)

Actual result:
--
Session Read:
Array
(
[Test1] => This should be ok
)

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

#39460 [Opn]: Crash when using 64-bit fields

[ben at thelemite dot freeserve dot co dot uk]

 ID:   39460
 User updated by:  ben at thelemite dot freeserve dot co dot uk
-Summary:  extra details plus backtrace
 Reported By:  ben at thelemite dot freeserve dot co dot uk
 Status:   Open
 Bug Type: MSSQL related
 Operating System: Solaris 10
 PHP Version:  5.2.0
 New Comment:

-


Previous Comments:


[2006-11-10 13:56:42] ben at thelemite dot freeserve dot co dot uk

Firstly I seem to have narrowed it down a little further.  Crashes only
occur when the first 64-bit field occurs in column 2 (as in my test
table).  If I rearrange the table to something like

TestTable {
   id, int
   value1, int
   value2, bigint
}

suddenly it doesn't crash anymore.  very, very weird.

anyway, the requested backtrace:-

php_mssql_get_column_content_with_type+0x2b8(6c0178, 2, 604998, 3e,
6140d8, 61357c)
_mssql_fetch_batch+0x244(0, 6037c8, , 0, 2, 523858)
zif_mssql_query+0x2a4(2, 604ae0, , 6c0178, 2, ffbfed60)
zend_do_fcall_common_helper_SPEC+0x6f0(ffbfee08, ffbfee08, 1, 688e20,
ffbfee08, 66d9e0)
execute+0x10c(6418d8, 40, 523818, ffbff0dc, 168, 748c)
zend_do_fcall_common_helper_SPEC+0x204(ffbff1e0, 35ebd8, 1, 6418d8,
ffbff1e0, 1)
execute+0x10c(689008, 40, 523818, ffbff3b4, 78, 748c)
zend_do_fcall_common_helper_SPEC+0x204(ffbff3e0, ffbff3e0, 1, 0, 0,
ffbff4a8)
execute+0x10c(5fffa0, ffbffc70, 1e8ff0, ffbff4ac, 4, 2279ac)
zend_execute_scripts+0xe0(7c54, 0, 3, ffbff598, 523598, ffbffc70)
php_execute_script+0x260(ffbffc70, 74, 2d00, 74657374, 0, ffbffa48)
main+0xfb8(2, ffbffd0c, ffbffd18, 50bf40, 0, 0)
_start+0x5c(0, 0, 0, 0, 0, 0)



[2006-11-10 12:58:31] [EMAIL PROTECTED]

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

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





[2006-11-10 12:55:39] ben at thelemite dot freeserve dot co dot uk

Just to clarify; it segfaults both in apache mod and cli.  SQL Server
2003 is being used.  built using gcc 3.4.6, and mssql is built-in (not
DSO loaded)



[2006-11-10 12:44:31] ben at thelemite dot freeserve dot co dot uk

Description:

Executing SELECT * queries on tables that contain 64-bit values (such
as bigints) cause a seg fault.  Segfault occurs in
php_mssql_get_column_content_with_type within php_mssql.c

It's probably system dependent but has been verified on a separate
Solaris 10 setup.

Note the following things though:

1) Running queries containing 64-bit fields that do not contain the
primary key do not seem to cause the crash, e.g: "SELECT value from
TestTable", but individually selecting fields does, e.g: "SELECT
id,value".  Bizzarely "SELECT value,id" doesn't cause a crash.

2) There seems to be some weird allocation issues going on that I have
not been able to get to the bottom of.  In
php_mssql_get_column_content_with_type there is:

case SQLFLT8:
ZVAL_DOUBLE(result, (double) floatcol8(offset));
break; 

If I change it to:

case SQLFLT8:
{
DBFLT8 res_buf;
memcpy(&res_buf, &floatcol8(offset), 8);
ZVAL_DOUBLE(result, res_buf);
}
break; 

It cures the problem!  But (very bizzarely), the following code still
crashes:

res_buf = *(DBFLT8 *)dbdata(mssql_ptr->link,offset);
ZVAL_DOUBLE(result, res_buf);


BUT... It does not crash at the point of reading the data into res_buf.
 It's crashes when something is done with the value!  (Possibly FreeTDS
is corrupting the stack?).

Help!


SunOS 5.10 Generic_118833-17 sun4u sparc SUNW,Ultra-60

PHP 5.1.6 (cli) (built: Oct 26 2006 15:30:54) [same on 5.2.0 as well
though]

FreeTDS 0.63




Reproduce code:
---
Table I have been using for experimenting:-

TestTable {
   id, int
   value, bigint
}

PHP code to generate crash:-

$link = mssql_connect("MyServer","MyUser","MyPassword");
$q = mssql_query("SELECT * from TestTable");
echo $q;

Expected result:

Resource id #X

Actual result:
--
nothing (segfaults when run from CLI)





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

#39460 [Fbk->Opn]: extra details plus backtrace

[ben at thelemite dot freeserve dot co dot uk]

 ID:   39460
 User updated by:  ben at thelemite dot freeserve dot co dot uk
-Summary:  Crash when using 64-bit fields
 Reported By:  ben at thelemite dot freeserve dot co dot uk
-Status:   Feedback
+Status:   Open
 Bug Type: MSSQL related
 Operating System: Solaris 10
 PHP Version:  5.2.0
 New Comment:

Firstly I seem to have narrowed it down a little further.  Crashes only
occur when the first 64-bit field occurs in column 2 (as in my test
table).  If I rearrange the table to something like

TestTable {
   id, int
   value1, int
   value2, bigint
}

suddenly it doesn't crash anymore.  very, very weird.

anyway, the requested backtrace:-

php_mssql_get_column_content_with_type+0x2b8(6c0178, 2, 604998, 3e,
6140d8, 61357c)
_mssql_fetch_batch+0x244(0, 6037c8, , 0, 2, 523858)
zif_mssql_query+0x2a4(2, 604ae0, , 6c0178, 2, ffbfed60)
zend_do_fcall_common_helper_SPEC+0x6f0(ffbfee08, ffbfee08, 1, 688e20,
ffbfee08, 66d9e0)
execute+0x10c(6418d8, 40, 523818, ffbff0dc, 168, 748c)
zend_do_fcall_common_helper_SPEC+0x204(ffbff1e0, 35ebd8, 1, 6418d8,
ffbff1e0, 1)
execute+0x10c(689008, 40, 523818, ffbff3b4, 78, 748c)
zend_do_fcall_common_helper_SPEC+0x204(ffbff3e0, ffbff3e0, 1, 0, 0,
ffbff4a8)
execute+0x10c(5fffa0, ffbffc70, 1e8ff0, ffbff4ac, 4, 2279ac)
zend_execute_scripts+0xe0(7c54, 0, 3, ffbff598, 523598, ffbffc70)
php_execute_script+0x260(ffbffc70, 74, 2d00, 74657374, 0, ffbffa48)
main+0xfb8(2, ffbffd0c, ffbffd18, 50bf40, 0, 0)
_start+0x5c(0, 0, 0, 0, 0, 0)


Previous Comments:


[2006-11-10 12:58:31] [EMAIL PROTECTED]

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

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





[2006-11-10 12:55:39] ben at thelemite dot freeserve dot co dot uk

Just to clarify; it segfaults both in apache mod and cli.  SQL Server
2003 is being used.  built using gcc 3.4.6, and mssql is built-in (not
DSO loaded)



[2006-11-10 12:44:31] ben at thelemite dot freeserve dot co dot uk

Description:

Executing SELECT * queries on tables that contain 64-bit values (such
as bigints) cause a seg fault.  Segfault occurs in
php_mssql_get_column_content_with_type within php_mssql.c

It's probably system dependent but has been verified on a separate
Solaris 10 setup.

Note the following things though:

1) Running queries containing 64-bit fields that do not contain the
primary key do not seem to cause the crash, e.g: "SELECT value from
TestTable", but individually selecting fields does, e.g: "SELECT
id,value".  Bizzarely "SELECT value,id" doesn't cause a crash.

2) There seems to be some weird allocation issues going on that I have
not been able to get to the bottom of.  In
php_mssql_get_column_content_with_type there is:

case SQLFLT8:
ZVAL_DOUBLE(result, (double) floatcol8(offset));
break; 

If I change it to:

case SQLFLT8:
{
DBFLT8 res_buf;
memcpy(&res_buf, &floatcol8(offset), 8);
ZVAL_DOUBLE(result, res_buf);
}
break; 

It cures the problem!  But (very bizzarely), the following code still
crashes:

res_buf = *(DBFLT8 *)dbdata(mssql_ptr->link,offset);
ZVAL_DOUBLE(result, res_buf);


BUT... It does not crash at the point of reading the data into res_buf.
 It's crashes when something is done with the value!  (Possibly FreeTDS
is corrupting the stack?).

Help!


SunOS 5.10 Generic_118833-17 sun4u sparc SUNW,Ultra-60

PHP 5.1.6 (cli) (built: Oct 26 2006 15:30:54) [same on 5.2.0 as well
though]

FreeTDS 0.63




Reproduce code:
---
Table I have been using for experimenting:-

TestTable {
   id, int
   value, bigint
}

PHP code to generate crash:-

$link = mssql_connect("MyServer","MyUser","MyPassword");
$q = mssql_query("SELECT * from TestTable");
echo $q;

Expected result:

Resource id #X

Actual result:
--
nothing (segfaults when run from CLI)





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

#39460 [Opn]: Crash when using 64-bit fields

[ben at thelemite dot freeserve dot co dot uk]

 ID:   39460
 User updated by:  ben at thelemite dot freeserve dot co dot uk
 Reported By:  ben at thelemite dot freeserve dot co dot uk
 Status:   Open
 Bug Type: MSSQL related
 Operating System: Solaris 10
 PHP Version:  5.2.0
 New Comment:

Just to clarify; it segfaults both in apache mod and cli.  SQL Server
2003 is being used.  built using gcc 3.4.6, and mssql is built-in (not
DSO loaded)


Previous Comments:


[2006-11-10 12:44:31] ben at thelemite dot freeserve dot co dot uk

Description:

Executing SELECT * queries on tables that contain 64-bit values (such
as bigints) cause a seg fault.  Segfault occurs in
php_mssql_get_column_content_with_type within php_mssql.c

It's probably system dependent but has been verified on a separate
Solaris 10 setup.

Note the following things though:

1) Running queries containing 64-bit fields that do not contain the
primary key do not seem to cause the crash, e.g: "SELECT value from
TestTable", but individually selecting fields does, e.g: "SELECT
id,value".  Bizzarely "SELECT value,id" doesn't cause a crash.

2) There seems to be some weird allocation issues going on that I have
not been able to get to the bottom of.  In
php_mssql_get_column_content_with_type there is:

case SQLFLT8:
ZVAL_DOUBLE(result, (double) floatcol8(offset));
break; 

If I change it to:

case SQLFLT8:
{
DBFLT8 res_buf;
memcpy(&res_buf, &floatcol8(offset), 8);
ZVAL_DOUBLE(result, res_buf);
}
break; 

It cures the problem!  But (very bizzarely), the following code still
crashes:

res_buf = *(DBFLT8 *)dbdata(mssql_ptr->link,offset);
ZVAL_DOUBLE(result, res_buf);


BUT... It does not crash at the point of reading the data into res_buf.
 It's crashes when something is done with the value!  (Possibly FreeTDS
is corrupting the stack?).

Help!


SunOS 5.10 Generic_118833-17 sun4u sparc SUNW,Ultra-60

PHP 5.1.6 (cli) (built: Oct 26 2006 15:30:54) [same on 5.2.0 as well
though]

FreeTDS 0.63




Reproduce code:
---
Table I have been using for experimenting:-

TestTable {
   id, int
   value, bigint
}

PHP code to generate crash:-

$link = mssql_connect("MyServer","MyUser","MyPassword");
$q = mssql_query("SELECT * from TestTable");
echo $q;

Expected result:

Resource id #X

Actual result:
--
nothing (segfaults when run from CLI)





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

#39460 [NEW]: Crash when using 64-bit fields

[ben at thelemite dot freeserve dot co dot uk]

From: ben at thelemite dot freeserve dot co dot uk
Operating system: Solaris 10
PHP version:  5.2.0
PHP Bug Type: MSSQL related
Bug description:  Crash when using 64-bit fields

Description:

Executing SELECT * queries on tables that contain 64-bit values (such as
bigints) cause a seg fault.  Segfault occurs in
php_mssql_get_column_content_with_type within php_mssql.c

It's probably system dependent but has been verified on a separate Solaris
10 setup.

Note the following things though:

1) Running queries containing 64-bit fields that do not contain the
primary key do not seem to cause the crash, e.g: "SELECT value from
TestTable", but individually selecting fields does, e.g: "SELECT
id,value".  Bizzarely "SELECT value,id" doesn't cause a crash.

2) There seems to be some weird allocation issues going on that I have not
been able to get to the bottom of.  In
php_mssql_get_column_content_with_type there is:

case SQLFLT8:
ZVAL_DOUBLE(result, (double) floatcol8(offset));
break; 

If I change it to:

case SQLFLT8:
{
DBFLT8 res_buf;
memcpy(&res_buf, &floatcol8(offset), 8);
ZVAL_DOUBLE(result, res_buf);
}
break; 

It cures the problem!  But (very bizzarely), the following code still
crashes:

res_buf = *(DBFLT8 *)dbdata(mssql_ptr->link,offset);
ZVAL_DOUBLE(result, res_buf);


BUT... It does not crash at the point of reading the data into res_buf. 
It's crashes when something is done with the value!  (Possibly FreeTDS is
corrupting the stack?).

Help!


SunOS 5.10 Generic_118833-17 sun4u sparc SUNW,Ultra-60

PHP 5.1.6 (cli) (built: Oct 26 2006 15:30:54) [same on 5.2.0 as well
though]

FreeTDS 0.63




Reproduce code:
---
Table I have been using for experimenting:-

TestTable {
   id, int
   value, bigint
}

PHP code to generate crash:-

$link = mssql_connect("MyServer","MyUser","MyPassword");
$q = mssql_query("SELECT * from TestTable");
echo $q;

Expected result:

Resource id #X

Actual result:
--
nothing (segfaults when run from CLI)

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

#39130 [NEW]: Compile failure with the compiler of VC++ 2005

[ben dot yan at msn dot com]

From: ben dot yan at msn dot com
Operating system: Windows
PHP version:  5.2.0RC5
PHP Bug Type: Compile Failure
Bug description:  Compile failure with the compiler of VC++ 2005 

Description:

Compile with VS.NET 2005

c:\program files\microsoft visual studio 8\vc\include\sys\stat.inl(44) :
error C2466: cannot allocate an array of constant size 0
c:\program files\microsoft visual studio 8\vc\include\sys\stat.inl(49) :
error C2466: cannot allocate an array of constant size 0
c:\program files\microsoft visual studio 8\vc\include\sys\utime.inl(39) :
error C2466: cannot allocate an array of constant size 0
c:\program files\microsoft visual studio 8\vc\include\sys\utime.inl(44) :
error C2466: cannot allocate an array of constant size 0
c:\program files\microsoft visual studio 8\vc\include\sys\utime.inl(49) :
error C2466: cannot allocate an array of constant size 0
c:\program files\microsoft visual studio 8\vc\include\sys\utime.inl(78) :
error C2466: cannot allocate an array of constant size 0


Reproduce code:
---
look the zend.h :

...

#include 

/*
 * general definitions
 */

#ifdef ZEND_WIN32
# include "zend_config.w32.h"
# define ZEND_PATHS_SEPARATOR   ';'
#elif defined(XXX)
...
#endif


Expected result:

Look the line 151 at the <../main/config.w32.h>:

/* vs.net 2005 has a 64-bit time_t.  This will likely break
 * 3rdParty libs that were built with older compilers; switch
 * back to 32-bit */
#define _USE_32BIT_TIME_T 1
#define HAVE_STDLIB_H 1


so the config.w32.h should be included first. But it isn't so in the
zend.h:

#include 

/*
 * general definitions
 */

#ifdef ZEND_WIN32
# include "zend_config.w32.h"
# define ZEND_PATHS_SEPARATOR   ';'
#elif defined(XXX)
...
#endif


This would induce the compile error. and if 

#include 

BEHIND the 

#ifdef ZEND_WIN32
# include "zend_config.w32.h"
# define ZEND_PATHS_SEPARATOR   ';'
#elif defined(XXX)
...
#endif

,it will be ok.

Actual result:
--
error C2466: cannot allocate an array of constant size 0

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

#38010 [Fbk->Opn]: Segfault in zend_assign_to_varible

[ben dot tc1415 at gmail dot com]

 ID:   38010
 User updated by:  ben dot tc1415 at gmail dot com
 Reported By:  ben dot tc1415 at gmail dot com
-Status:   Feedback
+Status:   Open
 Bug Type: MySQLi related
 Operating System: Linux
 PHP Version:  5CVS-2006-07-04 (CVS)
 New Comment:

This is probably not a bug, I think I may have a broken version of gcc
on my linux box, sorry for wasting everyone's time.


Previous Comments:


[2006-07-05 07:10:08] [EMAIL PROTECTED]

We would really need a short reproducable script though...



[2006-07-04 22:20:22] ben dot tc1415 at gmail dot com

I don't seem to be able to produce an actual script, but I have
narrowed it down to MySQLi. All being well I'll try and produce a
script that causes this tomorrow. I've re-catergoriesed the bug to
MySQLi though.



[2006-07-04 22:01:33] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.



[2006-07-04 21:34:43] ben dot tc1415 at gmail dot com

Description:

When running complex scripts, e.g. phpMyAdmin, php segfaults. This
seems to be happening inside the zend engine - in the
zend_assign_to_varible. It also occurs in php 5.1.4.

Reproduce code:
---
I cannot yet find any other reproduce code other than running
phpMyAdmin :(

Expected result:

phpMyAdmin runs

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213146208 (LWP 32409)]
0x0101b3f5 in zend_assign_to_variable (result=0xa85d114,
op1=0xa85d128,
op2=0xa85d13c, value=0xa85d140, type=1, Ts=0xb7afffe0,
tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_execute.c:273
273 if
(zend_hash_quick_find(EG(active_symbol_table), cv->na   me,
cv->name_len+1, cv->hash_value, (void **)ptr)==FAILURE) {
(gdb) bt
#0  0x0101b3f5 in zend_assign_to_variable (result=0xa85d114,
op1=0xa85d128,
op2=0xa85d13c, value=0xa85d140, type=1, Ts=0xb7afffe0,
tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_execute.c:273
#1  0x0101b9ae in ZEND_ASSIGN_SPEC_CV_CONST_HANDLER
(execute_data=0xb7b049cc,
tsrm_ls=0xa47c3a0) at
/home/blewis/php-src/Zend/zend_vm_execute.h:20842
#2  0x00fed85c in execute (op_array=0xa82ed48, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:92
#3  0x01037d38 in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER (
execute_data=0xb7b05cbc, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:19527
#4  0x00fed85c in execute (op_array=0xa788300, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:92
#5  0x00ff2e9b in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (
execute_data=0xb7b0954c, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:1971
#6  0x00fed85c in execute (op_array=0xa45af58, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:92
#7  0x00ff2e9b in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (
execute_data=0xb7b0af9c, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:1971
#8  0x00fed85c in execute (op_array=0xa76d6f0, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:92
#9  0x00fc5a3f in zend_execute_scripts (type=8, tsrm_ls=0xa47c3a0,
retval=Variab   le "retval" is not available.
)
at /home/blewis/php-src/Zend/zend.c:1109
#10 0x00f77ea0 in php_execute_script (primary_file=0xb7b0d2e4,
tsrm_ls=0xa47c3a0) at /home/blewis/php-src/main/main.c:1732
#11 0x01059526 in php_handler (r=0xa3fe328)
at /home/blewis/php-src/sapi/apache2handler/sapi_apache2.c:586
#12 0x080794d9 in ap_run_handler (r=0xa3fe328) at config.c:157
#13 0x0807c631 in ap_invoke_handler (r=0xa3fe328) at config.c:371
#14 0x080b2b48 in ap_process_request (r=0xa3fe328) at
http_request.c:258
#15 0x080afe5b in ap_process_http_connection (c=0xa2fad18) at
http_core.c:172
#16 0x080802b9 in ap_run_process_connection (c=0xa2fad18) at
connection.c:43
#17 0x080bcf94 in worker_thread (thd=0x9f15f10, dummy=0xa2700b8)
at worker.c:531
#18 0x00c0a686 in dummy_worker (opaque=0x9f15f10)
at threadproc/unix/thread.c:138
#19 0x00119255 in start_thread () from /lib/libpthread.so.0
#20 0x003bf92e in clone () from /lib/libc.so.6






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

#38010 [Fbk->Opn]: Segfault in zend_assign_to_varible

[ben dot tc1415 at gmail dot com]

 ID:   38010
 User updated by:  ben dot tc1415 at gmail dot com
 Reported By:  ben dot tc1415 at gmail dot com
-Status:   Feedback
+Status:   Open
-Bug Type: Reproducible crash
+Bug Type: MySQLi related
 Operating System: Linux
 PHP Version:  5CVS-2006-07-04 (CVS)
 New Comment:

I don't seem to be able to produce an actual script, but I have
narrowed it down to MySQLi. All being well I'll try and produce a
script that causes this tomorrow. I've re-catergoriesed the bug to
MySQLi though.


Previous Comments:


[2006-07-04 22:01:33] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.



[2006-07-04 21:34:43] ben dot tc1415 at gmail dot com

Description:

When running complex scripts, e.g. phpMyAdmin, php segfaults. This
seems to be happening inside the zend engine - in the
zend_assign_to_varible. It also occurs in php 5.1.4.

Reproduce code:
---
I cannot yet find any other reproduce code other than running
phpMyAdmin :(

Expected result:

phpMyAdmin runs

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213146208 (LWP 32409)]
0x0101b3f5 in zend_assign_to_variable (result=0xa85d114,
op1=0xa85d128,
op2=0xa85d13c, value=0xa85d140, type=1, Ts=0xb7afffe0,
tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_execute.c:273
273 if
(zend_hash_quick_find(EG(active_symbol_table), cv->na   me,
cv->name_len+1, cv->hash_value, (void **)ptr)==FAILURE) {
(gdb) bt
#0  0x0101b3f5 in zend_assign_to_variable (result=0xa85d114,
op1=0xa85d128,
op2=0xa85d13c, value=0xa85d140, type=1, Ts=0xb7afffe0,
tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_execute.c:273
#1  0x0101b9ae in ZEND_ASSIGN_SPEC_CV_CONST_HANDLER
(execute_data=0xb7b049cc,
tsrm_ls=0xa47c3a0) at
/home/blewis/php-src/Zend/zend_vm_execute.h:20842
#2  0x00fed85c in execute (op_array=0xa82ed48, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:92
#3  0x01037d38 in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER (
execute_data=0xb7b05cbc, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:19527
#4  0x00fed85c in execute (op_array=0xa788300, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:92
#5  0x00ff2e9b in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (
execute_data=0xb7b0954c, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:1971
#6  0x00fed85c in execute (op_array=0xa45af58, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:92
#7  0x00ff2e9b in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (
execute_data=0xb7b0af9c, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:1971
#8  0x00fed85c in execute (op_array=0xa76d6f0, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:92
#9  0x00fc5a3f in zend_execute_scripts (type=8, tsrm_ls=0xa47c3a0,
retval=Variab   le "retval" is not available.
)
at /home/blewis/php-src/Zend/zend.c:1109
#10 0x00f77ea0 in php_execute_script (primary_file=0xb7b0d2e4,
tsrm_ls=0xa47c3a0) at /home/blewis/php-src/main/main.c:1732
#11 0x01059526 in php_handler (r=0xa3fe328)
at /home/blewis/php-src/sapi/apache2handler/sapi_apache2.c:586
#12 0x080794d9 in ap_run_handler (r=0xa3fe328) at config.c:157
#13 0x0807c631 in ap_invoke_handler (r=0xa3fe328) at config.c:371
#14 0x080b2b48 in ap_process_request (r=0xa3fe328) at
http_request.c:258
#15 0x080afe5b in ap_process_http_connection (c=0xa2fad18) at
http_core.c:172
#16 0x080802b9 in ap_run_process_connection (c=0xa2fad18) at
connection.c:43
#17 0x080bcf94 in worker_thread (thd=0x9f15f10, dummy=0xa2700b8)
at worker.c:531
#18 0x00c0a686 in dummy_worker (opaque=0x9f15f10)
at threadproc/unix/thread.c:138
#19 0x00119255 in start_thread () from /lib/libpthread.so.0
#20 0x003bf92e in clone () from /lib/libc.so.6






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

#38010 [NEW]: Segfault in zend_assign_to_varible

[ben dot tc1415 at gmail dot com]

From: ben dot tc1415 at gmail dot com
Operating system: Linux
PHP version:  5CVS-2006-07-04 (CVS)
PHP Bug Type: Reproducible crash
Bug description:  Segfault in zend_assign_to_varible

Description:

When running complex scripts, e.g. phpMyAdmin, php segfaults. This seems
to be happening inside the zend engine - in the zend_assign_to_varible. It
also occurs in php 5.1.4.

Reproduce code:
---
I cannot yet find any other reproduce code other than running phpMyAdmin
:(

Expected result:

phpMyAdmin runs

Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213146208 (LWP 32409)]
0x0101b3f5 in zend_assign_to_variable (result=0xa85d114, op1=0xa85d128,
op2=0xa85d13c, value=0xa85d140, type=1, Ts=0xb7afffe0,
tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_execute.c:273
273 if (zend_hash_quick_find(EG(active_symbol_table),
cv->na   me, cv->name_len+1, cv->hash_value, (void **)ptr)==FAILURE) {
(gdb) bt
#0  0x0101b3f5 in zend_assign_to_variable (result=0xa85d114,
op1=0xa85d128,
op2=0xa85d13c, value=0xa85d140, type=1, Ts=0xb7afffe0,
tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_execute.c:273
#1  0x0101b9ae in ZEND_ASSIGN_SPEC_CV_CONST_HANDLER
(execute_data=0xb7b049cc,
tsrm_ls=0xa47c3a0) at
/home/blewis/php-src/Zend/zend_vm_execute.h:20842
#2  0x00fed85c in execute (op_array=0xa82ed48, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:92
#3  0x01037d38 in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER (
execute_data=0xb7b05cbc, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:19527
#4  0x00fed85c in execute (op_array=0xa788300, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:92
#5  0x00ff2e9b in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (
execute_data=0xb7b0954c, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:1971
#6  0x00fed85c in execute (op_array=0xa45af58, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:92
#7  0x00ff2e9b in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER (
execute_data=0xb7b0af9c, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:1971
#8  0x00fed85c in execute (op_array=0xa76d6f0, tsrm_ls=0xa47c3a0)
at /home/blewis/php-src/Zend/zend_vm_execute.h:92
#9  0x00fc5a3f in zend_execute_scripts (type=8, tsrm_ls=0xa47c3a0,
retval=Variab   le "retval" is not available.
)
at /home/blewis/php-src/Zend/zend.c:1109
#10 0x00f77ea0 in php_execute_script (primary_file=0xb7b0d2e4,
tsrm_ls=0xa47c3a0) at /home/blewis/php-src/main/main.c:1732
#11 0x01059526 in php_handler (r=0xa3fe328)
at /home/blewis/php-src/sapi/apache2handler/sapi_apache2.c:586
#12 0x080794d9 in ap_run_handler (r=0xa3fe328) at config.c:157
#13 0x0807c631 in ap_invoke_handler (r=0xa3fe328) at config.c:371
#14 0x080b2b48 in ap_process_request (r=0xa3fe328) at http_request.c:258
#15 0x080afe5b in ap_process_http_connection (c=0xa2fad18) at
http_core.c:172
#16 0x080802b9 in ap_run_process_connection (c=0xa2fad18) at
connection.c:43
#17 0x080bcf94 in worker_thread (thd=0x9f15f10, dummy=0xa2700b8)
at worker.c:531
#18 0x00c0a686 in dummy_worker (opaque=0x9f15f10)
at threadproc/unix/thread.c:138
#19 0x00119255 in start_thread () from /lib/libpthread.so.0
#20 0x003bf92e in clone () from /lib/libc.so.6


-- 
Edit bug report at http://bugs.php.net/?id=38010&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=38010&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=38010&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=38010&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38010&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=38010&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=38010&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38010&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38010&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=38010&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38010&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=38010&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=38010&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38010&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=38010&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38010&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38010&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=38010&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=3801

#28915 [Com]: php.exe - Application Error

[ben at remoteinformation dot com dot au]

 ID:   28915
 Comment by:   ben at remoteinformation dot com dot au
 Reported By:  spam at pasoft dot org
 Status:   No Feedback
 Bug Type: Unknown/Other Function
 Operating System: Windows/Linux
 PHP Version:  Irrelevant
 New Comment:

Hello, I have just started receiving this bug, on php 4.4.3-
dev and using Mapserver 4.8.3 (php_mapscript).

It is on a WinXPSP2 machine, using Apache 2.0.55 (win32)


As described below, it is sporadic (one map draws fine, the 
next one also renders properly, but the php.exe message 
appears and the system hangs until I click OK. I don't get 
any debug message, and although I followed the instructions 
to backtrace, I couldn't get them to work on the windows 
machine - is there any other place I could look.


Previous Comments:


[2004-07-04 01:00:03] 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".



[2004-06-25 10:42:22] [EMAIL PROTECTED]

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

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





[2004-06-25 04:25:32] spam at pasoft dot org

I get a php.exe Application Error, but unlike other cases, I get the
error at
random.  It will happen on one page of my project one day, and a
totally
different page the next, which makes it nearly impossible to track
down
and to replicate easily.
An interesting thing about this error is that it occurs in both
windows
and linux versions of PHP with absolutley no extensions installed, and
is present in all versions of PHP I've trade to date.

The error reads as fallows on my windows machine:
php.exe - Application Error
The instruction at "0x100bec17" referenced memory at "0x6526176".  The
memory could not be "written".

Click on OK to terminate the program
Click on CANCEL to debug the program

On my linux machine, I just get a blank page when the error occurs (no
real error message)

I'm unsure of what to do to help you guys find the problem, this
project
is a fairly large and depending on the bugs mood, it could occur
anywhere.

I'm sure its not a configuration problem.

My project makes use of:
Object Oriented Design
Sessions
MySQL
Expat (XML)
File I/O

It all started after I rewrote my XML parser, so I've enclosed the
link
to it, for inspection.

I would greatly appreciate some instruction that would better help you
track down this problem.

Its been driving me nuts for over a year, and any help you could
provide
would help me sleep better at night

Thanks
-Sarev0k

Reproduce code:
---
http://www.pasoft.org/temp/parser.txt



[2004-06-25 04:19:06] spam at pasoft dot org

Description:

 get the
php.exe Application Error, but in my case the error is completely
random.  It will happen on one page of my project one day, and a
totally
different page the next, which makes it nearly impossible to track
down
and to replicate easily.
An interesting thing about this error is that it occurs in both
windows
and linux versions of PHP with absolutley no extensions installed, and
is present in all versions of PHP I've trade to date.

The error reads as fallows on my windows machine:
php.exe - Application Error
The instruction at "0x100bec17" referenced memory at "0x6526176".  The
memory could not be "written".

Click on OK to terminate the program
Click on CANCEL to debug the program

On my linux machine, I just get a blank page when the error occurs (no
real error message)

I'm unsure of what to do to help you guys find the problem, this
project
is a fairly large and depending on the bugs mood, it could occur
anywhere.

I'm sure its not a configuration problem.

My project makes use of:
Object Oriented Design
Sessions
MySQL
Expat (XML)
File I/O

It all started after I rewrote my XML parser, so I've enclosed the link
to it, for inspection.

I would greatly appreciate some instruction that would better help you
track down this problem.

Its been driving me nuts for over a year, and any help you could
provide
would help me sleep better at night

Thanks
-Sarev0k

Reproduce code:
---
http://www.pasoft.org/temp/parser.txt

#36732 [Opn]: configargs req_extensions & x509_extensions broken

[ben at psc dot edu]

 ID:   36732
 User updated by:  ben at psc dot edu
 Reported By:  ben at psc dot edu
 Status:   Open
 Bug Type: OpenSSL related
 Operating System: Linux 2.6 / FC4
 PHP Version:  5.1.2
 New Comment:

typo in location of 4.4.1 and 4.4.2 patch.

correct spelling is:
  php-4.4.2-openssl-extensions-fix.patch


Previous Comments:


[2006-03-14 05:30:12] ben at psc dot edu

Description:

According to the PHP manual, configargs keys req_extensions and
x509_extensions can be used to select which extensions are used when
creating a CSR and x509 certificate, respectively.

There are [what appear to be] a few mistakes in ext/openssl/openssl.c
which result in neither of these two options working properly.

Bug #31638 appears to have reported this issue, but has not been
resolved.


The following patches resolve this issue, and are available at
http://www.psc.edu/~ben/patches/php/

  php-4.4.2-openssl-extentions-fix.patch
Tested with php-4.4.1 and php-4.4.2

  php-5.1.2-openssl-extensions-fix.patch
Tested with only php-5.1.2

Reproduce code:
---
$configargs = array(
"req_extensions" => "v3_req",
"x509_extensions" => "usr_cert"
);

$dn = array(
"countryName" => "GB",
"stateOrProvinceName" => "Berkshire",
"localityName" => "Newbury",
"organizationName" => "My Company Ltd",
"commonName" => "Demo Cert"
);

$key = openssl_pkey_new();
$csr = openssl_csr_new($dn, $key, $configargs);
$crt = openssl_csr_sign($csr, NULL, $key, 365, $configargs);

openssl_csr_export($csr, $str, false);
print $str . "\n\n";
openssl_x509_export($crt, $str, false);
print $str;

Expected result:

Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd,
CN=Demo Cert
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:e7:16:aa:4c:d2:b9:53:5b:50:74:ef:b8:7b:e3:
5f:1c:a3:12:f0:12:7f:9b:94:2b:1c:d7:c6:6e:99:
2a:4f:7a:59:b2:99:6f:43:a2:e3:85:93:09:d7:ff:
f0:d4:ff:05:de:e9:79:17:67:1e:23:f5:e9:41:41:
18:f3:31:80:16:9a:dd:56:f3:22:fb:44:7d:ca:40:
2b:fa:e1:6b:28:54:99:d5:34:69:18:dd:16:47:84:
54:fc:a0:0d:8f:9e:db:08:44:51:fe:5a:48:c7:61:
3c:34:6b:dc:af:b3:dc:37:7c:52:34:f8:0e:38:be:
25:45:96:ca:2f:b6:5e:eb:f5
Exponent: 65537 (0x10001)
Attributes:
Requested Extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
Signature Algorithm: md5WithRSAEncryption
67:0f:ab:26:a5:9e:6e:00:4d:71:39:a2:cc:c9:f6:67:32:e2:
5c:bd:21:4d:b9:e0:bb:8f:e8:d5:d6:42:3c:20:71:fc:08:7a:
00:b2:97:7d:b1:47:48:f4:a7:86:f5:7f:86:d7:9c:ca:ae:0e:
03:db:c5:df:c6:4b:ea:31:37:75:4f:1e:72:3d:d5:e3:89:9f:
82:ef:3d:88:d2:fe:fd:25:5d:d0:da:0e:a9:19:2c:e5:14:ee:
3c:90:0e:ed:f3:25:6f:36:29:39:a3:23:8b:b6:62:1a:fb:b3:
c7:ff:c6:73:cc:66:50:b4:1e:72:79:f6:8b:8c:67:99:f7:8b:
81:ea
-BEGIN CERTIFICATE REQUEST-
MIIByTCCATICAQAwYDELMAkGA1UEBhMCR0IxEjAQBgNVBAgTCUJlcmtzaGlyZTEQ
MA4GA1UEBxMHTmV3YnVyeTEXMBUGA1UEChMOTXkgQ29tcGFueSBMdGQxEjAQBgNV
BAMTCURlbW8gQ2VydDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA5xaqTNK5
U1tQdO+4e+NfHKMS8BJ/m5QrHNfGbpkqT3pZsplvQ6LjhZMJ1//w1P8F3ul5F2ce
I/XpQUEY8zGAFprdVvMi+0R9ykAr+uFrKFSZ1TRpGN0WR4RU/KANj57bCERR/lpI
x2E8NGvcr7PcN3xSNPgOOL4lRZbKL7Ze6/UCAwEAAaApMCcGCSqGSIb3DQEJDjEa
MBgwCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwDQYJKoZIhvcNAQEEBQADgYEAZw+r
JqWebgBNcTmizMn2ZzLiXL0hTbngu4/o1dZCPCBx/Ah6ALKXfbFHSPSnhvV/htec
yq4OA9vF38ZL6jE3dU8ecj3V44mfgu89iNL+/SVd0NoOqRks5RTuPJAO7fMlbzYp
OaMji7ZiGvuzx//Gc8xmULQecnn2i4xnmfeLgeo=
-END CERTIFICATE REQUEST-


Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd,
CN=Demo Cert
Validity
Not Before: Mar 14 04:02:52 2006 GMT
Not After : Mar 14 04:02:52 2007 GMT
Subject: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd,
CN=Demo Cert
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:e7:16:aa:4c:d2:b9:53:5b:50:74:ef:b8:7b:e3:
5f:1c:a3:12:f0:12:7f:9b:94:2b:1c:d7:c6:6e:99:
2a:4f

#36732 [NEW]: configargs req_extensions & x509_extensions broken

[ben at psc dot edu]

From: ben at psc dot edu
Operating system: Linux 2.6 / FC4
PHP version:  5.1.2
PHP Bug Type: OpenSSL related
Bug description:  configargs req_extensions & x509_extensions broken

Description:

According to the PHP manual, configargs keys req_extensions and
x509_extensions can be used to select which extensions are used when
creating a CSR and x509 certificate, respectively.

There are [what appear to be] a few mistakes in ext/openssl/openssl.c
which result in neither of these two options working properly.

Bug #31638 appears to have reported this issue, but has not been
resolved.


The following patches resolve this issue, and are available at
http://www.psc.edu/~ben/patches/php/

  php-4.4.2-openssl-extentions-fix.patch
Tested with php-4.4.1 and php-4.4.2

  php-5.1.2-openssl-extensions-fix.patch
Tested with only php-5.1.2

Reproduce code:
---
$configargs = array(
"req_extensions" => "v3_req",
"x509_extensions" => "usr_cert"
);

$dn = array(
"countryName" => "GB",
"stateOrProvinceName" => "Berkshire",
"localityName" => "Newbury",
"organizationName" => "My Company Ltd",
"commonName" => "Demo Cert"
);

$key = openssl_pkey_new();
$csr = openssl_csr_new($dn, $key, $configargs);
$crt = openssl_csr_sign($csr, NULL, $key, 365, $configargs);

openssl_csr_export($csr, $str, false);
print $str . "\n\n";
openssl_x509_export($crt, $str, false);
print $str;

Expected result:

Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd, CN=Demo
Cert
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:e7:16:aa:4c:d2:b9:53:5b:50:74:ef:b8:7b:e3:
5f:1c:a3:12:f0:12:7f:9b:94:2b:1c:d7:c6:6e:99:
2a:4f:7a:59:b2:99:6f:43:a2:e3:85:93:09:d7:ff:
f0:d4:ff:05:de:e9:79:17:67:1e:23:f5:e9:41:41:
18:f3:31:80:16:9a:dd:56:f3:22:fb:44:7d:ca:40:
2b:fa:e1:6b:28:54:99:d5:34:69:18:dd:16:47:84:
54:fc:a0:0d:8f:9e:db:08:44:51:fe:5a:48:c7:61:
3c:34:6b:dc:af:b3:dc:37:7c:52:34:f8:0e:38:be:
25:45:96:ca:2f:b6:5e:eb:f5
Exponent: 65537 (0x10001)
Attributes:
Requested Extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment
Signature Algorithm: md5WithRSAEncryption
67:0f:ab:26:a5:9e:6e:00:4d:71:39:a2:cc:c9:f6:67:32:e2:
5c:bd:21:4d:b9:e0:bb:8f:e8:d5:d6:42:3c:20:71:fc:08:7a:
00:b2:97:7d:b1:47:48:f4:a7:86:f5:7f:86:d7:9c:ca:ae:0e:
03:db:c5:df:c6:4b:ea:31:37:75:4f:1e:72:3d:d5:e3:89:9f:
82:ef:3d:88:d2:fe:fd:25:5d:d0:da:0e:a9:19:2c:e5:14:ee:
3c:90:0e:ed:f3:25:6f:36:29:39:a3:23:8b:b6:62:1a:fb:b3:
c7:ff:c6:73:cc:66:50:b4:1e:72:79:f6:8b:8c:67:99:f7:8b:
81:ea
-BEGIN CERTIFICATE REQUEST-
MIIByTCCATICAQAwYDELMAkGA1UEBhMCR0IxEjAQBgNVBAgTCUJlcmtzaGlyZTEQ
MA4GA1UEBxMHTmV3YnVyeTEXMBUGA1UEChMOTXkgQ29tcGFueSBMdGQxEjAQBgNV
BAMTCURlbW8gQ2VydDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA5xaqTNK5
U1tQdO+4e+NfHKMS8BJ/m5QrHNfGbpkqT3pZsplvQ6LjhZMJ1//w1P8F3ul5F2ce
I/XpQUEY8zGAFprdVvMi+0R9ykAr+uFrKFSZ1TRpGN0WR4RU/KANj57bCERR/lpI
x2E8NGvcr7PcN3xSNPgOOL4lRZbKL7Ze6/UCAwEAAaApMCcGCSqGSIb3DQEJDjEa
MBgwCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwDQYJKoZIhvcNAQEEBQADgYEAZw+r
JqWebgBNcTmizMn2ZzLiXL0hTbngu4/o1dZCPCBx/Ah6ALKXfbFHSPSnhvV/htec
yq4OA9vF38ZL6jE3dU8ecj3V44mfgu89iNL+/SVd0NoOqRks5RTuPJAO7fMlbzYp
OaMji7ZiGvuzx//Gc8xmULQecnn2i4xnmfeLgeo=
-END CERTIFICATE REQUEST-


Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd, CN=Demo
Cert
Validity
Not Before: Mar 14 04:02:52 2006 GMT
Not After : Mar 14 04:02:52 2007 GMT
Subject: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd, CN=Demo
Cert
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:e7:16:aa:4c:d2:b9:53:5b:50:74:ef:b8:7b:e3:
5f:1c:a3:12:f0:12:7f:9b:94:2b:1c:d7:c6:6e:99:
2a:4f:7a:59:b2:99:6f:43:a2:e3:85:93:09:d7:ff:
f0:d4:ff:05:de:e9:79:17:67:1e:23:f5:e9:41:41:
18:f3:31:80:16:9a:dd:56:f3:22:fb:44:7d:ca:40:
2b:fa:e1:6b:28:54:99:d5:34:69:18:dd:16:47:84:
54:fc:a0:0d:8f:

#36039 [Opn]: intVal broken for calculated 1999

[ben at bbbsystems dot net]

 ID:   36039
 User updated by:  ben at bbbsystems dot net
 Reported By:  ben at bbbsystems dot net
 Status:   Open
 Bug Type: *Math Functions
 Operating System: Free BSD 5.3
 PHP Version:  5.1.2
 New Comment:

The problem also happens with the function floor( )


Previous Comments:


[2006-01-17 00:57:47] ben at bbbsystems dot net

Description:

This bug is for the function intVal( ), and I also found that
typecasting with (int) produces the same results.

This is a very weird bug I encountered because of a price that is 19.99
and our processor requires it to be sent as 1999.  1999 is the only
value I was able to find that doesn't work correctly, but I'm sure
there are others.

I also checked it on a linux system with an older version of php 4 and
got the same results.  I upgraded our php to 5.1.2 then tried it again
after it failed.  I suspect the bug to be a floating point issue, but
I'm not certain of it.

-Ben Laurienti
BBB Systems, LLC

Reproduce code:
---
\n";
echo $test2 . "\n";
echo $test3 . "\n";
?>

Expected result:

1999
1999
1999

Actual result:
--
1999
1998
1999





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