[PHP-BUG] Req #63744 [NEW]: references in list()
From: ninzya at inbox dot lv Operating system: Any PHP version: Irrelevant Package: Scripting Engine problem Bug Type: Feature/Change Request Bug description:references in list() Description: Would be good to have a possibility to extract array elements by ref like in test script. Test script: --- $arr = array( 1, 2 ); list( &$first, &$second ) = $arr; ++$first; --$second; print_r( $arr); Expected result: array( 2, 1 ) Actual result: -- PHP Parse error: syntax error, unexpected '&', expecting ',' or ')' in ... on line 2 -- Edit bug report at https://bugs.php.net/bug.php?id=63744&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63744&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63744&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63744&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63744&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63744&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63744&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63744&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63744&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63744&r=support Expected behavior: https://bugs.php.net/fix.php?id=63744&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63744&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63744&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63744&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63744&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63744&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63744&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63744&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63744&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63744&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63744&r=mysqlcfg
Req #54243 [Com]: Shorter syntax for closures
Edit report at https://bugs.php.net/bug.php?id=54243&edit=1
ID: 54243
Comment by: ninzya at inbox dot lv
Reported by:anil at saog dot net
Summary:Shorter syntax for closures
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: *
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I'm sorry, Anil, but you did not convince me on readability of "Where($($a, $b,
{$a == $b}))".
"Microsoft's way" to define closures in C# linq "Where((a,b) => a == b)", in my
opinion, is far more readable. I read it as "a two argument function "(a,b)"
which results ("=>") in a being equal b ("a == b") or whatever the logic is
defined there. However you can not read "$($a, $b, {$a == $b})" as good as you
read microsoft's code. To me, there are too much dollar characters and they
make
your eyes hurt when you try to really understand which token does the dollar
sing really belong to. You definately don't want readers of your code to
tokenize a lot when the goal is readability :-)
Previous Comments:
[2012-03-19 11:54:13] anil at saog dot net
Guys, please calm down. I have no idea why you write these comments in a heat
but this issue is just a wishing. Also, readability is a non-objective property
which generally differs person to person, but the "key" is "shorter means
readable". By the way, did you ever inspect c# - linq syntax?
C# : ...Where((a,b) => a == b)
PHP : ...Where(function($a, $b){ return $a == $b; })
MY : ...Where($($a, $b, {$a == $b}))
readability? yes of course readability... so you think you are better than
microsoft on readability?
If you do not agree of course it is okay just tell it (like a human) otherwise
keep your ignoble and invaluable ideas to yourself.
[2012-03-19 11:13:20] ninzya at inbox dot lv
I think the proposed syntax is not readable at all. Rather it looks like you
have
been affected by a "wannabe jQuery inventor". How do you come up with a dollar
sign being "readable"? How do you define "readable code"? If you read your
code,
you read it as "dollar, dollar, bracket, dollar, dollar... whatever, dollar".
Is
this what you call "readability"?
However I do agree that the "use()" clause of closures sometimes bloats the
code a
little bit, especially if the closure is importing a lot of variables from its
context.
[2012-03-19 09:08:09] danko at very dot lv
Um, no, *that* is unreadable. The original syntax can easily be made readable
if you do care:
$myObject->MyMethod(
'abc',
function ($a) use ($b) {
return $a == $b;
}
);
There you go. As readable as it gets - just add some newlines and tabs. On the
other hand, a soup of brackets and dollar signs can't be readable regardless of
formatting.
[2011-03-13 16:16:45] anil at saog dot net
Changed package
[2011-03-13 16:09:36] anil at saog dot net
Description:
Current closure syntax makes the code a little bit unreadable and also
shortening the syntax of a handy thing like this seems more logical.
Test script:
---
As of now "closure" syntax is:
function ($a) use($b){ return $a == $b; }
Passing a closure to any other scope:
$myObject = new myObject ();
$myObject->MyMethod('abc', function ($a) use($b){ return $a == $b; });
Expected result:
My short syntax candidate is:
$([arg1],[arg2],[arg...], {[method body]},
[scope_var1],[scope_var2],[scope_var...])
So passing with use token syntax:
$myObject = new myObject ();
$myObject->MyMethod('abc', $($a, {$a == $b}, $b));
Without "use" token:
$myObject = new myObject ();
$myObject->MyMethod('abc', $($a, {$a == $b}));
With more than one method argument:
$myObject = new myObject ();
$myObject->MyMethod('abc', $($a,$k,$p,{$a == $b}));
--
Edit this bug report at https://bugs.php.net/bug.php?id=54243&edit=1
Req #61682 [Com]: allow use( $var as $varCopy, &$var as $varRef) syntax for closures
Edit report at https://bugs.php.net/bug.php?id=61682&edit=1
ID: 61682
Comment by: ninzya at inbox dot lv
Reported by:ninzya at inbox dot lv
Summary:allow use( $var as $varCopy, &$var as $varRef)
syntax for closures
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: Any
PHP Version:5.4.1RC1
Block user comment: N
Private report: N
New Comment:
I'm sorry, in the test script a $myFn() call should follow $myFn definition:
$someLongArray =array( 1, 2, 3 );
$myFn =function() use( $someLongArray as $arrCopy, &$someLongArray as $arrRef )
{
array_push( $arrCopy, 4);
array_push( $arrRef, 5);
};
$myFn();
print_r( $someLongArray);// 1, 2, 3, 5
Previous Comments:
[2012-04-09 15:41:46] ninzya at inbox dot lv
Description:
I'd like to propose a syntax for closures that would allow to specify a name
for
the imported symbol (variable). Please see test script.
Test script:
---
$someLongArray =array( 1, 2, 3 );
$myFn =function() use( $someLongArray as $arrCopy, &$someLongArray as $arrRef )
{
array_push( $arrCopy, 4);
array_push( $arrRef, 5);
};
print_r( $someLongArray);// 1, 2, 3, 5
Expected result:
Expecting such syntax to be supported in the future.
Actual result:
--
Syntax error.
--
Edit this bug report at https://bugs.php.net/bug.php?id=61682&edit=1
[PHP-BUG] Req #61682 [NEW]: allow use( $var as $varCopy, &$var as $varRef) syntax for closures
From:
Operating system: Any
PHP version: 5.4.1RC1
Package: Scripting Engine problem
Bug Type: Feature/Change Request
Bug description:allow use( $var as $varCopy, &$var as $varRef) syntax for
closures
Description:
I'd like to propose a syntax for closures that would allow to specify a
name for
the imported symbol (variable). Please see test script.
Test script:
---
$someLongArray =array( 1, 2, 3 );
$myFn =function() use( $someLongArray as $arrCopy, &$someLongArray as
$arrRef ) {
array_push( $arrCopy, 4);
array_push( $arrRef, 5);
};
print_r( $someLongArray);// 1, 2, 3, 5
Expected result:
Expecting such syntax to be supported in the future.
Actual result:
--
Syntax error.
--
Edit bug report at https://bugs.php.net/bug.php?id=61682&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61682&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61682&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61682&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61682&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61682&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61682&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61682&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61682&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61682&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61682&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61682&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61682&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61682&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61682&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61682&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61682&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61682&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61682&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61682&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61682&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61682&r=mysqlcfg
Bug #48034 [Com]: Crash when script is 8192 (8KB) bytes long
Edit report at https://bugs.php.net/bug.php?id=48034&edit=1 ID: 48034 Comment by: ninzya at inbox dot lv Reported by:ninzya at inbox dot lv Summary:Crash when script is 8192 (8KB) bytes long Status: Assigned Type: Bug Package:Reproducible crash Operating System: * PHP Version:5.*, 6CVS (2009-04-21) Assigned To:dmitry Block user comment: N Private report: N New Comment: Few hours ago tried PHP 5.4. Bug is still there. Previous Comments: [2012-03-23 17:49:45] paj...@php.net @ninzya at inbox dot lv It was not in 5.3.10, so please try with 5.3 snapshots. [2012-03-23 17:46:39] ninzya at inbox dot lv Just ran into this problem again, almost exactly two years later :) But this time with 4KB (4096 bytes) long script: [2012-01-17 09:30:14] dmi...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revision&revision=322384 Log: Fixed workaround for bug #48034 on Windows (Crash when script is 8192 (8KB) bytes long) [2012-01-17 08:15:40] paj...@php.net Dmitry, I think you can apply it already :) [2012-01-16 23:09:15] paj...@php.net >From Matt (our tester/QA team): "I've tested the patch from 48034 on php_5_4 r322075 on Win7 x64 sp1 and it fixes the bug from 60771. I tested the repro script PID1080 from 60771 that produces a >8k text file and tries to require it. I also produced another >8k file myself and added some php code to it (inside https://bugs.php.net/bug.php?id=48034 -- Edit this bug report at https://bugs.php.net/bug.php?id=48034&edit=1
Bug #48034 [Com]: Crash when script is 8192 (8KB) bytes long
Edit report at https://bugs.php.net/bug.php?id=48034&edit=1 ID: 48034 Comment by: ninzya at inbox dot lv Reported by:ninzya at inbox dot lv Summary:Crash when script is 8192 (8KB) bytes long Status: Assigned Type: Bug Package:Reproducible crash Operating System: * PHP Version:5.*, 6CVS (2009-04-21) Assigned To:dmitry Block user comment: N Private report: N New Comment: Just ran into this problem again, almost exactly two years later :) But this time with 4KB (4096 bytes) long script: Previous Comments: [2012-01-17 09:30:14] dmi...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revision&revision=322384 Log: Fixed workaround for bug #48034 on Windows (Crash when script is 8192 (8KB) bytes long) [2012-01-17 08:15:40] paj...@php.net Dmitry, I think you can apply it already :) [2012-01-16 23:09:15] paj...@php.net >From Matt (our tester/QA team): "I've tested the patch from 48034 on php_5_4 r322075 on Win7 x64 sp1 and it fixes the bug from 60771. I tested the repro script PID1080 from 60771 that produces a >8k text file and tries to require it. I also produced another >8k file myself and added some php code to it (inside https://bugs.php.net/bug.php?id=48034 -- Edit this bug report at https://bugs.php.net/bug.php?id=48034&edit=1
Req #54243 [Com]: Shorter syntax for closures
Edit report at https://bugs.php.net/bug.php?id=54243&edit=1
ID: 54243
Comment by: ninzya at inbox dot lv
Reported by:anil at saog dot net
Summary:Shorter syntax for closures
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: *
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I think the proposed syntax is not readable at all. Rather it looks like you
have
been affected by a "wannabe jQuery inventor". How do you come up with a dollar
sign being "readable"? How do you define "readable code"? If you read your
code,
you read it as "dollar, dollar, bracket, dollar, dollar... whatever, dollar".
Is
this what you call "readability"?
However I do agree that the "use()" clause of closures sometimes bloats the
code a
little bit, especially if the closure is importing a lot of variables from its
context.
Previous Comments:
[2012-03-19 09:08:09] danko at very dot lv
Um, no, *that* is unreadable. The original syntax can easily be made readable
if you do care:
$myObject->MyMethod(
'abc',
function ($a) use ($b) {
return $a == $b;
}
);
There you go. As readable as it gets - just add some newlines and tabs. On the
other hand, a soup of brackets and dollar signs can't be readable regardless of
formatting.
[2011-03-13 16:16:45] anil at saog dot net
Changed package
[2011-03-13 16:09:36] anil at saog dot net
Description:
Current closure syntax makes the code a little bit unreadable and also
shortening the syntax of a handy thing like this seems more logical.
Test script:
---
As of now "closure" syntax is:
function ($a) use($b){ return $a == $b; }
Passing a closure to any other scope:
$myObject = new myObject ();
$myObject->MyMethod('abc', function ($a) use($b){ return $a == $b; });
Expected result:
My short syntax candidate is:
$([arg1],[arg2],[arg...], {[method body]},
[scope_var1],[scope_var2],[scope_var...])
So passing with use token syntax:
$myObject = new myObject ();
$myObject->MyMethod('abc', $($a, {$a == $b}, $b));
Without "use" token:
$myObject = new myObject ();
$myObject->MyMethod('abc', $($a, {$a == $b}));
With more than one method argument:
$myObject = new myObject ();
$myObject->MyMethod('abc', $($a,$k,$p,{$a == $b}));
--
Edit this bug report at https://bugs.php.net/bug.php?id=54243&edit=1
Bug #55334 [Com]: MySQLi make mod_php crash on stress test
Edit report at https://bugs.php.net/bug.php?id=55334&edit=1 ID: 55334 Comment by: ninzya at inbox dot lv Reported by:bruno at chalopin dot fr Summary:MySQLi make mod_php crash on stress test Status: Open Type: Bug Package:MySQLi related Operating System: Windows 2008r2 x64 PHP Version:5.3.7RC4 Block user comment: N Private report: N New Comment: Got apache crashing due to MySQLi as well. Here's the bug report: https://bugs.php.net/bug.php?id=55334 Previous Comments: [2011-10-21 14:47:09] doug at sevone dot com I have been able to reproduce a similar (if not the same) crash by this SIMPLER script: On another machine, I have about 12 threads doing GET requests to that page simultaneously. I usually see a crash after about 1-2 seconds. As far as I can tell, this is a "mysqli" issue only (involving thread-safety). If I disable mysqlnd, then I still see the same problem. I see this on MySQL 5.5 and 5.1. However, the MySQL version should NOT matter, since I can reproduce the problem without EVER connecting to a MySQL box, and since it crashes using mysqlnd. OS: gentoo (x86_64) Apache: www-servers/apache-2.2.14-r1 Apache: www-servers/apache-2.2.21 PHP: dev-lang/php-5.3.6 PHP: dev-lang/php-5.3.8 [2011-08-02 07:40:05] bruno at chalopin dot fr More informations : The test database : --- CREATE TABLE `test` ( `id` int(11) NOT NULL, `data` text COLLATE latin1_general_ci, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci; INSERT INTO `test`(`id`,`data`) VALUES (1,'foo'),(2,'bar'),(3,'gru'); Software version : -- MySql 5.5.14 x86 Apache 2.2.19 x86 VC9 (from apachelounge) Both have default conf file. [2011-08-01 09:16:40] bruno at chalopin dot fr Description: mod_php crashes on stress test (ab -n 1 -c 20) due to MySqli (the use of the mysql extension don't make it crash) Test script: --- Test MySqli ' . $row['id'] . ' - ' . $row['data'] . ''; } ?> Actual result: -- Type of Analysis Performed Crash Analysis Machine Name CHALOPIN-2008R2 Operating System Unexpected Service Pack 1 Number Of Processors 8 Process ID 3444 Process Image D:\SysperTec\webstack\Apache2\bin\httpd.exe System Up-Time 01:19:31 Process Up-Time 00:00:01 Thread 16 - System ID 3560 Entry point msvcr90!_endthreadex+6f Create time 01/08/2011 10:35:10 Time spent in user mode 0 Days 0:0:0.0 Time spent in kernel mode 0 Days 0:0:0.0 Function Arg 1 Arg 2 Arg 3 Source php5ts!zend_register_internal_class_ex+b77 04ae90a0 6f21e664 016b02f0 php5ts!_efree+2e 016b02f0 0544ed20 6f223957 php5ts!_zval_ptr_dtor+54 0544f01c 0544ef50 0544f2b8 php5ts!zend_hash_destroy+27 0544dbe0 04a94b58 72451201 php5ts!zend_object_std_dtor+2b 0544f2b8 04a94b58 05442e4c php_mysqli!php_clear_mysql+d1 0544f2b8 04a94b58 04a94b58 php5ts!zend_objects_store_del_ref_by_handle_ex+1c1 0001 72465600 04a94b58 php5ts!zend_objects_store_del_ref+1a 0544e8b0 04a94b58 php5ts!_zval_dtor_func+7f 0544e8b0 0544dce0 6f223ad2 php5ts!_zval_ptr_dtor+4b 0544dcec 6f223d83 04a94b58 php5ts!zend_hash_clean+112 04a94b58 0262fa9c 0262fa8c php5ts!zend_hash_reverse_apply+53 04ae7218 6f21deb0 04a94b58 php5ts!shutdown_destructors+77 04a94b58 04a94b58 0262fae0 php5ts!zend_call_destructors+42 04a94b58 04a94b58 php5ts!php_request_shutdown+f0 0004 0156df20 php5apache2_2!zm_info_apache+1801 01d55f30 01d55f30 00cfb3e8 libhttpd!ap_run_handler+25 PHP5TS!ZEND_REGISTER_INTERNAL_CLASS_EX+B77In httpd__PID__3444__Date__08_01_2011__Time_10_35_10AM__368__Second_Chance_Exception_C005.dmp the assembly instruction at php5ts!zend_register_internal_class_ex+b77 in d:\SysperTec\webstack\php\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x3c7edce0 on thread 16 Module Information Image Name: d:\SysperTec\webstack\php\php5ts.dll Symbol Type: PDB Base address: 0x6f19 Time Stamp: Thu Jul 28 14:38:06 2011 Checksum: 0x005b1351 Comments: COM DLL: False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Script Interpreter ISAPIFilter: False File Version:
Bug #60699 [Opn]: mysqli_init() crashes under high concurrency
Edit report at https://bugs.php.net/bug.php?id=60699&edit=1 ID: 60699 User updated by:ninzya at inbox dot lv Reported by:ninzya at inbox dot lv Summary:mysqli_init() crashes under high concurrency Status: Open Type: Bug Package:MySQLi related Operating System: Windows 7 PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: Duplicate of https://bugs.php.net/bug.php?id=55334 Previous Comments: [2012-01-14 09:30:30] ninzya at inbox dot lv Changed status to Open [2012-01-13 12:04:02] ninzya at inbox dot lv Followed instructions on getting backtrace for Windows using Debug diagnostic tool and got no meaningful info out of it. Here's the error: In httpd__PID__4312__Date__01_13_2012__Time_01_52_49PM__761__Second_Chance_Exceptio n_C005.dmp the assembly instruction at php5ts!_efree+85 in C:\Program Files (x86)\PHP\5.4.0RC5\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x3a61f988 on thread 15 And here's information on thread 15: Thread 15 - System ID 5604 Entry point msvcrt!_endthreadex+6f Create time 1/13/2012 1:49:32 PM Time spent in user mode 0 Days 00:00:00.015 Time spent in kernel mode 0 Days 00:00:00.015 Function Source ntdll!NtRaiseException+12 ntdll!KiUserExceptionDispatcher+29 Now the exception info: PHP5TS!_EFREE+85In httpd__PID__4312__Date__01_13_2012__Time_01_52_49PM__761__Second_Chance_Exceptio n_C005.dmp the assembly instruction at php5ts!_efree+85 in C:\Program Files (x86)\PHP\5.4.0RC5\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x3a61f988 on thread 15 Module information: Image Name: C:\Program Files (x86)\PHP\5.4.0RC5\php5ts.dll Symbol Type: PDB Base address: 0x00905a4d Time Stamp: Fri Jan 06 03:02:19 2012 Checksum: 0x Comments: COM DLL: False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Script Interpreter ISAPIFilter: False File Version: 5.4.0RC5 Managed DLL: False Internal Name: PHP Script Interpreter VB DLL: False Legal Copyright: Copyright © 1997-2010 The PHP Group Loaded Image Name: php5ts.dll Legal Trademarks: PHP Mapped Image Name: Original filename: php5ts.dll Module name: php5ts Private Build: Single Threaded: False Product Name: PHP Module Size: 5.91 MBytes Product Version: 5.4.0RC5 Symbol File Name: c:\program files (x86)\php\5.4.0rc5\debug\php5ts.pdb Special Build: & Notice "Symbol File Name"... PDB files were loaded correctly and I have no clue why there's no info on stack trace for thread 15. For comparison, here's stack trace for some other thread, that did not raise any exceptions: Thread 6 - System ID 2748 Entry point msvcrt!_endthreadex+6f Create time 1/13/2012 1:49:32 PM Time spent in user mode 0 Days 00:00:00.015 Time spent in kernel mode 0 Days 00:00:00.015 Function Source php5ts!_zend_mm_alloc_int+d c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\zend\zend_alloc.c @ 1877 + d php5ts!_emalloc+32 c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\zend\zend_alloc.c @ 2425 + 5 php5ts!zendparse+70a c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\zend\zend_language_parser.y @ 987 + 25 php5ts!compile_file+15a c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\zend\zend_language_scanner.l @ 579 + c php5ts!phar_compile_file+87 c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\ext\phar\phar.c @ 3391 + 1d php5ts!zend_execute_scripts+80 c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\zend\zend.c @ 1264 + b php5ts!php_execute_script+1a7 c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\main\main.c @ 2476 + 12 php5apache2_2!php_handler+417 c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\sapi\apache2handler\sapi_apache2.c @ 667 + 23 libhttpd!ap_run_handler+21 .\server\config.c @ 158 + 21 libhttpd!ap_invoke_handler+b0 .\server\config.c @ 376 + 6 libhttpd!ap_internal_redirect+37 .\modules\http\http_request.c @ 557 mod_rewrite!handler_redirect+7b mod_rewrite.c @ 4839 + 31 libhttpd!ap_run_handler+21 .\server\config.c @ 158 + 21 libhttpd!ap_invoke_handler+b0 .\server\config.c @ 376 + 6 libhttpd!ap_process_request+3e .\modules\http\http_request.c @ 286 libhttpd!ap_process_http_connection+4c .\modules\http\http_core.c @ 190 + 6 libhttpd!ap_run_process_connection+21 .\server\connection.c @ 43 + 21 libhttpd!ap_process_connection+33 .\server\connection.c @ 190 + 6 libhttpd!worker_main+9c .\server\mpm\winnt\child.c @ 784 msvcrt!_endthreadex+44 msvcrt!_endthreadex+ce kernel32!BaseThreadInitThunk+e ntdll!__RtlUserThreadStart+70
Bug #60699 [Fbk->Opn]: mysqli_init() crashes under high concurrency
Edit report at https://bugs.php.net/bug.php?id=60699&edit=1 ID: 60699 User updated by:ninzya at inbox dot lv Reported by:ninzya at inbox dot lv Summary:mysqli_init() crashes under high concurrency -Status: Feedback +Status: Open Type: Bug Package:MySQLi related Operating System: Windows 7 PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: Changed status to Open Previous Comments: [2012-01-13 12:04:02] ninzya at inbox dot lv Followed instructions on getting backtrace for Windows using Debug diagnostic tool and got no meaningful info out of it. Here's the error: In httpd__PID__4312__Date__01_13_2012__Time_01_52_49PM__761__Second_Chance_Exceptio n_C005.dmp the assembly instruction at php5ts!_efree+85 in C:\Program Files (x86)\PHP\5.4.0RC5\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x3a61f988 on thread 15 And here's information on thread 15: Thread 15 - System ID 5604 Entry point msvcrt!_endthreadex+6f Create time 1/13/2012 1:49:32 PM Time spent in user mode 0 Days 00:00:00.015 Time spent in kernel mode 0 Days 00:00:00.015 Function Source ntdll!NtRaiseException+12 ntdll!KiUserExceptionDispatcher+29 Now the exception info: PHP5TS!_EFREE+85In httpd__PID__4312__Date__01_13_2012__Time_01_52_49PM__761__Second_Chance_Exceptio n_C005.dmp the assembly instruction at php5ts!_efree+85 in C:\Program Files (x86)\PHP\5.4.0RC5\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x3a61f988 on thread 15 Module information: Image Name: C:\Program Files (x86)\PHP\5.4.0RC5\php5ts.dll Symbol Type: PDB Base address: 0x00905a4d Time Stamp: Fri Jan 06 03:02:19 2012 Checksum: 0x Comments: COM DLL: False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Script Interpreter ISAPIFilter: False File Version: 5.4.0RC5 Managed DLL: False Internal Name: PHP Script Interpreter VB DLL: False Legal Copyright: Copyright © 1997-2010 The PHP Group Loaded Image Name: php5ts.dll Legal Trademarks: PHP Mapped Image Name: Original filename: php5ts.dll Module name: php5ts Private Build: Single Threaded: False Product Name: PHP Module Size: 5.91 MBytes Product Version: 5.4.0RC5 Symbol File Name: c:\program files (x86)\php\5.4.0rc5\debug\php5ts.pdb Special Build: & Notice "Symbol File Name"... PDB files were loaded correctly and I have no clue why there's no info on stack trace for thread 15. For comparison, here's stack trace for some other thread, that did not raise any exceptions: Thread 6 - System ID 2748 Entry point msvcrt!_endthreadex+6f Create time 1/13/2012 1:49:32 PM Time spent in user mode 0 Days 00:00:00.015 Time spent in kernel mode 0 Days 00:00:00.015 Function Source php5ts!_zend_mm_alloc_int+d c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\zend\zend_alloc.c @ 1877 + d php5ts!_emalloc+32 c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\zend\zend_alloc.c @ 2425 + 5 php5ts!zendparse+70a c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\zend\zend_language_parser.y @ 987 + 25 php5ts!compile_file+15a c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\zend\zend_language_scanner.l @ 579 + c php5ts!phar_compile_file+87 c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\ext\phar\phar.c @ 3391 + 1d php5ts!zend_execute_scripts+80 c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\zend\zend.c @ 1264 + b php5ts!php_execute_script+1a7 c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\main\main.c @ 2476 + 12 php5apache2_2!php_handler+417 c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\sapi\apache2handler\sapi_apache2.c @ 667 + 23 libhttpd!ap_run_handler+21 .\server\config.c @ 158 + 21 libhttpd!ap_invoke_handler+b0 .\server\config.c @ 376 + 6 libhttpd!ap_internal_redirect+37 .\modules\http\http_request.c @ 557 mod_rewrite!handler_redirect+7b mod_rewrite.c @ 4839 + 31 libhttpd!ap_run_handler+21 .\server\config.c @ 158 + 21 libhttpd!ap_invoke_handler+b0 .\server\config.c @ 376 + 6 libhttpd!ap_process_request+3e .\modules\http\http_request.c @ 286 libhttpd!ap_process_http_connection+4c .\modules\http\http_core.c @ 190 + 6 libhttpd!ap_run_process_connection+21 .\server\connection.c @ 43 + 21 libhttpd!ap_process_connection+33 .\server\connection.c @ 190 + 6 libhttpd!worker_main+9c .\server\mpm\winnt\child.c @ 784 msvcrt!_endthreadex+44 msvcrt!_endthreadex+ce kernel32!BaseThreadInitThunk+e ntdll!__RtlUserThreadStart+70 ntdll!_RtlUserThreadStart+1b Any clues? Maybe you can take any apache, take php 5.4.0RC5 ts, configure it as module, enable mysqli,
Bug #60699 [Com]: mysqli_init() crashes under high concurrency
Edit report at https://bugs.php.net/bug.php?id=60699&edit=1 ID: 60699 Comment by: ninzya at inbox dot lv Reported by:ninzya at inbox dot lv Summary:mysqli_init() crashes under high concurrency Status: Feedback Type: Bug Package:MySQLi related Operating System: Windows 7 PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: Followed instructions on getting backtrace for Windows using Debug diagnostic tool and got no meaningful info out of it. Here's the error: In httpd__PID__4312__Date__01_13_2012__Time_01_52_49PM__761__Second_Chance_Exceptio n_C005.dmp the assembly instruction at php5ts!_efree+85 in C:\Program Files (x86)\PHP\5.4.0RC5\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x3a61f988 on thread 15 And here's information on thread 15: Thread 15 - System ID 5604 Entry point msvcrt!_endthreadex+6f Create time 1/13/2012 1:49:32 PM Time spent in user mode 0 Days 00:00:00.015 Time spent in kernel mode 0 Days 00:00:00.015 Function Source ntdll!NtRaiseException+12 ntdll!KiUserExceptionDispatcher+29 Now the exception info: PHP5TS!_EFREE+85In httpd__PID__4312__Date__01_13_2012__Time_01_52_49PM__761__Second_Chance_Exceptio n_C005.dmp the assembly instruction at php5ts!_efree+85 in C:\Program Files (x86)\PHP\5.4.0RC5\php5ts.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x3a61f988 on thread 15 Module information: Image Name: C:\Program Files (x86)\PHP\5.4.0RC5\php5ts.dll Symbol Type: PDB Base address: 0x00905a4d Time Stamp: Fri Jan 06 03:02:19 2012 Checksum: 0x Comments: COM DLL: False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Script Interpreter ISAPIFilter: False File Version: 5.4.0RC5 Managed DLL: False Internal Name: PHP Script Interpreter VB DLL: False Legal Copyright: Copyright © 1997-2010 The PHP Group Loaded Image Name: php5ts.dll Legal Trademarks: PHP Mapped Image Name: Original filename: php5ts.dll Module name: php5ts Private Build: Single Threaded: False Product Name: PHP Module Size: 5.91 MBytes Product Version: 5.4.0RC5 Symbol File Name: c:\program files (x86)\php\5.4.0rc5\debug\php5ts.pdb Special Build: & Notice "Symbol File Name"... PDB files were loaded correctly and I have no clue why there's no info on stack trace for thread 15. For comparison, here's stack trace for some other thread, that did not raise any exceptions: Thread 6 - System ID 2748 Entry point msvcrt!_endthreadex+6f Create time 1/13/2012 1:49:32 PM Time spent in user mode 0 Days 00:00:00.015 Time spent in kernel mode 0 Days 00:00:00.015 Function Source php5ts!_zend_mm_alloc_int+d c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\zend\zend_alloc.c @ 1877 + d php5ts!_emalloc+32 c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\zend\zend_alloc.c @ 2425 + 5 php5ts!zendparse+70a c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\zend\zend_language_parser.y @ 987 + 25 php5ts!compile_file+15a c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\zend\zend_language_scanner.l @ 579 + c php5ts!phar_compile_file+87 c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\ext\phar\phar.c @ 3391 + 1d php5ts!zend_execute_scripts+80 c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\zend\zend.c @ 1264 + b php5ts!php_execute_script+1a7 c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\main\main.c @ 2476 + 12 php5apache2_2!php_handler+417 c:\php-sdk\php54dev-ts\vc9\x86\php- 5.4.0rc5\sapi\apache2handler\sapi_apache2.c @ 667 + 23 libhttpd!ap_run_handler+21 .\server\config.c @ 158 + 21 libhttpd!ap_invoke_handler+b0 .\server\config.c @ 376 + 6 libhttpd!ap_internal_redirect+37 .\modules\http\http_request.c @ 557 mod_rewrite!handler_redirect+7b mod_rewrite.c @ 4839 + 31 libhttpd!ap_run_handler+21 .\server\config.c @ 158 + 21 libhttpd!ap_invoke_handler+b0 .\server\config.c @ 376 + 6 libhttpd!ap_process_request+3e .\modules\http\http_request.c @ 286 libhttpd!ap_process_http_connection+4c .\modules\http\http_core.c @ 190 + 6 libhttpd!ap_run_process_connection+21 .\server\connection.c @ 43 + 21 libhttpd!ap_process_connection+33 .\server\connection.c @ 190 + 6 libhttpd!worker_main+9c .\server\mpm\winnt\child.c @ 784 msvcrt!_endthreadex+44 msvcrt!_endthreadex+ce kernel32!BaseThreadInitThunk+e ntdll!__RtlUserThreadStart+70 ntdll!_RtlUserThreadStart+1b Any clues? Maybe you can take any apache, take php 5.4.0RC5 ts, configure it as module, enable mysqli, create php file with "", run a stress test, get the crash and find out what it causes? Previous Comments:
Bug #60699 [Opn]: mysqli_init() crashes under high concurrency
Edit report at https://bugs.php.net/bug.php?id=60699&edit=1 ID: 60699 User updated by:ninzya at inbox dot lv Reported by:ninzya at inbox dot lv Summary:mysqli_init() crashes under high concurrency Status: Open Type: Bug -Package:MySQLi related +Package:Reproducible crash Operating System: Windows 7 PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: Changed from "MySQLi" to "Reproducible crash" so that more attention is paid to this issue. Previous Comments: ---- [2012-01-10 11:45:44] ninzya at inbox dot lv Description: Calling purely mysqli_init() crashes PHP under high concurrency. Using VC9 x86 Thread Safe (2012-Jan-06 02:06:02) build of PHP 5.4.0RC5. Using Apache HTTPd 2.2.21.0. Using ab (apache benchmark) tool to simulate high loads: "ab -c 30 -n 2000 http://localhost:8080/index.php";. PHP installed as module. Test script: --- mysqli_init(); Expected result: No crash Actual result: -- Crash -- Edit this bug report at https://bugs.php.net/bug.php?id=60699&edit=1
Bug #60709 [Com]: Any php file of size 8192 bytes crashes Apache and PHP
Edit report at https://bugs.php.net/bug.php?id=60709&edit=1
ID: 60709
Comment by: ninzya at inbox dot lv
Reported by:bugzilla33 at gmail dot com
Summary:Any php file of size 8192 bytes crashes Apache and
PHP
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Win All
PHP Version:5.4.0RC5
Block user comment: N
Private report: N
New Comment:
Duplicate: https://bugs.php.net/bug.php?id=48034
Previous Comments:
[2012-01-11 07:54:11] bugzilla33 at gmail dot com
Apache error.log:
[Wed Jan 11 08:39:51 2012] [notice] Parent: child process exited with status
255 -- Restarting.
[2012-01-11 07:51:23] bugzilla33 at gmail dot com
Description:
1. use Test script to generate crash.php, size 8192 bytes
2. now let crash php engine crash.php
3. Any php file of size 8192 bytes crashes Apache and PHP!
4. Tested with Apache 2.2.21 V9 apache longue, PHP 5.4.0 RC5 or RC6 dev on
three other machines, Win 7 x86 or Win 7 x64.
Test script:
---
testcase php file generator:
';
file_put_contents('crash.php',$out);
print('1. testcase file generated: crash.php, size '.strlen($out).'
bytes');
print('2. now let crash php engine crash.php');
print('3. Any php file of size 8192 bytes crashes Apache
and PHP!');
print('4. Tested with Apache 2.2.21 V9 apache longue, PHP 5.4.0 RC5 or RC6 dev
on three other machines, Win 7 x86 or Win 7 x64.');
?>
Expected result:
NO crash
Actual result:
--
CRASH
--
Edit this bug report at https://bugs.php.net/bug.php?id=60709&edit=1
[PHP-BUG] Bug #60699 [NEW]: mysqli_init() crashes under high concurrency
From: Operating system: Windows 7 PHP version: 5.4.0RC5 Package: MySQLi related Bug Type: Bug Bug description:mysqli_init() crashes under high concurrency Description: Calling purely mysqli_init() crashes PHP under high concurrency. Using VC9 x86 Thread Safe (2012-Jan-06 02:06:02) build of PHP 5.4.0RC5. Using Apache HTTPd 2.2.21.0. Using ab (apache benchmark) tool to simulate high loads: "ab -c 30 -n 2000 http://localhost:8080/index.php";. PHP installed as module. Test script: --- mysqli_init(); Expected result: No crash Actual result: -- Crash -- Edit bug report at https://bugs.php.net/bug.php?id=60699&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60699&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60699&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60699&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60699&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60699&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60699&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60699&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60699&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60699&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60699&r=support Expected behavior: https://bugs.php.net/fix.php?id=60699&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60699&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60699&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60699&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60699&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60699&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60699&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60699&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60699&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60699&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60699&r=mysqlcfg
Req #60372 [Com]: Context call feature
Edit report at https://bugs.php.net/bug.php?id=60372&edit=1
ID: 60372
Comment by: ninzya at inbox dot lv
Reported by:ninzya at inbox dot lv
Summary:Context call feature
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: Any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
So basically if the feature gets support from the community, I could then
prepare
an RFC describing the proposal in detail.
Previous Comments:
[2011-11-24 14:59:23] ninzya at inbox dot lv
An example on how the proposed syntactic sugar would improve code readability.
Before:
if( $user->hasPermission( $user::PERM_EDIT, $user->getProfile())) {
// has access to edit own profile
}
After:
if( $user->hasPermission( :PERM_EDIT, :getProfile())) {
// has access to edit own profile
}
Before:
$config->setSettings([
$config::SOME_TTL =>10,
$config::SOME_PATH =>"/var/www/...",
$config::SOMETHING_OTHER =>0xFF
]);
After:
$config->setSettings([
:SOME_TTL =>10,
:SOME_PATH =>"/var/www/...",
:SOMETHING_OTHER =>0xFF
]);
Note that use of ":" inside array definition contextually resolves arguments as
well. In the last example the ":SOME_TTL" syntax refers to the "SOME_TTL" class
constant of $config object (i.e. same as "$config::SOME_TTL")
------------
[2011-11-24 14:50:08] ninzya at inbox dot lv
Description:
I'd like to propose an extension to PHP syntax, that would allow programmer to
avoid code duplication in some cases and, therefore, would make PHP code more
readable.
My idea is to extend dynamic call operator ("->method()") add a "context"
syntax
to it's arguments. The syntax would mean that the argument's value is located
in
context of a specific object - the argument is either a property or method. The
syntax could be as follows:
$obj->area( :$x, :$y);
Note the ":" (colon) character in front of argument. The colon means that the
argument for the call is a property of object that the invoked method belongs
to. In this case both arguments are actually "$obj->x" and "$obj->y" values.
Syntax for method calls is as follows:
$obj->area( :x(), :y());
In this case both arguments are "$obj->x()" and "$obj->x()".
The following more complex example:
$obj->area( :mt_rand( 1, :$x), $y);
Here mt_rand() is a method of $obj (i.e. "$obj->mt_rand()", because colon
character is preceding the function name)) and since ":mt_rand()" is resolved
to
"$obj->mt_rand()", it's ":$x" argument is resolved to "$obj->x" as well.
However, a call like this:
mt_rand( :$x);
should yield a runtime error because this is not a dynamic call and the
argument
can not be resolved.
Test script:
---
class Test {
public $x =5;
public function y() {
return 10;
}
public function area( $x, $y, $name) {
echo $name .': ' .$x .' x ' .$y;
}
public function makeName( $name) {
return '#' .$name;
}
}
$test =new Test;
$test->area( :$x, :y(), :makeName( 'test'));
Expected result:
#test: 5 x 10
Actual result:
--
Not implemented yet.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60372&edit=1
Req #60372 [Com]: Context call feature
Edit report at https://bugs.php.net/bug.php?id=60372&edit=1
ID: 60372
Comment by: ninzya at inbox dot lv
Reported by:ninzya at inbox dot lv
Summary:Context call feature
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: Any
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
An example on how the proposed syntactic sugar would improve code readability.
Before:
if( $user->hasPermission( $user::PERM_EDIT, $user->getProfile())) {
// has access to edit own profile
}
After:
if( $user->hasPermission( :PERM_EDIT, :getProfile())) {
// has access to edit own profile
}
Before:
$config->setSettings([
$config::SOME_TTL =>10,
$config::SOME_PATH =>"/var/www/...",
$config::SOMETHING_OTHER =>0xFF
]);
After:
$config->setSettings([
:SOME_TTL =>10,
:SOME_PATH =>"/var/www/...",
:SOMETHING_OTHER =>0xFF
]);
Note that use of ":" inside array definition contextually resolves arguments as
well. In the last example the ":SOME_TTL" syntax refers to the "SOME_TTL" class
constant of $config object (i.e. same as "$config::SOME_TTL")
Previous Comments:
------------
[2011-11-24 14:50:08] ninzya at inbox dot lv
Description:
I'd like to propose an extension to PHP syntax, that would allow programmer to
avoid code duplication in some cases and, therefore, would make PHP code more
readable.
My idea is to extend dynamic call operator ("->method()") add a "context"
syntax
to it's arguments. The syntax would mean that the argument's value is located
in
context of a specific object - the argument is either a property or method. The
syntax could be as follows:
$obj->area( :$x, :$y);
Note the ":" (colon) character in front of argument. The colon means that the
argument for the call is a property of object that the invoked method belongs
to. In this case both arguments are actually "$obj->x" and "$obj->y" values.
Syntax for method calls is as follows:
$obj->area( :x(), :y());
In this case both arguments are "$obj->x()" and "$obj->x()".
The following more complex example:
$obj->area( :mt_rand( 1, :$x), $y);
Here mt_rand() is a method of $obj (i.e. "$obj->mt_rand()", because colon
character is preceding the function name)) and since ":mt_rand()" is resolved
to
"$obj->mt_rand()", it's ":$x" argument is resolved to "$obj->x" as well.
However, a call like this:
mt_rand( :$x);
should yield a runtime error because this is not a dynamic call and the
argument
can not be resolved.
Test script:
---
class Test {
public $x =5;
public function y() {
return 10;
}
public function area( $x, $y, $name) {
echo $name .': ' .$x .' x ' .$y;
}
public function makeName( $name) {
return '#' .$name;
}
}
$test =new Test;
$test->area( :$x, :y(), :makeName( 'test'));
Expected result:
#test: 5 x 10
Actual result:
--
Not implemented yet.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60372&edit=1
[PHP-BUG] Req #60372 [NEW]: Context call feature
From:
Operating system: Any
PHP version: Irrelevant
Package: Scripting Engine problem
Bug Type: Feature/Change Request
Bug description:Context call feature
Description:
I'd like to propose an extension to PHP syntax, that would allow programmer
to
avoid code duplication in some cases and, therefore, would make PHP code
more
readable.
My idea is to extend dynamic call operator ("->method()") add a "context"
syntax
to it's arguments. The syntax would mean that the argument's value is
located in
context of a specific object - the argument is either a property or method.
The
syntax could be as follows:
$obj->area( :$x, :$y);
Note the ":" (colon) character in front of argument. The colon means that
the
argument for the call is a property of object that the invoked method
belongs
to. In this case both arguments are actually "$obj->x" and "$obj->y"
values.
Syntax for method calls is as follows:
$obj->area( :x(), :y());
In this case both arguments are "$obj->x()" and "$obj->x()".
The following more complex example:
$obj->area( :mt_rand( 1, :$x), $y);
Here mt_rand() is a method of $obj (i.e. "$obj->mt_rand()", because colon
character is preceding the function name)) and since ":mt_rand()" is
resolved to
"$obj->mt_rand()", it's ":$x" argument is resolved to "$obj->x" as well.
However, a call like this:
mt_rand( :$x);
should yield a runtime error because this is not a dynamic call and the
argument
can not be resolved.
Test script:
---
class Test {
public $x =5;
public function y() {
return 10;
}
public function area( $x, $y, $name) {
echo $name .': ' .$x .' x ' .$y;
}
public function makeName( $name) {
return '#' .$name;
}
}
$test =new Test;
$test->area( :$x, :y(), :makeName( 'test'));
Expected result:
#test: 5 x 10
Actual result:
--
Not implemented yet.
--
Edit bug report at https://bugs.php.net/bug.php?id=60372&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60372&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60372&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60372&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60372&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60372&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60372&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60372&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60372&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60372&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60372&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60372&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60372&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60372&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60372&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60372&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60372&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60372&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60372&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60372&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60372&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60372&r=mysqlcfg
[PHP-BUG] Bug #60145 [NEW]: interface + use trait yields error for the abstract class?
From:
Operating system: Any
PHP version: 5.4.0beta2
Package: Scripting Engine problem
Bug Type: Bug
Bug description:interface + use trait yields error for the abstract class?
Description:
The code in the test script contains one trait and an interface, that uses
this
trait ("use TestTrait"). What I was trying to do here is to see how PHP
behaves if
i include "use" statement inside interface definition.
Suprisingly, test script produces very interesting result - I get a fatal
error
with the following text: "Class TestInterface contains 1 abstract method
and must
therefore be declared abstract or implement the remaining methods
(TestInterface::b)". It looks like PHP's compiler messes up when I mix
interfaces
together with "use" statement and somehow treats "TestInterface" as an
abstract
class.
I didn't go deeper to look into the problem as it's pretty clear that
something is
wrong here. In my opinion, PHP should not allow usage of "use" statment
inside
interface defitions.
Test script:
---
trait TestTrait {
}
interface TestInterface {
use TestTrait;
public function b();
}
Expected result:
PHP Fatal error: use of "use" statement in interfaces is not allowed.
Actual result:
--
PHP Fatal error: Class TestInterface contains 1 abstract method and must
therefore
be declared abstract or implement the remaining methods (TestInterface::b).
--
Edit bug report at https://bugs.php.net/bug.php?id=60145&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60145&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60145&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60145&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60145&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60145&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60145&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60145&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60145&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60145&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60145&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60145&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60145&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60145&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60145&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60145&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60145&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60145&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60145&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60145&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60145&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60145&r=mysqlcfg
Req #41132 [Com]: No way to get origional object from within __clone()
Edit report at https://bugs.php.net/bug.php?id=41132&edit=1
ID: 41132
Comment by: ninzya at inbox dot lv
Reported by:wb at pro-net dot co dot uk
Summary:No way to get origional object from within __clone()
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
PHP Version:5.2.1
Block user comment: N
Private report: N
New Comment:
++ for this.
Remark: I think it's still better to pass $originalThis to __clone() as a
regular
object with no lifted access restrictions to private/protected members (i.e.
just
pass it as regular fcall argument).
Previous Comments:
[2007-04-18 14:23:15] wb at pro-net dot co dot uk
Description:
When you clone an object the __clone method does not have a way to get a
reference to the original object.
It would be advantageous to have a way to get the original object from within
the __clone method.
One reason for this is that you can have an object that has child objects that
in-turn reference back to the parent object and on clone you want to clone
these child objects but would need to remove the original reference and replace
it with the new parent reference.
This feature could be implemented by simply passing the original object as an
argument to the __clone() method.
Reproduce code:
---
class Parent
{
protected $children = array();
public function __clone($originalThis)
{
$clonedChildren = array();
foreach($this->children as $child)
{
$childClone = clone $child;
$childClone->attach($this);
// we have no way of getting the original
// object do we cant do the following...
$childClone->detach($originalThis);
}
$this->children = $clonedChildren;
}
}
Expected result:
N/A
Actual result:
--
N/A
--
Edit this bug report at https://bugs.php.net/bug.php?id=41132&edit=1
Bug #54860 [Fbk->Csd]: PHP crash when using closures + extract(EXTR_REFS)
Edit report at https://bugs.php.net/bug.php?id=54860&edit=1
ID: 54860
User updated by:ninzya at inbox dot lv
Reported by:ninzya at inbox dot lv
Summary:PHP crash when using closures + extract(EXTR_REFS)
-Status: Feedback
+Status: Closed
Type: Bug
Package:Reproducible crash
Operating System: Windows 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Fixed in 5.3.7.
Previous Comments:
[2011-05-23 09:20:37] ninzya at inbox dot lv
Works fine with 5.3 r311342.
[2011-05-21 20:07:02] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I can't reproduce it.
[2011-05-19 14:02:47] ninzya at inbox dot lv
Sorry, extract() has nothing to do with this issue.
I was able to come up with more compact test script with no use of extract():
$x =new stdClass;
$y =&$x;
for( $i =0; $i < 2; ++$i) {
$closure =function() use( $y) {
$y->someProperty ='someValue';// crashes on second iteration
};
$closure();
}
This code does not crash PHP 5.3.5. It seems that references + closures became
broken in 5.3.6.
----
[2011-05-19 12:03:20] ninzya at inbox dot lv
Description:
See test script.
PHP 5.3.5 is not affected.
Test script:
---
// Initially $Object is not a reference and contains a "pointer"
// to an stdClass object.
$Object =new stdClass; /**/ echo 'New: '; debug_zval_dump( $Object);
// $Object becomes a reference to the "pointer" to an stdClass.
$Object =&$Object; /**/ echo 'Self-reference: '; debug_zval_dump( $Object);
// Now we import $Object into closure by value. In theory,
// $Object, that is inside closure, should not be a reference, but rather
// should be a variable, that "points" to stdClass (i.e. an equivalent of
// $ImportedObject in expression "$ImportedObject =$Object").
$closure =function() use( $Object) {
// Once you manipulate $Object, you get PHP crashed.
$Object->x =10;
//debug_zval_dump( $Object);
};
// By calling extract() we make $Object to reference a new stdClass instance.
extract( array( 'Object' =>new stdClass), EXTR_REFS);
echo 'After extract: '; debug_zval_dump( $Object);
// now we execute closure and get PHP crashed
$closure();
Expected result:
PHP should not crash.
Actual result:
--
PHP crashes.
If you put die() right before $closure(), then you get following output:
line 1: New: object(stdClass)#1 (0) refcount(2){
line 2: }
line 3: Self-reference: object(stdClass)#1 (0) refcount(1){
line 4: }
line 5: After extract: object(stdClass)#3 (0) refcount(2){
line 6: }
Some questions regarding that output:
1) why there is refcount(2) in the first line? Isn't the object referenced only
once and by $Object variable? I would expect to see refcount(1) here. As you
can
see on line 3, refcount seems to become correct after self-referencing is being
made.
2) why line 5 says object(stdClass)#3, while there were only two (and not 3)
stdClass objects allocated? If you comment out closure's definition, then you
get object(stdClass)#2 (an expected output). Does closure clone $Object when
you
say "use($Object)"? Shouldn't the stdClass object be simply "referenced" by the
"use($Object)"?
--
Edit this bug report at https://bugs.php.net/bug.php?id=54860&edit=1
Req #32100 [Com]: Request 'finally' support for exceptions
Edit report at https://bugs.php.net/bug.php?id=32100&edit=1
ID: 32100
Comment by: ninzya at inbox dot lv
Reported by:ceefour at gauldong dot net
Summary:Request 'finally' support for exceptions
Status: Closed
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: *
PHP Version:5.*
Block user comment: N
Private report: N
New Comment:
++finally
Previous Comments:
[2011-07-22 07:53:27] dsberliner at gmail dot com
++ for finally in exception handling. Please reconsider.
[2011-05-30 02:53:58] bat at flurf dot net
Here's an idea! Find all the people who think "finally" isn't needed in PHP.
Invite them to go back to programming Visual Basic, because they're ignorant.
The rest can work on implementing it. Easy!
[2011-05-05 11:52:26] ealexs at gmail dot com
PHP++ for finally in PHP ;)
my code:
disableSIPTrunk (10 lines of code)
try
{
// do some stuff
}
finally
{
enableSIPTrunk (10 lines of code)
}
// saves duplicate code and it's very elegant !
[2011-04-05 21:16:06] adam dot pippin at ohmedia dot ca
---
Disable user permission checking
try
{
Call a half a dozen methods
}
finally
{
Re-enable user permission checking
}
---
The ten year old discussion I found on the issue
(http://marc.info/?l=php-internals&m=96774165717219&w=3) doesn't seem terribly
applicable to my case. Specifically, it suggests:
---
try {
... modify contents ...
} catch {
... any error recovery code here ...
}
... cleanup code ...
---
Except my code doesn't 'recover' from errors. It runs back up the call stack
and reports the error to the user. I have absolutely zero use for a catch here.
My workaround (which, unlike a basic rethrow preserves the line/file):
---
Disable permission checking
try
{
Run methods
}
catch (Exception $e)
{
Enable permission checking
throw new Exception($e->getMessage(), $e->getCode(), $e);
}
Enable permission checking
---
The workaround simply requires a few extra lines of code and a bunch of
duplicated code. But hey, finally isn't required, so it's all good.
[2011-03-20 10:44:01] php at techdp dot co dot uk
+++ for finally in PHP. It is one of the most elegant and expressive keywords
in modern programming, allowing precise capture of error handling semantics,
and easy authorship of bug-free code!
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=32100
--
Edit this bug report at https://bugs.php.net/bug.php?id=32100&edit=1
Bug #54860 [Com]: PHP crash when using closures + extract(EXTR_REFS)
Edit report at http://bugs.php.net/bug.php?id=54860&edit=1
ID: 54860
Comment by: ninzya at inbox dot lv
Reported by:ninzya at inbox dot lv
Summary:PHP crash when using closures + extract(EXTR_REFS)
Status: Feedback
Type: Bug
Package:Reproducible crash
Operating System: Windows 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Works fine with 5.3 r311342.
Previous Comments:
[2011-05-21 20:07:02] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
I can't reproduce it.
[2011-05-19 14:02:47] ninzya at inbox dot lv
Sorry, extract() has nothing to do with this issue.
I was able to come up with more compact test script with no use of
extract():
$x =new stdClass;
$y =&$x;
for( $i =0; $i < 2; ++$i) {
$closure =function() use( $y) {
$y->someProperty ='someValue';// crashes on second iteration
};
$closure();
}
This code does not crash PHP 5.3.5. It seems that references + closures
became
broken in 5.3.6.
----
[2011-05-19 12:03:20] ninzya at inbox dot lv
Description:
See test script.
PHP 5.3.5 is not affected.
Test script:
---
// Initially $Object is not a reference and contains a "pointer"
// to an stdClass object.
$Object =new stdClass; /**/ echo 'New: '; debug_zval_dump( $Object);
// $Object becomes a reference to the "pointer" to an stdClass.
$Object =&$Object; /**/ echo 'Self-reference: '; debug_zval_dump(
$Object);
// Now we import $Object into closure by value. In theory,
// $Object, that is inside closure, should not be a reference, but
rather
// should be a variable, that "points" to stdClass (i.e. an equivalent
of
// $ImportedObject in expression "$ImportedObject =$Object").
$closure =function() use( $Object) {
// Once you manipulate $Object, you get PHP crashed.
$Object->x =10;
//debug_zval_dump( $Object);
};
// By calling extract() we make $Object to reference a new stdClass
instance.
extract( array( 'Object' =>new stdClass), EXTR_REFS);
echo 'After extract: '; debug_zval_dump( $Object);
// now we execute closure and get PHP crashed
$closure();
Expected result:
PHP should not crash.
Actual result:
--
PHP crashes.
If you put die() right before $closure(), then you get following
output:
line 1: New: object(stdClass)#1 (0) refcount(2){
line 2: }
line 3: Self-reference: object(stdClass)#1 (0) refcount(1){
line 4: }
line 5: After extract: object(stdClass)#3 (0) refcount(2){
line 6: }
Some questions regarding that output:
1) why there is refcount(2) in the first line? Isn't the object
referenced only
once and by $Object variable? I would expect to see refcount(1) here. As
you can
see on line 3, refcount seems to become correct after self-referencing
is being
made.
2) why line 5 says object(stdClass)#3, while there were only two (and
not 3)
stdClass objects allocated? If you comment out closure's definition,
then you
get object(stdClass)#2 (an expected output). Does closure clone $Object
when you
say "use($Object)"? Shouldn't the stdClass object be simply "referenced"
by the
"use($Object)"?
--
Edit this bug report at http://bugs.php.net/bug.php?id=54860&edit=1
Bug #54860 [Com]: PHP crash when using closures + extract(EXTR_REFS)
Edit report at http://bugs.php.net/bug.php?id=54860&edit=1
ID: 54860
Comment by: ninzya at inbox dot lv
Reported by:ninzya at inbox dot lv
Summary:PHP crash when using closures + extract(EXTR_REFS)
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Windows 7
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Sorry, extract() has nothing to do with this issue.
I was able to come up with more compact test script with no use of
extract():
$x =new stdClass;
$y =&$x;
for( $i =0; $i < 2; ++$i) {
$closure =function() use( $y) {
$y->someProperty ='someValue';// crashes on second iteration
};
$closure();
}
This code does not crash PHP 5.3.5. It seems that references + closures
became
broken in 5.3.6.
Previous Comments:
----
[2011-05-19 12:03:20] ninzya at inbox dot lv
Description:
See test script.
PHP 5.3.5 is not affected.
Test script:
---
// Initially $Object is not a reference and contains a "pointer"
// to an stdClass object.
$Object =new stdClass; /**/ echo 'New: '; debug_zval_dump( $Object);
// $Object becomes a reference to the "pointer" to an stdClass.
$Object =&$Object; /**/ echo 'Self-reference: '; debug_zval_dump(
$Object);
// Now we import $Object into closure by value. In theory,
// $Object, that is inside closure, should not be a reference, but
rather
// should be a variable, that "points" to stdClass (i.e. an equivalent
of
// $ImportedObject in expression "$ImportedObject =$Object").
$closure =function() use( $Object) {
// Once you manipulate $Object, you get PHP crashed.
$Object->x =10;
//debug_zval_dump( $Object);
};
// By calling extract() we make $Object to reference a new stdClass
instance.
extract( array( 'Object' =>new stdClass), EXTR_REFS);
echo 'After extract: '; debug_zval_dump( $Object);
// now we execute closure and get PHP crashed
$closure();
Expected result:
PHP should not crash.
Actual result:
--
PHP crashes.
If you put die() right before $closure(), then you get following
output:
line 1: New: object(stdClass)#1 (0) refcount(2){
line 2: }
line 3: Self-reference: object(stdClass)#1 (0) refcount(1){
line 4: }
line 5: After extract: object(stdClass)#3 (0) refcount(2){
line 6: }
Some questions regarding that output:
1) why there is refcount(2) in the first line? Isn't the object
referenced only
once and by $Object variable? I would expect to see refcount(1) here. As
you can
see on line 3, refcount seems to become correct after self-referencing
is being
made.
2) why line 5 says object(stdClass)#3, while there were only two (and
not 3)
stdClass objects allocated? If you comment out closure's definition,
then you
get object(stdClass)#2 (an expected output). Does closure clone $Object
when you
say "use($Object)"? Shouldn't the stdClass object be simply "referenced"
by the
"use($Object)"?
--
Edit this bug report at http://bugs.php.net/bug.php?id=54860&edit=1
[PHP-BUG] Bug #54860 [NEW]: PHP crash when using closures + extract(EXTR_REFS)
From:
Operating system: Windows 7
PHP version: 5.3.6
Package: Reproducible crash
Bug Type: Bug
Bug description:PHP crash when using closures + extract(EXTR_REFS)
Description:
See test script.
PHP 5.3.5 is not affected.
Test script:
---
// Initially $Object is not a reference and contains a "pointer"
// to an stdClass object.
$Object =new stdClass; /**/ echo 'New: '; debug_zval_dump( $Object);
// $Object becomes a reference to the "pointer" to an stdClass.
$Object =&$Object; /**/ echo 'Self-reference: '; debug_zval_dump(
$Object);
// Now we import $Object into closure by value. In theory,
// $Object, that is inside closure, should not be a reference, but rather
// should be a variable, that "points" to stdClass (i.e. an equivalent of
// $ImportedObject in expression "$ImportedObject =$Object").
$closure =function() use( $Object) {
// Once you manipulate $Object, you get PHP crashed.
$Object->x =10;
//debug_zval_dump( $Object);
};
// By calling extract() we make $Object to reference a new stdClass
instance.
extract( array( 'Object' =>new stdClass), EXTR_REFS);
echo 'After extract: '; debug_zval_dump( $Object);
// now we execute closure and get PHP crashed
$closure();
Expected result:
PHP should not crash.
Actual result:
--
PHP crashes.
If you put die() right before $closure(), then you get following output:
line 1: New: object(stdClass)#1 (0) refcount(2){
line 2: }
line 3: Self-reference: object(stdClass)#1 (0) refcount(1){
line 4: }
line 5: After extract: object(stdClass)#3 (0) refcount(2){
line 6: }
Some questions regarding that output:
1) why there is refcount(2) in the first line? Isn't the object referenced
only
once and by $Object variable? I would expect to see refcount(1) here. As
you can
see on line 3, refcount seems to become correct after self-referencing is
being
made.
2) why line 5 says object(stdClass)#3, while there were only two (and not
3)
stdClass objects allocated? If you comment out closure's definition, then
you
get object(stdClass)#2 (an expected output). Does closure clone $Object
when you
say "use($Object)"? Shouldn't the stdClass object be simply "referenced" by
the
"use($Object)"?
--
Edit bug report at http://bugs.php.net/bug.php?id=54860&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54860&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54860&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54860&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54860&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54860&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54860&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54860&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54860&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54860&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54860&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54860&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54860&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54860&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54860&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54860&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54860&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54860&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54860&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54860&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54860&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54860&r=mysqlcfg
Req #46182 [Com]: mysql_connection_reused( $link) function
Edit report at http://bugs.php.net/bug.php?id=46182&edit=1
ID: 46182
Comment by: ninzya at inbox dot lv
Reported by:ninzya at inbox dot lv
Summary:mysql_connection_reused( $link) function
Status: Wont fix
Type: Feature/Change Request
Package:MySQL related
Operating System: Any
PHP Version:5.3.0alpha2
Assigned To:mysql
Block user comment: N
Private report: N
New Comment:
Thank you for the info.
Previous Comments:
[2011-01-06 16:06:17] u...@php.net
Reusing of not properly cleaned up persistent connections is an evil
aside effect that's confusing many beginners. mysqli gives you the
choice if you want connections that are put into the persistent pool
always to be cleaned up and appear as if they had been just opened
(default) or to return them in the state the previous user as left them
when the connection was put into the persistent pool - with all the
dirty side effects: authentication changes are not detected,
transactions can be open, variables are not cleared up, temporary tables
are there etc. . mysqli makes a clear cut and calls mysql_change_user()
(C API = mysqli_change_user() PHP mysqli) before reusing a connection.
Its always cleaned up. That's a safe choice for 90% of the users. Only
some power users who know what they do should require the ext/mysql
behaviour. And those power users don't need an extra API call because
you can hack something using SQL connection variables:
SELECT @connection_init
if @connection_init = 0
INIT stuff
SET @connection_init = 1
[2008-09-26 13:24:06] ninzya at inbox dot lv
Description:
It would be great if we had mysql_connection_reused( $link) function,
which returned boolean value if just established connection was
reused or no.
Reproduce code:
---
$link =mysql_pconnect( $host .':' .$port, $user, $pass);
if( !mysql_connection_reused( $link)) {
mysql_query( 'SET NAMES utf8;');
mysql_query( 'USE mydb;');
} else {
// connection was reused, don't do any initialization queries,
// because they were already made by another request
}
Expected result:
This would allow to optimize database load on heavy loaded servers.
Actual result:
--
Not implemented
--
Edit this bug report at http://bugs.php.net/bug.php?id=46182&edit=1
Bug #51715 [Opn]: Lambda's definition breaks references when using use() clause.
Edit report at http://bugs.php.net/bug.php?id=51715&edit=1
ID: 51715
User updated by: ninzya at inbox dot lv
Reported by: ninzya at inbox dot lv
Summary: Lambda's definition breaks references when using use()
clause.
Status: Open
Type: Bug
Package: Scripting Engine problem
Operating System: Any
PHP Version: 5.3.2
New Comment:
Sorry, have forgotten that i have already filed that bug report a while
ago (http://bugs.php.net/bug.php?id=50230). I use closures a lot and
would like to get this bug fixed as soon as possible.
Previous Comments:
[2010-05-01 13:30:19] ninzya at inbox dot lv
If you change lambda definition from
function() use( $y){};
to
function() use( &$y){};
then script outputs expected result:
[...]# cat test.php
[...]# php -v
PHP 5.3.2 (cli) (built: Mar 4 2010 22:12:20)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
[...]# php test.php
int(10)
[2010-05-01 13:27:26] ninzya at inbox dot lv
Description:
See test script.
Test script:
---
[...]# cat test.php
[...]# php -v
PHP 5.3.2 (cli) (built: Mar 4 2010 22:12:20)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
[...]# php test.php
NULL
Expected result:
int(10)
Actual result:
--
NULL
--
Edit this bug report at http://bugs.php.net/bug.php?id=51715&edit=1
Bug #51715 [Opn]: Lambda's definition breaks references when using use() clause.
Edit report at http://bugs.php.net/bug.php?id=51715&edit=1
ID: 51715
User updated by: ninzya at inbox dot lv
Reported by: ninzya at inbox dot lv
Summary: Lambda's definition breaks references when using use()
clause.
Status: Open
Type: Bug
Package: Scripting Engine problem
Operating System: Any
PHP Version: 5.3.2
New Comment:
If you change lambda definition from
function() use( $y){};
to
function() use( &$y){};
then script outputs expected result:
[...]# cat test.php
[...]# php -v
PHP 5.3.2 (cli) (built: Mar 4 2010 22:12:20)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
[...]# php test.php
int(10)
Previous Comments:
[2010-05-01 13:27:26] ninzya at inbox dot lv
Description:
See test script.
Test script:
---
[...]# cat test.php
[...]# php -v
PHP 5.3.2 (cli) (built: Mar 4 2010 22:12:20)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
[...]# php test.php
NULL
Expected result:
int(10)
Actual result:
--
NULL
--
Edit this bug report at http://bugs.php.net/bug.php?id=51715&edit=1
[PHP-BUG] Bug #51715 [NEW]: Lambda's definition breaks references when using use() clause.
From: Operating system: Any PHP version: 5.3.2 Package: Scripting Engine problem Bug Type: Bug Bug description:Lambda's definition breaks references when using use() clause. Description: See test script. Test script: --- [...]# cat test.php [...]# php -v PHP 5.3.2 (cli) (built: Mar 4 2010 22:12:20) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies [...]# php test.php NULL Expected result: int(10) Actual result: -- NULL -- Edit bug report at http://bugs.php.net/bug.php?id=51715&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51715&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51715&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51715&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51715&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51715&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51715&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51715&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51715&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51715&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51715&r=support Expected behavior: http://bugs.php.net/fix.php?id=51715&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51715&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51715&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51715&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51715&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51715&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51715&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51715&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51715&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51715&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51715&r=mysqlcfg
#50862 [Com]: php timeout < mysql timeout
ID: 50862 Comment by: ninzya at inbox dot lv Reported By: hajo at clansphere dot de Status: Open Bug Type: *Configuration Issues Operating System: Windows (any) PHP Version: 5.3.2RC1 New Comment: What if your script is running for already 50 seconds and you try to connect to mysql, which has connection timeout of 20 seconds? The only thing that might be useful is checking if mysql.connect_timeout > max_execution_time. If so, then alert startup error and abort, since such big timeout does not make any sense. But, what about ini_set() then? I wouldn't care so much about this, you should know your configuration before running scripts on it. Previous Comments: [2010-01-27 15:29:42] hajo at clansphere dot de example error msg: Fatal error: Maximum execution time of 30 seconds exceeded in ***.php on line *** [2010-01-27 15:23:28] hajo at clansphere dot de white screen of death may also be possible as a current result [2010-01-27 14:33:09] hajo at clansphere dot de Description: does it make sense to have the following values for those two settings in the default configuration? took me some time to figure out this caused some unexpected errors while i had to setup a new php testing environment. please consider changing the default php.ini settings for the production- and development-example shipped with php-downloads. Reproduce code: --- max_execution_time = 30 mysql.connect_timeout = 60 Expected result: the mysql.connect_timeout should be e.g. 10 or 20 seconds. compared to what it is for mssql.connect_timeout (5 by default) that should be enough and show an mysql timeout error. Actual result: -- php errors that inform about a timeout in php error functions / error handler or something similar to this -- Edit this bug report at http://bugs.php.net/?id=50862&edit=1
#50230 [NEW]: References passed to closures as variables corrupt original passed variable
From: ninzya at inbox dot lv
Operating system: Windows 7
PHP version: 5.3.1RC4
PHP Bug Type: Scripting Engine problem
Bug description: References passed to closures as variables corrupt original
passed variable
Description:
See the reproduce code. I have a variable $ref, which is a reference to
another variable. I am passing $ref to closure as use() by value, but, this
kind of passing corrupts $ref variable after definition of closure and $ref
becomes no longer reference, but points directly to copied data of $source
variable, which $ref was previously referring to. However, if i define
closure the following way:
$closure =function() use( &$ref) {// note pass-by-reference
echo $ref;
};
the $ref does not loose it's state.
Reproduce code:
---
$source ='Dmitry';
$ref =&$source;
$closure =function() use( $ref) {
echo $ref;
};
$ref ='Dmitry2';
echo $ref ."\n";
echo $source ."\n";
Expected result:
Dmitry2
Dmitry2
Actual result:
--
Dmitry2
Dmitry
--
Edit bug report at http://bugs.php.net/?id=50230&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50230&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50230&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50230&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50230&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50230&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50230&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50230&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50230&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50230&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50230&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50230&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50230&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50230&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50230&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50230&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50230&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50230&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50230&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50230&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50230&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50230&r=mysqlcfg
#50180 [Bgs]: max_input_time should not be taken in count after request data is processed
ID: 50180 User updated by: ninzya at inbox dot lv Reported By: ninzya at inbox dot lv Status: Bogus Bug Type: PHP options/info functions Operating System: Windows 7 PHP Version: 5.3.1RC4 New Comment: Excuse me for this, i will try to be more attentive next time. Previous Comments: [2009-11-16 12:13:24] ras...@php.net A simple search for max_input_time: http://bugs.php.net/search.php?cmd=display&search_for=max_input_time&reorder_by=id 3rd one on the list. Bug #49868 [2009-11-16 11:18:42] ninzya at inbox dot lv Thank you for the quick reply. I did search the database for the already fixed issue, and i did not find anything. I did search by "max_input_time", i did search by "maximum execution time" and got nothing for PHP 5.3. It was a pleasure to submit bug report, as usual. [2009-11-15 17:36:56] j...@php.net Thank you for not searching the bug database before submitting report about already fixed issue. [2009-11-15 11:11:34] ninzya at inbox dot lv Description: INI configuration option max_input_time affects max execution timing. I have set max_execution_time to 0 and max_input_time to 60 (60 is by default), and if my script is being run for more than 60 secs, it's getting terminated with following error - PHP Fatal error: Maximum execution time of 60 seconds exceeded in ... on line 177. If i change value of max_input_time to any other, the value is reflected in the error message. Reproduce code: --- Expected result: No errors, 3 second execution. Actual result: -- PHP Fatal error: Maximum execution time of 2 seconds exceeded in ... on line 4 -- Edit this bug report at http://bugs.php.net/?id=50180&edit=1
#50180 [Bgs]: max_input_time should not be taken in count after request data is processed
ID: 50180 User updated by: ninzya at inbox dot lv Reported By: ninzya at inbox dot lv Status: Bogus Bug Type: PHP options/info functions Operating System: Windows 7 PHP Version: 5.3.1RC4 New Comment: Thank you for the quick reply. I did search the database for the already fixed issue, and i did not find anything. I did search by "max_input_time", i did search by "maximum execution time" and got nothing for PHP 5.3. It was a pleasure to submit bug report, as usual. Previous Comments: [2009-11-15 17:36:56] j...@php.net Thank you for not searching the bug database before submitting report about already fixed issue. [2009-11-15 11:11:34] ninzya at inbox dot lv Description: INI configuration option max_input_time affects max execution timing. I have set max_execution_time to 0 and max_input_time to 60 (60 is by default), and if my script is being run for more than 60 secs, it's getting terminated with following error - PHP Fatal error: Maximum execution time of 60 seconds exceeded in ... on line 177. If i change value of max_input_time to any other, the value is reflected in the error message. Reproduce code: --- Expected result: No errors, 3 second execution. Actual result: -- PHP Fatal error: Maximum execution time of 2 seconds exceeded in ... on line 4 -- Edit this bug report at http://bugs.php.net/?id=50180&edit=1
#50180 [NEW]: max_input_time should not be taken in count after request data is processed
From: ninzya at inbox dot lv Operating system: Windows 7 PHP version: 5.3.1RC4 PHP Bug Type: PHP options/info functions Bug description: max_input_time should not be taken in count after request data is processed Description: INI configuration option max_input_time affects max execution timing. I have set max_execution_time to 0 and max_input_time to 60 (60 is by default), and if my script is being run for more than 60 secs, it's getting terminated with following error - PHP Fatal error: Maximum execution time of 60 seconds exceeded in ... on line 177. If i change value of max_input_time to any other, the value is reflected in the error message. Reproduce code: --- Expected result: No errors, 3 second execution. Actual result: -- PHP Fatal error: Maximum execution time of 2 seconds exceeded in ... on line 4 -- Edit bug report at http://bugs.php.net/?id=50180&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50180&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50180&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50180&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50180&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50180&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50180&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50180&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50180&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50180&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50180&r=support Expected behavior: http://bugs.php.net/fix.php?id=50180&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50180&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50180&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50180&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50180&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50180&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50180&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50180&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50180&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50180&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50180&r=mysqlcfg
#49934 [Com]: Add possibility to pass callbacks to assert()
ID: 49934
Comment by: ninzya at inbox dot lv
Reported By: ninzya at inbox dot lv
Status: Open
Bug Type: Feature/Change Request
Operating System: any
PHP Version: 5.3SVN-2009-10-20 (SVN)
New Comment:
This is what i use right now in my apps:
/**
* Check if assertions are true (only in debug mode)
*
* @param callback.. $callbacks
*/
function assert_cb() {
if( !DEBUG_MODE)
// do not test for assertions in non-debug mode
return;
// we assume that all arguments are callbacks, so we
// execute them one by one, until we get 'false' as a
// result.
foreach( func_get_args() as $cb) {
if( call_user_func( $cb) ===false) {
// assertion has failed
throw new Exception( 'ASSERT_FAILED');
}
}
// all assertions are valid
}
Previous Comments:
[2009-10-20 14:38:32] ninzya at inbox dot lv
Description:
The current assert() implementation is very uncomfortable, for me at
least. assert() does not skip code execution inside it's parentheses
when assertions are disabled. Also, when you are using strings to
optimize runtime of app having full of assert()s around in cases like
this - assert( 'return false;') - is very hard to read, and, if
variables are being also involved, the code looks very ugly and is error
prone.
I would like to propose to take the full advantage of closures and add
possibility to pass callbacks to assert() function. Passing callbacks to
this function would solve the both problems - bring in the readability,
and would optimize runtime by not calling callbacks when assertions are
disabled. The effect would be the same as if using strings as
parameters, but the code would become more readable a look more nicer.
Here is an example of how does assert() code look like in current PHP
versions. Assume foo() is a method of an object:
function foo( $bar) {
// This way of testing assertion
// results in a low performance, because when you disable
// assertions, the code between parentheses is still being
// executed, thus, resulting in a waste of computer resources.
assert( !$bar->testAssert( '5'));
// Another way of testing assertion. This is more optimized,
// because the passed string is not eval()ed when assertion
// checking is disabled. Good, but... strings? Unreadable,
// ugly, error prone. Yes, i know, i could use double-quotes
// here, but that's not the point, strings are no way to good,
// maintainable code.
assert( '!$bar->testAssert( \'5\')');
}
Here is an example of what i would like to see in PHP:
function foo( $bar) {
// The new way of testing assertion. Code is good, IDEs can take
// advantage of a PHP syntax and highlight the statements for me
// in my closure. Readable, sexy, way better, than having strings.
// Also, closures allow to encapsulate larger blocks of code, which
// with string approach would result in a multi-line string
// concatenation hell.
assert( function(){
return $bar->testAssert( 5);
});
// As closures are callbacks by their type, the string callback also
// should be valid as assert()'s param:
assert( 'MyClass::myTestAssertion');
}
And here comes the problem, right, how to distinguish between strings
of code ('!$bar->testAssert( \'5\')') and strings - callbacks
('MyClass::myTestAssertion')? Right, there's no good way to do this, so
i propose to create a separate version of assert(), for example,
assert_cb() (assert by callback), to maintain compatibility with those,
who use the old assertion testing approach.
Reproduce code:
---
-
Expected result:
-
Actual result:
--
-
--
Edit this bug report at http://bugs.php.net/?id=49934&edit=1
#49934 [NEW]: Add possibility to pass callbacks to assert()
From: ninzya at inbox dot lv
Operating system: any
PHP version: 5.3SVN-2009-10-20 (SVN)
PHP Bug Type: Feature/Change Request
Bug description: Add possibility to pass callbacks to assert()
Description:
The current assert() implementation is very uncomfortable, for me at
least. assert() does not skip code execution inside it's parentheses when
assertions are disabled. Also, when you are using strings to optimize
runtime of app having full of assert()s around in cases like this - assert(
'return false;') - is very hard to read, and, if variables are being also
involved, the code looks very ugly and is error prone.
I would like to propose to take the full advantage of closures and add
possibility to pass callbacks to assert() function. Passing callbacks to
this function would solve the both problems - bring in the readability, and
would optimize runtime by not calling callbacks when assertions are
disabled. The effect would be the same as if using strings as parameters,
but the code would become more readable a look more nicer.
Here is an example of how does assert() code look like in current PHP
versions. Assume foo() is a method of an object:
function foo( $bar) {
// This way of testing assertion
// results in a low performance, because when you disable
// assertions, the code between parentheses is still being
// executed, thus, resulting in a waste of computer resources.
assert( !$bar->testAssert( '5'));
// Another way of testing assertion. This is more optimized,
// because the passed string is not eval()ed when assertion
// checking is disabled. Good, but... strings? Unreadable,
// ugly, error prone. Yes, i know, i could use double-quotes
// here, but that's not the point, strings are no way to good,
// maintainable code.
assert( '!$bar->testAssert( \'5\')');
}
Here is an example of what i would like to see in PHP:
function foo( $bar) {
// The new way of testing assertion. Code is good, IDEs can take
// advantage of a PHP syntax and highlight the statements for me
// in my closure. Readable, sexy, way better, than having strings.
// Also, closures allow to encapsulate larger blocks of code, which
// with string approach would result in a multi-line string
// concatenation hell.
assert( function(){
return $bar->testAssert( 5);
});
// As closures are callbacks by their type, the string callback also
// should be valid as assert()'s param:
assert( 'MyClass::myTestAssertion');
}
And here comes the problem, right, how to distinguish between strings of
code ('!$bar->testAssert( \'5\')') and strings - callbacks
('MyClass::myTestAssertion')? Right, there's no good way to do this, so i
propose to create a separate version of assert(), for example, assert_cb()
(assert by callback), to maintain compatibility with those, who use the old
assertion testing approach.
Reproduce code:
---
-
Expected result:
-
Actual result:
--
-
--
Edit bug report at http://bugs.php.net/?id=49934&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49934&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49934&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49934&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49934&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49934&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49934&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49934&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49934&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49934&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49934&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49934&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49934&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49934&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49934&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49934&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49934&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49934&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49934&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49934&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49934&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49934&r=mysqlcfg
#48880 [Com]: Random Appearing open_basedir problem
ID: 48880 Comment by: ninzya at inbox dot lv Reported By: brwarner at rogers dot com Status: Open Bug Type: Safe Mode/open_basedir Operating System: * PHP Version: 5.3.0 New Comment: I hit this bug quite frequently. I have noticed that it occurs after some time while apache is running, even if you don't actually request any pages. You can leave apache working for an hour, or two, and then request any php file - the result is this bug. Maybe it is somehow connected to PHP operations it does periodically (GC or something). One thing is clear - open_basedir's path (string it is referring to) is being corrupted and memory overwritten. Either it is done by overwriting this memory, or by change of memory location open_basedir's string ptr is pointing to. Previous Comments: [2009-07-29 12:19:41] lukas dot starecek at qcm dot cz Problem persists and ticket was suspended and no body except author or php developers can't change status to open. Realy annoying... [2009-07-29 01:00:00] 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". [2009-07-26 07:17:07] duchesne7 at gmail dot com I confirm this bug under Fedora 11 x64 with Apache 2.2.10 and PHP 5.3.0 (also tryed last SVN with no luck). Seems to be some sort of memory corruption since I sometimes see HTTP headers in the allowed paths, like: File(/home/cpanel/index.php) is not within the allowed path(s): (ww\tX-Powered-By: P) in Unknown on line 0 It happens whenever open_basedir is modified at runtime (either with php_admin_value in httpd.conf or with an extension that I use which reset open_basedir according to regex rules before script execution.) [2009-07-25 16:06:26] server at grow-werbeagentur dot de Confirm this Bug. Still persists with 200907251430 went back to 5.2.10 now, cause this is very anyoing.. The weird thing though is, that I tested the 5.3.0 release on our dev server first with no errors at all but when installing it on our production servers, which are configured exactly the same as our dev, I get this random open_basedir error.. weird.. [2009-07-22 16:19:47] hristozov at gmail dot com The problem persists with 200907221430. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/48880 -- Edit this bug report at http://bugs.php.net/?id=48880&edit=1
#48880 [Com]: Random Appearing open_basedir problem
ID: 48880 Comment by: ninzya at inbox dot lv Reported By: brwarner at rogers dot com Status: Verified Bug Type:Safe Mode/open_basedir PHP Version: 5.3.0 New Comment: Just hit this one on Windows XP. [20-Jul-2009 01:07:54] PHP Warning: Unknown: open_basedir restriction in effect. File(D:\...\auth.php) is not within the allowed path(s): (˜"ט"×\(g) in Unknown on line 0 [20-Jul-2009 01:07:54] PHP Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0 [20-Jul-2009 01:07:54] PHP Fatal error: Unknown: Failed opening required 'D:\...\auth.php' (include_path='.;C:\php5\pear') in Unknown on line 0 Previous Comments: [2009-07-13 09:59:08] jarda at jyxo dot com Same problem in Debian Etch. [2009-07-12 20:47:10] gwy...@php.net I set up a build of 5.3 (latest SVN) with Apache 2.2.11, set php_admin_value open_basedir, and ran the whole mess through valgrind. Here're the results: ==63247== Invalid read of size 1 ==63247==at 0x100C4974B: OnUpdateBaseDir (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100D00B5A: zend_alter_ini_entry_ex (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100D008C3: zend_alter_ini_entry (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100DF0C5D: apply_config (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100DEFF53: php_handler (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x11C2A: ap_run_handler (in /sw/httpd/bin/httpd) ==63247==by 0x124DD: ap_invoke_handler (in /sw/httpd/bin/httpd) ==63247==by 0x100038579: ap_process_request (in /sw/httpd/bin/httpd) ==63247==by 0x100034E3C: ap_process_http_connection (in /sw/httpd/bin/httpd) ==63247==by 0x100012356: ap_run_process_connection (in /sw/httpd/bin/httpd) ==63247==by 0x1000127A6: ap_process_connection (in /sw/httpd/bin/httpd) ==63247==by 0x10005EC22: child_main (in /sw/httpd/bin/httpd) ==63247== Address 0x1037727b0 is 0 bytes inside a block of size 17 free'd ==63247==at 0x1000BDAEF: free (vg_replace_malloc.c:324) ==63247==by 0x100CB259C: _efree (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100CFFF97: zend_restore_ini_entry_cb (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100D00042: zend_restore_ini_entry_wrapper (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100CF5F03: zend_hash_apply (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100D00225: zend_ini_deactivate (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100CE28D7: zend_deactivate (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100C40DC2: php_request_shutdown (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100DEFBB9: php_apache_request_dtor (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100DF05B9: php_handler (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x11C2A: ap_run_handler (in /sw/httpd/bin/httpd) ==63247==by 0x124DD: ap_invoke_handler (in /sw/httpd/bin/httpd) ==63247== ==63247== Invalid read of size 1 ==63247==at 0x100C49C20: php_check_open_basedir_ex (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100C497EA: OnUpdateBaseDir (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100D00B5A: zend_alter_ini_entry_ex (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100D008C3: zend_alter_ini_entry (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100DF0C5D: apply_config (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100DEFF53: php_handler (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x11C2A: ap_run_handler (in /sw/httpd/bin/httpd) ==63247==by 0x124DD: ap_invoke_handler (in /sw/httpd/bin/httpd) ==63247==by 0x100038579: ap_process_request (in /sw/httpd/bin/httpd) ==63247==by 0x100034E3C: ap_process_http_connection (in /sw/httpd/bin/httpd) ==63247==by 0x100012356: ap_run_process_connection (in /sw/httpd/bin/httpd) ==63247==by 0x1000127A6: ap_process_connection (in /sw/httpd/bin/httpd) ==63247== Address 0x1037727b0 is 0 bytes inside a block of size 17 free'd ==63247==at 0x1000BDAEF: free (vg_replace_malloc.c:324) ==63247==by 0x100CB259C: _efree (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100CFFF97: zend_restore_ini_entry_cb (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100D00042: zend_restore_ini_entry_wrapper (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100CF5F03: zend_hash_apply (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100D00225: zend_ini_deactivate (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100CE28D7: zend_deactivate (in /opt/httpd-2.2.11/modules/libphp5.so) ==63247==by 0x100C40DC2: php_request_shutdown (in /opt/htt
#48923 [Com]: while() is not working on PHP5 as it always did
ID: 48923
Comment by: ninzya at inbox dot lv
Reported By: raulsanchezt at gmail dot com
Status: Open
Bug Type: *Programming Data Structures
Operating System: Fedora 6
PHP Version: 5.2.10
New Comment:
You should be more carefully reading PHP docs and practicing your code
debugging rather than posting "cool ass kicking fail code" reports,
because your code contains bugs.
1) First two loops are infinite loops because !$v_success is always
true (i guess you should put "&&" (and) op instead of "or"), and the
last one shows you "expected result" because "$v_success = false" is an
assignment operation (nonsense), after which your loop hits false in
$v_success and goes on to compare "$v_x < $_SESSION["v_attempts"]" and
runs until it's false too.
2) Do you have session_start()'ed at the time of using $_SESSION
array?
The segmentation fault you see you get when you hit ctrl-c?
PHP has nothing to do with firefox scripting.
Previous Comments:
[2009-07-14 20:05:52] raulsanchezt at gmail dot com
Description:
What you'll see below are three versions of the same code. Version a)
worked for me all along PHP4 (for years and years). After upgrading to
PHP5 it's not working anymore. Version b) does not work either. Version
c) does work.
Version a) runs indefinitely until I Ctrl-C it.
Version b) runs indefinitely until I Ctrl-C it.
Version c) runs for a millionth of a second and shows the expected
result
This code is a great simplification of what I actually coded (a MySQL
wrapper). I spent two full weeks trying to find out what was wrong with
my new PHP5/MySQL/Zend Debugger/Eclipse implementation until I bumped
into this little, unbelievable, never-to-be-expected bug.
Reproduce code:
---
// version a) while() does not work anymore
$v_x = 0;
$v_success = false;
$_SESSION["v_attempts"] = 20;
while(!$v_success or ($v_x < $_SESSION["v_attempts"]))
{
// irrelevant code that may change the value of $v_success
$v_x++;
}
// version b) while() does not work either
$v_x = 0;
$v_success = false;
$_SESSION["v_attempts"] = 20;
while((!$v_success) or ($v_x < $_SESSION["v_attempts"]))
{
// irrelevant code that may change the value of $v_success
$v_x++;
}
// version c) this one works
$v_x = 0;
$v_success = false;
$_SESSION["v_attempts"] = 20;
while(($v_success = false) or ($v_x < $_SESSION["v_attempts"]))
{
// irrelevant code that may change the value of $v_success
$v_x++;
}
Expected result:
I expect to see the actual value of $v_x, which should be 20.
Actual result:
--
(gdb) run testfile.php
Starting program: /usr/local/zend/bin/php testfile.php
warning: Lowest section in system-supplied DSO at 0xe000 is .hash
at e0b4
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 4160407232 (LWP 24052)]
Error while reading shared library symbols:
Cannot find new threads: generic error
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
Segmentation fault
NOTE: all three versions produce this output. The three versions run
the same as CGIs and as Firefox scripts.
--
Edit this bug report at http://bugs.php.net/?id=48923&edit=1
#48903 [Bgs]: Lambda function as array index
ID: 48903
User updated by: ninzya at inbox dot lv
Reported By: ninzya at inbox dot lv
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.3.0
New Comment:
Yep, my typo, just figured out. Incorrectly used lambdas.
Previous Comments:
[2009-07-13 13:34:24] col...@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
You can't, as usual, use objects as array keys.
Check out SplObjectStorage.
[2009-07-13 13:29:35] ninzya at inbox dot lv
Description:
See reproduce code.
Reproduce code:
---
Expected result:
array(1) {
[5]=>
string(8) "Stepanov"
}
Actual result:
--
Warning: Illegal offset type in D:\...\index.php on line 5
array(0) {
}
--
Edit this bug report at http://bugs.php.net/?id=48903&edit=1
#48903 [NEW]: Lambda function as array index
From: ninzya at inbox dot lv
Operating system: Windows XP
PHP version: 5.3.0
PHP Bug Type: Scripting Engine problem
Bug description: Lambda function as array index
Description:
See reproduce code.
Reproduce code:
---
Expected result:
array(1) {
[5]=>
string(8) "Stepanov"
}
Actual result:
--
Warning: Illegal offset type in D:\...\index.php on line 5
array(0) {
}
--
Edit bug report at http://bugs.php.net/?id=48903&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48903&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48903&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48903&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48903&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48903&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48903&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48903&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48903&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48903&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48903&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48903&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48903&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48903&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48903&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48903&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48903&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48903&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48903&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48903&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48903&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48903&r=mysqlcfg
#48793 [Com]: Setting error_log in php.ini causes redirection
ID: 48793 Comment by: ninzya at inbox dot lv Reported By: memoimyself at yahoo dot com dot br Status: Open Bug Type: *General Issues Operating System: WinXP SP3 PHP Version: 5.3.0 New Comment: I guess this is your browser's activity. PHP itself does not deal with 'user hint' redirections by prepending or appending www's and com's to the requested host. Your browser, probably, reacts to HTTP 500 error code and attempts a redirection to probably valid location of www.localhost.com. Anyway, look at the access.log of apache, see what's the apache's response code to your request. Another guess may be is that the PHP is failing (segfaulting) with error_log, which leads to connection interruption between your browser and web server. Then browser attempts to connect to www.localhost.com... Anyway, redirection is being done by your browser. Previous Comments: [2009-07-04 21:10:31] memoimyself at yahoo dot com dot br Q: Is your apache server on 8080 port? A: Nope, 80. My httpd.conf is pretty straightforward and uses default values. Please note that Apache serves pure HTML (as well as other files) normally. Things only get weird when PHP is involved AND error_log is set in php.ini. -------- [2009-07-04 20:02:22] ninzya at inbox dot lv Is your apache server on 8080 port? [2009-07-03 18:43:47] memoimyself at yahoo dot com dot br Description: Set-up: WinXP SP3, PHP 5.3.0, Apache 2.2.11 This is a truly bizarre problem, but I've done a lot of testing and do believe it's a bug. A few days ago I updated my test server to PHP 5.3.0. After doing that, even though Apache had not been touched in any way, all URLs containing 'localhost' pointing to PHP files (e.g. 'http://localhost/whatever.php') started being redirected to 'www.localhost.com' (e.g. 'http://www.localhost.com/whatever.php'). At first it didn't even occur to me that the problem could have anything to do with PHP. I checked 'c:\windows\system32\drivers\etc\hosts' and it still contained a line for '127.0.0.1 localhost'. I checked my network adapter configuration and IPv6 had not been added as a protocol. My Apache configuration files were untouched. I spent two days searching high and low for a possible cause, and along the way realized that the problem only occurred when PHP was involved: HTML files were being served without any redirection issues. When I replaced php.ini with an old version from a backup and everything went back to normal, so I fired up a diff application and, bit by bit, started replacing the contents of the newer php.ini with lines from the old one. I finally isolated the problem: the error_log line, which specified the absolute path to a log file (the same path that had been working fine with previous PHP versions). When the line is commented out, the redirection problem goes away. I double-checked the existence of the log file and made sure it was writable. I then tried moving it to a different directory (updating php.ini accordingly), but that didn't work either. I also tried changing the path from "C:\Apache\logs\php_error.log" to "file:///C:/Apache/logs/php_error.log" and that did make the redirection problem go away, but no errors are actually logged, even though 'log_errors' is properly set to 'On'. If I set error_log back to "C:\Apache\logs\php_error.log", the redirection issues comes back. Reproduce code: --- Line in php.ini: error_log = "C:\Apache\logs\php_error.log" Expected result: Errors should be logged as usual. Actual result: -- Errors are not logged. Whether or not code contains any errors, browser (both IE and Firefox) gets redirected from http://localhost/path/to/script to http://www.localhost.com/path/to/script. -- Edit this bug report at http://bugs.php.net/?id=48793&edit=1
#48793 [Com]: Setting error_log in php.ini causes redirection
ID: 48793 Comment by: ninzya at inbox dot lv Reported By: memoimyself at yahoo dot com dot br Status: Open Bug Type: Unknown/Other Function Operating System: WinXP SP3 PHP Version: 5.3.0 New Comment: Is your apache server on 8080 port? Previous Comments: [2009-07-03 18:43:47] memoimyself at yahoo dot com dot br Description: Set-up: WinXP SP3, PHP 5.3.0, Apache 2.2.11 This is a truly bizarre problem, but I've done a lot of testing and do believe it's a bug. A few days ago I updated my test server to PHP 5.3.0. After doing that, even though Apache had not been touched in any way, all URLs containing 'localhost' pointing to PHP files (e.g. 'http://localhost/whatever.php') started being redirected to 'www.localhost.com' (e.g. 'http://www.localhost.com/whatever.php'). At first it didn't even occur to me that the problem could have anything to do with PHP. I checked 'c:\windows\system32\drivers\etc\hosts' and it still contained a line for '127.0.0.1 localhost'. I checked my network adapter configuration and IPv6 had not been added as a protocol. My Apache configuration files were untouched. I spent two days searching high and low for a possible cause, and along the way realized that the problem only occurred when PHP was involved: HTML files were being served without any redirection issues. When I replaced php.ini with an old version from a backup and everything went back to normal, so I fired up a diff application and, bit by bit, started replacing the contents of the newer php.ini with lines from the old one. I finally isolated the problem: the error_log line, which specified the absolute path to a log file (the same path that had been working fine with previous PHP versions). When the line is commented out, the redirection problem goes away. I double-checked the existence of the log file and made sure it was writable. I then tried moving it to a different directory (updating php.ini accordingly), but that didn't work either. I also tried changing the path from "C:\Apache\logs\php_error.log" to "file:///C:/Apache/logs/php_error.log" and that did make the redirection problem go away, but no errors are actually logged, even though 'log_errors' is properly set to 'On'. If I set error_log back to "C:\Apache\logs\php_error.log", the redirection issues comes back. Reproduce code: --- Line in php.ini: error_log = "C:\Apache\logs\php_error.log" Expected result: Errors should be logged as usual. Actual result: -- Errors are not logged. Whether or not code contains any errors, browser (both IE and Firefox) gets redirected from http://localhost/path/to/script to http://www.localhost.com/path/to/script. -- Edit this bug report at http://bugs.php.net/?id=48793&edit=1
#48659 [NEW]: dirname() to accept path level to return
From: ninzya at inbox dot lv Operating system: - PHP version: 5.3.0RC4 PHP Bug Type: Feature/Change Request Bug description: dirname() to accept path level to return Description: It would be great if dirname() function had a second parameter, let's say - uint $level, which would mean "how many path levels to strip off". By default this parameter could be set to 1 to not to break the backwards compatibility. Reproduce code: --- Expected result: Expect this feature to be implemented Actual result: -- - -- Edit bug report at http://bugs.php.net/?id=48659&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48659&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48659&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48659&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48659&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48659&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48659&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48659&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48659&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48659&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48659&r=support Expected behavior: http://bugs.php.net/fix.php?id=48659&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48659&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48659&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48659&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48659&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48659&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48659&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48659&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48659&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48659&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48659&r=mysqlcfg
#47712 [Fbk->Opn]: (mysqlnd) zval cache on windows fails at high concurrency
ID: 47712 User updated by: ninzya at inbox dot lv -Summary: (mysqlnd) last fetched row may get corrupted after calling mysql_free_result() Reported By: ninzya at inbox dot lv -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: Windows XP PHP Version: 5.3.0RC2 Assigned To: mysql New Comment: Changed bug summary. zval cache is still not fixed on windows. Changed bug status to "Open". Previous Comments: [2009-06-15 10:33:55] ninzya at inbox dot lv For example, this one http://bugs.php.net/bug.php?id=48525 I have seen some more bug reports just after you have turned off zval cache and committed to CVS, i can't find them right now. [2009-06-15 10:14:33] and...@php.net Can you be more specific about these memory leaks? [2009-06-14 11:31:32] ninzya at inbox dot lv People started reporting memory leaks when working with mysql (through PDO, mysqli, mysql). I didn't try to investigate this issue, but i assume the leaks may have taken place after andrey has switched zval cache to off. You should take a look at this. See some bug reports after andrey has posted about the change he has made to CVS. [2009-06-11 20:13:23] ninzya at inbox dot lv The problem with turned zval cache off is away, but with turned on zval cache bug still exists, so i assume the bug is NOT fixed, turning zval cache off is a temporary fix, that's why i keep the bug open. Or i shouldn't? [2009-06-11 17:30:45] and...@php.net Do you still experience the problem? You said you don't or you see it again? The zval cache is switched off and there is no way to enable it without recompiling. If the problem persist we have to search for the problem somewhere else. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47712 -- Edit this bug report at http://bugs.php.net/?id=47712&edit=1
#48534 [Com]: Infinite loop with: log_errors+display_startup_errors+no timezone
ID: 48534 Comment by: ninzya at inbox dot lv Reported By: paul at mantisforge dot org Status: Verified Bug Type: PHP options/info functions Operating System: Windows 32bit PHP Version: 5.3.0RC3 Assigned To: derick New Comment: ALSO hit this bug, i mean Previous Comments: [2009-06-15 21:23:29] ninzya at inbox dot lv Just hit this bug. [2009-06-12 17:26:34] s...@php.net This is a consequence of not-complete fix for bug #48247. I have a proposed fix, Derick needs to look at it. [2009-06-12 00:35:03] paj...@php.net Stan, can you take a look please? It could be related to your latest fix. [2009-06-11 22:24:21] paul at mantisforge dot org Description: Calling php from command line with (for example): c:\php\php -c "c:\php\foo.ini" -i Results in an infinite logging loop if a) display_startup_errors is on b) no timezone has been set in php.ini c) error logging to file is on Reproduce code: --- PHP.ini: log_errors = On error_log = "c:\temp\php.log" display_startup_errors = On Expected result: phpinfo(); is displayed Actual result: -- *snip* ctype ctype functions => enabled date date/time support => enabled "Olson" Timezone Database Version => 2009.9 Timezone Database => internal Warning: Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set () function. In case you used any of those methods and you are still getting thi s warning, you most likely misspelled the timezone identifier. We selected 'Euro pe/London' for '1.0/DST' instead in Unknown on line 0 Warning: Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set () function. In case you used any of those methods and you are still getting thi s warning, you most likely misspelled the timezone identifier. We selected 'Euro pe/London' for '1.0/DST' instead in Unknown on line 0 Warning: Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set () function. In case you used any of those methods and you are still getting thi s warning, you most likely misspelled the timezone identifier. We selected 'Euro pe/London' for '1.0/DST' instead in Unknown on line 0 ... .. . -- Edit this bug report at http://bugs.php.net/?id=48534&edit=1
#48534 [Com]: Infinite loop with: log_errors+display_startup_errors+no timezone
ID: 48534 Comment by: ninzya at inbox dot lv Reported By: paul at mantisforge dot org Status: Verified Bug Type: PHP options/info functions Operating System: Windows 32bit PHP Version: 5.3.0RC3 Assigned To: derick New Comment: Just hit this bug. Previous Comments: [2009-06-12 17:26:34] s...@php.net This is a consequence of not-complete fix for bug #48247. I have a proposed fix, Derick needs to look at it. [2009-06-12 00:35:03] paj...@php.net Stan, can you take a look please? It could be related to your latest fix. [2009-06-11 22:24:21] paul at mantisforge dot org Description: Calling php from command line with (for example): c:\php\php -c "c:\php\foo.ini" -i Results in an infinite logging loop if a) display_startup_errors is on b) no timezone has been set in php.ini c) error logging to file is on Reproduce code: --- PHP.ini: log_errors = On error_log = "c:\temp\php.log" display_startup_errors = On Expected result: phpinfo(); is displayed Actual result: -- *snip* ctype ctype functions => enabled date date/time support => enabled "Olson" Timezone Database Version => 2009.9 Timezone Database => internal Warning: Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set () function. In case you used any of those methods and you are still getting thi s warning, you most likely misspelled the timezone identifier. We selected 'Euro pe/London' for '1.0/DST' instead in Unknown on line 0 Warning: Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set () function. In case you used any of those methods and you are still getting thi s warning, you most likely misspelled the timezone identifier. We selected 'Euro pe/London' for '1.0/DST' instead in Unknown on line 0 Warning: Unknown: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set () function. In case you used any of those methods and you are still getting thi s warning, you most likely misspelled the timezone identifier. We selected 'Euro pe/London' for '1.0/DST' instead in Unknown on line 0 ... .. . -- Edit this bug report at http://bugs.php.net/?id=48534&edit=1
#47712 [Com]: (mysqlnd) last fetched row may get corrupted after calling mysql_free_result()
ID: 47712 Comment by: ninzya at inbox dot lv Reported By: ninzya at inbox dot lv Status: Feedback Bug Type: MySQL related Operating System: Windows XP PHP Version: 5.3.0RC2 Assigned To: mysql New Comment: For example, this one http://bugs.php.net/bug.php?id=48525 I have seen some more bug reports just after you have turned off zval cache and committed to CVS, i can't find them right now. Previous Comments: [2009-06-15 10:14:33] and...@php.net Can you be more specific about these memory leaks? [2009-06-14 11:31:32] ninzya at inbox dot lv People started reporting memory leaks when working with mysql (through PDO, mysqli, mysql). I didn't try to investigate this issue, but i assume the leaks may have taken place after andrey has switched zval cache to off. You should take a look at this. See some bug reports after andrey has posted about the change he has made to CVS. [2009-06-11 20:13:23] ninzya at inbox dot lv The problem with turned zval cache off is away, but with turned on zval cache bug still exists, so i assume the bug is NOT fixed, turning zval cache off is a temporary fix, that's why i keep the bug open. Or i shouldn't? [2009-06-11 17:30:45] and...@php.net Do you still experience the problem? You said you don't or you see it again? The zval cache is switched off and there is no way to enable it without recompiling. If the problem persist we have to search for the problem somewhere else. ---- [2009-06-10 23:51:39] ninzya at inbox dot lv I guess zval cache is not fixed on windows yet, so i open the bug. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47712 -- Edit this bug report at http://bugs.php.net/?id=47712&edit=1
#47712 [Com]: (mysqlnd) last fetched row may get corrupted after calling mysql_free_result()
ID: 47712 Comment by: ninzya at inbox dot lv Reported By: ninzya at inbox dot lv Status: Open Bug Type: MySQL related Operating System: Windows XP PHP Version: 5.3.0RC2 Assigned To: mysql New Comment: People started reporting memory leaks when working with mysql (through PDO, mysqli, mysql). I didn't try to investigate this issue, but i assume the leaks may have taken place after andrey has switched zval cache to off. You should take a look at this. See some bug reports after andrey has posted about the change he has made to CVS. Previous Comments: [2009-06-11 20:13:23] ninzya at inbox dot lv The problem with turned zval cache off is away, but with turned on zval cache bug still exists, so i assume the bug is NOT fixed, turning zval cache off is a temporary fix, that's why i keep the bug open. Or i shouldn't? [2009-06-11 17:30:45] and...@php.net Do you still experience the problem? You said you don't or you see it again? The zval cache is switched off and there is no way to enable it without recompiling. If the problem persist we have to search for the problem somewhere else. [2009-06-10 23:51:39] ninzya at inbox dot lv I guess zval cache is not fixed on windows yet, so i open the bug. [2009-06-09 13:47:54] and...@php.net Turning on is only possible through a recompilation. Maybe we can add an ini option (INI_SYSTEM) to switch it without recompilation. But currently the CVS is locked for changes. [2009-06-09 11:05:57] ninzya at inbox dot lv Well, seems something is wrong with concurrent access to zval cache on windows. Try turning zval cache on and test my code on windows machine. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47712 -- Edit this bug report at http://bugs.php.net/?id=47712&edit=1
#47712 [Fbk->Opn]: (mysqlnd) last fetched row may get corrupted after calling mysql_free_result()
ID: 47712 User updated by: ninzya at inbox dot lv Reported By: ninzya at inbox dot lv -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: Windows XP PHP Version: 5.3.0RC2 Assigned To: mysql New Comment: The problem with turned zval cache off is away, but with turned on zval cache bug still exists, so i assume the bug is NOT fixed, turning zval cache off is a temporary fix, that's why i keep the bug open. Or i shouldn't? Previous Comments: [2009-06-11 17:30:45] and...@php.net Do you still experience the problem? You said you don't or you see it again? The zval cache is switched off and there is no way to enable it without recompiling. If the problem persist we have to search for the problem somewhere else. [2009-06-10 23:51:39] ninzya at inbox dot lv I guess zval cache is not fixed on windows yet, so i open the bug. [2009-06-09 13:47:54] and...@php.net Turning on is only possible through a recompilation. Maybe we can add an ini option (INI_SYSTEM) to switch it without recompilation. But currently the CVS is locked for changes. [2009-06-09 11:05:57] ninzya at inbox dot lv Well, seems something is wrong with concurrent access to zval cache on windows. Try turning zval cache on and test my code on windows machine. [2009-06-09 09:54:26] and...@php.net The only change I did was to switch off the zval caching code so every time a zval is needed a new one is created by Zend instead of using our cache. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47712 -- Edit this bug report at http://bugs.php.net/?id=47712&edit=1
#47712 [Fbk->Opn]: (mysqlnd) last fetched row may get corrupted after calling mysql_free_result()
ID: 47712 User updated by: ninzya at inbox dot lv Reported By: ninzya at inbox dot lv -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: Windows XP PHP Version: 5.3.0RC2 Assigned To: mysql New Comment: I guess zval cache is not fixed on windows yet, so i open the bug. Previous Comments: [2009-06-09 13:47:54] and...@php.net Turning on is only possible through a recompilation. Maybe we can add an ini option (INI_SYSTEM) to switch it without recompilation. But currently the CVS is locked for changes. [2009-06-09 11:05:57] ninzya at inbox dot lv Well, seems something is wrong with concurrent access to zval cache on windows. Try turning zval cache on and test my code on windows machine. [2009-06-09 09:54:26] and...@php.net The only change I did was to switch off the zval caching code so every time a zval is needed a new one is created by Zend instead of using our cache. [2009-06-09 09:53:12] and...@php.net Hi, maybe it is, I think it should be. I did not rely on phpt for testing. I just put it on a Apache2 MPM, Linux, and ran 2 million requests, concurrency of 150, thread-safe build. I asked ab to run with verbosity of 2, and logged the output to a file. Then I did a grep on Conten-Length, then I uniq-ued and sorted the results. Just 5 results. One is correct, others were the errors because of exhausted resources. [2009-06-08 13:52:46] ninzya at inbox dot lv I have just tested my code on linux machine and got no problems. Seems this bug affects only windows build. I have downloaded latest available PHP 5.3.0RC3 snap from snaps.php.net (PHP 5.3.0RC3-dev (built: Jun 8 2009 14:06:20)), the bug is gone now. If this is your patched snap, then seems you have found the issue. If not, mayble the solar activity has decreased (we're lucky and the bug was fixed by another dev). Anyway, i'm glad it's working now. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47712 -- Edit this bug report at http://bugs.php.net/?id=47712&edit=1
#47712 [Com]: (mysqlnd) last fetched row may get corrupted after calling mysql_free_result()
ID: 47712 Comment by: ninzya at inbox dot lv Reported By: ninzya at inbox dot lv Status: Feedback Bug Type: MySQL related Operating System: Windows XP PHP Version: 5.3.0RC2 Assigned To: mysql New Comment: Well, seems something is wrong with concurrent access to zval cache on windows. Try turning zval cache on and test my code on windows machine. Previous Comments: [2009-06-09 09:54:26] and...@php.net The only change I did was to switch off the zval caching code so every time a zval is needed a new one is created by Zend instead of using our cache. [2009-06-09 09:53:12] and...@php.net Hi, maybe it is, I think it should be. I did not rely on phpt for testing. I just put it on a Apache2 MPM, Linux, and ran 2 million requests, concurrency of 150, thread-safe build. I asked ab to run with verbosity of 2, and logged the output to a file. Then I did a grep on Conten-Length, then I uniq-ued and sorted the results. Just 5 results. One is correct, others were the errors because of exhausted resources. [2009-06-08 13:52:46] ninzya at inbox dot lv I have just tested my code on linux machine and got no problems. Seems this bug affects only windows build. I have downloaded latest available PHP 5.3.0RC3 snap from snaps.php.net (PHP 5.3.0RC3-dev (built: Jun 8 2009 14:06:20)), the bug is gone now. If this is your patched snap, then seems you have found the issue. If not, mayble the solar activity has decreased (we're lucky and the bug was fixed by another dev). Anyway, i'm glad it's working now. [2009-06-08 13:26:07] ninzya at inbox dot lv Hello, Andrey. Well, the script you are using is not exactly the same i have provided. Try testing for values of $row keys, see if the contained data is the data you expect, as i did in my case. Do not rely on PHPT, try benchmarking locally. I will try my code on linux machine and report in a couple of minutes. [2009-06-08 13:17:46] and...@php.net Just tried again. 2 million requests, concurrency of 150, which led to load of 90 on the box - pretty hefty, where a problem should show itself and again no problem except that in some cases connection to MySQL couldn't be established, which is to be expected. MySQL was set up to have 1000 maximal connections, so it is not the bottleneck, just system resources. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47712 -- Edit this bug report at http://bugs.php.net/?id=47712&edit=1
#47712 [Com]: (mysqlnd) last fetched row may get corrupted after calling mysql_free_result()
ID: 47712 Comment by: ninzya at inbox dot lv Reported By: ninzya at inbox dot lv Status: Feedback Bug Type: MySQL related Operating System: Windows XP PHP Version: 5.3.0RC2 Assigned To: mysql New Comment: I have just tested my code on linux machine and got no problems. Seems this bug affects only windows build. I have downloaded latest available PHP 5.3.0RC3 snap from snaps.php.net (PHP 5.3.0RC3-dev (built: Jun 8 2009 14:06:20)), the bug is gone now. If this is your patched snap, then seems you have found the issue. If not, mayble the solar activity has decreased (we're lucky and the bug was fixed by another dev). Anyway, i'm glad it's working now. Previous Comments: [2009-06-08 13:26:07] ninzya at inbox dot lv Hello, Andrey. Well, the script you are using is not exactly the same i have provided. Try testing for values of $row keys, see if the contained data is the data you expect, as i did in my case. Do not rely on PHPT, try benchmarking locally. I will try my code on linux machine and report in a couple of minutes. [2009-06-08 13:17:46] and...@php.net Just tried again. 2 million requests, concurrency of 150, which led to load of 90 on the box - pretty hefty, where a problem should show itself and again no problem except that in some cases connection to MySQL couldn't be established, which is to be expected. MySQL was set up to have 1000 maximal connections, so it is not the bottleneck, just system resources. [2009-06-08 12:46:49] and...@php.net Hi, I switched on the zval cache and tried to reproduce the problem, with no success. I tested with Apache2 MPM. `ab` concurrency level starting from 20 up to 100. Time from 30 to 45 seconds. I got, with your code, only 3 types of errors. I added mysql_connect() myself - mysql_connect() fails because cannot have more connections on the unix socket. Using TCP/IP exhausts the resources earlier for connecting to MySQL - mysql_query() tries to connect, although the connection has failed, typical for mysql_query()! It fails : -- password problem -- no resources I did not see any corruption whatsoever. Difference from you is that I tested on Linux, as server. ab was running on a Mac connected over a FastEthernet switch. Here follows the code I used: [2009-06-08 10:36:49] and...@php.net Is is possible to provide a package which we can run, even it is not 20-30lines of code, so we can try to reproduce the problem? In the meanwhile I have committed a change to mysqlnd which I suppose should lead to the problem disappearing - switching the zval cache off. Could you try downloading and testing a binary from http://windows.php.net/snapshots/ New snapshot should be ready in a few hours. I suppose you will need the VC6 build. Thank you! Andrey [2009-05-12 09:42:13] ninzya at inbox dot lv This bug is still present in PHP 5.3.0RC2 and is critical to me. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47712 -- Edit this bug report at http://bugs.php.net/?id=47712&edit=1
#47712 [Com]: (mysqlnd) last fetched row may get corrupted after calling mysql_free_result()
ID: 47712 Comment by: ninzya at inbox dot lv Reported By: ninzya at inbox dot lv Status: Feedback Bug Type: MySQL related Operating System: Windows XP PHP Version: 5.3.0RC2 Assigned To: mysql New Comment: Hello, Andrey. Well, the script you are using is not exactly the same i have provided. Try testing for values of $row keys, see if the contained data is the data you expect, as i did in my case. Do not rely on PHPT, try benchmarking locally. I will try my code on linux machine and report in a couple of minutes. Previous Comments: [2009-06-08 13:17:46] and...@php.net Just tried again. 2 million requests, concurrency of 150, which led to load of 90 on the box - pretty hefty, where a problem should show itself and again no problem except that in some cases connection to MySQL couldn't be established, which is to be expected. MySQL was set up to have 1000 maximal connections, so it is not the bottleneck, just system resources. [2009-06-08 12:46:49] and...@php.net Hi, I switched on the zval cache and tried to reproduce the problem, with no success. I tested with Apache2 MPM. `ab` concurrency level starting from 20 up to 100. Time from 30 to 45 seconds. I got, with your code, only 3 types of errors. I added mysql_connect() myself - mysql_connect() fails because cannot have more connections on the unix socket. Using TCP/IP exhausts the resources earlier for connecting to MySQL - mysql_query() tries to connect, although the connection has failed, typical for mysql_query()! It fails : -- password problem -- no resources I did not see any corruption whatsoever. Difference from you is that I tested on Linux, as server. ab was running on a Mac connected over a FastEthernet switch. Here follows the code I used: [2009-06-08 10:36:49] and...@php.net Is is possible to provide a package which we can run, even it is not 20-30lines of code, so we can try to reproduce the problem? In the meanwhile I have committed a change to mysqlnd which I suppose should lead to the problem disappearing - switching the zval cache off. Could you try downloading and testing a binary from http://windows.php.net/snapshots/ New snapshot should be ready in a few hours. I suppose you will need the VC6 build. Thank you! Andrey [2009-05-12 09:42:13] ninzya at inbox dot lv This bug is still present in PHP 5.3.0RC2 and is critical to me. [2009-04-19 12:04:11] ninzya at inbox dot lv Changed bug summary. My configuration: Apache 2.2, PHP 5.3.0RC1 as module, Windows XP SP3, MySQL community server 5.1.33 Bug being hit during high concurrency running apache benchmark: "ab -c 30 -n 1". See previous posts for details. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47712 -- Edit this bug report at http://bugs.php.net/?id=47712&edit=1
#48343 [Com]: Mysqlnd memory leak when fetching rows
ID: 48343
Comment by: ninzya at inbox dot lv
Reported By: mikec at mikenz dot geek dot nz
Status: Open
Bug Type: MySQLi related
Operating System: *
PHP Version: 5.3CVS-2009-05-20 (snap)
New Comment:
Try destroying mysqli object before calculating estimated memory usage.
See what are results.
Previous Comments:
[2009-05-20 05:56:05] mikec at mikenz dot geek dot nz
Description:
A simple loop fetching rows from a database uses a lot more memory of
php5.3 when compared to php5.2.
First noticed on a Debian machine. Confirmed on a Windows machine with
latest snaps (20-May-2009). php.ini based on php.ini-dist/development
only change is to enable mysqli.
Reproduce code:
---
query('SELECT * FROM `test`');
$rows = 0;
while($result->fetch_array(MYSQLI_ASSOC)) {$rows++;}
$after = memory_get_usage();
echo "\nAfter: " . $after;
echo "\nDelta: " . ($after - $before);
echo "\nDelta per row: " . round(($after - $before)/$rows) . ' bytes
per row';
Expected result:
C:\test\php-5.2-nts-win32-VC6-x86-latest>php -v
PHP 5.2.10-dev (cli) (built: May 19 2009 11:46:39)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
C:\test\php-5.2-nts-win32-VC6-x86-latest>php r:\dbmem.php
Memory Usage (in bytes)
Before: 55216
After: 56080
Delta: 864
Delta per row: 58 bytes per row
Actual result:
--
C:\test\php-5.3-nts-win32-VC9-x86-latest>php -v
PHP 5.3.0RC3-dev (cli) (built: May 19 2009 12:57:00)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
C:\test\php-5.3-nts-win32-VC9-x86-latest>php r:\dbmem.php
Memory Usage (in bytes)
Before: 321328
After: 337384
Delta: 16056
Delta per row: 1070 bytes per row
Would expect the Delta per row to be the similar for PHP 5.3 but this
is
no where near.
--
Edit this bug report at http://bugs.php.net/?id=48343&edit=1
#47712 [Opn]: (mysqlnd) last fetched row may get corrupted after calling mysql_free_result()
ID: 47712
User updated by: ninzya at inbox dot lv
Reported By: ninzya at inbox dot lv
Status: Open
Bug Type: MySQL related
Operating System: Windows XP
-PHP Version: 5.3.0RC1
+PHP Version: 5.3.0RC2
New Comment:
This bug is still present in PHP 5.3.0RC2 and is critical to me.
Previous Comments:
[2009-04-19 12:04:11] ninzya at inbox dot lv
Changed bug summary.
My configuration:
Apache 2.2,
PHP 5.3.0RC1 as module,
Windows XP SP3,
MySQL community server 5.1.33
Bug being hit during high concurrency running apache benchmark: "ab -c
30 -n 1". See previous posts for details.
[2009-04-12 15:08:30] ninzya at inbox dot lv
Please excuse me for the delay. I have been figuring out what's the
cause of this bug and finally i have something to come up with.
The problem is in mysql_free_result function. Not in itself, but it's
behavior has changed. Consider the following example from the PHP manual
on mysql_free_result:
Example #1 A mysql_free_result() example
This code with PHP 5.3.0 with mysqlnd will now fail under high
concurrency, because mysql_free_result will affect $row variable and
allow another threads to use it's zval to store data. I suspect that
mysql_free_result marks the referenced by $row data as 'free' and
another threads pick that zval up and work with it. As soon as you
release result, another thread may corrupt $row variable. Test this
example under high concurrency and you will get different values for
$row['id'] and $row['email']. Run 1 req. test and some of them will
fail to produce correct output.
In my framework i use mysql_free_result before referencing last fetched
row of result set very often, that's why i hit this bug 'randomly'.
I have another example i just tested, this is part of my framework. The
idea is the same - mysql_free_result is being called before actually
using fetched data array.
$con =mysql_pconnect( 'localhost', 'root', '');
mysql_select_db( 'ewe10');
$q =mysql_query( $sql ='SELECT id, title, keywords, descr,
template_id, `title`, `keywords`, `descr`, `template_id`
FROM pages
WHERE node_id =11
AND alt_name =\'welcome\'
LIMIT 0, 1;', $con);
$row =mysql_fetch_assoc( $q);
mysql_free_result( $q);
if( $row['id'] ===null || $row['template_id'] !=8567 || $row['title']
!='My test page' || $row['keywords'] !='asdasd' || $row['descr']
!='asdasd') {
trigger_error( 'FAIL!', E_USER_WARNING);
trigger_error( 'SQL: ' .$sql, E_USER_WARNING);
ob_start();
var_dump( $row);
trigger_error( ob_get_clean(), E_USER_WARNING);
die('NOT OK');
}
die('OK');
SQL for the table:
CREATE TABLE `ewe10`.`pages` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'unique page
id',
`node_id` int(10) unsigned NOT NULL COMMENT 'node id in which this
page is',
`title` varchar(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL
COMMENT 'page title',
`keywords` varchar(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL
COMMENT 'page keywords',
`descr` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL COMMENT
'page description',
`template_id` int(10) unsigned DEFAULT NULL COMMENT 'template this
page is using (if NULL, template was deleted from database and this page
is stored as a backup)',
`type` enum('MAIN','PAGE') CHARACTER SET latin1 NOT NULL DEFAULT
'PAGE' COMMENT 'page type',
`alt_name` varchar(45) CHARACTER SET latin1 NOT NULL COMMENT 'page
alternative name',
`date_add` datetime NOT NULL COMMENT 'when page was added',
PRIMARY KEY (`id`),
UNIQUE KEY `NODE_ID_ALT_NAME` (`node_id`,`alt_name`) USING BTREE,
KEY `FK_pages_templates` (`template_id`),
KEY `TYPE` (`type`),
KEY `FK_pages_map` (`node_id`),
KEY `DATE_ADD` (`date_add`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=FIXED;
the only row in this table is shown on the screenshot i referenced in
previous report.
To address the issue more quickly, i would like to give you a hint -
after calling mysql_free_result there is no possibility to fetch any
more rows, so there's nothing to worry about mysql_fetch_*(), but there
is possibility that the last fetched row may be referenced. This means -
even if mysql_free_result was called, last fetched row must remain
locked in mysqlnd internal zval cache until the variable is
implicitly/explicitly unset.
#48034 [Ver]: PHP crashes when script is 8192 (8KB) bytes long
ID: 48034 User updated by: ninzya at inbox dot lv Reported By: ninzya at inbox dot lv Status: Verified Bug Type: Reproducible crash Operating System: * PHP Version: 5.*, 6CVS (2009-04-21) New Comment: I did everything mentioned in http://bugs.php.net/bugs-generating-backtrace-win32.php and got these results: Thread 250 - System ID 5552 Entry point msvcrt!_endthreadex+3a Create time 21.04.2009 15:20:51 Time spent in user mode 0 Days 0:0:0.656 Time spent in kernel mode 0 Days 0:0:0.921 Function Arg 1 Arg 2 Arg 3 Source php5ts!lex_scan+447c 0550fa34 010f54a0 002f php5ts!zend_register_auto_global+11f Previous Comments: [2009-04-21 15:31:46] lbarn...@php.net It seems related to http://bugs.php.net/bug.php?id=47596 . Not exactly the same problem, though. It seems php_stream_open_for_zend() does not mmap() enough for ZEND_MMAP_AHEAD (PHP_STREAM_OPTION_MMAP_API in plain_wrapper adjusts the mmap length to the filesize, so ignoring ZEND_MMAP_AHEAD), and this may crash when the parser reads ahead of the mmap()ed region. [2009-04-21 11:50:51] ninzya at inbox dot lv PHP is installed as apache module. No fancy filtering, default php/apache installation. All php modules disabled. Bug hits only if file size is 8KB exactly (8192 bytes). PHP 5.2.9 also is affected. By the way, Apache 2.2 is not affected. Seems this is apache 2.0 specific problem. Don't know where to post this issue, here, or in Apache bugtracker. [2009-04-21 11:40:31] j...@php.net Which apache module? Do you have some fancy filtering going on? Does this happen with PHP 5.2.9 ? Do you have any shared extensions loaded? Any Zend extensions like debugger or cache? (disable those and retry) [2009-04-21 11:27:52] ninzya at inbox dot lv http://www.stepanov.lv/pub/bug48034.txt <-- php file contents PHP as module. It crashes by displaying "Apache.exe - Application error" window, saying "The instruction at 0x0085779c referenced memory at 0x061e2000 (this actually varies). The memory could not be read. Click OK to terminate the program." (BTW, what is your formula for bogusness percentage?) [2009-04-21 11:14:48] j...@php.net Also: Exactly how does it crash? Are you sure it crashes? How did you configure PHP in Apache? (READ: Not enough information, 99% bogus..) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/48034 -- Edit this bug report at http://bugs.php.net/?id=48034&edit=1
#48034 [Fbk->Opn]: PHP crashes apache when php code is 8192 (8KB) bytes long.
ID: 48034 User updated by: ninzya at inbox dot lv Reported By: ninzya at inbox dot lv -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Windows XP PHP Version: 5.3.0RC1 New Comment: PHP is installed as apache module. No fancy filtering, default php/apache installation. All php modules disabled. Bug hits only if file size is 8KB exactly (8192 bytes). PHP 5.2.9 also is affected. By the way, Apache 2.2 is not affected. Seems this is apache 2.0 specific problem. Don't know where to post this issue, here, or in Apache bugtracker. Previous Comments: [2009-04-21 11:40:31] j...@php.net Which apache module? Do you have some fancy filtering going on? Does this happen with PHP 5.2.9 ? Do you have any shared extensions loaded? Any Zend extensions like debugger or cache? (disable those and retry) [2009-04-21 11:27:52] ninzya at inbox dot lv http://www.stepanov.lv/pub/bug48034.txt <-- php file contents PHP as module. It crashes by displaying "Apache.exe - Application error" window, saying "The instruction at 0x0085779c referenced memory at 0x061e2000 (this actually varies). The memory could not be read. Click OK to terminate the program." (BTW, what is your formula for bogusness percentage?) [2009-04-21 11:14:48] j...@php.net Also: Exactly how does it crash? Are you sure it crashes? How did you configure PHP in Apache? (READ: Not enough information, 99% bogus..) [2009-04-21 11:13:45] j...@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. (can not reproduce..) [2009-04-21 11:01:44] ninzya at inbox dot lv Still crashes The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/48034 -- Edit this bug report at http://bugs.php.net/?id=48034&edit=1
#48034 [Fbk->Opn]: PHP crashes apache when php code is 8192 (8KB) bytes long.
ID: 48034 User updated by: ninzya at inbox dot lv Reported By: ninzya at inbox dot lv -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Windows XP PHP Version: 5.3.0RC1 New Comment: http://www.stepanov.lv/pub/bug48034.txt <-- php file contents PHP as module. It crashes by displaying "Apache.exe - Application error" window, saying "The instruction at 0x0085779c referenced memory at 0x061e2000 (this actually varies). The memory could not be read. Click OK to terminate the program." (BTW, what is your formula for bogusness percentage?) Previous Comments: [2009-04-21 11:14:48] j...@php.net Also: Exactly how does it crash? Are you sure it crashes? How did you configure PHP in Apache? (READ: Not enough information, 99% bogus..) [2009-04-21 11:13:45] j...@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. (can not reproduce..) [2009-04-21 11:01:44] ninzya at inbox dot lv Still crashes [2009-04-21 10:35:14] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-04-21 10:22:26] ninzya at inbox dot lv Description: Configuration: Apache HTTPd 2.0.61.200 PHP: 5.3.0RC1 OS: Windows XP SP3 PHP crashes apache when php file including php tags + data between them is 8192 bytes (8KB) long. Reproduce code: --- Create file with the following content: or and request it through the browser. Expected result: No crashes Actual result: -- Crash -- Edit this bug report at http://bugs.php.net/?id=48034&edit=1
#48034 [Fbk->Opn]: PHP crashes apache when php code is 8192 (8KB) bytes long.
ID: 48034 User updated by: ninzya at inbox dot lv Reported By: ninzya at inbox dot lv -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Windows XP PHP Version: 5.3.0RC1 New Comment: Still crashes Previous Comments: [2009-04-21 10:35:14] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-04-21 10:22:26] ninzya at inbox dot lv Description: Configuration: Apache HTTPd 2.0.61.200 PHP: 5.3.0RC1 OS: Windows XP SP3 PHP crashes apache when php file including php tags + data between them is 8192 bytes (8KB) long. Reproduce code: --- Create file with the following content: or and request it through the browser. Expected result: No crashes Actual result: -- Crash -- Edit this bug report at http://bugs.php.net/?id=48034&edit=1
#48034 [NEW]: PHP crashes apache when php code is 8192 (8KB) bytes long.
From: ninzya at inbox dot lv Operating system: Windows XP PHP version: 5.3.0RC1 PHP Bug Type: Reproducible crash Bug description: PHP crashes apache when php code is 8192 (8KB) bytes long. Description: Configuration: Apache HTTPd 2.0.61.200 PHP: 5.3.0RC1 OS: Windows XP SP3 PHP crashes apache when php file including php tags + data between them is 8192 bytes (8KB) long. Reproduce code: --- Create file with the following content: or and request it through the browser. Expected result: No crashes Actual result: -- Crash -- Edit bug report at http://bugs.php.net/?id=48034&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48034&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48034&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48034&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48034&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48034&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48034&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48034&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48034&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48034&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48034&r=support Expected behavior: http://bugs.php.net/fix.php?id=48034&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48034&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48034&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48034&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48034&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48034&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48034&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48034&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48034&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48034&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48034&r=mysqlcfg
#47712 [Opn]: (mysqlnd) last fetched row may get corrupted after calling mysql_free_result()
ID: 47712
User updated by: ninzya at inbox dot lv
-Summary: Weird behavior under high load
Reported By: ninzya at inbox dot lv
Status: Open
Bug Type: MySQL related
Operating System: Windows XP
-PHP Version: 5.3.0beta1
+PHP Version: 5.3.0RC1
New Comment:
Changed bug summary.
My configuration:
Apache 2.2,
PHP 5.3.0RC1 as module,
Windows XP SP3,
MySQL community server 5.1.33
Bug being hit during high concurrency running apache benchmark: "ab -c
30 -n 1". See previous posts for details.
Previous Comments:
[2009-04-12 15:08:30] ninzya at inbox dot lv
Please excuse me for the delay. I have been figuring out what's the
cause of this bug and finally i have something to come up with.
The problem is in mysql_free_result function. Not in itself, but it's
behavior has changed. Consider the following example from the PHP manual
on mysql_free_result:
Example #1 A mysql_free_result() example
This code with PHP 5.3.0 with mysqlnd will now fail under high
concurrency, because mysql_free_result will affect $row variable and
allow another threads to use it's zval to store data. I suspect that
mysql_free_result marks the referenced by $row data as 'free' and
another threads pick that zval up and work with it. As soon as you
release result, another thread may corrupt $row variable. Test this
example under high concurrency and you will get different values for
$row['id'] and $row['email']. Run 1 req. test and some of them will
fail to produce correct output.
In my framework i use mysql_free_result before referencing last fetched
row of result set very often, that's why i hit this bug 'randomly'.
I have another example i just tested, this is part of my framework. The
idea is the same - mysql_free_result is being called before actually
using fetched data array.
$con =mysql_pconnect( 'localhost', 'root', '');
mysql_select_db( 'ewe10');
$q =mysql_query( $sql ='SELECT id, title, keywords, descr,
template_id, `title`, `keywords`, `descr`, `template_id`
FROM pages
WHERE node_id =11
AND alt_name =\'welcome\'
LIMIT 0, 1;', $con);
$row =mysql_fetch_assoc( $q);
mysql_free_result( $q);
if( $row['id'] ===null || $row['template_id'] !=8567 || $row['title']
!='My test page' || $row['keywords'] !='asdasd' || $row['descr']
!='asdasd') {
trigger_error( 'FAIL!', E_USER_WARNING);
trigger_error( 'SQL: ' .$sql, E_USER_WARNING);
ob_start();
var_dump( $row);
trigger_error( ob_get_clean(), E_USER_WARNING);
die('NOT OK');
}
die('OK');
SQL for the table:
CREATE TABLE `ewe10`.`pages` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'unique page
id',
`node_id` int(10) unsigned NOT NULL COMMENT 'node id in which this
page is',
`title` varchar(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL
COMMENT 'page title',
`keywords` varchar(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL
COMMENT 'page keywords',
`descr` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL COMMENT
'page description',
`template_id` int(10) unsigned DEFAULT NULL COMMENT 'template this
page is using (if NULL, template was deleted from database and this page
is stored as a backup)',
`type` enum('MAIN','PAGE') CHARACTER SET latin1 NOT NULL DEFAULT
'PAGE' COMMENT 'page type',
`alt_name` varchar(45) CHARACTER SET latin1 NOT NULL COMMENT 'page
alternative name',
`date_add` datetime NOT NULL COMMENT 'when page was added',
PRIMARY KEY (`id`),
UNIQUE KEY `NODE_ID_ALT_NAME` (`node_id`,`alt_name`) USING BTREE,
KEY `FK_pages_templates` (`template_id`),
KEY `TYPE` (`type`),
KEY `FK_pages_map` (`node_id`),
KEY `DATE_ADD` (`date_add`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=FIXED;
the only row in this table is shown on the screenshot i referenced in
previous report.
To address the issue more quickly, i would like to give you a hint -
after calling mysql_free_result there is no possibility to fetch any
more rows, so there's nothing to worry about mysql_fetch_*(), but there
is possibility that the last fetched row may be referenced. This means -
even if mysql_free_result was called, last fetched row must remain
locked in mysqlnd internal zval cache until the variable is
implicitly/explicitly unset.
[2009-04-07 13:21:59] johan...@php.net
Can you give me some more details about your system and the
configuration, please.
I spent some time with load testing diffe
#47712 [Fbk->Opn]: Weird behavior under high load
ID: 47712
User updated by: ninzya at inbox dot lv
Reported By: ninzya at inbox dot lv
-Status: Feedback
+Status: Open
Bug Type: MySQL related
Operating System: Windows XP
PHP Version: 5.3.0beta1
New Comment:
Please excuse me for the delay. I have been figuring out what's the
cause of this bug and finally i have something to come up with.
The problem is in mysql_free_result function. Not in itself, but it's
behavior has changed. Consider the following example from the PHP manual
on mysql_free_result:
Example #1 A mysql_free_result() example
This code with PHP 5.3.0 with mysqlnd will now fail under high
concurrency, because mysql_free_result will affect $row variable and
allow another threads to use it's zval to store data. I suspect that
mysql_free_result marks the referenced by $row data as 'free' and
another threads pick that zval up and work with it. As soon as you
release result, another thread may corrupt $row variable. Test this
example under high concurrency and you will get different values for
$row['id'] and $row['email']. Run 1 req. test and some of them will
fail to produce correct output.
In my framework i use mysql_free_result before referencing last fetched
row of result set very often, that's why i hit this bug 'randomly'.
I have another example i just tested, this is part of my framework. The
idea is the same - mysql_free_result is being called before actually
using fetched data array.
$con =mysql_pconnect( 'localhost', 'root', '');
mysql_select_db( 'ewe10');
$q =mysql_query( $sql ='SELECT id, title, keywords, descr,
template_id, `title`, `keywords`, `descr`, `template_id`
FROM pages
WHERE node_id =11
AND alt_name =\'welcome\'
LIMIT 0, 1;', $con);
$row =mysql_fetch_assoc( $q);
mysql_free_result( $q);
if( $row['id'] ===null || $row['template_id'] !=8567 || $row['title']
!='My test page' || $row['keywords'] !='asdasd' || $row['descr']
!='asdasd') {
trigger_error( 'FAIL!', E_USER_WARNING);
trigger_error( 'SQL: ' .$sql, E_USER_WARNING);
ob_start();
var_dump( $row);
trigger_error( ob_get_clean(), E_USER_WARNING);
die('NOT OK');
}
die('OK');
SQL for the table:
CREATE TABLE `ewe10`.`pages` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'unique page
id',
`node_id` int(10) unsigned NOT NULL COMMENT 'node id in which this
page is',
`title` varchar(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL
COMMENT 'page title',
`keywords` varchar(128) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL
COMMENT 'page keywords',
`descr` text CHARACTER SET utf8 COLLATE utf8_bin NOT NULL COMMENT
'page description',
`template_id` int(10) unsigned DEFAULT NULL COMMENT 'template this
page is using (if NULL, template was deleted from database and this page
is stored as a backup)',
`type` enum('MAIN','PAGE') CHARACTER SET latin1 NOT NULL DEFAULT
'PAGE' COMMENT 'page type',
`alt_name` varchar(45) CHARACTER SET latin1 NOT NULL COMMENT 'page
alternative name',
`date_add` datetime NOT NULL COMMENT 'when page was added',
PRIMARY KEY (`id`),
UNIQUE KEY `NODE_ID_ALT_NAME` (`node_id`,`alt_name`) USING BTREE,
KEY `FK_pages_templates` (`template_id`),
KEY `TYPE` (`type`),
KEY `FK_pages_map` (`node_id`),
KEY `DATE_ADD` (`date_add`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=FIXED;
the only row in this table is shown on the screenshot i referenced in
previous report.
To address the issue more quickly, i would like to give you a hint -
after calling mysql_free_result there is no possibility to fetch any
more rows, so there's nothing to worry about mysql_fetch_*(), but there
is possibility that the last fetched row may be referenced. This means -
even if mysql_free_result was called, last fetched row must remain
locked in mysqlnd internal zval cache until the variable is
implicitly/explicitly unset.
Previous Comments:
[2009-04-07 13:21:59] johan...@php.net
Can you give me some more details about your system and the
configuration, please.
I spent some time with load testing different configurations now using
mysqlnd, pconnects, and PHP's thread-safe mode and wasn't able to
reproduce this issue.
Maybe even try to come up with the shortest script possible showing the
issue ...
[2009-03-25 12:24:45] ninzya at inbox dot lv
I guess i can not switch between libmysql and mysqlnd
#47885 [NEW]: expr in empty() causes parse error
From: ninzya at inbox dot lv Operating system: Any PHP version: 5.3.0RC1 PHP Bug Type: Scripting Engine problem Bug description: expr in empty() causes parse error Description: expr in empty() causes parse error Reproduce code: --- Expected result: No parse errors Actual result: -- Parse error -- Edit bug report at http://bugs.php.net/?id=47885&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47885&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47885&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47885&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47885&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47885&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47885&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47885&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47885&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47885&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47885&r=support Expected behavior: http://bugs.php.net/fix.php?id=47885&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47885&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47885&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47885&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47885&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47885&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47885&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47885&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47885&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47885&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47885&r=mysqlcfg
#47712 [Com]: Weird behavior under high load
ID: 47712 Comment by: ninzya at inbox dot lv Reported By: ninzya at inbox dot lv Status: Open Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 5.3.0beta1 New Comment: I guess i can not switch between libmysql and mysqlnd in PHP 5.3. I have no tools to compile PHP myself with the proper library. If you know where i can find PHP 5.3RC1 with libmysql, i would test it out right away. Previous Comments: [2009-03-25 12:19:04] kak dot serpom dot po dot yaitsam at gmail dot com Try to test this under PHP 5.3 with libmysql driver (not mysqlnd). [2009-03-25 07:28:35] ninzya at inbox dot lv In most cases this bug is being hit when working with mysql, and only during high concurrency. When there is no concurrency, or concurrency is not big enough, bug does not trigger. Also i forgot to mention that PHP is installed as a module. Downloaded QA's PHP 5.3.0RC1 and tested it with both php_mysql and php_mysqli extensions, bug is still present. The page that is being executed during stress test contains 14 SQL queries, 11 of them are SELECT queries. In most cases the 5th to 7th SELECT queries are failing to return proper data using mysql_fetch_assoc(). When the bug triggers, the values of returned array (usually first on first two keys in the array) are being replaced with irrelevant to SELECT result data, contents of those values are either NULL or data that was stored in DB, but used to appear in previous SQL queries. In the example above you can clearly see that the value of key 'id' in array $row is 'SHARED', but shared is the value of another field in another SQL query i used to execute. Probably, mysqlnd is somehow sharing memory between requests, and somehow memory of another request being processed concurrently is being passed to current request. Another assumption may be that the mysqlnd somehow bypasses update of currently used cached zval. Anyway, if this is mysqlnd related, still don't know how to explain warning with empty constant mentioned in previous report. [2009-03-24 18:49:53] kak dot serpom dot po dot yaitsam at gmail dot com I guess the trouble is in MySQL Native Driver (mysqlnd). No? ---- [2009-03-21 22:45:24] ninzya at inbox dot lv Tested under PHP 5.2.9-1, the problem does not exist with that version of PHP. ---- [2009-03-20 12:34:59] ninzya at inbox dot lv And here is the screenshot of the output of MySql query browser after executing SQL query i mentioned above: http://www.stepanov.lv/pub/mysql.jpg The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47712 -- Edit this bug report at http://bugs.php.net/?id=47712&edit=1
#47771 [NEW]: Exception during object construction from arg call calls object's destructor
From: ninzya at inbox dot lv Operating system: Windows XP PHP version: 5.3.0RC1 PHP Bug Type: Scripting Engine problem Bug description: Exception during object construction from arg call calls object's destructor Description: If you create new object and pass to it's constructor argument from function call, that has thrown an exception, the object's constructor is not being called (which is correct behavior), but object's destructor is being called (which is not correct behavior). See reproduce code. Reproduce code: --- getMessage(); } ?> Expected result: Exception: TEST_EXCEPTION Actual result: -- Destr Exception: TEST_EXCEPTION -- Edit bug report at http://bugs.php.net/?id=47771&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47771&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47771&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47771&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47771&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47771&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47771&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47771&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47771&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47771&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47771&r=support Expected behavior: http://bugs.php.net/fix.php?id=47771&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47771&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47771&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47771&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47771&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47771&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47771&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47771&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47771&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47771&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47771&r=mysqlcfg
#47712 [Com]: Weird behavior under high load
ID: 47712
Comment by: ninzya at inbox dot lv
Reported By: ninzya at inbox dot lv
Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.3.0beta1
New Comment:
In most cases this bug is being hit when working with mysql, and only
during high concurrency. When there is no concurrency, or concurrency is
not big enough, bug does not trigger. Also i forgot to mention that PHP
is installed as a module.
Downloaded QA's PHP 5.3.0RC1 and tested it with both php_mysql and
php_mysqli extensions, bug is still present.
The page that is being executed during stress test contains 14 SQL
queries, 11 of them are SELECT queries. In most cases the 5th to 7th
SELECT queries are failing to return proper data using
mysql_fetch_assoc(). When the bug triggers, the values of returned array
(usually first on first two keys in the array) are being replaced with
irrelevant to SELECT result data, contents of those values are either
NULL or data that was stored in DB, but used to appear in previous SQL
queries. In the example above you can clearly see that the value of key
'id' in array $row is 'SHARED', but shared is the value of another field
in another SQL query i used to execute. Probably, mysqlnd is somehow
sharing memory between requests, and somehow memory of another request
being processed concurrently is being passed to current request. Another
assumption may be that the mysqlnd somehow bypasses update of currently
used cached zval.
Anyway, if this is mysqlnd related, still don't know how to explain
warning with empty constant mentioned in previous report.
Previous Comments:
[2009-03-24 18:49:53] kak dot serpom dot po dot yaitsam at gmail dot
com
I guess the trouble is in MySQL Native Driver (mysqlnd). No?
----
[2009-03-21 22:45:24] ninzya at inbox dot lv
Tested under PHP 5.2.9-1, the problem does not exist with that version
of PHP.
----
[2009-03-20 12:34:59] ninzya at inbox dot lv
And here is the screenshot of the output of MySql query browser after
executing SQL query i mentioned above:
http://www.stepanov.lv/pub/mysql.jpg
----
[2009-03-20 12:28:51] ninzya at inbox dot lv
I got a little bit closer to the problem. Here's what happens. See this
script:
// load page
$sql ='SELECT id, ' .implode( ', ', $properties) .'
FROM ' .TAB_PREF .'pages
WHERE node_id =' .$Db->escape( $nodeId, 'UINT').'
AND alt_name =' .$Db->escape( $pageAlt, 'STRING') .'
LIMIT 0, 1;';
if(( $row =$Db->queryFirst( $sql)) ===null)
throw new Exception( 'NOT_FOUND');
if( $row['id'] ===null) {// THIS IS WHERE YOU SHOULD LOOK AT
trigger_error( 'Got NULL!', E_USER_WARNING);
trigger_error( 'SQL: ' .$sql, E_USER_WARNING);
ob_start();
var_dump( $row);
trigger_error( ob_get_clean(), E_USER_WARNING);
die();
}
As you can see, i am testing if $row['id'] is null (this is unexpected
situation when this field becomes null, it's an auto column and at this
step i expect successfully fetched row), and if it is NULL, then i wish
to see the debug info for the contents of $row and overall "what's going
on".
Now here is the error log when this unexpected situation is being
RANDOMLY triggered during stress test:
[20-Mar-2009 14:20:37] PHP Warning: Got NULL! in D:\...\pages.php on
line 93
[20-Mar-2009 14:20:37] PHP Warning: SQL: SELECT id, `title`,
`keywords`, `descr`, `template_id`
FROM pages
WHERE node_id =11
AND alt_name ='welcome'
LIMIT 0, 1; in D:\...\pages.php on line 94
[20-Mar-2009 14:20:37] PHP Warning: array(5) {
["id"]=>
string(6) "SHARED"
["title"]=>
string(12) "My test page"
["keywords"]=>
string(6) "asdasd"
["descr"]=>
string(6) "asdasd"
["template_id"]=>
string(4) "8567"
}
in D:\...\pages.php on line 97
I don't know how to explain this. I guess this is mysqlnd failing this
bad.
[2009-03-20 12:12:15] ninzya at inbox dot lv
Every mentioned error/warning occurs randomly. It is not possible to
trigger these warnings (especially first) during each request, something
related to memory fails i think, or stack is being corrupted or
something.
I was investigating this problem for past day and i found this. Take a
look at the following script:
g
#47712 [Opn]: Weird behavior under high load
ID: 47712
User updated by: ninzya at inbox dot lv
Reported By: ninzya at inbox dot lv
Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.3.0beta1
New Comment:
Tested under PHP 5.2.9-1, the problem does not exist with that version
of PHP.
Previous Comments:
[2009-03-20 12:34:59] ninzya at inbox dot lv
And here is the screenshot of the output of MySql query browser after
executing SQL query i mentioned above:
http://www.stepanov.lv/pub/mysql.jpg
[2009-03-20 12:28:51] ninzya at inbox dot lv
I got a little bit closer to the problem. Here's what happens. See this
script:
// load page
$sql ='SELECT id, ' .implode( ', ', $properties) .'
FROM ' .TAB_PREF .'pages
WHERE node_id =' .$Db->escape( $nodeId, 'UINT').'
AND alt_name =' .$Db->escape( $pageAlt, 'STRING') .'
LIMIT 0, 1;';
if(( $row =$Db->queryFirst( $sql)) ===null)
throw new Exception( 'NOT_FOUND');
if( $row['id'] ===null) {// THIS IS WHERE YOU SHOULD LOOK AT
trigger_error( 'Got NULL!', E_USER_WARNING);
trigger_error( 'SQL: ' .$sql, E_USER_WARNING);
ob_start();
var_dump( $row);
trigger_error( ob_get_clean(), E_USER_WARNING);
die();
}
As you can see, i am testing if $row['id'] is null (this is unexpected
situation when this field becomes null, it's an auto column and at this
step i expect successfully fetched row), and if it is NULL, then i wish
to see the debug info for the contents of $row and overall "what's going
on".
Now here is the error log when this unexpected situation is being
RANDOMLY triggered during stress test:
[20-Mar-2009 14:20:37] PHP Warning: Got NULL! in D:\...\pages.php on
line 93
[20-Mar-2009 14:20:37] PHP Warning: SQL: SELECT id, `title`,
`keywords`, `descr`, `template_id`
FROM pages
WHERE node_id =11
AND alt_name ='welcome'
LIMIT 0, 1; in D:\...\pages.php on line 94
[20-Mar-2009 14:20:37] PHP Warning: array(5) {
["id"]=>
string(6) "SHARED"
["title"]=>
string(12) "My test page"
["keywords"]=>
string(6) "asdasd"
["descr"]=>
string(6) "asdasd"
["template_id"]=>
string(4) "8567"
}
in D:\...\pages.php on line 97
I don't know how to explain this. I guess this is mysqlnd failing this
bad.
[2009-03-20 12:12:15] ninzya at inbox dot lv
Every mentioned error/warning occurs randomly. It is not possible to
trigger these warnings (especially first) during each request, something
related to memory fails i think, or stack is being corrupted or
something.
I was investigating this problem for past day and i found this. Take a
look at the following script:
getMessage();
}
?>
Execution of this script produces:
Destr
Exception: TEST_EXCEPTION
Where it should produce only this part:
Exception: TEST_EXCEPTION
As you can see, destructor is being called, where it shouldn't be. I
will make a temporary work around for this situation and investigate
further, because i guess this is not the problem that has caused first
warning/error message i mentioned above.
[2009-03-19 00:30:38] scott...@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.
We need an actual reproduce script we can use, I took your small script
and ran it under 5.3.0 without issue.
I'm guessing our errors probably all stem from the same issue, if step
1 or 3 happen then 2 and 4 would be expected due to a lack of database
connection.
[2009-03-19 00:02:49] ninzya at inbox dot lv
Description:
My configuration is Windows XP, Apache 2.2.11.0, PHP 5.3.0beta1, i'm
coding a framework and periodically i am performing stress tests with
apache's ab.exe. Once my framework has become quite processive (lotsa
operations involved in request processing), there started to appear
unexpected PHP errors/warning in a PHP error log
#47712 [Opn]: Weird behavior under high load
ID: 47712
User updated by: ninzya at inbox dot lv
Reported By: ninzya at inbox dot lv
Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.3.0beta1
New Comment:
And here is the screenshot of the output of MySql query browser after
executing SQL query i mentioned above:
http://www.stepanov.lv/pub/mysql.jpg
Previous Comments:
[2009-03-20 12:28:51] ninzya at inbox dot lv
I got a little bit closer to the problem. Here's what happens. See this
script:
// load page
$sql ='SELECT id, ' .implode( ', ', $properties) .'
FROM ' .TAB_PREF .'pages
WHERE node_id =' .$Db->escape( $nodeId, 'UINT').'
AND alt_name =' .$Db->escape( $pageAlt, 'STRING') .'
LIMIT 0, 1;';
if(( $row =$Db->queryFirst( $sql)) ===null)
throw new Exception( 'NOT_FOUND');
if( $row['id'] ===null) {// THIS IS WHERE YOU SHOULD LOOK AT
trigger_error( 'Got NULL!', E_USER_WARNING);
trigger_error( 'SQL: ' .$sql, E_USER_WARNING);
ob_start();
var_dump( $row);
trigger_error( ob_get_clean(), E_USER_WARNING);
die();
}
As you can see, i am testing if $row['id'] is null (this is unexpected
situation when this field becomes null, it's an auto column and at this
step i expect successfully fetched row), and if it is NULL, then i wish
to see the debug info for the contents of $row and overall "what's going
on".
Now here is the error log when this unexpected situation is being
RANDOMLY triggered during stress test:
[20-Mar-2009 14:20:37] PHP Warning: Got NULL! in D:\...\pages.php on
line 93
[20-Mar-2009 14:20:37] PHP Warning: SQL: SELECT id, `title`,
`keywords`, `descr`, `template_id`
FROM pages
WHERE node_id =11
AND alt_name ='welcome'
LIMIT 0, 1; in D:\...\pages.php on line 94
[20-Mar-2009 14:20:37] PHP Warning: array(5) {
["id"]=>
string(6) "SHARED"
["title"]=>
string(12) "My test page"
["keywords"]=>
string(6) "asdasd"
["descr"]=>
string(6) "asdasd"
["template_id"]=>
string(4) "8567"
}
in D:\...\pages.php on line 97
I don't know how to explain this. I guess this is mysqlnd failing this
bad.
[2009-03-20 12:12:15] ninzya at inbox dot lv
Every mentioned error/warning occurs randomly. It is not possible to
trigger these warnings (especially first) during each request, something
related to memory fails i think, or stack is being corrupted or
something.
I was investigating this problem for past day and i found this. Take a
look at the following script:
getMessage();
}
?>
Execution of this script produces:
Destr
Exception: TEST_EXCEPTION
Where it should produce only this part:
Exception: TEST_EXCEPTION
As you can see, destructor is being called, where it shouldn't be. I
will make a temporary work around for this situation and investigate
further, because i guess this is not the problem that has caused first
warning/error message i mentioned above.
[2009-03-19 00:30:38] scott...@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.
We need an actual reproduce script we can use, I took your small script
and ran it under 5.3.0 without issue.
I'm guessing our errors probably all stem from the same issue, if step
1 or 3 happen then 2 and 4 would be expected due to a lack of database
connection.
[2009-03-19 00:02:49] ninzya at inbox dot lv
Description:
My configuration is Windows XP, Apache 2.2.11.0, PHP 5.3.0beta1, i'm
coding a framework and periodically i am performing stress tests with
apache's ab.exe. Once my framework has become quite processive (lotsa
operations involved in request processing), there started to appear
unexpected PHP errors/warning in a PHP error log file. For details see
reproduce code.
Reproduce code:
---
I was performing periodical stress testing by running "ab.exe -c 30 -n
1 http:///myframeworkpage.php";. Sometimes
#47712 [Opn]: Weird behavior under high load
ID: 47712
User updated by: ninzya at inbox dot lv
Reported By: ninzya at inbox dot lv
Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.3.0beta1
New Comment:
I got a little bit closer to the problem. Here's what happens. See this
script:
// load page
$sql ='SELECT id, ' .implode( ', ', $properties) .'
FROM ' .TAB_PREF .'pages
WHERE node_id =' .$Db->escape( $nodeId, 'UINT').'
AND alt_name =' .$Db->escape( $pageAlt, 'STRING') .'
LIMIT 0, 1;';
if(( $row =$Db->queryFirst( $sql)) ===null)
throw new Exception( 'NOT_FOUND');
if( $row['id'] ===null) {// THIS IS WHERE YOU SHOULD LOOK AT
trigger_error( 'Got NULL!', E_USER_WARNING);
trigger_error( 'SQL: ' .$sql, E_USER_WARNING);
ob_start();
var_dump( $row);
trigger_error( ob_get_clean(), E_USER_WARNING);
die();
}
As you can see, i am testing if $row['id'] is null (this is unexpected
situation when this field becomes null, it's an auto column and at this
step i expect successfully fetched row), and if it is NULL, then i wish
to see the debug info for the contents of $row and overall "what's going
on".
Now here is the error log when this unexpected situation is being
RANDOMLY triggered during stress test:
[20-Mar-2009 14:20:37] PHP Warning: Got NULL! in D:\...\pages.php on
line 93
[20-Mar-2009 14:20:37] PHP Warning: SQL: SELECT id, `title`,
`keywords`, `descr`, `template_id`
FROM pages
WHERE node_id =11
AND alt_name ='welcome'
LIMIT 0, 1; in D:\...\pages.php on line 94
[20-Mar-2009 14:20:37] PHP Warning: array(5) {
["id"]=>
string(6) "SHARED"
["title"]=>
string(12) "My test page"
["keywords"]=>
string(6) "asdasd"
["descr"]=>
string(6) "asdasd"
["template_id"]=>
string(4) "8567"
}
in D:\...\pages.php on line 97
I don't know how to explain this. I guess this is mysqlnd failing this
bad.
Previous Comments:
[2009-03-20 12:12:15] ninzya at inbox dot lv
Every mentioned error/warning occurs randomly. It is not possible to
trigger these warnings (especially first) during each request, something
related to memory fails i think, or stack is being corrupted or
something.
I was investigating this problem for past day and i found this. Take a
look at the following script:
getMessage();
}
?>
Execution of this script produces:
Destr
Exception: TEST_EXCEPTION
Where it should produce only this part:
Exception: TEST_EXCEPTION
As you can see, destructor is being called, where it shouldn't be. I
will make a temporary work around for this situation and investigate
further, because i guess this is not the problem that has caused first
warning/error message i mentioned above.
[2009-03-19 00:30:38] scott...@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.
We need an actual reproduce script we can use, I took your small script
and ran it under 5.3.0 without issue.
I'm guessing our errors probably all stem from the same issue, if step
1 or 3 happen then 2 and 4 would be expected due to a lack of database
connection.
[2009-03-19 00:02:49] ninzya at inbox dot lv
Description:
My configuration is Windows XP, Apache 2.2.11.0, PHP 5.3.0beta1, i'm
coding a framework and periodically i am performing stress tests with
apache's ab.exe. Once my framework has become quite processive (lotsa
operations involved in request processing), there started to appear
unexpected PHP errors/warning in a PHP error log file. For details see
reproduce code.
Reproduce code:
---
I was performing periodical stress testing by running "ab.exe -c 30 -n
1 http:///myframeworkpage.php";. Sometimes PHP error log had been
empty after 1 req. stress testing, sometimes there were some
errors/warning (from 1 to 10 usually), and these errors were reporting
absurd things happening around. What i noticed, is that under heavy load
PHP manages to implicitly reset s
#47712 [Fbk->Opn]: Weird behavior under high load
ID: 47712
User updated by: ninzya at inbox dot lv
Reported By: ninzya at inbox dot lv
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.3.0beta1
New Comment:
Every mentioned error/warning occurs randomly. It is not possible to
trigger these warnings (especially first) during each request, something
related to memory fails i think, or stack is being corrupted or
something.
I was investigating this problem for past day and i found this. Take a
look at the following script:
getMessage();
}
?>
Execution of this script produces:
Destr
Exception: TEST_EXCEPTION
Where it should produce only this part:
Exception: TEST_EXCEPTION
As you can see, destructor is being called, where it shouldn't be. I
will make a temporary work around for this situation and investigate
further, because i guess this is not the problem that has caused first
warning/error message i mentioned above.
Previous Comments:
[2009-03-19 00:30:38] scott...@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.
We need an actual reproduce script we can use, I took your small script
and ran it under 5.3.0 without issue.
I'm guessing our errors probably all stem from the same issue, if step
1 or 3 happen then 2 and 4 would be expected due to a lack of database
connection.
[2009-03-19 00:02:49] ninzya at inbox dot lv
Description:
My configuration is Windows XP, Apache 2.2.11.0, PHP 5.3.0beta1, i'm
coding a framework and periodically i am performing stress tests with
apache's ab.exe. Once my framework has become quite processive (lotsa
operations involved in request processing), there started to appear
unexpected PHP errors/warning in a PHP error log file. For details see
reproduce code.
Reproduce code:
---
I was performing periodical stress testing by running "ab.exe -c 30 -n
1 http:///myframeworkpage.php";. Sometimes PHP error log had been
empty after 1 req. stress testing, sometimes there were some
errors/warning (from 1 to 10 usually), and these errors were reporting
absurd things happening around. What i noticed, is that under heavy load
PHP manages to implicitly reset some variables to NULL value, or "lose
value", which results in NULL value. Here are some of those errors and
my assumptions for those errors:
1) "PHP Notice: Use of undefined constant - assumed '' in ... on line
25", where line #25 is "$Db->connect( DB_PERS, DB_HOST, DB_PORT,
DB_USER, DB_PASS);". This is definately failure of PHP.
2) "PHP Fatal error: Call to a member function fetch() on a non-object
in ... on line 611" where line #611 is "while( $this->Db->fetch(
$this->query));". Please note that this cycle is contained within
__destruct() method (probably $Db property is being destroyed too soon
when php execution ends, but i assume it was also implicitly reset to
NULL). Definately failure of PHP.
3) "PHP Warning: mysql_pconnect(): Access denied for user
'root'@'localhost' (using password: NO) in ... on line 163" where line
#163 is "$link =mysql_pconnect( $host .':' .$port, $user, $pass,
$clientFlags);" and $pass was never set to null or whatsoever (it
contains string password, always). I could assume here failure of MySQL
server.
4) "PHP Warning: mysql_real_escape_string() expects parameter 2 to be
resource, null given in ... on line 483" where line #483 is "return '\''
.mysql_real_escape_string( $data, $this->link) .'\'';" and i'm 100% sure
$link property is not null at the step, when call to
mysql_real_escape_string is issued. I could assume here failure of MySQL
server, which resulted in resource to become null (which is also
absurd).
5) "PHP Warning: Invalid argument supplied for foreach() in ... on
line 414" where line #414 is "foreach( $patchset as $blockId =>$fill)",
and $patchset is a reference to an array, always. Definately failure of
PHP.
And much more such examples, which all say the same thing - "i got the
null value, what the hell?".
I tried to make some stress testings for such code as:
class X {
public function __construct() {
}
public function __
#47712 [NEW]: Weird behavior under high load
From: ninzya at inbox dot lv
Operating system: Windows XP
PHP version: 5.3.0beta1
PHP Bug Type: Scripting Engine problem
Bug description: Weird behavior under high load
Description:
My configuration is Windows XP, Apache 2.2.11.0, PHP 5.3.0beta1, i'm
coding a framework and periodically i am performing stress tests with
apache's ab.exe. Once my framework has become quite processive (lotsa
operations involved in request processing), there started to appear
unexpected PHP errors/warning in a PHP error log file. For details see
reproduce code.
Reproduce code:
---
I was performing periodical stress testing by running "ab.exe -c 30 -n
1 http:///myframeworkpage.php";. Sometimes PHP error log had been
empty after 1 req. stress testing, sometimes there were some
errors/warning (from 1 to 10 usually), and these errors were reporting
absurd things happening around. What i noticed, is that under heavy load
PHP manages to implicitly reset some variables to NULL value, or "lose
value", which results in NULL value. Here are some of those errors and my
assumptions for those errors:
1) "PHP Notice: Use of undefined constant - assumed '' in ... on line
25", where line #25 is "$Db->connect( DB_PERS, DB_HOST, DB_PORT, DB_USER,
DB_PASS);". This is definately failure of PHP.
2) "PHP Fatal error: Call to a member function fetch() on a non-object in
... on line 611" where line #611 is "while( $this->Db->fetch(
$this->query));". Please note that this cycle is contained within
__destruct() method (probably $Db property is being destroyed too soon when
php execution ends, but i assume it was also implicitly reset to NULL).
Definately failure of PHP.
3) "PHP Warning: mysql_pconnect(): Access denied for user
'root'@'localhost' (using password: NO) in ... on line 163" where line #163
is "$link =mysql_pconnect( $host .':' .$port, $user, $pass, $clientFlags);"
and $pass was never set to null or whatsoever (it contains string password,
always). I could assume here failure of MySQL server.
4) "PHP Warning: mysql_real_escape_string() expects parameter 2 to be
resource, null given in ... on line 483" where line #483 is "return '\''
.mysql_real_escape_string( $data, $this->link) .'\'';" and i'm 100% sure
$link property is not null at the step, when call to
mysql_real_escape_string is issued. I could assume here failure of MySQL
server, which resulted in resource to become null (which is also absurd).
5) "PHP Warning: Invalid argument supplied for foreach() in ... on line
414" where line #414 is "foreach( $patchset as $blockId =>$fill)", and
$patchset is a reference to an array, always. Definately failure of PHP.
And much more such examples, which all say the same thing - "i got the
null value, what the hell?".
I tried to make some stress testings for such code as:
class X {
public function __construct() {
}
public function __destruct() {
}
public function test() {
}
public function Y() {
return new Y( $this);
}
}
class Y {
protected $X;
public function __construct( $X) {
$this->X =$X;
}
public function __destruct() {
$this->X->test();
}
}
$X =new X();
$Y =$X->Y();
$C =$X->Y();
$A =$X->Y();
but it executed successfully with no errors. I tried 30 requests,
everything went fine. But, when i stress-test my framework, PHP *sometimes*
acts weird. So far i failed to find compact reproduction code for this
issue.
Expected result:
I expect to see no warnings described in "Reproduce code" section.
Actual result:
--
PHP under heavy load implicitly resets random variable's value to NULL or
"looses" random variable's value, which results in assignment of NULL value
to that variable.
--
Edit bug report at http://bugs.php.net/?id=47712&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47712&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47712&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47712&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47712&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47712&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47712&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47712&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47712&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47712&r=oldversion
Not developer iss
#47299 [Com]: static lambda function now give parse error
ID: 47299
Comment by: ninzya at inbox dot lv
Reported By: nospam at example dot com
Status: Open
Bug Type: Compile Failure
Operating System: Windows XP SP3
PHP Version: 5.3.0beta1
New Comment:
This functionality has been temporarily dropped from PHP 5.3. Read
http://news.php.net/php.internals/42876 for details.
Previous Comments:
[2009-02-04 10:18:26] nospam at example dot com
Expected result is for it to work.
The parse error is the problem.
[2009-02-04 10:17:14] nospam at example dot com
Description:
The latest 5.3.0beta1 has broken static lambda functions.
Previously this worked on 5.3.0alpha3.
The example below is taken from: http://wiki.php.net/rfc/closures
The rfc page recommends using static to reduce memory overhead.
Reproduce code:
---
class Example {
public function doSomething () {
$x = 4;
$closure = static function ($y) use ($x) {
return $x + $y;
};
return $closure (6);
}
}
Expected result:
Parse error: parse error, expecting `T_PAAMAYIM_NEKUDOTAYIM'
--
Edit this bug report at http://bugs.php.net/?id=47299&edit=1
#47068 [Bgs]: Parse error if global namespace resolution is used
ID: 47068
User updated by: ninzya at inbox dot lv
Reported By: ninzya at inbox dot lv
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.3.0alpha3
New Comment:
A BACKSLASH? FAIL. That's very very BAD idea. The code has become NOT
readable, it looks like HDD DISK DUMP, FILE LIST, CRAP. It would be good
if you change your mind about NS separator before releasing 5.3.0 and
leave "::" as ns sep., or at least pick dot (".") or something, NOT
BACKSLASH.
I suggest you less chatting with your collegues and more chat with
people when deciding about things like namespace separators. I have read
your wiki, where devs suggest ":)", "^^", "**", "%%" as separators -
that's not serious. What's wrong with "::"? Why it was necessary to
change it to something like backslash? Backslash is the last thing u
should implement in this case.
I'm completely not comfortable with use of backslash as separator, and
100% of other people i guess too.
Previous Comments:
[2009-01-11 16:20:27] fel...@php.net
Hi,
the namespace separator was changed to \.
http://docs.php.net/manual/en/language.namespaces.basics.php
----------------
[2009-01-11 15:21:49] ninzya at inbox dot lv
This used to work in PHP 5.3.0alpha2
----------------
[2009-01-11 15:20:54] ninzya at inbox dot lv
Description:
See details below
Reproduce code:
---
index.php:
1:
Expected result:
Passed
Actual result:
--
Parse error: parse error in D:\WebServer\PHP-5.3a3\index.php on line 9
--
Edit this bug report at http://bugs.php.net/?id=47068&edit=1
#47069 [NEW]: Expecting T_VARIABLE in catch block
From: ninzya at inbox dot lv Operating system: Windows XP PHP version: 5.3.0alpha3 PHP Bug Type: Scripting Engine problem Bug description: Expecting T_VARIABLE in catch block Description: See details below. This used to work with PHP 5.3.0alpha2 Reproduce code: --- index.php: 1: Expected result: No parse errors Actual result: -- Parse error: parse error, expecting `T_VARIABLE' in D:\WebServer\PHP-5.3a3\index.php on line 5 -- Edit bug report at http://bugs.php.net/?id=47069&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47069&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47069&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47069&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47069&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47069&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47069&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47069&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47069&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47069&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47069&r=support Expected behavior: http://bugs.php.net/fix.php?id=47069&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47069&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47069&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47069&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47069&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47069&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47069&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47069&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47069&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47069&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47069&r=mysqlcfg
#47068 [Opn]: Parse error if global namespace resolution is used
ID: 47068 User updated by: ninzya at inbox dot lv Reported By: ninzya at inbox dot lv Status: Open Bug Type: Scripting Engine problem Operating System: Windows XP PHP Version: 5.3.0alpha3 New Comment: This used to work in PHP 5.3.0alpha2 Previous Comments: [2009-01-11 15:20:54] ninzya at inbox dot lv Description: See details below Reproduce code: --- index.php: 1: Expected result: Passed Actual result: -- Parse error: parse error in D:\WebServer\PHP-5.3a3\index.php on line 9 -- Edit this bug report at http://bugs.php.net/?id=47068&edit=1
#47068 [NEW]: Parse error if global namespace resolution is used
From: ninzya at inbox dot lv Operating system: Windows XP PHP version: 5.3.0alpha3 PHP Bug Type: Scripting Engine problem Bug description: Parse error if global namespace resolution is used Description: See details below Reproduce code: --- index.php: 1: Expected result: Passed Actual result: -- Parse error: parse error in D:\WebServer\PHP-5.3a3\index.php on line 9 -- Edit bug report at http://bugs.php.net/?id=47068&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47068&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47068&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47068&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47068&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47068&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47068&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47068&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47068&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47068&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47068&r=support Expected behavior: http://bugs.php.net/fix.php?id=47068&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47068&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47068&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47068&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47068&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47068&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47068&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47068&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47068&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47068&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47068&r=mysqlcfg
#46105 [WFx]: mysql_fetch_object calls constructor on object after setting up properties
ID: 46105
User updated by: ninzya at inbox dot lv
Reported By: ninzya at inbox dot lv
Status: Wont fix
Bug Type: MySQL related
Operating System: Windows XP
PHP Version: 5.3.0alpha2
Assigned To: mysql
New Comment:
Well, then you should't fix any bugs at all and have bugtracker,
because some folk's code may rely on those bugs. This is not a valid
behavior, you HAVE TO fix this, and if necessary, warn users about the
change. If this "feature" is not documented, there should be a slight
warning about this.
Previous Comments:
[2008-11-03 15:48:53] [EMAIL PROTECTED]
Yes, the behavior can be considered wrong, unfortunately we can't
change it as code might rely on that order, like doing work with the
data in the constructor ...
----
[2008-09-17 12:35:52] ninzya at inbox dot lv
Description:
when using custom object return through mysql_fetch_object, function
allocates specified in second parameter object, sets up all properties
and then calls constructor. I think this is wrong. Newly instantiated
object's constructor must be called before any other operation on the
object is performed.
Reproduce code:
---
/**
* Object class
*
*/
class Object {
/**
* Array of properties
*
* @var array
*/
protected $_props =array();
/**
* Construct object
*
* @param array $props
*/
public function __construct( $props =array()) {
var_dump( 'constr');
$this->_props =$props;
}
/**
* Magic method override
*
* @param string $key
*/
public function __isset( $key) {
var_dump( 'isset');
return array_key_exists( $key, $this->_props);
}
/**
* Magic method override
*
* @param string $key
* @return mixed/null
*/
public function __get( $key) {
var_dump( 'get');
if( !array_key_exists( $key, $this->_props))
return null;// entry does not exist
// return obtained value
return $this->_props[ $key];
}
/**
* Magic method override
*
* @param string $key
* @param mixed $value
*/
public function __set( $key, $value) {
var_dump( 'set');
$this->_props[ $key] =$value;
}
/**
* Magic method override
*
* @param string $key
*/
public function __unset( $key) {
var_dump( 'unset');
unset( $this->_props[ $key]);
}
/**
* Get associated array
*
* @return array
*/
public function __invoke() {
var_dump( 'invoke');
return $this->_props;
}
/**
* Get object name
*
* @return string
*/
public function __toString() {
return __CLASS__;
}
}
..
mysql_fetch_object( $result, 'Object');
Expected result:
string(6) "constr"
string(3) "set"
string(3) "set"
string(3) "set"
string(3) "set"
Actual result:
--
string(3) "set"
string(3) "set"
string(3) "set"
string(3) "set"
string(6) "constr"
--
Edit this bug report at http://bugs.php.net/?id=46105&edit=1
#46182 [NEW]: mysql_connection_reused( $link) function
From: ninzya at inbox dot lv
Operating system: Any
PHP version: 5.3.0alpha2
PHP Bug Type: Feature/Change Request
Bug description: mysql_connection_reused( $link) function
Description:
It would be great if we had mysql_connection_reused( $link) function,
which returned boolean value if just established connection was
reused or no.
Reproduce code:
---
$link =mysql_pconnect( $host .':' .$port, $user, $pass);
if( !mysql_connection_reused( $link)) {
mysql_query( 'SET NAMES utf8;');
mysql_query( 'USE mydb;');
} else {
// connection was reused, don't do any initialization queries,
// because they were already made by another request
}
Expected result:
This would allow to optimize database load on heavy loaded servers.
Actual result:
--
Not implemented
--
Edit bug report at http://bugs.php.net/?id=46182&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46182&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46182&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46182&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=46182&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=46182&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=46182&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=46182&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=46182&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=46182&r=support
Expected behavior:http://bugs.php.net/fix.php?id=46182&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46182&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46182&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=46182&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46182&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=46182&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=46182&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=46182&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=46182&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=46182&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=46182&r=mysqlcfg
#46105 [NEW]: mysql_fetch_object calls constructor on object after setting up properties
From: ninzya at inbox dot lv
Operating system: Windows XP
PHP version: 5.3.0alpha2
PHP Bug Type: MySQL related
Bug description: mysql_fetch_object calls constructor on object after setting
up properties
Description:
when using custom object return through mysql_fetch_object, function
allocates specified in second parameter object, sets up all properties and
then calls constructor. I think this is wrong. Newly instantiated object's
constructor must be called before any other operation on the object is
performed.
Reproduce code:
---
/**
* Object class
*
*/
class Object {
/**
* Array of properties
*
* @var array
*/
protected $_props =array();
/**
* Construct object
*
* @param array $props
*/
public function __construct( $props =array()) {
var_dump( 'constr');
$this->_props =$props;
}
/**
* Magic method override
*
* @param string $key
*/
public function __isset( $key) {
var_dump( 'isset');
return array_key_exists( $key, $this->_props);
}
/**
* Magic method override
*
* @param string $key
* @return mixed/null
*/
public function __get( $key) {
var_dump( 'get');
if( !array_key_exists( $key, $this->_props))
return null;// entry does not exist
// return obtained value
return $this->_props[ $key];
}
/**
* Magic method override
*
* @param string $key
* @param mixed $value
*/
public function __set( $key, $value) {
var_dump( 'set');
$this->_props[ $key] =$value;
}
/**
* Magic method override
*
* @param string $key
*/
public function __unset( $key) {
var_dump( 'unset');
unset( $this->_props[ $key]);
}
/**
* Get associated array
*
* @return array
*/
public function __invoke() {
var_dump( 'invoke');
return $this->_props;
}
/**
* Get object name
*
* @return string
*/
public function __toString() {
return __CLASS__;
}
}
..
mysql_fetch_object( $result, 'Object');
Expected result:
string(6) "constr"
string(3) "set"
string(3) "set"
string(3) "set"
string(3) "set"
Actual result:
--
string(3) "set"
string(3) "set"
string(3) "set"
string(3) "set"
string(6) "constr"
--
Edit bug report at http://bugs.php.net/?id=46105&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46105&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46105&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46105&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=46105&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=46105&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=46105&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=46105&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=46105&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=46105&r=support
Expected behavior:http://bugs.php.net/fix.php?id=46105&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46105&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46105&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=46105&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46105&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=46105&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=46105&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=46105&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=46105&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=46105&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=46105&r=mysqlcfg
