Bug #60765 [Com]: mysqli_real_escape_string not parse multibyte word safe while use mysqlnd
Edit report at https://bugs.php.net/bug.php?id=60765edit=1 ID: 60765 Comment by: xiaqii at gmail dot com Reported by:xiaqii at gmail dot com Summary:mysqli_real_escape_string not parse multibyte word safe while use mysqlnd Status: Not a bug Type: Bug Package:MySQLi related Operating System: ubuntu 10 PHP Version:5.3.9 Assigned To:uw Block user comment: N Private report: N New Comment: i do set charset with $dbcharset=GBK; mysqli_query($this-linkID, SET character_set_connection=$dbcharset, character_set_results=$dbcharset, character_set_client=binary) or $this-error(set names error); and my mysqlserver's default charset in my.cnf is also GBK i'll retest it ASAP. Previous Comments: [2012-01-26 10:02:22] johan...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php You have to call mysqli_set_charset() to set the correct encoding so PHP and the MySQL server know hat data to expect and how to interpret it. [2012-01-26 02:48:46] xiaqii at gmail dot com my site's charset is GBK [2012-01-16 06:19:58] xiaqii at gmail dot com i recomplie my php with old style --with-mysqli=/usr/local/mysql/bin/mysql_config' the sql is safe and execute ok. so the bug is : mysqlnd not parse some multibyte word. this can be sql injection problem. i hope my english is enough to explain this bug clearly.. -_-! [2012-01-16 05:50:24] xiaqii at gmail dot com Description: some Multibyte word contain \ ASCII code didn't been escaped. Test script: --- $link=mysqli_connect(); $var=æµ·è³; $var=mysqli_real_escape_string($link,$var); mysqli_query($link,INSERT INTO table SET manga_name='$var'); /// Expected result: sql injection Actual result: -- it is dangerous. my reply table has been update to all one word because this.. -- Edit this bug report at https://bugs.php.net/bug.php?id=60765edit=1
[PHP-BUG] Bug #60922 [NEW]: tests fail for mhash() and mhash_keygen_s2k() functions and MHASH_TIGER
From:
Operating system: Mac OS X
PHP version: 5.4SVN-2012-01-29 (SVN)
Package: mhash related
Bug Type: Bug
Bug description:tests fail for mhash() and mhash_keygen_s2k() functions and
MHASH_TIGER
Description:
make test failed test summary:
mhash() test [ext/hash/tests/mhash_001.phpt]
mhash_keygen_s2k() test [ext/hash/tests/mhash_003.phpt
mhash_003.out:
MHASH_TIGER: string(200)
67eac97b9dca0a47b1f6262f330264e4ce1c233760fe3255f642512fd3127929baccf1e758236b2768a4c2c0c06e118b19e40e2f04a5f745820fb8a99bdbc00698702a4d3120171856c4c94bda79ba1b4f60d509d7f8954da818a29797368dd47c1122aa
MHASH_TIGER: string(200)
470aca9d7bc9ea67e46402332f26f6b15532fe6037231cce297912d32f5142f6276b2358e7f1ccba8b116ec0c0c2a46845f7a5042f0ee41906c0db9ba9b80f82181720314d2a70981bba79da4bc9c4564d95f8d709d5604fd48d369797a218a862196f48
Test script:
---
mhash_003.php
foreach ($supported_hash_al as $hash=$wanted) {
$passwd = str_repeat($hash, 10);
$salt = str_repeat($hash, 2);
$result = mhash_keygen_s2k(constant($hash), $passwd, $salt, 100);
if (!strcmp(bin2hex($result), $wanted)) {
echo $hash\nok\n;
} else {
echo $hash: ;
var_dump($wanted);
echo $hash: ;
var_dump(bin2hex($result));
}
echo \n;
}
--
Edit bug report at https://bugs.php.net/bug.php?id=60922edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60922r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60922r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60922r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60922r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60922r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60922r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60922r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60922r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60922r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60922r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60922r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60922r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60922r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60922r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60922r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60922r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60922r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60922r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60922r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60922r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60922r=mysqlcfg
[PHP-BUG] Bug #60923 [NEW]: Failing tests for sapi/cli
From: Operating system: GNU/Linux (Fedora 16) PHP version: 5.4SVN-2012-01-29 (SVN) Package: CGI/CLI related Bug Type: Bug Bug description:Failing tests for sapi/cli Description: After checking out PHP54 from branches/PHP_5_4, running: ./buildconf ./configure make make test some tests for sapi/cli are failing. These tests were OK when I tested from tags/php_5_4_0RC6 The failing tests are: = FAILED TEST SUMMARY - version string [sapi/cli/tests/001.phpt] strip comments and whitespace with -w [sapi/cli/tests/007.phpt] execute a file with -f [sapi/cli/tests/008.phpt] using invalid combinations of cmdline options [sapi/cli/tests/009.phpt] syntax check [sapi/cli/tests/011.phpt] invalid arguments and error messages [sapi/cli/tests/012.phpt] syntax highlighting [sapi/cli/tests/014.phpt] CLI long options [sapi/cli/tests/015.phpt] = Full reports were submitted to http://qa.php.net/reports/ after running the tests. -- Edit bug report at https://bugs.php.net/bug.php?id=60923edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60923r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60923r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60923r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60923r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60923r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60923r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60923r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60923r=needscript Try newer version: https://bugs.php.net/fix.php?id=60923r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60923r=support Expected behavior: https://bugs.php.net/fix.php?id=60923r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60923r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60923r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60923r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60923r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60923r=dst IIS Stability: https://bugs.php.net/fix.php?id=60923r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60923r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60923r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60923r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60923r=mysqlcfg
Bug #60923 [Opn-Fbk]: Failing tests for sapi/cli
Edit report at https://bugs.php.net/bug.php?id=60923edit=1 ID: 60923 Updated by: ras...@php.net Reported by:robertbasic dot com at gmail dot com Summary:Failing tests for sapi/cli -Status: Open +Status: Feedback Type: Bug Package:CGI/CLI related Operating System: GNU/Linux (Fedora 16) PHP Version:5.4SVN-2012-01-29 (SVN) Block user comment: N Private report: N New Comment: I am not seeing these failures here. Could you dig into one of them to see if you can figure out why it is failing for you? Previous Comments: [2012-01-29 12:20:21] robertbasic dot com at gmail dot com Description: After checking out PHP54 from branches/PHP_5_4, running: ./buildconf ./configure make make test some tests for sapi/cli are failing. These tests were OK when I tested from tags/php_5_4_0RC6 The failing tests are: = FAILED TEST SUMMARY - version string [sapi/cli/tests/001.phpt] strip comments and whitespace with -w [sapi/cli/tests/007.phpt] execute a file with -f [sapi/cli/tests/008.phpt] using invalid combinations of cmdline options [sapi/cli/tests/009.phpt] syntax check [sapi/cli/tests/011.phpt] invalid arguments and error messages [sapi/cli/tests/012.phpt] syntax highlighting [sapi/cli/tests/014.phpt] CLI long options [sapi/cli/tests/015.phpt] = Full reports were submitted to http://qa.php.net/reports/ after running the tests. -- Edit this bug report at https://bugs.php.net/bug.php?id=60923edit=1
Bug #55509 [Com]: segfault on x86_64 using more than 2G memory
Edit report at https://bugs.php.net/bug.php?id=55509edit=1 ID: 55509 Comment by: simon at wakecodesleep dot com Reported by:r dot gauweiler at otterbach dot de Summary:segfault on x86_64 using more than 2G memory Status: Closed Type: Bug Package:Reproducible crash Operating System: Linux PHP Version:5.3.8 Assigned To:dmitry Block user comment: N Private report: N New Comment: I received this bug when running 'make test' with the default ./configure flags (no arguments) on the latest PHP 5.4.0 branch. I'm running Mac OS X Lion (10.7.2 - Darwin - Darwin Simons-MacBook-Air.local 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu- 1699.24.8~1/RELEASE_X86_64 x86_64) on a 1.8GHz Core i7, 4GB RAM MacBook Air. Previous Comments: [2011-09-13 07:01:49] dmi...@php.net This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. [2011-09-13 07:01:31] dmi...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=316590 Log: Fixed bug #55509 (segfault on x86_64 using more than 2G memory). (Laruence) [2011-09-07 08:43:33] larue...@php.net Dmitry, plz look at this, thanks :-) [2011-09-06 15:11:56] larue...@php.net The following patch has been added/updated: Patch Name: bug55509.diff Revision: 1315321916 URL: https://bugs.php.net/patch-display.php?bug=55509patch=bug55509.diffrevision=1315321916 [2011-09-06 14:48:56] larue...@php.net although I have submitted a phpt file for this, I really think it'd better not to be a default test case, since it consume too much memory, may cause the client feel worse.. 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=55509 -- Edit this bug report at https://bugs.php.net/bug.php?id=55509edit=1
Bug #60923 [Com]: Failing tests for sapi/cli
Edit report at https://bugs.php.net/bug.php?id=60923edit=1 ID: 60923 Comment by: robertbasic dot com at gmail dot com Reported by:robertbasic dot com at gmail dot com Summary:Failing tests for sapi/cli Status: Feedback Type: Bug Package:CGI/CLI related Operating System: GNU/Linux (Fedora 16) PHP Version:5.4SVN-2012-01-29 (SVN) Block user comment: N Private report: N New Comment: Will do. By looking at the expected and the actual outputs of sapi/cli/tests/001.phpt, looks like that var_dump(`$php -n -v`); first prints out the PHP version (the result from php -n -v) and then var_dumps a NULL, whereas it should var_dump the result from php -n -v. Actually, all these failing tests are this kind of thing: printing the result, var_dumping NULL, instead of var_dumping the result. What's strange, is that, for example sapi/cli/tests/007.phpt, from 3 var_dumps in that test, only one does this (the 2nd), the other 2 work as expected. Given that this works for RC6, I'm looking at commits since then, to see if anything from there is causing this. Any hints on what should I do to check is my system affecting this somehow? I'm using the test instructions you posted on codepad some time ago. Thanks! Previous Comments: [2012-01-29 13:50:42] ras...@php.net I am not seeing these failures here. Could you dig into one of them to see if you can figure out why it is failing for you? [2012-01-29 12:20:21] robertbasic dot com at gmail dot com Description: After checking out PHP54 from branches/PHP_5_4, running: ./buildconf ./configure make make test some tests for sapi/cli are failing. These tests were OK when I tested from tags/php_5_4_0RC6 The failing tests are: = FAILED TEST SUMMARY - version string [sapi/cli/tests/001.phpt] strip comments and whitespace with -w [sapi/cli/tests/007.phpt] execute a file with -f [sapi/cli/tests/008.phpt] using invalid combinations of cmdline options [sapi/cli/tests/009.phpt] syntax check [sapi/cli/tests/011.phpt] invalid arguments and error messages [sapi/cli/tests/012.phpt] syntax highlighting [sapi/cli/tests/014.phpt] CLI long options [sapi/cli/tests/015.phpt] = Full reports were submitted to http://qa.php.net/reports/ after running the tests. -- Edit this bug report at https://bugs.php.net/bug.php?id=60923edit=1
Bug #60923 [Com]: Failing tests for sapi/cli
Edit report at https://bugs.php.net/bug.php?id=60923edit=1
ID: 60923
Comment by: robertbasic dot com at gmail dot com
Reported by:robertbasic dot com at gmail dot com
Summary:Failing tests for sapi/cli
Status: Feedback
Type: Bug
Package:CGI/CLI related
Operating System: GNU/Linux (Fedora 16)
PHP Version:5.4SVN-2012-01-29 (SVN)
Block user comment: N
Private report: N
New Comment:
Hello again!
I did a svn log -r {2012-01-10}:HEAD against the PHP54 branch and went through
those commits.
What I've managed to do so far is to find what commit is causing the tests to
fail (at least I think it's this one):
http://svn.php.net/viewvc?view=revisionrevision=322743
The r322743 of the code has the tests failing, while the one prior to it
(r322678) has the tests passing.
Sadly my C skills are almost non-existent, so I can't promise a patch, but will
continue to poke around it.
Previous Comments:
[2012-01-29 14:24:04] robertbasic dot com at gmail dot com
Will do.
By looking at the expected and the actual outputs of sapi/cli/tests/001.phpt,
looks like that var_dump(`$php -n -v`); first prints out the PHP version (the
result from php -n -v) and then var_dumps a NULL, whereas it should var_dump
the result from php -n -v.
Actually, all these failing tests are this kind of thing: printing the result,
var_dumping NULL, instead of var_dumping the result. What's strange, is that,
for example sapi/cli/tests/007.phpt, from 3 var_dumps in that test, only one
does this (the 2nd), the other 2 work as expected.
Given that this works for RC6, I'm looking at commits since then, to see if
anything from there is causing this.
Any hints on what should I do to check is my system affecting this somehow? I'm
using the test instructions you posted on codepad some time ago.
Thanks!
[2012-01-29 13:50:42] ras...@php.net
I am not seeing these failures here. Could you dig into one of them to see if
you
can figure out why it is failing for you?
[2012-01-29 12:20:21] robertbasic dot com at gmail dot com
Description:
After checking out PHP54 from branches/PHP_5_4, running:
./buildconf
./configure
make
make test
some tests for sapi/cli are failing. These tests were OK when I tested from
tags/php_5_4_0RC6
The failing tests are:
=
FAILED TEST SUMMARY
-
version string [sapi/cli/tests/001.phpt]
strip comments and whitespace with -w [sapi/cli/tests/007.phpt]
execute a file with -f [sapi/cli/tests/008.phpt]
using invalid combinations of cmdline options [sapi/cli/tests/009.phpt]
syntax check [sapi/cli/tests/011.phpt]
invalid arguments and error messages [sapi/cli/tests/012.phpt]
syntax highlighting [sapi/cli/tests/014.phpt]
CLI long options [sapi/cli/tests/015.phpt]
=
Full reports were submitted to http://qa.php.net/reports/ after running the
tests.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60923edit=1
Bug #60920 [Com]: CLI: php -v on STDERR
Edit report at https://bugs.php.net/bug.php?id=60920edit=1 ID: 60920 Comment by: b...@php.net Reported by:the...@php.net Summary:CLI: php -v on STDERR Status: Open Type: Bug Package:PHP options/info functions PHP Version:5.4SVN-2012-01-28 (SVN) Block user comment: N Private report: N New Comment: This is causing sapi/cli/tests/001.phpt to fail - Is the fix intentional and does the unit test need updating, or should --version be outputting to STDOUT? Previous Comments: [2012-01-28 22:25:20] the...@php.net Same goes for startup errors, e.g. $ F:/Programme/php-5.4.0RC6-nts-Win32-VC9-x86/php.exe -dmagic_quotes_gpc=on 2/dev/null Fatal error: Directive 'magic_quotes_gpc' is no longer available in PHP in Unknown on line 0 vs. $ ~/devel/php/php/branches/PHP_5_4/Release/php.exe -dmagic_quotes_gpc=on 2/dev/null [2012-01-28 22:22:49] the...@php.net Description: The PHP version info lands on STDERR now, not on STDOUT. Caused by http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/main/output.c?r1=322743r2=322742pathrev=322743 Test script: --- $ php -v 2/dev/null Expected result: Something like: PHP 5.4.0RC7-dev (cli) (built: Jan 28 2012 22:23:46) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies Actual result: -- (nothing) -- Edit this bug report at https://bugs.php.net/bug.php?id=60920edit=1
Bug #60923 [Com]: Failing tests for sapi/cli
Edit report at https://bugs.php.net/bug.php?id=60923edit=1
ID: 60923
Comment by: robertbasic dot com at gmail dot com
Reported by:robertbasic dot com at gmail dot com
Summary:Failing tests for sapi/cli
Status: Feedback
Type: Bug
Package:CGI/CLI related
Operating System: GNU/Linux (Fedora 16)
PHP Version:5.4SVN-2012-01-29 (SVN)
Block user comment: N
Private report: N
New Comment:
Think I narrowed it down even more. Seems to me the problem is in the new
php_output_stderr function - when I comment it out, the tests pass again. I'll
attach a diff to show what I did.
Previous Comments:
[2012-01-29 16:21:26] robertbasic dot com at gmail dot com
Hello again!
I did a svn log -r {2012-01-10}:HEAD against the PHP54 branch and went through
those commits.
What I've managed to do so far is to find what commit is causing the tests to
fail (at least I think it's this one):
http://svn.php.net/viewvc?view=revisionrevision=322743
The r322743 of the code has the tests failing, while the one prior to it
(r322678) has the tests passing.
Sadly my C skills are almost non-existent, so I can't promise a patch, but will
continue to poke around it.
[2012-01-29 14:24:04] robertbasic dot com at gmail dot com
Will do.
By looking at the expected and the actual outputs of sapi/cli/tests/001.phpt,
looks like that var_dump(`$php -n -v`); first prints out the PHP version (the
result from php -n -v) and then var_dumps a NULL, whereas it should var_dump
the result from php -n -v.
Actually, all these failing tests are this kind of thing: printing the result,
var_dumping NULL, instead of var_dumping the result. What's strange, is that,
for example sapi/cli/tests/007.phpt, from 3 var_dumps in that test, only one
does this (the 2nd), the other 2 work as expected.
Given that this works for RC6, I'm looking at commits since then, to see if
anything from there is causing this.
Any hints on what should I do to check is my system affecting this somehow? I'm
using the test instructions you posted on codepad some time ago.
Thanks!
[2012-01-29 13:50:42] ras...@php.net
I am not seeing these failures here. Could you dig into one of them to see if
you
can figure out why it is failing for you?
[2012-01-29 12:20:21] robertbasic dot com at gmail dot com
Description:
After checking out PHP54 from branches/PHP_5_4, running:
./buildconf
./configure
make
make test
some tests for sapi/cli are failing. These tests were OK when I tested from
tags/php_5_4_0RC6
The failing tests are:
=
FAILED TEST SUMMARY
-
version string [sapi/cli/tests/001.phpt]
strip comments and whitespace with -w [sapi/cli/tests/007.phpt]
execute a file with -f [sapi/cli/tests/008.phpt]
using invalid combinations of cmdline options [sapi/cli/tests/009.phpt]
syntax check [sapi/cli/tests/011.phpt]
invalid arguments and error messages [sapi/cli/tests/012.phpt]
syntax highlighting [sapi/cli/tests/014.phpt]
CLI long options [sapi/cli/tests/015.phpt]
=
Full reports were submitted to http://qa.php.net/reports/ after running the
tests.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60923edit=1
[PHP-BUG] Req #60924 [NEW]: ArrayObject should implement JsonSerializable interface
From:
Operating system:
PHP version: 5.4.0RC6
Package: Class/Object related
Bug Type: Feature/Change Request
Bug description:ArrayObject should implement JsonSerializable interface
Description:
PHP 5.4 brings the new JsonSerializable interface. ArrayObject already
works with json_encode as expected but does not explicitly implement this
interface.
Test script:
---
$ao = new ArrayObject(array('foo' = 'bar'));
var_dump(json_encode($ao));
var_dump($ao instanceof JsonSerializable);
var_dump($ao-jsonSerialize());
Expected result:
string(13) {foo:bar}
bool(true)
string(13) {foo:bar}
Actual result:
--
string(13) {foo:bar}
bool(false)
PHP Fatal error: Call to undefined method ArrayObject::jsonSerialize() in
- on line 6
--
Edit bug report at https://bugs.php.net/bug.php?id=60924edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60924r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60924r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60924r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60924r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60924r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60924r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60924r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60924r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60924r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60924r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60924r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60924r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60924r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60924r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60924r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60924r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60924r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60924r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60924r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60924r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60924r=mysqlcfg
Bug #60923 [Fbk]: Failing tests for sapi/cli
Edit report at https://bugs.php.net/bug.php?id=60923edit=1
ID: 60923
Updated by: ras...@php.net
Reported by:robertbasic dot com at gmail dot com
Summary:Failing tests for sapi/cli
Status: Feedback
Type: Bug
Package:CGI/CLI related
Operating System: GNU/Linux (Fedora 16)
PHP Version:5.4SVN-2012-01-29 (SVN)
Block user comment: N
Private report: N
New Comment:
Yeah, looks to be the same as bug #60920
Previous Comments:
[2012-01-29 17:39:06] robertbasic dot com at gmail dot com
Think I narrowed it down even more. Seems to me the problem is in the new
php_output_stderr function - when I comment it out, the tests pass again. I'll
attach a diff to show what I did.
[2012-01-29 16:21:26] robertbasic dot com at gmail dot com
Hello again!
I did a svn log -r {2012-01-10}:HEAD against the PHP54 branch and went through
those commits.
What I've managed to do so far is to find what commit is causing the tests to
fail (at least I think it's this one):
http://svn.php.net/viewvc?view=revisionrevision=322743
The r322743 of the code has the tests failing, while the one prior to it
(r322678) has the tests passing.
Sadly my C skills are almost non-existent, so I can't promise a patch, but will
continue to poke around it.
[2012-01-29 14:24:04] robertbasic dot com at gmail dot com
Will do.
By looking at the expected and the actual outputs of sapi/cli/tests/001.phpt,
looks like that var_dump(`$php -n -v`); first prints out the PHP version (the
result from php -n -v) and then var_dumps a NULL, whereas it should var_dump
the result from php -n -v.
Actually, all these failing tests are this kind of thing: printing the result,
var_dumping NULL, instead of var_dumping the result. What's strange, is that,
for example sapi/cli/tests/007.phpt, from 3 var_dumps in that test, only one
does this (the 2nd), the other 2 work as expected.
Given that this works for RC6, I'm looking at commits since then, to see if
anything from there is causing this.
Any hints on what should I do to check is my system affecting this somehow? I'm
using the test instructions you posted on codepad some time ago.
Thanks!
[2012-01-29 13:50:42] ras...@php.net
I am not seeing these failures here. Could you dig into one of them to see if
you
can figure out why it is failing for you?
[2012-01-29 12:20:21] robertbasic dot com at gmail dot com
Description:
After checking out PHP54 from branches/PHP_5_4, running:
./buildconf
./configure
make
make test
some tests for sapi/cli are failing. These tests were OK when I tested from
tags/php_5_4_0RC6
The failing tests are:
=
FAILED TEST SUMMARY
-
version string [sapi/cli/tests/001.phpt]
strip comments and whitespace with -w [sapi/cli/tests/007.phpt]
execute a file with -f [sapi/cli/tests/008.phpt]
using invalid combinations of cmdline options [sapi/cli/tests/009.phpt]
syntax check [sapi/cli/tests/011.phpt]
invalid arguments and error messages [sapi/cli/tests/012.phpt]
syntax highlighting [sapi/cli/tests/014.phpt]
CLI long options [sapi/cli/tests/015.phpt]
=
Full reports were submitted to http://qa.php.net/reports/ after running the
tests.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60923edit=1
Bug #60923 [Fbk-Ctl]: Failing tests for sapi/cli
Edit report at https://bugs.php.net/bug.php?id=60923edit=1
ID: 60923
Updated by: ras...@php.net
Reported by:robertbasic dot com at gmail dot com
Summary:Failing tests for sapi/cli
-Status: Feedback
+Status: Critical
Type: Bug
Package:CGI/CLI related
Operating System: GNU/Linux (Fedora 16)
PHP Version:5.4SVN-2012-01-29 (SVN)
Block user comment: N
Private report: N
Previous Comments:
[2012-01-29 19:05:18] ras...@php.net
Yeah, looks to be the same as bug #60920
[2012-01-29 17:39:06] robertbasic dot com at gmail dot com
Think I narrowed it down even more. Seems to me the problem is in the new
php_output_stderr function - when I comment it out, the tests pass again. I'll
attach a diff to show what I did.
[2012-01-29 16:21:26] robertbasic dot com at gmail dot com
Hello again!
I did a svn log -r {2012-01-10}:HEAD against the PHP54 branch and went through
those commits.
What I've managed to do so far is to find what commit is causing the tests to
fail (at least I think it's this one):
http://svn.php.net/viewvc?view=revisionrevision=322743
The r322743 of the code has the tests failing, while the one prior to it
(r322678) has the tests passing.
Sadly my C skills are almost non-existent, so I can't promise a patch, but will
continue to poke around it.
[2012-01-29 14:24:04] robertbasic dot com at gmail dot com
Will do.
By looking at the expected and the actual outputs of sapi/cli/tests/001.phpt,
looks like that var_dump(`$php -n -v`); first prints out the PHP version (the
result from php -n -v) and then var_dumps a NULL, whereas it should var_dump
the result from php -n -v.
Actually, all these failing tests are this kind of thing: printing the result,
var_dumping NULL, instead of var_dumping the result. What's strange, is that,
for example sapi/cli/tests/007.phpt, from 3 var_dumps in that test, only one
does this (the 2nd), the other 2 work as expected.
Given that this works for RC6, I'm looking at commits since then, to see if
anything from there is causing this.
Any hints on what should I do to check is my system affecting this somehow? I'm
using the test instructions you posted on codepad some time ago.
Thanks!
[2012-01-29 13:50:42] ras...@php.net
I am not seeing these failures here. Could you dig into one of them to see if
you
can figure out why it is failing for 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=60923
--
Edit this bug report at https://bugs.php.net/bug.php?id=60923edit=1
Bug #60920 [Opn-Ctl]: CLI: php -v on STDERR
Edit report at https://bugs.php.net/bug.php?id=60920edit=1 ID: 60920 Updated by: ras...@php.net Reported by:the...@php.net Summary:CLI: php -v on STDERR -Status: Open +Status: Critical Type: Bug Package:PHP options/info functions PHP Version:5.4SVN-2012-01-28 (SVN) Block user comment: N Private report: N New Comment: No, not intentional. We need to have a close look at this one. Previous Comments: [2012-01-29 16:31:55] b...@php.net This is causing sapi/cli/tests/001.phpt to fail - Is the fix intentional and does the unit test need updating, or should --version be outputting to STDOUT? [2012-01-28 22:25:20] the...@php.net Same goes for startup errors, e.g. $ F:/Programme/php-5.4.0RC6-nts-Win32-VC9-x86/php.exe -dmagic_quotes_gpc=on 2/dev/null Fatal error: Directive 'magic_quotes_gpc' is no longer available in PHP in Unknown on line 0 vs. $ ~/devel/php/php/branches/PHP_5_4/Release/php.exe -dmagic_quotes_gpc=on 2/dev/null [2012-01-28 22:22:49] the...@php.net Description: The PHP version info lands on STDERR now, not on STDOUT. Caused by http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/main/output.c?r1=322743r2=322742pathrev=322743 Test script: --- $ php -v 2/dev/null Expected result: Something like: PHP 5.4.0RC7-dev (cli) (built: Jan 28 2012 22:23:46) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies Actual result: -- (nothing) -- Edit this bug report at https://bugs.php.net/bug.php?id=60920edit=1
[PHP-BUG] Bug #60925 [NEW]: fpm_atomic.h says unknown processor
From: Operating system: Linux PHP version: 5.3.9 Package: Compile Failure Bug Type: Bug Bug description:fpm_atomic.h says unknown processor Description: /tmp/buildd/php5-5.3.9/sapi/fpm/fpm/fpm_atomic.h:142:2: error: #error Unsupported processor. Please open a bug report (bugs.php.net). This is on: Linux ara5.mirbsd.org 3.2.0-1+m68k.1-atari #1 Mon Jan 23 06:44:50 UTC 2012 m68k GNU/Linux php5_5.3.3-7 compiled, so this is a regression. Test script: --- dpkg-buildpackage -rfakeroot -B -- Edit bug report at https://bugs.php.net/bug.php?id=60925edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60925r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60925r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60925r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60925r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60925r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60925r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60925r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60925r=needscript Try newer version: https://bugs.php.net/fix.php?id=60925r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60925r=support Expected behavior: https://bugs.php.net/fix.php?id=60925r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60925r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60925r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60925r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60925r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60925r=dst IIS Stability: https://bugs.php.net/fix.php?id=60925r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60925r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60925r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60925r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60925r=mysqlcfg
[PHP-BUG] Bug #60927 [NEW]: Recursive functions for preg_replace_callback causes SEGFAULT
From:
Operating system: Ubuntu 11.04
PHP version: 5.3.9
Package: PCRE related
Bug Type: Bug
Bug description:Recursive functions for preg_replace_callback causes SEGFAULT
Description:
Using recursive functions for preg_replace_callback that never ends PHP
will exit with a SEGFAULT (unexpected signal 11) due to a function stack
overflow.
It's expected that it should never end and therefore PHP should abort the
execution. However PHP should output a helpful error message rather than
just aborting it. Depending on your code this could be a major issue to
debug. (I was using Drupal and it look me hours to find the source.)
Test script:
---
?php
function a() {
b();
}
function b() {
a();
}
preg_replace_callback(/0/s, 'a', 0);
echo We made it my friend!;
Expected result:
Some sort of error message that the callback stack limit has been reached.
Actual result:
--
A 500 Internal Server error (Apache with mod_fcgid) and a SEGFAULT in the
error log.
--
Edit bug report at https://bugs.php.net/bug.php?id=60927edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60927r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60927r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60927r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60927r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60927r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60927r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60927r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60927r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60927r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60927r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60927r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60927r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60927r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60927r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60927r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60927r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60927r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60927r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60927r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60927r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60927r=mysqlcfg
Bug #60927 [Opn-]: Recursive functions for preg_replace_callback causes SEGFAULT
Edit report at https://bugs.php.net/bug.php?id=60927edit=1
ID: 60927
Updated by: johan...@php.net
Reported by:jimmy at axenhus dot com
Summary:Recursive functions for preg_replace_callback causes
SEGFAULT
-Status: Open
+Status: Bogus
Type: Bug
Package:PCRE related
Operating System: Ubuntu 11.04
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Recursion ends in a stack overflow. A stack overflow makes the operating system
kill the process.
Previous Comments:
[2012-01-29 19:33:01] jimmy at axenhus dot com
Description:
Using recursive functions for preg_replace_callback that never ends PHP will
exit with a SEGFAULT (unexpected signal 11) due to a function stack overflow.
It's expected that it should never end and therefore PHP should abort the
execution. However PHP should output a helpful error message rather than just
aborting it. Depending on your code this could be a major issue to debug. (I
was using Drupal and it look me hours to find the source.)
Test script:
---
?php
function a() {
b();
}
function b() {
a();
}
preg_replace_callback(/0/s, 'a', 0);
echo We made it my friend!;
Expected result:
Some sort of error message that the callback stack limit has been reached.
Actual result:
--
A 500 Internal Server error (Apache with mod_fcgid) and a SEGFAULT in the error
log.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60927edit=1
Bug #60927 [-Nab]: Recursive functions for preg_replace_callback causes SEGFAULT
Edit report at https://bugs.php.net/bug.php?id=60927edit=1
ID: 60927
Updated by: johan...@php.net
Reported by:jimmy at axenhus dot com
Summary:Recursive functions for preg_replace_callback causes
SEGFAULT
-Status: Bogus
+Status: Not a bug
Type: Bug
Package:PCRE related
Operating System: Ubuntu 11.04
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
.
Previous Comments:
[2012-01-29 19:47:53] johan...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Recursion ends in a stack overflow. A stack overflow makes the operating system
kill the process.
[2012-01-29 19:33:01] jimmy at axenhus dot com
Description:
Using recursive functions for preg_replace_callback that never ends PHP will
exit with a SEGFAULT (unexpected signal 11) due to a function stack overflow.
It's expected that it should never end and therefore PHP should abort the
execution. However PHP should output a helpful error message rather than just
aborting it. Depending on your code this could be a major issue to debug. (I
was using Drupal and it look me hours to find the source.)
Test script:
---
?php
function a() {
b();
}
function b() {
a();
}
preg_replace_callback(/0/s, 'a', 0);
echo We made it my friend!;
Expected result:
Some sort of error message that the callback stack limit has been reached.
Actual result:
--
A 500 Internal Server error (Apache with mod_fcgid) and a SEGFAULT in the error
log.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60927edit=1
[PHP-BUG] Bug #60928 [NEW]: php crash after http post without content type header set
From: Operating system: Linux PHP version: 5.3.9 Package: Apache2 related Bug Type: Bug Bug description:php crash after http post without content type header set Description: I wrote some software which post a binary (image) to our server. phplib crashes at the end of a http post without the content type header set. Version apache: [root@www ~]# /usr/sbin/httpd -V Server version: Apache/2.2.3 Server built: Oct 20 2011 17:00:12 Server's Module Magic Number: 20051115:3 Server loaded: APR 1.2.7, APR-Util 1.2.7 Compiled using: APR 1.2.7, APR-Util 1.2.7 Architecture: 64-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT=/etc/httpd -D SUEXEC_BIN=/usr/sbin/suexec -D DEFAULT_PIDLOG=run/httpd.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_LOCKFILE=logs/accept.lock -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf On kill/error/fault I found in error_log: Sat Jan 28 12:56:09 2012] [notice] child pid 17077 exit signal Segmentation fault (11), possible coredump in /tmp So made a coredump: gdb: bt all: [sorry, no debug mode, its commercial server, can't recompile etc] Core was generated by `/usr/sbin/httpd -k start'. Program terminated with signal 11, Segmentation fault. #0 0x7fe25c5696c0 in zend_hash_num_elements () from /etc/httpd/modules/libphp5.so (gdb) bt full #0 0x7fe25c5696c0 in zend_hash_num_elements () from /etc/httpd/modules/libphp5.so No symbol table info available. #1 0x7fe25c519606 in php_register_variable_ex () from /etc/httpd/modules/libphp5.so No symbol table info available. #2 0x7fe25c432625 in ?? () from /etc/httpd/modules/libphp5.so No symbol table info available. #3 0x7fe25c51a0e9 in php_std_post_handler () from /etc/httpd/modules/libphp5.so No symbol table info available. #4 0x7fe25c513dd3 in sapi_handle_post () from /etc/httpd/modules/libphp5.so No symbol table info available. #5 0x7fe25c519d2b in php_default_treat_data () from /etc/httpd/modules/libphp5.so No symbol table info available. #6 0x7fe257248134 in mbstr_treat_data () from /usr/lib64/php/modules/mbstring.so No symbol table info available. #7 0x7fe25c51a2a1 in ?? () from /etc/httpd/modules/libphp5.so No symbol table info available. #8 0x7fe25c50ab65 in php_request_startup () from /etc/httpd/modules/libphp5.so No symbol table info available. #9 0x7fe25c5e66d8 in ?? () from /etc/httpd/modules/libphp5.so No symbol table info available. #10 0x7fe268e89aca in ap_run_handler () No symbol table info available. #11 0x7fe268e8cf58 in ap_invoke_handler () No symbol table info available. #12 0x7fe268e97a18 in ap_process_request () No symbol table info available. #13 0x7fe268e94c50 in ?? () No symbol table info available. #14 0x7fe268e90d52 in ap_run_process_connection () No symbol table info available. #15 0x7fe268e9be49 in ?? () No symbol table info available. #16 0x7fe268e9c0da in ?? () No symbol table info available. #17 0x7fe268e9c190 in ?? () No symbol table info available. #18 0x7fe268e9ce7b in ap_mpm_run () No symbol table info available. #19 0x7fe268e76e48 in main () No symbol table info available. Test script: --- Qt source for posting binary without content type set: QString filename = QFileDialog::getOpenFileName(this); QFile* f = new QFile(filename); f-open(QFile::ReadOnly); QNetworkAccessManager* manager = new QNetworkAccessManager(this); QNetworkRequest req(QUrl(http://www.server.com/post.php;)); // uncomment line below for bypassing error // req.setHeader(QNetworkRequest::ContentTypeHeader,image/jpeg); QNetworkReply* rep = manager-post(req,f); f-setParent(rep); -- Edit bug report at https://bugs.php.net/bug.php?id=60928edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60928r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60928r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60928r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60928r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60928r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60928r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60928r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60928r=needscript Try newer version:
Bug #60928 [Opn-Fbk]: php crash after http post without content type header set
Edit report at https://bugs.php.net/bug.php?id=60928edit=1 ID: 60928 Updated by: paj...@php.net Reported by:bardobakker at gmail dot com Summary:php crash after http post without content type header set -Status: Open +Status: Feedback Type: Bug Package:Apache2 related Operating System: Linux PHP Version:5.3.9 Block user comment: N Private report: N New Comment: 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 ?php and ends 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. Previous Comments: [2012-01-29 22:31:10] bardobakker at gmail dot com Description: I wrote some software which post a binary (image) to our server. phplib crashes at the end of a http post without the content type header set. Version apache: [root@www ~]# /usr/sbin/httpd -V Server version: Apache/2.2.3 Server built: Oct 20 2011 17:00:12 Server's Module Magic Number: 20051115:3 Server loaded: APR 1.2.7, APR-Util 1.2.7 Compiled using: APR 1.2.7, APR-Util 1.2.7 Architecture: 64-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT=/etc/httpd -D SUEXEC_BIN=/usr/sbin/suexec -D DEFAULT_PIDLOG=run/httpd.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_LOCKFILE=logs/accept.lock -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf On kill/error/fault I found in error_log: Sat Jan 28 12:56:09 2012] [notice] child pid 17077 exit signal Segmentation fault (11), possible coredump in /tmp So made a coredump: gdb: bt all: [sorry, no debug mode, its commercial server, can't recompile etc] Core was generated by `/usr/sbin/httpd -k start'. Program terminated with signal 11, Segmentation fault. #0 0x7fe25c5696c0 in zend_hash_num_elements () from /etc/httpd/modules/libphp5.so (gdb) bt full #0 0x7fe25c5696c0 in zend_hash_num_elements () from /etc/httpd/modules/libphp5.so No symbol table info available. #1 0x7fe25c519606 in php_register_variable_ex () from /etc/httpd/modules/libphp5.so No symbol table info available. #2 0x7fe25c432625 in ?? () from /etc/httpd/modules/libphp5.so No symbol table info available. #3 0x7fe25c51a0e9 in php_std_post_handler () from /etc/httpd/modules/libphp5.so No symbol table info available. #4 0x7fe25c513dd3 in sapi_handle_post () from /etc/httpd/modules/libphp5.so No symbol table info available. #5 0x7fe25c519d2b in php_default_treat_data () from /etc/httpd/modules/libphp5.so No symbol table info available. #6 0x7fe257248134 in mbstr_treat_data () from /usr/lib64/php/modules/mbstring.so No symbol table info available. #7 0x7fe25c51a2a1 in ?? () from /etc/httpd/modules/libphp5.so No symbol table info available. #8 0x7fe25c50ab65 in php_request_startup () from /etc/httpd/modules/libphp5.so No symbol table info available. #9 0x7fe25c5e66d8 in ?? () from /etc/httpd/modules/libphp5.so No symbol table info available. #10 0x7fe268e89aca in ap_run_handler () No symbol table info available. #11 0x7fe268e8cf58 in ap_invoke_handler () No symbol table info available. #12 0x7fe268e97a18 in ap_process_request () No symbol table info available. #13 0x7fe268e94c50 in ?? () No symbol table info available. #14 0x7fe268e90d52 in ap_run_process_connection () No symbol table info available. #15 0x7fe268e9be49 in ?? () No symbol table info available. #16 0x7fe268e9c0da in ?? () No symbol table info available. #17 0x7fe268e9c190 in ?? () No symbol table info available. #18 0x7fe268e9ce7b in ap_mpm_run () No symbol table info available. #19 0x7fe268e76e48 in main () No symbol table info available. Test script: --- Qt source for posting binary without content type set: QString filename = QFileDialog::getOpenFileName(this); QFile* f = new QFile(filename); f-open(QFile::ReadOnly); QNetworkAccessManager* manager = new QNetworkAccessManager(this); QNetworkRequest req(QUrl(http://www.server.com/post.php;)); // uncomment line below for bypassing error //
[PHP-BUG] Bug #60930 [NEW]: PDO exec
From: Operating system: Ubuntu 11.10 64bits PHP version: 5.3.9 Package: PDO related Bug Type: Bug Bug description:PDO exec Description: SQL statement that return or should return a statement could leave an open cursor that cannot be closed. This bug is related to the following previous reports https://bugs.php.net/bug.php?id=36347 https://bugs.php.net/bug.php?id=34499 https://bugs.php.net/bug.php?id=42499 It's been reported that sql statement that do return result could cause this issue in non trivial situations. This report also highlight that statement returning empty result set could also cause the issue. Test script: --- $dbh = new PDO(mysql:your connection string, '', ''); echo $dbh-exec(SELECT * FROM cube where false); echo $dbh-exec(SELECT * FROM cube where false); print_r($dbh-errorInfo()); Expected result: 00 Actual result: -- 0Array ( [0] = HY000 [1] = 2014 [2] = Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO:: MYSQL_ATTR_USE_BUFFERED_QUERY attribute. ) -- Edit bug report at https://bugs.php.net/bug.php?id=60930edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60930r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60930r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60930r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60930r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60930r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60930r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60930r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60930r=needscript Try newer version: https://bugs.php.net/fix.php?id=60930r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60930r=support Expected behavior: https://bugs.php.net/fix.php?id=60930r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60930r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60930r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60930r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60930r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60930r=dst IIS Stability: https://bugs.php.net/fix.php?id=60930r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60930r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60930r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60930r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60930r=mysqlcfg
Req #50802 [Com]: Allow disable_functions in httpd.conf
Edit report at https://bugs.php.net/bug.php?id=50802edit=1 ID: 50802 Comment by: k dot reznichak at pcpin dot com Reported by:h dot reindl at thelounge dot net Summary:Allow disable_functions in httpd.conf Status: Wont fix Type: Feature/Change Request Package:Feature/Change Request Operating System: All PHP Version:5.2.12 Block user comment: N Private report: N New Comment: Hello, any updates here? Doesn't matter if suhosin-like or any other way, this feature would dramatically simplify server administration and reduce costs. My current solution with different apache instances listening on different ports via proxy was pain to set up and hurts every time I manage it. Please consider that some admins just going easy way by enabling sensitive functions globally for all virtual hosts causing security risk. That does not means PHP is insecure by itself, however it encourages people to act insecure. Kind Regards Previous Comments: [2010-01-29 15:45:08] h dot reindl at thelounge dot net Suhosin doesn't disable functions. It adds a separate blacklist mechanism. Yes, and it works fine This bug was about being able to do per-request disabling with the existing disable_function mechanism. And shows that the existing mechnism is poorly implemented if you need a extension to make a SECURITY-SETTING usable which is able to do nearly the same and would not be needed if the php-core does handle this better [2010-01-29 15:39:30] ras...@php.net Suhosin doesn't disable functions. It adds a separate blacklist mechanism. This bug was about being able to do per-request disabling with the existing disable_function mechanism. [2010-01-29 14:43:51] h dot reindl at thelounge dot net http://www.webhostingtalk.com/showthread.php?t=623944 If it is not possible because performance why it works with suhosin-extension perfectly with the only problem that function_exists() does not realize the suhosin setting? Sorry, but this sounds like it's possible but i say is not because i do not like to touch the code [2010-01-19 20:47:32] h dot reindl at thelounge dot net Hm very bad - so i have three choises * allow a function i would never like on all hosts * make a own httpd-instance for 2 vhosts * change the whole company-infrastructure especially adminpanel The performance hit would be way too high About what time-gain are we speaking? I can not believe that refresh this list takes a really long time With open_basedir it works also and you have to check this before every fs-operation - where is the difference and would it not make sense to look how to optimize initalizing the functon table? I agree with you that the phpinfo() out is misleading, but that's not what you filed a bug about. Of course i have because i saw this day that a function is active that should not and i never ever would have configured the machine this way if phpinfo() had not shown me that the configuration is active [2010-01-19 20:37:26] ras...@php.net Of course it is per-request. The same Apache/PHP process will handle different virtual hosts from one request to the next. Allowing per- dir/per-vhost changing of the function table would mean we have to reload the function table on each and every request. I agree with you that the phpinfo() out is misleading, but that's not what you filed a bug about. 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=50802 -- Edit this bug report at https://bugs.php.net/bug.php?id=50802edit=1
Bug #60758 [Com]: require() crashes Apache
Edit report at https://bugs.php.net/bug.php?id=60758edit=1
ID: 60758
Comment by: homma dot teppei+php at gmail dot com
Reported by:bugzilla33 at gmail dot com
Summary:require() crashes Apache
Status: Not a bug
Type: Bug
Package:Reproducible crash
Operating System: Windows
PHP Version:5.4.0RC5
Block user comment: N
Private report: N
New Comment:
The same problem occurred with CLI version.
The file to be 'include' (or 'require'), PHP will crash if its size is
multiples
of 4096 bytes.
OS:
both Windows 7 Professional (x64) and Windows 7 Home Premium (32bit)
PHP:
5.3.9 (thread safe, with no extension)
Test case:
First of all, I prepared the file is filled with 4096bytes white spaces.
And save as 'test.txt'.
with command prompt
c:\php-sdk\ php.exe -a
?php
require 'test.txt';
^Z[Ctrl+z enter]
- then crash.
another case:
test.php
?php
file_put_contents('test.txt', str_pad('', 4096));
include('./test.txt');
?
with command prompt
c:\php-sdk\ php.exe test.php
- then crash.
Call Stack:
php5ts_debug.dll!lex_scan(_zval_struct * zendlval, void * * * tsrm_ls)
line 942 + 0x12 bytes C
php5ts_debug.dll!zendlex(_znode * zendlval, void * * * tsrm_ls) line
4975 + 0x10 bytes C
php5ts_debug.dll!zendparse(void * tsrm_ls) line 3285 + 0xd bytes
C
php5ts_debug.dll!compile_file(_zend_file_handle * file_handle, int
type,
void * * * tsrm_ls) line 364 + 0x9 bytes C
php5ts_debug.dll!compile_filename(int type, _zval_struct * filename,
void * * * tsrm_ls) line 407 + 0x14 bytes C
php5ts_debug.dll!ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER(_zend_execute_data *
execute_data, void * * * tsrm_ls) line
1966 + 0x14 bytes C
php5ts_debug.dll!execute(_zend_op_array * op_array, void * * * tsrm_ls)
line 107 + 0x11 bytes C
php5ts_debug.dll!zend_execute_scripts(int type, void * * * tsrm_ls,
_zval_struct * * retval, int file_count, ...) line
1236 + 0x21 bytes C
php5ts_debug.dll!php_execute_script(_zend_file_handle * primary_file,
void * * * tsrm_ls) line 2308 + 0x1b bytes C
php.exe!main(int argc, char * * argv) line 1184 + 0x13 bytes C
php.exe!__tmainCRTStartup() line 555 + 0x19 bytes C
php.exe!mainCRTStartup() line 371 C
kernel32.dll!7718339a()
Previous Comments:
[2012-01-28 09:35:49] paj...@php.net
There is no bug, sadly he is spamming bugs.php.net with crash bugs which are
actually configuration issues.
[2012-01-28 00:47:48] ras...@php.net
Works fine on Linux. Doesn't seem like this should be an OS-specific thing. Can
anybody else reproduce this on Windows?
[2012-01-16 18:18:41] bugzilla33 at gmail dot com
Here you are:
http://host0001.webd.pl/bugs/php/reports/CrashHang_Report__PID_1080__01162012191518294.zip
[2012-01-15 10:08:14] bugzilla33 at gmail dot com
Thank you for this manual.
https://bugs.php.net/bugs-generating-backtrace-win32.php
This tool works on Win 7 only as (Analisys only) mode.
Options and settings tab looks otherwise.
There is no Add a rule button.
Please update the handbook as soon as possible.
---
Does anybody can do backtrace for laruence ??
[2012-01-15 03:30:56] larue...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
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=60758
--
Edit this bug report at https://bugs.php.net/bug.php?id=60758edit=1
Req #60926 [Com]: LIFO/FIFO iterator modes for priority queues
Edit report at https://bugs.php.net/bug.php?id=60926edit=1
ID: 60926
Comment by: carloschilazo at gmail dot com
Reported by:franssen dot roland at gmail dot com
Summary:LIFO/FIFO iterator modes for priority queues
Status: Open
Type: Feature/Change Request
Package:SPL related
Operating System: Ubuntu
PHP Version:5.4.0RC6
Block user comment: N
Private report: N
New Comment:
I believe this goes against the definition of a priority queue, if you insert
them
with the same priority then it really does not matter which one comes first...
I understand what you are asking, but if you need them like that then you could
maybe use another data structure or a mixture, or user different priorities..
Previous Comments:
[2012-01-29 19:31:07] franssen dot roland at gmail dot com
Description:
PHP version is actually PHP5.4RC3
It would be nice to be able to maintain the input order in a SPL priority queue
when multiple values share the same priority.
E.g. FIFO and LIFO
The current mode is neither one of these. I guess this is best
peformance-wise but sometimes you want to be explicitly, for instance when
registering event listeners; you expect them to run in order.
Test script:
---
?php
$queue = new \SplPriorityQueue;
$queue-insert('a', 100);
$queue-insert('b', 100);
$queue-insert('c', 110);
$queue-insert('d', 90);
foreach($queue as $element) {
var_dump($element);
echo 'br';
}
echo 'br';
$queue2 = new \SplPriorityQueue;
$queue2-insert('a', 100);
$queue2-insert('b', 100);
foreach($queue2 as $element) {
var_dump($element);
echo 'br';
}
Expected result:
string(1) c
string(1) a
string(1) b
string(1) d
string(1) a
string(1) b
Actual result:
--
string(1) c
string(1) b
string(1) a
string(1) d
string(1) a
string(1) b
--
Edit this bug report at https://bugs.php.net/bug.php?id=60926edit=1
Bug #60627 [Fbk]: httpd.worker segfault on startup with php_value
Edit report at https://bugs.php.net/bug.php?id=60627edit=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: 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: weird, does anyone else can reproduce this with the latest snap yet? Previous Comments: [2012-01-05 20:07:55] public at wernig dot net 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 [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 copypaste? 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? 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=60627edit=1
[PHP-BUG] Bug #60931 [NEW]: Entity handling for value in setAttribute() and createElement() differ
From:
Operating system: Windows
PHP version: 5.3.9
Package: DOM XML related
Bug Type: Bug
Bug description:Entity handling for value in setAttribute() and createElement()
differ
Description:
Two identical input values with entities create different results depending
if they're inserted as element or attribute into the DOM tree.
Entity handling differs as seen in the output below.
Test script:
---
define ('VAL','index.php?e=tamp;c=au');
$dd = new DOMDocument('1.0', 'UTF-8');
$root = $dd-createElement('root');
$href= $dd-createElement('href',VAL);
$root-setAttribute('href',VAL);
$root-appendChild($href);
$dd-appendChild($root);
echo $dd-saveXML();
Expected result:
?xml version=1.0 encoding=UTF-8?
root
href=index.php?e=tamp;c=auhrefindex.php?e=tamp;c=au/href/root
Actual result:
--
?xml version=1.0 encoding=UTF-8?
root
href=index.php?e=tamp;amp;c=auhrefindex.php?e=tamp;c=au/href/root
--
Edit bug report at https://bugs.php.net/bug.php?id=60931edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60931r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60931r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60931r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60931r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60931r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60931r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60931r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60931r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60931r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60931r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60931r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60931r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60931r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60931r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60931r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60931r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60931r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60931r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60931r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60931r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60931r=mysqlcfg
Bug #60931 [Opn-Nab]: Entity handling for value in setAttribute() and createElement() differ
Edit report at https://bugs.php.net/bug.php?id=60931edit=1
ID: 60931
Updated by: ahar...@php.net
Reported by:hrpeters at gmx dot net
Summary:Entity handling for value in setAttribute() and
createElement() differ
-Status: Open
+Status: Not a bug
Type: Bug
Package:DOM XML related
Operating System: Windows
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is documented behaviour, per the notes at
http://au2.php.net/domdocument.createElement -- the node value is not escaped
if
you use the non-standard shorthand in the createElement() method.
Previous Comments:
[2012-01-30 04:06:00] hrpeters at gmx dot net
Description:
Two identical input values with entities create different results depending if
they're inserted as element or attribute into the DOM tree.
Entity handling differs as seen in the output below.
Test script:
---
define ('VAL','index.php?e=tamp;c=au');
$dd = new DOMDocument('1.0', 'UTF-8');
$root = $dd-createElement('root');
$href= $dd-createElement('href',VAL);
$root-setAttribute('href',VAL);
$root-appendChild($href);
$dd-appendChild($root);
echo $dd-saveXML();
Expected result:
?xml version=1.0 encoding=UTF-8?
root href=index.php?e=tamp;c=auhrefindex.php?e=tamp;c=au/href/root
Actual result:
--
?xml version=1.0 encoding=UTF-8?
root
href=index.php?e=tamp;amp;c=auhrefindex.php?e=tamp;c=au/href/root
--
Edit this bug report at https://bugs.php.net/bug.php?id=60931edit=1
Bug #51558 [Com]: configuration script fails at building readline shared library module
Edit report at https://bugs.php.net/bug.php?id=51558edit=1 ID: 51558 Comment by: lzsiga at freemail dot c3 dot hu Reported by:cremator at mail dot bg Summary:configuration script fails at building readline shared library module Status: Open Type: Bug Package:Compile Failure Operating System: AIX 5.3 oslevel -r 5300-11 PHP Version:5.3, 5.4, trunk Block user comment: N Private report: N New Comment: Basically the problem is that ./configure checks for function 'rl_pending_input', which happens to be a variable. In AIX variables and functions are exported differently, so the detection fails. In Aix, functions and variables are exported differently, which prevents ld from resolving a variable as a function. nm -Bgx /usr/local/lib/libreadline.so | grep rl_pending_input # variable 0x20003338 D rl_pending_input nm -Bgx /usr/local/lib/libreadline.so | grep rl_yank_pop # function 0x10031acc T .rl_yank_pop 0x20003f58 D rl_yank_pop (So it is only 'D' for variables, both 'T' and 'D' for functions.) Previous Comments: [2012-01-27 21:09:31] fel...@php.net We got a new feedback from another reported bug related to this issue: Bug #60881 readline detection fails because of rl_pending_input variable [2010-06-08 14:13:28] tony2...@php.net What's in your config.log? I do not mean to paste it all, but I need to see the parts related to readline and rl_pending_input() in particular. Put config.log online, if possible. I guess your lib is broken or was built in a wrong way. [2010-04-15 10:50:05] cremator at mail dot bg Description: readline shared library 6.0 has been build on aix with gcc 4.2.0, gnu make 3.80, shared library ncurses 5.7, following a bit the guide at http://www.tekwire.net/joomla/building/apache/http_AIX_5.2.htm#p2.29 Everything seems to be working except that readline.h include file doesn't cope well with php 5.3.2 configure script. After downgrade php to 5.2.6 and patching it for openssl 1.0 everything works like it should. excuse my bad english and my less than little knowledge in coding Expected result: Thank you for using PHP. Actual result: -- checking for libedit readline replacement... no checking for readline support... yes, shared checking for tgetent in -lncurses... yes checking for readline in -lreadline... yes checking for rl_pending_input in -lreadline... no configure: error: invalid readline installation detected. Try --with-libedit instead. -- Edit this bug report at https://bugs.php.net/bug.php?id=51558edit=1
Bug #60881 [Dup-Csd]: readline detection fails because of rl_pending_input variable
Edit report at https://bugs.php.net/bug.php?id=60881edit=1 ID: 60881 User updated by:lzsiga at freemail dot c3 dot hu Reported by:lzsiga at freemail dot c3 dot hu Summary:readline detection fails because of rl_pending_input variable -Status: Duplicate +Status: Closed Type: Bug Package:*Compile Issues Operating System: aix PHP Version:5.3.9 Block user comment: N Private report: N New Comment: Closed as being duplicate. Previous Comments: [2012-01-27 21:08:00] fel...@php.net So it's just the same problem reported in bug #51558. Closing this one, let use the first reported one. Thanks for reporting! [2012-01-25 13:51:31] lzsiga at freemail dot c3 dot hu Description: Well, ./configure checks for function 'rl_pending_input', which happens to be a variable. In AIX variables and functions are exported differently, so the detection fails. My quick fix: sed_repl 's;rl_pending_input();rl_pending_input;g' configure -- Edit this bug report at https://bugs.php.net/bug.php?id=60881edit=1
Bug #52003 [Com]: Incorrect PDOStatement::execute() signature
Edit report at https://bugs.php.net/bug.php?id=52003edit=1
ID: 52003
Comment by: larry at ldrutledge dot com
Reported by:v1d4l0k4 at gmail dot com
Summary:Incorrect PDOStatement::execute() signature
Status: Assigned
Type: Bug
Package:PDO related
Operating System: Irrelevant
PHP Version:Irrelevant
Assigned To:pierrick
Block user comment: N
Private report: N
New Comment:
The situation appears to be unchanged in 5.3.9. The manual still shows a type
hint of array but a method in an extended class still triggers a warning unless
the type hint is omitted.
Previous Comments:
[2010-10-19 07:07:17] ka...@php.net
Pierrick, why don't you commit that patch the src? And add a changelog entry if
reasonable for PDOStatement::execute() :)
[2010-06-06 06:13:42] pierr...@php.net
The following patch has been added/updated:
Patch Name: ZEND_ARG_ARRAY_INFO
Revision: 1275797622
URL:
http://bugs.php.net/patch-display.php?bug=52003patch=ZEND_ARG_ARRAY_INFOrevision=1275797622
[2010-06-05 22:53:10] v1d4l0k4 at gmail dot com
Description:
Manual says PDOStatement::execute() signature is:
bool PDOStatement::execute ([ array $input_parameters = array() ] )
But in fact it is:
bool PDOStatement::execute ([ $input_parameters = null ] )
Test script:
---
?php
class DBStatement extends PDOStatement
{
public function execute(array $input_parameters = array())
{
return parent::execute($input_parameters);
}
}
$PDO = new PDO('mysql:host=127.0.0.1', 'root', '');
$PDO-setAttribute(PDO::ATTR_STATEMENT_CLASS, array('DBStatement'));
Expected result:
No errors
Actual result:
--
Strict Standards: Declaration of DBStatement::execute() should be compatible
with that of PDOStatement::execute() in /media/ext/Web/htdocs/test/bug.php on
line 9
--
Edit this bug report at https://bugs.php.net/bug.php?id=52003edit=1
Bug #60901 [Com]: Oracle-11.2 is not detected (too new)
Edit report at https://bugs.php.net/bug.php?id=60901edit=1 ID: 60901 Comment by: lzsiga at freemail dot c3 dot hu Reported by:lzsiga at freemail dot c3 dot hu Summary:Oracle-11.2 is not detected (too new) Status: Feedback Type: Bug Package:OCI8 related Operating System: AIX 6.1 PHP Version:5.3.9 Block user comment: N Private report: N New Comment: It might work, but I wouldn't want to hack around in the Oracle's directory... could you please add an option to ./configure prevent the version-autodetecting? Something like: OCI8_VERSION=11.2 ./configure --with-oci8 or export OCI8_VERSION=$(grep OCI_MAJOR_VERSION $ORACLE_HOME/rdbms/public/oci.h | cut -d' ' -f 4).$(grep OCI_MINOR_VERSION $ORACLE_HOME/rdbms/public/oci.h | cut -d' ' -f 4) ./configure --with-oci8 Previous Comments: [2012-01-27 20:47:04] s...@php.net Instead of patching the configuration script can you try creating a symbolic link from libclntsh.so and/or libclntsh.so.11.1 pointing to libclntsh.so.11.2? For ORACLE_HOME installs on Linux (and likely on Solaris) a symbolic link from libclntsh.so to libclntsh.so.11.1 is automatically created during Oracle installation. Linux Solaris 11.2 Instant Client zip installs provide libclntsh.so.11.1 (for drop-in library replacement similar to how Oracle 10.2 libs were called *.10.1). Generic installation instructions for Instant Client are to manually create a symbolic link from libclntsh.so to libclntsh.so.11.1 [2012-01-27 13:21:12] lzsiga at freemail dot c3 dot hu Quick fix: sed_repl 's: if test -s $OCI8_DIR/orainst/unix.rgs; then:'\ ' if test -s $OCI8_LCS_BASE.11.2; then\nOCI8_ORACLE_VERSION=11.2;\n'\ ' elif test -s $OCI8_DIR/orainst/unix.rgs; then:' configure [2012-01-27 12:31:13] lzsiga at freemail dot c3 dot hu Description: $ ls $ORACLE_HOME/lib32/libclntsh.so.*.1 configure tries this and fails, beacuse the Oracle version is 11.2 $ ls $ORACLE_HOME/lib32/libclntsh.so.*.2 /lib32/libclntsh.so.11.2 -- Edit this bug report at https://bugs.php.net/bug.php?id=60901edit=1
Bug #60881 [Csd-Dup]: readline detection fails because of rl_pending_input variable
Edit report at https://bugs.php.net/bug.php?id=60881edit=1 ID: 60881 Updated by: ahar...@php.net Reported by:lzsiga at freemail dot c3 dot hu Summary:readline detection fails because of rl_pending_input variable -Status: Closed +Status: Duplicate Type: Bug Package:*Compile Issues Operating System: aix PHP Version:5.3.9 Block user comment: N Private report: N New Comment: It was already closed. :) Previous Comments: [2012-01-30 05:43:20] lzsiga at freemail dot c3 dot hu Closed as being duplicate. [2012-01-27 21:08:00] fel...@php.net So it's just the same problem reported in bug #51558. Closing this one, let use the first reported one. Thanks for reporting! [2012-01-25 13:51:31] lzsiga at freemail dot c3 dot hu Description: Well, ./configure checks for function 'rl_pending_input', which happens to be a variable. In AIX variables and functions are exported differently, so the detection fails. My quick fix: sed_repl 's;rl_pending_input();rl_pending_input;g' configure -- Edit this bug report at https://bugs.php.net/bug.php?id=60881edit=1
Bug #60928 [Fbk-Opn]: php crash after http post without content type header set
Edit report at https://bugs.php.net/bug.php?id=60928edit=1 ID: 60928 User updated by:bardobakker at gmail dot com Reported by:bardobakker at gmail dot com Summary:php crash after http post without content type header set -Status: Feedback +Status: Open Type: Bug Package:Apache2 related Operating System: Linux PHP Version:5.3.9 Block user comment: N Private report: N New Comment: I already posted the c++ code (Qt) I use to do the post without content type header. I do not know a second way to do a similar post. One can use a empty php file to post to, even than it will crash: ?php ? But the lines i use to read the raw post data: ?php //load raw post $data = file_get_contents(php://input); //(current dir is writable) $handle = fopen(./file.jpg, w); fwrite($handle, $data); fclose($handle); ? Previous Comments: [2012-01-29 23:48:34] paj...@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 ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2012-01-29 22:31:10] bardobakker at gmail dot com Description: I wrote some software which post a binary (image) to our server. phplib crashes at the end of a http post without the content type header set. Version apache: [root@www ~]# /usr/sbin/httpd -V Server version: Apache/2.2.3 Server built: Oct 20 2011 17:00:12 Server's Module Magic Number: 20051115:3 Server loaded: APR 1.2.7, APR-Util 1.2.7 Compiled using: APR 1.2.7, APR-Util 1.2.7 Architecture: 64-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT=/etc/httpd -D SUEXEC_BIN=/usr/sbin/suexec -D DEFAULT_PIDLOG=run/httpd.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_LOCKFILE=logs/accept.lock -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf On kill/error/fault I found in error_log: Sat Jan 28 12:56:09 2012] [notice] child pid 17077 exit signal Segmentation fault (11), possible coredump in /tmp So made a coredump: gdb: bt all: [sorry, no debug mode, its commercial server, can't recompile etc] Core was generated by `/usr/sbin/httpd -k start'. Program terminated with signal 11, Segmentation fault. #0 0x7fe25c5696c0 in zend_hash_num_elements () from /etc/httpd/modules/libphp5.so (gdb) bt full #0 0x7fe25c5696c0 in zend_hash_num_elements () from /etc/httpd/modules/libphp5.so No symbol table info available. #1 0x7fe25c519606 in php_register_variable_ex () from /etc/httpd/modules/libphp5.so No symbol table info available. #2 0x7fe25c432625 in ?? () from /etc/httpd/modules/libphp5.so No symbol table info available. #3 0x7fe25c51a0e9 in php_std_post_handler () from /etc/httpd/modules/libphp5.so No symbol table info available. #4 0x7fe25c513dd3 in sapi_handle_post () from /etc/httpd/modules/libphp5.so No symbol table info available. #5 0x7fe25c519d2b in php_default_treat_data () from /etc/httpd/modules/libphp5.so No symbol table info available. #6 0x7fe257248134 in mbstr_treat_data () from /usr/lib64/php/modules/mbstring.so No symbol table info available. #7 0x7fe25c51a2a1 in ?? () from /etc/httpd/modules/libphp5.so No symbol table info available. #8 0x7fe25c50ab65 in php_request_startup () from /etc/httpd/modules/libphp5.so No symbol table info available. #9 0x7fe25c5e66d8 in ?? () from /etc/httpd/modules/libphp5.so No symbol table info available. #10 0x7fe268e89aca in ap_run_handler () No symbol table info available. #11 0x7fe268e8cf58 in ap_invoke_handler () No symbol table info available. #12 0x7fe268e97a18 in ap_process_request () No symbol table info available. #13 0x7fe268e94c50 in ?? () No symbol table info available. #14 0x7fe268e90d52 in ap_run_process_connection () No symbol table info available. #15 0x7fe268e9be49 in ?? () No symbol table info available. #16 0x7fe268e9c0da in ?? () No symbol table info available. #17 0x7fe268e9c190 in ?? ()
[PHP-BUG] Bug #60932 [NEW]: array_diff_assoc not working as expected.
From:
Operating system: MAC OSX 10.6.8
PHP version: 5.3.9
Package: *General Issues
Bug Type: Bug
Bug description:array_diff_assoc not working as expected.
Description:
The first key/value pair should, in theory, not be present in the result
array.
Test script:
---
$arrayAssoc1 = array(
'one' = '1: some val',
'two' = '1: another val',
'three' = '1: and another val',
'four' = '1: fourth val',
'five' = '1: fifth val',
'six' = '1: sixth param',
'seven' = '1: sixth param',
'starwars' = '2: lightsaber'
);
$arrayAssoc2 = array(
'one' = '1: some val',
'two' = '1: another val',
'three' = '1: and another val',
'one' = '2: some val',
'five' = '1: fifth val',
'three' = '2: and another val',
'seven' = '2: and another val',
'starwars' = '2: lightsaber'
);
var_dump(array_diff_assoc($arrayAssoc1, $arrayAssoc2));
Expected result:
array(5) {
[three] = string(18) 1: and another val
[four] = string(13) 1: fourth val
[six] = string(14) 1: sixth param
[seven] = string(14) 1: sixth param
}
Actual result:
--
array(5) {
[one] = string(11) 1: some val
[three] = string(18) 1: and another val
[four] = string(13) 1: fourth val
[six] = string(14) 1: sixth param
[seven] = string(14) 1: sixth param
}
--
Edit bug report at https://bugs.php.net/bug.php?id=60932edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60932r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60932r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60932r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60932r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60932r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60932r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60932r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60932r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60932r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60932r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60932r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60932r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60932r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60932r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60932r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60932r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60932r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60932r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60932r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60932r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60932r=mysqlcfg
