Bug #52562 [Fbk->Bgs]: Crash when using $GLOBALS
Edit report at http://bugs.php.net/bug.php?id=52562&edit=1 ID: 52562 Updated by: fel...@php.net Reported by:nick at witthaus dot com Summary:Crash when using $GLOBALS -Status: Feedback +Status: Bogus Type: Bug Package:Reproducible crash PHP Version:5.3.3 Block user comment: N New Comment: No problem, thanks for reporting anyway! ;) Previous Comments: [2010-08-07 18:58:49] nick at witthaus dot com Sorry, I had eAccelerator installed and that seemed to be causing the problem. I removed it and it worked as expected. I apologize for being an idiot. [2010-08-07 18:14:19] fel...@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. I cannot reproduce this. Are you using some extension that touches in the engine? [2010-08-07 18:10:36] nick at witthaus dot com Description: There seems to be a crash in 5.3.3 when trying to access the value of a $GLOBALS array variable when there is another $GLOBALS variable is used as an index. This worked in 5.3.2. Test script: --- Expected result: I expect to see 'foo0' echoed. Actual result: -- Causes a crash in 5.3.3. -- Edit this bug report at http://bugs.php.net/bug.php?id=52562&edit=1
Bug #52408 [Opn->Ana]: Configure script incorrectly assumes that all HP-UX OS's use .sl extensions
Edit report at http://bugs.php.net/bug.php?id=52408&edit=1 ID: 52408 Updated by: ka...@php.net Reported by:dmhilker at gmail dot com Summary:Configure script incorrectly assumes that all HP-UX OS's use .sl extensions -Status: Open +Status: Analyzed Type: Bug Package:Compile Failure Operating System: HP-UX 11.31 PHP Version:5.3.3 Block user comment: N Previous Comments: [2010-08-07 21:22:35] ka...@php.net Hi I belive we should have a check for the newer versions of HPUX and override those values to keep BC with older versions, however Im not familiar with the Unix build system, but if you can provide such a patch one of us will commit it [2010-07-22 17:21:08] dmhilker at gmail dot com Description: The php configure script assumes that all hp-ux os's use .sl extension for shared libraries. HP-UX 11.31 now uses .so extension for shared libraries. If the configure script is used on HP-UX 11.31, it will not find the shared libraries because it is always looking for the .sl extension. The configure script will have to test what version of hpux is being used in order to set the configure shlib suffix name variables correctly. Test script: --- Snip from configure: *hpux*) SHLIB_SUFFIX_NAME=sl SHLIB_DL_SUFFIX_NAME=sl I changed to this to get it to work: *hpux*) SHLIB_SUFFIX_NAME=so SHLIB_DL_SUFFIX_NAME=so -- Edit this bug report at http://bugs.php.net/bug.php?id=52408&edit=1
Bug #52408 [Opn]: Configure script incorrectly assumes that all HP-UX OS's use .sl extensions
Edit report at http://bugs.php.net/bug.php?id=52408&edit=1 ID: 52408 Updated by: ka...@php.net Reported by:dmhilker at gmail dot com Summary:Configure script incorrectly assumes that all HP-UX OS's use .sl extensions Status: Open Type: Bug Package:Compile Failure Operating System: HP-UX 11.31 PHP Version:5.3.3 Block user comment: N New Comment: Hi I belive we should have a check for the newer versions of HPUX and override those values to keep BC with older versions, however Im not familiar with the Unix build system, but if you can provide such a patch one of us will commit it Previous Comments: [2010-07-22 17:21:08] dmhilker at gmail dot com Description: The php configure script assumes that all hp-ux os's use .sl extension for shared libraries. HP-UX 11.31 now uses .so extension for shared libraries. If the configure script is used on HP-UX 11.31, it will not find the shared libraries because it is always looking for the .sl extension. The configure script will have to test what version of hpux is being used in order to set the configure shlib suffix name variables correctly. Test script: --- Snip from configure: *hpux*) SHLIB_SUFFIX_NAME=sl SHLIB_DL_SUFFIX_NAME=sl I changed to this to get it to work: *hpux*) SHLIB_SUFFIX_NAME=so SHLIB_DL_SUFFIX_NAME=so -- Edit this bug report at http://bugs.php.net/bug.php?id=52408&edit=1
Bug #50043 [Com]: PHP_SELF duplicates path again
Edit report at http://bugs.php.net/bug.php?id=50043&edit=1 ID: 50043 Comment by: kwils13 at gmail dot com Reported by:ahu at 52q dot net Summary:PHP_SELF duplicates path again Status: Closed Type: Bug Package:CGI related Operating System: Windows xp sp3 PHP Version:5.2.11 Block user comment: N New Comment: confirmed nginx issue. comment out SCRIPT_NAME in fastcgi_params. Know however that will break some CMS systems like Joomla (see: http://forum.nginx.org/read.php?11,10324,10475 as it apparently needs both) Previous Comments: [2009-10-30 17:18:04] ahu at 52q dot net It maybe the problem of nginx. [2009-10-30 16:53:34] ahu at 52q dot net Description: PHP_SELF duplicates path again!!! somebody had reported this problem servel years ago at http://bugs.php.net/bug.php?id=42523 And at the end I saw you said you fixed it.But it appears again now. How dispirited I am,when I spent a lot time search and search...from China to you here.:( nginx/0.8.21+php5.2.11 on Windows XP sp3 Reproduce code: --- phpinfo(); Expected result: /phpinfo.php Actual result: -- /phpinfo.php/phpinfo.php -- Edit this bug report at http://bugs.php.net/bug.php?id=50043&edit=1
[PHP-BUG] Bug #52563 [NEW]: [Feature request] error_reporting constant
From: Operating system: Any PHP version: Irrelevant Package: PHP options/info functions Bug Type: Bug Bug description:[Feature request] error_reporting constant Description: Feature request only; For completeness, and coding clarity, please define constant E_NONE to set error reporting to none rather than relying on the absolute integer value of 0 Test script: --- error_reporting(E_NONE); Expected result: [No error warning] Actual result: -- PHP Notice: Use of undefined constant E_NONE - assumed 'E_NONE' -- Edit bug report at http://bugs.php.net/bug.php?id=52563&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52563&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52563&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52563&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52563&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52563&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52563&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52563&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52563&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52563&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52563&r=support Expected behavior: http://bugs.php.net/fix.php?id=52563&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52563&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52563&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52563&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52563&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52563&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52563&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52563&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52563&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52563&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52563&r=mysqlcfg
Bug #52562 [Com]: Crash when using $GLOBALS
Edit report at http://bugs.php.net/bug.php?id=52562&edit=1 ID: 52562 Comment by: nick at witthaus dot com Reported by:nick at witthaus dot com Summary:Crash when using $GLOBALS Status: Feedback Type: Bug Package:Reproducible crash PHP Version:5.3.3 Block user comment: N New Comment: Sorry, I had eAccelerator installed and that seemed to be causing the problem. I removed it and it worked as expected. I apologize for being an idiot. Previous Comments: [2010-08-07 18:14:19] fel...@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. I cannot reproduce this. Are you using some extension that touches in the engine? [2010-08-07 18:10:36] nick at witthaus dot com Description: There seems to be a crash in 5.3.3 when trying to access the value of a $GLOBALS array variable when there is another $GLOBALS variable is used as an index. This worked in 5.3.2. Test script: --- Expected result: I expect to see 'foo0' echoed. Actual result: -- Causes a crash in 5.3.3. -- Edit this bug report at http://bugs.php.net/bug.php?id=52562&edit=1
Bug #52562 [Opn->Fbk]: Crash when using $GLOBALS
Edit report at http://bugs.php.net/bug.php?id=52562&edit=1 ID: 52562 Updated by: fel...@php.net Reported by:nick at witthaus dot com Summary:Crash when using $GLOBALS -Status: Open +Status: Feedback Type: Bug Package:Reproducible crash PHP Version:5.3.3 Block user comment: N New Comment: 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. I cannot reproduce this. Are you using some extension that touches in the engine? Previous Comments: [2010-08-07 18:10:36] nick at witthaus dot com Description: There seems to be a crash in 5.3.3 when trying to access the value of a $GLOBALS array variable when there is another $GLOBALS variable is used as an index. This worked in 5.3.2. Test script: --- Expected result: I expect to see 'foo0' echoed. Actual result: -- Causes a crash in 5.3.3. -- Edit this bug report at http://bugs.php.net/bug.php?id=52562&edit=1
[PHP-BUG] Bug #52562 [NEW]: Crash when using $GLOBALS
From: Operating system: PHP version: 5.3.3 Package: Reproducible crash Bug Type: Bug Bug description:Crash when using $GLOBALS Description: There seems to be a crash in 5.3.3 when trying to access the value of a $GLOBALS array variable when there is another $GLOBALS variable is used as an index. This worked in 5.3.2. Test script: --- Expected result: I expect to see 'foo0' echoed. Actual result: -- Causes a crash in 5.3.3. -- Edit bug report at http://bugs.php.net/bug.php?id=52562&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52562&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52562&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52562&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52562&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52562&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52562&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52562&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52562&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52562&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52562&r=support Expected behavior: http://bugs.php.net/fix.php?id=52562&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52562&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52562&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52562&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52562&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52562&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52562&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52562&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52562&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52562&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52562&r=mysqlcfg
Bug #52554 [Opn->Fbk]: Sporadic PHP Segmentation fault in combination with unixODBC
Edit report at http://bugs.php.net/bug.php?id=52554&edit=1
ID: 52554
Updated by: fel...@php.net
Reported by:cameron dot moller at gmail dot com
Summary:Sporadic PHP Segmentation fault in combination with
unixODBC
-Status: Open
+Status: Feedback
Type: Bug
Package:ODBC related
Operating System: 2.6.34-gentoo-r1 x86_64
PHP Version:5.3SVN-2010-08-06 (SVN)
Block user comment: N
New Comment:
That _estrndup on backtrace must be related to RETURN_STRINGL macro used
in the zif_odbc_result... Can you check in which RETURN_STRINGL the
crash occurs and get the string size passed to estrndup()?
Previous Comments:
[2010-08-07 12:08:50] cameron dot moller at gmail dot com
Re-emergeing glibc did not help
[2010-08-06 12:27:31] cameron dot moller at gmail dot com
Description:
Gentoo Linux x86_64
Kernel 2.6.34-gentoo-r1
unixODBC-2.3.0
freeTDS 0.64
PHP 5.3.2 (from Gentoo portage (~ = experimental))
(problem started on PHP 5.2.13 - I upgraded to ~5.3.2)
Apache 2.2.15
gcc 4.4.3-r2
glibc 2.11.2
MSSQL 2005 (remote server)
I have multiple pages that query the database successfully. However, 2
queries always result in a segmentation fault. I ran the page through
gdb and generated a backtrace. Shown below.
The suspect sql is simply "select distinct asgn_group from
csc_report_active order by asgn_group asc"
FYI - sql via isql gives me 773 rows - no problems.
php.ini is vanilla - no changes - but dated Jul 30 - about when the
problem started. Though I do not remember ever making any changes to
php.ini
httpd.conf also vanilla as is /etc/conf.d/apache2
[I] dev-lang/php
Available versions: (5) 5.2.13 ~5.2.14 (~)5.3.2 ~5.3.3
{adabas apache2 bcmath berkdb birdstep bzip2 calendar cdb cgi
cjk (+)cli concurrentmodphp crypt (+)ctype curl curlwrappers db2 dbase
dbmaker debug discard-path doc embed empress empress-bcs enchant esoob
exif fastbuild fdftk +fileinfo (+)filter firebird flatfile
force-cgi-redirect fpm frontbase ftp gd gd-external gdbm gmp (+)hash
(+)iconv imap inifile interbase intl iodbc ipv6 java-external (+)json
kerberos kolab ldap ldap-sasl libedit mcve mhash msql mssql mysql mysqli
mysqlnd ncurses nls oci8 oci8-instant-client odbc pcntl (+)pcre pdo
+phar pic (+)posix postgres qdbm readline recode reflection sapdb
(+)session sharedext sharedmem (+)simplexml snmp soap sockets solid
spell spl sqlite sqlite3 ssl suhosin sybase sybase-ct sysvipc threads
tidy (+)tokenizer truetype unicode wddx xml xmlreader xmlrpc xmlwriter
xpm xsl yaz zip zlib}
Installed versions: 5.3.2(5)(08:26:30 07/30/10)(apache2 berkdb
bzip2 cli crypt ctype fileinfo filter gd gdbm hash iconv imap json
kerberos ldap mssql mysql nls odbc phar posix postgres readline session
simplexml ssl tokenizer truetype unicode xml zlib -adabas -bcmath
-birdstep -calendar -cdb -cgi -cjk -concurrentmodphp -curl -curlwrappers
-db2 -dbmaker -debug -doc -embed -empress -empress-bcs -enchant -esoob
-exif -firebird -flatfile -frontbase -ftp -gd-external -gmp -inifile
-interbase -intl -iodbc -ipv6 -kolab -ldap-sasl -libedit -mysqli
-mysqlnd -oci8 -oci8-instant-client -pcntl -pdo -pic -qdbm -recode
-sapdb -sharedext -sharedmem -snmp -soap -sockets -solid -spell -sqlite
-sqlite3 -suhosin -sybase-ct -sysvipc -threads -tidy -wddx -xmlreader
-xmlrpc -xmlwriter -xpm -xsl -zip)
gdb /usr/bin/php
warning: Can not parse XML syscalls information; XML support was
disabled at compile time.
GNU gdb (Gentoo 7.0.1 p1) 7.0.1
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
Bug #52559 [Opn->Asn]: Calling undefined method on FilterIterator subclasses causes segfault
Edit report at http://bugs.php.net/bug.php?id=52559&edit=1 ID: 52559 Updated by: fel...@php.net Reported by:tobias382 at gmail dot com Summary:Calling undefined method on FilterIterator subclasses causes segfault -Status: Open +Status: Assigned Type: Bug Package:SPL related Operating System: Ubuntu 10.04 PHP Version:5.3SVN-2010-08-06 (snap) -Assigned To: +Assigned To:colder Block user comment: N Previous Comments: [2010-08-07 03:42:22] tobias382 at gmail dot com Description: The attached test script causes a segmentation fault in PHP 5.3.3 and the current PHP 5.3 snapshot, presumably because count() is not a defined method in FooIterator or any of its ancestor classes. The configure line used to compile the snapshot: Configure Command => './configure' '--prefix=/home/matt/Software/php5.3- 201008070030/build/php_build' '--without-pear' '--without-sqlite3' '--without- pdo-sqlite' '--without-sqlite' '--enable-debug' Test script: --- count(); Expected result: PHP Fatal error: Call to undefined method FooIterator::count() in test.php on line 8 Actual result: -- 1Segmentation fault gdb backtrace: #0 0x02926cd0 in ?? () #1 0x00573929 in spl_dual_it_free (intern=0x2a089f0) at /home/matt/Software/php5.3-201008070030/ext/spl/spl_iterators.c:1461 #2 0x00574ebd in spl_dual_it_dtor (_object=0x2a089f0, handle=1) at /home/matt/Software/php5.3-201008070030/ext/spl/spl_iterators.c:1942 #3 0x006ebbea in zend_objects_store_del_ref_by_handle_ex (handle=1, handlers=0xcace80) at /home/matt/Software/php5.3-201008070030/Zend/zend_objects_API.c:206 #4 0x006eba5f in zend_objects_store_del_ref (zobject=0x2a20e30) at /home/matt/Software/php5.3-201008070030/Zend/zend_objects_API.c:172 #5 0x006bbca2 in _zval_dtor_func (zvalue=0x2a20e30, __zend_filename=0xa4e9a8 "/home/matt/Software/php5.3- 201008070030/Zend/zend_execute_API.c", __zend_lineno=443) at /home/matt/Software/php5.3- 201008070030/Zend/zend_variables.c:52 #6 0x006abbba in _zval_dtor (zvalue=0x2a20e30, __zend_filename=0xa4e9a8 "/home/matt/Software/php5.3-201008070030/Zend/zend_execute_API.c", __zend_lineno=443) at /home/matt/Software/php5.3- 201008070030/Zend/zend_variables.h:35 #7 0x006acb48 in _zval_ptr_dtor (zval_ptr=0x2a24158, __zend_filename=0xa50290 "/home/matt/Software/php5.3- 201008070030/Zend/zend_variables.c", __zend_lineno=178) at /home/matt/Software/php5.3- 201008070030/Zend/zend_execute_API.c:443 #8 0x006bc01f in _zval_ptr_dtor_wrapper (zval_ptr=0x2a24158) at /home/matt/Software/php5.3-201008070030/Zend/zend_variables.c:178 #9 0x006ce705 in zend_hash_apply_deleter (ht=0xcc4588, p=0x2a24140) at /home/matt/Software/php5.3-201008070030/Zend/zend_hash.c:611 #10 0x006ced8e in zend_hash_reverse_apply (ht=0xcc4588, apply_func=0x6ac3f5 ) at /home/matt/Software/php5.3-201008070030/Zend/zend_hash.c:760 #11 0x006ac487 in shutdown_destructors () at /home/matt/Software/php5.3- 201008070030/Zend/zend_execute_API.c:226 #12 0x006bd8db in zend_call_destructors () at /home/matt/Software/php5.3-201008070030/Zend/zend.c:874 #13 0x00647cec in php_request_shutdown (dummy=0x0) at /home/matt/Software/php5.3-201008070030/main/main.c:1587 #14 0x007a27db in main (argc=2, argv=0x7fffd4f78e68) at /home/matt/Software/php5.3-201008070030/sapi/cli/php_cli.c:1373 -- Edit this bug report at http://bugs.php.net/bug.php?id=52559&edit=1
Bug->Req #52555 [Bgs->Asn]: Headers_List not returning HTTP Status Code
Edit report at http://bugs.php.net/bug.php?id=52555&edit=1
ID: 52555
Updated by: paj...@php.net
Reported by:dragoo...@php.net
Summary:Headers_List not returning HTTP Status Code
-Status: Bogus
+Status: Assigned
-Type: Bug
+Type: Feature/Change Request
Package:*Web Server problem
PHP Version:5.3.3
Assigned To:dragoonis
Block user comment: N
Previous Comments:
[2010-08-07 15:54:44] dragoo...@php.net
After some discussions in IRC we have concluded that it's best to make a
new function to give us the current response code rather than modifying
existing functionality.
I've added the patch below to be tested and committed into TRUNK or
wherever.
Cheers.
Paul.
[2010-08-07 15:53:20] dragoo...@php.net
The following patch has been added/updated:
Patch Name: http_response_code
Revision: 1281189200
URL:
http://bugs.php.net/patch-display.php?bug=52555&patch=http_response_code&revision=1281189200
[2010-08-06 14:15:06] dragoo...@php.net
As per IRC conversations, the status_line or http_response_code are not
headers therefore should not be returned from headers_list() so the
conclusion is to make a new function to give you http_response_code. I
will update this ticket with the patch.
[2010-08-06 13:42:58] johan...@php.net
RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1) makes a difference
between the Status-Line (6.1) and the Headers (6.2) that we allow
setting the Status-Line via header() is kind of a hack, headers_list()
should only list headers so users can work with them easily (like
splitting up at ": " etc.)
[2010-08-06 12:50:43] dragoo...@php.net
Description:
Ok so i've found the reason why this doesn't work but i'd like feedback
on the appropriate area to change as this looks like it was
intentionally developed this way.
headers_list() gets passed SG(sapi_headers).headers and prints them.
This works however when you do header() -> sapi_header_op() and you set
a response code such as 'HTTP/1.0 404 Not Found'.
It does not put this header into SG(sapi_headers).headers but it puts it
into SG(sapi_headers).http_response_code instead.
This looks to be intentional as there are special functions for updating
the response code such as sapi_update_response_code()
So the end question is, should I modify sapi_header_op() to also include
the response code in SG(sapi_headers).headers or should I modify
headers_list() to receive SG(sapi_headers).headers and
SG(sapi_headers).http_response_code.
I could also make a new function which only returns
SG(sapi_headers).http_response_code but i think that's a waste of time
and could update headers_list() or whatnot.
FYI: I tested apache_response_headers() and got no http response code in
their either.
Test script:
---
string(34) "X-Powered-By: PHP/5.3.2-1ubuntu4.2"
[1]=>
string(30) "Content-type: text/plain"
[2]=>
string(22) "HTTP/1.0 404 Not Found"
}
Actual result:
--
array(2) {
[0]=>
string(34) "X-Powered-By: PHP/5.3.2-1ubuntu4.2"
[1]=>
string(30) "Content-type: text/plain"
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=52555&edit=1
Bug #52555 [Com]: Headers_List not returning HTTP Status Code
Edit report at http://bugs.php.net/bug.php?id=52555&edit=1
ID: 52555
Comment by: dragoo...@php.net
Reported by:dragoo...@php.net
Summary:Headers_List not returning HTTP Status Code
Status: Bogus
Type: Bug
Package:*Web Server problem
PHP Version:5.3.3
Assigned To:dragoonis
Block user comment: N
New Comment:
After some discussions in IRC we have concluded that it's best to make a
new function to give us the current response code rather than modifying
existing functionality.
I've added the patch below to be tested and committed into TRUNK or
wherever.
Cheers.
Paul.
Previous Comments:
[2010-08-07 15:53:20] dragoo...@php.net
The following patch has been added/updated:
Patch Name: http_response_code
Revision: 1281189200
URL:
http://bugs.php.net/patch-display.php?bug=52555&patch=http_response_code&revision=1281189200
[2010-08-06 14:15:06] dragoo...@php.net
As per IRC conversations, the status_line or http_response_code are not
headers therefore should not be returned from headers_list() so the
conclusion is to make a new function to give you http_response_code. I
will update this ticket with the patch.
[2010-08-06 13:42:58] johan...@php.net
RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1) makes a difference
between the Status-Line (6.1) and the Headers (6.2) that we allow
setting the Status-Line via header() is kind of a hack, headers_list()
should only list headers so users can work with them easily (like
splitting up at ": " etc.)
[2010-08-06 12:50:43] dragoo...@php.net
Description:
Ok so i've found the reason why this doesn't work but i'd like feedback
on the appropriate area to change as this looks like it was
intentionally developed this way.
headers_list() gets passed SG(sapi_headers).headers and prints them.
This works however when you do header() -> sapi_header_op() and you set
a response code such as 'HTTP/1.0 404 Not Found'.
It does not put this header into SG(sapi_headers).headers but it puts it
into SG(sapi_headers).http_response_code instead.
This looks to be intentional as there are special functions for updating
the response code such as sapi_update_response_code()
So the end question is, should I modify sapi_header_op() to also include
the response code in SG(sapi_headers).headers or should I modify
headers_list() to receive SG(sapi_headers).headers and
SG(sapi_headers).http_response_code.
I could also make a new function which only returns
SG(sapi_headers).http_response_code but i think that's a waste of time
and could update headers_list() or whatnot.
FYI: I tested apache_response_headers() and got no http response code in
their either.
Test script:
---
string(34) "X-Powered-By: PHP/5.3.2-1ubuntu4.2"
[1]=>
string(30) "Content-type: text/plain"
[2]=>
string(22) "HTTP/1.0 404 Not Found"
}
Actual result:
--
array(2) {
[0]=>
string(34) "X-Powered-By: PHP/5.3.2-1ubuntu4.2"
[1]=>
string(30) "Content-type: text/plain"
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=52555&edit=1
Bug #52555 [PATCH]: Headers_List not returning HTTP Status Code
Edit report at http://bugs.php.net/bug.php?id=52555&edit=1
ID: 52555
Patch added by: dragoo...@php.net
Reported by:dragoo...@php.net
Summary:Headers_List not returning HTTP Status Code
Status: Bogus
Type: Bug
Package:*Web Server problem
PHP Version:5.3.3
Assigned To:dragoonis
Block user comment: N
New Comment:
The following patch has been added/updated:
Patch Name: http_response_code
Revision: 1281189200
URL:
http://bugs.php.net/patch-display.php?bug=52555&patch=http_response_code&revision=1281189200
Previous Comments:
[2010-08-06 14:15:06] dragoo...@php.net
As per IRC conversations, the status_line or http_response_code are not
headers therefore should not be returned from headers_list() so the
conclusion is to make a new function to give you http_response_code. I
will update this ticket with the patch.
[2010-08-06 13:42:58] johan...@php.net
RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1) makes a difference
between the Status-Line (6.1) and the Headers (6.2) that we allow
setting the Status-Line via header() is kind of a hack, headers_list()
should only list headers so users can work with them easily (like
splitting up at ": " etc.)
[2010-08-06 12:50:43] dragoo...@php.net
Description:
Ok so i've found the reason why this doesn't work but i'd like feedback
on the appropriate area to change as this looks like it was
intentionally developed this way.
headers_list() gets passed SG(sapi_headers).headers and prints them.
This works however when you do header() -> sapi_header_op() and you set
a response code such as 'HTTP/1.0 404 Not Found'.
It does not put this header into SG(sapi_headers).headers but it puts it
into SG(sapi_headers).http_response_code instead.
This looks to be intentional as there are special functions for updating
the response code such as sapi_update_response_code()
So the end question is, should I modify sapi_header_op() to also include
the response code in SG(sapi_headers).headers or should I modify
headers_list() to receive SG(sapi_headers).headers and
SG(sapi_headers).http_response_code.
I could also make a new function which only returns
SG(sapi_headers).http_response_code but i think that's a waste of time
and could update headers_list() or whatnot.
FYI: I tested apache_response_headers() and got no http response code in
their either.
Test script:
---
string(34) "X-Powered-By: PHP/5.3.2-1ubuntu4.2"
[1]=>
string(30) "Content-type: text/plain"
[2]=>
string(22) "HTTP/1.0 404 Not Found"
}
Actual result:
--
array(2) {
[0]=>
string(34) "X-Powered-By: PHP/5.3.2-1ubuntu4.2"
[1]=>
string(30) "Content-type: text/plain"
}
--
Edit this bug report at http://bugs.php.net/bug.php?id=52555&edit=1
Req #52385 [Opn]: Support for autoloading functions
Edit report at http://bugs.php.net/bug.php?id=52385&edit=1 ID: 52385 User updated by:php-bugs at majkl578 dot cz Reported by:php-bugs at majkl578 dot cz Summary:Support for autoloading functions Status: Open Type: Feature/Change Request Package:SPL related Operating System: Irrelevant PHP Version:5.3.3RC3 Block user comment: N New Comment: It doesn't make any difference to me. I'm using tokenizer to look up for classes in all files. Then I store them in an associative array (class=>file) and when the class is requested, it is loaded according to this list. With functions it'd be completely same. I don't think PHP should provide anything more, just an autoloader to be used with user-defined callback (like spl_autoload_register does). "With classes you often have one class per fileâ¦" Often, but not always. Previous Comments: [2010-08-07 01:51:34] johan...@php.net With classes you often have one class per file, with functions not which makes the lookup usually way more complex; I don't see us adding this. [2010-07-24 07:00:14] php-bugs at majkl578 dot cz Decoded version (really nice bug :)): Would it be possible to add a support for autoloading user-defined functions? Currently only classes are supported by either __autoload or spl_autoload or spl_autoload_register. Including all functions is really awful job whereas classess could be autoloaded nicely (imagine implementation for spl_autoload_register which scans a directory for classess and then includes specific file). I suggest to make possible something similar to the example above for normal functions (global as well as those in namespaces). PS: I know that it could be hacked by emulating namespace with class (eg. static method String::webalize()) but since PHP 5.3 it would be probably nicier not to hack it with classes, but place it to namespace as a regular function (String\webalize()). [2010-07-21 05:29:55] php-bugs at majkl578 dot cz Description: Would it be possible to add a support for autoloading user-defined functions? Currently only classes are supported by either __autoload or spl_autoload or spl_autoload_register. Including all functions is really awful job whereas classess could be autoloaded nicely (imagine implementation for spl_autoload_register which scans a directory for classess and then includes specific file). I suggest to make possible something similar to the example above for normal functions (global as well as those in namespaces). PS: I know that it could be hacked by emulating namespace with class (eg. static method String::webalize()) but since PHP 5.3 it would be probably nicier not to hack it with classes, but place it to namespace as a regular function (String\webalize()). -- Edit this bug report at http://bugs.php.net/bug.php?id=52385&edit=1
Bug #52561 [Opn->Asn]: function mysqli_ping no attempted reconnection!
Edit report at http://bugs.php.net/bug.php?id=52561&edit=1
ID: 52561
Updated by: johan...@php.net
Reported by:paulgao at yeah dot net
Summary:function mysqli_ping no attempted reconnection!
-Status: Open
+Status: Assigned
Type: Bug
Package:MySQL related
Operating System: irrelevant
PHP Version:5.3.3
-Assigned To:
+Assigned To:mysql
Block user comment: N
Previous Comments:
[2010-08-07 13:41:12] paulgao at yeah dot net
and mysql server version 5.1.49.
[2010-08-07 13:32:26] paulgao at yeah dot net
Description:
I use mysqli_ping reconnection database when php script long time run.
when my use mysqlnd module, mysqli_ping() is run fail, errormsg is
"MySQL server has gone away".
mysqli.reconnect setting is ON.
mysql server timeout is 30s.
Test script:
---
ping()) {
printf ("Our connection is ok!\n");
} else {
printf ("Error: %s\n", $mysqli->error);
}
/* close connection */
$mysqli->close();
?>
Expected result:
Our connection is ok!
Actual result:
--
Error: MySQL server has gone away
--
Edit this bug report at http://bugs.php.net/bug.php?id=52561&edit=1
Bug #49816 [Bgs]: output corruption using flush
Edit report at http://bugs.php.net/bug.php?id=49816&edit=1 ID: 49816 User updated by:paul at wcclan dot net Reported by:paul at wcclan dot net Summary:output corruption using flush Status: Bogus Type: Bug Package:Apache2 related Operating System: * PHP Version:5.* Block user comment: N New Comment: with php 5.3.3 the "just don't compress" solution seems to be in place so at least it doesn't cause any problems. However, shouldn't flush() also work when applying compression? Previous Comments: [2010-08-07 13:26:52] johan...@php.net The new output buffering is in trunk, it won't be ported to 5.3. [2010-01-30 15:39:16] ben at xnode dot org Still experiencing this issue with PHP 5.3.1 and Apache 2.2.14. Quite annoying as it means either not being able to use Flush (which isn't an option for some apps) or not being able to use compression. [2009-11-19 15:59:01] j...@php.net Unfortunately flush() with apache2handler SAPI will also disable compression. Like I've said in the commit it's temporary "fix" to at least keep things working. The real fix requires doing MFH of new output buffering code where this works fine. Johannes, please reply, I've asked you several times now whether I can merge the new and working output buffering code from HEAD (like I already suggested before 5.3.0 was released!). [2009-11-18 21:19:12] paul at wcclan dot net I might be reading this wrong, but aren't you just opting not to compress with this code? If so, how do you explain that compression worked fine before 5.2.11? If I am reading it wrong, great job on the fix :) [2009-11-15 00:13:20] s...@php.net Automatic comment from SVN on behalf of jani Revision: http://svn.php.net/viewvc/?view=revision&revision=290765 Log: - Temporary hack to fix bug #49816 (works fine in HEAD which has working output buffering..) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49816 -- Edit this bug report at http://bugs.php.net/bug.php?id=49816&edit=1
Bug #52561 [Com]: function mysqli_ping no attempted reconnection!
Edit report at http://bugs.php.net/bug.php?id=52561&edit=1
ID: 52561
Comment by: paulgao at yeah dot net
Reported by:paulgao at yeah dot net
Summary:function mysqli_ping no attempted reconnection!
Status: Open
Type: Bug
Package:MySQL related
Operating System: irrelevant
PHP Version:5.3.3
Block user comment: N
New Comment:
and mysql server version 5.1.49.
Previous Comments:
[2010-08-07 13:32:26] paulgao at yeah dot net
Description:
I use mysqli_ping reconnection database when php script long time run.
when my use mysqlnd module, mysqli_ping() is run fail, errormsg is
"MySQL server has gone away".
mysqli.reconnect setting is ON.
mysql server timeout is 30s.
Test script:
---
ping()) {
printf ("Our connection is ok!\n");
} else {
printf ("Error: %s\n", $mysqli->error);
}
/* close connection */
$mysqli->close();
?>
Expected result:
Our connection is ok!
Actual result:
--
Error: MySQL server has gone away
--
Edit this bug report at http://bugs.php.net/bug.php?id=52561&edit=1
[PHP-BUG] Bug #52561 [NEW]: function mysqli_ping no attempted reconnection!
From:
Operating system: irrelevant
PHP version: 5.3.3
Package: MySQL related
Bug Type: Bug
Bug description:function mysqli_ping no attempted reconnection!
Description:
I use mysqli_ping reconnection database when php script long time run.
when my use mysqlnd module, mysqli_ping() is run fail, errormsg is "MySQL
server has gone away".
mysqli.reconnect setting is ON.
mysql server timeout is 30s.
Test script:
---
ping()) {
printf ("Our connection is ok!\n");
} else {
printf ("Error: %s\n", $mysqli->error);
}
/* close connection */
$mysqli->close();
?>
Expected result:
Our connection is ok!
Actual result:
--
Error: MySQL server has gone away
--
Edit bug report at http://bugs.php.net/bug.php?id=52561&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52561&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52561&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52561&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52561&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52561&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52561&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52561&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52561&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52561&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52561&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52561&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52561&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52561&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52561&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52561&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52561&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52561&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52561&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52561&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52561&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52561&r=mysqlcfg
Bug #49816 [Asn->Bgs]: output corruption using flush
Edit report at http://bugs.php.net/bug.php?id=49816&edit=1 ID: 49816 Updated by: johan...@php.net Reported by:paul at wcclan dot net Summary:output corruption using flush -Status: Assigned +Status: Bogus Type: Bug Package:Apache2 related Operating System: * PHP Version:5.* -Assigned To:johannes +Assigned To: Block user comment: N New Comment: The new output buffering is in trunk, it won't be ported to 5.3. Previous Comments: [2010-01-30 15:39:16] ben at xnode dot org Still experiencing this issue with PHP 5.3.1 and Apache 2.2.14. Quite annoying as it means either not being able to use Flush (which isn't an option for some apps) or not being able to use compression. [2009-11-19 15:59:01] j...@php.net Unfortunately flush() with apache2handler SAPI will also disable compression. Like I've said in the commit it's temporary "fix" to at least keep things working. The real fix requires doing MFH of new output buffering code where this works fine. Johannes, please reply, I've asked you several times now whether I can merge the new and working output buffering code from HEAD (like I already suggested before 5.3.0 was released!). [2009-11-18 21:19:12] paul at wcclan dot net I might be reading this wrong, but aren't you just opting not to compress with this code? If so, how do you explain that compression worked fine before 5.2.11? If I am reading it wrong, great job on the fix :) [2009-11-15 00:13:20] s...@php.net Automatic comment from SVN on behalf of jani Revision: http://svn.php.net/viewvc/?view=revision&revision=290765 Log: - Temporary hack to fix bug #49816 (works fine in HEAD which has working output buffering..) [2009-11-14 22:28:40] j...@php.net Caused by fixing bug #49248 and does not happen with HEAD. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=49816 -- Edit this bug report at http://bugs.php.net/bug.php?id=49816&edit=1
Bug #52518 [Fbk->Opn]: Segfault in /Zend/zend_objects_API.c:230
Edit report at http://bugs.php.net/bug.php?id=52518&edit=1 ID: 52518 User updated by:correo at sevein dot com Reported by:correo at sevein dot com Summary:Segfault in /Zend/zend_objects_API.c:230 -Status: Feedback +Status: Open Type: Bug Package:Reproducible crash Operating System: Linux/Windows PHP Version:5.3.3 Block user comment: N New Comment: I continue investigating this issue. I ran valgrind to complete this report and got this: ==1994== Invalid read of size 4 ==1994==at 0x701E1C: zend_objects_store_del_ref_by_handle_ex (zend_objects_API.c:230) ==1994==by 0x701F62: zend_objects_store_del_ref (zend_objects_API.c:172) ==1994==by 0x6D4B04: _zval_ptr_dtor (zend_variables.h:35) ==1994==by 0x6EC4CA: zend_hash_destroy (zend_hash.c:526) ==1994==by 0x6FE5F8: zend_object_std_dtor (zend_objects.c:45) ==1994==by 0x6FE618: zend_objects_free_object_storage (zend_objects.c:128) ==1994==by 0x701F49: zend_objects_store_del_ref_by_handle_ex (zend_objects_API.c:220) ==1994==by 0x701F62: zend_objects_store_del_ref (zend_objects_API.c:172) ==1994==by 0x75AE41: ZEND_ASSIGN_SPEC_CV_CONST_HANDLER (zend_execute.c:691) ==1994==by 0x704927: execute (zend_vm_execute.h:107) ==1994==by 0x6E0179: zend_execute_scripts (zend.c:1194) ==1994==by 0x68F8CC: php_execute_script (main.c:2260) ==1994==by 0x76638D: main (php_cli.c:1192) ==1994== Address 0x10611c30 is 1,014,768 bytes inside a block of size 1,048,576 free'd ==1994==at 0x4C285A2: realloc (vg_replace_malloc.c:525) ==1994==by 0x702080: zend_objects_store_put (zend_objects_API.c:113) ==1994==by 0x6FE2C7: zend_objects_new (zend_objects.c:138) ==1994==by 0x6E86F2: _object_and_properties_init (zend_API.c:1079) ==1994==by 0x709168: ZEND_NEW_SPEC_HANDLER (zend_vm_execute.h:476) ==1994==by 0x704927: execute (zend_vm_execute.h:107) ==1994==by 0x6D6D03: zend_call_function (zend_execute_API.c:963) ==1994==by 0x6F5F4E: zend_call_method (zend_interfaces.c:97) ==1994==by 0x6FE4DE: zend_objects_destroy_object (zend_objects.c:113) ==1994==by 0x701F30: zend_objects_store_del_ref_by_handle_ex (zend_objects_API.c:206) ==1994==by 0x701F62: zend_objects_store_del_ref (zend_objects_API.c:172) ==1994==by 0x6D4B04: _zval_ptr_dtor (zend_variables.h:35) ==1994==by 0x6EC4CA: zend_hash_destroy (zend_hash.c:526) ==1994==by 0x6FE5F8: zend_object_std_dtor (zend_objects.c:45) ==1994==by 0x6FE618: zend_objects_free_object_storage (zend_objects.c:128) ==1994==by 0x701F49: zend_objects_store_del_ref_by_handle_ex (zend_objects_API.c:220) ==1994==by 0x701F62: zend_objects_store_del_ref (zend_objects_API.c:172) ==1994==by 0x6D4B04: _zval_ptr_dtor (zend_variables.h:35) ==1994==by 0x6EC4CA: zend_hash_destroy (zend_hash.c:526) ==1994==by 0x6FE5F8: zend_object_std_dtor (zend_objects.c:45) ==1994==by 0x6FE618: zend_objects_free_object_storage (zend_objects.c:128) ==1994==by 0x701F49: zend_objects_store_del_ref_by_handle_ex (zend_objects_API.c:220) ==1994==by 0x701F62: zend_objects_store_del_ref (zend_objects_API.c:172) ==1994==by 0x75AE41: ZEND_ASSIGN_SPEC_CV_CONST_HANDLER (zend_execute.c:691) ==1994==by 0x704927: execute (zend_vm_execute.h:107) ==1994==by 0x6E0179: zend_execute_scripts (zend.c:1194) ==1994==by 0x68F8CC: php_execute_script (main.c:2260) ==1994==by 0x76638D: main (php_cli.c:1192) ==1994== ==1994== Invalid read of size 4 ==1994==at 0x701E1C: zend_objects_store_del_ref_by_handle_ex (zend_objects_API.c:230) ==1994==by 0x701F62: zend_objects_store_del_ref (zend_objects_API.c:172) ==1994==by 0x75AE41: ZEND_ASSIGN_SPEC_CV_CONST_HANDLER (zend_execute.c:691) ==1994==by 0x704927: execute (zend_vm_execute.h:107) ==1994==by 0x6E0179: zend_execute_scripts (zend.c:1194) ==1994==by 0x68F8CC: php_execute_script (main.c:2260) ==1994==by 0x76638D: main (php_cli.c:1192) ==1994== Address 0x106172f0 is 1,036,976 bytes inside a block of size 1,048,576 free'd ==1994==at 0x4C285A2: realloc (vg_replace_malloc.c:525) ==1994==by 0x702080: zend_objects_store_put (zend_objects_API.c:113) ==1994==by 0x6FE2C7: zend_objects_new (zend_objects.c:138) ==1994==by 0x6E86F2: _object_and_properties_init (zend_API.c:1079) ==1994==by 0x709168: ZEND_NEW_SPEC_HANDLER (zend_vm_execute.h:476) ==1994==by 0x704927: execute (zend_vm_execute.h:107) ==1994==by 0x6D6D03: zend_call_function (zend_execute_API.c:963) ==1994==by 0x6F5F4E: zend_call_method (zend_interfaces.c:97) ==1994==by 0x6FE4DE: zend_objects_destroy_object (zend_objects.c:113) ==1994==by 0x701F30: zend_objects_store_del_ref_by_handle_ex (zend_objects_API.c:206) ==1994==by 0x701F62: zend_objects_store_del_ref (zend_objects_API.c:172) ==1994==by 0x6D4B04:
Bug #52554 [Opn]: Sporadic PHP Segmentation fault in combination with unixODBC
Edit report at http://bugs.php.net/bug.php?id=52554&edit=1
ID: 52554
User updated by:cameron dot moller at gmail dot com
Reported by:cameron dot moller at gmail dot com
Summary:Sporadic PHP Segmentation fault in combination with
unixODBC
Status: Open
Type: Bug
Package:ODBC related
Operating System: 2.6.34-gentoo-r1 x86_64
PHP Version:5.3SVN-2010-08-06 (SVN)
Block user comment: N
New Comment:
Re-emergeing glibc did not help
Previous Comments:
[2010-08-06 12:27:31] cameron dot moller at gmail dot com
Description:
Gentoo Linux x86_64
Kernel 2.6.34-gentoo-r1
unixODBC-2.3.0
freeTDS 0.64
PHP 5.3.2 (from Gentoo portage (~ = experimental))
(problem started on PHP 5.2.13 - I upgraded to ~5.3.2)
Apache 2.2.15
gcc 4.4.3-r2
glibc 2.11.2
MSSQL 2005 (remote server)
I have multiple pages that query the database successfully. However, 2
queries always result in a segmentation fault. I ran the page through
gdb and generated a backtrace. Shown below.
The suspect sql is simply "select distinct asgn_group from
csc_report_active order by asgn_group asc"
FYI - sql via isql gives me 773 rows - no problems.
php.ini is vanilla - no changes - but dated Jul 30 - about when the
problem started. Though I do not remember ever making any changes to
php.ini
httpd.conf also vanilla as is /etc/conf.d/apache2
[I] dev-lang/php
Available versions: (5) 5.2.13 ~5.2.14 (~)5.3.2 ~5.3.3
{adabas apache2 bcmath berkdb birdstep bzip2 calendar cdb cgi
cjk (+)cli concurrentmodphp crypt (+)ctype curl curlwrappers db2 dbase
dbmaker debug discard-path doc embed empress empress-bcs enchant esoob
exif fastbuild fdftk +fileinfo (+)filter firebird flatfile
force-cgi-redirect fpm frontbase ftp gd gd-external gdbm gmp (+)hash
(+)iconv imap inifile interbase intl iodbc ipv6 java-external (+)json
kerberos kolab ldap ldap-sasl libedit mcve mhash msql mssql mysql mysqli
mysqlnd ncurses nls oci8 oci8-instant-client odbc pcntl (+)pcre pdo
+phar pic (+)posix postgres qdbm readline recode reflection sapdb
(+)session sharedext sharedmem (+)simplexml snmp soap sockets solid
spell spl sqlite sqlite3 ssl suhosin sybase sybase-ct sysvipc threads
tidy (+)tokenizer truetype unicode wddx xml xmlreader xmlrpc xmlwriter
xpm xsl yaz zip zlib}
Installed versions: 5.3.2(5)(08:26:30 07/30/10)(apache2 berkdb
bzip2 cli crypt ctype fileinfo filter gd gdbm hash iconv imap json
kerberos ldap mssql mysql nls odbc phar posix postgres readline session
simplexml ssl tokenizer truetype unicode xml zlib -adabas -bcmath
-birdstep -calendar -cdb -cgi -cjk -concurrentmodphp -curl -curlwrappers
-db2 -dbmaker -debug -doc -embed -empress -empress-bcs -enchant -esoob
-exif -firebird -flatfile -frontbase -ftp -gd-external -gmp -inifile
-interbase -intl -iodbc -ipv6 -kolab -ldap-sasl -libedit -mysqli
-mysqlnd -oci8 -oci8-instant-client -pcntl -pdo -pic -qdbm -recode
-sapdb -sharedext -sharedmem -snmp -soap -sockets -solid -spell -sqlite
-sqlite3 -suhosin -sybase-ct -sysvipc -threads -tidy -wddx -xmlreader
-xmlrpc -xmlwriter -xpm -xsl -zip)
gdb /usr/bin/php
warning: Can not parse XML syscalls information; XML support was
disabled at compile time.
GNU gdb (Gentoo 7.0.1 p1) 7.0.1
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
This is free software: you are free to change and redistribute it.
There is NO WARRANTY,
