#51009 [NEW]: PDO with pgsql returning NULL when integer expected in prepared query
From: peter at allicient dot co dot uk Operating system: FreeBSD 8.0 PHP version: 5.2.12 PHP Bug Type: PDO related Bug description: PDO with pgsql returning NULL when integer expected in prepared query Description: When using a prepared SELECT query of the form "SELECT table_a.column_id, table_a.column_some_string FROM table_a LEFT OUTER JOIN table_b ON (table_a.column_id = table_b.foreign_key_id)" - which executes successfully - there is a problem fetching the results. Using fetchAll( PDO::FETCH_ASSOC ) returns the rows with the strings intact but the column_id (integer) as NULL. PDO::FETCH_BOTH shows that numerically indexed rows have the column_id as expected but the error still present when indexed by the column name. The same query performed via pgadmin3 returns the expected results, and is the same as PDO::FETCH_NUM so there is definitely a problem with PDO::FETCH_ASSOC. Other SELECT queries work as expected, it seems to be related to the "LEFT OUTER JOIN". It can be coded around but is nonetheless a curious error. Expected result: For the PDO::FETCH_ASSOC to return the same data as PDO::FETCH_NUM. -- Edit bug report at http://bugs.php.net/?id=51009&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51009&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51009&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51009&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51009&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51009&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51009&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51009&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51009&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51009&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51009&r=support Expected behavior: http://bugs.php.net/fix.php?id=51009&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51009&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51009&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51009&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51009&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51009&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51009&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51009&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51009&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51009&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51009&r=mysqlcfg
#51008 [NEW]: Zend/tests/bug45877.phpt fails
From: geissert at debian dot org
Operating system: debian sid
PHP version: 5.3.1
PHP Bug Type: Unknown/Other Function
Bug description: Zend/tests/bug45877.phpt fails
Description:
The test fails
Reproduce code:
---
Expected result:
array(2) {
[2147483647]=>
int(1)
[-2147483648]=>
int(1)
["2147483648"]=>
int(1)
}
Actual result:
--
array(2) {
[2147483647]=>
int(1)
[-2147483648]=>
int(1)
}
--
Edit bug report at http://bugs.php.net/?id=51008&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51008&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51008&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51008&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51008&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51008&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51008&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51008&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51008&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51008&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51008&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51008&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51008&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51008&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51008&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51008&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51008&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51008&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51008&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51008&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51008&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51008&r=mysqlcfg
#51007 [NEW]: posix_uname{,_basic}.phpt are duplicates and lack handling of domainname
From: geissert at debian dot org
Operating system: debian
PHP version: 5.3.1
PHP Bug Type: POSIX related
Bug description: posix_uname{,_basic}.phpt are duplicates and lack handling of
domainname
Description:
Both tests test the same functionality and they both miss the case where
the domainname key may exist.
A simple workaround would be to unset($uname['domainname']) on _basic.phpt
and drop the other one.
--
Edit bug report at http://bugs.php.net/?id=51007&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51007&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51007&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51007&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51007&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51007&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51007&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51007&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51007&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51007&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51007&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51007&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51007&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51007&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51007&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51007&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51007&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51007&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51007&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51007&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51007&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51007&r=mysqlcfg
#51005 [Ana]: --without-sqlite3 should be --with-sqlite3
ID: 51005 Updated by: ras...@php.net Reported By: geissert at debian dot org Status: Analyzed Bug Type:*Compile Issues PHP Version: 5.3.1 New Comment: Yes, I am aware of that, but it is --without-sqlite3 there because by default if you don't specify anything you get sqlite3 compiled in since we bundle that library. So when you do ./configure --help you should see --without-sqlite3 as the listed option letting you know to use that to build PHP without it. Previous Comments: [2010-02-10 23:00:05] geissert at debian dot org Sorry for not being specific, I was talking about the description on the m4 file: PHP_ARG_WITH(sqlite3, whether to enable the SQLite3 extension, [ --without-sqlite3[=DIR] Do not include SQLite3 support. DIR is the prefix to SQLite3 installation directory.], yes) [2010-02-10 22:32:35] ras...@php.net The option is called --with-sqlite3. That's how autoconf works. You have --enable/--disable and --with/--without switches. If the feature is on by default then you use --disable/--without to turn it off. If the feature is off by default, then it is the opposite. Try it by using --with-sqlite3=/some/path But yes, the yes/no responses are messed up when using these. [2010-02-10 22:09:56] geissert at debian dot org Description: I just noticed sqlite3's config0.m4 has an inverted logic: --without-sqlite3 defaults to yes, which instead of NOT including sqlite3 it _does_ include it (using the bundled copy). --without-sqlite3=/foo also makes it include the extension, looking for the headers under /foo --without-sqlite3=no does not include it. IOW: the option should be called --with-sqlite3, not --without-sqlite3 -- Edit this bug report at http://bugs.php.net/?id=51005&edit=1
#51005 [Com]: --without-sqlite3 should be --with-sqlite3
ID: 51005 Comment by: geissert at debian dot org Reported By: geissert at debian dot org Status: Analyzed Bug Type:*Compile Issues PHP Version: 5.3.1 New Comment: Sorry for not being specific, I was talking about the description on the m4 file: PHP_ARG_WITH(sqlite3, whether to enable the SQLite3 extension, [ --without-sqlite3[=DIR] Do not include SQLite3 support. DIR is the prefix to SQLite3 installation directory.], yes) Previous Comments: [2010-02-10 22:32:35] ras...@php.net The option is called --with-sqlite3. That's how autoconf works. You have --enable/--disable and --with/--without switches. If the feature is on by default then you use --disable/--without to turn it off. If the feature is off by default, then it is the opposite. Try it by using --with-sqlite3=/some/path But yes, the yes/no responses are messed up when using these. [2010-02-10 22:09:56] geissert at debian dot org Description: I just noticed sqlite3's config0.m4 has an inverted logic: --without-sqlite3 defaults to yes, which instead of NOT including sqlite3 it _does_ include it (using the bundled copy). --without-sqlite3=/foo also makes it include the extension, looking for the headers under /foo --without-sqlite3=no does not include it. IOW: the option should be called --with-sqlite3, not --without-sqlite3 -- Edit this bug report at http://bugs.php.net/?id=51005&edit=1
#51005 [Opn->Ana]: --without-sqlite3 should be --with-sqlite3
ID: 51005 Updated by: ras...@php.net Reported By: geissert at debian dot org -Status: Open +Status: Analyzed Bug Type:*Compile Issues PHP Version: 5.3.1 New Comment: The option is called --with-sqlite3. That's how autoconf works. You have --enable/--disable and --with/--without switches. If the feature is on by default then you use --disable/--without to turn it off. If the feature is off by default, then it is the opposite. Try it by using --with-sqlite3=/some/path But yes, the yes/no responses are messed up when using these. Previous Comments: [2010-02-10 22:09:56] geissert at debian dot org Description: I just noticed sqlite3's config0.m4 has an inverted logic: --without-sqlite3 defaults to yes, which instead of NOT including sqlite3 it _does_ include it (using the bundled copy). --without-sqlite3=/foo also makes it include the extension, looking for the headers under /foo --without-sqlite3=no does not include it. IOW: the option should be called --with-sqlite3, not --without-sqlite3 -- Edit this bug report at http://bugs.php.net/?id=51005&edit=1
#51005 [NEW]: --without-sqlite3 should be --with-sqlite3
From: geissert at debian dot org Operating system: PHP version: 5.3.1 PHP Bug Type: *Compile Issues Bug description: --without-sqlite3 should be --with-sqlite3 Description: I just noticed sqlite3's config0.m4 has an inverted logic: --without-sqlite3 defaults to yes, which instead of NOT including sqlite3 it _does_ include it (using the bundled copy). --without-sqlite3=/foo also makes it include the extension, looking for the headers under /foo --without-sqlite3=no does not include it. IOW: the option should be called --with-sqlite3, not --without-sqlite3 -- Edit bug report at http://bugs.php.net/?id=51005&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51005&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51005&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51005&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51005&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51005&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51005&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51005&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51005&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51005&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51005&r=support Expected behavior: http://bugs.php.net/fix.php?id=51005&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51005&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51005&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51005&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51005&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51005&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51005&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51005&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51005&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51005&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51005&r=mysqlcfg
#50978 [Opn->Fbk]: OciFetchStatement
ID: 50978 Updated by: s...@php.net Reported By: atila at nutroeste dot com dot br -Status: Open +Status: Feedback Bug Type: OCI8 related Operating System: RHEL 5.2 64 BITS PHP Version: 5.2.12 Assigned To: sixd New Comment: Some thoughts: - really verify the statement should succeed and there is data in the table - echo the statement out and make sure there are no syntax errors - add error checking to your OCI calls - make sure the table is not being modified (e.g columns added or data removed) by another job - after getting the error, verify your script runs with command line PHP (instead of using a DB tool) Previous Comments: [2010-02-10 12:53:33] atila at nutroeste dot com dot br Sorry if I wasn't clear enough,and if you want I could give you accesses do my server by Terminal Server, to see the real sql. please be comfortable to contact me by e-mail, and anything to help you to resolve this please!!! ask me. Because my transactional system has been passed by a lot o changes and I had to create a lot of union's between what I had and the customizations I have now. Thanks a Lot for your attention Atila Santos [2010-02-09 21:49:58] johan...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-02-09 20:13:21] atila at nutroeste dot com dot br Description: Dears, The function is OciFetchStatement. Since I have more than 2 times the same problem, and the task to resolve this was to hard. I have to report that every time I use a complex sql using operator union or union all, the return message is Notice: Undefined offset: 0 in /usr/local/apache/html/pedidos/teste_union.php on line 19 numero de linhas: As you can see the "Undefined offset: 0" means that there is no record to be retrived from a query, but if I run this same query using my database tool, a result could be seen. To resolve this I had to create temporary tables to insert the data into it's own structure using my sql union/union all query to became only one table and force the OciFetchStatement to retrive the results I wanted. My database is Oracle 10.2.04 running on Linux rhel 5.2 64bits. My php version is source 5.2.9 running in the same host. Thanks an advance Atila Santos mail: at...@nutroeste.com.br Country Brazil State Goias, city: Goiania +5562-30962539/2500 System Analist/Dba Oracle/Web Developer Reproduce code: --- Notice: Undefined offset: 0 in /usr/local/apache/html/pedidos/teste_union.php on line 19 Expected result: The result should bring me up values of rows. -- Edit this bug report at http://bugs.php.net/?id=50978&edit=1
#50998 [Com]: unaligned memory access in hash_tiger.c
ID: 50998 Comment by: geissert at debian dot org Reported By: geissert at debian dot org Status: Open Bug Type: hash related Operating System: linux ia64 PHP Version: 5.3.1 New Comment: Failed test: ext/hash/tests/mhash_001.phpt Output: MHASH_MD5 ok MHASH_SHA1 ok MHASH_HAVAL256 ok MHASH_HAVAL192 ok MHASH_HAVAL224 ok MHASH_HAVAL160 ok MHASH_RIPEMD160 ok MHASH_GOST ok Bus error (core dumped) Previous Comments: [2010-02-10 19:06:50] geissert at debian dot org Description: ext/hash/hash_tiger.c's TigerFinalize makes an unaligned memory access at: tiger_compress(context->passes, ((php_hash_uint64 *) context->buffer), context->state); -- Edit this bug report at http://bugs.php.net/?id=50998&edit=1
#51003 [NEW]: unaligned memory access in ext/hash/hash_tiger.c
From: geissert at debian dot org Operating system: linux ia64 PHP version: 5.3.1 PHP Bug Type: Reproducible crash Bug description: unaligned memory access in ext/hash/hash_tiger.c Description: There's an unaligned memory access on PHP_TIGERUpdate(): tiger_compress(context->passes, ((const php_hash_uint64 *) context->buffer), context->state); Failed test ext/hash/tests/hash_file_basic1.phpt Actual result: -- *** Testing hash_file() : basic functionality *** adler32: ff87222e crc32: 61664d33 gost: d9e65f0c0c2ef944e4f8a01f4a46365c4f33a2853756878182a7f03e1490a4cd haval128,3: 8bb81269aca8b7f87829020d76a4e841 md2: 70f791c0d8fa9edd7d08e32fcba8c354 md4: a9d034b16bb290c57a645afd6f14cd3b md5: 704bf818448f5bbb94061332d2c889aa ripemd128: d02a5f320a11c54c7d51f933b0bd8471 ripemd160: 3ff296ca6314313af3ed0437c8fc0ebbd3242d3b ripemd256: 0edd779587c11cf3278b264251eb37529832fb207121cd45dd95002e48a8 ripemd320: bf162fa2ff20491b3016c5d8190f8ee47d7dcda8c38eaf6779349a243a029d275eec9adf16ec1b35 sha1: 8529b266611e3bd0d208fd9614653c2a8f23d0fe sha256: a0f5702fa5d3670b80033d668e8732b70550392abb53841355447f8bb0f72245 sha384: a35d875ed96d94b6452acad910f97978200faa2398d8a0e6b9cffa33704c3809e3d2e5b0d63700d8f32a0716e7d2d528 sha512: 1f42adaf938fbf136e381b164bae5f984c7f9fe60c82728bd889c14f187c7d63e81a0305a1731c7e0a8f3ed9fd2ec92a3833a93502bdf269532601f0b8e2bab0 snefru: d414b2345d3e7fa1a31c044cf334bfc1fec24d89e464411998d579d24663895f Bus error (core dumped) -- Edit bug report at http://bugs.php.net/?id=51003&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51003&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51003&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51003&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51003&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51003&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51003&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51003&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51003&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51003&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51003&r=support Expected behavior: http://bugs.php.net/fix.php?id=51003&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51003&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51003&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51003&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51003&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51003&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51003&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51003&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51003&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51003&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51003&r=mysqlcfg
#50999 [Com]: unaligned memory access in Zend/zend_API.c
ID: 50999 Comment by: geissert at debian dot org Reported By: geissert at debian dot org Status: Open Bug Type: Reproducible crash Operating System: linux ia64 PHP Version: 5.3.1 New Comment: Failed test: ext/dba/tests/dba_cdb_read.phpt log: EXPECTED OUTPUT database handler: cdb 7NNN =1234 #1122 ?1212314 #1212314 =1231324 ACTUAL OUTPUT database handler: cdb 7NNN =1234 #1122 ?1212314 #1212314 =Bus error (core dumped) FAILED Previous Comments: [2010-02-10 19:12:28] geissert at debian dot org Description: There's an unaligned memory access on zend_parse_arg_impl(): *p = Z_LVAL_PP(arg); -- Edit this bug report at http://bugs.php.net/?id=50999&edit=1
#50987 [Com]: unaligned memory access in phar.c
ID: 50987 Comment by: geissert at debian dot org Reported By: geissert at debian dot org Status: Feedback Bug Type: PHAR related Operating System: linux ia64 PHP Version: 5.3.1 New Comment: The phar one was found while building the extension itself (the call to php in ext/phar/Makefile.frag to generate phar.php.) There are probably more, but still have to process them. In the meanwhile, here's another (found while unpacking pear): @@ -512,7 +512,7 @@ void phar_entry_remove(phar_entry_data * (buffer) += 2 #else # define PHAR_GET_32(buffer, var) \ - var = *(php_uint32*)(buffer); \ + memcpy(&var, buffer, sizeof(var)); \ buffer += 4 # define PHAR_GET_16(buffer, var) \ var = *(php_uint16*)(buffer); \ As for CFLAGS: -O2 -Wall -fsigned-char -fno-strict-aliasing -g -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security Should be easy for you to find them by running the test suite under prctl --unaligned=signal (all the phar tests will fail.) That's how I found them all (I can provide the name of the tests that failed in a moment, I'm rebuilding with the patches I already provided.) Previous Comments: [2010-02-10 20:05:21] paj...@php.net hi, Can you provide test cases for these crashes please? As well as your settings (CFLAGS&co) as I can't see crashes on IA64 here (or other 64bit platforms). Same applies for your other reports :) Thanks for your feedback! [2010-02-10 07:27:23] geissert at debian dot org Description: There's an unaligned memory access in ext/phar/phar.c's phar_set_32 function. The following patch fixes it: --- php.orig/ext/phar/phar.c +++ php/ext/phar/phar.c @@ -2491,7 +2491,7 @@ static inline void phar_set_32(char *buf *((buffer) + 1) = (unsigned char) (((var) >> 8) & 0xFF); *((buffer) + 0) = (unsigned char) ((var) & 0xFF); #else - *(php_uint32 *)(buffer) = (php_uint32)(var); + memcpy(buffer, &var, sizeof(var)); #endif } /* }}} */ -- Edit this bug report at http://bugs.php.net/?id=50987&edit=1
#50977 [Fbk->Opn]: imap_headerinfo Address buffer overflow
ID: 50977 User updated by: lokitek at gmail dot com Reported By: lokitek at gmail dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: CentOS 5.4 PHP Version: 5.2.12 New Comment: drop centOS isn't all that easy - What would you recommend instead? ;) I'll update c-client and will let you know. Thanks! Previous Comments: [2010-02-10 16:24:41] paj...@php.net Yes, or you may drop centos as well, known to have outdated versions of everything. Please let us know if it still happens once you have a decent version if c-client. [2010-02-10 16:06:17] lokitek at gmail dot com The c-client library is: libc-client 2004g-2.2.1 2004 sounds somewhat old, should I try to find an upgrade for it? [2010-02-10 00:16:36] paj...@php.net I'm not asking which PHP version you use (try 5.2.12, instead of 5.2.11) but which c-client library you use. c-client is the imap library used by the php imap extension. [2010-02-10 00:12:41] lokitek at gmail dot com I don't think that it makes a huge difference, but I just realized that I'm on php-5.2.11 and using php-imap-5.2.11 If this isn't what you're after, just let me know and I can do a bit of debugging all around. Thanks! [2010-02-09 19:06:57] paj...@php.net Which imap version do you use? 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/50977 -- Edit this bug report at http://bugs.php.net/?id=50977&edit=1
#51002 [Opn->Asn]: An int variable is used as size_t in child function
ID: 51002 Updated by: johan...@php.net Reported By: s...@php.net -Status: Open +Status: Assigned Bug Type: Zip Related Operating System: n/a PHP Version: 5.3.2RC1 -Assigned To: +Assigned To: pajoye New Comment: Assign to maintainer Previous Comments: [2010-02-10 20:07:06] s...@php.net Description: In php_zip_add_from_pattern() a pointer to file_stripped_len is passed to php_based which treats the address as a size_t. If the size of int differs from the size of size_t then this could cause a memory access error. int entry_name_len,file_stripped_len; ... php_basename(Z_STRVAL_PP(zval_file), Z_STRLEN_PP(zval_file), NULL, 0, &basename, (size_t *)&file_stripped_len TSRMLS_CC) This is related to Rasmus's fix http://svn.php.net/viewvc?view=revision&revision=294816 -- Edit this bug report at http://bugs.php.net/?id=51002&edit=1
#51002 [NEW]: An int variable is used as size_t in child function
From: s...@php.net Operating system: n/a PHP version: 5.3.2RC1 PHP Bug Type: Zip Related Bug description: An int variable is used as size_t in child function Description: In php_zip_add_from_pattern() a pointer to file_stripped_len is passed to php_based which treats the address as a size_t. If the size of int differs from the size of size_t then this could cause a memory access error. int entry_name_len,file_stripped_len; ... php_basename(Z_STRVAL_PP(zval_file), Z_STRLEN_PP(zval_file), NULL, 0, &basename, (size_t *)&file_stripped_len TSRMLS_CC) This is related to Rasmus's fix http://svn.php.net/viewvc?view=revision&revision=294816 -- Edit bug report at http://bugs.php.net/?id=51002&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51002&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51002&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51002&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51002&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51002&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51002&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51002&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51002&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51002&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51002&r=support Expected behavior: http://bugs.php.net/fix.php?id=51002&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51002&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51002&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51002&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51002&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51002&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51002&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51002&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51002&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51002&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51002&r=mysqlcfg
#51001 [NEW]: Always shows stack trace when a Fatal error occurs
From: abdallah at gmx dot com
Operating system: Windows 7
PHP version: 5.3.1
PHP Bug Type: Feature/Change Request
Bug description: Always shows stack trace when a Fatal error occurs
Description:
Always shows stack trace when a Fatal error occurs without having to do
always something like this :
getTraceAsString();
}
?>
Reproduce code:
---
getTraceAsString();
}
?>
Expected result:
#0 /home/bjori/tmp/ex.php(7): test()
#1 {main}
Actual result:
--
nothin'
--
Edit bug report at http://bugs.php.net/?id=51001&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51001&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51001&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51001&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51001&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51001&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51001&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51001&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51001&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51001&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51001&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51001&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51001&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51001&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51001&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51001&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51001&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51001&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51001&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51001&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51001&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51001&r=mysqlcfg
#50987 [Opn->Fbk]: unaligned memory access in phar.c
ID: 50987 Updated by: paj...@php.net Reported By: geissert at debian dot org -Status: Open +Status: Feedback Bug Type: PHAR related Operating System: linux ia64 PHP Version: 5.3.1 New Comment: hi, Can you provide test cases for these crashes please? As well as your settings (CFLAGS&co) as I can't see crashes on IA64 here (or other 64bit platforms). Same applies for your other reports :) Thanks for your feedback! Previous Comments: [2010-02-10 07:27:23] geissert at debian dot org Description: There's an unaligned memory access in ext/phar/phar.c's phar_set_32 function. The following patch fixes it: --- php.orig/ext/phar/phar.c +++ php/ext/phar/phar.c @@ -2491,7 +2491,7 @@ static inline void phar_set_32(char *buf *((buffer) + 1) = (unsigned char) (((var) >> 8) & 0xFF); *((buffer) + 0) = (unsigned char) ((var) & 0xFF); #else - *(php_uint32 *)(buffer) = (php_uint32)(var); + memcpy(buffer, &var, sizeof(var)); #endif } /* }}} */ -- Edit this bug report at http://bugs.php.net/?id=50987&edit=1
#51000 [NEW]: unaligned memory access in ext/hash/hash_tiger.c
From: geissert at debian dot org Operating system: linux ia64 PHP version: 5.3.1 PHP Bug Type: Reproducible crash Bug description: unaligned memory access in ext/hash/hash_tiger.c Description: There's an unaligned memory access on PHP_TIGERUpdate(): context->passed += 512; -- Edit bug report at http://bugs.php.net/?id=51000&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51000&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51000&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51000&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51000&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51000&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51000&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51000&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51000&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51000&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51000&r=support Expected behavior: http://bugs.php.net/fix.php?id=51000&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51000&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51000&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51000&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51000&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51000&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51000&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51000&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51000&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51000&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51000&r=mysqlcfg
#50999 [NEW]: unaligned memory access in Zend/zend_API.c
From: geissert at debian dot org Operating system: linux ia64 PHP version: 5.3.1 PHP Bug Type: Reproducible crash Bug description: unaligned memory access in Zend/zend_API.c Description: There's an unaligned memory access on zend_parse_arg_impl(): *p = Z_LVAL_PP(arg); -- Edit bug report at http://bugs.php.net/?id=50999&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50999&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50999&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50999&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50999&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50999&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50999&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50999&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50999&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50999&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50999&r=support Expected behavior: http://bugs.php.net/fix.php?id=50999&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50999&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50999&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50999&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50999&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50999&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50999&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50999&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50999&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50999&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50999&r=mysqlcfg
#50998 [NEW]: unaligned memory access in hash_tiger.c
From: geissert at debian dot org Operating system: linux ia64 PHP version: 5.3.1 PHP Bug Type: hash related Bug description: unaligned memory access in hash_tiger.c Description: ext/hash/hash_tiger.c's TigerFinalize makes an unaligned memory access at: tiger_compress(context->passes, ((php_hash_uint64 *) context->buffer), context->state); -- Edit bug report at http://bugs.php.net/?id=50998&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50998&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50998&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50998&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50998&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50998&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50998&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50998&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50998&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50998&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50998&r=support Expected behavior: http://bugs.php.net/fix.php?id=50998&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50998&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50998&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50998&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50998&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50998&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50998&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50998&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50998&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50998&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50998&r=mysqlcfg
#50973 [Opn]: DOMDocument::saveHTML() should be able to take a node as an arg
ID: 50973 User updated by: geoffers+phpbugs at gmail dot com Reported By: geoffers+phpbugs at gmail dot com Status: Open Bug Type: DOM XML related Operating System: N/A PHP Version: 5.3SVN-2010-02-09 (SVN) New Comment: http://pastebin.ca/1792855 is a patch for this, based upon saveXML(). There is one notable difference between what I have, based on that, and what is currently there: the if (mem) within the if (!size) is not present within saveXML(), and nor as a result in my patch. I presume that it should either be in both saveXML and saveHTML or neither: any idea? And, of course, my prior comment was wrong: it's only saveXML() which has the argument, not save(). Previous Comments: [2010-02-09 16:00:06] geoffers+phpbugs at gmail dot com Description: At the moment DOMDocument::save() and DOMDocument::saveXML() both take an optional first argument which is a node to serialize; DOMDocument::saveHTML() and DOMDocument::saveHTMLFile() have no such option and always serialize the whole file. For cases where HTML serialization is needed of a specific node, all that can be done is doing it within PHP code (which is comparatively very slow). As libxml includes the needed APIs to do this, it doesn't appear to be overly complex to implement. I'll try to write a patch for this later. -- Edit this bug report at http://bugs.php.net/?id=50973&edit=1
#50997 [NEW]: SOAP Error when trying to submit 2nd Element of a choice
From: mrsharp at gmx dot de Operating system: debian PHP version: 5.2.12 PHP Bug Type: SOAP related Bug description: SOAP Error when trying to submit 2nd Element of a choice Description: My Actual PHP Version: PHP Version 5.2.11-0.dotdeb.0 not 100% sure if this relates to Bug #43723: "SOAP not sent properly from client for " because SOAP is not sent at all in my scenario (Fatal Error) Part of my WSDL is this schema excerpt A SOAP operation now employs this type... if I attempt to submit a property set which resembles "someGroupDefB" I receive a SOAP-ERROR: Encoding: object hasn't someGroupDefA property so it seems that choice is not properly evalutated... Expected result: I expect that SOAP accepts both sets of parameters without complaining about the other missing... -- Edit bug report at http://bugs.php.net/?id=50997&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50997&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50997&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50997&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50997&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50997&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50997&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50997&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50997&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50997&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50997&r=support Expected behavior: http://bugs.php.net/fix.php?id=50997&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50997&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50997&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50997&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50997&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50997&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50997&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50997&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50997&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50997&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50997&r=mysqlcfg
#49996 [Asn->Fbk]: DateTimeZone::getTransitions performance drop
ID: 49996
Updated by: der...@php.net
Reported By: dor at videocells dot com
-Status: Assigned
+Status: Feedback
Bug Type: Performance problem
Operating System: Centos 5.2 64 bit
PHP Version: 5.3.0
Assigned To: derick
New Comment:
Are you using Centos' packages?
Previous Comments:
[2009-10-28 07:52:30] der...@php.net
It's indeed quite a bit slower... not sure if this is a *bug* though,
but will check it out.
[2009-10-28 06:56:30] dor at videocells dot com
I have two exact computers in terms of OS installation and apache/php
configuration (except the php 5.3 against php 5.2.9)
the average speed this function takes to run in php 5.2.9 is :
float(0.015974044799805) float(0.0457763671875)
float(0.04506450195) float(0.65398216247559) float(0.92506408691406)
float(0.70810317993164) float(0.19216537475586) float(0.32210350036621)
float(0.73885917663574) float(0.16283988952637) float(0.94914436340332)
float(0.62394142150879) float(0.25200843811035)
while on php 5.3 its :
float(63.025951385498) float(62.762022018433) float(62.709093093872)
float(63.004970550537) float(63.482046127319) float(63.012838363647)
float(62.775135040283) float(62.896966934204) float(63.131093978882)
float(63.91716003418) float(63.18211555481)
its 60 times slower.
can i somehow send a print screen, or attach the printouts of both
computer's phpinfo() ?
[2009-10-27 22:27:17] j...@php.net
With this simplified and working (!) script I get exactly same results
with PHP_5_2, PHP_5_3 and HEAD of today:
"Etc/GMT+12",
"(GMT -11:00) Midway Island, Samoa" => "Pacific/Midway",
"(GMT -10:00) Hawaii" => "US/Hawaii",
// many many more time zones...
"(GMT +12:00) Auckland, Wellington" => "Pacific/Auckland",
"(GMT +12:00) Fiji, Kamchatka, Marshall Is." => "Asia/Kamchatka",
"(GMT +13:00) Nuku'alofa" => "Pacific/Tongatapu");
foreach ($timezoneArray as $TimezoneDescription => $TimezoneID)
{
$res = timezone_open($TimezoneID);
if($res)
{
$start = microtime(true);
$trans = $res->getTransitions();
$end = microtime(true);
var_dump(1000 * ($end - $start));
}
}
?>
Now, where is the performance issue here?
[2009-10-27 06:55:10] dor at videocells dot com
"Etc/GMT+12",
"(GMT -11:00) Midway Island, Samoa" => "Pacific/Midway",
"(GMT -10:00) Hawaii" => "US/Hawaii",
// many many more time zones...
"(GMT +12:00) Auckland, Wellington" => "Pacific/Auckland",
"(GMT +12:00) Fiji, Kamchatka, Marshall Is." => "Asia/Kamchatka",
"(GMT +13:00) Nuku'alofa" => "Pacific/Tongatapu");
foreach ($timezoneArray as $TimezoneDescription => $TimezoneID)
{
$res = timezone_open($TimezoneID)
if($res)
{
$TimeInTimezone = new DateTime ("now",$res)
$microParts = explode(" ",microtime());
list($a,$b) = explode(".",$microParts[0]);
echo "before : ".strftime('%Y%m%d-%H%M%S',time()).".".$b;
//the following line takes alot of time :
$trans = $res->getTransitions();
$microParts_2 = explode(" ",microtime());
list($c,$d) = explode(".",$microParts_2[0]);
echo "before : ".strftime('%Y%m%d-%H%M%S',time()).".".$d;}
}
[2009-10-26 22:49:11] j...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
And preferrably such which does not have several syntax errors and
missing parts..
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/49996
--
Edit this bug report at http://bugs.php.net/?id=49996&edit=1
#49585 [Asn->Csd]: date_format buffer not long enough for >4 digit years
ID: 49585 Updated by: der...@php.net Reported By: ahar...@php.net -Status: Assigned +Status: Closed Bug Type: Date/time related Operating System: Linux (Ubuntu 9.04) PHP Version: 5.3SVN-2009-09-18 (SVN) Assigned To: derick New Comment: 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2010-02-10 16:55:41] s...@php.net Automatic comment from SVN on behalf of derick Revision: http://svn.php.net/viewvc/?view=revision&revision=294855 Log: - Fixed bug #49585 (date_format buffer not long enough for >4 digit years). #- Was already partly fixed with my previous commit. [2009-09-18 09:28:23] ahar...@php.net Gah, just found another corner case while writing the PHPT case. The "short" day name used by 'r' may not actually be three characters in all cases -- 'Unknown' can be returned. Ergo, we need another four characters. Revised patch: http://www.adamharvey.name/stuff/date-format-buffer-64-revised.patch PHPT test case: http://www.adamharvey.name/stuff/bug49585.phpt [2009-09-18 09:10:18] ahar...@php.net By which I mean http://www.adamharvey.name/stuff/date-format-buffer-64.patch -- the PHP bug tracker's autolinking picked up the full stop. :) [2009-09-18 09:09:32] ahar...@php.net Actually, I'm running a 64 bit machine anyway; the point is that the explicit (int) cast will be 32 bit regardless on an LP64 or LLP64 architecture. Nevertheless, a patch that can definitely handle 64 bit ints is at http://www.adamharvey.name/stuff/date-format-buffer-64.patch. [2009-09-18 09:01:48] der...@php.net Oh, and a few phpt test cases would be awesome too :-) 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/49585 -- Edit this bug report at http://bugs.php.net/?id=49585&edit=1
#47199 [Com]: pg_delete fails on NULL
ID: 47199 Comment by: ewgraf at gmail dot com Reported By: andrew at labyrinth-it dot co dot uk Status: Open Bug Type: PostgreSQL related Operating System: Linux (Fedora) PHP Version: 5.2.10 New Comment: Patch for this bug: http://news.php.net/php.internals/46974 Previous Comments: [2009-05-31 06:27:21] andrew at labyrinth-it dot co dot uk Sorry, I think I posted my reply in the wrong place, so let me try again. I have just downloaded and tested the latest PHP version: PHP 5.2.10RC2-dev (cli) (built: May 31 2009 07:16:36) With this version I still get the same error. The Postgresql version I am testing against is: PostgreSQL 8.3.5 on i386-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.3.2 20081007 (Red Hat 4.3.2-6) The call to: print(pg_delete($db,'demo',$row,PGSQL_DML_STRING)) still prints out: DELETE FROM demo WHERE id=1 AND col1=NULL; The final test should use the SQL language "IS NULL" test rather than "=NULL" which never evaluates to true. The same problem exists if using pg_update, which produces: UPDATE demo SET id=2,col1='Two' WHERE id=1 AND col1=NULL; Again, "col1=NULL" will never evaluate to true using SQL, and the test col1 IS NULL should be used instead. [2009-05-19 15:34:41] andrew at labyrinth-it dot co dot uk For completeness, I get the error running on Fedora 10 with Postgres 8.3.5 [2009-05-19 15:31:54] andrew at labyrinth-it dot co dot uk I am using: PHP 5.2.10-dev (cli) (built: May 19 2009 15:40:36) and still get the same error result. This error is also in the pg_update function, where NULl values are compared with "= NULL" rather than "IS NULL" in the WHERE part of the generated SQL. [2009-01-23 11:46:35] andrew at labyrinth-it dot co dot uk Description: pg_delete uses incorrect syntax for NULL columns. The code generated compares values with "col = NULL" instead of "col IS NULL". As a result, the row is not matched so is not deleted. Reproduce code: --- 1 [col1] => ) DELETE FROM demo WHERE id=1 AND col1 IS NULL; Actual result: -- When this runs, the second loop displays results for tables that have NULL columns at the start of the run. --- Array ( [id] => 1 [col1] => ) DELETE FROM demo WHERE id=1 AND col1=NULL; Array ( [id] => 1 [col1] => ) -- Edit this bug report at http://bugs.php.net/?id=47199&edit=1
#50977 [Opn->Fbk]: imap_headerinfo Address buffer overflow
ID: 50977
Updated by: paj...@php.net
Reported By: lokitek at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: CentOS 5.4
PHP Version: 5.2.12
New Comment:
Yes, or you may drop centos as well, known to have outdated versions of
everything. Please let us know if it still happens once you have a
decent version if c-client.
Previous Comments:
[2010-02-10 16:06:17] lokitek at gmail dot com
The c-client library is:
libc-client 2004g-2.2.1
2004 sounds somewhat old, should I try to find an upgrade for it?
[2010-02-10 00:16:36] paj...@php.net
I'm not asking which PHP version you use (try 5.2.12, instead of
5.2.11) but which c-client library you use. c-client is the imap library
used by the php imap extension.
[2010-02-10 00:12:41] lokitek at gmail dot com
I don't think that it makes a huge difference, but I just realized that
I'm on php-5.2.11 and using php-imap-5.2.11
If this isn't what you're after, just let me know and I can do a bit of
debugging all around.
Thanks!
[2010-02-09 19:06:57] paj...@php.net
Which imap version do you use?
[2010-02-09 19:00:23] lokitek at gmail dot com
Description:
While using the imap_headerinfo() function to obtain information about
emails that I check via IMAP, I noticed that PHP complained about
imap_headerinfo() Address buffer overflow.
A bit of investigation revealed that a spam message containing 500+ CC
email addresses caused this issue.
Reproduce code:
---
// Send an email with 500+ CCd users. then use imap_headerinfo() to //
obtain all header information.
// [from doc]
$mBox = imap_open("{host:143/imap/novalidate-cert}INBOX}", $username,
$password); // open as imap
$header = imap_header($mBox, 1); // get first mails header
// imap_headerinfo() will crash with the following error:
// PHP Fatal error: imap_headerinfo(): Address buffer overflow
Expected result:
I expect to information about the given message number by reading its
headers and returned in an object format
Actual result:
--
PHP Fatal error: imap_headerinfo(): Address buffer overflow
--
Edit this bug report at http://bugs.php.net/?id=50977&edit=1
#50930 [Asn->Csd]: wrong date by php_date.c patch with ancient gcc/glibc versions
ID: 50930 Updated by: der...@php.net Reported By: nathan dot kessler at hushmail dot me -Status: Assigned +Status: Closed Bug Type: Date/time related Operating System: SuSE 7.3 i386 / gcc version 2.95 PHP Version: 5.*, 6 Assigned To: derick New Comment: 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/. Thank you for the report, and for helping us make PHP better. Fixed in rev. 294854 by always relying on our own function. Previous Comments: [2010-02-10 16:23:32] s...@php.net Automatic comment from SVN on behalf of derick Revision: http://svn.php.net/viewvc/?view=revision&revision=294854 Log: - Added a test case for bug #45866 - Fixed tests: oo_002, bug46268 - Fixed bug #50930 (Wrong date by php_date.c patch with ancient gcc/glibc versions). - Make sure faulty strings passed to DateTime::modify() notify the user. - Revert fix for bug #50392 as it was fixed wrongly without a proper test case. - Fixed a bug with the 'r' formatting function as the default buffer size that was allocated only fit 4 digit years. [2010-02-04 18:57:53] j...@php.net I'll leave it for Derick to decide what to do. I suggest removing the whole check from config.m4 and replacing the llabs() stuff with some own macro/function used always for any and all compilers and systems. [2010-02-04 02:33:49] kmcgrail at apache dot org In my previous comment, I referred to the wrong patch. I meant to say remove 291371. The cookie warning from 286508 is good and valid IMO. OK, so I believe the patch in 291371 definitely is causing the issue in combination with older GCC's. Here's the testing I've done: PHP 5.2.12 compiled by gcc 3.2.3 - SquirrelMail 1.2.19 works as well as PHPMyAdmin 2.11.10. PHP 5.2.12 compiled by gcc 2.9.6 - SM 1.2.19 is broken with the error "You must be logged in to access this page." PHPMyAdmin sporadically triggers "Warning: Expiry date cannot have a year greater then " Finally, PHP 5.2.12 compiled with revision 291371 removed with GCC 2.96 - PHPMyadmin & SquirrelMail works. So I think the issue is with the llabs call as you expected and my experience confirms it. If you have a patch you want me to test, let me know. [2010-02-03 23:28:37] j...@php.net Oops, that bug was no warning but an error. So can't really just revert.. [2010-02-03 23:26:34] j...@php.net I'm considering reverting the patch for fixing bug #50266 since that was only a warning anyway..need to investigate a bit more though. 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/50930 -- Edit this bug report at http://bugs.php.net/?id=50930&edit=1
#50977 [Fbk->Opn]: imap_headerinfo Address buffer overflow
ID: 50977
User updated by: lokitek at gmail dot com
Reported By: lokitek at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: CentOS 5.4
PHP Version: 5.2.12
New Comment:
The c-client library is:
libc-client 2004g-2.2.1
2004 sounds somewhat old, should I try to find an upgrade for it?
Previous Comments:
[2010-02-10 00:16:36] paj...@php.net
I'm not asking which PHP version you use (try 5.2.12, instead of
5.2.11) but which c-client library you use. c-client is the imap library
used by the php imap extension.
[2010-02-10 00:12:41] lokitek at gmail dot com
I don't think that it makes a huge difference, but I just realized that
I'm on php-5.2.11 and using php-imap-5.2.11
If this isn't what you're after, just let me know and I can do a bit of
debugging all around.
Thanks!
[2010-02-09 19:06:57] paj...@php.net
Which imap version do you use?
[2010-02-09 19:00:23] lokitek at gmail dot com
Description:
While using the imap_headerinfo() function to obtain information about
emails that I check via IMAP, I noticed that PHP complained about
imap_headerinfo() Address buffer overflow.
A bit of investigation revealed that a spam message containing 500+ CC
email addresses caused this issue.
Reproduce code:
---
// Send an email with 500+ CCd users. then use imap_headerinfo() to //
obtain all header information.
// [from doc]
$mBox = imap_open("{host:143/imap/novalidate-cert}INBOX}", $username,
$password); // open as imap
$header = imap_header($mBox, 1); // get first mails header
// imap_headerinfo() will crash with the following error:
// PHP Fatal error: imap_headerinfo(): Address buffer overflow
Expected result:
I expect to information about the given message number by reading its
headers and returned in an object format
Actual result:
--
PHP Fatal error: imap_headerinfo(): Address buffer overflow
--
Edit this bug report at http://bugs.php.net/?id=50977&edit=1
#50995 [NEW]: segfault with Zend Memory Manager = enabled
From: valters at videinfra dot com Operating system: Debian Lenny PHP version: 5.2.12 PHP Bug Type: Unknown/Other Function Bug description: segfault with Zend Memory Manager = enabled Description: ./configure --prefix=/usr/local/php5.2 --sysconfdir=/etc --with-apxs2=/usr/local/apache/bin/apxs --with-config-file-path=/etc/php/apache2-php5 --with-config-file-scan-dir=/etc/php/apache2-php5/ext-active --without-pear --enable-bcmath --enable-calendar --with-curl --enable-exif --enable-ftp --with-gettext --with-gmp --enable-mbstring --with-mcrypt --with-mhash --with-openssl --with-openssl-dir --with-pgsql --with-pspell --enable-soap --enable-sockets --with-xmlrpc --with-xsl --enable-zip --with-zlib --enable-dba --with-db4 --with-gdbm --with-freetype-dir --with-jpeg-dir --with-png-dir --with-gd --with-imap --with-imap-ssl --with-ldap --with-pdo-dblib --with-pdo-pgsql --with-pdo-sqlite --with-readline --with-sqlite --enable-sqlite-utf8 --with-kerberos --disable-ipv6 there is no segfault with --enable-debug and it seems that this crash happens after the end of the script. The crash happens when php is compiled with Zend Memory Manager = enabled Server version: Apache/2.2.14 (Unix) [notice] child pid 8480 exit signal Segmentation fault (11) Actual result: -- 0xb79d7ffa in zend_mm_remove_from_free_list (heap=, mm_block=0x8f35784) at /root/php-5.2.12/Zend/zend_alloc.c:822 822 ZEND_MM_CHECK_TREE(mm_block); (gdb) bt #0 0xb79d7ffa in zend_mm_remove_from_free_list (heap=, mm_block=0x8f35784) at /root/php-5.2.12/Zend/zend_alloc.c:822 #1 0xb79d8131 in _zend_mm_free_int (heap=0x8965fd8, p=) at /root/php-5.2.12/Zend/zend_alloc.c:1979 #2 0xb79fbe5a in zend_hash_destroy (ht=0x8f36c64) at /root/php-5.2.12/Zend/zend_hash.c:531 #3 0xb79f18d5 in _zval_dtor_func (zvalue=0x8f42320) at /root/php-5.2.12/Zend/zend_variables.c:42 #4 0xb79e5460 in _zval_ptr_dtor (zval_ptr=0x8f41fc0) at /root/php-5.2.12/Zend/zend_variables.h:35 #5 0xb79fbe2e in zend_hash_destroy (ht=0x8f36e7c) at /root/php-5.2.12/Zend/zend_hash.c:526 #6 0xb7a0bcb3 in zend_object_std_dtor (object=0x8f41460) at /root/php-5.2.12/Zend/zend_objects.c:45 #7 0xb7a0bce2 in zend_objects_free_object_storage (object=0x8f41460) at /root/php-5.2.12/Zend/zend_objects.c:122 #8 0xb7a0f018 in zend_objects_store_del_ref_by_handle (handle=51) at /root/php-5.2.12/Zend/zend_objects_API.c:211 #9 0xb7a0f038 in zend_objects_store_del_ref (zobject=0x8f4094c) at /root/php-5.2.12/Zend/zend_objects_API.c:169 #10 0xb79e5460 in _zval_ptr_dtor (zval_ptr=0x91dcf74) at /root/php-5.2.12/Zend/zend_variables.h:35 #11 0xb79fbe2e in zend_hash_destroy (ht=0x91dcf10) at /root/php-5.2.12/Zend/zend_hash.c:526 #12 0xb7a0bcb3 in zend_object_std_dtor (object=0x91dceb8) at /root/php-5.2.12/Zend/zend_objects.c:45 #13 0xb7a0bce2 in zend_objects_free_object_storage (object=0x91dceb8) at /root/php-5.2.12/Zend/zend_objects.c:122 #14 0xb7a0f018 in zend_objects_store_del_ref_by_handle (handle=102) at /root/php-5.2.12/Zend/zend_objects_API.c:211 #15 0xb7a0f038 in zend_objects_store_del_ref (zobject=0x91dcea0) at /root/php-5.2.12/Zend/zend_objects_API.c:169 #16 0xb79e5460 in _zval_ptr_dtor (zval_ptr=0x91dd028) at /root/php-5.2.12/Zend/zend_variables.h:35 #17 0xb79fbe2e in zend_hash_destroy (ht=0x91dcb00) at /root/php-5.2.12/Zend/zend_hash.c:526 #18 0xb79f18d5 in _zval_dtor_func (zvalue=0x91dbff4) at /root/php-5.2.12/Zend/zend_variables.c:42 #19 0xb79e5460 in _zval_ptr_dtor (zval_ptr=0x9113624) at /root/php-5.2.12/Zend/zend_variables.h:35 #20 0xb79fbe2e in zend_hash_destroy (ht=0x91dc424) at /root/php-5.2.12/Zend/zend_hash.c:526 #21 0xb7a0bcb3 in zend_object_std_dtor (object=0x911424c) at /root/php-5.2.12/Zend/zend_objects.c:45 #22 0xb7a0bce2 in zend_objects_free_object_storage (object=0x911424c) at /root/php-5.2.12/Zend/zend_objects.c:122 #23 0xb7a0f018 in zend_objects_store_del_ref_by_handle (handle=97) at /root/php-5.2.12/Zend/zend_objects_API.c:211 #24 0xb7a0f038 in zend_objects_store_del_ref (zobject=0x9108a8c) at /root/php-5.2.12/Zend/zend_objects_API.c:169 #25 0xb79e5460 in _zval_ptr_dtor (zval_ptr=0x91dcae0) at /root/php-5.2.12/Zend/zend_variables.h:35 #26 0xb79fbe2e in zend_hash_destroy (ht=0x91dc3d4) at /root/php-5.2.12/Zend/zend_hash.c:526 #27 0xb79f18d5 in _zval_dtor_func (zvalue=0x908e678) at /root/php-5.2.12/Zend/zend_variables.c:42 #28 0xb79e5460 in _zval_ptr_dtor (zval_ptr=0x91de514) at /root/php-5.2.12/Zend/zend_variables.h:35 #29 0xb79fbe2e in zend_hash_destroy (ht=0x9189c04) at /root/php-5.2.12/Zend/zend_hash.c:526 #30 0xb79f18d5 in _zval_dtor_func (zvalue=0x9165f54) at /root/php-5.2.12/Zend/zend_variables.c:42 #31 0xb79e5460 in _zval_ptr_dtor (zval_ptr=0x9165f00) at /root/php-5.2.12/Zend/zend_variables.h:35 #32 0xb79fbe2e in zend_hash_destroy (ht=0x9189b20) at /root/php-5.2.12/Zend/zend_hash.c:526 #33 0xb7a0bcb3 in zend_object_std_dtor (object=0x918ad50) at /root/php-5.2.12/Zend/zend_objects.c:45 #34 0xb7a0bce2 in zend_
#50392 [Csd->Opn]: date_create_from_format enforces 6 digits for 'u' format character
ID: 50392
Updated by: der...@php.net
Reported By: grodny at oneclick dot sk
-Status: Closed
+Status: Open
Bug Type: Date/time related
Operating System: *
PHP Version: 5.3.1
-Assigned To:
+Assigned To: derick
New Comment:
Reopening as this bug was fixed incorrectly. It would treat "0010" as
"10" which is not what it is meant to do. The test case didn't
properly test the values either.
Previous Comments:
[2009-12-15 12:40:47] il...@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/.
Thank you for the report, and for helping us make PHP better.
[2009-12-15 12:34:17] s...@php.net
Automatic comment from SVN on behalf of iliaa
Revision: http://svn.php.net/viewvc/?view=revision&revision=292162
Log: Fixed bu #50392(date_create_from_format() enforces 6 digits for
'u' format character)
[2009-12-06 12:11:07] der...@php.net
Hi,
I guess it's not really required, I'll have a look (in a bit).
Derick
[2009-12-06 10:53:34] grodny at oneclick dot sk
Description:
As a result of fixing bug #45554, 'u' format character now requires
exactly 6 digits of microsecond part during parsing.
Patch fragment:
...
if ((f = timelib_get_nr((char **) &ptr, 6)) == TIMELIB_UNSET || ptr -
tptr != 6) {
...
Is check for exactly 6 digits really necessary, while other format
characters are more benevolent about number of digits being parsed?
Reproduce code:
---
date_default_timezone_set('Europe/Bratislava');
var_dump(date_create_from_format('Y-m-d H:i:s.u', '2009-03-01
18:00:00.0'));
Expected result:
object(DateTime)#1 (3) {
["date"]=>
string(19) "2009-03-01 18:00:00"
["timezone_type"]=>
int(3)
["timezone"]=>
string(17) "Europe/Bratislava"
}
Actual result:
--
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=50392&edit=1
#48795 [Com]: Building intl 64-bit fails on OS X
ID: 48795 Comment by: surfchen at gmail dot com Reported By: gwy...@php.net Status: Verified Bug Type: Compile Failure Operating System: Mac OS X 10.5.8, 10.6.2 PHP Version: 5.3SVN-2009-11-23 (SVN) New Comment: It is a linking problem, here is the simple workaround: edit Makefile and add -lstdc++ into EXTRA_LIBS. Previous Comments: [2010-01-10 11:54:55] harald dot lapp at gmail dot com same problem here: osx 10.5.8, php5.3-latest any ideas how to fix this issue? [2009-11-24 11:46:48] j...@php.net well, build system does handle C++ quite fine for me. OSX is "special".. [2009-11-24 01:23:26] gwy...@php.net No, upgrading the bundled libtool didn't fix it. The buildsystem isn't set up to deal with C++ files automatically. [2009-11-23 21:58:18] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-09-15 15:25:13] ram...@php.net I'm having the same exact problem using --enable-intl --with-icu-dir=/path/to/icu I installed ICU with macports, and so I'm using /opt/local as my path to ICU. 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/48795 -- Edit this bug report at http://bugs.php.net/?id=48795&edit=1
#50978 [Fbk->Opn]: OciFetchStatement
ID: 50978 User updated by: atila at nutroeste dot com dot br Reported By: atila at nutroeste dot com dot br -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: RHEL 5.2 64 BITS PHP Version: 5.2.12 New Comment: Sorry if I wasn't clear enough,and if you want I could give you accesses do my server by Terminal Server, to see the real sql. please be comfortable to contact me by e-mail, and anything to help you to resolve this please!!! ask me. Because my transactional system has been passed by a lot o changes and I had to create a lot of union's between what I had and the customizations I have now. Thanks a Lot for your attention Atila Santos Previous Comments: [2010-02-09 21:49:58] johan...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-02-09 20:13:21] atila at nutroeste dot com dot br Description: Dears, The function is OciFetchStatement. Since I have more than 2 times the same problem, and the task to resolve this was to hard. I have to report that every time I use a complex sql using operator union or union all, the return message is Notice: Undefined offset: 0 in /usr/local/apache/html/pedidos/teste_union.php on line 19 numero de linhas: As you can see the "Undefined offset: 0" means that there is no record to be retrived from a query, but if I run this same query using my database tool, a result could be seen. To resolve this I had to create temporary tables to insert the data into it's own structure using my sql union/union all query to became only one table and force the OciFetchStatement to retrive the results I wanted. My database is Oracle 10.2.04 running on Linux rhel 5.2 64bits. My php version is source 5.2.9 running in the same host. Thanks an advance Atila Santos mail: at...@nutroeste.com.br Country Brazil State Goias, city: Goiania +5562-30962539/2500 System Analist/Dba Oracle/Web Developer Reproduce code: --- Notice: Undefined offset: 0 in /usr/local/apache/html/pedidos/teste_union.php on line 19 Expected result: The result should bring me up values of rows. -- Edit this bug report at http://bugs.php.net/?id=50978&edit=1
#50992 [Opn->Bgs]: Database connect error
ID: 50992
Updated by: johan...@php.net
Reported By: gert-rainer dot bitterlich at ima-dresden dot de
-Status: Open
+Status: Bogus
Bug Type: MySQLi related
Operating System: Windows 7 64bit
PHP Version: 5.3.1
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
There's nothing we can do. Please use 127.0.0.1 or configure your
systme to use IPv4 127.0.0.1, not IPv6 [::1] for localhost.
Previous Comments:
[2010-02-10 12:19:08] gert-rainer dot bitterlich at ima-dresden dot de
Description:
The connect to the MySQL database (V5.1.x) faild with PHP 5.3.1 (also
with PHP 5.3.2RC1), when I use a real servername, like localhost or the
PC name. If I use the IP address it works fine.
With PHP 5.3.0 it was OK.
Reproduce code:
---
Host = '.$sHost.'';
$link = mysqli_init();
if (!$link) {
die('mysqli_init failed');
}
if (!mysqli_options($link, MYSQLI_INIT_COMMAND, 'SET AUTOCOMMIT = 0'))
{
die('Setting MYSQLI_INIT_COMMAND failed');
}
if (!mysqli_options($link, MYSQLI_OPT_CONNECT_TIMEOUT, 5)) {
die('Setting MYSQLI_OPT_CONNECT_TIMEOUT failed');
}
if (!mysqli_real_connect($link, $sHost, 'root', 'xitami',
'kb_globals')) {
die('Connect Error (' . mysqli_connect_errno() . ') '
. mysqli_connect_error());
}
echo 'Success... ' . mysqli_get_host_info($link) . "\n";
mysqli_close($link);
?>
Expected result:
Host = localhost
Success... localhost via TCP/IP
Actual result:
--
Host = localhost
Warning: mysqli_real_connect() [function.mysqli-real-connect]: [2002]
Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle na (trying
to connect via tcp://localhost:3306) in
D:\Inetpub\wwwroot\php\test\test_mysqli.php on line 20
Warning: mysqli_real_connect() [function.mysqli-real-connect]:
(HY000/2002): Ein Verbindungsversuch ist fehlgeschlagen, da die
Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat,
oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host
nicht reagiert hat. in D:\Inetpub\wwwroot\php\test\test_mysqli.php on
line 20
Connect Error (2002) Ein Verbindungsversuch ist fehlgeschlagen, da die
Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat,
oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host
nicht reagiert hat.
--
Edit this bug report at http://bugs.php.net/?id=50992&edit=1
#50966 [Opn]: Some resource leak (odbc_connect and odbc_close) using dbase or Microsoft Acces
ID: 50966
User updated by: gg dot cwlee at gmail dot com
Reported By: gg dot cwlee at gmail dot com
Status: Open
Bug Type: ODBC related
Operating System: Windows XP
PHP Version: 5.2.12
New Comment:
We identify the problem is within php_curl.dll. We are using PHP
v5.2.12, and find that all newer PHP versions have this problem. We have
to backtrack to the older PHP v5.2.0 before this problem disappears.
The problem source code:
PHP v5.2.12 ext\curl\interface.c Line 670
#ifdef PHP_CURL_NEED_OPENSSL_TSL
if (!CRYPTO_get_id_callback()) {
int i, c = CRYPTO_num_locks();
php_curl_openssl_tsl = malloc(c * sizeof(MUTEX_T));
PHP v5.2.0 ext\curl\interface.c Line 609
#ifdef PHP_CURL_NEED_OPENSSL_TSL
{
int i, c = CRYPTO_num_locks();
php_curl_openssl_tsl = malloc(c * sizeof(MUTEX_T));
The only difference is the if statement:
if (!CRYPTO_get_id_callback())
Previous Comments:
[2010-02-08 11:19:30] gg dot cwlee at gmail dot com
Description:
We have a resource leak problem when using Apache 2.2.11 and PHP 5.2.12
with odbc_connect() and odbc_close() functions on dbase or Microsoft
Access.
>From my observe, it will leak some (Nonpaged) kernel Memory and some
handles not free by the Apache(HTTPD.EXE).
And I also tested no this resource leak problem on Apache 2.2.11 and
PHP 5.2.0.
Thanks.
Chris
Reproduce code:
---
--
Edit this bug report at http://bugs.php.net/?id=50966&edit=1
#50992 [NEW]: Database connect error
From: gert-rainer dot bitterlich at ima-dresden dot de
Operating system: Windows 7 64bit
PHP version: 5.3.1
PHP Bug Type: MySQLi related
Bug description: Database connect error
Description:
The connect to the MySQL database (V5.1.x) faild with PHP 5.3.1 (also with
PHP 5.3.2RC1), when I use a real servername, like localhost or the PC name.
If I use the IP address it works fine.
With PHP 5.3.0 it was OK.
Reproduce code:
---
Host = '.$sHost.'';
$link = mysqli_init();
if (!$link) {
die('mysqli_init failed');
}
if (!mysqli_options($link, MYSQLI_INIT_COMMAND, 'SET AUTOCOMMIT = 0')) {
die('Setting MYSQLI_INIT_COMMAND failed');
}
if (!mysqli_options($link, MYSQLI_OPT_CONNECT_TIMEOUT, 5)) {
die('Setting MYSQLI_OPT_CONNECT_TIMEOUT failed');
}
if (!mysqli_real_connect($link, $sHost, 'root', 'xitami', 'kb_globals'))
{
die('Connect Error (' . mysqli_connect_errno() . ') '
. mysqli_connect_error());
}
echo 'Success... ' . mysqli_get_host_info($link) . "\n";
mysqli_close($link);
?>
Expected result:
Host = localhost
Success... localhost via TCP/IP
Actual result:
--
Host = localhost
Warning: mysqli_real_connect() [function.mysqli-real-connect]: [2002] Ein
Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle na (trying to
connect via tcp://localhost:3306) in
D:\Inetpub\wwwroot\php\test\test_mysqli.php on line 20
Warning: mysqli_real_connect() [function.mysqli-real-connect]:
(HY000/2002): Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle
nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die
hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht
reagiert hat. in D:\Inetpub\wwwroot\php\test\test_mysqli.php on line 20
Connect Error (2002) Ein Verbindungsversuch ist fehlgeschlagen, da die
Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat,
oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host
nicht reagiert hat.
--
Edit bug report at http://bugs.php.net/?id=50992&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=50992&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=50992&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=50992&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=50992&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=50992&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=50992&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=50992&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=50992&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=50992&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=50992&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=50992&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=50992&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=50992&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=50992&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50992&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=50992&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=50992&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=50992&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=50992&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=50992&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=50992&r=mysqlcfg
#50953 [Bgs]: fsockopen will not work on 'localhost'
ID: 50953
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
Status: Bogus
Bug Type: Sockets related
Operating System: Windows XP
PHP Version: 5.2.12
New Comment:
This has got nothing to do with IPV6 addresses as my hosts file does
not contain anf IPV6 addresses. All it has is as follows:
127.0.0.1 localhost
Every other piece of software on my PC uses 'loalhost' without a
problem, so should fsockopen in PHP. Curl can manage it, so why not
fsockopen.
I have the same setup on another PC which runs Windows XP with IPV6
support and PHP 5.3.0, and it does not have a problem with 'localhost',
so this is a genuine bug in 5.2
Do not keep telling me that you have already addressed this issue in
other posts because you have not. You nhave suggested removing any IPV6
entries from the hosts file, which I have done, but this does not fix
the problem.
If gethostbyname() can work with 'localhost' then why can't
fsockopen()?
Previous Comments:
[2010-02-10 11:06:08] paj...@php.net
It works just fine here using localhost and ipv4.
You are clearly experiencing the IPv6 problem described in a good dozen
bugs here (with solutions).
I'm sorry if it is not acceptable but we can't do anything about that,
see the other reports for a complete and detailed explanation.
[2010-02-10 10:57:11] tony at marston-home dot demon dot co dot uk
THIS IS NOT BOGUS, IT IS A GENUINE BUG!!!
If print_r(gethostbynamel('localhost')); produces the following:
Array
(
[0] => 127.0.0.1
)
then why can't fsockopen connect to 'localhost'? It is a valid name
which is recognised by every other piece of software on my computer, so
there is no good reason why fsockopen should have a problem with it.
I have another PC which runs 5.3.0 where fsockopen does not have a
problem with 'localhost', therefore there is a bug in 5.2
[2010-02-10 10:18:16] paj...@php.net
Already explained why it can't and won't be fixed in 5.2, neither in
5.3. Use the IP then instead of the hostname. Bogus (duplicated, not
really a bug per se but a feature,etc.)
[2010-02-10 08:17:49] carsten_sttgt at gmx dot de
> Did you install IPv6 support for XP?
Yes.
> Comment out the IPv6 entries for localhost
Of course not! (PHP is not the center of the universe and i need a
working IPv6)
> (see the other bogus reports for detailed explanations
Don't you think it's better to fix the bug in the streams code?
(Already explained in an other bug report about mysqlnd)
BTW (regarding the above quirk):
- for XP it's also a good idea to verify that there is a entry for IPv4
in the HOSTS file (or just deinstall IPv6)
- and that's not working for e.g. Windows 7.
Regards,
Carsten
[2010-02-08 11:39:51] ahar...@php.net
Reopening per discussion in bug #50965.
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/50953
--
Edit this bug report at http://bugs.php.net/?id=50953&edit=1
#50953 [Bgs]: fsockopen will not work on 'localhost'
ID: 50953
Updated by: paj...@php.net
Reported By: tony at marston-home dot demon dot co dot uk
Status: Bogus
Bug Type: Sockets related
Operating System: Windows XP
PHP Version: 5.2.12
New Comment:
It works just fine here using localhost and ipv4.
You are clearly experiencing the IPv6 problem described in a good dozen
bugs here (with solutions).
I'm sorry if it is not acceptable but we can't do anything about that,
see the other reports for a complete and detailed explanation.
Previous Comments:
[2010-02-10 10:57:11] tony at marston-home dot demon dot co dot uk
THIS IS NOT BOGUS, IT IS A GENUINE BUG!!!
If print_r(gethostbynamel('localhost')); produces the following:
Array
(
[0] => 127.0.0.1
)
then why can't fsockopen connect to 'localhost'? It is a valid name
which is recognised by every other piece of software on my computer, so
there is no good reason why fsockopen should have a problem with it.
I have another PC which runs 5.3.0 where fsockopen does not have a
problem with 'localhost', therefore there is a bug in 5.2
[2010-02-10 10:18:16] paj...@php.net
Already explained why it can't and won't be fixed in 5.2, neither in
5.3. Use the IP then instead of the hostname. Bogus (duplicated, not
really a bug per se but a feature,etc.)
[2010-02-10 08:17:49] carsten_sttgt at gmx dot de
> Did you install IPv6 support for XP?
Yes.
> Comment out the IPv6 entries for localhost
Of course not! (PHP is not the center of the universe and i need a
working IPv6)
> (see the other bogus reports for detailed explanations
Don't you think it's better to fix the bug in the streams code?
(Already explained in an other bug report about mysqlnd)
BTW (regarding the above quirk):
- for XP it's also a good idea to verify that there is a entry for IPv4
in the HOSTS file (or just deinstall IPv6)
- and that's not working for e.g. Windows 7.
Regards,
Carsten
[2010-02-08 11:39:51] ahar...@php.net
Reopening per discussion in bug #50965.
[2010-02-07 17:27:30] tony at marston-home dot demon dot co dot uk
I have tried that, but it still doesn't work.
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/50953
--
Edit this bug report at http://bugs.php.net/?id=50953&edit=1
#50953 [Bgs]: fsockopen will not work on 'localhost'
ID: 50953
User updated by: tony at marston-home dot demon dot co dot uk
Reported By: tony at marston-home dot demon dot co dot uk
Status: Bogus
Bug Type: Sockets related
Operating System: Windows XP
PHP Version: 5.2.12
New Comment:
THIS IS NOT BOGUS, IT IS A GENUINE BUG!!!
If print_r(gethostbynamel('localhost')); produces the following:
Array
(
[0] => 127.0.0.1
)
then why can't fsockopen connect to 'localhost'? It is a valid name
which is recognised by every other piece of software on my computer, so
there is no good reason why fsockopen should have a problem with it.
I have another PC which runs 5.3.0 where fsockopen does not have a
problem with 'localhost', therefore there is a bug in 5.2
Previous Comments:
[2010-02-10 10:18:16] paj...@php.net
Already explained why it can't and won't be fixed in 5.2, neither in
5.3. Use the IP then instead of the hostname. Bogus (duplicated, not
really a bug per se but a feature,etc.)
[2010-02-10 08:17:49] carsten_sttgt at gmx dot de
> Did you install IPv6 support for XP?
Yes.
> Comment out the IPv6 entries for localhost
Of course not! (PHP is not the center of the universe and i need a
working IPv6)
> (see the other bogus reports for detailed explanations
Don't you think it's better to fix the bug in the streams code?
(Already explained in an other bug report about mysqlnd)
BTW (regarding the above quirk):
- for XP it's also a good idea to verify that there is a entry for IPv4
in the HOSTS file (or just deinstall IPv6)
- and that's not working for e.g. Windows 7.
Regards,
Carsten
[2010-02-08 11:39:51] ahar...@php.net
Reopening per discussion in bug #50965.
[2010-02-07 17:27:30] tony at marston-home dot demon dot co dot uk
I have tried that, but it still doesn't work.
[2010-02-07 17:15:21] paj...@php.net
Comment out the IPv6 entries for localhost (see the other bogus reports
for detailed explanations).
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/50953
--
Edit this bug report at http://bugs.php.net/?id=50953&edit=1
#50990 [Opn]: gmp extension doesn't compile with gmp 5.0.1
ID: 50990 Updated by: paj...@php.net Reported By: php-bugs-2010 at ryandesign dot com Status: Open Bug Type: Compile Failure Operating System: Mac OS X 10.6.2 PHP Version: 5.3.2RC1 New Comment: ZF depends on the gmp php extension, which can be built against MPIR instead of gmplib. See http://www.mpir.org/. It is a rock solid gmp compatible library with much better support for modern architecture and optimizations, without the (l)gpl v3 license madness. Previous Comments: [2010-02-10 10:23:47] juri dot saltbacka at gmail dot com It is important because ZendFramework depends on GMP. At least on Mac OS X [2010-02-10 09:31:31] paj...@php.net I would suggest to go with MPIR instead. GMP 5.x breaks ABI badly and is also not compatible with PHP, from a license point of view. [2010-02-10 08:59:47] php-bugs-2010 at ryandesign dot com Description: The gmp extension doesn't compile with gmp 5.0.1. This used to work with gmp 4.3.2. Reproduce code: --- 1. cd /path/to/php-5.3.2RC1 2. ./configure --disable-all --with-gmp=/opt/local 3. make Expected result: successful compile Actual result: -- /bin/sh /path/to/php-5.3.2RC1/libtool --silent --preserve-dup-deps -- mode=compile gcc -Iext/gmp/ -I/path/to/php-5.3.2RC1/ext/gmp/ - DPHP_ATOM_INC -I/path/to/php-5.3.2RC1/include -I/path/to/php- 5.3.2RC1/main -I/path/to/php-5.3.2RC1 -I/path/to/php- 5.3.2RC1/ext/date/lib -I/path/to/php-5.3.2RC1/ext/ereg/regex - I/opt/local/include -I/path/to/php-5.3.2RC1/TSRM -I/path/to/php- 5.3.2RC1/Zend -no-cpp-precomp -g -O2 -fvisibility=hidden -c /path/to/php-5.3.2RC1/ext/gmp/gmp.c -o ext/gmp/gmp.lo /path/to/php-5.3.2RC1/ext/gmp/gmp.c: In function zif_gmp_random: /path/to/php-5.3.2RC1/ext/gmp/gmp.c:1377: error: __GMP_BITS_PER_MP_LIMB undeclared (first use in this function) /path/to/php-5.3.2RC1/ext/gmp/gmp.c:1377: error: (Each undeclared identifier is reported only once /path/to/php-5.3.2RC1/ext/gmp/gmp.c:1377: error: for each function it appears in.) -- Edit this bug report at http://bugs.php.net/?id=50990&edit=1
#50990 [Com]: gmp extension doesn't compile with gmp 5.0.1
ID: 50990 Comment by: juri dot saltbacka at gmail dot com Reported By: php-bugs-2010 at ryandesign dot com Status: Open Bug Type: Compile Failure Operating System: Mac OS X 10.6.2 PHP Version: 5.3.2RC1 New Comment: It is important because ZendFramework depends on GMP. At least on Mac OS X Previous Comments: [2010-02-10 09:31:31] paj...@php.net I would suggest to go with MPIR instead. GMP 5.x breaks ABI badly and is also not compatible with PHP, from a license point of view. [2010-02-10 08:59:47] php-bugs-2010 at ryandesign dot com Description: The gmp extension doesn't compile with gmp 5.0.1. This used to work with gmp 4.3.2. Reproduce code: --- 1. cd /path/to/php-5.3.2RC1 2. ./configure --disable-all --with-gmp=/opt/local 3. make Expected result: successful compile Actual result: -- /bin/sh /path/to/php-5.3.2RC1/libtool --silent --preserve-dup-deps -- mode=compile gcc -Iext/gmp/ -I/path/to/php-5.3.2RC1/ext/gmp/ - DPHP_ATOM_INC -I/path/to/php-5.3.2RC1/include -I/path/to/php- 5.3.2RC1/main -I/path/to/php-5.3.2RC1 -I/path/to/php- 5.3.2RC1/ext/date/lib -I/path/to/php-5.3.2RC1/ext/ereg/regex - I/opt/local/include -I/path/to/php-5.3.2RC1/TSRM -I/path/to/php- 5.3.2RC1/Zend -no-cpp-precomp -g -O2 -fvisibility=hidden -c /path/to/php-5.3.2RC1/ext/gmp/gmp.c -o ext/gmp/gmp.lo /path/to/php-5.3.2RC1/ext/gmp/gmp.c: In function zif_gmp_random: /path/to/php-5.3.2RC1/ext/gmp/gmp.c:1377: error: __GMP_BITS_PER_MP_LIMB undeclared (first use in this function) /path/to/php-5.3.2RC1/ext/gmp/gmp.c:1377: error: (Each undeclared identifier is reported only once /path/to/php-5.3.2RC1/ext/gmp/gmp.c:1377: error: for each function it appears in.) -- Edit this bug report at http://bugs.php.net/?id=50990&edit=1
#50953 [Opn->Bgs]: fsockopen will not work on 'localhost'
ID: 50953 Updated by: paj...@php.net Reported By: tony at marston-home dot demon dot co dot uk -Status: Open +Status: Bogus Bug Type: Sockets related Operating System: Windows XP PHP Version: 5.2.12 New Comment: Already explained why it can't and won't be fixed in 5.2, neither in 5.3. Use the IP then instead of the hostname. Bogus (duplicated, not really a bug per se but a feature,etc.) Previous Comments: [2010-02-10 08:17:49] carsten_sttgt at gmx dot de > Did you install IPv6 support for XP? Yes. > Comment out the IPv6 entries for localhost Of course not! (PHP is not the center of the universe and i need a working IPv6) > (see the other bogus reports for detailed explanations Don't you think it's better to fix the bug in the streams code? (Already explained in an other bug report about mysqlnd) BTW (regarding the above quirk): - for XP it's also a good idea to verify that there is a entry for IPv4 in the HOSTS file (or just deinstall IPv6) - and that's not working for e.g. Windows 7. Regards, Carsten [2010-02-08 11:39:51] ahar...@php.net Reopening per discussion in bug #50965. [2010-02-07 17:27:30] tony at marston-home dot demon dot co dot uk I have tried that, but it still doesn't work. [2010-02-07 17:15:21] paj...@php.net Comment out the IPv6 entries for localhost (see the other bogus reports for detailed explanations). [2010-02-07 16:28:31] tony at marston-home dot demon dot co dot uk Yes, but why should this make a difference? I have another Windows XP PC running PHP 5.3.0 and that works OK. I have just upgraded this PC from PHP 4.4.9 to 5.2.12, and it worked OK in PHP 4. Is it something to do with the fact that IPV6 support is enabled in PHP 5.2.12 but disabled in PHP 5.3.0? Is this a PHP problem and not an OS problem? FYI my hosts file contains the following: 127.0.0.1 localhost ::1 localhost 127.0.0.1 laptop 192.168.1.64desktop 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/50953 -- Edit this bug report at http://bugs.php.net/?id=50953&edit=1
#50986 [Opn->Bgs]: using swf object the flv extension videos not playing
ID: 50986
Updated by: paj...@php.net
Reported By: bhupinder1045 at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: *PDF functions
Operating System: Vista
PHP Version: 5.3.1
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2010-02-10 07:21:47] bhupinder1045 at gmail dot com
Description:
var file = ""; //
for uploaded file name.
//var utube = ""; // for
utube link..
alert(file)
var s1 = new
swf("../flashplayer/mediaplayer.swf","mediaplayer","500","320","8");
//var s1 = new
SWFObject("../flashplayer/mediaplayer.swf","mediaplayer","500","320","8");
s1.addParam("allowfullscreen","true");
s1.addVariable("width","500");
s1.addVariable("height","320");
s1.addVariable("autostart","false"); // 'true' terurn
auto run
s1.addVariable("repeat","true"); // 'true' terurn auto
run
s1.addVariable("autoPlay", "no");
// s1.addVariable("soundPath", "");
//s1.write("flashplayer");
alert(file)
// if(utube == '')
s1.addVariable("file",file);
// else
// s1.addVariable("file",utube);
s1.write("container");
Reproduce code:
---
---
>From manual page: function.swf-actionplay#Description
---
--
Edit this bug report at http://bugs.php.net/?id=50986&edit=1
#50990 [Opn]: gmp extension doesn't compile with gmp 5.0.1
ID: 50990 Updated by: paj...@php.net Reported By: php-bugs-2010 at ryandesign dot com Status: Open Bug Type: Compile Failure Operating System: Mac OS X 10.6.2 PHP Version: 5.3.2RC1 New Comment: I would suggest to go with MPIR instead. GMP 5.x breaks ABI badly and is also not compatible with PHP, from a license point of view. Previous Comments: [2010-02-10 08:59:47] php-bugs-2010 at ryandesign dot com Description: The gmp extension doesn't compile with gmp 5.0.1. This used to work with gmp 4.3.2. Reproduce code: --- 1. cd /path/to/php-5.3.2RC1 2. ./configure --disable-all --with-gmp=/opt/local 3. make Expected result: successful compile Actual result: -- /bin/sh /path/to/php-5.3.2RC1/libtool --silent --preserve-dup-deps -- mode=compile gcc -Iext/gmp/ -I/path/to/php-5.3.2RC1/ext/gmp/ - DPHP_ATOM_INC -I/path/to/php-5.3.2RC1/include -I/path/to/php- 5.3.2RC1/main -I/path/to/php-5.3.2RC1 -I/path/to/php- 5.3.2RC1/ext/date/lib -I/path/to/php-5.3.2RC1/ext/ereg/regex - I/opt/local/include -I/path/to/php-5.3.2RC1/TSRM -I/path/to/php- 5.3.2RC1/Zend -no-cpp-precomp -g -O2 -fvisibility=hidden -c /path/to/php-5.3.2RC1/ext/gmp/gmp.c -o ext/gmp/gmp.lo /path/to/php-5.3.2RC1/ext/gmp/gmp.c: In function zif_gmp_random: /path/to/php-5.3.2RC1/ext/gmp/gmp.c:1377: error: __GMP_BITS_PER_MP_LIMB undeclared (first use in this function) /path/to/php-5.3.2RC1/ext/gmp/gmp.c:1377: error: (Each undeclared identifier is reported only once /path/to/php-5.3.2RC1/ext/gmp/gmp.c:1377: error: for each function it appears in.) -- Edit this bug report at http://bugs.php.net/?id=50990&edit=1
#50990 [NEW]: gmp extension doesn't compile with gmp 5.0.1
From: php-bugs-2010 at ryandesign dot com Operating system: Mac OS X 10.6.2 PHP version: 5.3.2RC1 PHP Bug Type: Compile Failure Bug description: gmp extension doesn't compile with gmp 5.0.1 Description: The gmp extension doesn't compile with gmp 5.0.1. This used to work with gmp 4.3.2. Reproduce code: --- 1. cd /path/to/php-5.3.2RC1 2. ./configure --disable-all --with-gmp=/opt/local 3. make Expected result: successful compile Actual result: -- /bin/sh /path/to/php-5.3.2RC1/libtool --silent --preserve-dup-deps -- mode=compile gcc -Iext/gmp/ -I/path/to/php-5.3.2RC1/ext/gmp/ - DPHP_ATOM_INC -I/path/to/php-5.3.2RC1/include -I/path/to/php- 5.3.2RC1/main -I/path/to/php-5.3.2RC1 -I/path/to/php- 5.3.2RC1/ext/date/lib -I/path/to/php-5.3.2RC1/ext/ereg/regex - I/opt/local/include -I/path/to/php-5.3.2RC1/TSRM -I/path/to/php- 5.3.2RC1/Zend -no-cpp-precomp -g -O2 -fvisibility=hidden -c /path/to/php-5.3.2RC1/ext/gmp/gmp.c -o ext/gmp/gmp.lo /path/to/php-5.3.2RC1/ext/gmp/gmp.c: In function zif_gmp_random: /path/to/php-5.3.2RC1/ext/gmp/gmp.c:1377: error: __GMP_BITS_PER_MP_LIMB undeclared (first use in this function) /path/to/php-5.3.2RC1/ext/gmp/gmp.c:1377: error: (Each undeclared identifier is reported only once /path/to/php-5.3.2RC1/ext/gmp/gmp.c:1377: error: for each function it appears in.) -- Edit bug report at http://bugs.php.net/?id=50990&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50990&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50990&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50990&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50990&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50990&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50990&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50990&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50990&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50990&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50990&r=support Expected behavior: http://bugs.php.net/fix.php?id=50990&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50990&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50990&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50990&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50990&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50990&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50990&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50990&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50990&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50990&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50990&r=mysqlcfg
#50953 [Com]: fsockopen will not work on 'localhost'
ID: 50953 Comment by: carsten_sttgt at gmx dot de Reported By: tony at marston-home dot demon dot co dot uk Status: Open Bug Type: Sockets related Operating System: Windows XP PHP Version: 5.2.12 New Comment: > Did you install IPv6 support for XP? Yes. > Comment out the IPv6 entries for localhost Of course not! (PHP is not the center of the universe and i need a working IPv6) > (see the other bogus reports for detailed explanations Don't you think it's better to fix the bug in the streams code? (Already explained in an other bug report about mysqlnd) BTW (regarding the above quirk): - for XP it's also a good idea to verify that there is a entry for IPv4 in the HOSTS file (or just deinstall IPv6) - and that's not working for e.g. Windows 7. Regards, Carsten Previous Comments: [2010-02-08 11:39:51] ahar...@php.net Reopening per discussion in bug #50965. [2010-02-07 17:27:30] tony at marston-home dot demon dot co dot uk I have tried that, but it still doesn't work. [2010-02-07 17:15:21] paj...@php.net Comment out the IPv6 entries for localhost (see the other bogus reports for detailed explanations). [2010-02-07 16:28:31] tony at marston-home dot demon dot co dot uk Yes, but why should this make a difference? I have another Windows XP PC running PHP 5.3.0 and that works OK. I have just upgraded this PC from PHP 4.4.9 to 5.2.12, and it worked OK in PHP 4. Is it something to do with the fact that IPV6 support is enabled in PHP 5.2.12 but disabled in PHP 5.3.0? Is this a PHP problem and not an OS problem? FYI my hosts file contains the following: 127.0.0.1 localhost ::1 localhost 127.0.0.1 laptop 192.168.1.64desktop [2010-02-07 16:07:01] paj...@php.net Did you install IPv6 support for XP? 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/50953 -- Edit this bug report at http://bugs.php.net/?id=50953&edit=1
