#42699 [Fbk-Opn]: PHP_SELF duplicates path
ID: 42699 User updated by: vvv at colocall dot net Reported By: vvv at colocall dot net -Status: Feedback +Status: Open Bug Type: CGI related Operating System: FreeBSD 6.2, apache 2.2.6 PHP Version: 5.2CVS-2007-09-18 Assigned To: dmitry New Comment: I've just reproduce it with the snapshot http://snaps.php.net/php5.2-200709240630.tar.bz2 FreeBSD 6.2-RELEASE-p1 './configure' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml' '--with-libxml-dir=/usr/local' '--enable-reflection' '--program-prefix=' '--disable-path-info-check' '--with-regex=php' '--with-zend-vm=CALL' '--disable-ipv6' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' Previous Comments: [2007-09-21 14:35:13] [EMAIL PROTECTED] I cannot reproduce it: Linux 2.6.22, glibc 2.6 '../configure' '--prefix=/home/dmitry/php/usr/php5.2-debug' '--with-config-file-path=/home/dmitry/php/usr/php5.2-debug/etc' '--enable-force-cgi-redirect' '--enable-fastcgi' '--enable-pic' '--enable-debug' '--enable-memory-limit' '--disable-rpath' '--with-regex=php' '--with-zlib' '--with-layout=GNU' '--enable-magic-quotes' '--enable-track-vars' '--disable-path-info-check' Request to http://127.0.0.1/test/phpinfo.php gives _SERVER[PHP_SELF] == /test/phpinfo.php. [2007-09-19 11:43:48] vvv at colocall dot net The problem has gone after recompiling without --disable-path-info-check. FreeBSD port applies this option by default. [2007-09-19 02:01:33] w dot ashcroft at redfoxuk dot com I noticed the bug fix for #42523 was a specific workaround for when the server software CGI variable was set as Microsoft-IIS; so clearly the hack fix for #42523 needs to be done properly if it doesn't fix the problem completely. [2007-09-18 12:23:33] [EMAIL PROTECTED] Dmitry, can you check this out please. [2007-09-18 11:22:00] vvv at colocall dot net I've tried php5.2-200709180830 before submitting the bug. I've got the same behavior as using php-5.2.4. 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/42699 -- Edit this bug report at http://bugs.php.net/?id=42699edit=1
#42743 [NEW]: oci_num_rows returns wrong value when parameter 1 is null
From: pcdinh at gmail dot com Operating system: CentOs PHP version: 5.2.4 PHP Bug Type: OCI8 related Bug description: oci_num_rows returns wrong value when parameter 1 is null Description: OCI8 said oci_num_rows returns TRUE on success or FALSE on failure. But when the first parameter is null, oci_num_rows returns null. Reproduce code: --- oci_num_rows(null) Expected result: oci_num_rows(null) should return false because parameter must be a statement/resource. null statement is abnormal Actual result: -- oci_num_rows(null) return null -- Edit bug report at http://bugs.php.net/?id=42743edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42743r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42743r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42743r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42743r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42743r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42743r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42743r=needscript Try newer version:http://bugs.php.net/fix.php?id=42743r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42743r=support Expected behavior:http://bugs.php.net/fix.php?id=42743r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42743r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42743r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42743r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42743r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42743r=dst IIS Stability:http://bugs.php.net/fix.php?id=42743r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42743r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42743r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42743r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42743r=mysqlcfg
#42745 [NEW]: oci_execute returns wring value when the first parameter is null
From: pcdinh at gmail dot com Operating system: CentOS 5 PHP version: 5.2.4 PHP Bug Type: OCI8 related Bug description: oci_execute returns wring value when the first parameter is null Description: OCI8 docs said: oci_execute returns TRUE on success or FALSE on failure. But when the first parameter is null, null is returned as well. That return value does not reflect the state of the execution: true or false. Reproduce code: --- oci_execute(null) Expected result: oci_execute(null) should return false because null statement is abnormal. Developer should know that executing query on a null statement when developing a finance application with Oracle and PHp is dangerous. Actual result: -- oci_execute(null) return null wrongly -- Edit bug report at http://bugs.php.net/?id=42745edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42745r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42745r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42745r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42745r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42745r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42745r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42745r=needscript Try newer version:http://bugs.php.net/fix.php?id=42745r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42745r=support Expected behavior:http://bugs.php.net/fix.php?id=42745r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42745r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42745r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42745r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42745r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42745r=dst IIS Stability:http://bugs.php.net/fix.php?id=42745r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42745r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42745r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42745r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42745r=mysqlcfg
#42625 [Fbk-Opn]: When mysql and mysqli enabled both together, php CLI hangs when ZTS is enabled
ID: 42625 User updated by: jama at mk dot cvut dot cz Reported By: jama at mk dot cvut dot cz -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: Gentoo/Linux PHP Version: 5.2.4 Assigned To: andrey New Comment: tested on php6.0-200709240630 mysqli OK mysql+mysqli BAD mysql+mysqlng OK I created simple bash script for building and testing php snapshots for this bug. It's on http://pastebin.com/m68372238 Runned in this case as . ./test.sh php6.0-200709240630.tar.bz2 php6.0-200709240630 php6.0-200709240630 Manualy killed when php -i was hanging on second test and result looks like this: # cat php6.0-200709240630.log OK php6.0-200709240630-mysqli ./configure --disable-all --enable-maintainer-zts --with-mysqli=/usr/bin/mysql_config BAD php6.0-200709240630-mysqli-mysql ./configure --disable-all --enable-maintainer-zts --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config OK php6.0-200709240630-mysqli-mysqlng ./configure --disable-all --enable-maintainer-zts --with-mysql=mysql --with-mysqli=mysqlnd Previous Comments: [2007-09-22 08:47:41] [EMAIL PROTECTED] Hi, - can you try building PHP6? - if still han gs, can you try building with mysqlnd (PHP6, --with-mysqli=mysqlnd --with-mysql=mysql) and see if there is still a problem Andrey [2007-09-19 14:08:19] [EMAIL PROTECTED] I can't reproduce with MySQL 5.1.22 [2007-09-19 13:40:39] [EMAIL PROTECTED] Propably some issue with the BETA mysql version used. Assigned to the mysql maintainer. [2007-09-19 13:39:33] [EMAIL PROTECTED] # mysql_config --version 5.0.27 [2007-09-19 13:38:49] [EMAIL PROTECTED] I can not reproduce this. 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/42625 -- Edit this bug report at http://bugs.php.net/?id=42625edit=1
#41147 [Asn-Csd]: mb_check_encoding fails to check invalid string
ID: 41147 Updated by: [EMAIL PROTECTED] Reported By: teracci2002 at yahoo dot co dot jp -Status: Assigned +Status: Closed Bug Type: mbstring related Operating System: Linux PHP Version: 5.2.1 Assigned To: hirokawa 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. It is a documentation problem, and it is already fixed in CVS. Previous Comments: [2007-09-19 20:52:48] mike at silverorange dot com 0x00, 0xe3 is a valid byte sequence in UTF-8 but by itself is not a valid UTF-8 string (it's missing two bytes). The function is documented as checking the validity of a string so it should return false for this case. If the function is only supposed to validate byte-streams then the documentation should be fixed. [2007-09-16 08:56:57] [EMAIL PROTECTED] Sorry for delaying response. 0x00,0x81 is also valid byte sequence in Shift_JIS because 0x81 is a valid first byte of a double-byte JIS X 0208 character. See: http://en.wikipedia.org/wiki/Shift_jis We cannot decide the byte stream is valid or invalid because the last byte of byte stream (0x81) is a valid first byte of double-byte character. In this case, true (valid) will be returned. The byte stream including a valid first byte + a invalid second byte returns false. For example, var_dump(mb_check_encoding(\x81\x00, Shift_JIS)); returns false (invalid). It is because 0x81 is valid first byte of a double-byte JIS X0208 character, but, 0x00 is invalid second byte of a double-byte JIS X0208 character. And, 0x00, 0xe3 in UTF-8, it is also valid byte sequence (a null byte + first byte of a three-byte UTF-8 character). See: http://en.wikipedia.org/wiki/UTF-8 [2007-09-04 22:38:26] [EMAIL PROTECTED] Did you read it Rui? (why do your reports end up as 'Analyzed' all the time? :) [2007-09-04 14:55:58] teracci2002 at yahoo dot co dot jp 0x00+0xa1 is valid byte sequence in Shift_JIS sequence. I know it. But 0x00+0x81 is invalid sequence in Shift_JIS. Then, why below statement returns bool(true) ? var_dump(mb_check_encoding(\x00\x81, Shift_JIS)); Read bug report again, please. [2007-09-04 14:30:06] [EMAIL PROTECTED] No one says 0x00,0xa1 is invalid character in ShiftJIS. I didn't say that. 0x00+0xa1 is valid byte sequence in Shift_JIS sequence. A character in Shift_JIS encoding is encoded in either single byte or double byte. In this case, the byte stream is reconigzed as two character, a null byte and a comma character in Katakana(0xa1) see: http://hp.vector.co.jp/authors/VA013241/misc/shiftjis.html 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/41147 -- Edit this bug report at http://bugs.php.net/?id=41147edit=1
#42746 [NEW]: '\u' char in single quotes gets interepreted.
From: mahesh dot vemula at in dot ibm dot com
Operating system: Linux, Windows XP
PHP version: 6CVS-2007-09-24 (CVS)
PHP Bug Type: *Unicode Issues
Bug description: '\u' char in single quotes gets interepreted.
Description:
'\u' escape sequence char in single quotes('') is being interpreted by
PHP6.
Reproduce code:
---
?php
var_dump(\u1234);
var_dump('\u1234');
?
Expected result:
unicode(1) #4660;
unicode(6) \u1234
Actual result:
--
unicode(1) #4660;
unicode(1) #4660;
--
Edit bug report at http://bugs.php.net/?id=42746edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42746r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42746r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42746r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42746r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42746r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42746r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42746r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42746r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42746r=support
Expected behavior:http://bugs.php.net/fix.php?id=42746r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42746r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42746r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42746r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42746r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42746r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42746r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42746r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42746r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42746r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42746r=mysqlcfg
#42699 [Opn-Asn]: PHP_SELF duplicates path
ID: 42699 Updated by: [EMAIL PROTECTED] Reported By: vvv at colocall dot net -Status: Open +Status: Assigned Bug Type: CGI related Operating System: FreeBSD 6.2, apache 2.2.6 PHP Version: 5.2CVS-2007-09-18 Assigned To: dmitry New Comment: Dmitry, use --disable-path-info-check and you'll get the problem. Previous Comments: [2007-09-24 08:14:33] vvv at colocall dot net I've just reproduce it with the snapshot http://snaps.php.net/php5.2-200709240630.tar.bz2 FreeBSD 6.2-RELEASE-p1 './configure' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml' '--with-libxml-dir=/usr/local' '--enable-reflection' '--program-prefix=' '--disable-path-info-check' '--with-regex=php' '--with-zend-vm=CALL' '--disable-ipv6' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' [2007-09-21 14:35:13] [EMAIL PROTECTED] I cannot reproduce it: Linux 2.6.22, glibc 2.6 '../configure' '--prefix=/home/dmitry/php/usr/php5.2-debug' '--with-config-file-path=/home/dmitry/php/usr/php5.2-debug/etc' '--enable-force-cgi-redirect' '--enable-fastcgi' '--enable-pic' '--enable-debug' '--enable-memory-limit' '--disable-rpath' '--with-regex=php' '--with-zlib' '--with-layout=GNU' '--enable-magic-quotes' '--enable-track-vars' '--disable-path-info-check' Request to http://127.0.0.1/test/phpinfo.php gives _SERVER[PHP_SELF] == /test/phpinfo.php. [2007-09-19 11:43:48] vvv at colocall dot net The problem has gone after recompiling without --disable-path-info-check. FreeBSD port applies this option by default. [2007-09-19 02:01:33] w dot ashcroft at redfoxuk dot com I noticed the bug fix for #42523 was a specific workaround for when the server software CGI variable was set as Microsoft-IIS; so clearly the hack fix for #42523 needs to be done properly if it doesn't fix the problem completely. [2007-09-18 12:23:33] [EMAIL PROTECTED] Dmitry, can you check this out please. 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/42699 -- Edit this bug report at http://bugs.php.net/?id=42699edit=1
#42625 [Opn-Asn]: When mysql and mysqli enabled both together, php CLI hangs when ZTS is enabled
ID: 42625 Updated by: [EMAIL PROTECTED] Reported By: jama at mk dot cvut dot cz -Status: Open +Status: Assigned Bug Type: MySQL related Operating System: Gentoo/Linux PHP Version: 5.2.4 Assigned To: andrey Previous Comments: [2007-09-24 09:39:40] jama at mk dot cvut dot cz tested on php6.0-200709240630 mysqli OK mysql+mysqli BAD mysql+mysqlng OK I created simple bash script for building and testing php snapshots for this bug. It's on http://pastebin.com/m68372238 Runned in this case as . ./test.sh php6.0-200709240630.tar.bz2 php6.0-200709240630 php6.0-200709240630 Manualy killed when php -i was hanging on second test and result looks like this: # cat php6.0-200709240630.log OK php6.0-200709240630-mysqli ./configure --disable-all --enable-maintainer-zts --with-mysqli=/usr/bin/mysql_config BAD php6.0-200709240630-mysqli-mysql ./configure --disable-all --enable-maintainer-zts --with-mysql=/usr --with-mysqli=/usr/bin/mysql_config OK php6.0-200709240630-mysqli-mysqlng ./configure --disable-all --enable-maintainer-zts --with-mysql=mysql --with-mysqli=mysqlnd [2007-09-22 08:47:41] [EMAIL PROTECTED] Hi, - can you try building PHP6? - if still han gs, can you try building with mysqlnd (PHP6, --with-mysqli=mysqlnd --with-mysql=mysql) and see if there is still a problem Andrey [2007-09-19 14:08:19] [EMAIL PROTECTED] I can't reproduce with MySQL 5.1.22 [2007-09-19 13:40:39] [EMAIL PROTECTED] Propably some issue with the BETA mysql version used. Assigned to the mysql maintainer. [2007-09-19 13:39:33] [EMAIL PROTECTED] # mysql_config --version 5.0.27 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/42625 -- Edit this bug report at http://bugs.php.net/?id=42625edit=1
#33296 [Com]: popen (passthru etc.) doesn't work correct
ID: 33296
Comment by: jgh at fgdh dot jfhk
Reported By: thomas dot wetzler at siemens dot com
Status: No Feedback
Bug Type: Program Execution
Operating System: SUN OS
PHP Version: 4.3.10
New Comment:
http://www.meta-fx.com
Previous Comments:
[2007-09-17 08:39:39] uj at u dot g8tr
http://www.meta-fx.com
[2005-07-19 09:47:33] screen at brainkrash dot com
Tested script from thomas dot wetzler at siemens dot com on php4.4.0
cli/apache2 and php4-STABLE-200507190640 on Linux server and ALL samples
worked.
Found this bug searching for a similar (maybe the same) issue related
to popen/freads calling SVN. I modified this test script and ran tests
using 4.4.0 and php4-STABLE-200507190640 with the following results:
script
--
#!/usr/local/apache2/php/bin/php
#
?
for ($i=0; $i10; $i++) {
$statement = /usr/local/subversion/bin/svn help;
echo \n\n$i***\n;
$handle = popen($statement, 'r');
echo Subprozess: '$handle'; . gettype($handle) . \n;
$output = '';
while (!feof($handle)) {
$output .= fgets($handle);
}
echo $output;
pclose($handle);
}
?
results
---
/usr/local/apache2/php/bin/php -f test.php test440_cli.txt
works
wget -O test440_apache2.txt
http://brainkrash.com/~screen/test/test.php
all 10 fail with no return from fgets
/usr/local/apache2/php/bin/php -f test.php
test4-200507190640_cli.txt
works
wget -O test4-200507190640_apache2.txt
http://brainkrash.com/~screen/test/test.php
all 10 fail with no return from fgets
expected result
---
0***
Subprozess: 'Resource id #4'; resource
usage: svn subcommand [options] [args]
Subversion command-line client, version 1.2.1.
Type 'svn help subcommand' for help on a specific subcommand.
Most subcommands take file and/or directory arguments, recursing
on the directories. If no arguments are supplied to such a
command, it recurses on the current directory (inclusive) by default.
Available subcommands:
add
blame (praise, annotate, ann)
... TRUNCATED
failure results
---
0***
Subprozess: 'Resource id #2'; resource
EOF
[2005-06-23 01:00:04] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2005-06-15 19:16:03] [EMAIL PROTECTED]
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
Try also the latest PHP 4 snapshot.
[2005-06-15 15:54:16] thomas dot wetzler at siemens dot com
We tried out PHP Version 5. With the commandline (php.exe) it seems to
work but with the mod_php-module we get the same failure.
Because the testing of our application take a long time, it would be
good if you can find a solution for Version 4.
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/33296
--
Edit this bug report at http://bugs.php.net/?id=33296edit=1
#42699 [Asn-Csd]: PHP_SELF duplicates path
ID: 42699 Updated by: [EMAIL PROTECTED] Reported By: vvv at colocall dot net -Status: Assigned +Status: Closed Bug Type: CGI related Operating System: FreeBSD 6.2, apache 2.2.6 PHP Version: 5.2CVS-2007-09-18 Assigned To: dmitry 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: [2007-09-24 10:39:22] [EMAIL PROTECTED] Dmitry, use --disable-path-info-check and you'll get the problem. [2007-09-24 08:14:33] vvv at colocall dot net I've just reproduce it with the snapshot http://snaps.php.net/php5.2-200709240630.tar.bz2 FreeBSD 6.2-RELEASE-p1 './configure' '--with-layout=GNU' '--with-config-file-scan-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml' '--with-libxml-dir=/usr/local' '--enable-reflection' '--program-prefix=' '--disable-path-info-check' '--with-regex=php' '--with-zend-vm=CALL' '--disable-ipv6' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' [2007-09-21 14:35:13] [EMAIL PROTECTED] I cannot reproduce it: Linux 2.6.22, glibc 2.6 '../configure' '--prefix=/home/dmitry/php/usr/php5.2-debug' '--with-config-file-path=/home/dmitry/php/usr/php5.2-debug/etc' '--enable-force-cgi-redirect' '--enable-fastcgi' '--enable-pic' '--enable-debug' '--enable-memory-limit' '--disable-rpath' '--with-regex=php' '--with-zlib' '--with-layout=GNU' '--enable-magic-quotes' '--enable-track-vars' '--disable-path-info-check' Request to http://127.0.0.1/test/phpinfo.php gives _SERVER[PHP_SELF] == /test/phpinfo.php. [2007-09-19 11:43:48] vvv at colocall dot net The problem has gone after recompiling without --disable-path-info-check. FreeBSD port applies this option by default. [2007-09-19 02:01:33] w dot ashcroft at redfoxuk dot com I noticed the bug fix for #42523 was a specific workaround for when the server software CGI variable was set as Microsoft-IIS; so clearly the hack fix for #42523 needs to be done properly if it doesn't fix the problem completely. 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/42699 -- Edit this bug report at http://bugs.php.net/?id=42699edit=1
#39404 [Asn-Csd]: Support entity as substitute_character setting
ID: 39404 Updated by: [EMAIL PROTECTED] Reported By: martin dot t dot kutschker at blackbox dot net -Status: Assigned +Status: Closed Bug Type:Feature/Change Request PHP Version: 5.2.0 Assigned To: hirokawa 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: [2006-11-07 14:27:41] [EMAIL PROTECTED] Reclassified as feature request assigned to maintainer. [2006-11-06 17:09:37] martin dot t dot kutschker at blackbox dot net Fix spelling of entity in the summary. [2006-11-06 16:56:19] martin dot t dot kutschker at blackbox dot net Description: It would be great if the charset conversion could also output SGML/HTML entites for missing characters in the output charset. The option long is not very HTML-friendly. But with entity any Unicode aware browser could deal with the missing charater. eg mbstring.substitute_character=long = U+3000 mbstring.substitute_character=entity = #x3000; -- Edit this bug report at http://bugs.php.net/?id=39404edit=1
#30485 [Com]: CLI Error
ID: 30485 Comment by: hello at timperrett dot com Reported By: jcastro at elnuevodia dot com Status: No Feedback Bug Type: MSSQL related Operating System: Windows Xp PHP Version: 5.0.2 New Comment: I also have this problem. Im using 5.2.4.4 and have IIS set up with virtual directories to my php applications. Everything works in the default site, but then when I try to access the virtual directories I get the same error in my even viewer. Previous Comments: [2005-03-20 18:04:52] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2005-03-07 22:17:14] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2004-10-19 21:19:19] [EMAIL PROTECTED] The short answer is don't use persistent connection in CLI. The long answer: It matters because the persistent connection layer gets initialized. Maybe there is a problem in reusing or storing the persistent connection. So most probably this is no direct CLI problem. [2004-10-19 20:22:50] jcastro at elnuevodia dot com Description: I am using adodb to make an update in sqlserver. the script uses 2 connections . One of them is not even use in the exmaple. If I uncomment the connection that is use, the program crash I GET IN EVENT VIEWER Faulting application php.exe, version 5.0.2.2,faulting module php5ts.dll, version 5.0.2.2, fault address 0x0003f640. ALSO IF I CHANGE THE PCONNECT INSIDE connectSybase() to a connect, IT DOES NOT CRASH. WHY WILL IT MATTER IF I AM NOT EVEN USING THE CONNECTION? Also if I change to php 4.3.9 it works , NO problems. Reproduce code: --- http://www.eldiainc.com/temp/debug.htm Actual result: -- Window with CLI encounter an error Faulting application php.exe, version 5.0.2.2,faulting module php5ts.dll, version 5.0.2.2, fault address 0x0003f640. -- Edit this bug report at http://bugs.php.net/?id=30485edit=1
#40677 [Com]: PHP crash when calling Java
ID: 40677 Comment by: anton17 at inbox dot lv Reported By: poon dot fung at comcast dot net Status: Suspended Bug Type: Java related Operating System: windows xp PHP Version: 5.2.1 Assigned To: edink New Comment: yo yo yo Previous Comments: [2007-03-06 16:03:45] peter_jones_jr at yahoo dot com Hi, the documentation which comes with PHP clearly states that ext/java only works with some older versions of PHP4. I don't think ext/java is mentioned in the PHP manual page, at least not on debian. Calling Java classes in-process is not possible unless you use a PHP implementation written in pure Java. For the Zend PHP engine you need an external Java process. I think this is what you mean with Java application server. Peter [2007-03-05 17:26:38] poon dot fung at comcast dot net I read in some discussions that PHP-Java Bridge is a replacement to PHP Java integration method. However, PHP-Java Bridge documentation shows only methods of calling from PHP to Java application server but not calling Java classes in-process. I would like to be able to call Java libraries from PHP. If PHP Java integration were to be discontinued, manual page should be updated. I spent quite a bit of time trying to figure out why the integration did not work because there is no indication that it may not. [2007-03-05 16:00:22] [EMAIL PROTECTED] Short of deleting it from the CVS it is not possible atm. Java extension is not maintained and probably does not work on any platform. [2007-03-05 09:49:56] [EMAIL PROTECTED] Edin, I'd prefer the former. [2007-03-02 21:16:38] valid at email dot address This crash happens when you add the following to your php.ini extension=php_java.dll The php_java.dll from http://pecl4win.php.net/ext.php/php_java.dll and the php_java.dll which is part of the official pecl for windows download crash the php executable. Either remove the php_java.dll from the official pecl4win download or or fix this bug. 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/40677 -- Edit this bug report at http://bugs.php.net/?id=40677edit=1
#41147 [Csd]: mb_check_encoding fails to check invalid string
ID: 41147 User updated by: teracci2002 at yahoo dot co dot jp Reported By: teracci2002 at yahoo dot co dot jp Status: Closed Bug Type: mbstring related Operating System: Linux PHP Version: 5.2.1 Assigned To: hirokawa New Comment: I guess the problem is not only in the document. var_dump(mb_check_encoding(\x00\xE3,UTF-8)); = bool(true)may be checking validity of byte streams var_dump(mb_check_encoding(\xE3, UTF-8)); = bool(false) may be checking validity of string # I hope that this function checks validity of string, not byte streams (but this is just my opinion). Previous Comments: [2007-09-24 10:15:32] [EMAIL PROTECTED] 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. It is a documentation problem, and it is already fixed in CVS. [2007-09-19 20:52:48] mike at silverorange dot com 0x00, 0xe3 is a valid byte sequence in UTF-8 but by itself is not a valid UTF-8 string (it's missing two bytes). The function is documented as checking the validity of a string so it should return false for this case. If the function is only supposed to validate byte-streams then the documentation should be fixed. [2007-09-16 08:56:57] [EMAIL PROTECTED] Sorry for delaying response. 0x00,0x81 is also valid byte sequence in Shift_JIS because 0x81 is a valid first byte of a double-byte JIS X 0208 character. See: http://en.wikipedia.org/wiki/Shift_jis We cannot decide the byte stream is valid or invalid because the last byte of byte stream (0x81) is a valid first byte of double-byte character. In this case, true (valid) will be returned. The byte stream including a valid first byte + a invalid second byte returns false. For example, var_dump(mb_check_encoding(\x81\x00, Shift_JIS)); returns false (invalid). It is because 0x81 is valid first byte of a double-byte JIS X0208 character, but, 0x00 is invalid second byte of a double-byte JIS X0208 character. And, 0x00, 0xe3 in UTF-8, it is also valid byte sequence (a null byte + first byte of a three-byte UTF-8 character). See: http://en.wikipedia.org/wiki/UTF-8 [2007-09-04 22:38:26] [EMAIL PROTECTED] Did you read it Rui? (why do your reports end up as 'Analyzed' all the time? :) [2007-09-04 14:55:58] teracci2002 at yahoo dot co dot jp 0x00+0xa1 is valid byte sequence in Shift_JIS sequence. I know it. But 0x00+0x81 is invalid sequence in Shift_JIS. Then, why below statement returns bool(true) ? var_dump(mb_check_encoding(\x00\x81, Shift_JIS)); Read bug report again, please. 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/41147 -- Edit this bug report at http://bugs.php.net/?id=41147edit=1
#42060 [Com]: [PATCH] Add pagedResults support and more (PAT18 and PAT19 updated for 5.2.3)
ID: 42060 Comment by: avel+php at noc dot uoa dot gr Reported By: iarenuno at eteo dot mondragon dot edu Status: No Feedback Bug Type: LDAP related Operating System: Any PHP Version: 5.2.3 Assigned To: jani New Comment: This is a _killer_ feature that we have been waiting for a long time. White pages apps written in PHP, with large directories behind them, desparetely need the paging feature -- and not only them! The API seems intuitive to me so far. I'm eager for this to be included in PHP 5.3. Thanks for the patch. Alexandros Vellis Previous Comments: [2007-09-07 18:40:25] ando at sys-net dot it A working patch with test examples lined up to HEAD as of 5 minutes ago is available here http://www.sys-net.it/~ando/Download/#PHP I'm the original developer, and I'm willing to cooperate in integrating it, if needed. So you can re-open the bug now. p. [2007-09-07 14:59:29] ando at sys-net dot it Yes, so many functions are needed to support generic stuff + dozens of well-known, RFC/I.D. based LDAP controls and extended operations, without code duplication. Any developer would agree. [2007-09-07 14:57:40] ando at sys-net dot it Be serious: the patch applies back up to PHP 4 (the last time an update occurred to LDAP support). [2007-08-04 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2007-07-27 05:06:27] [EMAIL PROTECTED] Ok, but let's keep this in Feedback status until that then. 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/42060 -- Edit this bug report at http://bugs.php.net/?id=42060edit=1
#41635 [Opn-Asn]: SoapServer and zlib.output_compression with FastCGI result in major slowdown
ID: 41635 Updated by: [EMAIL PROTECTED] Reported By: jln at magentammt dot com -Status: Open +Status: Assigned Bug Type: SOAP related Operating System: FreeBSD 6.2 PHP Version: 5.2.4 Assigned To: dmitry Previous Comments: [2007-09-21 12:11:44] jln at magentammt dot com Normal soap results appear to work, _BUT_ soap faults are still slow. [2007-07-13 14:01:38] [EMAIL PROTECTED] 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. [2007-07-02 14:14:14] jln at magentammt dot com Still couldn't get the ./configure version of PHP working, even when using the same parameters as used by the ports, but according to some older notes of mine the Apache/mod_php5 and zlib.output_compression combination worked. Didn't try Apache with FastCGI, and Lighttpd only works with FastCGI. [2007-06-26 14:25:20] jln at magentammt dot com I'm probably daft, but I can't get zlib compression working: ./configure --enable-soap --enable-fastcgi --with-zlib --with-zlib-dir --enable-force-cgi-redirect --enable-discard-path --with-mysqli=/usr/local/bin/mysql_config followed by make and copy to the proper location, update php.ini, restart lighttpd. But the http headers don't have any output compression bits in them... Also the webservice (soap) doesn't work anymore, no messages just 'http request failed' in the client. The newly build version of php is used (5.2.4/dev). If I switch to the regular, ports build, 5.2.3 compression works (not for soap of-course). [2007-06-26 11:13:37] [EMAIL PROTECTED] I'm using the FreeBSD ports system which automatically patches the sources, and that fails on the snapshot. You don't need any patches or port systems to install the snapshot. Moreover, they can be causing your problems, that's why I want you to test clean PHP sources without any third-party patches. Just grab the sources, ./configure it, make and put the result binaries to the correct place. 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/41635 -- Edit this bug report at http://bugs.php.net/?id=41635edit=1
#42297 [Com]: mysql_fetch functions return ? instead of utf8 chars other than latin1
ID: 42297 Comment by: dev at unleashedmind dot com Reported By: bmilosavljevic at gmail dot com Status: Open Bug Type:MySQL related PHP Version: 4.4.7 New Comment: Confirming that this bug exists. Previous Comments: [2007-08-14 16:07:27] bmilosavljevic at gmail dot com Description: mysql_fetch functions return question marks (?) instead of utf8 chars (other than latin1). Tested on linux production server and on local windows developer server as well. -- Edit this bug report at http://bugs.php.net/?id=42297edit=1
#42747 [NEW]: option --enable-dio not recognized
From: richard dot cubek at web dot de Operating system: Suse Linux 10.2 PHP version: 5.2.4 PHP Bug Type: *Configuration Issues Bug description: option --enable-dio not recognized Description: As described on http://www.php.net/manual/en/ref.dio.php i added --enable-dio as option, my complete configuration command is: ./configure --with-apxs2=/usr/sbin/apxs2-prefork --with-mysql --with-gd --enable-gd-native-ttf --with-zlib-dir=/usr/lib --with-png-dir=/usr/lib --with-jpeg-dir=/usr/lib --with-freetype-dir=/usr/lib --with-bz2 --enable-dio Works fine, but at the end of the output, I get: --- Thank you for using PHP. Notice: Following unknown configure options were used: --enable-dio Check './configure --help' for available options --- So, option --enable-dio is not recognized. With ./configure --help | grep dio i also get no result. After 'make install', calling the function dio_open() then calls an fatal error (unknown function...). -- Edit bug report at http://bugs.php.net/?id=42747edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42747r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42747r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42747r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42747r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42747r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42747r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42747r=needscript Try newer version:http://bugs.php.net/fix.php?id=42747r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42747r=support Expected behavior:http://bugs.php.net/fix.php?id=42747r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42747r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42747r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42747r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42747r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42747r=dst IIS Stability:http://bugs.php.net/fix.php?id=42747r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42747r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42747r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42747r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42747r=mysqlcfg
#42747 [Opn-Bgs]: option --enable-dio not recognized
ID: 42747 Updated by: [EMAIL PROTECTED] Reported By: richard dot cubek at web dot de -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: Suse Linux 10.2 PHP Version: 5.2.4 New Comment: It is not bundled anymore. See http://pecl.php.net/dio to fetch the CVS version (being unmaintained, there is no release in pecl). Not a bug bogus. Previous Comments: [2007-09-24 16:18:20] richard dot cubek at web dot de Description: As described on http://www.php.net/manual/en/ref.dio.php i added --enable-dio as option, my complete configuration command is: ./configure --with-apxs2=/usr/sbin/apxs2-prefork --with-mysql --with-gd --enable-gd-native-ttf --with-zlib-dir=/usr/lib --with-png-dir=/usr/lib --with-jpeg-dir=/usr/lib --with-freetype-dir=/usr/lib --with-bz2 --enable-dio Works fine, but at the end of the output, I get: --- Thank you for using PHP. Notice: Following unknown configure options were used: --enable-dio Check './configure --help' for available options --- So, option --enable-dio is not recognized. With ./configure --help | grep dio i also get no result. After 'make install', calling the function dio_open() then calls an fatal error (unknown function...). -- Edit this bug report at http://bugs.php.net/?id=42747edit=1
#33533 [Com]: PDO_ODBC: Segmentation Fault with selecting informix text column
ID: 33533 Comment by: hgj at jm dot bnb Reported By: scott dot barnett at thuringowa dot qld dot gov dot au Status: No Feedback Bug Type: PDO related Operating System: CentOS 4.1 / Redhat Enterprise 4 PHP Version: 5CVS-2005-07-04 Assigned To: wez New Comment: http://www.meta-fx.com Previous Comments: [2005-09-24 01:00:02] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2005-09-16 20:34:11] [EMAIL PROTECTED] I've poked around, and this really looks like either a unixODBC or informix bug (perhaps both). It's quite possible that PDO is doing something that unixODBC or informix doesn't like, but the problem is that unixODBC is trying to call a function that is set to NULL. (gdb) info linkmap /lib/libcrypt.so.1 /usr/lib/libz.so.1 /lib/libresolv.so.2 /lib/tls/libm.so.6 /lib/libnsl.so.1 00a4 /usr/local/lib/libodbc.so.1 /lib/libdl.so.2 /lib/tls/libpthread.so.0 /lib/tls/libc.so.6 /lib/ld-linux.so.2 005e1000 /usr/lib/gconv/ISO8859-1.so 001f7000 /opt/informix/lib/cli/iclis09b.so 007d5000 /opt/informix/lib/esql/libifgls.so 00d89000 /opt/informix/lib/esql/libifglx.so 0039e000 /lib/libnss_files.so.2 00198000 /opt/informix/lib/esql/igo4a304.so 0098d000 /usr/local/lib/libodbccr.so.1 (gdb) where #0 0x in ?? () fault here, calling a NULL function. #1 0x00990ef2 in CLGetData (statement_handle=0x8faec48, column_number=2, target_type=1, target_value=0x8fb383c, buffer_length=256, strlen_or_ind=0x8fb36c4) at SQLGetData.c:336 this address is in libodbccr.so.1, part of unix odbc #2 0x00a58f0c in SQLGetData (statement_handle=0x8fae670, column_number=2, target_type=1, target_value=0x8fb383c, buffer_length=256, strlen_or_ind=0x8fb36c4) at SQLGetData.c:412 this address is in libodbccr.so.1, part of unix odbc #3 0x080abd8a in odbc_stmt_get_col (stmt=0x8fb7f94, colno=1, ptr=0xbfe6083c, len=0xbfe60838, caller_frees=0xbfe60834) at /home/wez/php5-200509161630/ext/pdo_odbc/odbc_stmt.c:434 this address is in the pdo odbc driver. What I suspect is the problem is that either informix doesn't set a flag to tell unixodbc about the functions it supports, or that unixodbc doesn't respect a flag that it should. Ultimately, unixODBC should catch that NULL and report an error properly. I don't think I can do anything while this crash problem exists, and I think you should file a bug report with the unix ODBC guys so that we can figure out what is going wrong, and then we can figure out how to make things work for you. I'm happy to co-operate with them in tracking this down. [2005-09-10 21:47:04] [EMAIL PROTECTED] That crash looks like the informix libraries are trying to call a NULL callback handler. There's no way I can debug this without being able to sit down at the machine with my hands on gdb; Can I get a non-privileged account on that machine, so that I can build a CLI php and test it? [2005-08-03 08:41:40] [EMAIL PROTECTED] Wez, the fix didn't quite fix it? :) (note to myself: need to get my eyes checked) [2005-08-03 06:32:45] scott dot barnett at thuringowa dot qld dot gov dot au Still having build problems. Thanks. (gdb) bt #0 0x in ?? () #1 0x002e7ef2 in CLGetData (statement_handle=0x83a5590, column_number=2, target_type=1, target_value=0x83a5a74, buffer_length=256, strlen_or_ind=0x83a57c4) at SQLGetData.c:336 #2 0x00498f0c in SQLGetData (statement_handle=0x83a4fb8, column_number=2, target_type=1, target_value=0x83a5a74, buffer_length=256, strlen_or_ind=0x83a57c4) at SQLGetData.c:412 #3 0x00d63d9e in odbc_stmt_get_col (stmt=0x83ae01c, colno=1, ptr=0xbff2e70c, len=0xbff2e708, caller_frees=0xbff2e704) at /usr/src/apache/php5-200508030230/ext/pdo_odbc/odbc_stmt.c:434 #4 0x00d5caa5 in fetch_value (stmt=0x83ae01c, dest=0x83a7724, colno=1) at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:447 #5 0x00d5d776 in do_fetch (stmt=0x83ae01c, do_bind=1, return_value=0x834b8cc, how=PDO_FETCH_OBJ, ori=PDO_FETCH_ORI_NEXT, offset=0, return_all=0x0) at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:870 #6 0x00d60903 in pdo_stmt_iter_get (ce=0x83004e0, object=0x834b94c) at /usr/src/apache/php5-200508030230/ext/pdo/pdo_stmt.c:2135 #7 0x00f42baf in ZEND_FE_RESET_SPEC_CV_HANDLER (execute_data=0xbff2ebf0) at
#42718 [Opn]: FILTER_UNSAFE_RAW not applied when configured as default filter, even with flags
ID: 42718
User updated by: arnaud dot lb at gmail dot com
-Summary: unsafe_raw not applied has default filter
Reported By: arnaud dot lb at gmail dot com
Status: Open
Bug Type:Filter related
PHP Version: 5.2.4
New Comment:
I made a little (one-line) patch for this bug:
https://s3.amazonaws.com/arnaud.lb/filter-bug-42718.patch.txt
And a testcase:
https://s3.amazonaws.com/arnaud.lb/bug42718.phpt.txt
And an other test case to check if the patch does not modify the
behavior of the php_sapi_filter() function:
- Apply filter, only if filter will do something (unsafe_raw with no
flags do nothing)
- Else, fallback to magic_quotes_gpc if enabled
https://s3.amazonaws.com/arnaud.lb/052.phpt.txt
Previous Comments:
[2007-09-20 16:54:55] arnaud dot lb at gmail dot com
Description:
The unsafe_raw filter is not applied when configured as default
filter.
I found that the php_sapi_filter() internal function in
ext/filter/filter.c intentionally bypass this filter:
if (!(IF_G(default_filter) == FILTER_UNSAFE_RAW)){
(apply default filter)
} else [...]
The unsafe_raw filter does nothing by default, but it
can optionally strip or encode special characters, and it is the
only filter which is able to do that without doing any other
filtering.
Reproduce code:
---
- Prints filter.default and filter.default_flags values,
- Check if $_GET['a'] contains a null byte (null bytes may be filtered
by FILTER_UNSAFE_RAW with the FILTER_FLAG_STRIP_LOW flag
- Check if $_GET['a'] though filter_input() with the same filter/flags
contains a null byte.
?php
echo filter.default = . ini_get('filter.default') . br /\n;
echo filter.default_flags = . ini_get('filter.default_flags') .
br /\n;
echo br /;
echo \$_GET['a'] contains \\0: . (strpos($_GET['a'], \0) !== false
? 'Yes' : 'No') . br /\n;
echo br /;
echo \$_GET['a'] throught filter_var() contains \\0: .
(strpos(filter_var($_GET['a'], FILTER_UNSAFE_RAW,
FILTER_FLAG_STRIP_LOW), \0) !== false ? 'Yes' : 'No') . br /;
echo br /;
?
Expected result:
filter.default: unsafe_raw
filter.default_flags: 4
$_GET['a'] contains \0: No
$_GET['a'] through filter_var() contains \0: No
Actual result:
--
filter.default: unsafe_raw
filter.default_flags: 4
$_GET['a'] contains \0: Yes
$_GET['a'] through filter_var() contains \0: No
--
Edit this bug report at http://bugs.php.net/?id=42718edit=1
#42748 [NEW]: $_POST not working
From: mazz3x at gmail dot com
Operating system: Arch Linux 2007.08.1
PHP version: 5.2.4
PHP Bug Type: Unknown/Other Function
Bug description: $_POST not working
Description:
when I try to submit i always get the same result...
Reproduce code:
---
?php
echo var_dump($_POST);
echo form method=\post\ action=\{$_SERVER['PHP_SELF']}\
input type=\text\ name=\test\ /
input type=\submit\ /
/form;
?
Expected result:
array(1) { [test]= string(7) testing }
Actual result:
--
array(0) { }
--
Edit bug report at http://bugs.php.net/?id=42748edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42748r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42748r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42748r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42748r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42748r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42748r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42748r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42748r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42748r=support
Expected behavior:http://bugs.php.net/fix.php?id=42748r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42748r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42748r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42748r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42748r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42748r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42748r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42748r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42748r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42748r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42748r=mysqlcfg
#42749 [NEW]: error_reporting() SOMETIMES does not have any affect
From: gabe at mudbugmedia dot com
Operating system: Linux proto 2.6.20-hardened-r5
PHP version: 5CVS-2007-09-24 (snap)
PHP Bug Type: Output Control
Bug description: error_reporting() SOMETIMES does not have any affect
Description:
Periodically PHP stops respecting calls to error_reporting() to alter
the current error level away from the system default specified in
php.ini. All calls to error_reporting() for the current connection
will not update the actual level. This behavior will occur with only
*some* of the connections, but not all of them. Reloading the page
(after waiting for the keep alive to time out) will sometimes result
in the expected behavior, and others will result in the erroneous
behavior. Restarting Apache (running 2.2.6 with mod_php) seems to
briefly fix the problem, but it eventually returns.
This behavior also occurs when trying to set the error reporting level
via .htaccess such as:
php_value E_ALL ^ E_NOTICE
when this occurs, a phpinfo() call shows that the error reporting
level has defaulted back to the system-wide default (specified in
php.ini) and ignores the php_value statement all together. Again,
this is behavior that only happens *sometimes* and alters between page
reloads.
As a side effect, this causes all supporting libraries that rely on
error suppression, like Smarty, to throw errors.
Reproduce code:
---
?php
var_dump(error_reporting());
var_dump(error_reporting(E_ALL ^ E_NOTICE ^ E_USER_NOTICE));
trigger_error('This should not be seen', E_USER_NOTICE);
echo $a; // should cause a notice
var_dump(error_reporting());
?
Expected result:
int(6143)
int(6143)
int(5111)
Actual result:
--
int(6143)
int(6143)
br /
bNotice/b: This should not be seen in
b/home/gabebug/public_html/error_reporting_tests.php/b on line
b5/bbr
/
br /
bNotice/b: Undefined variable: a in
b/home/gabebug/public_html/error_reporting_tests.php/b on line
b6/bbr
/
int(6143)
--
Edit bug report at http://bugs.php.net/?id=42749edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42749r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42749r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42749r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42749r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42749r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42749r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42749r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42749r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42749r=support
Expected behavior:http://bugs.php.net/fix.php?id=42749r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42749r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42749r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42749r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42749r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42749r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42749r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42749r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42749r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42749r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42749r=mysqlcfg
#42297 [Opn]: mysql_fetch functions return ? instead of utf8 chars other than latin1
ID: 42297
User updated by: bmilosavljevic at gmail dot com
Reported By: bmilosavljevic at gmail dot com
Status: Open
Bug Type:MySQL related
PHP Version: 4.4.7
New Comment:
I think I 've found the solution! This bug is due to MySQL, I think. If
the following sql query is executed: SET CHARACTER SET utf8 (without ;
is recommended)
immediately after establishing a connection, the problem is solved, at
least for me! Even more suitable query would be SET NAMES utf8, because
connection's query strings are also submitted to the server in utf8.
?php
$link = mysql_connect('localhost', 'database_username',
'database_user_pwd');
if (!$link) {
die('Could not connect: ' . mysql_error());
}
if (!mysql_select_db('database_name', $link)) {
echo 'Could not select database';
exit;
}
//could be also SET NAMES utf8
$sql = 'SET CHARACTER SET utf8';
$result = mysql_query($sql, $link);
...
?
and instead of ... any query executed should return proper utf8
characters. Check this please in your environment!
Previous Comments:
[2007-09-24 14:10:44] dev at unleashedmind dot com
Confirming that this bug exists.
[2007-08-14 16:07:27] bmilosavljevic at gmail dot com
Description:
mysql_fetch functions return question marks (?) instead of utf8 chars
(other than latin1). Tested on linux production server and on local
windows developer server as well.
--
Edit this bug report at http://bugs.php.net/?id=42297edit=1
#42749 [Com]: error_reporting() SOMETIMES does not have any affect
ID: 42749
Comment by: hoffie at gentoo dot org
Reported By: gabe at mudbugmedia dot com
Status: Open
Bug Type: Output Control
Operating System: Linux proto 2.6.20-hardened-r5
PHP Version: 5CVS-2007-09-24 (snap)
New Comment:
Might be related to bug 41561 (and related commits) when building with
threads (I guess this is the case here).
Previous Comments:
[2007-09-24 20:04:39] gabe at mudbugmedia dot com
Description:
Periodically PHP stops respecting calls to error_reporting() to alter
the current error level away from the system default specified in
php.ini. All calls to error_reporting() for the current connection
will not update the actual level. This behavior will occur with only
*some* of the connections, but not all of them. Reloading the page
(after waiting for the keep alive to time out) will sometimes result
in the expected behavior, and others will result in the erroneous
behavior. Restarting Apache (running 2.2.6 with mod_php) seems to
briefly fix the problem, but it eventually returns.
This behavior also occurs when trying to set the error reporting level
via .htaccess such as:
php_value E_ALL ^ E_NOTICE
when this occurs, a phpinfo() call shows that the error reporting
level has defaulted back to the system-wide default (specified in
php.ini) and ignores the php_value statement all together. Again,
this is behavior that only happens *sometimes* and alters between page
reloads.
As a side effect, this causes all supporting libraries that rely on
error suppression, like Smarty, to throw errors.
Reproduce code:
---
?php
var_dump(error_reporting());
var_dump(error_reporting(E_ALL ^ E_NOTICE ^ E_USER_NOTICE));
trigger_error('This should not be seen', E_USER_NOTICE);
echo $a; // should cause a notice
var_dump(error_reporting());
?
Expected result:
int(6143)
int(6143)
int(5111)
Actual result:
--
int(6143)
int(6143)
br /
bNotice/b: This should not be seen in
b/home/gabebug/public_html/error_reporting_tests.php/b on line
b5/bbr
/
br /
bNotice/b: Undefined variable: a in
b/home/gabebug/public_html/error_reporting_tests.php/b on line
b6/bbr
/
int(6143)
--
Edit this bug report at http://bugs.php.net/?id=42749edit=1
#42749 [Opn]: error_reporting() SOMETIMES does not have any affect
ID: 42749
User updated by: gabe at mudbugmedia dot com
Reported By: gabe at mudbugmedia dot com
Status: Open
Bug Type: Output Control
Operating System: Linux proto 2.6.20-hardened-r5
PHP Version: 5CVS-2007-09-24 (snap)
New Comment:
I don't think this is a threading problem, as I'm running Apache 2.2.6
under `prefork` mpm, and when I compiled (via gentoo USE flags -- not
sure what the 'thread' use flag corresponds to in the ./configure),
threads were disabled. Also, the last comment on #41561 states that
threads weren't involved and that it was patched in the CVS last week,
and I've been experiencing this behavior on today's CVS snap.
This is my configure statement:
'./configure' '--prefix=/usr/lib/php5' '--host=i686-pc-linux-gnu' '--
mandir=/usr/lib/php5/man' '--infodir=/usr/lib/php5/info' '--
sysconfdir=/etc' '--cache-file=./config.cache' '--disable-cli' '--
with-apxs2=/usr/sbin/apxs2' '--with-config-file-path=/etc/php/apache2-
php5' '--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active'
'--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar'
'--with-curl' '--without-curlwrappers' '--disable-dbase' '--disable-
exif' '--without-fbsql' '--without-fdftk' '--disable-filter' '--
disable-ftp' '--with-gettext' '--without-gmp' '--disable-hash' '--
without-iconv' '--disable-ipv6' '--disable-json' '--without-kerberos'
'--enable-mbstring' '--with-mcrypt' '--without-mhash' '--without-msql'
'--without-mssql' '--without-ncurses' '--with-openssl' '--with-
openssl-dir=/usr' '--disable-pcntl' '--disable-pdo' '--without-pgsql'
'--without-pspell' '--without-recode' '--disable-reflection' '--
disable-simplexml' '--disable-shmop' '--without-snmp' '--disable-soap'
'--disable-sockets' '--disable-spl' '--without-sybase' '--without-
sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm'
'--without-tidy' '--disable-tokenizer' '--disable-wddx' '--disable-
xmlreader' '--disable-xmlwriter' '--without-xmlrpc' '--without-xsl' '-
-disable-zip' '--with-zlib' '--disable-debug' '--without-cdb' '--
without-db4' '--without-flatfile' '--without-gdbm' '--without-inifile'
'--without-qdbm' '--without-freetype-dir' '--without-t1lib' '--
disable-gd-jis-conv' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--
without-xpm-dir' '--with-gd' '--with-mysql=/usr' '--with-mysql-
sock=/var/run/mysqld/mysqld.sock' '--without-mysqli' '--with-readline'
'--without-libedit' '--without-mm' '--without-sqlite' '--with-pic'
Previous Comments:
[2007-09-24 20:18:06] hoffie at gentoo dot org
Might be related to bug 41561 (and related commits) when building with
threads (I guess this is the case here).
[2007-09-24 20:04:39] gabe at mudbugmedia dot com
Description:
Periodically PHP stops respecting calls to error_reporting() to alter
the current error level away from the system default specified in
php.ini. All calls to error_reporting() for the current connection
will not update the actual level. This behavior will occur with only
*some* of the connections, but not all of them. Reloading the page
(after waiting for the keep alive to time out) will sometimes result
in the expected behavior, and others will result in the erroneous
behavior. Restarting Apache (running 2.2.6 with mod_php) seems to
briefly fix the problem, but it eventually returns.
This behavior also occurs when trying to set the error reporting level
via .htaccess such as:
php_value E_ALL ^ E_NOTICE
when this occurs, a phpinfo() call shows that the error reporting
level has defaulted back to the system-wide default (specified in
php.ini) and ignores the php_value statement all together. Again,
this is behavior that only happens *sometimes* and alters between page
reloads.
As a side effect, this causes all supporting libraries that rely on
error suppression, like Smarty, to throw errors.
Reproduce code:
---
?php
var_dump(error_reporting());
var_dump(error_reporting(E_ALL ^ E_NOTICE ^ E_USER_NOTICE));
trigger_error('This should not be seen', E_USER_NOTICE);
echo $a; // should cause a notice
var_dump(error_reporting());
?
Expected result:
int(6143)
int(6143)
int(5111)
Actual result:
--
int(6143)
int(6143)
br /
bNotice/b: This should not be seen in
b/home/gabebug/public_html/error_reporting_tests.php/b on line
b5/bbr
/
br /
bNotice/b: Undefined variable: a in
b/home/gabebug/public_html/error_reporting_tests.php/b on line
b6/bbr
/
int(6143)
--
Edit this bug report at http://bugs.php.net/?id=42749edit=1
#42749 [Opn]: error_reporting() SOMETIMES does not have any affect
ID: 42749
User updated by: gabe at mudbugmedia dot com
Reported By: gabe at mudbugmedia dot com
Status: Open
Bug Type: Output Control
Operating System: Linux proto 2.6.20-hardened-r5
PHP Version: 5CVS-2007-09-24 (snap)
New Comment:
I extended my reproduction code to check ini_set(), which suffers the
same behavior.
Code:
?php
var_dump(error_reporting());
var_dump(error_reporting(E_ALL ^ E_NOTICE ^ E_USER_NOTICE));
trigger_error('This should not be seen', E_USER_NOTICE);
echo $a; // should cause a notice
var_dump(error_reporting());
var_dump(ini_set('error_reporting', E_ALL ^ E_NOTICE ^ E_USER_NOTICE ^
E_USER_WARNING));
var_dump(error_reporting());
trigger_error('This should not be seen', E_USER_NOTICE);
echo $a; // should cause a notice
var_dump(error_reporting());
?
Output:
int(6143) int(6143)
Notice: This should not be seen in
/home/gabebug/public_html/error_reporting_tests.php on line 5
Notice: Undefined variable: a in
/home/gabebug/public_html/error_reporting_tests.php on line 6
int(6143) bool(false) int(6143)
Notice: This should not be seen in
/home/gabebug/public_html/error_reporting_tests.php on line 11
Notice: Undefined variable: a in
/home/gabebug/public_html/error_reporting_tests.php on line 12
int(6143)
Previous Comments:
[2007-09-24 20:54:00] gabe at mudbugmedia dot com
I don't think this is a threading problem, as I'm running Apache 2.2.6
under `prefork` mpm, and when I compiled (via gentoo USE flags -- not
sure what the 'thread' use flag corresponds to in the ./configure),
threads were disabled. Also, the last comment on #41561 states that
threads weren't involved and that it was patched in the CVS last week,
and I've been experiencing this behavior on today's CVS snap.
This is my configure statement:
'./configure' '--prefix=/usr/lib/php5' '--host=i686-pc-linux-gnu' '--
mandir=/usr/lib/php5/man' '--infodir=/usr/lib/php5/info' '--
sysconfdir=/etc' '--cache-file=./config.cache' '--disable-cli' '--
with-apxs2=/usr/sbin/apxs2' '--with-config-file-path=/etc/php/apache2-
php5' '--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active'
'--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar'
'--with-curl' '--without-curlwrappers' '--disable-dbase' '--disable-
exif' '--without-fbsql' '--without-fdftk' '--disable-filter' '--
disable-ftp' '--with-gettext' '--without-gmp' '--disable-hash' '--
without-iconv' '--disable-ipv6' '--disable-json' '--without-kerberos'
'--enable-mbstring' '--with-mcrypt' '--without-mhash' '--without-msql'
'--without-mssql' '--without-ncurses' '--with-openssl' '--with-
openssl-dir=/usr' '--disable-pcntl' '--disable-pdo' '--without-pgsql'
'--without-pspell' '--without-recode' '--disable-reflection' '--
disable-simplexml' '--disable-shmop' '--without-snmp' '--disable-soap'
'--disable-sockets' '--disable-spl' '--without-sybase' '--without-
sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm'
'--without-tidy' '--disable-tokenizer' '--disable-wddx' '--disable-
xmlreader' '--disable-xmlwriter' '--without-xmlrpc' '--without-xsl' '-
-disable-zip' '--with-zlib' '--disable-debug' '--without-cdb' '--
without-db4' '--without-flatfile' '--without-gdbm' '--without-inifile'
'--without-qdbm' '--without-freetype-dir' '--without-t1lib' '--
disable-gd-jis-conv' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--
without-xpm-dir' '--with-gd' '--with-mysql=/usr' '--with-mysql-
sock=/var/run/mysqld/mysqld.sock' '--without-mysqli' '--with-readline'
'--without-libedit' '--without-mm' '--without-sqlite' '--with-pic'
[2007-09-24 20:18:06] hoffie at gentoo dot org
Might be related to bug 41561 (and related commits) when building with
threads (I guess this is the case here).
[2007-09-24 20:04:39] gabe at mudbugmedia dot com
Description:
Periodically PHP stops respecting calls to error_reporting() to alter
the current error level away from the system default specified in
php.ini. All calls to error_reporting() for the current connection
will not update the actual level. This behavior will occur with only
*some* of the connections, but not all of them. Reloading the page
(after waiting for the keep alive to time out) will sometimes result
in the expected behavior, and others will result in the erroneous
behavior. Restarting Apache (running 2.2.6 with mod_php) seems to
briefly fix the problem, but it eventually returns.
This behavior also occurs when trying to set the error reporting level
via .htaccess such as:
php_value E_ALL ^ E_NOTICE
when this occurs, a phpinfo() call shows that the error reporting
level has defaulted back to the system-wide default (specified in
php.ini) and ignores the php_value statement all together. Again,
this is
#42749 [Opn]: error_reporting() SOMETIMES does not have any affect
ID: 42749
User updated by: gabe at mudbugmedia dot com
Reported By: gabe at mudbugmedia dot com
Status: Open
Bug Type: Output Control
Operating System: Linux proto 2.6.20-hardened-r5
PHP Version: 5CVS-2007-09-24 (snap)
New Comment:
In the comments of the other bug, this is mentioned:
When error_reporting was overwritten with ADMIN privileges it cannot
be
changed anymore by the @ operator :)
If I add something like:
@include 'doesnotexist';
at the end of the test file, no warning will be issued even when the
problem behavior is occurring. Usage of the '@' symbol for error
suppression is completely unaffected by this bug.
Previous Comments:
[2007-09-24 20:56:17] gabe at mudbugmedia dot com
I extended my reproduction code to check ini_set(), which suffers the
same behavior.
Code:
?php
var_dump(error_reporting());
var_dump(error_reporting(E_ALL ^ E_NOTICE ^ E_USER_NOTICE));
trigger_error('This should not be seen', E_USER_NOTICE);
echo $a; // should cause a notice
var_dump(error_reporting());
var_dump(ini_set('error_reporting', E_ALL ^ E_NOTICE ^ E_USER_NOTICE ^
E_USER_WARNING));
var_dump(error_reporting());
trigger_error('This should not be seen', E_USER_NOTICE);
echo $a; // should cause a notice
var_dump(error_reporting());
?
Output:
int(6143) int(6143)
Notice: This should not be seen in
/home/gabebug/public_html/error_reporting_tests.php on line 5
Notice: Undefined variable: a in
/home/gabebug/public_html/error_reporting_tests.php on line 6
int(6143) bool(false) int(6143)
Notice: This should not be seen in
/home/gabebug/public_html/error_reporting_tests.php on line 11
Notice: Undefined variable: a in
/home/gabebug/public_html/error_reporting_tests.php on line 12
int(6143)
[2007-09-24 20:54:00] gabe at mudbugmedia dot com
I don't think this is a threading problem, as I'm running Apache 2.2.6
under `prefork` mpm, and when I compiled (via gentoo USE flags -- not
sure what the 'thread' use flag corresponds to in the ./configure),
threads were disabled. Also, the last comment on #41561 states that
threads weren't involved and that it was patched in the CVS last week,
and I've been experiencing this behavior on today's CVS snap.
This is my configure statement:
'./configure' '--prefix=/usr/lib/php5' '--host=i686-pc-linux-gnu' '--
mandir=/usr/lib/php5/man' '--infodir=/usr/lib/php5/info' '--
sysconfdir=/etc' '--cache-file=./config.cache' '--disable-cli' '--
with-apxs2=/usr/sbin/apxs2' '--with-config-file-path=/etc/php/apache2-
php5' '--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active'
'--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar'
'--with-curl' '--without-curlwrappers' '--disable-dbase' '--disable-
exif' '--without-fbsql' '--without-fdftk' '--disable-filter' '--
disable-ftp' '--with-gettext' '--without-gmp' '--disable-hash' '--
without-iconv' '--disable-ipv6' '--disable-json' '--without-kerberos'
'--enable-mbstring' '--with-mcrypt' '--without-mhash' '--without-msql'
'--without-mssql' '--without-ncurses' '--with-openssl' '--with-
openssl-dir=/usr' '--disable-pcntl' '--disable-pdo' '--without-pgsql'
'--without-pspell' '--without-recode' '--disable-reflection' '--
disable-simplexml' '--disable-shmop' '--without-snmp' '--disable-soap'
'--disable-sockets' '--disable-spl' '--without-sybase' '--without-
sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm'
'--without-tidy' '--disable-tokenizer' '--disable-wddx' '--disable-
xmlreader' '--disable-xmlwriter' '--without-xmlrpc' '--without-xsl' '-
-disable-zip' '--with-zlib' '--disable-debug' '--without-cdb' '--
without-db4' '--without-flatfile' '--without-gdbm' '--without-inifile'
'--without-qdbm' '--without-freetype-dir' '--without-t1lib' '--
disable-gd-jis-conv' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--
without-xpm-dir' '--with-gd' '--with-mysql=/usr' '--with-mysql-
sock=/var/run/mysqld/mysqld.sock' '--without-mysqli' '--with-readline'
'--without-libedit' '--without-mm' '--without-sqlite' '--with-pic'
[2007-09-24 20:18:06] hoffie at gentoo dot org
Might be related to bug 41561 (and related commits) when building with
threads (I guess this is the case here).
[2007-09-24 20:04:39] gabe at mudbugmedia dot com
Description:
Periodically PHP stops respecting calls to error_reporting() to alter
the current error level away from the system default specified in
php.ini. All calls to error_reporting() for the current connection
will not update the actual level. This behavior will occur with only
*some* of the connections, but not all of them. Reloading the page
(after waiting for the keep alive to time out) will sometimes
#39312 [NoF-Opn]: Cannot install OCI_PDO
ID: 39312
User updated by: andrew dot nagy at villanova dot edu
Reported By: andrew dot nagy at villanova dot edu
-Status: No Feedback
+Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.6
New Comment:
I just did an install of php 5.2.4 on a brand new RHEL server. The
only way I could get this to work is by using the zip files provided by
Oracle, not the RPMs. Both the Basic and SDK are need (well I am
assuming the Basic is needed). Once I unzip the files, I needed to
create 2 symbolic links -- both libclntsh.so and libocci.so.
Could this be fixed in the configure script to look for the original
files instead of the renamed files?
For now - I have created a patch that makes the language a bit more
intuitive if this helps at all. It is diff'ed against the 5.2.4
release.
1305,1306c1305,1306
Use
--with-pdo-oci=instantclient,/path/to/instantclient,version
for an Oracle Instant Client SDK
install.
---
Use
--with-pdo-oci=instantclient,prefix,version
for an Oracle Instant Client SDK.
73096c73096
{ echo configure: error: I'm too dumb to figure out where the
include dir is in your Instant Client install 12; exit 1; }
---
{ echo configure: error: Cannot find the Instant Client SDK in
your Instant Client install 12; exit 1; }
73105c73105
{ echo configure: error: I'm too dumb to figure out where the
libraries are in your Instant Client install 12; exit 1; }
---
{ echo configure: error: Cannot find the libclntsh.so file.
Try making a symbolic link in your Instant Client SDK install 12;
exit 1; }
Previous Comments:
[2006-11-16 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2006-11-08 21:37:15] [EMAIL PROTECTED]
If you know how exactly to make it more verbose and clear - we would
gladly accept your patch for ext/pdo_oci/config.m4.
See here:
http://cvs.php.net/viewvc.cgi/php-src/ext/pdo_oci/config.m4?revision=1.14.2.5view=markup
[2006-11-08 21:21:48] andrew dot nagy at villanova dot edu
I guess I am saying that the error checking should be more verbose.
Instead of reporting Im too dumb to find your missing files.
The most important part is adding the installation procedure to the doc
page for PDO_OCI, but that hasn't been written yet it appears.
[2006-11-08 20:39:51] [EMAIL PROTECTED]
Is their anyway this checking can be added to the configure script?
What do you mean?
[2006-11-08 20:01:52] andrew dot nagy at villanova dot edu
Okay, that solved it.
I added the other symlink that you have and I added the version number
back into my configure statement and I was able to pass the configure.
Is their anyway this checking can be added to the configure script?
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/39312
--
Edit this bug report at http://bugs.php.net/?id=39312edit=1
#41712 [Asn]: [PATCH] Add CURL Progress Function Callback
ID: 41712
User updated by: sdteffen at gmail dot com
Reported By: sdteffen at gmail dot com
Status: Assigned
Bug Type: Feature/Change Request
Operating System: SuSE Linux 10.2
PHP Version: 5CVS-2007-06-16 (CVS)
Assigned To: iliaa
New Comment:
The progress function only returned 3 values instead of 4. The
following revised patch fixes this problem (it completely replaces the
previous patch):
diff -u php-5.2.3/ext/curl/interface.c
php-5.2.3.patched/ext/curl/interface.c
--- php-5.2.3/ext/curl/interface.c 2007-05-22 10:39:20.0 +0200
+++ php-5.2.3.patched/ext/curl/interface.c 2007-06-16
13:30:05.0 +0200
@@ -368,6 +368,7 @@
REGISTER_CURL_CONSTANT(CURLOPT_HEADER);
REGISTER_CURL_CONSTANT(CURLOPT_HTTPHEADER);
REGISTER_CURL_CONSTANT(CURLOPT_NOPROGRESS);
+ REGISTER_CURL_CONSTANT(CURLOPT_PROGRESSFUNCTION);
REGISTER_CURL_CONSTANT(CURLOPT_NOBODY);
REGISTER_CURL_CONSTANT(CURLOPT_FAILONERROR);
REGISTER_CURL_CONSTANT(CURLOPT_UPLOAD);
@@ -777,6 +778,80 @@
}
/* }}} */
+/* {{{ curl_progress
+ */
+static size_t curl_progress(void *clientp,
+double dltotal,
+double dlnow,
+double ultotal,
+double ulnow)
+{
+ php_curl *ch = (php_curl *) clientp;
+ php_curl_progress *t = ch-handlers-progress;
+ int length = -1;
+
+#if PHP_CURL_DEBUG
+ fprintf(stderr, curl_progress() called\n);
+ fprintf(stderr, clientp = %x, dltotal = %f, dlnow = %f, ultotal =
%f, ulnow = %f\n, clientp, dltotal, dlnow, ultotal, ulnow);
+#endif
+
+ switch (t-method) {
+ case PHP_CURL_USER: {
+ zval **argv[4];
+ zval *zdltotal = NULL;
+ zval *zdlnow = NULL;
+ zval *zultotal = NULL;
+ zval *zulnow = NULL;
+ zval *retval_ptr;
+ int error;
+ zend_fcall_info fci;
+ TSRMLS_FETCH_FROM_CTX(ch-thread_ctx);
+
+ MAKE_STD_ZVAL(zdltotal);
+ MAKE_STD_ZVAL(zdlnow);
+ MAKE_STD_ZVAL(zultotal);
+ MAKE_STD_ZVAL(zulnow);
+
+ ZVAL_LONG(zdltotal, dltotal);
+ ZVAL_LONG(zdlnow, dlnow);
+ ZVAL_LONG(zultotal, ultotal);
+ ZVAL_LONG(zulnow, ulnow);
+
+ argv[0] = zdltotal;
+ argv[1] = zdlnow;
+ argv[2] = zultotal;
+ argv[3] = zulnow;
+
+ fci.size = sizeof(fci);
+ fci.function_table = EG(function_table);
+ fci.function_name = t-func_name;
+ fci.object_pp = NULL;
+ fci.retval_ptr_ptr = retval_ptr;
+ fci.param_count = 4;
+ fci.params = argv;
+ fci.no_separation = 0;
+ fci.symbol_table = NULL;
+
+ ch-in_callback = 1;
+ error = zend_call_function(fci, t-fci_cache
TSRMLS_CC);
+ ch-in_callback = 0;
+ if (error == FAILURE) {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING,
Cannot call the
CURLOPT_READFUNCTION);
+ length = -1;
+ }
+
+ zval_ptr_dtor(argv[0]);
+ zval_ptr_dtor(argv[1]);
+ zval_ptr_dtor(argv[2]);
+ zval_ptr_dtor(argv[3]);
+ break;
+ }
+ }
+ return 0;
+}
+/* }}} */
+
+
/* {{{ curl_read
*/
static size_t curl_read(char *data, size_t size, size_t nmemb, void
*ctx)
@@ -1065,6 +1140,7 @@
(*ch)-handlers-write= ecalloc(1, sizeof(php_curl_write));
(*ch)-handlers-write_header = ecalloc(1, sizeof(php_curl_write));
(*ch)-handlers-read = ecalloc(1, sizeof(php_curl_read));
+ (*ch)-handlers-progress = ecalloc(1,
sizeof(php_curl_progress));
(*ch)-in_callback = 0;
(*ch)-header.str_len = 0;
@@ -1418,6 +1494,17 @@
ch-handlers-read-func_name = *zvalue;
ch-handlers-read-method = PHP_CURL_USER;
break;
+ case CURLOPT_PROGRESSFUNCTION:
+ curl_easy_setopt(ch-cp, CURLOPT_PROGRESSFUNCTION,
curl_progress);
+ curl_easy_setopt(ch-cp, CURLOPT_PROGRESSDATA, ch);
+ if (ch-handlers-progress-func_name) {
+
zval_ptr_dtor(ch-handlers-progress-func_name);
+
#42750 [NEW]: if session_name contains a dot, a new session is started every request
From: dominik dot dorn at gmail dot com Operating system: Gentoo Linux PHP version: 5.2.4 PHP Bug Type: Session related Bug description: if session_name contains a dot, a new session is started every request Description: i was trying to fool a little around and tried to set the session_name to MYSITE.NET_SessionID'. PHP sets a cookie with the name ASP.NET_SessionID but seems not to read it at the next page request. Reproduce code: --- I tried this with the session_name(ASP.NET_SessionID); function and with setting it thru php.ini session.name = MYSITE.NET_SessionID i even tried to surround the text with quotes in php.ini like session.name = MYSITE.NET_SessionID or session.name = 'MYSITE.NET_SessionID Expected result: php reads the session id from the cookie names MYSITE.NET_SessionID' and then reads the sessiondata with the specified sessionhash -- Edit bug report at http://bugs.php.net/?id=42750edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=42750r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=42750r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=42750r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=42750r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=42750r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=42750r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=42750r=needscript Try newer version:http://bugs.php.net/fix.php?id=42750r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=42750r=support Expected behavior:http://bugs.php.net/fix.php?id=42750r=notwrong Not enough info: http://bugs.php.net/fix.php?id=42750r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=42750r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=42750r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42750r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=42750r=dst IIS Stability:http://bugs.php.net/fix.php?id=42750r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=42750r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=42750r=float No Zend Extensions: http://bugs.php.net/fix.php?id=42750r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=42750r=mysqlcfg
