[PHP-BUG] Bug #53404 [NEW]: Statically link libevent into PHP-FPM
From: Operating system: Linux PHP version: 5.3.3 Package: FPM related Bug Type: Bug Bug description:Statically link libevent into PHP-FPM Description: Some of us would like to have the possibility to statically link the libevent into the php-fpm binary in order to simplify the deployment aka put just a single binary to the production machines. The configure fails to pick up the static library version of libevent. Test script: --- cd ~/libevent-1.4.14b ./configure --prefix=/usr/local/libevent-1.4.14b --disable-shared make ; make install cd ~/php-5.3.3 ./configure --enable-fpm --with-libevent-dir=/usr/local/libevent-1.4.14b ... Expected result: Successful configuration and build. Actual result: -- checking for libevent = 1.4.11 install prefix... configure: error: Could not find libevent = 1.4.11 in /usr/local/libevent-1.4.14b -- Edit bug report at http://bugs.php.net/bug.php?id=53404edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53404r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53404r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53404r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53404r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53404r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53404r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53404r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53404r=needscript Try newer version: http://bugs.php.net/fix.php?id=53404r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53404r=support Expected behavior: http://bugs.php.net/fix.php?id=53404r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53404r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53404r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53404r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53404r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53404r=dst IIS Stability: http://bugs.php.net/fix.php?id=53404r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53404r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53404r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53404r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53404r=mysqlcfg
Bug #53076 [Com]: file_put_contents doesn't release the LOCK_EX
Edit report at http://bugs.php.net/bug.php?id=53076edit=1
ID: 53076
Comment by: admin at saltwaterc dot net
Reported by:admin at saltwaterc dot net
Summary:file_put_contents doesn't release the LOCK_EX
Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: Irrelevant
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
Bogus? Seriously? That's a three line patch. A simple if. Now look, I
am not a wannabe researcher trying to find theoretical problems with
your scripting engine. I'm an actual system administrator, doing
actual live PHP deployments and that condition actually broke our
application (specifically an IPB product, forum + support module) with
our actual network filesystem. Real life situation, not Hollywood
junk.
I may not have your operating system, specifically *nix, experience,
but I can recognize an issue when it is present. I already told you
that not having that explicit unlock may cause deadlocks, depending
onto the *filesystem implementation*. I know, it's a very specific
situation, would (mostly?) happen on buggy (network?) filesystems, but
this attitude: it's their junk, let them fix it won't help anybody
when in production scenarios the applications start to crash.
I know that probably this would be ignored, and sometimes ignorance is
bliss, but ignorance doesn't fix software. Just don't tell me that I
am the one that doesn't understand the situation since you keep
quoting: closing the file will both release the locks and flush the
data to disk - this is simply not universally true. I rest my case,
do whatever you want.
Previous Comments:
[2010-11-25 20:39:47] il...@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Closing the file will both release the locks and flush the data to disk.
If you
have an interrupt happen it between, the same could be true before flush
or
unlock.
[2010-10-16 14:56:31] admin at saltwaterc dot net
My bad. I did the bug report in a little bit hurry.
The 'actual result' is broken since I use my patch
for my PHP build, while keeping an eye on my old
strace outputs, with actual production setup:
Invision Power Board + Minify + PHP 5.3.3 (PHP-FPM)
+ Ubuntu Server 10.04. Therefore, it's kinda 'emulated'.
But it does happen with the standard PHP of doing things.
However, the lock release when the stream is closed
depends onto the filesystem implementation.
See this changelog:
http://ftp.zresearch.com/pub/gluster/glusterfs/3.0/3.0.3/GlusterFS_3.0.3_Release
_Notes.pdf
I know that usually this happens on buggy filesystems
that have issues with advisory locking, but in my
humble opinion this doesn't mean that the file_put_contents
should not include those 3 lines of code that make things
to be a little bit stable from now on such as avoiding deadlocks
when things go unplanned. As I said, this specific conditions
took down one of our production virtual hosts.
[2010-10-16 09:52:46] cataphr...@php.net
I don't get an explicit LOCK_UN either, but it should be unnecessary, as
locks are released when the file is closed.
@crrodriguez
There's no need to call php_stream_flush as that is already done when
the stream is closed. See:
http://lxr.php.net/xref/PHP_TRUNK/main/streams/streams.c#_php_stream_free
[2010-10-16 02:20:24] crrodriguez at opensuse dot org
Patch ACK'ed , looks correct.
BUT, you should also call php_stream_flush before closing the stream..
to make it
slightly more reliable though there is still no warranty that the file
is stored
on the filesystem...
article worth reading
http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-
and-the-zero-length-file-problem/ ;)
[2010-10-16 02:12:58] ras...@php.net
Note the example code does an explicit unlock. Are you sure that isn't
what you
are seeing there?
If you try: strace php -r 'file_put_contents('foo', 'bar', LOCK_EX);'
Do you see an unlock still?
I get:
open(/home/rasmus/foo, O_WRONLY|O_CREAT, 0666) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
flock(3
Bug #53076 [Com]: file_put_contents doesn't release the LOCK_EX
Edit report at http://bugs.php.net/bug.php?id=53076edit=1
ID: 53076
Comment by: admin at saltwaterc dot net
Reported by:admin at saltwaterc dot net
Summary:file_put_contents doesn't release the LOCK_EX
Status: Feedback
Type: Bug
Package:Scripting Engine problem
Operating System: Irrelevant
PHP Version:5.3.3
Block user comment: N
New Comment:
My bad. I did the bug report in a little bit hurry.
The 'actual result' is broken since I use my patch
for my PHP build, while keeping an eye on my old
strace outputs, with actual production setup:
Invision Power Board + Minify + PHP 5.3.3 (PHP-FPM)
+ Ubuntu Server 10.04. Therefore, it's kinda 'emulated'.
But it does happen with the standard PHP of doing things.
However, the lock release when the stream is closed
depends onto the filesystem implementation.
See this changelog:
http://ftp.zresearch.com/pub/gluster/glusterfs/3.0/3.0.3/GlusterFS_3.0.3_Release
_Notes.pdf
I know that usually this happens on buggy filesystems
that have issues with advisory locking, but in my
humble opinion this doesn't mean that the file_put_contents
should not include those 3 lines of code that make things
to be a little bit stable from now on such as avoiding deadlocks
when things go unplanned. As I said, this specific conditions
took down one of our production virtual hosts.
Previous Comments:
[2010-10-16 09:52:46] cataphr...@php.net
I don't get an explicit LOCK_UN either, but it should be unnecessary, as
locks are released when the file is closed.
@crrodriguez
There's no need to call php_stream_flush as that is already done when
the stream is closed. See:
http://lxr.php.net/xref/PHP_TRUNK/main/streams/streams.c#_php_stream_free
[2010-10-16 02:20:24] crrodriguez at opensuse dot org
Patch ACK'ed , looks correct.
BUT, you should also call php_stream_flush before closing the stream..
to make it
slightly more reliable though there is still no warranty that the file
is stored
on the filesystem...
article worth reading
http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-
and-the-zero-length-file-problem/ ;)
[2010-10-16 02:12:58] ras...@php.net
Note the example code does an explicit unlock. Are you sure that isn't
what you
are seeing there?
If you try: strace php -r 'file_put_contents('foo', 'bar', LOCK_EX);'
Do you see an unlock still?
I get:
open(/home/rasmus/foo, O_WRONLY|O_CREAT, 0666) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
flock(3, LOCK_EX) = 0
ftruncate(3, 0) = 0
write(3, bar, 3) = 3
close(3)= 0
[2010-10-16 02:05:13] cataphr...@php.net
I can't reproduce this. I get the output bar.
File locks are released when the file are closed. Additionally, your
'actual result' section shows an unlock:
...
write(3, bar, 3) = 3
flock(3, LOCK_UN) = 0 ---
Am I missing something?
[2010-10-15 17:16:19] admin at saltwaterc dot net
Test script:
---
?php
file_put_contents('foo', 'bar', LOCK_EX);
$fh = fopen('foo', 'rb'); // there, I messed up the first time
flock($fh, LOCK_SH);
$file_contents = stream_get_contents($fh);
flock($fh, LOCK_UN);
fclose($fh);
echo $file_contents.PHP_EOL;
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=53076
--
Edit this bug report at http://bugs.php.net/bug.php?id=53076edit=1
[PHP-BUG] Bug #53076 [NEW]: file_put_contents doesn't release the LOCK_EX
From:
Operating system: Irrelevant
PHP version: 5.3.3
Package: Scripting Engine problem
Bug Type: Bug
Bug description:file_put_contents doesn't release the LOCK_EX
Description:
The name is pretty self explanatory. When the file_put_content function is
used along with the LOCK_EX flag, the file descriptor / file handle doesn't
get unlocked. Most of the time this won't be an issue, but depending on the
underlying file system, it could lead to severe application crash. Such
example is the GlusterFS version packaged for the Ubuntu 10.04 which would
block the PHP process in uninterruptible sleep. I know that most of the
time this situation won't affect real life scenarios, but it already took
down a virtual host from our production cluster, based onto the above
setup.
Test script:
---
?php
file_put_contents('foo', 'bar', LOCK_EX);
$fh = fopen($file, 'rb');
flock($fh, LOCK_SH);
$file_contents = stream_get_contents($fh);
flock($fh, LOCK_UN);
fclose($fh);
echo $file_contents.PHP_EOL;
Expected result:
output: bar
strace:
getcwd(/media/glusterfs01/gluster-bug, 4096) = 31
lstat(/media/glusterfs01/gluster-bug/foo, {st_mode=S_IFREG|0644,
st_size=3, ...}) = 0
open(/media/glusterfs01/gluster-bug/foo, O_WRONLY|O_CREAT, 0666) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
flock(3, LOCK_EX) = 0
ftruncate(3, 0) = 0
write(3, bar, 3) = 3
flock(3, LOCK_UN) = 0
close(3)= 0
getcwd(/media/glusterfs01/gluster-bug, 4096) = 31
open(/media/glusterfs01/gluster-bug/foo, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
flock(3, LOCK_SH) = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=3, ...}) = 0
read(3, bar, 8192)= 3
read(3, , 8192) = 0
read(3, , 8192) = 0
flock(3, LOCK_UN) = 0
close(3)= 0
Actual result:
--
output: none
strace:
getcwd(/media/glusterfs01/gluster-bug, 4096) = 31
lstat(/media/glusterfs01/gluster-bug/foo, {st_mode=S_IFREG|0644,
st_size=3, ...}) = 0
open(/media/glusterfs01/gluster-bug/foo, O_WRONLY|O_CREAT, 0666) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
flock(3, LOCK_EX) = 0
ftruncate(3, 0) = 0
write(3, bar, 3) = 3
flock(3, LOCK_UN) = 0
close(3)= 0
getcwd(/media/glusterfs01/gluster-bug, 4096) = 31
open(/media/glusterfs01/gluster-bug/foo, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
flock(3, LOCK_SH
And then it blocks here ...
--
Edit bug report at http://bugs.php.net/bug.php?id=53076edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53076r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53076r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53076r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53076r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53076r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53076r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53076r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53076r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53076r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53076r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53076r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53076r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53076r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53076r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53076r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53076r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53076r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53076r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53076r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53076r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53076r=mysqlcfg
Bug #53076 [Opn]: file_put_contents doesn't release the LOCK_EX
Edit report at http://bugs.php.net/bug.php?id=53076edit=1
ID: 53076
User updated by:admin at saltwaterc dot net
Reported by:admin at saltwaterc dot net
Summary:file_put_contents doesn't release the LOCK_EX
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Irrelevant
PHP Version:5.3.3
Block user comment: N
New Comment:
Test script:
---
?php
file_put_contents('foo', 'bar', LOCK_EX);
$fh = fopen('foo', 'rb'); // there, I messed up the first time
flock($fh, LOCK_SH);
$file_contents = stream_get_contents($fh);
flock($fh, LOCK_UN);
fclose($fh);
echo $file_contents.PHP_EOL;
Previous Comments:
[2010-10-15 17:12:59] admin at saltwaterc dot net
Description:
The name is pretty self explanatory. When the file_put_content function
is used along with the LOCK_EX flag, the file descriptor / file handle
doesn't get unlocked. Most of the time this won't be an issue, but
depending on the underlying file system, it could lead to severe
application crash. Such example is the GlusterFS version packaged for
the Ubuntu 10.04 which would block the PHP process in uninterruptible
sleep. I know that most of the time this situation won't affect real
life scenarios, but it already took down a virtual host from our
production cluster, based onto the above setup.
Test script:
---
?php
file_put_contents('foo', 'bar', LOCK_EX);
$fh = fopen($file, 'rb');
flock($fh, LOCK_SH);
$file_contents = stream_get_contents($fh);
flock($fh, LOCK_UN);
fclose($fh);
echo $file_contents.PHP_EOL;
Expected result:
output: bar
strace:
getcwd(/media/glusterfs01/gluster-bug, 4096) = 31
lstat(/media/glusterfs01/gluster-bug/foo, {st_mode=S_IFREG|0644,
st_size=3, ...}) = 0
open(/media/glusterfs01/gluster-bug/foo, O_WRONLY|O_CREAT, 0666) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
flock(3, LOCK_EX) = 0
ftruncate(3, 0) = 0
write(3, bar, 3) = 3
flock(3, LOCK_UN) = 0
close(3)= 0
getcwd(/media/glusterfs01/gluster-bug, 4096) = 31
open(/media/glusterfs01/gluster-bug/foo, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
flock(3, LOCK_SH) = 0
fstat(3, {st_mode=S_IFREG|0644, st_size=3, ...}) = 0
read(3, bar, 8192)= 3
read(3, , 8192) = 0
read(3, , 8192) = 0
flock(3, LOCK_UN) = 0
close(3)= 0
Actual result:
--
output: none
strace:
getcwd(/media/glusterfs01/gluster-bug, 4096) = 31
lstat(/media/glusterfs01/gluster-bug/foo, {st_mode=S_IFREG|0644,
st_size=3, ...}) = 0
open(/media/glusterfs01/gluster-bug/foo, O_WRONLY|O_CREAT, 0666) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
flock(3, LOCK_EX) = 0
ftruncate(3, 0) = 0
write(3, bar, 3) = 3
flock(3, LOCK_UN) = 0
close(3)= 0
getcwd(/media/glusterfs01/gluster-bug, 4096) = 31
open(/media/glusterfs01/gluster-bug/foo, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3, ...}) = 0
lseek(3, 0, SEEK_CUR) = 0
flock(3, LOCK_SH
And then it blocks here ...
--
Edit this bug report at http://bugs.php.net/bug.php?id=53076edit=1
Bug #52086 [Com]: No new line at the end of a included pool file crahes the PHP FPM daemon
Edit report at http://bugs.php.net/bug.php?id=52086edit=1 ID: 52086 Comment by: admin at saltwaterc dot net Reported by: admin at saltwaterc dot net Summary: No new line at the end of a included pool file crahes the PHP FPM daemon Status: Analyzed Type: Bug Package: FPM related Operating System: * PHP Version: 5.3.2 Assigned To: fat New Comment: service php-fpm restart Gracefully shutting down php-fpm done Starting php-fpm PHP: syntax error, unexpected $end in Unknown on line 1 Jun 19 15:50:58.956049 [ERROR] Unable to include /usr/local/zend/etc/fpm.d/default.conf from /usr/local/zend/etc/php-fpm.conf at line 8 Jun 19 15:50:58.956439 [ERROR] failed to load configuration file '/usr/local/zend/etc/php-fpm.conf' failed It doesn't dump the backtrace and the memory map, but it still crashes. I made a PHP script that writes the configuration to /usr/local/zend/etc/fpm.d/: #!/usr/local/zend/bin/php ?php file_put_contents ( /usr/local/zend/etc/fpm.d/default.conf, [default] user = php-fpm group = php-fpm listen = /var/run/php-fpm/default.sock pm = static pm.max_children = 2 pm.max_requests = 1 chdir = /var/www ); This reproduces the bug. If I manually edit the file with nano, everything is fine since nano automatically adds a new line at the end of the last line. Previous Comments: [2010-06-15 17:08:02] f...@php.net Can you try the attached patch please ? [2010-06-15 17:07:25] f...@php.net The following patch has been added/updated: Patch Name: fpm-include.error.patch Revision: 1276614445 URL: http://bugs.php.net/patch-display.php?bug=52086patch=fpm-include.error.patchrevision=1276614445 [2010-06-15 14:49:38] admin at saltwaterc dot net Description: I have a script that automatically generates pool configurations based on input parameters and a template configuration. It didn't used to place a new line at the end of the generated configuration file which degenerated into a hard to debug error as the daemon crashes without any useful explanation. By adding a new line after the last configuration line (in my example, php_admin_value[upload_tmp_dir] = /home/example.com/tmp) everything works as expected. Test script: --- [example.com] user = example.com group = example.com listen = /var/run/php-fpm/example.com.sock pm = static pm.max_children = 2 pm.max_requests = 1 slowlog = /home/example.com/logs/fpm/slow.log chdir = /home/example.com/docroot php_admin_value[error_log] = /home/example.com/logs/fpm/error.log php_admin_value[open_basedir] = /home/example.com/docroot:/home/example.com/sessions:/home/example.com/tmp php_admin_value[session.save_path] = /home/example.com/sessions php_admin_value[upload_tmp_dir] = /home/example.com/tmp Expected result: Successful PHP FPM daemon start. Actual result: -- Starting php-fpm PHP: syntax error, unexpected $end in Unknown on line 1 Jun 15 12:35:12.090707 [ERROR] Unable to include /usr/local/zend/etc/fpm.d/example.com.ini from /usr/local/zend/etc/php-fpm.conf at line 23 *** glibc detected *** /usr/local/zend/sbin/php-fpm: double free or corruption (fasttop): 0x1ac80380 *** + backtrace + memory map -- Edit this bug report at http://bugs.php.net/bug.php?id=52086edit=1
[PHP-BUG] Bug #52086 [NEW]: No new line at the end of a included pool file crahes the PHP FPM daemon
From: Operating system: * PHP version: 5.3.2 Package: FPM related Bug Type: Bug Bug description:No new line at the end of a included pool file crahes the PHP FPM daemon Description: I have a script that automatically generates pool configurations based on input parameters and a template configuration. It didn't used to place a new line at the end of the generated configuration file which degenerated into a hard to debug error as the daemon crashes without any useful explanation. By adding a new line after the last configuration line (in my example, php_admin_value[upload_tmp_dir] = /home/example.com/tmp) everything works as expected. Test script: --- [example.com] user = example.com group = example.com listen = /var/run/php-fpm/example.com.sock pm = static pm.max_children = 2 pm.max_requests = 1 slowlog = /home/example.com/logs/fpm/slow.log chdir = /home/example.com/docroot php_admin_value[error_log] = /home/example.com/logs/fpm/error.log php_admin_value[open_basedir] = /home/example.com/docroot:/home/example.com/sessions:/home/example.com/tmp php_admin_value[session.save_path] = /home/example.com/sessions php_admin_value[upload_tmp_dir] = /home/example.com/tmp Expected result: Successful PHP FPM daemon start. Actual result: -- Starting php-fpm PHP: syntax error, unexpected $end in Unknown on line 1 Jun 15 12:35:12.090707 [ERROR] Unable to include /usr/local/zend/etc/fpm.d/example.com.ini from /usr/local/zend/etc/php-fpm.conf at line 23 *** glibc detected *** /usr/local/zend/sbin/php-fpm: double free or corruption (fasttop): 0x1ac80380 *** + backtrace + memory map -- Edit bug report at http://bugs.php.net/bug.php?id=52086edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52086r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52086r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52086r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52086r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52086r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52086r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52086r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52086r=needscript Try newer version: http://bugs.php.net/fix.php?id=52086r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52086r=support Expected behavior: http://bugs.php.net/fix.php?id=52086r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52086r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52086r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52086r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52086r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52086r=dst IIS Stability: http://bugs.php.net/fix.php?id=52086r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52086r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52086r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52086r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52086r=mysqlcfg
[PHP-BUG] Bug #51821 [NEW]: configure fails to pick up a custom prefix for libevent
From:
Operating system: Linux
PHP version: 5.3.2
Package: FPM related
Bug Type: Bug
Bug description:configure fails to pick up a custom prefix for libevent
Description:
Using a custom prefix for the libevent installation
(/usr/local/libevent-1.4.13) doesn't get picked up by the configure script,
even though I properly used the --with-libevent-dir option. Unless the
prefix for the libevent installation is a path that ldconfig knows about,
the configure fails.
I could fix it with:
export LD_LIBRARY_PATH=/usr/local/libevent-$libevent_version/lib
within my build script which gives me the idea that the configure fails to
properly set its environment. Still an arcane method though.
Test script:
---
./configure [...] --enable-fpm --with-fpm-user=php-fpm
--with-fpm-group=php-fpm --with-libevent-dir=/usr/local/libevent-1.4.13
Expected result:
To run configure without errors.
Actual result:
--
./configure says:
checking for FPM build... yes
checking for libevent = 1.4.11 install prefix...
/usr/local/libevent-1.4.13
no
configure: error: build test failed. Please check the config.log for
details.
config.log says:
configure:9409: checking for libevent = 1.4.11 install prefix
configure:9524: gcc -o conftest -g -O2 -fvisibility=hidden
-I/usr/local/libevent-1.4.13/include -L/usr/local/libevent-1.4.13/lib
conftest.c -levent 15
configure:9724: gcc -o conftest -g -O2 -fvisibility=hidden conftest.c
-L/usr/local/libevent-1.4.13/lib -levent 15
configure: failed program was:
#line 9713 configure
#include confdefs.h
char event_init();
int main() {
event_init();
return 0;
}
--
Edit bug report at http://bugs.php.net/bug.php?id=51821edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51821r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51821r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51821r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51821r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51821r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51821r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51821r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51821r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51821r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51821r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51821r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51821r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51821r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51821r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51821r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51821r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51821r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51821r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51821r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51821r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51821r=mysqlcfg
[PHP-BUG] Bug #51799 [NEW]: FPM crashes if the include is enabled, but there are no files
From: Operating system: Linux PHP version: 5.3.2 Package: FPM related Bug Type: Bug Bug description:FPM crashes if the include is enabled, but there are no files Description: If the include configuration option is enabled, but the pool directory is empty, php-fpm crashes pretty ugly. I could manage to enable the service by creating an empty default.conf file within the fpm.d directory, but obviously this isn't the solution. The used FPM is the latest trunk indicated by php-fpm.org http://svn.php.net/repository/php/php-src/trunk/sapi/fpm. Test script: --- The include line is: include=/usr/local/zend/etc/fpm.d/*.conf r...@test-lucid:/usr/local/zend/etc/fpm.d# ls -la total 8 drwxr-sr-x 2 root zend 4096 May 12 11:59 . drwxrwsr-x 7 root zend 4096 May 12 11:59 .. r...@test-lucid:/usr/local/zend/etc/fpm.d# Expected result: To be able to start the php-fpm service just with the default pool from php-fpm.conf if fpm.d is empty. In my humble opinion the application shouldn't crash if no pattern is matched. Actual result: -- May 12 12:10:52.239695 [ERROR] Nothing match the include pattern '/usr/local/zend/etc/fpm.d/*.conf' from /usr/local/zend/etc/php-fpm.conf at line 10. The backtrace is quite useless since the error is generated by sapi/fpm/fpm/fpm_conf.c, after the glob() call. -- Edit bug report at http://bugs.php.net/bug.php?id=51799edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51799r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51799r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51799r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51799r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51799r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51799r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51799r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51799r=needscript Try newer version: http://bugs.php.net/fix.php?id=51799r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51799r=support Expected behavior: http://bugs.php.net/fix.php?id=51799r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51799r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51799r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51799r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51799r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51799r=dst IIS Stability: http://bugs.php.net/fix.php?id=51799r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51799r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51799r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51799r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51799r=mysqlcfg
#49974 [NEW]: Windows x64 build lacks proper suport for 64-bit signed long
From: admin at saltwaterc dot net
Operating system: Windows x64, irrelevant version
PHP version: 5.2.11
PHP Bug Type: Scripting Engine problem
Bug description: Windows x64 build lacks proper suport for 64-bit signed long
Description:
The Windows x64 build of PHP has an issue with the integer data type. It
may have issues with floating point numbers, but I didn't test it. The
integer bugs me since I work with large integers as column primary keys in
databases. I can't check for overflows with is_int() either (obvious).
Runtime:
- 3rd party PHP 5.2.5 x64 build
- 3rd party PHP 5.2.8 x64 build
- my own PHP 5.2.11 x64 builds
- official snapshot PHP 5.3.1RC1 (used below) - so the issue is in both of
the 5.2.x and 5.3.x branches
Compiler
- MSVC++ 8.0 Express
- MSVC++ 9.0 Express
Windows SDK:
- 6.1a
- 7.0
Since there were various versions built with various compilers and
Windwows SDKs, I tend to believe that this is a PHP build system related
issue, rather than an issue with that MSVC++ stuff.
PS: at the moment this x64 issue is a development problem as the code goes
into production on *nix machines with proper 64-bit support. Please don't
tell me the same story from report #49492. Yes, Apache doesn't provide
official x64 builds, but it is supported, thus 64-bit development is
possible. Try it yourself:
http://www.anindya.com/apache-http-server-2-2-14-x86-x64-msi-installers/
Reproduce code:
---
?php // long.php
function assert_handler($file, $line, $code)
{
echo Assertion Failed:
File '$file'
Line '$line'
Code '$code';
}
assert_options(ASSERT_ACTIVE, 1);
assert_options(ASSERT_WARNING, 0);
assert_options(ASSERT_QUIET_EVAL, 1);
assert_options(ASSERT_CALLBACK, 'assert_handler');
assert(is_int(3147483647) === TRUE);
Expected result:
Nothing!
Actual result:
--
C:\Users\Saltwater\Desktopphp-5.3.1RC1-Win32-VC9-x64\php.exe long.php
Assertion Failed:
File 'C:\Users\Saltwater\Desktop\long.php'
Line '13'
Code ''
C:\Users\Saltwater\Desktop
--
Edit bug report at http://bugs.php.net/?id=49974edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49974r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49974r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49974r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49974r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49974r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49974r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49974r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49974r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49974r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49974r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49974r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49974r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49974r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49974r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49974r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49974r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49974r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49974r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49974r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49974r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49974r=mysqlcfg
#49974 [Asn]: Windows x64 build lacks proper suport for 64-bit signed long long
ID: 49974 User updated by: admin at saltwaterc dot net -Summary: Windows x64 build lacks proper suport for 64-bit signed long Reported By: admin at saltwaterc dot net Status: Assigned Bug Type: Scripting Engine problem Operating System: win32 only - Windows x64 PHP Version: 5.2.11 Assigned To: pajoye New Comment: Well, even though 5.2 doesn't have support - it does compile. The task manager shows the runtime as native 64-bit app. The assertion test was the whole idea: assertion failed. In unit testing, the assertions should not fail in order to pass the test. I simply changed 2147483647 with 3147483647 (the first digit) in order to make it to fail a test that should not fail under x64, but fails under x86. It could have been 31474836470 which I assure you that its 32-bit float representation won't pass as integer, but under 64-bit is fine. Under Windows, yes, it displays your output for PHP_INT_MAX with either a x86 build or a x64 build. I know what's the upper limit for 32-bit signed long, where under 64-bit the PHP integer should be a signed long long. Under Debian/Ubuntu/Linux, the 5.2.x x86_64 builds: (Ubuntu Hardy) rem...@ubuntuvz:~$ php -r 'echo PHP_INT_MAX.\n;' 9223372036854775807 rem...@ubuntuvz:~$ php -v PHP 5.2.4-2ubuntu5.7 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 21 2009 22:17:39) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies rem...@ubuntuvz:~$ php long.php rem...@ubuntuvz:~$ # no failure here (Debian Lenny) saltwa...@web:~$ php -r 'echo PHP_INT_MAX.\n;' 9223372036854775807 saltwa...@web:~$ php -v PHP 5.2.6-1+lenny3 with Suhosin-Patch 0.9.6.2 (cli) (built: Apr 26 2009 20:09:03) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH saltwa...@web:~$ php long.php saltwa...@web:~$ # no failure here either (Ubuntu Karmic) saltwa...@karmic:~$ php -r 'echo PHP_INT_MAX.\n;' 9223372036854775807 saltwa...@karmic:~$ php -v PHP 5.2.10-2ubuntu5 with Suhosin-Patch 0.9.7 (cli) (built: Oct 13 2009 18:33:05) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies saltwa...@karmic:~$ php long.php saltwa...@karmic:~$ # again - no failure (Debian Lenny - Quick setup with Zend Server CE) r...@php-test:~# php -r 'echo PHP_INT_MAX.\n;' 9223372036854775807 r...@php-test:~# php -v PHP 5.3.0 (cli) (built: Jul 21 2009 08:21:24) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies with Zend Extension Manager v5.1, Copyright (c) 2003-2009, by Zend Technologies - with Zend Data Cache v4.0, Copyright (c) 2004-2009, by Zend Technologies [loaded] [licensed] [disabled] - with Zend Utils v1.0, Copyright (c) 2004-2009, by Zend Technologies [loaded] [licensed] [enabled] - with Zend Optimizer+ v4.0, Copyright (c) 1999-2009, by Zend Technologies [loaded] [licensed] [disabled] - with Zend Debugger v5.2, Copyright (c) 1999-2009, by Zend Technologies [loaded] [licensed] [enabled] r...@php-test:~# php long.php r...@php-test:~# # still nothing (Debian Lenny - same machine, my own build) r...@php-test:~# php -i | grep conf Configure Command = './configure' '--prefix=/opt/local' '--disable-cgi' '--with-layout=gnu' r...@php-test:~# php -r 'echo PHP_INT_MAX.\n;' 9223372036854775807 r...@php-test:~# php -v PHP 5.3.0 (cli) (built: Oct 23 2009 22:40:27) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies r...@php-test:~# php long.php r...@php-test:~# (CentOS 5.3 - Quick setup with Zend Server CE) [r...@php-test-cent ~]# php -r 'echo PHP_INT_MAX.\n;' [blah, some PHP strict timezone complains] 9223372036854775807 [r...@php-test-cent ~]# php -v PHP 5.3.0 (cli) (built: Aug 25 2009 03:54:07) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies with Zend Extension Manager v5.1, Copyright (c) 2003-2009, by Zend Technologies - with Zend Data Cache v4.0, Copyright (c) 2004-2009, by Zend Technologies [loaded] [licensed] [disabled] - with Zend Utils v1.0, Copyright (c) 2004-2009, by Zend Technologies [loaded] [licensed] [enabled] - with Zend Optimizer+ v4.0, Copyright (c) 1999-2009, by Zend Technologies [loaded] [licensed] [disabled] - with Zend Debugger v5.2, Copyright (c) 1999-2009, by Zend Technologies [loaded] [licensed] [enabled] [r...@php-test-cent ~]# php long.php [r...@php-test-cent ~]# # CentOS passes as well Previous Comments: [2009-10-23 19:25:26] paj...@php.net Also given that PHP_INT_MAX is 2147483647, having 3147483647 being stored as a float is perfectly valid. Try to confirm: php -r echo PHP_INT_MAX
