Bug #60837 [Opn]: Segmentation fail, if use trait

2012-01-23 Thread piphon at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60837&edit=1

 ID: 60837
 User updated by:piphon at gmail dot com
 Reported by:piphon at gmail dot com
 Summary:Segmentation fail, if use trait
 Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 11.10 64bit
 PHP Version:5.4SVN-2012-01-22 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

I check svn head, when https://bugs.php.net/bug.php?id=60840 fixed


Previous Comments:

[2012-01-24 06:27:54] piphon at gmail dot com

Snapshot PHP 5.4.0RC7-dev (cli) (built: Jan 24 2012 11:49:24) worked.

Sorry, can't try SVN branch 
(https://svn.php.net/repository/php/php-src/branches/PHP_5_4@322646). Could not 
compile sources for test issue. Modules (pdo, pdo_mysql) not compiled as static 
libraries (multiple definition of `get_module') or pdo_mysql not linked as 
shared library (mysqlnd_debug_std_no_trace_funcs not found). And debugging and 
normal. I'll try again.


[2012-01-24 05:32:44] larue...@php.net

Please try using this snapshot:

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

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

could you plz also try with 5.4 branch head? thanks very much :)


[2012-01-24 04:27:25] piphon at gmail dot com

PHP 5.5.0-dev (cli) from https://svn.php.net/repository/php/php-src/trunk  
worked.


[2012-01-24 03:00:37] larue...@php.net

piphon,  can you verify that whether this issues still existing in svn head now?
I am doubt that this issues was fixed by dmitry in http://svn.php.net/viewvc?
view=revision&revision=322495


[2012-01-23 08:51:35] piphon at gmail dot com

> What exactly did you do with the reflection API? Perhaps, there was something 
going wrong? At least it should not mess up the function tables.

Unknown. Reflection used only by Doctrine Annotations driver. However in older 
code, I'm used static method in trait, which stored in value static property.

P.S. Mystery...




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


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


Bug #60837 [Fbk->Opn]: Segmentation fail, if use trait

2012-01-23 Thread piphon at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60837&edit=1

 ID: 60837
 User updated by:piphon at gmail dot com
 Reported by:piphon at gmail dot com
 Summary:Segmentation fail, if use trait
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 11.10 64bit
 PHP Version:5.4SVN-2012-01-22 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

Snapshot PHP 5.4.0RC7-dev (cli) (built: Jan 24 2012 11:49:24) worked.

Sorry, can't try SVN branch 
(https://svn.php.net/repository/php/php-src/branches/PHP_5_4@322646). Could not 
compile sources for test issue. Modules (pdo, pdo_mysql) not compiled as static 
libraries (multiple definition of `get_module') or pdo_mysql not linked as 
shared library (mysqlnd_debug_std_no_trace_funcs not found). And debugging and 
normal. I'll try again.


Previous Comments:

[2012-01-24 05:32:44] larue...@php.net

Please try using this snapshot:

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

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

could you plz also try with 5.4 branch head? thanks very much :)


[2012-01-24 04:27:25] piphon at gmail dot com

PHP 5.5.0-dev (cli) from https://svn.php.net/repository/php/php-src/trunk  
worked.


[2012-01-24 03:00:37] larue...@php.net

piphon,  can you verify that whether this issues still existing in svn head now?
I am doubt that this issues was fixed by dmitry in http://svn.php.net/viewvc?
view=revision&revision=322495


[2012-01-23 08:51:35] piphon at gmail dot com

> What exactly did you do with the reflection API? Perhaps, there was something 
going wrong? At least it should not mess up the function tables.

Unknown. Reflection used only by Doctrine Annotations driver. However in older 
code, I'm used static method in trait, which stored in value static property.

P.S. Mystery...


[2012-01-23 08:43:32] g...@php.net

The stack trace you provided points at a corrupted function table, I would say.
That might still be something different than the comment bug.

What exactly did you do with the reflection API? Perhaps, there was something 
going wrong? At least it should not mess up the function tables.




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


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


Bug #60837 [Opn->Fbk]: Segmentation fail, if use trait

2012-01-23 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=60837&edit=1

 ID: 60837
 Updated by: larue...@php.net
 Reported by:piphon at gmail dot com
 Summary:Segmentation fail, if use trait
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 11.10 64bit
 PHP Version:5.4SVN-2012-01-22 (SVN)
 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/

could you plz also try with 5.4 branch head? thanks very much :)


Previous Comments:

[2012-01-24 04:27:25] piphon at gmail dot com

PHP 5.5.0-dev (cli) from https://svn.php.net/repository/php/php-src/trunk  
worked.


[2012-01-24 03:00:37] larue...@php.net

piphon,  can you verify that whether this issues still existing in svn head now?
I am doubt that this issues was fixed by dmitry in http://svn.php.net/viewvc?
view=revision&revision=322495


[2012-01-23 08:51:35] piphon at gmail dot com

> What exactly did you do with the reflection API? Perhaps, there was something 
going wrong? At least it should not mess up the function tables.

Unknown. Reflection used only by Doctrine Annotations driver. However in older 
code, I'm used static method in trait, which stored in value static property.

P.S. Mystery...


[2012-01-23 08:43:32] g...@php.net

The stack trace you provided points at a corrupted function table, I would say.
That might still be something different than the comment bug.

What exactly did you do with the reflection API? Perhaps, there was something 
going wrong? At least it should not mess up the function tables.


[2012-01-23 08:41:44] larue...@php.net

maybe dmitry's fix has also fixed this problem: http://svn.php.net/viewvc?
view=revision&revision=322495




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


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


Bug #60837 [Fbk->Opn]: Segmentation fail, if use trait

2012-01-23 Thread piphon at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60837&edit=1

 ID: 60837
 User updated by:piphon at gmail dot com
 Reported by:piphon at gmail dot com
 Summary:Segmentation fail, if use trait
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 11.10 64bit
 PHP Version:5.4SVN-2012-01-22 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

PHP 5.5.0-dev (cli) from https://svn.php.net/repository/php/php-src/trunk  
worked.


Previous Comments:

[2012-01-24 03:00:37] larue...@php.net

piphon,  can you verify that whether this issues still existing in svn head now?
I am doubt that this issues was fixed by dmitry in http://svn.php.net/viewvc?
view=revision&revision=322495


[2012-01-23 08:51:35] piphon at gmail dot com

> What exactly did you do with the reflection API? Perhaps, there was something 
going wrong? At least it should not mess up the function tables.

Unknown. Reflection used only by Doctrine Annotations driver. However in older 
code, I'm used static method in trait, which stored in value static property.

P.S. Mystery...


[2012-01-23 08:43:32] g...@php.net

The stack trace you provided points at a corrupted function table, I would say.
That might still be something different than the comment bug.

What exactly did you do with the reflection API? Perhaps, there was something 
going wrong? At least it should not mess up the function tables.


[2012-01-23 08:41:44] larue...@php.net

maybe dmitry's fix has also fixed this problem: http://svn.php.net/viewvc?
view=revision&revision=322495


[2012-01-23 08:38:19] piphon at gmail dot com

In Zend/zend_comile.c changed behavior of traits. Perhaps this is corrected 
bug. My original point of view (when I first met this bug): a mistake in 
reflection for classes that used traits). I removed comment in trait and all 
successful worked (RC1 or 2, i don't remember).




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


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


Bug #60837 [Ctl->Fbk]: Segmentation fail, if use trait

2012-01-23 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=60837&edit=1

 ID: 60837
 Updated by: larue...@php.net
 Reported by:piphon at gmail dot com
 Summary:Segmentation fail, if use trait
-Status: Critical
+Status: Feedback
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 11.10 64bit
 PHP Version:5.4SVN-2012-01-22 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

piphon,  can you verify that whether this issues still existing in svn head now?
I am doubt that this issues was fixed by dmitry in http://svn.php.net/viewvc?
view=revision&revision=322495


Previous Comments:

[2012-01-23 08:51:35] piphon at gmail dot com

> What exactly did you do with the reflection API? Perhaps, there was something 
going wrong? At least it should not mess up the function tables.

Unknown. Reflection used only by Doctrine Annotations driver. However in older 
code, I'm used static method in trait, which stored in value static property.

P.S. Mystery...


[2012-01-23 08:43:32] g...@php.net

The stack trace you provided points at a corrupted function table, I would say.
That might still be something different than the comment bug.

What exactly did you do with the reflection API? Perhaps, there was something 
going wrong? At least it should not mess up the function tables.


[2012-01-23 08:41:44] larue...@php.net

maybe dmitry's fix has also fixed this problem: http://svn.php.net/viewvc?
view=revision&revision=322495


[2012-01-23 08:38:19] piphon at gmail dot com

In Zend/zend_comile.c changed behavior of traits. Perhaps this is corrected 
bug. My original point of view (when I first met this bug): a mistake in 
reflection for classes that used traits). I removed comment in trait and all 
successful worked (RC1 or 2, i don't remember).


[2012-01-23 07:54:39] g...@php.net

Hi, I was not able to reproduce the problem, because I do not have the 
necessary 
setup. Think, I got as far as that PDO complains about a missing database 
table, 
but I also changed the db driver from mysql to sqlite.

The only thing I saw was that on an old checkout, the bug with doccomments 
#60809 
caused segfaults. But, that seems unrelated to the stacktrace below.




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


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


Bug->Req #60850 [Opn]: Built in web server does not set $_SERVER['SCRIPT_FILENAME'] when using router

2012-01-23 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=60850&edit=1

 ID: 60850
 Updated by: larue...@php.net
 Reported by:dave dot marshall at atstsolutions dot co dot uk
 Summary:Built in web server does not set
 $_SERVER['SCRIPT_FILENAME'] when using router
 Status: Open
-Type:   Bug
+Type:   Feature/Change Request
 Package:Built-in web server
 Operating System:   Linux/Ubuntu 11.10
 PHP Version:5.4SVN-2012-01-23 (snap)
 Block user comment: N
 Private report: N

 New Comment:

router is a especially script, if we set this as the script_name, what about 
the 
script which router routed to?


Previous Comments:

[2012-01-23 13:45:31] dave dot marshall at atstsolutions dot co dot uk

Description:

Nothing special done when compiling, just --configure and then make.

If the webserver couldn't do any path translation, $_SERVER['SCRIPT_FILENAME'] 
is not populated. If this is desired behaviour, perhaps the documentation 
should be updated, as existing software will rely on it.



Given the code below in router.php, and starting the web server with a router
> ~/Downloads/php5.4-201201231230/sapi/cli/php -S localhost:8000 router.php

Fetch the root url, NULL returned

> curl localhost:8000
NULL

Given that this variable is documented, I'd expect it to be string(29) 
"/home/davem/temp_ws/router.php"

Touching a file called index.php, seems to trick the webserver in to thinking 
it's done a path translation for the root url

> touch index.php
> curl localhost:8000
string(29) "/home/davem/temp_ws/index.php"



Test script:
---
router.php

https://bugs.php.net/bug.php?id=60850&edit=1


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

2012-01-23 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: Critical
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 10.04.3 LTS
 PHP Version:5.4.0RC6
-Assigned To:stas
+Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

assign to myself, will close after commit to 5.4 branch


Previous Comments:

[2012-01-21 17:29:04] larue...@php.net

fixed in trunk, will commit to branch when I got the permission from stas, and 
a   
simple reproduce script:

http://svn.php.net/viewvc/?view=revision&revision=322541
Log: Fixed bug #60825 (Segfault when running symfony 2 tests)


[2012-01-21 07:52:38] php at wallbash dot com

Yes. It is that function that cases the crash rasmus.

Compiling php-5.4 from current SVN the tests run just fine :)

Regards,
Edorian


[2012-01-21 05:23:50] ras...@php.net

Can you try reproducing with the current svn code?
I went through the reproduce steps and the unit tests ran to completion for me.

However, under Valgrind I did get some complaints for one of the tests. Can you 
tell if your crash is on this same test?

Starting test 
'Symfony\Bundle\SecurityBundle\Tests\Functional\FormLoginTest::testFormLogin 
with data set #0 ('config.yml')'.
==24587== Conditional jump or move depends on uninitialised value(s)
==24587==at 0x9DE434: zend_call_function (zend_execute_API.c:925)
==24587==by 0xA128C3: zend_call_method (zend_interfaces.c:97)
==24587==by 0xA2BAE6: zend_std_cast_object_tostring 
(zend_object_handlers.c:1494)
==24587==by 0x9E582A: _convert_to_string (zend_operators.c:588)
==24587==by 0xB05BB6: ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER 
(zend_vm_execute.h:27073)
==24587==by 0xA342CC: execute (zend_vm_execute.h:410)
==24587==by 0x9DE67C: zend_call_function (zend_execute_API.c:958)
==24587==by 0x74F4C9: zim_reflection_method_invokeArgs 
(php_reflection.c:2926)
==24587==by 0xA35C22: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:642)
==24587==by 0xA36C1E: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 
(zend_vm_execute.h:752)
==24587==by 0xA342CC: execute (zend_vm_execute.h:410)
==24587==by 0x9F2AEF: zend_execute_scripts (zend.c:1272)
==24587== 
==24587== Conditional jump or move depends on uninitialised value(s)
==24587==at 0x9DBB70: _zval_ptr_dtor (zend_execute_API.c:433)
==24587==by 0x9DED15: zend_call_function (zend_execute_API.c:1019)
==24587==by 0xA128C3: zend_call_method (zend_interfaces.c:97)
==24587==by 0xA2BAE6: zend_std_cast_object_tostring 
(zend_object_handlers.c:1494)
==24587==by 0x9E582A: _convert_to_string (zend_operators.c:588)
==24587==by 0xB05BB6: ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER 
(zend_vm_execute.h:27073)
==24587==by 0xA342CC: execute (zend_vm_execute.h:410)
==24587==by 0x9DE67C: zend_call_function (zend_execute_API.c:958)
==24587==by 0x74F4C9: zim_reflection_method_invokeArgs 
(php_reflection.c:2926)
==24587==by 0xA35C22: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:642)
==24587==by 0xA36C1E: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 
(zend_vm_execute.h:752)
==24587==by 0xA342CC: execute (zend_vm_execute.h:410)
==24587== 
==24587== Conditional jump or move depends on uninitialised value(s)
==24587==at 0x9DBC28: _zval_ptr_dtor (zend_execute_API.c:444)
==24587==by 0x9DED15: zend_call_function (zend_execute_API.c:1019)
==24587==by 0xA128C3: zend_call_method (zend_interfaces.c:97)
==24587==by 0xA2BAE6: zend_std_cast_object_tostring 
(zend_object_handlers.c:1494)
==24587==by 0x9E582A: _convert_to_string (zend_operators.c:588)
==24587==by 0xB05BB6: ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER 
(zend_vm_execute.h:27073)
==24587==by 0xA342CC: execute (zend_vm_execute.h:410)
==24587==by 0x9DE67C: zend_call_function (zend_execute_API.c:958)
==24587==by 0x74F4C9: zim_reflection_method_invokeArgs 
(php_reflection.c:2926)
==24587==by 0xA35C22: zend_do_fcall_common_helper_SPEC 
(zend_vm_execute.h:642)
==24587==by 0xA36C1E: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER 
(zend_vm_execute.h:752)
==24587==by 0xA342CC: execute (zend_vm_execute.h:410)


[2012-01-21 04:59:45] ras...@php.net

Stas, this looks like a blocker for 5.4




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 

Req #55633 [Com]: New argument $invert for array_filter()

2012-01-23 Thread vovan-ve at yandex dot ru
Edit report at https://bugs.php.net/bug.php?id=55633&edit=1

 ID: 55633
 Comment by: vovan-ve at yandex dot ru
 Reported by:vovan-ve at yandex dot ru
 Summary:New argument $invert for array_filter()
 Status: Open
 Type:   Feature/Change Request
 Package:Arrays related
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

> Use Closures

Usage of any user-defined function as a callback anywhere will reduce 
performance. I think, it is much better to improve array_filter() as mentioned 
above.


Previous Comments:

[2012-01-23 22:39:24] gmblar+php at gmail dot com

Use Closures

$values = array(42, 'foo', false, null, array(), '');
var_dump(array_filter($values, function($value) {
return !is_null($value);
}));


[2011-09-07 11:58:51] vovan-ve at yandex dot ru

Description:

I think, it would be useful to add new argument $invert to array_filter() 
function. It will be most useful to use built-in functions as a callback. For 
example this call:

$result = array_filter($values, 'is_null', true);

should to _remove_ all NULLs from array.

May be the parameter should be named $positive and have default value TRUE (and 
FALSE for inversion) to make code readable.

Test script:
---
$values = array(42, 'foo', false, null, array(), '');
var_dump(
  array_filter($values, null, true), // no callback - leave false value
  array_filter($values, 'is_null', true) // leave non-null values
);

Expected result:

array(5) {
  [0]=>
  bool(false)
  [1]=>
  NULL
  [2]=>
  array(0) {
  }
  [3]=>
  string(0) ""
}
array(5) {
  [0]=>
  int(42)
  [1]=>
  string(3) "foo"
  [2]=>
  bool(false)
  [3]=>
  array(0) {
  }
  [4]=>
  string(0) ""
}







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


Bug #60863 [Opn]: mysqlnd does not compile in the combination NTS & Debug (Windows)

2012-01-23 Thread cseiler
Edit report at https://bugs.php.net/bug.php?id=60863&edit=1

 ID: 60863
 Updated by: csei...@php.net
 Reported by:csei...@php.net
 Summary:mysqlnd does not compile in the combination NTS &
 Debug (Windows)
 Status: Open
 Type:   Bug
 Package:MySQL related
 Operating System:   Windows XP
 PHP Version:5.4SVN-2012-01-23 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

The following error messages are produced by the VC9 compiler (messages 
unfortunately in German, but "nichtdeklarierter Bezeichner" means "undeclared 
identifier"):

d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(100) : 
error C2143: Syntaxfehler: Es fehlt ';' vor 'Typ'
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(100) : 
error C2275: 'uint64_t': UngÃŒltige Verwendung dieses Typs als Ausdruck
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\win32\php_stdint.h(87): Siehe 
Deklaration von 'uint64_t'
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(100) : 
error C2146: Syntaxfehler: Fehlendes ';' vor Bezeichner '__dbg_prof_start'
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(100) : 
error C2065: '__dbg_prof_start': nichtdeklarierter Bezeichner
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(100) : 
error C2275: 'zend_bool': UngÃŒltige Verwendung dieses Typs als Ausdruck
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\zend\zend_types.h(25): Siehe 
Deklaration von 'zend_bool'
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(100) : 
error C2146: Syntaxfehler: Fehlendes ';' vor Bezeichner 'dbg_skip_trace'
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(100) : 
error C2065: 'dbg_skip_trace': nichtdeklarierter Bezeichner
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(100) : 
error C2065: 'dbg_skip_trace': nichtdeklarierter Bezeichner
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(100) : 
error C2065: '__dbg_prof_tp': nichtdeklarierter Bezeichner
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(100) : 
warning C4133: 'Funktion': Inkompatible Typen - von 'int *' zu 'timeval *'
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(100) : 
error C2065: '__dbg_prof_start': nichtdeklarierter Bezeichner
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(100) : 
error C2065: '__dbg_prof_tp': nichtdeklarierter Bezeichner
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(100) : 
error C2224: Der linke Teil von '.tv_sec' muss eine Struktur/Union sein
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(100) : 
error C2065: '__dbg_prof_tp': nichtdeklarierter Bezeichner
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(100) : 
error C2224: Der linke Teil von '.tv_usec' muss eine Struktur/Union sein
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(104) : 
error C2065: '__dbg_prof_tp': nichtdeklarierter Bezeichner
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(104) : 
warning C4133: 'Funktion': Inkompatible Typen - von 'int *' zu 'timeval *'
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(104) : 
error C2065: '__dbg_prof_tp': nichtdeklarierter Bezeichner
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(104) : 
error C2224: Der linke Teil von '.tv_sec' muss eine Struktur/Union sein
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(104) : 
error C2065: '__dbg_prof_tp': nichtdeklarierter Bezeichner
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(104) : 
error C2224: Der linke Teil von '.tv_usec' muss eine Struktur/Union sein
d:\php-sdk\php54dev\vc9\x86\php5.4-svn\ext\mysqlnd\mysqlnd_driver.c(104) : 
error C2065: '__dbg_prof_start': nichtdeklarierter Bezeichner


Previous Comments:

[2012-01-23 23:11:44] csei...@php.net

Description:

The mysqlnd driver does not compile in the combination NTS (thread UNsafe) + 
Debug build under Microsoft Windows XP. (WinSDK 6.1, VC9 SP1 Pro)

See  for further details 
and discussion.

The following configure line was used:

cscript /nologo configure.js
 "--disable-phar"
 "--disable-ipv6"
 "--disable-zts"
 "--enable-cgi"
 "--disable-bcmath"
 "--disable-calendar"
 "--disable-odbc"
 "--disable-tokenizer"
 "--disable-xmlreader"
 "--disable-xmlwriter"
 "--without-wddx"
 "--enable-debug"
 "--enable-cli-win32"
 "--enable-pdo"
 "--with-openssl"
 "--with-php-build=..\deps"
 "--with-libxml"
 "--with-pdo-sqlite"

It chokes on the following two lines:

mysqlnd_driver.c, 100:
DBG_ENTER("mysqlnd_error_list_pdtor");

mysqlnd_driver.c, 104:
DBG_VOID_RETURN;

Debug + ZTS (thread safe

[PHP-BUG] Bug #60863 [NEW]: mysqlnd does not compile in the combination NTS & Debug (Windows)

2012-01-23 Thread csei...@php.net
From: cseiler
Operating system: Windows XP
PHP version:  5.4SVN-2012-01-23 (SVN)
Package:  MySQL related
Bug Type: Bug
Bug description:mysqlnd does not compile in the combination NTS & Debug 
(Windows)

Description:

The mysqlnd driver does not compile in the combination NTS (thread UNsafe)
+ Debug build under Microsoft Windows XP. (WinSDK 6.1, VC9 SP1 Pro)

See  for further
details and discussion.

The following configure line was used:

cscript /nologo configure.js
 "--disable-phar"
 "--disable-ipv6"
 "--disable-zts"
 "--enable-cgi"
 "--disable-bcmath"
 "--disable-calendar"
 "--disable-odbc"
 "--disable-tokenizer"
 "--disable-xmlreader"
 "--disable-xmlwriter"
 "--without-wddx"
 "--enable-debug"
 "--enable-cli-win32"
 "--enable-pdo"
 "--with-openssl"
 "--with-php-build=..\deps"
 "--with-libxml"
 "--with-pdo-sqlite"

It chokes on the following two lines:

mysqlnd_driver.c, 100:
DBG_ENTER("mysqlnd_error_list_pdtor");

mysqlnd_driver.c, 104:
DBG_VOID_RETURN;

Debug + ZTS (thread safe), Release + NTS and Release + ZTS all compile. As
do all 4 variants of PHP 5.3 with the same configure line.

Could potentially be related to PHP bug #60840


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



Req #55149 [Com]: Limit the result of print_r() to facilitate debugging

2012-01-23 Thread gmblar+php at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=55149&edit=1

 ID: 55149
 Comment by: gmblar+php at gmail dot com
 Reported by:victor at cmp dot es
 Summary:Limit the result of print_r() to facilitate
 debugging
 Status: Open
 Type:   Feature/Change Request
 Package:Class/Object related
 Operating System:   Irrelevant
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Try xdebug_var_dump http://xdebug.org/docs/all_functions#xdebug_var_dump for a 
limited output.


Previous Comments:

[2011-07-07 02:31:49] lenzai2004-dev at yahoo dot com

Why not writing your own custom php function for that purpose ?
Also for debugging var_dump is sometimes more useful than print_r.


[2011-07-06 11:51:03] victor at cmp dot es

Description:

You could add an additional third parameter to print_r() function in order to 
limit the nesting level of output.
Instead of showing all levels of nested arrays/objects, it could be limited to 
N nesting levels.
If I only want to know my simple class member variables (with 3 or 4 of them) 
of an object but the object has members with "references/alias" to other big 
objects/classes, the screen is filled with a lot of (in this case) useless 
information.
If I could limit in this case the output to 1 or 2 nesting levels it would be 
much easier for me to debug.
If this third parameter were ommitted or zero, the whole tree would be shown 
(as done now).








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


Req #55633 [Com]: New argument $invert for array_filter()

2012-01-23 Thread gmblar+php at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=55633&edit=1

 ID: 55633
 Comment by: gmblar+php at gmail dot com
 Reported by:vovan-ve at yandex dot ru
 Summary:New argument $invert for array_filter()
 Status: Open
 Type:   Feature/Change Request
 Package:Arrays related
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Use Closures

$values = array(42, 'foo', false, null, array(), '');
var_dump(array_filter($values, function($value) {
return !is_null($value);
}));


Previous Comments:

[2011-09-07 11:58:51] vovan-ve at yandex dot ru

Description:

I think, it would be useful to add new argument $invert to array_filter() 
function. It will be most useful to use built-in functions as a callback. For 
example this call:

$result = array_filter($values, 'is_null', true);

should to _remove_ all NULLs from array.

May be the parameter should be named $positive and have default value TRUE (and 
FALSE for inversion) to make code readable.

Test script:
---
$values = array(42, 'foo', false, null, array(), '');
var_dump(
  array_filter($values, null, true), // no callback - leave false value
  array_filter($values, 'is_null', true) // leave non-null values
);

Expected result:

array(5) {
  [0]=>
  bool(false)
  [1]=>
  NULL
  [2]=>
  array(0) {
  }
  [3]=>
  string(0) ""
}
array(5) {
  [0]=>
  int(42)
  [1]=>
  string(3) "foo"
  [2]=>
  bool(false)
  [3]=>
  array(0) {
  }
  [4]=>
  string(0) ""
}







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


Req #60219 [Com]: POSTDATA periods (.) being converted to underscores (_)

2012-01-23 Thread tim at xi dot co dot nz
Edit report at https://bugs.php.net/bug.php?id=60219&edit=1

 ID: 60219
 Comment by: tim at xi dot co dot nz
 Reported by:kieran at menor dot dk
 Summary:POSTDATA periods (.) being converted to underscores
 (_)
 Status: Open
 Type:   Feature/Change Request
 Package:Unknown/Other Function
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

See: 

https://wiki.php.net/rfc/url_dots


Previous Comments:

[2012-01-23 20:08:33] kcerny at wirelesscapital dot com

The relevant code is found in the source file main/php_variables.c at line 94:

/* ensure that we don't have spaces or dots in the variable name (not 
binary safe) */
for (p = var; *p; p++) {
if (*p == ' ' || *p == '.') {
*p='_';
} else if (*p == '[') {
is_array = 1;
ip = p;
*p = 0;
break;
}
}

I'm not sure what repercussions we'll face by removing that first if statement. 
I would suggest controlling this replacement behavior using an INI setting for 
backwards compatibility.


[2011-11-15 04:20:32] pablitobof at yahoo dot com dot mx

PHP 5.4 alpha1 has just been released which removes register_globals.  It seems 
appropriate that there would be a matching move towards removing the now 
unnecessary translation of characters in requests.


[2011-11-04 14:10:02] kieran at menor dot dk

Not to mention, it's also potentially confusing and unexpected behavior for 
people who didn't happen to read that tiny paragraph of the manual.


[2011-11-04 14:04:59] kieran at menor dot dk

Description:

This is documented "intended" behavior as per this section of the manual:

http://www.php.net/manual/en/language.variables.external.php#language.variables.external.dot-in-names

I'm guessing it's a leftover from back when register_globals a common thing. 
It's been reported as a bug before a long time ago, and dismissed:

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

... but this is 2011, and I think it's worth giving it another go. Here's why:

First of all, nobody assigns POSTDATA directly to variables anymore. It all 
goes through $_POST;
Secondly, the claim that you can't have periods in variable names is bogus (see 
test script).
Lastly, the period is a good seperator to have available, and I understand that 
certain services such as OpenID depend on it, as noted here: 
http://stackoverflow.com/questions/68651/can-i-get-php-to-stop-replacing-characters-in-get-or-post-arrays#1939911

Test script:
---
${'sure.you.can'} = 'Foo';
var_dump($GLOBALS['sure.you.can']);







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


Bug #60017 [Com]: __FILE__ case inconsistency on Mac / MAMP

2012-01-23 Thread gmblar+php at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60017&edit=1

 ID: 60017
 Comment by: gmblar+php at gmail dot com
 Reported by:ykessler at gmail dot com
 Summary:__FILE__ case inconsistency on Mac / MAMP
 Status: Open
 Type:   Bug
 Package:Filesystem function related
 Operating System:   Mac OSX
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

This happens because the default filesystem (hfs+) is case insensitive.

a.php

'  and this is also not 
possible?? Any ideas.


[2011-10-16 13:30:43] ykessler at gmail dot com

Here is another test run outside the Users directory, in the standard MAMP 
install under Applications/MAMP/htdocs:

a.php:

__FILE__ = ".__FILE__;
echo "__DIR__ = ".__DIR__;
include("a_inc.php");
?>

a_inc.php:

__FILE__ = ".__FILE__;
echo "__DIR__ = ".__DIR__;
?>

http://localhost/tests/a.php =

__FILE__ = /applications/mamp/htdocs/tests/a.php
__DIR__ = /applications/mamp/htdocs/tests
__FILE__ = /Applications/MAMP/htdocs/tests/a_inc.php
__DIR__ = /Applications/MAMP/htdocs/tests


Zend Engine v2.3.0
OSX 10.6.8
Apache/2.0.63 (Unix) PHP/5.3.2 DAV/2


[2011-10-08 23:39:39] karcieri at gmail dot com

Environment:
---
Zend Server version: 5.1.0

Test script:
---
Same as bug report

Actual result:
--
__FILE__ = /usr/local/zend/apache2/htdocs/Test
__DIR__ = /usr/local/zend/apache2/htdocs/Test

__FILE__ = /usr/local/zend/apache2/htdocs/Test
__DIR__ = /usr/local/zend/apache2/htdocs/Test

Is it possible that this bug is only related to the Users directory?


[2011-10-08 21:51:37] ykessler at gmail dot com

Description:

---
>From manual page: http://www.php.net/language.constants.predefined
---

__FILE__ and __DIR__, return lower case paths when in the calling file, and 
mixed 
case paths in an included file, when run on MAMP.

Test script:
---
//The following will show all lower case paths when in the calling file, 
//and mixed case paths in an included file, when run on MAMP.

echo "__FILE__ = ".__FILE__;
echo "__DIR__ = ".__DIR__;

// include another file with the same code ...

Actual result:
--
__FILE__ = /users/me/stuff/mamp_server/my_site/myfile.php
__DIR__ = /users/me/stuff/mamp_server/my_site

__FILE__ = /Users/me/Stuff/mamp_server/my_site/myfile.php
__DIR__ = /Users/me/Stuff/mamp_server/my_site






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


Req #60847 [Com]: mkdir second argument should prepend leading zero if only 3 numbers are inputte

2012-01-23 Thread phpmpan at mpan dot pl
Edit report at https://bugs.php.net/bug.php?id=60847&edit=1

 ID: 60847
 Comment by: phpmpan at mpan dot pl
 Reported by:me at davecarlson dot co dot uk
 Summary:mkdir second argument should prepend leading zero if
 only 3 numbers are inputte
 Status: Open
 Type:   Feature/Change Request
 Package:*Directory/Filesystem functions
 Operating System:   Debian Squeeze
 PHP Version:5.3.9
 Block user comment: N
 Private report: N

 New Comment:

There is no way to detect this, as this is a function, not a language 
construct. Also the argument may come from a variable or another function.

You are also missing one important thing: there is NO requirement to use 
leading zero. `mkdir` accepts a bitmask. A convenient way to input bitmasks is 
hexadecimal or octal notation. This way of describing numbers is used in many 
cases, not only to specify file mode mask. But this is just a way to specify a 
number, nothing more. If you want, you can safely write 493 or 0x1ED an 
everything will be OK. If one doesn't feel comfortable with specifying bitmasks 
directly, something more explicit may be used:
(1 << 9 | 1 << 8 | 1 << 7 | 1 << 6 | 1 << 4 | 1 << 3 | 1)


Previous Comments:

[2012-01-23 10:36:27] me at davecarlson dot co dot uk

Description:

---
>From manual page: http://www.php.net/function.mkdir#refsect1-function.mkdir-
parameters
---

It can be **very** easy to omit the leading zero in the permissions argument, 
especially if working on a command line all day where "775" for example works 
in 
a chmod. Although the documentation clearly states it needs a leading zero, it 
would be good if the function could detect such a trivial error that can lead 
to 
quite bad results. It would also help consistency between the linux command 
line 
and php.

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


[PHP-BUG] Bug #60860 [NEW]: session.save_handler=user without defined function core dumps

2012-01-23 Thread bfra...@php.net
From: 
Operating system: Fedora, RHEL, OS X
PHP version:  5.3.9
Package:  Session related
Bug Type: Bug
Bug description:session.save_handler=user without defined function core dumps

Description:

The following script will core dump because the save_handlers have not been
defined, but the session extension is not checking to make sure the
functions are not null before trying to call them.

I would expect an error, but not a core dump.

I think the fix would be in mod_user.c to add a check in PS_OPEN_FUNC,
PS_CLOSE_FUNC, PS_READ_FUNC, PS_WRITE_FUNC, PS_DESTROY_FUNC, PS_GC_FUNC
with something like this:


  if (PSF(open) == NULL) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "user session handler open
not found");
return FAILURE;
  }


Or maybe the error "User session functions not configured" or something.

The problem I have with the patch is that it needs TSRMLS_CC, which the PS
function don't pass in and I don't know enough about the threading stuff to
fix.


Test script:
---
% php -d session.save_handler=user



Expected result:

Expecting a warning about how the user session function are not
defined/set.

Actual result:
--
This is a backtrace from running under Apache 2.x

#0  zend_is_callable_ex (callable=0x0, object_ptr=0x0, check_flags=8,
callable_name=0xaf48, callable_name_len=0xae8c, fcc=0xaf50,
error=0xaf4c)
at php-5.3.9/Zend/zend_API.c:2718
#1  0xf72e150a in zend_call_function (fci=0xaff0, fci_cache=0xaf50)
at php-5.3.9/Zend/zend_execute_API.c:817
#2  0xf72e21c1 in call_user_function_ex (function_table=0x81f43f8,
object_pp=0x0, function_name=0xaf4c, retval_ptr_ptr=0xaf4c,
param_count=4294946636, params=0xaf4c, no_separation=-20660, 
symbol_table=0xaf4c) at php-5.3.9/Zend/zend_execute_API.c:758
#3  0xf72e2235 in call_user_function (function_table=0x81f43f8,
object_pp=0x0, function_name=0x0, retval_ptr=0xf6cc7d10, param_count=2,
params=0xb0c0)
at php-5.3.9/Zend/zend_execute_API.c:731
#4  0xf6a35fcf in ps_call_handler (func=0x0, argc=2, argv=0xb0c0) at
php-5.3.9/ext/session/mod_user.c:53
#5  0xf6a360e7 in ps_open_user (mod_data=0xaf4c, save_path=0xf6a36a49
"", session_name=0xf6a3675f "YBY") at php-5.3.9/ext/session/mod_user.c:93
#6  0xf6a32951 in php_session_start () at
php-5.3.9/ext/session/session.c:512
#7  0xf6a34784 in zif_session_start (ht=0, return_value=0xf6cc7b00,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=0)
at php-5.3.9/ext/session/session.c:1911
#8  0xf7315474 in zend_do_fcall_common_helper_SPEC
(execute_data=0xf654f028) at php-5.3.9/Zend/zend_vm_execute.h:320
#9  0xf73144ba in execute (op_array=0xf6cc7a1c) at
php-5.3.9/Zend/zend_vm_execute.h:107
#10 0xf72f0e31 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at php-5.3.9/Zend/zend.c:1237
#11 0xf7294be4 in php_execute_script (primary_file=0xd5d0) at
php-5.3.9/main/main.c:2343
#12 0xf737ae3d in php_handler (r=0x82c6588) at
php-5.3.9/sapi/apache2handler/sapi_apache2.c:685
#13 0x08074ddd in ap_run_handler (r=0x82c6588) at config.c:157
#14 0x080751c1 in ap_invoke_handler (r=0x82c6588) at config.c:376
#15 0x08081d22 in ap_process_request (r=0x82c6588) at http_request.c:282
#16 0x0807f31a in ap_process_http_connection (c=0x82c23b8) at
http_core.c:190
#17 0x0807b971 in ap_run_process_connection (c=0x82c23b8) at
connection.c:43
#18 0x080868b7 in child_main (child_num_arg=Variable "child_num_arg" is not
available.
) at prefork.c:667
#19 0x08086ab1 in make_child (s=0x80aafd0, slot=0) at prefork.c:712
#20 0x08087153 in ap_mpm_run (_pconf=0x80a90d8, plog=0x80d7190,
s=0x80aafd0) at prefork.c:990
#21 0x08063047 in main (argc=2, argv=0xdb74) at main.c:739


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

Req #60219 [Com]: POSTDATA periods (.) being converted to underscores (_)

2012-01-23 Thread kcerny at wirelesscapital dot com
Edit report at https://bugs.php.net/bug.php?id=60219&edit=1

 ID: 60219
 Comment by: kcerny at wirelesscapital dot com
 Reported by:kieran at menor dot dk
 Summary:POSTDATA periods (.) being converted to underscores
 (_)
 Status: Open
 Type:   Feature/Change Request
 Package:Unknown/Other Function
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

The relevant code is found in the source file main/php_variables.c at line 94:

/* ensure that we don't have spaces or dots in the variable name (not 
binary safe) */
for (p = var; *p; p++) {
if (*p == ' ' || *p == '.') {
*p='_';
} else if (*p == '[') {
is_array = 1;
ip = p;
*p = 0;
break;
}
}

I'm not sure what repercussions we'll face by removing that first if statement. 
I would suggest controlling this replacement behavior using an INI setting for 
backwards compatibility.


Previous Comments:

[2011-11-15 04:20:32] pablitobof at yahoo dot com dot mx

PHP 5.4 alpha1 has just been released which removes register_globals.  It seems 
appropriate that there would be a matching move towards removing the now 
unnecessary translation of characters in requests.


[2011-11-04 14:10:02] kieran at menor dot dk

Not to mention, it's also potentially confusing and unexpected behavior for 
people who didn't happen to read that tiny paragraph of the manual.


[2011-11-04 14:04:59] kieran at menor dot dk

Description:

This is documented "intended" behavior as per this section of the manual:

http://www.php.net/manual/en/language.variables.external.php#language.variables.external.dot-in-names

I'm guessing it's a leftover from back when register_globals a common thing. 
It's been reported as a bug before a long time ago, and dismissed:

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

... but this is 2011, and I think it's worth giving it another go. Here's why:

First of all, nobody assigns POSTDATA directly to variables anymore. It all 
goes through $_POST;
Secondly, the claim that you can't have periods in variable names is bogus (see 
test script).
Lastly, the period is a good seperator to have available, and I understand that 
certain services such as OpenID depend on it, as noted here: 
http://stackoverflow.com/questions/68651/can-i-get-php-to-stop-replacing-characters-in-get-or-post-arrays#1939911

Test script:
---
${'sure.you.can'} = 'Foo';
var_dump($GLOBALS['sure.you.can']);







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


Bug #60843 [Bgs]: preg_split crash

2012-01-23 Thread ruben dot cheng at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60843&edit=1

 ID: 60843
 User updated by:ruben dot cheng at gmail dot com
 Reported by:ruben dot cheng at gmail dot com
 Summary:preg_split crash
 Status: Bogus
 Type:   Bug
 Package:PCRE related
 Operating System:   Windows 7x64
 PHP Version:5.3.6 and later
 Block user comment: N
 Private report: N

 New Comment:

Thanks... I increased the stack size in Apache using the ThreadStackSize 
directive, and It didn't crash. For some reason, the stack size under Windows 
Platform is low. This issue can be closed.


Previous Comments:

[2012-01-23 07:48:30] paj...@php.net

As I said earlier, ask the hoster to increase the stack of Apache. It can be 
done 
via the httpd config or EDITBIN (see MSDN).

But there is nothing PHP can do, PHP itself has a large enough stack but it is 
limited by Apache's one.


[2012-01-23 05:20:00] ruben dot cheng at gmail dot com

I have tested this under several environment and seems to be related to windows 
platform. Here a results:

* Linux ubuntu LTS x86, PHP 5.3.2: OK
* Linux opensuse 11.2 x64, PHP 5.3.3: OK
* Linux unknown (provider-production), PHP 5.3.6: OK
* Windows 7x64. Apache 2.2.21 x64 (ApacheLounge). PHP 5.3.6 x64 (anindya): Crash
* Windows 7x64. Apache 2.2.21 x64 (ApacheLounge). PHP 5.3.9 x64 (anindya): Crash
* Windows 7x64. Apache 2.2.21 x64 (anindya). PHP 5.3.6 x64 (anindya): Crash
* Windows 7x64. Apache 2.2.21 x64 (anindya). PHP 5.3.9 x64 (anindya): Crash
* Windows 7x64. Apache 2.2.21 x32 (ApacheLounge). PHP 5.3.9 x32 (PHP.net): Crash

If I run the same script under cli on Windows instead from browser It doesn't 
crash.

PHP is loaded as module (except provider server)

Another think strange. The script doesn't crash on Windows if there few SQL 
sentences. It seems to be a preg_split pattern overflow. 

I tried each SQL of the $query variable from the start, and it crashes after 
appeding the 8th SQL sentence

By the way, how can I increase the stack ?


[2012-01-22 22:54:18] paj...@php.net

Ask your host to increase the stack and to update as well.


[2012-01-22 22:40:18] ruben dot cheng at gmail dot com

Description:

I was running a preg_split to split a string by ";" (taking care not to split 
enclosed ";" of SQL sentence) results a preg_split crash without notice and 
error. 
The test script is only 3 lines.

I'm using PHP 5.3.6, cannot upgrade because the hosting is stuck at this 
version.

Test script:
---


Expected result:

The script runs the preg_split line and crash, it didn't even reach the echo 
line







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


Bug #60719 [Asn->Csd]: dev-lang/php-5.3.9 has problems with stream_get_line()

2012-01-23 Thread alexander dot haensch at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60719&edit=1

 ID: 60719
 User updated by:alexander dot haensch at gmail dot com
 Reported by:alexander dot haensch at gmail dot com
 Summary:dev-lang/php-5.3.9 has problems with
 stream_get_line()
-Status: Assigned
+Status: Closed
 Type:   Bug
 Package:Streams related
 Operating System:   gentoo
 PHP Version:5.3.9
 Assigned To:cataphract
 Block user comment: N
 Private report: N

 New Comment:

The bug is fixed with the new version of streams.c


Previous Comments:

[2012-01-23 13:44:07] alexander dot haensch at gmail dot com

I applied a patch from the new streams.c you reported against vanilla 5.3.9. It 
compiles fine.
As soon as i'll have the technician ready,  i will report if this bug is fixed 
with the new streams.c.


[2012-01-23 09:19:51] cataphr...@php.net

You can patch main/streams/streams.c with the output of
svn diff 
http://svn.php.net/repository/php/php-src/branches/PHP_5_3/main/streams/streams.c@322581
 
http://svn.php.net/repository/php/php-src/branches/PHP_5_3/main/streams/streams.c@322582


[2012-01-23 08:52:09] alexander dot haensch at gmail dot com

Can someone send the patch itself here? 
It impossible for me to test the whole php snapshot on my production system. If 
i could get the stream_get_line() patch i could test it.


[2012-01-23 08:21:27] cataphr...@php.net

Snapshots can be found at http://snaps.php.net/ (note the fix is not in 5.4, 
only 5.3 and trunk).


[2012-01-23 08:20:11] cataphr...@php.net

Yesterday I committed some fixes to stream_get_line() (see bug #60817). Please 
see if it has any influence in your problem (it's likely it does).

Thank you.




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


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


[PHP-BUG] Bug #60853 [NEW]: Missing NCURSES_KEY_HOME constant

2012-01-23 Thread mbt at gator dot net
From: 
Operating system: Linux
PHP version:  5.3.9
Package:  ncurses related
Bug Type: Bug
Bug description:Missing NCURSES_KEY_HOME constant

Description:

The PECL ncurses extension has a regression:  the NCURSES_KEY_HOME constant
is 
not defined when the extension is loaded.

How on earth did this happen??  The first clue I had something was amiss
with 
the ncurses codebase showed up in a diff between the PHP 5.2.17 tarball
with 
the ncurses extension incorporated and the PECL 1.0.0 tarball:  the ncurses

files had 2010 as the copyright year; the PECL sources had 2006.

The key difference is in ncurses.c, in which the list of
constant-initializing 
macros is rearranged.  The PECL version lacks a PHP_NCURSES_CONST(KEY_HOME)

line.

A look through the history is a bit more disturbing.  The oldest PHP
tarball I 
could find--for version 5.1.4--has ZERO code difference from PECL ncurses 
1.0.0.  Maintenance of the ncurses code did proceed since 2006, especially
in 
the rearrangement of the constants in ncurses.c that resulted in adding the

missing NCURSES_KEY_HOME constant.

How many other regressions happened because you went back to an old version
of 
the ncurses code?  I noted a regression at line 1475 of ncurses_functions.c

that you repaired by version 1.0.1.  The other regressions seem more
benign:  
the call to DISPLAY_INI_ENTRIES() in the PHP_MINFO_FUNCTION() at line 277
of 
ncurses.c has nothing to display because there are no .ini entries for the

extension, and line 35 of ncurses_functions.c has a spelling error (ncruses

instead of ncurses).

I tried looked at the Subversion repository, but after letting the checkout

run for several hours it was still running.

I've given you a patch for that you can apply.  I added that patch to the 
Gentoo ebuild I made for dev-php5/pecl-ncurses-1.0.0, rebuilt it, and saw
that 
it worked.  I'm hoping the fix makes it out to Debian to get into Squeeze
(and 
PHP 5.3) by the time we move to Squeeze at work.

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



Bug #60852 [Opn->Bgs]: CLI doesn't read .user.ini

2012-01-23 Thread pajoye
Edit report at https://bugs.php.net/bug.php?id=60852&edit=1

 ID: 60852
 Updated by: paj...@php.net
 Reported by:rcodron at ankama dot com
 Summary:CLI doesn't read .user.ini
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   Linux
 PHP Version:5.3.9
 Block user comment: N
 Private report: N

 New Comment:

Expected, .user.ini is only supported by the CGI sapi. We have a feature 
request 
to make it work for other SAPIs.


Previous Comments:

[2012-01-23 14:21:38] rcodron at ankama dot com

Description:

if you try to run php cli in a sub dir like :
/usr/local/dir1/dir2/dir3/dir4/myphp.php where you have a .user.ini in dir4 php 
doesn't read the .user.ini



Test script:
---
.user.ini :
include_path = ".:/usr/local/dirA/dirB/dirC/frameworks/"

php /usr/local/dir1/dir2/dir3/dir4/myphp.php

in dir4 :
myphp.php
.user.ini

Expected result:

php load the .user.ini where the path of a custom lib







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


Bug #60848 [Opn->Bgs]: php -r works differently

2012-01-23 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=60848&edit=1

 ID: 60848
 Updated by: larue...@php.net
 Reported by:public at grik dot net
 Summary:php -r works differently
-Status: Open
+Status: Bogus
 Type:   Bug
 Package:CGI/CLI related
 Operating System:   linux
 PHP Version:5.4.0RC6
 Block user comment: N
 Private report: N

 New Comment:

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

use single quotes, or there will be variable substitution of shell.


Previous Comments:

[2012-01-23 11:55:26] public at grik dot net

Description:

PHP behaves differently with the code given in a file and in a parameter 
provided 
with -r
php -r ignores variables, partially recognizes scalar type hinting.

Test script:
---
[root@devel data]# php -r "echo 1;"
1[root@devel data]# php -r "$x=3;"

Parse error: syntax error, unexpected '=' in Command line code on line 1


# php -r "var_dump($x);"

Warning: Wrong parameter count for var_dump() in Command line code on line 1

# php -r "function foo(int $a){}"

Parse error: syntax error, unexpected '(int )' (int) (T_INT_CAST), expecting 
'(' in Command line code on line 1

Expected result:

1

Actual result:
--
Parse errors






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


[PHP-BUG] Bug #60852 [NEW]: CLI doesn't read .user.ini

2012-01-23 Thread rcodron at ankama dot com
From: 
Operating system: Linux
PHP version:  5.3.9
Package:  CGI/CLI related
Bug Type: Bug
Bug description:CLI doesn't read .user.ini

Description:

if you try to run php cli in a sub dir like :
/usr/local/dir1/dir2/dir3/dir4/myphp.php where you have a .user.ini in dir4
php doesn't read the .user.ini



Test script:
---
.user.ini :
include_path = ".:/usr/local/dirA/dirB/dirC/frameworks/"

php /usr/local/dir1/dir2/dir3/dir4/myphp.php

in dir4 :
myphp.php
.user.ini

Expected result:

php load the .user.ini where the path of a custom lib


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



[PHP-BUG] Bug #60850 [NEW]: Built in web server does not set $_SERVER['SCRIPT_FILENAME'] when using router

2012-01-23 Thread dave dot marshall at atstsolutions dot co dot uk
From: 
Operating system: Linux/Ubuntu 11.10
PHP version:  5.4SVN-2012-01-23 (snap)
Package:  Built-in web server
Bug Type: Bug
Bug description:Built in web server does not set $_SERVER['SCRIPT_FILENAME'] 
when using router

Description:

Nothing special done when compiling, just --configure and then make.

If the webserver couldn't do any path translation,
$_SERVER['SCRIPT_FILENAME'] is not populated. If this is desired behaviour,
perhaps the documentation should be updated, as existing software will rely
on it.



Given the code below in router.php, and starting the web server with a
router
> ~/Downloads/php5.4-201201231230/sapi/cli/php -S localhost:8000
router.php

Fetch the root url, NULL returned

> curl localhost:8000
NULL

Given that this variable is documented, I'd expect it to be string(29)
"/home/davem/temp_ws/router.php"

Touching a file called index.php, seems to trick the webserver in to
thinking it's done a path translation for the root url

> touch index.php
> curl localhost:8000
string(29) "/home/davem/temp_ws/index.php"



Test script:
---
router.php

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



Bug #60719 [Asn]: dev-lang/php-5.3.9 has problems with stream_get_line()

2012-01-23 Thread alexander dot haensch at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60719&edit=1

 ID: 60719
 User updated by:alexander dot haensch at gmail dot com
 Reported by:alexander dot haensch at gmail dot com
 Summary:dev-lang/php-5.3.9 has problems with
 stream_get_line()
 Status: Assigned
 Type:   Bug
 Package:Streams related
 Operating System:   gentoo
 PHP Version:5.3.9
 Assigned To:cataphract
 Block user comment: N
 Private report: N

 New Comment:

I applied a patch from the new streams.c you reported against vanilla 5.3.9. It 
compiles fine.
As soon as i'll have the technician ready,  i will report if this bug is fixed 
with the new streams.c.


Previous Comments:

[2012-01-23 09:19:51] cataphr...@php.net

You can patch main/streams/streams.c with the output of
svn diff 
http://svn.php.net/repository/php/php-src/branches/PHP_5_3/main/streams/streams.c@322581
 
http://svn.php.net/repository/php/php-src/branches/PHP_5_3/main/streams/streams.c@322582


[2012-01-23 08:52:09] alexander dot haensch at gmail dot com

Can someone send the patch itself here? 
It impossible for me to test the whole php snapshot on my production system. If 
i could get the stream_get_line() patch i could test it.


[2012-01-23 08:21:27] cataphr...@php.net

Snapshots can be found at http://snaps.php.net/ (note the fix is not in 5.4, 
only 5.3 and trunk).


[2012-01-23 08:20:11] cataphr...@php.net

Yesterday I committed some fixes to stream_get_line() (see bug #60817). Please 
see if it has any influence in your problem (it's likely it does).

Thank you.


[2012-01-22 23:14:43] seguer at gmail dot com

I have updated https://github.com/kr/beanstalkd/issues/88 with a packet trace 
suggested by kr, author of beanstalkd




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


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


Bug #43910 [Com]: Error when parsing Akamain SOAP

2012-01-23 Thread pritiatwork at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=43910&edit=1

 ID: 43910
 Comment by: pritiatwork at gmail dot com
 Reported by:vbrodsky at tremormedia dot com
 Summary:Error when parsing Akamain SOAP
 Status: No Feedback
 Type:   Bug
 Package:SOAP related
 Operating System:   CentOS release 5 (Final)
 PHP Version:5.2.5
 Block user comment: N
 Private report: N

 New Comment:

PHP : 5.2.11
OS:RedHat5

Error Received:
string(192) "Exception: class com.idoox.soap.DemarshallException: Type in 
schema differs from type in SOAP message - expected 
string@http://www.w3.org/1999/XMLSchema; got Map@http://xml.apache.org/xml-soap";


Previous Comments:

[2010-02-26 22:05:00] hrad...@php.net

This works for me:

https://ccuapi.akamai.com/ccuapi-axis.wsdl');

$username = 'example';
$password = 'secret';
$url = 'http://www.example.com/foo.php';

try {
$purgeResult = $client->purgeRequest($username, $password, '', array(), 
array($url));
}
catch(SoapFault $e){
echo "Exception\n";
var_dump($e);
echo "\n";

}
var_dump($purgeResult);
?>


[2008-02-05 01:00:02] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".


[2008-01-28 23:13:21] tony2...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.




[2008-01-22 17:50:54] vbrodsky at tremormedia dot com

Description:

I am trying to access Akamai Cache Control Service using SOAP Client. Since 
Akamai officially does not support PHP, I am using Java wsdl 
https://ccuapi.akamai.com/ccuapi-axis.wsdl.

I have created various tests, but no matter what I do I get PHP SOAP exception 
(see below). Is there is something wrong with the array of strings passed as a 
parameter? 

There apparently used to be idoox interoperatbility issue with an array of 
strings (http://aspn.activestate.com/ASPN/Mail/Message/soapbuilders/761488) but 
it is fixed, supposedly.



BTW my php version is 1.5.6 (comes CentOS distribution)

Reproduce code:
---
echo "**";
echo "Example1: call using array() to pass ArrayOfString";
$client = new SoapClient("https://ccuapi.akamai.com/ccuapi-axis.wsdl";);
var_dump($client->__getFunctions());
var_dump($client->__getTypes()); 

$params = array('xxx', 'yyy', NULL, NULL, 
"http://objects.dev.tremormedia.com/xml/val.xml";);

try {
$purgeResult = $client->purgeRequest($params);
}
catch(SoapFault $e){
echo "Exception ";
var_dump($e);
echo "";

}
var_dump($purgeResult);

echo "**";
echo "Example7: call using associative array() to pass parameters; 
ArrayOfString is passed as php array()" . "";
$client = new SoapClient("https://ccuapi.akamai.com/ccuapi-axis.wsdl";);
var_dump($client->__getFunctions());
var_dump($client->__getTypes()); 

$params = array(
"name" => "xxx", 
"pwd" => "yyy", 
"network" => array(''), 
"opt" => array("action=remove"), 
"uri"=> array("http://objects.dev.tremormedia.com/xml/val.xml";) 
);

try {
$purgeResult = $client->purgeRequest($params);
}
catch(SoapFault $e){
echo "Exception ";
var_dump($e);
echo "";

}
var_dump($purgeResult);

Expected result:

should return something... perhaps an Akamai error (url does not existetc.). 
Should not cause a php exception

Actual result:
--
object(SoapFault)[2]
  protected 'message' => string 'Exception: class 
com.idoox.soap.DemarshallException: Type in schema differs from type in SOAP 
message - expected string@http://www.w3.org/1999/XMLSchema; got 
ArrayOfString@http://www.akamai.com/purge' (length=199)
  private 'string' => string '' (length=0)
  protected 'code' => i

[PHP-BUG] Bug #60849 [NEW]: Too many open links not reported correctly

2012-01-23 Thread haavard dot pedersen at gmail dot com
From: 
Operating system: Linux
PHP version:  5.3.9
Package:  MySQLi related
Bug Type: Bug
Bug description:Too many open links not reported correctly

Description:

The "Too many links" error condition does not provide any error code. The
only way 
you can get a description of the error is via the warning output. Run test
script 
with mysqli.max_connections = 1 to see the problem. This even breaks the 
documentations example for mysqli_real_connect().

Test script:
---
$link1 = mysqli_init();
$m_rc1 = mysqli_real_connect($link1, 'localhost', 'dbuser', 'dbpassword',
'testdb', 8889);

echo "--- Opening second link ---\n";
$link2 = mysqli_init();
echo "mysqli_init() result : ".var_export($link2, TRUE)."\n";

echo "--- Opening second connection ---\n";
$m_rc2 = mysqli_real_connect($link2, 'localhost', 'dbuser', 'dbpassword',
'testdb', 8889);
echo "mysqli_real_connect() result : ".var_export($m_rc2, TRUE)."\n";
echo "Error number: ".var_export(mysqli_connect_errno($link2), TRUE)."\n";


Expected result:

An error number returned on the last line.

Actual result:
--
Error number is 0, possibly indicating success.

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



[PHP-BUG] Bug #60848 [NEW]: php -r works differently

2012-01-23 Thread public at grik dot net
From: 
Operating system: linux
PHP version:  5.4.0RC6
Package:  CGI/CLI related
Bug Type: Bug
Bug description:php -r works differently

Description:

PHP behaves differently with the code given in a file and in a parameter
provided 
with -r
php -r ignores variables, partially recognizes scalar type hinting.

Test script:
---
[root@devel data]# php -r "echo 1;"
1[root@devel data]# php -r "$x=3;"

Parse error: syntax error, unexpected '=' in Command line code on line 1


# php -r "var_dump($x);"

Warning: Wrong parameter count for var_dump() in Command line code on line
1

# php -r "function foo(int $a){}"

Parse error: syntax error, unexpected '(int )' (int) (T_INT_CAST),
expecting '(' in Command line code on line 1

Expected result:

1

Actual result:
--
Parse errors

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



Req #41243 [Com]: How to use ZIPARCHIVE::CM_STORE

2012-01-23 Thread mpeters at domblogger dot net
Edit report at https://bugs.php.net/bug.php?id=41243&edit=1

 ID: 41243
 Comment by: mpeters at domblogger dot net
 Reported by:joel dot alexandre at gmail dot com
 Summary:How to use ZIPARCHIVE::CM_STORE
 Status: Assigned
 Type:   Feature/Change Request
 Package:Zip Related
 PHP Version:5.x
 Assigned To:pajoye
 Block user comment: N
 Private report: N

 New Comment:

It is imperative that this bug be addressed and fixed.

The epub specification requires that the first file in the zip archive be named 
mimetype and be uncompressed.

Until this bug is fixed, it is thus impossible to create a valid epub file in 
pure php w/o executing system commands (forbidden in many environments).

*maybe* it could be worked around by having a skeleton zip archive with the 
mimetype file in it uncompressed, but really, we need to be able to create a 
fresh zip archive, add that file, with no compression.


Previous Comments:

[2010-07-02 14:20:03] php at atis dot id dot lv

This would be quite nice for me too. No compression could be useful for 
creating large archives of multiple files on the fly.


[2010-06-04 17:44:31] shockmaker at hotmail dot com

I'm looking to create a zip file with a compression level of 0 on some files.
So this feature is essential for me.


[2010-03-16 04:53:19] jotunbane at gmail dot com

3 years and still no solution to this?

Dude you are holding back an entire industry here (exaggeration, I know).

Can somebody come up with a workaround for this??


[2009-12-13 16:49:59] made at up dot address

Please implement the ability to store files uncompressed in a zip archive.

Without this, it is not possible to create epub documents using php, as the 
standards require that a particular file is always added to the archive 
uncompressed.

http://www.idpf.org/2007/ops/OPS_2.0_final_spec.html


[2009-05-26 11:31:03] andreidf at yahoo dot com

"Future versions will let you specify the compression mode and method."

When? :)




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


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


[PHP-BUG] Req #60847 [NEW]: mkdir second argument should prepend leading zero if only 3 numbers are inputte

2012-01-23 Thread me at davecarlson dot co dot uk
From: 
Operating system: Debian Squeeze
PHP version:  5.3.9
Package:  *Directory/Filesystem functions
Bug Type: Feature/Change Request
Bug description:mkdir second argument should prepend leading zero if only 3 
numbers are inputte

Description:

---
>From manual page:
http://www.php.net/function.mkdir#refsect1-function.mkdir-
parameters
---

It can be **very** easy to omit the leading zero in the permissions
argument, 
especially if working on a command line all day where "775" for example
works in 
a chmod. Although the documentation clearly states it needs a leading zero,
it 
would be good if the function could detect such a trivial error that can
lead to 
quite bad results. It would also help consistency between the linux command
line 
and php.

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



Bug #60719 [Asn]: dev-lang/php-5.3.9 has problems with stream_get_line()

2012-01-23 Thread cataphract
Edit report at https://bugs.php.net/bug.php?id=60719&edit=1

 ID: 60719
 Updated by: cataphr...@php.net
 Reported by:alexander dot haensch at gmail dot com
 Summary:dev-lang/php-5.3.9 has problems with
 stream_get_line()
 Status: Assigned
 Type:   Bug
 Package:Streams related
 Operating System:   gentoo
 PHP Version:5.3.9
 Assigned To:cataphract
 Block user comment: N
 Private report: N

 New Comment:

You can patch main/streams/streams.c with the output of
svn diff 
http://svn.php.net/repository/php/php-src/branches/PHP_5_3/main/streams/streams.c@322581
 
http://svn.php.net/repository/php/php-src/branches/PHP_5_3/main/streams/streams.c@322582


Previous Comments:

[2012-01-23 08:52:09] alexander dot haensch at gmail dot com

Can someone send the patch itself here? 
It impossible for me to test the whole php snapshot on my production system. If 
i could get the stream_get_line() patch i could test it.


[2012-01-23 08:21:27] cataphr...@php.net

Snapshots can be found at http://snaps.php.net/ (note the fix is not in 5.4, 
only 5.3 and trunk).


[2012-01-23 08:20:11] cataphr...@php.net

Yesterday I committed some fixes to stream_get_line() (see bug #60817). Please 
see if it has any influence in your problem (it's likely it does).

Thank you.


[2012-01-22 23:14:43] seguer at gmail dot com

I have updated https://github.com/kr/beanstalkd/issues/88 with a packet trace 
suggested by kr, author of beanstalkd


[2012-01-19 00:46:49] seguer at gmail dot com

I can confirm this occuring with PHP 5.3.9 and beanstalkd.

I have created an issue with test code on the beanstalkd github repo: 
https://github.com/kr/beanstalkd/issues/88

It only seems to happen with a socket connection to a beanstalkd service, as 
testing it against google.com.au is fine.




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


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


Bug #60719 [Asn]: dev-lang/php-5.3.9 has problems with stream_get_line()

2012-01-23 Thread alexander dot haensch at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60719&edit=1

 ID: 60719
 User updated by:alexander dot haensch at gmail dot com
 Reported by:alexander dot haensch at gmail dot com
 Summary:dev-lang/php-5.3.9 has problems with
 stream_get_line()
 Status: Assigned
 Type:   Bug
 Package:Streams related
 Operating System:   gentoo
 PHP Version:5.3.9
 Assigned To:cataphract
 Block user comment: N
 Private report: N

 New Comment:

Can someone send the patch itself here? 
It impossible for me to test the whole php snapshot on my production system. If 
i could get the stream_get_line() patch i could test it.


Previous Comments:

[2012-01-23 08:21:27] cataphr...@php.net

Snapshots can be found at http://snaps.php.net/ (note the fix is not in 5.4, 
only 5.3 and trunk).


[2012-01-23 08:20:11] cataphr...@php.net

Yesterday I committed some fixes to stream_get_line() (see bug #60817). Please 
see if it has any influence in your problem (it's likely it does).

Thank you.


[2012-01-22 23:14:43] seguer at gmail dot com

I have updated https://github.com/kr/beanstalkd/issues/88 with a packet trace 
suggested by kr, author of beanstalkd


[2012-01-19 00:46:49] seguer at gmail dot com

I can confirm this occuring with PHP 5.3.9 and beanstalkd.

I have created an issue with test code on the beanstalkd github repo: 
https://github.com/kr/beanstalkd/issues/88

It only seems to happen with a socket connection to a beanstalkd service, as 
testing it against google.com.au is fine.


[2012-01-11 22:41:19] cataphr...@php.net

There's a change in 5.3.9 in stream_get_line that may be causing your problems, 
but to understand if it's a bug in PHP, we'd need a short reproducible script 
(or a pair of scripts in this case).

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


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


Bug #60837 [Ctl]: Segmentation fail, if use trait

2012-01-23 Thread piphon at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60837&edit=1

 ID: 60837
 User updated by:piphon at gmail dot com
 Reported by:piphon at gmail dot com
 Summary:Segmentation fail, if use trait
 Status: Critical
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 11.10 64bit
 PHP Version:5.4SVN-2012-01-22 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

> What exactly did you do with the reflection API? Perhaps, there was something 
going wrong? At least it should not mess up the function tables.

Unknown. Reflection used only by Doctrine Annotations driver. However in older 
code, I'm used static method in trait, which stored in value static property.

P.S. Mystery...


Previous Comments:

[2012-01-23 08:43:32] g...@php.net

The stack trace you provided points at a corrupted function table, I would say.
That might still be something different than the comment bug.

What exactly did you do with the reflection API? Perhaps, there was something 
going wrong? At least it should not mess up the function tables.


[2012-01-23 08:41:44] larue...@php.net

maybe dmitry's fix has also fixed this problem: http://svn.php.net/viewvc?
view=revision&revision=322495


[2012-01-23 08:38:19] piphon at gmail dot com

In Zend/zend_comile.c changed behavior of traits. Perhaps this is corrected 
bug. My original point of view (when I first met this bug): a mistake in 
reflection for classes that used traits). I removed comment in trait and all 
successful worked (RC1 or 2, i don't remember).


[2012-01-23 07:54:39] g...@php.net

Hi, I was not able to reproduce the problem, because I do not have the 
necessary 
setup. Think, I got as far as that PDO complains about a missing database 
table, 
but I also changed the db driver from mysql to sqlite.

The only thing I saw was that on an old checkout, the bug with doccomments 
#60809 
caused segfaults. But, that seems unrelated to the stacktrace below.


[2012-01-23 07:40:43] piphon at gmail dot com

Check last commits for RC in SVN:

PHP 5.4.0 RC5 - fail 
(https://svn.php.net/repository/php/php-src/tags/php_5_4_0RC5)
PHP 5.4.0 RC6 - fail 
(https://svn.php.net/repository/php/php-src/tags/php_5_4_0RC6)
PHP 5.4.0 RC7-dev - worked in last commits 
(https://svn.php.net/repository/php/php-src/branches/PHP_5_4)

I'm unable to verify trunk (PHP 5.5 dev), because PDO is not installed or is 
not compiled.

P.S. My English bad...




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


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


Bug #60837 [Ctl]: Segmentation fail, if use trait

2012-01-23 Thread gron
Edit report at https://bugs.php.net/bug.php?id=60837&edit=1

 ID: 60837
 Updated by: g...@php.net
 Reported by:piphon at gmail dot com
 Summary:Segmentation fail, if use trait
 Status: Critical
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 11.10 64bit
 PHP Version:5.4SVN-2012-01-22 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

The stack trace you provided points at a corrupted function table, I would say.
That might still be something different than the comment bug.

What exactly did you do with the reflection API? Perhaps, there was something 
going wrong? At least it should not mess up the function tables.


Previous Comments:

[2012-01-23 08:41:44] larue...@php.net

maybe dmitry's fix has also fixed this problem: http://svn.php.net/viewvc?
view=revision&revision=322495


[2012-01-23 08:38:19] piphon at gmail dot com

In Zend/zend_comile.c changed behavior of traits. Perhaps this is corrected 
bug. My original point of view (when I first met this bug): a mistake in 
reflection for classes that used traits). I removed comment in trait and all 
successful worked (RC1 or 2, i don't remember).


[2012-01-23 07:54:39] g...@php.net

Hi, I was not able to reproduce the problem, because I do not have the 
necessary 
setup. Think, I got as far as that PDO complains about a missing database 
table, 
but I also changed the db driver from mysql to sqlite.

The only thing I saw was that on an old checkout, the bug with doccomments 
#60809 
caused segfaults. But, that seems unrelated to the stacktrace below.


[2012-01-23 07:40:43] piphon at gmail dot com

Check last commits for RC in SVN:

PHP 5.4.0 RC5 - fail 
(https://svn.php.net/repository/php/php-src/tags/php_5_4_0RC5)
PHP 5.4.0 RC6 - fail 
(https://svn.php.net/repository/php/php-src/tags/php_5_4_0RC6)
PHP 5.4.0 RC7-dev - worked in last commits 
(https://svn.php.net/repository/php/php-src/branches/PHP_5_4)

I'm unable to verify trunk (PHP 5.5 dev), because PDO is not installed or is 
not compiled.

P.S. My English bad...


[2012-01-23 03:24:56] larue...@php.net

I can not reproduce this... everything works well here.. (both svn-trunk and 
5.4 
branch)




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


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


Bug #60837 [Ctl]: Segmentation fail, if use trait

2012-01-23 Thread laruence
Edit report at https://bugs.php.net/bug.php?id=60837&edit=1

 ID: 60837
 Updated by: larue...@php.net
 Reported by:piphon at gmail dot com
 Summary:Segmentation fail, if use trait
 Status: Critical
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 11.10 64bit
 PHP Version:5.4SVN-2012-01-22 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

maybe dmitry's fix has also fixed this problem: http://svn.php.net/viewvc?
view=revision&revision=322495


Previous Comments:

[2012-01-23 08:38:19] piphon at gmail dot com

In Zend/zend_comile.c changed behavior of traits. Perhaps this is corrected 
bug. My original point of view (when I first met this bug): a mistake in 
reflection for classes that used traits). I removed comment in trait and all 
successful worked (RC1 or 2, i don't remember).


[2012-01-23 07:54:39] g...@php.net

Hi, I was not able to reproduce the problem, because I do not have the 
necessary 
setup. Think, I got as far as that PDO complains about a missing database 
table, 
but I also changed the db driver from mysql to sqlite.

The only thing I saw was that on an old checkout, the bug with doccomments 
#60809 
caused segfaults. But, that seems unrelated to the stacktrace below.


[2012-01-23 07:40:43] piphon at gmail dot com

Check last commits for RC in SVN:

PHP 5.4.0 RC5 - fail 
(https://svn.php.net/repository/php/php-src/tags/php_5_4_0RC5)
PHP 5.4.0 RC6 - fail 
(https://svn.php.net/repository/php/php-src/tags/php_5_4_0RC6)
PHP 5.4.0 RC7-dev - worked in last commits 
(https://svn.php.net/repository/php/php-src/branches/PHP_5_4)

I'm unable to verify trunk (PHP 5.5 dev), because PDO is not installed or is 
not compiled.

P.S. My English bad...


[2012-01-23 03:24:56] larue...@php.net

I can not reproduce this... everything works well here.. (both svn-trunk and 
5.4 
branch)


[2012-01-22 12:30:40] piphon at gmail dot com

> Do you have a reproduce code by any chance?

Yes. Finally recreated it.

Small example with dependencies (zf, doctrine, e.t.c) on github.com: 
g...@github.com:alurin/zend-bug.git

Files:
  - Example/IdentityTrait.php - trait, add id field
  - Example/Temp.php - entity, used IdentityTrait
  - library/ - vendors libraries (submodules)
  - bootstrap.php - setup doctrine
  - script.php - Console interface for doctrine (if update or create data 
scheme).
  - index.php  - Test example

$ php script.php orm:schema-tool:create
ATTENTION: This operation should not be executed in a production environment.

Creating database schema...
Database schema created successfully!
Segmentation fail (core dumped)

$ php index.php
zend_mm_heap corrupted


All code in two files

index.php
-
 array(
'namespaces' => array(
'Zend'  => PATH_TO_VENDORS . 
'/zf2/library/Zend',
'Doctrine\ORM'  => PATH_TO_VENDORS . 
'/doctrine2/lib/Doctrine/ORM',
'Doctrine\Common'   => PATH_TO_VENDORS . 
'/doctrine2-common/lib/Doctrine/Common',
'Doctrine\DBAL' => PATH_TO_VENDORS . 
'/doctrine2-dbal/lib/Doctrine/DBAL',
'Symfony\Component\Console' => PATH_TO_VENDORS . 
'/symfony-console',
'Symfony\Component\Yaml'=> PATH_TO_VENDORS . 
'/symfony-yaml',
)
)
)
);

function create_doctrine() {
$cache = new \Doctrine\Common\Cache\ArrayCache;

$config = new Configuration;
$config->setMetadataCacheImpl($cache);
$driverImpl = $config->newDefaultAnnotationDriver(__DIR__ . '/Example');
$config->setMetadataDriverImpl($driverImpl);
$config->setQueryCacheImpl($cache);
$config->setProxyDir('/path/to/myproject/lib/MyProject/Proxies');
$config->setProxyNamespace('MyProject\Proxies');
$config->setAutoGenerateProxyClasses(false);

$connectionOptions = array(
'driver'   => 'pdo_mysql',/* Your DB driver here   */
'host' => 'localhost',/* Your DB host here */
'user' => 'php_bug',  /* Your DB user here */
'password' => 'A8haaWUH7wxjhfrn', /* Your DB user password */
'dbname'   => 'php_bug',  /* Your DB name here */
'driverOptions' => array(
1002 => "SET NAMES 'UTF8'"
),
);

$em = EntityManager::create($connectionOptions, $config);
return $em;
}

$main = function() {
$em = create_doctrine();

include 'full-compounds.php';
$temp = new Example\Temp();
$em->persist($temp);
$em->flush();

$rep

Bug #60837 [Ctl]: Segmentation fail, if use trait

2012-01-23 Thread piphon at gmail dot com
Edit report at https://bugs.php.net/bug.php?id=60837&edit=1

 ID: 60837
 User updated by:piphon at gmail dot com
 Reported by:piphon at gmail dot com
 Summary:Segmentation fail, if use trait
 Status: Critical
 Type:   Bug
 Package:Reproducible crash
 Operating System:   Ubuntu 11.10 64bit
 PHP Version:5.4SVN-2012-01-22 (SVN)
 Block user comment: N
 Private report: N

 New Comment:

In Zend/zend_comile.c changed behavior of traits. Perhaps this is corrected 
bug. My original point of view (when I first met this bug): a mistake in 
reflection for classes that used traits). I removed comment in trait and all 
successful worked (RC1 or 2, i don't remember).


Previous Comments:

[2012-01-23 07:54:39] g...@php.net

Hi, I was not able to reproduce the problem, because I do not have the 
necessary 
setup. Think, I got as far as that PDO complains about a missing database 
table, 
but I also changed the db driver from mysql to sqlite.

The only thing I saw was that on an old checkout, the bug with doccomments 
#60809 
caused segfaults. But, that seems unrelated to the stacktrace below.


[2012-01-23 07:40:43] piphon at gmail dot com

Check last commits for RC in SVN:

PHP 5.4.0 RC5 - fail 
(https://svn.php.net/repository/php/php-src/tags/php_5_4_0RC5)
PHP 5.4.0 RC6 - fail 
(https://svn.php.net/repository/php/php-src/tags/php_5_4_0RC6)
PHP 5.4.0 RC7-dev - worked in last commits 
(https://svn.php.net/repository/php/php-src/branches/PHP_5_4)

I'm unable to verify trunk (PHP 5.5 dev), because PDO is not installed or is 
not compiled.

P.S. My English bad...


[2012-01-23 03:24:56] larue...@php.net

I can not reproduce this... everything works well here.. (both svn-trunk and 
5.4 
branch)


[2012-01-22 12:30:40] piphon at gmail dot com

> Do you have a reproduce code by any chance?

Yes. Finally recreated it.

Small example with dependencies (zf, doctrine, e.t.c) on github.com: 
g...@github.com:alurin/zend-bug.git

Files:
  - Example/IdentityTrait.php - trait, add id field
  - Example/Temp.php - entity, used IdentityTrait
  - library/ - vendors libraries (submodules)
  - bootstrap.php - setup doctrine
  - script.php - Console interface for doctrine (if update or create data 
scheme).
  - index.php  - Test example

$ php script.php orm:schema-tool:create
ATTENTION: This operation should not be executed in a production environment.

Creating database schema...
Database schema created successfully!
Segmentation fail (core dumped)

$ php index.php
zend_mm_heap corrupted


All code in two files

index.php
-
 array(
'namespaces' => array(
'Zend'  => PATH_TO_VENDORS . 
'/zf2/library/Zend',
'Doctrine\ORM'  => PATH_TO_VENDORS . 
'/doctrine2/lib/Doctrine/ORM',
'Doctrine\Common'   => PATH_TO_VENDORS . 
'/doctrine2-common/lib/Doctrine/Common',
'Doctrine\DBAL' => PATH_TO_VENDORS . 
'/doctrine2-dbal/lib/Doctrine/DBAL',
'Symfony\Component\Console' => PATH_TO_VENDORS . 
'/symfony-console',
'Symfony\Component\Yaml'=> PATH_TO_VENDORS . 
'/symfony-yaml',
)
)
)
);

function create_doctrine() {
$cache = new \Doctrine\Common\Cache\ArrayCache;

$config = new Configuration;
$config->setMetadataCacheImpl($cache);
$driverImpl = $config->newDefaultAnnotationDriver(__DIR__ . '/Example');
$config->setMetadataDriverImpl($driverImpl);
$config->setQueryCacheImpl($cache);
$config->setProxyDir('/path/to/myproject/lib/MyProject/Proxies');
$config->setProxyNamespace('MyProject\Proxies');
$config->setAutoGenerateProxyClasses(false);

$connectionOptions = array(
'driver'   => 'pdo_mysql',/* Your DB driver here   */
'host' => 'localhost',/* Your DB host here */
'user' => 'php_bug',  /* Your DB user here */
'password' => 'A8haaWUH7wxjhfrn', /* Your DB user password */
'dbname'   => 'php_bug',  /* Your DB name here */
'driverOptions' => array(
1002 => "SET NAMES 'UTF8'"
),
);

$em = EntityManager::create($connectionOptions, $config);
return $em;
}

$main = function() {
$em = create_doctrine();

include 'full-compounds.php';
$temp = new Example\Temp();
$em->persist($temp);
$em->flush();

$repo = $em->getRepository('Example\Temp');
$temp = $repo->find(1);
$temp->events()->attach('init', function() {
echo "Init\n";
});
};

call_user_func_array($main, array());

full-compunds.php
--

Bug #60719 [Asn]: dev-lang/php-5.3.9 has problems with stream_get_line()

2012-01-23 Thread cataphract
Edit report at https://bugs.php.net/bug.php?id=60719&edit=1

 ID: 60719
 Updated by: cataphr...@php.net
 Reported by:alexander dot haensch at gmail dot com
 Summary:dev-lang/php-5.3.9 has problems with
 stream_get_line()
 Status: Assigned
 Type:   Bug
 Package:Streams related
 Operating System:   gentoo
 PHP Version:5.3.9
 Assigned To:cataphract
 Block user comment: N
 Private report: N

 New Comment:

Snapshots can be found at http://snaps.php.net/ (note the fix is not in 5.4, 
only 5.3 and trunk).


Previous Comments:

[2012-01-23 08:20:11] cataphr...@php.net

Yesterday I committed some fixes to stream_get_line() (see bug #60817). Please 
see if it has any influence in your problem (it's likely it does).

Thank you.


[2012-01-22 23:14:43] seguer at gmail dot com

I have updated https://github.com/kr/beanstalkd/issues/88 with a packet trace 
suggested by kr, author of beanstalkd


[2012-01-19 00:46:49] seguer at gmail dot com

I can confirm this occuring with PHP 5.3.9 and beanstalkd.

I have created an issue with test code on the beanstalkd github repo: 
https://github.com/kr/beanstalkd/issues/88

It only seems to happen with a socket connection to a beanstalkd service, as 
testing it against google.com.au is fine.


[2012-01-11 22:41:19] cataphr...@php.net

There's a change in 5.3.9 in stream_get_line that may be causing your problems, 
but to understand if it's a bug in PHP, we'd need a short reproducible script 
(or a pair of scripts in this case).

Thanks.


[2012-01-11 18:31:42] alexander dot haensch at gmail dot com

Description:

It looks like that the new php version has a problem with talking to beanstalkd
on a local socket.
example:
$packet = stream_get_line($this->_connection, 16384, "\r\n");

https://github.com/davidpersson/beanstalk/blob/master/src/Socket/Beanstalk.php#L190

Expected result:

operation should finish in below 1second

Actual result:
--
needs about 1 minute to complete






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


Bug #60719 [Fbk->Asn]: dev-lang/php-5.3.9 has problems with stream_get_line()

2012-01-23 Thread cataphract
Edit report at https://bugs.php.net/bug.php?id=60719&edit=1

 ID: 60719
 Updated by: cataphr...@php.net
 Reported by:alexander dot haensch at gmail dot com
 Summary:dev-lang/php-5.3.9 has problems with
 stream_get_line()
-Status: Feedback
+Status: Assigned
 Type:   Bug
 Package:Streams related
 Operating System:   gentoo
 PHP Version:5.3.9
-Assigned To:
+Assigned To:cataphract
 Block user comment: N
 Private report: N

 New Comment:

Yesterday I committed some fixes to stream_get_line() (see bug #60817). Please 
see if it has any influence in your problem (it's likely it does).

Thank you.


Previous Comments:

[2012-01-22 23:14:43] seguer at gmail dot com

I have updated https://github.com/kr/beanstalkd/issues/88 with a packet trace 
suggested by kr, author of beanstalkd


[2012-01-19 00:46:49] seguer at gmail dot com

I can confirm this occuring with PHP 5.3.9 and beanstalkd.

I have created an issue with test code on the beanstalkd github repo: 
https://github.com/kr/beanstalkd/issues/88

It only seems to happen with a socket connection to a beanstalkd service, as 
testing it against google.com.au is fine.


[2012-01-11 22:41:19] cataphr...@php.net

There's a change in 5.3.9 in stream_get_line that may be causing your problems, 
but to understand if it's a bug in PHP, we'd need a short reproducible script 
(or a pair of scripts in this case).

Thanks.


[2012-01-11 18:31:42] alexander dot haensch at gmail dot com

Description:

It looks like that the new php version has a problem with talking to beanstalkd
on a local socket.
example:
$packet = stream_get_line($this->_connection, 16384, "\r\n");

https://github.com/davidpersson/beanstalk/blob/master/src/Socket/Beanstalk.php#L190

Expected result:

operation should finish in below 1second

Actual result:
--
needs about 1 minute to complete






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


Bug #60775 [Csd->Bgs]: file_get_contents does not return all content

2012-01-23 Thread cataphract
Edit report at https://bugs.php.net/bug.php?id=60775&edit=1

 ID: 60775
 Updated by: cataphr...@php.net
 Reported by:tech163 at fusionswift dot com
 Summary:file_get_contents does not return all content
-Status: Closed
+Status: Bogus
 Type:   Bug
 Package:Streams related
 Operating System:   CentOS 6.2
 PHP Version:5.3.9
 Block user comment: N
 Private report: N



Previous Comments:

[2012-01-18 03:43:51] tech163 at fusionswift dot com

Oops. Seemed to be a nginx proxy issue.


[2012-01-17 16:49:37] m...@php.net

Look, how should I reproduce when this script only works on your server.
Please provide a self-contained reproduce case.  Eventually check your server 
config, too.


[2012-01-17 13:02:38] tech163 at fusionswift dot com



where the file, wp-includes/js/tinymce/wp-tinymce.js, contains 
https://www.cheatswhiz.com/wp-includes/js/tinymce/wp-tinymce.js. When that code 
is excuted, only portions of https://www.cheatswhiz.com/wp-
includes/js/tinymce/wp-tinymce.js is read, Also, the echo 'test'; after the 
file_get_contents is not executed.


[2012-01-17 13:00:20] m...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.




[2012-01-17 02:41:02] tech163 at fusionswift dot com

Description:

This error began appearing a few days ago after I ran yum update, and 
recompiled 
PHP, using 

'./configure'  '--prefix=/home/arch120113' '--with-config-file-
path=/home/arch120112/php' '--with-mysqli=mysqlnd' '--with-mysql=mysqlnd' 
'--with-
pdo-mysql=mysqlnd' '--with-mysql-sock=/var/lib/mysql/mysql.sock' 
'--enable-bcmath' 
'--enable-calendar' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--
enable-mbstring' '--enable-sockets' '--with-bz2' '--with-curl' '--with-gd' '--
enable-gd-native-ttf' '--with-jpeg-dir=/opt' '--with-png-dir=/opt' '--with-
gettext' '--with-imap' '--with-imap-ssl' '--with-kerberos' '--with-mcrypt' '--
with-openssl' '--with-zlib' '--enable-zip' '--enable-fpm' '--with-freetype-
dir=/usr/include/freetype2/'

Now, when I use file_get_contents() on a large file (300KB), not the entire 
thing 
appears.

Test script:
---
https://www.cheatswhiz.com/info.php



File it's reading from is 
https://www.cheatswhiz.com/wp-includes/js/tinymce/wp-tinymce.js

Expected result:

The entire content of the file is read. 

Actual result:
--
Only part of the content is read 






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


Bug #39197 [Com]: How do I get shared library 'libphp5.so'?

2012-01-23 Thread lzsiga at freemail dot c3 dot hu
Edit report at https://bugs.php.net/bug.php?id=39197&edit=1

 ID: 39197
 Comment by: lzsiga at freemail dot c3 dot hu
 Reported by:lzsiga at freemail dot c3 dot hu
 Summary:How do I get shared library 'libphp5.so'?
 Status: Bogus
 Type:   Bug
 Package:Apache2 related
 Operating System:   AIX
 PHP Version:5.1.6
 Block user comment: N
 Private report: N

 New Comment:

using LDFLAGS='-Wl,-brtl' makes the situation much easier... putting shared 
objects into *.a archives (what AIX does by default) is simply bad...


Previous Comments:

[2006-11-11 23:02:17] ras...@php.net

Ok, so not really a bug here.  The configure check does warn you about gnu-ld.  
It could probably be cleaned up a bit, but as you said, you are on a rather 
exotic platform.


[2006-10-30 02:59:18] lzsiga at freemail dot c3 dot hu

Let me summarize the problem in three steps:

When compiling PHP5 on AIX:

1. If you want to get dynamically loadable shared object (generally this is 
your first goal) do not use GNU-ld.
The default AIX linker will give you the AIX-compliant 'libphp5.so' within 
'libphp5.a'.

2. If you want to get standalone executable (generally this is your second 
goal) you have to edit one of the files 'Makefile', 'configure' or 
'sapi/cli/config.m4' as described in bug #39187.

3. If you are using such an exotic platform then Prepare for trouble (And make 
it double).

Now will someone please close this bug.


[2006-10-20 10:09:22] lzsiga at freemail dot c3 dot hu

Very well, I was blind enough to miss this part of the output of ./configure:

checking whether the gcc linker (/usr/local/bin/gld) supports shared libraries..
*** Warning: the GNU linker, at least up to release 2.9.1, is reported
*** to be unable to reliably create shared libraries on AIX.
*** Therefore, libtool is disabling shared libraries support.  If you
*** really care for shared libraries, you may want to modify your PATH
*** so that a non-GNU linker is found, and then restart.

no
checking dynamic linker characteristics... aix5.2.0.0 ld.so
checking how to hardcode library paths into programs... unsupported
checking whether stripping libraries is possible... no
checking if libtool supports shared libraries... no
checking whether to build shared libraries... no
checking whether to build static libraries... yes


[2006-10-19 13:09:02] lzsiga at freemail dot c3 dot hu

Description:

Some of us are really quick-handed closing bug-reports as 'bogus', but I still 
have a problem with PHP-5.1.6 compilation on AIX-5.2:
Even specifing both --enable-shared and --disable-static is not enough to 
create a shared object (libphp5.so).
For some strange reason the problem occures only when I set environment 
variable LD to the GNU-ld.








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