date:20120705

Bug #62335 [Com]: zlib conflict with gzhandler

2012-07-05 Thread dietmar at gps-tour dot info

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

 ID: 62335
 Comment by: dietmar at gps-tour dot info
 Reported by:hajo at csphere dot eu
 Summary:zlib conflict with gzhandler
 Status: Open
 Type:   Bug
 Package:Zlib related
 Operating System:   Windows 7
 PHP Version:5.4.4
 Block user comment: N
 Private report: N

 New Comment:

Hi,
the Bug was fixed by Mike in this commit:
http://git.php.net/?p=php-
src.git;a=commit;h=85a62e9086db7a8ddfcda4ab1279a2439935f8d5

On the 15th of May, the following commit by mike removed the added line by the 
above commit:
http://git.php.net/?p=php-
src.git;a=commitdiff;h=0ad53bfd7da12a92a46c08e3fff579a15026b88b

I'not shure, if this was realy intended... So maybe mike can take over this 
ticket... Would be great, to have a working ob_gzhandler again in 5.4


Previous Comments:

[2012-06-21 13:09:17] php at lippe-net dot de

The Error is still there in Debians php 5.4.5-dev.


[2012-06-21 11:57:43] v dot a dot popov at gmail dot com

Seems to be a problem in merging the fix to actual branch, which releases are 
made of.
This commit:
http://git.php.net/?p=php-src.git;a=commit;h=85a62e9086db7a8ddfcda4ab1279a2439935f8d5
really fixes the problem, but relevant line is not present in php-5.4.3 and 
php-5.4.4.


[2012-06-18 13:39:29] hajo at csphere dot eu

bug 55544 is about this issue, too. between stable php 5.4.0 and 5.4.3 it was 
fixed and seems to fail again now.


[2012-06-15 16:31:45] mtanalin at yandex dot ru

Same error for me with this code:

ob_start('ob_gzhandler');

Windows 7, Apache 2.4, PHP 5.4.4 thread-safe, "zlib.output_compression" is set 
to "off" in php.ini.

The bug disappears if I add "php_flag zlib.output_compression off" in .htaccess 
file of specific host. So, probably, the bug is that global (from php.ini) 
"zlib.output_compression=off" setting is just _ignored_ in PHP 5.4.4.


[2012-06-15 14:50:54] hajo at csphere dot eu

update: the issue always starts on first refresh, so it might be caused by the 
fix for bug 60761, just guessing.




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

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


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

Bug #62467 [Opn->Wfx]: SimpleXML memory usage is not reported by memory_get_usage()

2012-07-05 Thread cataphract

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

 ID: 62467
 Updated by: cataphr...@php.net
 Reported by:zerkyn at gmail dot com
 Summary:SimpleXML memory usage is not reported by
 memory_get_usage()
-Status: Open
+Status: Wont fix
 Type:   Bug
 Package:SimpleXML related
 Operating System:   Windows, Linux
 PHP Version:5.3.14
 Block user comment: N
 Private report: N

 New Comment:

This can't be fixed; PHP doesn't control the way libxml2 does the allocations.


Previous Comments:

[2012-07-02 19:45:46] zerkyn at gmail dot com

Description:

When using SimpleXML functions to load XML data, the memory consumption is not 
tracked internally by PHP. 

Calling the "memory_get_usage()", you can see only a light memory consumption 
increase, which is clearly not an appropriate value for the document loaded (it 
is easily seen on a big documents, e.g. 1Mb+). However, the proper memory 
increase is observed by using system tools ('tasklist /FI "PID eq ..."' under 
Windows, 'ps' under Linux).

The issue affects profiling scripts, which are not able to fulfill their role. 
And it affects 'memory_limit' setting, which doesn't control application 
memory, consumed by SimpleXML.

Test script:
---
https://bugs.php.net/bug.php?id=62467&edit=1

Bug #62481 [Opn->Fbk]: xdebug openssl_encrypt crash

2012-07-05 Thread pajoye

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

 ID: 62481
 Updated by: paj...@php.net
 Reported by:bronze1man at gmail dot com
 Summary:xdebug openssl_encrypt crash
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:OpenSSL related
 Operating System:   ubuntu 1204
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

I'd to ask to try your code with a vanilla PHP version, either latest 5.3 or 
latest 5.4, without suhosin patch, as we can't reproduce this issue.


Previous Comments:

[2012-07-05 01:10:13] bronze1man at gmail dot com

sorry,php version is 5.3.10


[2012-07-04 15:08:58] a...@php.net

You wrote 5.3.14 in the ticket, but 5.3.10 in the description ... what is 
correct?

On 5.3.10-dotdeb it segfaults for me without xdebug too. With the 5.3.15-dev 
there are no issues with or without xdebug for me. Can you confirm that?


[2012-07-04 13:53:04] bronze1man at gmail dot com

Description:

start xdebug openssl_encrypt an empty string ,then it will crash.

php version:
PHP 5.3.10-1ubuntu3.2 with Suhosin-Patch (cli) (built: Jun 13 2012 17:20:55) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans


Test script:
---
https://bugs.php.net/bug.php?id=62481&edit=1

Bug #62476 [Com]: DateTime::createFromFormat z format incorrect wrt 29.02

2012-07-05 Thread Sjon at hortensius dot net

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

 ID: 62476
 Comment by: Sjon at hortensius dot net
 Reported by:kaido at tradenet dot ee
 Summary:DateTime::createFromFormat z format incorrect wrt
 29.02
 Status: Open
 Type:   Bug
 Package:Calendar related
 Operating System:   debian 2.6.32-5-amd64
 PHP Version:5.4.4
 Block user comment: N
 Private report: N

 New Comment:

I can confirm this, this is broken since 5.3.9

http://3v4l.org/1Z4W4


Previous Comments:

[2012-07-04 00:20:58] kaido at tradenet dot ee

Description:

When creating DateTime object from string and using z (day of year) format 
option, 
the 29.02 of the leap year is missing. works ok in 5.3.5

Test script:
---
for ($d=55;$d<65;$d++) {
$dt = DateTime::createFromFormat ('z.Y', $d.'.2012');
$dd = $dt->format ('d.m.Y');
echo "$d $dd\n";
}

29.02.2012 is clearly missing .. 

Expected result:

55 25.02.2012
56 26.02.2012
57 27.02.2012
58 28.02.2012
59 29.02.2012
60 01.03.2012
61 02.03.2012
62 03.03.2012
63 04.03.2012
64 05.03.2012

Actual result:
--
55 25.02.2012
56 26.02.2012
57 27.02.2012
58 28.02.2012
59 01.03.2012
60 02.03.2012
61 03.03.2012
62 04.03.2012
63 05.03.2012
64 06.03.2012






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

Bug #62468 [Com]: SimpleXML memory leak, if circular references are removed by Garbage Collector

2012-07-05 Thread Sjon at hortensius dot net

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

 ID: 62468
 Comment by: Sjon at hortensius dot net
 Reported by:zerkyn at gmail dot com
 Summary:SimpleXML memory leak, if circular references are
 removed by Garbage Collector
 Status: Open
 Type:   Bug
 Package:SimpleXML related
 Operating System:   Windows 7, Linux
 PHP Version:5.3.14
 Block user comment: N
 Private report: N

 New Comment:

I can confirm this, but it has already been fixed in PHP 5.4. I assume this is 
because of the circular references that were fixed then.

http://3v4l.org/JICRi


Previous Comments:

[2012-07-02 20:13:45] zerkyn at gmail dot com

Description:

The SimpleXMLElement memory leaks, when:
1) An object holds reference to a SimpleXMLElement, and
2) The object is involved in a circular references net, and
3) All external references to that net are cleared, so Garbage Collector finds 
that net, correctly sees it as a garbage cycle, and cleans all its objects

After the Garbage Collector finishes its work, the memory, consumed by 
SimpleXMLElement is not freed, thus producing a memory leak.

The issue is reproduced both at Windows and Linux platforms.

Full version for the test script is there: 
https://dl.dropbox.com/u/17950262/php/issues/simplexml_memory_leak.zip


Test script:
---
xml = simplexml_load_file('pretty_big_file_of_1mb_size.xml');
$this->me = $this;
}
}

echo "Sys memory usage before: ", SystemMemoryUsage(), "\n";

for ($i = 0; $i < 1000; $i++) {
$a = new SelfLinked();
unset($a);
gc_collect_cycles();
}

echo "Sys memory usage after: ", SystemMemoryUsage(), "\n";

/** - */
function SystemMemoryUsage() 
{
... 
// Return memory consumption by executing system tool - tasklist, ps or 
anything else
// See https://bugs.php.net/bug.php?id=62467 on proper memory profiling of 
SimpleXML functions
}
}

Expected result:

Memory consumption does not change.

Actual result:
--
Huge increase of memory consumption is reported.






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

Bug #60882 [Com]: PDO crashes PHP FastCGI daemon when querying Sphinx server

2012-07-05 Thread vitalif at yourcmc dot ru

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

 ID: 60882
 Comment by: vitalif at yourcmc dot ru
 Reported by:balshoy dot tone at gmail dot com
 Summary:PDO crashes PHP FastCGI daemon when querying Sphinx
 server
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   Ubuntu 11.10
 PHP Version:5.4.0RC6
 Block user comment: N
 Private report: N

 New Comment:

I've discovered what's the error is using gdb - MysqlND can't determine the 
charset when connecting to Sphinx, because it skips authentication.

So the workaround is very simple - add ";charset=utf8" to your DSN.
Like the following:
$dsn = "mysql:host=127.0.0.1;port=9306;dbname=index;charset=utf8";

+ just for the information, stack trace of php crash:
Program received signal SIGSEGV, Segmentation fault.
mysqlnd_cset_escape_slashes (cset=0x0, newstr=0x7f5521562ce1 "", 
escapestr=0x7f552146d438 "Ð¼Ð°Ð¹ÐºÐ°", escapestr_len=)
at /home/pspesivt/setup/php-5.4.4/ext/mysqlnd/mysqlnd_charset.c:719
719 if (cset->char_maxlen > 1 && (len = 
cset->mb_valid(escapestr, end))) {
(gdb) bt
#0  mysqlnd_cset_escape_slashes (cset=0x0, newstr=0x7f5521562ce1 "", 
escapestr=0x7f552146d438 "Ð¼Ð°Ð¹ÐºÐ°", escapestr_len=)
at /home/pspesivt/setup/php-5.4.4/ext/mysqlnd/mysqlnd_charset.c:719
#1  0x00765e41 in php_mysqlnd_conn_data_escape_string_pub 
(conn=0x7f5521562238, newstr=0x7f5521562ce1 "", escapestr=0x7f552146d438 
"Ð¼Ð°Ð¹ÐºÐ°", escapestr_len=10)
at /home/pspesivt/setup/php-5.4.4/ext/mysqlnd/mysqlnd.c:1470
#2  0x005fe5dd in mysql_handle_quoter (dbh=, 
unquoted=0x7f552146d438 "Ð¼Ð°Ð¹ÐºÐ°", unquotedlen=10, quoted=0x2aa2368, 
quotedlen=0x2aa2360, 
paramtype=) at 
/home/pspesivt/setup/php-5.4.4/ext/pdo_mysql/mysql_driver.c:309
#3  0x005fdb08 in pdo_parse_params (stmt=0x7f55215628d8, 
inquery=0x7f552155f278 "SELECT id, WEIGHT() rank FROM sportmaster_catalog 
WHERE MATCH(:query) LIMIT 1000", inquery_len=44704592, outquery=0x7f5521562968, 
outquery_len=0x7f5521562970) at 
/home/pspesivt/setup/php-5.4.4/ext/pdo/pdo_sql_parser.c:584
#4  0x005fb2bb in zim_PDOStatement_execute (ht=, 
return_value=0x2aa2298, return_value_ptr=, 
this_ptr=, return_value_used=) at 
/home/pspesivt/setup/php-5.4.4/ext/pdo/pdo_stmt.c:497
#5  0x7f5510e9e58f in xdebug_execute_internal 
(current_execute_data=0x7f55215265d8, return_value_used=0) at 
/home/pspesivt/setup/xdebug-2.2.0/xdebug.c:1482
#6  0x0085ee56 in zend_do_fcall_common_helper_SPEC (execute_data=) at /home/pspesivt/setup/php-5.4.4/Zend/zend_vm_execute.h:644
#7  0x0084c280 in execute (op_array=0x7f552155d518) at 
/home/pspesivt/setup/php-5.4.4/Zend/zend_vm_execute.h:410
#8  0x7f5510e9eaa9 in xdebug_execute (op_array=0x7f552155d518) at 
/home/pspesivt/setup/xdebug-2.2.0/xdebug.c:1390
#9  0x007e33ff in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /home/pspesivt/setup/php-5.4.4/Zend/zend.c:1279
#10 0x00786b47 in php_execute_script (primary_file=0x7fff91c803f0) at 
/home/pspesivt/setup/php-5.4.4/main/main.c:2473
#11 0x00896159 in main (argc=559047608, argv=0x7f55215264e0) at 
/home/pspesivt/setup/php-5.4.4/sapi/fpm/fpm/fpm_main.c:1856


Previous Comments:

[2012-01-25 14:01:00] balshoy dot tone at gmail dot com

Description:

I have a sphinx server with real time indexes and I'm trying to query them 
using 
PDO via sphinx MySQL protocol.

Every time a script runs into `$pdo->execute(array(1))` part the whole PHP 
FastCGI daemon crashes, no errors displayed in php error log.

Everything works normally when I query ordinary MySQL database this way.
Also provided code works fine in PHP 5.3

Test script:
---
$dsn = "mysql:host=127.0.0.1;port=9306;dbname=index";
$pdo = new PDO($dsn, '', ''); 

$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

$stmt = $pdo->prepare("SELECT * FROM user WHERE id = ?"); 
$rslt = $stmt->execute(array(1)); // crash

var_dump($stmt->fetchAll(PDO::FETCH_ASSOC));

Expected result:

Either result set or PDO exception should be displayed.

Actual result:
--
Script fails silently without any records in error.log
Also PHP FastCGI daemon gets terminated.






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

Bug #62023 [Com]: [sapi/cli/php] Error 1

2012-07-05 Thread xin3n at yahoo dot com

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

 ID: 62023
 Comment by: xin3n at yahoo dot com
 Reported by:zhanglijiu at gmail dot com
 Summary:[sapi/cli/php] Error 1
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   Mac OS 10.6.8
 PHP Version:5.4.3
 Block user comment: N
 Private report: N

 New Comment:

Yes 
$ make clean 
Really works


Previous Comments:

[2012-05-15 04:27:30] zhanglijiu at gmail dot com

There are also others people faced this problem.
http://stackoverflow.com/questions/9845139/php-installation-fails-in-sapi-cli-php
https://bugs.php.net/bug.php?id=43189

I think the problem is "Fails to link iconv", this problem always happens for 
mac 
os compiled php. I have fixed the problem by disabled-iconv, but it should have 
a 
better solution.


[2012-05-15 02:23:08] larue...@php.net

could you paste your whole compiling log in pastebin.com,  then give us the 
link?

thanks


[2012-05-14 14:21:52] reeze dot xia at gmail dot com

Have you ever make before? 
you could try 
$ make clean
$ make


[2012-05-14 12:32:53] zhanglijiu at gmail dot com

Description:

When I try to compiler php 5.4.3, there is a errors. I searched this issues, 
but 
I can not find a good solution.

Undefined symbols for architecture x86_64:
  "_print", referenced from:
  _date_format in php_date.o
 (maybe you meant: _zend_print_variable, _php_quot_print_encode , 
_php_print_credits , _php_info_print_box_end , _php_info_print_style , 
_zend_print_flat_zval_r , _file_printedlen , _php_info_print_css , 
_zend_print_zval_ex , _zend_make_printable_zval , _zif_quoted_printable_encode 
, 
_debug_print_backtrace_args , _php_info_print_hr , _cdf_print_classid , 
_zend_print_zval_r_ex , _php_info_print_box_start , _php_print_info , 
_zend_print_zval , _php_info_print_table_start , _php_info_print_table_row_ex , 
_printf , _php_info_print_table_end , _php_printf , _php_info_print_table_row , 
_cdf_print_elapsed_time , _php_quot_print_decode , _zend_print_zval_r , 
_file_printf , _php_info_print_module , _zif_user_printf , 
_php_info_print_table_colspan_header , _cdf_print_property_name , _zif_print_r 
, 
_zif_quoted_printable_decode , _zend_printf , __php_stream_printf , 
_php_print_info_htmlhead , _print_class , _php_info_print_table_header , 
_zend_do_print )
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1








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

Bug #62476 [Com]: DateTime::createFromFormat z format incorrect wrt 29.02

2012-07-05 Thread kaido at tradenet dot ee

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

 ID: 62476
 Comment by: kaido at tradenet dot ee
 Reported by:kaido at tradenet dot ee
 Summary:DateTime::createFromFormat z format incorrect wrt
 29.02
 Status: Open
 Type:   Bug
 Package:Calendar related
 Operating System:   debian 2.6.32-5-amd64
 PHP Version:5.4.4
 Block user comment: N
 Private report: N

 New Comment:

the bug was introduced in commit 4c9fad8b362a7d2b6a94b4961e4b2dc037b2766d to 
fix 
the bug #51994.

the problem is that in parse_date.c in timelib_parse_from_format() function, in 
case of the z-format option, the date is immidiately normalized, but at that 
point (if year format option happens to come _after_ the z - ie right from it) 
year is not yet set, and -9 is used instead, which most probably is not a 
leap year :)

the obvious quick solution is to call timelib_do_normalize() only if year is  
set already.

doing so passes all test, too. even the one for #51994.

should the timelib_do_normalize() call be added to year option, too, if 
date/month are set at that point?


also, in timelib_do_normalize() there seems to be 3 checks like:

if (time->s != TIMELIB_UNSET) .. 

shouldn't 2nd and 3rd be "if (time->i != TIMELIB_UNSET)" and "if (time->h != 
TIMELIB_UNSET)" instead ?

(I did not dig deep enough, to be sure, though)


Previous Comments:

[2012-07-05 11:04:10] Sjon at hortensius dot net

I can confirm this, this is broken since 5.3.9

http://3v4l.org/1Z4W4


[2012-07-04 00:20:58] kaido at tradenet dot ee

Description:

When creating DateTime object from string and using z (day of year) format 
option, 
the 29.02 of the leap year is missing. works ok in 5.3.5

Test script:
---
for ($d=55;$d<65;$d++) {
$dt = DateTime::createFromFormat ('z.Y', $d.'.2012');
$dd = $dt->format ('d.m.Y');
echo "$d $dd\n";
}

29.02.2012 is clearly missing .. 

Expected result:

55 25.02.2012
56 26.02.2012
57 27.02.2012
58 28.02.2012
59 29.02.2012
60 01.03.2012
61 02.03.2012
62 03.03.2012
63 04.03.2012
64 05.03.2012

Actual result:
--
55 25.02.2012
56 26.02.2012
57 27.02.2012
58 28.02.2012
59 01.03.2012
60 02.03.2012
61 03.03.2012
62 04.03.2012
63 05.03.2012
64 06.03.2012






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

Bug #61102 [Com]: GD build test failed. Please check the config.log for details

2012-07-05 Thread damon dot conway at alchemysystems dot com

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

 ID: 61102
 Comment by: damon dot conway at alchemysystems dot com
 Reported by:leonardo dot burchi at gmail dot com
 Summary:GD build test failed. Please check the config.log
 for details
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   Centos 6.2
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

For those of you having trouble with this, I was able to work around it by 
doing an export LDFLAGS=-L/usr/lib64/mysql in the script I use to configure 
php.  Try setting this env variable for what you need until the PHP devs are 
able to fix the configure process.


Previous Comments:

[2012-02-16 10:18:35] leonardo dot burchi at gmail dot com

Description:

Launching configure script for PHP 5.3.10 on Centos 6.2 64 bit with configure 
commando you can see in test script, I get the error GD build test failed. 
Please check the config.log for details.



Test script:
---
./configure --with-apxs2=/usr/local/apache/bin/apxs --with-mysql 
--with-mysqli=/usr/bin/mysql_config --enable-mbstring --with-openssl 
--with-zlib --with-gd --with-jpeg-dir=/root/jpeg-8d --with-gettext 
--with-mcrypt --with-curl --with-libdir=lib64 --with-freetype-dir=/usr/local 
--with-pdo-mysql

Expected result:

I expect a successfull build :-)

Actual result:
--
I get the error "configure: error: GD build test failed. Please check the 
config.log for details.".
The last lines I can see in config.log are:

configure:37551: gcc -o conftest -g -O2 -fvisibility=hidden   
-Wl,-rpath,/usr/li   b6464 
-L/usr/lib6464 -Wl,-rpath,/usr/local/lib64 -L/usr/local/lib64 -lz conftest  
 .c -lpng  -ljpeg -lcurl -lz 
-lrt -lm -ldl -lnsl  -lxml2 -lz -lm -lssl -lcrypto -
   ldl -lz -lcurl -lxml2 -lz -lm 1>&5
configure:38325: checking for FT_New_Face in -lfreetype
configure:38344: gcc -o conftest -g -O2 -fvisibility=hidden   
-Wl,-rpath,/usr/li   b6464 
-L/usr/lib6464 -Wl,-rpath,/usr/local/lib64 -L/usr/local/lib64 conftest.c -  
 lfreetype  -lpng -lz -ljpeg 
-lcurl -lz -lrt -lm -ldl -lnsl  -lxml2 -lz -lm -lssl
-lcrypto -ldl -lz -lcurl -lxml2 -lz -lm 1>&5
configure:44777: gcc -o conftest -g -O2 -fvisibility=hidden   
-Wl,-rpath,/usr/li   b6464 
-L/usr/lib6464 -Wl,-rpath,/usr/local/lib64 -L/usr/local/lib64 conftest.c
   -lfreetype -lpng -lz -ljpeg 
-lcurl -lz -lrt -lm -ldl -lnsl  -lxml2 -lz -lm -ls  
 sl -lcrypto -ldl -lz -lcurl -lxml2 -lz -lm 1>&5
configure: failed program was:
#line 44766 "configure"
#include "confdefs.h"

char foobar () {}
char foobar();
int main() {
  foobar();
  return 0;
}






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

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

2012-07-05 Thread angelo at camargo dot ws

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

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

 New Comment:

++ for finally in PHP


Previous Comments:

[2012-06-07 09:16:55] jl235 at kent dot ac dot uk

Most of the exceptions people come across in their PHP code tends to be for 
either File IO, or database access. Both of these need a finally to ensure the 
handle/connection/whatever gets closed, or dealt with in some other way. Using 
try/catch is already a lot more cumbersome then a world without Exceptions, but 
without finally, it adds a lot duplication and state management.

For example in my own code I do something along the lines of ...



$time = microtime( true );
$sql = generateSQLQuery();
$conn = openDBConnection();
$ex = null;

try {
$result = runSQLQuery( $conn, $sql );
} catch ( Exception $ex ) { /* do nothing */ }

closeDBConnection( $conn );
logSQLQuery( $sql, microtime(true) - $time );

if ( $ex !== null ) {
throw $ex;
}



... which could just be ...



$time = microtime( true );
$sql  = generateSQLQuery();
$conn = openDBConnection();

try {
$result = runSQLQuery( $conn, $sql );
} finally {
closeDBConnection( $conn );
logSQLQuery( $sql, microtime(true) - $time );
}



Simpler to write, easier to read, harder to get wrong, and more elegant.

Please re-open this.


[2012-06-05 11:19:41] sgnezdov at fastmail dot fm

Finally is absolutely necessary for proper management of disposable resources.

There is no easy to read workaround for

try { 
 causeException();
} finally {
 releaseResource();
}

others pointed out that solving this issue kills re-throw, which is equally 
important.


[2012-05-29 21:36:49] kavi at postpro dot net

Since every other kitchen sink on the planet has been thrown into PHP, why not 
also the refrigerator which we all expect to be here?  Come on.  At least give 
a 
good reason.

Quoting topaz:

"Ugly workaround hack time!

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


...yeah, you're actually describing the *entire language* there. :|


[2012-04-25 20:32:33] toplegocreator at hotmail dot com

"Though this is still possible (however much more to type) it is wrong design. 
Since obviously you are using the exceptions as control flow."

If exceptions should never be propagated up the stack to a block of code that 
knows how to deal with them, why are exceptions there in the first place? 
Exceptions ARE flow control. That's their reason for existing. If they 
shouldn't be used that way, they shouldn't be included in the language.

Let me elaborate. An exception should occur any time when the current block 
cannot successfully continue execution in the current state and has no direct 
means (or shouldn't have any direct means because of good separation of 
concerns) of informing the client of the problem. A finally clause, while not 
strictly needed if code repetition is acceptable (and it isn't in my book), is 
appropriate for ensuring that resources (like database connections, open files, 
a printer, whatever) are released when fatal errors occur. Trying to deal with 
the error as some kind of returned result all the way up the stack will just 
make your code more difficult to read and maintain; an error should go all the 
way up the stack until a piece of code that's responsible for output can 
determine how to inform the client. That's how exceptions are supposed to be 
used, and a finally clause makes it possible to properly and (fairly) reliably 
release resources, which is also a best practice.


[2012-04-19 20:00:39] simon at stienen dot name

RAII is an elegant solution for tidying up scopes reliably.
It is also possible in PHP to do RAII without writing one class per resource 
type:

callback = $callback;
}

function __destruct() {
if (is_callable($this->callback)) {
call_user_func($this->callback);
}
}
}

function do_something() {
mysql_query("LOCK TABLES mytable WRITE");
$guard = new ScopeGuard(function() {
mysql_query("UNLOCK TABLES");
});

Bug #62480 [Com]: mbstring and mbregex won't compile

2012-07-05 Thread a...@php.net

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

 ID: 62480
 Comment by: a...@php.net
 Reported by:rs at bytecamp dot net
 Summary:mbstring and mbregex won't compile
 Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   FreeBSD 8.1-RELEASE-p12
 PHP Version:5.4.4
 Block user comment: N
 Private report: N

 New Comment:

I don't have any FreeBSD versions at hand, but bundled oniguruma version is 
5.9.2, so it could be incompatible ... you could easily check that just 
temporarily uninstalling 2.5.8 from the system and trying to recompile PHP 
again.


Previous Comments:

[2012-07-04 13:35:10] rs at bytecamp dot net

One thing to add: oniguruma-2.5.8 is installed on this machine (for ruby). 
Could this be the cause, because /usr/local/include is also in the list of 
include directories?


[2012-07-04 13:21:06] rs at bytecamp dot net

Description:

When enabling mbstring and mbregex, make will bail out with the following log:

/bin/sh /tmp/php-5.4/php-5.4.4/libtool --silent --preserve-dup-deps 
--mode=compile cc  -Iext/mbstring/ -I/tmp/php-5.4/php-5.4.4/ext/mbstring/ 
-DPHP_ATOM_INC -I/tmp/php-5.4/php-5.4.4/include -I/tmp/php-5.4/php-5.4.4/main 
-I/tmp/php-5.4/php-5.4.4 -I/tmp/php-5.4/php-5.4.4/ext/date/lib 
-I/tmp/php-5.4/php-5.4.4/ext/ereg/regex -I/usr/local/include/libxml2 
-I/usr/local/include -I/tmp/php-5.4/php-5.4.4/ext/mbstring/oniguruma 
-I/tmp/php-5.4/php-5.4.4/ext/mbstring/libmbfl 
-I/tmp/php-5.4/php-5.4.4/ext/mbstring/libmbfl/mbfl 
-I/tmp/php-5.4/php-5.4.4/ext/sqlite3/libsqlite -I/tmp/php-5.4/php-5.4.4/TSRM 
-I/tmp/php-5.4/php-5.4.4/Zend-I/usr/local/include -g -O2 
-fvisibility=hidden  -c /tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c -o 
ext/mbstring/mbstring.lo
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c: In function 
'_php_mb_compile_regex':
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:987: error: expected ')' before 
'OnigUChar'
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:987: warning: cast from pointer 
to integer of different size
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:988: error: expected ')' before 
'OnigUChar'
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:988: warning: cast from pointer 
to integer of different size
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:990: warning: passing argument 2 
of 'onig_new' makes pointer from integer without a cast
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:990: warning: passing argument 3 
of 'onig_new' makes pointer from integer without a cast
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:991: error: 'OnigUChar' 
undeclared (first use in this function)
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:991: error: (Each undeclared 
identifier is reported only once
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:991: error: for each function it 
appears in.)
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:991: error: expected ';' before 
'err_str'
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:992: error: 'err_str' undeclared 
(first use in this function)
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c: In function 
'_php_mb_match_regex':
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1003: error: expected ')' before 
'OnigUChar'
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1003: warning: cast from pointer 
to integer of different size
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1004: error: expected ')' before 
'OnigUChar'
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1004: warning: cast from pointer 
to integer of different size
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1004: error: expected ')' before 
'OnigUChar'
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1004: warning: cast from pointer 
to integer of different size
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1005: error: expected ')' before 
'OnigUChar'
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1005: warning: cast from pointer 
to integer of different size
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1005: warning: passing argument 
2 of 'onig_search' makes pointer from integer without a cast
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1005: warning: passing argument 
3 of 'onig_search' makes pointer from integer without a cast
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1005: warning: passing argument 
4 of 'onig_search' makes pointer from integer without a cast
/tmp/php-5.4/php-5.4.4/ext/mbstring/mbstring.c:1005: warning: passing argument 
5 of 'onig_search' makes pointer from integer without a cast
*** Error code 1


Test script:
---
./configure --prefix=/usr/local/php-4.4-fail --enable-mbstring --enable-mbregex
make








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

[PHP-BUG] Bug #62487 [NEW]: next/current and each behave differently with unset

2012-07-05 Thread justin at crowdfavorite dot com

From: justin at crowdfavorite dot com
Operating system: OS X
PHP version:  5.4.4
Package:  Arrays related
Bug Type: Bug
Bug description:next/current and each behave differently with unset

Description:

Removing the current array element using unset() while iterating through
the array with next() and current() causes the array pointer to miss the
next array element.  

Removing the /next/ array element with unset() while iterating through the
array with each() does /not/ cause similar behavior - the array element
following is correctly picked up at the next call to each().

It seems like the behavior with next()/current() is incorrect (but that it
would be good for the behavior to be consistent regardless).

Test script:
---
example code: http://pastebin.com/5HMumA0A

Expected result:

12345 - expected
12345
1245 - expected
1245
12345 - expected
12345

Actual result:
--
12345 - expected
12345
1245 - expected
1245
12345 - expected
1245

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

[PHP-BUG] Bug #62488 [NEW]: Invalid bcrypt hash

2012-07-05 Thread smt837784 at yahoo dot com

From: smt837784 at yahoo dot com
Operating system: Fedora 16 (3.3.4-1.fc16.x86_64)
PHP version:  5.3.14
Package:  *Encryption and hash functions
Bug Type: Bug
Bug description:Invalid bcrypt hash

Description:

If the salt is less than 128 bits (22 characters in base 64) it is padded
with "$" instead of ".". Which is an invalid bcrypt hash.

Test script:
---
echo crypt('', '$2y$04$..') . '';
echo crypt('', '$2y$04$') . '';
echo crypt('', '$2y$04$$.'); // keep backwards
compatibility

Expected result:

$2y$04$..w74bL5gU7LSJClZClCa.Pkz14aTv/XO
$2y$04$..w74bL5gU7LSJClZClCa.Pkz14aTv/XO
$2y$04$$.w74bL5gU7LSJClZClCa.Pkz14aTv/XO

Actual result:
--
$2y$04$..w74bL5gU7LSJClZClCa.Pkz14aTv/XO
$2y$04$$.w74bL5gU7LSJClZClCa.Pkz14aTv/XO
$2y$04$$.w74bL5gU7LSJClZClCa.Pkz14aTv/XO

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

Bug #61939 [Com]: PDO_FIREBIRD incorrect result of query for NUMERIC(x, y) type in 1 dialect

2012-07-05 Thread mar...@php.net

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

 ID: 61939
 Comment by: mar...@php.net
 Reported by:sim-mail at list dot ru
 Summary:PDO_FIREBIRD incorrect result of query for
 NUMERIC(x, y) type in 1 dialect
 Status: Open
 Type:   Bug
 Package:PDO related
 Operating System:   Windows 7 32bit
 PHP Version:5.3.12
 Block user comment: N
 Private report: N

 New Comment:

Currently it is possible to create databases in Dialect 1 and 3 only, however 
it 
is recommended that you use Dialect 3 exclusively, since Dialect 1 will 
eventually be deprecated.


Previous Comments:

[2012-06-26 15:50:14] manubing at gmail dot com

Also affected on macosx using PHP 5.3.10 and debian lenny with PHP 
5.2.6-1+lenny16.

Something odd: incorrect results are the same for a column for all rows fetched:
using the previous example:

public 'COST' => string '1.00' <-- Error

All rows fetched will have 'COST' set to '1.00' (even if actual values differs)


Running again the query will give another (eg: '600.00') incorrect value, 
the same on all rows again.


[2012-05-04 14:53:01] sim-mail at list dot ru

only 1 dialect


[2012-05-04 14:50:22] sim-mail at list dot ru

Description:

PDO_FIREBIRD incorrect result of query for NUMERIC(x, y) or DECIMAL (x, y) type

setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$sth = $dbh->prepare($sql);
$sth->execute();
$obj = $sth->fetch();
var_dump($obj);
$sth = null;
?>

Script print 

object(stdClass)[3]
  public 'ID' => string '1' (length=1)
  public 'NAME' => string 'my price' (length=8)
  public 'COST' => string '1.00' (length=4) <-- Error hear (correct result 
12.34)

Test script:
---
Sql script for create database

SET SQL DIALECT 1;
SET NAMES WIN1251;

CREATE DATABASE 'LOCALHOST:D:\interbasedata\test.fdb'
USER 'SYSDBA' PASSWORD 'masterkey'
PAGE_SIZE 16384
DEFAULT CHARACTER SET WIN1251 COLLATION WIN1251;

CREATE TABLE PRICE (
IDINTEGER NOT NULL,
NAME  VARCHAR(10),
COST  NUMERIC(15,2)
);

INSERT INTO PRICE (ID, NAME, COST) VALUES (1, 'my price', 12.34);

COMMIT WORK;

ALTER TABLE PRICE ADD CONSTRAINT PK_PRICE PRIMARY KEY (ID);







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

Bug #61939 [Opn->Asn]: PDO_FIREBIRD incorrect result of query for NUMERIC(x, y) type in 1 dialect

2012-07-05 Thread mariuz

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

 ID: 61939
 Updated by: mar...@php.net
 Reported by:sim-mail at list dot ru
 Summary:PDO_FIREBIRD incorrect result of query for
 NUMERIC(x, y) type in 1 dialect
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:PDO related
 Operating System:   Windows 7 32bit
 PHP Version:5.3.12
-Assigned To:
+Assigned To:mariuz
 Block user comment: N
 Private report: N



Previous Comments:

[2012-07-06 06:26:39] mar...@php.net

Currently it is possible to create databases in Dialect 1 and 3 only, however 
it 
is recommended that you use Dialect 3 exclusively, since Dialect 1 will 
eventually be deprecated.


[2012-06-26 15:50:14] manubing at gmail dot com

Also affected on macosx using PHP 5.3.10 and debian lenny with PHP 
5.2.6-1+lenny16.

Something odd: incorrect results are the same for a column for all rows fetched:
using the previous example:

public 'COST' => string '1.00' <-- Error

All rows fetched will have 'COST' set to '1.00' (even if actual values differs)


Running again the query will give another (eg: '600.00') incorrect value, 
the same on all rows again.


[2012-05-04 14:53:01] sim-mail at list dot ru

only 1 dialect


[2012-05-04 14:50:22] sim-mail at list dot ru

Description:

PDO_FIREBIRD incorrect result of query for NUMERIC(x, y) or DECIMAL (x, y) type

setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$sth = $dbh->prepare($sql);
$sth->execute();
$obj = $sth->fetch();
var_dump($obj);
$sth = null;
?>

Script print 

object(stdClass)[3]
  public 'ID' => string '1' (length=1)
  public 'NAME' => string 'my price' (length=8)
  public 'COST' => string '1.00' (length=4) <-- Error hear (correct result 
12.34)

Test script:
---
Sql script for create database

SET SQL DIALECT 1;
SET NAMES WIN1251;

CREATE DATABASE 'LOCALHOST:D:\interbasedata\test.fdb'
USER 'SYSDBA' PASSWORD 'masterkey'
PAGE_SIZE 16384
DEFAULT CHARACTER SET WIN1251 COLLATION WIN1251;

CREATE TABLE PRICE (
IDINTEGER NOT NULL,
NAME  VARCHAR(10),
COST  NUMERIC(15,2)
);

INSERT INTO PRICE (ID, NAME, COST) VALUES (1, 'my price', 12.34);

COMMIT WORK;

ALTER TABLE PRICE ADD CONSTRAINT PK_PRICE PRIMARY KEY (ID);







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

Bug #62335 [Com]: zlib conflict with gzhandler

Bug #62467 [Opn->Wfx]: SimpleXML memory usage is not reported by memory_get_usage()

Bug #62481 [Opn->Fbk]: xdebug openssl_encrypt crash

Bug #62476 [Com]: DateTime::createFromFormat z format incorrect wrt 29.02

Bug #62468 [Com]: SimpleXML memory leak, if circular references are removed by Garbage Collector

Bug #60882 [Com]: PDO crashes PHP FastCGI daemon when querying Sphinx server

Bug #62023 [Com]: [sapi/cli/php] Error 1

Bug #62476 [Com]: DateTime::createFromFormat z format incorrect wrt 29.02

Bug #61102 [Com]: GD build test failed. Please check the config.log for details

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

Bug #62480 [Com]: mbstring and mbregex won't compile

[PHP-BUG] Bug #62487 [NEW]: next/current and each behave differently with unset

[PHP-BUG] Bug #62488 [NEW]: Invalid bcrypt hash

Bug #61939 [Com]: PDO_FIREBIRD incorrect result of query for NUMERIC(x, y) type in 1 dialect

Bug #61939 [Opn->Asn]: PDO_FIREBIRD incorrect result of query for NUMERIC(x, y) type in 1 dialect

15 matches

Site Navigation

Mail list logo

Footer information