Req #60655 [PATCH]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1 ID: 60655 Patch added by: larue...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: rand_hash_resize.patch Revision: 1325750958 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=rand_hash_resize.patch&revision=1325750958 Previous Comments: [2012-01-05 05:04:53] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739893 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739893 [2012-01-05 05:03:29] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739809 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739809 [2012-01-05 05:02:16] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739736 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739736 [2012-01-05 04:17:03] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325737023 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325737023 [2012-01-05 04:08:22] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325736502 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325736502 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=60655 -- Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1
Bug #60601 [Com]: ReflectionMethod::InvokeArgs not work normally in function
Edit report at https://bugs.php.net/bug.php?id=60601&edit=1
ID: 60601
Comment by: joelp at email dot cz
Reported by:joelp at email dot cz
Summary:ReflectionMethod::InvokeArgs not work normally in
function
Status: Open
Type: Bug
Package:Arrays related
Operating System: Linux
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
Yes this works. But that not solved, why this code work correctly outside of
the function and not works inside.
Previous Comments:
[2011-12-29 01:11:31] hanskrentel at yahoo dot de
This is not a bug but a problem how you pass the arguments.
As the warning says, you need to give a variable, but you give values:
$variables = array ("one62","two62");
Instead give variables:
$var1 = "one62";
$var2 = "two62";
$variables = array (&$var1, &$var2);
Hope this is helpful.
[2011-12-23 13:56:49] joelp at email dot cz
Description:
If I try to use ReflectionMethod::InvokeArgs after using function array_unshift
inside of user function, this return me this:
Warning: Parameter 2 to mysqli_stmt::bind_param() expected to be a reference,
value given in /www/transaction_test.php on line 132
Fatal error: Uncaught exception 'ReflectionException' with message 'Invocation
of method mysqli_stmt::bind_param() failed' in /www/transaction_test.php:132
Stack trace: #0 /www/transaction_test.php(132):
ReflectionMethod->invokeArgs(Object(mysqli_stmt), Array) #1
/www/transaction_test.php(146): test_case_function('INSERT INTO `te...', Array,
'ss') #2 {main} thrown in /www/transaction_test.php on line 132
If I try run it out of user function. Everything is OK.
Test script:
---
function test_case_function ($sql,$variables,$vars) {
$mysqli = new mysqli(db_server, db_user_name, db_user_passwd, db_name);
$mysqli->query("SET NAMES 'utf8'") or die ('Could not set Charset');
$mysqli->autocommit(FALSE);
array_unshift($variables,$vars);
if ($stm=$mysqli->prepare($sql)) {
$method= new ReflectionMethod('mysqli_stmt','bind_param');
$method->invokeArgs($stm,$variables);
}
$stm->execute();
printf("%d Row inserted\n", $stm->affected_rows);
$mysqli->commit();
$stm->close();
$mysqli->close();
}
$sql = "INSERT INTO `test_table` (`time`,`one`,`two`) VALUES (NOW(),?,?);";
$vars = 'ss';
$variables = array ("one62","two62");
test_case_function($sql,$variables,$vars);
Expected result:
Script print "1 Row inserted "
Actual result:
--
Warning: Parameter 2 to mysqli_stmt::bind_param() expected to be a reference,
value given in /www/transaction_test.php on line 132
Fatal error: Uncaught exception 'ReflectionException' with message 'Invocation
of method mysqli_stmt::bind_param() failed' in /www/transaction_test.php:132
Stack trace: #0 /www/transaction_test.php(132):
ReflectionMethod->invokeArgs(Object(mysqli_stmt), Array) #1
/www/transaction_test.php(146): test_case_function('INSERT INTO `te...', Array,
'ss') #2 {main} thrown in /www/transaction_test.php on line 132
--
Edit this bug report at https://bugs.php.net/bug.php?id=60601&edit=1
Bug #48447 [Com]: After FORK Interbase doesn't work
Edit report at https://bugs.php.net/bug.php?id=48447&edit=1
ID: 48447
Comment by: steffen at kernelguy dot dk
Reported by:jjoss at mail dot ru
Summary:After FORK Interbase doesn't work
Status: Assigned
Type: Bug
Package:InterBase related
Operating System: Ubuntu Linux 2.6.18
PHP Version:5.2.9
Assigned To:mariuz
Block user comment: N
Private report: N
New Comment:
If I only call ibase_connect from the child code it works.
What I'm doing:
>From a php script run by apache I exec a spawn.php script which again calls
>pcntl_fork.
I can access the database before the fork, which is successfull.
Then after the fork I get the error below when I try to start a new
transaction, even after creating a new connection with ibase_connect:
"WARNING ibase_trans(): Unable to complete network request to host "localhost".
Error writing data to the connection."
If I dont access the database before the fork, then the child code works. So
that's my workaround for now.
Previous Comments:
[2009-06-01 17:02:33] jjoss at mail dot ru
Description:
After using the pcntl_fork() function both parent and child are not able to
connect to the database.
Reproduce code:
---
obj->Log->debug('ReportGeneric before fork ('.getmygid().')');
$pid = pcntl_fork();
if ($pid == -1) die('fork error');
if ($pid)
{
// PARENT
dbGet('parent');
posix_kill(getmypid(), 9);
}
else
{
// CHILD
dbGet('child');
posix_kill(getmypid(), 9);
}
?>
Expected result:
$ php fork_interbase.php
grandpa: 27850
grandpa:
Array
(
[0] => 1
)
child: 27852
child:
Array
(
[0] => 1
)
parent: 27850
parent:
Array
(
[0] => 1
)
Killed
$
Actual result:
--
$ php fork_interbase.php
grandpa: 27850
grandpa:
Array
(
[0] => 1
)
child: 27852
parent: 27850
parent: row empty - Unable to complete network request to host "localhost".
Error writing data to the connection. Broken pipe
child: query error - Unable to complete network request to host "localhost".
Error reading data from the connection.
Killed
$
--
Edit this bug report at https://bugs.php.net/bug.php?id=48447&edit=1
Bug #60627 [Com]: httpd.worker segfault on startup with php_value
Edit report at https://bugs.php.net/bug.php?id=60627&edit=1 ID: 60627 Comment by: public at wernig dot net Reported by:fedora at famillecollet dot com Summary:httpd.worker segfault on startup with php_value Status: Re-Opened Type: Bug Package:Apache2 related Operating System: GNU/Linux (Fedora 16) PHP Version:5.4SVN-2011-12-30 (snap) Assigned To:laruence Block user comment: N Private report: N New Comment: Is there any further information that I can provide to help track this down? Previous Comments: [2012-01-05 02:45:29] larue...@php.net seems there is something wrong in solaris .. re-open [2012-01-04 19:15:45] fedora at famillecollet dot com Thanks for the patch. Works for me, httpd.worker + php 5.4.0RC5-dev ZTS 201201041830. (solaris bug seems another issue) [2012-01-04 18:50:34] public at wernig dot net OK, managed to get gdb into the zone: # gdb /usr/local/apache2/bin/httpd GNU gdb 6.8 ... This GDB was configured as "i386-pc-solaris2.11"... (gdb) run -X Starting program: /usr/local/apache2/bin/httpd -X warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 0074 warning: Lowest section in /lib/libdl.so.1 is .dynamic at 0074 warning: Lowest section in /lib/librt.so.1 is .dynamic at 0074 warning: Lowest section in /lib/libthread.so.1 is .dynamic at 0074 Program received signal SIGSEGV, Segmentation fault. 0xfe8956bb in mutex_lock_impl () from /lib/libc.so.1 (gdb) bt #0 0xfe8956bb in mutex_lock_impl () from /lib/libc.so.1 #1 0xfe895938 in pthread_mutex_lock () from /lib/libc.so.1 #2 0xfe14088d in tsrm_mutex_lock (mutexp=0x0) at /opt/build.d/php-5/tmp/php5.4-201201041430/TSRM/TSRM.c:391 #3 0xfe140e85 in ts_resource_ex (id=0, th_id=0x0) at /opt/build.d/php-5/tmp/php5.4-201201041430/TSRM/TSRM.c:391 #4 0xfe1c3538 in _zend_hash_add_or_update (ht=0x8267cc8, arKey=0x8267cf0 "open_basedir", nKeyLength=13, pData=0x8047894, nDataSize=12, pDest=0x0, flag=1) at /opt/build.d/php-5/tmp/php5.4-201201041430/Zend/zend_hash.c:617 #5 0xfe280bbe in real_value_hnd (dummy=0x8267cc8, name=0x8267cf0 "open_basedir", value=0x8267d00 "/data/web/markus:/usr/local/apache2/php/lib/php", status=4) at /opt/build.d/php-5/tmp/php5.4-201201041430/sapi/apache2handler/apache_config.c:73 #6 0x0808fa2a in invoke_cmd (cmd=0xfe560cf0, parms=0x8047c70, mconfig=0x8267cc8, args=0x81a1656 "") at config.c:316 #7 0x08267cc8 in ?? () #8 0x08267cf0 in ?? () #9 0x08267d00 in ?? () #10 0x0004 in ?? () #11 0x in ?? () [2012-01-04 18:19:22] public at wernig dot net Yes, the build is always from a pristine source directory (scripted). I'm sorry to admit that I do not know how to produce a meaningful backtrace. I have the core file and gdb installed on the machine, yet not in the environment (solaris zone) where apache runs. Could you give a pointer on how to produce a helpful backtrace? [2012-01-04 16:05:09] larue...@php.net can you give me the backtrace? and btw, did you build that from a pure environ(make clean, make install). 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=60627 -- Edit this bug report at https://bugs.php.net/bug.php?id=60627&edit=1
Bug #60627 [ReO]: httpd.worker segfault on startup with php_value
Edit report at https://bugs.php.net/bug.php?id=60627&edit=1 ID: 60627 Updated by: larue...@php.net Reported by:fedora at famillecollet dot com Summary:httpd.worker segfault on startup with php_value Status: Re-Opened Type: Bug Package:Apache2 related Operating System: GNU/Linux (Fedora 16) PHP Version:5.4SVN-2011-12-30 (snap) Assigned To:laruence Block user comment: N Private report: N New Comment: sorry, kind of buzy these days, I will look at this in 1 or 2 days, thanks Previous Comments: [2012-01-05 09:14:19] public at wernig dot net Is there any further information that I can provide to help track this down? [2012-01-05 02:45:29] larue...@php.net seems there is something wrong in solaris .. re-open [2012-01-04 19:15:45] fedora at famillecollet dot com Thanks for the patch. Works for me, httpd.worker + php 5.4.0RC5-dev ZTS 201201041830. (solaris bug seems another issue) [2012-01-04 18:50:34] public at wernig dot net OK, managed to get gdb into the zone: # gdb /usr/local/apache2/bin/httpd GNU gdb 6.8 ... This GDB was configured as "i386-pc-solaris2.11"... (gdb) run -X Starting program: /usr/local/apache2/bin/httpd -X warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 0074 warning: Lowest section in /lib/libdl.so.1 is .dynamic at 0074 warning: Lowest section in /lib/librt.so.1 is .dynamic at 0074 warning: Lowest section in /lib/libthread.so.1 is .dynamic at 0074 Program received signal SIGSEGV, Segmentation fault. 0xfe8956bb in mutex_lock_impl () from /lib/libc.so.1 (gdb) bt #0 0xfe8956bb in mutex_lock_impl () from /lib/libc.so.1 #1 0xfe895938 in pthread_mutex_lock () from /lib/libc.so.1 #2 0xfe14088d in tsrm_mutex_lock (mutexp=0x0) at /opt/build.d/php-5/tmp/php5.4-201201041430/TSRM/TSRM.c:391 #3 0xfe140e85 in ts_resource_ex (id=0, th_id=0x0) at /opt/build.d/php-5/tmp/php5.4-201201041430/TSRM/TSRM.c:391 #4 0xfe1c3538 in _zend_hash_add_or_update (ht=0x8267cc8, arKey=0x8267cf0 "open_basedir", nKeyLength=13, pData=0x8047894, nDataSize=12, pDest=0x0, flag=1) at /opt/build.d/php-5/tmp/php5.4-201201041430/Zend/zend_hash.c:617 #5 0xfe280bbe in real_value_hnd (dummy=0x8267cc8, name=0x8267cf0 "open_basedir", value=0x8267d00 "/data/web/markus:/usr/local/apache2/php/lib/php", status=4) at /opt/build.d/php-5/tmp/php5.4-201201041430/sapi/apache2handler/apache_config.c:73 #6 0x0808fa2a in invoke_cmd (cmd=0xfe560cf0, parms=0x8047c70, mconfig=0x8267cc8, args=0x81a1656 "") at config.c:316 #7 0x08267cc8 in ?? () #8 0x08267cf0 in ?? () #9 0x08267d00 in ?? () #10 0x0004 in ?? () #11 0x in ?? () [2012-01-04 18:19:22] public at wernig dot net Yes, the build is always from a pristine source directory (scripted). I'm sorry to admit that I do not know how to produce a meaningful backtrace. I have the core file and gdb installed on the machine, yet not in the environment (solaris zone) where apache runs. Could you give a pointer on how to produce a helpful backtrace? 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=60627 -- Edit this bug report at https://bugs.php.net/bug.php?id=60627&edit=1
Bug #60627 [ReO->Fbk]: httpd.worker segfault on startup with php_value
Edit report at https://bugs.php.net/bug.php?id=60627&edit=1 ID: 60627 Updated by: larue...@php.net Reported by:fedora at famillecollet dot com Summary:httpd.worker segfault on startup with php_value -Status: Re-Opened +Status: Feedback Type: Bug Package:Apache2 related Operating System: GNU/Linux (Fedora 16) PHP Version:5.4SVN-2011-12-30 (snap) Assigned To:laruence Block user comment: N Private report: N New Comment: @public are you sure your backtrace is simple copy&paste? there is two strange lines: #2 0xfe14088d in tsrm_mutex_lock (mutexp=0x0) at /opt/build.d/php-5/tmp/php5.4- 201201041430/TSRM/TSRM.c:391 #3 0xfe140e85 in ts_resource_ex (id=0, th_id=0x0) at /opt/build.d/php- 5/tmp/php5.4-201201041430/TSRM/TSRM.c:391 both of them are in line 391. Previous Comments: [2012-01-05 09:19:03] larue...@php.net sorry, kind of buzy these days, I will look at this in 1 or 2 days, thanks [2012-01-05 09:14:19] public at wernig dot net Is there any further information that I can provide to help track this down? [2012-01-05 02:45:29] larue...@php.net seems there is something wrong in solaris .. re-open [2012-01-04 19:15:45] fedora at famillecollet dot com Thanks for the patch. Works for me, httpd.worker + php 5.4.0RC5-dev ZTS 201201041830. (solaris bug seems another issue) [2012-01-04 18:50:34] public at wernig dot net OK, managed to get gdb into the zone: # gdb /usr/local/apache2/bin/httpd GNU gdb 6.8 ... This GDB was configured as "i386-pc-solaris2.11"... (gdb) run -X Starting program: /usr/local/apache2/bin/httpd -X warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 0074 warning: Lowest section in /lib/libdl.so.1 is .dynamic at 0074 warning: Lowest section in /lib/librt.so.1 is .dynamic at 0074 warning: Lowest section in /lib/libthread.so.1 is .dynamic at 0074 Program received signal SIGSEGV, Segmentation fault. 0xfe8956bb in mutex_lock_impl () from /lib/libc.so.1 (gdb) bt #0 0xfe8956bb in mutex_lock_impl () from /lib/libc.so.1 #1 0xfe895938 in pthread_mutex_lock () from /lib/libc.so.1 #2 0xfe14088d in tsrm_mutex_lock (mutexp=0x0) at /opt/build.d/php-5/tmp/php5.4-201201041430/TSRM/TSRM.c:391 #3 0xfe140e85 in ts_resource_ex (id=0, th_id=0x0) at /opt/build.d/php-5/tmp/php5.4-201201041430/TSRM/TSRM.c:391 #4 0xfe1c3538 in _zend_hash_add_or_update (ht=0x8267cc8, arKey=0x8267cf0 "open_basedir", nKeyLength=13, pData=0x8047894, nDataSize=12, pDest=0x0, flag=1) at /opt/build.d/php-5/tmp/php5.4-201201041430/Zend/zend_hash.c:617 #5 0xfe280bbe in real_value_hnd (dummy=0x8267cc8, name=0x8267cf0 "open_basedir", value=0x8267d00 "/data/web/markus:/usr/local/apache2/php/lib/php", status=4) at /opt/build.d/php-5/tmp/php5.4-201201041430/sapi/apache2handler/apache_config.c:73 #6 0x0808fa2a in invoke_cmd (cmd=0xfe560cf0, parms=0x8047c70, mconfig=0x8267cc8, args=0x81a1656 "") at config.c:316 #7 0x08267cc8 in ?? () #8 0x08267cf0 in ?? () #9 0x08267d00 in ?? () #10 0x0004 in ?? () #11 0x in ?? () 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=60627 -- Edit this bug report at https://bugs.php.net/bug.php?id=60627&edit=1
Req #60655 [Opn]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1 ID: 60655 Updated by: ses...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: Your patch does not fix the problem. It will make the first X hashtable grow operations random. But the moment you already inserte 65536 entries the HashTable is now big enough to launch the attack. Maybe your test script already breaks your patch the moment you try to insert 2^17 entries. Otherwise the attack script might need some tweaking. Anyway, your patch will not solve the problem. Previous Comments: [2012-01-05 08:09:18] larue...@php.net The following patch has been added/updated: Patch Name: rand_hash_resize.patch Revision: 1325750958 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=rand_hash_resize.patch&revision=1325750958 [2012-01-05 05:04:53] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739893 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739893 [2012-01-05 05:03:29] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739809 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739809 [2012-01-05 05:02:16] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739736 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739736 [2012-01-05 04:17:03] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325737023 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325737023 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=60655 -- Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1
Req #60655 [Opn]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1 ID: 60655 Updated by: larue...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: sorry, didn't get your point? the collision can not be predicatible any more, why this patch doesn't solve the problem? Previous Comments: [2012-01-05 11:24:44] ses...@php.net Your patch does not fix the problem. It will make the first X hashtable grow operations random. But the moment you already inserte 65536 entries the HashTable is now big enough to launch the attack. Maybe your test script already breaks your patch the moment you try to insert 2^17 entries. Otherwise the attack script might need some tweaking. Anyway, your patch will not solve the problem. [2012-01-05 08:09:18] larue...@php.net The following patch has been added/updated: Patch Name: rand_hash_resize.patch Revision: 1325750958 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=rand_hash_resize.patch&revision=1325750958 [2012-01-05 05:04:53] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739893 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739893 [2012-01-05 05:03:29] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739809 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739809 [2012-01-05 05:02:16] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739736 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739736 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=60655 -- Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1
Req #60655 [Opn]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1 ID: 60655 Updated by: ses...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: You are mistaken to believe that randomizing the TableSize will stop predictable collisions: This is only true if you try to exploit the problem with numerical indicies. The moment you use alpha numerical keys and produce collisions in the DJB hashing function the table size does not matter anymore, because the return value of the hash function is the same. Previous Comments: [2012-01-05 11:29:15] larue...@php.net sorry, didn't get your point? the collision can not be predicatible any more, why this patch doesn't solve the problem? [2012-01-05 11:24:44] ses...@php.net Your patch does not fix the problem. It will make the first X hashtable grow operations random. But the moment you already inserte 65536 entries the HashTable is now big enough to launch the attack. Maybe your test script already breaks your patch the moment you try to insert 2^17 entries. Otherwise the attack script might need some tweaking. Anyway, your patch will not solve the problem. [2012-01-05 08:09:18] larue...@php.net The following patch has been added/updated: Patch Name: rand_hash_resize.patch Revision: 1325750958 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=rand_hash_resize.patch&revision=1325750958 [2012-01-05 05:04:53] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739893 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739893 [2012-01-05 05:03:29] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739809 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739809 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=60655 -- Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1
[PHP-BUG] Bug #60664 [NEW]: mb_ereg leads to script executing timeout
From:
Operating system: Debian
PHP version: 5.3.8
Package: mbstring related
Bug Type: Bug
Bug description:mb_ereg leads to script executing timeout
Description:
I tried this with php 5.3.8 and 5.3.2 with the same results.
Test script:
---
Welcome to our Exclusive Online Store
If you are a registered member, please log in here.
Magento is the leading hub for exclusive specialty
items for all your home, apparel and entertainment needs!
';
$content = mbereg_replace("\r\n", ' ', $content);
$content = mbereg_replace("\n", ' ', $content);
var_dump($content);
var_dump(mb_ereg('(.*?\s){100}', $content, $_m));
var_dump($_m);
Expected result:
$content should be truncated to string that contains ~100 words.
Actual result:
--
Script executing hangs.
--
Edit bug report at https://bugs.php.net/bug.php?id=60664&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60664&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60664&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60664&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60664&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60664&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60664&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60664&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60664&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60664&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60664&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60664&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60664&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60664&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60664&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60664&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60664&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60664&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60664&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60664&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60664&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60664&r=mysqlcfg
Req #60655 [Opn]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1 ID: 60655 Updated by: larue...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: yes, the hash value of string index is the same, but the index = hash_value % nTableSize, we don't use the hash value as index directly, didn't I misunderstand you? Previous Comments: [2012-01-05 11:53:37] ses...@php.net You are mistaken to believe that randomizing the TableSize will stop predictable collisions: This is only true if you try to exploit the problem with numerical indicies. The moment you use alpha numerical keys and produce collisions in the DJB hashing function the table size does not matter anymore, because the return value of the hash function is the same. [2012-01-05 11:29:15] larue...@php.net sorry, didn't get your point? the collision can not be predicatible any more, why this patch doesn't solve the problem? [2012-01-05 11:24:44] ses...@php.net Your patch does not fix the problem. It will make the first X hashtable grow operations random. But the moment you already inserte 65536 entries the HashTable is now big enough to launch the attack. Maybe your test script already breaks your patch the moment you try to insert 2^17 entries. Otherwise the attack script might need some tweaking. Anyway, your patch will not solve the problem. [2012-01-05 08:09:18] larue...@php.net The following patch has been added/updated: Patch Name: rand_hash_resize.patch Revision: 1325750958 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=rand_hash_resize.patch&revision=1325750958 [2012-01-05 05:04:53] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739893 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739893 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=60655 -- Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1
Req #60655 [Opn]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1 ID: 60655 Updated by: larue...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: oh, I got you, thanks. Previous Comments: [2012-01-05 14:04:50] larue...@php.net yes, the hash value of string index is the same, but the index = hash_value % nTableSize, we don't use the hash value as index directly, didn't I misunderstand you? [2012-01-05 11:53:37] ses...@php.net You are mistaken to believe that randomizing the TableSize will stop predictable collisions: This is only true if you try to exploit the problem with numerical indicies. The moment you use alpha numerical keys and produce collisions in the DJB hashing function the table size does not matter anymore, because the return value of the hash function is the same. [2012-01-05 11:29:15] larue...@php.net sorry, didn't get your point? the collision can not be predicatible any more, why this patch doesn't solve the problem? [2012-01-05 11:24:44] ses...@php.net Your patch does not fix the problem. It will make the first X hashtable grow operations random. But the moment you already inserte 65536 entries the HashTable is now big enough to launch the attack. Maybe your test script already breaks your patch the moment you try to insert 2^17 entries. Otherwise the attack script might need some tweaking. Anyway, your patch will not solve the problem. [2012-01-05 08:09:18] larue...@php.net The following patch has been added/updated: Patch Name: rand_hash_resize.patch Revision: 1325750958 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=rand_hash_resize.patch&revision=1325750958 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=60655 -- Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1
Req #60655 [Opn]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1 ID: 60655 Updated by: larue...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: I got you point, and agree in theory, yes, the string hash value could be the same, does anyone have a method to compute it in real? yes I really doubt that if we can find so many string keys with the same hash value to be able launch a attach, and won't reach the max post size Previous Comments: [2012-01-05 14:05:52] larue...@php.net oh, I got you, thanks. [2012-01-05 14:04:50] larue...@php.net yes, the hash value of string index is the same, but the index = hash_value % nTableSize, we don't use the hash value as index directly, didn't I misunderstand you? [2012-01-05 11:53:37] ses...@php.net You are mistaken to believe that randomizing the TableSize will stop predictable collisions: This is only true if you try to exploit the problem with numerical indicies. The moment you use alpha numerical keys and produce collisions in the DJB hashing function the table size does not matter anymore, because the return value of the hash function is the same. [2012-01-05 11:29:15] larue...@php.net sorry, didn't get your point? the collision can not be predicatible any more, why this patch doesn't solve the problem? [2012-01-05 11:24:44] ses...@php.net Your patch does not fix the problem. It will make the first X hashtable grow operations random. But the moment you already inserte 65536 entries the HashTable is now big enough to launch the attack. Maybe your test script already breaks your patch the moment you try to insert 2^17 entries. Otherwise the attack script might need some tweaking. Anyway, your patch will not solve the problem. 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=60655 -- Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1
Req #60655 [Opn]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1 ID: 60655 Updated by: ses...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: It is not "a theory", The whole disclosure from n-runs was about colliding the DJB hash function with alpha numerical keys. Previous Comments: [2012-01-05 14:14:08] larue...@php.net I got you point, and agree in theory, yes, the string hash value could be the same, does anyone have a method to compute it in real? yes I really doubt that if we can find so many string keys with the same hash value to be able launch a attach, and won't reach the max post size [2012-01-05 14:05:52] larue...@php.net oh, I got you, thanks. [2012-01-05 14:04:50] larue...@php.net yes, the hash value of string index is the same, but the index = hash_value % nTableSize, we don't use the hash value as index directly, didn't I misunderstand you? [2012-01-05 11:53:37] ses...@php.net You are mistaken to believe that randomizing the TableSize will stop predictable collisions: This is only true if you try to exploit the problem with numerical indicies. The moment you use alpha numerical keys and produce collisions in the DJB hashing function the table size does not matter anymore, because the return value of the hash function is the same. [2012-01-05 11:29:15] larue...@php.net sorry, didn't get your point? the collision can not be predicatible any more, why this patch doesn't solve the problem? 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=60655 -- Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1
Req #60655 [Opn]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1 ID: 60655 Updated by: larue...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: sesser, I am not good at algorithm, so if you can help me, I will appreciate. just a guess, what about change the zend_hash_func, add some new seed like: register ulong hash = 5381 + nKeyLength; thanks Previous Comments: [2012-01-05 14:44:32] ses...@php.net It is not "a theory", The whole disclosure from n-runs was about colliding the DJB hash function with alpha numerical keys. [2012-01-05 14:14:08] larue...@php.net I got you point, and agree in theory, yes, the string hash value could be the same, does anyone have a method to compute it in real? yes I really doubt that if we can find so many string keys with the same hash value to be able launch a attach, and won't reach the max post size [2012-01-05 14:05:52] larue...@php.net oh, I got you, thanks. [2012-01-05 14:04:50] larue...@php.net yes, the hash value of string index is the same, but the index = hash_value % nTableSize, we don't use the hash value as index directly, didn't I misunderstand you? [2012-01-05 11:53:37] ses...@php.net You are mistaken to believe that randomizing the TableSize will stop predictable collisions: This is only true if you try to exploit the problem with numerical indicies. The moment you use alpha numerical keys and produce collisions in the DJB hashing function the table size does not matter anymore, because the return value of the hash function is the same. 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=60655 -- Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1
Req #60655 [Opn]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1 ID: 60655 Updated by: ses...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: BTW a simple approach to cause 65536 alpha numerical collisions would use most probably less than 2MB of POST payload. And this is the NOT mathematically optimized version. Previous Comments: [2012-01-05 14:47:21] larue...@php.net sesser, I am not good at algorithm, so if you can help me, I will appreciate. just a guess, what about change the zend_hash_func, add some new seed like: register ulong hash = 5381 + nKeyLength; thanks [2012-01-05 14:44:32] ses...@php.net It is not "a theory", The whole disclosure from n-runs was about colliding the DJB hash function with alpha numerical keys. [2012-01-05 14:14:08] larue...@php.net I got you point, and agree in theory, yes, the string hash value could be the same, does anyone have a method to compute it in real? yes I really doubt that if we can find so many string keys with the same hash value to be able launch a attach, and won't reach the max post size [2012-01-05 14:05:52] larue...@php.net oh, I got you, thanks. [2012-01-05 14:04:50] larue...@php.net yes, the hash value of string index is the same, but the index = hash_value % nTableSize, we don't use the hash value as index directly, didn't I misunderstand you? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60655 -- Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1
Req #60655 [Opn]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1 ID: 60655 Updated by: ses...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: laruence: nothing against you, but fixing the hash table thing is not a simple easy fix. It must be done by someone who understands the mathematical problem of hash collisions and who understands the impact of making changes to a hash function. Just changing some constants in the algorithm will not improve the situation. The opposite can be the case. By changing some constants it could be possible to destroy the distribution of collisions and suddenly some values collide more often than others. So please do not try to fix a problem that must be solved by someone with the mathematical background knowledge. Previous Comments: [2012-01-05 14:48:14] ses...@php.net BTW a simple approach to cause 65536 alpha numerical collisions would use most probably less than 2MB of POST payload. And this is the NOT mathematically optimized version. [2012-01-05 14:47:21] larue...@php.net sesser, I am not good at algorithm, so if you can help me, I will appreciate. just a guess, what about change the zend_hash_func, add some new seed like: register ulong hash = 5381 + nKeyLength; thanks [2012-01-05 14:44:32] ses...@php.net It is not "a theory", The whole disclosure from n-runs was about colliding the DJB hash function with alpha numerical keys. [2012-01-05 14:14:08] larue...@php.net I got you point, and agree in theory, yes, the string hash value could be the same, does anyone have a method to compute it in real? yes I really doubt that if we can find so many string keys with the same hash value to be able launch a attach, and won't reach the max post size [2012-01-05 14:05:52] larue...@php.net oh, I got you, thanks. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60655 -- Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1
[PHP-BUG] Bug #60665 [NEW]: call to empty() on NULL result using PDO::FETCH_LAZY returns false
From: Operating system: Ubuntu Linux / Windows 7 PHP version: 5.3.8 Package: PDO related Bug Type: Bug Bug description:call to empty() on NULL result using PDO::FETCH_LAZY returns false Description: > PHP 5.3.8 (on both Ubuntu Linux and Windows 7) > ./configure --with-pdo-mysql > No changes to php.ini When fetching rows from a MySQL database using PDO with the default fetch method FETCH_LAZY, the empty() function returns false on NULL values in the database. This behavior does not exist when using other fetch methods (such as FETCH_OBJ or FETCH_ASSOC). Test script: --- $row = $stmt->fetch(PDO::FETCH_LAZY); echo $row->Address2."\n"; // RIGHT: outputs '' var_dump($row->Address2); // RIGHT: outputs 'NULL' var_dump(!$row->Address2);// RIGHT: outputs 'bool(true)' var_dump(!!$row->Address2); // RIGHT: outputs 'bool(false)' echo empty($row->Address2)."\n"; // WRONG: outputs '' var_dump(empty($row->Address2)); // WRONG: outputs 'bool(false)' var_dump(empty($row['Address2']));// WRONG: outputs 'bool(false)' $var = $row['Address2']; var_dump($var); // RIGHT: outputs 'NULL' var_dump(empty($var));// RIGHT: outputs 'bool(true)' Expected result: NULL bool(true) bool(false) 1 bool(true) bool(true) NULL bool(true) Actual result: -- NULL bool(true) bool(false) bool(false) bool(false) NULL bool(true) -- Edit bug report at https://bugs.php.net/bug.php?id=60665&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60665&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60665&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60665&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60665&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60665&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60665&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60665&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60665&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60665&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60665&r=support Expected behavior: https://bugs.php.net/fix.php?id=60665&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60665&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60665&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60665&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60665&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60665&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60665&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60665&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60665&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60665&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60665&r=mysqlcfg
Req #60655 [Opn]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1 ID: 60655 Updated by: larue...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: sesser, yes, you are right, a constant can not fix this problem, only make it more diffcult to find the special keys.. Previous Comments: [2012-01-05 14:52:32] ses...@php.net laruence: nothing against you, but fixing the hash table thing is not a simple easy fix. It must be done by someone who understands the mathematical problem of hash collisions and who understands the impact of making changes to a hash function. Just changing some constants in the algorithm will not improve the situation. The opposite can be the case. By changing some constants it could be possible to destroy the distribution of collisions and suddenly some values collide more often than others. So please do not try to fix a problem that must be solved by someone with the mathematical background knowledge. [2012-01-05 14:48:14] ses...@php.net BTW a simple approach to cause 65536 alpha numerical collisions would use most probably less than 2MB of POST payload. And this is the NOT mathematically optimized version. [2012-01-05 14:47:21] larue...@php.net sesser, I am not good at algorithm, so if you can help me, I will appreciate. just a guess, what about change the zend_hash_func, add some new seed like: register ulong hash = 5381 + nKeyLength; thanks [2012-01-05 14:44:32] ses...@php.net It is not "a theory", The whole disclosure from n-runs was about colliding the DJB hash function with alpha numerical keys. [2012-01-05 14:14:08] larue...@php.net I got you point, and agree in theory, yes, the string hash value could be the same, does anyone have a method to compute it in real? yes I really doubt that if we can find so many string keys with the same hash value to be able launch a attach, and won't reach the max post size 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=60655 -- Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1
Req #60655 [Com]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1 ID: 60655 Comment by: miha dot vrhovnik at domenca dot si Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: As the authors say in the video the Perl solved this in 2003. They fixed it by randomizing hash seed. Probably for each "hash". You can look this video for more details: http://www.youtube.com/watch?v=R2Cq3CLI6H8&feature=channel_video_title Previous Comments: [2012-01-05 15:07:54] larue...@php.net sesser, yes, you are right, a constant can not fix this problem, only make it more diffcult to find the special keys.. [2012-01-05 14:52:32] ses...@php.net laruence: nothing against you, but fixing the hash table thing is not a simple easy fix. It must be done by someone who understands the mathematical problem of hash collisions and who understands the impact of making changes to a hash function. Just changing some constants in the algorithm will not improve the situation. The opposite can be the case. By changing some constants it could be possible to destroy the distribution of collisions and suddenly some values collide more often than others. So please do not try to fix a problem that must be solved by someone with the mathematical background knowledge. [2012-01-05 14:48:14] ses...@php.net BTW a simple approach to cause 65536 alpha numerical collisions would use most probably less than 2MB of POST payload. And this is the NOT mathematically optimized version. [2012-01-05 14:47:21] larue...@php.net sesser, I am not good at algorithm, so if you can help me, I will appreciate. just a guess, what about change the zend_hash_func, add some new seed like: register ulong hash = 5381 + nKeyLength; thanks [2012-01-05 14:44:32] ses...@php.net It is not "a theory", The whole disclosure from n-runs was about colliding the DJB hash function with alpha numerical keys. 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=60655 -- Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1
Bug #60627 [Com]: httpd.worker segfault on startup with php_value
Edit report at https://bugs.php.net/bug.php?id=60627&edit=1 ID: 60627 Comment by: public at wernig dot net Reported by:fedora at famillecollet dot com Summary:httpd.worker segfault on startup with php_value Status: Feedback Type: Bug Package:Apache2 related Operating System: GNU/Linux (Fedora 16) PHP Version:5.4SVN-2011-12-30 (snap) Assigned To:laruence Block user comment: N Private report: N New Comment: Yes, this is exactly as it is displayed by gdb. I still have the console open, and the output is what I have pasted. Strange, now that you mention it... Previous Comments: [2012-01-05 10:21:34] larue...@php.net @public are you sure your backtrace is simple copy&paste? there is two strange lines: #2 0xfe14088d in tsrm_mutex_lock (mutexp=0x0) at /opt/build.d/php-5/tmp/php5.4- 201201041430/TSRM/TSRM.c:391 #3 0xfe140e85 in ts_resource_ex (id=0, th_id=0x0) at /opt/build.d/php- 5/tmp/php5.4-201201041430/TSRM/TSRM.c:391 both of them are in line 391. [2012-01-05 09:19:03] larue...@php.net sorry, kind of buzy these days, I will look at this in 1 or 2 days, thanks [2012-01-05 09:14:19] public at wernig dot net Is there any further information that I can provide to help track this down? [2012-01-05 02:45:29] larue...@php.net seems there is something wrong in solaris .. re-open [2012-01-04 19:15:45] fedora at famillecollet dot com Thanks for the patch. Works for me, httpd.worker + php 5.4.0RC5-dev ZTS 201201041830. (solaris bug seems another issue) 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=60627 -- Edit this bug report at https://bugs.php.net/bug.php?id=60627&edit=1
Bug #60627 [Com]: httpd.worker segfault on startup with php_value
Edit report at https://bugs.php.net/bug.php?id=60627&edit=1 ID: 60627 Comment by: public at wernig dot net Reported by:fedora at famillecollet dot com Summary:httpd.worker segfault on startup with php_value Status: Feedback Type: Bug Package:Apache2 related Operating System: GNU/Linux (Fedora 16) PHP Version:5.4SVN-2011-12-30 (snap) Assigned To:laruence Block user comment: N Private report: N New Comment: fwiw, here's file and linkeage info: # file /usr/local/apache2/modules/libphp5.so /usr/local/apache2/modules/libphp5.so: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped # ldd /usr/local/apache2/modules/libphp5.so libcrypt.so.1 => /usr/lib/libcrypt.so.1 libc-client.so =>/usr/local/imap/lib/libc-client.so libresolv.so.2 =>/lib/libresolv.so.2 librt.so.1 =>/lib/librt.so.1 libmysqlclient.so.18 => /usr/local/mysql/lib/libmysqlclient.so.18 libcrypto.so.1.0.0 =>/usr/local/ssl/lib/libcrypto.so.1.0.0 libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0 libpam.so.1 => /lib/libpam.so.1 libintl.so.8 => /opt/csw/lib/libintl.so.8 libdb-4.7.so => /opt/csw/lib/libdb-4.7.so libz.so => /opt/csw/lib/libz.so libm.so.2 => /lib/libm.so.2 libnsl.so.1 => /lib/libnsl.so.1 libsocket.so.1 =>/lib/libsocket.so.1 libxml2.so.2 => /lib/libxml2.so.2 libc.so.1 => /lib/libc.so.1 libgcc_s.so.1 => /opt/csw/lib/libgcc_s.so.1 libgen.so.1 => /lib/libgen.so.1 libmd.so.1 =>/lib/libmd.so.1 libthread.so.1 =>/lib/libthread.so.1 libz.so.1 => /lib/libz.so.1 libdl.so.1 =>/lib/libdl.so.1 libiconv.so.2 => /opt/csw/lib/libiconv.so.2 libpthread.so.1 => /lib/libpthread.so.1 libmp.so.2 =>/lib/libmp.so.2 Previous Comments: [2012-01-05 20:04:56] public at wernig dot net Yes, this is exactly as it is displayed by gdb. I still have the console open, and the output is what I have pasted. Strange, now that you mention it... [2012-01-05 10:21:34] larue...@php.net @public are you sure your backtrace is simple copy&paste? there is two strange lines: #2 0xfe14088d in tsrm_mutex_lock (mutexp=0x0) at /opt/build.d/php-5/tmp/php5.4- 201201041430/TSRM/TSRM.c:391 #3 0xfe140e85 in ts_resource_ex (id=0, th_id=0x0) at /opt/build.d/php- 5/tmp/php5.4-201201041430/TSRM/TSRM.c:391 both of them are in line 391. [2012-01-05 09:19:03] larue...@php.net sorry, kind of buzy these days, I will look at this in 1 or 2 days, thanks [2012-01-05 09:14:19] public at wernig dot net Is there any further information that I can provide to help track this down? [2012-01-05 02:45:29] larue...@php.net seems there is something wrong in solaris .. re-open 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=60627 -- Edit this bug report at https://bugs.php.net/bug.php?id=60627&edit=1
[PHP-BUG] Bug #60666 [NEW]: scandir doesn''t return entries on GlusterFS (redHat's) file system
From:
Operating system: CentOS 5.7
PHP version: 5.3.8
Package: Directory function related
Bug Type: Bug
Bug description:scandir doesn''t return entries on GlusterFS (redHat's) file
system
Description:
When I'm trying to scandir or opendir/readdir on GlusterFS Distributed
volumes (mounted to some folder) I got something but not I'm expecting to
obtainan: empty array even without . and .. entries, only . entry, 2-3
entries instead of >100 and so on.
Other ways (bash ls or perl opendir) works correctly.
for example:
distributed GlusterFS volume mounted to /sites/blog folder.
scandir("/sites/blog");
array(0) {
}
distributed GlusterFS volume mounted to /sites/other folder:
scandir("/sites/other");
array(1) {
[0]=>
string(1) "."
}
scandir("/sites/other/old");
array(3) {
[0]=>
string(1) "."
[1]=>
string(11) "1.2.0.2540"
[2]=>
string(11) "1.5.0.2559"
}
Test script:
---
--
Edit bug report at https://bugs.php.net/bug.php?id=60666&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60666&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60666&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60666&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60666&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60666&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60666&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60666&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60666&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60666&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60666&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60666&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60666&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60666&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60666&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60666&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60666&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60666&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60666&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60666&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60666&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60666&r=mysqlcfg
Req #53754 [Com]: Modify headers_list() to return an array of set headers in CLI SAPI
Edit report at https://bugs.php.net/bug.php?id=53754&edit=1
ID: 53754
Comment by: wiltave at gmail dot com
Reported by:pistole at rhp dot org
Summary:Modify headers_list() to return an array of set
headers in CLI SAPI
Status: Open
Type: Feature/Change Request
Package:CGI/CLI related
Operating System: Ubuntu Server 10.0
PHP Version:5.3.5
Block user comment: N
Private report: N
New Comment:
It would be useful to write unit tests. Some codes need to send headers.
Thank you.
Previous Comments:
[2011-01-14 22:45:54] pistole at rhp dot org
Description:
Calling headers_list() from the CLI version of PHP always returns an empty
array, ignoring the results of previous calls to header(), despite the fact
that they are already tracked internally.
As some background, I'm attempting to write a pure PHP bootstrap development
HTTP server to help programmers easily create new development environments and
for lightweight standalone webapps that don't need a fully featured web-server
to deploy.
One of the things I'm trying to accomplish with this is to enable out of the
box usage on various *nix distros and Mac OSX. The PHP-CGI SAPI is perfect for
my project, but it isn't always installed by default (certainly not on OSX), so
I'm attempting to make it work with the CLI version.
I've managed to work around most of the limitations I've run up against, but
this headers_list() always returning an empty array is a complete show-stopper.
Without being able to retrieve the list, apps that set any kind of custom
headers (including cookies), can never work correctly.
I've attached a one-line patch to enable headers_list() to function in the CLI
SAPI. Another (probably better) option would be to create an ini file setting
to determine which behavior to exhibit. I'd be happy to do the dev work for
that and submit the revised patch.
Test script:
---
#!/usr/bin/php
string(23) "X-Powered-By: PHP/5.3.5"
[1]=>
string(14) "Location: asdf"
}
Actual result:
--
array(0) {
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=53754&edit=1
