#48187 [Fbk->Opn]: DateTime::diff() corrupting microtime() result
ID: 48187 User updated by: wavetrex at gmail dot com Reported By: wavetrex at gmail dot com -Status: Feedback +Status: Open Bug Type: Date/time related Operating System: Windows 2003 Server PHP Version: 5.3.0RC2 New Comment: @jani: I'm using microtime() multiple times to determine how long some complex parts of the script take to execute, when I noticed weird differences. Also, while the second microtime() call after diff() is wrong, the third seems to be ok, just like calling the function resets some internal variable that was broken during execution of diff() I prepared a script on my server: http://wt.ath.cx/diff.php The code for this script is here: http://wt.ath.cx/diff.txt Server configuration: http://wt.ath.cx/phpinfo.php Time difference between the two calls: Expected result: 3.814697265625E-5 (a few microseconds) Actual result: -142455.45035195 (??) Your script: http://wt.ath.cx/jani.php ... also has the error. If this probably occurs on my server, I'm thinking... it might be timezone related ? I'm sure yours and mine are different. (check my phpinfo.php to see date/time settings) P.S. While investigating, I noticed that in some rare cases it doesn't happen, and after Ctrl-R it gives the erroned value again. Try reloading the page a few times in case 1st time it shows the correct values. I'll keep experimenting with the new 5.3.0 time functions and see if some other errors appear. Previous Comments: [2009-05-09 04:15:40] j...@php.net Try this script instead: (I can't reproduce this..) diff($date2)); var_dump($begin_u, microtime(true)); var_dump($begin_t, time()); var_dump($begin_a, date(DATE_ATOM)); ?> [2009-05-08 05:42:58] wavetrex at gmail dot com Description: calling DateTime::diff() seems to corrupt the result returned by microtime(), so it returns the wrong time after this function has been called Reproduce code: --- "; var_dump(microtime()); var_dump(time()); var_dump(date(DATE_ATOM)); var_dump($date1->diff($date2)); var_dump(microtime()); var_dump(time()); var_dump(date(DATE_ATOM)); echo ""; ?> Expected result: Expecting the 2nd microtime to be slightly bigger ( by a few miliseconds ) than first. instead, it's a totally wrong 5 seconds distance (or maybe other arbitrary value) date() and time() seem to be unaffected Actual result: -- before calling diff: string(21) "0.98425000 1241761004" after it: string(21) "0.25882200 1241709345" -- Edit this bug report at http://bugs.php.net/?id=48187&edit=1
#48198 [Opn->Asn]: error: 'MYSQLND_LLU_SPEC' undeclared
ID: 48198 Updated by: j...@php.net Reported By: ajmiller at engr dot psu dot edu -Status: Open +Status: Assigned Bug Type: MySQL related Operating System: Mac OS X Server 10.5.6 PHP Version: 5.3.0RC2 -Assigned To: +Assigned To: mysql Previous Comments: [2009-05-08 21:32:39] ajmiller at engr dot psu dot edu Description: Compiling with mysqlnd drivers failed. System: Mac OS X Server 10.5.6 on a G5 iMac with XCode 3.1.2 This bug is similar to that described in Bug #47992 /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_ps_codec.c:82: error: 'MYSQLND_LLU_SPEC' undeclared (first use in this function) /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_ps_codec.c:111: error: 'MYSQLND_LL_SPEC' undeclared (first use in this function) changing line 177 in ext/mysqlnd/mysqlnd_portability.h from #if __powerpc64__ to #if __powerpc64__ || __ppc64__ and line 192 from #if __powerpc__ && !__powerpc64__ to #if (__powerpc__ || __ppc__ ) && !(__powerpc64__ || __ppc64__) resolves the error. Reproduce code: --- ./configure '--prefix=/usr/local' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-apxs2=/usr/sbin/apxs' '--with-ldap=/usr' '--with-kerberos=/usr' '--enable-cli' '--with-zlib-dir=/usr' '--enable-trans-sid' '--with-xml' '--enable-exif' '--enable-ftp' '--enable-mbstring' '--enable-mbregex' '--enable-dbx' '--enable-sockets' '--with-iodbc=/usr' '--with-curl=/usr' '--with-config-file-path=/etc' '--sysconfdir=/private/etc' '--with-mysql-sock=/var/mysql' '--with-mysqli=mysqlnd' '--with-mysql=mysqlnd' '--with-openssl' '--with-xmlrpc' '--with-xsl=/usr' '--with-pear' Expected result: Compile with out errors. Actual result: -- /bin/sh /Users/ajmiller/Desktop/php-5.3.0RC2/libtool --silent -- preserve-dup-deps --mode=compile gcc -Iext/mysqlnd/ - I/Users/ajmiller/Desktop/php-5.3.0RC2/ext/mysqlnd/ -DPHP_ATOM_INC - I/Users/ajmiller/Desktop/php-5.3.0RC2/include - I/Users/ajmiller/Desktop/php-5.3.0RC2/main - I/Users/ajmiller/Desktop/php-5.3.0RC2 -I/Users/ajmiller/Desktop/php- 5.3.0RC2/ext/ereg/regex -I/usr/include/libxml2 - I/Users/ajmiller/Desktop/php-5.3.0RC2/ext/date/lib - I/Users/ajmiller/Desktop/php-5.3.0RC2/ext/mbstring/oniguruma - I/Users/ajmiller/Desktop/php-5.3.0RC2/ext/mbstring/libmbfl - I/Users/ajmiller/Desktop/php-5.3.0RC2/ext/mbstring/libmbfl/mbfl - I/Users/ajmiller/Desktop/php-5.3.0RC2/ext/sqlite3/libsqlite - I/Users/ajmiller/Desktop/php-5.3.0RC2/TSRM - I/Users/ajmiller/Desktop/php-5.3.0RC2/Zend -no-cpp-precomp -O2 - I/usr/include -fvisibility=hidden -c /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_ps_codec.c -o ext/mysqlnd/mysqlnd_ps_codec.lo In file included from /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd.h:59, from /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_ps_codec.c:23: /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_portability.h:471:1: warning: "float8get" redefined /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_portability.h:423:1: warning: this is the location of the previous definition /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_portability.h:472:1: warning: "float8store" redefined /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_portability.h:413:1: warning: this is the location of the previous definition /Users/ajmiller/Desktop/php-5.3.0RC2/ext/mysqlnd/mysqlnd_ps_codec.c: In function 'ps_fetch_from_1_to_8_bytes': /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_ps_codec.c:82: error: 'MYSQLND_LLU_SPEC' undeclared (first use in this function) /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_ps_codec.c:82: error: (Each undeclared identifier is reported only once /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_ps_codec.c:82: error: for each function it appears in.) /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_ps_codec.c:111: error: 'MYSQLND_LL_SPEC' undeclared (first use in this function) make: *** [ext/mysqlnd/mysqlnd_ps_codec.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=48198&edit=1
#48180 [Ver->WFx]: mb_ereg(i)_replace() evaluate replacement string not escaped properly
ID: 48180
Updated by: j...@php.net
Reported By: 5up3rh3i at gmail dot com
-Status: Verified
+Status: Wont fix
Bug Type: mbstring related
Operating System: *
PHP Version: 5.*CVS, 6CVS (2009-05-08)
New Comment:
Considered and realized that we can't really fix this. You just have to
do the 'addslashes()' yourself. Reason: doing "magical" addslashes()
call on the replacement would cause problems with certain encodings.
Previous Comments:
[2009-05-09 05:13:07] j...@php.net
This should show the problem more clearly:
[2009-05-07 14:54:22] 5up3rh3i at gmail dot com
Description:
when option parameter set e, matches not be escaped.
ex:
phpinfo() will be evaluated.
mb_ereg_replace()
if ((replace_len - i) >= 2 && fwd == 1 &&
p[0] == '\\' && p[1] >= '0' && p[1] <=
'9') {
n = p[1] - '0';
}
if (n >= 0 && n < regs->num_regs) {
if (regs->beg[n] >= 0 && regs->beg[n] <
regs->end[n] &&
regs->end[n] <= string_len) {
smart_str_appendl(pbuf, string
+ regs->beg[n], regs->end[n] -
regs->beg[n]);
// matches not be escaped
}
preg_replace()
if ('\\' == *walk || '$' == *walk) {
smart_str_appendl(&code, segment, walk - segment);
if (walk_last == '\\') {
code.c[code.len-1] = *walk++;
segment = walk;
walk_last = 0;
continue;
}
segment = walk;
if (preg_get_backref(&walk, &backref)) {
if (backref < count) {
/* Find the corresponding string match
and substitute it
in instead of the backref */
match = subject + offsets[backref<<1];
match_len = offsets[(backref<<1)+1] -
offsets[backref<<1];
if (match_len) {
esc_match =
php_addslashes_ex(match, match_len, &esc_match_len,
0, 1 TSRMLS_CC);
// matches escaped by addslashes()
...
smart_str_appendl(&code, esc_match,
esc_match_len);
--
Edit this bug report at http://bugs.php.net/?id=48180&edit=1
#48180 [Opn->Ver]: mb_ereg(i)_replace() evaluate replacement string not escaped properly
ID: 48180 Updated by: j...@php.net -Summary: mb_ereg(i)_replace() evaluate replacement string vulnerability Reported By: 5up3rh3i at gmail dot com -Status: Open +Status: Verified Bug Type: mbstring related Operating System: * -PHP Version: 5.2.9 +PHP Version: 5.*CVS, 6CVS (2009-05-08) New Comment: This should show the problem more clearly: Previous Comments: [2009-05-08 00:47:06] 5up3rh3i at gmail dot com plz try this code too why matches escaped in preg_replace(), but mb_ereg__replace() not? [2009-05-07 22:41:03] j...@php.net Yes, it works fine now. What's the bug? [2009-05-07 16:21:33] 5up3rh3i at gmail dot com plz try this code [2009-05-07 16:20:54] 5up3rh3i at gmail dot com Sorry, the test code is woring [2009-05-07 16:15:56] j...@php.net PHP Parse error: syntax error, unexpected T_LNUMBER, expecting T_STRING in /home/jani/t.php on line 3 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/48180 -- Edit this bug report at http://bugs.php.net/?id=48180&edit=1
#43857 [Asn]: --program-suffix not always reflected everywhere
ID: 43857 Updated by: j...@php.net Reported By: bjoern at xrow dot de Status: Assigned Bug Type: Compile Failure Operating System: linux PHP Version: 5.2.6 Assigned To: cellog New Comment: See also bug #48194 Previous Comments: [2009-04-20 04:43:02] cel...@php.net this is about to be fixed some time this week, the PEAR version with the fix should be released any day now, and once its stability is verified, we'll update the phar. I will update the Makefile.frag when this happens, and then change the status to Feedback to make sure it works for you (my preliminary testing has it working here) [2009-01-22 01:16:51] j...@php.net Was the package updated for 5.2.8 or not..? (it's 5.2.9 soon..) [2008-11-29 04:08:17] cel...@php.net this is now fixed in PEAR CVS, but I will keep this open until the install phar in php's source is updated [2008-11-29 03:43:14] cel...@php.net This is a very difficult problem to solve for all cases. Most fixes I've tried thus far break many other cases. For instance, the calls to "phpize" and "php-config" are done inside the source of PEAR/Builder.php. If we manually modify the source of PEAR/Builder.php, the instant a user calls "pear config-set php_bin /path/to/some/other/php" the whole thing breaks. So, what I am going to do is provide two new options to the "install" "upgrade" and "upgrade-all" commands which are designed to account for --program-suffix or --program-prefix being used, --program-suffix and --program-prefix which will programmatically append/prepend for the phpize/php-config commands. I'll also provide 2 new config variables that can be set to make this automatic. This new feature will not appear until PEAR 1.8.0 is released, which will hopefully be before PHP 5.3.0 [2008-02-18 11:05:10] j...@php.net This is actually PEAR bug, but as it's quite tightly connected to PHP we can keep this here. I don't know where that pecl script is and I don't want to touch it either since there's some new installer cooking..so Greg, can you please fix it to use the provided php-config instead? (note: php-config also might use the --program-prefix and --program-suffix options!) 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/43857 -- Edit this bug report at http://bugs.php.net/?id=43857&edit=1
#48194 [Opn->Fbk]: Invalid path to php binary in generated pear and pecl scripts
ID: 48194 Updated by: j...@php.net Reported By: oxie at live dot nl -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Ubuntu 8.04.2 PHP Version: 5.2.9 New Comment: Does /usr/local/lamp/php/bin/php-config exist? If so, what do these output: # /usr/local/lamp/php/bin/php-config --prefix And # /usr/local/lamp/php/bin/php-config --php-binary Previous Comments: [2009-05-08 19:48:33] oxie at live dot nl Description: The generated scripts bin/pear and bin/pecl have the wrong path to the PHP executable. The path in the script look likes '/usr/local/lamp/apache2/bin/apxs2/bin/apxs/bin/php', where it must be '/usr/local/lamp/php/bin/php'. When manually chaning the path to that, it is working. The output that i get is, logically: exec: 28: /usr/local/lamp/apache2/bin/apxs/bin/php: not found My configure statement: ./configure --prefix=/usr/local/lamp/php --with-apxs2=/usr/local/lamp/apache2/bin/apxs --with-pear=/usr/local/lamp/php/lib/php [a lot of extensions] The bin/pear script: http://pastebin.com/d132560e -- Edit this bug report at http://bugs.php.net/?id=48194&edit=1
#48187 [Opn->Fbk]: DateTime::diff() corrupting microtime() result
ID: 48187 Updated by: j...@php.net Reported By: wavetrex at gmail dot com -Status: Open +Status: Feedback Bug Type: Date/time related Operating System: Windows 2003 Server PHP Version: 5.3.0RC2 New Comment: Try this script instead: (I can't reproduce this..) diff($date2)); var_dump($begin_u, microtime(true)); var_dump($begin_t, time()); var_dump($begin_a, date(DATE_ATOM)); ?> Previous Comments: [2009-05-08 05:42:58] wavetrex at gmail dot com Description: calling DateTime::diff() seems to corrupt the result returned by microtime(), so it returns the wrong time after this function has been called Reproduce code: --- "; var_dump(microtime()); var_dump(time()); var_dump(date(DATE_ATOM)); var_dump($date1->diff($date2)); var_dump(microtime()); var_dump(time()); var_dump(date(DATE_ATOM)); echo ""; ?> Expected result: Expecting the 2nd microtime to be slightly bigger ( by a few miliseconds ) than first. instead, it's a totally wrong 5 seconds distance (or maybe other arbitrary value) date() and time() seem to be unaffected Actual result: -- before calling diff: string(21) "0.98425000 1241761004" after it: string(21) "0.25882200 1241709345" -- Edit this bug report at http://bugs.php.net/?id=48187&edit=1
#48190 [Ver]: Content-type parameter "boundary" is not case-insensitive in HTTP uploads
ID: 48190
Updated by: j...@php.net
Reported By: carsten_sttgt at gmx dot de
Status: Verified
Bug Type: HTTP related
Operating System: Windows NT
PHP Version: 5.*CVS, 6CVS (2009-05-08)
New Comment:
Yes, I know it's not an upload per se, but the code that handles is one
that most of the time takes care of file uploads. :)
Problem is in rfc1867.c:804, strstr() should be replaced with something
that does the same but case-insensitively.
Previous Comments:
[2009-05-09 04:07:33] j...@php.net
Yes, I know it's not an upload per se, but the code that handles is one
that most of the time takes care of file uploads. :)
Problem is in rfc1867.c:804, strstr() should be replaced with something
that does the same but case-insensitively.
[2009-05-08 23:23:57] carsten_sttgt at gmx dot de
> Just curious, but what client actually uses
> uppercase/mixed case "boundary" parameter name?
I'm using imap_mail_compose() to build the 'header' and 'content' keys
in the stream_context_create() options array. And then using this
context with e.g. file_get_contents() to make the POST request.
BTW: The above example is a HTTP POST request without a file upload.
[2009-05-08 22:05:58] j...@php.net
Just curious, but what client actually uses uppercase/mixed case
"boundary" parameter name? (and
[2009-05-08 21:41:55] carsten_sttgt at gmx dot de
In my first post I have refereed to RFC2045, but RFC2616 is also very
clear about this [1]:
| The type, subtype, and parameter attribute names are
| case- insensitive. Parameter values might or might
| not be case-sensitive, depending on the semantics
| of the parameter name.
type = MULTIPART
subtype = form-data
parameter attribute name = BOUNDARY
parameter value = 250-16659-1241787336=:9320
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7
[2009-05-08 13:46:57] carsten_sttgt at gmx dot de
Description:
Hello,
PHP does not work correctly with POST requests and a Content-Type of
MULTIPART/form-data, if the parameter name "BOUNDARY" is in uppercase.
According to RFC2045, matching of media type, subtype and parameter
(attributes) is always case-insensitive.
(only the value of the BOUNDARY parameter is compared case-sensitive)
Tested on Windows with 5.2-dev, 5.3-dev and 6.0-dev. CGI and Apache
module.
Regards,
Carsten
Reproduce code:
---
Put this textfile in your PHP directory:
test.txt **
--250-16659-1241787336=:9320
Content-Type: TEXT/plain; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: form-data; name=nick
php-faq
--250-16659-1241787336=:9320
Content-Type: TEXT/plain; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: form-data; name=desc
post demo script
--250-16659-1241787336=:9320--
Put this phpfile in your PHP directory:
test.php **
Open a command prompt, go to your PHP dir and execute:
# set REQUEST_METHOD=POST
# set REDIRECT_STATUS=1
# set SCRIPT_FILENAME=test.php
# set CONTENT_LENGTH=391
# set CONTENT_TYPE=MULTIPART/form-data;
BOUNDARY="250-16659-1241787336=:9320"
# type test.text | php-cgi.exe
if you set CONTENT_TYPE in this way, you have the correct result:
# set CONTENT_TYPE=MULTIPART/form-data;
boundary="250-16659-1241787336=:9320"
Regards,
Carsten
BTW:
e.g. the IMAP-Module from PHP is using/generating BOUNDARY in
uppercase.
Expected result:
Content-type: text/html
array(2) {
["nick"]=>
string(7) "php-faq"
["desc"]=>
string(16) "post demo script"
}
Actual result:
--
Content-type: text/html
Warning: Missing boundary in multipart/form-data POST data in
Unknown
on line 0
array(0) {
}
--
Edit this bug report at http://bugs.php.net/?id=48190&edit=1
#48190 [Opn->Ver]: Content-type parameter "boundary" is not case-insensitive in HTTP uploads
ID: 48190
Updated by: j...@php.net
Reported By: carsten_sttgt at gmx dot de
-Status: Open
+Status: Verified
Bug Type: HTTP related
Operating System: Windows NT
PHP Version: 5.*CVS, 6CVS (2009-05-08)
New Comment:
Yes, I know it's not an upload per se, but the code that handles is one
that most of the time takes care of file uploads. :)
Problem is in rfc1867.c:804, strstr() should be replaced with something
that does the same but case-insensitively.
Previous Comments:
[2009-05-08 23:23:57] carsten_sttgt at gmx dot de
> Just curious, but what client actually uses
> uppercase/mixed case "boundary" parameter name?
I'm using imap_mail_compose() to build the 'header' and 'content' keys
in the stream_context_create() options array. And then using this
context with e.g. file_get_contents() to make the POST request.
BTW: The above example is a HTTP POST request without a file upload.
[2009-05-08 22:05:58] j...@php.net
Just curious, but what client actually uses uppercase/mixed case
"boundary" parameter name? (and
[2009-05-08 21:41:55] carsten_sttgt at gmx dot de
In my first post I have refereed to RFC2045, but RFC2616 is also very
clear about this [1]:
| The type, subtype, and parameter attribute names are
| case- insensitive. Parameter values might or might
| not be case-sensitive, depending on the semantics
| of the parameter name.
type = MULTIPART
subtype = form-data
parameter attribute name = BOUNDARY
parameter value = 250-16659-1241787336=:9320
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7
[2009-05-08 13:46:57] carsten_sttgt at gmx dot de
Description:
Hello,
PHP does not work correctly with POST requests and a Content-Type of
MULTIPART/form-data, if the parameter name "BOUNDARY" is in uppercase.
According to RFC2045, matching of media type, subtype and parameter
(attributes) is always case-insensitive.
(only the value of the BOUNDARY parameter is compared case-sensitive)
Tested on Windows with 5.2-dev, 5.3-dev and 6.0-dev. CGI and Apache
module.
Regards,
Carsten
Reproduce code:
---
Put this textfile in your PHP directory:
test.txt **
--250-16659-1241787336=:9320
Content-Type: TEXT/plain; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: form-data; name=nick
php-faq
--250-16659-1241787336=:9320
Content-Type: TEXT/plain; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: form-data; name=desc
post demo script
--250-16659-1241787336=:9320--
Put this phpfile in your PHP directory:
test.php **
Open a command prompt, go to your PHP dir and execute:
# set REQUEST_METHOD=POST
# set REDIRECT_STATUS=1
# set SCRIPT_FILENAME=test.php
# set CONTENT_LENGTH=391
# set CONTENT_TYPE=MULTIPART/form-data;
BOUNDARY="250-16659-1241787336=:9320"
# type test.text | php-cgi.exe
if you set CONTENT_TYPE in this way, you have the correct result:
# set CONTENT_TYPE=MULTIPART/form-data;
boundary="250-16659-1241787336=:9320"
Regards,
Carsten
BTW:
e.g. the IMAP-Module from PHP is using/generating BOUNDARY in
uppercase.
Expected result:
Content-type: text/html
array(2) {
["nick"]=>
string(7) "php-faq"
["desc"]=>
string(16) "post demo script"
}
Actual result:
--
Content-type: text/html
Warning: Missing boundary in multipart/form-data POST data in
Unknown
on line 0
array(0) {
}
--
Edit this bug report at http://bugs.php.net/?id=48190&edit=1
#48196 [Opn->Ver]: Bug in string concatenation after calling preg_match_all()
ID: 48196 Updated by: j...@php.net Reported By: saulo_gil at argentina dot com -Status: Open +Status: Verified Bug Type: PCRE related -Operating System: Windows XP +Operating System: win32 only - Windows XP -PHP Version: 5.2.9, 5.3.0RC2 +PHP Version: 5.*, 6CVS (2009-05-09) New Comment: Verified under windows. Does NOT happen with other OSes. Previous Comments: [2009-05-09 01:18:28] saulo_gil at argentina dot com Forgot to mention one thing, I've tried to reproduce this bug using the PHP CLI, calling this script with php.exe -q I've just reproduced it again on a freshly installed XP box. Same happened with PHP 5.2.9-2. [2009-05-08 23:26:18] fel...@php.net I can't reproduce it. [2009-05-08 20:33:55] saulo_gil at argentina dot com Description: If I try to perform a simple concatenation involving a variable created from the matches output of preg_match_all() the resulting string is borked. Please see the code above. What I want to do: echo "[" . $var . "]"; Reproduce code: --- Expected result: [SPD_EXECUTIVE_PROVIDER_DEALER] Actual result: -- ]SPD_EXECUTIVE_PROVIDER_DEALER -- Edit this bug report at http://bugs.php.net/?id=48196&edit=1
#48197 [Opn->Asn]: __call performs extra allocs
ID: 48197 Updated by: j...@php.net Reported By: rodricg at sellingsource dot com -Status: Open +Status: Assigned Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5.3.0RC2 -Assigned To: +Assigned To: dmitry New Comment: Dmitry, can you please check this out.. Previous Comments: [2009-05-08 20:43:02] rodricg at sellingsource dot com Description: When returning a value from __call (as compared to a non-dynamic method) extra memory is allocated. This leads to performance degradation dependent on the size of the returned value. Hopefully this is a better description/example of bug #47525. Reproduce code: --- http://rodric.org/mem.phps This script takes 3 arguments. ie. mem.php See "Actual Result" for invocations. Expected result: Bytes allocated when using __call should be similar to not using __call. When using __call the time taken should not degrade linearly as the size of the result value increases. Actual result: -- Change USE_ZEND_ALLOC to 1 and you will see that "magic" performs exactly more allocs than "getStr". Using __call: USE_ZEND_ALLOC=0 valgrind php -n -d memory_limit=1024M mem.php 100 magic 100 2>&1 | pcregrep "Time|allocs" Time: 1.5781 ==25158== malloc/free: 19,564 allocs, 18,033 frees, 104,476,083 bytes allocated. USE_ZEND_ALLOC=0 valgrind php -n -d memory_limit=1024M mem.php 100 magic 200 2>&1 | pcregrep "Time|allocs" Time: 3.1066 ==25161== malloc/free: 19,564 allocs, 18,033 frees, 205,476,083 bytes allocated. Not Using __call: USE_ZEND_ALLOC=0 valgrind php -n -d memory_limit=1024M mem.php 100 getStr 100 2>&1 | pcregrep "Time|allocs" Time: 0.0280 ==25181== malloc/free: 18,764 allocs, 17,233 frees, 4,444,183 bytes allocated. USE_ZEND_ALLOC=0 valgrind php -n -d memory_limit=1024M mem.php 100 getStr 200 2>&1 | pcregrep "Time|allocs" Time: 0.0281 ==25183== malloc/free: 18,764 allocs, 17,233 frees, 5,444,183 bytes allocated. -- Edit this bug report at http://bugs.php.net/?id=48197&edit=1
#36030 [Com]: stream_set_timeout() does not work for php://stdin
ID: 36030 Comment by: squid3 at treenet dot co dot nz Reported By: silencer at inbox dot ru Status: No Feedback Bug Type: Streams related Operating System: * PHP Version: 5.1.2 New Comment: Encountered this bug when upgrading php4 to php5 about a year ago. It no longer seems to be an issue as of: Debian Lenny PHP 5.2.9-2 with Suhosin-Patch 0.9.7 (cli) (built: Apr 25 2009 08:53:53) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies Previous Comments: [2008-07-24 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". [2008-07-13 15:56:35] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2006-01-16 10:56:22] silencer at inbox dot ru Description: stream_set_timeout can't be used for php://stdin (PHP executed as CGI, not Apache module). Bug #22837 describe same problem for PHP4 and promises "better support" in PHP5, but still don't working. Reproduce code: --- Expected result: output "Success" Actual result: -- output "Failed" -- Edit this bug report at http://bugs.php.net/?id=36030&edit=1
#48196 [Opn]: Reproducible bug in string concatenation after calling preg_match_all
ID: 48196 User updated by: saulo_gil at argentina dot com -Summary: bug in string concatenation after calling preg_match_all() Reported By: saulo_gil at argentina dot com Status: Open Bug Type: PCRE related Operating System: Windows XP PHP Version: 5.3.0RC2 New Comment: Forgot to mention one thing, I've tried to reproduce this bug using the PHP CLI, calling this script with php.exe -q I've just reproduced it again on a freshly installed XP box. Same happened with PHP 5.2.9-2. Previous Comments: [2009-05-08 23:26:18] fel...@php.net I can't reproduce it. [2009-05-08 20:33:55] saulo_gil at argentina dot com Description: If I try to perform a simple concatenation involving a variable created from the matches output of preg_match_all() the resulting string is borked. Please see the code above. What I want to do: echo "[" . $var . "]"; Reproduce code: --- Expected result: [SPD_EXECUTIVE_PROVIDER_DEALER] Actual result: -- ]SPD_EXECUTIVE_PROVIDER_DEALER -- Edit this bug report at http://bugs.php.net/?id=48196&edit=1
#48193 [Opn->Fbk]: ODBC crash from PHP
ID: 48193
Updated by: fel...@php.net
Reported By: leo dot nnnaaarrrdddooo at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: ODBC related
Operating System: Debian 5.0 "Lenny" AMD64
PHP Version: 5.2CVS-2009-05-08 (CVS)
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:
[2009-05-08 17:32:06] leo dot nnnaaarrrdddooo at gmail dot com
I did two clean installs of Debian 5.0 AMD64 to check I didn't have
anything wrong installed.
[2009-05-08 17:26:38] leo dot nnnaaarrrdddooo at gmail dot com
Description:
ODBC crashes when using php script included (using a MySQL database),
and an
ALERT - canary mismatch on efree() - heap overflow detected (attacker
'X.X.X.X', etc ...)
line pops up in the error.log for apache.
This happens on current stable Debian 5.0 "lenny" AMD64, with system up
to date as of today, running: apache2, php5, mysql-server.
Compiling latest MySQL odbc driver version 5.1.5 doesn't crash, but
does lock up the calling process if same script is run with php5 client
from command line.
Reproduce code:
---
$conn="DRIVER={MySQL}; DatabaseName='test';
CommLinks=tcpip(Host=localhost); ";
$conn=odbc_connect($conn, "user", "");
$sql='SELECT * FROM test.T1;';
echo $sql;
$pg_query=odbc_exec($pg_conn, $sql);
odbc_close($pg_conn);
echo "A";
--
Edit this bug report at http://bugs.php.net/?id=48193&edit=1
#48196 [Opn]: Reproducible bug in string concatenation after calling preg_match_all
ID: 48196 Updated by: fel...@php.net Reported By: saulo_gil at argentina dot com Status: Open Bug Type: PCRE related Operating System: Windows XP PHP Version: 5.3.0RC2 New Comment: I can't reproduce it. Previous Comments: [2009-05-08 20:33:55] saulo_gil at argentina dot com Description: If I try to perform a simple concatenation involving a variable created from the matches output of preg_match_all() the resulting string is borked. Please see the code above. What I want to do: echo "[" . $var . "]"; Reproduce code: --- Expected result: [SPD_EXECUTIVE_PROVIDER_DEALER] Actual result: -- ]SPD_EXECUTIVE_PROVIDER_DEALER -- Edit this bug report at http://bugs.php.net/?id=48196&edit=1
#48190 [Opn]: Content-type parameter "boundary" is not case-insensitive in HTTP uploads
ID: 48190
User updated by: carsten_sttgt at gmx dot de
Reported By: carsten_sttgt at gmx dot de
Status: Open
Bug Type: HTTP related
Operating System: Windows NT
PHP Version: 5.*CVS, 6CVS (2009-05-08)
New Comment:
> Just curious, but what client actually uses
> uppercase/mixed case "boundary" parameter name?
I'm using imap_mail_compose() to build the 'header' and 'content' keys
in the stream_context_create() options array. And then using this
context with e.g. file_get_contents() to make the POST request.
BTW: The above example is a HTTP POST request without a file upload.
Previous Comments:
[2009-05-08 22:05:58] j...@php.net
Just curious, but what client actually uses uppercase/mixed case
"boundary" parameter name? (and
[2009-05-08 21:41:55] carsten_sttgt at gmx dot de
In my first post I have refereed to RFC2045, but RFC2616 is also very
clear about this [1]:
| The type, subtype, and parameter attribute names are
| case- insensitive. Parameter values might or might
| not be case-sensitive, depending on the semantics
| of the parameter name.
type = MULTIPART
subtype = form-data
parameter attribute name = BOUNDARY
parameter value = 250-16659-1241787336=:9320
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7
[2009-05-08 13:46:57] carsten_sttgt at gmx dot de
Description:
Hello,
PHP does not work correctly with POST requests and a Content-Type of
MULTIPART/form-data, if the parameter name "BOUNDARY" is in uppercase.
According to RFC2045, matching of media type, subtype and parameter
(attributes) is always case-insensitive.
(only the value of the BOUNDARY parameter is compared case-sensitive)
Tested on Windows with 5.2-dev, 5.3-dev and 6.0-dev. CGI and Apache
module.
Regards,
Carsten
Reproduce code:
---
Put this textfile in your PHP directory:
test.txt **
--250-16659-1241787336=:9320
Content-Type: TEXT/plain; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: form-data; name=nick
php-faq
--250-16659-1241787336=:9320
Content-Type: TEXT/plain; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: form-data; name=desc
post demo script
--250-16659-1241787336=:9320--
Put this phpfile in your PHP directory:
test.php **
Open a command prompt, go to your PHP dir and execute:
# set REQUEST_METHOD=POST
# set REDIRECT_STATUS=1
# set SCRIPT_FILENAME=test.php
# set CONTENT_LENGTH=391
# set CONTENT_TYPE=MULTIPART/form-data;
BOUNDARY="250-16659-1241787336=:9320"
# type test.text | php-cgi.exe
if you set CONTENT_TYPE in this way, you have the correct result:
# set CONTENT_TYPE=MULTIPART/form-data;
boundary="250-16659-1241787336=:9320"
Regards,
Carsten
BTW:
e.g. the IMAP-Module from PHP is using/generating BOUNDARY in
uppercase.
Expected result:
Content-type: text/html
array(2) {
["nick"]=>
string(7) "php-faq"
["desc"]=>
string(16) "post demo script"
}
Actual result:
--
Content-type: text/html
Warning: Missing boundary in multipart/form-data POST data in
Unknown
on line 0
array(0) {
}
--
Edit this bug report at http://bugs.php.net/?id=48190&edit=1
#48190 [Opn]: Content-type parameter "boundary" is not case-insensitive in HTTP uploads
ID: 48190
Updated by: j...@php.net
-Summary: wrong content-type parsing
Reported By: carsten_sttgt at gmx dot de
Status: Open
Bug Type: HTTP related
Operating System: Windows NT
PHP Version: 5.*CVS, 6CVS (2009-05-08)
New Comment:
Just curious, but what client actually uses uppercase/mixed case
"boundary" parameter name? (and
Previous Comments:
[2009-05-08 21:41:55] carsten_sttgt at gmx dot de
In my first post I have refereed to RFC2045, but RFC2616 is also very
clear about this [1]:
| The type, subtype, and parameter attribute names are
| case- insensitive. Parameter values might or might
| not be case-sensitive, depending on the semantics
| of the parameter name.
type = MULTIPART
subtype = form-data
parameter attribute name = BOUNDARY
parameter value = 250-16659-1241787336=:9320
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7
[2009-05-08 13:46:57] carsten_sttgt at gmx dot de
Description:
Hello,
PHP does not work correctly with POST requests and a Content-Type of
MULTIPART/form-data, if the parameter name "BOUNDARY" is in uppercase.
According to RFC2045, matching of media type, subtype and parameter
(attributes) is always case-insensitive.
(only the value of the BOUNDARY parameter is compared case-sensitive)
Tested on Windows with 5.2-dev, 5.3-dev and 6.0-dev. CGI and Apache
module.
Regards,
Carsten
Reproduce code:
---
Put this textfile in your PHP directory:
test.txt **
--250-16659-1241787336=:9320
Content-Type: TEXT/plain; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: form-data; name=nick
php-faq
--250-16659-1241787336=:9320
Content-Type: TEXT/plain; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: form-data; name=desc
post demo script
--250-16659-1241787336=:9320--
Put this phpfile in your PHP directory:
test.php **
Open a command prompt, go to your PHP dir and execute:
# set REQUEST_METHOD=POST
# set REDIRECT_STATUS=1
# set SCRIPT_FILENAME=test.php
# set CONTENT_LENGTH=391
# set CONTENT_TYPE=MULTIPART/form-data;
BOUNDARY="250-16659-1241787336=:9320"
# type test.text | php-cgi.exe
if you set CONTENT_TYPE in this way, you have the correct result:
# set CONTENT_TYPE=MULTIPART/form-data;
boundary="250-16659-1241787336=:9320"
Regards,
Carsten
BTW:
e.g. the IMAP-Module from PHP is using/generating BOUNDARY in
uppercase.
Expected result:
Content-type: text/html
array(2) {
["nick"]=>
string(7) "php-faq"
["desc"]=>
string(16) "post demo script"
}
Actual result:
--
Content-type: text/html
Warning: Missing boundary in multipart/form-data POST data in
Unknown
on line 0
array(0) {
}
--
Edit this bug report at http://bugs.php.net/?id=48190&edit=1
#48195 [Opn->Fbk]: iconv link failure
ID: 48195 Updated by: j...@php.net Reported By: rickdunn at chez dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: OS X 10.5.6 PHP Version: 5.3.0RC2 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2009-05-08 19:50:44] rickdunn at chez dot com Description: Bug #43189 has returned in 5.3 RC2. Make fails with 'undefined symbols' related to iconv. Reproduce code: --- CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer -arch x86_64 -m64" CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti -arch x86_64 -m64" ./configure --prefix=/usr/local/php5 --with-apxs2=/usr/sbin/apxs --with-config-file-scan-dir=/usr/local/php5/php.d --with-ldap=/usr --with-bz2=/usr --with-kerberos=/usr --enable-cli --with-zlib-dir=/usr --enable-exif --enable-soap --enable-ftp --enable-mbstring --enable-mbregex --enable-sockets --with-iodbc=/usr --with-curl=shared,/usr --sysconfdir=/private/etc --with-mysqli=mysqlnd --with-mysql=mysqlnd --with-pdo-mysql=mysqlnd --with-openssl --with-xmlrpc --with-xsl=/usr --with-gd --with-jpeg-dir=/usr/local/lib --with-png-dir=/usr/X11R6 --with-freetype-dir=/usr/X11R6 --with-xpm-dir=/usr/X11R6 --enable-gd-native-ttf --with-mcrypt=shared --enable-calendar --enable-bcmath Expected result: Successful installation. Actual result: -- Make fails. -- Edit this bug report at http://bugs.php.net/?id=48195&edit=1
#48190 [Opn]: wrong content-type parsing
ID: 48190
User updated by: carsten_sttgt at gmx dot de
Reported By: carsten_sttgt at gmx dot de
Status: Open
Bug Type: HTTP related
Operating System: Windows NT
PHP Version: 5.*CVS, 6CVS (2009-05-08)
New Comment:
In my first post I have refereed to RFC2045, but RFC2616 is also very
clear about this [1]:
| The type, subtype, and parameter attribute names are
| case- insensitive. Parameter values might or might
| not be case-sensitive, depending on the semantics
| of the parameter name.
type = MULTIPART
subtype = form-data
parameter attribute name = BOUNDARY
parameter value = 250-16659-1241787336=:9320
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7
Previous Comments:
[2009-05-08 13:46:57] carsten_sttgt at gmx dot de
Description:
Hello,
PHP does not work correctly with POST requests and a Content-Type of
MULTIPART/form-data, if the parameter name "BOUNDARY" is in uppercase.
According to RFC2045, matching of media type, subtype and parameter
(attributes) is always case-insensitive.
(only the value of the BOUNDARY parameter is compared case-sensitive)
Tested on Windows with 5.2-dev, 5.3-dev and 6.0-dev. CGI and Apache
module.
Regards,
Carsten
Reproduce code:
---
Put this textfile in your PHP directory:
test.txt **
--250-16659-1241787336=:9320
Content-Type: TEXT/plain; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: form-data; name=nick
php-faq
--250-16659-1241787336=:9320
Content-Type: TEXT/plain; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: form-data; name=desc
post demo script
--250-16659-1241787336=:9320--
Put this phpfile in your PHP directory:
test.php **
Open a command prompt, go to your PHP dir and execute:
# set REQUEST_METHOD=POST
# set REDIRECT_STATUS=1
# set SCRIPT_FILENAME=test.php
# set CONTENT_LENGTH=391
# set CONTENT_TYPE=MULTIPART/form-data;
BOUNDARY="250-16659-1241787336=:9320"
# type test.text | php-cgi.exe
if you set CONTENT_TYPE in this way, you have the correct result:
# set CONTENT_TYPE=MULTIPART/form-data;
boundary="250-16659-1241787336=:9320"
Regards,
Carsten
BTW:
e.g. the IMAP-Module from PHP is using/generating BOUNDARY in
uppercase.
Expected result:
Content-type: text/html
array(2) {
["nick"]=>
string(7) "php-faq"
["desc"]=>
string(16) "post demo script"
}
Actual result:
--
Content-type: text/html
Warning: Missing boundary in multipart/form-data POST data in
Unknown
on line 0
array(0) {
}
--
Edit this bug report at http://bugs.php.net/?id=48190&edit=1
#48198 [NEW]: Compile failure with mysqlnd similar to Bug #47992
From: ajmiller at engr dot psu dot edu Operating system: Mac OS X Server 10.5.6 PHP version: 5.3.0RC2 PHP Bug Type: Compile Failure Bug description: Compile failure with mysqlnd similar to Bug #47992 Description: Compiling with mysqlnd drivers failed. System: Mac OS X Server 10.5.6 on a G5 iMac with XCode 3.1.2 This bug is similar to that described in Bug #47992 /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_ps_codec.c:82: error: 'MYSQLND_LLU_SPEC' undeclared (first use in this function) /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_ps_codec.c:111: error: 'MYSQLND_LL_SPEC' undeclared (first use in this function) changing line 177 in ext/mysqlnd/mysqlnd_portability.h from #if __powerpc64__ to #if __powerpc64__ || __ppc64__ and line 192 from #if __powerpc__ && !__powerpc64__ to #if (__powerpc__ || __ppc__ ) && !(__powerpc64__ || __ppc64__) resolves the error. Reproduce code: --- ./configure '--prefix=/usr/local' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-apxs2=/usr/sbin/apxs' '--with-ldap=/usr' '--with-kerberos=/usr' '--enable-cli' '--with-zlib-dir=/usr' '--enable-trans-sid' '--with-xml' '--enable-exif' '--enable-ftp' '--enable-mbstring' '--enable-mbregex' '--enable-dbx' '--enable-sockets' '--with-iodbc=/usr' '--with-curl=/usr' '--with-config-file-path=/etc' '--sysconfdir=/private/etc' '--with-mysql-sock=/var/mysql' '--with-mysqli=mysqlnd' '--with-mysql=mysqlnd' '--with-openssl' '--with-xmlrpc' '--with-xsl=/usr' '--with-pear' Expected result: Compile with out errors. Actual result: -- /bin/sh /Users/ajmiller/Desktop/php-5.3.0RC2/libtool --silent -- preserve-dup-deps --mode=compile gcc -Iext/mysqlnd/ - I/Users/ajmiller/Desktop/php-5.3.0RC2/ext/mysqlnd/ -DPHP_ATOM_INC - I/Users/ajmiller/Desktop/php-5.3.0RC2/include - I/Users/ajmiller/Desktop/php-5.3.0RC2/main - I/Users/ajmiller/Desktop/php-5.3.0RC2 -I/Users/ajmiller/Desktop/php- 5.3.0RC2/ext/ereg/regex -I/usr/include/libxml2 - I/Users/ajmiller/Desktop/php-5.3.0RC2/ext/date/lib - I/Users/ajmiller/Desktop/php-5.3.0RC2/ext/mbstring/oniguruma - I/Users/ajmiller/Desktop/php-5.3.0RC2/ext/mbstring/libmbfl - I/Users/ajmiller/Desktop/php-5.3.0RC2/ext/mbstring/libmbfl/mbfl - I/Users/ajmiller/Desktop/php-5.3.0RC2/ext/sqlite3/libsqlite - I/Users/ajmiller/Desktop/php-5.3.0RC2/TSRM - I/Users/ajmiller/Desktop/php-5.3.0RC2/Zend -no-cpp-precomp -O2 - I/usr/include -fvisibility=hidden -c /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_ps_codec.c -o ext/mysqlnd/mysqlnd_ps_codec.lo In file included from /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd.h:59, from /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_ps_codec.c:23: /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_portability.h:471:1: warning: "float8get" redefined /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_portability.h:423:1: warning: this is the location of the previous definition /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_portability.h:472:1: warning: "float8store" redefined /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_portability.h:413:1: warning: this is the location of the previous definition /Users/ajmiller/Desktop/php-5.3.0RC2/ext/mysqlnd/mysqlnd_ps_codec.c: In function 'ps_fetch_from_1_to_8_bytes': /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_ps_codec.c:82: error: 'MYSQLND_LLU_SPEC' undeclared (first use in this function) /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_ps_codec.c:82: error: (Each undeclared identifier is reported only once /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_ps_codec.c:82: error: for each function it appears in.) /Users/ajmiller/Desktop/php- 5.3.0RC2/ext/mysqlnd/mysqlnd_ps_codec.c:111: error: 'MYSQLND_LL_SPEC' undeclared (first use in this function) make: *** [ext/mysqlnd/mysqlnd_ps_codec.lo] Error 1 -- Edit bug report at http://bugs.php.net/?id=48198&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48198&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48198&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48198&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48198&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48198&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48198&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48198&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48198&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48198&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48198&r=support Expected behavior: http://bugs.php.net/fix.php?id=48198&
#48191 [Opn->Fbk]: Passing the Session ID won't work after disable session.use_cookies
ID: 48191
Updated by: j...@php.net
Reported By: jens at dutzi dot me
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: Debian (lenny)
PHP Version: 5.3.0RC2
-Assigned To:
+Assigned To: fb-req-jani
New Comment:
You must also check the "session.use_only_cookies" directive and set
that also to 0 to be able to really use cookies.
Previous Comments:
[2009-05-08 14:19:46] jens at dutzi dot me
Description:
When forcing PHP to not use cookies for sessions, PHP doesn't recognize
the existing session. Instead it will create a new one. Session files
will be created as expected.
The Bug can be reproduced with:
1.) ini_set('session.use_cookies', 0); in the php-code
and
2.) session.use_cookies = 0; in php.ini
The following sample code is identical to
http://www.php.net/manual/en/session.idpassing.php
Reproduce code:
---
Hello visitor, you have seen this page times.
To continue, click here.
Expected result:
On the first run, a new session should be created with
$_SESSION['count'] = 1. On everey reload $_SESSION['count'] should be
increased. (s.a. example #1 at
http://www.php.net/manual/en/session.idpassing.php)
Actual result:
--
On every run, PHP creates a new session with $_SESSION['count']=1.
--
Edit this bug report at http://bugs.php.net/?id=48191&edit=1
#48192 [Opn]: if structure inherit else
ID: 48192
User updated by: skds1433 at hotmail dot com
Reported By: skds1433 at hotmail dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: vista
PHP Version: 5.2.9
New Comment:
To me, the whole 'dangling else' is a paradox.
Wouldn't it seem more complete if that dangling 'else' was interpreted
for both 'if'?
If 'if a then if b then s1 else s2' was interpreted like this (below),
I personally see no paradox. It just seems to me, like a paradox for the
fact that this isn't how it's interpreted.
if (a)
{
if (b)
{
s1
}
else
{
s2
}
}
else
{
s2
}
I'm not looking for a solution, since there's probably 20 different
ways to solve that. I'm just suggesting what might be a better way.
Previous Comments:
[2009-05-08 18:39:20] random-passer-by at hello dot world
This is a twist on the Dangling Else problem:
http://en.wikipedia.org/wiki/Dangling_else
I find your solution more confusing and incompatible than what I've
seen in any other other programming language.
This should achieve the correct result and avoid the extra foo
comparisons without a language change:
function routine ($foo, $bar)
{
do {
if ($foo === 0) { echo "foo is 0\n"; break; }
elseif ($foo === 1)
if ($bar === 0) { echo "bar is 0\n"; break; }
elseif ($bar === 1) { echo "bar is 1\n"; break; }
echo "foo: ".$foo.", bar: ".$bar."\n";
} while (0);
}
[2009-05-08 17:04:59] skds1433 at hotmail dot com
Description:
I'm requesting a way for the 'if' control struction to be able to
inherit 'else' control structures, in a similar matter as below. This
will help prevent duplicated code, and help keep it clean and
uncluttered.
I've included an 'expected_equivalent', which is actually less code
than in the 'routine' function. However, if a developer wishes to
include a greater diveristy, it can become a real advantage to use just
one 'else'.
Additionally, it I think it would be benefitional for 'if' control
structure to make it more 'complete'.
I also understand there are already numerous ways to do this, which
have the same result and possibly even less code. Nonetheless, I believe
this way could be a better, easier way for certain situations.
Reproduce code:
---
Expected result:
foo is 0
bar is 0
bar is 1
foo: 2, bar: 1
foo: 1, bar: 2
foo: 2, bar: 2
Actual result:
--
foo is 0
bar is 0
bar is 1
foo: 1, bar: 2
--
Edit this bug report at http://bugs.php.net/?id=48192&edit=1
#48197 [NEW]: __call performs extra allocs
From: rodricg at sellingsource dot com Operating system: Linux PHP version: 5.3.0RC2 PHP Bug Type: Scripting Engine problem Bug description: __call performs extra allocs Description: When returning a value from __call (as compared to a non-dynamic method) extra memory is allocated. This leads to performance degradation dependent on the size of the returned value. Hopefully this is a better description/example of bug #47525. Reproduce code: --- http://rodric.org/mem.phps This script takes 3 arguments. ie. mem.php See "Actual Result" for invocations. Expected result: Bytes allocated when using __call should be similar to not using __call. When using __call the time taken should not degrade linearly as the size of the result value increases. Actual result: -- Change USE_ZEND_ALLOC to 1 and you will see that "magic" performs exactly more allocs than "getStr". Using __call: USE_ZEND_ALLOC=0 valgrind php -n -d memory_limit=1024M mem.php 100 magic 100 2>&1 | pcregrep "Time|allocs" Time: 1.5781 ==25158== malloc/free: 19,564 allocs, 18,033 frees, 104,476,083 bytes allocated. USE_ZEND_ALLOC=0 valgrind php -n -d memory_limit=1024M mem.php 100 magic 200 2>&1 | pcregrep "Time|allocs" Time: 3.1066 ==25161== malloc/free: 19,564 allocs, 18,033 frees, 205,476,083 bytes allocated. Not Using __call: USE_ZEND_ALLOC=0 valgrind php -n -d memory_limit=1024M mem.php 100 getStr 100 2>&1 | pcregrep "Time|allocs" Time: 0.0280 ==25181== malloc/free: 18,764 allocs, 17,233 frees, 4,444,183 bytes allocated. USE_ZEND_ALLOC=0 valgrind php -n -d memory_limit=1024M mem.php 100 getStr 200 2>&1 | pcregrep "Time|allocs" Time: 0.0281 ==25183== malloc/free: 18,764 allocs, 17,233 frees, 5,444,183 bytes allocated. -- Edit bug report at http://bugs.php.net/?id=48197&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48197&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48197&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48197&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48197&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48197&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48197&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48197&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48197&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48197&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48197&r=support Expected behavior: http://bugs.php.net/fix.php?id=48197&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48197&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48197&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48197&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48197&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48197&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48197&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48197&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48197&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48197&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48197&r=mysqlcfg
#48196 [NEW]: Reproducible bug in string concatenation after calling preg_match_all
From: saulo_gil at argentina dot com Operating system: Windows XP PHP version: 5.3.0RC2 PHP Bug Type: *Regular Expressions Bug description: Reproducible bug in string concatenation after calling preg_match_all Description: If I try to perform a simple concatenation involving a variable created from the matches output of preg_match_all() the resulting string is borked. Please see the code above. What I want to do: echo "[" . $var . "]"; Reproduce code: --- Expected result: [SPD_EXECUTIVE_PROVIDER_DEALER] Actual result: -- ]SPD_EXECUTIVE_PROVIDER_DEALER -- Edit bug report at http://bugs.php.net/?id=48196&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48196&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48196&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48196&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48196&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48196&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48196&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48196&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48196&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48196&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48196&r=support Expected behavior: http://bugs.php.net/fix.php?id=48196&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48196&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48196&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48196&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48196&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48196&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48196&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48196&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48196&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48196&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48196&r=mysqlcfg
#43823 [Com]: Segmentation fault at end of script
ID: 43823 Comment by: delgado dot enrique at gmail dot com Reported By: andreas dot meinl at gmx dot de Status: No Feedback Bug Type: PDO related Operating System: Ubuntu 7.10, AMD64 PHP Version: 5.2.5 New Comment: I had to comment out: extension=curl.so >From /etc/php5/cli/conf.d/curl.ini And add it to /etc/php5/cli/conf.d/pgsql.ini AFTER: extension=pgsql.so To get around this issue. Previous Comments: [2009-04-08 03:35:15] mpoisson at livra dot com I'm having the same problem on 3 diferent Linux distributions Ubuntu, Debian and Centos. The last one is a 64bits OS. On Ubuntu and Debian it was solved changing the order of the extensions on the ini files. In my case I had to load Postgres extension before CURL. Under CentOS I'm still trying to solve it. [2008-08-10 00:57:38] rod at 23net dot net I was mistaken. The systems were NOT configured the same. This is a known issue with the order of extensions listed in extensions.ini in FreeBSD. Reordering the extensions fixed the problem. [2008-08-10 00:34:47] rod at 23net dot net I am experiencing this same problem. It happens on some systems but not others (all configured exactly the same). Some systems are 32 bit, some 64 bit, all running FreeBSD 7.0 (either i386 or AMD64), PHP 5.2.6 and Postgres 8.3.3. The segfault ALWAYS occurs at the end of the script even when the connection is explicitly closed. The script performs as expected, it just segfaults when the script ends. It happens when using PDO or pg_connect(). [2008-01-20 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". [2008-01-14 03:39:34] jfolkins at gmail dot com Description: I wanted to add a piece to this puzzle that may be helpful. Though I am not using PDO, I am using pg_connect() to connect to my PostgreSQL database. Machines: 1) Dell p4 3.2gz 1gb RAM, Ubuntu 7.10 x86, PHP 5.2.3, PostgreSQL 8.2.5 2) AMD64 X2 3800+ 1GB RAM, Ubuntu 7.10 x86, PHP 5.2.3, PostgreSQL 8.2.5 Script: Expected Results: I expect the word "Successful" to be displayed along with the version number of php on this machine. Results: x...@xxx:/dial/app/db$ php db_test.php Connection Successful 5.2.3-1ubuntu6.2 Segmentation fault (core dumped) x...@xxx:/dial/app/db$ Additional Notes: I get the same results on both machines. I also wanted to add that I have scripts that input data into the database. These sciprts DO indeed work. But, I always get the "Segmentation fault (core dumped)" at the end of every script that connects to the postgreSQL database. 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/43823 -- Edit this bug report at http://bugs.php.net/?id=43823&edit=1
#44081 [Com]: Cannot execute queries while other unbuffered queries are active
ID: 44081
Comment by: xfurious at gmail dot com
Reported By: abouzekry at gmail dot com
Status: No Feedback
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.8
New Comment:
Unless I'm losing my mind, this is happening on PHP 5.2.9-2/windows as
well.
Previous Comments:
[2009-05-03 01:00:09] 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".
[2009-04-25 14:54:25] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-02-25 14:18:04] stewart dot duncan at rocketmail dot com
Really annoying this one. Reproduced on 5.2.8.
[2008-02-09 11:46:41] abouzekry at gmail dot com
Description:
the same code runs on php5.2.0 without any problems, while it's
problematic with php5.2.5 i don't know why!, it insists on giving
me the following message...
Cannot execute queries while other unbuffered queries are active.
Consider using PDOStatement::fetchAll(). Alternatively, if your code is
only ever going to run against mysql, you may enable query buffering by
setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute
however i closed the cursor after each result fetch
Reproduce code:
---
if(isset($_POST['user_name'], $_POST['pass']))
{
/* check wether the user exists or not */
$result = $db->query("CALL proc_check_user('{$_POST['user_name']}',
'{$_POST['pass']}')")
or
die('0-1-Database-Query-Error-login.php:'.print_r($db->errorInfo()));
$row = $result->fetchAll(PDO::FETCH_ASSOC)
or
die('0-2-Database-Fetch-Error-login.php:'.print_r($db->errorInfo()));
/* close the DB cursor to be able to perform the other querie(s)*/
$result->closeCursor();
/* if the user doesn't exist exit prematurely! */
if($row['userExists'] == 0)
{
exit('0-2-Authentication-Error-login.php: User Doesnt Exist!');
}
/* get the user_id and full_name */
$result = $db->query("CALL
proc_get_user_data('{$_POST['user_name']}', '{$_POST['pass']}')")
or
die('0-3-Database-Query-Error-login.php:'.print_r($db->errorInfo()));
$row = $result->fetch(PDO::FETCH_ASSOC);
}
Expected result:
the machine with php5.2.0 installed when running the same code
produces
a correct authentication for valid users (POSTed) and error for invalid
users.
--
Edit this bug report at http://bugs.php.net/?id=44081&edit=1
#48195 [NEW]: iconv link failure
From: rickdunn at chez dot com Operating system: OS X 10.5.6 PHP version: 5.3.0RC2 PHP Bug Type: Compile Failure Bug description: iconv link failure Description: Bug #43189 has returned in 5.3 RC2. Make fails with 'undefined symbols' related to iconv. Reproduce code: --- CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer -arch x86_64 -m64" CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti -arch x86_64 -m64" ./configure --prefix=/usr/local/php5 --with-apxs2=/usr/sbin/apxs --with-config-file-scan-dir=/usr/local/php5/php.d --with-ldap=/usr --with-bz2=/usr --with-kerberos=/usr --enable-cli --with-zlib-dir=/usr --enable-exif --enable-soap --enable-ftp --enable-mbstring --enable-mbregex --enable-sockets --with-iodbc=/usr --with-curl=shared,/usr --sysconfdir=/private/etc --with-mysqli=mysqlnd --with-mysql=mysqlnd --with-pdo-mysql=mysqlnd --with-openssl --with-xmlrpc --with-xsl=/usr --with-gd --with-jpeg-dir=/usr/local/lib --with-png-dir=/usr/X11R6 --with-freetype-dir=/usr/X11R6 --with-xpm-dir=/usr/X11R6 --enable-gd-native-ttf --with-mcrypt=shared --enable-calendar --enable-bcmath Expected result: Successful installation. Actual result: -- Make fails. -- Edit bug report at http://bugs.php.net/?id=48195&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48195&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48195&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48195&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48195&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48195&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48195&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48195&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48195&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48195&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48195&r=support Expected behavior: http://bugs.php.net/fix.php?id=48195&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48195&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48195&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48195&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48195&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48195&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48195&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48195&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48195&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48195&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48195&r=mysqlcfg
#48194 [NEW]: The path to the PHP executable isn't correct
From: oxie at live dot nl Operating system: Ubuntu 8.04.2 PHP version: 5.2.9 PHP Bug Type: *Compile Issues Bug description: The path to the PHP executable isn't correct Description: The generated scripts bin/pear and bin/pecl have the wrong path to the PHP executable. The path in the script look likes '/usr/local/lamp/apache2/bin/apxs2/bin/apxs/bin/php', where it must be '/usr/local/lamp/php/bin/php'. When manually chaning the path to that, it is working. The output that i get is, logically: exec: 28: /usr/local/lamp/apache2/bin/apxs/bin/php: not found My configure statement: ./configure --prefix=/usr/local/lamp/php --with-apxs2=/usr/local/lamp/apache2/bin/apxs --with-pear=/usr/local/lamp/php/lib/php [a lot of extensions] The bin/pear script: http://pastebin.com/d132560e -- Edit bug report at http://bugs.php.net/?id=48194&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48194&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48194&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48194&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48194&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48194&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48194&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48194&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48194&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48194&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48194&r=support Expected behavior: http://bugs.php.net/fix.php?id=48194&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48194&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48194&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48194&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48194&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48194&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48194&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48194&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48194&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48194&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48194&r=mysqlcfg
#46289 [Com]: PDO execute causes apache.exe to crash
ID: 46289
Comment by: mattgrdinic at yahoo dot com
Reported By: asylow at free dot fr
Status: Open
Bug Type: PDO related
Operating System: Windows XP SP3
PHP Version: 5.2.9
New Comment:
I can confirm this bug as well. The solution was similar to above, I
replaced the php_pdo_mysql.dll and php_pdo.dll which were version
5.2.9.9 with ones from my 5.2.8 install (which were version 5.2.8.8(,
and all works as expected.
Previous Comments:
[2009-05-03 19:01:26] oddvibes at gmail dot com
I fixed this problem on my computer. In my case it seems to have to do
something with the Xammp installation. It probably would be interesting
to know if the other people who were experiencing this problem were also
running on xammp.
I found this sollution by searching the web and found it on the
Magento-forum:
http://www.magentocommerce.com/boards/viewthread/31789/
The solution is simple:
- Download:
http://windows.php.net/downloads/snaps/php-5.2-win32-VC6-x86-latest.zip
- Unzip & copy libmysql.dll into xampp\apache\bin & xampp\php.
- Restart apache.
[2009-05-03 17:43:26] oddvibes at gmail dot com
I'm having the same issue on Windows Vista. The following Windows crash
information might be useful:
Windows error-reporting creates the following error-messages:
Faulting application apache.exe, version 2.2.11.0, time stamp
0x493f5d44, faulting module php_pdo_mysql.dll, version 5.2.8.8, time
stamp 0x493d7650, exception code 0xc005, fault offset 0x250a,
process id 0xf10, application start time 0x01c9c677df857f87.
And:
Faulting application apache.exe, version 2.2.11.0, time stamp
0x493f5d44, faulting module ntdll.dll, version 6.0.6001.18000, time
stamp 0x4791a7a6, exception code 0xc005, fault offset 0x0006814c,
process id 0x10d8, application start time 0x01c9c677ded2aa47.
And after that, the following information:
Fault bucket 1062083465, type 1
Event Name: APPCRASH
Response: None
Cab Id: 0
Problem signature:
P1: apache.exe
P2: 2.2.11.0
P3: 493f5d44
P4: php_pdo_mysql.dll
P5: 5.2.8.8
P6: 493d7650
P7: c005
P8: 250a
P9:
P10:
Attached files:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Report09c3bd88\WERAF65.tmp.version.txt
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Report09c3bd88\WERAF66.tmp.appcompat.txt
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Report09c3bd88\WERAFC4.tmp.hdmp
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Report09c3bd88\WERBC91.tmp.mdmp
These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\Report0cdbcec7
Specs:
* Windows Vista Home Edition
* Apache 2.2
* MySQL 5.1.30
* PHP 5.2.8
[2009-02-20 03:23:12] michael dot cordover+php at gmail dot com
I also get this issue on WinXP SP2 (5.1 build 2600) running Apache
2.2.11.0 (from xampplite 1.7.0).
Interestingly this occurs with executing a PDO::prepare()d SELECT
statement but not on UPDATE or INSERT. This happens even when
PDOStatement::bindValue / bindParam is not used.
I cannot reproduce the "subtle change makes it work" described by
asylow.
I am unable to provide a backtrace.
--Code--
$dbConn = new PDO(DBDSN, DBUSER, DBPASS);
// Connection is definitely valid
$q = $dbConn->prepare('SELECT * FROM people');
$q->execute();
--Crash report--
AppName: apache.exe
AppVer: 2.2.11.0
ModName: php_pdo_mysql.dll
ModVer: 5.2.9.9
Offset: 249a
--PHP Version-- [per phpinfo()]
Was occurring on 5.2.8 and also on snapshot:
PHP Version 5.2.9RC3-dev
System Windows NT 18315XP 5.1 build 2600
Build Date Feb 18 2009 23:39:16
Configure Command cscript /nologo configure.js
"--enable-snapshot-build" "--enable-debug-pack"
"--with-snapshot-template=d:\php-sdk\bin\\..\snap_5_2\vc6\x86\template"
"--with-php-build=d:\php-sdk\bin\\..\snap_5_2\vc6\x86\php_build"
"--with-pdo-oci=D:\php-sdk\oracle\instantclient10\sdk,shared"
"--with-oci8=D:\php-sdk\oracle\instantclient10\sdk,shared"
--PDO Version-- [per phpinfo()]
pdo_mysql PDO Driver for MySQL, client library version 5.1.30
--MySQL Version--
C:\xampplite\mysql\bin>mysqld.exe --version
mysqld.exe Ver 5.1.30-community for Win32 on ia32 (MySQL Community
Server (GPL))
[2008-10-14 13:13:30] asylow at free dot fr
The same happens with PHP Version 5.2.7RC2-dev - Oct 14 2008 01:38:31
The Call Stack debug is :
PHP5TS! 0096c9a3()
PHP5TS! 0096d28b()
free_statement(_pdo_stmt_t * 0x062d21d0, void * * * 0x01ec7d58) line
2396 + 19 bytes
php_pdo_stmt_delref(_pdo_stmt_t * 0x062d21d0, void * * * 0x01ec7d58)
line 2426 + 13 bytes
pdo_dbstmt_free_storage(_pdo_stmt_t * 0x062d21d0, void * * *
0x01ec7d58)
#44294 [Com]: Undefined symbols with libxml2
ID: 44294 Comment by: rdohms at gmail dot com Reported By: danval at gmail dot com Status: No Feedback Bug Type: Compile Failure Operating System: Mac 10.5 Leopard Client PHP Version: 5.2-latest New Comment: Compiling libxml2 from source solved this for me Previous Comments: [2008-08-03 16:21:22] whisller at gmail dot com I also have this same problem on Leopard. But solution which you wrote, "remove all instances of libxml from your system" can only crash Leopard ( http://jamesclarke.info/notes/libxml2/ - see comments ). My "sudo make" also return this same error like in danval situation. [2008-03-11 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". [2008-03-03 13:02:57] j...@php.net Check that your installed libxml2 is clean, ie. you don't have messed up the headers vs. libraries when installing it. It happens when if you install it from sources and don't remove the existing installation first. Most likely this is just a messed up installation of libxml2 so the easiest way to solve it is first removing all instances of any libxml2 related files from your system and reinstalling it from scratch, then do the same for PHP. (use _fresh_ sources!) [2008-03-01 08:28:51] danval at gmail dot com Seems it was the way i configured libxml2? this was my setting ./configure --prefix=/Apache/local/libxml \ --enable-shared \ --with-zlib=/Apache/local/zlib do you see how it would generate that error? is this zlib directory the same as the one configured in php? I was able to use a binary version of libxml2 when i configured php to successfully build. [2008-03-01 04:09:28] danval at gmail dot com returned the exact same error?? Anything else it could be? what does that error mean? main/internal_functions.o -lmysqlclient -lmhash -lmcrypt -lltdl -liconv -lpng -lz -ljpeg -lcurl -lz -lm -lxml2 -lz -liconv -lm -lcurl -lssl -lcrypto -lldap -lz -lxml2 -lz -liconv -lm -lxml2 -lz -liconv -lm -lxml2 -lz -liconv -lm -lxml2 -lz -liconv -lm -lxml2 -lz -liconv -lm -lxml2 -lz -liconv -lm -o libs/libphp5.bundle && cp libs/libphp5.bundle libs/libphp5.so Undefined symbols: "_xmlTextReaderSchemaValidate", referenced from: _zim_xmlreader_setSchema in php_xmlreader.o "_xmlTextReaderSetup", referenced from: _zim_xmlreader_XML in php_xmlreader.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 adsl-69-234-187-240:php5.2-200803010330 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/44294 -- Edit this bug report at http://bugs.php.net/?id=44294&edit=1
#48192 [Com]: if structure inherit else
ID: 48192
Comment by: random-passer-by at hello dot world
Reported By: skds1433 at hotmail dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: vista
PHP Version: 5.2.9
New Comment:
This is a twist on the Dangling Else problem:
http://en.wikipedia.org/wiki/Dangling_else
I find your solution more confusing and incompatible than what I've
seen in any other other programming language.
This should achieve the correct result and avoid the extra foo
comparisons without a language change:
function routine ($foo, $bar)
{
do {
if ($foo === 0) { echo "foo is 0\n"; break; }
elseif ($foo === 1)
if ($bar === 0) { echo "bar is 0\n"; break; }
elseif ($bar === 1) { echo "bar is 1\n"; break; }
echo "foo: ".$foo.", bar: ".$bar."\n";
} while (0);
}
Previous Comments:
[2009-05-08 17:04:59] skds1433 at hotmail dot com
Description:
I'm requesting a way for the 'if' control struction to be able to
inherit 'else' control structures, in a similar matter as below. This
will help prevent duplicated code, and help keep it clean and
uncluttered.
I've included an 'expected_equivalent', which is actually less code
than in the 'routine' function. However, if a developer wishes to
include a greater diveristy, it can become a real advantage to use just
one 'else'.
Additionally, it I think it would be benefitional for 'if' control
structure to make it more 'complete'.
I also understand there are already numerous ways to do this, which
have the same result and possibly even less code. Nonetheless, I believe
this way could be a better, easier way for certain situations.
Reproduce code:
---
Expected result:
foo is 0
bar is 0
bar is 1
foo: 2, bar: 1
foo: 1, bar: 2
foo: 2, bar: 2
Actual result:
--
foo is 0
bar is 0
bar is 1
foo: 1, bar: 2
--
Edit this bug report at http://bugs.php.net/?id=48192&edit=1
#45565 [Com]: Autoconfig of httpd.conf file failes with 64bit
ID: 45565 Comment by: teohhanhui at gmail dot com Reported By: cobie85 at gmail dot com Status: Assigned Bug Type: Windows Installer Operating System: Windows Server 2008 64bit PHP Version: 5.2.6 Assigned To: jmertic New Comment: Auto-configuration of web server during installation is optional. Previous Comments: [2009-02-15 21:45:38] news at soos dot com any solution comming? any turnaround? Thanks M [2008-08-19 15:08:19] tim dot hawkins at mac dot com I am of a strong belife that the installer SHOULD NOT ever change the apache conf file, the fact that it does at the moment is a major pain in the *^%$, for those of us running distributions that dont have the php enabling instructions in httpd.conf. It is increasingly becoming common to have separate conf fragment directories that are included from httpd.conf. (like php does with the php.d conf directory) Virtually every time i have installed php from source I have had to "undo" the mess that php makes of this. Please leave the httpd.conf alone, it does not belong to the php project, and editing it is always a bad idea. [2008-07-20 10:56:28] j...@php.net Assigned to the installer maintainer. [2008-07-19 17:59:20] cobie85 at gmail dot com Description: I use Windows Server 2008 64bit version and choose in the installer to install it on a Apache Webserver 2.2. This failes. Maybe this is, because Apache is not (yet) available for 64bit and therefore the installationpath of Apache is not c:\Progam Files\Apache Software... BUT c:\Program Files (x86)\Apache Software The Program Files folder without the (x86) is the 64bit version. Reproduce code: --- - Expected result: - Actual result: -- - -- Edit this bug report at http://bugs.php.net/?id=45565&edit=1
#48170 [Com]: Array key differentiates between unicode and binary strings
ID: 48170 Comment by: rodrigosouzadossantos at gmail dot com Reported By: rodrigosouzadossantos at gmai dot com Status: Feedback Bug Type: *Unicode Issues Operating System: Debian Lenny PHP Version: 6CVS-2009-05-06 (snap) New Comment: Hi, When I created this bug I missed my e-mail. I wrote 'gmai.com' instead of 'gmail.com'. So I can not recover the password to edit this post and provide more information. Is there any way to change my e-mail address? Thank in advance. Rodrigo Souza Previous Comments: [2009-05-06 19:50:08] f...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Works for me with CVS HEAD on Debian lenny. Are you sure the input from Postgres is not to blame? Code: - $result[ 'app1' ] = 'app value'; $result[ 'app2' ] = 'some value'; print_r( $result ); var_dump( $result[ 'app1' ] ); var_dump( $result[ b'app1' ] ); Result: --- Array ( [app1] => app value [app2] => some value ) unicode(9) "app value" NULL [2009-05-06 18:00:14] rodrigosouzadossantos at gmai dot com Description: I have a array that is populated with result query from a Postgres. The keys of array are the field name and the value are the field value. Like this: Array ( [app1] => app value [app2] => some value ) Reproduce code: --- $result[ 'app1' ] = 'app value'; $result[ 'app2' ] = 'some value'; print_r( $result ); var_dump( $result[ 'app1' ] ); Expected result: string(9) "app value" Actual result: -- NULL The result of var_dump is correct when is puts a 'b' (binary) before string, like: var_dump( $result[ b'app1' ] ); Is it the expected behavior? -- Edit this bug report at http://bugs.php.net/?id=48170&edit=1
#44780 [Com]: some time zone offsets not recognized by timezone_name_from_abbr
ID: 44780
Comment by: mfburdett at gmail dot com
Reported By: shawn dot parker at alttech dot com
Status: Assigned
Bug Type: Date/time related
Operating System: *
PHP Version: 5CVS-2008-08-14
Assigned To: derick
New Comment:
I was able to resolve this by changing the fallbackmap from hours to
minutes (the bug is apparently due to some issue with float vs.
integer). Also, this patch adds Caracas and Shanghai time (there are
likely other missing time zones, however) and uses the new spelling for
Calcutta (Kolkata).
Index: ext/date/lib/fallbackmap.h
===
RCS file: /repository/php-src/ext/date/lib/fallbackmap.h,v
retrieving revision 1.3
diff -u -p -r1.3 fallbackmap.h
--- ext/date/lib/fallbackmap.h 15 Oct 2005 18:14:40 - 1.3
+++ ext/date/lib/fallbackmap.h 8 May 2009 18:18:32 -
@@ -1,40 +1,42 @@
- { "sst", 0, -11, "Pacific/Apia" },
- { "hst", 0, -10, "Pacific/Honolulu" },
- { "akst", 0, -9, "America/Anchorage" },
- { "akdt", 1, -8, "America/Anchorage" },
- { "pst", 0, -8, "America/Los_Angeles" },
- { "pdt", 1, -7, "America/Los_Angeles" },
- { "mst", 0, -7, "America/Denver" },
- { "mdt", 1, -6, "America/Denver" },
- { "cst", 0, -6, "America/Chicago" },
- { "cdt", 1, -5, "America/Chicago" },
- { "est", 0, -5, "America/New_York" },
- { "edt", 1, -4, "America/New_York" },
- { "ast", 0, -4, "America/Halifax" },
- { "adt", 1, -3, "America/Halifax" },
- { "brt", 0, -3, "America/Sao_Paulo" },
- { "brst", 1, -2, "America/Sao_Paulo" },
- { "azost", 0, -1, "Atlantic/Azores" },
- { "azodt", 1,0, "Atlantic/Azores" },
- { "gmt", 0,0, "Europe/London" },
- { "bst", 1,1, "Europe/London" },
- { "cet", 0,1, "Europe/Paris" },
- { "cest", 1,2, "Europe/Paris" },
- { "eet", 0,2, "Europe/Helsinki" },
- { "eest", 1,3, "Europe/Helsinki" },
- { "msk", 0,3, "Europe/Moscow" },
- { "msd", 1,4, "Europe/Moscow" },
- { "gst", 0,4, "Asia/Dubai" },
- { "pkt", 0,5, "Asia/Karachi" },
- { "ist", 0, 5.5, "Asia/Calcutta" },
- { "npt", 0, 5.75, "Asia/Katmandu" },
- { "yekt", 1,6, "Asia/Yekaterinburg" },
- { "novst", 1,7, "Asia/Novosibirsk" },
- { "krat", 0,7, "Asia/Krasnoyarsk" },
- { "krast", 1,8, "Asia/Krasnoyarsk" },
- { "jst", 0,9, "Asia/Tokyo" },
- { "est", 0, 10, "Australia/Melbourne" },
- { "cst", 1, 10.5, "Australia/Adelaide" },
- { "est", 1, 11, "Australia/Melbourne" },
- { "nzst", 0, 12, "Pacific/Auckland" },
- { "nzdt", 1, 13, "Pacific/Auckland" },
+ { "sst", 0, -660, "Pacific/Apia" },
+ { "hst", 0, -600, "Pacific/Honolulu" },
+ { "akst", 0, -540, "America/Anchorage" },
+ { "akdt", 1, -480, "America/Anchorage" },
+ { "pst", 0, -480, "America/Los_Angeles" },
+ { "pdt", 1, -420, "America/Los_Angeles" },
+ { "mst", 0, -420, "America/Denver" },
+ { "mdt", 1, -360, "America/Denver" },
+ { "cst", 0, -360, "America/Chicago" },
+ { "cdt", 1, -300, "America/Chicago" },
+ { "est", 0, -300, "America/New_York" },
+ { "vet", 0, -270, "America/Caracas" },
+ { "edt", 1, -240, "America/New_York" },
+ { "ast", 0, -240, "America/Halifax" },
+ { "adt", 1, -180, "America/Halifax" },
+ { "brt", 0, -180, "America/Sao_Paulo" },
+ { "brst", 1, -120, "America/Sao_Paulo" },
+ { "azost", 0, -60, "Atlantic/Azores" },
+ { "azodt", 1,0, "Atlantic/Azores" },
+ { "gmt", 0,0, "Europe/London" },
+ { "bst", 1, 60, "Europe/London" },
+ { "cet", 0, 60, "Europe/Paris" },
+ { "cest", 1, 120, "Europe/Paris" },
+ { "eet", 0, 120, "Europe/Helsinki" },
+ { "eest", 1, 180, "Europe/Helsinki" },
+ { "msk", 0, 180, "Europe/Moscow" },
+ { "msd", 1, 240, "Europe/Moscow" },
+ { "gst", 0, 240, "Asia/Dubai" },
+ { "pkt", 0, 300, "Asia/Karachi" },
+ { "ist", 0, 330, "Asia/Kolkata" },
+ { "npt", 0, 345, "Asia/Katmandu" },
+ { "yekt", 1, 360, "Asia/Yekaterinburg" },
+ { "novst", 1, 420, "Asia/Novosibirsk" },
+ { "krat", 0, 420, "Asia/Krasnoyarsk" },
+ { "cst", 0, 480, "Asia/Shanghai" },
+ { "krast", 1, 480, "Asia/Krasnoyarsk" },
+ { "jst", 0, 540, "Asia/Tokyo" },
+ { "est", 0, 600, "Australia/Melbourne" },
+ { "cst", 1, 630, "Australia/Adelaide" },
+ { "est", 1, 660, "Australia/Melbourne" },
+ { "nzst", 0, 720, "Pacific/Auckland" },
+ { "nzdt", 1, 780, "Pacific/Auckland"
#48193 [Opn]: ODBC crash from PHP
ID: 48193
User updated by: leo dot nnnaaarrrdddooo at gmail dot com
Reported By: leo dot nnnaaarrrdddooo at gmail dot com
Status: Open
Bug Type: ODBC related
Operating System: Debian 5.0 "Lenny" AMD64
PHP Version: 5.2CVS-2009-05-08 (CVS)
New Comment:
I did two clean installs of Debian 5.0 AMD64 to check I didn't have
anything wrong installed.
Previous Comments:
[2009-05-08 17:26:38] leo dot nnnaaarrrdddooo at gmail dot com
Description:
ODBC crashes when using php script included (using a MySQL database),
and an
ALERT - canary mismatch on efree() - heap overflow detected (attacker
'X.X.X.X', etc ...)
line pops up in the error.log for apache.
This happens on current stable Debian 5.0 "lenny" AMD64, with system up
to date as of today, running: apache2, php5, mysql-server.
Compiling latest MySQL odbc driver version 5.1.5 doesn't crash, but
does lock up the calling process if same script is run with php5 client
from command line.
Reproduce code:
---
$conn="DRIVER={MySQL}; DatabaseName='test';
CommLinks=tcpip(Host=localhost); ";
$conn=odbc_connect($conn, "user", "");
$sql='SELECT * FROM test.T1;';
echo $sql;
$pg_query=odbc_exec($pg_conn, $sql);
odbc_close($pg_conn);
echo "A";
--
Edit this bug report at http://bugs.php.net/?id=48193&edit=1
#48193 [NEW]: ODBC crash from PHP
From: leo dot nnnaaarrrdddooo at gmail dot com
Operating system: Debian 5.0 "Lenny" AMD64
PHP version: 5.2CVS-2009-05-08 (CVS)
PHP Bug Type: ODBC related
Bug description: ODBC crash from PHP
Description:
ODBC crashes when using php script included (using a MySQL database), and
an
ALERT - canary mismatch on efree() - heap overflow detected (attacker
'X.X.X.X', etc ...)
line pops up in the error.log for apache.
This happens on current stable Debian 5.0 "lenny" AMD64, with system up to
date as of today, running: apache2, php5, mysql-server.
Compiling latest MySQL odbc driver version 5.1.5 doesn't crash, but does
lock up the calling process if same script is run with php5 client from
command line.
Reproduce code:
---
$conn="DRIVER={MySQL}; DatabaseName='test';
CommLinks=tcpip(Host=localhost); ";
$conn=odbc_connect($conn, "user", "");
$sql='SELECT * FROM test.T1;';
echo $sql;
$pg_query=odbc_exec($pg_conn, $sql);
odbc_close($pg_conn);
echo "A";
--
Edit bug report at http://bugs.php.net/?id=48193&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48193&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48193&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48193&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48193&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48193&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48193&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48193&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48193&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48193&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48193&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48193&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48193&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48193&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48193&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48193&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48193&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48193&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48193&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48193&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48193&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48193&r=mysqlcfg
#48192 [NEW]: if structure inherit else
From: skds1433 at hotmail dot com Operating system: vista PHP version: 5.2.9 PHP Bug Type: Feature/Change Request Bug description: if structure inherit else Description: I'm requesting a way for the 'if' control struction to be able to inherit 'else' control structures, in a similar matter as below. This will help prevent duplicated code, and help keep it clean and uncluttered. I've included an 'expected_equivalent', which is actually less code than in the 'routine' function. However, if a developer wishes to include a greater diveristy, it can become a real advantage to use just one 'else'. Additionally, it I think it would be benefitional for 'if' control structure to make it more 'complete'. I also understand there are already numerous ways to do this, which have the same result and possibly even less code. Nonetheless, I believe this way could be a better, easier way for certain situations. Reproduce code: --- Expected result: foo is 0 bar is 0 bar is 1 foo: 2, bar: 1 foo: 1, bar: 2 foo: 2, bar: 2 Actual result: -- foo is 0 bar is 0 bar is 1 foo: 1, bar: 2 -- Edit bug report at http://bugs.php.net/?id=48192&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48192&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48192&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48192&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48192&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48192&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48192&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48192&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48192&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48192&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48192&r=support Expected behavior: http://bugs.php.net/fix.php?id=48192&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48192&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48192&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48192&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48192&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48192&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48192&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48192&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48192&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48192&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48192&r=mysqlcfg
#47855 [Com]: VC6 Thread Safe MSI install fails
ID: 47855 Comment by: tc_loss at yahoo dot com Reported By: mfaust at usinternet dot com Status: Open Bug Type: Windows Installer Operating System: Windows XP SP3 PHP Version: 5.3 RC2 Assigned To: jmertic New Comment: This happened on install of php 5.3 ORC1 and 2 Thread safe on Windows Vista Home Basic 64bit. for PHP 5.3 ORC1 it worked even though I got the error. For PHP5.3 ORC2 Apache 2.2.11 fails to start after install. Previous Comments: [2009-05-08 13:35:22] mfaust at usinternet dot com This still happens with the recent RC2 release (VC6 Thread Safe) [2009-05-08 13:33:42] mfaust at usinternet dot com This happens with the most recent RC2 release installer (VC6 Thread Safe). [2009-04-23 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". [2009-04-15 17:13:39] jmer...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-04-14 18:48:46] rosswholland at btinternet dot com I have Vista Home Premium, and get this whichever of the msi files I try to run. I have tried: php-5.2.9-2-win32-installer php-5.2.9-2-Win32-VC6-x86 php-5.2-win32-VC6-x86-latest I want to use PHP on Apache 2.2 server with MySql, but can't seem to get is all working properly. Have all my code under sub-directories under htdocs directory. Have managed to get it to run php for some but not other, and MySQL does not seem to be set up??? Help? 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/47855 -- Edit this bug report at http://bugs.php.net/?id=47855&edit=1
#48191 [NEW]: Passing the Session ID won't work after disable session.use_cookies
From: jens at dutzi dot me
Operating system: Debian (lenny)
PHP version: 5.3.0RC2
PHP Bug Type: Session related
Bug description: Passing the Session ID won't work after disable
session.use_cookies
Description:
When forcing PHP to not use cookies for sessions, PHP doesn't recognize
the existing session. Instead it will create a new one. Session files will
be created as expected.
The Bug can be reproduced with:
1.) ini_set('session.use_cookies', 0); in the php-code
and
2.) session.use_cookies = 0; in php.ini
The following sample code is identical to
http://www.php.net/manual/en/session.idpassing.php
Reproduce code:
---
Hello visitor, you have seen this page times.
To continue, click here.
Expected result:
On the first run, a new session should be created with $_SESSION['count']
= 1. On everey reload $_SESSION['count'] should be increased. (s.a. example
#1 at http://www.php.net/manual/en/session.idpassing.php)
Actual result:
--
On every run, PHP creates a new session with $_SESSION['count']=1.
--
Edit bug report at http://bugs.php.net/?id=48191&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48191&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48191&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48191&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48191&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48191&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48191&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48191&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48191&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48191&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48191&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48191&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48191&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48191&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48191&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48191&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48191&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48191&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48191&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48191&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48191&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48191&r=mysqlcfg
#48190 [NEW]: wrong content-type parsing
From: carsten_sttgt at gmx dot de
Operating system: Windows_NT
PHP version: 5.3CVS-2009-05-08 (snap)
PHP Bug Type: *Web Server problem
Bug description: wrong content-type parsing
Description:
Hello,
PHP does not work correctly with POST requests and a Content-Type of
MULTIPART/form-data, if the parameter name "BOUNDARY" is in uppercase.
According to RFC2045, matching of media type, subtype and parameter
(attributes) is always case-insensitive.
(only the value of the BOUNDARY parameter is compared case-sensitive)
Tested on Windows with 5.2-dev, 5.3-dev and 6.0-dev. CGI and Apache
module.
Regards,
Carsten
Reproduce code:
---
Put this textfile in your PHP directory:
test.txt **
--250-16659-1241787336=:9320
Content-Type: TEXT/plain; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: form-data; name=nick
php-faq
--250-16659-1241787336=:9320
Content-Type: TEXT/plain; CHARSET=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Disposition: form-data; name=desc
post demo script
--250-16659-1241787336=:9320--
Put this phpfile in your PHP directory:
test.php **
Open a command prompt, go to your PHP dir and execute:
# set REQUEST_METHOD=POST
# set REDIRECT_STATUS=1
# set SCRIPT_FILENAME=test.php
# set CONTENT_LENGTH=391
# set CONTENT_TYPE=MULTIPART/form-data;
BOUNDARY="250-16659-1241787336=:9320"
# type test.text | php-cgi.exe
if you set CONTENT_TYPE in this way, you have the correct result:
# set CONTENT_TYPE=MULTIPART/form-data;
boundary="250-16659-1241787336=:9320"
Regards,
Carsten
BTW:
e.g. the IMAP-Module from PHP is using/generating BOUNDARY in uppercase.
Expected result:
Content-type: text/html
array(2) {
["nick"]=>
string(7) "php-faq"
["desc"]=>
string(16) "post demo script"
}
Actual result:
--
Content-type: text/html
Warning: Missing boundary in multipart/form-data POST data in
Unknown
on line 0
array(0) {
}
--
Edit bug report at http://bugs.php.net/?id=48190&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48190&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48190&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48190&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48190&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48190&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48190&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48190&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48190&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48190&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48190&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48190&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48190&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48190&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48190&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48190&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48190&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48190&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48190&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48190&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48190&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48190&r=mysqlcfg
#47855 [NoF->Opn]: VC6 Thread Safe MSI install fails
ID: 47855 User updated by: mfaust at usinternet dot com Reported By: mfaust at usinternet dot com -Status: No Feedback +Status: Open Bug Type: Windows Installer Operating System: Windows XP SP3 -PHP Version: 5.3CVS-2009-03-31 (snap) +PHP Version: 5.3 RC2 Assigned To: jmertic New Comment: This still happens with the recent RC2 release (VC6 Thread Safe) Previous Comments: [2009-05-08 13:33:42] mfaust at usinternet dot com This happens with the most recent RC2 release installer (VC6 Thread Safe). [2009-04-23 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". [2009-04-15 17:13:39] jmer...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-04-14 18:48:46] rosswholland at btinternet dot com I have Vista Home Premium, and get this whichever of the msi files I try to run. I have tried: php-5.2.9-2-win32-installer php-5.2.9-2-Win32-VC6-x86 php-5.2-win32-VC6-x86-latest I want to use PHP on Apache 2.2 server with MySql, but can't seem to get is all working properly. Have all my code under sub-directories under htdocs directory. Have managed to get it to run php for some but not other, and MySQL does not seem to be set up??? Help? [2009-03-31 23:27:50] mfaust at usinternet dot com Description: Towards the end of the install process the installer prompts with "There is a problem with this Windows installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor." Clicking on "OK" takes you to once last install screen stating PHP 5.3.0 Setup Wizard ended prematurely. As far as I can tell the steps that are missed are modifying httpd.conf and mime.types for the Apache 2.2 install. This happens on two separately configured Windows XP SP3 machines. This happens in PHP 5.3.0 RC1 as well as 2009-03-31 SNAP -- Edit this bug report at http://bugs.php.net/?id=47855&edit=1
#47855 [Com]: VC6 Thread Safe MSI install fails
ID: 47855 Comment by: mfaust at usinternet dot com Reported By: mfaust at usinternet dot com Status: No Feedback Bug Type: Windows Installer Operating System: Windows XP SP3 PHP Version: 5.3CVS-2009-03-31 (snap) Assigned To: jmertic New Comment: This happens with the most recent RC2 release installer (VC6 Thread Safe). Previous Comments: [2009-04-23 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". [2009-04-15 17:13:39] jmer...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-04-14 18:48:46] rosswholland at btinternet dot com I have Vista Home Premium, and get this whichever of the msi files I try to run. I have tried: php-5.2.9-2-win32-installer php-5.2.9-2-Win32-VC6-x86 php-5.2-win32-VC6-x86-latest I want to use PHP on Apache 2.2 server with MySql, but can't seem to get is all working properly. Have all my code under sub-directories under htdocs directory. Have managed to get it to run php for some but not other, and MySQL does not seem to be set up??? Help? [2009-03-31 23:27:50] mfaust at usinternet dot com Description: Towards the end of the install process the installer prompts with "There is a problem with this Windows installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor." Clicking on "OK" takes you to once last install screen stating PHP 5.3.0 Setup Wizard ended prematurely. As far as I can tell the steps that are missed are modifying httpd.conf and mime.types for the Apache 2.2 install. This happens on two separately configured Windows XP SP3 machines. This happens in PHP 5.3.0 RC1 as well as 2009-03-31 SNAP -- Edit this bug report at http://bugs.php.net/?id=47855&edit=1
#48175 [Opn->Csd]: FILE_IGNORE_NEW_LINES does not remove "\r\n"
ID: 48175 Updated by: lbarn...@php.net Reported By: carsten_sttgt at gmx dot de -Status: Open +Status: Closed Bug Type: Filesystem function related Operating System: * PHP Version: 5.2.9 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. Fix merged to 5.2CVS and 6CVS Previous Comments: [2009-05-07 14:48:03] carsten_sttgt at gmx dot de executed with "php.exe -n test.php": 5.2.10-dev - Thu, 07 May 2009 11:42:06 +0100 101 101 13 5.3.0RC1 - Tue, 24 Mar 2009 22:33:04 + 5.3.0RC3-dev - Thu, 07 May 2009 13:08:08 + 101 101 101 6.0.0-dev - hu, 07 May 2009 11:30:12 + 13 101 101 So it's seems to be fixed in PHP5.3. - is there a plan to release this PHP5.2.10 (have still the old behavior)? - is this result expected in PHP6 (and why)? [2009-05-07 13:46:44] lbarn...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-05-07 12:42:05] j...@php.net See also bug #44034 [2009-05-07 09:23:02] carsten_sttgt at gmx dot de Description: Hello, if I use FILE_IGNORE_NEW_LINES with file(), a "\r\n" will not be removed. It works with a single "\r" or "\n". (Tested on *nix and Windows.) Regards, Carsten Reproduce code: --- Expected result: 101 101 101 Actual result: -- 101 101 13 -- Edit this bug report at http://bugs.php.net/?id=48175&edit=1
#47918 [Opn]: stream_set_blocking() does not work with pipes opened with proc_open()
ID: 47918
User updated by: RQuadling at GMail dot com
Reported By: RQuadling at GMail dot com
Status: Open
Bug Type: Streams related
Operating System: Win
PHP Version: 5.*, 6CVS (2009-04-07)
New Comment:
I also tried opening the pipes descriptors like ...
$a_Descriptors = array(0 => array('pipe', 'rn'), 1 => array('pipe',
'wn'), 2 => array('pipe', 'wn'));
but no change.
Previous Comments:
[2009-04-07 21:50:45] RQuadling at GMail dot com
I tried both 0 and False to set non blocking mode. In all cases the
function returns false and the meta data reports that the pipe is
still in blocking mode.
I've just tried it with PHP 5.2.8 (cli) (built: Dec 8 2008 19:31:23)
(on Windows XP SP3) on my home laptop and the same problem.
[2009-04-07 20:00:36] j...@php.net
I'm not sure if it matters, but doing RTFM:
bool stream_set_blocking ( resource $stream , int $mode )
"If mode is 0, the given stream will be switched to non-blocking
mode, and if 1, it will be switched to blocking mode."
:)
[2009-04-07 12:31:33] RQuadling at GMail dot com
Description:
I'm trying to set non-blocking mode on pipes attached to a process
opened using proc_open.
The documentation and the user notes suggest that what I am doing
should work.
Running this with php -n to remove my ini file settings.
Reproduce code:
---
array('pipe', 'r'), 1 => array('pipe',
'w'), 2 => array('pipe', 'w'));
// Provide a place for the pipes.
$a_Pipes = array();
// Create the thread.
$r_Thread = proc_open("dir c:\\ /b", $a_Descriptors, $a_Pipes, Null,
$_ENV);
// Display the current STDOUT meta data.
print_r(stream_get_meta_data($a_Pipes[1]));
// Try to change the blocking mode to non-blocking.
echo (stream_set_blocking($a_Pipes[1], False) ? 'Successfully' :
'Failed'), ' to set blocking mode to non-blocking', PHP_EOL;
// Display the current STDOUT meta data.
print_r(stream_get_meta_data($a_Pipes[1]));
Expected result:
5.3.0RC2-dev WINNT cli
INI:
Array
(
[stream_type] => STDIO
[mode] => r
[unread_bytes] => 0
[seekable] =>
[timed_out] =>
[blocked] => 1
[eof] =>
)
Successfully set blocking mode to non-blocking
Array
(
[stream_type] => STDIO
[mode] => r
[unread_bytes] => 0
[seekable] =>
[timed_out] =>
[blocked] =>
[eof] =>
)
Actual result:
--
5.3.0RC2-dev WINNT cli
INI:
Array
(
[stream_type] => STDIO
[mode] => r
[unread_bytes] => 0
[seekable] =>
[timed_out] =>
[blocked] => 1
[eof] =>
)
Failed to set blocking mode to non-blocking
Array
(
[stream_type] => STDIO
[mode] => r
[unread_bytes] => 0
[seekable] =>
[timed_out] =>
[blocked] => 1
[eof] =>
)
--
Edit this bug report at http://bugs.php.net/?id=47918&edit=1
#48189 [NEW]: ibase_execute error in return param
From: maxwer at ukr dot net
Operating system: Win2000SP4
PHP version: 5.2.9
PHP Bug Type: InterBase related
Bug description: ibase_execute error in return param
Description:
ibase_execute return values
http://ua2.php.net/manual/ru/function.ibase-execute.php
Çàìå÷àíèå: In PHP 5.0.0 and up, this function returns the number of rows
affected by the query (if > 0 and applicable to the statement type). A
query that succeeded, but did not affect any rows (e.g. an UPDATE of a
non-existent record) will return TRUE.
if(Affected_rows == 0){
return STRING "0 " (zero and space) THIS ERROR! need BOOLEAN true
}else{
return INTEGER n --- this normal
}
--
Edit bug report at http://bugs.php.net/?id=48189&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48189&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48189&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48189&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48189&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48189&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48189&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48189&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48189&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48189&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48189&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48189&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48189&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48189&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48189&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48189&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48189&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48189&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48189&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48189&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48189&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48189&r=mysqlcfg
#48188 [NEW]: Cannot execute a scrollable cursors twice with PDO_PGSQL
From: mbecc...@php.net
Operating system: *
PHP version: 5.3CVS-2009-05-08 (CVS)
PHP Bug Type: PDO related
Bug description: Cannot execute a scrollable cursors twice with PDO_PGSQL
Description:
Scrollable cursor support for PDO_PGSQL was introduced in PHP 5.3 (see bug
#44861). Some small issues need to be ironed out, e.g. I found out that
it's impossible to execute a pdo statement using a cursor twice. The
current code fails as the cursor is already existing.
Reproduce code:
---
$pdo = new PDO("pgsql:dbname=test", 'user', 'pass', array(
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION
));
$res = $pdo->prepare("SELECT (?)::int AS x", array(
PDO::ATTR_CURSOR => PDO::CURSOR_SCROLL
));
try {
var_dump($res->execute(array(1)));
var_dump($res->execute(array(2)));
} catch (Exception $e) {
var_dump($e->getMessage());
}
Expected result:
bool(true)
bool(true)
Actual result:
--
bool(true)
string(94) "SQLSTATE[42P03]: Duplicate cursor: 7 ERROR: cursor
"pdo_crsr_0104fee8" already exists"
--
Edit bug report at http://bugs.php.net/?id=48188&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48188&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48188&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48188&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48188&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48188&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48188&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48188&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48188&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48188&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48188&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48188&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48188&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48188&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48188&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48188&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48188&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48188&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48188&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48188&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48188&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48188&r=mysqlcfg
