date:20120318

Bug #61408 [Nab]: Character set failure

2012-03-18 Thread inge at upandforward dot com

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

 ID: 61408
 User updated by:inge at upandforward dot com
 Reported by:inge at upandforward dot com
 Summary:Character set failure
 Status: Not a bug
 Type:   Bug
 Package:Strings related
 Operating System:   Linux Ubuntu
 PHP Version:5.3.5-1ubuntu7.7
 Block user comment: N
 Private report: N

 New Comment:

Already installed! :)
Anyway, I thought that utf-8 was utf-8, regardless of locale. Oh well. I'll do 
with my work-around.


Previous Comments:

[2012-03-19 00:23:27] ahar...@php.net

That's really a question for an Ubuntu support channel, but I think installing 
the 
language-support-nb package would do it.


[2012-03-16 10:07:04] inge at upandforward dot com

Comment found on stackoverflow.com:

"If you ask me, setlocale() sucks ass. I am a friend of managing this manually 
or using a library like Zend_Localeso you don't have to depend on locales being 
installed on the server (and sometimes still not working)".

The client should NOT be expected to use the same locale as the server, but if 
I could install the Norwegian locale, I think it might still be OK, So how do I 
install the above mentioned library, or some equivalent?


[2012-03-16 01:35:25] ahar...@php.net

There are encodings where 0x2f (/) and 0x5c (\) are valid bytes within 
multi-byte 
characters, so basename() has to be locale-aware to deal with that.

Fundamentally, I don't really see why you would expect basename() to be able to 
deal sensibly with a configured locale that you don't have installed. Your test 
script behaves fine provided nb_NO.utf8 is available.

Not a bug -> closing.


[2012-03-15 23:01:59] inge at upandforward dot com

Here's a replacement, but without the $suffix parameter:

function IV_basename($name)
{   $name = strrchr($name,DIRECTORY_SEPARATOR);
if ($name) return substr($name,1);
return false;
}


[2012-03-15 22:55:47] inge at upandforward dot com

There is no return value (it may be false or an empty string), and locale -a 
does not include "nb_NO". However, the site is used in Norway for Norwegian 
users, so it must be able to handle Norwegian characters. The basename function 
should not make such distinctions, so I have written my own - which works 
independently of locale or character set.
The php version has been corrected above because the bug report did not give 
that choice. My suggested replacement could not be uploaded because the site 
did not accept a text file, even if it stated that it was the only filetype 
accepted. I also had great trouble getting the right CAPTCHA (Oh, yes, I can 
add numbers! :) )




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=61408


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

Bug #61419 [Opn->Fbk]: Upload Progress returning empty array

2012-03-18 Thread laruence

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

 ID: 61419
 Updated by: larue...@php.net
 Reported by:jasmin_z at hotmail dot com
 Summary:Upload Progress returning empty array
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Session related
 Operating System:   Debian 6 Squeeze x64
 PHP Version:5.4.0
 Block user comment: N
 Private report: N

 New Comment:

Plz use a huge size file to test, since you set the 
session.upload_progress.cleanup on,  which means, the upload info will be clean 
as soon as all the post data was parsed. see: 
http://cn.php.net/manual/en/session.configuration.php#ini.session.upload-
progress.cleanup


Previous Comments:

[2012-03-16 18:47:30] jasmin_z at hotmail dot com

Description:

Session upload tracking is returning empty array when queued.
PHP is build from source using following configure string:

./configure --prefix=/usr/local --sysconfdir=/etc/php --localstatedir=/var 
--libdir=/usr/lib64 --with-layout=GNU --with-config-file-path=/etc/php 
--with-config-file-scan-dir=/etc/php/conf.d --with-openssl --with-mcrypt 
--with-zlib --with-tidy --with-bz2 --with-curl --with-curlwrappers --with-mhash 
--with-pear --with-imap=/usr/lib64/ --with-imap-ssl --with-kerberos 
--with-gettext --with-pic --with-mysql=mysqlnd --with-mysqli=mysqlnd 
--with-pdo-mysql=mysqlnd --with-mysql-sock=/var/run/mysql/mysql.sock --with-gd 
--with-xsl --with-xmlrpc --with-mm --with-freetype-dir=/usr/lib 
--with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib --with-fpm-user=www-data 
--with-fpm-group=www-data --enable-gd-native-ttf --enable-pcntl 
--enable-calendar --enable-ftp --enable-exif --enable-intl --enable-mbstring 
--enable-sockets --enable-zip --enable-soap --enable-fpm --disable-debug 
--disable-rpath


Webserver used is nginx (1.0.14) built from source.

Test script:
---
http://www.neowin.net/forum/topic/1063478-php-540-upload-tracking-returning-empty-array/

Expected result:

Array containing information about files being uploaded.

Actual result:
--
array(0) {
}






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

Bug #61408 [Nab]: Character set failure

2012-03-18 Thread aharvey

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

 ID: 61408
 Updated by: ahar...@php.net
 Reported by:inge at upandforward dot com
 Summary:Character set failure
 Status: Not a bug
 Type:   Bug
 Package:Strings related
 Operating System:   Linux Ubuntu
 PHP Version:5.3.5-1ubuntu7.7
 Block user comment: N
 Private report: N

 New Comment:

That's really a question for an Ubuntu support channel, but I think installing 
the 
language-support-nb package would do it.


Previous Comments:

[2012-03-16 10:07:04] inge at upandforward dot com

Comment found on stackoverflow.com:

"If you ask me, setlocale() sucks ass. I am a friend of managing this manually 
or using a library like Zend_Localeso you don't have to depend on locales being 
installed on the server (and sometimes still not working)".

The client should NOT be expected to use the same locale as the server, but if 
I could install the Norwegian locale, I think it might still be OK, So how do I 
install the above mentioned library, or some equivalent?


[2012-03-16 01:35:25] ahar...@php.net

There are encodings where 0x2f (/) and 0x5c (\) are valid bytes within 
multi-byte 
characters, so basename() has to be locale-aware to deal with that.

Fundamentally, I don't really see why you would expect basename() to be able to 
deal sensibly with a configured locale that you don't have installed. Your test 
script behaves fine provided nb_NO.utf8 is available.

Not a bug -> closing.


[2012-03-15 23:01:59] inge at upandforward dot com

Here's a replacement, but without the $suffix parameter:

function IV_basename($name)
{   $name = strrchr($name,DIRECTORY_SEPARATOR);
if ($name) return substr($name,1);
return false;
}


[2012-03-15 22:55:47] inge at upandforward dot com

There is no return value (it may be false or an empty string), and locale -a 
does not include "nb_NO". However, the site is used in Norway for Norwegian 
users, so it must be able to handle Norwegian characters. The basename function 
should not make such distinctions, so I have written my own - which works 
independently of locale or character set.
The php version has been corrected above because the bug report did not give 
that choice. My suggested replacement could not be uploaded because the site 
did not accept a text file, even if it stated that it was the only filetype 
accepted. I also had great trouble getting the right CAPTCHA (Oh, yes, I can 
add numbers! :) )


[2012-03-15 21:28:20] cataphr...@php.net

What's the return value of setlocale? Does locale -a show that locale?




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=61408


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

Bug #37391 [Com]: PREG_OFFSET_CAPTURE not UTF-8 aware when using u modifier

2012-03-18 Thread harald dot lapp at gmail dot com

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

 ID: 37391
 Comment by: harald dot lapp at gmail dot com
 Reported by:mike at silverorange dot com
 Summary:PREG_OFFSET_CAPTURE not UTF-8 aware when using u
 modifier
 Status: Not a bug
 Type:   Bug
 Package:PCRE related
 Operating System:   Linux
 PHP Version:5.1.4
 Block user comment: N
 Private report: N

 New Comment:

I am not sure, where the manual mentions, that PREG_OFFSET_CAPTURE is not 
"UTF-8" 
aware. And even if it was, it is still very, very, very annoying, Any chances, 
that this behaviour could get changed?


Previous Comments:

[2006-05-10 07:03:42] 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

.


[2006-05-09 22:57:49] mike at silverorange dot com

Description:

When using preg_match_all() with the PREG_OFFSET_CAPTURE flag, the returned 
match offsets are in octets rather than characters.

PCRE is compiled with --enable-utf8 and I am using the u modifier in my regular 
expression.


Reproduce code:
---


Expected result:

Array
(
[0] => Array
(
[0] => Array
(
[0] => B
[1] => 2
)
)
)

Actual result:
--
Array
(
[0] => Array
(
[0] => Array
(
[0] => B
[1] => 4
)
)
)






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

[PHP-BUG] Bug #61430 [NEW]: Transposed memset() params in sapi/fpm/fpm/fpm_shm.c

2012-03-18 Thread michaelhood at gmail dot com

From: 
Operating system: Linux
PHP version:  5.4.0
Package:  FPM related
Bug Type: Bug
Bug description:Transposed memset() params in sapi/fpm/fpm/fpm_shm.c

Description:

Affects all versions which bundle PHP-FPM. (>=5.3.3)

In fpm_shm_alloc there is a call to memset() to initialise the segment. The

parameters to memset() are transposed. Since we are [trying to] initialise
with 0,  
but passing 0 to size_t, it silently fails to do anything.

Patch attached, tested on 5.3.10 and 5.4.0.


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

Bug #61197 [Opn->Nab]: SNMPv3 cannot connect after reboot

2012-03-18 Thread lytboris

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

 ID: 61197
 Updated by: lytbo...@php.net
 Reported by:markn at ieee dot org
 Summary:SNMPv3 cannot connect after reboot
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:SNMP related
-Operating System:   Linux
+Operating System:   Irrelevant
 PHP Version:Irrelevant
-Assigned To:
+Assigned To:lytboris
 Block user comment: N
 Private report: N

 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

This is bug in Net-SNMP library: you can try this simple script as a proof that 
snmpwalk has the same flaw:
snmpwalk -v3 -l authNoPriv -a MD5 -u admin -A Password01 192.168.1.1 . >out 
&;sleep 0.2; /etc/init.d/snmpd restart

Basically this engine* stuff should be maintained in SNMP-library itself: 
php-snmp does not specify (and maintain) these variables at all.


Previous Comments:

[2012-02-27 21:31:22] markn at ieee dot org

wrong email address. bad day at the keyboard.


[2012-02-27 21:17:10] markn at ieee dot org

Description:

Under certain conditions, it is not possible to reconnect to a device that has 
rebooted while using SNMPv3.

This happens if a PHP script is connecting with authNoPriv or authPriv.

After the device reboots, PHP's SNMPv3 routines do not take note of the 
modified 
msgAuthoritativeEngineReboots count and the modified msgAuthoritativeEngineTime 
values - they continue trying to use the old values, and as a result are never 
able to communicate after a reboot.

During device maintenance, it is often necessary to reboot a device - such as 
after a firmware upgrade. So this is actually something that is needed.

Basically, there needs to be a way to discard existing session information.

Test script:
---


Expected result:

Run this script, verify that it successfully reads the data. Reboot the device 
and 
see that it is unable to read the data after the device is back up. Use 
Wireshark 
to observe that the boot count and time values have changed, but the PHP SNMP 
routines ignore the new values.








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

Bug #61388 [Asn->Csd]: ReflectionObject:getProperties called on ArrayObject throws Segmentation Fault

2012-03-18 Thread cataphract

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

 ID: 61388
 Updated by: cataphr...@php.net
 Reported by:piotr dot nowak at onet dot eu
 Summary:ReflectionObject:getProperties called on ArrayObject
 throws Segmentation Fault
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Reflection related
 Operating System:   Linux (Ubuntu) x64
 PHP Version:5.4.0
 Assigned To:cataphract
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2012-03-18 18:23:29] cataphr...@php.net

Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&revision=324337
Log: - Fixed bug #61388 (ReflectionObject:getProperties() issues invalid reads
  when get_properties returns a hash table with (inaccessible) dynamic
  numeric properties).


[2012-03-14 23:16:45] piotr dot nowak at onet dot eu

To be sure that problem doesn't come from the used package, I have compiled the 
current version of 5.4 branch from SVN (revision #324259). It was compiled with 
completely default configuration (only --prefix=/tmp/php/php-5.4 was used).

GDB traces:

piotr@piotr-Vostro-430:/tmp/php/php-5.4/bin$ gdb ./php
GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /tmp/php/php-5.4/bin/php...done.
(gdb) run /tmp/bug.php 
Starting program: /tmp/php/php-5.4/bin/php /tmp/bug.php
Array
(
)
Array
(
)

Program received signal SIGSEGV, Segmentation fault.
0x0056b358 in _adddynproperty (pptr=, 
num_args=, args=0x7fffb698, 
hash_key=0x7fffb680) at 
/tmp/php/php-src-5.4/ext/reflection/php_reflection.c:3835
3835if (hash_key->arKey[0] == '\0') {
(gdb) bt
#0  0x0056b358 in _adddynproperty (pptr=, 
num_args=, 
args=0x7fffb698, hash_key=0x7fffb680) at 
/tmp/php/php-src-5.4/ext/reflection/php_reflection.c:3835
#1  0x006893cc in zend_hash_apply_with_arguments (ht=0x77fd72c0, 
apply_func=0x56b310 <_adddynproperty>, num_args=2) at 
/tmp/php/php-src-5.4/Zend/zend_hash.c:772
#2  0x0056a401 in zim_reflection_class_getProperties (ht=, return_value=0x77fd7eb8, 
return_value_ptr=, this_ptr=0x77fd7ee8, 
return_value_used=)
at /tmp/php/php-src-5.4/ext/reflection/php_reflection.c:3876
#3  0x0071d1d9 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x77fa2060)
at /tmp/php/php-src-5.4/Zend/zend_vm_execute.h:642
#4  0x006d960c in execute (op_array=0x77fd64a0) at 
/tmp/php/php-src-5.4/Zend/zend_vm_execute.h:410
#5  0x0067d205 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3)
at /tmp/php/php-src-5.4/Zend/zend.c:1272
#6  0x0061de28 in php_execute_script (primary_file=0x7fffde60)
at /tmp/php/php-src-5.4/main/main.c:2473
#7  0x0071f6e7 in do_cli (argc=2, argv=0x7fffe238) at 
/tmp/php/php-src-5.4/sapi/cli/php_cli.c:983
#8  0x00425590 in main (argc=2, argv=0x7fffe238) at 
/tmp/php/php-src-5.4/sapi/cli/php_cli.c:1356
(gdb) frame 0
#0  0x0056b358 in _adddynproperty (pptr=, 
num_args=, 
args=0x7fffb698, hash_key=0x7fffb680) at 
/tmp/php/php-src-5.4/ext/reflection/php_reflection.c:3835
3835if (hash_key->arKey[0] == '\0') {
(gdb) frame 1
#1  0x006893cc in zend_hash_apply_with_arguments (ht=0x77fd72c0, 
apply_func=0x56b310 <_adddynproperty>, num_args=2) at 
/tmp/php/php-src-5.4/Zend/zend_hash.c:772
772 result = apply_func(p->pData TSRMLS_CC, num_args, args, 
&hash_key);
(gdb) frame 2
#2  0x0056a401 in zim_reflection_class_getProperties (ht=, return_value=0x77fd7eb8, 
return_value_ptr=, this_ptr=0x77fd7ee8, 
return_value_used=)
at /tmp/php/php-src-5.4/ext/reflection/php_reflection.c:3876
3876zend_hash_apply_with_arguments(properties TSRMLS_CC, 
(apply_func_args_t) _adddynproperty, 2, &ce, return_value);
(gdb) frame 3
#3  0x0071d1d9 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x77fa2060)
a

Req #54033 [Csd->Asn]: add get_error_handler and get_exception handler

2012-03-18 Thread tyra3l at gmail dot com

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

 ID: 54033
 User updated by:tyra3l at gmail dot com
 Reported by:tyra3l at gmail dot com
 Summary:add get_error_handler and get_exception handler
-Status: Closed
+Status: Assigned
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 PHP Version:5.3.5
 Assigned To:tyrael
 Block user comment: N
 Private report: N

 New Comment:

hi


Previous Comments:

[2012-03-18 17:52:10] tyr...@php.net

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




[2011-02-18 11:45:20] tyra3l at gmail dot com

the get_exception_handler is least important for me: I cannot come up with a 
situation, which couldn't be solved by set_exception_handler and 
restore_exception_handler, because the exception handler doesn't have something 
like the $error_types in the set_error_handler.
but I think it would be more consistent if both the error and exception handler 
functions would provide that.

Tyrael


[2011-02-17 01:04:00] tyra3l at gmail dot com

of course it returns the callback.
but:
- you can't get it without overwriting
- it doesn't return the error_types, hence you won't know on which error should 
you call the previous handler
- if you would think, that maybe the restore_error_handler would come to the 
rescue(you set your error handler, in your error handler you catch everything, 
and restore the previous handler for the errors that isn't for you and and call 
the original error handler with trigger_error): you can only tigger E_USER_*. :(

am I missing something?

if not, please re-open the issue, because it isn't bogus.

Tyrael


[2011-02-17 00:50:53] ras...@php.net

set_error_handler() already returns the previously set error handler, if any.


[2011-02-17 00:44:58] tyra3l at gmail dot com

Description:

my co-worker had a problem with the Zend Framework Soap Server class: he was 
using trigger_error for handling the application level errors, and the ZF Soap 
Server class set his own error_handler, so my co-worker's error handler was 
swapped out, and his E_USER_WARNING/E_USER_ERROR errors was ignored (if you 
have 
an userspace error handler then every error type, which isn't observed will be 
discarded)

I mentioned this on twitter (I wasn't really nice)
http://twitter.com/#!/Tyr43l/status/22704699030
and Matthew Weier O'Phinney responded that they had to do this, because there 
was some quirks about the SoapServer or DomDocument class.

so if they don't set their error_handler, they can't handle the error, if they 
do, they will overwrite any existing error_handler.

if there would be a way, to get the current(previous) error handler, then they 
could have save the current/previous error handler (with the error type 
parameter!) and from their error handler, they could have call the applevel 
error handler callback.

of course, some stackable mechanism, like the spl_autoload would be a more 
better approach but that would break BC, at least I couldn't figure out a way 
to 
do it without problems.

I will ask Matthew to comment on this issue (what was the exact problem that 
forced them to set the error handler at the first place)







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

Req #54033 [Asn->Csd]: add get_error_handler and get_exception handler

2012-03-18 Thread tyrael

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

 ID: 54033
 Updated by: tyr...@php.net
 Reported by:tyra3l at gmail dot com
 Summary:add get_error_handler and get_exception handler
-Status: Assigned
+Status: Closed
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 PHP Version:5.3.5
 Assigned To:tyrael
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2011-02-18 11:45:20] tyra3l at gmail dot com

the get_exception_handler is least important for me: I cannot come up with a 
situation, which couldn't be solved by set_exception_handler and 
restore_exception_handler, because the exception handler doesn't have something 
like the $error_types in the set_error_handler.
but I think it would be more consistent if both the error and exception handler 
functions would provide that.

Tyrael


[2011-02-17 01:04:00] tyra3l at gmail dot com

of course it returns the callback.
but:
- you can't get it without overwriting
- it doesn't return the error_types, hence you won't know on which error should 
you call the previous handler
- if you would think, that maybe the restore_error_handler would come to the 
rescue(you set your error handler, in your error handler you catch everything, 
and restore the previous handler for the errors that isn't for you and and call 
the original error handler with trigger_error): you can only tigger E_USER_*. :(

am I missing something?

if not, please re-open the issue, because it isn't bogus.

Tyrael


[2011-02-17 00:50:53] ras...@php.net

set_error_handler() already returns the previously set error handler, if any.


[2011-02-17 00:44:58] tyra3l at gmail dot com

Description:

my co-worker had a problem with the Zend Framework Soap Server class: he was 
using trigger_error for handling the application level errors, and the ZF Soap 
Server class set his own error_handler, so my co-worker's error handler was 
swapped out, and his E_USER_WARNING/E_USER_ERROR errors was ignored (if you 
have 
an userspace error handler then every error type, which isn't observed will be 
discarded)

I mentioned this on twitter (I wasn't really nice)
http://twitter.com/#!/Tyr43l/status/22704699030
and Matthew Weier O'Phinney responded that they had to do this, because there 
was some quirks about the SoapServer or DomDocument class.

so if they don't set their error_handler, they can't handle the error, if they 
do, they will overwrite any existing error_handler.

if there would be a way, to get the current(previous) error handler, then they 
could have save the current/previous error handler (with the error type 
parameter!) and from their error handler, they could have call the applevel 
error handler callback.

of course, some stackable mechanism, like the spl_autoload would be a more 
better approach but that would break BC, at least I couldn't figure out a way 
to 
do it without problems.

I will ask Matthew to comment on this issue (what was the exact problem that 
forced them to set the error handler at the first place)







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

Req #54033 [ReO->Asn]: add get_error_handler and get_exception handler

2012-03-18 Thread tyrael

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

 ID: 54033
 Updated by: tyr...@php.net
 Reported by:tyra3l at gmail dot com
 Summary:add get_error_handler and get_exception handler
-Status: Re-Opened
+Status: Assigned
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 PHP Version:5.3.5
-Assigned To:
+Assigned To:tyrael
 Block user comment: N
 Private report: N



Previous Comments:

[2011-02-18 11:45:20] tyra3l at gmail dot com

the get_exception_handler is least important for me: I cannot come up with a 
situation, which couldn't be solved by set_exception_handler and 
restore_exception_handler, because the exception handler doesn't have something 
like the $error_types in the set_error_handler.
but I think it would be more consistent if both the error and exception handler 
functions would provide that.

Tyrael


[2011-02-17 01:04:00] tyra3l at gmail dot com

of course it returns the callback.
but:
- you can't get it without overwriting
- it doesn't return the error_types, hence you won't know on which error should 
you call the previous handler
- if you would think, that maybe the restore_error_handler would come to the 
rescue(you set your error handler, in your error handler you catch everything, 
and restore the previous handler for the errors that isn't for you and and call 
the original error handler with trigger_error): you can only tigger E_USER_*. :(

am I missing something?

if not, please re-open the issue, because it isn't bogus.

Tyrael


[2011-02-17 00:50:53] ras...@php.net

set_error_handler() already returns the previously set error handler, if any.


[2011-02-17 00:44:58] tyra3l at gmail dot com

Description:

my co-worker had a problem with the Zend Framework Soap Server class: he was 
using trigger_error for handling the application level errors, and the ZF Soap 
Server class set his own error_handler, so my co-worker's error handler was 
swapped out, and his E_USER_WARNING/E_USER_ERROR errors was ignored (if you 
have 
an userspace error handler then every error type, which isn't observed will be 
discarded)

I mentioned this on twitter (I wasn't really nice)
http://twitter.com/#!/Tyr43l/status/22704699030
and Matthew Weier O'Phinney responded that they had to do this, because there 
was some quirks about the SoapServer or DomDocument class.

so if they don't set their error_handler, they can't handle the error, if they 
do, they will overwrite any existing error_handler.

if there would be a way, to get the current(previous) error handler, then they 
could have save the current/previous error handler (with the error type 
parameter!) and from their error handler, they could have call the applevel 
error handler callback.

of course, some stackable mechanism, like the spl_autoload would be a more 
better approach but that would break BC, at least I couldn't figure out a way 
to 
do it without problems.

I will ask Matthew to comment on this issue (what was the exact problem that 
forced them to set the error handler at the first place)







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

Req #54033 [Asn->Opn]: add get_error_handler and get_exception handler

2012-03-18 Thread tyrael

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

 ID: 54033
 Updated by: tyr...@php.net
 Reported by:tyra3l at gmail dot com
 Summary:add get_error_handler and get_exception handler
-Status: Assigned
+Status: Open
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

sorry for my last two changes about this issue.


Previous Comments:

[2012-03-18 16:41:54] tyra3l at gmail dot com

asd


[2012-03-18 16:41:41] tyra3l at gmail dot com

test


[2011-02-18 11:45:20] tyra3l at gmail dot com

the get_exception_handler is least important for me: I cannot come up with a 
situation, which couldn't be solved by set_exception_handler and 
restore_exception_handler, because the exception handler doesn't have something 
like the $error_types in the set_error_handler.
but I think it would be more consistent if both the error and exception handler 
functions would provide that.

Tyrael


[2011-02-17 01:04:00] tyra3l at gmail dot com

of course it returns the callback.
but:
- you can't get it without overwriting
- it doesn't return the error_types, hence you won't know on which error should 
you call the previous handler
- if you would think, that maybe the restore_error_handler would come to the 
rescue(you set your error handler, in your error handler you catch everything, 
and restore the previous handler for the errors that isn't for you and and call 
the original error handler with trigger_error): you can only tigger E_USER_*. :(

am I missing something?

if not, please re-open the issue, because it isn't bogus.

Tyrael


[2011-02-17 00:50:53] ras...@php.net

set_error_handler() already returns the previously set error handler, if any.




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=54033


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

Req #54033 [Csd->Asn]: add get_error_handler and get_exception handler

2012-03-18 Thread tyra3l at gmail dot com

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

 ID: 54033
 User updated by:tyra3l at gmail dot com
 Reported by:tyra3l at gmail dot com
 Summary:add get_error_handler and get_exception handler
-Status: Closed
+Status: Assigned
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

asd


Previous Comments:

[2012-03-18 16:41:41] tyra3l at gmail dot com

test


[2011-02-18 11:45:20] tyra3l at gmail dot com

the get_exception_handler is least important for me: I cannot come up with a 
situation, which couldn't be solved by set_exception_handler and 
restore_exception_handler, because the exception handler doesn't have something 
like the $error_types in the set_error_handler.
but I think it would be more consistent if both the error and exception handler 
functions would provide that.

Tyrael


[2011-02-17 01:04:00] tyra3l at gmail dot com

of course it returns the callback.
but:
- you can't get it without overwriting
- it doesn't return the error_types, hence you won't know on which error should 
you call the previous handler
- if you would think, that maybe the restore_error_handler would come to the 
rescue(you set your error handler, in your error handler you catch everything, 
and restore the previous handler for the errors that isn't for you and and call 
the original error handler with trigger_error): you can only tigger E_USER_*. :(

am I missing something?

if not, please re-open the issue, because it isn't bogus.

Tyrael


[2011-02-17 00:50:53] ras...@php.net

set_error_handler() already returns the previously set error handler, if any.


[2011-02-17 00:44:58] tyra3l at gmail dot com

Description:

my co-worker had a problem with the Zend Framework Soap Server class: he was 
using trigger_error for handling the application level errors, and the ZF Soap 
Server class set his own error_handler, so my co-worker's error handler was 
swapped out, and his E_USER_WARNING/E_USER_ERROR errors was ignored (if you 
have 
an userspace error handler then every error type, which isn't observed will be 
discarded)

I mentioned this on twitter (I wasn't really nice)
http://twitter.com/#!/Tyr43l/status/22704699030
and Matthew Weier O'Phinney responded that they had to do this, because there 
was some quirks about the SoapServer or DomDocument class.

so if they don't set their error_handler, they can't handle the error, if they 
do, they will overwrite any existing error_handler.

if there would be a way, to get the current(previous) error handler, then they 
could have save the current/previous error handler (with the error type 
parameter!) and from their error handler, they could have call the applevel 
error handler callback.

of course, some stackable mechanism, like the spl_autoload would be a more 
better approach but that would break BC, at least I couldn't figure out a way 
to 
do it without problems.

I will ask Matthew to comment on this issue (what was the exact problem that 
forced them to set the error handler at the first place)







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

Req #54033 [ReO->Csd]: add get_error_handler and get_exception handler

2012-03-18 Thread tyra3l at gmail dot com

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

 ID: 54033
 User updated by:tyra3l at gmail dot com
 Reported by:tyra3l at gmail dot com
 Summary:add get_error_handler and get_exception handler
-Status: Re-Opened
+Status: Closed
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

test


Previous Comments:

[2011-02-18 11:45:20] tyra3l at gmail dot com

the get_exception_handler is least important for me: I cannot come up with a 
situation, which couldn't be solved by set_exception_handler and 
restore_exception_handler, because the exception handler doesn't have something 
like the $error_types in the set_error_handler.
but I think it would be more consistent if both the error and exception handler 
functions would provide that.

Tyrael


[2011-02-17 01:04:00] tyra3l at gmail dot com

of course it returns the callback.
but:
- you can't get it without overwriting
- it doesn't return the error_types, hence you won't know on which error should 
you call the previous handler
- if you would think, that maybe the restore_error_handler would come to the 
rescue(you set your error handler, in your error handler you catch everything, 
and restore the previous handler for the errors that isn't for you and and call 
the original error handler with trigger_error): you can only tigger E_USER_*. :(

am I missing something?

if not, please re-open the issue, because it isn't bogus.

Tyrael


[2011-02-17 00:50:53] ras...@php.net

set_error_handler() already returns the previously set error handler, if any.


[2011-02-17 00:44:58] tyra3l at gmail dot com

Description:

my co-worker had a problem with the Zend Framework Soap Server class: he was 
using trigger_error for handling the application level errors, and the ZF Soap 
Server class set his own error_handler, so my co-worker's error handler was 
swapped out, and his E_USER_WARNING/E_USER_ERROR errors was ignored (if you 
have 
an userspace error handler then every error type, which isn't observed will be 
discarded)

I mentioned this on twitter (I wasn't really nice)
http://twitter.com/#!/Tyr43l/status/22704699030
and Matthew Weier O'Phinney responded that they had to do this, because there 
was some quirks about the SoapServer or DomDocument class.

so if they don't set their error_handler, they can't handle the error, if they 
do, they will overwrite any existing error_handler.

if there would be a way, to get the current(previous) error handler, then they 
could have save the current/previous error handler (with the error type 
parameter!) and from their error handler, they could have call the applevel 
error handler callback.

of course, some stackable mechanism, like the spl_autoload would be a more 
better approach but that would break BC, at least I couldn't figure out a way 
to 
do it without problems.

I will ask Matthew to comment on this issue (what was the exact problem that 
forced them to set the error handler at the first place)







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

[PHP-BUG] Bug #61429 [NEW]: php54-svn build ignores '--enable-static=no --enable-=shared' flags

2012-03-18 Thread locuse at mm dot st

From: 
Operating system: linux x86_64
PHP version:  5.4SVN-2012-03-18 (SVN)
Package:  *Compile Issues
Bug Type: Bug
Bug description:php54-svn build ignores '--enable-static=no 
--enable-=shared' flags

Description:

i'm building php5.4 from source,

cd PHP_5_4
svn info
URL: https://svn.php.net/repository/php/php-src/branches/PHP_5_4
Repository Root: https://svn.php.net/repository
Repository UUID: c90b9560-bf6c-de11-be94-00142212c4b1
Revision: 324330
Node Kind: directory
Schedule: normal
Last Changed Author: cataphract
Last Changed Rev: 324327
Last Changed Date: 2012-03-18 08:07:20 -0700 (Sun, 18 Mar 2012)

i've configure to disable static build

echo $CFLAGS
-O2 -march=amdfam10 -mtune=amdfam10
rm -rf /usr/local/extTEST
mkdir -p /usr/local/extTEST
export EXTENSION_DIR='/usr/local/extTEST'
./configure --prefix=/usr/local/php5 \
--enable-shared=yes --enable-static=no --enable-session=shared

but after,

make -j20
make install
Installing shared extensions: /usr/local/extTEST/
...

BOTH the *.so & *.a ext's are _deployed_ to the extenstion-dir install
target.

ls -al /usr/local/extTEST
total 124K
drwxr-xr-x+  2 root root 4.0K Mar 18 09:20 ./
drwxrwxr-x+ 36 root root 4.0K Mar 18 09:19 ../
-rwxr-xr-x+  1 root root 105K Mar 18 09:20 session.a*
-rwxr-xr-x+  1 root root 7.7K Mar 18 09:20 session.so*

this holds true for any individual, or set of, extension(s) specified.

iiuc from chat in ##php, the *.a's _are_ built, and the target *.so's are 
derived from them, but the deployment should only be of the *.so's, in this

case.

checking the Makefile,

grep ^"CFLAGS =" Makefile
CFLAGS = $(CFLAGS_CLEAN) -prefer-non-pic -static

that "-static" flag, apparently installed by libtool (?), is unexpected.

is this a bug, or is there an additional config flag/setting needed to
end-up 
with just the *.so's deployed?


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

Bug #61423 [Opn->Csd]: gzip compression fails

2012-03-18 Thread iliaa

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

 ID: 61423
 Updated by: il...@php.net
 Reported by:borrible13th at gmx dot net
 Summary:gzip compression fails
-Status: Open
+Status: Closed
 Type:   Bug
 Package:SOAP related
 Operating System:   ALL
 PHP Version:5.4.0
-Assigned To:
+Assigned To:iliaa
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2012-03-17 02:01:29] borrible13th at gmx dot net

Description:

SOAP fails to compress with gzip encoding (compression level greater 0): it 
warns 
"encoding mode must be either ZLIB_ENCODING_RAW, ZLIB_ENCODING_GZIP or 
ZLIB_ENCODING_DEFLATE" and throws SoapFault with "SoapClient::__doRequest() 
returned non string value".

Cause: Zlib introduces new constants ZLIB_ENCODING_RAW, ZLIB_ENCODING_GZIP, 
ZLIB_ENCODING_DEFLATE and redefines FORCE_GZIP as ZLIB_ENCODING_GZIP and 
FORCE_DEFLATE as ZLIB_ENCODING_DEFLATE.

In php_http.c, line 263ff. the call to gzencode is prepared with an hard coded 
magic number (1) for the gzip encoding: gzencode(data, level, 1).
It should be gzencode(data, level, FORCE_GZIP) or gzencode(data, level, 
ZLIB_ENCODING_GZIP), because the magic number is now defined as 0x1f (31).

Test script:
---
new SoapClient($wsdl, array('soap_version' => SOAP_1_2, 'compression' => 
SOAP_COMPRESSION_ACCEPT | SOAP_COMPRESSION_GZIP | 1 ));

Expected result:

Call gzencode(data, level, FORCE_GZIP) (or gzencode(data, level, 
ZLIB_ENCODING_GZIP)), so it returns compressed data.

Actual result:
--
gzencode(data, level, 1) is called, so it returns always false and warns 
"encoding 
mode must be either ZLIB_ENCODING_RAW, ZLIB_ENCODING_GZIP or 
ZLIB_ENCODING_DEFLATE".






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

Bug #61418 [Asn->Csd]: Segmentation foult using FiltesystemIterator & RegexIterator

2012-03-18 Thread cataphract

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

 ID: 61418
 Updated by: cataphr...@php.net
 Reported by:melkorm at gmail dot com
 Summary:Segmentation foult using FiltesystemIterator &
 RegexIterator
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:SPL related
 Operating System:   Linux Mint 12
 PHP Version:5.3.10
 Assigned To:cataphract
 Block user comment: N
 Private report: N



Previous Comments:

[2012-03-18 15:07:08] cataphr...@php.net

Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&revision=324327
Log: - Fixed bug #61418 (Segmentation fault when DirectoryIterator's or
  FilesystemIterator's iterators are requested more than once without
  having had its dtor callback called in between).


[2012-03-17 23:27:20] cataphr...@php.net

Verified.

The zend_object_iterator_funcs.dtor function (implementation: 
spl_filesystem_tree_it_dtor) seems faulty. In the reproduce script here, the 
zend_object_iterator is requested twice: first by the RegexIterator 
constructor, and then by foreach. The zend_object_iterator returned is the same 
in both cases -- that owned by the FilesystemIterator and its destructor gets 
called twice. But obviously the destructor is not prepared to be called twice 
as it unconditionally calls zval_ptr_dtor (for some reason, twice) and zeroes 
the reference to the owning object.


[2012-03-17 18:52:31] melkorm at gmail dot com

Sorry for this, but I am not used to this bugtrucker yet, anywho proper script 
should look like that:
$fileIterator = new FilesystemIterator(__DIR__, 
FilesystemIterator::KEY_AS_FILENAME);
$regexpIterator = new RegexIterator($fileIterator,
'#.*#',
\RegexIterator::MATCH,
\RegexIterator::USE_KEY
);
foreach ($fileIterator as $key => $file)
{
}

No idea why this `doubled`.


[2012-03-17 18:50:14] melkorm at gmail dot com

There is a typo


[2012-03-16 17:52:20] melkorm at gmail dot com

It also fails at :
melkorm@bibiop ~ $ php -v
PHP 5.3.6-13ubuntu3.6 with Suhosin-Patch (cli) (built: Feb 11 2012 03:26:01) 
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans




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=61418


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

Bug #61418 [Ver->Asn]: Segmentation foult using FiltesystemIterator & RegexIterator

2012-03-18 Thread cataphract

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

 ID: 61418
 Updated by: cataphr...@php.net
 Reported by:melkorm at gmail dot com
 Summary:Segmentation foult using FiltesystemIterator &
 RegexIterator
-Status: Verified
+Status: Assigned
 Type:   Bug
 Package:SPL related
 Operating System:   Linux Mint 12
 PHP Version:5.3.10
-Assigned To:
+Assigned To:cataphract
 Block user comment: N
 Private report: N



Previous Comments:

[2012-03-17 23:27:20] cataphr...@php.net

Verified.

The zend_object_iterator_funcs.dtor function (implementation: 
spl_filesystem_tree_it_dtor) seems faulty. In the reproduce script here, the 
zend_object_iterator is requested twice: first by the RegexIterator 
constructor, and then by foreach. The zend_object_iterator returned is the same 
in both cases -- that owned by the FilesystemIterator and its destructor gets 
called twice. But obviously the destructor is not prepared to be called twice 
as it unconditionally calls zval_ptr_dtor (for some reason, twice) and zeroes 
the reference to the owning object.


[2012-03-17 18:52:31] melkorm at gmail dot com

Sorry for this, but I am not used to this bugtrucker yet, anywho proper script 
should look like that:
$fileIterator = new FilesystemIterator(__DIR__, 
FilesystemIterator::KEY_AS_FILENAME);
$regexpIterator = new RegexIterator($fileIterator,
'#.*#',
\RegexIterator::MATCH,
\RegexIterator::USE_KEY
);
foreach ($fileIterator as $key => $file)
{
}

No idea why this `doubled`.


[2012-03-17 18:50:14] melkorm at gmail dot com

There is a typo


[2012-03-16 17:52:20] melkorm at gmail dot com

It also fails at :
melkorm@bibiop ~ $ php -v
PHP 5.3.6-13ubuntu3.6 with Suhosin-Patch (cli) (built: Feb 11 2012 03:26:01) 
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans


[2012-03-16 17:47:22] melkorm at gmail dot com

Description:

melkorm@bibiop ~/htdocs/test.dev $ php -v
PHP 5.3.10-1~dotdeb.1 with Suhosin-Patch (cli) (built: Feb  2 2012 23:28:08) 
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
with Suhosin v0.9.33, Copyright (c) 2007-2012, by SektionEins GmbH


Test script:
---
$fileIterator = new FilesystemIterator(__DIR__, 
FilesystemIterator::KEY_AS_FILENAME);
$regexpIterator = new RegexIterator($fileIterator,
$regexpIterator = new RegexIterator($fileIterator,
'#.*#',
'#.*#',
\RegexIterator::MATCH,
\RegexIterator::MATCH,
\RegexIterator::USE_KEY
\RegexIterator::USE_KEY
);
);
foreach ($fileIterator as $key => $file)
foreach ($fileIterator as $key => $file)
{
}

Actual result:
--
Segemntation foult

strace output can be found here : http://pastebin.com/CFV6qepj






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

Bug #61408 [Nab]: Character set failure

Bug #61419 [Opn->Fbk]: Upload Progress returning empty array

Bug #61408 [Nab]: Character set failure

Bug #37391 [Com]: PREG_OFFSET_CAPTURE not UTF-8 aware when using u modifier

[PHP-BUG] Bug #61430 [NEW]: Transposed memset() params in sapi/fpm/fpm/fpm_shm.c

Bug #61197 [Opn->Nab]: SNMPv3 cannot connect after reboot

Bug #61388 [Asn->Csd]: ReflectionObject:getProperties called on ArrayObject throws Segmentation Fault

Req #54033 [Csd->Asn]: add get_error_handler and get_exception handler

Req #54033 [Asn->Csd]: add get_error_handler and get_exception handler

Req #54033 [ReO->Asn]: add get_error_handler and get_exception handler

Req #54033 [Asn->Opn]: add get_error_handler and get_exception handler

Req #54033 [Csd->Asn]: add get_error_handler and get_exception handler

Req #54033 [ReO->Csd]: add get_error_handler and get_exception handler

[PHP-BUG] Bug #61429 [NEW]: php54-svn build ignores '--enable-static=no --enable-=shared' flags

Bug #61423 [Opn->Csd]: gzip compression fails

Bug #61418 [Asn->Csd]: Segmentation foult using FiltesystemIterator & RegexIterator

Bug #61418 [Ver->Asn]: Segmentation foult using FiltesystemIterator & RegexIterator

17 matches

Site Navigation

Mail list logo

Footer information