[PHP-BUG] Bug #53074 [NEW]: Sending php-fpm service a HUP signal causes problems with daemontools
From: Operating system: Linux (funtoo/gentoo) PHP version: 5.3.3 Package: FPM related Bug Type: Bug Bug description:Sending php-fpm service a HUP signal causes problems with daemontools Description: I'm running php-fpm with DJB daemontools (daemonize = no) process supervisor. Every time I send the process a HUP signal (graceful reload) the process is in some way detached from daemontools so it's not possible to reload it because it's already runninng. Since the children processes aren't properly (?) terminated, php-fpm refuses to start: Test script: --- # ps axf 1806 ?Ss 0:00 /bin/sh /command/svscanboot 1809 ?S 0:02 \_ svscan /service 1811 ?S 0:00 | \_ supervise nginx 1861 ?S 0:00 | | \_ nginx: master process /usr/local/sbin/nginx -c /usr/local/etc/nginx/nginx.conf 1947 ?S 0:00 | | \_ nginx: worker process 1812 ?S 0:00 | \_ supervise log 1862 ?S 0:00 | | \_ /command/multilog t s1000 n30 /var/log/nginx 1824 ?S 0:00 | \_ supervise php-fpm 20807 ?Ss 0:00 | | \_ /usr/local/sbin/php-fpm --fpm-config /usr/local/etc/php/php-fpm.conf 20808 ?S 0:00 | | \_ /usr/local/sbin/php-fpm --fpm-config /usr/local/etc/php/php-fpm.conf 20809 ?S 0:00 | | \_ /usr/local/sbin/php-fpm --fpm-config /usr/local/etc/php/php-fpm.conf 20810 ?S 0:00 | | \_ /usr/local/sbin/php-fpm --fpm-config /usr/local/etc/php/php-fpm.conf 1825 ?S 0:00 | \_ supervise log # svc -h /service/php-fpm # ps axf 14606 ?S 0:01 /srv/bin/php-cgi --fpm --fpm-config /srv/etc/php/php-fpm.conf 14607 ?S 0:00 /srv/bin/php-cgi --fpm --fpm-config /srv/etc/php/php-fpm.conf 14608 ?S 0:01 /srv/bin/php-cgi --fpm --fpm-config /srv/etc/php/php-fpm.conf # tailf /var/log/php-fpm/current @40004cb81c1f223b929c Oct 15 06:17:09.545883 [ERROR] bind() for address '127.0.0.1:9000' failed: Address already in use (98) @40004cb81c1f34789c0c Oct 15 06:17:09.880267 [WARNING] [pool www] pm.start_servers is not set. It's been set to 3. @40004cb81c1f35767854 Oct 15 06:17:09.880736 [ERROR] bind() for address '127.0.0.1:9000' failed: Address already in use (98) @40004cb81c203798141c Oct 15 06:17:10.932654 [WARNING] [pool www] pm.start_servers is not set. It's been set to 3. -- Edit bug report at http://bugs.php.net/bug.php?id=53074edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53074r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53074r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53074r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53074r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53074r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53074r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53074r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53074r=needscript Try newer version: http://bugs.php.net/fix.php?id=53074r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53074r=support Expected behavior: http://bugs.php.net/fix.php?id=53074r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53074r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53074r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53074r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53074r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53074r=dst IIS Stability: http://bugs.php.net/fix.php?id=53074r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53074r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53074r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53074r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53074r=mysqlcfg
[PHP-BUG] Bug #53075 [NEW]: Running fpm with default config produces pm.min_spare_servers error
From: Operating system: any PHP version: 5.3.3 Package: FPM related Bug Type: Bug Bug description:Running fpm with default config produces pm.min_spare_servers error Description: Just copying etc/php-fpm.conf.default to etc/php-fpm.conf doesn't work: we have pm.dynamic by default (why?) and the following error occures: Starting php_fpm Oct 15 12:15:18.755094 [ALERT] [pool www] pm.min_spare_servers(0) must be a positive value Oct 15 12:15:18.755148 [ERROR] failed to post process the configuration removing comments ';' for dynamic config helps Shorter: there should be either pm.static and comments for these spare settings, or pm.dynamic with non-commented settings. -- Edit bug report at http://bugs.php.net/bug.php?id=53075edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53075r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53075r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53075r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53075r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53075r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53075r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53075r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53075r=needscript Try newer version: http://bugs.php.net/fix.php?id=53075r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53075r=support Expected behavior: http://bugs.php.net/fix.php?id=53075r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53075r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53075r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53075r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53075r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53075r=dst IIS Stability: http://bugs.php.net/fix.php?id=53075r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53075r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53075r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53075r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53075r=mysqlcfg
Bug #48753 [Com]: go-pear.bat / phar not working
Edit report at http://bugs.php.net/bug.php?id=48753edit=1 ID: 48753 Comment by: jwspam1 at GMAIL dot COM Reported by:bjoern at xrow dot de Summary:go-pear.bat / phar not working Status: Closed Type: Bug Package:PHAR related Operating System: WINDOWS VISTA PHP Version:5.3.0 Assigned To:cellog Block user comment: N New Comment: The same thing in php-5.3.3-nts-Win32-VC6-x86.msi Is it at all possible for you people to test things before releasing them? (The workaround is to replace go-pear.bat with this: @ECHO OFF set PHP_BIN=php.exe %PHP_BIN% -d output_buffering=0 -d phar.require_hash=0 PEAR\go-pear.phar pause ) Previous Comments: [2010-10-01 09:41:07] nospam at marcmittag dot de I have the same problem today with this package on win xp: php-5.3.3-Win32-VC6-x86.zip. Exactly the same error-message as orignally posted in the bug report. [2009-08-02 22:19:46] cel...@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. [2009-07-16 19:39:23] paj...@php.net See http://news.php.net/php.internals/44569 Can you guys simply regenerate this phar please? [2009-07-16 19:35:15] shank1969 at hotmail dot com http://lenss.nl/2008/07/pear-install-weirdness/ = 404. Any other ideas? [2009-07-16 18:48:14] bjoern at xrow dot de learn c and fix it on your own. your comment was not helpfull to solve this bug. 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=48753 -- Edit this bug report at http://bugs.php.net/bug.php?id=48753edit=1
Bug #53053 [Fbk-Csd]: Magic Method __set changes object class
Edit report at http://bugs.php.net/bug.php?id=53053edit=1
ID: 53053
User updated by:dave dot a dot roberts at gmail dot com
Reported by:dave dot a dot roberts at gmail dot com
Summary:Magic Method __set changes object class
-Status: Feedback
+Status: Closed
Type: Bug
Package:Class/Object related
Operating System: FreeBSD 8.1-RELEASE
PHP Version:5.3.3
Block user comment: N
New Comment:
I think this was happening because I was trying to pull an object out of
an array by the wrong key. Sorry to waste your time.
Previous Comments:
[2010-10-14 04:43:28] ahar...@php.net
Please provide a complete reproduction script, preferably (well) under
50 lines of code.
For the record, I can't reproduce this with the following script:
?php
class C {
public function __set($name, $value) {
$this-$name = $value;
}
}
$c = new C;
var_dump(get_class($c));
$c-foo = 'bar';
var_dump(get_class($c));
?
[2010-10-13 17:49:42] dave dot a dot roberts at gmail dot com
Description:
I have an object I created from class Post.
$p = new Post();
get_class($p) will return the class Post.
After I assign a variable to the class using the magic method __set
$p-datereceived = 1234;
get_class($p) will return stdClass.
Test script:
---
$p = new Post();
print(get_class($p)); // returns Post
$p-datereceived = 1234;
print(get_class($p)); // returns stdClass.
Expected result:
The classname of Post should be returned twice.
Actual result:
--
Post is returned the first time, stdClass is returned the second time.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53053edit=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 #45546 [Com]: PCRE with utf8 kill apache childprocess
Edit report at http://bugs.php.net/bug.php?id=45546edit=1 ID: 45546 Comment by: sergio at gruposinternet dot com dot br Reported by:kaiser at macbureau dot de Summary:PCRE with utf8 kill apache childprocess Status: No Feedback Type: Bug Package:PCRE related Operating System: FreeBSD 7 PHP Version:5.2.6 Block user comment: N New Comment: Still broken. FreeBSD: 7.2-RELEASE Apache: 2.2.15 PHP version: 5.2.14 (without Suhosin patch) PCRE Library Version = 7.9 2009-04-11 From dmesg: pid 61580 (httpd), uid 80: exited on signal 4 Previous Comments: [2010-06-04 18:56:30] martin at veverka dot eu Hi. Still broken. from Apache error log: [notice] child pid 43125 exit signal Illegal instruction (4) FreeBSD 8.0 Apache/2.2.15 PHP 5.3.2 with Suhosin-Patch PCRE Library Version = 8.02 2010-03-19 [2009-09-18 19:57:50] chris at smartt dot com Still happening on FreeBSD 7.2 and PHP 5.2.9 with Suhosin-Patch 0.9.7 (cli) (built: May 11 2009 22:23:18) #1860 0x28cdcad1 in match () from /usr/local/lib/libpcre.so.0 #1861 0x28cde851 in match () from /usr/local/lib/libpcre.so.0 #1862 0x28ce6ad7 in pcre_exec () from /usr/local/lib/libpcre.so.0 #1863 0x28cc931b in php_pcre_match_impl () from /usr/local/lib/php/20060613/pcre.so #1864 0x28cc9de0 in php_do_pcre_match () from /usr/local/lib/php/20060613/pcre.so #1865 0x0815c7bd in execute_internal () #1866 0x285d16e0 in suhosin_execute_internal () from /usr/local/lib/php/20060613/suhosin.so #1867 0x081695db in zend_do_fcall_common_helper_SPEC () #1868 0x0815d961 in execute () #1869 0x287810c2 in _su3jdmx () from /usr/local/lib/php/20060613/ioncube_loader_fre_5.2.so #1870 0x2912ef9c in ?? () #1871 0x in ?? () #1872 0x285dc780 in __JCR_LIST__ () from /usr/local/lib/php/20060613/suhosin.so #1873 0x285d1c55 in suhosin_execute_ex () from /usr/local/lib/php/20060613/suhosin.so [2009-06-10 18:06:00] bob at veznat dot com This is still broken. FreeBSD 7.1 and PHP 5.2.9. It seems that the original bug filer has provided plenty of repro. If that is not the case I'd be happy to go through the process of digging up all I can from my machine. [2009-02-26 01:30:01] joe at lastpass dot com Happens at somewhere between 3500 and 6400 characters on every Linux platform I have access to (x86 and x86_64): PHP 5.2.6-3ubuntu2 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 13 2009 20:07:08) PHP 5.2.6-2ubuntu4.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 11 2009 20:44:58) PHP 5.2.4-2ubuntu5.5 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 11 2009 20:09:11) PHP 5.2.6-3ubuntu2 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 13 2009 20:20:01) [2009-02-08 11:55:20] vanav at vanav dot com dot ua Two gdb examples: gdb66: Program received signal SIGSEGV, Segmentation fault. match ( eptr=0x29385a68 3'\;\n$select[] = \SELECT p1.id, nick, p1.creation_date, p1.modification_date, p1.post_title, p1.post_text, p1.parent_post_id, p2.post_title AS parent_post_title, p3.post_title AS answer_parent_post_ti..., ecode=0x28f160ed \034\T, mstart=0x293854bc ?php\n$select = array();\n$select[] = \SELECT uni_files.id, name, disk_filename, icon, size FROM uni_files INNER JOIN uni_filetypes ON uni_files.filetype_id=uni_filetypes.id WHERE post_id='167' AND blo..., offset_top=4, md=0xbfbef000, ims=6, eptrb=0x0, flags=0, rdepth=1362) at /usr/ports/lang/php5/work/php-5.2.8/ext/pcre/pcrelib/pcre_exec.c:580 580 prop_value = 0; and 0x2863b28a in match ( eptr=0x2940b64f ?#1072;#1052;202#1052;214, #1076;#1072;#1078;#1077; #1052;201#1052;200#1077;#1076;#1085;#1077;#1084;#1052;203 #1082;#1083;#1072;#1052;201#1052;201#1052;203, ?00\223 #1079;#1072;#1052;217#1074;#1080;#1083; ?232#1052;203#1085;#1080;#1052;206#1052;213#1085;. #1076;#1072;#1078;#1077; #1052;201#1052;200#1077;#1076;#1085;#1077;#1084;#1052;203 #1082;#1083;#1072;#1052;201#1052;201#1052;203, ?00\223 #1079;#1072;#1052;217#1074;#1080;#1083; ?232#1052;203#1085;#1080;#1052;206#1052;213#1085;. /pp?222#1052;213 #1079;#1085;#1072;#1077;#1052;202#1077;, #1052;207#1052;202#1086; ?..., ecode=0x28ef03bb \034'U, mstart=0x2940b398 'p?237#1086; #1084;#1085;#1077;#1085;#1080;#1052;216 ?232#1052;203#1085;#1080;#1052;206#1052;213#1085;#1072;, #1082;#1052;200#1052;213#1084;#1052;201#1082;#1080;#1077; #1074;#1083;#1072;#1052;201#1052;202#1080; #1076;#1086;#1083;#1078;#1085;#1052;213 #1076;#1072;#1052;202#1052;214 #1074;#1086;#1079;#1084;#1086;#1078;#1085;#1086;#1052;201#1052;202#1052;214
Bug #45546 [Com]: PCRE with utf8 kill apache childprocess
Edit report at http://bugs.php.net/bug.php?id=45546edit=1 ID: 45546 Comment by: sergio at gruposinternet dot com dot br Reported by:kaiser at macbureau dot de Summary:PCRE with utf8 kill apache childprocess Status: No Feedback Type: Bug Package:PCRE related Operating System: FreeBSD 7 PHP Version:5.2.6 Block user comment: N New Comment: It seems that setting pcre.recursion_limit to 1700 can be used as workaround, but be warned to check for error conditions as stated by the documentation at http://www.php.net/preg_match Previous Comments: [2010-10-15 20:48:48] sergio at gruposinternet dot com dot br Still broken. FreeBSD: 7.2-RELEASE Apache: 2.2.15 PHP version: 5.2.14 (without Suhosin patch) PCRE Library Version = 7.9 2009-04-11 From dmesg: pid 61580 (httpd), uid 80: exited on signal 4 [2010-06-04 18:56:30] martin at veverka dot eu Hi. Still broken. from Apache error log: [notice] child pid 43125 exit signal Illegal instruction (4) FreeBSD 8.0 Apache/2.2.15 PHP 5.3.2 with Suhosin-Patch PCRE Library Version = 8.02 2010-03-19 [2009-09-18 19:57:50] chris at smartt dot com Still happening on FreeBSD 7.2 and PHP 5.2.9 with Suhosin-Patch 0.9.7 (cli) (built: May 11 2009 22:23:18) #1860 0x28cdcad1 in match () from /usr/local/lib/libpcre.so.0 #1861 0x28cde851 in match () from /usr/local/lib/libpcre.so.0 #1862 0x28ce6ad7 in pcre_exec () from /usr/local/lib/libpcre.so.0 #1863 0x28cc931b in php_pcre_match_impl () from /usr/local/lib/php/20060613/pcre.so #1864 0x28cc9de0 in php_do_pcre_match () from /usr/local/lib/php/20060613/pcre.so #1865 0x0815c7bd in execute_internal () #1866 0x285d16e0 in suhosin_execute_internal () from /usr/local/lib/php/20060613/suhosin.so #1867 0x081695db in zend_do_fcall_common_helper_SPEC () #1868 0x0815d961 in execute () #1869 0x287810c2 in _su3jdmx () from /usr/local/lib/php/20060613/ioncube_loader_fre_5.2.so #1870 0x2912ef9c in ?? () #1871 0x in ?? () #1872 0x285dc780 in __JCR_LIST__ () from /usr/local/lib/php/20060613/suhosin.so #1873 0x285d1c55 in suhosin_execute_ex () from /usr/local/lib/php/20060613/suhosin.so [2009-06-10 18:06:00] bob at veznat dot com This is still broken. FreeBSD 7.1 and PHP 5.2.9. It seems that the original bug filer has provided plenty of repro. If that is not the case I'd be happy to go through the process of digging up all I can from my machine. [2009-02-26 01:30:01] joe at lastpass dot com Happens at somewhere between 3500 and 6400 characters on every Linux platform I have access to (x86 and x86_64): PHP 5.2.6-3ubuntu2 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 13 2009 20:07:08) PHP 5.2.6-2ubuntu4.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 11 2009 20:44:58) PHP 5.2.4-2ubuntu5.5 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 11 2009 20:09:11) PHP 5.2.6-3ubuntu2 with Suhosin-Patch 0.9.6.2 (cli) (built: Feb 13 2009 20:20:01) 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=45546 -- Edit this bug report at http://bugs.php.net/bug.php?id=45546edit=1
Bug #50737 [Com]: stream_set_blocking creates high cpu usage
Edit report at http://bugs.php.net/bug.php?id=50737edit=1 ID: 50737 Comment by: pdescham49 at gmail dot com Reported by:jason at lentink dot net Summary:stream_set_blocking creates high cpu usage Status: Bogus Type: Bug Package:Streams related Operating System: Linux PHP Version:5.2.12 Block user comment: N New Comment: Wow. Nice thread, You'll go far in life with an attitude like that. I assume you are not being paid for this support. If you were my employee I would fire you on the spot. Previous Comments: [2010-01-28 08:44:29] j...@php.net Stil a FAIL: Warning: fsockopen(): php_network_getaddresses: getaddrinfo failed: Name or service not known [2010-01-15 10:48:09] jason at lentink dot net Then we go back to the first post and there is a 2 line example of the problem. Reproduce code: --- ?php $socket = fsockopen(somehost, 631313, $errno, $errstr); stream_set_blocking($socket, 0); // non blocking this is enough to trigger the problem. I hope this is short enough. [2010-01-15 08:56:36] j...@php.net Strike 3. As long as you can not provide a short reproducing script (like described in my first comment to this report) the bug is most likely something you did wrong. [2010-01-14 12:53:42] jason at lentink dot net Whatever you want :) http://www.grasvezel.nl/media/software/cpuload.txt Here is a complete undressed file which only has the problem. [2010-01-14 12:17:19] j...@php.net I asked for small, complete script NOT for a framework. 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=50737 -- Edit this bug report at http://bugs.php.net/bug.php?id=50737edit=1
[PHP-BUG] Bug #53078 [NEW]: Europe/London is in two timezones
From:
Operating system: Ubuntu Linux 10.04
PHP version: 5.3.3
Package: *Calendar problems
Bug Type: Bug
Bug description:Europe/London is in two timezones
Description:
I was about to create a timezone selector widget with map and select box
with the timezone IDs, but when I asked for the full timezone list with
DateTimeZone::listAbbreviations() I saw that Europe/London is in two
different timezones according to the Greenwich Mean Time:
- bdst: DST is TRUE, offset is GMT+2 hours (== DST:false and GMT+1)
- bst: offset is GMT+1 hour and DST doesn't matter, both TRUE (== GMT+0)
and FALSE (== GMT+1) can be found
- gmt: DST is FALSE, offset is GMT+0. It is GMT of course :)
How can this be possible?
Test script:
---
?php
$dtz = DateTimeZone::listAbbreviations();
die('pre'.print_r($dtz, true).'/pre');
// and search for 'Europe/London' or see description below
Expected result:
GMT+1 in Summer and GMT+0 otherwise. Something like:
[bst] = array(25) {
[0] = array(3) {
[dst] = bool(true)
[offset] = int(3600)
[timezone_id] = string(13) Europe/London
}
...
}
...
[gmt] = array(30) {
...
[26] = array(3) {
[dst] = bool(false)
[offset] = int(0)
[timezone_id] = string(13) Europe/London
}
...
}
Actual result:
--
...
[bdst] = array(8) {
[0] = array(3) {
[dst] = bool(true)
[offset] = int(7200)
[timezone_id] = string(13) Europe/London
}
...
}
...
[bst] = array(25) {
[0] = array(3) {
[dst] = bool(false)
[offset] = int(3600)
[timezone_id] = string(13) Europe/London
}
[1] = array(3) {
[dst] = bool(true)
[offset] = int(3600)
[timezone_id] = string(13) Europe/London
}
...
}
...
[gmt] = array(30) {
...
[26] = array(3) {
[dst] = bool(false)
[offset] = int(0)
[timezone_id] = string(13) Europe/London
}
...
}
...
--
Edit bug report at http://bugs.php.net/bug.php?id=53078edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53078r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53078r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53078r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53078r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53078r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53078r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53078r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53078r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53078r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53078r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53078r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53078r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53078r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53078r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53078r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53078r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53078r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53078r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53078r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53078r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53078r=mysqlcfg
[PHP-BUG] Bug #53079 [NEW]: SSH2 randomly works along side MySQL
From: Operating system: CentOS 5.5 PHP version: 5.3.3 Package: Unknown/Other Function Bug Type: Bug Bug description:SSH2 randomly works along side MySQL Description: ssh2_exec and ssh2_shell functions randomly work. Expected result: These functions work perfectly when no MySQL connection is active. They should work when a MySQL connection is active too. Actual result: -- When a MySQL connection is active, the ssh2_exec and ssh2_shell functions randomly pick up on the MySQL stream, making the data returned from the ssh2_exec and ssh2_shell functions corrupt. I am guessing that there is a conflict between the 2 extensions. -- Edit bug report at http://bugs.php.net/bug.php?id=53079edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53079r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53079r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53079r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53079r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53079r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53079r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53079r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53079r=needscript Try newer version: http://bugs.php.net/fix.php?id=53079r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53079r=support Expected behavior: http://bugs.php.net/fix.php?id=53079r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53079r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53079r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53079r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53079r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53079r=dst IIS Stability: http://bugs.php.net/fix.php?id=53079r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53079r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53079r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53079r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53079r=mysqlcfg
Bug #31455 [Com]: multiple session_start() creates multiple session cookies in HTTP-Response
Edit report at http://bugs.php.net/bug.php?id=31455edit=1
ID: 31455
Comment by: WarrenGaebel at FriendlyNeighbourGuide dot ca
Reported by:rene dot bangemann at web dot de
Summary:multiple session_start() creates multiple session
cookies in HTTP-Response
Status: Wont fix
Type: Bug
Package:Session related
Operating System: Win32
PHP Version:4CVS, 5CVS
Assigned To:tony2001
Block user comment: N
New Comment:
I am experiencing a similar, but not identical problem.
I reload my page multiple times, using session_start() every time it
loads. JavaScript sets cookies that I use in php. When using Internet
Explorer, $_ENV[HTTP_COOKIE] contains multiple entries for each
cookie. This does not happen with Firefox.
As near as I can figure so far, when executing code at a domain named
x.y.z, Internet Explorer sends the cookies for x.y.z followed by the
cookies for y.z. Php then puts both sets of cookies into
$_ENV[HTTP_COOKIE].
Perhaps this may be considered a PHP bug, perhaps not. IMHO, this is an
Internet Explorer bug. I post it here in the hope that it may help you
resolve your problem.
... Warren Gaebel, B.A., B.C.S.
Previous Comments:
[2005-02-14 00:18:30] rene dot bangemann at web dot de
Ok, you are right that someone could start several sessions within one
request. But thats not my use case:
I'm using a PHP script to perform some actions which can take up to some
hours.
E.G. for displaying progress information about the running process a
second php script needs to access the session vars. This forces to close
the session file via session_write_close() in the first script. After
this function call, the second PHP script can do a session_start() and
access the current values of the session vars.
After finishing the second request the session file will be closed
again.
If the first script has to store new values of session related vars in
the session file, it uses a combination of session_start() and
session_write_close() to update the content within the session file.
Unfortunatly in my case this can happen very often (because of the long
execution time).
Under normal circumstances I could live with this feature :-). But I'm
afraid that in combination with HTML frames this behaviour of PHP can
force deadlocks in different browsers like Internet Explorer or Mozilla.
Unfortunately I can't present a 100% working example for reproducable
deadlocks.
I would suggest to create a flag containing true or false, if the Cookie
for the current session id already was sent or not.
If the cookie wasn't already sent, or the used session id changes, of
course another Cookie has to be sent.
[2005-02-13 18:03:51] tony2...@php.net
Okay, no more dirty hacks =)
Marking it as won't fix and considering as a feature.
[2005-02-13 09:44:30] sni...@php.net
Then how would you handle this (very unlikely :) code:
?php
session_name('foo1');
session_id('foobar1');
session_start();
session_write_close();
session_name('foo2');
session_id('foobar2');
session_start();
session_write_close();
session_name('foo3');
session_id('foobar3');
session_start();
session_write_close();
?
Yes, someone MIGHT rely on that kind of code too.
And as it IS possible to start as many _different_ sessions in single
request, why should we not allow it?
(this is actually for Tony, FYI when he figures out how to fix this bug
:)
[2005-01-09 15:49:13] rene dot bangemann at web dot de
Description:
I'm using a combination of session_start() and session_write_close() to
access and update session variables.
In some scripts this function calls will be executed up to 50 times.
For each call of session_start() a HTTP-Header with the PHP session id
will be created in the same HTTP response.
I would expect, that in the HTTP response will be only one HTTP-Header
with the session id.
Reproduce code:
---
?php
session_start();
session_write_close();
session_start();
session_write_close();
session_start();
session_write_close();
?
Expected result:
HTTP-Header Set-Cookie with PHP session id created only once in HTTP
response
Actual result:
--
The code above will create a HTTP response with three identical HTTP
Set-Cookie headers
--
Edit this bug report at http://bugs.php.net/bug.php?id=31455edit=1
Bug #53079 [Opn]: SSH2 randomly works along side MySQL
Edit report at http://bugs.php.net/bug.php?id=53079edit=1 ID: 53079 User updated by:josh at servebyte dot com Reported by:josh at servebyte dot com Summary:SSH2 randomly works along side MySQL Status: Open Type: Bug Package:Unknown/Other Function Operating System: CentOS 5.5 PHP Version:5.3.3 Block user comment: N New Comment: ssh2 0.11.0 php 3.3.3 libssh2 1.2.7-1.el5.rf Previous Comments: [2010-10-15 23:25:07] josh at servebyte dot com Description: ssh2_exec and ssh2_shell functions randomly work. Expected result: These functions work perfectly when no MySQL connection is active. They should work when a MySQL connection is active too. Actual result: -- When a MySQL connection is active, the ssh2_exec and ssh2_shell functions randomly pick up on the MySQL stream, making the data returned from the ssh2_exec and ssh2_shell functions corrupt. I am guessing that there is a conflict between the 2 extensions. -- Edit this bug report at http://bugs.php.net/bug.php?id=53079edit=1
Bug #40880 [Com]: public-protected inheritance causes fatal
Edit report at http://bugs.php.net/bug.php?id=40880edit=1
ID: 40880
Comment by: robertoblanko at gmail dot com
Reported by:prometheus__0 at hotmail dot com
Summary:public-protected inheritance causes fatal
Status: Bogus
Type: Bug
Package:Class/Object related
Operating System: SUSE SLES 10
PHP Version:5CVS-2007-03-21 (snap)
Block user comment: N
New Comment:
Same problem here. You cannot actually apply the singleton pattern to
subclasses with this behavior. I do not see any reason for not calling
this a bug.
Previous Comments:
[2010-09-07 12:58:35] nickyla83 at yahoo dot fr
I'm in the same situation as our friend prometheus here, I am trying
to use a singleton pattern and logically, this should involve being able
to encapsulate the subcalasses information particularly setting up a
private constructor for the singleton subclass, IT DEFINITELY DOES MAKE
SENSE, so please try to take this under consideration for the next php
engine release.
[2007-03-21 10:05:25] prometheus__0 at hotmail dot com
is this the 'php'-dev definition?
i'm asking cause wraping a singleton pattern around a subclass makes
sense
and the same example is valid for java and c++
to ask it differently: why is it working this way in php? (i'm
interested in the background of this)
my point is that 2 languages allow it and there is an example which is
valid, not?
[2007-03-21 09:43:47] der...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is how it works... you can always open up an API through a new
extended interface, but not hide more.
[2007-03-21 09:38:19] prometheus__0 at hotmail dot com
Description:
(1) It is not possible to make inherited functions more private, which
seems like a bug to me but
(2) it is possible to make inherited functions more public, which
shouldn't be possible, afaik.
The example code causes the fatal (1)
if you change
protected function __construct()
to
public function __construct()
from class b
and
public function __construct(){
to
protected function __construct(){
from class a
it works (2)
since i'm not an expert in oop i tried the same example in java and it
works the complete opposite way (the b functions can be more private but
not more public)
and in C++ it's the same
i know bug report http://bugs.php.net/bug.php?id=34237 but it considers
point (2)
point (1) is still a bug in my opinion
Reproduce code:
---
?php
class a{
public function __construct(){
print(public construct\n);
}
}
class b extends a{
protected function __construct(){
print(protected construct\n);
}
public static function getInstance(){
return new b();
}
}
$b = b::getInstance();
?
Expected result:
protected construct
Actual result:
--
Fatal error: Access level to b::__construct() must be public (as in
class a) in PHPDocument2 on line 16
--
Edit this bug report at http://bugs.php.net/bug.php?id=40880edit=1
[PHP-BUG] Bug #53080 [NEW]: Error when request on port 3306
From:
Operating system: Windows XP
PHP version: Irrelevant
Package: cURL related
Bug Type: Bug
Bug description:Error when request on port 3306
Description:
When I get a request from a host which is using mysql, I'll get an error I
can't turn off (R (strange chars) Host 'X' is not allowed to connect
to this MySQL server). I can't suppress this error.
Test script:
---
$host = 'www.hostUSINGmysql.com'; // for example
www.schutterijkleintuindorp.nl
$ch = curl_init();
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_NOBODY, true);
curl_setopt($ch, CURLOPT_TIMEOUT, 5);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, false);
curl_setopt($ch, CURLOPT_URL, $host);
curl_setopt($ch, CURLOPT_PORT, 3306);
$test = curl_exec($ch);
if(!empty($test))
{
$page .= 'JA - 3306br /';
}
else
{
$page .= 'Nee - 3306br /';
}
echo $page;
curl_close($ch);
Expected result:
Getting JA - 3306 or NEE 3306
--
Edit bug report at http://bugs.php.net/bug.php?id=53080edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53080r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53080r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53080r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53080r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53080r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53080r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53080r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53080r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53080r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53080r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53080r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53080r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53080r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53080r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53080r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53080r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53080r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53080r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53080r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53080r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53080r=mysqlcfg
Bug #41350 [NoF-Csd]: Error in my_thread_global_end()
Edit report at http://bugs.php.net/bug.php?id=41350edit=1 ID: 41350 Updated by: fel...@php.net Reported by:graham at directhostinguk dot com Summary:Error in my_thread_global_end() -Status: No Feedback +Status: Closed Type: Bug Package:MySQL related Operating System: * PHP Version:5.2.6 Assigned To:scottmac Block user comment: N Previous Comments: [2009-05-11 06:47:00] j_holyfield05 at hotmail dot com This solution works perfect for me http://tinyurl.com/php-mysql-bug PHP team should replace or update the DLL/binary in all their newer releases thankz [2009-03-16 16:48:58] chris at crgs dot co dot uk Just to confirm that this is fixed in the updated libmysql.dll recently released as part of MySQL 5.0.77. If you have MySQL 5.0.77 installed, just replace the copy of libmysql.dll currently provided with PHP with the version from 'C:\Program Files\MySQL\MySQL Server 5.0\bin' (or equivalent folder) and you should be good to go. It would be great if the PHP team could update the copy of libmysql.dll supplied in the next release of PHP to 5.0.77 or above. Thanks to all those who have worked to get this fixed. [2009-03-10 00:14:52] paul at orac dot clara dot co dot uk Libmysql.dll from Mysql 5.0.77 seems to work fine and doesn't have the problems detailed in bug #46842. Libmysql.dll from Mysql 5.1.32 still doesn't work. I don't know why the PHP folks have closed #46842 as Bogus when it quite clearly is not. [2009-03-03 00:12:17] chaz_meister_rock at yahoo dot com Same error in PHP 5.2.9. [2009-02-20 03:14:23] kram0815 at gmx dot net have this bug too on my system uname -a = 2.6.26-1-amd64 Debian Lenny php -v = PHP 5.2.6-1+lenny2 mysql -V = Ver 14.12 Distrib 5.0.51a msg in /var/log/apache2/error.log = Error in my_thread_global_end(): 41 threads didn't exit 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=41350 -- Edit this bug report at http://bugs.php.net/bug.php?id=41350edit=1
Bug #40479 [NoF-Fbk]: zend_mm_heap corrupted
Edit report at http://bugs.php.net/bug.php?id=40479edit=1 ID: 40479 Updated by: fel...@php.net Reported by:rrossi at maggioli dot it Summary:zend_mm_heap corrupted -Status: No Feedback +Status: Feedback Type: Bug Package:Reproducible crash Operating System: Suse Linux 9.0 PHP Version:5.2.1 Block user comment: N New Comment: 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 ?php and ends 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. Previous Comments: [2010-09-16 13:23:05] michael202 at gmx dot de The problem is still in 5.3.3 on Suse 11.2, but it is not reproducible :-( Sometimes it is twice a day sometimes every few days. Apache starts giving these messages: child pid x exit signal Segmentation fault (11) And if your are lucky, the scripts still return xml-results. If you get a no result from the script (i.a. white page in browser), you'll need a apache stop and start (graceful does not help) and the error_log says: seg fault or similar nasty error detected in the parent process [2010-08-09 10:32:10] sht dot alien at gmx dot net I had it coming when I started my unittests. But it happened out of nowhere ^^ Wehen I set USE_ZEND_ALLOC=0 it didn't go away, but instead I got a debug backtrace (as seen below). But I came up with a solution: ZendDebugger was the root of all evil. I'll check out if there's a newer version available... FAILURES! Tests: 284, Assertions: 1911, Errors: 4, Incomplete: 10, Skipped: 9. *** glibc detected *** /usr/local/zend/bin/php: free(): invalid pointer: 0x035b5a8f *** === Backtrace: = /lib/libc.so.6(+0x775b6)[0x7f56f13105b6] /lib/libc.so.6(cfree+0x73)[0x7f56f1316e53] /usr/local/zend/bin/php(zend_hash_destroy+0x7b)[0x656b7b] /usr/local/zend/bin/php(destroy_zend_class+0x55)[0x641845] /usr/local/zend/bin/php[0x656822] /usr/local/zend/bin/php(zend_hash_reverse_apply+0x59)[0x656929] /usr/local/zend/bin/php[0x63e486] /usr/local/zend/bin/php[0x64a8b2] /usr/local/zend/bin/php(php_request_shutdown+0x1ae)[0x5f9cce] /usr/local/zend/bin/php[0x6d2be4] /lib/libc.so.6(__libc_start_main+0xfd)[0x7f56f12b7c4d] /usr/local/zend/bin/php[0x45ffaa] === Memory map: 0040-009d8000 r-xp 08:01 12588460 /usr/local/zend/bin/php 00ad8000-00b5f000 rwxp 005d8000 08:01 12588460 /usr/local/zend/bin/php 00b5f000-00b7f000 rwxp 00:00 0 02b4e000-04999000 rwxp 00:00 0 [heap] 7f56e000-7f56e0021000 rwxp 00:00 0 7f56e0021000-7f56e400 ---p 00:00 0 7f56e5309000-7f56e530e000 r-xp 08:01 15842 /lib/libnss_dns-2.11.1.so 7f56e530e000-7f56e550d000 ---p 5000 08:01 15842 /lib/libnss_dns-2.11.1.so 7f56e550d000-7f56e550e000 r-xp 4000 08:01 15842 /lib/libnss_dns-2.11.1.so 7f56e550e000-7f56e550f000 rwxp 5000 08:01 15842 /lib/libnss_dns-2.11.1.so 7f56e550f000-7f56e5511000 r-xp 08:01 41397 /lib/libnss_mdns4_minimal.so.2 7f56e5511000-7f56e571 ---p 2000 08:01 41397 /lib/libnss_mdns4_minimal.so.2 7f56e571-7f56e5711000 r-xp 1000 08:01 41397 /lib/libnss_mdns4_minimal.so.2 7f56e5711000-7f56e5712000 rwxp 2000 08:01 41397 /lib/libnss_mdns4_minimal.so.2 7f56e5712000-7f56e5714000 rwxp 00:00 0 7f56e5794000-7f56e58f7000 r-xp 08:01 12582939 /usr/local/zend/lib/debugger/php-5.3.x/ZendDebugger.so 7f56e58f7000-7f56e59f7000 ---p 00163000 08:01 12582939 /usr/local/zend/lib/debugger/php-5.3.x/ZendDebugger.so 7f56e59f7000-7f56e5a21000 rwxp 00163000 08:01 12582939 /usr/local/zend/lib/debugger/php-5.3.x/ZendDebugger.so 7f56e5a21000-7f56e5a27000 rwxp 00:00 0 7f56e5a27000-7f56e5a69000 r-xp 08:01 12583569 /usr/local/zend/lib/optimizerplus/php-5.3.x/ZendOptimizerPlus.so 7f56e5a69000-7f56e5b69000 ---p 00042000 08:01 12583569 /usr/local/zend/lib/optimizerplus/php-5.3.x/ZendOptimizerPlus.so 7f56e5b69000-7f56e5b6b000 rwxp 00042000 08:01 12583569 /usr/local/zend/lib/optimizerplus/php-5.3.x/ZendOptimizerPlus.so
Bug #51105 [NoF-Bgs]: PHP str_repeat() Function Integer Overflow
Edit report at http://bugs.php.net/bug.php?id=51105edit=1
ID: 51105
Updated by: fel...@php.net
Reported by:r3d dot w0rm at yahoo dot com
Summary:PHP str_repeat() Function Integer Overflow
-Status: No Feedback
+Status: Bogus
Type: Bug
Package:Strings related
Operating System: All
PHP Version:5.3.2RC2
Block user comment: N
New Comment:
I cannot reproduce this. (probably already fixed)
Previous Comments:
[2010-07-16 01:41:46] php at crummett dot us
PHP says you do not have enough memory to do this. The string generated
would be 8GiB in size.
Also, this can be simplified as:
Reproduce code:
---
?php
str_repeat('0x0x0x0x',9);
Actual result:
---
Fatal error: Possible integer overflow in memory allocation (8 *
9 + 1) in crash.php on line 2
[2010-03-01 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.
[2010-02-21 17:26:53] paj...@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.
[2010-02-21 16:33:01] r3d dot w0rm at yahoo dot com
Os : win Xp Sp 2 , Fedora 11
Cpu : 2.2
[2010-02-21 15:14:28] paj...@php.net
Which processor and OS do you use? I get the expected fatal error here.
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=51105
--
Edit this bug report at http://bugs.php.net/bug.php?id=51105edit=1
Bug #51038 [Opn-Fbk]: HTML entities with invalid chars
Edit report at http://bugs.php.net/bug.php?id=51038edit=1 ID: 51038 Updated by: fel...@php.net Reported by:jvp at 4ssl dot us Summary:HTML entities with invalid chars -Status: Open +Status: Feedback Type: Bug Package:*General Issues Operating System: centos 5.4 x86_64 PHP Version:5.2.12 Block user comment: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2010-02-15 21:23:37] jvp at 4ssl dot us .diff is available here: http://4ssl.us/webdev/ -- thank you, johann [2010-02-15 21:18:34] fel...@php.net Show us the .diff file related to this test failure. [2010-02-13 01:16:48] jvp at 4ssl dot us Description: HTML entities with invalid chars [ext/standard/tests/strings/htmlentities-utf.phpt] Reproduce code: --- 'make test' failure Expected result: pass Actual result: -- fail -- Edit this bug report at http://bugs.php.net/bug.php?id=51038edit=1
Bug #51034 [NoF-Fbk]: test for PDORow::queryString property numeric offsets / Crash
Edit report at http://bugs.php.net/bug.php?id=51034edit=1 ID: 51034 Updated by: fel...@php.net Reported by:jvp at 4ssl dot us Summary:test for PDORow::queryString property numeric offsets / Crash -Status: No Feedback +Status: Feedback Type: Bug Package:PDO related Operating System: centos 5.4 x86_64 PHP Version:5.2.12 Block user comment: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2010-02-23 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. [2010-02-15 21:19:44] fel...@php.net Show us the .diff file related to this test failure. [2010-02-13 00:59:32] jvp at 4ssl dot us Description: Bug #44327 (PDORow::queryString property numeric offsets / Crash) [ext/pdo_mysql/tests/bug44327.phpt] Reproduce code: --- 'make test' failure Expected result: pass Actual result: -- fail -- Edit this bug report at http://bugs.php.net/bug.php?id=51034edit=1
Bug #53006 [Asn-Csd]: stream_get_contents offset max is 1165
Edit report at http://bugs.php.net/bug.php?id=53006edit=1 ID: 53006 Updated by: cataphr...@php.net Reported by:poulpillusion at free dot fr Summary:stream_get_contents offset max is 1165 -Status: Assigned +Status: Closed Type: Bug Package:Streams related Operating System: Linux Aptosid PHP Version:5.3.3 Assigned To:cataphract Block user comment: N Previous Comments: [2010-10-15 01:11:04] poulpillusion at free dot fr You fixed it ! I assume this is your fix : http://svn.php.net/viewvc/php/php-src/trunk/main/streams/streams.c?r1=303414r2=304354 Even if you did all the work, I feel a little proud. Thank you very much, cataphract. [2010-10-14 05:19:59] cataphr...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-10-14 05:15:19] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=304384 Log: - [DOC] Reverted rev #304382 and rev #304380, as I figured out a way to fix the erratic behavior without breaking backwards compatibility. Namely, $offset retains SEEK_SET behavior but actually SEEK_CUR is passed to _php_stream_seek, if possible, by moving the offset stream-gt;position bytes. - Addresses bug #53006. [2010-10-14 04:03:20] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=304380 Log: - [DOC] Changed stream_get_contents() so that the offset is relative to the current position (seek with SEEK_CUR, not SEEK_SET). Only positive values are allowed. This breaking change is necessary to fix the erratic behavior in streams without a seek handlder. Addresses bug #53006. #Note that the example on the doc page for stream_get_contents() may fail #without this change. #This change is also in the spirit of stream_get_contents(), whose description #is quot;Reads all remaining bytes (or up to maxlen bytes) from a stream...quot;. #Previous behavior allowed setting the file pointer to positions before the #current one, so they wouldn't be quot;remaining bytesquot;. The previous behavior was #also inconsistent in that it allowed an moving to offset 1, 2, ..., but not 0. [2010-10-13 23:59:37] poulpillusion at free dot fr Ok so... is there anything else I can do to help you fix this bug ? I mean : more testing, more feedback ? 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=53006 -- Edit this bug report at http://bugs.php.net/bug.php?id=53006edit=1
Bug #53006 [Csd]: stream_get_contents offset max is 1165
Edit report at http://bugs.php.net/bug.php?id=53006edit=1 ID: 53006 Updated by: cataphr...@php.net Reported by:poulpillusion at free dot fr Summary:stream_get_contents offset max is 1165 Status: Closed Type: Bug Package:Streams related Operating System: Linux Aptosid PHP Version:5.3.3 Assigned To:cataphract Block user comment: N New Comment: That may or may not have helped (probably not, but I'm not sure, since I couldn't reproduce the blocking). What fixed it for me was this one: http://svn.php.net/viewvc/?view=revisionamp;revision=304384 Thank you for helping making PHP better. Previous Comments: [2010-10-15 01:11:04] poulpillusion at free dot fr You fixed it ! I assume this is your fix : http://svn.php.net/viewvc/php/php-src/trunk/main/streams/streams.c?r1=303414r2=304354 Even if you did all the work, I feel a little proud. Thank you very much, cataphract. [2010-10-14 05:19:59] cataphr...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-10-14 05:15:19] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=304384 Log: - [DOC] Reverted rev #304382 and rev #304380, as I figured out a way to fix the erratic behavior without breaking backwards compatibility. Namely, $offset retains SEEK_SET behavior but actually SEEK_CUR is passed to _php_stream_seek, if possible, by moving the offset stream-gt;position bytes. - Addresses bug #53006. [2010-10-14 04:03:20] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=304380 Log: - [DOC] Changed stream_get_contents() so that the offset is relative to the current position (seek with SEEK_CUR, not SEEK_SET). Only positive values are allowed. This breaking change is necessary to fix the erratic behavior in streams without a seek handlder. Addresses bug #53006. #Note that the example on the doc page for stream_get_contents() may fail #without this change. #This change is also in the spirit of stream_get_contents(), whose description #is quot;Reads all remaining bytes (or up to maxlen bytes) from a stream...quot;. #Previous behavior allowed setting the file pointer to positions before the #current one, so they wouldn't be quot;remaining bytesquot;. The previous behavior was #also inconsistent in that it allowed an moving to offset 1, 2, ..., but not 0. [2010-10-13 23:59:37] poulpillusion at free dot fr Ok so... is there anything else I can do to help you fix this bug ? I mean : more testing, more feedback ? 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=53006 -- Edit this bug report at http://bugs.php.net/bug.php?id=53006edit=1
Bug #53076 [Opn-Fbk]: file_put_contents doesn't release the LOCK_EX
Edit report at http://bugs.php.net/bug.php?id=53076edit=1
ID: 53076
Updated by: cataphr...@php.net
Reported by:admin at saltwaterc dot net
Summary:file_put_contents doesn't release the LOCK_EX
-Status: Open
+Status: Feedback
Type: Bug
Package:Scripting Engine problem
Operating System: Irrelevant
PHP Version:5.3.3
Block user comment: N
New Comment:
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?
Previous Comments:
[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;
[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 #53076 [Fbk]: file_put_contents doesn't release the LOCK_EX
Edit report at http://bugs.php.net/bug.php?id=53076edit=1
ID: 53076
Updated by: ras...@php.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:
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
Previous Comments:
[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;
[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 #53061 [Opn]: filesystem functions deal poorly with out of disk space conditions
Edit report at http://bugs.php.net/bug.php?id=53061edit=1
ID: 53061
Updated by: cataphr...@php.net
Reported by:crrodriguez at opensuse dot org
Summary:filesystem functions deal poorly with out of disk
space conditions
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: *nix
PHP Version:5.3SVN-2010-10-14 (SVN)
Block user comment: N
New Comment:
Well, there's the hint that the return value is smaller than
strlen(str_repeat(fail, 1024000)) = 4096000.
I'm not sure if adding a warning here is appropriate, we try to avoid
warnings in correct scripts so that programmers don't have to use @ to
have notice/warning free code. Even if we consider a disk full an
exceptional circumstance that merited breaking this guideline, a warning
would be of little use; unless the logs are in a separate filesystems,
the warning message would not be able to be logged.
So:
* We can't return false, because a part of the data may have been
written and we need to return how much.
* A warning would be of no use in most circumstances.
Maybe we could return a false+warning if no data has been written, but
it seems dangerous because sometimes programmers would be warned of an
out-of-disk-space conditional and other times they wouldn't.
Previous Comments:
[2010-10-15 02:47:11] crrodriguez at opensuse dot org
A liltte bit better test case:
# dd if=/dev/zero of=/tmp/vfs bs=1024 count=1024
# losetup /dev/loop0 /tmp/vfs
# mkfs -t ext2 -m 1 -v /dev/loop0
# mkdir /mnt/vfs
# mount -t ext2 /dev/loop0 /mnt/vfs
?php
$fp = fopen('/mnt/vfs/foo.txt', 'wb');
var_dump(fwrite($fp, str_repeat(fail, 1024000)));
var_dump(fflush($fp));
var_dump(fclose($fp));
?
int(1003520)
bool(true)
bool(true)
ls -l /mnt/vfs/foo.txt
-rw-r--r-- 1 root root 1003520 oct 14 21:43 /mnt/vfs/foo.txt
Partial data on disk, no warning or return values hinting the problem.
[2010-10-14 07:00:13] cataphr...@php.net
Why would fflush return false? Nothing was written by fwrite, so the
flush is a no-op.
[2010-10-14 06:35:11] crrodriguez at opensuse dot org
Description:
Filesystem functions have IMHO the wrong behaviuor on disk-full
conditions
Test script:
---
?php
$fp = fopen('/dev/full', 'wb');
var_dump(fwrite($fp, fail));
var_dump(fflush($fp));
var_dump(fclose($fp));
Expected result:
bool(false) and warning ...No space left on device.. (aka, handle
ENOSPC)
bool(false)
bool(true)
Actual result:
--
int(0)
bool(true)
bool(true)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53061edit=1
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: crrodriguez at opensuse dot org
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:
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/ ;)
Previous Comments:
[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;
[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,
Bug #53078 [Opn-Bgs]: Europe/London is in two timezones
Edit report at http://bugs.php.net/bug.php?id=53078edit=1
ID: 53078
Updated by: cataphr...@php.net
Reported by:gixx at freemail dot hu
Summary:Europe/London is in two timezones
-Status: Open
+Status: Bogus
Type: Bug
Package:*Calendar problems
Operating System: Ubuntu Linux 10.04
PHP Version:5.3.3
Block user comment: N
New Comment:
That's simply because there were times Europe/London had an 1 hour
offset to GMT (2 in the summer).
Previous Comments:
[2010-10-15 23:21:11] gixx at freemail dot hu
Description:
I was about to create a timezone selector widget with map and select box
with the timezone IDs, but when I asked for the full timezone list with
DateTimeZone::listAbbreviations() I saw that Europe/London is in two
different timezones according to the Greenwich Mean Time:
- bdst: DST is TRUE, offset is GMT+2 hours (== DST:false and GMT+1)
- bst: offset is GMT+1 hour and DST doesn't matter, both TRUE (==
GMT+0) and FALSE (== GMT+1) can be found
- gmt: DST is FALSE, offset is GMT+0. It is GMT of course :)
How can this be possible?
Test script:
---
?php
$dtz = DateTimeZone::listAbbreviations();
die('pre'.print_r($dtz, true).'/pre');
// and search for 'Europe/London' or see description below
Expected result:
GMT+1 in Summer and GMT+0 otherwise. Something like:
[bst] = array(25) {
[0] = array(3) {
[dst] = bool(true)
[offset] = int(3600)
[timezone_id] = string(13) Europe/London
}
...
}
...
[gmt] = array(30) {
...
[26] = array(3) {
[dst] = bool(false)
[offset] = int(0)
[timezone_id] = string(13) Europe/London
}
...
}
Actual result:
--
...
[bdst] = array(8) {
[0] = array(3) {
[dst] = bool(true)
[offset] = int(7200)
[timezone_id] = string(13) Europe/London
}
...
}
...
[bst] = array(25) {
[0] = array(3) {
[dst] = bool(false)
[offset] = int(3600)
[timezone_id] = string(13) Europe/London
}
[1] = array(3) {
[dst] = bool(true)
[offset] = int(3600)
[timezone_id] = string(13) Europe/London
}
...
}
...
[gmt] = array(30) {
...
[26] = array(3) {
[dst] = bool(false)
[offset] = int(0)
[timezone_id] = string(13) Europe/London
}
...
}
...
--
Edit this bug report at http://bugs.php.net/bug.php?id=53078edit=1
