Bug #41293 [Com]: HTTP_RAW_POST_DATA fails to ever be set
Edit report at http://bugs.php.net/bug.php?id=41293&edit=1
ID: 41293
Comment by: php at yahoo dot com
Reported by:jerome at rainstormconsulting dot com
Summary:HTTP_RAW_POST_DATA fails to ever be set
Status: Closed
Type: Bug
Package:HTTP related
Operating System: linux (centos or ubuntu)
PHP Version:5.2.2
Assigned To:iliaa
Block user comment: N
Private report: N
New Comment:
Thank you all
Previous Comments:
[2007-05-06 16:34:21] il...@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.
[2007-05-06 14:06:40] sylvain at jamendo dot com
I used the same fix as Jerome,
if (phpversion()=="5.2.2") $GLOBALS['HTTP_RAW_POST_DATA'] =
file_get_contents("php://input");
Anyway, this seems like a duplicate of a bug that appeared in 5.1.0 (cf
changelog)
I just can't believe there is no unit tests for this kind of bugs that
should never ever appear again.
[2007-05-06 13:42:54] jerome at rainstormconsulting dot com
Putting this in a file all my services include seems to be working,
but I only did this on a test machine, i will not upgrade our
production server until this is resolved though.
if (!isset($HTTP_RAW_POST_DATA)){
$HTTP_RAW_POST_DATA = file_get_contents('php://input');
}
[2007-05-06 13:35:26] sylvain at jamendo dot com
Are you aware that this is a *major* issue?
All our xmlrpc backends are broken because of this bug, both with pear
XML_RPC and XML_RPC2.
Is there a workaround besides php://input ?
[2007-05-05 14:10:44] develar at gmail dot com
>> php://input is not affected
only in start script, but in end script php://input is empty.
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=41293
--
Edit this bug report at http://bugs.php.net/bug.php?id=41293&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: mark at catseye dot org
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
Block user comment: N
Private report: N
New Comment:
I tried this out in a development snapshot for PHP 5.3.7, but found that
calls to zlog() from children were not showing up in syslog.
The following change fixes the problem; let me know if you'd like me to
upload a new version of the patch.
diff -up php-snap/sapi/fpm/fpm/fpm_stdio.c.syslog
php-snap/sapi/fpm/fpm/fpm_st
dio.c
--- php-snap/sapi/fpm/fpm/fpm_stdio.c.syslog 2011-04-11
19:10:17.425036568 -0
400
+++ php-snap/sapi/fpm/fpm/fpm_stdio.c 2011-04-11 19:10:24.569131370
-0400
@@ -64,9 +64,9 @@ int fpm_stdio_init_child(struct fpm_work
#endif
{
close(fpm_globals.error_log_fd);
+ fpm_globals.error_log_fd = -1;
+ zlog_set_fd(-1);
}
- fpm_globals.error_log_fd = -1;
- zlog_set_fd(-1);
if (wp->listening_socket != STDIN_FILENO) {
if (0 > dup2(wp->listening_socket, STDIN_FILENO)) {
Previous Comments:
[2011-02-15 21:34:21] php at mike2k dot com
I would log everything under a consistent ident/facility myself.
Then you have all FPM stuff coming in one stream. If you want to split
it up then
you can use filters inside of whatever syslog tools you use.
$.02
[2011-02-15 19:42:45] kyle_leaders at mcgraw-hill dot com
As a small fix to this, I just noticed that in 5.3.5, PHP-FPM logs
correctly to
the syslog, but the syslog tag is incorrect.
If for example you have a pool named "www" it will log to syslog like
so:
2011-02-15 13:28:09.172141-05:00 hostname w: PHP Warning: ocierror()
expects
parameter 1 to be resource, null given in filename.php on line 177
Similarly if you have a longer pool name (poolname) it'll show up like
so:
2011-02-15 13:28:09.172141-05:00 hostname olname: PHP Warning:
ocierror()
expects parameter 1 to be resource, null given in filename.php on line
177
It seems to be chopping off the first 2 characters of the pool name when
it
reports the syslog tag/program name to syslog.
[2011-02-10 07:58:45] ef-lists at email dot de
Oh you're right. We're actually experiencing this issue here.
At least the master process should always log to the configured
ident/facility - that's configuration and process manager
warnings/errors. By far the most important log output from FPM, IMHO.
I don't think this is a critical issue for FPM, as log output is never
discarded and other sapis (milter, thttpd, mod_php with Apache ErrorLog
set to syslog) do it the same way - although it would be nice to see
this resolved. I still wonder how to properly do this... open a separate
socket and mimic syslog behaviour? How to address this on Windows?
If you have updates, I'd be really curious. If I can help, let me know.
:-)
[2011-01-29 15:46:44] f...@php.net
thx for the up to date patch. But there is still a remaining problem:
php_syslog(), openlog() and closelog() can be called from FPM code, core
code,
user script, module, sapi, ...
If two calls to openlog() are made from two different places. Then this
is not
sure than php_syslog() will log the right ident and facility.
This a global reflection to make around PHP and not only in FPM.
I'm working on it.
[2011-01-28 15:53:44] ef-lists at email dot de
Hi,
added a new patch, which can be applied to a vanilla PHP 5.3.5.
compiles and runs with:
--enable-debug without relevant warnings
--enable-maintainer-zts
without other flags
with having HAVE_SYSLOG_H in main/php_config.h undefined
changes:
* modified patch to work with FPM in 5.3.5
* added new parameters to config dump (todo: translate syslog prio and
facility to nice human-readable values)
* made comparing syslog facilities case-insensitive
* replaced syslog() calls with php_syslog()
Regards,
Edgar
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 #54482 [Bgs]: imagecreatefromstring fails
Edit report at http://bugs.php.net/bug.php?id=54482&edit=1
ID: 54482
User updated by:info822 at freshsoftware dot net
Reported by:info822 at freshsoftware dot net
Summary:imagecreatefromstring fails
Status: Bogus
Type: Bug
Package:GD related
Operating System: Fedora 13 (Godard) Kernel Linux
PHP Version:5.3.6
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
I am closing this issue. Imagecreatefromstring does not handle large
images very well. I had to rewrite my code as shown above.
Previous Comments:
[2011-04-11 23:25:25] info822 at freshsoftware dot net
$img_info = getimagesize("$calendar_info->event_img");
//Create a smaller image pallet
$thumb = imagecreatetruecolor($new_width, $new_height);// or die("Could
create true color image. Error on file: " . __FILE__ . " Line: " .
__LINE__);
// Output
if($img_info[2] == 1){
$source = imagecreatefromgif("$calendar_info->event_img");// or
die("Could create image from string. Error on file: " . __FILE__ . "
Line: " . __LINE__);
imagecopyresampled($thumb, $source, 0, 0, 0, 0, $new_width,
$new_height, $img_info[0], $img_info[1]);// or die("Could not copy image
Error on file: " . __FILE__ . " Line: " . __LINE__);
header("Content-Length: " . filesize("$calendar_info->event_img"));
header("Content-type: " . image_type_to_mime_type(IMAGETYPE_GIF));
imagegif($thumb);
}
elseif($img_info[2] == 2){
$source = imagecreatefromjpeg("$calendar_info->event_img");// or
die("Could create image from string. Error on file: " . __FILE__ . "
Line: " . __LINE__);
imagecopyresampled($thumb, $source, 0, 0, 0, 0, $new_width,
$new_height, $img_info[0], $img_info[1]);// or die("Could not copy image
Error on file: " . __FILE__ . " Line: " . __LINE__);
header("Content-Length: " . filesize("$calendar_info->event_img"));
header("Content-type: " . image_type_to_mime_type(IMAGETYPE_JPEG));
imagejpeg($thumb);
}
elseif($img_info[2] == 3){
$source = imagecreatefrompng("$calendar_info->event_img");// or
die("Could create image from string. Error on file: " . __FILE__ . "
Line: " . __LINE__);
imagecopyresampled($thumb, $source, 0, 0, 0, 0, $new_width,
$new_height, $img_info[0], $img_info[1]);// or die("Could not copy image
Error on file: " . __FILE__ . " Line: " . __LINE__);
header("Content-Length: " . filesize("$calendar_info->event_img"));
header("Content-type: " . image_type_to_mime_type(IMAGETYPE_PNG));
imagepng($thumb);
}
imagedestroy($thumb);
?>
[2011-04-08 19:46:41] paj...@php.net
Totally unrelated issues.
[2011-04-08 19:21:33] info822 at freshsoftware dot net
I am not the only person with that problem. Read:
http://www.zabbix.com/forum/showthread.php?t=11195
http://bugs.php.net/bug.php?id=29482
http://drupal.org/node/307028
[2011-04-08 18:19:28] paj...@php.net
It is not PHP, it works just fine on any machine I tried.
[2011-04-08 18:05:56] info822 at freshsoftware dot net
The code is outputing errors. Look at:
http://thewordsmith.dyndns.info/test/
Notice that a2.png is not created in:
http://thewordsmith.dyndns.info/link_to_tmp/
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=54482
--
Edit this bug report at http://bugs.php.net/bug.php?id=54482&edit=1
Bug #54482 [Bgs]: imagecreatefromstring fails
Edit report at http://bugs.php.net/bug.php?id=54482&edit=1
ID: 54482
User updated by:info822 at freshsoftware dot net
Reported by:info822 at freshsoftware dot net
Summary:imagecreatefromstring fails
Status: Bogus
Type: Bug
Package:GD related
Operating System: Fedora 13 (Godard) Kernel Linux
PHP Version:5.3.6
Assigned To:pajoye
Block user comment: N
Private report: N
New Comment:
$img_info = getimagesize("$calendar_info->event_img");
//Create a smaller image pallet
$thumb = imagecreatetruecolor($new_width, $new_height);// or die("Could
create true color image. Error on file: " . __FILE__ . " Line: " .
__LINE__);
// Output
if($img_info[2] == 1){
$source = imagecreatefromgif("$calendar_info->event_img");// or
die("Could create image from string. Error on file: " . __FILE__ . "
Line: " . __LINE__);
imagecopyresampled($thumb, $source, 0, 0, 0, 0, $new_width,
$new_height, $img_info[0], $img_info[1]);// or die("Could not copy image
Error on file: " . __FILE__ . " Line: " . __LINE__);
header("Content-Length: " . filesize("$calendar_info->event_img"));
header("Content-type: " . image_type_to_mime_type(IMAGETYPE_GIF));
imagegif($thumb);
}
elseif($img_info[2] == 2){
$source = imagecreatefromjpeg("$calendar_info->event_img");// or
die("Could create image from string. Error on file: " . __FILE__ . "
Line: " . __LINE__);
imagecopyresampled($thumb, $source, 0, 0, 0, 0, $new_width,
$new_height, $img_info[0], $img_info[1]);// or die("Could not copy image
Error on file: " . __FILE__ . " Line: " . __LINE__);
header("Content-Length: " . filesize("$calendar_info->event_img"));
header("Content-type: " . image_type_to_mime_type(IMAGETYPE_JPEG));
imagejpeg($thumb);
}
elseif($img_info[2] == 3){
$source = imagecreatefrompng("$calendar_info->event_img");// or
die("Could create image from string. Error on file: " . __FILE__ . "
Line: " . __LINE__);
imagecopyresampled($thumb, $source, 0, 0, 0, 0, $new_width,
$new_height, $img_info[0], $img_info[1]);// or die("Could not copy image
Error on file: " . __FILE__ . " Line: " . __LINE__);
header("Content-Length: " . filesize("$calendar_info->event_img"));
header("Content-type: " . image_type_to_mime_type(IMAGETYPE_PNG));
imagepng($thumb);
}
imagedestroy($thumb);
?>
Previous Comments:
[2011-04-08 19:46:41] paj...@php.net
Totally unrelated issues.
[2011-04-08 19:21:33] info822 at freshsoftware dot net
I am not the only person with that problem. Read:
http://www.zabbix.com/forum/showthread.php?t=11195
http://bugs.php.net/bug.php?id=29482
http://drupal.org/node/307028
[2011-04-08 18:19:28] paj...@php.net
It is not PHP, it works just fine on any machine I tried.
[2011-04-08 18:05:56] info822 at freshsoftware dot net
The code is outputing errors. Look at:
http://thewordsmith.dyndns.info/test/
Notice that a2.png is not created in:
http://thewordsmith.dyndns.info/link_to_tmp/
[2011-04-08 17:49:21] info822 at freshsoftware dot net
I know that the coding works. The problem is either with PHP or the
libraries. How do you know that this is not a PHP problem? Just because
the code is know to work does not mean that the PHP build is not
experiencing problems. I am the ISP of the dev box.
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=54482
--
Edit this bug report at http://bugs.php.net/bug.php?id=54482&edit=1
Bug #54491 [Opn]: Crash during shutdown sequence
Edit report at http://bugs.php.net/bug.php?id=54491&edit=1
ID: 54491
User updated by:msamson at chowly dot com
Reported by:msamson at chowly dot com
Summary:Crash during shutdown sequence
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Fedora 14 x64
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Just reproduced the bug in Ubuntu 10.10 i386 with a php 5.3.6 ppa
For a total of 2 different computers (both F14 x64) and 4 virtual
machines:
Fedora x64 RPM
Fedora x64 Source
Ubuntu x64 PPA
Ubuntu x86 PPA
Previous Comments:
[2011-04-08 17:50:57] msamson at chowly dot com
Valgrind output of `php webroot/index.php`
zend_mm_heap corrupted
==3214==
==3214== HEAP SUMMARY:
==3214== in use at exit: 7,084,078 bytes in 14,840 blocks
==3214== total heap usage: 16,202 allocs, 1,362 frees, 7,502,798 bytes
allocated
==3214==
==3214== LEAK SUMMARY:
==3214==definitely lost: 0 bytes in 0 blocks
==3214==indirectly lost: 0 bytes in 0 blocks
==3214== possibly lost: 5,259,364 bytes in 1,386 blocks
==3214==still reachable: 1,824,714 bytes in 13,454 blocks
==3214== suppressed: 0 bytes in 0 blocks
==3214== Rerun with --leak-check=full to see details of leaked memory
==3214==
==3214== For counts of detected and suppressed errors, rerun with: -v
==3214== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 42 from 8)
[2011-04-08 17:05:12] msamson at chowly dot com
No, the crash also occurs when the mongo.so extension is not loaded.
At first, it thought it was the culprit, but it happens without mongo
being
loaded.
One thing, the CLI version seems to be more resilient, it needs more
data loaded
to crash, whereas with the apache module, it's always crashing.
Chromium reports `Error 324 (net::ERR_EMPTY_RESPONSE): Unknown error`
when
accessing a url.
I was able to get a backtrace (with no execute or zbacktrace output) and
around
frame 30-ish, it specifies entering the shutdown sequence, cleaning up a
closure
and then the crash.
Changing the summary to better reflect the problem.
[2011-04-08 09:54:35] ahar...@php.net
Does PHP only crash when the mongo extension is loaded? If so, please
report this at http://pecl.php.net/package/mongo, as bugs in PECL
extensions aren't dealt with in this bug tracker.
[2011-04-08 06:28:38] msamson at chowly dot com
Finally got a backtrace:
/Zend/Zend_execute_API.c:437
437 Z_DELREF_PP(zval_ptr);
There is a mention in another frame about requesting php shutdown. Then
higher, it says it will cleanup a closure. Sadly, no execute and
zbacktrace output was empty.
[2011-04-08 05:27:10] msamson at chowly dot com
Description:
PHP crash either as a httpd module or as cli with `zend_mm_heap
corrupted`.
Please see https://bugzilla.redhat.com/show_bug.cgi?id=694630
This was initially thought as a fedora packaging bug, but even a
compiled from
source php is producing the same error.
Test script:
---
Please see https://bugzilla.redhat.com/show_bug.cgi?id=694630 for a
simple script.
Actual result:
--
Tested is using a 2 different virtual machines both running Fedora 14
x64. One
with php from yum, the other compiled.
gdb reports no backtrace and says there is `no stack`.
Apache 2.2 crashes, running php-cli too.
relevant strace output:
array(0) {
}
}
) = 1681
write(2, "zend_mm_heap corrupted\n", 23zend_mm_heap corrupted
) = 23
exit_group(1) = ?
Another one with sessions:
pwrite(3, "cart|a:1:{s:2:\"id\";C:7:\"MongoId\""..., 63, 0) = 63
close(3)= 0
close(4)= 0
write(2, "zend_mm_heap corrupted\n", 23zend_mm_heap corrupted
) = 23
exit_group(1)
It appears php is crashing at the end of the request just before
delivering the
content, when a database of some sort is used.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54491&edit=1
Bug #54506 [Bgs]: Regex Unicode problem
Edit report at http://bugs.php.net/bug.php?id=54506&edit=1 ID: 54506 User updated by:chsavio at gmail dot com Reported by:chsavio at gmail dot com Summary:Regex Unicode problem Status: Bogus Type: Bug Package:PCRE related Operating System: Centos 2.6.18 PHP Version:5.3SVN-2011-04-08 (snap) Block user comment: N Private report: N New Comment: Missed the PCRE modifiers section of the documentation. Sorry about that. Thanks for your time. Previous Comments: [2011-04-11 16:52:23] johan...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Use the /u modifier. [2011-04-11 16:39:27] chsavio at gmail dot com Description: Combinations of unicode characters in brackets appear to match a completely incorrect character. We're using PHP 5.3.3 (cli). And I was able to reproduce the problem on a PHP regex test site. http://www.pagecolumn.com/tool/pregtest.htm Test script: --- http://www.pagecolumn.com/tool/pregtest.htm Should be the equivalent of the following, but is not Expected result: I'd expect no matches. Array ( ) Actual result: -- I get a match. Array ( [0] => ø ) -- Edit this bug report at http://bugs.php.net/bug.php?id=54506&edit=1
Bug #49344 [Com]: pdo_mssql fails to connect,throws PDOException SQLSTATE[] (null) (severity 0)
Edit report at http://bugs.php.net/bug.php?id=49344&edit=1
ID: 49344
Comment by: tom at punkave dot com
Reported by:rockyjl at gmai dot com
Summary:pdo_mssql fails to connect,throws PDOException
SQLSTATE[] (null) (severity 0)
Status: No Feedback
Type: Bug
Package:PDO related
Operating System: win2003 X64
PHP Version:5.2.11RC1
Assigned To:felipe
Block user comment: N
Private report: N
New Comment:
Works with the command line tsql tool even though it does not work with
command
line PHP. Both using the FreeTDS that was installed on PHP's behalf.
Previous Comments:
[2011-04-11 18:47:33] tom at punkave dot com
Still experiencing this error. Tweaking freetds.conf:
[global]
# TDS protocol version
# Microsoft compatible we hope
tds version = 7.0
Had no effect.
PHP 5.3.5 (cli) (built: Jan 27 2011 11:42:56) on macports.
[2011-01-07 09:37:47] wrobel at wsb-nlu dot edu dot pl
It seems that the problem is solved by changing tds version to 7.0
instead of 8.0 in freetds configuration...
[2011-01-06 12:11:45] wrobel at wsb-nlu dot edu dot pl
I have the same problem when connecting: PDOException with message
SQLSTATE[] (null) (severity 0).
My environment is:
PHP 5.2.14
apache-2.2.16
Sql Server 2008 Express (and Sql Server 2008 R2)
Linux/PLD
[2009-10-09 18:56:19] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=289440
Log: - Possible fix for bug #49344 on Windows (pdo_mssql fails to
connect,throws PDOException SQLSTATE[] (null) (severity 0))
[2009-10-07 09:14:41] philipp at servicemail24 dot de
The same error occurs using Ubuntu 0910 with Zend Framework:
require_once('Zend/Db.php');
$db = Zend_Db::factory('Pdo_Mssql', array(
'host' => 'sqlsrv',
'username' => 'php',
'password' => 'secret',
'dbname' => 'myDatabase',
'pdoType' => 'dblib'
));
$result = $db->fetchAll(SELECT * FROM MyTable");
var_dump($result);
Zend_Db_Adapter_Exception: SQLSTATE[] (null) (severity 0) in
/usr/share/php/libzend-framework-php/Zend/Db/Adapter/Pdo/Abstract.php on
line 144
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=49344
--
Edit this bug report at http://bugs.php.net/bug.php?id=49344&edit=1
[PHP-BUG] Bug #54509 [NEW]: array_map fails with namespaces
From:
Operating system: Ubuntu 10.10
PHP version: 5.3SVN-2011-04-11 (SVN)
Package: Arrays related
Bug Type: Bug
Bug description:array_map fails with namespaces
Description:
Using php 5.3.3-1 array_map needs to have the namespace included in the
callback despite being called from within the same namespace.
This came up with OAuth.php. Example:
Test script:
---
namespace mynamespace;
class OAuthUtil {/*{{{*/
public static function urlencode_rfc3986($input) {/*{{{*/
if (is_array($input)) {
return array_map(array('OAuthUtil','urlencode_rfc3986'),
$input);
} else if (is_scalar($input)) {
return str_replace('+', ' ',
str_replace('%7E', '~', rawurlencode($input)));
} else {
return '';
}
}/*}}}*/
}
Expected result:
It should work the same as if the namespace were specified in the callback,
but it doesn't:
namespace mynamespace;
class OAuthUtil {/*{{{*/
public static function urlencode_rfc3986($input) {/*{{{*/
if (is_array($input)) {
return
array_map(array('\mynamespace\OAuthUtil','urlencode_rfc3986'),
$input);
} else if (is_scalar($input)) {
return str_replace('+', ' ',
str_replace('%7E', '~', rawurlencode($input)));
} else {
return '';
}
}/*}}}*/
}
Actual result:
--
It does not find the function that it should.
--
Edit bug report at http://bugs.php.net/bug.php?id=54509&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54509&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54509&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54509&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54509&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54509&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54509&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54509&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54509&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54509&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54509&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54509&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54509&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54509&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54509&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54509&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54509&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54509&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54509&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54509&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54509&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54509&r=mysqlcfg
[PHP-BUG] Bug #54508 [NEW]: mysqli: truncated floats
From: Operating system: Linux PHP version: 5.3.6 Package: MySQLi related Bug Type: Bug Bug description:mysqli: truncated floats Description: There's an inconsistency in behaviour between mysqli and PDO_MSYQL in the following SELECT, e.g., SELECT TRUNCATE(SUM(aFloatColumn),2) FROM aTable; Let's say the sum of the column is 42.001. With PDO_MYSQL, you'll get "42.00". But with MYSQLI, you'll instead get "42". Test script: --- http://bugs.php.net/bug.php?id=54508&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54508&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54508&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54508&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54508&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54508&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54508&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54508&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54508&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54508&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54508&r=support Expected behavior: http://bugs.php.net/fix.php?id=54508&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54508&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54508&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54508&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54508&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54508&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54508&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54508&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54508&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54508&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54508&r=mysqlcfg
Bug #49344 [Com]: pdo_mssql fails to connect,throws PDOException SQLSTATE[] (null) (severity 0)
Edit report at http://bugs.php.net/bug.php?id=49344&edit=1
ID: 49344
Comment by: tom at punkave dot com
Reported by:rockyjl at gmai dot com
Summary:pdo_mssql fails to connect,throws PDOException
SQLSTATE[] (null) (severity 0)
Status: No Feedback
Type: Bug
Package:PDO related
Operating System: win2003 X64
PHP Version:5.2.11RC1
Assigned To:felipe
Block user comment: N
Private report: N
New Comment:
Still experiencing this error. Tweaking freetds.conf:
[global]
# TDS protocol version
# Microsoft compatible we hope
tds version = 7.0
Had no effect.
PHP 5.3.5 (cli) (built: Jan 27 2011 11:42:56) on macports.
Previous Comments:
[2011-01-07 09:37:47] wrobel at wsb-nlu dot edu dot pl
It seems that the problem is solved by changing tds version to 7.0
instead of 8.0 in freetds configuration...
[2011-01-06 12:11:45] wrobel at wsb-nlu dot edu dot pl
I have the same problem when connecting: PDOException with message
SQLSTATE[] (null) (severity 0).
My environment is:
PHP 5.2.14
apache-2.2.16
Sql Server 2008 Express (and Sql Server 2008 R2)
Linux/PLD
[2009-10-09 18:56:19] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=289440
Log: - Possible fix for bug #49344 on Windows (pdo_mssql fails to
connect,throws PDOException SQLSTATE[] (null) (severity 0))
[2009-10-07 09:14:41] philipp at servicemail24 dot de
The same error occurs using Ubuntu 0910 with Zend Framework:
require_once('Zend/Db.php');
$db = Zend_Db::factory('Pdo_Mssql', array(
'host' => 'sqlsrv',
'username' => 'php',
'password' => 'secret',
'dbname' => 'myDatabase',
'pdoType' => 'dblib'
));
$result = $db->fetchAll(SELECT * FROM MyTable");
var_dump($result);
Zend_Db_Adapter_Exception: SQLSTATE[] (null) (severity 0) in
/usr/share/php/libzend-framework-php/Zend/Db/Adapter/Pdo/Abstract.php on
line 144
[2009-09-23 04:20:01] Rockyjl at gmail dot com
My Modification:
static int pdo_dblib_handle_factory(pdo_dbh_t *dbh, zval *driver_options
TSRMLS_DC)
{
pdo_dblib_db_handle *H;
int i, ret = 0;
char *location = " L=";
struct pdo_data_src_parser vars[] = {
{ "charset",NULL, 0 },
{ "appname","PHP " PDO_DBLIB_FLAVOUR, 0 },
{ "host", "127.0.0.1", 0 },
{ "dbname", NULL, 0 },
{ "secure", NULL, 0 }, /* DBSETLSECURE */
/* TODO: DBSETLVERSION ? */
};
php_pdo_parse_data_source(dbh->data_source, dbh->data_source_len, vars,
5);
H = pecalloc(1, sizeof(*H), dbh->is_persistent);
H->login = dblogin();
H->err.sqlstate = dbh->error_code;
if (!H->login) {
strcat(location, "login");
goto cleanup;
}
if (dbh->username) {
DBSETLUSER(H->login, dbh->username);
}
if (dbh->password) {
DBSETLPWD(H->login, dbh->password);
}
#if !PHP_DBLIB_IS_MSSQL
if (vars[0].optval) {
DBSETLCHARSET(H->login, vars[0].optval);
}
#endif
DBSETLAPP(H->login, vars[1].optval);
#if PHP_DBLIB_IS_MSSQL
dbprocerrhandle(H->login, (EHANDLEFUNC) error_handler);
dbprocmsghandle(H->login, (MHANDLEFUNC) msg_handler);
#endif
H->link = dbopen(H->login, vars[2].optval);
if (H->link == NULL) {
strcat(location, "link");
goto cleanup;
}
/* dblib do not return more than this length from text/image */
DBSETOPT(H->link, DBTEXTLIMIT, "2147483647");
/* limit text/image from network */
DBSETOPT(H->link, DBTEXTSIZE, "2147483647");
if (vars[3].optval && FAIL == dbuse(H->link, vars[3].optval)) {
strcat(location, "optval");
goto cleanup;
}
ret = 1;
dbh->max_escaped_char_length = 2;
dbh->alloc_own_columns = 1;
cleanup:
for (i = 0; i < sizeof(vars)/sizeof(vars[0]); i++) {
if (vars[i].freeme) {
efree(vars[i].optval);
}
}
dbh->methods = &dblib_methods;
dbh->driver_data = H;
if (!ret) {
zend_throw_exception_ex(
Bug #54403 [Com]: FILTER_VALIDATE_EMAIL
Edit report at http://bugs.php.net/bug.php?id=54403&edit=1
ID: 54403
Comment by: tomas dot brastavicius at quantum dot lt
Reported by:mariomaresca at hotmail dot it
Summary:FILTER_VALIDATE_EMAIL
Status: Bogus
Type: Bug
Package:Filter related
Operating System: windows 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Status of this issue should be changed to Feedback.
We are discussing whether email address ma...@mail.com is valid as per
RFC 2822, but the test script works as expected, i.e.
filter_var('ma...@mail.com', FILTER_VALIDATE_EMAIL) returns false.
I have checked this against 5.3.3 and the latest trunk, both on Linux.
Perhaps this is Windows specific bug ?
Previous Comments:
[2011-03-30 15:29:14] carsten_sttgt at gmx dot de
@aharvey
> That's a valid e-mail address: RFC 2822
According to RFC 2822 and this topic FILTER_VALIDATE_EMAIL is working
wrong ("ma...@mail.com" isn't a valid e-mail address, see the answer
from Tomas).
BTW:
FILTER_VALIDATE_EMAIL is working according to RFC2822? In the manual I
can't read which rules are used for validating e-mails.
[2011-03-29 16:28:49] dtajchre...@php.net
Once the expected/correct behavior is agreed upon, we should also add a
test case
for this. filter's behavior has been inconsistent across the last 10+
releases.
[2011-03-29 15:18:29] tomas dot brastavicius at quantum dot lt
It is not correct. Address contains no characters other than atext
characters or "." surrounded by atext.
dot-atom = [CFWS] dot-atom-text [CFWS]
dot-atom-text = 1*atext *("." 1*atext)
Reference, http://tools.ietf.org/html/rfc2822#section-3.2.4
[2011-03-29 11:41:10] ahar...@php.net
That's a valid e-mail address: RFC 2822 only requires the local part to
be a valid dot-atom, and dot-atom elements may end with a period.
[2011-03-27 19:29:56] mariomaresca at hotmail dot it
Description:
---
>From manual page: http://www.php.net/function.filter-var#Description
---
filter_var with FILTER_VALIDATE_EMAIL takes as good this malformed
email:
"ma...@mail.com"
Test script:
---
$email='ma...@mail.com';
if (filter_var($email, FILTER_VALIDATE_EMAIL))
echo '$email is good';
else
echo '$email is bad';
Expected result:
$email is bad
Actual result:
--
$email is good
--
Edit this bug report at http://bugs.php.net/bug.php?id=54403&edit=1
Bug #48539 [Com]: pdo_dblib fails to connect, throws empty PDOException "SQLSTATE[] (null)"
Edit report at http://bugs.php.net/bug.php?id=48539&edit=1
ID: 48539
Comment by: tom at punkave dot com
Reported by:frase at cs dot wisc dot edu
Summary:pdo_dblib fails to connect, throws empty
PDOException "SQLSTATE[] (null)"
Status: Closed
Type: Bug
Package:PDO related
Operating System: *
PHP Version:5.2.10, 5.3.0RC4
Assigned To:felipe
Block user comment: N
Private report: N
New Comment:
Did this fix ever get put in PHP 5.3? I am getting this error exactly as
originally described with all PHP 5.3.x versions tried.
Previous Comments:
[2009-06-28 02:10:33] 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 and HEAD.
5.3 in soon.
Thanks.
[2009-06-27 21:43:08] tilo at levante dot de
The following patch solved the issue in version 5.2.10
These three lines were added from version 5.2.9 to 5.2.10.
I use a ms sql 7 server, maybe this server is not able th set the
TEXTLIMIT to the given value.
Greetings
tilo
--- ext/pdo_dblib/dblib_driver.c.orig 2009-03-20 23:14:17.0
+0100
+++ ext/pdo_dblib/dblib_driver.c2009-06-28 01:50:50.0 +0200
@@ -230,9 +230,9 @@
goto cleanup;
}
- if (DBSETOPT(H->link, DBTEXTLIMIT, "2147483647") == FAIL) {
- goto cleanup;
- }
+// if (DBSETOPT(H->link, DBTEXTLIMIT, "2147483647") == FAIL) {
+// goto cleanup;
+// }
if (vars[3].optval && FAIL == dbuse(H->link, vars[3].optval)) {
goto cleanup;
[2009-06-25 16:57:52] nicholas dot j dot miller at gmail dot com
Our development team is seeing this problem in 5.2.10 as well.
[2009-06-19 16:58:52] thomas dot parrott at jellyfish dot co dot uk
This issue appears to be in 5.2.10 as well.
[2009-06-19 13:40:03] frase at cs dot wisc dot edu
This problem remains in RC4.
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=48539
--
Edit this bug report at http://bugs.php.net/bug.php?id=48539&edit=1
Bug #54403 [Bgs]: FILTER_VALIDATE_EMAIL
Edit report at http://bugs.php.net/bug.php?id=54403&edit=1
ID: 54403
User updated by:mariomaresca at hotmail dot it
Reported by:mariomaresca at hotmail dot it
Summary:FILTER_VALIDATE_EMAIL
Status: Bogus
Type: Bug
Package:Filter related
Operating System: windows 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Stop saying that's is a valid email.
Try to valid it with gmail.com Google will say [a-z]. isn't valid in any
case.
Previous Comments:
[2011-04-11 18:25:12] tomas dot brastavicius at quantum dot lt
Status of this issue should be changed to Feedback.
We are discussing whether email address ma...@mail.com is valid as per
RFC 2822, but the test script works as expected, i.e.
filter_var('ma...@mail.com', FILTER_VALIDATE_EMAIL) returns false.
I have checked this against 5.3.3 and the latest trunk, both on Linux.
Perhaps this is Windows specific bug ?
[2011-03-30 15:29:14] carsten_sttgt at gmx dot de
@aharvey
> That's a valid e-mail address: RFC 2822
According to RFC 2822 and this topic FILTER_VALIDATE_EMAIL is working
wrong ("ma...@mail.com" isn't a valid e-mail address, see the answer
from Tomas).
BTW:
FILTER_VALIDATE_EMAIL is working according to RFC2822? In the manual I
can't read which rules are used for validating e-mails.
[2011-03-29 16:28:49] dtajchre...@php.net
Once the expected/correct behavior is agreed upon, we should also add a
test case
for this. filter's behavior has been inconsistent across the last 10+
releases.
[2011-03-29 15:18:29] tomas dot brastavicius at quantum dot lt
It is not correct. Address contains no characters other than atext
characters or "." surrounded by atext.
dot-atom = [CFWS] dot-atom-text [CFWS]
dot-atom-text = 1*atext *("." 1*atext)
Reference, http://tools.ietf.org/html/rfc2822#section-3.2.4
[2011-03-29 11:41:10] ahar...@php.net
That's a valid e-mail address: RFC 2822 only requires the local part to
be a valid dot-atom, and dot-atom elements may end with a period.
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=54403
--
Edit this bug report at http://bugs.php.net/bug.php?id=54403&edit=1
Bug #54505 [Bgs]: Date("Y") for certain years returns incorrectly
Edit report at http://bugs.php.net/bug.php?id=54505&edit=1
ID: 54505
User updated by:josh dot reinert at gmail dot com
Reported by:josh dot reinert at gmail dot com
Summary:Date("Y") for certain years returns incorrectly
Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Windows 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Oh wow, sorry Derick. I miss interpreted the "weeks start on Monday" to
include the first of the year. As for what I am trying to do, our
company uses the weeks of the year to calculate the "Month's End". Our
weeks actually start on Sunday's and according to one of our Accountants
the first Sunday of the year is week 1. I apologize for submitting a
bad report. Thank you for the information.
Previous Comments:
[2011-04-11 16:58:44] der...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Uh, what are you trying to do here? The year is the ISO-year, and the W
an ISO-week number. Please read up on how that works here:
http://en.wikipedia.org/wiki/ISO_year#Relation_with_the_Gregorian_calendar
[2011-04-11 16:39:32] josh dot reinert at gmail dot com
Trying to modify the summary since it affects the year not just the
month
[2011-04-11 16:35:45] josh dot reinert at gmail dot com
Description:
I am actually running PHP 5.3.5 on Apache 2.2 on Windows 7 as my
development machine.
php.net states:
W ISO-8601 week number of year, weeks starting on Monday (added in PHP
4.1.0)
I have a calender class that I created that lists the weeks of the year
for a given month. For certain years when January 1st is not on Sunday
or Monday the date function is returning that it is still on the first
week of the year where if the weeks start on Monday it should be
returning the last week of the previous year. This then offsets the
rest of the year. I noticed it when I had a Dec. with week 54.
Test script:
---
for ($i=2000; $i<2040; $i++){
// Week of the Year
$WoY = (int) date("W", mktime(0, 0, 0, 1, 1, $i));
// Day of Jan 1st
$DoM = date("l", mktime(0, 0, 0, 1, 1, $i));
// If the week is 1 then the day must be either Sunday or Monday;
otherwise we are still in the previous year
if ($WoY == 1 && !($DoM == "Monday" || $DoM == "Sunday"))
print "$DoM Jan 1, $i is on week $WoY\n\n";
}
Expected result:
Actual result:
--
Tuesday Jan 1, 2002 is on week 1
Wednesday Jan 1, 2003 is on week 1
Thursday Jan 1, 2004 is on week 1
Tuesday Jan 1, 2008 is on week 1
Thursday Jan 1, 2009 is on week 1
Tuesday Jan 1, 2013 is on week 1
Wednesday Jan 1, 2014 is on week 1
Thursday Jan 1, 2015 is on week 1
Tuesday Jan 1, 2019 is on week 1
Wednesday Jan 1, 2020 is on week 1
Wednesday Jan 1, 2025 is on week 1
Thursday Jan 1, 2026 is on week 1
Tuesday Jan 1, 2030 is on week 1
Wednesday Jan 1, 2031 is on week 1
Thursday Jan 1, 2032 is on week 1
Tuesday Jan 1, 2036 is on week 1
Thursday Jan 1, 2037 is on week 1
Wednesday Jan 1, 2039 is on week 1
--
Edit this bug report at http://bugs.php.net/bug.php?id=54505&edit=1
[PHP-BUG] Req #54507 [NEW]: [PATCH] Allow openssl compiled without SSLv2 support
From: Operating system: all PHP version: 5.3SVN-2011-04-11 (SVN) Package: OpenSSL related Bug Type: Feature/Change Request Bug description:[PATCH] Allow openssl compiled without SSLv2 support Description: the attached patch allows the openSSL extension to be used with the library compiled without SSLv2 Test script: --- --- Expected result: --- Actual result: -- --- -- Edit bug report at http://bugs.php.net/bug.php?id=54507&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54507&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54507&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54507&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54507&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54507&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54507&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54507&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54507&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54507&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54507&r=support Expected behavior: http://bugs.php.net/fix.php?id=54507&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54507&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54507&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54507&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54507&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54507&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54507&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54507&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54507&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54507&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54507&r=mysqlcfg
Bug #54505 [Opn->Bgs]: Date("Y") for certain years returns incorrectly
Edit report at http://bugs.php.net/bug.php?id=54505&edit=1
ID: 54505
Updated by: der...@php.net
Reported by:josh dot reinert at gmail dot com
Summary:Date("Y") for certain years returns incorrectly
-Status: Open
+Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Windows 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Uh, what are you trying to do here? The year is the ISO-year, and the W
an ISO-week number. Please read up on how that works here:
http://en.wikipedia.org/wiki/ISO_year#Relation_with_the_Gregorian_calendar
Previous Comments:
[2011-04-11 16:39:32] josh dot reinert at gmail dot com
Trying to modify the summary since it affects the year not just the
month
[2011-04-11 16:35:45] josh dot reinert at gmail dot com
Description:
I am actually running PHP 5.3.5 on Apache 2.2 on Windows 7 as my
development machine.
php.net states:
W ISO-8601 week number of year, weeks starting on Monday (added in PHP
4.1.0)
I have a calender class that I created that lists the weeks of the year
for a given month. For certain years when January 1st is not on Sunday
or Monday the date function is returning that it is still on the first
week of the year where if the weeks start on Monday it should be
returning the last week of the previous year. This then offsets the
rest of the year. I noticed it when I had a Dec. with week 54.
Test script:
---
for ($i=2000; $i<2040; $i++){
// Week of the Year
$WoY = (int) date("W", mktime(0, 0, 0, 1, 1, $i));
// Day of Jan 1st
$DoM = date("l", mktime(0, 0, 0, 1, 1, $i));
// If the week is 1 then the day must be either Sunday or Monday;
otherwise we are still in the previous year
if ($WoY == 1 && !($DoM == "Monday" || $DoM == "Sunday"))
print "$DoM Jan 1, $i is on week $WoY\n\n";
}
Expected result:
Actual result:
--
Tuesday Jan 1, 2002 is on week 1
Wednesday Jan 1, 2003 is on week 1
Thursday Jan 1, 2004 is on week 1
Tuesday Jan 1, 2008 is on week 1
Thursday Jan 1, 2009 is on week 1
Tuesday Jan 1, 2013 is on week 1
Wednesday Jan 1, 2014 is on week 1
Thursday Jan 1, 2015 is on week 1
Tuesday Jan 1, 2019 is on week 1
Wednesday Jan 1, 2020 is on week 1
Wednesday Jan 1, 2025 is on week 1
Thursday Jan 1, 2026 is on week 1
Tuesday Jan 1, 2030 is on week 1
Wednesday Jan 1, 2031 is on week 1
Thursday Jan 1, 2032 is on week 1
Tuesday Jan 1, 2036 is on week 1
Thursday Jan 1, 2037 is on week 1
Wednesday Jan 1, 2039 is on week 1
--
Edit this bug report at http://bugs.php.net/bug.php?id=54505&edit=1
Bug #54506 [Opn->Bgs]: Regex Unicode problem
Edit report at http://bugs.php.net/bug.php?id=54506&edit=1 ID: 54506 Updated by: johan...@php.net Reported by:chsavio at gmail dot com Summary:Regex Unicode problem -Status: Open +Status: Bogus Type: Bug Package:PCRE related Operating System: Centos 2.6.18 PHP Version:5.3SVN-2011-04-08 (snap) Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Use the /u modifier. Previous Comments: [2011-04-11 16:39:27] chsavio at gmail dot com Description: Combinations of unicode characters in brackets appear to match a completely incorrect character. We're using PHP 5.3.3 (cli). And I was able to reproduce the problem on a PHP regex test site. http://www.pagecolumn.com/tool/pregtest.htm Test script: --- http://www.pagecolumn.com/tool/pregtest.htm Should be the equivalent of the following, but is not Expected result: I'd expect no matches. Array ( ) Actual result: -- I get a match. Array ( [0] => ø ) -- Edit this bug report at http://bugs.php.net/bug.php?id=54506&edit=1
Bug #54505 [Opn]: Date("Y") for certain years returns incorrectly
Edit report at http://bugs.php.net/bug.php?id=54505&edit=1
ID: 54505
User updated by:josh dot reinert at gmail dot com
Reported by:josh dot reinert at gmail dot com
-Summary:Date("Y") for Dec returns incorrectly
+Summary:Date("Y") for certain years returns incorrectly
Status: Open
Type: Bug
Package:Date/time related
Operating System: Windows 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Trying to modify the summary since it affects the year not just the
month
Previous Comments:
[2011-04-11 16:35:45] josh dot reinert at gmail dot com
Description:
I am actually running PHP 5.3.5 on Apache 2.2 on Windows 7 as my
development machine.
php.net states:
W ISO-8601 week number of year, weeks starting on Monday (added in PHP
4.1.0)
I have a calender class that I created that lists the weeks of the year
for a given month. For certain years when January 1st is not on Sunday
or Monday the date function is returning that it is still on the first
week of the year where if the weeks start on Monday it should be
returning the last week of the previous year. This then offsets the
rest of the year. I noticed it when I had a Dec. with week 54.
Test script:
---
for ($i=2000; $i<2040; $i++){
// Week of the Year
$WoY = (int) date("W", mktime(0, 0, 0, 1, 1, $i));
// Day of Jan 1st
$DoM = date("l", mktime(0, 0, 0, 1, 1, $i));
// If the week is 1 then the day must be either Sunday or Monday;
otherwise we are still in the previous year
if ($WoY == 1 && !($DoM == "Monday" || $DoM == "Sunday"))
print "$DoM Jan 1, $i is on week $WoY\n\n";
}
Expected result:
Actual result:
--
Tuesday Jan 1, 2002 is on week 1
Wednesday Jan 1, 2003 is on week 1
Thursday Jan 1, 2004 is on week 1
Tuesday Jan 1, 2008 is on week 1
Thursday Jan 1, 2009 is on week 1
Tuesday Jan 1, 2013 is on week 1
Wednesday Jan 1, 2014 is on week 1
Thursday Jan 1, 2015 is on week 1
Tuesday Jan 1, 2019 is on week 1
Wednesday Jan 1, 2020 is on week 1
Wednesday Jan 1, 2025 is on week 1
Thursday Jan 1, 2026 is on week 1
Tuesday Jan 1, 2030 is on week 1
Wednesday Jan 1, 2031 is on week 1
Thursday Jan 1, 2032 is on week 1
Tuesday Jan 1, 2036 is on week 1
Thursday Jan 1, 2037 is on week 1
Wednesday Jan 1, 2039 is on week 1
--
Edit this bug report at http://bugs.php.net/bug.php?id=54505&edit=1
[PHP-BUG] Bug #54506 [NEW]: Regex Unicode problem
From: Operating system: Centos 2.6.18 PHP version: 5.3SVN-2011-04-08 (snap) Package: PCRE related Bug Type: Bug Bug description:Regex Unicode problem Description: Combinations of unicode characters in brackets appear to match a completely incorrect character. We're using PHP 5.3.3 (cli). And I was able to reproduce the problem on a PHP regex test site. http://www.pagecolumn.com/tool/pregtest.htm Test script: --- http://www.pagecolumn.com/tool/pregtest.htm Should be the equivalent of the following, but is not Expected result: I'd expect no matches. Array ( ) Actual result: -- I get a match. Array ( [0] => ø ) -- Edit bug report at http://bugs.php.net/bug.php?id=54506&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54506&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54506&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54506&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54506&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54506&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54506&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54506&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54506&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54506&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54506&r=support Expected behavior: http://bugs.php.net/fix.php?id=54506&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54506&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54506&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54506&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54506&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54506&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54506&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54506&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54506&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54506&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54506&r=mysqlcfg
[PHP-BUG] Bug #54505 [NEW]: Date("Y") for Dec returns incorrectly
From:
Operating system: Windows 7
PHP version: 5.3.6
Package: Date/time related
Bug Type: Bug
Bug description:Date("Y") for Dec returns incorrectly
Description:
I am actually running PHP 5.3.5 on Apache 2.2 on Windows 7 as my
development machine.
php.net states:
W ISO-8601 week number of year, weeks starting on Monday (added in PHP
4.1.0)
I have a calender class that I created that lists the weeks of the year for
a given month. For certain years when January 1st is not on Sunday or
Monday the date function is returning that it is still on the first week of
the year where if the weeks start on Monday it should be returning the last
week of the previous year. This then offsets the rest of the year. I
noticed it when I had a Dec. with week 54.
Test script:
---
for ($i=2000; $i<2040; $i++){
// Week of the Year
$WoY = (int) date("W", mktime(0, 0, 0, 1, 1, $i));
// Day of Jan 1st
$DoM = date("l", mktime(0, 0, 0, 1, 1, $i));
// If the week is 1 then the day must be either Sunday or Monday;
otherwise we are still in the previous year
if ($WoY == 1 && !($DoM == "Monday" || $DoM == "Sunday"))
print "$DoM Jan 1, $i is on week $WoY\n\n";
}
Expected result:
Actual result:
--
Tuesday Jan 1, 2002 is on week 1
Wednesday Jan 1, 2003 is on week 1
Thursday Jan 1, 2004 is on week 1
Tuesday Jan 1, 2008 is on week 1
Thursday Jan 1, 2009 is on week 1
Tuesday Jan 1, 2013 is on week 1
Wednesday Jan 1, 2014 is on week 1
Thursday Jan 1, 2015 is on week 1
Tuesday Jan 1, 2019 is on week 1
Wednesday Jan 1, 2020 is on week 1
Wednesday Jan 1, 2025 is on week 1
Thursday Jan 1, 2026 is on week 1
Tuesday Jan 1, 2030 is on week 1
Wednesday Jan 1, 2031 is on week 1
Thursday Jan 1, 2032 is on week 1
Tuesday Jan 1, 2036 is on week 1
Thursday Jan 1, 2037 is on week 1
Wednesday Jan 1, 2039 is on week 1
--
Edit bug report at http://bugs.php.net/bug.php?id=54505&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54505&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54505&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54505&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54505&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54505&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54505&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54505&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54505&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54505&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54505&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54505&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54505&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54505&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54505&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54505&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54505&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54505&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54505&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54505&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54505&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54505&r=mysqlcfg
Bug #54470 [Com]: array_walk_recursive corruption
Edit report at http://bugs.php.net/bug.php?id=54470&edit=1
ID: 54470
Comment by: RQuadling at GMail dot com
Reported by:RQuadling at GMail dot com
Summary:array_walk_recursive corruption
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Windows XP SP3
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
This seems to be fixes now via http://svn.php.net/viewvc?
view=revision&sortby=file&revision=310050
Previous Comments:
[2011-04-05 15:33:03] RQuadling at GMail dot com
Description:
I'm getting the crash in 5.3.6 and 5.3.7-dev from SVN.
The initial code was part of an exception handler and its purpose was to
generate a nicely formatted plain-text message to be emailed to me when
there
was an exception.
I've reduced the code to the following example. No extensions required.
Tested with 5.3.0 - 5.3.5 - all working fine.
Tested with 5.3.6 and my own build 5.3.7-dev - crash.
The specifics of this code is to take an array (a stripped down stack
trace),
and pad the elements so that they can be written out in a "table"
format, all
nicely
vertically aligned.
The crash comes during shutdown, not whilst running my code.
Depending upon the amount of additional code, I can either get corrupted
output
or a crash.
The "Expected result" below is for PHP 5.3.5 and the "Actual result"
below is
for PHP 5.3.6. Both are the official builds with no php.ini loaded.
The current example just outputs corrupted data.
Adding more code often results in an access violation.
Test script:
---
7, 'age' => 2);
echo 'Widths within ', __FUNCTION__, ' before array_walk_recursive ',
var_export($widths, True), PHP_EOL;
$b_Result = array_walk_recursive($data, function(&$value, $key)
use($widths, $alignments) {
$value = str_pad($value, $widths[$key], ' ',
isset($alignments[$key])
? $alignments[$key] : STR_PAD_RIGHT);
});
echo 'Widths within ', __FUNCTION__, ' after array_walk_recursive ',
var_export($widths, True), PHP_EOL;
return $b_Result;
}
$alignments = array('age' => STR_PAD_LEFT); // Force the age to be right
aligned.
$data = array( // A list of names and ages.
array('name' => 'Richard', 'age' => 43,),
array('name' => 'Oscar', 'age' => 2,),
);
arrayPad($data, $alignments, $widths);
echo 'The data ', var_export($data, True), PHP_EOL, 'The alignments ',
var_export($alignments, True), PHP_EOL, 'The widths returned by arrayPad
', var_export($widths, True);
Expected result:
php-5.3.5\php -n -f err_001.php
Widths within arrayPad before array_walk_recursive array (
'name' => 7,
'age' => 2,
)
Widths within arrayPad after array_walk_recursive array (
'name' => 7,
'age' => 2,
)
The data array (
0 =>
array (
'name' => 'Richard',
'age' => '43',
),
1 =>
array (
'name' => 'Oscar ',
'age' => ' 2',
),
)
The alignments array (
'age' => 0,
)
The widths returned by arrayPad array (
'name' => 7,
'age' => 2,
)
Actual result:
--
php-5.3.6\php -n -f err_001.php
Widths within arrayPad before array_walk_recursive array (
'name' => 7,
'age' => 2,
)
Widths within arrayPad after array_walk_recursive ! 1
ââ¨â²âºâº â¥
â ! Rich
The data array (
0 =>
array (
'name' => 'Richard',
'age' => '43',
),
1 =>
array (
'name' => 'Oscar ',
'age' => ' 2',
),
)
The alignments array (
'age' => 0,
)
The widths returned by arrayPad array (
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=54470&edit=1
Bug #54501 [Opn->Bgs]: event_buffer_write from libevent dont work in a forked process
Edit report at http://bugs.php.net/bug.php?id=54501&edit=1
ID: 54501
Updated by: ahar...@php.net
Reported by:fireangel_info at yahoo dot com
Summary:event_buffer_write from libevent dont work in a
forked process
-Status: Open
+Status: Bogus
Type: Bug
Package:PCNTL related
Operating System: Debian-60-squeeze-64-minimal
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Please report bugs in PECL packages on the PECL bug tracker; in this
case, at http://pecl.php.net/bugs/report.php?package=event
Previous Comments:
[2011-04-10 02:42:18] fireangel_info at yahoo dot com
Description:
---
>From manual page: http://www.php.net/function.event-buffer-write#Return
Values
---
// event_buffer_write($buffer,'asdawdasd'); <== here it will send the
'asdawdasd'
$pid = pcntl_fork();
switch ($pid) {
case -1: // Error
die('Fork failed');
break;
case 0: // Child
$thispid=posix_getpid();
event_buffer_write($buffer,'asdawdasd');// $buffer is a valid
connection/ <== here it will NOT send the 'asdawdasd'
posix_kill($thispid, 9);
break;
}
/*
$buffer resource is transmited to the child but event_buffer_write wont
run.
*/
--
Edit this bug report at http://bugs.php.net/bug.php?id=54501&edit=1
Bug #50410 [Com]: curl extension slows down PHP
Edit report at http://bugs.php.net/bug.php?id=50410&edit=1 ID: 50410 Comment by: threedigitnumber at gmail dot com Reported by:procyonar at gmail dot com Summary:curl extension slows down PHP Status: Closed Type: Bug Package:cURL related Operating System: win32 only - Windows 7 PHP Version:* Assigned To:pajoye Block user comment: N Private report: N New Comment: My tests indicate that something is still going on with 5.3.6: tanguy's ssleay fixes the issue. Previous Comments: [2011-04-11 11:08:35] paj...@php.net 5.3.6's does not use rand_screen anymore and any version of libcurl after this date either. [2011-04-11 07:42:14] tanguy at pruvot dot tk arf, link was truncated : http://tanguy.tk/?q=content/php-535-correctif-lenteur-au-chargement-de-phpcurl [2011-04-11 05:39:10] tanguy at pruvot dot tk You can download the patched libeay here (work for all PHP versions) : http://tanguy.wdscript.fr/index.php?q=content/php-535-correctif-lenteur-au- chargement-de-phpcurl [2011-04-11 05:29:56] threedigitnumber at gmail dot com Still not solved with 5.36. In CLI Mode with curl: php -v takes 1.15 seconds. without curl: php -v takes 0.125 seconds. [2010-12-20 00:47:59] tanguy dot pruvot at gmail dot com Please reopen this issue... "php -m" with php_curl : 3 seconds on a SSD disk "php -m" without curl : instant output Please read the previous answers, seems related to libeay32 ... 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=50410 -- Edit this bug report at http://bugs.php.net/bug.php?id=50410&edit=1
Bug #50410 [Csd]: curl extension slows down PHP
Edit report at http://bugs.php.net/bug.php?id=50410&edit=1 ID: 50410 Updated by: paj...@php.net Reported by:procyonar at gmail dot com Summary:curl extension slows down PHP Status: Closed Type: Bug Package:cURL related Operating System: win32 only - Windows 7 PHP Version:* Assigned To:pajoye Block user comment: N Private report: N New Comment: 5.3.6's does not use rand_screen anymore and any version of libcurl after this date either. Previous Comments: [2011-04-11 07:42:14] tanguy at pruvot dot tk arf, link was truncated : http://tanguy.tk/?q=content/php-535-correctif-lenteur-au-chargement-de-phpcurl [2011-04-11 05:39:10] tanguy at pruvot dot tk You can download the patched libeay here (work for all PHP versions) : http://tanguy.wdscript.fr/index.php?q=content/php-535-correctif-lenteur-au- chargement-de-phpcurl [2011-04-11 05:29:56] threedigitnumber at gmail dot com Still not solved with 5.36. In CLI Mode with curl: php -v takes 1.15 seconds. without curl: php -v takes 0.125 seconds. [2010-12-20 00:47:59] tanguy dot pruvot at gmail dot com Please reopen this issue... "php -m" with php_curl : 3 seconds on a SSD disk "php -m" without curl : instant output Please read the previous answers, seems related to libeay32 ... [2010-12-13 12:41:47] beta dot tests at hotmail dot com On the binaries and sources releases for windows i hope that this PHP 5.3 (5.3.4) isnt the final relese because i once i install the cURL is see a delay of at least 700ms to 1020ms, on windows xp 32bit using FastCGI 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=50410 -- Edit this bug report at http://bugs.php.net/bug.php?id=50410&edit=1
Req #54473 [Opn]: PATCH: openssl extension should also load engines
Edit report at http://bugs.php.net/bug.php?id=54473&edit=1 ID: 54473 Updated by: cataphr...@php.net Reported by:crrodriguez at opensuse dot org Summary:PATCH: openssl extension should also load engines Status: Open Type: Feature/Change Request Package:OpenSSL related Operating System: all PHP Version:5.3SVN-2011-04-05 (SVN) Block user comment: N Private report: N New Comment: Reading the docs, it would appear ENGINE_cleanup() should be called on shutdown. Previous Comments: [2011-04-05 23:39:16] crrodriguez at opensuse dot org Description: Currently openssl allows hardware engines to be used, which are usually much faster than the library itself, but PHP does not currently load them if available at Module init.. This is more important now that when openssl is used with new Intel CPUs, it can use AES_NI instruction sets. The attached patch fixes the problem. Test script: --- -- Expected result: engines loaded at MINIT Actual result: -- Not currently loaded. -- Edit this bug report at http://bugs.php.net/bug.php?id=54473&edit=1
