#37168 [Opn]: WDDX serializer inefficient with larger structures
ID: 37168 User updated by: dolecek at sky dot cz Reported By: dolecek at sky dot cz Status: Open Bug Type: WDDX related Operating System: Windows, NetBSD -PHP Version: 5.1.2 +PHP Version: 5.1.4 New Comment: I figured I used a malloc() debug option when I run the test on NetBSD (/etc/malloc.conf - 'J'), which caused each realloc() call to explicitly malloc() new piece of memory and free the old. With that disabled, the WDDX serializer result is much better on NetBSD (this is without the patch, run with PHP 5.1.4) and actually can complete the benchmark: wddx_serialize_value() (without /etc/malloc.conf - J): 0050: 0.0027 0100: 0.0058 0200: 0.0152 0400: 0.0724 0800: 0.3820 1600: 1.6633 3200: 6.9623 6400: 28.6273 For comparison, this is result with standard serialize(): 0050: 0.0016 0100: 0.0032 0200: 0.0092 0400: 0.0275 0800: 0.1174 1600: 0.5613 3200: 2.3775 6400: 9.8372 So, the WDDX serializer still shows strong non-linear behaviour. wddx_serialize_value() with patch (and without /etc/malloc.conf-J): 0050: 0.0026 0100: 0.0048 0200: 0.0104 0400: 0.0227 0800: 0.0476 1600: 0.0933 3200: 0.1914 6400: 0.3859 serialize() result after applying similar patch to ext/standard/var.c: 0050: 0.0015 0100: 0.0028 0200: 0.0061 0400: 0.0151 0800: 0.0320 1600: 0.0670 3200: 0.1374 6400: 0.2744 Previous Comments: [2006-05-23 22:07:24] dolecek at sky dot cz Changing the OS to Windows, NetBSD. [2006-05-02 19:33:16] dolecek at sky dot cz Fine, the difference is entirely dependant on platform realloc() implementation. Anyone can try the patch on MS Windows? I don't have native compiler there. Thanks. [2006-05-02 13:36:00] [EMAIL PROTECTED] I tried your patch on linux 2.6 and MacOSX 10.3.4 and in both cases had no visible difference (beyond the margin of error) in terms of speed and time taken to execute the code. [2006-04-23 21:32:41] dolecek at sky dot cz Also, it would be useful to know if my patch improves performance on your system (even though the time increase is linear even without my patch on your system). Could you include results without and with patch on your system, please? [2006-04-23 21:29:43] dolecek at sky dot cz I tried the snapshot php5.1-200604232030 - results: NetBSD 3.99.15 (compiled with ./configure --enable-wddx --with-libxml-dir=/usr/pkg): 50: 0.010740995407104 100: 0.053707838058472 200: 0.23849892616272 400: 2.4622600078583 800: 18.556435823441 1600: 94.584519863129 (3200 and 6400 skipped) Tried also Windows version on Windows XP (same computer): 50: 0.0027320384979248 100: 0.0066189765930176 200: 0.024183988571167 400: 0.096118927001953 800: 0.57651996612549 1600: 2.4123661518097 3200: 8.9470641613007 6400: 34.234342098236 So PHP snapshot is ever worse on NetBSD 3.99.15 then PHP 5.1.2. On Windows XP, the increase is linear, but the time increase is non-proportional (2x size means ~4x time increase). What OS did you try the test? Older BSD malloc() was power-of-2 internally and thus would not suffer from this usage pattern. The more modern version used on NetBSD has been adjusted to minimize total memory use, which gives the realloc() performance hit in this case. Perhaps modern GNU libc malloc()/realloc() handles this usage pattern better and that is the reason you don't see the problem? BTW, if the patch 2) or it's variant is adopted, it would be useful to use some suitable power-of-2 value for SMART_STR_START_SIZE (to get multiple of page size and optimal memory use of last page), rather then changing SMART_STR_PREALLOC (which is unused in my patch). 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/37168 -- Edit this bug report at http://bugs.php.net/?id=37168edit=1
#37349 [Asn-Fbk]: memory corruption within run-tests.php
ID: 37349 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Feedback Bug Type: Streams related Operating System: n/a PHP Version: 6CVS-2006-05-07 (CVS) Assigned To: pollita New Comment: Nuno, you must be kidding: - [24 May 9:53pm UTC] [EMAIL PROTECTED] .. I can't reproduce it with the latest CVS. - I said I don't see any valgrind warnings with any of tidy tests, what's the point to refer to your first post? What exactly do you get? Previous Comments: [2006-05-26 18:03:44] [EMAIL PROTECTED] Tony: its in my first comment :) You just need to run valgrind on run-tests.php while testing the tidy/tests/020.phpt file. This produces a nice error message: 'BORK TEST', along with a huge valgrind report. (also, the problem might be in ICU. I haven't look further though) [2006-05-26 06:38:27] [EMAIL PROTECTED] Okay, but how to reproduce it? [2006-05-25 17:06:08] [EMAIL PROTECTED] yep, it is still valid. This bug has nothing to do with tidy itself. It happens that I made a test for tidy that triggered a problem somewhere else. [2006-05-24 21:53:47] [EMAIL PROTECTED] Is this still valid? I can't reproduce it with the latest CVS. [2006-05-07 22:24:04] [EMAIL PROTECTED] Maybe Sara is the best person to look into this (as she implemented the Unicode streams stuff). 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/37349 -- Edit this bug report at http://bugs.php.net/?id=37349edit=1
#37609 [Opn-Bgs]: URL parsing problem with query string and anchor in IE
ID: 37609 Updated by: [EMAIL PROTECTED] Reported By: dmb27 at cornell dot edu -Status: Open +Status: Bogus Bug Type: HTTP related Operating System: Debian unstable 2.6.15 kernel PHP Version: 5.1.4 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2006-05-26 23:43:53] dmb27 at cornell dot edu Description: This is basically bug #9699, but it is marked as closed, and I can't comment on it, and it still exists in PHP 5.1.2 A redirect to a URL with both a query string and an anchor reference treats the anchor portion as part of the query string. For example, in my application, using IE 6, a redirect to: http://adventurersguild.wikispaces.com/message/view/Trading+Board/23190?o=0#28590 has a [QUERY_STRING] = o=0#28590 however in Firefox, [QUERY_STRING] = o=0 If I hit refresh at the error, it doesn't do a redirect and everything is fine. This happens only in Internet Explorer 6, not in Firefox 1.5.0.3 -- Edit this bug report at http://bugs.php.net/?id=37609edit=1
#37349 [Fbk]: memory corruption within run-tests.php
ID: 37349 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Streams related Operating System: n/a PHP Version: 6CVS-2006-05-07 (CVS) Assigned To: pollita New Comment: no, Tony, I'm not :) I'll update ICU to check if that is the problem. Previous Comments: [2006-05-27 09:33:51] [EMAIL PROTECTED] Nuno, you must be kidding: - [24 May 9:53pm UTC] [EMAIL PROTECTED] .. I can't reproduce it with the latest CVS. - I said I don't see any valgrind warnings with any of tidy tests, what's the point to refer to your first post? What exactly do you get? [2006-05-26 18:03:44] [EMAIL PROTECTED] Tony: its in my first comment :) You just need to run valgrind on run-tests.php while testing the tidy/tests/020.phpt file. This produces a nice error message: 'BORK TEST', along with a huge valgrind report. (also, the problem might be in ICU. I haven't look further though) [2006-05-26 06:38:27] [EMAIL PROTECTED] Okay, but how to reproduce it? [2006-05-25 17:06:08] [EMAIL PROTECTED] yep, it is still valid. This bug has nothing to do with tidy itself. It happens that I made a test for tidy that triggered a problem somewhere else. [2006-05-24 21:53:47] [EMAIL PROTECTED] Is this still valid? I can't reproduce it with the latest CVS. 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/37349 -- Edit this bug report at http://bugs.php.net/?id=37349edit=1
#37610 [NEW]: win32build has incorrect expat, PHP non-buildable
From: jdolecek at NetBSD dot org Operating system: Windows PHP version: 5.1.4 PHP Bug Type: Compile Failure Bug description: win32build has incorrect expat, PHP non-buildable Description: http://www.php.net/extra/win32build.zip has incorrect version of expat bundled - with version bundled there, extensions xml and wddx don't build, missing some symbols and e.g. structure XML_Memory_Handling_Suite. Reproduce code: --- Try to follow README.WIN32-BUILD-SYSTEM and setup build environment on MS Windows. Expected result: Compiles fine. Actual result: -- Build ends with compile failure. -- Edit bug report at http://bugs.php.net/?id=37610edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37610r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37610r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37610r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37610r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37610r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37610r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37610r=needscript Try newer version:http://bugs.php.net/fix.php?id=37610r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37610r=support Expected behavior:http://bugs.php.net/fix.php?id=37610r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37610r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37610r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37610r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37610r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37610r=dst IIS Stability:http://bugs.php.net/fix.php?id=37610r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37610r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37610r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37610r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37610r=mysqlcfg
#37349 [Fbk-Opn]: memory corruption within run-tests.php
ID: 37349 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Streams related Operating System: n/a PHP Version: 6CVS-2006-05-07 (CVS) Assigned To: pollita New Comment: I've upgraded ICU to version 3.4.1 and I still get the same problems: http://mega.ist.utl.pt/~ncpl/php6-tidy-valgrind.txt Previous Comments: [2006-05-27 09:40:35] [EMAIL PROTECTED] no, Tony, I'm not :) I'll update ICU to check if that is the problem. [2006-05-27 09:33:51] [EMAIL PROTECTED] Nuno, you must be kidding: - [24 May 9:53pm UTC] [EMAIL PROTECTED] .. I can't reproduce it with the latest CVS. - I said I don't see any valgrind warnings with any of tidy tests, what's the point to refer to your first post? What exactly do you get? [2006-05-26 18:03:44] [EMAIL PROTECTED] Tony: its in my first comment :) You just need to run valgrind on run-tests.php while testing the tidy/tests/020.phpt file. This produces a nice error message: 'BORK TEST', along with a huge valgrind report. (also, the problem might be in ICU. I haven't look further though) [2006-05-26 06:38:27] [EMAIL PROTECTED] Okay, but how to reproduce it? [2006-05-25 17:06:08] [EMAIL PROTECTED] yep, it is still valid. This bug has nothing to do with tidy itself. It happens that I made a test for tidy that triggered a problem somewhere else. 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/37349 -- Edit this bug report at http://bugs.php.net/?id=37349edit=1
#37445 [Asn]: Reproducible segfault
ID: 37445 User updated by: dhrubab at gmail dot com Reported By: dhrubab at gmail dot com Status: Assigned Bug Type: PDO related Operating System: Linux PHP Version: 5.1.4 Assigned To: wez New Comment: The two urls I provided were broken for a while but have now been relocated to the following two urls. Sorry for any inconvenience. Source: http://static.dhruba.net/bugs/37445.src.html Phpinfo: http://static.dhruba.net/bugs/37445.phpinfo.html I should also mention that I've been getting futher segfaults being caused by a variety of very different code. For example doing var_dump(); followed by exit; within a loop is causing a segfault. I'm not able to reproduce with smaller test cases. Is it okay if I give you a trace for the segfault from my own application since the smaller test cases are sometimes quite difficult to produce? Previous Comments: [2006-05-26 08:51:04] dhrubab at gmail dot com Has analysis of this problem been started? [2006-05-26 00:56:46] php at seven dot net dot nz I too was going nuts from this bug. I know no C so I can't help too much, but here's my GDB trace for people that understand it. So far I can't narrow down exactly what code is causing the segfault. Reverting the diff as suggested by indeyets at gmail dot com solved the problem. ./configure --enable-debug --with-apxs2=/usr/bin/apxs2 --with-zlib --with-bz2 --with-gd --with-ttf --with-pdo-mysql --with-mysql --with-xmlrpc --with-curl Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1214347584 (LWP 14636)] 0xb7401950 in mysql_more_results () from /usr/lib/libmysqlclient.so.15 (gdb) where #0 0xb7401950 in mysql_more_results () from /usr/lib/libmysqlclient.so.15 #1 0xb76ff78c in pdo_mysql_stmt_dtor (stmt=0x8399a74) at /tmp/php-5.1.4/ext/pdo_mysql/mysql_statement.c:71 #2 0xb76f9713 in free_statement (stmt=0x8399a74) at /tmp/php-5.1.4/ext/pdo/pdo_stmt.c:2200 #3 0xb786485b in zend_objects_store_free_object_storage (objects=0xb79e396c) at /tmp/php-5.1.4/Zend/zend_objects_API.c:86 #4 0xb783b851 in shutdown_executor () at /tmp/php-5.1.4/Zend/zend_execute_API.c:281 #5 0xb7848645 in zend_deactivate () at /tmp/php-5.1.4/Zend/zend.c:854 #6 0xb7806229 in php_request_shutdown (dummy=0x0) at /tmp/php-5.1.4/main/main.c:1287 #7 0xb78e71b7 in php_handler (r=0x82af068) at /tmp/php-5.1.4/sapi/apache2handler/sapi_apache2.c:445 #8 0x08077e38 in ap_run_handler () #9 0x080781bc in ap_invoke_handler () #10 0x080698c3 in ap_internal_redirect () #11 0xb717cc03 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so #12 0x082af058 in ?? () #13 0x082a66b0 in ?? () #14 0x in ?? () [2006-05-19 09:21:12] greg dot smith at gr-tech dot net I have reproduced the bug on Centos 4 64bit and 32 bit and Fedora core 5 as well as Suse 10.1 [2006-05-15 12:40:11] indeyets at gmail dot com reverting this diff helps to solve problem, while the proper resolution is not available: http://cvs.php.net/viewcvs.cgi/php-src/ext/pdo_mysql/mysql_statement.c?r1=1.48.2.12r2=1.48.2.13 [2006-05-15 10:20:58] dhrubab at gmail dot com A note to say I'm using latest php (5.1.4), mysql (5.0.21), pecl-pdo (1.0.3) and pecl-pdo-mysql (1.0.2). The example code relies on mysql5 default tables being there. 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/37445 -- Edit this bug report at http://bugs.php.net/?id=37445edit=1
#37611 [NEW]: WDDX serializer encodes all non-ascii characters with char/
From: jdolecek at NetBSD dot org
Operating system: Any
PHP version: 5.1.5CVS
PHP Bug Type: WDDX related
Bug description: WDDX serializer encodes all non-ascii characters with char/
Description:
The condition which determines if a character in string should be encoded
using the char code=XX/ construct was changed in
php-src/ext/wddx/wddx.c was changed in rev. 1.135 to:
if (iscntrl((int)*(unsigned char *)p) || (int)*(unsigned char *)p = 127)
{
...encode using char code=XX/...
}
This means that _all_ non-ascii characters are encoded with the construct,
which explodes the result packet size if non-ascii characters are used.
The || (int)*(unsigned char *)p = 127 parts seems as left-over debug
code and should be removed.
Reproduce code:
---
// this was not actually tried, this is just code review
wddx_serialize_value(char(200));
Expected result:
wddxPacket
version='1.0'header/datastring#268;/string/data/wddxPacket
Actual result:
--
wddxPacket version='1.0'header/datastringchar
code=C8//string/data/wddxPacket
--
Edit bug report at http://bugs.php.net/?id=37611edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37611r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37611r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37611r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37611r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37611r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37611r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37611r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37611r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37611r=support
Expected behavior:http://bugs.php.net/fix.php?id=37611r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37611r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37611r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37611r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37611r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37611r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37611r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37611r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37611r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37611r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37611r=mysqlcfg
#37611 [Opn]: WDDX serializer encodes all non-ascii characters with char/
ID: 37611
User updated by: jdolecek at NetBSD dot org
Reported By: jdolecek at NetBSD dot org
Status: Open
Bug Type: WDDX related
Operating System: Any
PHP Version: 5.1.5CVS
New Comment:
Seems the bug submit system turns non-ascii character to some entities,
the #268; should be character with ordinal value 200 (i.e. result of
chr(200)).
Previous Comments:
[2006-05-27 09:57:18] jdolecek at NetBSD dot org
Description:
The condition which determines if a character in string should be
encoded using the char code=XX/ construct was changed in
php-src/ext/wddx/wddx.c was changed in rev. 1.135 to:
if (iscntrl((int)*(unsigned char *)p) || (int)*(unsigned char *)p =
127) {
...encode using char code=XX/...
}
This means that _all_ non-ascii characters are encoded with the
construct, which explodes the result packet size if non-ascii
characters are used.
The || (int)*(unsigned char *)p = 127 parts seems as left-over debug
code and should be removed.
Reproduce code:
---
// this was not actually tried, this is just code review
wddx_serialize_value(char(200));
Expected result:
wddxPacket
version='1.0'header/datastring#268;/string/data/wddxPacket
Actual result:
--
wddxPacket version='1.0'header/datastringchar
code=C8//string/data/wddxPacket
--
Edit this bug report at http://bugs.php.net/?id=37611edit=1
#37076 [Fbk-Asn]: SimpleXML ignores .=
ID: 37076 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Assigned Bug Type: SimpleXML related Operating System: * PHP Version: 6, 5.1.* Assigned To: helly New Comment: http://php.is/bugs/37076/bug37076.phpt (fails still) Previous Comments: [2006-05-27 01:12:01] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip Can you please write a test case? [2006-04-14 12:03:29] [EMAIL PROTECTED] Reproduced in HEAD It does however work in 5.0.. [2006-04-14 10:58:40] [EMAIL PROTECTED] This cannot work in 5.1. Please test HEAD and assign to me if it is not working in HEAD or close if it does. [2006-04-14 00:30:30] [EMAIL PROTECTED] Description: Simplexml doesn't respect .= Reproduce code: --- ?php $xml = simplexml_load_string(rootfoo //root); $xml-foo = foo; $xml-foo .= bar; print $xml-asXML(); Expected result: ?xml version=1.0? rootfoofoobar/foo/root Actual result: -- ?xml version=1.0? rootfoofoo/foo/root -- Edit this bug report at http://bugs.php.net/?id=37076edit=1
#37408 [Fbk-Csd]: max_execution_time seems to be in affect for interactive CLI sessions
ID: 37408 User updated by: Jared dot Williams1 at ntlworld dot com Reported By: Jared dot Williams1 at ntlworld dot com -Status: Feedback +Status: Closed Bug Type: Scripting Engine problem Operating System: Win2000 PHP Version: 5.1.4 Assigned To: helly New Comment: Latest snaps do seem fixed. Previous Comments: [2006-05-27 01:02:11] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-05-25 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. [2006-05-19 08:05:50] psadac at gmail dot com it's a bug. I run php 5.1.4 over Windows XP, i have max_execution_time = 240 in my php.ini, set_time_limit(0) in my php script and i get Maximum execution time of 60 seconds exceeded. [2006-05-18 13:42:54] mlee at kanhan dot com It's 30 seconds in my php.ini, but the error I get is this: Fatal error: Maximum execution time of 60 seconds exceeded Anyway, I thought the documentation is quite clear about the fact max_execution_time is one of the overridden php.ini directives for the CLI executable and that the default value is 0 (infinite). [2006-05-17 14:06:28] [EMAIL PROTECTED] What's defined for max_execution_time in your php.ini 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/37408 -- Edit this bug report at http://bugs.php.net/?id=37408edit=1
#37612 [Opn-Ver]: Segfault - infinite recursion
ID: 37612
Updated by: [EMAIL PROTECTED]
Reported By: kevin at oceania dot net
-Status: Open
+Status: Verified
Bug Type: Reproducible crash
Operating System: Linux
-PHP Version: 5CVS-2006-05-27 (snap)
+PHP Version: 6, 5.2.0-cvs
New Comment:
Shorter reproducible code:
?php
class foo {
public function bar() {
return $this-bar();
}
}
$foo = new foo();
$foo-bar();
?
Previous Comments:
[2006-05-27 11:16:49] kevin at oceania dot net
Description:
... infinite recursion
[Sat May 27 21:42:49 2006] [notice] child pid 10096 exit signal
Segmentation fault (11)
[Sat May 27 21:42:49 2006] [notice] child pid 10097 exit signal
Segmentation fault (11)
Reproduce code:
---
http://phpro.org/segfault.phps
Expected result:
output html table
Actual result:
--
(gdb) bt
#0 0x00bd5f1f in _int_malloc () from /lib/tls/libc.so.6
#1 0x00bd7f81 in malloc () from /lib/tls/libc.so.6
#2 0xf61f206b in _emalloc (size=44, __zend_filename=0xf634e1a0
/home/kevin/html/php/dev/php5.2-200605230630/Zend/zend_vm_execute.h,
__zend_lineno=225, __zend_orig_filename=0x0, __zend_orig_lineno=0) at
/home/kevin/html/php/dev/php5.2-200605230630/Zend/zend_alloc.c:182
#3 0xf622947b in zend_do_fcall_common_helper_SPEC
(execute_data=0xfe34a200) at zend_vm_execute.h:225
#4 0xf6229fa0 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xfe34a200) at zend_vm_execute.h:322
#5 0xf6228fd2 in execute (op_array=0xa157704) at zend_vm_execute.h:92
#6 0xf62294e8 in zend_do_fcall_common_helper_SPEC
(execute_data=0xfe34a350) at zend_vm_execute.h:234
#7 0xf6229fa0 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xfe34a350) at zend_vm_execute.h:322
#8 0xf6228fd2 in execute (op_array=0xa157704) at zend_vm_execute.h:92
#9 0xf62294e8 in zend_do_fcall_common_helper_SPEC
(execute_data=0xfe34a4a0) at zend_vm_execute.h:234
--
Edit this bug report at http://bugs.php.net/?id=37612edit=1
#37613 [NEW]: tempnam suffix support and dir behavior change
From: wardenik at gmail dot com Operating system: Linux PHP version: 5.1.4 PHP Bug Type: Feature/Change Request Bug description: tempnam suffix support and dir behavior change Description: It would be very useful if the tempnam function would allow to support suffix on the created filename as well. I'm creating for instance xml files with it, and they have to have .xml at the end. Moreover, I think that the behavior that tempnam changes the prefix when unable to create the file in the supplied 'dir' is wrong. It should generate an error instead and not trash some other unwanted places. -- Edit bug report at http://bugs.php.net/?id=37613edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37613r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37613r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37613r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37613r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37613r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37613r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37613r=needscript Try newer version:http://bugs.php.net/fix.php?id=37613r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37613r=support Expected behavior:http://bugs.php.net/fix.php?id=37613r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37613r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37613r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37613r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37613r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37613r=dst IIS Stability:http://bugs.php.net/fix.php?id=37613r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37613r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37613r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37613r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37613r=mysqlcfg
#37612 [Ver-Bgs]: Segfault - infinite recursion
ID: 37612
Updated by: [EMAIL PROTECTED]
Reported By: kevin at oceania dot net
-Status: Verified
+Status: Bogus
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 6, 5.2.0-cvs
New Comment:
Yes, smashing the stack produces segfault and this is expected.
Previous Comments:
[2006-05-27 12:14:32] [EMAIL PROTECTED]
Shorter reproducible code:
?php
class foo {
public function bar() {
return $this-bar();
}
}
$foo = new foo();
$foo-bar();
?
[2006-05-27 11:16:49] kevin at oceania dot net
Description:
... infinite recursion
[Sat May 27 21:42:49 2006] [notice] child pid 10096 exit signal
Segmentation fault (11)
[Sat May 27 21:42:49 2006] [notice] child pid 10097 exit signal
Segmentation fault (11)
Reproduce code:
---
http://phpro.org/segfault.phps
Expected result:
output html table
Actual result:
--
(gdb) bt
#0 0x00bd5f1f in _int_malloc () from /lib/tls/libc.so.6
#1 0x00bd7f81 in malloc () from /lib/tls/libc.so.6
#2 0xf61f206b in _emalloc (size=44, __zend_filename=0xf634e1a0
/home/kevin/html/php/dev/php5.2-200605230630/Zend/zend_vm_execute.h,
__zend_lineno=225, __zend_orig_filename=0x0, __zend_orig_lineno=0) at
/home/kevin/html/php/dev/php5.2-200605230630/Zend/zend_alloc.c:182
#3 0xf622947b in zend_do_fcall_common_helper_SPEC
(execute_data=0xfe34a200) at zend_vm_execute.h:225
#4 0xf6229fa0 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xfe34a200) at zend_vm_execute.h:322
#5 0xf6228fd2 in execute (op_array=0xa157704) at zend_vm_execute.h:92
#6 0xf62294e8 in zend_do_fcall_common_helper_SPEC
(execute_data=0xfe34a350) at zend_vm_execute.h:234
#7 0xf6229fa0 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0xfe34a350) at zend_vm_execute.h:322
#8 0xf6228fd2 in execute (op_array=0xa157704) at zend_vm_execute.h:92
#9 0xf62294e8 in zend_do_fcall_common_helper_SPEC
(execute_data=0xfe34a4a0) at zend_vm_execute.h:234
--
Edit this bug report at http://bugs.php.net/?id=37612edit=1
#35386 [Com]: firebird: first row is null
ID: 35386
Comment by: stefan at horochovec dot com dot br
Reported By: slapaf at hotmail dot com
Status: Suspended
Bug Type: PDO related
Operating System: winxp sp2
PHP Version: 5CVS-2006-12-02 (snap)
New Comment:
Hi, i´m using PHP 5.1.4, Windows XP SP2 and Firebird 1.x and have the
same problem.
Previous Comments:
[2006-05-04 13:06:06] krovomi at msn dot com
Does someone got a solution to this problem ?
Thanks
[2006-03-27 22:32:47] [EMAIL PROTECTED]
Looking for someone to maintain the firebird driver.
[2006-03-21 16:11:10] salbefe at inf dot upv dot es
I have the same problem in Windows 2003 SP1.
[2006-03-10 09:49:11] astro101 at hotmail dot com
Yes had same problem WinXP SP2 Firebird 1.5.3 and firebird 2 and PHP
5.1.2, PHP5.1.3RC1, PHP5.1.3RC2.
[2006-02-11 17:25:16] thomas at last-it dot de
same problem on linux, php 5.1.2
I tried to debug the problem, but imho the problem is strange.
The reason why the first row is null is as following:
file: ext/pdo/pdo_stmt.c
line: 532
code
case PDO_PARAM_STR:
if (value !(value_len == 0 stmt-dbh-oracle_nulls ==
PDO_NULL_EMPTY_STRING)) {
ZVAL_STRINGL(dest, value, value_len, !caller_frees);
if (caller_frees) {
caller_frees = 0;
}
break;
}
default:
ZVAL_NULL(dest);
/code
With the first returned row from DB the first if clause above evaluates
to false.
so ZVAL_NULL is called. thats the reason for the null values in the
first result set.
Normally should value point to the argument ptr of the
firebird_stmt_get_col function (in firebird_statement.c).
gdp says that ptr is filled with the data out of DB properly.
So why is value not the same as ptr and why is this only in the
first result set??
greetz Thomas
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/35386
--
Edit this bug report at http://bugs.php.net/?id=35386edit=1
#37445 [Asn]: Reproducible segfault
ID: 37445
Updated by: [EMAIL PROTECTED]
Reported By: dhrubab at gmail dot com
Status: Assigned
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.4
Assigned To: wez
New Comment:
$oDB= new PDO('mysql:host=localhost;dbname=yourdb', 'user',
'pass');
// emulated or not does not matter
$oDB-setAttribute(PDO :: ATTR_EMULATE_PREPARES, true);
$oStm = $oDB-prepare(SELECT * FROM tbl WHERE
xyz=:character_set);
$oStm-bindParam(':character_set', 'foo);
For the record, the problem here is only about how PDO manages to free
its resource when a fatal error or exit() occurs.
In this example, it is a fatal error raise with the bindParam call (it
expects a variable as it uses a reference).
The problem is the same in many other bug reports (unexpected script
exist, like exit() in a function). The solution is to always set
query_stmt in the dbh struct, and add another flag to define if there
was an error or not.
I have patches that fix the problem for mysql. To be sure I don't break
something in the working drivers, I have to install pgsql.
Previous Comments:
[2006-05-27 09:56:46] dhrubab at gmail dot com
The two urls I provided were broken for a while but have now been
relocated to the following two urls. Sorry for any inconvenience.
Source: http://static.dhruba.net/bugs/37445.src.html
Phpinfo: http://static.dhruba.net/bugs/37445.phpinfo.html
I should also mention that I've been getting futher segfaults being
caused by a variety of very different code. For example doing
var_dump(); followed by exit; within a loop is causing a segfault. I'm
not able to reproduce with smaller test cases. Is it okay if I give
you a trace for the segfault from my own application since the smaller
test cases are sometimes quite difficult to produce?
[2006-05-26 08:51:04] dhrubab at gmail dot com
Has analysis of this problem been started?
[2006-05-26 00:56:46] php at seven dot net dot nz
I too was going nuts from this bug. I know no C so I can't help too
much, but here's my GDB trace for people that understand it. So far I
can't narrow down exactly what code is causing the segfault. Reverting
the diff as suggested by indeyets at gmail dot com solved the problem.
./configure --enable-debug --with-apxs2=/usr/bin/apxs2 --with-zlib
--with-bz2 --with-gd --with-ttf --with-pdo-mysql --with-mysql
--with-xmlrpc --with-curl
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1214347584 (LWP 14636)]
0xb7401950 in mysql_more_results () from /usr/lib/libmysqlclient.so.15
(gdb) where
#0 0xb7401950 in mysql_more_results () from
/usr/lib/libmysqlclient.so.15
#1 0xb76ff78c in pdo_mysql_stmt_dtor (stmt=0x8399a74) at
/tmp/php-5.1.4/ext/pdo_mysql/mysql_statement.c:71
#2 0xb76f9713 in free_statement (stmt=0x8399a74) at
/tmp/php-5.1.4/ext/pdo/pdo_stmt.c:2200
#3 0xb786485b in zend_objects_store_free_object_storage
(objects=0xb79e396c) at /tmp/php-5.1.4/Zend/zend_objects_API.c:86
#4 0xb783b851 in shutdown_executor () at
/tmp/php-5.1.4/Zend/zend_execute_API.c:281
#5 0xb7848645 in zend_deactivate () at /tmp/php-5.1.4/Zend/zend.c:854
#6 0xb7806229 in php_request_shutdown (dummy=0x0) at
/tmp/php-5.1.4/main/main.c:1287
#7 0xb78e71b7 in php_handler (r=0x82af068) at
/tmp/php-5.1.4/sapi/apache2handler/sapi_apache2.c:445
#8 0x08077e38 in ap_run_handler ()
#9 0x080781bc in ap_invoke_handler ()
#10 0x080698c3 in ap_internal_redirect ()
#11 0xb717cc03 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so
#12 0x082af058 in ?? ()
#13 0x082a66b0 in ?? ()
#14 0x in ?? ()
[2006-05-19 09:21:12] greg dot smith at gr-tech dot net
I have reproduced the bug on Centos 4 64bit and 32 bit and Fedora core
5 as well as Suse 10.1
[2006-05-15 12:40:11] indeyets at gmail dot com
reverting this diff helps to solve problem, while the proper resolution
is not available:
http://cvs.php.net/viewcvs.cgi/php-src/ext/pdo_mysql/mysql_statement.c?r1=1.48.2.12r2=1.48.2.13
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/37445
--
Edit this bug report at http://bugs.php.net/?id=37445edit=1
#37614 [NEW]: Class name lowercased in error message
From: [EMAIL PROTECTED]
Operating system: Irrelevant
PHP version: 5CVS-2006-05-27 (CVS)
PHP Bug Type: Scripting Engine problem
Bug description: Class name lowercased in error message
Description:
The class name in the Cannot redeclare class ... error message is
lowercased and not the original one.
Reproduce code:
---
?php
class Foo {}
class Foo {}
?
Expected result:
Fatal error: Cannot redeclare class Foo in /home/sb/test.php on line 3
Actual result:
--
Fatal error: Cannot redeclare class foo in /home/sb/test.php on line 3
--
Edit bug report at http://bugs.php.net/?id=37614edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37614r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37614r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37614r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37614r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37614r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37614r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37614r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37614r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37614r=support
Expected behavior:http://bugs.php.net/fix.php?id=37614r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37614r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37614r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37614r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37614r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37614r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37614r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37614r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37614r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37614r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37614r=mysqlcfg
#37615 [NEW]: session_is_persistent
From: elias at adaptiveinstance dot com Operating system: all PHP version: 5.1.4 PHP Bug Type: Session related Bug description: session_is_persistent Description: There is no reliable way to determine if the session has already been closed with session_write_close() or not. a function like session_is_persistent() would be needful to validate that changes to $_SESSION will be written. -- Edit bug report at http://bugs.php.net/?id=37615edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37615r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37615r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37615r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37615r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37615r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37615r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37615r=needscript Try newer version:http://bugs.php.net/fix.php?id=37615r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37615r=support Expected behavior:http://bugs.php.net/fix.php?id=37615r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37615r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37615r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37615r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37615r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37615r=dst IIS Stability:http://bugs.php.net/fix.php?id=37615r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37615r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37615r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37615r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37615r=mysqlcfg
#37615 [Opn-WFx]: session_is_persistent
ID: 37615 Updated by: [EMAIL PROTECTED] Reported By: elias at adaptiveinstance dot com -Status: Open +Status: Wont fix Bug Type: Session related Operating System: all PHP Version: 5.1.4 New Comment: There is also no way to determine if any other function has been called, but that doesn't mean we're going to add new functions for that. Previous Comments: [2006-05-27 14:35:44] elias at adaptiveinstance dot com Description: There is no reliable way to determine if the session has already been closed with session_write_close() or not. a function like session_is_persistent() would be needful to validate that changes to $_SESSION will be written. -- Edit this bug report at http://bugs.php.net/?id=37615edit=1
#37448 [Com]: FastCGI Error: Server too busy Server
ID: 37448 Comment by: msisolak at yahoo dot com Reported By: coder1 at gmail dot com Status: No Feedback Bug Type: CGI related Operating System: Windows XP PHP Version: 5.1.4 New Comment: I am also able to reproduce this on the current 5.2 branch (built: May 27 2006 16:22:11) with isapi_fcgi.dll (FCGI_SERVER_VERSION = 2.2.2 0.5.2 beta). It appears to be triggered by an echo that is larger than some magic number around 16kB. This code: ?php echo str_repeat(str_repeat(-=-=-=, 20) . br, 131); ? outputs a page that is 16,244 bytes. If I increase the count to 132 (what would be 16,368 bytes) I get: HTTP/1.1 503 Server too busy Server: Microsoft-IIS/5.1 Date: Sat, 27 May 2006 15:05:07 GMT X-Powered-By: ASP.NET Connection: close Content-Type: text/html Server Error, unable to connect to fastcgi server. Previous Comments: [2006-05-23 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. [2006-05-15 17:16:28] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2006-05-15 17:05:23] coder1 at gmail dot com Description: isapi_fcgi.dll fails to load PHP properly on WinXP SP2/IIS5.1 There are no errors showing up in the event log. When I configure IIS to php-cgi.exe, the page loads as expected. This was an upgrade from 5.1.2 to 5.1.4. 5.1.2 works OK with the same isapi_fcgi.dll. Additionally, I tested the Zend FastCGI file (zend_fcgi.dll) included with Zend Core. This version of FastCGI works OK. It is Caraveo's version (and my modification originating from this source) which previously worked on 5.1.2 that now fails to work with 5.1.4. Reproduce code: --- ? phpinfo(); ? Expected result: Display PHP Information Actual result: -- HTTP/1.1 503 Server too busy Server: Microsoft-IIS/5.1 Date: Wed, 10 May 2006 17:09:58 GMT Connection: close Content-Type: text/html Server Error, unable to connect to fastcgi server. -- Edit this bug report at http://bugs.php.net/?id=37448edit=1
#37615 [WFx]: session_is_persistent
ID: 37615 User updated by: elias at adaptiveinstance dot com Reported By: elias at adaptiveinstance dot com Status: Wont fix Bug Type: Session related Operating System: all PHP Version: 5.1.4 New Comment: thats not what's on my mind at all. i think adding an internal flag that tracks if session_write_close() was called isn't that hard. Previous Comments: [2006-05-27 14:45:36] [EMAIL PROTECTED] There is also no way to determine if any other function has been called, but that doesn't mean we're going to add new functions for that. [2006-05-27 14:35:44] elias at adaptiveinstance dot com Description: There is no reliable way to determine if the session has already been closed with session_write_close() or not. a function like session_is_persistent() would be needful to validate that changes to $_SESSION will be written. -- Edit this bug report at http://bugs.php.net/?id=37615edit=1
#37212 [Asn-Csd]: Access to protected property of common base class
ID: 37212
Updated by: [EMAIL PROTECTED]
Reported By: andreasblixt at msn dot com
-Status: Assigned
+Status: Closed
Bug Type: Class/Object related
Operating System: *
-PHP Version: 5.1.*, 5.2.0-dev
+PHP Version: 5.1.*
Assigned To: helly
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Fixed in 5.2, cannot fix in 5.0/5.1
Previous Comments:
[2006-05-27 02:14:58] [EMAIL PROTECTED]
Fixed in HEAD so far.
[2006-05-27 02:05:19] [EMAIL PROTECTED]
Fix requies API change so it is not doable in 5.1.
[2006-05-27 01:40:49] [EMAIL PROTECTED]
The problem is that right now struct property_info does not know where
the property was declared. Thus what the engine sees is B accessing
some protected property in C. The fix seems however quite easy. I'll
give it a try.
[2006-05-05 19:03:33] [EMAIL PROTECTED]
Probably a missing check if the property was declared in a common
parent class?
[2006-04-27 19:39:38] crescentfreshpot at yahoo dot com
Odd. Here is a complete example.
?php
class A {
protected $value;
public function __construct($val) {
$this-value = $val;
}
public function copyValue($obj) {
$this-value = $obj-value;
}
protected function getValue() {
return $this-value;
}
}
class B extends A {
public function copyValue($obj) {
$this-value = $obj-getValue(); // this works
$this-value = $obj-value; // this is fatal
}
}
class C extends A {}
$B = new B(Value from B);
$C = new C(Value from C);
$B-copyValue($C);
?
Strange that the method call works but the property access doesn't.
Both are protected.
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/37212
--
Edit this bug report at http://bugs.php.net/?id=37212edit=1
#37614 [Opn-Csd]: Class name lowercased in error message
ID: 37614
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.*
Assigned To: helly
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2006-05-27 14:20:28] [EMAIL PROTECTED]
Description:
The class name in the Cannot redeclare class ... error message is
lowercased and not the original one.
Reproduce code:
---
?php
class Foo {}
class Foo {}
?
Expected result:
Fatal error: Cannot redeclare class Foo in /home/sb/test.php on line 3
Actual result:
--
Fatal error: Cannot redeclare class foo in /home/sb/test.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=37614edit=1
#37616 [NEW]: DATE_RFC822 does not product RFC 822 dates
From: evert at collab dot nl Operating system: Debian PHP version: 5.1.4 PHP Bug Type: Date/time related Bug description: DATE_RFC822 does not product RFC 822 dates Description: The DATE_RFC822 constant does not always produce proper dates It puts a 'CEST' time zone identifier in the end of the string, however there are only a few time zone abbriviations that are 'legal' in RFC 822, instead it should show the offset in these cases.. Reproduce code: --- echo(date(RFC822)); Expected result: Thu, 25 May 2006 01:11:01 +0100 Actual result: -- Thu, 25 May 2006 01:11:01 CEST -- Edit bug report at http://bugs.php.net/?id=37616edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37616r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=37616r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37616r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37616r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37616r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37616r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37616r=needscript Try newer version:http://bugs.php.net/fix.php?id=37616r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37616r=support Expected behavior:http://bugs.php.net/fix.php?id=37616r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37616r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37616r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37616r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37616r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37616r=dst IIS Stability:http://bugs.php.net/fix.php?id=37616r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37616r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37616r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37616r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37616r=mysqlcfg
#37616 [Opn-Asn]: DATE_RFC822 does not product RFC 822 dates
ID: 37616 Updated by: [EMAIL PROTECTED] Reported By: evert at collab dot nl -Status: Open +Status: Assigned Bug Type: Date/time related Operating System: Debian PHP Version: 5.1.4 -Assigned To: +Assigned To: derick New Comment: Patch (5.2-cvs and HEAD): http://php.is/bugs/37616/bug37616.patch.txt phpdoc: http://php.is/bugs/37616/bug37616.phpdoc.patch.txt however; I don't quite see the need for this constant as RFC2822 supersedes the one specified in Request For Comments (RFC) 822, Standard for the Format of ARPA Internet Text Messages, updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. -Hannes Previous Comments: [2006-05-27 21:22:47] evert at collab dot nl Description: The DATE_RFC822 constant does not always produce proper dates It puts a 'CEST' time zone identifier in the end of the string, however there are only a few time zone abbriviations that are 'legal' in RFC 822, instead it should show the offset in these cases.. Reproduce code: --- echo(date(RFC822)); Expected result: Thu, 25 May 2006 01:11:01 +0100 Actual result: -- Thu, 25 May 2006 01:11:01 CEST -- Edit this bug report at http://bugs.php.net/?id=37616edit=1
