#35791 [Opn->Fbk]: file_exists() does not see removed symlinks
ID: 35791
Updated by: [EMAIL PROTECTED]
Reported By: jgmtfia at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: Linux
PHP Version: 5.1.1
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Previous Comments:
[2005-12-24 01:07:44] judas dot iscariote at gmail dot com
File 'C' exists:
lrwxrwxrwx 1 1 2005-12-23 21:10 C -> A
Deleted 'C'
ls: C: No such file or directory
(PASS) PHP sees the file as deleted.
php -v
PHP 5.1.2RC2-dev (cli) (built: Dec 23 2005 17:37:05)
SUSE Linux 10 x86_64
[2005-12-24 01:05:54] jgmtfia at gmail dot com
Interesting. How should I proceed?
[2005-12-24 00:23:26] [EMAIL PROTECTED]
That's what I get:
File 'C' exists:
rwxrwxrwx 1 1 2005-12-24 02:22 C -> A
Deleted 'C'
ls: C: No such file or directory
(PASS) PHP sees the file as deleted.
[2005-12-23 22:16:07] jgmtfia at gmail dot com
Description:
I have narrowed down a PHP problem. I can demonstrate it with
file_exists().
I have 2 files, A and B, and one symlink C that points to A.
-rw-r--r-- Dec 23 14:13 A
-rw-r--r-- Dec 23 14:13 B
lrwxr-xr-x Dec 23 14:13 C -> A
When I delete link C from PHP, and then clearstatcache(), file_exists()
returns true for link C. **It continues to do so until A is removed
from disk**. Using the Apache2 module, I do multiple page reloads and
only after some time has passed does PHP notice that link C has been
removed.
Not a big problem in general, however, if I do the following:
unlink("C");
symlink("B", "C");
file_get_contents("C");
**PHP still reads the contents of A**. Using the CLI version I have to
run the script again before the contents of B are read. In Apache I
need to reload multiple times.
I can reproduce this on linux kernels 2.6.10 and 2.6.14. On ext2 and
ext3 filesystems. The code below executes correctly (passes) with PHP
4.3.10 and fails on 5.1.0b3, 5.1.0 and 5.1.1.
Reproduce code:
---
&1";
clearstatcache();
if(!file_exists($FILE))
echo "$FILE link does not exist, cannot run test.\n";
echo "File '$FILE' exists:\n\t\t".`$LS`."\n";
if(!unlink($FILE)){
echo "Unable to delete '$FILE'\n\t\t".`$LS`."\n";
exit;
}
clearstatcache();
echo "Deleted '$FILE'\n\t\t".`$LS`."\n";
if(!file_exists($FILE)){
echo "(PASS) PHP sees the file as deleted.\n";
exit;
}
echo "(FAIL) File '$FILE' deleted as seen by OS. ";
echo "file_exists() still thinks it exists:\n\t\t".`$LS`."\n";
echo "Deleting 'A'\n";
unlink('A');
clearstatcache();
if(file_exists($FILE)){
echo "(FAIL) PHP still sees '$FILE' as
existing:\n\t\t".`$LS`."\n";
exit;
}
echo "(FAIL) PHP sees file as deleted only after link target
deleted.\n";
?>
Expected result:
~/x$ ./php-4.3.10-15 ./test.php
File 'C' exists:
lrwxr-xr-x 1 1 Dec 23 14:00 C -> A
Deleted 'C'
ls: C: No such file or directory
(PASS) PHP sees the file as deleted.
Actual result:
--
~/x$ ./php-5.1.1 ./test.php
File 'C' exists:
lrwxr-xr-x 1 1 Dec 23 14:02 C -> A
Deleted 'C'
ls: C: No such file or directory
(FAIL) File 'C' deleted as seen by OS. file_exists() still thinks it
exists:
ls: C: No such file or directory
Deleting 'A'
(FAIL) PHP sees file as deleted only after link target deleted.
--
Edit this bug report at http://bugs.php.net/?id=35791&edit=1
#29955 [Fbk->Csd]: mb_strtoupper() / lower() broken with some locale
ID: 29955 Updated by: [EMAIL PROTECTED] Reported By: jan at horde dot org -Status: Feedback +Status: Closed Bug Type: mbstring related Operating System: Linux PHP Version: 5CVS, 4CVS (2004-09-02) Assigned To: hirokawa Previous Comments: [2005-12-23 14:56:27] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php6.0-latest.tar.gz For Windows: http://snaps.php.net/win32/php6.0-win32-latest.zip Turkish language support is added in CVS HEAD. When mbstring.language = Turkish, Turkish case filding will be performed in ISO-8859-9. (upper:0x69 -> 0xdd, lower:0x49->0xfd) Otherwise, normal case folding is performed. (upper:0x69 -> 0x49, lower:0x49->0x69) [2005-12-23 14:28:29] [EMAIL PROTECTED] "man iso-8859-9" will tell you. "i" maps to "0xdd" and "0xfd" maps to "I" See also: http://www.eki.ee/letter/chardata.cgi?lang=tr+Turkish&script=latin [2005-12-23 14:24:06] jan at horde dot org See http://www.gymel.com/charsets/ISO8859-9.html#U0069 and http://www.gymel.com/charsets/ISO8859-9.html#U0049 under "Bemerkungen:" (remarks). [2005-12-23 14:10:05] [EMAIL PROTECTED] I don't know which is the standard way (0x49 or 0xdd). In ISO-8859-9 (Turkish), upper case of 'i' (0x69) always should be translated to 'I' with dot (0xdd) ? If yes, please let me know some URLs which describe the mapping. [2005-12-21 23:22:57] [EMAIL PROTECTED] Rui, yet another for you. Moriyoshi seems to have vanished.. 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/29955 -- Edit this bug report at http://bugs.php.net/?id=29955&edit=1
#35775 [Asn->Bgs]: typo in NEWS file (CVS)
ID: 35775 Updated by: [EMAIL PROTECTED] Reported By: judas dot iscariote at gmail dot com -Status: Assigned +Status: Bogus Bug Type: *General Issues Operating System: Irrelevant PHP Version: 5.1.2RC1 Assigned To: ilia New Comment: There are more important things than this to fix.. Previous Comments: [2005-12-22 17:20:20] judas dot iscariote at gmail dot com Description: News file has a typo. Reproduce code: --- cvs co Expected result: 22 Dec 2005, PHP 5.1.2RC1 Actual result: -- 22 Dec 2006, PHP 5.1.2RC1 -- Edit this bug report at http://bugs.php.net/?id=35775&edit=1
#35781 [Opn->Asn]: stream_filter_append will cause segfault
ID: 35781 Updated by: [EMAIL PROTECTED] Reported By: sqchen at citiz dot net -Status: Open +Status: Assigned -Bug Type: Unknown/Other Function +Bug Type: Filesystem function related Operating System: redhat 7.3 -PHP Version: 5.1.1 +PHP Version: 5.1.2RC1 -Assigned To: +Assigned To: wez New Comment: Assigned to the streams author. Previous Comments: [2005-12-23 04:36:32] judas dot iscariote at gmail dot com (gdb) bt #0 0x2b5433f0 in memcpy () from /lib64/tls/libc.so.6 #1 0x0003 in ?? () #2 0x0071ca50 in php_register_internal_extensions () #3 0x0062acfa in strfilter_rot13_filter (stream=0xaa6fc0, thisfilter=0xaa7360, buckets_in=0x7fc21d60, buckets_out=0x7fc21d50, bytes_consumed=0x0, flags=0) at /local/local/bodegon/php-debug/ext/standard/filters.c:46 #4 0x0065e69d in php_stream_fill_read_buffer (stream=0xaa6fc0, size=8192) at /local/local/bodegon/php-debug/main/streams/streams.c:458 #5 0x0065ecfa in _php_stream_read (stream=0xaa6fc0, buf=0x7fc21e70 "", size=8192) at /local/local/bodegon/php-debug/main/streams/streams.c:584 #6 0x006602d2 in _php_stream_passthru (stream=0xaa6fc0, __php_stream_call_depth=0, __zend_filename=0x762ae0 "/local/local/bodegon/php-debug/ext/standard/file.c", __zend_lineno=1487, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /local/local/bodegon/php-debug/main/streams/streams.c:1183 #7 0x005ca9ff in zif_fpassthru (ht=1, return_value=0xaa4f90, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /local/local/bodegon/php-debug/ext/standard/file.c:1487 #8 0x006c2ef2 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fc241a0) at zend_vm_execute.h:192 #9 0x006c8e57 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0x7fc241a0) at zend_vm_execute.h:1587 #10 0x006c2a66 in execute (op_array=0xaa5e70) at zend_vm_execute.h:92 #11 0x0069ce03 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /local/local/bodegon/php-debug/Zend/zend.c:1101 #12 0x00649cd3 in php_execute_script (primary_file=0x7fc26830) at /local/local/bodegon/php-debug/main/main.c:1720 #13 0x0071bd3d in main (argc=2, argv=0x7fc26a28) at /local/local/bodegon/php-debug/sapi/cli/php_cli.c:1077 [2005-12-23 04:17:47] judas dot iscariote at gmail dot com ==308== Process terminating with default action of signal 11 (SIGSEGV) ==308== Bad permissions for mapped region at address 0x1669DFFF ==308==at 0x11B1CEC7: memcpy (in /usr/lib64/valgrind/vgpreload_memcheck.so) ==308==by 0x508DDA: php_stream_bucket_make_writeable (string3.h:52) ==308==by 0x4E48C4: ??? (filters.c:46) ==308==by 0x506424: ??? (streams.c:458) ==308==by 0x50689A: _php_stream_read (streams.c:584) ==308==by 0x506E9F: _php_stream_passthru (streams.c:1183) ==308==by 0x49F60E: zif_fpassthru (file.c:1487) ==308==by 0x54F5E4: ??? (zend_vm_execute.h:192) ==308==by 0x54ECD2: execute (zend_vm_execute.h:92) ==308==by 0x526ADA: zend_eval_string (zend_execute_API.c:1085) ==308==by 0x526C27: zend_eval_string_ex (zend_execute_API.c:1119) ==308==by 0x5C2FBD: main (php_cli.c:1116) php -v PHP 5.1.2RC1 (cli) (built: Dec 22 2005 19:34:24) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0, Copyright (c) 1998-2005 Zend Technologies [2005-12-23 03:00:41] sqchen at citiz dot net Description: stream_filter_append($fp, "string.rot13", -49) will cause Segmentation fault Reproduce code: --- Actual result: -- Segmentation fault -- Edit this bug report at http://bugs.php.net/?id=35781&edit=1
#35785 [Opn->Fbk]: SimpleXML memory read error
ID: 35785 Updated by: [EMAIL PROTECTED] Reported By: TheFFF at gmail dot com -Status: Open +Status: Feedback Bug Type: SimpleXML related Operating System: Windows Xp Pro PHP Version: 5.1.1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2005-12-23 12:14:24] TheFFF at gmail dot com Description: trying to set some values Reproduce code: --- "); $count = count($x -> posts) + 1; $x -> bla -> posts[$count] -> name = $_POST["name"]; echo $x -> asXML(); ?> also getting the error with simplexml_load_file(); Expected result: bla dosen't exist so some kinda error Actual result: -- The instuction at "0x006d693c" referenced memory "0x00c". The memory could not be "read" -- Edit this bug report at http://bugs.php.net/?id=35785&edit=1
#35785 [Ver->Opn]: SimpleXML memory read error
ID: 35785 Updated by: [EMAIL PROTECTED] Reported By: TheFFF at gmail dot com -Status: Verified +Status: Open Bug Type: SimpleXML related Operating System: Windows Xp Pro PHP Version: 5.1.1 Previous Comments: [2005-12-23 12:14:24] TheFFF at gmail dot com Description: trying to set some values Reproduce code: --- "); $count = count($x -> posts) + 1; $x -> bla -> posts[$count] -> name = $_POST["name"]; echo $x -> asXML(); ?> also getting the error with simplexml_load_file(); Expected result: bla dosen't exist so some kinda error Actual result: -- The instuction at "0x006d693c" referenced memory "0x00c". The memory could not be "read" -- Edit this bug report at http://bugs.php.net/?id=35785&edit=1
#35780 [Opn->Asn]: $INSTALL_ROOT confuses PEAR installer configuration
ID: 35780 Updated by: [EMAIL PROTECTED] Reported By: andre at tomt dot net -Status: Open +Status: Assigned Bug Type: *Configuration Issues Operating System: Linux (Debian sid/amd64) -PHP Version: 5.1.1 +PHP Version: 5CVS-2005-12-23 (snap) -Assigned To: +Assigned To: cellog New Comment: Greg, can you fix this please? :) Previous Comments: [2005-12-22 23:31:48] andre at tomt dot net no change [2005-12-22 23:18:00] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-12-22 22:59:12] andre at tomt dot net Description: When installing the PEAR installer and the base components as shipped in the php tarball, using INSTALL_ROOT will confuse the pear installation. INSTALL_ROOT gets prepended on the paths in the configuration (pear.conf) and in the pear binary. This breaks packaging. Reproduce code: --- ./configure make make install-pear INSTALL_ROOT=/somewhere/else/php-pear Now observe the "pear" shell script, and the pear.conf. I can't recall this used to be a problem before PHP 5.1. Expected result: Not having INSTALL_ROOT prepended in pear config and in pear command. Actual result: -- INSTALL_ROOT prepended in pear config and in pear command. -- Edit this bug report at http://bugs.php.net/?id=35780&edit=1
#35780 [Opn->Fbk]: $INSTALL_ROOT confuses PEAR installer configuration
ID: 35780 Updated by: [EMAIL PROTECTED] Reported By: andre at tomt dot net -Status: Open +Status: Feedback Bug Type: *Configuration Issues Operating System: Linux (Debian sid/amd64) PHP Version: 5.1.1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2005-12-22 22:59:12] andre at tomt dot net Description: When installing the PEAR installer and the base components as shipped in the php tarball, using INSTALL_ROOT will confuse the pear installation. INSTALL_ROOT gets prepended on the paths in the configuration (pear.conf) and in the pear binary. This breaks packaging. Reproduce code: --- ./configure make make install-pear INSTALL_ROOT=/somewhere/else/php-pear Now observe the "pear" shell script, and the pear.conf. I can't recall this used to be a problem before PHP 5.1. Expected result: Not having INSTALL_ROOT prepended in pear config and in pear command. Actual result: -- INSTALL_ROOT prepended in pear config and in pear command. -- Edit this bug report at http://bugs.php.net/?id=35780&edit=1
#35778 [Opn->Fbk]: PHP 5.1.1
ID: 35778 Updated by: [EMAIL PROTECTED] Reported By: popefelix at gmail dot com -Status: Open +Status: Feedback Bug Type: PDO related Operating System: SuSE Linux 9.3 PHP Version: 5.1.1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2005-12-22 22:11:02] popefelix at gmail dot com Description: When attempting to compile PHP 5.1.1 with "--enable-pdo=shared" passed to ./configure, make fails with undefined references in ext/pdo_sqlite/pdo_sqlite.c. While I realize that this is a duplicate of bug 34939, this error is in PHP 5.1.1, which postdates the closure of that bug. Reproduce code: --- './configure' '--enable-soap' '--with-apxs2' '--with-mysqli=/usr/local/mysql/bin/mysql_config' '--prefix=/usr/local/php' '--with-xml' '--with-zlib' '--with-openssl' '--enable-calendar' '--with-jpeg-dir=/usr/lib' '--with-gd' '--with-xsl' '--enable-mbstring' --enable-pdo=shared --enable-fileinfo=shared Expected result: PHP should compile. Actual result: -- ext/pdo_sqlite/.libs/pdo_sqlite.o(.text+0x5c): In function `zm_shutdown_pdo_sqlite': /usr/src/php-5.1.1/ext/pdo_sqlite/pdo_sqlite.c:87: undefined reference to `php_pdo_unregister_driver' ext/pdo_sqlite/.libs/pdo_sqlite.o(.text+0x7c): In function `zm_startup_pdo_sqlite': /usr/src/php-5.1.1/ext/pdo_sqlite/pdo_sqlite.c:80: undefined reference to `php_pdo_register_driver' ext/pdo_sqlite/.libs/sqlite_driver.o(.text+0x19c): In function `zif_SQLite_sqliteCreateAggregate': /usr/src/php-5.1.1/ext/pdo_sqlite/sqlite_driver.c:543: undefined reference to `pdo_raise_impl_error' ext/pdo_sqlite/.libs/sqlite_driver.o(.text+0x394): In function `zif_SQLite_sqliteCreateFunction': /usr/src/php-5.1.1/ext/pdo_sqlite/sqlite_driver.c:471: undefined reference to `pdo_raise_impl_error' ext/pdo_sqlite/.libs/sqlite_driver.o(.text+0xb2a): In function `pdo_sqlite_last_insert_id': /usr/src/php-5.1.1/ext/pdo_sqlite/sqlite_driver.c:197: undefined reference to `php_pdo_int64_to_str' ext/pdo_sqlite/.libs/sqlite_driver.o(.text+0xddc): In function `_pdo_sqlite_error': /usr/src/php-5.1.1/ext/pdo_sqlite/sqlite_driver.c:78: undefined reference to `php_pdo_get_exception' ext/pdo_sqlite/.libs/sqlite_driver.o(.text+0x101d): In function `pdo_sqlite_handle_factory': /usr/src/php-5.1.1/ext/pdo_sqlite/sqlite_driver.c:697: undefined reference to `php_pdo_get_exception' ext/pdo_sqlite/.libs/sqlite_statement.o(.text+0x365): In function `pdo_sqlite_stmt_param_hook': /usr/src/php-5.1.1/ext/pdo_sqlite/sqlite_statement.c:116: undefined reference to `pdo_raise_impl_error' ext/sqlite/.libs/sqlite.o(.text+0x4a67): In function `zm_shutdown_sqlite': /usr/src/php-5.1.1/ext/sqlite/sqlite.c:1113: undefined reference to `php_pdo_unregister_driver' ext/sqlite/.libs/sqlite.o(.text+0x5298): In function `zm_startup_sqlite': /usr/src/php-5.1.1/ext/sqlite/sqlite.c:1100: undefined reference to `php_pdo_register_driver' ext/sqlite/.libs/pdo_sqlite2.o(.text+0x1af): In function `pdo_sqlite2_last_insert_id': /usr/src/php-5.1.1/ext/sqlite/pdo_sqlite2.c:373: undefined reference to `php_pdo_int64_to_str' ext/sqlite/.libs/pdo_sqlite2.o(.text+0x544): In function `_pdo_sqlite2_error': /usr/src/php-5.1.1/ext/sqlite/pdo_sqlite2.c:291: undefined reference to `php_pdo_get_exception' ext/sqlite/.libs/pdo_sqlite2.o(.text+0xb60): In function `pdo_sqlite2_handle_factory': /usr/src/php-5.1.1/ext/sqlite/pdo_sqlite2.c:579: undefined reference to `php_pdo_get_exception' -- Edit this bug report at http://bugs.php.net/?id=35778&edit=1
#32561 [Opn->Asn]: Erroneous Allow HTTP response header
ID: 32561 Updated by: [EMAIL PROTECTED] Reported By: mnot at pobox dot com -Status: Open +Status: Assigned Bug Type: Apache related Operating System: * PHP Version: 5.*, 4.* Assigned To: rasmus New Comment: Rasmus, are you planning on doing anything about this? Previous Comments: [2005-10-20 00:32:28] mnot at pobox dot com See also: http://issues.apache.org/bugzilla/show_bug.cgi?id=15242 for resolution of a simliar bug in mod_cgi. [2005-09-21 12:51:15] [EMAIL PROTECTED] Assigned to Rasmus who should know what to do with this bug. [2005-04-24 00:00:26] [EMAIL PROTECTED] This was added in PHP 3, by Rasmus with this commit msg: "AAPI cleanup - Set rqst->allowed correctly and deny OPTIONS requests" [2005-04-04 18:41:12] mnot at pobox dot com By doing that, it's saying that it would handle those methods in the future. If it won't, it shouldn't set that. The downline handler *shouldn't* blow away r->allowed and put its own values in; this would remove any information from other handlers. E.g., if mod_cgi did this, mod_dav couldn't advertise the methods that it would catch. [2005-04-04 07:25:19] [EMAIL PROTECTED] Actually, it resets the r->allowed to all the methods when it declines to handle the request for the next handler in the chain. It probably doesn't need to do this, but it isn't unique to the xbithack handler. Whatever finally accepts to handle the request should be setting r->allowed accordingly. 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/32561 -- Edit this bug report at http://bugs.php.net/?id=32561&edit=1
#32561 [Asn->Opn]: Erroneous Allow HTTP response header
ID: 32561 Updated by: [EMAIL PROTECTED] Reported By: mnot at pobox dot com -Status: Assigned +Status: Open Bug Type: Apache related Operating System: * PHP Version: 5.*, 4.* Assigned To: rasmus Previous Comments: [2005-10-20 00:32:28] mnot at pobox dot com See also: http://issues.apache.org/bugzilla/show_bug.cgi?id=15242 for resolution of a simliar bug in mod_cgi. [2005-09-21 12:51:15] [EMAIL PROTECTED] Assigned to Rasmus who should know what to do with this bug. [2005-04-24 00:00:26] [EMAIL PROTECTED] This was added in PHP 3, by Rasmus with this commit msg: "AAPI cleanup - Set rqst->allowed correctly and deny OPTIONS requests" [2005-04-04 18:41:12] mnot at pobox dot com By doing that, it's saying that it would handle those methods in the future. If it won't, it shouldn't set that. The downline handler *shouldn't* blow away r->allowed and put its own values in; this would remove any information from other handlers. E.g., if mod_cgi did this, mod_dav couldn't advertise the methods that it would catch. [2005-04-04 07:25:19] [EMAIL PROTECTED] Actually, it resets the r->allowed to all the methods when it declines to handle the request for the next handler in the chain. It probably doesn't need to do this, but it isn't unique to the xbithack handler. Whatever finally accepts to handle the request should be setting r->allowed accordingly. 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/32561 -- Edit this bug report at http://bugs.php.net/?id=32561&edit=1
#35774 [Opn->Bgs]: cannot access libphp5.so
ID: 35774 Updated by: [EMAIL PROTECTED] Reported By: necat at digicol dot de -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: ia64-hp-hpux11.23 PHP Version: 5.1.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. Previous Comments: [2005-12-22 15:02:48] necat at digicol dot de Description: php version is php-5.1-200512191330 configure ok make ok make install not ok Reproduce code: --- #!/bin/sh PHPVER=5.1-200512191330 APAVER=13.34 PHP=/dc5/home/appdc5/Sourcen/php-$PHPVER PHPINST=/dc5/dc/bin/php-$PHPVER PHPCONF=/dc5/dc/init APACHE=/dc5/home/appdc5/Sourcen/apache_$APAVER CCLIENT=/usr/share/doc/packages/imap ORACLE=/dc5/home/appdc5/oracle/ORAHOME APXS=/dc5/dc/bin/apache_1.3.34/bin/apxs ../php-$PHPVER/configure \ --with-png-dir=/usr/local \ --with-freetype-dir=/usr/local \ --with-jpeg-dir=/usr/local \ --with-config-file-path=$PHPCONF \ --prefix=$PHPINST \ --exec-prefix=$PHPINST \ --enable-mbstring=all \ --enable-mbregex \ --enable-pcntl \ --with-dom \ --with-gdbm \ --enable-sigchild \ --enable-inline-optimization \ --without-mysql \ --with-zlib \ --enable-exif \ --enable-ftp \ --with-iconv \ --enable-memory-limit \ --with-oci8=$ORACLE \ --with-apxs=$APXS \ --without-pear Actual result: -- make install Installing PHP SAPI module: apache [activating module `php5' in /dc5/dc/bin/apache_1.3.34/conf/httpd.conf] cp libs/libphp5.so /dc5/dc/bin/apache_1.3.34/libexec/libphp5.so cp: cannot access libs/libphp5.so: No such file or directory apxs:Break: Command failed with rc=1 *** Error exit code 1 Stop. [EMAIL PROTECTED]:/dc5/home/appdc5/Sourcen/php-5.1-200512191330-apxs>ll libs total 52848 drwxr-x--- 2 appdc5 dc5 96 Dec 22 14:11 ./ drwxr-x--- 14 appdc5 dc5 8192 Dec 22 14:11 ../ -rw-r--r-- 1 appdc5 dc527039978 Dec 22 14:11 libphp5.a -rw-r- 1 appdc5 dc5 1174 Dec 22 14:11 libphp5.la Regards, Necat Kutlar -- Edit this bug report at http://bugs.php.net/?id=35774&edit=1
#35732 [Opn->Fbk]: Access violation on file open
ID: 35732 Updated by: [EMAIL PROTECTED] Reported By: rene at lico dot nl -Status: Open +Status: Feedback Bug Type: IIS related Operating System: Windows 2003 PHP Version: 5CVS-2005-12-20 (snap) New Comment: Do you have the asp tags enabled in php.ini ? Previous Comments: [2005-12-22 14:08:48] rene at lico dot nl I can't find the exact cause. If the error has occoured it wil again do so when the is executed. I've tried to get the error only using file_get_contents, but that dind't work out. This also means I can't get it to happen on apache. Note that the website I use here uses both asp and php files. The complete site can't be copied to an apache environment. I've found sombody who has visual c so we're installing everything else on his pc. I hope this results in something more. I'll keep you updated on this, but I think it will be next year; since I'm on holiday for the next week. [2005-12-21 21:15:09] [EMAIL PROTECTED] Can you reproduce this using some other web server, like Apache? [2005-12-21 17:39:35] rene at lico dot nl No, the localhost could also be replaced with something else like an asp scripts (what it is used for in my case) [2005-12-21 16:20:21] [EMAIL PROTECTED] If you have this: http://localhost";); ?> Is the content of this file in same file which is outputted? [2005-12-21 16:12:51] rene at lico dot nl I would try the develpack if i had MSVC6, but i don't. What to do? Is there a seperate download to only have the debug functions? I will try to make a seperate script that raises the problem... The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/35732 -- Edit this bug report at http://bugs.php.net/?id=35732&edit=1
#35772 [Opn->Bgs]: preg_match don't match right...
ID: 35772 Updated by: [EMAIL PROTECTED] Reported By: nwhunter at gmail dot com -Status: Open +Status: Bogus Bug Type: Regexps related Operating System: Debian PHP Version: 5.1.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: [2005-12-22 13:45:30] nwhunter at gmail dot com Description: problem with preg_match, dont match right if string contain something eg. \x1ds\x1f\x1f\x1f\x1f\x1f\x1faa . Reproduce code: --- aa"; // ok $cn2 = "{__directr[15]}\x1d s\x1f\x1f\x1f\x1f\x1f\x1faa"; // not ok if(preg_match("/^(\{\_\_+[a-z]+\[+(.*)+\]\})/i", $cn1)) print("ok"); else print("not ok"); if(preg_match("/^(\{\_\_+[a-z]+\[+(.*)+\]\})/i", $cn2)) print("ok"); else print("not ok"); ?> Expected result: ok ok Actual result: -- ok not ok -- Edit this bug report at http://bugs.php.net/?id=35772&edit=1
#35773 [Opn->Fbk]: Zend engine loops
ID: 35773 Updated by: [EMAIL PROTECTED] Reported By: igmar at palsenberg dot com -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux 2.6.x PHP Version: 4CVS-2005-12-22 (CVS) New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2005-12-22 14:18:27] igmar at palsenberg dot com Description: The ZE loops at certain code. I haven't found the actual code that triggers it, but it show up frequently when using phpMyAdmin. Configure line : ./configure' '--with-apache=/home/igmar/OWN/lamp-ssl/apache_1.3.34' '--with-gd' '--with-zlib' '--with-kerberos' '--with-openssl' '--enable-gd-native-ttf' '--with-freetype' '--with-freetype-dir=/usr' '--enable-track-vars' '--with-freetype' '--with-mysql=/usr' '--enable-sockets' '--with-config-file-path=/etc/httpsd' '--enable-memory-limit' '--enable-sysvshm' '--enable-sysvsem' '--with-domxml' '--with-dom' '--enable-ftp' '--with-openssl' '--with-db4' '--with-gettext' '--with-pdflib' '--with-jpeg-dir=/usr' '--with-tiff-dir=/usr' '--with-png-dir=/usr' '--with-ming=/usr' '--with-xmlrpc' '--with-readline' '--enable-xslt' '--with-xslt-sablot' '--enable-mbstring' '--with-imap' '--with-imap-ssl' Apache is 1.3.34 + latest mod_ssl Reproduce code: --- Unknown Actual result: -- 2 backtraces when the process starts looping. If there is a way that I can find out which PHP code it is actually executing, I'll be happy to find out. 4.3.x didn't exhibit this behaviour, I haven't tested 4.4.0. BT #1 #0 0x080f9326 in zend_hash_find (ht=0x84e53cc, arKey=0x87904bc "buffer", nKeyLength=7, pData=0xbfcb22c8) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_hash.c:896 #1 0x080ff813 in zend_fetch_var_address (opline=0x87c7450, Ts=0xbfcb2310, type=0) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_execute.c:594 #2 0x08101c26 in execute (op_array=0x8747e2c) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_execute.c:1302 #3 0x08104405 in execute (op_array=0x85b935c) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_execute.c:2272 #4 0x080f529f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend.c:934 #5 0x080d370c in php_execute_script (primary_file=0xbfcbc650) at /home/igmar/OWN/lamp-ssl/php-src/main/main.c:1753 #6 0x0810c558 in apache_php_module_main (r=0x858e454, display_source_mode=0) at /home/igmar/OWN/lamp-ssl/php-src/sapi/apache/sapi_apache.c:54 #7 0x080cbc80 in send_php (r=0x858e454, display_source_mode=0, filename=0x0) at /home/igmar/OWN/lamp-ssl/php-src/sapi/apache/mod_php4.c:627 #8 0x080cbf0e in send_parsed_php (r=0x858e454) at /home/igmar/OWN/lamp-ssl/php-src/sapi/apache/mod_php4.c:642 #9 0x0821d7c8 in ap_invoke_handler () #10 0x08232e7e in process_request_internal () #11 0x08232edd in ap_process_request () #12 0x08229ceb in child_main ()#13 0x08229fd4 in make_child () #14 0x0822a30d in perform_idle_server_maintenance () #15 0x0822a91a in standalone_main () #16 0x0822af3d in main () BT #2 : 0x080f8536 in zend_hash_add_or_update (ht=0x864cb2c, arKey=0x85cee4c "offset", nKeyLength=7, pData=0xbfcb1314, nDataSize=4, pDest=0xbfcb1318, flag=1) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_hash.h:197 197 h += (h << 5); #0 0x080f8536 in zend_hash_add_or_update (ht=0x864cb2c, arKey=0x85cee4c "offset", nKeyLength=7, pData=0xbfcb1314, nDataSize=4, pDest=0xbfcb1318, flag=1) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_hash.h:197 #1 0x080ff9df in zend_fetch_var_address (opline=0x87bd13c, Ts=0xbfcb1360, type=1) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_execute.c:609 #2 0x08101c5b in execute (op_array=0x8604e30) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_execute.c:1281 #3 0x08103f93 in execute (op_array=0x8747e2c) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_execute.c:1719 #4 0x08104405 in execute (op_array=0x85b935c) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_execute.c:2272 #5 0x080f529f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend.c:934 #6 0x080d370c in php_execute_script (primary_file=0xbfcbc650) at /home/igmar/OWN/lamp-ssl/php-src/main/main.c:1753 #7 0x0810c558 in apache_php_module_main (r=0x858e454, display_source_mode=0) at /home/igmar/OWN/lamp-ssl/php-src/sapi/apache/sapi_apache.c:54 #8 0x080cbc80 in send_php (r=0x858e454, display_source_mode=0, filename=0x0) at /home/igmar/OWN/lamp-ssl/php-src/sapi/apache/mod_php4.c:627 #9 0x080cbf0e in send_parsed_php (r=0x858e454) at /home/igmar/OWN/lamp-ssl/php-src/sapi/apache/mod_php4.c:642 #10 0x0821d7c8 in ap_invoke_handler () #11 0x08232e7e in process_request_internal
#35732 [Opn->Fbk]: Access violation on file open
ID: 35732 Updated by: [EMAIL PROTECTED] Reported By: rene at lico dot nl -Status: Open +Status: Feedback Bug Type: IIS related Operating System: Windows 2003 PHP Version: 5CVS-2005-12-20 (snap) Previous Comments: [2005-12-22 14:37:02] rene at lico dot nl I'm not yet able to reproduce the problem by using a seperate peace of code. I will post it here when I can reproduce it [2005-12-22 14:33:22] [EMAIL PROTECTED] 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 possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. [2005-12-22 14:20:30] rene at lico dot nl no. IIS is also configured to use the php engine only on .php and asp engine only on .asp and .inc [2005-12-22 14:17:05] [EMAIL PROTECTED] Do you have the asp tags enabled in php.ini ? [2005-12-22 14:08:48] rene at lico dot nl I can't find the exact cause. If the error has occoured it wil again do so when the is executed. I've tried to get the error only using file_get_contents, but that dind't work out. This also means I can't get it to happen on apache. Note that the website I use here uses both asp and php files. The complete site can't be copied to an apache environment. I've found sombody who has visual c so we're installing everything else on his pc. I hope this results in something more. I'll keep you updated on this, but I think it will be next year; since I'm on holiday for the next week. 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/35732 -- Edit this bug report at http://bugs.php.net/?id=35732&edit=1
#35732 [Opn->Fbk]: Access violation on file open
ID: 35732 Updated by: [EMAIL PROTECTED] Reported By: rene at lico dot nl -Status: Open +Status: Feedback Bug Type: IIS related Operating System: Windows 2003 PHP Version: 5CVS-2005-12-20 (snap) New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Previous Comments: [2005-12-22 14:20:30] rene at lico dot nl no. IIS is also configured to use the php engine only on .php and asp engine only on .asp and .inc [2005-12-22 14:17:05] [EMAIL PROTECTED] Do you have the asp tags enabled in php.ini ? [2005-12-22 14:08:48] rene at lico dot nl I can't find the exact cause. If the error has occoured it wil again do so when the is executed. I've tried to get the error only using file_get_contents, but that dind't work out. This also means I can't get it to happen on apache. Note that the website I use here uses both asp and php files. The complete site can't be copied to an apache environment. I've found sombody who has visual c so we're installing everything else on his pc. I hope this results in something more. I'll keep you updated on this, but I think it will be next year; since I'm on holiday for the next week. [2005-12-21 21:15:09] [EMAIL PROTECTED] Can you reproduce this using some other web server, like Apache? [2005-12-21 17:39:35] rene at lico dot nl No, the localhost could also be replaced with something else like an asp scripts (what it is used for in my case) 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/35732 -- Edit this bug report at http://bugs.php.net/?id=35732&edit=1
#35604 [Asn->Fbk]: PDO crash
ID: 35604 Updated by: [EMAIL PROTECTED] Reported By: smlerman at gmail dot com -Status: Assigned +Status: Feedback Bug Type: PDO related Operating System: Linux PHP Version: 5CVS-2005-12-09 (snap) Assigned To: wez New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2005-12-12 14:40:52] smlerman at gmail dot com # awk --version GNU Awk 3.1.3 Copyright (C) 1989, 1991-2003 Free Software Foundation. [2005-12-12 14:26:47] [EMAIL PROTECTED] ==19435== Invalid write of size 4 ==19435==at 0x80B5654: pgsql_stmt_param_hook (pgsql_statement.c:278) ==19435==by 0x80AD15B: dispatch_param_event (pdo_stmt.c:149) ==19435==by 0x80AD9F7: zif_PDOStatement_execute (pdo_stmt.c:422) ==19435==by 0x81A5B6C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:192) ==19435==by 0x81A6064: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:314) ==19435==by 0x81A5832: execute (zend_vm_execute.h:92) ==19435==by 0x818A69D: zend_execute_scripts (zend.c:1101) ==19435==by 0x8149B57: php_execute_script (main.c:1720) ==19435==by 0x81EA7A1: main (php_cli.c:1077) ==19435== Address 0x1BD907B8 is 0 bytes after a block of size 8 alloc'd ==19435==at 0x1B901B95: calloc (vg_replace_malloc.c:279) ==19435==by 0x80B52AD: pgsql_stmt_param_hook (pgsql_statement.c:222) ==19435==by 0x80AD15B: dispatch_param_event (pdo_stmt.c:149) ==19435==by 0x80AD9F7: zif_PDOStatement_execute (pdo_stmt.c:422) ==19435==by 0x81A5B6C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:192) ==19435==by 0x81A6064: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:314) ==19435==by 0x81A5832: execute (zend_vm_execute.h:92) ==19435==by 0x818A69D: zend_execute_scripts (zend.c:1101) ==19435==by 0x8149B57: php_execute_script (main.c:1720) ==19435==by 0x81EA7A1: main (php_cli.c:1077) ==19435== ==19435== Invalid write of size 4 ==19435==at 0x80B5672: pgsql_stmt_param_hook (pgsql_statement.c:279) ==19435==by 0x80AD15B: dispatch_param_event (pdo_stmt.c:149) ==19435==by 0x80AD9F7: zif_PDOStatement_execute (pdo_stmt.c:422) ==19435==by 0x81A5B6C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:192) ==19435==by 0x81A6064: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:314) ==19435==by 0x81A5832: execute (zend_vm_execute.h:92) ==19435==by 0x818A69D: zend_execute_scripts (zend.c:1101) ==19435==by 0x8149B57: php_execute_script (main.c:1720) ==19435==by 0x81EA7A1: main (php_cli.c:1077) ==19435== Address 0x1BD907F0 is 0 bytes after a block of size 8 alloc'd ==19435==at 0x1B901B95: calloc (vg_replace_malloc.c:279) ==19435==by 0x80B52CF: pgsql_stmt_param_hook (pgsql_statement.c:225) ==19435==by 0x80AD15B: dispatch_param_event (pdo_stmt.c:149) ==19435==by 0x80AD9F7: zif_PDOStatement_execute (pdo_stmt.c:422) ==19435==by 0x81A5B6C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:192) ==19435==by 0x81A6064: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:314) ==19435==by 0x81A5832: execute (zend_vm_execute.h:92) ==19435==by 0x818A69D: zend_execute_scripts (zend.c:1101) ==19435==by 0x8149B57: php_execute_script (main.c:1720) ==19435==by 0x81EA7A1: main (php_cli.c:1077) ==19435== ==19435== Invalid write of size 4 ==19435==at 0x80B5687: pgsql_stmt_param_hook (pgsql_statement.c:280) ==19435==by 0x80AD15B: dispatch_param_event (pdo_stmt.c:149) ==19435==by 0x80AD9F7: zif_PDOStatement_execute (pdo_stmt.c:422) ==19435==by 0x81A5B6C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:192) ==19435==by 0x81A6064: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:314) ==19435==by 0x81A5832: execute (zend_vm_execute.h:92) ==19435==by 0x818A69D: zend_execute_scripts (zend.c:1101) ==19435==by 0x8149B57: php_execute_script (main.c:1720) ==19435==by 0x81EA7A1: main (php_cli.c:1077) ==19435== Address 0x1BD90828 is 0 bytes after a block of size 8 alloc'd ==19435==at 0x1B901B95: calloc (vg_replace_malloc.c:279) ==19435==by 0x80B52F1: pgsql_stmt_param_hook (pgsql_statement.c:228) ==19435==by 0x80AD15B: dispatch_param_event (pdo_stmt.c:149) ==19435==by 0x80AD9F7: zif_PDOStatement_execute (pdo_stmt.c:422) ==19435==by 0x81A5B6C: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:192) ==19435==by 0x81A6064: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:314) ==19435==by 0x81A5832: execute (zend_vm_execute.h:92) ==19435==by 0x818A69D: zend_execute_scripts (zend.c:1101) ==19435==by 0x8149B57: php_execute_script (main.c:1720) ==19435==by 0x81EA7A1: main (php_cli.c:1077) ==19435== ==19435== Invalid write of size
#35773 [Opn->Bgs]: Zend engine loops
ID: 35773 Updated by: [EMAIL PROTECTED] Reported By: igmar at palsenberg dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux 2.6.x PHP Version: 4CVS-2005-12-22 (CVS) New Comment: Then you need to fix the code. Previous Comments: [2005-12-22 14:48:45] igmar at palsenberg dot com Those snaps are for 5.x, this is a 4.x setup, and has code that doesn't work on 5.x [2005-12-22 14:32:37] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-12-22 14:18:27] igmar at palsenberg dot com Description: The ZE loops at certain code. I haven't found the actual code that triggers it, but it show up frequently when using phpMyAdmin. Configure line : ./configure' '--with-apache=/home/igmar/OWN/lamp-ssl/apache_1.3.34' '--with-gd' '--with-zlib' '--with-kerberos' '--with-openssl' '--enable-gd-native-ttf' '--with-freetype' '--with-freetype-dir=/usr' '--enable-track-vars' '--with-freetype' '--with-mysql=/usr' '--enable-sockets' '--with-config-file-path=/etc/httpsd' '--enable-memory-limit' '--enable-sysvshm' '--enable-sysvsem' '--with-domxml' '--with-dom' '--enable-ftp' '--with-openssl' '--with-db4' '--with-gettext' '--with-pdflib' '--with-jpeg-dir=/usr' '--with-tiff-dir=/usr' '--with-png-dir=/usr' '--with-ming=/usr' '--with-xmlrpc' '--with-readline' '--enable-xslt' '--with-xslt-sablot' '--enable-mbstring' '--with-imap' '--with-imap-ssl' Apache is 1.3.34 + latest mod_ssl Reproduce code: --- Unknown Actual result: -- 2 backtraces when the process starts looping. If there is a way that I can find out which PHP code it is actually executing, I'll be happy to find out. 4.3.x didn't exhibit this behaviour, I haven't tested 4.4.0. BT #1 #0 0x080f9326 in zend_hash_find (ht=0x84e53cc, arKey=0x87904bc "buffer", nKeyLength=7, pData=0xbfcb22c8) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_hash.c:896 #1 0x080ff813 in zend_fetch_var_address (opline=0x87c7450, Ts=0xbfcb2310, type=0) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_execute.c:594 #2 0x08101c26 in execute (op_array=0x8747e2c) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_execute.c:1302 #3 0x08104405 in execute (op_array=0x85b935c) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_execute.c:2272 #4 0x080f529f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend.c:934 #5 0x080d370c in php_execute_script (primary_file=0xbfcbc650) at /home/igmar/OWN/lamp-ssl/php-src/main/main.c:1753 #6 0x0810c558 in apache_php_module_main (r=0x858e454, display_source_mode=0) at /home/igmar/OWN/lamp-ssl/php-src/sapi/apache/sapi_apache.c:54 #7 0x080cbc80 in send_php (r=0x858e454, display_source_mode=0, filename=0x0) at /home/igmar/OWN/lamp-ssl/php-src/sapi/apache/mod_php4.c:627 #8 0x080cbf0e in send_parsed_php (r=0x858e454) at /home/igmar/OWN/lamp-ssl/php-src/sapi/apache/mod_php4.c:642 #9 0x0821d7c8 in ap_invoke_handler () #10 0x08232e7e in process_request_internal () #11 0x08232edd in ap_process_request () #12 0x08229ceb in child_main ()#13 0x08229fd4 in make_child () #14 0x0822a30d in perform_idle_server_maintenance () #15 0x0822a91a in standalone_main () #16 0x0822af3d in main () BT #2 : 0x080f8536 in zend_hash_add_or_update (ht=0x864cb2c, arKey=0x85cee4c "offset", nKeyLength=7, pData=0xbfcb1314, nDataSize=4, pDest=0xbfcb1318, flag=1) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_hash.h:197 197 h += (h << 5); #0 0x080f8536 in zend_hash_add_or_update (ht=0x864cb2c, arKey=0x85cee4c "offset", nKeyLength=7, pData=0xbfcb1314, nDataSize=4, pDest=0xbfcb1318, flag=1) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_hash.h:197 #1 0x080ff9df in zend_fetch_var_address (opline=0x87bd13c, Ts=0xbfcb1360, type=1) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_execute.c:609 #2 0x08101c5b in execute (op_array=0x8604e30) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_execute.c:1281 #3 0x08103f93 in execute (op_array=0x8747e2c) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_execute.c:1719 #4 0x08104405 in execute (op_array=0x85b935c) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend_execute.c:2272 #5 0x080f529f in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/igmar/OWN/lamp-ssl/php-src/Zend/zend.c:934 #6 0x080d370c in php_execute_script (primary_file=0xbfcbc650) at /home/igmar/OWN/lamp-ssl/php-src/main/main.c:1753 #7 0x0810c558 in apache_php_module_main (r=0x858e454, display_source_mode=0) at /home/igmar/OWN/lamp-ssl/php-src/sapi/apache/sapi
#35770 [Opn->Asn]: inconsistent method naming PDO::exec and PDOStatement::execute
ID: 35770 Updated by: [EMAIL PROTECTED] Reported By: fh at ez dot no -Status: Open +Status: Assigned Bug Type: PDO related Operating System: linux - gentoo PHP Version: 5.1.1 -Assigned To: +Assigned To: wez New Comment: Assigned to the maintainer. Previous Comments: [2005-12-22 11:10:04] fh at ez dot no Description: The methods should either be named the same or given names that separate them more clearly. -- Edit this bug report at http://bugs.php.net/?id=35770&edit=1
#35386 [Asn->Fbk]: first row is null
ID: 35386
Updated by: [EMAIL PROTECTED]
Reported By: slapaf at hotmail dot com
-Status: Assigned
+Status: Feedback
Bug Type: PDO related
Operating System: winxp sp2
PHP Version: 5.1.0
Assigned To: abies
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Previous Comments:
[2005-11-25 11:58:10] [EMAIL PROTECTED]
Assigned to the maintainer.
[2005-11-25 11:55:38] slapaf at hotmail dot com
deleting row with "name 1" and inserting a "name 5" returns:
NULL :
string : name 3
string : name 4
string : name 5
[2005-11-25 11:48:44] slapaf at hotmail dot com
array(2) {
["EVENT_NAME"]=>
NULL
[0]=>
NULL
}
array(2) {
["EVENT_NAME"]=>
string(6) "name 2"
[0]=>
string(6) "name 2"
}
array(2) {
["EVENT_NAME"]=>
string(6) "name 3"
[0]=>
string(6) "name 3"
}
array(2) {
["EVENT_NAME"]=>
string(6) "name 4"
[0]=>
string(6) "name 4"
}
[2005-11-25 11:44:58] [EMAIL PROTECTED]
Change this line:
print ''.gettype($row['EVENT_NAME']).' : '.$row['EVENT_NAME'];
to
var_dump($row);
and paste the result here.
[2005-11-25 11:38:32] slapaf at hotmail dot com
Description:
When using PDO for simple query in Firebird it returns first row as
null.
I've tried using ADODB for control and it returns the correct results.
Reproduce code:
---
$dbh = new PDO("firebird:dbname=localhost:test.fdb","","**");
$sql='SELECT EVENT_NAME FROM EVENTS';
foreach($dbh->query($sql) as $row){
print ''.gettype($row['EVENT_NAME']).' :
'.$row['EVENT_NAME'];
}
Expected result:
string : name 1
string : name 2
string : name 3
string : name 4
Actual result:
--
NULL :
string : name 2
string : name 3
string : name 4
--
Edit this bug report at http://bugs.php.net/?id=35386&edit=1
#32503 [Opn->NoF]: fopen() in cwd: filename must start with ./ under safe mode
ID: 32503 Updated by: [EMAIL PROTECTED] Reported By: Bjorn dot Wiberg at its dot uu dot se -Status: Open +Status: No Feedback Bug Type: Safe Mode/open_basedir Operating System: IBM AIX 5.2.0.0 ML5 PHP Version: 5.1.1 Previous Comments: [2005-12-19 17:46:22] Bjorn dot Wiberg at its dot uu dot se Hi sniper! Just wanted to tell you that for 5.1.1, the following holds: If the path to the file is not listable (r flag) all the way, one gets the following message: Warning: fopen(): open_basedir restriction in effect. File(a.txt) is not within the allowed path(s): (.:/apache/php/lib/php/:/apache/htdocs/bwiberg/) in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Warning: fopen(a.txt): failed to open stream: Not owner in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 The same error occurs until one makes sure that the path all the way to the file is listable (r flag). Then, with the path all the way to the file listable (r flag), one gets, with "a.txt" and no existing file: /apache/htdocs/bwiberg/test/safemode Warning: fopen(): Unable to access a.txt in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Warning: fopen(a.txt): failed to open stream: No such file or directory in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 However, "./a.txt" and no existing file works fine. With "a.txt" and the file already existing, things work just fine. With "./a.txt" and the file already existing, things work just fine. Would it be OK to wait for 5.1.2, or have things related to this actually changed in the latest snapshot? (I just recompiled and installed 5.1.1, awaiting some possible input on or fixes to another bug, so I hope to recompile again sometime early next year.) Wishing you a Merry Christmas and a Happy New Year, and for putting up with me and my AIX troubles. :-) Best regards, Björn [2005-07-05 10:21:38] Bjorn dot Wiberg at its dot uu dot se (Thanks for fixing the mpm_common crash, that problem is gone now.) With #define HAVE_BROKEN_GETCWD 1 in php_config.h, and having made sure that the path up to the directory where the file is to be created has sufficient permissions, I still get the same error: /apache/htdocs/bwiberg/test/safemode Warning: fopen(): Unable to access a.txt in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Warning: fopen(a.txt): failed to open stream: No such file or directory in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Having the read (r) permission off for the "test" directory along the way: Warning: fopen(): open_basedir restriction in effect. File(a.txt) is not within the allowed path(s): (.:/apache/php/lib/php/:/apache/htdocs/bwiberg/) in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Warning: fopen(a.txt): failed to open stream: Not owner in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Best regards, Björn [2005-05-09 14:15:53] Bjorn dot Wiberg at its dot uu dot se Hi again! I just tried the #define HAVE_BROKEN_GETCWD 1 trick from http://bugs.php.net/bug.php?id=32501, with PHP 5.0.4 (the "fixed" version) but that didn't help in this regard. I thought I would mention this. Best regards, Björn [2005-04-05 09:28:28] Bjorn dot Wiberg at its dot uu dot se Hi Tony! Thank you for your feedback! I'm afraid that absolute paths aren't a very viable solution to this, as that probably would break too many scripts, expecting it to be possible to "just" save a file to the current directory. Is the "PHP realpath hack" supposed to handle these kind of problems on AIX? Please let me know if I can help in any way! Best regards, Björn [2005-04-04 17:11:05] [EMAIL PROTECTED] Right, this is somehow concerned with broken realpath() on AIX. The problem is that we end up with relative path in php_checkuid_ex() function and it fails to check permissions for the directory. Of course, the easiest solution is to use absolute paths everywhere. 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/32503 -- Edit this bug report at http://bugs.php.net/?id=32503&edit=1
#35769 [Opn->Bgs]: error handing dates prior to 1970
ID: 35769
Updated by: [EMAIL PROTECTED]
Reported By: php at 62nds dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: linux
PHP Version: 4.4.2RC1
New Comment:
This depends lot on the OS behind. If you want reliable date handling
you have to start using PHP 5.1 which has new date code. This is not
critical bug in PHP 4 so it will never get fixed there.
Previous Comments:
[2005-12-22 08:45:49] php at 62nds dot com
Example outputs "1969.12.31", mktime returns correct value
[2005-12-22 08:42:22] php at 62nds dot com
Description:
Wrong month and day returned by gmdate; year is correct most of the
time.
Reproduce code:
---
$membday = mktime(0, 0, 0, 6, 15, 1966);
echo gmdate('Y.m.d', $membday);
--
Edit this bug report at http://bugs.php.net/?id=35769&edit=1
#35750 [Fbk->Bgs]: libphp5.so not created
ID: 35750 Updated by: [EMAIL PROTECTED] Reported By: tim at or-media dot com -Status: Feedback +Status: Bogus Bug Type: *Compile Issues Operating System: Fedora core 4 PHP Version: 5.1.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. Previous Comments: [2005-12-21 12:32:48] tim at or-media dot com Has i already wrote "php 5.1-latest snap" - that did not work either. But i now have it working. How? I options i wanted to be includeder where: ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-config-file-path=/etc \ --with-pspell \ --with-bz2 \ --enable-magic-quotes \ --with-zlib \ --enable-bcmath \ --enable-calendar \ --with-gd \ --with-mysql \ --with-curl \ --with-db4\ --enable-dbx \ --enable-dio \ --enable-dom \ --with-dom-xslt \ --with-dom-exslt \ --with-dom \ --enable-bcmath \ --enable-exif \ --enable-ftp \ --enable-filepro \ --with-jpeg-dir=/usr/lib/ \ --with-freetype-dir=/usr/lib/ plus a few more. So what i done was only configured it with ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs \ --with-config-file-path=/etc \ Then kept compiling it with a few more added options. After i get it all working ill post the final configure [2005-12-20 19:01:12] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-12-20 18:48:37] tim at or-media dot com Description: I have seen this in previous reports but none have helped. After trying: php 4.3.11 php 5.1.1 php 5.l-latest snap It will not create libphp5.so or libphp4.so I have also updated the libtool in fc4 Reproduce code: --- make install Installing PHP SAPI module: apache2handler /usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp5.la /usr/local/apache2/modules /usr/local/apache2/build/libtool --mode=install cp libphp5.la /usr/local/apache2/modules/ cp .libs/libphp5.lai /usr/local/apache2/modules/libphp5.la cp .libs/libphp5.a /usr/local/apache2/modules/libphp5.a ranlib /usr/local/apache2/modules/libphp5.a chmod 644 /usr/local/apache2/modules/libphp5.a libtool: install: warning: remember to run `libtool --finish /home/timmy/webserver/php5.1-200512201530/libs' Warning! dlname not found in /usr/local/apache2/modules/libphp5.la. Assuming installing a .so rather than a libtool archive. chmod 755 /usr/local/apache2/modules/libphp5.so chmod: cannot access `/usr/local/apache2/modules/libphp5.so': No such file or directory apxs:Error: Command failed with rc=65536 . make: *** [install-sapi] Error 1 Expected result: libphp5.so built and moved to /usr/local/apache2/modules Actual result: -- didnt build lib -- Edit this bug report at http://bugs.php.net/?id=35750&edit=1
#27678 [Asn]: number_format() crashes with large numbers.
ID: 27678 Updated by: [EMAIL PROTECTED] Reported By: morten_odegaard at broadpark dot no Status: Assigned Bug Type: Math related Operating System: * PHP Version: 5CVS, 4CVS (2005-08-19) Assigned To: helly New Comment: 3rd reminder for Marcus: Check this out after Christmas 2005 but before New Year's eve 2005-2006 :) Previous Comments: [2005-11-01 11:31:35] [EMAIL PROTECTED] Marcus, can you check this out please? [2005-03-30 10:58:49] kameshj at fastmail dot fm Regarding the segfault, In main/snprintf.c:ap_php_cvt has a call to memmove(&buf[mvl], &buf[0], NDIG-mvl-1); NDIG-mvl-1 becomes -1 in the mentioned defect of double being 1e80, decimals 3, dec_sep '' and thousand_sep ' '. As I could see php recognizes a float as hight as 1e308, I feel NDIG should be set accordingly to higher value let us say 310 or 311. [2004-12-12 23:52:48] [EMAIL PROTECTED] (gdb) run -r "echo number_format(1e80, 3, '', ' ');" Starting program: /www/php-modules/bin/php -r "echo number_format(1e80, 3, '', ' ');" [New Thread 1087948032 (LWP 31942)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1087948032 (LWP 31942)] 0x4207c0ad in memmove () from /lib/tls/libc.so.6 (gdb) bt #0 0x4207c0ad in memmove () from /lib/tls/libc.so.6 #1 0xbfffd8e8 in ?? () #2 0x08259347 in ap_php_cvt (arg=Cannot access memory at address 0xffef ) at /usr/src/web/php/php4/main/snprintf.c:294 Cannot access memory at address 0x [2004-03-24 14:27:01] morten_odegaard at broadpark dot no Description: number_format() seems to be having problems with large numbers. I've found two different bugs, where one can segfault Apache. They are tested on both 4.3.4 and 5.0RC1 on Linux, and 4.3.4 on Windows. Bugs happens in all of them. -- Calling the function on numbers higher than (and including) 1e71, it will display a wrong result. Some numbers will have one 0 replaced with a 7, while some will be a digit too short, but be very close to the number it is supposed to show. -- When calling number_format() on numbers bigger than (and including) 1e80, it will either return nothing or crash, depending on the 'decimals' parameter. If 'decimals' is bigger then 0, then it will return nothing. If 'decimals' is lower then 1, Apache will segfault. Reproduce code: --- $ php -r "echo number_format(1e71, 0, '', ' ');" 100 000 000 000 000 070 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 $ php -r "echo number_format(1e72, 0, '', ' ');" 999 999 999 999 999 600 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 $ php -r "echo number_format(1e80, 3, '', ' ');" $ php -r "echo number_format(1e80, 0, '', ' ');" Segmentation fault Expected result: 100 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 1 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 10 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000.000 10 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 Actual result: -- Bug 1: Wrong numbers, as shown above. Bug 2: Nothing or a segfault, as show above. -- Edit this bug report at http://bugs.php.net/?id=27678&edit=1
#32062 [Opn->Asn]: mbstring fails to match encoding with some locale settings
ID: 32062 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: mbstring related Operating System: * PHP Version: 5CVS, 4CVS (2005-02-22) -Assigned To: moriyoshi +Assigned To: hirokawa New Comment: Rui, check this too if you don't mind. :) Previous Comments: [2005-02-22 16:17:51] [EMAIL PROTECTED] Right, there were typos. The reproduce code should've been [2005-02-22 15:25:03] [EMAIL PROTECTED] tr_TR == Turkish, and ISO-8859-1 is not a valid character set of that locale, no? [2005-02-22 06:55:52] [EMAIL PROTECTED] Description: mbstring fails to match encoding name against any one of the supported encodings with some locale settings. Irrelevant to bug #29955. Reproduce code: --- Expected result: string(1) "a" string(1) "a" string(1) "a" string(1) "a" Actual result: -- string(1) "a" string(1) "a" Warning: mb_convert_encoding(): Illegal character encoding specified in %s on line %d string(1) "a" string(1) "a" -- Edit this bug report at http://bugs.php.net/?id=32062&edit=1
#32062 [Asn->Opn]: mbstring fails to match encoding with some locale settings
ID: 32062 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Open Bug Type: mbstring related Operating System: * PHP Version: 5CVS, 4CVS (2005-02-22) Assigned To: moriyoshi Previous Comments: [2005-02-22 16:17:51] [EMAIL PROTECTED] Right, there were typos. The reproduce code should've been [2005-02-22 15:25:03] [EMAIL PROTECTED] tr_TR == Turkish, and ISO-8859-1 is not a valid character set of that locale, no? [2005-02-22 06:55:52] [EMAIL PROTECTED] Description: mbstring fails to match encoding name against any one of the supported encodings with some locale settings. Irrelevant to bug #29955. Reproduce code: --- Expected result: string(1) "a" string(1) "a" string(1) "a" string(1) "a" Actual result: -- string(1) "a" string(1) "a" Warning: mb_convert_encoding(): Illegal character encoding specified in %s on line %d string(1) "a" string(1) "a" -- Edit this bug report at http://bugs.php.net/?id=32062&edit=1
#29955 [Opn->Asn]: mb_strtoupper() / lower() broken with some locale
ID: 29955
Updated by: [EMAIL PROTECTED]
Reported By: jan at horde dot org
-Status: Open
+Status: Assigned
Bug Type: mbstring related
Operating System: Linux
PHP Version: 5CVS, 4CVS (2004-09-02)
-Assigned To: moriyoshi
+Assigned To: hirokawa
New Comment:
Rui, yet another for you. Moriyoshi seems to have vanished..
Previous Comments:
[2005-08-08 00:18:22] [EMAIL PROTECTED]
Are you going to fix this or not? If not, change the status to 'wont
fix'.
[2005-05-13 08:00:26] [EMAIL PROTECTED]
Turkish locale would need complete overhaul on the
entire extension because the locale's character
properties and required case folding behaviour are very
special.
PHP-ICU extension could support anything, but that's
just an ongoing work by l0t3k.
[2005-05-13 02:26:18] mustafa at deu dot edu dot tr
I get the same results like jan.
I need to get UTF-8 output for consuming a web service and I configured
my php 5.0.4 with --enable-mbstring=all parameter (on linux that has
been set with Turkish locale)
I see that mbstring extension has limited language support in source
code. (German, English, Japanese, Korean, Russian, Chinese)
Is there a way to add our (Turkish) language to source code? Any
references about this extension's source?
[2005-02-22 11:10:06] [EMAIL PROTECTED]
It turned out this is because mbstring doesn't take the
locale into consideration.
[2004-09-02 17:15:42] jan at horde dot org
Description:
In ISO-8859-9 (Turkish) the uppercase letter of "i" is a dotted
uppercase "I", the lowercase letter of "I" is a dotless "i". But
mb_strtolower() und mb_strtoupper() simply return the ASCII uppercase
or lowercase counterparts.
You get the correct result with:
setlocale(LC_ALL, 'tr_TR');
echo strtoupper('i');
echo strtolower('I');
But the wrong results with:
echo mb_strtoupper('i', 'iso-8859-9');
echo mb_strtolower('I', 'iso-8859-9');
--
Edit this bug report at http://bugs.php.net/?id=29955&edit=1
#29955 [Asn->Opn]: mb_strtoupper() / lower() broken with some locale
ID: 29955
Updated by: [EMAIL PROTECTED]
Reported By: jan at horde dot org
-Status: Assigned
+Status: Open
Bug Type: mbstring related
Operating System: Linux
PHP Version: 5CVS, 4CVS (2004-09-02)
Assigned To: moriyoshi
Previous Comments:
[2005-08-08 00:18:22] [EMAIL PROTECTED]
Are you going to fix this or not? If not, change the status to 'wont
fix'.
[2005-05-13 08:00:26] [EMAIL PROTECTED]
Turkish locale would need complete overhaul on the
entire extension because the locale's character
properties and required case folding behaviour are very
special.
PHP-ICU extension could support anything, but that's
just an ongoing work by l0t3k.
[2005-05-13 02:26:18] mustafa at deu dot edu dot tr
I get the same results like jan.
I need to get UTF-8 output for consuming a web service and I configured
my php 5.0.4 with --enable-mbstring=all parameter (on linux that has
been set with Turkish locale)
I see that mbstring extension has limited language support in source
code. (German, English, Japanese, Korean, Russian, Chinese)
Is there a way to add our (Turkish) language to source code? Any
references about this extension's source?
[2005-02-22 11:10:06] [EMAIL PROTECTED]
It turned out this is because mbstring doesn't take the
locale into consideration.
[2004-09-02 17:15:42] jan at horde dot org
Description:
In ISO-8859-9 (Turkish) the uppercase letter of "i" is a dotted
uppercase "I", the lowercase letter of "I" is a dotless "i". But
mb_strtolower() und mb_strtoupper() simply return the ASCII uppercase
or lowercase counterparts.
You get the correct result with:
setlocale(LC_ALL, 'tr_TR');
echo strtoupper('i');
echo strtolower('I');
But the wrong results with:
echo mb_strtoupper('i', 'iso-8859-9');
echo mb_strtolower('I', 'iso-8859-9');
--
Edit this bug report at http://bugs.php.net/?id=29955&edit=1
#28899 [Opn->Asn]: mb_substr() and substr() work differently
ID: 28899 Updated by: [EMAIL PROTECTED] Reported By: mauroi at digbang dot com -Status: Open +Status: Assigned Bug Type: mbstring related Operating System: * PHP Version: 5CVS, 4CVS (2004-12-12) -Assigned To: +Assigned To: hirokawa New Comment: Rui, can you check this please? Seems a bit odd that mbstring overloaded substr() works differently from the PHP core substr().. Previous Comments: [2005-02-23 16:56:34] drraf at tlen dot pl If mb_string() can overload substr() (when function overloading in on when using mbstring) - in my opinion mb_substr() should be fixed. [2005-02-03 03:25:48] [EMAIL PROTECTED] Whatever is the "logical" behaviour of the function, it doesn't really matter: We will NOT change the behaviour of substr() at this point. Thus the only place to change is mbstring. [2004-12-20 13:58:20] mauroi at digbang dot com just to mention it... lot of code written with the mb_* function overload relies on substr returning a zero length string... changing substr to work like mb_substr won't break anything (i think) [2004-12-20 10:28:55] [EMAIL PROTECTED] The very nature of "substr" is that the function returns the specified part of the string whenever the range is valid and returns an error status if it is out of range. If a null string is a valid string entity, then it should be able to be referred to by index "0" and thus the implementation returns a null string instead of false. Or you would say this isn't really logical? :) [2004-12-15 04:19:11] [EMAIL PROTECTED] The correct quote from up-to-date manual: "If string is less than or equal to start characters long, FALSE will be returned." Notice the 'or equal' there? Thus logically mb_substr() is buggy. 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/28899 -- Edit this bug report at http://bugs.php.net/?id=28899&edit=1
#28899 [Asn->Opn]: mb_substr() and substr() work differently
ID: 28899 Updated by: [EMAIL PROTECTED] Reported By: mauroi at digbang dot com -Status: Assigned +Status: Open Bug Type: mbstring related Operating System: * PHP Version: 5CVS, 4CVS (2004-12-12) Assigned To: moriyoshi Previous Comments: [2005-02-23 16:56:34] drraf at tlen dot pl If mb_string() can overload substr() (when function overloading in on when using mbstring) - in my opinion mb_substr() should be fixed. [2005-02-03 03:25:48] [EMAIL PROTECTED] Whatever is the "logical" behaviour of the function, it doesn't really matter: We will NOT change the behaviour of substr() at this point. Thus the only place to change is mbstring. [2004-12-20 13:58:20] mauroi at digbang dot com just to mention it... lot of code written with the mb_* function overload relies on substr returning a zero length string... changing substr to work like mb_substr won't break anything (i think) [2004-12-20 10:28:55] [EMAIL PROTECTED] The very nature of "substr" is that the function returns the specified part of the string whenever the range is valid and returns an error status if it is out of range. If a null string is a valid string entity, then it should be able to be referred to by index "0" and thus the implementation returns a null string instead of false. Or you would say this isn't really logical? :) [2004-12-15 04:19:11] [EMAIL PROTECTED] The correct quote from up-to-date manual: "If string is less than or equal to start characters long, FALSE will be returned." Notice the 'or equal' there? Thus logically mb_substr() is buggy. 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/28899 -- Edit this bug report at http://bugs.php.net/?id=28899&edit=1
#35461 [Asn->Csd]: Ming extension fails to compile with ming 0.3beta1
ID: 35461 Updated by: [EMAIL PROTECTED] Reported By: hostmaster at xenterra dot net -Status: Assigned +Status: Closed Bug Type: Ming related Operating System: * PHP Version: 5CVS-2005-12-21 (cvs) Assigned To: helly New Comment: This bug has been fixed in CVS. 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: [2005-11-29 19:29:56] hostmaster at xenterra dot net The snapshot php5-200511291530 failed to compile with ext/ming with essentially the same error messages as were originally reported (see Actual Result below). It appears that the ming extension code has not yet been re-worked. [2005-11-28 23:56:40] hostmaster at xenterra dot net Description: No script; this is a compile error. Configure options: ./configure --with-apxs=/usr/local/apache/bin/apxs \ --with-pgsql=/usr/local/pgsql \ --enable-dba \ --with-flatfile \ --with-openssl \ --enable-exif \ --with-gd=/usr/local/gd-2.0.33 \ --with-jpeg-dir=/usr/lib \ --with-png-dir=/usr/lib \ --with-zlib-dir=/usr/lib \ --with-xpm-dir=/usr/X11R6/lib \ --with-imap=/usr/local/imap-2002d \ --with-imap-ssl=/usr/local/ssl \ --with-curl \ --with-curlwrappers \ --enable-ftp \ --enable-soap \ --with-libxml-dir=/usr/local/lib \ --with-ming=/usr/local/lib \ --enable-sockets Compilation also failed using CVS snapshot php5-200511282130 on Slackware 10.2, and on Slackware 10.1 using official release. Ming version is ming-0.3beta1. Reproduce code: --- No code. Expected result: N/A Actual result: -- Following is gcc output right before "make" quit: /usr/local/php-5.1.1/ext/ming/ming.c: In function `zif_swfbitmap___construct': /usr/local/php-5.1.1/ext/ming/ming.c:386: warning: assignment from incompatible pointer type /usr/local/php-5.1.1/ext/ming/ming.c: In function `zif_swfmovie_output': /usr/local/php-5.1.1/ext/ming/ming.c:2267: error: too few arguments to function `SWFMovie_output' /usr/local/php-5.1.1/ext/ming/ming.c: In function `zif_swfmovie_saveToFile': /usr/local/php-5.1.1/ext/ming/ming.c:2329: error: too few arguments to function `SWFMovie_output' /usr/local/php-5.1.1/ext/ming/ming.c: In function `zif_swfmovie_save': /usr/local/php-5.1.1/ext/ming/ming.c:2380: error: too few arguments to function `SWFMovie_output' /usr/local/php-5.1.1/ext/ming/ming.c:2399: error: too few arguments to function `SWFMovie_output' /usr/local/php-5.1.1/ext/ming/ming.c: In function `zif_swftextfield_setFont': /usr/local/php-5.1.1/ext/ming/ming.c:3741: warning: passing arg 2 of `SWFTextField_setFont' from incompatible pointer type make: *** [ext/ming/ming.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=35461&edit=1
#35533 [Opn->Asn]: stream_socket_sendto() does not work with Unix sockets
ID: 35533 Updated by: [EMAIL PROTECTED] Reported By: mark-phpbugs at vectrex dot org dot uk -Status: Open +Status: Assigned Bug Type: Sockets related Operating System: Linux 2.6, Debian PHP Version: 5.1.1 Assigned To: pollita New Comment: Sara, can you look at this? Previous Comments: [2005-12-03 18:49:18] mark-phpbugs at vectrex dot org dot uk Description: No valid parameter exists for stream_socket_sendto with unix sockets; you can call it but it won't work under any circumstances. Reproduce code: --- Expected result: Send a Unix datagram containing "Hello" to socket /tmp/anothersocket Actual result: -- Warning: stream_socket_sendto(): php_network_getaddresses: getaddrinfo failed: Name or service not known in /home/mark/progs/betterforum/site/udgsendtotest.php on line 14 Warning: stream_socket_sendto(): Failed to parse `udg:///tmp/anothersocket' into a valid network address in /home/mark/progs/betterforum/site/udgsendtotest.php on line 14 -- Edit this bug report at http://bugs.php.net/?id=35533&edit=1
#35533 [Asn->Opn]: stream_socket_sendto() does not work with Unix sockets
ID: 35533 Updated by: [EMAIL PROTECTED] Reported By: mark-phpbugs at vectrex dot org dot uk -Status: Assigned +Status: Open Bug Type: Sockets related Operating System: Linux 2.6, Debian PHP Version: 5.1.1 Assigned To: pollita Previous Comments: [2005-12-03 18:49:18] mark-phpbugs at vectrex dot org dot uk Description: No valid parameter exists for stream_socket_sendto with unix sockets; you can call it but it won't work under any circumstances. Reproduce code: --- Expected result: Send a Unix datagram containing "Hello" to socket /tmp/anothersocket Actual result: -- Warning: stream_socket_sendto(): php_network_getaddresses: getaddrinfo failed: Name or service not known in /home/mark/progs/betterforum/site/udgsendtotest.php on line 14 Warning: stream_socket_sendto(): Failed to parse `udg:///tmp/anothersocket' into a valid network address in /home/mark/progs/betterforum/site/udgsendtotest.php on line 14 -- Edit this bug report at http://bugs.php.net/?id=35533&edit=1
#26555 [Asn->Fbk]: lvarchar not recognized
ID: 26555 Updated by: [EMAIL PROTECTED] Reported By: jkaufman at wamnetgov dot com -Status: Assigned +Status: Feedback Bug Type: Informix related Operating System: Mandrake 9.1 PHP Version: 4CVS-2003-12-9 Assigned To: nobbie New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2004-01-12 07:05:02] [EMAIL PROTECTED] Assigned to the ext/informix maintainer, Corne'. [2003-12-10 13:18:33] jkaufman at wamnetgov dot com Forgot to mention that the informix sdk is: IBM INFORMIX-Client SDK 2.81.UC1 PRODUCT RELEASE INFORMIX-ESQL/C Version 9.53 DATE: 04 Feb 2003 [2003-12-10 12:53:51] jkaufman at wamnetgov dot com I don't *know* that the interpretation of lvarchar in ifx.c is wrong just because I see a void type, but I do know this. I modified my db schema and changed the lvarchar(1000) to char(500) and the query works fine. I would prefer the lvarchar approach (it uses less db space and I 500 characters is not enough for my app), but it does demonstrate that there is something amiss in the way php handles lvarchar. [2003-12-09 14:41:20] [EMAIL PROTECTED] What informix sdk do you have installed? (and if your c-client, the imap thing, is linked with ssl, you need to use --with-imap-ssl) [2003-12-09 12:40:35] jkaufman at wamnetgov dot com I built using the snapshot. First problem is that '--with-imap' did not include '-lssl', though php-4.3.3 did. I removed that option from my configure statement and rebuilt. The problem is still present. ifx.c shows: #line 1768 "/usr/src/php4-STABLE-200312091430/ext/informix/ifx.ec" ifx_int8_t int8_var; #line 1769 "/usr/src/php4-STABLE-200312091430/ext/informix/ifx.ec" void *lvar_tmp = 0; 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/26555 -- Edit this bug report at http://bugs.php.net/?id=26555&edit=1
#28883 [Asn->Fbk]: [PATCH] fix for crash during module shutdown
ID: 28883
Updated by: [EMAIL PROTECTED]
Reported By: novicky at aarongroup dot cz
-Status: Assigned
+Status: Feedback
Bug Type: Informix related
Operating System: *
PHP Version: 5CVS, 4CVS (2005-02-05)
Assigned To: nobbie
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Previous Comments:
[2004-06-22 19:08:12] novicky at aarongroup dot cz
Description:
There is a problem in function ifx_do_close which can lead to crash
during module shutdown.
The function ifx_do_close is called during shutdown from list
destrucors _close_ifx_link and _close_ifx_plink. If something goes
wrong in this function, error reporting is performed and emalloc is
called. Calling emalloc is not possible during memory destruction and
can cause segfault.
It is necessary to remove all error reporting from ifx_do_close (which
is in fact useless).
Here is a patch:
--- ifx.ec.orig 2004-06-01 02:52:14.0 +0200
+++ ifx.ec 2004-06-22 18:46:01.0 +0200
@@ -295,7 +295,6 @@
PARAMETER char *link;
EXEC SQL END DECLARE SECTION;
{
- char *ifx_err = NULL;
TSRMLS_FETCH();
EXEC SQL SET CONNECTION :link;
@@ -310,32 +309,12 @@
if (ifx_check() == 0) {
/* DISCONNECT again, after rollback */
EXEC SQL DISCONNECT :link;
- if (ifx_check() < 0) {
- IFXG(sv_sqlcode) = SQLCODE;
- php_error_docref(NULL TSRMLS_CC,
E_WARNING, "Disconnect link %s
after Automatic Rollback fails (%s)", link, (ifx_err =
ifx_error(link)));
}
- }
- if (ifx_check() < 0) {
+ else if (ifx_check() < 0) {
/* CLOSE database if rollback or disconnect
fails */
EXEC SQL CLOSE DATABASE;
- if (ifx_check() < 0) {
- IFXG(sv_sqlcode) = SQLCODE;
- php_error_docref(NULL TSRMLS_CC,
E_WARNING, "Close database fails
%s (%s)", link, (ifx_err = ifx_error(link)));
- }
}
}
- else if (SQLCODE < 0) {
- IFXG(sv_sqlcode) = SQLCODE;
- php_error_docref(NULL TSRMLS_CC, E_WARNING, "Disconnect
link %s
fails (%s)", link, (ifx_err = ifx_error(link)));
- }
- }
- else {
- IFXG(sv_sqlcode) = SQLCODE;
- php_error_docref(NULL TSRMLS_CC, E_WARNING, "Set connection %s
fails
(%s)", link, (ifx_err = ifx_error(link)));
- }
-
- if (ifx_err) {
- efree(ifx_err);
}
}
--
Edit this bug report at http://bugs.php.net/?id=28883&edit=1
#32954 [Asn->WFx]: ifx_fetch_row() : SEGV if row has TEXT fields (PHP Apache Module only)
ID: 32954
Updated by: [EMAIL PROTECTED]
Reported By: andreybl at matrix dot co dot il
-Status: Assigned
+Status: Wont fix
Bug Type: Informix related
Operating System: Red Hat 3.0 ES
PHP Version: 5CVS, 4CVS, 6CVS (2005-09-04)
Assigned To: nobbie
New Comment:
There was no feedback from Corne. This means the extension is
practically abandoned. However, since IBM nowadays owns informix, you
could ask for their support to fix this.
Previous Comments:
[2005-09-23 15:35:46] [EMAIL PROTECTED]
Assigned to the maintainer. Cornelius, if you get this mail, please
reply via email to me if you're actually maintaining this extension
anymore. (to [EMAIL PROTECTED])
[2005-05-05 12:29:55] andreybl at matrix dot co dot il
Description:
Apache version: 1.3.33
Informix server version: IDS 9.40.UC5
Informix SDK version: csdk_informix.2.90
'./configure' '--with-informix=/isoc/informix'
'--with-config-file-path=/isoc/apache/conf' '--enable-track-vars'
'--with-apache=/isoc/sources/apache' '--without-mysql'
NOTE:
The problem occurs in PHP Apache Module ONLY and NOT occurs in PHP
CGI.
Description:
Segmentation Fault in httpd when call to the
ifx_fetch_row() while among the fields to be selected there is a field
of type TEXT containing NON-NULL data:
- In httpd log file (./apache/logs/error_log):
[Thu May 5 12:02:10 2005] [notice] child pid 20754 exit signal
Segmentation fault (11)
- In browser:
"The page cannot be displayed"
Seems my BUG is simillar to #8715, which was closed since there was No
feedback. So probably the problem in #8715 still persists too.
Please, take care of this report as soon as possible, since it is of
Critical severity for me. Actually this stops the whole project.
Thanks,
Andrey
Reproduce code:
---
$trace = fopen('/tmp/php_bug.txt', 'w+');
$conn_id = ifx_connect('DB', 'USER', 'PASS');
if (!$conn_id)
{
echo "FAILED TO CONNECT"; die();
}
fwrite($trace, "after ifx_connect\n"); fflush($trace);
$res_id = ifx_query('SELECT * FROM registrars where regid = 5',
$conn_id);
if (!$res_id)
{
echo "FAILED TO PREPARE"; echo ifx_getsqlca(); die();
}
fwrite($trace, "after ifx_query\n"); fflush($trace);
$row = ifx_fetch_row($res_id);
fwrite($trace, "after ifx_fetch_row: regid = {$row['regid']}\n");
fflush($trace);
ifx_free_result($res_id);
fwrite($trace, "after ifx_free_result\n"); fflush($trace);
ifx_close($conn_id);
fwrite($trace, "after ifx_close\n"); fflush($trace);
Expected result:
Hm. I expect the httpd not to crash.
Actual result:
--
Here is the backtrace:
Program received signal SIGSEGV, Segmentation fault.
0xb7359e6f in _int_free () from /lib/tls/libc.so.6
(gdb) bt
#0 0xb7359e6f in _int_free () from /lib/tls/libc.so.6
#1 0xb7358e68 in free () from /lib/tls/libc.so.6
#2 0xb7583c3c in ifx_free_sqldata () from
/isoc/informix/lib/esql/libifsql.so
#3 0xb7583a80 in sqli_desc_dealloc () from
/isoc/informix/lib/esql/libifsql.so
#4 0x080b4a14 in zif_ifx_free_result ()
#5 0x080abca6 in execute ()
#6 0x0809fa5b in zend_execute_scripts ()
#7 0x0808193b in php_execute_script ()
#8 0x080aee8e in apache_php_module_main ()
#9 0x0807a772 in ap_get_server_built ()
#10 0x0807a7dc in ap_get_server_built ()
#11 0x0812e6d3 in ap_invoke_handler ()
#12 0x0814356f in ap_some_auth_required ()
#13 0x081435ce in ap_process_request ()
#14 0x0813a731 in ap_child_terminate ()
#15 0x0813a8d1 in ap_child_terminate ()
#16 0x0813aa37 in ap_child_terminate ()
#17 0x0813b0ee in ap_child_terminate ()
#18 0x0813b90c in main ()
(gdb) qui
In the test program above I fetch only one row. If the TEXT field in
the row has NULL value everything's OK and the output in the
php_bug.txt file (see the programm) is the following:
after ifx_connect
after ifx_query
after ifx_fetch_row: regid = 3
after ifx_free_result
after ifx_close
i.e. all the functions returned ok.
If the TEXT field in the row has non-NULL data, then the SEGV occurs
and the output in the php_bug.txt test file is:
after ifx_connect
after ifx_query
after ifx_fetch_row: regid = 11
i.e. ifx_free_result did not return.
NOTE: if the TEXT-type field is not in the list of the filds to be
selected, then everything is OK.
--
Edit this bug report at http://bugs.php.net/?id=32954&edit=1
#26608 [Asn->WFx]: Sporadic -439 errors on ifx_connect()
ID: 26608 Updated by: [EMAIL PROTECTED] Reported By: gemery at bmihs dot co dot uk -Status: Assigned +Status: Wont fix Bug Type: Informix related Operating System: RedHat Linux 8 PHP Version: 5.*, 4.* Assigned To: nobbie New Comment: The ext/informix is no longer supported. Since the IBM now owns informix, you need to use http://pecl.php.net/pdo_informix and post any bugs of it there. Previous Comments: [2004-09-30 20:06:50] swinny23 at hotmail dot com I had experienced the same thorn in my side for well over a year, and we just dealt with it by rebooting Apache every once in a while, but I think we have finally fixed the issue. We switched to Apache 2 on Suse with PHP and all our 439 issues have went away. So if you are using Apache 1.3 try changing to Apache 2 if you can. [2004-04-15 20:29:00] gemery at bmihs dot co dot uk OK... Some new information: I got in contact with Cornelius, the maintainer of the ifx code. He came up with the following (which is a work in progress): -439 error:Description:Each Apache Thread can only have 1 active connection to an informix database, after a -439 occurance. o ifx_close() doesn't close the database connection, possibly leaving it available for other requests - Fixed in PHP-4.3.4 (after RC1) o ifx_close() can't close connections which produced -439 errors - Looks like a bug (or feature) in the ESQL/C or IDS Engine, or incorrect thread usageReproduce bug:o in httpd.conf, set MaxRequestsPerChild to 1o access a php script which runs a massive queryo you'll keep getting -439 errors ===TEMPORARY FIX===Because the -439 error causes problems for Apache/PHP to reconnect in each thread, the thread should be closed often to kill the conection which is the problem.This doesn't prevent the problem, but makes it occur less, and not affect as many users when it does.In httpd.conf: o Set MaxRequestsPerChild to a low number (approx: the minimum number of possible connections in a request to your site, maybe times 3) o Set MaxKeepAliveRequests to a low number (see above)---===HACKING INFO===Things to check: o if ifx_close closes connection when -439 is encountered:- NOo why -439 is encountered on new connection attempt, in same apache thread after first -439:- Possible Runaway process - incorrect thread usage o if -439 is encountered immediately from same apache thread, different request, if first request has -439 set:- YESThings to try: o ESQL/C thread safe stuff - Didn't work for me o check error -451, from the release docsfrom /opt/informix/release/en_us/0333/ESQLCREL_9.1:92103 With arrary fetch enabled frontend doesn't recover from-451 error but returns -439 error for all subsequentoperations - Doubtedly, becuase the tests failed without blobs in sight I have also upgraded our apache server to version 2 (2.0.49) and this seems to have made the problem go away entirely (possibly because it handles threading in a proper way - which seems to be the root cause of the 439 issue). Hope this helps. Some more news from the php devs would be appreciated though :) [2003-12-17 09:57:25] gemery at bmihs dot co dot uk OK.. Having the installed the new sdk and the snapshot (as suggested), the system ran fine for two days. On the third day, these three errors occurred: [error] PHP Warning: ifx_query(): Set connection connec83 fails (E [SQLSTATE=IX 000 SQLCODE=-439]) in /var/www/html/casetrack/searchresult.php on line 0 [error] PHP Warning: ifx_query(): Set connection connec80 fails (E [SQLSTATE=IX 000 SQLCODE=-439]) in /var/www/html/casetrack/searchresult.php on line 0 [error] PHP Warning: ifx_query(): Set connection connec1 fails (E [SQLSTATE=IX 000 SQLCODE=-439]) in /var/www/html/casetrack/searchresult.php on line 0 After this, any attempt to use ifx_connect() resulted in this error: [error] PHP Warning: ifx_connect(): E [SQLSTATE=IX 000 SQLCODE=-439] in /var/www/html/casetrack/login.php on line 60 A restart of apache seemed to resolve the issue temporarily, but the problem recurs after a (random) amount of time. Any help/suggestions would be appreciated as the new sdk doesn't seem to solve the issue. [2003-12-14 20:37:12] [EMAIL PROTECTED] According to bug #14254, the newer informix sdk should fix this. [2003-12-12 12:55:12] geme
#35765 [Opn->Bgs]: fopen wrapper using invalid SIZE command
ID: 35765
Updated by: [EMAIL PROTECTED]
Reported By: jasonandtonya at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: FTP related
Operating System: *
PHP Version: 5CVS-2005-12-21 (snap)
New Comment:
"Is there a reason that you are using a non-standard command SIZE for
verifying existance of the file?"
There propably is and this has worked fine since PHP 4.
Get a working FTP server.
Previous Comments:
[2005-12-21 18:28:40] jasonandtonya at gmail dot com
Description:
when opening a file via ftp as an array
$logfile=fopen('ftp://example.com/filename.ext',"r");
it returns an error:
500 'SIZE filename.ext': command not understood and example.com is
running a Solaris default ftp daemon.
Looking at the latest version 5.1-latest, (I'm assuming that it is
using ftp_fopen_wrapper.c):
ftp_fopen_wrapper.c,v 1.85.2.2 2005/11/22 03:01:39
line 450:
/* find out the size of the file (verifying it exists) */
php_stream_printf(stream TSRMLS_CC, "SIZE %s\r\n",
resource->path);
Is there a reason that you are using a non-standard command SIZE for
verifying existance of the file?
Reproduce code:
---
$file=fopen('ftp://example.com/filename.ext',"r");
Expected result:
No error message when doing fopen
Actual result:
--
Warning: fopen('ftp://example.com/filename.ext') [function.fopen]:
failed to open stream: FTP server reports 500 'SIZE filename.ext':
command not understood. in /patrh/to/htdocs/filename.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=35765&edit=1
#31774 [Opn->Fbk]: Data missing using DirectoryIterator with ftp:// wrapper
ID: 31774
Updated by: [EMAIL PROTECTED]
Reported By: php at lachoseinteractive dot net
-Status: Open
+Status: Feedback
Bug Type: FTP related
-Operating System: Linux & Mac OS X
+Operating System: *
PHP Version: 5CVS-2005-03-20
Assigned To: pollita
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Previous Comments:
[2005-01-31 12:41:10] php at lachoseinteractive dot net
After more investigation, it turns out that the iterator
reconnects to the server several times for each file of
list in order to get SIZE information, etc instead of
parsing a raw list from an FTP LIST command.
Looks like DirectoryIterator needs optimization for use
with ftp wrapper.
[2005-01-31 02:32:17] php at lachoseinteractive dot net
Description:
Reading a directory with a DirectoryIterator using an
ftp wrapper doesn't work well.
Tested on 3 ftp servers. (proftp, ncftp, and ..unknown
:-/). on 3 different machines and network.
With proftp and ncftp, some items are missing from the
retrieved directory list. (whereas it works well with
readdir()), even with a directory containing no more
than 2 or 3 files. This doesn't seem to be related to
the nature of the file, but rather to its position in
the list : add a new file to the directory, and the
previously missing file would show up, while another one
is now missing.
On the third server (ftpperso.free.fr), the directory
was correctly read.
In all cases, retrieving the list is very slow, and
often fails.
Reproduce code:
---
example:
$dir = new DirectoryIterator("ftp://myftpserver.com/";);
foreach ( $dir as $f ) {
if ( $f->isDot() ) continue;
echo $f->getFilename()."\n";
}
--
Edit this bug report at http://bugs.php.net/?id=31774&edit=1
#31774 [Asn->Opn]: Data missing using DirectoryIterator with ftp:// wrapper
ID: 31774
Updated by: [EMAIL PROTECTED]
Reported By: php at lachoseinteractive dot net
-Status: Assigned
+Status: Open
Bug Type: FTP related
Operating System: Linux & Mac OS X
PHP Version: 5CVS-2005-03-20
Assigned To: pollita
Previous Comments:
[2005-01-31 12:41:10] php at lachoseinteractive dot net
After more investigation, it turns out that the iterator
reconnects to the server several times for each file of
list in order to get SIZE information, etc instead of
parsing a raw list from an FTP LIST command.
Looks like DirectoryIterator needs optimization for use
with ftp wrapper.
[2005-01-31 02:32:17] php at lachoseinteractive dot net
Description:
Reading a directory with a DirectoryIterator using an
ftp wrapper doesn't work well.
Tested on 3 ftp servers. (proftp, ncftp, and ..unknown
:-/). on 3 different machines and network.
With proftp and ncftp, some items are missing from the
retrieved directory list. (whereas it works well with
readdir()), even with a directory containing no more
than 2 or 3 files. This doesn't seem to be related to
the nature of the file, but rather to its position in
the list : add a new file to the directory, and the
previously missing file would show up, while another one
is now missing.
On the third server (ftpperso.free.fr), the directory
was correctly read.
In all cases, retrieving the list is very slow, and
often fails.
Reproduce code:
---
example:
$dir = new DirectoryIterator("ftp://myftpserver.com/";);
foreach ( $dir as $f ) {
if ( $f->isDot() ) continue;
echo $f->getFilename()."\n";
}
--
Edit this bug report at http://bugs.php.net/?id=31774&edit=1
#35732 [Opn->Fbk]: Access violation on file open
ID: 35732 Updated by: [EMAIL PROTECTED] Reported By: rene at lico dot nl -Status: Open +Status: Feedback Bug Type: IIS related Operating System: Windows 2003 PHP Version: 5CVS-2005-12-20 (snap) New Comment: Can you reproduce this using some other web server, like Apache? Previous Comments: [2005-12-21 17:39:35] rene at lico dot nl No, the localhost could also be replaced with something else like an asp scripts (what it is used for in my case) [2005-12-21 16:20:21] [EMAIL PROTECTED] If you have this: http://localhost";); ?> Is the content of this file in same file which is outputted? [2005-12-21 16:12:51] rene at lico dot nl I would try the develpack if i had MSVC6, but i don't. What to do? Is there a seperate download to only have the debug functions? I will try to make a seperate script that raises the problem... [2005-12-21 15:19:42] [EMAIL PROTECTED] Well, if you have some debugging tools installed, this link http://bugs.php.net/bugs-generating-backtrace-win32.php should be useful. [2005-12-21 14:53:46] rene at lico dot nl Tried the win32-latest and still the same error. It seems to work for a while before 1 requests took a long time and finally did nothing. Php stil works for pages that don't access a file the way the example does. Any suggestions for debugging? 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/35732 -- Edit this bug report at http://bugs.php.net/?id=35732&edit=1
#35612 [Opn->Asn]: [PATCH] iis6 Access Violation crash
ID: 35612
Updated by: [EMAIL PROTECTED]
Reported By: alacn dot uhahaa at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: IIS related
Operating System: Windows Server 2003
PHP Version: 5CVS-2005-12-20 (snap)
Assigned To: dmitry
Previous Comments:
[2005-12-21 19:08:29] alacn dot uhahaa at gmail dot com
ok, i have tested it on iis5 (windows xp) and iis6 (windows 2003), both
is configured to use the extension php5isapi.dll.
we use WaitForSingleObject to wait the thread finish:
- it will return WAIT_OBJECT_0 when the thread finish,
- or return WAIT_TIMEOUT if the thread didnt finish before the time
elapse
the thing is, it should result WAIT_OBJECT_0 meaning that the thread
was ended fine.
lets debug it, set WITH_ALACN_PATCH to 0 to use current code; or set it
to 1 to use fixed code
"everyone" user need have full access on the "c:\temp\" otherwise it
can fail create the file.
on the file c:\temp\php_debug.log:
-- means its fine
WaitForSingleObject:
it returned WAIT_OBJECT_0! thread was ended.
-- means that we didnt wait the thread finish
WaitForSingleObject:
it returned WAIT_TIMEOUT! thread may still running!.
-- deadlocked after WaitForSingleObject, process killed!
WaitForSingleObject:
--- php5.1-200512211530_zend_execute_API.c Tue Dec 20 09:30:10 2005
+++ php5.1-200512211530_debug_zend_execute_API.cWed Dec 21 15:52:46
2005
@@ -1256,6 +1256,26 @@
}
+void save_debug_msg(char *sz)
+{
+ HANDLE h;
+ int i;
+ DWORD dwRW;
+
+ h = CreateFile("c:\\temp\\php_debug.log", GENERIC_READ |
GENERIC_WRITE, FILE_SHARE_READ, 0, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL,
0);
+ if(h == INVALID_HANDLE_VALUE) return;
+
+ SetFilePointer(h, 0, 0, 2);
+
+ i = strlen(sz);
+ WriteFile(h, sz, i, &dwRW, 0);
+
+ CloseHandle(h);
+}
+
+// change this!!
+#define WITH_ALACN_PATCH 1
+
static unsigned __stdcall timeout_thread_proc(void *pArgs)
{
@@ -1284,6 +1304,9 @@
}
DestroyWindow(timeout_window);
UnregisterClass(wc.lpszClassName, NULL);
+#if WITH_ALACN_PATCH
+ SetEvent(timeout_thread_handle);
+#endif
return 0;
}
@@ -1291,20 +1314,42 @@
void zend_init_timeout_thread()
{
timeout_thread_event = CreateEvent(NULL, FALSE, FALSE, NULL);
+#if WITH_ALACN_PATCH
+ timeout_thread_handle = CreateEvent(0, 0, 0, 0);
+ _beginthreadex(NULL, 0, timeout_thread_proc, NULL, 0,
&timeout_thread_id);
+#else
timeout_thread_handle = _beginthreadex(NULL, 0, timeout_thread_proc,
NULL, 0, &timeout_thread_id);
+#endif
WaitForSingleObject(timeout_thread_event, INFINITE);
}
void zend_shutdown_timeout_thread()
{
+ DWORD dw;
+
if (!timeout_thread_initialized) {
return;
}
PostThreadMessage(timeout_thread_id, WM_QUIT, 0, 0);
+ save_debug_msg("WaitForSingleObject:\r\n");
+
/* Wait for thread termination */
- WaitForSingleObject(timeout_thread_handle, 5000);
+ dw = WaitForSingleObject(timeout_thread_handle, INFINITE);
+ switch(dw)
+ {
+ case WAIT_OBJECT_0:
+ save_debug_msg("it returned WAIT_OBJECT_0! thread was
ended.\r\n");
+ break;
+ case WAIT_TIMEOUT:
+ save_debug_msg("it returned WAIT_TIMEOUT! thread may still
running!.\r\n");
+ break;
+ default:
+ save_debug_msg("unknow return.\n");
+ break;
+ }
+
CloseHandle(timeout_thread_handle);
}
[2005-12-21 11:09:24] [EMAIL PROTECTED]
alacn, could you please explain why WaitForSingleObject() may not work
on thread handle? (it works fine for me).
Is it IIS6 specific behavior?
Also I didn't understand, why you need 30 sec timeout?
The tmeout thread is event based and it never locks. It should quit
right after it gets WM_QUIT.
[2005-12-21 08:11:27] vaguener at hotmail dot com
thats right,
when i set the wait time to INFINITE in the current code
"WaitForSingleObject(timeout_thread_handle, INFINITE);"
it never close the worker process.
but on alacn's code it do.
"WaitForSingleObject(timeout_thread_finish, INFINITE);"
[2005-12-20 12:38:23] alacn dot uhahaa at gmail dot com
ok.. here is udiff for latest cvs (php5.1)
what is happenning is that since the thread that created the timeout
thread have different access levels than the one that will wait it
finish, waitforsingleobject on timeout thread handle wont work right,
it will always timeout, and access violation will occur
expected: it should return before the timeout, that way wont occur
access violation
the fix: it should wait at least 30
#35765 [Opn->Fbk]: fopen wrapper using invalid SIZE command
ID: 35765
Updated by: [EMAIL PROTECTED]
Reported By: jasonandtonya at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: FTP related
Operating System: ALL
PHP Version: 5.1.1
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Previous Comments:
[2005-12-21 18:28:40] jasonandtonya at gmail dot com
Description:
when opening a file via ftp as an array
$logfile=fopen('ftp://example.com/filename.ext',"r");
it returns an error:
500 'SIZE filename.ext': command not understood and example.com is
running a Solaris default ftp daemon.
Looking at the latest version 5.1-latest, (I'm assuming that it is
using ftp_fopen_wrapper.c):
ftp_fopen_wrapper.c,v 1.85.2.2 2005/11/22 03:01:39
line 450:
/* find out the size of the file (verifying it exists) */
php_stream_printf(stream TSRMLS_CC, "SIZE %s\r\n",
resource->path);
Is there a reason that you are using a non-standard command SIZE for
verifying existance of the file?
Reproduce code:
---
$file=fopen('ftp://example.com/filename.ext',"r");
Expected result:
No error message when doing fopen
Actual result:
--
Warning: fopen('ftp://example.com/filename.ext') [function.fopen]:
failed to open stream: FTP server reports 500 'SIZE filename.ext':
command not understood. in /patrh/to/htdocs/filename.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=35765&edit=1
#35732 [Opn->Fbk]: Access violation on file open
ID: 35732 Updated by: [EMAIL PROTECTED] Reported By: rene at lico dot nl -Status: Open +Status: Feedback Bug Type: IIS related Operating System: Windows 2003 PHP Version: 5CVS-2005-12-20 (snap) New Comment: If you have this: http://localhost";); ?> Is the content of this file in same file which is outputted? Previous Comments: [2005-12-21 16:12:51] rene at lico dot nl I would try the develpack if i had MSVC6, but i don't. What to do? Is there a seperate download to only have the debug functions? I will try to make a seperate script that raises the problem... [2005-12-21 15:19:42] [EMAIL PROTECTED] Well, if you have some debugging tools installed, this link http://bugs.php.net/bugs-generating-backtrace-win32.php should be useful. [2005-12-21 15:19:27] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2005-12-21 14:53:46] rene at lico dot nl Tried the win32-latest and still the same error. It seems to work for a while before 1 requests took a long time and finally did nothing. Php stil works for pages that don't access a file the way the example does. Any suggestions for debugging? [2005-12-19 14:01:59] [EMAIL PROTECTED] Yes. It's worth trying the latest version before starting to debug something. 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/35732 -- Edit this bug report at http://bugs.php.net/?id=35732&edit=1
#35732 [Opn->Fbk]: Access violation on file open
ID: 35732 Updated by: [EMAIL PROTECTED] Reported By: rene at lico dot nl -Status: Open +Status: Feedback Bug Type: IIS related Operating System: Windows 2003 PHP Version: 5CVS-2005-12-21 (snap) New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Previous Comments: [2005-12-21 14:53:46] rene at lico dot nl Tried the win32-latest and still the same error. It seems to work for a while before 1 requests took a long time and finally did nothing. Php stil works for pages that don't access a file the way the example does. Any suggestions for debugging? [2005-12-19 14:01:59] [EMAIL PROTECTED] Yes. It's worth trying the latest version before starting to debug something. [2005-12-19 13:44:53] rene at lico dot nl Is this the only way? I would rather use a debug method since the server is heavily used... [2005-12-19 13:11:00] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-12-19 13:04:33] rene at lico dot nl Description: Using PHP as ISAPI module results in getting "PHP has encountered an Access Violation at ...". The cause of this access violation is quite unknown to me and I have no idea how to debug this error. What I have found is that it _could_ happen on a file_get_contents or a fopen using the http wrapper. But again: i'm not sure. First of all: please help me in tracing down this problem. Reproduce code: --- http://localhost";); ?> Expected result: not the actual result :) Actual result: -- PHP has encountered an Access Violation at 010E2ED6 -- Edit this bug report at http://bugs.php.net/?id=35732&edit=1
#35759 [Opn->Asn]: mysqli_stmt_bind_result() makes huge allocation when column empty
ID: 35759
Updated by: [EMAIL PROTECTED]
Reported By: squasar at eternalviper dot net
-Status: Open
+Status: Assigned
Bug Type: MySQLi related
Operating System: *
PHP Version: 5.1.1
-Assigned To:
+Assigned To: georg
New Comment:
This sounds more like documentation issue than a real bug, but I let
Georg decide.
Previous Comments:
[2005-12-21 07:41:55] squasar at eternalviper dot net
Description:
If a MEDIUMBLOB column has an empty value (length of zero),
mysqli_stmt_bind_result() attempts to allocate a buffer of 16M
for it. The offending code is in mysqli_api.c, line 332:
if (stmt->stmt->fields[ofs].max_length == 0) {
This will be true if the column is empty as well as in the
case where the user has not called store_result(). The result
is the code using the value of length instead of max_length,
which is 16M for a mediumblob.
Reproduce code:
---
Assume there exists a table:
CREATE TABLE a_table ( some_blob MEDIUMBLOB NOT NULL );
execute();
$s->store_result();
print_r( $s->result_metadata()->fetch_fields() );
$s->bind_result( $data );
$s->fetch();
print_r( $data );
?>
Expected result:
Array
(
[0] => stdClass Object
(
[name] => some_blob
[orgname] => some_blob
[table] => a_table
[orgtable] => a_table
[def] =>
[max_length] => 0
[length] => 0
[charsetnr] => 63
[flags] => 144
[type] => 252
[decimals] => 0
)
)
Actual result:
--
Array
(
[0] => stdClass Object
(
[name] => some_blob
[orgname] => some_blob
[table] => a_table
[orgtable] => a_table
[def] =>
[max_length] => 0
[length] => 16777215
[charsetnr] => 63
[flags] => 144
[type] => 252
[decimals] => 0
)
)
Fatal error: Allowed memory size of 8388608 bytes exhausted
(tried to allocate 16777216 bytes) in test.php on line 8
--
Edit this bug report at http://bugs.php.net/?id=35759&edit=1
#35758 [Opn->Fbk]: SoapClient::__construct() [function.--construct]: SSL: fatal protocol error
ID: 35758
Updated by: [EMAIL PROTECTED]
Reported By: kurzhumov at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: SOAP related
Operating System: Red Hat Enterprise Linux ES
PHP Version: 5CVS-2005-12-21 (snap)
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Previous Comments:
[2005-12-21 07:33:46] kurzhumov at gmail dot com
Description:
The SOAP extension fails to connect to Web-service on Microsoft Windows
Server 2003 over SSL.
Warning: SoapClient::__construct(): SSL: fatal protocol error in
test.php on line 7
Client: Red Hat Enterprise Linux ES
Server: IIS 6 on Microsoft Windows Server 2003
Reproduce code:
---
https://example.com/WebServices/Test.asmx?WSDL');
var_dump($client);
?>
Actual result:
--
Warning: SoapClient::__construct(): SSL: fatal protocol error in
test.php on line 7
object(SoapClient)#1 (2) {
["_soap_version"]=>
int(1)
["sdl"]=>
resource(5) of type (Unknown)
}
PHP Warning: SoapClient::__construct(): SSL: fatal protocol error in
test.php on line 7
--
Edit this bug report at http://bugs.php.net/?id=35758&edit=1
#35754 [Opn->Bgs]: Apache doesn't render PHP script (Blank page results)
ID: 35754 Updated by: [EMAIL PROTECTED] Reported By: ronjawanda at yahoo dot ca -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: XP SP2 PHP Version: 5.1.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: [2005-12-21 04:34:49] judas dot iscariote at gmail dot com **not** a PHP Bug, you should reinstall PHP, something went wrong in your upgrade. [2005-12-21 02:20:06] ronjawanda at yahoo dot ca Description: I have apache 2.0.55 with PHP 5.0.5 PHP works fine. I use a simple scripts When I installed 5.1.1 my pages are blank and the view source shows the script. ie: Apache isn't recognising the PHP libraries. I have the same settings with 5.0.5 as I did with 5.1.1 I then reviewed all the docs and found that I could possibly add a registry setting to point to c:/php/ This didn't work. I forget the registry setting but it is on the documentation page. I'm on win xp SP2. Ron -- Edit this bug report at http://bugs.php.net/?id=35754&edit=1
#35751 [Opn->Fbk]: using date with a timestamp makes httpd segfault
ID: 35751
Updated by: [EMAIL PROTECTED]
Reported By: lehmann at ans-netz dot de
-Status: Open
+Status: Feedback
Bug Type: Date/time related
Operating System: FreeBSD 6.0/alpha
PHP Version: 5.1.1
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Previous Comments:
[2005-12-20 20:53:59] lehmann at ans-netz dot de
here is the backtrace:
(gdb) bt
#0 0x0001200297c8 in php_format_date (format=0x120132fd8 "\036",
format_len=540212224, ts=1, localtime=46)
at
/usr/obj/alpha-ev56-6.0/usr/ports/lang/php5/work/php-5.1.1/ext/date/php_date.c:467
#1 0x in ?? ()
Previous frame identical to this frame (corrupt stack?)
(gdb) up 0
#0 0x0001200297c8 in php_format_date (format=0x120132fd8 "\036",
format_len=540212224, ts=1, localtime=46)
at
/usr/obj/alpha-ev56-6.0/usr/ports/lang/php5/work/php-5.1.1/ext/date/php_date.c:467
467 switch (format[i]) {
(gdb) list
462 }
463 buffer[32] = '\0';
464 timelib_isoweek_from_date(t->y, t->m, t->d, &isoweek,
&isoyear);
465
466 for (i = 0; i < format_len; i++) {
467 switch (format[i]) {
468 /* day */
469 case 'd': snprintf(buffer, 32, "%02d",
(int) t->d); break;
470 case 'D': snprintf(buffer, 32, "%s",
day_short_names[timelib_day_of_week(t->y, t->m, t->d)]); break;
471 case 'j': snprintf(buffer, 32, "%d",
(int) t->d); break;
(gdb)
[2005-12-20 20:33:57] [EMAIL PROTECTED]
Instead of running it through your webserver, try the command line...
(with GDB too).
[2005-12-20 20:25:19] lehmann at ans-netz dot de
I'm not able to get a working backtrace, i compiled php with
--enable-debug during configure:
[EMAIL PROTECTED] php-5.1.1> gdb /usr/local/sbin/httpd /tmp/httpd.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "alpha-marcel-freebsd"...(no debugging
symbols found)...
Core was generated by `httpd'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libz.so.3...(no debugging symbols
found)...done.
Loaded symbols for /lib/libz.so.3
Reading symbols from /usr/lib/libssl.so.4...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/libssl.so.4
[...]
Loaded symbols for /usr/local/libexec/apache2/libphp5.so
Reading symbols from /usr/local/lib/libxml2.so.5...done.
Loaded symbols for /usr/local/lib/libxml2.so.5
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 0x000160953668 in ?? () from
/usr/local/libexec/apache2/libphp5.so
(gdb) bt
#0 0x000160953668 in ?? () from
/usr/local/libexec/apache2/libphp5.so
#1 0x0002 in ?? ()
Cannot access memory at address 0xfffe
(gdb)
[2005-12-20 19:11:13] lehmann at ans-netz dot de
Description:
Using date() in combination with a timestamp makes my httpd segfault on
FreeBSD 5.0/alpha - it worked with PHP 5.0.5 like a charm.
Using just date() with a format string, but w/o a timestamp works w/o
problems.
Reproduce code:
---
Expected result:
it should work?
Actual result:
--
[EMAIL PROTECTED] php5> ktrace httpd -X
pid 30132 (httpd): unaligned access: va=0x11ffc72c pc=0x160a59720
ra=0x160a59e44 op=stq
Segmentation fault
Exit 139
[EMAIL PROTECTED] php5>
last part of the ktrace:
27732 httpdRET read 487/0x1e7
27732 httpdCALL stat(0x1605da495,0x11ffe658)
27732 httpdNAMI "/etc/nsswitch.conf"
27732 httpdRET stat 0
27732 httpdCALL stat(0x1605da495,0x11ffe658)
27732 httpdEvents dropped.
27732 httpdRET stat 0
27732 httpdEvents dropped.
27732 httpdCALL open(0x1202e43c0,0,0x1b6)
27732 httpdEvents dropped.
27732 httpdRET lstat 0
27732 httpdEvents dropped.
27732 httpdRET open 23/0x17
27732 httpdEvents dropped.
27732 httpdRET open 23/0x17
27732 httpdEvents dropped.
27732 httpdRET stat 0
27732 httpdEvents dropped.
27732 httpdRET lstat 0
27732 httpdEvents dropped.
27732 httpdRET lstat 0
27732 httpdEvents dropped.
27732 httpdRET lstat 0
27
#35748 [Opn->Fbk]: is_dir function always returns false on FreeBSD.
ID: 35748 Updated by: [EMAIL PROTECTED] Reported By: hml at uraroji dot com -Status: Open +Status: Feedback Bug Type: Directory function related Operating System: FreeBSD 4.11 PHP Version: 4.4.1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2005-12-20 17:35:04] hml at uraroji dot com Description: php 4.4.1 is_dir() function always returns false on FreeBSD. php 4.4.0 was working normally. Reproduce code: --- Expected result: dir / dir ./ dir ../ dir /usr Actual result: -- non dir / non dir ./ non dir ../ non dir /usr -- Edit this bug report at http://bugs.php.net/?id=35748&edit=1
#32361 [Opn->Asn]: connection oci_connect stay persist after process the php
ID: 32361 Updated by: [EMAIL PROTECTED] Reported By: diego dot veiga at embraer dot com dot br -Status: Open +Status: Assigned Bug Type: OCI8 related Operating System: Fedora3 PHP Version: 5CVS, 4CVS (2005-03-22) Assigned To: tony2001 New Comment: tony2001: Still not fixed..? Previous Comments: [2005-12-20 16:14:27] diego dot veiga at embraer dot com dot br Hi, I just installed the latest cvs snapshot and executed the query but the connection continues persistent. regards [2005-12-20 14:04:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-09-08 11:46:32] [EMAIL PROTECTED] The bug has been fixed in OCI8 v.1.1, which is available in CVS HEAD and PECL (use `pear install oci8-beta` to install it). [2005-06-17 16:09:38] emiliano dot ticci at dada dot net While waiting for an official fix I solved by commenting and decommenting some lines. This is my diff file for oci8.c (Php 5.0.4): 1103c1103 < #if 0 --- > /* #if 0 commented to avoid connection stay persist */ 1109c1109 < #endif --- > /* #endif */ 3204a3205 > /* Prevents a recursive call to this function (?) 3207a3209 > */ I don't know if this could be a good solution, however it seems to work perfectly... Sorry for my poor english. [2005-03-21 17:45:27] diego dot veiga at embraer dot com dot br I upgraded the php to 5.0.3 and reproduce the same error, it seems the oci_connect is working like the oci_pconnect. Does anybody has an idea? 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/32361 -- Edit this bug report at http://bugs.php.net/?id=32361&edit=1
#35388 [Opn->Fbk]: crash on new object when passed incorrect access details
ID: 35388 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: MySQLi related Operating System: Windows XP Home SP2 PHP Version: 5CVS-2005-12-20 (snap) Assigned To: georg New Comment: Make sure you don't have multiple libmysql.dll's around in your system. Previous Comments: [2005-12-20 15:41:13] [EMAIL PROTECTED] Problem still exists after trying latest snapshot. [2005-12-19 13:41:09] jhala at uoregon dot edu update on that. i made my instance of this problem go away and php/phpmyadmin worked fine by simply making sure that i copied libmysql.dll from the php main directory (where the phpinstall program put it automagically) to the extensions directory (which I had added to windows PATH). restarted apache, problem gone. hope this helps. [2005-11-28 23:18:31] [EMAIL PROTECTED] Looks like there is a binary incompatibility in protocol when connecting from 4.1 client to 5.0.16. I was able to reproduce the problem under linux too. As a possible workaround you should compile PHP against 5.0.16 client lib. [2005-11-25 12:15:02] [EMAIL PROTECTED] Description: If you create a new mysqli object using incorrect login details, Apache crashes. Version info output from mysql_* and mysqli_* functions: mysql Client Encoding: latin1 Client Version: 5.0.16 Protocol Version: 10 Server Version: 5.0.16-nt mysqli Client Encoding: latin1 Client Version: 4.1.7 Protocol Version: 10 Server Version: 5.0.16-nt Reproduce code: --- Ensure username and/or password are incorrect: Expected result: Incorrect login details error Actual result: -- Apache crashes. Windows error reporting shows: szAppName : Apache.exe szAppVer : 2.0.55.0 szModName : php5ts.dll szModVer : 5.1.0.0 offset : 8be4 -- Edit this bug report at http://bugs.php.net/?id=35388&edit=1
#35711 [Ana->WFx]: [PATCH] ISO-8859 charset not correctly detected
ID: 35711
Updated by: [EMAIL PROTECTED]
Reported By: matteo at beccati dot com
-Status: Analyzed
+Status: Wont fix
Bug Type: mbstring related
Operating System: Debian GNU/Linux
PHP Version: 5.1.1
Assigned To: hirokawa
Previous Comments:
[2005-12-20 15:44:31] [EMAIL PROTECTED]
Please note that encoding detection is not always perfect.
Especially, when the string is too short, the wrong detection might be
caused.
In your case, it is not a bug, but it is the specification.
UTF-8 is a variable length multibyte encoding format,
the length of a character in UTF-8 is from one to six.
Please look at ext/mbstring/libmbfl/filter/mbfilter_utf8.c:about 249L.
0xe8 is a valid byte sequence as the 1st character of 3 byte code.
We cannot detect 0xe8 is ISO-8859-1 or UTF-8,
because this byte is valid in both encodings.
In this case, the response will be choose
from the order defined by mb_detect_order().
I suggest to use the sufficient length of string
for the reliable encoding detection.
[2005-12-19 09:03:36] [EMAIL PROTECTED]
Rui, can you check this out please?
[2005-12-19 09:00:50] matteo at beccati dot com
Oops, I just realized that I forgot the -u flag :)
Here is the downlaodable patch:
http://beccati.com/download/mbstring-patch-20051219.txt
[2005-12-19 08:48:47] [EMAIL PROTECTED]
Please provide any patches in unified diff format. (like the first
one). And downloadable somewhere.
[2005-12-16 23:50:13] matteo at beccati dot com
I've made a patch which seems to fix the issue. It basicly checks
filter status during judgement. Status seems to be != 0 only when it is
matching a multibyte character. I added anyway a fallback to the old
judgement routine, just in case no matching encoding is found.
Index: ext/mbstring/libmbfl/mbfl/mbfilter.c
===
RCS file: /repository/php-src/ext/mbstring/libmbfl/mbfl/mbfilter.c,v
retrieving revision 1.7.2.1
diff -u -r1.7.2.1 mbfilter.c
--- ext/mbstring/libmbfl/mbfl/mbfilter.c5 Nov 2005 04:49:57
- 1.7.2.1
+++ ext/mbstring/libmbfl/mbfl/mbfilter.c16 Dec 2005 22:46:26
-
@@ -575,12 +575,22 @@
for (i = 0; i < num; i++) {
filter = &flist[i];
- if (!filter->flag) {
+ if (!filter->flag && !filter->status) {
encoding = filter->encoding;
break;
}
}
+ if (!encoding) {
+ for (i = 0; i < num; i++) {
+ filter = &flist[i];
+ if (!filter->flag) {
+ encoding = filter->encoding;
+ break;
+ }
+ }
+ }
+
/* cleanup */
/* dtors should be called in reverse order */
i = num; while (--i >= 0) {
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/35711
--
Edit this bug report at http://bugs.php.net/?id=35711&edit=1
#35744 [Opn->Bgs]: safe_mode error?
ID: 35744
Updated by: [EMAIL PROTECTED]
Reported By: rudenko at id dot com dot ua
-Status: Open
+Status: Bogus
Bug Type: Filesystem function related
Operating System: Fedora Core 3
PHP Version: 5.1.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:
[2005-12-20 15:34:58] rudenko at id dot com dot ua
If I use your script I have same results as yours.
bool(true)
bool(true)
bool(true)
[2005-12-20 15:26:47] [EMAIL PROTECTED]
#php -d safe_mode=1 -r 'var_dump(ini_get("safe_mode"));
var_dump(is_file("/etc/passwd")); var_dump(file_exists("/etc/passwd"));
var_dump(is_readable("/etc/passwd"));'
string(1) "1"
bool(true)
bool(true)
bool(true)
# whoami
root
PHP 5.0.6-dev
PHP 5.1.2-dev
PHP 4.4.2RC2-dev
[2005-12-20 15:14:50] rudenko at id dot com dot ua
I reproduce same bug on FreeBSD 6 server.
1. In your php.ini file you must set safe_mode = On
2. You must start script from shell
[2005-12-20 15:03:26] [EMAIL PROTECTED]
I'm still unable to reproduce it.
[2005-12-20 14:57:56] rudenko at id dot com dot ua
Installing latest snapshot 2005-12-20 11:30 does not solve this problem
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/35744
--
Edit this bug report at http://bugs.php.net/?id=35744&edit=1
#35743 [Opn->Bgs]: link error with static libraries
ID: 35743 Updated by: [EMAIL PROTECTED] Reported By: webtech at get-telecom dot fr -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Solaris 10 PHP Version: 5.1.1 New Comment: This has nothing to do with _PHP_, you need to recompile the libraries you link it with. Previous Comments: [2005-12-20 11:21:13] webtech at get-telecom dot fr Description: Hello, first, I want to say that I've read the two bugs #35465 and #35475 (see at the end of description). When linking with the libmysqlclient static library, libtool is unable to link the libphp5.la object (I've got thousand of lines, but here's a sample) : fclose 0x623 /db/mysql/lib/libz.a(gzio.o) fseek 0xe52 /db/mysql/lib/libz.a(gzio.o) fseek 0xf6f /db/mysql/lib/libz.a(gzio.o) fread 0x39c /db/mysql/lib/libz.a(gzio.o) fread 0x430 /db/mysql/lib/libz.a(gzio.o) fread 0x753 /db/mysql/lib/libz.a(gzio.o) fread 0x892 /db/mysql/lib/libz.a(gzio.o) qsort 0x228 /db/mysql/lib/libmysqlclient.a(my_lib.o) qsort 0x14cb /db/mysql/lib/libmysqlclient.a(ctype-simple.o) fwrite 0x334 /db/mysql/lib/libz.a(gzio.o) fwrite 0xa9d /db/mysql/lib/libz.a(gzio.o) fwrite 0xc4f /db/mysql/lib/libz.a(gzio.o) ftell 0x22c /db/mysql/lib/libz.a(gzio.o) exit0x78 /db/mysql/lib/libmysqlclient.a(my_malloc.o) exit0x9e5 /db/mysql/lib/libmysqlclient.a(client.o) exit0x238 /db/mysql/lib/libmysqlclient.a(default.o) exit0x485 /db/mysql/lib/libmysqlclient.a(default.o) ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I've tried the two "solutions" of the two bugs #35465 and #35475 : - the first one is to passing the option -fpic in CFLAFS variable, but it won't work for me. - and the second was to use the libtool of php 5.0.5, but link failed too : Undefined first referenced symbol in file libiconv_close ext/gd/libgd/gdkanji.lo libiconv_open ext/gd/libgd/gdkanji.lo fdatasync ext/pdo_sqlite/sqlite/src/os_unix.lo (symbol belongs to implicit dependency /lib/librt.so.1) libiconvext/gd/libgd/gdkanji.lo ld: fatal: Symbol referencing errors. No output written to sapi/cli/php I've tried too with the snapshot of php 5.1.2 dev, but it's the same ! What can I do to compile 5.1.1 ? Thanks for your help -- Edit this bug report at http://bugs.php.net/?id=35743&edit=1
#35612 [Opn->Asn]: [PATCH] iis6 Access Violation crash
ID: 35612
Updated by: [EMAIL PROTECTED]
Reported By: alacn dot uhahaa at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: IIS related
Operating System: Windows Server 2003
-PHP Version: 5.1.1
+PHP Version: 5CVS-2005-12-20 (snap)
Assigned To: dmitry
New Comment:
Dmitry, can you check this out please.
Previous Comments:
[2005-12-20 12:38:23] alacn dot uhahaa at gmail dot com
ok.. here is udiff for latest cvs (php5.1)
what is happenning is that since the thread that created the timeout
thread have different access levels than the one that will wait it
finish, waitforsingleobject on timeout thread handle wont work right,
it will always timeout, and access violation will occur
expected: it should return before the timeout, that way wont occur
access violation
the fix: it should wait at least 30 secs, waitforsingleobject will
never elapse all the 30 secs, unless in a bad error,
- it will always return before the 30 secs, as it should -
btw ...cant php4 be fixed too? :(
--- php5.1-200512200930_zend_execute_API.c Fri Dec 16 21:30:06 2005
+++ php5.1-200512200930_fixed_zend_execute_API.cTue Dec 20 08:44:24
2005
@@ -46,7 +46,7 @@
static WNDCLASS wc;
static HWND timeout_window;
static HANDLE timeout_thread_event;
-static HANDLE timeout_thread_handle;
+static HANDLE timeout_thread_finish;
static DWORD timeout_thread_id;
static int timeout_thread_initialized=0;
#endif
@@ -1282,6 +1282,7 @@
}
DestroyWindow(timeout_window);
UnregisterClass(wc.lpszClassName, NULL);
+ SetEvent(timeout_thread_finish);
return 0;
}
@@ -1289,7 +1290,8 @@
void zend_init_timeout_thread()
{
timeout_thread_event = CreateEvent(NULL, FALSE, FALSE, NULL);
- timeout_thread_handle = _beginthreadex(NULL, 0, timeout_thread_proc,
NULL, 0, &timeout_thread_id);
+ timeout_thread_finish = CreateEvent(0, 0, 0, 0);
+ _beginthreadex(NULL, 0, timeout_thread_proc, NULL, 0,
&timeout_thread_id);
WaitForSingleObject(timeout_thread_event, INFINITE);
}
@@ -1302,8 +1304,7 @@
PostThreadMessage(timeout_thread_id, WM_QUIT, 0, 0);
/* Wait for thread termination */
- WaitForSingleObject(timeout_thread_handle, 5000);
- CloseHandle(timeout_thread_handle);
+ WaitForSingleObject(timeout_thread_finish, 3);
}
#endif
[2005-12-19 08:51:01] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
And this time, really make sure you have the right PHP installed. Only
way to be sure is to delete ALL old dlls related to PHP. Especially
from C:\windows\ directory.
Also, make any patches against the latest CVS sources. PHP 4 is too
old.
[2005-12-09 19:11:13] [EMAIL PROTECTED]
Fixed in CVS HEAD, PHP_5_1 and PHP_5_0.
[2005-12-09 12:29:41] alacn dot uhahaa at gmail dot com
Description:
PHP5 and PHP4 on iis6 (windows server 2003) sometimes crash with access
violation
Reproduce code:
---
(code at zend_execute_API.c)
before iis shutdown or recycle the pool, it will call
"zend_shutdown_timeout_thread()", that will post a quit message on
"timeout_thread_id" and return
Expected result:
"zend_shutdown_timeout_thread()" should wait "timeout_thread" finish
before return
Actual result:
--
sometimes "zend_shutdown_timeout_thread()" return before the
"tiumeout_thread" finish, and the iis release the library, than the iis
crash at "timeout_thread_proc()" because the library was released.
the fix for PHP5 and PHP4 at "zend_execute_API.c"
"[...]" means hidden code...
#ifdef ZEND_WIN32
#include
/* true global */
[...]
// add next line
static HANDLE timeout_thread_finish_event;
#endif
[...]
static unsigned __stdcall timeout_thread_proc(void *pArgs)
{
[...]
DestroyWindow(timeout_window);
UnregisterClass(wc.lpszClassName, NULL);
// add next line
SetEvent(timeout_thread_finish_event);
return 0;
}
void zend_init_timeout_thread()
{
timeout_thread_event = CreateEvent([..]);
// add next line
timeout_thread_finish_event = CreateEvent(0, 0, 0, 0);
[...]
}
void zend_shutdown_timeout_thread()
{
[...]
PostThreadMessage(timeout_thread_id, WM_QUIT, 0, 0);
// add next line
WaitForSingleObject(timeout_thread_finish_event, 3);
}
--
Edit this bug report at http://bugs.php.net/?id=35612&edit=1
#35741 [Opn->Bgs]: problema con function COPY
ID: 35741 Updated by: [EMAIL PROTECTED] Reported By: egarcia at jig dot es -Status: Open +Status: Bogus Bug Type: *Directory/Filesystem functions Operating System: Windows XP/2000 PHP Version: 5.1.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: [2005-12-20 09:51:22] egarcia at jig dot es Good morning: I have updated the PHP of my server to version 5.1.1. Everything goes well until now unless I cannot enclose a file (an image in this particular case) to the server through a form. The error that it gives is: Warning: copy(c:\\maps\\tumbs\\mapsys.jpg) [ function.copy ]: failed to open stream: Such does not case out or directory in c:\phpscripts\mapcdr.php on line 366... This happens whenever it becomes from any computer towards the server. The peculiar thing, is that this does not happen if is made directly in the own server (localhost). Help me what is the problem and its possible solution. Thank you very much by its aid. [2005-12-20 09:41:14] [EMAIL PROTECTED] Please only file bugreports in English. Can you translate? [2005-12-20 09:34:54] egarcia at jig dot es Description: Buenos días: He actualizado el PHP de mi servidor a la versión 5.1.1. Todo va bien hasta ahora salvo que no puedo adjuntar un archivo (una imagen en este caso particular) al server a través de un formulario. El error que da es: Warning: copy(c:\\maps\\tumbs\\mapsys.jpg) [function.copy]: failed to open stream: No such file or directory in c:\phpscripts\mapcdr.php on line 366 ... Esto ocurre siempre que se hace desde cualquier ordenador hacia el servidor. Lo curioso, es que esto no pasa si se hace directamente en el propio servidor (localhost). Indíquenme cual es el problema y su posible solución. Muchas gracias por su ayuda. Reproduce code: --- copy($imagen,"../imagenproductos/".$nombre_img); -- Edit this bug report at http://bugs.php.net/?id=35741&edit=1
#35730 [Opn->Fbk]: mssql didn't use the right character encoding in freetds.conf
ID: 35730 Updated by: [EMAIL PROTECTED] Reported By: liang at saga-city dot com -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: FreeBSD PHP Version: 5.1.1 Assigned To: fmk New Comment: How about a short reproducing script too? Previous Comments: [2005-12-20 09:43:48] liang at saga-city dot com new FreeTDS(0.64)CVS makes no difference. Both PHP4/PHP5.1.1 call to the same Shared object "libsybdb.so.5" and using the same freetds.conf. It's obvious PHP5.1.1 behaves different. Sorry, I have some production machines to take care for the time being. Will not get back on this issuses shortly. Hopefully the problem will be solved soon. Cheers, [2005-12-20 02:41:46] [EMAIL PROTECTED] Please try to upgrade to the latest CVS version of FreeTDS. As I mentioned before all the encoding stuff is handled by FreeTDS. There is no encoding handling in the code for the PHP extension and the code differences between version 4, 5.0, 5.1 and 6.0 of PHP are only related to internal PHP stuff and has nothing to do with how the library is used. [2005-12-20 01:37:48] liang at saga-city dot com We have some production machines with PHP5.0.3/FreeBSD5.4/FreeTDS0.62.4 installed, All works great. Now we are setting a clean and new FreeBSD 6.0 system box with only freetds-0.63 mysql5.0-client and apache22 installed. It's obvious testing PHP4/PHP5 installation link to the same freetds library. [2005-12-19 18:12:27] [EMAIL PROTECTED] Are you absolutely sure you're linking PHP with the same freetds library as you did with PHP 4? [2005-12-19 05:48:08] liang at saga-city dot com we have been testing the mssql extension both in PHP4 and PHP5.1.1, " with the same freetds.conf " tds version = 8.0 client charset = BIG-5 In php4, it works fine, but not in php5.1.1 ( our old system uses php5.0.3 also work fine in the "same" freetds.conf ) 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/35730 -- Edit this bug report at http://bugs.php.net/?id=35730&edit=1
#35737 [Opn->Fbk]: undefined symbol: sqlite3SelectDelete
ID: 35737 Updated by: [EMAIL PROTECTED] Reported By: jphml at videotron dot ca -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Linux PHP Version: 5.1.1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip And what OS is that exactly? Previous Comments: [2005-12-20 04:26:09] jphml at videotron dot ca Description: When tring to use Apache 2.0.55 with PHP 5.1.1 module (libphp5.so) you get the following error on Apache startup Syntax error on line 232 of /opt/fruity/conf/httpd.conf: Cannot load /opt/fruity/modules/libphp5.so into server: /opt/fruity/modules/libphp5.so: undefined symbol: sqlite3SelectDelete Your are then unable to start apache. Here is my configure line for Apache: ./configure --prefix=/opt/fruity --enable-so Here is my configure line for PHP 5.1.1: ./configure --prefix=/opt/fruity --with-apxs2=/opt/fruity/bin/apxs --with-mysql Here is my line about PHP in httpd.conf LoadModule php5_modulemodules/libphp5.so I tried the following: - Apache 1.3.34 with PHP 5.1.1: same error - Compile PHP 5.1.1 with --without-sqlite: Same error - Compile PHP without --with-mysql: Same error The following configuration works: Apache 2.0.55 and PHP 5.0.5 with the configure lines above. (In Apache 1.x use --enable-module=so instead of --enable-so). Note that both software were always compiled with --prefix=/opt/fruity, I didn't tried without. Expected result: You expect that Apache will start without errors Actual result: -- When you start apache you get: [EMAIL PROTECTED] bin]# ./apachectl start Syntax error on line 232 of /opt/fruity/conf/httpd.conf: Cannot load /opt/fruity/modules/libphp5.so into server: /opt/fruity/modules/libphp5.so: undefined symbol: sqlite3SelectDelete and Apache doesn't start -- Edit this bug report at http://bugs.php.net/?id=35737&edit=1
#35735 [Opn->Csd]: $EGREP and $SED are not defined in configure
ID: 35735 Updated by: [EMAIL PROTECTED] -Summary: egrep not defined in ext/curl/config.m4 Reported By: selsky at columbia dot edu -Status: Open +Status: Closed -Bug Type: cURL related +Bug Type: Compile Failure Operating System: Solaris PHP Version: 4CVS-2005-12-19 (snap) New Comment: This bug has been fixed in CVS. 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: [2005-12-19 23:19:53] selsky at columbia dot edu Description: $EGREP is not defined in ./configure since the following is missing from ext/curl/config.m4: dnl properly set EGREP for AC_EGREP_CPP later on AC_CHECK_PROG(EGREP, egrep, grep -E) AC_SUBST(EGREP) Reproduce code: --- $ ./configure --with-openssl=/opt/openssl-0.9.7i --with-curl=/opt/curl-7.11.1 Expected result: [...] checking for SSL support in libcurl... yes Actual result: -- [...] checking for SSL support in libcurl... ../../src/configure: SSL: not found no -- Edit this bug report at http://bugs.php.net/?id=35735&edit=1
#35714 [Opn->Bgs]: odbc_connect() does not timeout.
ID: 35714
Updated by: [EMAIL PROTECTED]
Reported By: ceason at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: ODBC related
Operating System: Linux
PHP Version: 5.1.1
New Comment:
You won't test, we can't fix. Bogus.
Previous Comments:
[2005-12-19 23:10:21] ceason at gmail dot com
Compiled with latest and gave POD ODBC driver a spin. Switching to POD
will require a rewrite if I understand it correctly. Will have to work
with original for now.
[2005-12-17 02:53:19] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
And use the PDO ODBC driver instead.
[2005-12-16 21:13:50] ceason at gmail dot com
Description:
A php script that didn't check the odbc_connect return value entered a
state
where it did not end. The httpd server does not seem to time these
requests out
and reports the as "W" Sending Reply state. Eventually this causes
access
denial due to max_connection limit being reached. I upgraded to httpd
2.2.0 and
php 5.1.1 but the problem still occurs.
This is the timeout value from httpd.conf
#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 300
This is the timeout value from php.ini
max_execution_time = 120 ; Maximum execution time of each script,
in seconds
max_input_time = 60 ; Maximum amount of time each script may spend
parsing
request data
memory_limit = 8M ; Maximum amount of memory a script may consume
(8MB)
server-status entry:
0-0 27217 2/2/2 W 0.0032840 13.20.010.01
ceason madmax GET
/status/ras_results.php?db=bgs1&severityCB=1&facilityCB=1&b
I initially reported this as an Apache bug and received this response.
This is a bug in mod_php. If mod_php does not return the control of
execution
from the script, httpd can't do anytning. Please report this to the
PHP
Project, instead of Apache HTTP Server Project.
Reproduce code:
---
$dbconn = odbc_connect("BOGUS","username","password");
$query = "select * from footable";
while(odbc_fetch_row($result)) {
print"$result";
}
This may fail correct the 1st time. Hit refresh after this and it
should hang up.
Expected result:
Similiar error messages as below
Warning: odbc_connect() [function.odbc-connect]: SQL error: \EA, SQL
state D\$ in SQLConnect in /var/www/html/test.php on line 14
Warning: odbc_fetch_row(): supplied argument is not a valid ODBC result
resource in /var/www/html/test.php on line 16
Actual result:
--
Hang after refresh
--
Edit this bug report at http://bugs.php.net/?id=35714&edit=1
#29840 [Opn->Asn]: is_executable does not honor the safe_mode_exec_dir setting
ID: 29840 Updated by: [EMAIL PROTECTED] Reported By: markus at cultcom dot de -Status: Open +Status: Assigned Bug Type: Filesystem function related Operating System: * PHP Version: 5CVS, 4CVS (2005-01-04) Assigned To: tony2001 New Comment: tony2001: 2 words for you: Just commit! :) Previous Comments: [2005-12-05 11:17:08] [EMAIL PROTECTED] Any news on this? Would appreciate this patch in PHP4 and PHP5 [2005-08-12 01:00:33] [EMAIL PROTECTED] Please try this patch: http://tony2001.phpclub.net/dev/tmp/bugs_29840_31618.diff (with the latest snapshot/CVS). [2004-12-12 11:36:05] [EMAIL PROTECTED] Jani, I sent a patch for this problem to Wez long ago. The problem is that is_executable() indeed doesn't respect safe_mode_exec_dir as it should, so I'm assigning this to Wez. [2004-12-12 02:07:16] [EMAIL PROTECTED] It works just fine. (it returns false always when in safe-mode..) [2004-08-25 18:06:12] markus at cultcom dot de Description: Seems to be a common problem nobody complains about... "is_executable()" does not work in safe_mode! Some PHP-Projects check for sendmail using this function and don't work in safe_mode even if sendmail acutally IS executable (i.e. PEAR: Mail.php). is_executable() should at least honor the safe_mode_exec_dir directive! Reproduce code: --- Try with PHP/CGI and suexec + safe_mode where example-UID != sendmail-UID Expected result: true, what else? Actual result: -- false. -- Edit this bug report at http://bugs.php.net/?id=29840&edit=1
#35691 [Opn->Asn]: Can't change to another drive letter using chdir()
ID: 35691
Updated by: [EMAIL PROTECTED]
Reported By: ejwaibel at gmail dot com
-Status: Open
+Status: Assigned
Bug Type: *Directory/Filesystem functions
Operating System: Windows 2003
-PHP Version: 5.1.1
+PHP Version: 5CVS-2005-12-19 (snap)
-Assigned To:
+Assigned To: nlopess
Previous Comments:
[2005-12-19 17:41:10] [EMAIL PROTECTED]
So, this is only happening with attached drive on Windows 2003. I can
only think of a bug in GetLongPathName().
I'll install windows 2003 server somewhere to test.
[2005-12-19 01:42:04] erik dot waibel at cubic dot com
This is what I get when running the code with an existing drive (such
as C:)
Files in current directory...
Array ( [0] => TCdetails.php [1] => TCgetdata.php [2] =>
TCgetversion.php [3] => TCmanual.php [4] => TCpreview.php [5] =>
TCprocess.php [6] => TCsearch.php [7] => changes.php [8] =>
checklist.php [9] => details.php [10] => footer.php [11] => getarq.php
[12] => getdata.php [13] => help.php [14] => hints.php [15] =>
import.php [16] => login.php [17] => manual.php [18] => modules.php
[19] => password.php [20] => phpinfo.php [21] => process.php [22] =>
search.php [23] => srnform_windows.php [24] => stscr.php [25] =>
user.php )
string(35) "d:\scmtools\test\ctssrn-enhancement" CWD:
bool(true) Change dir:
string(3) "C:\" CWD:
Files in CWD...
Array ( [0] => AUTOEXEC.BAT [1] => CONFIG.SYS [2] => Documents and
Settings [3] => IO.SYS [4] => Inetpub [5] => MSDOS.SYS [6] =>
NTDETECT.COM [7] => PHP [8] => Perl [9] => Program Files [10] =>
RECYCLER [11] => System Volume Information [12] => WINDOWS [13] =>
boot.ini [14] => dsn [15] => dsn.dir [16] => dsn.pag [17] => mvfslogs
[18] => ntldr [19] => pagefile.sys [20] => temp.log [21] => wmpub )
This is what I get when I change to the drive that is being 'subst':
Files in current directory...
Array ( [0] => TCdetails.php [1] => TCgetdata.php [2] =>
TCgetversion.php [3] => TCmanual.php [4] => TCpreview.php [5] =>
TCprocess.php [6] => TCsearch.php [7] => changes.php [8] =>
checklist.php [9] => details.php [10] => footer.php [11] => getarq.php
[12] => getdata.php [13] => help.php [14] => hints.php [15] =>
import.php [16] => login.php [17] => manual.php [18] => modules.php
[19] => password.php [20] => phpinfo.php [21] => process.php [22] =>
search.php [23] => srnform_windows.php [24] => stscr.php [25] =>
user.php )
string(35) "d:\scmtools\test\ctssrn-enhancement" CWD:
bool(false) Change dir:
string(35) "d:\scmtools\test\ctssrn-enhancement" CWD:
Files in CWD...
Array ( [0] => TCdetails.php [1] => TCgetdata.php [2] =>
TCgetversion.php [3] => TCmanual.php [4] => TCpreview.php [5] =>
TCprocess.php [6] => TCsearch.php [7] => cc-get-modules.exe [8] =>
cc-import.exe [9] => changes.php [10] => checklist.php [11] =>
details.php [12] => error_log.log [13] => footer.php [14] => getarq.php
[15] => getdata.php [16] => help.php [17] => hints.php [18] =>
import.php [19] => login.php [20] => manual.php [21] => modules.php
[22] => password.php [23] => phpinfo.php [24] => process.php [25] =>
search.php [26] => srnform_windows.php [27] => stscr.php [28] =>
user.php )
[2005-12-19 00:14:44] [EMAIL PROTECTED]
I've also tested with networked drives and it works fine.
can you please test with a simple script like:
Please include all error messages printed by PHP.
[2005-12-16 16:41:50] erik dot waibel at cubic dot com
I updated my PHP version to the Windows .zip file that you included,
but that still did not work. We are using a Windows NT 5.2 build 3790
machine (it's a Windows NT server). I actually just checked and it
seems like I can change to the "C:" drive, but what I forgot to mention
earlier, here is another piece of my code that is used to "subst" the Q:
drive for a directory that exists on another drive.
$subst = exec("subst $substDrive M:\\$sessionView", $substOutput);
$currentDir = getcwd();
$changeTo = "$substDrive\\sdadmin";
chdir("$changeTo") || die("Can't change
location to: $changeTo.");
The reason I'm doing this is because of our Source Control program
"ClearCase" that we use. Can you let me know if there is another way I
should do this?
[2005-12-16 14:06:53] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Sorry, but I can't reproduce this behaviour. I'm able to chdir()
between drives with PHP 5.1.2 from snaps.php.net and with PHP 6 built
by me.
I've a
#35730 [Asn->Fbk]: mssql didn't use the right character encoding in freetds.conf
ID: 35730 Updated by: [EMAIL PROTECTED] Reported By: liang at saga-city dot com -Status: Assigned +Status: Feedback Bug Type: MSSQL related Operating System: FreeBSD PHP Version: 5.1.1 Assigned To: fmk New Comment: Are you absolutely sure you're linking PHP with the same freetds library as you did with PHP 4? Previous Comments: [2005-12-19 05:48:08] liang at saga-city dot com we have been testing the mssql extension both in PHP4 and PHP5.1.1, " with the same freetds.conf " tds version = 8.0 client charset = BIG-5 In php4, it works fine, but not in php5.1.1 ( our old system uses php5.0.3 also work fine in the "same" freetds.conf ) [2005-12-19 03:27:06] [EMAIL PROTECTED] All encoding is handled by freetds in both PHP4 and PHP5. Execpt for internal PHP stuff the mssql extension is the same for PHP4 and PHP5. You need to change the encoding in freetds.conf. [2005-12-19 02:29:00] liang at saga-city dot com Description: php5 mssql didn't use character encoding specify in freetds.conf ( alwasy use ISO-8559-1 , seen in freetds.log ) switch to php4 , everythings works fine -- Edit this bug report at http://bugs.php.net/?id=35730&edit=1
#35734 [Opn->Bgs]: RecursiveIteratorIterator constructor fails to recognize mode constants
ID: 35734
Updated by: [EMAIL PROTECTED]
Reported By: dpantel at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: SPL related
Operating System: RHES (linux 2.4.21-37)
PHP Version: 5.1.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.
Those are class constants now:
RecursiveIteratorIterator::SELF_FIRST
Previous Comments:
[2005-12-19 16:27:39] dpantel at gmail dot com
Description:
RecursiveIteratorIterator constructor fails to recognize mode
constants.
The constructor works fine when passed only a RecursiveIterator object.
It also functions correctly if passed a RecursiveIterator object and an
integer (0,1,2, etc) as the second (mode) argument. However, if one
attempts to pass a documented constant keyword (RIT_SELF_FIRST or
SELF_FIRST), the constructor fails.
Note: different documentations show different constant definitions
(RIT_SELF_FIRST vs SELF_FIRST). I have tried both, and neither one
works.
Reproduce code:
---
class Rit implements RecursiveIterator {...}
$test = new Rit();
//work fine
$rii = new RecursiveIteratorIterator($test);
$rii = new RecursiveIteratorIterator($test, 1);
//do not work
$rii = new RecursiveIteratorIterator($test, RIT_SELF_FIRST);
$rii = new RecursiveIteratorIterator($test, SELF_FIRST);
//even tried this, with no avail
$rii = new RecursiveIteratorIterator($test,
RecursiveIteratorIterator::RIT_SELF_FIRST);
$rii = new RecursiveIteratorIterator($test,
RecursiveIteratorIterator::SELF_FIRST);
Expected result:
A RecursiveIteratorIterator object
Actual result:
--
Notice: Use of undefined constant RIT_SELF_FIRST - assumed
'RIT_SELF_FIRST' in /www/rit.class.php on line 276
(or Notice: Use of undefined constant SELF_FIRST - assumed 'SELF_FIRST'
in /www/rit.class.php on line 276)
Fatal error: Uncaught exception 'InvalidArgumentException' with message
'An instance of RecursiveIterator or IteratorAggregate creating it is
required' in /www/rit.class.php:276 Stack trace: #0
/www/rit.class.php(276):
RecursiveIteratorIterator->__construct(Object(treeIterator),
'RIT_SELF_FIRST') ...
--
Edit this bug report at http://bugs.php.net/?id=35734&edit=1
#35733 [Opn->Bgs]: preg_replace() distroys $GLOBALS
ID: 35733
Updated by: [EMAIL PROTECTED]
Reported By: gerhard at tinned-software dot net
-Status: Open
+Status: Bogus
Bug Type: PCRE related
Operating System: WinXP/Linux
PHP Version: 5.1.1
New Comment:
If it worked in PHP 4 it's a bug there. Don't play around with GLOBALS
like that. It's expected behaviour to work unexpectedly.
Previous Comments:
[2005-12-19 16:21:56] gerhard at tinned-software dot net
with preg_replace i only remove newlines from a string which contains
the content of the variable! $value contains the content of the
variable and is copied to $entry ... only $entry is changed not the
$value which is used to check if it is an array and which is aslo used
to call the function recursive!
foreach($array as $key => $value){
$entry = $value;
how can this damage the $GLOBALS??? ... and if this is not a bug, way
it is working with PHP4.x???
[2005-12-19 15:12:47] [EMAIL PROTECTED]
$GLOBALS contains reference to itself.
In your code you're effectively converting all the elements to strings
with preg_replace(), so GLOBALS itself becomes string too.
Not a bug.
[2005-12-19 15:01:19] gerhard at tinned-software dot net
Description:
PHP 5 PCRE Bug!?
We have in our program a function to log all $GLOBALS variables. This
function
calls itself recursive to log all variables of a array and all its
sub-arrays.
This function is working fine in PHP 4.0.1 and up to 4.3.10 (the
highest of our
test configuration.)
Since PHP5 (different versions) it was not working anymore when you
call the function with $GLOBALS as
parameter. The logfile contained only one line ...
|-> GLOBALS = Array
After some hours i go it working by replacing the preg_replace()
function with
the ereg_replace() function.
The problem shows as follows:
After calling function preg_replace() the $GLOBALS array contails only
1 element
which is $GLOBALS. (i cheched it with count($GLOBALS);) after that the
check
is_array() is always returning "1" instead of true or false.
after replacing the ...
preg_replace("/\r*\n/", " ", $entry);
... with ...
ereg_replace("\n", " ", $entry);
ereg_replace("\r", " ", $entry);
... the function is working without problems. PHP must be configured
correctly
because this function preg_replace() is used very often in our program.
This
function is also workinf fine when called with any other array. Only
when
$GLOBALS is used to call this function it shows this behaviour.
We checked this behaviour with different PHP4.x (everything was
working) and some versions of PHP5 (on all the same problem - last
tested version 5.1.1). And also on different OS (Linux, MacOSX, WinXP,
Win2000).
Reproduce code:
---
$value){
$entry = $value;
$entry = preg_replace("/\r*\n/", " ", $entry);
$entry2 = "$level_space|-> $key = $entry\n";
$FILE = fopen("array.log", "a");
fwrite($FILE, $entry2);
fclose($FILE);
echo is_array($value);
if(is_array($value)){
if($key == "GLOBALS"){ continue; }
array_log($value, $level + 1);
}
}
}
?>
Expected result:
Logfile with PHP 5.1.1:
|-> GLOBALS = Array
Logfile with 4.x.x (as it should look like):
|-> HTTP_ENV_VARS = Array
|-> DBROOT = /dev/null
|-> BOOT_FILE = /boot/vmlinuz
|-> HOSTNAME = mail
|-> CONSOLE = /dev/console
|-> LD_LIBRARY_PATH = :/lib
.
.
.
|-> HTTP_POST_FILES = Array
|-> GLOBALS = Array
|-> GATEWAY_INTERFACE = CGI/1.1
|-> SERVER_PROTOCOL = HTTP/1.0
|-> REQUEST_METHOD = GET
|-> QUERY_STRING =
.
.
.
Actual result:
--
Replace ...
$entry = preg_replace("/\r*\n/", " ", $entry);
... With ...
$entry = ereg_replace("\r", "", $entry);
$entry = ereg_replace("\n", " ", $entry);
After changing it to ereg_replace() it is working with PHP4.0.1, 4.3.10
and 5.1.1
--
Edit this bug report at http://bugs.php.net/?id=35733&edit=1
#35730 [Opn->Asn]: mssql didn't use the right character encoding in freetds.conf
ID: 35730 Updated by: [EMAIL PROTECTED] Reported By: liang at saga-city dot com -Status: Open +Status: Assigned Bug Type: MSSQL related Operating System: FreeBSD PHP Version: 5.1.1 -Assigned To: +Assigned To: fmk Previous Comments: [2005-12-19 05:48:08] liang at saga-city dot com we have been testing the mssql extension both in PHP4 and PHP5.1.1, " with the same freetds.conf " tds version = 8.0 client charset = BIG-5 In php4, it works fine, but not in php5.1.1 ( our old system uses php5.0.3 also work fine in the "same" freetds.conf ) [2005-12-19 03:27:06] [EMAIL PROTECTED] All encoding is handled by freetds in both PHP4 and PHP5. Execpt for internal PHP stuff the mssql extension is the same for PHP4 and PHP5. You need to change the encoding in freetds.conf. [2005-12-19 02:29:00] liang at saga-city dot com Description: php5 mssql didn't use character encoding specify in freetds.conf ( alwasy use ISO-8559-1 , seen in freetds.log ) switch to php4 , everythings works fine -- Edit this bug report at http://bugs.php.net/?id=35730&edit=1
#32503 [Opn->Fbk]: fopen() in cwd: filename must start with ./ under safe mode
ID: 32503 Updated by: [EMAIL PROTECTED] Reported By: Bjorn dot Wiberg at its dot uu dot se -Status: Open +Status: Feedback Bug Type: Safe Mode/open_basedir Operating System: IBM AIX 5.2.0.0 ML5 PHP Version: 5CVS-2005-07-05 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2005-07-05 10:21:38] Bjorn dot Wiberg at its dot uu dot se (Thanks for fixing the mpm_common crash, that problem is gone now.) With #define HAVE_BROKEN_GETCWD 1 in php_config.h, and having made sure that the path up to the directory where the file is to be created has sufficient permissions, I still get the same error: /apache/htdocs/bwiberg/test/safemode Warning: fopen(): Unable to access a.txt in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Warning: fopen(a.txt): failed to open stream: No such file or directory in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Having the read (r) permission off for the "test" directory along the way: Warning: fopen(): open_basedir restriction in effect. File(a.txt) is not within the allowed path(s): (.:/apache/php/lib/php/:/apache/htdocs/bwiberg/) in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Warning: fopen(a.txt): failed to open stream: Not owner in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Best regards, Björn [2005-05-09 14:15:53] Bjorn dot Wiberg at its dot uu dot se Hi again! I just tried the #define HAVE_BROKEN_GETCWD 1 trick from http://bugs.php.net/bug.php?id=32501, with PHP 5.0.4 (the "fixed" version) but that didn't help in this regard. I thought I would mention this. Best regards, Björn [2005-04-05 09:28:28] Bjorn dot Wiberg at its dot uu dot se Hi Tony! Thank you for your feedback! I'm afraid that absolute paths aren't a very viable solution to this, as that probably would break too many scripts, expecting it to be possible to "just" save a file to the current directory. Is the "PHP realpath hack" supposed to handle these kind of problems on AIX? Please let me know if I can help in any way! Best regards, Björn [2005-04-04 17:11:05] [EMAIL PROTECTED] Right, this is somehow concerned with broken realpath() on AIX. The problem is that we end up with relative path in php_checkuid_ex() function and it fails to check permissions for the directory. Of course, the easiest solution is to use absolute paths everywhere. [2005-04-01 16:32:32] Bjorn dot Wiberg at its dot uu dot se Tried php5-200503310630 (5.1.0-dev), but the problem is still present: /apache/htdocs/bwiberg/test/safemode Warning: fopen(): Unable to access a.txt in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 Warning: fopen(a.txt): failed to open stream: No such file or directory in /apache/htdocs/bwiberg/test/safemode/write.php on line 5 (Whereas "./a.txt" works just fine.) Best regards, Björn 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/32503 -- Edit this bug report at http://bugs.php.net/?id=32503&edit=1
#32962 [Asn->Fbk]: Installer puts php.ini in wrong location
ID: 32962 Updated by: [EMAIL PROTECTED] Reported By: ash at theleys dot net -Status: Assigned +Status: Feedback Bug Type: IIS related Operating System: Windows Server 2003 PHP Version: 5.0.4 Assigned To: phildriscoll New Comment: Does this happen with the latest release? (5.1.1) Previous Comments: [2005-11-07 00:01:14] [EMAIL PROTECTED] Phil, there's the feedback you asked. (given same day, but you didn't notice?) [2005-05-09 11:38:37] ash at theleys dot net Under this comment are all the environment variables, - there isn't a "win" one, but "windir" is pointing to the correct folder. - This was installed with me using a terminal services session, but that's not been a problem before. (the comp. names have been changed here for privacy) ALLUSERSPROFILE=C:\Documents and Settings\All Users APPDATA=C:\Documents and Settings\Administrator\Application Data CLIENTNAME=CHANGEDTOPROTECTSERVER ClusterLog=C:\WINDOWS\Cluster\cluster.log CommonProgramFiles=C:\Program Files\Common Files COMPUTERNAME=CHANGEDTOPROTECTSERVER ComSpec=C:\WINDOWS\system32\cmd.exe HOMEDRIVE=C: HOMEPATH=\Documents and Settings\Administrator LOGONSERVER=\\HENRYV NUMBER_OF_PROCESSORS=4 OS=Windows_NT Path=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH PROCESSOR_ARCHITECTURE=x86 PROCESSOR_IDENTIFIER=x86 Family 15 Model 2 Stepping 9, GenuineIntel PROCESSOR_LEVEL=15 PROCESSOR_REVISION=0209 ProgramFiles=C:\Program Files PROMPT=$P$G SESSIONNAME=RDP-Tcp#1 SystemDrive=C: SystemRoot=C:\WINDOWS TEMP=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1 TMP=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1 USERDOMAIN=HENRYV USERNAME=Administrator USERPROFILE=C:\Documents and Settings\Administrator windir=C:\WINDOWS [2005-05-09 11:01:08] [EMAIL PROTECTED] I don't have Windows Server 2003, and I can't reproduce the problem on W2K Advanced Server (the only Windows machine I have). Can you tell me what the value of the WIN environment variable is when you are logged in as administrator? Thanks [2005-05-07 06:14:01] [EMAIL PROTECTED] Assigning to the author of the installer. [2005-05-06 13:18:01] ash at theleys dot net Description: Using the php-5.0.4-installer.exe puts php.ini into c:\docs&settings\administrator\WINDOWS\ - not in c:\windows, therefore it's not available, and causes "500" errors. - Found this out by parsing from php -i and noticing Configuration File (php.ini) Path was set wrongly. Expected result: phpinfo (or whatever the web page contains) Actual result: -- 500 CGI Error -- Edit this bug report at http://bugs.php.net/?id=32962&edit=1
#33073 [Asn->Fbk]: PHP Windows Installer does not set Verify File Exists for IIS 6.
ID: 33073 Updated by: [EMAIL PROTECTED] Reported By: webmaster at cyberdogtech dot com -Status: Assigned +Status: Feedback Bug Type: IIS related Operating System: Windows Server 2003 PHP Version: 5.0.4 Assigned To: phildriscoll New Comment: Does this happen with the latest release? (5.1.1) Previous Comments: [2005-11-07 00:01:42] [EMAIL PROTECTED] Phil, are you aware of this issue? [2005-05-20 10:34:06] [EMAIL PROTECTED] Assigned the person behind the installer.. =) [2005-05-20 00:31:02] webmaster at cyberdogtech dot com Description: I discovered this bug while using the PHP Windows Installer with 5.0.4 under IIS6 on Windows Server 2003 SP1. The installer adds the ISAPI extension to IIS for .php files, linking them to php-cgi.exe. The problem is, it does not set the option of "Verify that File Exists." This option causes IIS to validate the presence of the requested file. Without it set, as it stands now, php will always return an html page even for non-existent files! For example if I request www.website.com/nothing.php (a file which doesn't exist), PHP will still return empty HTML tags instead of the usual 404. By activating this IIS option, however, a 404 is returned properly instead of invoking PHP on the missing file name. -- Edit this bug report at http://bugs.php.net/?id=33073&edit=1
#33115 [Asn->Fbk]: Windows Install Silent Option breaks OS environment path variable
ID: 33115 Updated by: [EMAIL PROTECTED] Reported By: john dot jantjes at gmail dot com -Status: Assigned +Status: Feedback Bug Type: IIS related Operating System: Windows XP PHP Version: 5.0.4, 4.3.11 Assigned To: phildriscoll New Comment: Does this happen with the latest release? (5.1.1) Previous Comments: [2005-11-07 00:03:50] [EMAIL PROTECTED] Phil, have you checked this report yet..? [2005-05-24 04:20:36] john dot jantjes at gmail dot com If the installer is used normally, not silent, the issue does not appear. [2005-05-24 04:16:42] john dot jantjes at gmail dot com Description: I have been using the windows installer, with the "/s" option for a silent install, and have found that it breaks the OS environment variable. For example Instread of path being path=c:\windows;c:\windows\system32; . It becomes path=%SystemRoot%;%SystemRoot%\system32;.. It set the path variable to reference another variable, which just does not seem to work. Only the windows and windows system entries in path are effected. -- Edit this bug report at http://bugs.php.net/?id=33115&edit=1
#34340 [Asn->Bgs]: imagepstext returns T1Lib Error: Font ID Invalid in this Context
ID: 34340
Updated by: [EMAIL PROTECTED]
Reported By: brian at visionn dot com
-Status: Assigned
+Status: Bogus
Bug Type: GD related
Operating System: Windows NT
PHP Version: 5.1.0RC1
Assigned To: pajoye
New Comment:
Not PHP bug. Please report this to the T1 library author(s).
Previous Comments:
[2005-10-05 21:57:56] [EMAIL PROTECTED]
This is propably some threading issue with T1lib..
[2005-10-05 21:56:30] brian at visionn dot com
New version of test script with :
PATH_TO_FONT\font_file.pfb should be edited to work on the system
used.
I can't really post on online version, since each time you run the
script with an error, it would cause me to have to restart my web
server.
The easiest way to see the error would be to point the $font variable
to a non-existent pfb file, run it, then fix it to point to an existing
pfb file. Once the error has occurred, the function no longer works even
when the code is correct and the pfb file exists. Once you restart IIS,
it works again.
[2005-09-02 18:55:54] brian at visionn dot com
To reproduce, first run the code that work fine. Then introduce an
error, run it. Remove the error, run it. The clean code doesn't work
until a restart of IIS. There is a comment from 2001 in the docs about
this on the imagepstext page...so this might be a T1Lib error that it
can't recover from, and so wouldn't belong as a pure PHP bug(?)
[2005-09-02 18:49:14] brian at visionn dot com
apologies, here's a better version of the code with hardcoded values:
$font = imagepsloadfont("C:\\PATH_TO_FONT\\font_file.pfb");
$header_img = imagecreate(320, 20);
$font_color = imagecolorallocate($header_img, 42, 86, 143);
$bg_color = imagecolorallocate($header_img, 255, 255, 255);
imagefill($header_img, 0, 0, $bg_color);
imagepstext($header_img, "TEXT", $font, 18, $font_color,
$bg_color, 0, 16, 0, 0, 0, 16);
[2005-09-02 17:45:00] brian at visionn dot com
The error was fixed by restarting IIS.
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/34340
--
Edit this bug report at http://bugs.php.net/?id=34340&edit=1
#35711 [Opn->Asn]: [PATCH] ISO-8859 charset not correctly detected
ID: 35711
Updated by: [EMAIL PROTECTED]
Reported By: matteo at beccati dot com
-Status: Open
+Status: Assigned
Bug Type: mbstring related
Operating System: Debian GNU/Linux
PHP Version: 5.1.1
-Assigned To: moriyoshi
+Assigned To: hirokawa
New Comment:
Rui, can you check this out please?
Previous Comments:
[2005-12-19 09:00:50] matteo at beccati dot com
Oops, I just realized that I forgot the -u flag :)
Here is the downlaodable patch:
http://beccati.com/download/mbstring-patch-20051219.txt
[2005-12-19 08:48:47] [EMAIL PROTECTED]
Please provide any patches in unified diff format. (like the first
one). And downloadable somewhere.
[2005-12-16 23:50:13] matteo at beccati dot com
I've made a patch which seems to fix the issue. It basicly checks
filter status during judgement. Status seems to be != 0 only when it is
matching a multibyte character. I added anyway a fallback to the old
judgement routine, just in case no matching encoding is found.
Index: ext/mbstring/libmbfl/mbfl/mbfilter.c
===
RCS file: /repository/php-src/ext/mbstring/libmbfl/mbfl/mbfilter.c,v
retrieving revision 1.7.2.1
diff -u -r1.7.2.1 mbfilter.c
--- ext/mbstring/libmbfl/mbfl/mbfilter.c5 Nov 2005 04:49:57
- 1.7.2.1
+++ ext/mbstring/libmbfl/mbfl/mbfilter.c16 Dec 2005 22:46:26
-
@@ -575,12 +575,22 @@
for (i = 0; i < num; i++) {
filter = &flist[i];
- if (!filter->flag) {
+ if (!filter->flag && !filter->status) {
encoding = filter->encoding;
break;
}
}
+ if (!encoding) {
+ for (i = 0; i < num; i++) {
+ filter = &flist[i];
+ if (!filter->flag) {
+ encoding = filter->encoding;
+ break;
+ }
+ }
+ }
+
/* cleanup */
/* dtors should be called in reverse order */
i = num; while (--i >= 0) {
[2005-12-16 17:51:13] [EMAIL PROTECTED]
Moriyoshi, if ext/mbstring is not maintained anymore, please let us
know.
[2005-12-16 17:18:27] matteo at beccati dot com
Description:
I was evaluating the mbstring extension because of its capabilities to
filter and convert input parameter to the correct encoding. During my
test I found out that an ISO-8859-1 string which ends with an an
accented character is wrongly detected as UTF-8, even if it ends with
an incomplete multibyte character (using iconv to convert the string
raises such notice).
Also reproduced with PHP 4.3.11 on FreeBSD 4 and 5.0.2 on Win32.
Reproduce code:
---
Expected result:
Trying: string(7) "Test: à"
Notice: iconv(): Detected an incomplete multibyte character in input
string in test.php on line 13
Detected encoding: ISO-8859-1
Converted string:string(8) "Test: Ã "
Trying: string(8) "Test: àa"
Notice: iconv(): Detected an illegal character in input string in
/var/www/mbstring/test.php on line 13
Detected encoding: ISO-8859-1
Converted string:string(9) "Test: Ã a"
Actual result:
--
Trying: string(7) "Test: à"
Notice: iconv(): Detected an incomplete multibyte character in input
string in test.php on line 13
Detected encoding: UTF-8
Converted string:string(6) "Test: "
Trying: string(8) "Test: àa"
Notice: iconv(): Detected an illegal character in input string in
/var/www/mbstring/test.php on line 13
Detected encoding: ISO-8859-1
Converted string:string(9) "Test: Ã a"
--
Edit this bug report at http://bugs.php.net/?id=35711&edit=1
#27132 [Opn->Asn]: ncurses_getch() interrupted by receipt of a handled signal
ID: 27132
Updated by: [EMAIL PROTECTED]
Reported By: neuhauser at chello dot cz
-Status: Open
+Status: Assigned
Bug Type: ncurses related
Operating System: *
PHP Version: 5CVS, 4CVS (2004-02-25)
Assigned To: hholzgra
New Comment:
Hartmut: If you're not going to do anything about this, please
de-assign it with some comment. And preferrably move the whole
extension to PECL the same time..
Previous Comments:
[2004-02-03 09:51:52] neuhauser at chello dot cz
Description:
receipt of a signal interrupts ncurses_getch(), which
should never happen
curs_getch(3X):
The behavior of getch and friends in the presence
of handled signals is unspecified in the SVr4 and
XSI Curses documentation. Under historical curses
implementations, it varied depending on whether
the operating system's implementation of handled
signal receipt interrupts a read(2) call in
progress or not, and also (in some implementations)
depending on whether an input timeout or
non-blocking mode hsd been set.
Programmers concerned about portability should be
prepared for either of two cases: (a) signal
receipt does not interrupt getch; (b) signal
receipt interrupts getch and causes it to return
ERR with errno set to EINTR.
Under the ncurses implementation, handled signals
never interrupt getch.
(emphasis added)
Reproduce code:
---
compare the behavior of this PHP snippet
#include
#include
int c;
void sigalrm()
{
char s[40];
sprintf(s, "sigalrm: '%d'\n", c);
addstr(s);
refresh();
}
int main(int argc, char** argv)
{
initscr();
cbreak();
nl();
noecho();
signal(SIGALRM, sigalrm);
for (;;) {
alarm(1);
c = getch();
if ('q' == c) {
return 0;
}
}
endwin();
return 0;
}
Expected result:
I was expecting to see the same output as given by the C version:
single
sigalrm: '0'
line until next keypress, then the zero would be replaced with ascii
code of the pressed key
Actual result:
--
endless series of
sigalrm: '-1'
lines, which suggests that receipt of the alarm, although handled,
interrupts the getch() call which then returns ERR.
(as a sidenote, http://www.php.net/manual/en/ref.ncurses.php says "On
error ncurses functions return NCURSES_ERR", but said constant doesn't
exist in 4.3.3 or 4.3.4, both cli)
--
Edit this bug report at http://bugs.php.net/?id=27132&edit=1
#27132 [Asn->Opn]: ncurses_getch() interrupted by receipt of a handled signal
ID: 27132
Updated by: [EMAIL PROTECTED]
Reported By: neuhauser at chello dot cz
-Status: Assigned
+Status: Open
Bug Type: ncurses related
Operating System: *
PHP Version: 5CVS, 4CVS (2004-02-25)
Assigned To: hholzgra
Previous Comments:
[2004-02-03 09:51:52] neuhauser at chello dot cz
Description:
receipt of a signal interrupts ncurses_getch(), which
should never happen
curs_getch(3X):
The behavior of getch and friends in the presence
of handled signals is unspecified in the SVr4 and
XSI Curses documentation. Under historical curses
implementations, it varied depending on whether
the operating system's implementation of handled
signal receipt interrupts a read(2) call in
progress or not, and also (in some implementations)
depending on whether an input timeout or
non-blocking mode hsd been set.
Programmers concerned about portability should be
prepared for either of two cases: (a) signal
receipt does not interrupt getch; (b) signal
receipt interrupts getch and causes it to return
ERR with errno set to EINTR.
Under the ncurses implementation, handled signals
never interrupt getch.
(emphasis added)
Reproduce code:
---
compare the behavior of this PHP snippet
#include
#include
int c;
void sigalrm()
{
char s[40];
sprintf(s, "sigalrm: '%d'\n", c);
addstr(s);
refresh();
}
int main(int argc, char** argv)
{
initscr();
cbreak();
nl();
noecho();
signal(SIGALRM, sigalrm);
for (;;) {
alarm(1);
c = getch();
if ('q' == c) {
return 0;
}
}
endwin();
return 0;
}
Expected result:
I was expecting to see the same output as given by the C version:
single
sigalrm: '0'
line until next keypress, then the zero would be replaced with ascii
code of the pressed key
Actual result:
--
endless series of
sigalrm: '-1'
lines, which suggests that receipt of the alarm, although handled,
interrupts the getch() call which then returns ERR.
(as a sidenote, http://www.php.net/manual/en/ref.ncurses.php says "On
error ncurses functions return NCURSES_ERR", but said constant doesn't
exist in 4.3.3 or 4.3.4, both cli)
--
Edit this bug report at http://bugs.php.net/?id=27132&edit=1
#35447 [Opn->Asn]: xml_parse_into_struct() chokes on the UTF-8 BOM
ID: 35447 Updated by: [EMAIL PROTECTED] Reported By: saramaca at libertysurf dot fr -Status: Open +Status: Assigned Bug Type: XML related Operating System: * PHP Version: 5.1.1 Assigned To: rrichards New Comment: Rob, what's the status with this? Previous Comments: [2005-11-28 20:28:32] [EMAIL PROTECTED] As far as the default attribute values - have to check on expat behavior. The other issue is fixed with libxml2 2.6.18. I have a patch (http://www.ctindustries.net/patches/xml.compat.diff.txt) that looks like it should work around the issue with older libxml2 libs, but need more testing with different encoding/BOM schemes to make sure it doesnt break anything as were playing with the libxml encoding handling here. [2005-11-28 18:03:18] [EMAIL PROTECTED] expat vs libxml2 incompatibility? [2005-11-28 14:55:33] saramaca at libertysurf dot fr Description: In PHP4 xml_parse_into_struct() can parse an UTF-8-encoded XML file with or without a UTF-8 BOM (\xEF\xBB\xBF). In PHP 5, this is no longer the case and it raises an error saying the string doesn't contain any XML data (Empty document). Additionally PHP 5's xml_parse_into_struct() does *NOT* place default attribute values into the struct (e.g. despite the DTD provided, $content[1]['attributes']['type'] isn't set to "literal" in actual result section below ; please compare it to expected result.) This used to work under PHP 4.1.x and above (but the parser is based on expat AFAIK.) PS: I guess "manually" stripping this magic number -- if embedded -- before calling the function would yield the expected result. However I found an acceptable work-around that seems to work equally well across versions 4 and 5 of PHP : Rather than: Reproduce code: --- http://www.diptyque.net/bugs/utf8_bom.php ; running PHP 4 --> outputs expected result http://www.diptyque.net/bugs/utf8_bom.phps ; source code Expected result: w/ autodetect --> Array ( [0] => Array ( [tag] => bundle [type] => open [level] => 1 [value] => ) [1] => Array ( [tag] => resource [type] => complete [level] => 2 [attributes] => Array ( [key] => rSeeYou [type] => literal ) [value] => A bient&244;t ) [2] => Array ( [tag] => bundle [value] => [type] => cdata [level] => 1 ) [3] => Array ( [tag] => bundle [type] => close [level] => 1 ) ) w/o autodetect --> Array ( [0] => Array ( [tag] => bundle [type] => open [level] => 1 [value] => ) [1] => Array ( [tag] => resource [type] => complete [level] => 2 [attributes] => Array ( [key] => rSeeYou [type] => literal ) [value] => A bient&244;t ) [2] => Array ( [tag] => bundle [value] => [type] => cdata [level] => 1 ) [3] => Array ( [tag] => bundle [type] => close [level] => 1 ) ) Actual result: -- w/ autodetect --> Array ( [0] => Array ( [tag] => bundle [type] => open [level] => 1 [value] => ) [1] => Array ( [tag] => resource [type] => complete [level] => 2 [attributes] => Array ( [key] => rSeeYou ) [value] => A bient&244;t ) [2] => Array ( [tag] => bundle [value] => [type] => cdata [level] => 1 ) [3] => Array ( [tag] => bundle [type] => close [level] => 1 ) ) w/o autodetect --> Empty document -- Edit this bug report at http://bugs.php.net/?id=35447&edit=1
#35447 [Asn->Opn]: xml_parse_into_struct() chokes on the UTF-8 BOM
ID: 35447 Updated by: [EMAIL PROTECTED] Reported By: saramaca at libertysurf dot fr -Status: Assigned +Status: Open Bug Type: XML related Operating System: * PHP Version: 5.1.1 Assigned To: rrichards Previous Comments: [2005-11-28 20:28:32] [EMAIL PROTECTED] As far as the default attribute values - have to check on expat behavior. The other issue is fixed with libxml2 2.6.18. I have a patch (http://www.ctindustries.net/patches/xml.compat.diff.txt) that looks like it should work around the issue with older libxml2 libs, but need more testing with different encoding/BOM schemes to make sure it doesnt break anything as were playing with the libxml encoding handling here. [2005-11-28 18:03:18] [EMAIL PROTECTED] expat vs libxml2 incompatibility? [2005-11-28 14:55:33] saramaca at libertysurf dot fr Description: In PHP4 xml_parse_into_struct() can parse an UTF-8-encoded XML file with or without a UTF-8 BOM (\xEF\xBB\xBF). In PHP 5, this is no longer the case and it raises an error saying the string doesn't contain any XML data (Empty document). Additionally PHP 5's xml_parse_into_struct() does *NOT* place default attribute values into the struct (e.g. despite the DTD provided, $content[1]['attributes']['type'] isn't set to "literal" in actual result section below ; please compare it to expected result.) This used to work under PHP 4.1.x and above (but the parser is based on expat AFAIK.) PS: I guess "manually" stripping this magic number -- if embedded -- before calling the function would yield the expected result. However I found an acceptable work-around that seems to work equally well across versions 4 and 5 of PHP : Rather than: Reproduce code: --- http://www.diptyque.net/bugs/utf8_bom.php ; running PHP 4 --> outputs expected result http://www.diptyque.net/bugs/utf8_bom.phps ; source code Expected result: w/ autodetect --> Array ( [0] => Array ( [tag] => bundle [type] => open [level] => 1 [value] => ) [1] => Array ( [tag] => resource [type] => complete [level] => 2 [attributes] => Array ( [key] => rSeeYou [type] => literal ) [value] => A bient&244;t ) [2] => Array ( [tag] => bundle [value] => [type] => cdata [level] => 1 ) [3] => Array ( [tag] => bundle [type] => close [level] => 1 ) ) w/o autodetect --> Array ( [0] => Array ( [tag] => bundle [type] => open [level] => 1 [value] => ) [1] => Array ( [tag] => resource [type] => complete [level] => 2 [attributes] => Array ( [key] => rSeeYou [type] => literal ) [value] => A bient&244;t ) [2] => Array ( [tag] => bundle [value] => [type] => cdata [level] => 1 ) [3] => Array ( [tag] => bundle [type] => close [level] => 1 ) ) Actual result: -- w/ autodetect --> Array ( [0] => Array ( [tag] => bundle [type] => open [level] => 1 [value] => ) [1] => Array ( [tag] => resource [type] => complete [level] => 2 [attributes] => Array ( [key] => rSeeYou ) [value] => A bient&244;t ) [2] => Array ( [tag] => bundle [value] => [type] => cdata [level] => 1 ) [3] => Array ( [tag] => bundle [type] => close [level] => 1 ) ) w/o autodetect --> Empty document -- Edit this bug report at http://bugs.php.net/?id=35447&edit=1
#35612 [Asn->Fbk]: [PATCH] iis6 Access Violation crash
ID: 35612
Updated by: [EMAIL PROTECTED]
Reported By: alacn dot uhahaa at gmail dot com
-Status: Assigned
+Status: Feedback
Bug Type: IIS related
Operating System: Windows Server 2003
PHP Version: 5.1.1
Assigned To: dmitry
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
And this time, really make sure you have the right PHP installed. Only
way to be sure is to delete ALL old dlls related to PHP. Especially
from C:\windows\ directory.
Also, make any patches against the latest CVS sources. PHP 4 is too
old.
Previous Comments:
[2005-12-13 11:15:11] alacn dot uhahaa at gmail dot com
its not fixed in cvs (php5.1-200512130930)
udiff for php4:
--- php4.4.1_zend_execute_API.c Tue Aug 02 14:52:34 2005
+++ php4.4.1_fixed_zend_execute_API.c Tue Dec 13 08:11:36 2005
@@ -52,6 +52,7 @@
static HANDLE timeout_thread_event;
static DWORD timeout_thread_id;
static int timeout_thread_initialized=0;
+static HANDLE timeout_thread_finish_event; // alacn
#endif
@@ -813,6 +814,9 @@
}
DestroyWindow(timeout_window);
UnregisterClass(wc.lpszClassName, NULL);
+
+ SetEvent(timeout_thread_finish_event); // alacn
+
return 0;
}
@@ -820,6 +824,7 @@
void zend_init_timeout_thread()
{
timeout_thread_event = CreateEvent(NULL, FALSE, FALSE, NULL);
+ timeout_thread_finish_event = CreateEvent(0, 0, 0, 0); // alacn
_beginthreadex(NULL, 0, timeout_thread_proc, NULL, 0,
&timeout_thread_id);
WaitForSingleObject(timeout_thread_event, INFINITE);
}
@@ -831,6 +836,8 @@
return;
}
PostThreadMessage(timeout_thread_id, WM_QUIT, 0, 0);
+
+ WaitForSingleObject(timeout_thread_finish_event, 3); // alacn
}
#endif
[2005-12-13 09:13:43] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2005-12-12 19:46:58] [EMAIL PROTECTED]
Reassigned to Dmitry.
[2005-12-12 19:17:26] alacn dot uhahaa at gmail dot com
at cvs its:
timeout_thread_handle = _beginthreadex(..);
and
WaitForSingleObject(timeout_thread_handle, 5000);
but this wont work right, because the thread that created the
timeout_thread is not the same that will wait it finish, so, if you
check, WaitForSingleObject will always result WAIT_OBJECT_TIMEOUT
instead of WAIT_OBJECT_0
thats why it should wait using an event object instead of thread
handle
also, it should be at least 30 secs, because 5 secs is not enough, with
an event object (instead of thread handle), it will finish before the 30
secs as it should be
--- php5.1.1_zend_execute_API.c Thu Nov 24 09:33:12 2005
+++ php5.1.1_fixed_zend_execute_API.c Fri Dec 09 10:38:58 2005
@@ -48,6 +48,7 @@
static HANDLE timeout_thread_event;
static DWORD timeout_thread_id;
static int timeout_thread_initialized=0;
+static HANDLE timeout_thread_finish_event; // alacn
#endif
#if ZEND_DEBUG
@@ -1255,6 +1256,9 @@
}
DestroyWindow(timeout_window);
UnregisterClass(wc.lpszClassName, NULL);
+
+ SetEvent(timeout_thread_finish_event); // alacn
+
return 0;
}
@@ -1262,6 +1266,7 @@
void zend_init_timeout_thread()
{
timeout_thread_event = CreateEvent(NULL, FALSE, FALSE, NULL);
+ timeout_thread_finish_event = CreateEvent(0, 0, 0, 0); // alacn
_beginthreadex(NULL, 0, timeout_thread_proc, NULL, 0,
&timeout_thread_id);
WaitForSingleObject(timeout_thread_event, INFINITE);
}
@@ -1273,6 +1278,8 @@
return;
}
PostThreadMessage(timeout_thread_id, WM_QUIT, 0, 0);
+
+ WaitForSingleObject(timeout_thread_finish_event, 3); // alacn
}
#endif
[2005-12-09 19:11:13] [EMAIL PROTECTED]
Fixed in CVS HEAD, PHP_5_1 and PHP_5_0.
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/35612
--
Edit this bug report at http://bugs.php.net/?id=35612&edit=1
#35711 [Asn->Fbk]: [PATCH] ISO-8859 charset not correctly detected
ID: 35711
Updated by: [EMAIL PROTECTED]
Reported By: matteo at beccati dot com
-Status: Assigned
+Status: Feedback
Bug Type: mbstring related
Operating System: Debian GNU/Linux
PHP Version: 5.1.1
Assigned To: moriyoshi
New Comment:
Please provide any patches in unified diff format. (like the first
one). And downloadable somewhere.
Previous Comments:
[2005-12-17 10:13:11] matteo at beccati dot com
Improved patch to also work with mbstring.encoding_translation
enabled.
Index: ext/mbstring/libmbfl/mbfl/mbfilter.c
===
RCS file: /repository/php-src/ext/mbstring/libmbfl/mbfl/mbfilter.c,v
retrieving revision 1.7.2.1
diff -r1.7.2.1 mbfilter.c
443c443
< if (!filter->flag) {
---
> if (!filter->flag && !filter->status) {
447a448,458
>
> if (encoding == mbfl_no_encoding_invalid) {
> n = identd->filter_list_size - 1;
> while (n >= 0) {
> filter = identd->filter_list[n];
> if (!filter->flag) {
> encoding =
filter->encoding->no_encoding;
> }
> n--;
> }
> }
578c589
< if (!filter->flag) {
---
> if (!filter->flag && !filter->status) {
583a595,604
> if (!encoding) {
> for (i = 0; i < num; i++) {
> filter = &flist[i];
> if (!filter->flag) {
> encoding = filter->encoding;
> break;
> }
> }
> }
>
[2005-12-16 23:50:13] matteo at beccati dot com
I've made a patch which seems to fix the issue. It basicly checks
filter status during judgement. Status seems to be != 0 only when it is
matching a multibyte character. I added anyway a fallback to the old
judgement routine, just in case no matching encoding is found.
Index: ext/mbstring/libmbfl/mbfl/mbfilter.c
===
RCS file: /repository/php-src/ext/mbstring/libmbfl/mbfl/mbfilter.c,v
retrieving revision 1.7.2.1
diff -u -r1.7.2.1 mbfilter.c
--- ext/mbstring/libmbfl/mbfl/mbfilter.c5 Nov 2005 04:49:57
- 1.7.2.1
+++ ext/mbstring/libmbfl/mbfl/mbfilter.c16 Dec 2005 22:46:26
-
@@ -575,12 +575,22 @@
for (i = 0; i < num; i++) {
filter = &flist[i];
- if (!filter->flag) {
+ if (!filter->flag && !filter->status) {
encoding = filter->encoding;
break;
}
}
+ if (!encoding) {
+ for (i = 0; i < num; i++) {
+ filter = &flist[i];
+ if (!filter->flag) {
+ encoding = filter->encoding;
+ break;
+ }
+ }
+ }
+
/* cleanup */
/* dtors should be called in reverse order */
i = num; while (--i >= 0) {
[2005-12-16 17:51:13] [EMAIL PROTECTED]
Moriyoshi, if ext/mbstring is not maintained anymore, please let us
know.
[2005-12-16 17:18:27] matteo at beccati dot com
Description:
I was evaluating the mbstring extension because of its capabilities to
filter and convert input parameter to the correct encoding. During my
test I found out that an ISO-8859-1 string which ends with an an
accented character is wrongly detected as UTF-8, even if it ends with
an incomplete multibyte character (using iconv to convert the string
raises such notice).
Also reproduced with PHP 4.3.11 on FreeBSD 4 and 5.0.2 on Win32.
Reproduce code:
---
Expected result:
Trying: string(7) "Test: à"
Notice: iconv(): Detected an incomplete multibyte character in input
string in test.php on line 13
Detected encoding: ISO-8859-1
Converted string:string(8) "Test: Ã "
Trying: string(8) "Test: àa"
Notice: iconv(): Detected an illegal character in input string in
/var/www/mbstring/test.php on line 13
Detected encoding: ISO-8859-1
Converted string:string(9) "Test: Ã a"
Actual result:
--
Trying: string(7) "Test: à"
Notice: iconv(): Detected an incomplete multibyte character in input
string in test.php on line 13
Detected encoding: UTF-8
Converted string:string(6) "Test: "
Trying: string(8) "Test: àa"
Notice: iconv(): Detected an illegal character in input string in
/var/www/mbstring/t
#35730 [Opn->Bgs]: mssql didn't use the right character encoding in freetds.conf
ID: 35730 Updated by: [EMAIL PROTECTED] Reported By: liang at saga-city dot com -Status: Open +Status: Bogus Bug Type: MSSQL related Operating System: FreeBSD PHP Version: 5.1.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: [2005-12-19 05:48:08] liang at saga-city dot com we have been testing the mssql extension both in PHP4 and PHP5.1.1, " with the same freetds.conf " tds version = 8.0 client charset = BIG-5 In php4, it works fine, but not in php5.1.1 ( our old system uses php5.0.3 also work fine in the "same" freetds.conf ) [2005-12-19 03:27:06] [EMAIL PROTECTED] All encoding is handled by freetds in both PHP4 and PHP5. Execpt for internal PHP stuff the mssql extension is the same for PHP4 and PHP5. You need to change the encoding in freetds.conf. [2005-12-19 02:29:00] liang at saga-city dot com Description: php5 mssql didn't use character encoding specify in freetds.conf ( alwasy use ISO-8559-1 , seen in freetds.log ) switch to php4 , everythings works fine -- Edit this bug report at http://bugs.php.net/?id=35730&edit=1
#35723 [Opn->Csd]: xmlrpc_introspection.c fails compile per C99 std
ID: 35723
Updated by: [EMAIL PROTECTED]
Reported By: richton at nbcs dot rutgers dot edu
-Status: Open
+Status: Closed
Bug Type: Compile Failure
Operating System: irrelevant
PHP Version: 5CVS-2005-12-18 (snap)
New Comment:
This bug has been fixed in CVS.
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:
[2005-12-18 17:56:31] richton at nbcs dot rutgers dot edu
Sun Studio. It's free (as in beer) now, you can download it
from sun.com. Linker is the standard Solaris 9 linker, latest
patch 112963-25. However this shouldn't be a compiler issue as
it's written into the standard. (admittedly there's a lot of
non-C99 compliant gcc out there, but...)
[2005-12-18 11:32:40] [EMAIL PROTECTED]
What compiler and linker are you using?
[2005-12-18 05:00:20] richton at nbcs dot rutgers dot edu
Description:
ext/xmlrpc/libxmlrpc/xmlrpc_introspection.c has a couple
inline functions:
inline XMLRPC_VALUE find_named_value(XMLRPC_VALUE list, const
char* needle) {
inline void describe_method(XMLRPC_SERVER server, XMLRPC_VALUE
vector, const char* method) {
They are referenced elsewhere in the file, but there is no
external definition. See C99 specification section 6.7.4.
An extra keyword here would go a long way...
Reproduce code:
---
make
Expected result:
successful compile
Actual result:
--
Undefined first referenced
symbol in file
find_named_valueext/xmlrpclibxmlrpc/.libs/
xmlrpc_introspection.o
describe_method ext/xmlrpclibxmlrpc/.libs/
xmlrpc_introspection.o
ld: fatal: Symbol referencing errors. No output written to
sapi/cli/php
--
Edit this bug report at http://bugs.php.net/?id=35723&edit=1
#35329 [Asn->Bgs]: php.ini location changed between 5.0 and 5.1
ID: 35329 Updated by: [EMAIL PROTECTED] Reported By: cjbj at hotmail dot com -Status: Assigned +Status: Bogus Bug Type: *General Issues Operating System: win32 PHP Version: 5.1.0 Assigned To: wez New Comment: This is no bug, it has been documented like this forever: http://www.php.net/manual/en/configuration.php#configuration.file What you've relied upon was an undocumented bug. Previous Comments: [2005-12-13 01:38:12] stan64 at gmail dot com Ok, so I used filemon to see where it checked for php.ini. I put it in php root, that is in path and PHPIniDir. And it finds the file reads it and php don't work. I use the recommended ini configured like the last versions that worked. If I try to put it in Windows then... The read pattern is similiar for alot of scrolling but it never looks for php.ini outside of the php directory. PHP works and says it found the ini in the windows directory. Though the settings n phpinfo do NOT represent the ini I put there. [2005-12-13 01:13:50] stan64 at gmail dot com I have got this bug also on 2 systems with alot of installation methods and with both 5.0.4 and 5.1.1. First off PHP won't work if I set PHPIniDir to a wrong path other than the config file lies within. When it's pointed at the wrong location phpinfo says that it have found a ini file in the windows directory. Though it does not contain such a file. I try to put my file there and it don't read it. It still reads it imaginary file that is supposed to be located in the windows directory. I have read through the installation steps carefully, tried all helpful comments. Tried things I found on google. And all with the same result. [2005-11-28 17:10:28] [EMAIL PROTECTED] CWD (why it checked the Apache dir) is now only searched when running under CLI. Either this is really a bug or FAQ in the manual should be changed to say to use Apache/bin (path is checked in 5.0 and 5.1 at least since its the binary location). [2005-11-28 15:19:43] [EMAIL PROTECTED] Chris, can you try using filemon from sysinternals to see if it's trying to access alternate php.ini paths? [2005-11-23 02:54:38] cjbj at hotmail dot com When I upgraded from 5.5 to 5.1, I had to 0. Unzip 5.1 to c:\php5-win32-latest 1. Edit c:/Program Files/Apache Group/Apache2/conf/httpd.conf and change: LoadModule php5_module "c:/php5.0-win32-200511031730/php5apache2.dll" to LoadModule php5_module "c:/php5-win32-latest/php5apache2.dll" 2. Edit c:\Program Files\Apache Group\Apache2\php.ini and change: extension_dir = "c:\php5.0-win32-200511031730\ext" to extension_dir = "c:\php5-win32-latest\ext" 3. Copy c:\Program Files\Apache Group\Apache2\php.ini to c:\WINDOWS Step 3 was not needed when upgrading any 5.0.x to 5.0.y. 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/35329 -- Edit this bug report at http://bugs.php.net/?id=35329&edit=1
#35455 [Asn->Bgs]: php.ini <--> pear command
ID: 35455 Updated by: [EMAIL PROTECTED] Reported By: hardy at voos dot de -Status: Assigned +Status: Bogus Bug Type: PHP options/info functions Operating System: Linux PHP Version: 5.1.1 Assigned To: cellog New Comment: Since this is about PHP 5.1.1 and this is a PEAR bug -> bogus. Previous Comments: [2005-11-28 19:40:44] hardy at voos dot de Now I did "make install", renamed "php" binary to "php-cgi" and did "make install-cli" for the CLI binary. Then I changed the "Action ..." statement in Apache httpd.conf to reflect the new CGI binary path. Perhaps that is not correct doing, but it works. Also thanks for your very fast answers! Bye [2005-11-28 19:26:14] [EMAIL PROTECTED] this has nothing to do with phar, it is PEAR. We have a conundrum, because PHP 4.2 simply doesn't work if you pass -dregister_argc_argv=On, and 4.2 is the earliest officially supported version. As the question of supporting PHP 4.2 is a political and not a technical decision, I have to now drag over to pear-core and try to solve this one with the other developers. In the mean time, perhaps it is time to be sure that the cli version of PHP is installed with "make install"!! [2005-11-28 19:14:55] [EMAIL PROTECTED] Greg, obviously .phar has to check if it's CLI or CGI. Please, fix it. [2005-11-28 19:12:00] hardy at voos dot de - Extracted the source package to "/usr/local/php-5.1.1" - cd to that - mkdir "lokal" - ./configure --prefix=/usr/local/php-5.1.1/lokal --enableforce-cgi-redirect --enable-discard-path --disable-ipv6 --with-openssl --enable-mbstring --with-mysql=/usr/local/mysql-4.0.20/lokal --with-pgsql=/usr/local/postgresql-8.1.0/lokal --disable-inline-optimization - make - make install Output from "make install" is: Installing PHP SAPI module: cgi Installing PHP CGI into: /usr/local/php-5.1.1/lokal/bin/ Installing build environment: /usr/local/php-5.1.1/lokal/lib/php/build/ Installing header files: /usr/local/php-5.1.1/lokal/include/php/ Installing helper programs: /usr/local/php-5.1.1/lokal/bin/ program: phpize program: php-config Installing man pages: /usr/local/php-5.1.1/lokal/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/local/php-5.1.1/lokal/lib/php/ [PEAR] Archive_Tar- already installed: 1.3.1 [PEAR] Console_Getopt - already installed: 1.2 [PEAR] PEAR - already installed: 1.4.5 Wrote PEAR system config file at: /usr/local/php-5.1.1/lokal/etc/pear.conf You may want to add: /usr/local/php-5.1.1/lokal/lib/php to your php.ini include_path Installing PDO headers: /usr/local/php-5.1.1/lokal/include/php/ext/pdo/ [2005-11-28 19:04:36] [EMAIL PROTECTED] How exactly did you configure/install PHP? 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/35455 -- Edit this bug report at http://bugs.php.net/?id=35455&edit=1
#35714 [Opn->Fbk]: odbc_connect() does not timeout.
ID: 35714
Updated by: [EMAIL PROTECTED]
Reported By: ceason at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: ODBC related
Operating System: Linux
PHP Version: 5.1.1
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
And use the PDO ODBC driver instead.
Previous Comments:
[2005-12-16 21:13:50] ceason at gmail dot com
Description:
A php script that didn't check the odbc_connect return value entered a
state
where it did not end. The httpd server does not seem to time these
requests out
and reports the as "W" Sending Reply state. Eventually this causes
access
denial due to max_connection limit being reached. I upgraded to httpd
2.2.0 and
php 5.1.1 but the problem still occurs.
This is the timeout value from httpd.conf
#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 300
This is the timeout value from php.ini
max_execution_time = 120 ; Maximum execution time of each script,
in seconds
max_input_time = 60 ; Maximum amount of time each script may spend
parsing
request data
memory_limit = 8M ; Maximum amount of memory a script may consume
(8MB)
server-status entry:
0-0 27217 2/2/2 W 0.0032840 13.20.010.01
ceason madmax GET
/status/ras_results.php?db=bgs1&severityCB=1&facilityCB=1&b
I initially reported this as an Apache bug and received this response.
This is a bug in mod_php. If mod_php does not return the control of
execution
from the script, httpd can't do anytning. Please report this to the
PHP
Project, instead of Apache HTTP Server Project.
Reproduce code:
---
$dbconn = odbc_connect("BOGUS","username","password");
$query = "select * from footable";
while(odbc_fetch_row($result)) {
print"$result";
}
This may fail correct the 1st time. Hit refresh after this and it
should hang up.
Expected result:
Similiar error messages as below
Warning: odbc_connect() [function.odbc-connect]: SQL error: \EA, SQL
state D\$ in SQLConnect in /var/www/html/test.php on line 14
Warning: odbc_fetch_row(): supplied argument is not a valid ODBC result
resource in /var/www/html/test.php on line 16
Actual result:
--
Hang after refresh
--
Edit this bug report at http://bugs.php.net/?id=35714&edit=1
#35688 [Opn->Bgs]: Configure --with-mysqli failed for MySQL with library or lib version not found
ID: 35688
Updated by: [EMAIL PROTECTED]
Reported By: sfletcher at abcoa dot com
-Status: Open
+Status: Bogus
Bug Type: MySQLi related
Operating System: AIX 5.2
PHP Version: 5.1.1
New Comment:
You're using wrong libs within wrong architecture. And this is never
gonna be a PHP bug so stop reopening and call the IBM support
instead..
Previous Comments:
[2005-12-16 18:39:10] sfletcher at abcoa dot com
Installed the GNU Binutils and redo the configure with this new command
by enabling the --with-gnu-ld option.
--snip--
./configure --with-mysqli=/usr/local/mysql/bin/mysql_config
--with-apxs2=../../apache2/bin/apxs --with-unixODBC --with-openssl
--with-curl --with-gnu-ld --disable-libxml --disable-dom
--enable-track-vars --enable-ftp --enable-sockets
--snip--
Still get the configure failure.
--snip--
checking for mcrypt support... no
checking for mhash support... no
checking whether to include mime_magic support... no
checking for MING support... no
checking for msession support... no
checking for mSQL support... no
checking for MSSQL support via FreeTDS... no
checking for MySQL support... no
checking for specified location of the MySQL UNIX socket... no
checking for MySQLi support... yes
checking whether to enable embedded MySQLi support... no
checking for mysql_set_server_option in -lmysqlclient... no
configure: error: wrong mysql library version or lib not found. Check
config.log for more information.
--snip--
and the log file...
--snip--
configure:53543: checking for mcrypt support
configure:54372: checking for mhash support
configure:54844: checking whether to include mime_magic support
configure:55199: checking for MING support
configure:56122: checking for msession support
configure:56830: checking for mSQL support
configure:57339: checking for MSSQL support via FreeTDS
configure:57987: checking for MySQL support
configure:58033: checking for specified location of the MySQL UNIX
socket
configure:59186: checking for MySQLi support
configure:59232: checking whether to enable embedded MySQLi support
configure:59378: checking for mysql_set_server_option in -lmysqlclient
configure:59397: gcc -o conftest -g -O2
-Wl,-rpath,/usr/local/mysql/lib -L/usr/local/mysql/lib
-Wl,-rpath,/usr/local/ssl/lib -L/usr/local/ssl/lib
-Wl,-rpath,/usr/local/lib -L/usr/local/lib -lmysqlclient -lz -lcrypt
-lnsl_r -lm conftest.c -lmysqlclient -liconv -lssl -lcrypto -lcurl
-lssl -lcrypto -lm -lcurl -lssl -lcrypto 1>&5
/usr/local/lib/gcc-lib/powerpc-ibm-aix5.2.0.0/3.3.2/../../../../powerpc-ibm-aix5.2.0.0/bin/ld:
warning: powerpc:601 architecture of input file
`/usr/local/lib/gcc-lib/powerpc-ibm-aix5.2.0.0/3.3.2/libgcc.a(_divdi3.o)'
is incompatible with rs6000:6000 output
/usr/local/lib/gcc-lib/powerpc-ibm-aix5.2.0.0/3.3.2/../../../../powerpc-ibm-aix5.2.0.0/bin/ld:
warning: powerpc:601 architecture of input file
`/usr/local/lib/gcc-lib/powerpc-ibm-aix5.2.0.0/3.3.2/libgcc.a(_moddi3.o)'
is incompatible with rs6000:6000 output
/usr/local/lib/gcc-lib/powerpc-ibm-aix5.2.0.0/3.3.2/../../../../powerpc-ibm-aix5.2.0.0/bin/ld:
warning: powerpc:601 architecture of input file
`/usr/local/lib/gcc-lib/powerpc-ibm-aix5.2.0.0/3.3.2/libgcc.a(_udivdi3.o)'
is incompatible with rs6000:6000 output
/usr/local/lib/gcc-lib/powerpc-ibm-aix5.2.0.0/3.3.2/../../../../powerpc-ibm-aix5.2.0.0/bin/ld:
warning: powerpc:601 architecture of input file
`/usr/local/lib/gcc-lib/powerpc-ibm-aix5.2.0.0/3.3.2/libgcc.a(_umoddi3.o)'
is incompatible with rs6000:6000 output
/usr/local/lib/gcc-lib/powerpc-ibm-aix5.2.0.0/3.3.2/../../../../powerpc-ibm-aix5.2.0.0/bin/ld:
warning: powerpc:601 architecture of input file
`/usr/local/lib/gcc-lib/powerpc-ibm-aix5.2.0.0/3.3.2/libgcc.a(_udivmoddi4.o)'
is incompatible with rs6000:6000 output
/usr/local/lib/gcc-lib/powerpc-ibm-aix5.2.0.0/3.3.2/../../../../powerpc-ibm-aix5.2.0.0/bin/ld:
warning: powerpc:601 architecture of input file
`/usr/local/lib/gcc-lib/powerpc-ibm-aix5.2.0.0/3.3.2/libgcc_eh.a(unwind-dw2.o)'
is incompatible with rs6000:6000 output
/usr/local/lib/gcc-lib/powerpc-ibm-aix5.2.0.0/3.3.2/../../../../powerpc-ibm-aix5.2.0.0/bin/ld:
warning: powerpc:601 architecture of input file
`/usr/local/lib/gcc-lib/powerpc-ibm-aix5.2.0.0/3.3.2/libgcc_eh.a(unwind-dw2-fde.o)'
is incompatible with rs6000:6000 output
/tmp//cc0rNEYc.o(.pr+0xc): In function `.main':
conftest.c:59393: undefined reference to `.mysql_set_server_option'
collect2: ld returned 1 exit status
configure: failed program was:
#line 59386 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char mysql_set_server_option();
int main() {
mysql_set_server_option()
; return 0; }
--snip--
Since the GNU ld is working. So, re-opening the bug. I'm not trying
to a
#35713 [Opn->Bgs]: cannot use isset or other on variables indexed by a numerical string
ID: 35713
Updated by: [EMAIL PROTECTED]
Reported By: nalkat at yahoo dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 5.1.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:
[2005-12-16 17:30:38] nalkat at yahoo dot com
Description:
When dealing with arrays indexed by a numerical string (i.e.
$array['1']) and then attempting to use isset or similar on the value,
results are not as expected.
As you can see from the example below, it would be impossible to use
something such as:
$opts = getopt("1:2:a:b:");
if (isset($opts['1'])) {
do_something();
}
if (isset($opts['2'])) {
do_something_else();
}
if (isset($opts['a'])) {
echo "works\n";
}
...
...
Reproduce code:
---
(host)# php -q test.php -1 hi -a bye
Expected result:
EXPECTED:
---
it worked for 1!
it worked for a!
array(2) {
["1"]=>
string(2) "hi"
["a"]=>
string(3) "bye"
}
Actual result:
--
ACTUAL:
---
it worked for a!
array(2) {
["1"]=>
string(2) "hi"
["a"]=>
string(3) "bye"
}
--
Edit this bug report at http://bugs.php.net/?id=35713&edit=1
#35711 [Opn->Asn]: ISO-8859 charset not correctly detected when
ID: 35711 Updated by: [EMAIL PROTECTED] Reported By: matteo at beccati dot com -Status: Open +Status: Assigned Bug Type: mbstring related Operating System: Debian GNU/Linux PHP Version: 5.1.1 -Assigned To: +Assigned To: moriyoshi New Comment: Moriyoshi, if ext/mbstring is not maintained anymore, please let us know. Previous Comments: [2005-12-16 17:18:27] matteo at beccati dot com Description: I was evaluating the mbstring extension because of its capabilities to filter and convert input parameter to the correct encoding. During my test I found out that an ISO-8859-1 string which ends with an an accented character is wrongly detected as UTF-8, even if it ends with an incomplete multibyte character (using iconv to convert the string raises such notice). Also reproduced with PHP 4.3.11 on FreeBSD 4 and 5.0.2 on Win32. Reproduce code: --- Expected result: Trying: string(7) "Test: à" Notice: iconv(): Detected an incomplete multibyte character in input string in test.php on line 13 Detected encoding: ISO-8859-1 Converted string:string(8) "Test: Ã " Trying: string(8) "Test: àa" Notice: iconv(): Detected an illegal character in input string in /var/www/mbstring/test.php on line 13 Detected encoding: ISO-8859-1 Converted string:string(9) "Test: Ã a" Actual result: -- Trying: string(7) "Test: à" Notice: iconv(): Detected an incomplete multibyte character in input string in test.php on line 13 Detected encoding: UTF-8 Converted string:string(6) "Test: " Trying: string(8) "Test: àa" Notice: iconv(): Detected an illegal character in input string in /var/www/mbstring/test.php on line 13 Detected encoding: ISO-8859-1 Converted string:string(9) "Test: Ã a" -- Edit this bug report at http://bugs.php.net/?id=35711&edit=1
#35710 [Opn->Bgs]: get_browser returns false
ID: 35710
Updated by: [EMAIL PROTECTED]
Reported By: mike at blueroot dot co dot uk
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Linux
PHP Version: 5.1.1
New Comment:
I meant bug #27372 which is the root issue.
Previous Comments:
[2005-12-16 16:47:44] mike at blueroot dot co dot uk
open
[2005-12-16 16:46:10] mike at blueroot dot co dot uk
Do you mean bug #8419?
I thought this bug report was a little old to be re-opening (it is from
2000!). I think its unlikely that a bug that affected php 4.0.1 would
still be valid in 2005 got php 5.1.1 (and 5.0.4).
The 'resolution' for that bug was also vague.
"Please try current CVS, it has browscap behaviour fixed. If
it still fails, please repoen and provide your bworscap.ini
file (or where I can get the same one)."
I have searched for other bugs relating to get_browser and nothing is
the same as this one, except for this relic.
Maybe you can add a note for this bug to say which the duplicate is and
also maybe point towards the solution (#8419 certainly doesnt help)
[2005-12-16 16:33:37] [EMAIL PROTECTED]
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.
[2005-12-16 16:25:14] mike at blueroot dot co dot uk
Description:
get_browser() returns false when given valid parameters. browscap.ini
is the latest downloaded from
http://www.garykeith.com/browsers/downloads.asp
browscap is set correctly in php.ini and shows in phpinfo()
Reproduce code:
---
echo count(file(ini_get('browscap')))."";
$browser = get_browser('Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7) Gecko/20040803 Firefox/0.9.3', true);
var_dump($browser);
The first line shows that the browscap.ini file is being read properly
# wc -l /php5/lib/browscap.ini
14296 /php5/lib/browscap.ini
Expected result:
14296
Array
(
[browser_name_regex] => ^mozilla/5\.0 (windows; .; windows nt 5\.1;
.*rv:.*) gecko/.* firefox/0\.9.*$
[browser_name_pattern] => Mozilla/5.0 (Windows; ?; Windows NT 5.1;
*rv:*) Gecko/* Firefox/0.9*
[parent] => Firefox 0.9
[platform] => WinXP
[browser] => Firefox
[version] => 0.9
[majorver] => 0
[minorver] => 9
[css] => 2
[frames] => 1
[iframes] => 1
[tables] => 1
[cookies] => 1
[backgroundsounds] =>
[vbscript] =>
[javascript] => 1
[javaapplets] => 1
[activexcontrols] =>
[cdf] =>
[aol] =>
[beta] => 1
[win16] =>
[crawler] =>
[stripper] =>
[wap] =>
[netclr] =>
)
Actual result:
--
14296
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=35710&edit=1
#35706 [Opn->Fbk]: Constants defined even when they are no randomly
ID: 35706
Updated by: [EMAIL PROTECTED]
Reported By: andy at mandlnet dot co dot uk
-Status: Open
+Status: Feedback
Bug Type: Unknown/Other Function
Operating System: Linux
PHP Version: 4.4.1
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Previous Comments:
[2005-12-16 16:28:29] andy at mandlnet dot co dot uk
I have now downgraded to 4.3.10 so can not provide you with a URL for
examples however, If you create a new virtual host and a script
containing the following:
Visit this site and then using a different virtual server on the same
physical server use the script posted earlier to display all
constants.
You may have to reload each page a few times before the constants are
displayed, but it does eventually.
[2005-12-16 11:41:38] [EMAIL PROTECTED]
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 possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-12-16 11:31:39] andy at mandlnet dot co dot uk
Description:
Defined constants appear to carry over occasionally between sites on
the same server. We have downgraded to PHP 4.3.10 now and this has
fixed the problem.
Reproduce code:
---
$value) {
printf("%s = ", $key);
var_dump($value);
}
?>
Expected result:
Sometimes you will get just a normal result, if you have a site on the
same server that uses defined constants sometimes they appear at the
bottom.
It should display all defined constants from
E_ERROR = int(1) to GD_BUNDLED = int(0) as no others have been defined
in our script.
Actual result:
--
Occasionally we got :
CMS_VERSION_MAJ = int(4) CMS_VERSION_MIN = int(0) CMS_VERSION_INC =
int(3) CMS_VERSION = string(5) "4.0.3" CMS_CONFIG_SITENAME = string(11)
"" CMS_CONFIG_CHIEF_EMAIL = string(21) ""
CMS_CONFIG_ADMIN_CLIENTHELPCONTACT = string(58) ""
as well as constants defined for database conectivity. (username and
password) from other virtual hosts on the same server.
--
Edit this bug report at http://bugs.php.net/?id=35706&edit=1
#35710 [Opn->Bgs]: get_browser returns false
ID: 35710
Updated by: [EMAIL PROTECTED]
Reported By: mike at blueroot dot co dot uk
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Linux
PHP Version: 5.1.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.
Previous Comments:
[2005-12-16 16:25:14] mike at blueroot dot co dot uk
Description:
get_browser() returns false when given valid parameters. browscap.ini
is the latest downloaded from
http://www.garykeith.com/browsers/downloads.asp
browscap is set correctly in php.ini and shows in phpinfo()
Reproduce code:
---
echo count(file(ini_get('browscap')))."";
$browser = get_browser('Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7) Gecko/20040803 Firefox/0.9.3', true);
var_dump($browser);
The first line shows that the browscap.ini file is being read properly
# wc -l /php5/lib/browscap.ini
14296 /php5/lib/browscap.ini
Expected result:
14296
Array
(
[browser_name_regex] => ^mozilla/5\.0 (windows; .; windows nt 5\.1;
.*rv:.*) gecko/.* firefox/0\.9.*$
[browser_name_pattern] => Mozilla/5.0 (Windows; ?; Windows NT 5.1;
*rv:*) Gecko/* Firefox/0.9*
[parent] => Firefox 0.9
[platform] => WinXP
[browser] => Firefox
[version] => 0.9
[majorver] => 0
[minorver] => 9
[css] => 2
[frames] => 1
[iframes] => 1
[tables] => 1
[cookies] => 1
[backgroundsounds] =>
[vbscript] =>
[javascript] => 1
[javaapplets] => 1
[activexcontrols] =>
[cdf] =>
[aol] =>
[beta] => 1
[win16] =>
[crawler] =>
[stripper] =>
[wap] =>
[netclr] =>
)
Actual result:
--
14296
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=35710&edit=1
#35702 [Opn->Fbk]: print_r(NAN) return NaNQ(1) , but it should be NAN , right?
ID: 35702 Updated by: [EMAIL PROTECTED] Reported By: samuelkid at citiz dot net -Status: Open +Status: Feedback Bug Type: Variables related Operating System: EBCDIC platform PHP Version: 5.1.1 New Comment: And what OS/Platform is it? Previous Comments: [2005-12-16 10:26:06] samuelkid at citiz dot net Description: print_r(NAN) return NaNQ(1) , but it should be NAN , right? Is it platform related? my operating system is based on EBCDIC not ASCII Reproduce code: --- print_r(NAN) Expected result: NAN Actual result: -- NANQ(1) -- Edit this bug report at http://bugs.php.net/?id=35702&edit=1
#35688 [Opn->Bgs]: Configure --with-mysqli failed for MySQL with library or lib version not found
ID: 35688
Updated by: [EMAIL PROTECTED]
Reported By: sfletcher at abcoa dot com
-Status: Open
+Status: Bogus
Bug Type: MySQLi related
Operating System: AIX 5.2
PHP Version: 5.1.1
New Comment:
You're using GCC with native ld. Either use all native or all GNU
tools. Not PHP bug.
Previous Comments:
[2005-12-15 23:55:27] sfletcher at abcoa dot com
Positive. The machine is from scratch with nothing on it. Then I
downloaded the AIX 5.2 (POWER, 64-bit) standard gzipped package from
the http://dev.mysql.com/downloads/mysql/5.0.html web site.
[2005-12-15 23:42:21] [EMAIL PROTECTED]
Are you sure you don't have any other versions of mysql installed
somewhere?
[2005-12-15 20:16:29] sfletcher at abcoa dot com
Description:
MySQL Version: 5.0.16 (AIX 64 binary from mysql.com site)
I followed this documentation at http://us3.php.net/mysql that
mentioned "You can download headers and libraries from MySQL." which
take me to mysql.com site. I then went on to download section and came
upon the "Contributed API" section with a link which then lead me to
http://us3.php.net/manual/en/ref.mysqli.php . So, I followed this
part..
--snip--
To install the mysqli extension for PHP, use the
--with-mysqli=mysql_config_path/mysql_config configuration option
where mysql_config_path represents the location of the mysql_config
program that comes with MySQL versions greater than 4.1.
--snip--
which lead me to this configure command..
--snip--
./configure --with-mysqli=/usr/local/mysql/bin/mysql_config
--with-apxs2=../../apache2/bin/apxs --with-unixODBC --with-openssl
--with-curl --disable-libxml --disable-dom --enable-track-vars
--enable-ftp --enable-sockets
--snip--
See actual result below. I could find no existing bug so I filed a new
bug, upon the submission of this bug that cause me find bug #30835 which
cause to modify this bug report a little more.
I used the "mysql_config --libs" command from bug #30835 and got this
result..
--snip--
-L/usr/local/mysql/lib -lmysqlclient -lz -lcrypt -lnsl_r -lm
--snip--
All of the MySQL stuffs are inside the
"/usr/local/mysql-standard-5.0.16-aix5.2-powerpc-64bit" directory where
I used the symbolic link to make it become a "/usr/local/mysql"
directory.
I know the symbolic link is not hte problem because PHP can find it
without a problem.
Expected result:
PHP should be able to configured successfully without an error.
Actual result:
--
Then the configure terminated with errors...
--snip--
checking for mcrypt support... no
checking for mhash support... no
checking whether to include mime_magic support... no
checking for MING support... no
checking for msession support... no
checking for mSQL support... no
checking for MSSQL support via FreeTDS... no
checking for MySQL support... no
checking for specified location of the MySQL UNIX socket... no
checking for MySQLi support... yes
checking whether to enable embedded MySQLi support... no
checking for mysql_set_server_option in -lmysqlclient... no
configure: error: wrong mysql library version or lib not found. Check
config.log for more information.
--snip--
The config.log is posted here
--snip--
configure:53543: checking for mcrypt support
configure:54372: checking for mhash support
configure:54844: checking whether to include mime_magic support
configure:55199: checking for MING support
configure:56122: checking for msession support
configure:56830: checking for mSQL support
configure:57339: checking for MSSQL support via FreeTDS
configure:57987: checking for MySQL support
configure:58033: checking for specified location of the MySQL UNIX
socket
configure:59186: checking for MySQLi support
configure:59232: checking whether to enable embedded MySQLi support
configure:59378: checking for mysql_set_server_option in -lmysqlclient
configure:59397: gcc -o conftest -g -O2 -L/usr/local/mysql/lib
-L/usr/local/mysql/lib -L/usr/local/ssl/lib -L/usr/local/ssl/lib
-L/usr/local/lib -L/usr/local/lib -lmysqlclient -lz -lcrypt -lnsl_r -lm
conftest.c -lmysqlclient -liconv -lssl -lcrypto -lcurl -lssl -lcrypto
-lm -lcurl -lssl -lcrypto 1>&5
ld: 0711-317 ERROR: Undefined symbol: .mysql_set_server_option
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
collect2: ld returned 8 exit status
configure: failed program was:
#line 59386 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char mysql_set_server_option();
int main() {
mysql_set_server_option()
; return 0; }
--snip--
I hope to have this up and running shortly beca
#35677 [Opn->Asn]: Using PDO with SOAP (Webservices) causes errors.
ID: 35677
Updated by: [EMAIL PROTECTED]
Reported By: prefab5 at hotmail dot com
-Status: Open
+Status: Assigned
Bug Type: SOAP related
Operating System: Windows
PHP Version: 5CVS-2005-12-15 (snap)
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2005-12-15 10:33:55] prefab5 at hotmail dot com
Description:
When connecting to a SoapServer that also includes PDO to create a
database connection, the SoapServer stops sending SOAP-ENV resulting in
a "Fatal error: Uncaught SoapFault exception: [Client] looks like we got
no XML document in..."
Using mysqli to connect to a database within the SoapServer (you
actually call PDO/mysqli from within the class that the SoapServer
uses) works fine and directly calling the class itself also causes no
problems.
PHP doesn't crash, but sometimes Apache (2.0.55) does.
Reproduce code:
---
http://www.mindstix.com/persistenceTestServer.zip
Expected result:
Count: 1
Count: 2
Count: 3
Actual result:
--
Fatal error: Uncaught SoapFault exception: [Client] looks like we got
no XML document in C:\test\webservices\persistenceTestClient.php:6
Stack trace: #0 [internal function]: SoapClient->__call('count', Array)
#1 C:\test\webservices\persistenceTestClient.php(6): SoapClient->count()
#2 {main} thrown in C:\test\webservices\persistenceTestClient.php on
line 6
--
Edit this bug report at http://bugs.php.net/?id=35677&edit=1
#35683 [Opn->Bgs]: OVERALL_TARGET uses += not = in Makefile.frag
ID: 35683 Updated by: [EMAIL PROTECTED] Reported By: to2958 at sbc dot com -Status: Open +Status: Bogus Bug Type: Informix related Operating System: AIX 4.3.3 PHP Version: 5CVS-2005-12-15 (snap) New Comment: Install GNU tools. gmake, etc. Previous Comments: [2005-12-15 15:32:50] to2958 at sbc dot com Description: There is a += in the ext/informix/Makefile.frag for the OVERALL_TARGET which I don't think is right. I've never seen this used in Makefiles though I'm not an expert. This prevents make from working and gives me this: make: make 1254-025 There must be an existing description file or specify a target. When I do the patch below and simply replace the += with = the make runs fine. I didn't really see related bugs nor the use of += in other projects Thanks Reproduce code: --- --- Makefile.frag.orig Thu Dec 15 08:23:46 2005 +++ Makefile.frag Thu Dec 15 08:24:01 2005 @@ -1,5 +1,5 @@ -OVERALL_TARGET += $(srcdir)/ifx.c +OVERALL_TARGET = $(srcdir)/ifx.c $(srcdir)/ifx.c: $(srcdir)/ifx.ec (if test -d $(INFORMIXDIR); then \ -- Edit this bug report at http://bugs.php.net/?id=35683&edit=1
#35685 [Fbk]: post_max_size stays locked to 8M
ID: 35685
Updated by: [EMAIL PROTECTED]
Reported By: motion_4u at hotmail dot com
Status: Feedback
Bug Type: *General Issues
Operating System: Windows 2000 advanced
PHP Version: 5.1.1
New Comment:
And FYI: PHP does not store the whole file in memory. Thus the
memory_limit of 200M is a bit too much. 8M is fine.
Previous Comments:
[2005-12-15 19:40:53] [EMAIL PROTECTED]
And what is upload_max_filesize set to?
Does the upload give any error?
Do var_dump($_FILES); and you should see the error code.
[2005-12-15 17:28:18] motion_4u at hotmail dot com
Description:
I have tried to upload a 100MB file to the server and for that I have
changed the following variables to enable the upload within PHP.INI
file:
max_execution_time = 3000
max_input_time = 600
memory_limit = 200M
post_max_size = 200M
But uploading small files up to 8 MB do work but PHP stops the upload
for files bigger than 8 MB.
I have also tried to set the post_max_size value with the
ini_set ( "post_max_size", "200M" );
with no success.
Actual result:
--
Calling the below snippent
echo 'post_max_size = ' . ini_get('post_max_size');
shows still: post_max_size =8M :((
--
Edit this bug report at http://bugs.php.net/?id=35685&edit=1
#35685 [Opn->Fbk]: post_max_size stays locked to 8M
ID: 35685
Updated by: [EMAIL PROTECTED]
Reported By: motion_4u at hotmail dot com
-Status: Open
+Status: Feedback
Bug Type: *General Issues
Operating System: Windows 2000 advanced
PHP Version: 5.1.1
New Comment:
And what is upload_max_filesize set to?
Does the upload give any error?
Do var_dump($_FILES); and you should see the error code.
Previous Comments:
[2005-12-15 17:28:18] motion_4u at hotmail dot com
Description:
I have tried to upload a 100MB file to the server and for that I have
changed the following variables to enable the upload within PHP.INI
file:
max_execution_time = 3000
max_input_time = 600
memory_limit = 200M
post_max_size = 200M
But uploading small files up to 8 MB do work but PHP stops the upload
for files bigger than 8 MB.
I have also tried to set the post_max_size value with the
ini_set ( "post_max_size", "200M" );
with no success.
Actual result:
--
Calling the below snippent
echo 'post_max_size = ' . ini_get('post_max_size');
shows still: post_max_size =8M :((
--
Edit this bug report at http://bugs.php.net/?id=35685&edit=1
#35686 [Opn->Bgs]: mhash compilation error
ID: 35686 Updated by: [EMAIL PROTECTED] Reported By: pavel at rauspc dot cz -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: CentOS 4.2 x86_64 PHP Version: 5CVS-2005-12-15 (snap) New Comment: There's something very wrong with this new mhash version. Please report this to the mhash authors. If they have some workaround, please let me know. Previous Comments: [2005-12-15 19:04:42] pavel at rauspc dot cz Description: ext/mhash/.libs/mhash.o(.text+0x29c): In function `zif_mhash': /usr/src/dist/php5.1-200512151730/ext/mhash/mhash.c:186: undefined reference to `mhash_free' mhash 0.9.3 ( compiled in /opt/mhash ) GCC 3.4.4 # ldconfig -p | grep mhash libmhash.so.2 (libc6,x86-64) => /opt/mhash/lib/libmhash.so.2 libmhash.so (libc6,x86-64) => /opt/mhash/lib/libmhash.so -- Edit this bug report at http://bugs.php.net/?id=35686&edit=1
#35677 [Opn->Fbk]: Using PDO with SOAP (Webservices) causes errors.
ID: 35677
Updated by: [EMAIL PROTECTED]
Reported By: prefab5 at hotmail dot com
-Status: Open
+Status: Feedback
Bug Type: SOAP related
Operating System: Windows
PHP Version: 5CVS-2005-12-15 (snap)
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
Previous Comments:
[2005-12-15 10:33:55] prefab5 at hotmail dot com
Description:
When connecting to a SoapServer that also includes PDO to create a
database connection, the SoapServer stops sending SOAP-ENV resulting in
a "Fatal error: Uncaught SoapFault exception: [Client] looks like we got
no XML document in..."
Using mysqli to connect to a database within the SoapServer (you
actually call PDO/mysqli from within the class that the SoapServer
uses) works fine and directly calling the class itself also causes no
problems.
PHP doesn't crash, but sometimes Apache (2.0.55) does.
Reproduce code:
---
http://www.mindstix.com/persistenceTestServer.zip
Expected result:
Count: 1
Count: 2
Count: 3
Actual result:
--
Fatal error: Uncaught SoapFault exception: [Client] looks like we got
no XML document in C:\test\webservices\persistenceTestClient.php:6
Stack trace: #0 [internal function]: SoapClient->__call('count', Array)
#1 C:\test\webservices\persistenceTestClient.php(6): SoapClient->count()
#2 {main} thrown in C:\test\webservices\persistenceTestClient.php on
line 6
--
Edit this bug report at http://bugs.php.net/?id=35677&edit=1
#35671 [Opn->Fbk]: Named parameters not working in PDO_ODBC
ID: 35671
Updated by: [EMAIL PROTECTED]
Reported By: mknobloch at midstate dot edu
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Windows 2003 SP1
PHP Version: 5.1.1
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Previous Comments:
[2005-12-14 21:04:50] mknobloch at midstate dot edu
Description:
When using a named parameters array, PDO_ODBC substitutes the last
value in the array for each named parameter.
This code works fine in 5.1.0. The bug first appeared in 5.1.1. I can
also confirm that this bug does not affect PDO_SQLITE.
Reproduce code:
---
$dbh = new PDO("odbc:testdb");
$dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);
$sql = "INSERT INTO testtable (field1, field2, field3) VALUES (:value1,
:value2, :value3)";
$sth = $dbh->prepare($sql, array(PDO::ATTR_CURSOR,
PDO::CURSOR_FWDONLY));
$parm = array(
":value1" => 15,
":value2" => 20,
":value3" => 25
);
$sth->execute($parm);
Expected result:
I expect a new record to be inserted into the table with field1 = 15,
field2 = 20, and field3 = 25
Actual result:
--
A new record is created, but 25 is inserted into all three fields.
--
Edit this bug report at http://bugs.php.net/?id=35671&edit=1
