Req #52052 [PATCH]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 Patch added by: f...@php.net Reported by: ef-lists at email dot de Summary: add syslog support to FPM Status: Assigned Type: Feature/Change Request Package: FPM related Operating System: Linux/*NIX PHP Version: 5.3SVN-2010-06-11 (SVN) Assigned To: fat New Comment: The following patch has been added/updated: Patch Name: fpm-syslog.v2.patch Revision: 1276418186 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v2.patch&revision=1276418186 Previous Comments: [2010-06-12 19:54:05] ef-lists at email dot de Great job! :-) I'll try it out and report feedback to you. [2010-06-12 18:49:35] f...@php.net The attached patch should activate syslog sypport to error_log only. You can try it on trunk. change error_log to "syslog" You can also set syslog_facility and syslog_ident to feet your needs. But default values should be OK. I'm working on the slowlog patch also but it's a bit more complicated. ++ Jerome [2010-06-12 18:47:15] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v1.patch Revision: 1276361235 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v1.patch&revision=1276361235 [2010-06-11 18:10:10] ef-lists at email dot de Description: At current, FPM only allows logging to local files, both for the ErrorLog and SlowLog. Using syslog aids the administrator greatly in centralizing logfiles. Also PHP itself has syslog support, so FPM should consequently have it, too. I hereby ask to add syslog support to FPM. -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
Req #52052 [Com]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 Comment by: f...@php.net Reported by: ef-lists at email dot de Summary: add syslog support to FPM Status: Assigned Type: Feature/Change Request Package: FPM related Operating System: Linux/*NIX PHP Version: 5.3SVN-2010-06-11 (SVN) Assigned To: fat New Comment: You can try instead the new revision of the patch I've just attached. It adds sending slowlog to syslog. Set slowlog to syslog. Moreover you can set slowlog_syslog_level to same values as log_level. By default it's LOG_DEBUG. There is no way to change the ident and the facility for slowlog, it takes the same values as the globals ones (syslog_facility and syslog_event). There is no need to because the pool name is prepended to every slowlog message. Previous Comments: [2010-06-13 10:36:27] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v2.patch Revision: 1276418186 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v2.patch&revision=1276418186 [2010-06-12 19:54:05] ef-lists at email dot de Great job! :-) I'll try it out and report feedback to you. [2010-06-12 18:49:35] f...@php.net The attached patch should activate syslog sypport to error_log only. You can try it on trunk. change error_log to "syslog" You can also set syslog_facility and syslog_ident to feet your needs. But default values should be OK. I'm working on the slowlog patch also but it's a bit more complicated. ++ Jerome [2010-06-12 18:47:15] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v1.patch Revision: 1276361235 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v1.patch&revision=1276361235 [2010-06-11 18:10:10] ef-lists at email dot de Description: At current, FPM only allows logging to local files, both for the ErrorLog and SlowLog. Using syslog aids the administrator greatly in centralizing logfiles. Also PHP itself has syslog support, so FPM should consequently have it, too. I hereby ask to add syslog support to FPM. -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
Req #52052 [PATCH]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 Patch added by: f...@php.net Reported by: ef-lists at email dot de Summary: add syslog support to FPM Status: Assigned Type: Feature/Change Request Package: FPM related Operating System: Linux/*NIX PHP Version: 5.3SVN-2010-06-11 (SVN) Assigned To: fat New Comment: The following patch has been added/updated: Patch Name: fpm-syslog.v3.patch Revision: 1276419780 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v3.patch&revision=1276419780 Previous Comments: [2010-06-13 10:41:26] f...@php.net You can try instead the new revision of the patch I've just attached. It adds sending slowlog to syslog. Set slowlog to syslog. Moreover you can set slowlog_syslog_level to same values as log_level. By default it's LOG_DEBUG. There is no way to change the ident and the facility for slowlog, it takes the same values as the globals ones (syslog_facility and syslog_event). There is no need to because the pool name is prepended to every slowlog message. [2010-06-13 10:36:27] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v2.patch Revision: 1276418186 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v2.patch&revision=1276418186 [2010-06-12 19:54:05] ef-lists at email dot de Great job! :-) I'll try it out and report feedback to you. [2010-06-12 18:49:35] f...@php.net The attached patch should activate syslog sypport to error_log only. You can try it on trunk. change error_log to "syslog" You can also set syslog_facility and syslog_ident to feet your needs. But default values should be OK. I'm working on the slowlog patch also but it's a bit more complicated. ++ Jerome [2010-06-12 18:47:15] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v1.patch Revision: 1276361235 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v1.patch&revision=1276361235 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=52052 -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
Req #52052 [Com]: add syslog support to FPM
Edit report at http://bugs.php.net/bug.php?id=52052&edit=1 ID: 52052 Comment by: f...@php.net Reported by: ef-lists at email dot de Summary: add syslog support to FPM Status: Assigned Type: Feature/Change Request Package: FPM related Operating System: Linux/*NIX PHP Version: 5.3SVN-2010-06-11 (SVN) Assigned To: fat New Comment: my mistakes. The v2 patch was buggy. Use v3 instead. Previous Comments: [2010-06-13 11:03:00] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v3.patch Revision: 1276419780 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v3.patch&revision=1276419780 [2010-06-13 10:41:26] f...@php.net You can try instead the new revision of the patch I've just attached. It adds sending slowlog to syslog. Set slowlog to syslog. Moreover you can set slowlog_syslog_level to same values as log_level. By default it's LOG_DEBUG. There is no way to change the ident and the facility for slowlog, it takes the same values as the globals ones (syslog_facility and syslog_event). There is no need to because the pool name is prepended to every slowlog message. [2010-06-13 10:36:27] f...@php.net The following patch has been added/updated: Patch Name: fpm-syslog.v2.patch Revision: 1276418186 URL: http://bugs.php.net/patch-display.php?bug=52052&patch=fpm-syslog.v2.patch&revision=1276418186 [2010-06-12 19:54:05] ef-lists at email dot de Great job! :-) I'll try it out and report feedback to you. [2010-06-12 18:49:35] f...@php.net The attached patch should activate syslog sypport to error_log only. You can try it on trunk. change error_log to "syslog" You can also set syslog_facility and syslog_ident to feet your needs. But default values should be OK. I'm working on the slowlog patch also but it's a bit more complicated. ++ Jerome 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=52052 -- Edit this bug report at http://bugs.php.net/bug.php?id=52052&edit=1
Bug #52067 [Asn->Csd]: chdir to a nonexisting directory when chrooting is buggy
Edit report at http://bugs.php.net/bug.php?id=52067&edit=1 ID: 52067 Updated by: f...@php.net Reported by: f...@php.net Summary: chdir to a nonexisting directory when chrooting is buggy -Status: Assigned +Status: Closed Type: Bug Package: FPM related Operating System: linux PHP Version: 5.3SVN-2010-06-12 (SVN) Assigned To: fat Previous Comments: [2010-06-13 12:30:37] f...@php.net Automatic comment from SVN on behalf of fat Revision: http://svn.php.net/viewvc/?view=revision&revision=300418 Log: Fix #52067, chroot and chdir path were not checked at startup. If configured with unexistant directories, FPM entered in an error loop. [2010-06-12 19:49:58] f...@php.net Description: when setting chroot and chdir to a non existing directory into the chroot. FPM loops creating children which are dying because they can't chdir. Jun 12 19:46:10.884803 [NOTICE] [pool www] child 27114 started Jun 12 19:46:10.884930 [WARNING] [pool www] child 27114 exited with code 255 after 0.000149 seconds from start Jun 12 19:46:10.885001 [WARNING] [pool www] child 27114 said into stderr: "Jun 12 19:46:10.884025 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.885072 [WARNING] [pool www] child 27114 said into stderr: "Jun 12 19:46:10.884153 [ERROR] [pool www] child failed to initialize", pipe is closed Jun 12 19:46:10.886642 [NOTICE] [pool www] child 27115 started Jun 12 19:46:10.886768 [WARNING] [pool www] child 27115 exited with code 255 after 0.000149 seconds from start Jun 12 19:46:10.886842 [WARNING] [pool www] child 27115 said into stderr: "Jun 12 19:46:10.885852 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.886914 [WARNING] [pool www] child 27115 said into stderr: "Jun 12 19:46:10.885982 [ERROR] [pool www] child failed to initialize", pipe is closed Jun 12 19:46:10.888469 [NOTICE] [pool www] child 27116 started Jun 12 19:46:10.888596 [WARNING] [pool www] child 27116 exited with code 255 after 0.000150 seconds from start Jun 12 19:46:10.888671 [WARNING] [pool www] child 27116 said into stderr: "Jun 12 19:46:10.887691 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.888744 [WARNING] [pool www] child 27116 said into stderr: "Jun 12 19:46:10.887820 [ERROR] [pool www] child failed to initialize", pipe is closed Jun 12 19:46:10.890295 [NOTICE] [pool www] child 27117 started Jun 12 19:46:10.890422 [WARNING] [pool www] child 27117 exited with code 255 after 0.000150 seconds from start Jun 12 19:46:10.890491 [WARNING] [pool www] child 27117 said into stderr: "Jun 12 19:46:10.889524 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.890563 [WARNING] [pool www] child 27117 said into stderr: "Jun 12 19:46:10.889651 [ERROR] [pool www] child failed to initialize", pipe is closed Jun 12 19:46:10.893124 [NOTICE] [pool www] child 27119 started Jun 12 19:46:10.893256 [WARNING] [pool www] child 27119 exited with code 255 after 0.000155 seconds from start Jun 12 19:46:10.893329 [WARNING] [pool www] child 27119 said into stderr: "Jun 12 19:46:10.892335 [ERROR] [pool www] chdir(/usr/local/nginx/html) failed: No such file or directory (2)" Jun 12 19:46:10.893401 [WARNING] [pool www] child 27119 said into stderr: "Jun 12 19:46:10.892467 [ERROR] [pool www] child failed to initialize", pipe is closed Test script: --- chroot=/usr/local/nginx/html chdir=/usr/local/nginx/html -- Edit this bug report at http://bugs.php.net/bug.php?id=52067&edit=1
Bug #52050 [Asn->Fbk]: PHP-FPM Dies after self-initiating reload
Edit report at http://bugs.php.net/bug.php?id=52050&edit=1 ID: 52050 Updated by: f...@php.net Reported by: marcus at adolfsson dot com Summary: PHP-FPM Dies after self-initiating reload -Status: Assigned +Status: Feedback Type: Bug Package: FPM related Operating System: fc7 PHP Version: 5.3.2 Assigned To: fat New Comment: Can you also provide the libevent version and the OS you're using. Thanks Previous Comments: [2010-06-11 16:27:49] marcus at adolfsson dot com ldd /usr/sbin/php-fpm libcrypt.so.1 => /lib64/libcrypt.so.1 (0x003a8300) libaspell.so.15 => /usr/lib64/libaspell.so.15 (0x003a8600) libpspell.so.15 => /usr/lib64/libpspell.so.15 (0x003a8640) librt.so.1 => /lib64/librt.so.1 (0x003a8180) libmysqlclient.so.15 => /usr/lib64/mysql/libmysqlclient.so.15 (0x0036a360) libmcrypt.so.4 => /usr/lib64/libmcrypt.so.4 (0x00357ba0) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0036a320) libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x0036a3e0) libz.so.1 => /usr/lib64/libz.so.1 (0x0035af40) libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x003a8700) libcurl.so.3 => /usr/lib64/libcurl.so.3 (0x0035af80) libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x003a8540) libpcre.so.0 => /lib64/libpcre.so.0 (0x0035b040) libm.so.6 => /lib64/libm.so.6 (0x003a80c0) libdl.so.2 => /lib64/libdl.so.2 (0x003a8080) libevent-1.4.so.1 => /usr/local/lib/libevent-1.4.so.1 (0x2aac3000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x0036a2e0) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x003a8440) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x003a8340) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x003a83c0) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x003a8280) libssl.so.6 => /lib64/libssl.so.6 (0x0035afc0) libcrypto.so.6 => /lib64/libcrypto.so.6 (0x0035b080) libresolv.so.2 => /lib64/libresolv.so.2 (0x003a82c0) libidn.so.11 => /usr/lib64/libidn.so.11 (0x003a8200) libc.so.6 => /lib64/libc.so.6 (0x003a8040) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x003a8400) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x003a84c0) libpthread.so.0 => /lib64/libpthread.so.0 (0x003a8100) /lib64/ld-linux-x86-64.so.2 (0x003a8000) libnsl.so.1 => /lib64/libnsl.so.1 (0x003a8240) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x003a8480) [2010-06-11 16:10:16] tony2...@php.net Please also show the output of `ldd /path/to/php-fpm`. Thanks. [2010-06-11 15:36:27] marcus at adolfsson dot com This is my conf file: ; ; FPM Configuration ; ; ;include=/etc/fpm.d/*.conf ;; ; Global Options ; ;; [global] pid = /usr/logs/php-fpm.pid error_log = /usr/logs/php-fpm.log ; Log level ; Possible Values: alert, error, warning, notice, debug log_level = notice ; If this number of child processes exit with SIGSEGV or SIGBUS within the time ; interval set by emergency_restart_interval then FPM will restart. A value ; of '0' means 'Off'. ; Default Value: 0 emergency_restart_threshold = 10 ; Interval of time used by emergency_restart_interval to determine when ; a graceful restart will be initiated. This can be useful to work around ; accidental corruptions in an accelerator's shared memory. ; Available Units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 emergency_restart_interval = 1m ; Time limit for child processes to wait for a reaction on signals from master. ; Available units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 process_control_timeout = 5s ; Send FPM to background. Set to 'no' to keep FPM in foreground for debugging. ; Default Value: yes daemonize = yes ; Pool Definitions ; ; Multiple pools of child processes may be started with different listening ; ports and different management options. The name of the pool will be ; used in logs and stats. There is no limitation on the number of pools which ; FPM can handle. Your system will tell you anyway :) ; Start a new pool named 'www'. [www] ; The address on which to accept FastCGI requests. ; Valid syntaxes are: ;
Bug #33957 [Com]: gmdate('W')/date('W') sometimes returns wrong week number.
Edit report at http://bugs.php.net/bug.php?id=33957&edit=1 ID: 33957 Comment by: cgullz at gmail dot com Reported by: paul at stunning-stuff dot com Summary: gmdate('W')/date('W') sometimes returns wrong week number. Status: Closed Type: Bug Package: Date/time related Operating System: * PHP Version: 5CVS-2005-08-02 Assigned To: derick New Comment: Hi, I have the same problem using date('W') to show week number of 13/June/2010 which should be 25, but it displays 23. I use php 5.2.6 through WAMP2. This is the first time I hear about snapshot so not sure what am I suppose to do to fix this problem. Can someone please explain to me what should I do? Thank you, Sigal Previous Comments: [2010-05-19 20:56:04] paul at stunning-stuff dot com Hi Warwick, The 1st week of a year does not necessarily start on the first of January under the rules of ISO8601. I checked your examples and they seemed fine. Please read up on ISO8601. -Paul [2010-05-19 04:06:11] wps at wwe dot com date('W', $timestamp) fails to return "01" for some January 1st years on PHP version 5.3.2 and 5.2.8 on CentOS and Windows. $year = 1970; $month = 1; $day = 1; while ($year <= 2028) { $timestamp = mktime(12, 0, 0, $month, $day, $year); print $year . " :: " . date('W', $timestamp). " :: " . date('D', $timestamp) . "\n"; $year++; } Expect 01 for every year but instead get 1970 :: 01 :: Thu 1971 :: 53 :: Fri 1972 :: 52 :: Sat 1973 :: 01 :: Mon 1974 :: 01 :: Tue 1975 :: 01 :: Wed 1976 :: 01 :: Thu 1977 :: 53 :: Sat 1978 :: 52 :: Sun ... 2020 :: 01 :: Wed 2021 :: 53 :: Fri 2022 :: 52 :: Sat 2023 :: 52 :: Sun 2024 :: 01 :: Mon 2025 :: 01 :: Wed 2026 :: 01 :: Thu 2027 :: 53 :: Fri 2028 :: 52 :: Sat 1st falling on Friday returns 53 1st falling on Saturday/Sunday return 52 Checked dates using http://www.tuxgraphics.org/toolbox/cal_year.html Warwick Shaw [2005-08-31 16:31:52] der...@php.net This bug has been fixed in CVS. 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. [2005-08-02 16:45:08] paul at stunning-stuff dot com Thanks for your quick reply and thanks for doing such a great job on PHP. You dev's really make this the best open source language today. I hope you are able to solve this problem (I'm sure you will). One more note though: This problem should reoccur every 28 years before and after 1992. This might help you in your testing. Thanks, Paul van der Maas --- www.stunning-stuff.com [2005-08-02 16:22:09] der...@php.net Indeed a bug, will have a look at it - thanks for the reproducable case. 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=33957 -- Edit this bug report at http://bugs.php.net/bug.php?id=33957&edit=1
[PHP-BUG] Bug #52075 [NEW]: php -b 127.0.0.1 vs php -y php-fpm.conf -x
From: Operating system: ubuntu 9.04 PHP version: 5.2.13 Package: CGI related Bug Type: Bug Bug description:php -b 127.0.0.1 vs php -y php-fpm.conf -x Description: As starting php-cgi in 2 ways, the 2 results were different. 1./path/to/php-cgi -b 127.0.0.1:9000 2./path/to/php-cgi -y /path/to/php-fpm.conf -x The first one was correct. The second, which said: 'No input file specified'. As i tracked down the c code, i found out the reason finally, but dunno why still. /php/to/phpsrc/TSRM/tsrm_virtual_cwd.c CWD_API int virutal_file_ex(cwd_state *state,.) around line 1339 the exact code block: #if !defined(TSRM_WIN32) && !defined(NETWARE) .. if (use_realpath == CWD_REALPATH) { return 1; } goto no_realpath; It's the above function that keeps the problem presenting.. As i tested, while started as the 1st way, this function return 0, and the tsrm_realpath returns NULL, also tsrm_realpath was called from init_request_info. I think u must be familiarer with the code. And the 2cd way was all right. Here is my nginx(0.6.39) conf block: server { listen 80; server_name pk.local.com; index index.php; root /home/zyk/pk_local; location / { root /home/zyk/pk_local; fastcgi_pass 127.0.0.1:9000; # fastcgi_pass unix:/usr/local/app/php/logs/php.sock; fastcgi_index index.php; fastcgi_intercept_errors on; include fcgi.conf; include fastcgi_params.default; } } } Dir /home/zyk/pk_local is RW for the php daemon userid. Here is my php configure option: configure --enable-fastcgi --enable-fpm --enable-mbstring --prefix=/usr/local/app/php Here is my php-fpm.conf All relative paths in this config are relative to php's install prefix Pid file /usr/local/app/php/logs/php-fpm.pid Error log file /usr/local/app/php/logs/php-fpm.log Log level notice When this amount of php processes exited with SIGSEGV or SIGBUS ... 10 ... in a less than this interval of time, a graceful restart will be initiated. Useful to work around accidental curruptions in accelerator's shared memory. 1m Time limit on waiting child's reaction on signals from master 5s Set to 'no' to debug fpm no Name of pool. Used in logs and stats. default Address to accept fastcgi requests on. Valid syntax is 'ip.ad.re.ss:port' or just 'port' or '/path/to/unix/socket' 127.0.0.1:9000 Set listen(2) backlog -1 Set permissions for unix socket, if one used. In Linux read/write permissions must be set in order to allow connections from web server. Many BSD-derrived systems allow connections regardless of permissions. nobody nobody 0666 Additional php.ini defines, specific to this pool of workers. nginx Unix user of processes nobody Unix group of processes nobody Process manager settings Sets style of controling worker process count. Valid values are 'static' and 'apache-like' static Sets the limit on the number of simultaneous requests that will be served. Equivalent to Apache MaxClients directive. Equivalent to PHP_FCGI_CHILDREN environment in original php.fcgi Used with any pm_style. 5 Settings group for 'apache-like' pm style
Bug #52075 [Opn]: php -b 127.0.0.1 vs php -y php-fpm.conf -x
Edit report at http://bugs.php.net/bug.php?id=52075&edit=1 ID: 52075 User updated by: luk-4u at hotmail dot com Reported by: luk-4u at hotmail dot com Summary: php -b 127.0.0.1 vs php -y php-fpm.conf -x Status: Open Type: Bug Package: CGI related Operating System: ubuntu 9.04 PHP Version: 5.2.13 New Comment: "As i tested, while started as the 1st way, this function return 0, and the tsrm_realpath returns NULL' This sentence was written wrong, correct is : the 1st way returns 0; the second returns 1; Previous Comments: [2010-06-13 13:38:07] luk-4u at hotmail dot com Description: As starting php-cgi in 2 ways, the 2 results were different. 1./path/to/php-cgi -b 127.0.0.1:9000 2./path/to/php-cgi -y /path/to/php-fpm.conf -x The first one was correct. The second, which said: 'No input file specified'. As i tracked down the c code, i found out the reason finally, but dunno why still. /php/to/phpsrc/TSRM/tsrm_virtual_cwd.c CWD_API int virutal_file_ex(cwd_state *state,.) around line 1339 the exact code block: #if !defined(TSRM_WIN32) && !defined(NETWARE) .. if (use_realpath == CWD_REALPATH) { return 1; } goto no_realpath; It's the above function that keeps the problem presenting.. As i tested, while started as the 1st way, this function return 0, and the tsrm_realpath returns NULL, also tsrm_realpath was called from init_request_info. I think u must be familiarer with the code. And the 2cd way was all right. Here is my nginx(0.6.39) conf block: server { listen 80; server_name pk.local.com; index index.php; root /home/zyk/pk_local; location / { root /home/zyk/pk_local; fastcgi_pass 127.0.0.1:9000; # fastcgi_pass unix:/usr/local/app/php/logs/php.sock; fastcgi_index index.php; fastcgi_intercept_errors on; include fcgi.conf; include fastcgi_params.default; } } } Dir /home/zyk/pk_local is RW for the php daemon userid. Here is my php configure option: configure --enable-fastcgi --enable-fpm --enable-mbstring --prefix=/usr/local/app/php Here is my php-fpm.conf All relative paths in this config are relative to php's install prefix Pid file /usr/local/app/php/logs/php-fpm.pid Error log file /usr/local/app/php/logs/php-fpm.log Log level notice When this amount of php processes exited with SIGSEGV or SIGBUS ... 10 ... in a less than this interval of time, a graceful restart will be initiated. Useful to work around accidental curruptions in accelerator's shared memory. 1m Time limit on waiting child's reaction on signals from master 5s Set to 'no' to debug fpm no Name of pool. Used in logs and stats. default Address to accept fastcgi requests on. Valid syntax is 'ip.ad.re.ss:port' or just 'port' or '/path/to/unix/socket' 127.0.0.1:9000 Set listen(2) backlog -1 Set permissions for unix socket, if one used. In Linux read/write permissions must be set in order to allow connections from web server. Many BSD-derrived systems allow connections regardless of permissions. nobody nobody 0666 Additional php.ini defines, specific to this pool of workers. nginx Unix user of processes nobody Unix group of processes nobody Process manager settings Sets style of controling worker process count. Valid values are 'static'
Req #30157 [Asn->Opn]: ftell() function does not use stream_tell()
Edit report at http://bugs.php.net/bug.php?id=30157&edit=1 ID: 30157 Updated by: fel...@php.net Reported by: tendencies at free dot fr Summary: ftell() function does not use stream_tell() -Status: Assigned +Status: Open Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: * PHP Version: 5CVS-2004-09-19 (dev) -Assigned To: pollita +Assigned To: Previous Comments: [2009-02-24 17:18:11] doctorrock83 at gmail dot com Confirmed at the date of this message, the bug is still present in PHP 5.2.8, and PHP 5.3 branch. [2006-07-26 16:43:31] w...@php.net (PS: I got here via Bug #37096) [2006-07-26 16:42:25] w...@php.net I truly hope that this patch didn't get committed; it's not part of the streams design and is fundamentally redundant. I don't have time to make any further commentary than that; further analysis of the user-stream case mentioned in this bug report is required, but it certainly does not require making this kind of change to the core. [2005-06-16 17:22:20] tony2...@php.net >Why did you need to add tell() function to the streams internals? Because the original problem (stream_tell() is not used) looks like a bug to me. [2005-06-16 17:17:11] w...@php.net This tell patch (http://tony2001.phpclub.net/dev/tmp/userstreamop_tell.diff) is "wrong"; the position should be set implicitly when the stream is opened, and be updated by the streams layer when it knows that it is changed (as happens when you seek). If you need to determine the current position, you simply need to seek with a zero offset from the current position. Why did you need to add tell() function to the streams internals? 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=30157 -- Edit this bug report at http://bugs.php.net/bug.php?id=30157&edit=1
Bug #37096 [NoF->Opn]: referencing bug with return value for stream_seek
Edit report at http://bugs.php.net/bug.php?id=37096&edit=1 ID: 37096 Updated by: fel...@php.net Reported by: w...@php.net Summary: referencing bug with return value for stream_seek -Status: No Feedback +Status: Open Type: Bug Package: Streams related Operating System: * PHP Version: 5CVS-2006-04-16 (CVS) Previous Comments: [2006-09-16 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2006-09-08 21:04:46] tony2...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2006-07-26 09:21:28] tendencies at free dot fr See this bug : http://bugs.php.net/bug.php?id=30157 [2006-04-16 02:29:02] w...@php.net Description: When using user-space streams via stream_wrapper_register(), if you return the value of a property of the object from stream_seek(), it gets mangled. Sounds like a problem with the way that the retval from call_user_function_ex() is disposed. The workaround is to create a temporary value using a trick like this: function stream_seek($offset, $whence) { ... $retval = $this->pos + 0; return $retval; } presumably the rest of the user wrapper code has the same flaw. Reproduce code: --- Abbreviated example; my actual test case is too large. Valgrind does not indicate any memory errors, so the problem is likely logical rather than sloppy memory handling. class MyStream { var $this->pos = 0; function stream_tell() { return $this->pos; } function stream_seek($offset, $whence) { return $this->pos; } } Actual result: -- Problem manifested for me by converting $this->pos to bool(true), which was then interpreted by the user space wrapper as an invalid return value from stream_tell(), which simply returns $this->pos. -- Edit this bug report at http://bugs.php.net/bug.php?id=37096&edit=1
Req #29337 [Asn->Fbk]: dns_get_record() unavailable on *BSD
Edit report at http://bugs.php.net/bug.php?id=29337&edit=1 ID: 29337 Updated by: fel...@php.net Reported by: php at to-the-max dot net Summary: dns_get_record() unavailable on *BSD -Status: Assigned +Status: Feedback Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: FreeBSD PHP Version: 5.0.0 -Assigned To: pollita +Assigned To: New Comment: Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2008-04-18 12:00:06] manuel at mausz dot at I ran into the same problem yesterday. So I decided to modify the source to fallback to the deprecated ns_mkquery/ns_send if the newer functions aren't available. Patch for 5.3 and HEAD: http://manuel.mausz.at/coding/patches/php/5.3.0/php-5.3.0-dns_get_record.patch Tested on FreeBSD but should work on other BSDs and probably on OS X too. [2004-08-02 11:08:39] der...@php.net Assigning to the person who last touched this. [2004-07-22 19:30:31] php at to-the-max dot net Description: dns_get_record() is not available when PHP is compiled under BSD. /ext/standard/dns.c uses the res_nmkquery() and res_nsearch() functions present in newer versions of BIND's libresolv. However those functions are not present on *BSD (and probably other) systems. Please consider using the older res_mkquery(), res_search() fuctions, to maximize compatibility. -- Edit this bug report at http://bugs.php.net/bug.php?id=29337&edit=1
Req #46934 [Asn->Opn]: Unable to untighten open_basedir restriction
Edit report at http://bugs.php.net/bug.php?id=46934&edit=1 ID: 46934 Updated by: fel...@php.net Reported by: kristof dot coomans at telenet dot be Summary: Unable to untighten open_basedir restriction -Status: Assigned +Status: Open Type: Feature/Change Request -Package: Feature/Change Request +Package: *General Issues Operating System: * PHP Version: 5.3CVS-2009-04-10 -Assigned To: pollita +Assigned To: Previous Comments: [2009-04-12 16:17:59] crrodriguez at opensuse dot org I think that allowing un-tightening is not a very good idea... Expected result: The last call should be allowed, and a file test.txt should have been created in the same directory as the script. Actual result: -- Warning: file_put_contents(): open_basedir restriction in effect. File(C:\sites\ trunk\test.txt) is not within the allowed path(s): (░δç☺♀) in ... Warning: file_put_contents(C:\sites\trunk\test.txt): failed to open stream: Operation not permitted in ... -- Edit this bug report at http://bugs.php.net/bug.php?id=46934&edit=1
Bug #29521 [Asn]: compress.bzip2 wrapper
Edit report at http://bugs.php.net/bug.php?id=29521&edit=1 ID: 29521 Updated by: fel...@php.net Reported by: nlop...@php.net Summary: compress.bzip2 wrapper Status: Assigned Type: Bug Package: Bzip2 Related Operating System: win32 only PHP Version: 5.2CVS-2007-01-10 -Assigned To: nlopess +Assigned To: iliaa New Comment: Ilia, was this bug fixed with the fix for bug #42117? Previous Comments: [2008-11-30 22:46:19] paj...@php.net Assign to the reporter, he has a cvs account too now >) [2007-08-10 11:41:23] nlop...@php.net I don't think this has anything to do with that bug. I checked both filter and wrapper sources and they are too different. [2007-08-05 18:17:43] phofstetter at sensational dot ch Hi, being the reporter of bug #42117, I think this really is the same thing and I actually reported a duplicate (terribly sorry for this), though "my" bug is about the bzip2.compress *filter* where this is about the stream *wrapper*, but the bug really feels like being the same problem. Also, the warning is consistent to what I have seen in my case and to what the incorrect checking of that error code (see #42117) would cause. I'm really having my hopes up that this is going to be fixed now :-) Philip [2007-08-04 21:03:19] j...@php.net See bug #42117 which might be the same issue. Nuno, can you try the patch? [2007-01-12 22:10:27] nlop...@php.net yep, it still issue the same warning. 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=29521 -- Edit this bug report at http://bugs.php.net/bug.php?id=29521&edit=1
Bug #33997 [Asn->Fbk]: Returned: Bug #16069 - ICONV transliteration failure
Edit report at http://bugs.php.net/bug.php?id=33997&edit=1 ID: 33997 Updated by: fel...@php.net Reported by: RVaughn at pheedo dot com Summary: Returned: Bug #16069 - ICONV transliteration failure -Status: Assigned +Status: Feedback Type: Bug Package: ICONV related Operating System: * PHP Version: 5.*, 6CVS (2009-04-25) -Assigned To: derick +Assigned To: New Comment: Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2009-04-27 16:13:23] j...@php.net Still fails. [2005-08-08 00:10:15] sni...@php.net Assigning to Derick who's comment about my patch was "It's funny" and other comment about the iconv code "this is a mess" :) [2005-08-07 14:42:23] der...@php.net Please provide a location where we can download your failed test's .out and .exp file. [2005-08-04 23:34:18] RVaughn at pheedo dot com Do let me know if you want me to put the output somewhere on our site where it can be downloaded, the code itself is just the PHP-provided test: bug16069.phpt. Thanks! Cheers! [2005-08-04 23:32:57] RVaughn at pheedo dot com OK, here's the diff output from the test results, please note that the output is the same until part way through, and the ultimate length is different: === /usr/local/src/Tars/php-4.4.0/ext/iconv/tests/bug16069.phpt === EXPECTED OUTPUT ¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë) ACTUAL OUTPUT ¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë) FAILED 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=33997 -- Edit this bug report at http://bugs.php.net/bug.php?id=33997&edit=1
Bug #41758 [Asn->Wfx]: SORT_LOCALE_STRING broken for sort() in PHP6
Edit report at http://bugs.php.net/bug.php?id=41758&edit=1 ID: 41758 Updated by: fel...@php.net Reported by: hedvall at gmail dot com Summary: SORT_LOCALE_STRING broken for sort() in PHP6 -Status: Assigned +Status: Wont fix Type: Bug Package: Arrays related Operating System: Win2k SP4 PHP Version: 6CVS-2007-06-21 (snap) Assigned To: andrei Previous Comments: [2007-06-21 10:19:30] hedvall at gmail dot com Description: According to the documentation for sort(), you must use i18n_loc_set_default() for sort() with SORT_LOCALE_STRING to work in PHP6. However, i18n_loc_set_default() is an undefined function. The documentation instead refers to locale_set_default(). When setting the locale to "sv_SE" (correct) the function returns false, but when setting it to "sv_PHP" (incorrect) the function returns true which is the wrong behavior. The example from locale_set_default() uses "pt_PT" which can be set, but when sorting the result turns out the wrong way. When using locale_get_default() it returns what was set with locale_set_default() even if that function turned it down by returning false. When later using sort() or asort() (or any other sort) with SORT_LOCALE_STRING the result is the same as a normal sort. Reproduce code: --- Expected result: Array ( [0] => caçada [1] => cacto [2] => caramelo ) Actual result: -- Array ( [0] => cacto [1] => caramelo [2] => caçada ) -- Edit this bug report at http://bugs.php.net/bug.php?id=41758&edit=1
Bug #41631 [Asn]: default_socket_timeout does not work with SSL
Edit report at http://bugs.php.net/bug.php?id=41631&edit=1 ID: 41631 Updated by: fel...@php.net Reported by: david at acz dot org Summary: default_socket_timeout does not work with SSL Status: Assigned Type: Bug Package: OpenSSL related Operating System: * -PHP Version: 5.2.11 +PHP Version: 5.2, 5.3 Assigned To: pajoye New Comment: Pierre, doesn't the attached patch fix this issue? Previous Comments: [2010-03-15 10:33:47] jason at kapoks dot co dot uk Had this issue over the weekend with 5.2.10. Essentially this means our entire service is vulnerable to Denial of Service. Linux localhost.localdomain 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 i686 i386 GNU/Linux CentOS release 5.3 (Final) PHP 5.2.10 (cli) (built: Jun 21 2009 11:10:43) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies [2010-01-18 19:16:42] wdierkes at 5dollarwhitebox dot org This is also reproducible on 5.2.12 as described. As mentioned previously, this has the potentially to have major effects (Denial of Servide) etc due to processes hanging and never timing out. # cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.4 (Tikanga) # php -v PHP 5.2.12 (cli) (built: Dec 17 2009 12:23:35) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies # uname -a Linux linux 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux [2009-10-16 20:14:25] arkadi dot shishlov at gmail dot com At least it would be helpful to set TCP keep-alive on socket so OS could timeout it eventually, otherwise there are connections stuck for days. [2009-09-24 19:30:14] srina...@php.net bug #48524 depends on this fix (http://bugs.php.net/bug.php?id=48524&edit=1) i wish , bug tracking system allowed to be able to close a bug as duplicate of another. then, we could close 48524 as dup of this (41631). this can also trigger the internal score for this bug to be increased (helping in set priority etc). [2009-09-18 10:10:02] marcin at php4u dot co dot uk Still can reproduce on Windows XP SP3, PHP 5.2.6 while connecting to https, script doesn't time out 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=41631 -- Edit this bug report at http://bugs.php.net/bug.php?id=41631&edit=1
Bug #43327 [Asn->Opn]: wrong return value from mail(), if sendmail_path is wrong
Edit report at http://bugs.php.net/bug.php?id=43327&edit=1 ID: 43327 Updated by: fel...@php.net Reported by: carsten_sttgt at gmx dot de Summary: wrong return value from mail(), if sendmail_path is wrong -Status: Assigned +Status: Open Type: Bug Package: Mail related Operating System: win32 only (?) PHP Version: 5.*, 6 (2009-08-07) -Assigned To: garretts +Assigned To: Previous Comments: [2009-08-20 10:39:59] j...@php.net Reopened, fix was reverted. [2009-08-20 09:03:20] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=287495 Log: - revert fix for #43327, it breaks system&co functions [2009-08-20 01:56:05] carsten_sttgt at gmx dot de Hi Garrett, > Can you retest with the latest 5.3 snapshot, and post feedback? I can do this. Just some remarks first: > This occurs because popen_ex executes the command using the comspec > ('cmd.exe'), which will always create a valid process--but intended > actual child process fails. That's correct. No error during creation of the process ("cmd.exe" / "GetLastError == 0"). But in this case, "cmd.exe" returns an exit code != 0, which is available with "GetExitCodeProcess()". So you know there's a problem. Regarding mail(): - mail() does not detect that "cmd.exe" can't start "sendmail.exe" - it also does not detect, if "cmd.exe" can start "sendmail.exe", but "sendmail.exe" is returning an exit code != 0 --> if "cmd.exe" can start a program, it's returning the exit code from that program, and so this is available with GetExitCodeProcess(). So there is the question, why does mail() does not test the return value of pclose() in a correct way on windows? At the moment it looks like: | #ifdef PHP_WIN32 | if (ret == -1) | { | MAIL_RET(0); | } else { |MAIL_RET(1); | } But I think it should be also something like?: | if (ret != 0) > I'm patching this so that it skips using cmd.exe--there is really > no reason this should be here, Some hints: - If you want start an executable with just the name and without the extension (like ".com, *.pl"), you must do this through "cmd.exe" (only for "*.exe" files you can use just the name). - In the MSDN you can read, that you have to use "cmd.exe" to start a batchfile with CreateProcess. Ok, for me that's working without "cmd.exe". But maybe this depends on the Windows version or compiler. Regards, Carsten [2009-08-19 18:56:08] garre...@php.net Carsten, Can you retest with the latest 5.3 snapshot, and post feedback? Thanks [2009-08-19 18:43:46] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=287480 Log: - fixed #43327, wrong return value from mail(), if sendmail_path is wrong 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=43327 -- Edit this bug report at http://bugs.php.net/bug.php?id=43327&edit=1
Bug #52075 [Opn->Csd]: php -b 127.0.0.1 vs php -y php-fpm.conf -x
Edit report at http://bugs.php.net/bug.php?id=52075&edit=1 ID: 52075 Updated by: f...@php.net Reported by: luk-4u at hotmail dot com Summary: php -b 127.0.0.1 vs php -y php-fpm.conf -x -Status: Open +Status: Closed Type: Bug Package: FPM related Operating System: ubuntu 9.04 PHP Version: 5.2.13 -Assigned To: +Assigned To: fat New Comment: FPM is not supported on 5.2.x and your revision is old as the conf file is formatted in XML (now it's INI). Please use 5.3.x from http://snaps.php.net/ If you're using the FPM patch from http://php-fpm.org to use FPM on 5.2.x, please ask on the FPM mailing list (http://groups.google.com/group/highload-php- en). ++ Jerome Previous Comments: [2010-06-13 13:41:48] luk-4u at hotmail dot com "As i tested, while started as the 1st way, this function return 0, and the tsrm_realpath returns NULL' This sentence was written wrong, correct is : the 1st way returns 0; the second returns 1; [2010-06-13 13:38:07] luk-4u at hotmail dot com Description: As starting php-cgi in 2 ways, the 2 results were different. 1./path/to/php-cgi -b 127.0.0.1:9000 2./path/to/php-cgi -y /path/to/php-fpm.conf -x The first one was correct. The second, which said: 'No input file specified'. As i tracked down the c code, i found out the reason finally, but dunno why still. /php/to/phpsrc/TSRM/tsrm_virtual_cwd.c CWD_API int virutal_file_ex(cwd_state *state,.) around line 1339 the exact code block: #if !defined(TSRM_WIN32) && !defined(NETWARE) .. if (use_realpath == CWD_REALPATH) { return 1; } goto no_realpath; It's the above function that keeps the problem presenting.. As i tested, while started as the 1st way, this function return 0, and the tsrm_realpath returns NULL, also tsrm_realpath was called from init_request_info. I think u must be familiarer with the code. And the 2cd way was all right. Here is my nginx(0.6.39) conf block: server { listen 80; server_name pk.local.com; index index.php; root /home/zyk/pk_local; location / { root /home/zyk/pk_local; fastcgi_pass 127.0.0.1:9000; # fastcgi_pass unix:/usr/local/app/php/logs/php.sock; fastcgi_index index.php; fastcgi_intercept_errors on; include fcgi.conf; include fastcgi_params.default; } } } Dir /home/zyk/pk_local is RW for the php daemon userid. Here is my php configure option: configure --enable-fastcgi --enable-fpm --enable-mbstring --prefix=/usr/local/app/php Here is my php-fpm.conf All relative paths in this config are relative to php's install prefix Pid file /usr/local/app/php/logs/php-fpm.pid Error log file /usr/local/app/php/logs/php-fpm.log Log level notice When this amount of php processes exited with SIGSEGV or SIGBUS ... 10 ... in a less than this interval of time, a graceful restart will be initiated. Useful to work around accidental curruptions in accelerator's shared memory. 1m Time limit on waiting child's reaction on signals from master 5s Set to 'no' to debug fpm no Name of pool. Used in logs and stats. default Address to accept fastcgi requests on. Valid syntax is 'ip.ad.re.ss:port' or just 'port' or '/path/to/unix/socket' 127.0.0.1:9000 Set listen(2) backlog -1 Set permissions for unix socket, if one used. In Linux read/write permissions must be set in order to allow connections from web server. Many BSD-derrived systems allow connections regardless of permissions. nobody nobody 0666 Additional php.ini defines, specific to this pool of workers. nginx
Req #51973 [Com]: a way to restart single pools, enable/disable modules per pool
Edit report at http://bugs.php.net/bug.php?id=51973&edit=1 ID: 51973 Comment by: f...@php.net Reported by: slogster at gmail dot com Summary: a way to restart single pools, enable/disable modules per pool Status: Assigned Type:Feature/Change Request Package: FPM related PHP Version: 5.3SVN-2010-06-02 (SVN) Assigned To: fat New Comment: For enabeling extensions you can use the php_admin_value setting for each pool: php_admin_value[extension] = extension.so Previous Comments: [2010-06-02 13:01:49] slogster at gmail dot com Description: Hi, I would like to be able do enable/disable modules per pool and would also like to be able to restart single pool when I change its config. Thanks -- Edit this bug report at http://bugs.php.net/bug.php?id=51973&edit=1
Bug #45808 [Asn]: [PATCH] stream_socket_enable_crypto() blocks and eats CPU
Edit report at http://bugs.php.net/bug.php?id=45808&edit=1 ID: 45808 Updated by: fel...@php.net Reported by: six at aegis-corp dot org -Summary: stream_socket_enable_crypto() blocks and eats CPU +Summary: [PATCH] stream_socket_enable_crypto() blocks and eats CPU Status: Assigned Type: Bug Package: Streams related Operating System: Linux 2.6 PHP Version: 5.*, 6 Assigned To: pajoye New Comment: Pierre, what about this patch? Previous Comments: [2009-10-13 10:45:21] vincent at optilian dot com Actually I fixed some things in the patch, see below ... It makes more sense to test whether the socket is in blocking mode, even if a client ssl socket doesn't need multiple calls to stream_socket_enable_crypto() --- xp_ssl.c.orig 2009-10-12 19:34:31.0 +0200 +++ xp_ssl.c2009-10-13 12:30:24.0 +0200 @@ -299,8 +299,12 @@ SSL_METHOD *method; if (sslsock->ssl_handle) { - php_error_docref(NULL TSRMLS_CC, E_WARNING, "SSL/TLS already set-up for this stream"); - return -1; + if (sslsock->s.is_blocked) { + php_error_docref(NULL TSRMLS_CC, E_WARNING, "SSL/TLS already set-up for this stream"); + return -1; + } else { + return 0; + } } /* need to do slightly different things, based on client/server method, @@ -415,7 +419,7 @@ } if (n <= 0) { - retry = handle_ssl_error(stream, n, 1 TSRMLS_CC); + retry = handle_ssl_error(stream, n, sslsock->is_client || sslsock->s.is_blocked TSRMLS_CC); } else { break; } [2009-10-12 20:50:36] vincent at optilian dot com Here is a patch to fix this issue (diff against 5.3.0) As far as I have tested, everything works as expected with this patch applied. --- xp_ssl.c.orig 2009-10-12 19:34:31.0 +0200 +++ xp_ssl.c2009-10-12 20:39:19.0 +0200 @@ -299,8 +299,12 @@ SSL_METHOD *method; if (sslsock->ssl_handle) { - php_error_docref(NULL TSRMLS_CC, E_WARNING, "SSL/TLS already set-up for this stream"); - return -1; + if (sslsock->is_client) { + php_error_docref(NULL TSRMLS_CC, E_WARNING, "SSL/TLS already set-up for this stream"); + return -1; + } else { + return 0; + } } /* need to do slightly different things, based on client/server method, @@ -415,7 +419,7 @@ } if (n <= 0) { - retry = handle_ssl_error(stream, n, 1 TSRMLS_CC); + retry = handle_ssl_error(stream, n, sslsock->is_client TSRMLS_CC); } else { break; } [2009-08-18 16:15:00] garre...@php.net FYI: I can't repro this on Windows with the build off the snaps' box (VC9 x86 Non Thread Safe (2009-Aug-18 16:00:00)). It: blocks until connection using telnet[expected] doens't consume any CPU[expected] and returns 'bool(false)' [expected -- I assume the same as 'int(0)'] and exits[expected] G [2008-10-30 11:03:57] xl269 at cam dot ac dot uk just to confirm that this bug still exists in php5.3-200810292330 [2008-09-25 17:59:37] singularity_control at rcpt dot at This makes a serious security issue. It is a very effective DoS on all single process PHP servers with SSL and a slightly less bad DoS on multi-process PHP servers. 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=45808 -- Edit this bug report at http://bugs.php.net/bug.php?id=45808&edit=1
Bug #46834 [Asn->Wfx]: Range of mcrypt functions fail on PHP 6.0
Edit report at http://bugs.php.net/bug.php?id=46834&edit=1 ID: 46834 Updated by: fel...@php.net Reported by: a...@php.net Summary: Range of mcrypt functions fail on PHP 6.0 -Status: Assigned +Status: Wont fix Type: Bug Package: mcrypt related Operating System: * PHP Version: 6CVS-2008-12-11 (snap) Assigned To: derick Previous Comments: [2008-12-11 10:39:32] a...@php.net Description: A range of PHPTs fail on PHP 6 where they pass on PHP 5.2/5.3. In many cases it looks like the function returns different output from encryption/decryption calls. The following failing tests are all checked into PHP 6 and marked with an XFAIL section: mcrypt_cbc_3des_encrypt.phpt mcrypt_cbc_3des_decrypt.phpt mcrypt_cbc_variation4.phpt mcrypt_cbc_variation5.phpt mcrypt_rijndael128_128BitKey.phpt mcrypt_rijndael128_256BitKey.phpt mcrypt_decrypt_3des_cbc.phpt mcrypt_decrypt_variation5.phpt mcrypt_encrypt_3des_cbc.phpt mcrypt_encrypt_variation5.phpt mcrypt_ecb_variation4.phpt The problem may be common to all the failing tests and looks like something has changed with different length initialisation vectors. Reproduce code: --- (See the tests checked into CVS) Expected result: For example, the mcrypt_cbc_3des_decrypt.phpt test expects: --- testing different iv lengths iv length=4 Warning: mcrypt_cbc(): The IV parameter must be as long as the blocksize in %s on line %d unicode(32) "736563726574206d657373616765" iv length=8 unicode(32) "736563726574206d657373616765" iv length=9 Warning: mcrypt_cbc(): The IV parameter must be as long as the blocksize in %s on line %d unicode(32) "736563726574206d657373616765" Actual result: -- iv length=4 Warning: mcrypt_cbc(): The IV parameter must be as long as the blocksize in D:\Testing\php-6.0\mcrypt_cbc_3des_decrypt.php on line 52 unicode(32) "425750466574206d657373616765" iv length=8 unicode(32) "736563726574206d657373616765" iv length=9 Warning: mcrypt_cbc(): The IV parameter must be as long as the blocksize in D:\Testing\php-6.0\mcrypt_cbc_3des_decrypt.php on line 52 unicode(32) "4257504650421755657373616765" -- Edit this bug report at http://bugs.php.net/bug.php?id=46834&edit=1
Bug #46981 [Asn->Csd]: PDO get Data Bug for Firebird DBMS
Edit report at http://bugs.php.net/bug.php?id=46981&edit=1 ID: 46981 Updated by: fel...@php.net Reported by: flylink at 126 dot com Summary: PDO get Data Bug for Firebird DBMS -Status: Assigned +Status: Closed Type: Bug Package: PDO related Operating System: Windows PHP Version: 5.2.9 -Assigned To: abies +Assigned To: felipe New Comment: It was already fixed in 5.2.10. (see bug #47845) Thanks. Previous Comments: [2009-02-09 13:26:10] fel...@php.net I can reproduce it on 5.2.9-CVS. [2009-01-03 11:10:49] flylink at 126 dot com Maybe it is not clear from my last description, please read the following: In PHP script, when access Firbird database with PDO drive and get the data from a reslut set by executing SQL qury sentence when there is a result set, the first row data is null. [2009-01-01 01:59:15] ka...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2008-12-31 03:16:01] flylink at 126 dot com Description: I use PDO driver to access Firebird DBMS, find a bug,I couldn't get first row's data Reproduce code: --- http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> http://www.w3.org/1999/xhtml";> PDO for Firebird PDO BUG for Firebird:"; $sql='SELECT * from link'; $rs=$dbConn->query($sql); foreach ($rs as $row) { print "1==>".$row[1]." 2==>".$row['SITELINK'].""; } $dbConn=NULL; ?> Expected result: PDO BUG for Firebird: 1==>Firebird 2==>http://www.firebirdsql.org 1==>?Ìò±SDN 2==>http://www.csdn.net 1==>???í¼¾ 2==>http://firebird.dearinfo.com/ 1==>IBPhoenix 2==>http://www.ibphoenix.com 1==>??Ô½PHP 2==>http://www.phpe.net 1==>Fracle-Janus Soft 2==>http://www.janus-software.com 1==>FirebirdÖÎɧǸ 2==>http://www.firebird.net.cn 1==>?ãÊ?Í?Ð×Ѷ 2==>http://www.it136.net 1==>DelphiÔ°?Ø 2==>http://www.delphifans.com 1==>Delphi K.TopÓÕ?^ 2==>http://delphi.ktop.com.tw 1==>DotNetFirebird 2==>http://www.dotnetfirebird.org/ 1==>Firebird?Ù·?͸վ 2==>http://www.firebirdsql.org/ 1==>Î?IJ??Í 2==>http://blog.csdn.net/jianlei/ 1==>DelphiÒ¤?? 2==>http://www.51delphi.com 1==>Delphi?ÐÓ 2==>http://www.2ccc.com 1==>??͸ҳ 2==>http://www.destructor.de/firebird/index.htm 1==>???UÅ 2==>http://jianlei.ys168.com Actual result: -- PDO BUG for Firebird: 1==> 2==> 1==>?Ìò±SDN 2==>http://www.csdn.net 1==>???í¼¾ 2==>http://firebird.dearinfo.com/ 1==>IBPhoenix 2==>http://www.ibphoenix.com 1==>??Ô½PHP 2==>http://www.phpe.net 1==>Fracle-Janus Soft 2==>http://www.janus-software.com 1==>FirebirdÖÎɧǸ 2==>http://www.firebird.net.cn 1==>?ãÊ?Í?Ð×Ѷ 2==>http://www.it136.net 1==>DelphiÔ°?Ø 2==>http://www.delphifans.com 1==>Delphi K.TopÓÕ?^ 2==>http://delphi.ktop.com.tw 1==>DotNetFirebird 2==>http://www.dotnetfirebird.org/ 1==>Firebird?Ù·?͸վ 2==>http://www.firebirdsql.org/ 1==>Î?IJ??Í 2==>http://blog.csdn.net/jianlei/ 1==>DelphiÒ¤?? 2==>http://www.51delphi.com 1==>Delphi?ÐÓ 2==>http://www.2ccc.com 1==>??͸ҳ 2==>http://www.destructor.de/firebird/index.htm 1==>???UÅ 2==>http://jianlei.ys168.com -- Edit this bug report at http://bugs.php.net/bug.php?id=46981&edit=1
Bug #46990 [Asn->Wfx]: Passing UTF8 strings to filesystem functions produce wrong filenames
Edit report at http://bugs.php.net/bug.php?id=46990&edit=1 ID: 46990 Updated by: fel...@php.net Reported by: alex dot bazan at concatel dot com Summary: Passing UTF8 strings to filesystem functions produce wrong filenames -Status: Assigned +Status: Wont fix Type: Bug Package: Filesystem function related Operating System: win32 only - Windows XP PHP Version: 6* Assigned To: pajoye Previous Comments: [2009-01-09 11:24:18] paj...@php.net Can't be fixed in 5.2 neither in 5.3. It will work smoothly in 6.x (unicode support). [2009-01-09 10:54:13] alex dot bazan at concatel dot com For anyone stumbling upon this bug, i wrote a workaround building a wrapper for filesystem functions. This workaround will will not fix the issue completely but will work with latin compatible characters when using UTF8 as the string encoding. People using other characters (japanese, chinese, hebrew ...) will still have problems. CODE: /** * Wrapper for PHP filesystem functions */ class Fsw { /** * Returns the filename for use with filesystem functions */ static function setName ($file) { if (DIRECTORY_SEPARATOR=="\\") { $file=utf8_decode($file); } return $file; } /** * Encondes the filename returned by filesystem functions */ static function getName ($file) { if (DIRECTORY_SEPARATOR=="\\") { $file=utf8_encode($file); } return $file; } static function file_exists ($filename) { return file_exists(self::setName($filename)); } static function fopen ($filename,$mode) { return fopen(self::setName($filename),$mode); } static function opendir ($dirname) { return opendir(self::setName($dirname)); } static function readdir ($dir_handle) { $file=readdir($dir_handle); if ($file) { // check if file is found before converting it's // name or we will convert bool(false) to string $file=self::getName($file); } return $file; } // just create any other filesystem function you might use in your code here } [2009-01-03 13:25:07] j...@php.net [2009-01-02 08:06:39] alex dot bazan at concatel dot com The UTF string did not get saved correctly in the bug report. It was a japanese string. [2009-01-02 08:03:37] alex dot bazan at concatel dot com Description: Under Windows, when I use fpoen() or mkdir() with a UTF8 encoded string, the file or directory name is not converted to the filesystem encoding and thus the file or directory is created with a wrong file name. Reproduce code: --- Expected result: Directory 日本語 should be created Actual result: -- Directory æ¥æ¬èª is created -- Edit this bug report at http://bugs.php.net/bug.php?id=46990&edit=1
Bug #47164 [Asn->Wfx]: uncomfortable (binary)char() append to binary string
Edit report at http://bugs.php.net/bug.php?id=47164&edit=1 ID: 47164 Updated by: fel...@php.net Reported by: lunter at interia dot pl Summary: uncomfortable (binary)char() append to binary string -Status: Assigned +Status: Wont fix Type: Bug Package: Unicode Engine related Operating System: * PHP Version: 6CVS-2009-01-20 (snap) Assigned To: scottmac Previous Comments: [2009-01-21 16:24:57] johan...@php.net Scott said he'd look into this :-) [2009-01-21 12:31:14] lunter at interia dot pl johan...@php.net "(binary)chr($c) will give the wrong result" hmmm... try code above. b1.dat consists utf-8 data b2.dat consists binary chars 0 - 255 step 1, file length is correct - 256B & chars are correct... [2009-01-21 11:26:24] johan...@php.net $b = sprintf("%c%c%c", 255, 254, 253); should work, but having a simple function might still be helpful [2009-01-21 11:12:52] johan...@php.net Actually we need a function doing "binary chr" - chr() in PHP 6 takes a codepoint not the byte value, so (binary)chr($c) will give the wrong result. [2009-01-20 10:59:03] lunter at interia dot pl Description: uncomfortable (binary)char() append to a binary string Reproduce code: --- $b=(binary)''; $b.=chr(255); $b.=chr(254); $b.=chr(253); $b.=chr(252); $b.=chr(251); ... $b.=chr(0); Expected result: detect $b type as binary string and adding chr() in binary mode like this: $b=(binary)''; $b.=(binary)chr(255); $b.=(binary)chr(254); $b.=(binary)chr(253); $b.=(binary)chr(252); $b.=(binary)chr(251); ... $b.=(binary)chr(0); Actual result: -- adding chr() in unicode -- Edit this bug report at http://bugs.php.net/bug.php?id=47164&edit=1
Bug #48240 [Asn->Csd]: DBA Segmentation fault dba_nextkey
Edit report at http://bugs.php.net/bug.php?id=48240&edit=1 ID: 48240 Updated by: fel...@php.net Reported by: VJTD3 at VJTD3 dot com Summary: DBA Segmentation fault dba_nextkey -Status: Assigned +Status: Closed Type: Bug Package: DBM/DBA related Operating System: linux redhat fedora 10 PHP Version: 5.2.9 Assigned To: felipe New Comment: The crash has been fixed, to change the behavior (when wasn't crashing) lead to BC. Previous Comments: [2009-05-19 05:03:00] VJTD3 at VJTD3 dot com i didn't see a reply, changed it to open in case that's needed for devs. [2009-05-13 07:16:08] VJTD3 at VJTD3 dot com can this be changed to return the first result if there is one and false if there are none? db_firstkey is a rewind, db_nextkey is a iterator. starting from the beginning makes sense. [2009-05-13 02:17:19] fel...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Fixed in 5.2, 5.3 and HEAD. FALSE is returned now. [2009-05-12 14:31:58] VJTD3 at VJTD3 dot com [New Thread 0xb7ff56c0 (LWP 10754)] Program received signal SIGSEGV, Segmentation fault. 0x080d0c66 in dba_nextkey_db4 (info=0x84d75f0, newlen=0xbfffb360) at php-5.2.9/ext/dba/dba_db4.c:222 222 if (dba->cursor->c_get(dba->cursor, &gkey, &gval, DB_NEXT) == 0) { (gdb) bt #0 0x080d0c66 in dba_nextkey_db4 (info=0x84d75f0, newlen=0xbfffb360) at php-5.2.9/ext/dba/dba_db4.c:222 #1 0x080cf3cc in zif_dba_nextkey (ht=1, return_value=0x84d6e78, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at php-5.2.9/ext/dba/dba.c:1101 #2 0x08304280 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffb548) at php-5.2.9/Zend/zend_vm_execute.h:200 #3 0x08309bba in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbfffb548) at php-5.2.9/Zend/zend_vm_execute.h:1729 #4 0x08303dfd in execute (op_array=0x84d7538) at php-5.2.9/Zend/zend_vm_execute.h:92 #5 0x082df04e in zend_execute_scripts (type=8, retval=0x0, file_count=3) at php-5.2.9/Zend/zend.c:1134 #6 0x0828dd81 in php_execute_script (primary_file=0xbfffd8c4) at php-5.2.9/main/main.c:2023 #7 0x0835a851 in main (argc=2, argv=0xbfffda04) at php-5.2.9/sapi/cli/php_cli.c:1133 (gdb) frame 0 #0 0x080d0c66 in dba_nextkey_db4 (info=0x84d75f0, newlen=0xbfffb360) at php-5.2.9/ext/dba/dba_db4.c:222 222 if (dba->cursor->c_get(dba->cursor, &gkey, &gval, DB_NEXT) == 0) { (gdb) frame 1 #1 0x080cf3cc in zif_dba_nextkey (ht=1, return_value=0x84d6e78, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at php-5.2.9/ext/dba/dba.c:1101 1101nkey = info->hnd->nextkey(info, &len TSRMLS_CC); (gdb) frame 2 #2 0x08304280 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfffb548) at php-5.2.9/Zend/zend_vm_execute.h:200 200 ((zend_internal_function *) EX(function_state).f unction)->handler(opline->extended_value, EX_T(opline->result.u.var).var.ptr, EX (function_state).function->common.return_reference?&EX_T(opline->result.u.var).v ar.ptr:NULL, EX(object), return_value_used TSRMLS_CC); (gdb) frame 3 #3 0x08309bba in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbfffb548) at php-5.2.9/Zend/zend_vm_execute.h:1729 1729return zend_do_fcall_common_helper_SPEC(ZEND_OPCODE_HANDLER_ARGS _PASSTHRU); (gdb) frame 4 #4 0x08303dfd in execute (op_array=0x84d7538) at php-5.2.9/Zend/zend_vm_execute.h:92 92 if (EX(opline)->handler(&execute_data TSRMLS_CC) > 0) { (gdb) frame 5 #5 0x082df04e in zend_execute_scripts (type=8, retval=0x0, file_count=3) at php-5.2.9/Zend/zend.c:1134 1134zend_execute(EG(active_op_array) TSRMLS_CC); (gdb) frame 6 #6 0x0828dd81 in php_execute_script (primary_file=0xbfffd8c4) at php-5.2.9/main/main.c:2023 2023retval = (zend_execute_scripts(ZEND_REQUIRE TSRMLS_CC, N
Bug #18556 [Com]: Setting locale to 'tr_TR' lowercases class names
Edit report at http://bugs.php.net/bug.php?id=18556&edit=1 ID: 18556 Comment by: ceremcem at cshus dot org Reported by: spud at nothingness dot org Summary: Setting locale to 'tr_TR' lowercases class names Status: Assigned Type: Bug Package: Scripting Engine problem Operating System: Linux (RedHat 7.2) PHP Version: 5CVS, 4CVS (2005-10-04) Assigned To: dmitry New Comment: This bug still exists in PHP version 5.3.2. Previous Comments: [2010-02-02 21:31:15] housecafe at freenet dot de Dear php-team, I´ve seen that 5.2.13RC1 is in progress. Could you fix this bug in this version, please ? Because I need turkish locale. Thanks in advance. [2010-01-22 09:00:27] paj...@php.net Dmitry, can you look at it please? It is still reproduceable with 5.2 and 5.3. [2009-11-13 16:58:15] joesiegrist at gmail dot com It is unbelievable that this bug persists into 2009. It is time to fix it. [2009-08-04 11:23:15] cankoy at ymail dot com Setting LC_CTYPE to something other than tr_TR solves nothing, it's not even a workaround, you just get a bastardized locale in which regex patterns do not match Turkish char.s and XXlower/XXupper functions become nothing but a joke. This bug has been around for ages, so it's not fixable? OK, don't fix it, but at least provide a means to turn off(*) the horrible PHP design decision "case-insensitive function lookup", so that we have an option to avoid all this mess. (*)like, a Php.ini directive [2009-07-30 17:21:41] onur dot oguzel at gmail dot com i guess nobody looks at this bug, setlocale(LC_ALL, 'tr_TR'); setlocale(LC_CTYPE, 'en_US'); sure solves this but it is still a 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=18556 -- Edit this bug report at http://bugs.php.net/bug.php?id=18556&edit=1
Bug #49764 [Asn->Fbk]: number_format() fails (randomly?)
Edit report at http://bugs.php.net/bug.php?id=49764&edit=1 ID: 49764 Updated by: fel...@php.net Reported by: tec at baufi24 dot de Summary: number_format() fails (randomly?) -Status: Assigned +Status: Feedback Type: Bug Package: Math related Operating System: Windows Server 2003 RC2 PHP Version: 5.2.11 Assigned To: pajoye New Comment: Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2010-05-13 21:26:19] derek dot ethier at humber dot ca I'm not sure if this will help at all, but outside of confirming this issue with number_format, it now appears as though converting a string to float causing a very similar problem. It seems to happen so randomly, but the only consistent element is that the numbers all have 9 in them. There is an existing bug opened for float that was closed as bogus: http://bugs.php.net/bug.php?id=47716 [2010-04-16 11:15:26] paj...@php.net I will ask our test team to try to reproduce it. [2010-04-15 20:24:54] derek dot ethier at humber dot ca I've been experiencing a similar problem on 5.2.12 and 5.2.13 on a Windows Server 2003 environment (not R2). I haven't been able to nail down any sort of specifics as it happens so randomly. The only consistent element seems to centre around odd numbers (specifically with 9) format incorrectly in a similar manner to the one originally described (with a colon in the middle). I'm not sure if this helps at all, but I thought I'd add a comment anyway. [2009-12-21 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". [2009-12-13 18:13:29] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ 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=49764 -- Edit this bug report at http://bugs.php.net/bug.php?id=49764&edit=1
Bug #49764 [Fbk->Asn]: number_format() fails (randomly?)
Edit report at http://bugs.php.net/bug.php?id=49764&edit=1 ID: 49764 Updated by: paj...@php.net Reported by: tec at baufi24 dot de Summary: number_format() fails (randomly?) -Status: Feedback +Status: Assigned Type: Bug Package: Math related Operating System: Windows Server 2003 RC2 PHP Version: 5.2.11 Assigned To: pajoye New Comment: Nothing changed here. Previous Comments: [2010-06-13 19:26:12] fel...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2010-05-13 21:26:19] derek dot ethier at humber dot ca I'm not sure if this will help at all, but outside of confirming this issue with number_format, it now appears as though converting a string to float causing a very similar problem. It seems to happen so randomly, but the only consistent element is that the numbers all have 9 in them. There is an existing bug opened for float that was closed as bogus: http://bugs.php.net/bug.php?id=47716 [2010-04-16 11:15:26] paj...@php.net I will ask our test team to try to reproduce it. [2010-04-15 20:24:54] derek dot ethier at humber dot ca I've been experiencing a similar problem on 5.2.12 and 5.2.13 on a Windows Server 2003 environment (not R2). I haven't been able to nail down any sort of specifics as it happens so randomly. The only consistent element seems to centre around odd numbers (specifically with 9) format incorrectly in a similar manner to the one originally described (with a colon in the middle). I'm not sure if this helps at all, but I thought I'd add a comment anyway. [2009-12-21 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". 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=49764 -- Edit this bug report at http://bugs.php.net/bug.php?id=49764&edit=1
Bug #51920 [Com]: ip2long result depends on platform
Edit report at http://bugs.php.net/bug.php?id=51920&edit=1 ID: 51920 Comment by: artificial at iol dot ie Reported by: olafvdspek at gmail dot com Summary: ip2long result depends on platform Status: Bogus Type: Bug Package: Network related Operating System: Debian x64 PHP Version: 5.3.2 New Comment: This is why I peruse bugs.php.net... for the lulz when somebody submits a bogus bug and makes themself look stupid. Previous Comments: [2010-05-27 09:41:35] olafvdspek at gmail dot com Like I said before, I know what signed and unsigned shorts, ints, longs and long longs are. [2010-05-27 08:25:49] m...@php.net Please read up on that topic and stop complaining about nothing. You may start here or anywhere else: http://en.wikipedia.org/wiki/Integer_%28computer_science%29 [2010-05-26 23:28:15] olafvdspek at gmail dot com Then just return the negative value. [2010-05-26 23:26:23] johan...@php.net This would be a different binary representation, which breaks binary math, which people often do with IP addresses. [2010-05-26 17:16:53] olafvdspek at gmail dot com Returning -107373295 on x64 would make it consistent with x86. But people might prefer 3221234342, in which case it could be returned as a string. 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=51920 -- Edit this bug report at http://bugs.php.net/bug.php?id=51920&edit=1
Bug #50858 [Asn->Csd]: $encryption_key parameter seems to be ineffective
Edit report at http://bugs.php.net/bug.php?id=50858&edit=1 ID: 50858 Updated by: fel...@php.net Reported by: roger dot olivier at gmail dot com Summary: $encryption_key parameter seems to be ineffective -Status: Assigned +Status: Closed Type: Bug Package: SQLite related Operating System: win32 only - Windows XP Sp3 PHP Version: 5.3.1 Assigned To: scottmac New Comment: The encryption_key will be used if the SQLITE_HAS_CODEC was properly defined in the build. Previous Comments: [2010-01-27 10:12:05] roger dot olivier at gmail dot com Description: The use of the encryption_key parameter in the SQLite3::open method don't works whereas the sqlite3 extension is compiled with the support of SEE (http://www.hwaci.com/sw/sqlite/see.html) The extension as been compiled in VC9 with the following configure : configure --enable-apache2-2handler --with-sqlite3=shared --enable-pdo=shared --with-pdo-sqlite=shared --enable-cgi --without-t1lib --enable-cli-win32 --with-extra-includes=d:/projets/php-sdk/Apache2/include;d:/projets/php-sdk/icu/include --with-extra-libs=d:/projets/php-sdk/Apache2/lib;d:/projets/php-sdk/icu/ The new php_sqlite3.dll and php_pdo_sqlite.dll are used to replace the dll present in the binary (still 5.3.1 VC9). Note : The use of PRAGMA key = 'mykey' works fine , it's just the use of the encryption_key parameter which seems broken Reproduce code: --- query('SELECT COUNT(*) from users'); var_dump($result->fetchArray()); ?> Expected result: array(2) { [0]=> int(1) ["COUNT(*)"]=> int(1) } Actual result: -- Unable to prepare statement: 26, file is encrypted or is not a database in -- Edit this bug report at http://bugs.php.net/bug.php?id=50858&edit=1
Bug #50858 [Csd->Bgs]: $encryption_key parameter seems to be ineffective
Edit report at http://bugs.php.net/bug.php?id=50858&edit=1 ID: 50858 Updated by: fel...@php.net Reported by: roger dot olivier at gmail dot com Summary: $encryption_key parameter seems to be ineffective -Status: Closed +Status: Bogus Type: Bug Package: SQLite related Operating System: win32 only - Windows XP Sp3 PHP Version: 5.3.1 Assigned To: scottmac Previous Comments: [2010-06-13 20:04:29] fel...@php.net The encryption_key will be used if the SQLITE_HAS_CODEC was properly defined in the build. [2010-01-27 10:12:05] roger dot olivier at gmail dot com Description: The use of the encryption_key parameter in the SQLite3::open method don't works whereas the sqlite3 extension is compiled with the support of SEE (http://www.hwaci.com/sw/sqlite/see.html) The extension as been compiled in VC9 with the following configure : configure --enable-apache2-2handler --with-sqlite3=shared --enable-pdo=shared --with-pdo-sqlite=shared --enable-cgi --without-t1lib --enable-cli-win32 --with-extra-includes=d:/projets/php-sdk/Apache2/include;d:/projets/php-sdk/icu/include --with-extra-libs=d:/projets/php-sdk/Apache2/lib;d:/projets/php-sdk/icu/ The new php_sqlite3.dll and php_pdo_sqlite.dll are used to replace the dll present in the binary (still 5.3.1 VC9). Note : The use of PRAGMA key = 'mykey' works fine , it's just the use of the encryption_key parameter which seems broken Reproduce code: --- query('SELECT COUNT(*) from users'); var_dump($result->fetchArray()); ?> Expected result: array(2) { [0]=> int(1) ["COUNT(*)"]=> int(1) } Actual result: -- Unable to prepare statement: 26, file is encrypted or is not a database in -- Edit this bug report at http://bugs.php.net/bug.php?id=50858&edit=1
Bug #18556 [Com]: Setting locale to 'tr_TR' lowercases class names
Edit report at http://bugs.php.net/bug.php?id=18556&edit=1 ID: 18556 Comment by: ceremcem at cshus dot org Reported by: spud at nothingness dot org Summary: Setting locale to 'tr_TR' lowercases class names Status: Assigned Type: Bug Package: Scripting Engine problem Operating System: Linux (RedHat 7.2) PHP Version: 5CVS, 4CVS (2005-10-04) Assigned To: dmitry New Comment: EDIT: The code that I used to regenerate this bug as follows: foreach(get_declared_classes() as $class) { if(!class_exists($class)) echo "$class No Longer Exists!\n"; } This code does not produce errors anymore but method names are still giving this type of error. I'm using ImageMagick and its PHP extension, imagick, which gives the error "fatal: thumbnailImage() method not found", seems to be related with this bug. When I rewrite the method name as ...->thumbnailimage(), all works OK. So, the methods documented in http://www.php.net/manual/en/class.imagick.php which include "I" (capital i), it can not be used without replacing "I" with "i". (same errors occur with MagickWand class) Could you please fix this too? Previous Comments: [2010-06-13 19:11:23] ceremcem at cshus dot org This bug still exists in PHP version 5.3.2. [2010-02-02 21:31:15] housecafe at freenet dot de Dear php-team, I´ve seen that 5.2.13RC1 is in progress. Could you fix this bug in this version, please ? Because I need turkish locale. Thanks in advance. [2010-01-22 09:00:27] paj...@php.net Dmitry, can you look at it please? It is still reproduceable with 5.2 and 5.3. [2009-11-13 16:58:15] joesiegrist at gmail dot com It is unbelievable that this bug persists into 2009. It is time to fix it. [2009-08-04 11:23:15] cankoy at ymail dot com Setting LC_CTYPE to something other than tr_TR solves nothing, it's not even a workaround, you just get a bastardized locale in which regex patterns do not match Turkish char.s and XXlower/XXupper functions become nothing but a joke. This bug has been around for ages, so it's not fixable? OK, don't fix it, but at least provide a means to turn off(*) the horrible PHP design decision "case-insensitive function lookup", so that we have an option to avoid all this mess. (*)like, a Php.ini directive 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=18556 -- Edit this bug report at http://bugs.php.net/bug.php?id=18556&edit=1
Bug #50374 [Asn]: .user.ini subdirectory not working and problem with [PATH] in php.ini
Edit report at http://bugs.php.net/bug.php?id=50374&edit=1 ID: 50374 User updated by: tom_borgo at hotmail dot com Reported by: tom_borgo at hotmail dot com Summary: .user.ini subdirectory not working and problem with [PATH] in php.ini Status: Assigned Type: Bug Package: Scripting Engine problem Operating System: XP SP3 PHP Version: 5.3.1 Assigned To: pajoye New Comment: Hello, Yes, the problem has not been resolved, or the documentation has not been updated to say that it is normal that it doesn't affect the subdirectory. It is a shame because .user.ini is very important to use php directive by directory (because htaccess cannot be used in this way like PHP in apache module). I hope problem will be taken really into consideration. And it is really easy to test it. Thanks. Thomas. Previous Comments: [2010-06-10 21:15:49] jirka at pbox dot cz Same issue with php 5.3.2 (CGI) on WinXP SP3. Build date Apr 1 2010 17:13:20. .user.ini custom setting works in the directory where the ini file is located, but has no effect in any of subdirectories. [2009-12-11 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-12-03 16:10:27] tom_borgo at hotmail dot com Ok so i just tried with the 5.3.2-dev (Dec 3 2009 14:57:19) snapshot. Problem .user.ini for php script in subdirectory is always the same. /www/phpinfo.php -> take into account the /www/.user.ini /www/administrator/phpinfo.php -> take NOT into account the /www/.user.ini For the [PATH] problem, i tried and problem is no more here. So I tried again with 5.3.1, no more problem. Problem is just with 5.3.0 (VC8 from ZendServer), so [PATH] problem is just for ZendServer. So we can forgot about the [PATH] problem. But for the .user.ini, am i mistaken something ? Or is it a php problem ? Thanks. Thomas. [2009-12-03 15:50:05] tom_borgo at hotmail dot com To: paj...@php.net Yes I know it works only for CGI/FastCGI SAPI (http://php.net/manual/en/configuration.file.per-user.php). .user.ini works for me only for the directory where it is and without any [PATH] section in the main php.ini. I tried with a PHP downloaded from the php.net (5.3.1 NTS VC6 and i try with VC9 too). It is the same as the one from ZendServer (VC8). So problem is in ZendServer,but too in the last stable binary windows compiled on the php.net website. Is it a configuration problem on my side or does another people got the same problems ? I will try with the snapshot right now. I keep you warning. Thanks. Thomas. [2009-12-03 15:39:18] tom_borgo at hotmail dot com Just a comment about the [PATH] section It is said in http://php.net/ini.sections that directive in PATH section overide custom and runtime ini directives. So I think it is in fact normal that .user.ini don't change the display_errors flag. But .user.ini are not parsed if [PATH] section are in the main php.ini for other directory Ex: [PATH=/www2/] display_errors = 1 /www/.user.ini is not more taken into account ! If i remove the PATH section (i put it inthe end of my php.ini), .user.ini is taken into account. Really strange... 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=50374 -- Edit this bug report at http://bugs.php.net/bug.php?id=50374&edit=1
Bug #50374 [Asn]: .user.ini subdirectory not working and problem with [PATH] in php.ini
Edit report at http://bugs.php.net/bug.php?id=50374&edit=1 ID: 50374 Updated by: paj...@php.net Reported by: tom_borgo at hotmail dot com Summary: .user.ini subdirectory not working and problem with [PATH] in php.ini Status: Assigned Type: Bug Package: Scripting Engine problem Operating System: XP SP3 PHP Version: 5.3.1 Assigned To: pajoye New Comment: Assigned means "someone (me) will work on it", not "it is fixed" :) Btw, htscanner allows htaccess-like file for 5.x, for the record. Previous Comments: [2010-06-13 20:19:49] tom_borgo at hotmail dot com Hello, Yes, the problem has not been resolved, or the documentation has not been updated to say that it is normal that it doesn't affect the subdirectory. It is a shame because .user.ini is very important to use php directive by directory (because htaccess cannot be used in this way like PHP in apache module). I hope problem will be taken really into consideration. And it is really easy to test it. Thanks. Thomas. [2010-06-10 21:15:49] jirka at pbox dot cz Same issue with php 5.3.2 (CGI) on WinXP SP3. Build date Apr 1 2010 17:13:20. .user.ini custom setting works in the directory where the ini file is located, but has no effect in any of subdirectories. [2009-12-11 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-12-03 16:10:27] tom_borgo at hotmail dot com Ok so i just tried with the 5.3.2-dev (Dec 3 2009 14:57:19) snapshot. Problem .user.ini for php script in subdirectory is always the same. /www/phpinfo.php -> take into account the /www/.user.ini /www/administrator/phpinfo.php -> take NOT into account the /www/.user.ini For the [PATH] problem, i tried and problem is no more here. So I tried again with 5.3.1, no more problem. Problem is just with 5.3.0 (VC8 from ZendServer), so [PATH] problem is just for ZendServer. So we can forgot about the [PATH] problem. But for the .user.ini, am i mistaken something ? Or is it a php problem ? Thanks. Thomas. [2009-12-03 15:50:05] tom_borgo at hotmail dot com To: paj...@php.net Yes I know it works only for CGI/FastCGI SAPI (http://php.net/manual/en/configuration.file.per-user.php). .user.ini works for me only for the directory where it is and without any [PATH] section in the main php.ini. I tried with a PHP downloaded from the php.net (5.3.1 NTS VC6 and i try with VC9 too). It is the same as the one from ZendServer (VC8). So problem is in ZendServer,but too in the last stable binary windows compiled on the php.net website. Is it a configuration problem on my side or does another people got the same problems ? I will try with the snapshot right now. I keep you warning. Thanks. Thomas. 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=50374 -- Edit this bug report at http://bugs.php.net/bug.php?id=50374&edit=1
Bug #50374 [Asn]: .user.ini subdirectory not working and problem with [PATH] in php.ini
Edit report at http://bugs.php.net/bug.php?id=50374&edit=1 ID: 50374 User updated by: tom_borgo at hotmail dot com Reported by: tom_borgo at hotmail dot com Summary: .user.ini subdirectory not working and problem with [PATH] in php.ini Status: Assigned Type: Bug Package: Scripting Engine problem Operating System: XP SP3 PHP Version: 5.3.1 Assigned To: pajoye New Comment: Thanks Pajoye for your fast answer. I really hope you can fix it ! :) Yes htscanner is an alternative solution, i never try it. I prefer rely on PHP itself. And htscanner is in alpha stage and last release is more one year old, i mean for system in real production it is necessary to have stable version. Htscanner seems ok for leisure purpose but I will not use it for bussiness application. Previous Comments: [2010-06-13 20:32:37] paj...@php.net Assigned means "someone (me) will work on it", not "it is fixed" :) Btw, htscanner allows htaccess-like file for 5.x, for the record. [2010-06-13 20:19:49] tom_borgo at hotmail dot com Hello, Yes, the problem has not been resolved, or the documentation has not been updated to say that it is normal that it doesn't affect the subdirectory. It is a shame because .user.ini is very important to use php directive by directory (because htaccess cannot be used in this way like PHP in apache module). I hope problem will be taken really into consideration. And it is really easy to test it. Thanks. Thomas. [2010-06-10 21:15:49] jirka at pbox dot cz Same issue with php 5.3.2 (CGI) on WinXP SP3. Build date Apr 1 2010 17:13:20. .user.ini custom setting works in the directory where the ini file is located, but has no effect in any of subdirectories. [2009-12-11 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-12-03 16:10:27] tom_borgo at hotmail dot com Ok so i just tried with the 5.3.2-dev (Dec 3 2009 14:57:19) snapshot. Problem .user.ini for php script in subdirectory is always the same. /www/phpinfo.php -> take into account the /www/.user.ini /www/administrator/phpinfo.php -> take NOT into account the /www/.user.ini For the [PATH] problem, i tried and problem is no more here. So I tried again with 5.3.1, no more problem. Problem is just with 5.3.0 (VC8 from ZendServer), so [PATH] problem is just for ZendServer. So we can forgot about the [PATH] problem. But for the .user.ini, am i mistaken something ? Or is it a php problem ? Thanks. Thomas. 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=50374 -- Edit this bug report at http://bugs.php.net/bug.php?id=50374&edit=1
[PHP-BUG] Req #52076 [NEW]: rename Australian time zone abbreviations to avoid ambiguity
From: Operating system: Linux PHP version: 5.3.2 Package: Date/time related Bug Type: Feature/Change Request Bug description:rename Australian time zone abbreviations to avoid ambiguity Description: In PHP, formatting a date with 'T' for an Australian East or Central time zone generates "EST" and "CST" respectively. Since time zone calculations often involve global context, it is confusing to have multiple definitions of EST and CST, as EST is also used for Eastern Standard Time (US) and CST for Central Standard Time (US). To quote Wikipedia: "The proper names of Australia's time zones vary. In international contexts they are often called Australian Western Standard Time (AWST), Australian Central Standard Time (ACST), and Australian Eastern Standard Time (AEST). In domestic contexts the leading "Australian" is often dropped." -- Edit bug report at http://bugs.php.net/bug.php?id=52076&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52076&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52076&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52076&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52076&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52076&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52076&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52076&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52076&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52076&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52076&r=support Expected behavior: http://bugs.php.net/fix.php?id=52076&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52076&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52076&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52076&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52076&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52076&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52076&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52076&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52076&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52076&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52076&r=mysqlcfg
Req #52076 [Opn->Wfx]: rename Australian time zone abbreviations to avoid ambiguity
Edit report at http://bugs.php.net/bug.php?id=52076&edit=1 ID: 52076 Updated by: der...@php.net Reported by: dfsdf at mailinator dot com Summary: rename Australian time zone abbreviations to avoid ambiguity -Status: Open +Status: Wont fix Type: Feature/Change Request Package: Date/time related Operating System: Linux PHP Version: 5.3.2 New Comment: We are consuming another data source here. If you want to get this changed, you need to take this up with the folks at http://www.twinsun.com/tz/tz-link.htm through their mailing-list. I can however tell you, that you probably have little success convincing them without proper backed-up governmental descriptions. Previous Comments: [2010-06-13 21:14:09] dfsdf at mailinator dot com Description: In PHP, formatting a date with 'T' for an Australian East or Central time zone generates "EST" and "CST" respectively. Since time zone calculations often involve global context, it is confusing to have multiple definitions of EST and CST, as EST is also used for Eastern Standard Time (US) and CST for Central Standard Time (US). To quote Wikipedia: "The proper names of Australia's time zones vary. In international contexts they are often called Australian Western Standard Time (AWST), Australian Central Standard Time (ACST), and Australian Eastern Standard Time (AEST). In domestic contexts the leading "Australian" is often dropped." -- Edit this bug report at http://bugs.php.net/bug.php?id=52076&edit=1
[PHP-BUG] Bug #52077 [NEW]: SNMP GET/WALK may hangs FOREVER
From: Operating system: Win XP SP3 PHP version: 5.2.13 Package: SNMP related Bug Type: Bug Bug description:SNMP GET/WALK may hangs FOREVER Description: Under a heavy GET/WALK-ing (form localhost to localhost) php may hangs forever -> apache's threads becomes zombies with CLOSE_WAIT sates even all timeouts (php and apache) are elapsed many times. Call-stack of a one zombie-thread: ntoskrnl.exe!KiUnlockDispatcherDatabase+0x77 ntoskrnl.exe!KeSetEvent+0x74 ntoskrnl.exe!PspGetSetContextSpecialApc+0x4e ntoskrnl.exe!KiDeliverApc+0xb3 ntoskrnl.exe!KiSwapThread+0x64 ntoskrnl.exe!KeWaitForSingleObject+0x1c2 ntoskrnl.exe!NtWaitForSingleObject+0x9a ntoskrnl.exe!KiFastCallEntry+0xf8 ntdll.dll!KiFastSystemCallRet ntdll.dll!ZwWaitForSingleObject+0xc mswsock.dll!SockWaitForSingleObject+0x1a0 mswsock.dll!WSPRecvFrom+0x1f0 WS2_32.dll!recvfrom+0x89 php_snmp.dll!snmp_sess_read+0x21f php_snmp.dll!snmp_sess_read+0x10 php_snmp.dll!snmp_read+0x17 php_snmp.dll!snmp_synch_response_cb+0xe8 php_snmp.dll!snmp_synch_response+0x19 php_snmp.dll!php_snmp_internal+0x267 php_snmp.dll!php_snmp+0x6da php_snmp.dll!zif_snmp2_get+0x27 php5ts.dll!zend_do_fcall_common_helper_SPEC+0x7ab php5ts.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER+0xe5 php5ts.dll!execute+0x1c5 php5ts.dll!zend_do_fcall_common_helper_SPEC+0x8ca php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+0x15 php5ts.dll!execute+0x1c5 php5ts.dll!zend_do_fcall_common_helper_SPEC+0x8ca php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+0x15 php5ts.dll!execute+0x1c5 php5ts.dll!zend_execute_scripts+0x107 php5ts.dll!php_execute_script+0x21d php5apache.dll!apache_php_module_main+0x91 php5apache.dll!send_php+0x265 php5apache.dll!send_parsed_php+0x10 ApacheCore.dll!ap_invoke_handler+0x87 ApacheCore.dll!ap_process_request+0x2b4 ApacheCore.dll!ap_process_request+0x26 ApacheCore.dll!ap_start_restart+0x37f WS2_32.dll!WSASocketW+0x119 IMHO bad call "WS2_32.dll!recvfrom" in buggy ucd-snmp library may hangs. There are no socket option like "setsockopt(sd, SOL_SOCKET, SO_RCVTIMEO, ..." before recvfrom call. -- Edit bug report at http://bugs.php.net/bug.php?id=52077&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52077&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52077&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52077&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52077&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52077&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52077&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52077&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52077&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52077&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52077&r=support Expected behavior: http://bugs.php.net/fix.php?id=52077&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52077&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52077&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52077&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52077&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52077&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52077&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52077&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52077&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52077&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52077&r=mysqlcfg
[PHP-BUG] Bug #52078 [NEW]: fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt
From: Operating system: PLD Linux PHP version: 5.3.2 Package: *General Issues Bug Type: Bug Bug description:fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt Description: fileinode overflows on filesystem where inode count is huge. it is mentioned in comment of manual as well: http://php.net/manual/en/function.fileinode.php Test script: --- $ (t=`mktemp -d`; cd $t; php -r 'var_dump(fileinode("."));'; echo $t; ls -ldi $t) int(-2051936757) /home/users/glen/tmp/tmp.zLdoithBR0 2243030539 drwx-- 2 glen users 6 Jun 14 00:26 /home/users/glen/tmp/tmp.zLdoithBR0/ Expected result: test must be fixed to expect %i instead of %d. -- Edit bug report at http://bugs.php.net/bug.php?id=52078&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52078&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52078&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52078&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52078&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52078&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52078&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52078&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52078&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52078&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52078&r=support Expected behavior: http://bugs.php.net/fix.php?id=52078&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52078&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52078&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52078&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52078&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52078&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52078&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52078&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52078&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52078&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52078&r=mysqlcfg
Bug #52078 [Opn]: fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt
Edit report at http://bugs.php.net/bug.php?id=52078&edit=1 ID: 52078 User updated by: glen at delfi dot ee Reported by: glen at delfi dot ee Summary: fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt Status: Open Type: Bug -Package: *General Issues +Package: Filesystem function related Operating System: PLD Linux PHP Version: 5.3.2 New Comment: fix package Previous Comments: [2010-06-13 23:29:48] glen at delfi dot ee Description: fileinode overflows on filesystem where inode count is huge. it is mentioned in comment of manual as well: http://php.net/manual/en/function.fileinode.php Test script: --- $ (t=`mktemp -d`; cd $t; php -r 'var_dump(fileinode("."));'; echo $t; ls -ldi $t) int(-2051936757) /home/users/glen/tmp/tmp.zLdoithBR0 2243030539 drwx-- 2 glen users 6 Jun 14 00:26 /home/users/glen/tmp/tmp.zLdoithBR0/ Expected result: test must be fixed to expect %i instead of %d. -- Edit this bug report at http://bugs.php.net/bug.php?id=52078&edit=1
Bug #31481 [Com]: curl isn't following redirects with a relative path
Edit report at http://bugs.php.net/bug.php?id=31481&edit=1 ID: 31481 Comment by: ktcox at rogers dot com Reported by: jason at merchant dot to Summary: curl isn't following redirects with a relative path Status: No Feedback Type: Bug Package: HTTP related Operating System: Windows XP Pro PHP Version: 4.3.10 New Comment: This Works http://localhost/updateindex.php'); $page = curl_exec($addpage); curl_close($addpage); echo "$page"; ?> The following don't work. Previous Comments: [2005-01-31 22:34:22] sni...@php.net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2005-01-11 04:54:37] sni...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2005-01-11 00:07:59] jason at merchant dot to Description: I am grabbing an https:// page using curl and that page redirects using a relative path like "/page1.php". curl is failing to follow this path. I have tried replacing the relative path with an absolute path on the page I'm grabbing and that worked so I know the problem lies in the relative path redirection. -- Edit this bug report at http://bugs.php.net/bug.php?id=31481&edit=1
Bug #52018 [Com]: Probable cookie problem with 5.3.2
Edit report at http://bugs.php.net/bug.php?id=52018&edit=1 ID: 52018 Comment by: dklanac at gmail dot com Reported by: nospam at nospam dot homelinux dot org Summary: Probable cookie problem with 5.3.2 Status: Open Type: Bug Package: HTTP related Operating System: Linux Debian 5.0.4 PHP Version: 5.3.2 New Comment: Correction. My local PHP version whose cookies work properly is 5.3.1. Previous Comments: [2010-06-08 13:05:33] nospam at nospam dot homelinux dot org Isolating the phpBB "automatic logon" feature would likely be a long and complex task, as I haven't deeply studied its code. I already opened a topic on the phpBB forum about 10 days ago, I just added an update to it. http://www.phpbb.com/community/viewtopic.php?t=2092537 Gingko [2010-06-08 07:54:26] phi...@php.net Maybe you can reproduce by isolating the phpBB "automatic logon" feature? Do the phpBB people have any ideas? I suspect they'd do a more efficient job finding this bug. [2010-06-07 21:47:59] nospam at nospam dot homelinux dot org Description: There seems to be a problem with PHP 5.3.2: cookies are not working properly in some cases, for example when running PhpBB 3.0.5 (and probably other versions also). The reason **seems** to be that the $_COOKIE super global variable is not always populated with received cookies, and the most visible effect is that the users of my phpBB forum are not able to use the âautomatic logonâ feature of phpBB. However, a simple test case with the setcookie function works properly, so I donât know exactly what kind of cookie can trigger the bug. Downgrading to phpBB 5.2.13 or lower effectively fix the problem. I made multiple tries, using either 5.2.6, 5.2.13 or 5.3.2, either compiled by myself or installed from Debian packages, with or without the Debian security patches, while keeping the same php.ini configuration in all cases, and the result was always the same: - with 5.2.6 or 5.2.13, cookies are handled properly, and phpBB users can use the phpBB's automatic âautomatic logonâ feature. - with 5.3.2, cookies seem to be blocked, $_COOKIE is not populated (except maybe by as many empty strings as the number of expected cookies). The server also uses Apache 2.2.9 and MySQL 5.1.46, and I tried on two different Debian 5.0.4 configurations, one as 32 bits at my home and one as 64 bits in a datacenter. I used Wireshark for network sniffing, so I can tell that cookies are truely present in HTTP headers. I tracked the $_COOKIE variable by adding a "error_log(print_r($_COOKIE, true))" instruction near the beginning of the phpBB common code. Test script: --- I'm sorry, I don't know how to make a short test script showing the problem. I tried a short test with setcookie but it worked properly, even with 5.3.2. I suppose that there are some combined interactions within phpBB triggering this problem when they happen altogether. The only procedure that I can suggest is the following: - Install a phpBB server (download from http://www.php.net/) with the default configuration. - Create a user account with any name. - Try to login on this account. Don't forget to check the "Log me on automatically each visit" option when login. - Browse a little inside the forum, check that the connexion is kept by session ID. - Quit your browser, closing all of its Windows. - Reopen the browser, and open again the phpBB forum. Use the root address of the forum, without the session ID parameter. Expected result: When opening the forum homepage, login should be already made, kept from previous session. This is what happens with 5.2.6 or 5.2.13. Actual result: -- Forum open correctly, but previous login is completely forgotten. This is what happens with 5.3.2. -- Edit this bug report at http://bugs.php.net/bug.php?id=52018&edit=1
Bug #31481 [NoF]: curl isn't following redirects with a relative path
Edit report at http://bugs.php.net/bug.php?id=31481&edit=1 ID: 31481 Updated by: ras...@php.net Reported by: jason at merchant dot to Summary: curl isn't following redirects with a relative path Status: No Feedback Type: Bug Package: HTTP related Operating System: Windows XP Pro PHP Version: 4.3.10 New Comment: Those are not supposed to work. curl_init() takes a URL. None of the arguments in your example that don't work are URLs. Previous Comments: [2010-06-14 00:15:42] ktcox at rogers dot com This Works http://localhost/updateindex.php'); $page = curl_exec($addpage); curl_close($addpage); echo "$page"; ?> The following don't work. [2005-01-31 22:34:22] sni...@php.net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2005-01-11 04:54:37] sni...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2005-01-11 00:07:59] jason at merchant dot to Description: I am grabbing an https:// page using curl and that page redirects using a relative path like "/page1.php". curl is failing to follow this path. I have tried replacing the relative path with an absolute path on the page I'm grabbing and that worked so I know the problem lies in the relative path redirection. -- Edit this bug report at http://bugs.php.net/bug.php?id=31481&edit=1