date:20121124

[PHP-BUG] Bug #63595 [NEW]: Not really sane memory management initialization

2012-11-24 Thread arekm at maven dot pl

From: arekm at maven dot pl
Operating system: 
PHP version:  5.3.19
Package:  GNU MP related
Bug Type: Bug
Bug description:Not really sane memory management initialization

Description:

php gmp module uses:

mp_set_memory_functions(gmp_emalloc, gmp_erealloc, gmp_efree);

to switch to Zend memory management functions.

The problem is that there are other modules that use gmp. One is php-curl
in 
case when curl uses gnutls for SSL connections (gnutls >= 3.1.1).

gnutls also uses gmp.

The problem happens when curl first uses gmp, gmp allocates some things
(using 
generic memory management functions) and then php-gmp module changes memory

management functions to own (Zend) one.

Then memory allocated by generic functions is going to be reallocated/freed

using Zend functions which causes segfault.

Probably the solution would be to immediately set
mp_set_memory_functions
to Zend functions, before any other module has a chance to initialize gmp.

More:
http://lists.gnu.org/archive/html/help-gnutls/2012-11/msg00050.html
http://lists.gnu.org/archive/html/help-gnutls/2012-11/msg00049.html

Test script:
---
- build php with curl and gmp
- libcurl library needs to be built with gnutls >= 3.1.1
- run php cli
- press ctrl+D
=> result = segfault

Expected result:

No segfault.

Actual result:
--
Segfault.

Program received signal SIGSEGV, Segmentation fault.
0x7fffea23ef20 in ?? ()
(gdb) bt
#0  0x7fffea23ef20 in ?? ()
#1  0x7fffeb445d3b in mp_clear_multi (address@hidden) at multi.c:38
#2  0x7fffeb4472ca in ecc_del_point (p=0xc63ed0) at ecc_points.c:62
#3  0x7fffeb446972 in _ecc_wmnaf_cache_entry_free (p=)
at 
ecc_mulmod_cached.c:54
#4  ecc_wmnaf_cache_free () at ecc_mulmod_cached.c:68
#5  0x7fffeb445685 in gnutls_crypto_deinit () at init.c:44
#6  0x7fffeb3adb71 in gnutls_global_deinit () at gnutls_global.c:305
#7  0x7fffee0c9a79 in Curl_gtls_cleanup () at gtls.c:182
#8  0x7fffee0ca189 in Curl_ssl_cleanup () at sslgen.c:193
#9  0x7fffee0bbbf5 in curl_global_cleanup () at easy.c:325
#10 0x7fffee6f9bf8 in zm_shutdown_curl () from /usr/lib64/php/curl.so
#11 0x77a96105 in module_destructor () from 
/usr/lib64/libphp_common-5.3.18.so
#12 0x77a9b4ae in ?? () from /usr/lib64/libphp_common-5.3.18.so
#13 0x77a9cd08 in zend_hash_graceful_reverse_destroy () from 
/usr/lib64/libphp_common-5.3.18.so
#14 0x77a8f175 in zend_shutdown () from 
/usr/lib64/libphp_common-5.3.18.so
#15 0x77a3e01b in php_module_shutdown () from 
/usr/lib64/libphp_common-5.3.18.so
#16 0x00403406 in main ()
(gdb)

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

Bug #55479 [Opn]: ext/pcntl/tests failures

2012-11-24 Thread pajoye

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

 ID: 55479
 Updated by: paj...@php.net
 Reported by:glen at delfi dot ee
 Summary:ext/pcntl/tests failures
 Status: Open
 Type:   Bug
 Package:Testing related
 PHP Version:5.4.0alpha3
-Assigned To:
+Assigned To:sixd
 Block user comment: N
 Private report: N

 New Comment:

PR available at https://github.com/php/php-src/pull/59


Previous Comments:

[2011-09-08 11:02:34] glen at delfi dot ee

i wouldn't call it workaround, but rather "changes needed to get tests run 
standalone, i.e independant what is installed in system", which is important to 
get tests run unaffected by environment details

i agree, that support from run-tests.php side would make tests simplier. would 
it 
be needed to document the interface somewhere?

should i try to make such patch?


[2011-09-08 09:58:27] bj...@php.net

That seems like a bad workaround which would need to be repeated in many places.
run-tests maybe could export an environment variable which contained proper 
execute command..?


[2011-08-27 14:42:56] glen at delfi dot ee

i.e to be independant of php version installed in system while running tests, 
the 
following args need to be told when invoking php cli inside each .phpt:

$args = array("-n", "-d$extension_dir", "-c$inipath", ...);

where $extension_dir is ./modules and $inipath ./php-temp.ini, without doing so 
it would read /usr/lib/php for $extension_dir and /etc/php/php.ini for $inipath


[2011-08-27 14:37:43] glen at delfi dot ee

err, i know all that

the bug is that "make test" is using modules from to-be-installed path, where 
could be installed other version of php

so the patch is to enforce currently built version of php config and modules of 
php-cli that is invoked from tests itself

"make test" itself already does the php invocation properly, but invoking 
$PHP_TEST_EXECUTABLE from tests should do the same.

i've included patch for two tests i saw failing. i would proceed in other exts 
if i see interest in that.

is it clear what i'm saying here? maybe just look at the patch as patch says 
more than i'm able to explain.


[2011-08-26 15:22:04] ka...@php.net

>From the trace it looks like you are using some old dynamically linked 
>libraries thats compiled to a different version that the one you are using 
>(see the APINO).

Packages like PCRE and SPL should be statically compiled anyway, although I 
don't reckon we have any issues using dynamically loaded ones.




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


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

Bug #54379 [Opn]: PDO_OCI: UTF-8 output gets truncated

2012-11-24 Thread pajoye

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

 ID: 54379
 Updated by: paj...@php.net
 Reported by:sms at inbox dot ru
 Summary:PDO_OCI: UTF-8 output gets truncated
 Status: Open
 Type:   Bug
 Package:PDO related
 PHP Version:5.3.6
-Assigned To:
+Assigned To:sixd
 Block user comment: N
 Private report: N

 New Comment:

See PR at https://github.com/php/php-src/pull/59


Previous Comments:

[2012-09-07 21:35:35] tomasz at trejderowski dot pl

This bug is nearly exact duplicate of bug #35003:

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

Then only difference is that this one is still open (second one: closed) and 
this contains a solution, how to fix this bug. Even though, it requires to 
change ONE line and recompile sources, no one at PHP Dev Team took care to fix 
it. Even though, this is really huge bug, as it completely prevents using PHP + 
Oracle on UTF-8 encode webpages / databases.

The last change is, that this bug issue remains open for "only" 1,5 year, while 
second one, closed, but still not fixed, remains untough for SEVEN years (since 
initial report).


[2011-10-13 16:51:59] info-phpbug at ch2o dot info

i've issued the same bug with different version of oracle client (10.2) and the 
patch i've resolved the problem.


[2011-08-06 08:17:20] mitans02 at gmail dot com

I have same problem with UTF8 database and UTF8 client.
PDO_OCI should set string buffer length correct to handling UTF8.

Check also oracle OCI documents below:
http://download.oracle.com/docs/cd/B10500_01/server.920/a96529/ch6.htm#1004620

- Database settings
SQL> 
  1  SELECT PARAMETER, VALUE
  2FROM NLS_DATABASE_PARAMETERS
  3*  WHERE PARAMETER IN ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET')

PARAMETER  VALUE
-- --
NLS_CHARACTERSET   AL32UTF8
NLS_NCHAR_CHARACTERSET AL16UTF16

- Table for test
CREATE TABLE mytable (col1 NVARCHAR2(20));

- Test data
INSERT INTO mytable VALUES('12345678901234567890'); /* 20 signle byte char */
INSERT INTO mytable 
VALUES('ããããããããããããããããã¡ã¤ã¦ã¨'); /* 20 
double byte char, Japanese */

- Test Program
setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
$stmt = $db->prepare("SELECT * FROM mytable");
$stmt->execute();
var_dump($stmt->fetchAll(PDO::FETCH_ASSOC));
?>
- Test Program Output
# php ocitest.php 
  
NLS_LANG=Japanese_Japan.AL32UTF8


Warning: PDOStatement::fetchAll(): column 0 data was too large for buffer and 
was truncated to fit it in /root/ocitest.php on line 9
array(2) {
  [0]=>
  array(1) {
["COL1"]=>
string(20) "12345678901234567890"
  }
  [1]=>
  array(1) {
["COL1"]=>
string(40) "ããããããããããããã
  }
}

- Client Environment
# uname -a
Linux localhost.localdomain 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:35 EDT 2010 
i686 i686 i386 GNU/Linux
# rpm -qa | grep oracle
oracle-instantclient11.2-devel-11.2.0.2.0-1
oracle-instantclient11.2-sqlplus-11.2.0.2.0-1
oracle-instantclient11.2-basic-11.2.0.2.0-1
# php -v
PHP 5.3.6 (cli) (built: Aug  5 2011 09:15:02) 
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies

- Suggest fix
Patch to oci_statement.c

# diff -u oci_statement.c oci_statement.c.new 
--- oci_statement.c 2011-08-06 01:07:53.0 -0700
+++ oci_statement.c.new 2011-08-06 01:08:03.0 -0700
@@ -529,7 +529,7 @@
(param, OCI_DTYPE_PARAM, &colname, &namelen, 
OCI_ATTR_NAME, S->err));
 
col->precision = scale;
-   col->maxlen = data_size;
+   col->maxlen = ( data_size + 1 ) * sizeof(utext);
col->namelen = namelen;
col->name = estrndup((char *)colname, namelen);


[2011-03-25 04:39:19] sms at inbox dot ru

Description:

Data is stored in ANSI charset (CL8MSWIN1251) while connection uses UTF-8.

PDOStatement::fetchAll() generates warning and fields containing non-english 
characters gets truncated. For example, PDO outputs only 53 UTF-8 russian 
characters for VARCHAR2(100) field.

MySQL's PDOStatement::fetchAll() works fine in the same situation.


Test script:
---
$pdo = new PDO('oci:dbname=[host];charset=UTF8', '[user]', '[pass]');
$cmd = $pdo->query('SELECT * FROM user');
var_dump($cmd->fetchAll());


Expected result:

Table field(s) not truncated, no warnings

Actual result:
--
Table field(s) gets truncated, PHP warning:

PDOStatement::fetchAll() [pdostatement.fetchall]: column 0 data was too 
large for buffer and was truncated to fit

Bug #63392 [Opn]: DateTime::modify() start of week inconsistency

2012-11-24 Thread pajoye

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

 ID: 63392
 Updated by: paj...@php.net
 Reported by:chris at cmbuckley dot co dot uk
 Summary:DateTime::modify() start of week inconsistency
 Status: Open
 Type:   Bug
 Package:Date/time related
 PHP Version:5.4Git-2012-10-30 (snap)
-Assigned To:
+Assigned To:derick
 Block user comment: N
 Private report: N

 New Comment:

See also PR https://github.com/php/php-src/pull/224


Previous Comments:

[2012-10-30 02:26:30] chris at cmbuckley dot co dot uk

Description:

Calling $dt->modify("Monday this week") for all dates 13â19 May 2012 
(SunâSat) 
result in the same date (2012-05-14), suggesting that "this week" runs 
SunâSat. 
However, calling $dt->modify("Sunday this week") gives the "next" Sunday (2012-
05-20) for the same range.

On a related note, the documentation on relative date formats is lacking on the 
behaviour of this and strtotime when used with locales; one might expect the 
start of the week to be interpreted from LC_TIME.

Test script:
---
modify("Sunday this week");
var_dump($dt->format('r'));

Expected result:

string(31) "Sun, 13 May 2012 00:00:00 +"

Actual result:
--
string(31) "Sun, 20 May 2012 00:00:00 +"






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

Bug #63593 [Opn->Dup]: scandir return "?" in place of unicode letter in Windows httpd.

2012-11-24 Thread pajoye

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

 ID: 63593
 Updated by: paj...@php.net
 Reported by:john dot peterson10 at gmail dot com
 Summary:scandir return "?" in place of unicode letter in
 Windows httpd.
-Status: Open
+Status: Duplicate
 Type:   Bug
 Package:*Unicode Issues
 Operating System:   Windows
 PHP Version:5.5Git-2012-11-23 (snap)
 Block user comment: N
 Private report: N

 New Comment:

there is no Unicode support for file system functions in PHP. There is already 
a 
feature request for that > mark as duplicated.


Previous Comments:

[2012-11-23 23:06:22] john dot peterson10 at gmail dot com

Description:

Reproduce

Program
httpd-2.2.22-win32-x86-openssl-0.9.8t.msi
php-5.5-ts-windows-vc9-x86-r64788e3.zip

Config
httpd-2.2.22-win32-x86-openssl-0.9.8t.msi/program files/Apache Software 
Foundation/Apache2.2/conf/original/httpd.conf.in
php-5.5-ts-windows-vc9-x86-r64788e3.zip/php.ini-development

Command
# cd `httpd ServerRoot`
touch ãã¡ã¤ã«
curl -v 'http://server/test.php'# return ""
php test.php# return "ãã¡ã¤ã«"

Test script:
---


Expected result:

See above.

Actual result:
--
See above.






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

Bug #63593 [Com]: scandir return "?" in place of unicode letter in Windows httpd.

2012-11-24 Thread john dot peterson10 at gmail dot com

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

 ID: 63593
 Comment by: john dot peterson10 at gmail dot com
 Reported by:john dot peterson10 at gmail dot com
 Summary:scandir return "?" in place of unicode letter in
 Windows httpd.
 Status: Duplicate
 Type:   Bug
 Package:*Unicode Issues
 Operating System:   Windows
 PHP Version:5.5Git-2012-11-23 (snap)
 Block user comment: N
 Private report: N

 New Comment:

What is the duplicate ID?


Previous Comments:

[2012-11-24 11:56:09] paj...@php.net

there is no Unicode support for file system functions in PHP. There is already 
a 
feature request for that > mark as duplicated.


[2012-11-23 23:06:22] john dot peterson10 at gmail dot com

Description:

Reproduce

Program
httpd-2.2.22-win32-x86-openssl-0.9.8t.msi
php-5.5-ts-windows-vc9-x86-r64788e3.zip

Config
httpd-2.2.22-win32-x86-openssl-0.9.8t.msi/program files/Apache Software 
Foundation/Apache2.2/conf/original/httpd.conf.in
php-5.5-ts-windows-vc9-x86-r64788e3.zip/php.ini-development

Command
# cd `httpd ServerRoot`
touch ãã¡ã¤ã«
curl -v 'http://server/test.php'# return ""
php test.php# return "ãã¡ã¤ã«"

Test script:
---


Expected result:

See above.

Actual result:
--
See above.






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

Bug #63593 [Dup]: scandir return "?" in place of unicode letter in Windows httpd.

2012-11-24 Thread pajoye

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

 ID: 63593
 Updated by: paj...@php.net
 Reported by:john dot peterson10 at gmail dot com
 Summary:scandir return "?" in place of unicode letter in
 Windows httpd.
 Status: Duplicate
 Type:   Bug
 Package:*Unicode Issues
 Operating System:   Windows
 PHP Version:5.5Git-2012-11-23 (snap)
 Block user comment: N
 Private report: N

 New Comment:

I don't have it at hand but if you search for 'windows file unicode', you will 
find a couple with work around (tricky but possible).


Previous Comments:

[2012-11-24 11:59:55] john dot peterson10 at gmail dot com

What is the duplicate ID?


[2012-11-24 11:56:09] paj...@php.net

there is no Unicode support for file system functions in PHP. There is already 
a 
feature request for that > mark as duplicated.


[2012-11-23 23:06:22] john dot peterson10 at gmail dot com

Description:

Reproduce

Program
httpd-2.2.22-win32-x86-openssl-0.9.8t.msi
php-5.5-ts-windows-vc9-x86-r64788e3.zip

Config
httpd-2.2.22-win32-x86-openssl-0.9.8t.msi/program files/Apache Software 
Foundation/Apache2.2/conf/original/httpd.conf.in
php-5.5-ts-windows-vc9-x86-r64788e3.zip/php.ini-development

Command
# cd `httpd ServerRoot`
touch ãã¡ã¤ã«
curl -v 'http://server/test.php'# return ""
php test.php# return "ãã¡ã¤ã«"

Test script:
---


Expected result:

See above.

Actual result:
--
See above.






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

Bug #63593 [Com]: scandir return "?" in place of unicode letter in Windows httpd.

2012-11-24 Thread john dot peterson10 at gmail dot com

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

 ID: 63593
 Comment by: john dot peterson10 at gmail dot com
 Reported by:john dot peterson10 at gmail dot com
 Summary:scandir return "?" in place of unicode letter in
 Windows httpd.
 Status: Duplicate
 Type:   Bug
 Package:*Unicode Issues
 Operating System:   Windows
 PHP Version:5.5Git-2012-11-23 (snap)
 Block user comment: N
 Private report: N

 New Comment:

Please comment on the fact that CLI and httpd return different data.

Please post the relevant source file and line.


Previous Comments:

[2012-11-24 12:20:05] paj...@php.net

I don't have it at hand but if you search for 'windows file unicode', you will 
find a couple with work around (tricky but possible).


[2012-11-24 11:59:55] john dot peterson10 at gmail dot com

What is the duplicate ID?


[2012-11-24 11:56:09] paj...@php.net

there is no Unicode support for file system functions in PHP. There is already 
a 
feature request for that > mark as duplicated.


[2012-11-23 23:06:22] john dot peterson10 at gmail dot com

Description:

Reproduce

Program
httpd-2.2.22-win32-x86-openssl-0.9.8t.msi
php-5.5-ts-windows-vc9-x86-r64788e3.zip

Config
httpd-2.2.22-win32-x86-openssl-0.9.8t.msi/program files/Apache Software 
Foundation/Apache2.2/conf/original/httpd.conf.in
php-5.5-ts-windows-vc9-x86-r64788e3.zip/php.ini-development

Command
# cd `httpd ServerRoot`
touch ãã¡ã¤ã«
curl -v 'http://server/test.php'# return ""
php test.php# return "ãã¡ã¤ã«"

Test script:
---


Expected result:

See above.

Actual result:
--
See above.






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

Bug #63593 [Dup]: scandir return "?" in place of unicode letter in Windows httpd.

2012-11-24 Thread john dot peterson10 at gmail dot com

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

 ID: 63593
 User updated by:john dot peterson10 at gmail dot com
 Reported by:john dot peterson10 at gmail dot com
 Summary:scandir return "?" in place of unicode letter in
 Windows httpd.
 Status: Duplicate
 Type:   Bug
 Package:*Unicode Issues
 Operating System:   Windows
 PHP Version:5.5Git-2012-11-23 (snap)
 Block user comment: N
 Private report: N

 New Comment:

php test.php# return ""
%cygwin%/bin/php test.php   # return "ãã¡ã¤ã«"


Previous Comments:

[2012-11-24 12:34:23] john dot peterson10 at gmail dot com

Please comment on the fact that CLI and httpd return different data.

Please post the relevant source file and line.


[2012-11-24 12:20:05] paj...@php.net

I don't have it at hand but if you search for 'windows file unicode', you will 
find a couple with work around (tricky but possible).


[2012-11-24 11:59:55] john dot peterson10 at gmail dot com

What is the duplicate ID?


[2012-11-24 11:56:09] paj...@php.net

there is no Unicode support for file system functions in PHP. There is already 
a 
feature request for that > mark as duplicated.


[2012-11-23 23:06:22] john dot peterson10 at gmail dot com

Description:

Reproduce

Program
httpd-2.2.22-win32-x86-openssl-0.9.8t.msi
php-5.5-ts-windows-vc9-x86-r64788e3.zip

Config
httpd-2.2.22-win32-x86-openssl-0.9.8t.msi/program files/Apache Software 
Foundation/Apache2.2/conf/original/httpd.conf.in
php-5.5-ts-windows-vc9-x86-r64788e3.zip/php.ini-development

Command
# cd `httpd ServerRoot`
touch ãã¡ã¤ã«
curl -v 'http://server/test.php'# return ""
php test.php# return "ãã¡ã¤ã«"

Test script:
---


Expected result:

See above.

Actual result:
--
See above.






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

Bug #63593 [Dup]: scandir return "?" in place of unicode letter in Windows httpd.

2012-11-24 Thread pajoye

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

 ID: 63593
 Updated by: paj...@php.net
 Reported by:john dot peterson10 at gmail dot com
 Summary:scandir return "?" in place of unicode letter in
 Windows httpd.
 Status: Duplicate
 Type:   Bug
 Package:*Unicode Issues
 Operating System:   Windows
 PHP Version:5.5Git-2012-11-23 (snap)
 Block user comment: N
 Private report: N

 New Comment:

Different runtime encoding. Nothing wrong here. Also cygwin is total different 
story from a shell point of view.


Previous Comments:

[2012-11-24 12:42:36] john dot peterson10 at gmail dot com

php test.php# return ""
%cygwin%/bin/php test.php   # return "ãã¡ã¤ã«"


[2012-11-24 12:34:23] john dot peterson10 at gmail dot com

Please comment on the fact that CLI and httpd return different data.

Please post the relevant source file and line.


[2012-11-24 12:20:05] paj...@php.net

I don't have it at hand but if you search for 'windows file unicode', you will 
find a couple with work around (tricky but possible).


[2012-11-24 11:59:55] john dot peterson10 at gmail dot com

What is the duplicate ID?


[2012-11-24 11:56:09] paj...@php.net

there is no Unicode support for file system functions in PHP. There is already 
a 
feature request for that > mark as duplicated.




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


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

Bug #63593 [Com]: scandir return "?" in place of unicode letter in Windows httpd.

2012-11-24 Thread john dot peterson10 at gmail dot com

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

 ID: 63593
 Comment by: john dot peterson10 at gmail dot com
 Reported by:john dot peterson10 at gmail dot com
 Summary:scandir return "?" in place of unicode letter in
 Windows httpd.
 Status: Duplicate
 Type:   Bug
 Package:*Unicode Issues
 Operating System:   Windows
 PHP Version:5.5Git-2012-11-23 (snap)
 Block user comment: N
 Private report: N

 New Comment:

"Please post the relevant source file and line."


Previous Comments:

[2012-11-24 12:56:59] paj...@php.net

Different runtime encoding. Nothing wrong here. Also cygwin is total different 
story from a shell point of view.


[2012-11-24 12:42:36] john dot peterson10 at gmail dot com

php test.php# return ""
%cygwin%/bin/php test.php   # return "ãã¡ã¤ã«"


[2012-11-24 12:34:23] john dot peterson10 at gmail dot com

Please comment on the fact that CLI and httpd return different data.

Please post the relevant source file and line.


[2012-11-24 12:20:05] paj...@php.net

I don't have it at hand but if you search for 'windows file unicode', you will 
find a couple with work around (tricky but possible).


[2012-11-24 11:59:55] john dot peterson10 at gmail dot com

What is the duplicate ID?




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


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

Bug #63520 [Sus->Asn]: JSON extension includes a problematic license statement

2012-11-24 Thread pajoye

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

 ID: 63520
 Updated by: paj...@php.net
 Reported by:kaplan at debian dot org
 Summary:JSON extension includes a problematic license
 statement
-Status: Suspended
+Status: Assigned
 Type:   Bug
 Package:JSON related
 PHP Version:Irrelevant
-Assigned To:
+Assigned To:remi
 Block user comment: N
 Private report: N



Previous Comments:

[2012-11-23 13:33:42] r...@php.net

A patch proposed in https://bugs.php.net/63588 makes "json_encode" really free.


[2012-11-15 18:09:30] ras...@php.net

I am not saying it isn't a tricky license clause to deal with and it would be 
better if it wasn't there. However, I am also not keen on spending resources on 
rewriting code for this reason. If someone supplies a functionally equivalent 
replacement, we will have a look at it. But as far as I am concerned, license-
wise the terms Good and Evil are not legal terms. These are more subjective 
self-describing terms and since I deem PHP's use of the code as "Good" then we 
comply with the license. Could others perhaps use PHP and thus the code for 
"Evil" and therefore not comply with the license? Sure, but there are many 
things people can do with our code that is either against the various licenses 
involved or even illegal criminally. It is something we cannot control.


[2012-11-15 18:01:24] paj...@php.net

More seriously, as soon as the license is changed upstream, we will merge it. 
But 
we won't be able to do anything before.


[2012-11-15 18:00:52] paj...@php.net

well, the FSF does not like the PHP license either. Nothing worries me here :)


[2012-11-15 17:58:38] ansgar at debian dot org

I just want to note that the FSF[1] and other distributions like Fedora also 
think this license is bad[2].

  [1] 
  [2] , look for 
"JSON License"

So this is not a problem for just Debian.

Ansgar




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


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

Bug #63593 [Dup]: scandir return "?" in place of unicode letter in Windows httpd.

2012-11-24 Thread pajoye

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

 ID: 63593
 Updated by: paj...@php.net
 Reported by:john dot peterson10 at gmail dot com
 Summary:scandir return "?" in place of unicode letter in
 Windows httpd.
 Status: Duplicate
 Type:   Bug
 Package:*Unicode Issues
 Operating System:   Windows
 PHP Version:5.5Git-2012-11-23 (snap)
 Block user comment: N
 Private report: N

 New Comment:

No, sorry. I do not have the time to give all the details again. Look at the 
other 
bugs, explanation are in there. You have to convert your filenames to the 
runtime 
encoding, given that you know it.

Changing the core to support wild char APIs are not yet planed for 5.5.


Previous Comments:

[2012-11-24 12:58:15] john dot peterson10 at gmail dot com

"Please post the relevant source file and line."


[2012-11-24 12:56:59] paj...@php.net

Different runtime encoding. Nothing wrong here. Also cygwin is total different 
story from a shell point of view.


[2012-11-24 12:42:36] john dot peterson10 at gmail dot com

php test.php# return ""
%cygwin%/bin/php test.php   # return "ãã¡ã¤ã«"


[2012-11-24 12:34:23] john dot peterson10 at gmail dot com

Please comment on the fact that CLI and httpd return different data.

Please post the relevant source file and line.


[2012-11-24 12:20:05] paj...@php.net

I don't have it at hand but if you search for 'windows file unicode', you will 
find a couple with work around (tricky but possible).




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


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

Bug #63126 [Opn->Asn]: DISABLE_AUTHENTICATOR ignores array

2012-11-24 Thread remi

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

 ID: 63126
 Updated by: r...@php.net
 Reported by:r...@php.net
 Summary:DISABLE_AUTHENTICATOR ignores array
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:IMAP related
 Operating System:   GNU/Linux (Fedora 18)
 PHP Version:5.4.7
-Assigned To:
+Assigned To:remi
 Block user comment: N
 Private report: N



Previous Comments:

[2012-09-21 07:55:31] r...@php.net

I try to send my first pull request, I hope this is ok
https://github.com/php/php-src/pull/200


[2012-09-21 07:38:31] r...@php.net

I can find a exchange server an test the fix.

Test script:
$inbox = 
imap_open($server,$userlogin,$password,OP_HALFOPEN,1,array('DISABLE_AUTHENTICATOR'
 => array('GSSAPI','NTLM')));
var_dump(imap_errors());

Without the patch:
array(2) {
  [0]=>
  string(148) "Kerberos error: Credentials cache file 
'/run/user/1000/krb5cc_ea1f24ead9d3199b715d4d57505d4335/t (try running kinit) 
for exchange2007."
  [1]=>
  string(55) "SECURITY PROBLEM: insecure server advertised AUTH=PLAIN"
}

With the patch:
array(1) {
  [0]=>
  string(55) "SECURITY PROBLEM: insecure server advertised AUTH=PLAIN"
}


[2012-09-21 06:42:50] r...@php.net

This also affects php 5.3


[2012-09-21 06:33:46] r...@php.net

Description:

According to source code, DISABLE_AUTHENTICATOR could be a string or an array.

Works as expected:
imap_open($srv,$user,$pass,OP_HALF_OPEN,1,
   array('DISABLE_AUTHENTICATOR'=>'GSSAPI');

Doesn't works:
imap_open($srv,$user,$pass,OP_HALF_OPEN,1,
   array('DISABLE_AUTHENTICATOR'=>array('GSSAPI','NTLM'));


The trivial attached patch should fix this (but cannot test it)








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

Bug #63126 [Asn->Csd]: DISABLE_AUTHENTICATOR ignores array

2012-11-24 Thread remi

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

 ID: 63126
 Updated by: r...@php.net
 Reported by:r...@php.net
 Summary:DISABLE_AUTHENTICATOR ignores array
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:IMAP related
 Operating System:   GNU/Linux (Fedora 18)
 PHP Version:5.4.7
 Assigned To:remi
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of remi
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=f55bed9dad0ffbec170b857c0b3b1b33426fe9d5
Log: Fixed Bug #63126 DISABLE_AUTHENTICATOR ignores array


Previous Comments:

[2012-09-21 07:55:31] r...@php.net

I try to send my first pull request, I hope this is ok
https://github.com/php/php-src/pull/200


[2012-09-21 07:38:31] r...@php.net

I can find a exchange server an test the fix.

Test script:
$inbox = 
imap_open($server,$userlogin,$password,OP_HALFOPEN,1,array('DISABLE_AUTHENTICATOR'
 => array('GSSAPI','NTLM')));
var_dump(imap_errors());

Without the patch:
array(2) {
  [0]=>
  string(148) "Kerberos error: Credentials cache file 
'/run/user/1000/krb5cc_ea1f24ead9d3199b715d4d57505d4335/t (try running kinit) 
for exchange2007."
  [1]=>
  string(55) "SECURITY PROBLEM: insecure server advertised AUTH=PLAIN"
}

With the patch:
array(1) {
  [0]=>
  string(55) "SECURITY PROBLEM: insecure server advertised AUTH=PLAIN"
}


[2012-09-21 06:42:50] r...@php.net

This also affects php 5.3


[2012-09-21 06:33:46] r...@php.net

Description:

According to source code, DISABLE_AUTHENTICATOR could be a string or an array.

Works as expected:
imap_open($srv,$user,$pass,OP_HALF_OPEN,1,
   array('DISABLE_AUTHENTICATOR'=>'GSSAPI');

Doesn't works:
imap_open($srv,$user,$pass,OP_HALF_OPEN,1,
   array('DISABLE_AUTHENTICATOR'=>array('GSSAPI','NTLM'));


The trivial attached patch should fix this (but cannot test it)








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

Bug #63582 [Nab]: ReflectionClass->getProperties() omits private members of parent classes

2012-11-24 Thread anthon dot pang at gmail dot com

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

 ID: 63582
 User updated by:anthon dot pang at gmail dot com
 Reported by:anthon dot pang at gmail dot com
 Summary:ReflectionClass->getProperties() omits private
 members of parent classes
 Status: Not a bug
 Type:   Bug
 Package:Reflection related
 Operating System:   Ubuntu 12.04
 PHP Version:5.5.0alpha1
 Block user comment: N
 Private report: N

 New Comment:

Thanks for the explanation.


Previous Comments:

[2012-11-23 01:54:10] ahar...@php.net

Private properties and methods only exist within the exact class they are 
defined in: note that if you call getParentClass() on the $reflection object 
and then call getProperties() on that, "c" appears along with the other 
properties defined in Foo.


[2012-11-22 16:12:23] anthon dot pang at gmail dot com

Description:

getProperties() doesn't include "private" scoped properties from parent classes

Test script:
---
getProperties();

foreach ($propertyList as $property) {
var_dump($property->getName());
}

Expected result:

string(1) "d"
string(1) "e"
string(1) "f"
string(1) "a"
string(1) "b"
string(1) "c"

Actual result:
--
string(1) "d"
string(1) "e"
string(1) "f"
string(1) "a"
string(1) "b"






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

Req #62858 [Com]: Please remove 'final' restriction on SimpleXMLElement::__construct

2012-11-24 Thread anthon dot pang at gmail dot com

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

 ID: 62858
 Comment by: anthon dot pang at gmail dot com
 Reported by:michaelduff at yahoo dot com
 Summary:Please remove 'final' restriction on
 SimpleXMLElement::__construct
 Status: Open
 Type:   Feature/Change Request
 Package:SimpleXML related
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

Dupe of #46684


Previous Comments:

[2012-08-21 05:47:48] larue...@php.net

there must be some reason for the author mark the constructor as final, like 
some 
work must be done before any user access to it.


[2012-08-18 19:36:50] michaelduff at yahoo dot com

Description:

The __construct() method on SimpleXMLElement is marked 'final', which prevents 
extension of the class for, say, XML-format-specific objects which augment 
otherwise empty incoming XML data.

The current workaround is to use __get and __set and company (which 
unfortunately means  fails), and which 
is much slower -- or to use a static factory method which forces some XML in 
there (which is syntactically ugly imo.)

Not to shoot my request in the foot, but I forsee possible issues with these 
functions:

- simplexml_import_dom ( $node [, $class_name ] )
- simplexml_load_file ( string $filename [, string $class_name ] ... )
- simplexml_load_string ( string $data [, string $class_name ] ... )

However, perhaps it would suffice to require 'a compatible function signature' 
rather than to mark it final?







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

Bug #63591 [Opn->Fbk]: Can't write to properties of mysqli classes using Reflection API

2012-11-24 Thread reeze

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

 ID: 63591
 Updated by: re...@php.net
 Reported by:HMWiesinger at gmx dot at
 Summary:Can't write to properties of mysqli classes using
 Reflection API
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:MySQLi related
 Operating System:   Linux
 PHP Version:5.4.9
 Block user comment: N
 Private report: N

 New Comment:

affected_rows property is kinda readonly property, so we can't change
that with reflection apis or property value update. 

it makes the property reliable, I don't see a reason to change that,
I you really need to do that inherit it with a subclass.


Previous Comments:

[2012-11-23 20:07:34] HMWiesinger at gmx dot at

Description:

It doesn't seem to be possible to get write access to properties of mysqli 
classes 
using the Reflection API. 



Test script:
---
$mysqli = new MySQLi();
$reflection = new ReflectionClass('\MySQLi');

$property = $reflection->getProperty('affected_rows');
$property->setAccessible(TRUE);
$property->setValue($mysqli, 10);


Expected result:

No Error

Actual result:
--
Fatal error: ReflectionProperty::setValue(): Cannot write property






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

Bug #63575 [Opn]: Cloning are incorrect

2012-11-24 Thread laruence

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

 ID: 63575
 Updated by: larue...@php.net
 Reported by:vadimx at gmail dot com
 Summary:Cloning are incorrect
 Status: Open
 Type:   Bug
 Package:SimpleXML related
 Operating System:   Windows/Linux
 PHP Version:5.3.18
-Assigned To:
+Assigned To:helly
 Block user comment: N
 Private report: N

 New Comment:

helly, do you have time to look at this?


Previous Comments:

[2012-11-21 17:52:57] vadimx at gmail dot com

Description:

When changing child's in cloned object, it's change in parent object, not in 
cloned.

Test script:
---
$xml = '';

$o1 = new SimpleXMlElement($xml);
$o2 = clone $o1;

$r = current($o2->xpath('/a'));
$r->addChild('c',new SimpleXMlElement(''));

echo $o1->asXML();
echo PHP_EOL;
echo $o2->asXML();

Expected result:






Actual result:
--










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

Bug #60825 [Asn]: Segfault when running symfony 2 tests

2012-11-24 Thread laruence

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

 ID: 60825
 Updated by: larue...@php.net
 Reported by:php at wallbash dot com
 Summary:Segfault when running symfony 2 tests
 Status: Assigned
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 10.04.3 LTS
 PHP Version:5.4.0RC6
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

close, as the previous comment.


Previous Comments:

[2012-07-24 23:37:39] ras...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=cf54cc736bc27f18b9a27ed882ad87b1d2e7a2b3
Log: Fixed bug #60825 (Segfault when running symfony 2 tests)


[2012-07-24 23:37:36] ras...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=a222954a45df7af796e3c890075010bf0213773b
Log: Re-fixed bug #60825 (Segfault when running symfony 2 tests)


[2012-07-24 23:37:35] ras...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=498d9aea7f1ac60ccefd0de5e5d854c27d603900
Log: Fixed bug #60825 (Segfault when running symfony 2 tests)


[2012-06-27 08:37:15] maxime dot marais at gmail dot com

It seems this issue is solved with version 5.3.14 (http://bugs.php.net/61730). 
For my project, version 5.3.14 solved the issue that still occured with version 
5.3.13.

Could someone confirm?


[2012-05-31 02:16:28] larue...@php.net

@maxime dot marais at gmail dot com, okey,ãI will write to your mail. thanks




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


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

Bug #60825 [Asn->Csd]: Segfault when running symfony 2 tests

2012-11-24 Thread laruence

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

 ID: 60825
 Updated by: larue...@php.net
 Reported by:php at wallbash dot com
 Summary:Segfault when running symfony 2 tests
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 10.04.3 LTS
 PHP Version:5.4.0RC6
 Assigned To:laruence
 Block user comment: N
 Private report: N



Previous Comments:

[2012-11-24 16:01:53] larue...@php.net

close, as the previous comment.


[2012-07-24 23:37:39] ras...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=cf54cc736bc27f18b9a27ed882ad87b1d2e7a2b3
Log: Fixed bug #60825 (Segfault when running symfony 2 tests)


[2012-07-24 23:37:36] ras...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=a222954a45df7af796e3c890075010bf0213773b
Log: Re-fixed bug #60825 (Segfault when running symfony 2 tests)


[2012-07-24 23:37:35] ras...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=498d9aea7f1ac60ccefd0de5e5d854c27d603900
Log: Fixed bug #60825 (Segfault when running symfony 2 tests)


[2012-06-27 08:37:15] maxime dot marais at gmail dot com

It seems this issue is solved with version 5.3.14 (http://bugs.php.net/61730). 
For my project, version 5.3.14 solved the issue that still occured with version 
5.3.13.

Could someone confirm?




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


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

Req #62858 [Opn->Dup]: Please remove 'final' restriction on SimpleXMLElement::__construct

2012-11-24 Thread laruence

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

 ID: 62858
 Updated by: larue...@php.net
 Reported by:michaelduff at yahoo dot com
 Summary:Please remove 'final' restriction on
 SimpleXMLElement::__construct
-Status: Open
+Status: Duplicate
 Type:   Feature/Change Request
 Package:SimpleXML related
 PHP Version:5.4.6
 Block user comment: N
 Private report: N

 New Comment:

dup to #46684


Previous Comments:

[2012-11-24 15:01:01] anthon dot pang at gmail dot com

Dupe of #46684


[2012-08-21 05:47:48] larue...@php.net

there must be some reason for the author mark the constructor as final, like 
some 
work must be done before any user access to it.


[2012-08-18 19:36:50] michaelduff at yahoo dot com

Description:

The __construct() method on SimpleXMLElement is marked 'final', which prevents 
extension of the class for, say, XML-format-specific objects which augment 
otherwise empty incoming XML data.

The current workaround is to use __get and __set and company (which 
unfortunately means  fails), and which 
is much slower -- or to use a static factory method which forces some XML in 
there (which is syntactically ugly imo.)

Not to shoot my request in the foot, but I forsee possible issues with these 
functions:

- simplexml_import_dom ( $node [, $class_name ] )
- simplexml_load_file ( string $filename [, string $class_name ] ... )
- simplexml_load_string ( string $data [, string $class_name ] ... )

However, perhaps it would suffice to require 'a compatible function signature' 
rather than to mark it final?







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

Bug #63591 [Fbk->Nab]: Can't write to properties of mysqli classes using Reflection API

2012-11-24 Thread laruence

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

 ID: 63591
 Updated by: larue...@php.net
 Reported by:HMWiesinger at gmx dot at
 Summary:Can't write to properties of mysqli classes using
 Reflection API
-Status: Feedback
+Status: Not a bug
 Type:   Bug
 Package:MySQLi related
 Operating System:   Linux
 PHP Version:5.4.9
 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

mysqli link properties are designed to be read-only.

the write func for them throw that error:

static int mysqli_write_na(mysqli_object *obj, zval *newval TSRMLS_DC)
{
php_error_docref(NULL TSRMLS_CC, E_ERROR, "Cannot write property");
return FAILURE;
}


Previous Comments:

[2012-11-24 15:23:48] re...@php.net

affected_rows property is kinda readonly property, so we can't change
that with reflection apis or property value update. 

it makes the property reliable, I don't see a reason to change that,
I you really need to do that inherit it with a subclass.


[2012-11-23 20:07:34] HMWiesinger at gmx dot at

Description:

It doesn't seem to be possible to get write access to properties of mysqli 
classes 
using the Reflection API. 



Test script:
---
$mysqli = new MySQLi();
$reflection = new ReflectionClass('\MySQLi');

$property = $reflection->getProperty('affected_rows');
$property->setAccessible(TRUE);
$property->setValue($mysqli, 10);


Expected result:

No Error

Actual result:
--
Fatal error: ReflectionProperty::setValue(): Cannot write property






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

Bug #63126 [Csd]: DISABLE_AUTHENTICATOR ignores array

2012-11-24 Thread laruence

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

 ID: 63126
 Updated by: larue...@php.net
 Reported by:r...@php.net
 Summary:DISABLE_AUTHENTICATOR ignores array
 Status: Closed
 Type:   Bug
 Package:IMAP related
 Operating System:   GNU/Linux (Fedora 18)
 PHP Version:5.4.7
 Assigned To:remi
 Block user comment: N
 Private report: N

 New Comment:

@remi, please also commit your test script. thanks


Previous Comments:

[2012-11-24 14:04:12] r...@php.net

Automatic comment on behalf of remi
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=f55bed9dad0ffbec170b857c0b3b1b33426fe9d5
Log: Fixed Bug #63126 DISABLE_AUTHENTICATOR ignores array


[2012-11-24 14:03:18] r...@php.net

Automatic comment on behalf of remi
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=f55bed9dad0ffbec170b857c0b3b1b33426fe9d5
Log: Fixed Bug #63126 DISABLE_AUTHENTICATOR ignores array


[2012-11-24 14:02:12] r...@php.net

Automatic comment on behalf of remi
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=f55bed9dad0ffbec170b857c0b3b1b33426fe9d5
Log: Fixed Bug #63126 DISABLE_AUTHENTICATOR ignores array


[2012-11-24 13:59:51] r...@php.net

Automatic comment on behalf of remi
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=f55bed9dad0ffbec170b857c0b3b1b33426fe9d5
Log: Fixed Bug #63126 DISABLE_AUTHENTICATOR ignores array


[2012-09-21 07:55:31] r...@php.net

I try to send my first pull request, I hope this is ok
https://github.com/php/php-src/pull/200




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


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

Bug #63149 [Opn->Asn]: Feature missing with system SQLite

2012-11-24 Thread remi

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

 ID: 63149
 Updated by: r...@php.net
 Reported by:r...@php.net
 Summary:Feature missing with system SQLite
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:SQLite related
 Operating System:   GNU/Linux (Fedora 18)
 PHP Version:5.4.7
-Assigned To:
+Assigned To:remi
 Block user comment: N
 Private report: N



Previous Comments:

[2012-09-24 11:55:56] r...@php.net

Please consider https://github.com/php/php-src/pull/203


[2012-09-24 11:51:17] r...@php.net

Description:

When build against bundled SQLite, SQLITE_ENABLE_COLUMN_METADATA is defined, so 
sqlite3_column_table_name is know as available and used in pdo_sqlite (for 
getColumnMeta)

When build against system SQlite, availability of sqlite3_column_table_name is 
not checked.

This make bug_42589 fail.

I will submit a pull request with the fix.







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

Bug #63149 [Asn->Csd]: Feature missing with system SQLite

2012-11-24 Thread remi

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

 ID: 63149
 Updated by: r...@php.net
 Reported by:r...@php.net
 Summary:Feature missing with system SQLite
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:SQLite related
 Operating System:   GNU/Linux (Fedora 18)
 PHP Version:5.4.7
 Assigned To:remi
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of remi
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=67e67c254d25442dc4d98342e53f791b0a710a5a
Log: Fixed Bug #63149 Feature missing with system SQLite


Previous Comments:

[2012-09-24 11:55:56] r...@php.net

Please consider https://github.com/php/php-src/pull/203


[2012-09-24 11:51:17] r...@php.net

Description:

When build against bundled SQLite, SQLITE_ENABLE_COLUMN_METADATA is defined, so 
sqlite3_column_table_name is know as available and used in pdo_sqlite (for 
getColumnMeta)

When build against system SQlite, availability of sqlite3_column_table_name is 
not checked.

This make bug_42589 fail.

I will submit a pull request with the fix.







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

[PHP-BUG] Bug #63596 [NEW]: finally in generators segfaults since the new finally implementation

2012-11-24 Thread ni...@php.net

From: nikic
Operating system: 
PHP version:  master-Git-2012-11-24 (Git)
Package:  Scripting Engine problem
Bug Type: Bug
Bug description:finally in generators segfaults since the new finally 
implementation

Description:

Since
https://github.com/php/php-src/commit/eb4825b50b1f4d20b574d8f66acf26e35180e7e6
the test Zend/tests/generators/finally_ran_on_close.phpt segfaults.

Output:

before yield
finally run
Segmentation fault (core dumped)

Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x086c6e21 in execute_ex (execute_data=0xb7fb868c, tsrm_ls=0x8d4a070)
at /home/nikic/dev/php-src/Zend/zend_vm_execute.h:435
435 if ((ret = OPLINE->handler(execute_data TSRMLS_CC)) > 
0) {
(gdb) bt
#0  0x086c6e21 in execute_ex (execute_data=0xb7fb868c, tsrm_ls=0x8d4a070)
at /home/nikic/dev/php-src/Zend/zend_vm_execute.h:435
#1  0x086b43d7 in zend_generator_resume (generator=0xb7fb7f20, 
tsrm_ls=0x8d4a070) at
/home/nikic/dev/php-src/Zend/zend_generators.c:535
#2  0x086b2bf6 in zend_generator_close (generator=0xb7fb7f20, 
finished_execution=0 '\000', tsrm_ls=0x8d4a070)
at /home/nikic/dev/php-src/Zend/zend_generators.c:64
#3  0x086b30b1 in zend_generator_free_storage (generator=0xb7fb7f20, 
tsrm_ls=0x8d4a070) at
/home/nikic/dev/php-src/Zend/zend_generators.c:195
#4  0x086bfb8e in zend_objects_store_del_ref_by_handle_ex (handle=1, 
handlers=0x8d47700, tsrm_ls=0x8d4a070)
at /home/nikic/dev/php-src/Zend/zend_objects_API.c:220
#5  0x086bf7fd in zend_objects_store_del_ref (zobject=0xb7fb6214, 
tsrm_ls=0x8d4a070) at
/home/nikic/dev/php-src/Zend/zend_objects_API.c:172
#6  0x08684659 in _zval_dtor_func (zvalue=0xb7fb6214, 
__zend_filename=0x8c87e44
"/home/nikic/dev/php-src/Zend/zend_execute_API.c", __zend_lineno=439) at
/home/nikic/dev/php-src/Zend/zend_variables.c:54
#7  0x08672b43 in _zval_dtor (__zend_lineno=, 
__zend_filename=0x8c87e44
"/home/nikic/dev/php-src/Zend/zend_execute_API.c", zvalue=0xb7fb6214) at
/home/nikic/dev/php-src/Zend/zend_variables.h:35
#8  _zval_ptr_dtor (zval_ptr=0xb7fb7bc0, 
__zend_filename=0x8c89164
"/home/nikic/dev/php-src/Zend/zend_variables.c", 
__zend_lineno=182) at
/home/nikic/dev/php-src/Zend/zend_execute_API.c:439
#9  0x08684a5e in _zval_ptr_dtor_wrapper (zval_ptr=0xb7fb7bc0)
at /home/nikic/dev/php-src/Zend/zend_variables.c:182
#10 0x08698ac5 in zend_hash_del_key_or_index (ht=0x8d4bb88, 
arKey=0xb7fb7da4 "gen", nKeyLength=4, h=2090288735, flag=2)
at /home/nikic/dev/php-src/Zend/zend_hash.c:531
#11 0x08677af9 in zend_delete_variable (ex=0x0, ht=0x8d4bb88, 
name=0xb7fb7da4 "gen", name_len=4, hash_value=2090288735, 
tsrm_ls=0x8d4a070) at
/home/nikic/dev/php-src/Zend/zend_execute_API.c:1703
#12 0x087d8ec9 in ZEND_UNSET_VAR_SPEC_CV_UNUSED_HANDLER (
execute_data=0xb7f9a07c, tsrm_ls=0x8d4a070)
at /home/nikic/dev/php-src/Zend/zend_vm_execute.h:38546
#13 0x086c6e2d in execute_ex (execute_data=0xb7f9a07c, tsrm_ls=0x8d4a070)
at /home/nikic/dev/php-src/Zend/zend_vm_execute.h:435
#14 0x086c6f18 in execute (op_array=0xb7fb6acc, tsrm_ls=0x8d4a070)
at /home/nikic/dev/php-src/Zend/zend_vm_execute.h:460
#15 0x08688d5d in zend_execute_scripts (type=8, tsrm_ls=0x8d4a070,
retval=0x0, 
file_count=3) at /home/nikic/dev/php-src/Zend/zend.c:1309
#16 0x085ea548 in php_execute_script (primary_file=0xbfffe0d0, 
tsrm_ls=0x8d4a070) at /home/nikic/dev/php-src/main/main.c:2468
#17 0x087e75b1 in do_cli (argc=2, argv=0xb374, tsrm_ls=0x8d4a070)
at /home/nikic/dev/php-src/sapi/cli/php_cli.c:988
#18 0x087e8aec in main (argc=2, argv=0xb374)
at /home/nikic/dev/php-src/sapi/cli/php_cli.c:1364


The relevant code in the generator storage free handler:
http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_generators.c#36.



-- 
Edit bug report at https://bugs.php.net/bug.php?id=63596&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=63596&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=63596&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=63596&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=63596&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=63596&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63596&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=63596&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=63596&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63596&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=63596&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63596&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63596&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=63596&r=globals
PHP 4 support discontinued: https://bugs.php.net/

Bug #63591 [Nab]: Can't write to properties of mysqli classes using Reflection API

2012-11-24 Thread HMWiesinger at gmx dot at

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

 ID: 63591
 User updated by:HMWiesinger at gmx dot at
 Reported by:HMWiesinger at gmx dot at
 Summary:Can't write to properties of mysqli classes using
 Reflection API
 Status: Not a bug
 Type:   Bug
 Package:MySQLi related
 Operating System:   Linux
 PHP Version:5.4.9
 Block user comment: N
 Private report: N

 New Comment:

I understand that making the properties (not only affected_rows) readonly 
ensures certain integrity. No arguing there.

What I'm trying to do is mock the MySQLi class (and some others) for unit 
testing. Mocking the methods works fine, but the properties have been a bit of 
a 
difficulty. My solution so far was to hook in behind MySQLi and mock the actual 
database connection using mysqlnd_uh. But that is not working (yet) with 5.4 
and 
no real estimations of when that will be fixed. With 5.5 drawing nearer, I was 
looking at alternative ways to do this. I tried subclassing MySQLi as well, 
that 
didn't work either.


Previous Comments:

[2012-11-24 16:20:09] larue...@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

mysqli link properties are designed to be read-only.

the write func for them throw that error:

static int mysqli_write_na(mysqli_object *obj, zval *newval TSRMLS_DC)
{
php_error_docref(NULL TSRMLS_CC, E_ERROR, "Cannot write property");
return FAILURE;
}


[2012-11-24 15:23:48] re...@php.net

affected_rows property is kinda readonly property, so we can't change
that with reflection apis or property value update. 

it makes the property reliable, I don't see a reason to change that,
I you really need to do that inherit it with a subclass.


[2012-11-23 20:07:34] HMWiesinger at gmx dot at

Description:

It doesn't seem to be possible to get write access to properties of mysqli 
classes 
using the Reflection API. 



Test script:
---
$mysqli = new MySQLi();
$reflection = new ReflectionClass('\MySQLi');

$property = $reflection->getProperty('affected_rows');
$property->setAccessible(TRUE);
$property->setValue($mysqli, 10);


Expected result:

No Error

Actual result:
--
Fatal error: ReflectionProperty::setValue(): Cannot write property






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

Bug #60598 [Com]: cli/apache sapi segfault on objects manipulation

2012-11-24 Thread manuel-php at mausz dot at

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

 ID: 60598
 Comment by: manuel-php at mausz dot at
 Reported by:arekm at maven dot pl
 Summary:cli/apache sapi segfault on objects manipulation
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Linux
 PHP Version:5.4.0RC3
 Block user comment: N
 Private report: N

 New Comment:

Hi,

I've tried to debug this yesterday but was unable to come up with a working 
fix. So I decided to share my results. Maybe someone with more in-depth 
knowledge of the php gc/heap can fix it more easily now.

First of all: The problem is also reproducible with 2 (and more) objects. It 
just doesn't crash due to phps memory heap. The corruption occurs during PHPs 
garbage collection which kicks in just after __destruct() but before releasing 
the objects. Since GC_ROOT_BUFFER_MAX_ENTRIES is 1 per default you'll see 
heap memory corruption warnings starting at 9994 objects (looks like 6 other 
zvals are created during startup). Reducing GC_ROOT_BUFFER_MAX_ENTRIES to 8 
allows to reduce OBJECT_COUNT (in the example script from arekm) to 2. Another 
more simple solution is to call gc_collect_cycles() in __destruct() just after 
unset(...).

So here comes my (stripped down) debug output (verified via valgrind + gdb):
* GC_ROOT_BUFFER_MAX_ENTRIES=default (10k)
* OBJECT_COUNT=2
* call gc_collect_cycles() in __destruct()
* abbr.: pt ...(object) properties_table

[...]
[object_properties_init]
  name=Object addr=b20d9d88 pt_addr=b20d9808
  pt[0]_addr=b20d6148 pt[0].handle=#0
[zend_std_write_property]
  name=_guid (=pt[0])
  old_addr=b20d6148 new_addr=b20d9db8 new.handle=#0

[...]
[zval_collect_white]
  adding zval to zval_to_free-list
  zval: addr=b20d9db8 refcnt=2 handle=#0
[gc_collect_cycles]
  freeing zval
  zval: addr=b20d9db8 refcnt=2 handle=#0

[...]
[zend_object_std_dtor]
  object=Object addr=b20d9d88 pt_addr=b20d9808
  calling zval_ptr_dtor for pt[0]_addr=b20d9db8 pt[0].handle=#-1307730616

[...]

Hope this helps.


Previous Comments:

[2012-03-16 15:56:14] eugen at kochuev dot com

We also face the similar issue in symfony 1.4 project. Issue appears in %.3 and 
5.4 versions and does not happen in 5.2. Disabling GC makes segfaults less 
frequent, but still does not solve the problem.


[2012-01-08 10:26:09] arekm at maven dot pl

PHP 5.4.0 RC5 also dies

$ ~/test/php-test/bin/php --version
PHP 5.4.0RC5 (cli) (built: Jan  8 2012 11:23:44)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies


[arekm@ixion-pld php-5.4.0RC5]$ ~/test/php-test/bin/php ~/a.php
If you see this, try to increase OBJECT_COUNT to 100,000Segmentation fault


[2012-01-06 14:09:16] daan at react dot com

Looks alot like https://bugs.php.net/bug.php?id=39346 

Curiously, the segfault looks alot like https://bugs.php.net/bug.php?id=60457 - 
but that might just be PHPs reaction to memory corruption.


[2011-12-22 22:33:07] arekm at maven dot pl

Description:

[arekm@ixion-pld php-5.4.0RC3]$ export LC_ALL=C
[arekm@ixion-pld php-5.4.0RC3]$ ./sapi/cli/php -n ~/a.php
If you see this, try to increase OBJECT_COUNT to 100,000Segmentation fault
[arekm@ixion-pld php-5.4.0RC3]$ ./sapi/cli/php -n --version
PHP 5.4.0RC3 (cli) (built: Dec 22 2011 23:19:37)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies

Test script:
---
_guid = self::$maxGuid++] = $this;
}
public function __destruct() {
 unset(self::$world[$this->_guid]);
}
}

for ($i = 0; $i < OBJECT_COUNT; ++$i) {
new Object();
}

// You probably won't see this because of the "zend_mm_heap corrupted"
echo 'If you see this, try to increase OBJECT_COUNT to 100,000';
?>

Expected result:

cli not segfaulting

Actual result:
--
Starting program: /home/users/arekm/rpm/BUILD/php-5.4.0RC3/sapi/cli/.libs/php 
-n 
/home/users/arekm/a.php
[Thread debugging using libthread_db enabled]
If you see this, try to increase OBJECT_COUNT to 100,000
Program received signal SIGSEGV, Segmentation fault.
0x77a462b9 in gc_zval_possible_root (zv=0x75677420) at 
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/Zend/zend_gc.c:143
143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);
(gdb) bt
#0  0x77a462b9 in gc_zval_possible_root (zv=0x75677420) at 
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/Zend/zend_gc.c:143
#1  0x77a48ba2 in zend_object_std_dtor (object=0x756773d0) at 
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/Zend/zend_objects.c:54
#2  0x77a48bd9 in zend_objects_free_object_

Bug #63596 [Opn->Csd]: finally in generators segfaults since the new finally implementation

2012-11-24 Thread nikic

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

 ID: 63596
 Updated by: ni...@php.net
 Reported by:ni...@php.net
 Summary:finally in generators segfaults since the new
 finally implementation
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Scripting Engine problem
 PHP Version:master-Git-2012-11-24 (Git)
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of nikic
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=60871e51ada0644f258c991d67adba22d38f8a7b
Log: Fix bug #63596: finally in generators segfaults


Previous Comments:

[2012-11-24 16:57:50] ni...@php.net

Description:

Since 
https://github.com/php/php-src/commit/eb4825b50b1f4d20b574d8f66acf26e35180e7e6 
the test Zend/tests/generators/finally_ran_on_close.phpt segfaults.

Output:

before yield
finally run
Segmentation fault (core dumped)

Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x086c6e21 in execute_ex (execute_data=0xb7fb868c, tsrm_ls=0x8d4a070)
at /home/nikic/dev/php-src/Zend/zend_vm_execute.h:435
435 if ((ret = OPLINE->handler(execute_data TSRMLS_CC)) > 
0) {
(gdb) bt
#0  0x086c6e21 in execute_ex (execute_data=0xb7fb868c, tsrm_ls=0x8d4a070)
at /home/nikic/dev/php-src/Zend/zend_vm_execute.h:435
#1  0x086b43d7 in zend_generator_resume (generator=0xb7fb7f20, 
tsrm_ls=0x8d4a070) at /home/nikic/dev/php-src/Zend/zend_generators.c:535
#2  0x086b2bf6 in zend_generator_close (generator=0xb7fb7f20, 
finished_execution=0 '\000', tsrm_ls=0x8d4a070)
at /home/nikic/dev/php-src/Zend/zend_generators.c:64
#3  0x086b30b1 in zend_generator_free_storage (generator=0xb7fb7f20, 
tsrm_ls=0x8d4a070) at /home/nikic/dev/php-src/Zend/zend_generators.c:195
#4  0x086bfb8e in zend_objects_store_del_ref_by_handle_ex (handle=1, 
handlers=0x8d47700, tsrm_ls=0x8d4a070)
at /home/nikic/dev/php-src/Zend/zend_objects_API.c:220
#5  0x086bf7fd in zend_objects_store_del_ref (zobject=0xb7fb6214, 
tsrm_ls=0x8d4a070) at /home/nikic/dev/php-src/Zend/zend_objects_API.c:172
#6  0x08684659 in _zval_dtor_func (zvalue=0xb7fb6214, 
__zend_filename=0x8c87e44 
"/home/nikic/dev/php-src/Zend/zend_execute_API.c", __zend_lineno=439) at 
/home/nikic/dev/php-src/Zend/zend_variables.c:54
#7  0x08672b43 in _zval_dtor (__zend_lineno=, 
__zend_filename=0x8c87e44 
"/home/nikic/dev/php-src/Zend/zend_execute_API.c", zvalue=0xb7fb6214) at 
/home/nikic/dev/php-src/Zend/zend_variables.h:35
#8  _zval_ptr_dtor (zval_ptr=0xb7fb7bc0, 
__zend_filename=0x8c89164 "/home/nikic/dev/php-src/Zend/zend_variables.c", 
__zend_lineno=182) at /home/nikic/dev/php-src/Zend/zend_execute_API.c:439
#9  0x08684a5e in _zval_ptr_dtor_wrapper (zval_ptr=0xb7fb7bc0)
at /home/nikic/dev/php-src/Zend/zend_variables.c:182
#10 0x08698ac5 in zend_hash_del_key_or_index (ht=0x8d4bb88, 
arKey=0xb7fb7da4 "gen", nKeyLength=4, h=2090288735, flag=2)
at /home/nikic/dev/php-src/Zend/zend_hash.c:531
#11 0x08677af9 in zend_delete_variable (ex=0x0, ht=0x8d4bb88, 
name=0xb7fb7da4 "gen", name_len=4, hash_value=2090288735, 
tsrm_ls=0x8d4a070) at /home/nikic/dev/php-src/Zend/zend_execute_API.c:1703
#12 0x087d8ec9 in ZEND_UNSET_VAR_SPEC_CV_UNUSED_HANDLER (
execute_data=0xb7f9a07c, tsrm_ls=0x8d4a070)
at /home/nikic/dev/php-src/Zend/zend_vm_execute.h:38546
#13 0x086c6e2d in execute_ex (execute_data=0xb7f9a07c, tsrm_ls=0x8d4a070)
at /home/nikic/dev/php-src/Zend/zend_vm_execute.h:435
#14 0x086c6f18 in execute (op_array=0xb7fb6acc, tsrm_ls=0x8d4a070)
at /home/nikic/dev/php-src/Zend/zend_vm_execute.h:460
#15 0x08688d5d in zend_execute_scripts (type=8, tsrm_ls=0x8d4a070, retval=0x0, 
file_count=3) at /home/nikic/dev/php-src/Zend/zend.c:1309
#16 0x085ea548 in php_execute_script (primary_file=0xbfffe0d0, 
tsrm_ls=0x8d4a070) at /home/nikic/dev/php-src/main/main.c:2468
#17 0x087e75b1 in do_cli (argc=2, argv=0xb374, tsrm_ls=0x8d4a070)
at /home/nikic/dev/php-src/sapi/cli/php_cli.c:988
#18 0x087e8aec in main (argc=2, argv=0xb374)
at /home/nikic/dev/php-src/sapi/cli/php_cli.c:1364


The relevant code in the generator storage free handler: 
http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_generators.c#36.








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

Bug #52339 [Com]: SPL autoloader breaks class_exists()

2012-11-24 Thread ciantic at oksidi dot com

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

 ID: 52339
 Comment by: ciantic at oksidi dot com
 Reported by:dangerous dot ben at gmail dot com
 Summary:SPL autoloader breaks class_exists()
 Status: Re-Opened
 Type:   Bug
 Package:SPL related
 Operating System:   any (debian)
 PHP Version:5.3.3RC2
 Block user comment: N
 Private report: N

 New Comment:

Is this bug still happening in PHP5.4 and greater? I'm using 5.3.8.

If one uses class_exists it should never throw error, only true or false. It 
makes 
no sense otherwise. This is one of those where setting of some other 
application 
can totally broke functionality elsewhere. Should everyone using class_exists 
catch try LogicException too? I'd argue not.

Though the workaround (empty function for spl) is kind of nice, as dangerous 
dot 
ben mentioned.


Previous Comments:

[2012-08-08 16:18:39] kilbyc at bellsouth dot net

Even worse. The no arg register is inconsistent.



If the autoload stack is empty by the time the no arg registered is called, how 
can it function differently than if the autoload stack has been emptied by the 
time the no arg register is called?

This is nonsensical behavior, and manual for spl_autoload say nothing about it 
throwing. Let alone LogicException. I would have expected this to be a 
RuntimeException. As it depends on the specific environment it is run in as to 
whether or not spl_autoload will find something.


[2012-08-08 16:02:40] kilbyc at bellsouth dot net

PHP 5.3.8 (cli) (built: Aug 23 2011 11:50:20)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies




spl_autoload is inconsistent with itself.


[2012-03-16 22:02:29] pwolfenden at qualys dot com

Although I have not yet migrated to 5.3, I care about this bug because I'm 
using 
an autoload function (in 5.2) which contains some directory traversal logic and 
uses class_exists() to decide whether or not to keep looking. I need to do this 
because I'm in the scenario described by james (and so cannot assume that all 
the 
package files in my codebase follow my preferred naming convention), and I 
would 
much prefer class_exists() to continue to return false rather than having it 
throw 
a new Exception.


[2012-02-03 00:01:46] frozenf...@php.net

Re-opening, as there still exists the conflict of class_exists() generating an 
error when autoloading fails, which is a chicken and the egg sort of issue. If 
one wants to try autoloading if the class doesn't exist, but autoloading fails, 
it should be possible to recover from that failure.

My understanding of the underlying code is that it generates an error in this 
case. Perhaps it should generate an exception, which can be caught an handled.


[2010-10-11 21:37:47] james at nearlysensical dot com

I 100% agree with dangerous dot ben. class_exists should return false if the 
class 
can't be autoloaded. Allowing it to do so would make it much easier to use an 
autoloader in contexts where you're interacting with an existing codebase that 
may 
not be so spl_autoload friendly. Bump.




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


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

Bug #62524 [Com]: fopen follows redirects for non-3xx statuses

2012-11-24 Thread wes at serverdensity dot com

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

 ID: 62524
 Comment by: wes at serverdensity dot com
 Reported by:mike dot hall at twistdigital dot co dot uk
 Summary:fopen follows redirects for non-3xx statuses
 Status: Open
 Type:   Bug
 Package:Streams related
 Operating System:   Ubuntu 12.04
 PHP Version:5.4.4
 Block user comment: N
 Private report: N

 New Comment:

I've submitted a patch for this via Github pull request: 
https://github.com/php/php-src/pull/236


Previous Comments:

[2012-07-12 14:34:17] Sjon at hortensius dot net

A more complete example confirms this behavior:

I also fixed some syntax errors

http://php.net', true, 201);

if (isset($_GET['waa']))
return;

$context = stream_context_create(array(
"http" => array(
"method"  => "POST",
"header"  => "Content-Length: 13",
"content" => "{\"foo\":\"bar\"}",
),
));

$fp = fopen('http://'.$_SERVER['SERVER_NAME']. $_SERVER['PHP_SELF'] .'?waa=1', 
'r', null, $context);
print(stream_get_contents($fp));


[2012-07-10 16:00:52] mike dot hall at twistdigital dot co dot uk

Description:

The HTTP location header can either be used to direct the user to another 
resource (when accompanied by a 3xx status code) or to inform the user of the 
location of the document they just created (with a 2xx) status code.

It doesn't make sense to treat the location header as a redirect in the second 
context - the location header indicates a redirect only when accompanied by a 
3xx 
status code.

Currently, PHP follows Location headers as if they are redirects regardless of 
the returned status code.

Test script:
---
$context = stream_context_create([
"http" => [
"method"  => "POST"
"header"  => "Content-Length: 13"
"content" => "{\"foo\":\"bar\"}",
],
]);

// Returns HTTP/1.1 201 Created
// Location: http://example.com/mydb/documentid
//
// {"status":"ok"}
$fp = fopen('http://example.com/mydb', 'r', null, $context);
$data = stream_get_contents($fp);

list($headers, $body) = explode("\r\n\r\n", $data, 2);
echo $body;

Expected result:

{"status":"ok"}

Actual result:
--
{"foo":"bar"}






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

Bug #60285 [Opn->Csd]: setting REPORT_EXIT_STATUS for make test won't work

2012-11-24 Thread laruence

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

 ID: 60285
 Updated by: larue...@php.net
 Reported by:tyr...@php.net
 Summary:setting REPORT_EXIT_STATUS for make test won't work
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Testing related
 PHP Version:trunk-SVN-2011-11-13 (SVN)
-Assigned To:
+Assigned To:laruence
 Block user comment: N
 Private report: N



Previous Comments:

[2012-06-21 03:21:51] reeze dot xia at gmail dot com

Yes, I got the same problem,  I use Travis to test my extension, but make test 
didn't report failed test correctly. 

http://travis-ci.org/#!/reeze/php-sundown/jobs/1670528

That commit ignore the status code, the lastest version add another command 
after run-test: 

rm $(top_builddir)/tmp-php.ini; \

This makes it never return exit code.
--


[2011-11-13 18:45:24] tyr...@php.net

I just checked, it was introduced way back in 2003:
http://svn.php.net/viewvc?view=revision&revision=135844


[2011-11-13 18:35:57] tyr...@php.net

Description:

when setting up the ci environment, I noticed, that passing the 
REPORT_EXIT_STATUS 
environment variable to run-tests.php works, but passing the same thing to make 
test won't.
after some debugging with Hannes, we figured out, that the test target in the 
Makefile overuses the error suppression 
operator(http://sunsite.ualberta.ca/Documentation/Gnu/make-
3.79/html_chapter/make_5.html#SEC48).
if you check the test target (http://svn.php.net/viewvc/php/php-
src/trunk/Makefile.global?view=markup#l88) you can see that the whole target is 
a 
one-liner prefixed with -
which means that anything can fail in the target, it will still report success. 
:/

the same pattern is used for many of the targets.
Could somebody look into this?

Test script:
---
REPORT_EXIT_STATUS=1 make test;
echo $?;

Expected result:

should print non-zero if there are failed tests.

Actual result:
--
always prints 0






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

Bug #60598 [Opn->Fbk]: cli/apache sapi segfault on objects manipulation

2012-11-24 Thread laruence

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

 ID: 60598
 Updated by: larue...@php.net
 Reported by:arekm at maven dot pl
 Summary:cli/apache sapi segfault on objects manipulation
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Linux
 PHP Version:5.4.0RC3
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

  http://snaps.php.net/php5.4-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

I can not reproduce this,

could you please try with new version PHP-5.4.x?

thanks


Previous Comments:

[2012-11-24 17:46:34] manuel-php at mausz dot at

Hi,

I've tried to debug this yesterday but was unable to come up with a working 
fix. So I decided to share my results. Maybe someone with more in-depth 
knowledge of the php gc/heap can fix it more easily now.

First of all: The problem is also reproducible with 2 (and more) objects. It 
just doesn't crash due to phps memory heap. The corruption occurs during PHPs 
garbage collection which kicks in just after __destruct() but before releasing 
the objects. Since GC_ROOT_BUFFER_MAX_ENTRIES is 1 per default you'll see 
heap memory corruption warnings starting at 9994 objects (looks like 6 other 
zvals are created during startup). Reducing GC_ROOT_BUFFER_MAX_ENTRIES to 8 
allows to reduce OBJECT_COUNT (in the example script from arekm) to 2. Another 
more simple solution is to call gc_collect_cycles() in __destruct() just after 
unset(...).

So here comes my (stripped down) debug output (verified via valgrind + gdb):
* GC_ROOT_BUFFER_MAX_ENTRIES=default (10k)
* OBJECT_COUNT=2
* call gc_collect_cycles() in __destruct()
* abbr.: pt ...(object) properties_table

[...]
[object_properties_init]
  name=Object addr=b20d9d88 pt_addr=b20d9808
  pt[0]_addr=b20d6148 pt[0].handle=#0
[zend_std_write_property]
  name=_guid (=pt[0])
  old_addr=b20d6148 new_addr=b20d9db8 new.handle=#0

[...]
[zval_collect_white]
  adding zval to zval_to_free-list
  zval: addr=b20d9db8 refcnt=2 handle=#0
[gc_collect_cycles]
  freeing zval
  zval: addr=b20d9db8 refcnt=2 handle=#0

[...]
[zend_object_std_dtor]
  object=Object addr=b20d9d88 pt_addr=b20d9808
  calling zval_ptr_dtor for pt[0]_addr=b20d9db8 pt[0].handle=#-1307730616

[...]

Hope this helps.


[2012-03-16 15:56:14] eugen at kochuev dot com

We also face the similar issue in symfony 1.4 project. Issue appears in %.3 and 
5.4 versions and does not happen in 5.2. Disabling GC makes segfaults less 
frequent, but still does not solve the problem.


[2012-01-08 10:26:09] arekm at maven dot pl

PHP 5.4.0 RC5 also dies

$ ~/test/php-test/bin/php --version
PHP 5.4.0RC5 (cli) (built: Jan  8 2012 11:23:44)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies


[arekm@ixion-pld php-5.4.0RC5]$ ~/test/php-test/bin/php ~/a.php
If you see this, try to increase OBJECT_COUNT to 100,000Segmentation fault


[2012-01-06 14:09:16] daan at react dot com

Looks alot like https://bugs.php.net/bug.php?id=39346 

Curiously, the segfault looks alot like https://bugs.php.net/bug.php?id=60457 - 
but that might just be PHPs reaction to memory corruption.


[2011-12-22 22:33:07] arekm at maven dot pl

Description:

[arekm@ixion-pld php-5.4.0RC3]$ export LC_ALL=C
[arekm@ixion-pld php-5.4.0RC3]$ ./sapi/cli/php -n ~/a.php
If you see this, try to increase OBJECT_COUNT to 100,000Segmentation fault
[arekm@ixion-pld php-5.4.0RC3]$ ./sapi/cli/php -n --version
PHP 5.4.0RC3 (cli) (built: Dec 22 2011 23:19:37)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies

Test script:
---
_guid = self::$maxGuid++] = $this;
}
public function __destruct() {
 unset(self::$world[$this->_guid]);
}
}

for ($i = 0; $i < OBJECT_COUNT; ++$i) {
new Object();
}

// You probably won't see this because of the "zend_mm_heap corrupted"
echo 'If you see this, try to increase OBJECT_COUNT to 100,000';
?>

Expected result:

cli not segfaulting

Actual result:
--
Starting program: /home/users/arekm/rpm/BUILD/php-5.4.0RC3/sapi/cli/.libs/php 
-n 
/home/users/arekm/a.php
[Thread debugging using libthread_db enabled]
If you see this, try to increase OBJECT_COUNT to 100,000
Program received signal SIGSEGV, Segmentation fault.
0x77a462b9 in gc_zval_possible_root (zv=0x75677420) at 
/home/users/arekm/rpm/BUILD/php-5.4.0RC3/Zend/zend_gc.c:143
143 GC_ZOB

Bug #63591 [Nab]: Can't write to properties of mysqli classes using Reflection API

2012-11-24 Thread laruence

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

 ID: 63591
 Updated by: larue...@php.net
 Reported by:HMWiesinger at gmx dot at
 Summary:Can't write to properties of mysqli classes using
 Reflection API
 Status: Not a bug
 Type:   Bug
 Package:MySQLi related
 Operating System:   Linux
 PHP Version:5.4.9
 Block user comment: N
 Private report: N

 New Comment:

hmm, yes, subclass still use that write_func.

a solution might be use composite, like:

class MysqliMock {
   public $mysqli;
   public function __construct() {
$this->mysqli = new MySQLi();
   }
   public function __call($method, $args) {
call_user_func_array(array($this->mysqli, "method"), $args)
   
   }

   public function __get($name) {
 //you can mock the properties here
   }

   public function __set($name, $value) {

   }
}
?>

what do you think? thanks


Previous Comments:

[2012-11-24 17:28:53] HMWiesinger at gmx dot at

I understand that making the properties (not only affected_rows) readonly 
ensures certain integrity. No arguing there.

What I'm trying to do is mock the MySQLi class (and some others) for unit 
testing. Mocking the methods works fine, but the properties have been a bit of 
a 
difficulty. My solution so far was to hook in behind MySQLi and mock the actual 
database connection using mysqlnd_uh. But that is not working (yet) with 5.4 
and 
no real estimations of when that will be fixed. With 5.5 drawing nearer, I was 
looking at alternative ways to do this. I tried subclassing MySQLi as well, 
that 
didn't work either.


[2012-11-24 16:20:09] larue...@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

mysqli link properties are designed to be read-only.

the write func for them throw that error:

static int mysqli_write_na(mysqli_object *obj, zval *newval TSRMLS_DC)
{
php_error_docref(NULL TSRMLS_CC, E_ERROR, "Cannot write property");
return FAILURE;
}


[2012-11-24 15:23:48] re...@php.net

affected_rows property is kinda readonly property, so we can't change
that with reflection apis or property value update. 

it makes the property reliable, I don't see a reason to change that,
I you really need to do that inherit it with a subclass.


[2012-11-23 20:07:34] HMWiesinger at gmx dot at

Description:

It doesn't seem to be possible to get write access to properties of mysqli 
classes 
using the Reflection API. 



Test script:
---
$mysqli = new MySQLi();
$reflection = new ReflectionClass('\MySQLi');

$property = $reflection->getProperty('affected_rows');
$property->setAccessible(TRUE);
$property->setValue($mysqli, 10);


Expected result:

No Error

Actual result:
--
Fatal error: ReflectionProperty::setValue(): Cannot write property






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

Bug #63361 [Opn->Asn]: Header not installed

2012-11-24 Thread remi

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

 ID: 63361
 Updated by: r...@php.net
 Reported by:r...@php.net
 Summary:Header not installed
-Status: Open
+Status: Assigned
 Type:   Bug
 Package:MySQLi related
 Operating System:   GNU/Linux (Fedora 18)
 PHP Version:5.4.8
-Assigned To:
+Assigned To:remi
 Block user comment: N
 Private report: N



Previous Comments:

[2012-10-25 12:47:59] r...@php.net

Description:

In ext/mysqli/php_mysqli_structs.h (snipped for readability):

#ifdef MYSQLI_USE_MYSQLND
...
#include "mysqli_mysqlnd.h"
...
#else
...
#include "mysqli_libmysql.h"
...
#endif

So installed php_mysqli_structs.h is unusable without 
mysqli_mysqlnd.h/mysqli_libmysql.h which are not installed.








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

Bug #63361 [Asn->Csd]: Header not installed

2012-11-24 Thread remi

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

 ID: 63361
 Updated by: r...@php.net
 Reported by:r...@php.net
 Summary:Header not installed
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:MySQLi related
 Operating System:   GNU/Linux (Fedora 18)
 PHP Version:5.4.8
 Assigned To:remi
 Block user comment: N
 Private report: N

 New Comment:

Automatic comment on behalf of remi
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=8d2c44b59dfc6c5c608121546edac5840def3f9a
Log: Fixed Bug #63361 Header not installed


Previous Comments:

[2012-10-25 12:47:59] r...@php.net

Description:

In ext/mysqli/php_mysqli_structs.h (snipped for readability):

#ifdef MYSQLI_USE_MYSQLND
...
#include "mysqli_mysqlnd.h"
...
#else
...
#include "mysqli_libmysql.h"
...
#endif

So installed php_mysqli_structs.h is unusable without 
mysqli_mysqlnd.h/mysqli_libmysql.h which are not installed.








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

37 matches

Mail list logo