#21592 [NEW]: form submit and iso-8859-2
From: [EMAIL PROTECTED] Operating system: RH 8.0 PHP version: 4.3.0 PHP Bug Type: Scripting Engine problem Bug description: form submit and iso-8859-2 When I submit a form (GET or POST), characters only in the iso-8859-2 charset (like õûÕÛ) are not converted from quoted-printable to their 1-character-long representations, instead they left unchanged like õ etc. I set the charset in the httpd.conf file, in the php.ini file, in the header of the html file and in the accept-charset attrib. of the form tag, but with no avail. I tried it in NN, Opera and IE. One more thing: sometimes it works correctly, but most of the time it doesn't. So strange enough! -- Edit bug report at http://bugs.php.net/?id=21592&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21592&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21592&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21592&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21592&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21592&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21592&r=support Expected behavior: http://bugs.php.net/fix.php?id=21592&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21592&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21592&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21592&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21592&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21592&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21592&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21592&r=gnused
#19292 [Com]: random error: open_basedir restriction in effect. File is in wrong directory
ID: 19292 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Apache related Operating System: linux PHP Version: 4.2.3,4.3.0 New Comment: Same problem with php 4.3.0 / apache 1.3.27 / Slackware The problem seems to appear when a virtual host has a open_basedir defined, but not in other virtualhost. In this case others virtual hosts take the value of one of defined open_basedir. (maybe the value come from another http child open in same time) Seems to have same behaviour with auto_append. Hope it will help to solve this bug. Fred Previous Comments: [2003-01-11 21:33:19] [EMAIL PROTECTED] I have 2 FreeBSD servers with the same problem. Both have /www as symlink. Real path is /home/www. I also have a Windows machine, with no symlink ;-) - no problem there. /www is c:/www there, and all works. All machines have same httpd.conf, same Apache, same 4.2.3 [2003-01-11 05:16:38] [EMAIL PROTECTED] 4.3.o stills has the same problem, the test suite I posted on 30 Oct 2002 12:56am fails with this messages: Warning: main() [function.main]: open_basedir restriction in effect. File(/usr/local/lib/php/hello.php) is not within the allowed path(s): (/usr/local/http-docs/common/scripts/) in /usr/local/http-docs/common/lib/test/test.php on line 5 Warning: main(hello.php) [function.main]: failed to create stream: Not owner in /usr/local/http-docs/common/lib/test/test.php on line 5 Fatal error: main() [function.main]: Failed opening required 'hello.php' (include_path='./:/usr/local/http-docs/common/lib:/usr/local/lib/php:/usr/local/http-docs/common/lib/phpwhois') in /usr/local/http-docs/common/lib/test/test.php on line 5 where test.php tries to include hello.php which is in /usr/local/http-docs/common/lib/test that is a path that's included in include_path [2003-01-10 04:36:13] [EMAIL PROTECTED] Update version. Bug confirmed in 4.3.0 - final. [2003-01-10 03:17:18] [EMAIL PROTECTED] Is somebody working on this critical bug in php 4.3.0?? Bug was opened 8 sep and now it isn't even the same year... This is a severe problem for all hosting companies since they have to turn of open_basedir to get things going without errors. [2003-01-09 12:42:13] [EMAIL PROTECTED] I have just tried to EXPLICITLY set "php_admin_flag safe_mode off" to ALL virtual hosts, which should not be restricted with safe mode and it seems to help. So the problem is here only when I rely on the default setting in php.ini file (where I have safe mode off by default) and when there is AT LEAST one virtual host with safe_mode enabled. 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/19292 -- Edit this bug report at http://bugs.php.net/?id=19292&edit=1
#14391 [Com]: gmmktime, gmdate work incorrect
ID: 14391
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: No Feedback
Bug Type: Date/time related
Operating System: Windows 2000 Server
PHP Version: 4.0.6
New Comment:
this bug has been around for over 2 years and it's a big one!!!
for time based apps lets face it, the gmmktime function is extremely
important.
any idea when this will be fixed?
Previous Comments:
[2003-01-08 02:13:31] [EMAIL PROTECTED]
I use Win2K.I got this problem too. But after I updated to php 4.2.1
version, they are gone. It works well on php 4.2.1 (or higher version,
I guess).
Kae
[2002-12-12 09:03:48] [EMAIL PROTECTED]
Same problem - runing at the same time 2 systems:
On Windows NT 5.0 build 2195 PHP 4.1.1 on GMT zone:
echo (gmdate("U") . ""); //1039704601
echo (date ("U") . ""); //1039704601
echo (mktime() . ""); //1039704601
echo (gmmktime() . ""); //1039701001
echo (time() . ""); //1039704601
On Linux webdev 2.4.19 #1 PHP 4.2.2 on EDT zone:
echo (gmdate("U") . ""); //1039704601
echo (date ("U") . ""); //1039704601
echo (mktime() . ""); //1039704601
echo (gmmktime() . ""); //1039686601
echo (time() . ""); //1039704601
Peter
[2002-08-04 01:00:10] [EMAIL PROTECTED]
No feedback was provided for this bug for over a month, 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".
[2002-07-03 19:54:16] [EMAIL PROTECTED]
Could you please retry with a current snapshot or CVS-checkout? There
have been changes to mktime, so this problem might be already fixed in
CVS.
Please reopen the case if the problem persists.
Thanks for helping!
[2002-07-03 15:21:20] [EMAIL PROTECTED]
Here's a different perspective: I've been duplicating examples in
Python, Perl, Tcl, and PHP, thinking my next book may be full of such.
One of my examples converts between an ASCII GMT representation and the
local machine's seconds since the epoch. I did the example in the
other languages before trying PHP. Tcl works "out of the box". In
Python and Perl, I found ways of getting the gmt-to-local time
differential and used that differential to adjust the result produced
by mktime to create something similar to PHP's mktime. (It's not well
tested but doesn't have the bug PHP's mktime has. I get correct
results for daylight and nondaylight local times.) In PHP, I can't
find tools sufficient to calculate that time differential. HERE's THE
POINT: All these languages seem to rely on the same basic C library.
If it can be done using those C library tools (however indirectly) in
some of them it ought to be possible in all.
J Adrian Zimmer
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/14391
--
Edit this bug report at http://bugs.php.net/?id=14391&edit=1
#21594 [NEW]: import construct
From: [EMAIL PROTECTED] Operating system: all PHP version: 4.3.0 PHP Bug Type: Feature/Change Request Bug description: import construct could be interesting for OOP a java like import construct importing a selected file with syntax import "path/to/my_file.php"; which is the same of include / require but also import "path/to/my_lib/*"; that should import all php files in the directory. -- Edit bug report at http://bugs.php.net/?id=21594&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21594&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21594&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21594&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21594&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21594&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21594&r=support Expected behavior: http://bugs.php.net/fix.php?id=21594&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21594&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21594&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21594&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21594&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21594&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21594&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21594&r=gnused
#21540 [Fbk->Opn]: include_path problem
ID: 21540 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.3.0 New Comment: Yes, I have the following line in php.ini include_path= .:./:/usr/local/src/php-4.1.1/php-4.1.1/pear Previous Comments: [2003-01-10 16:37:59] [EMAIL PROTECTED] Do you have include_path specified in your php.ini? [2003-01-10 01:53:50] [EMAIL PROTECTED] I'm running Apache 1.3.27. I tried include_path both in httpd.conf and .htaccess. Problem existed in both cases. [2003-01-09 19:42:16] [EMAIL PROTECTED] Which Apache are you using and where are you specifying the include_path, httpd.conf (virtual host) or .htaccess? [2003-01-09 03:37:10] [EMAIL PROTECTED] It seems that include_path is not working correctly. When I try to include Mail.php from PEAR I get Warning: sendmail() [function.sendmail]: Failed opening 'Mail.php' for inclusion (include_path='./:/usr/local/src/php-4.3/pear;') in /usr/local/apache/www/htdocs/aircargo.idstudio.pl/funcs.php on line 6 Mail.php IS in directory /usr/local/src/php-4.3/pear My config: php_value include_path ./:/usr/local/src/php-4.3/pear Look at the error - there is ; at the end of include_path, but it is not in my server configuration. When I added another path at the end: php_value include_path ./:/usr/local/src/php-4.3/pear:. script started to work. I think that there is an typo somewhere in the code. -- Edit this bug report at http://bugs.php.net/?id=21540&edit=1
#21595 [NEW]: Overflow in Numeric types
From: [EMAIL PROTECTED] Operating system: Red Hat 7.2 PHP version: 4.3.0 PHP Bug Type: Variables related Bug description: Overflow in Numeric types Hello, I've seen a bugreport (Bug #21340 numerics can overflow php numeric datatypes ) and I have experienced it too with postgreSQL. Database IDs (varchar(24)) are interpreted as numbers, and lose information. f.e.: 20020101 is equal to 200201010001 () The patches I've found were bad, they didn't help. Values from a field larger than PHP's numerc types should be reported as srtings, not as numerics! Bye, Alex -- Edit bug report at http://bugs.php.net/?id=21595&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21595&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21595&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21595&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21595&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21595&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21595&r=support Expected behavior: http://bugs.php.net/fix.php?id=21595&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21595&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21595&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21595&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21595&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21595&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21595&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21595&r=gnused
#21596 [NEW]: Bundled GD-Lib 2.1 won't let JPGraph start up
From: [EMAIL PROTECTED] Operating system: Linux 7.3 PHP version: 4.3.0 PHP Bug Type: GD related Bug description: Bundled GD-Lib 2.1 won't let JPGraph start up - compile PHP 4.3.0 on Linux 7.3 with GD-Lib 2.7 installed via APXS against Apache 1.3.27 with the GD-option set, not specifying any directory -> installs the GD-Lib bundled with PHP 4.3.0 -> JPGraph doesn't give any output anymore (plainly won't start up at all, so no error messsage is generated) workaround: - compile PHP 4.3.0 on Linux 7.3 with GD-Lib 2.7 installed via APXS against Apache 1.3.27 with the GD-option set, specifying the GD-Lib 2.7 directory -> PHP 4.3.0 refers to GD-Lib 2.7 -> JPGraph works as usual Note: I use the GD 2.7 with the GIF-patch, but I don't think this would make any difference, since JPGraph won't start up at all with the bundled GD-Lib, and it is set to use png anyway. -- Edit bug report at http://bugs.php.net/?id=21596&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21596&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21596&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21596&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21596&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21596&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21596&r=support Expected behavior: http://bugs.php.net/fix.php?id=21596&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21596&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21596&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21596&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21596&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21596&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21596&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21596&r=gnused
#21598 [NEW]: mysql_fetch_field() segfaults
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 5CVS-2003-01-12 (dev) PHP Bug Type: Zend Engine 2 problem Bug description: mysql_fetch_field() segfaults Reproducing script: Stacktrace: php4ts_debug.dll!_object_and_properties_init(_zval_struct * arg=0x00b40420, _zend_class_entry * class_type=0x00b274f0, _hashtable * properties=0x, char * __zend_filename=0x102e40c0, unsigned int __zend_lineno=2118, void * * * tsrm_ls=0x00b22980) Line 603 + 0x13 C php4ts_debug.dll!_object_init_ex(_zval_struct * arg=0x00b40420, _zend_class_entry * class_type=0x00b274f0, char * __zend_filename=0x102e40c0, unsigned int __zend_lineno=2118, void * * * tsrm_ls=0x00b22980) Line 610 + 0x1bC php4ts_debug.dll!_object_init(_zval_struct * arg=0x00b40420, char * __zend_filename=0x102e40c0, unsigned int __zend_lineno=2118, void * * * tsrm_ls=0x00b22980) Line 615 + 0x1bC php4ts_debug.dll!zif_mysql_fetch_field(int ht=1, _zval_struct * return_value=0x00b40420, _zval_struct * this_ptr=0x, int return_value_used=0, void * * * tsrm_ls=0x00b22980) Line 2118 + 0x1d C php4ts_debug.dll!zend_do_fcall_common_helper(_zend_execute_data * execute_data=0x0012fafc, _zend_op_array * op_array=0x00b40388, void * * * tsrm_ls=0x00b22980) Line 2561 + 0x36 C php4ts_debug.dll!zend_do_fcall_handler(_zend_execute_data * execute_data=0x0012fafc, _zend_op_array * op_array=0x00b40388, void * * * tsrm_ls=0x00b22980) Line 2687 + 0x11 C php4ts_debug.dll!execute(_zend_op_array * op_array=0x00b40388, void * * * tsrm_ls=0x00b22980) Line 1213 + 0x13 C php4ts_debug.dll!zend_execute_scripts(int type=8, void * * * tsrm_ls=0x00b22980, _zval_struct * * retval=0x, int file_count=3, ) Line 958 + 0x21 C php4ts_debug.dll!php_execute_script(_zend_file_handle * primary_file=0x0012ff48, void * * * tsrm_ls=0x00b22980) Line 1691 + 0x1bC php.exe!main(int argc=1, char * * argv=0x00b22580) Line 1431 + 0x11C php.exe!mainCRTStartup() Line 338 + 0x11 C kernel32.dll!77e8ca90() -- Edit bug report at http://bugs.php.net/?id=21598&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21598&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21598&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21598&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21598&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21598&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21598&r=support Expected behavior: http://bugs.php.net/fix.php?id=21598&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21598&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21598&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21598&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21598&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21598&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21598&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21598&r=gnused
#21598 [Opn->Ver]: Apache processes don't clean up
ID: 21598 Updated by: [EMAIL PROTECTED] -Summary: mysql_fetch_field() segfaults -Reported By: [EMAIL PROTECTED] +Reported By: [EMAIL PROTECTED] -Status: Open +Status: Verified Bug Type: Zend Engine 2 problem -Operating System: Windows 2000 +Operating System: RHL7.3 -PHP Version: 5CVS-2003-01-12 (dev) +PHP Version: 4.3.0-pre2 Previous Comments: [2003-01-12 08:34:35] [EMAIL PROTECTED] Reproducing script: Stacktrace: php4ts_debug.dll!_object_and_properties_init(_zval_struct * arg=0x00b40420, _zend_class_entry * class_type=0x00b274f0, _hashtable * properties=0x, char * __zend_filename=0x102e40c0, unsigned int __zend_lineno=2118, void * * * tsrm_ls=0x00b22980) Line 603 + 0x13 C php4ts_debug.dll!_object_init_ex(_zval_struct * arg=0x00b40420, _zend_class_entry * class_type=0x00b274f0, char * __zend_filename=0x102e40c0, unsigned int __zend_lineno=2118, void * * * tsrm_ls=0x00b22980) Line 610 + 0x1bC php4ts_debug.dll!_object_init(_zval_struct * arg=0x00b40420, char * __zend_filename=0x102e40c0, unsigned int __zend_lineno=2118, void * * * tsrm_ls=0x00b22980) Line 615 + 0x1bC php4ts_debug.dll!zif_mysql_fetch_field(int ht=1, _zval_struct * return_value=0x00b40420, _zval_struct * this_ptr=0x, int return_value_used=0, void * * * tsrm_ls=0x00b22980) Line 2118 + 0x1dC php4ts_debug.dll!zend_do_fcall_common_helper(_zend_execute_data * execute_data=0x0012fafc, _zend_op_array * op_array=0x00b40388, void * * * tsrm_ls=0x00b22980) Line 2561 + 0x36 C php4ts_debug.dll!zend_do_fcall_handler(_zend_execute_data * execute_data=0x0012fafc, _zend_op_array * op_array=0x00b40388, void * * * tsrm_ls=0x00b22980) Line 2687 + 0x11 C php4ts_debug.dll!execute(_zend_op_array * op_array=0x00b40388, void * * * tsrm_ls=0x00b22980) Line 1213 + 0x13 C php4ts_debug.dll!zend_execute_scripts(int type=8, void * * * tsrm_ls=0x00b22980, _zval_struct * * retval=0x, int file_count=3, ) Line 958 + 0x21 C php4ts_debug.dll!php_execute_script(_zend_file_handle * primary_file=0x0012ff48, void * * * tsrm_ls=0x00b22980) Line 1691 + 0x1bC php.exe!main(int argc=1, char * * argv=0x00b22580) Line 1431 + 0x11C php.exe!mainCRTStartup() Line 338 + 0x11 C kernel32.dll!77e8ca90() -- Edit this bug report at http://bugs.php.net/?id=21598&edit=1
#18071 [Com]: unset($_SESSION['name']); not works when varible is readed before unset
ID: 18071 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Session related Operating System: win 2k, debian 2.2 PHP Version: 4.2.1 New Comment: i had the same problem!!! i spend a bloody long time to find what was wrong!!! so i'm still using session_unregister Previous Comments: [2002-09-11 11:31:16] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-08-15 18:17:30] [EMAIL PROTECTED] Please try a recent snapshot, of the non-stable kind. I believe Zeev just fixed this (at least your test case works for me). [2002-08-08 08:33:16] [EMAIL PROTECTED] Final note; we're currently running with register_globals on, while we migrate old code. It seems that this is the reason unset($_SESSION['varname']) won't work. But, the inconsistent behavior (you can assign to $_SESSION but not unset variables from it), is simply intolerable. Either both: $_SESSION['varname'] = 'value'; unset($_SESSION['varname']); work as intended, even with register globals on, or none of them should work. I would prefer them both to work because this will make it much easier to migrate old code while still running with register globals on. [2002-08-08 05:18:43] [EMAIL PROTECTED] unset.php should be the name you save the testscript as... [2002-08-07 15:45:01] [EMAIL PROTECTED] Your ([EMAIL PROTECTED]) sample script does not work for me. Results look like: session just after session_start() Array ( ) Next and the Next link unset.php doesn't exist. Can you finish your test case please? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18071 -- Edit this bug report at http://bugs.php.net/?id=18071&edit=1
#21587 [Com]: ob_gzhandler sending out empty pages
ID: 21587
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Zlib Related
Operating System: FreeBSD 4.6
PHP Version: 4.2.2
New Comment:
I can't upgrade PHP on my host's server but I did get someone to test
with PHP 4.3.0 on Linux and the problem was fixed, thanks.
Previous Comments:
[2003-01-11 23:12:59] [EMAIL PROTECTED]
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.
[2003-01-11 14:26:07] [EMAIL PROTECTED]
I have an obsolete PDA browser which doesn't support gz compressed
pages but sends out the following (unnecessary) header in it's HTTP
requests:
"Accept-Encoding: "
using ob_start("ob_gzhandler"); leads to the browser receiving empty
pages.
--
Edit this bug report at http://bugs.php.net/?id=21587&edit=1
#21587 [Bgs]: ob_gzhandler sending out empty pages
ID: 21587
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Zlib Related
Operating System: FreeBSD 4.6
-PHP Version: 4.2.2
+PHP Version: 4.3.0
New Comment:
If you want to let PHP automatically choose an appropreate encoding
scheme
by Accept-Encoding header that is sent by clients,
try zlib.output_compression directive instead of using ob_* stuff.
Not a php developer issue though.
Previous Comments:
[2003-01-12 10:06:33] [EMAIL PROTECTED]
I can't upgrade PHP on my host's server but I did get someone to test
with PHP 4.3.0 on Linux and the problem was fixed, thanks.
[2003-01-11 23:12:59] [EMAIL PROTECTED]
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.
[2003-01-11 14:26:07] [EMAIL PROTECTED]
I have an obsolete PDA browser which doesn't support gz compressed
pages but sends out the following (unnecessary) header in it's HTTP
requests:
"Accept-Encoding: "
using ob_start("ob_gzhandler"); leads to the browser receiving empty
pages.
--
Edit this bug report at http://bugs.php.net/?id=21587&edit=1
#21054 [Sus->Csd]: 'ob_gzhandler' cannot be used twice???
ID: 21054
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Suspended
+Status: Closed
Bug Type: Output Control
Operating System: Redhat 7.2
PHP Version: 4.3.0RC3
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
So than it is fixed in CVS -> closed
Previous Comments:
[2003-01-11 14:58:35] [EMAIL PROTECTED]
Now I have 4.4.0-dev (200301041230) and the problem seems to be
corrected, I don't see anymore this warning in logs.
BTW this is the output:
array(4) { ["output_buffering"]=> string(1) "1" ["output_handler"]=>
bool(false) ["zlib.output_compression"]=> string(0) ""
["zlib.output_handler"]=> string(0) "" }
[2003-01-11 11:41:09] [EMAIL PROTECTED]
To both of you: please execute the following script:
[2002-12-18 04:45:40] [EMAIL PROTECTED]
The same message appears if I place
in the begining of the any php script.
(W2kPro SP2, PHP4.3.0RC2, Apache 2.0.43)
[2002-12-16 15:56:49] [EMAIL PROTECTED]
It's a pretty useless bugreport like this. Suspended until you can
profile some real useful information to reproduce this problem.
[2002-12-16 15:52:45] [EMAIL PROTECTED]
I don't know if it's a particular script to cause the warning, the log
don't tell me anything
Other informations:
Apache: 2.0.43
PHP: 4.3.0RC3
Zend Optimizer: 2.0.3
Configure:
'./configure' '--enable-track-vars' '--prefix=/usr'
'--exec-prefix=/usr' '--libexecdir=/usr/lib/apache' '--bindir=/usr/bin'
'--sbindir=/usr/sbin' '--datadir=/home/httpd'
'--sysconfdir=/etc/httpd/conf' '--localstatedir=/var'
'--libdir=/usr/lib/apache' '--includedir=/usr/include/apache'
'--mandir=/usr/man' '--with-mysql=/usr'
'--with-config-file-path=/usr/local/Zend/etc' '--enable-memory-limit'
'--with-apxs2' '--with-zlib' '--disable-session'
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/21054
--
Edit this bug report at http://bugs.php.net/?id=21054&edit=1
#21579 [Fbk->Bgs]: freetype wont compile into php 4.3
ID: 21579 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Bogus Bug Type: GD related Operating System: linux PHP Version: 4.3.0 New Comment: When you installed the library correctly and experience the problem again feel free to open the bug. For now we suppose the erroneous library causing the problem. Previous Comments: [2003-01-11 12:32:56] [EMAIL PROTECTED] You really should compile/install that ft2 lib correctly first.. [2003-01-11 12:25:36] [EMAIL PROTECTED] #include #include FT_CONFIG_CONFIG_H #include FT_ERRORS_H #include FT_TYPES_H i had found ft2build.h in /usr/local/etc/freetype/include so i made a symlink to it but even that didnt work ? can i not reply via email what is [EMAIL PROTECTED] ? [2003-01-11 12:14:31] [EMAIL PROTECTED] 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. Thank you for your interest in PHP. [2003-01-11 11:33:03] [EMAIL PROTECTED] Please show the line 41 from your file: /usr/local/etc/freetype/include/freetype2/freetype/freetype.h [2003-01-11 05:33:42] [EMAIL PROTECTED] In file included from /usr/src/sources/php/php-4.3.0/ext/gd/libgd/gdft.c:49: /usr/local/etc/freetype/include/freetype2/freetype/freetype.h:41:22: ft2build.h: N o such file or directory here is the initial error thens spits out heaps of other gd errors which is too much to paste in, i cannot compile freetype in, but when i take it out php 4.3 compiled fine -- Edit this bug report at http://bugs.php.net/?id=21579&edit=1
#21590 [Bgs]: PHP 4.3.0 does not function
ID: 21590 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: PWS related Operating System: Windows 98 SE PHP Version: 4.3.0 New Comment: I wanted to make sure I wasn't experiencing a quirk of my PWS installation, so I uninstalled PWS and removed every reference to PHP in the registry and in the windows directory I could. I then reinstalled PWS. After verifying that PHP scripts did not run and were not recognized as any sort of script, I re-ran the PHP 4.3.0 installer. The result was the same: PHP files could not be executed as a web document, with the same error page. Simply replacing the php.exe and php4ts.dll with the 4.1.1 versions restored functionality. Previous Comments: [2003-01-11 23:09:51] [EMAIL PROTECTED] 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. Thank you for your interest in PHP. [2003-01-11 18:02:57] [EMAIL PROTECTED] What extensions are you loading? Did you copy the DLLs from the 4.3.0 installation package to your %SYSTEM%\ directory? (Note: the additional DLLs from your old 4.1.1 may not work with 4.3.0, hence copying the new DLLs) [2003-01-11 16:51:57] [EMAIL PROTECTED] I installed PHP 4.3.0 over 4.1.1 on a Win98SE machine running PWS. I installed using the installation program. After reinstall and reboot PHP scripts no longer functioned: the error was "Cannot find server" (and *not* the common server 500 error. it was the generic error for failing to even find a page.) I verified the installation process: The installer failed to add the correction "extension_dir" path line in the php.ini file. Correcting that did not fix the problem. I returned to the 4.1.1 version. It functions using either the php4ts.dll or the php.exe as the interpreter (set in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w3svc\parameters\Script Map registry key). It functions using either its php.ini file or the new one from the 4.3.0 installation. The 4.3.0 system will not work, using either the php4ts.dll or php.exe as the interpreter set in the registry. The php.exe file works properly if called from the shell (to parse a php file). But it fails whenever called by way of PWS, it seems. I have tried running the 4.3.0 installer twice, and I have manually installed 4.3.0 from the binaries. In all cases it fails. I can trivially reinstall 4.1.1 by replacing the 4.3.0 php.exe and php4ts.dll files with the 4.1.1 versions in my install directory. I am using the default PHP configuration, with the exception of placing the install files in c:\program files\PHP. I have not tried using the ISAPI dlls nor have I tried a different installation location. I couldn't find this reported in the database. Sincerely, David Fischer [EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=21590&edit=1
#21590 [Bgs]: PHP 4.3.0 does not function
ID: 21590 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: PWS related Operating System: Windows 98 SE PHP Version: 4.3.0 New Comment: "What extensions are you loading?" None "Did you copy the DLLs from the 4.3.0 installation package to your %SYSTEM%\ directory?" I tried that, but it didn't help. But from what I've read that seemed to be discouraged. Instead, the method is to use the registry key to "point" at the PHP binary. In my second attempt, I merely let the installer do its thing. I'll check the support sections. Perhaps not a problem with PHP per se, but it seems to be a problem with the Windows binaries and how they work with PWS on a Win98 system. Thanks. Previous Comments: [2003-01-12 12:34:21] [EMAIL PROTECTED] I wanted to make sure I wasn't experiencing a quirk of my PWS installation, so I uninstalled PWS and removed every reference to PHP in the registry and in the windows directory I could. I then reinstalled PWS. After verifying that PHP scripts did not run and were not recognized as any sort of script, I re-ran the PHP 4.3.0 installer. The result was the same: PHP files could not be executed as a web document, with the same error page. Simply replacing the php.exe and php4ts.dll with the 4.1.1 versions restored functionality. [2003-01-11 23:09:51] [EMAIL PROTECTED] 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. Thank you for your interest in PHP. [2003-01-11 18:02:57] [EMAIL PROTECTED] What extensions are you loading? Did you copy the DLLs from the 4.3.0 installation package to your %SYSTEM%\ directory? (Note: the additional DLLs from your old 4.1.1 may not work with 4.3.0, hence copying the new DLLs) [2003-01-11 16:51:57] [EMAIL PROTECTED] I installed PHP 4.3.0 over 4.1.1 on a Win98SE machine running PWS. I installed using the installation program. After reinstall and reboot PHP scripts no longer functioned: the error was "Cannot find server" (and *not* the common server 500 error. it was the generic error for failing to even find a page.) I verified the installation process: The installer failed to add the correction "extension_dir" path line in the php.ini file. Correcting that did not fix the problem. I returned to the 4.1.1 version. It functions using either the php4ts.dll or the php.exe as the interpreter (set in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w3svc\parameters\Script Map registry key). It functions using either its php.ini file or the new one from the 4.3.0 installation. The 4.3.0 system will not work, using either the php4ts.dll or php.exe as the interpreter set in the registry. The php.exe file works properly if called from the shell (to parse a php file). But it fails whenever called by way of PWS, it seems. I have tried running the 4.3.0 installer twice, and I have manually installed 4.3.0 from the binaries. In all cases it fails. I can trivially reinstall 4.1.1 by replacing the 4.3.0 php.exe and php4ts.dll files with the 4.1.1 versions in my install directory. I am using the default PHP configuration, with the exception of placing the install files in c:\program files\PHP. I have not tried using the ISAPI dlls nor have I tried a different installation location. I couldn't find this reported in the database. Sincerely, David Fischer [EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=21590&edit=1
#21592 [Opn->Fbk]: form submit and iso-8859-2
ID: 21592 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: RH 8.0 PHP Version: 4.3.0 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. Please provide an example which reproduces this error, also include any relevant httpd.conf/php.ini settings. Previous Comments: [2003-01-12 02:52:51] [EMAIL PROTECTED] When I submit a form (GET or POST), characters only in the iso-8859-2 charset (like õûÕÛ) are not converted from quoted-printable to their 1-character-long representations, instead they left unchanged like õ etc. I set the charset in the httpd.conf file, in the php.ini file, in the header of the html file and in the accept-charset attrib. of the form tag, but with no avail. I tried it in NN, Opera and IE. One more thing: sometimes it works correctly, but most of the time it doesn't. So strange enough! -- Edit this bug report at http://bugs.php.net/?id=21592&edit=1
#21312 [Opn]: session_register doesnt like null values
ID: 21312
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: Windows 2000 Server
PHP Version: 4.3.0
New Comment:
Is anyone taking a look at this? I just want to know how long I should
wait.
Sorry if this sounds impatient, it isnt meant to be. I am just
wondering. :)
Charles
Previous Comments:
[2003-01-03 10:38:26] [EMAIL PROTECTED]
Tryed that and still the same results.
[2003-01-03 10:22:52] [EMAIL PROTECTED]
Try adding this to your php.ini file:
session.bug_compat_42 = 1
session.bug_compat_warn = 0
[2003-01-01 12:19:47] [EMAIL PROTECTED]
i've the same problem with linux (apache 1.3.27) + mysql.
contents of nearly all variable are exchanged!
with a small function i had fixed this temporarly:
function dp_session_register($variable) {
global ${$variable};
if(is_null(${$variable}))
${$variable}="";
return session_register($variable);
}
i hope, this will fixed as soon as posible. thanks.
daniel prior
[2002-12-31 08:59:20] [EMAIL PROTECTED]
";
$sql_result = mssql_query($sql,$connection);
$num = mssql_num_rows($sql_result);
$retVal = "Records = ".$num;
if ($num > 0) {
mssql_data_seek($sql_result,0);
$row = mssql_fetch_object($sql_result);
$retVal = $row->Text;
}
mssql_free_result($sql_result);
echo $retVal;
?>
In this case the mssql_query fails with:
PHP Warning: mssql_query(): supplied argument is not a valid MS
SQL-Link resource.
if I simply comment the $source = $_SERVER... it succeeds.
If I change session_register to $_SESSION["source"] = $source; it
succeeds.
I am not sure how these are related.
What is even weirder is the echo "$sql $connection";
They echo what is expected when it works. When it doesnt whichever was
defined first is the value for both.
IE When it fails as it is written
select * from tbl_Texts; select * from tbl_Texts;
If you change
$connection = mssql_connect('server','UserName','password');
$sql = "select * from tbl;";
to
$sql = "select * from tbl;";
$connection = mssql_connect('server','UserName','password');
it echos
Resource id #3 Resource id #3
I will in the future use $_SESSION but there are alot of files to
change if this wont be fixed.
Thanks
Charles Killmer
--
Edit this bug report at http://bugs.php.net/?id=21312&edit=1
#21590 [Bgs]: PHP 4.3.0 does not function
ID: 21590 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: PWS related Operating System: Windows 98 SE PHP Version: 4.3.0 New Comment: I've got 4.3.0 to function and I believe I know the problem: the " cgi.force_redirect=0" must be active in the php.ini file. This was not set by the installer. It would likely save others time and frustration if the installer automatically set this. How could I submit this as a feature request for the installer people? Thanks. Previous Comments: [2003-01-12 12:39:38] [EMAIL PROTECTED] "What extensions are you loading?" None "Did you copy the DLLs from the 4.3.0 installation package to your %SYSTEM%\ directory?" I tried that, but it didn't help. But from what I've read that seemed to be discouraged. Instead, the method is to use the registry key to "point" at the PHP binary. In my second attempt, I merely let the installer do its thing. I'll check the support sections. Perhaps not a problem with PHP per se, but it seems to be a problem with the Windows binaries and how they work with PWS on a Win98 system. Thanks. [2003-01-12 12:34:21] [EMAIL PROTECTED] I wanted to make sure I wasn't experiencing a quirk of my PWS installation, so I uninstalled PWS and removed every reference to PHP in the registry and in the windows directory I could. I then reinstalled PWS. After verifying that PHP scripts did not run and were not recognized as any sort of script, I re-ran the PHP 4.3.0 installer. The result was the same: PHP files could not be executed as a web document, with the same error page. Simply replacing the php.exe and php4ts.dll with the 4.1.1 versions restored functionality. [2003-01-11 23:09:51] [EMAIL PROTECTED] 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. Thank you for your interest in PHP. [2003-01-11 18:02:57] [EMAIL PROTECTED] What extensions are you loading? Did you copy the DLLs from the 4.3.0 installation package to your %SYSTEM%\ directory? (Note: the additional DLLs from your old 4.1.1 may not work with 4.3.0, hence copying the new DLLs) [2003-01-11 16:51:57] [EMAIL PROTECTED] I installed PHP 4.3.0 over 4.1.1 on a Win98SE machine running PWS. I installed using the installation program. After reinstall and reboot PHP scripts no longer functioned: the error was "Cannot find server" (and *not* the common server 500 error. it was the generic error for failing to even find a page.) I verified the installation process: The installer failed to add the correction "extension_dir" path line in the php.ini file. Correcting that did not fix the problem. I returned to the 4.1.1 version. It functions using either the php4ts.dll or the php.exe as the interpreter (set in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w3svc\parameters\Script Map registry key). It functions using either its php.ini file or the new one from the 4.3.0 installation. The 4.3.0 system will not work, using either the php4ts.dll or php.exe as the interpreter set in the registry. The php.exe file works properly if called from the shell (to parse a php file). But it fails whenever called by way of PWS, it seems. I have tried running the 4.3.0 installer twice, and I have manually installed 4.3.0 from the binaries. In all cases it fails. I can trivially reinstall 4.1.1 by replacing the 4.3.0 php.exe and php4ts.dll files with the 4.1.1 versions in my install directory. I am using the default PHP configuration, with the exception of placing the install files in c:\program files\PHP. I have not tried using the ISAPI dlls nor have I tried a different installation location. I couldn't find this reported in the database. Sincerely, David Fischer [EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=21590&edit=1
#21599 [NEW]: should be in a block level element (XHTML and trans sid)
From: [EMAIL PROTECTED] Operating system: All PHP version: 4.3.0 PHP Bug Type: Session related Bug description: should be in a block level element (XHTML and trans sid) Bug reopened, see comments at http://bugs.php.net/bug.php?id=13472. -- Edit bug report at http://bugs.php.net/?id=21599&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21599&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21599&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21599&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21599&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21599&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21599&r=support Expected behavior: http://bugs.php.net/fix.php?id=21599&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21599&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21599&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21599&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21599&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21599&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21599&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21599&r=gnused
#21600 [NEW]: assign by reference function call changes variable contents
From: [EMAIL PROTECTED]
Operating system: Redhat 8
PHP version: 4.3.0
PHP Bug Type: Variables related
Bug description: assign by reference function call changes variable contents
under 4.3.0 with apache 2.0.40 I see this strange behavior with aliasing:
$foo = "Philip Johnson's \"Glass House\" remains one of the most famous
residences in the world.";
$foo =& bar($foo);
print $foo;
function bar($text){
return $text;
}
outputs: Philip Johnson's "Glass House" remains one of the most famous
residences in the worlh
This didn't happen under 4.2.3. Although really this was a mistake on my
part (I meant to do $foo = bar($foo)) it seems like strange behavior
nonetheless.
It's also strange to me that if I change
return $text;
to
return "$text";
it works as I would expect.
--
Edit bug report at http://bugs.php.net/?id=21600&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21600&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21600&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21600&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21600&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21600&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21600&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21600&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21600&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21600&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21600&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21600&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21600&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21600&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21600&r=gnused
#9852 [Com]: Header redirect and db connection cause "CGI misbehaved"
ID: 9852
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.2.1
New Comment:
We have chanced our PHP-Script from using ODBC to native MSSQL (using
the MSSQL library). The same error (incl. 502 Bad Gateway).
The next try was to change the server name to its IP address within the
connect statement - and it works!
No error since the change, running now over 14 days!
May be there is a problem (known under Windows systems) resolving the
server name?
Hope this helps a lot of PHP developers running Windows systems!
Theo
Previous Comments:
[2003-01-07 17:29:12] [EMAIL PROTECTED]
Just an idea: does it help to close the database connection right
before calling the header('Location: URL') function? I understand that
putting in a timer helps (most of the time), but I think that's a bit
of an ugly solution. I mean: how long should you wait? The ideal number
of microseconds to sleep depends on the server, the load on the server,
and so on. As the problem occurs when there is a database connection, I
wonder if it goes away if this connection is closed, before doing the
real redirecting. Sadly enough I can't test this myself, because I
don't have access to a server that's fast enough. Anyone?
[2002-12-28 19:08:25] [EMAIL PROTECTED]
We have posted this problem first at 2001-06-28 (ID# 11788). This
request was closed (Bogus) with the following comment:
Once and for all: It's not the lack of interest, it's the lack of good
developers with knowledge about it. Historically, OpenSource projects
operating in cross-platform environments have a stronger unix
developer
community. It's a fact.
I think, the best way for IIS-Users is, to develope there page under
ASP!
And for PHP you should say: running under all unix plattforms - but not
under IIS!
[2002-12-27 07:00:54] [EMAIL PROTECTED]
Good Afternoon,
I have seen many comments regarding PHP should be compliant with
enterprise software. I would suggest that it is - UNIX and Apache are
enterprise level solutions and PHP is a ROCK star on those platforms.
Just because we are no forcing it to do things on an AXX Backward
platform like MS W2k and XP is not a reason to complain.
I have run into the issue, because I am having to rewrite our
authentication scripts because the IIS CGI cannont handle a simple
authentication redirect. Before you blame PHP, try looking at all the
garbage hoops that IIS puts you through.
Nicolas
[2002-11-14 06:36:33] [EMAIL PROTECTED]
Just for your information:
Don't blame PHP. ASP.net ALSO SHOWS LOTS OF "CGI ERROR". I
solve this problem by slowing down connection -- do not put
src='xxx.php/asp' in your frame tag. use onload() handler
to load page into frames with javascript AFTER the frame
page is loaded.
[2002-10-29 14:00:20] [EMAIL PROTECTED]
I'm happy to hear that most people are able to solve their CGI errors
by changing the Windows Performance Options. We have Scott to thank for
this little trick!
Rasmus, I think what people are upset about is that this bug was
closed. It's obviously a Micro$haft problem (big surprise) but even so,
it's quite frustrating to feel like y'all don't give a dern :-( This
is obviously not the case but closing the bug makes people think that
you're not interested in finding a solution. Even if the problem is not
the fault of PHP.
On an unrelated note I'm *extremely happy* to see that you've included
the php_zip.dll extension in php-4.3.0pre2-Win32.zip. SWT!
Now all we need is a solid php4isapi.dll ;-)
Ottawa
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/9852
--
Edit this bug report at http://bugs.php.net/?id=9852&edit=1
#13472 [Csd->Opn]: input type=hidden should be in a fieldset if there is one (XHTML and trans sid)
ID: 13472 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Session related Operating System: Any -PHP Version: 4.2.0 +PHP Version: 4.3.0 New Comment: Opened again. Previous Comments: [2003-01-08 19:07:11] [EMAIL PROTECTED] so could anybody reopen this bug... or create a new one? [2003-01-08 17:07:06] [EMAIL PROTECTED] It looks like they fixed the openness of input tags, i.e. - the tags close like rather than but the hidden input field is still automatically inserted *outside* of a block-level element. It's a mistake to automatically force the hidden input field on us to begin with. Is there a way to turn JUST that part of the trans-id off? This bug is still very much a problem in 4.3 [2003-01-05 19:10:09] [EMAIL PROTECTED] is this really fixed? i have php 4.3 and php add the input tag directly after the form tag! the only _fix_ i found is a comment in the php.ini ; to URLs. If you want XHTML conformity, remove the form entry. [2002-12-03 23:00:43] [EMAIL PROTECTED] to: [EMAIL PROTECTED] is this bug fixed entirely? re: [3 Mar 8:08am] [EMAIL PROTECTED] Notice .. any blocklevel tag is affected .. not just fieldset and as such any solution to this problem should take this issue into account. [2002-09-25 06:11:46] [EMAIL PROTECTED] Fixed in 4.3 CVS. Thanks for your report. 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/13472 -- Edit this bug report at http://bugs.php.net/?id=13472&edit=1
#21599 [Opn->Bgs]: should be in a block level element (XHTML and trans sid)
ID: 21599 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Session related Operating System: All PHP Version: 4.3.0 New Comment: I've opened #13472 again. Previous Comments: [2003-01-12 14:54:21] [EMAIL PROTECTED] Bug reopened, see comments at http://bugs.php.net/bug.php?id=13472. -- Edit this bug report at http://bugs.php.net/?id=21599&edit=1
#21600 [Opn->Ver]: assign by reference function call changes variable contents
ID: 21600
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Verified
Bug Type: Variables related
Operating System: Redhat 8
PHP Version: 4.3.0
New Comment:
Verified with HEAD(ZE2) and PHP_4_3(ZE1).
The provided script causes segmentation fault.
Previous Comments:
[2003-01-12 15:07:10] [EMAIL PROTECTED]
under 4.3.0 with apache 2.0.40 I see this strange behavior with
aliasing:
$foo = "Philip Johnson's \"Glass House\" remains one of the most famous
residences in the world.";
$foo =& bar($foo);
print $foo;
function bar($text){
return $text;
}
outputs: Philip Johnson's "Glass House" remains one of the most famous
residences in the worlh
This didn't happen under 4.2.3. Although really this was a mistake on
my part (I meant to do $foo = bar($foo)) it seems like strange behavior
nonetheless.
It's also strange to me that if I change
return $text;
to
return "$text";
it works as I would expect.
--
Edit this bug report at http://bugs.php.net/?id=21600&edit=1
#21153 [Com]: readline won't be built as an external module
ID: 21153 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Readline related Operating System: Mandrake 9.0 PHP Version: 4.3.0RC4 New Comment: This looks to be related to readline includes in /usr/include and the actualy libraries being installed in /lib so they are available for applications such as bash during boot up when /usr may not be available. Previous Comments: [2003-01-07 12:57:20] [EMAIL PROTECTED] It does not work with: cd ext/readline;phpize;aclocal ./configure --with-readline [--SNIP--] checking for libedit readline replacement... yes, shared checking for readline support... yes, shared checking for tgetent in -lncurses... yes checking for readline in -lreadline... no configure: error: readline library not found The problem is it checks for tgetent in -lncurses, but it doesn't add the lib in the $LIBS variable. I have the GNU readline library, version 4.3 I managed to get it work, but then, it also insists on checking *both* readline and libedit. So I installed libedit, and the same problem with the -lncurses appeared. Seems to me someone should check the config.m4 [2002-12-22 19:29:40] [EMAIL PROTECTED] Hi. (sorry, this one was accidently also filed as #21152, I forgot to change the summary...) readline won't build as a external module. Here's my configure line that don't work: ./configure \ --prefix=/usr \ --exec-prefix=/usr \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --datadir=/usr/share \ --sysconfdir=/etc \ --libdir=/usr/lib \ --includedir=/usr/include \ --infodir=/usr/share/info \ --mandir=/usr/share/man \ --with-apxs2=/usr/sbin/apxs \ --enable-force-cgi-redirect \ --enable-discard-path \ --enable-debug \ --with-layout=GNU \ --with-config-file-path=/etc \ --with-config-file-scan-dir=/etc/httpd/conf.d \ --with-pear=/usr/lib/php \ --enable-safe-mode \ --with-exec-dir=/usr/bin \ --enable-magic-quotes \ --disable-rpath \ --with-openssl=shared,/usr --with-zlib=shared,/usr --with-zlib-dir=/usr \ --enable-bcmath=shared \ --with-bz2=shared,/usr \ --enable-calendar=shared \ --without-cpdflib \ --with-jpeg-dir=/usr \ --with-tiff-dir=/usr \ --without-crack \ --with-ctype=shared \ --with-curl=shared,/usr \ --without-cyrus \ --without-db \ --enable-dba=shared,/usr \ --with-gdbm=shared,/usr \ --without-ndbm \ --without-db2 \ --without-db3 \ --with-db4=shared,/usr \ --without-dbm \ --with-cdb=shared,/usr \ --with-flatfile=shared \ --enable-dbase=shared \ --enable-dbx=shared,/usr \ --enable-dio=shared,/usr \ --with-dom=shared,/usr --with-zlib-dir=/usr --with-dom-xslt=shared,/usr --with-dom-exslt=shared,/usr \ --enable-exif=shared \ --without-fbsql \ --without-fdftk \ --enable-filepro=shared \ --without-fribidi \ --enable-ftp=shared \ --with-gd=shared --with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/usr --with-xpm-dir=/usr/X11R6/lib/ \ --with-ttf=/usr \ --with-freetype-dir=/usr \ --with-t1lib=/usr \ --enable-gd-native-ttf \ --with-gettext=shared,/usr \ --with-gmp=shared,/usr \ --without-hwapi \ --without-hyperwave \ --without-iconv \ --with-imap=shared,/usr \ --without-kerberos \ --with-imap-ssl=shared,/usr \ --without-informix \ --without-ingres \ --without-interbase \ --without-ircg \ --with-ircg-config=/dev/null \ --without-java \ --with-ldap=shared,/usr \ --enable-mbstring=shared \ --enable-mbregex=shared \ --without-mcal \ --with-mcrypt=shared,/usr \ --without-mcve \ --with-mhash=shared,/usr \ --enable-mime-magic=shared \ --with-ming=shared,/usr \ --with-mnogosearch=shared,/usr \ --without-msession \ --without-msql \ --without-mssql \ --with-mysql=shared,/usr --with-mysql-sock=/var/lib/mysql/mysql.sock --with-zlib-dir=/usr \ --with-ncurses=shared,/usr \ --without-oci8 \ --without-adabas \ --without-sapdb \ --without-solid \ --without-ibm-db2 \ --without-empress \ --without-empress-bcs \ --without-birdstep \ --without-custom-odbc \ --without-iodbc \ --without-esoob \ --with-unixODBC=shared,/usr \ --without-openlink \ --without-dbmaker \ --without-oracle \ --enable-overload=shared \ --without-ovrimos \ --disable-pcntl \ --without-pcre-regex \ --with-pcre-regex=shared,/usr \ --without-pdflib --with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/usr --with-tiff-dir=/usr \ --with
#21602 [NEW]: Parser wont work after update
From: [EMAIL PROTECTED]
Operating system: suse 8.0
PHP version: 4.3.0
PHP Bug Type: Strings related
Bug description: Parser wont work after update
foreach ($urls as $k){
$start = '';
$online = strip_tags(implode(" ",@file($k)));
$trans = get_html_translation_table (HTML_ENTITIES);
foreach($trans as $key=>$var){
$story = str_replace($var,$key,$online);
}
$start = strpos($story,$keywords[$i])+strlen($keywords[$i]);
$uo[$i] = trim(substr($online,$start,3));
$i++;
}
i use this little script with php 4.2.2 to parse other web communities to
collect data inside a database who many users are online. After updating
the php version, this script produces with an array of four elements three
correct results and one trash result?
--
Edit bug report at http://bugs.php.net/?id=21602&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21602&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21602&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21602&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21602&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21602&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21602&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21602&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21602&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21602&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21602&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21602&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21602&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21602&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21602&r=gnused
#21602 [Opn->Fbk]: Parser wont work after update
ID: 21602
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Strings related
Operating System: suse 8.0
PHP Version: 4.3.0
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:
[2003-01-12 16:46:56] [EMAIL PROTECTED]
foreach ($urls as $k){
$start = '';
$online = strip_tags(implode(" ",@file($k)));
$trans = get_html_translation_table (HTML_ENTITIES);
foreach($trans as $key=>$var){
$story = str_replace($var,$key,$online);
}
$start = strpos($story,$keywords[$i])+strlen($keywords[$i]);
$uo[$i] = trim(substr($online,$start,3));
$i++;
}
i use this little script with php 4.2.2 to parse other web communities
to collect data inside a database who many users are online. After
updating the php version, this script produces with an array of four
elements three correct results and one trash result?
--
Edit this bug report at http://bugs.php.net/?id=21602&edit=1
#21603 [NEW]: snmp shared module crash the apache server when starts
From: [EMAIL PROTECTED] Operating system: Linux RedHat 8.0.92 PHP version: 4CVS-2003-01-12 (stable) PHP Bug Type: SNMP related Bug description: snmp shared module crash the apache server when starts Hi, all at php, I'm building rpms oh php-4.3.1 stable from 12 Jan 2003, httpd-2.0.40-15, on a RedHat 8.0.92, I built it succesfully a lot of packages, but the snmp module crash apache web server, but there is something very strange, it works on a server but in another don't,(is working on the server where I built it) here my ldd command on the server that is working..., there's not error log in apache [root@ecodevel root]# ldd /usr/lib/php4/snmp.so libsnmp.so.5 => /usr/lib/libsnmp.so.5 (0x4001c000) libc.so.6 => /lib/i686/libc.so.6 (0x4200) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) [root@ecodevel root]# here the ldd in the server that crash apache, both servers have the same redhat8.0.92.. [root@linux root]# ldd /usr/lib/php4/snmp.so libsnmp.so.5 => /usr/lib/libsnmp.so.5 (0x40009000) libc.so.6 => /lib/i686/libc.so.6 (0x4200) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000) [root@linux root]# As you see the number after libsnmp is different... Here my configure line... './configure' '--host=i686-pc-linux-gnu' '--build=i686-pc-linux-gnu' '--target=i686-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--prefix=/usr' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4' '--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext' '--with-pdflib=shared' '--with-tiff-dir=/usr' '--with-ncurses' '--with-gmp' '--with-iconv' '--enable-xslt=shared' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-ldap=shared' '--with-mcal=shared,/usr' '--with-mcrypt=shared,/usr' '--with-mhash=shared,/usr' '--with-mssql=shared,/usr' '--with-mysql=shared,/usr' '--with-pgsql=shared' '--with-snmp=shared,/usr' '--with-snmp=shared' '--with-xslt-sablot=shared,/usr' '--with-sablot-js=shared,/usr' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--with-apxs2=/usr/sbin/apxs' I hope it helps -- Edit bug report at http://bugs.php.net/?id=21603&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21603&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21603&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21603&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21603&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21603&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21603&r=support Expected behavior: http://bugs.php.net/fix.php?id=21603&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21603&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21603&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21603&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21603&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21603&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21603&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21603&r=gnused
#21102 [Com]: stat, lstat fail if filesize larger than 2 GB
ID: 21102 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: *Directory/Filesystem functions Operating System: solaris PHP Version: 4.4.0-dev New Comment: Current OS is Solaris 9u1, 64 bit kernel. Checking types.h and stat.h indicates that Solaris uses an off_t type for the stat structure. off_t is either a long, or a longlong_t, defined as long long. It seems to me that the stat structure in Solaris has the correct type. This is also indicated by the fact that I can use the stat(2) functions to stat the file in a simple C-program without any errors (and get the correct file size), Solaris does not have a shell stat command (AFAIK). Previous Comments: [2003-01-11 21:35:05] [EMAIL PROTECTED] What version of Solaris are you running? Many unixes (even current ones) use a signed int (32-bit) for the st_size element of the stat struct used by their c-library's stat() function. Try taking a look in stat.h and/or types.h if you'd like to confirm this on your local system. Does the stat command (from the shell) return sensible output when run against this file? [2003-01-11 20:49:47] [EMAIL PROTECTED] Updating -> 4.4.0-dev / open [2003-01-11 20:10:51] [EMAIL PROTECTED] [unable to edit bug report] latest CVS tarball does not fix the bug, example still fails with latest release. [2003-01-09 01:00:02] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, 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". [2002-12-22 00:55:50] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip 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/21102 -- Edit this bug report at http://bugs.php.net/?id=21102&edit=1
#21102 [Fbk->Ana]: stat, lstat to support 64 bit variants when available
ID: 21102 Updated by: [EMAIL PROTECTED] -Summary: stat, lstat fail if filesize larger than 2 GB Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Analyzed -Bug Type: *Directory/Filesystem functions +Bug Type: Feature/Change Request -Operating System: solaris +Operating System: any with large file support PHP Version: 4.4.0-dev New Comment: PHP does not support 64-bit stat'ing. Additionally, PHP only supports signed 32-bit integers (unless your CPU is 64-bit native). PHP could return large file sizes as floating point numbers, but the infrastructure for 64 bit stat is not in place at this time. I'm changing this to a feature request, as this is the "expected" behaviour. Previous Comments: [2003-01-12 18:22:29] [EMAIL PROTECTED] Current OS is Solaris 9u1, 64 bit kernel. Checking types.h and stat.h indicates that Solaris uses an off_t type for the stat structure. off_t is either a long, or a longlong_t, defined as long long. It seems to me that the stat structure in Solaris has the correct type. This is also indicated by the fact that I can use the stat(2) functions to stat the file in a simple C-program without any errors (and get the correct file size), Solaris does not have a shell stat command (AFAIK). [2003-01-11 21:35:05] [EMAIL PROTECTED] What version of Solaris are you running? Many unixes (even current ones) use a signed int (32-bit) for the st_size element of the stat struct used by their c-library's stat() function. Try taking a look in stat.h and/or types.h if you'd like to confirm this on your local system. Does the stat command (from the shell) return sensible output when run against this file? [2003-01-11 20:49:47] [EMAIL PROTECTED] Updating -> 4.4.0-dev / open [2003-01-11 20:10:51] [EMAIL PROTECTED] [unable to edit bug report] latest CVS tarball does not fix the bug, example still fails with latest release. [2003-01-09 01:00:02] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, 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". 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/21102 -- Edit this bug report at http://bugs.php.net/?id=21102&edit=1
#21604 [NEW]: variables can be dynamically added to a class, without it being defined.
From: [EMAIL PROTECTED]
Operating system: Windows 2000 Server
PHP version: 4.2.3
PHP Bug Type: Zend Engine 2 problem
Bug description: variables can be dynamically added to a class, without it being
defined.
If you run the following script and check the output, you will see the
that variable JUNK has been dynamically defined in the class X_Row() by
using the statement:
$user->query_row->JUNK = "stuff";
This behaviour certainly wasn't what I would expect.
---
query_row = new X_Row();
return;
}
}
class X_Row
{
var $USERNAME;
var $PASSWORD;
var $CHECKING;
function X_Row() {
$this->USERNAME = NULL;
$this->PASSWORD = NULL;
$this->CHECKING = NULL;
return;
} //end function X_Row
} //X_Row
$user = new X();
//$user->query_row is of class X_Row
//Therefore, the next statement should be valid,
//USERNAME has been declared in X_Row
$user->query_row->USERNAME = 'mtl';
//But the next statement shouldn't be
//because the variable JUNK has not
//been declared in the class
$user->query_row->JUNK = 'stuff';
$classname = get_class($user->query_row);
$classvars = get_class_vars($classname);
$query_row_class_vars = array_keys($classvars);
echo "classname:{$classname}";
echo "classvars:";
var_dump($classvars);
echo "query_row_class_vars";
var_dump($query_row_class_vars);
echo "HOW IS THIS POSSIBLE? SEE BELOW!";
echo "user->query_row:";
var_dump($user->query_row);
?>
--
Edit bug report at http://bugs.php.net/?id=21604&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21604&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21604&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21604&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21604&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21604&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21604&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21604&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21604&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21604&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21604&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21604&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21604&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21604&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21604&r=gnused
#21606 [NEW]: binary value not returned correctly
From: [EMAIL PROTECTED] Operating system: Linux Debian PHP version: 4.3.0 PHP Bug Type: LDAP related Bug description: binary value not returned correctly binary value which is kept in LDAP (like userCertificate or jpegPhoto attributes) not returned correctly when ldap_search call is made. In fact it returns only a few bytes of full attribute value. The problem is probably in some symbols in binary file which are cannot be exported by PHP so PHP simply breaks an export. Below is hex-dump of what is actually exported instead of full file: for jpegPhoto attribute: FF D8 FF 00 for userCertificate attribute: 30 82 03 68 30 82 03 0B A0 03 02 01 -- Edit bug report at http://bugs.php.net/?id=21606&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21606&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21606&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21606&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21606&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21606&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21606&r=support Expected behavior: http://bugs.php.net/fix.php?id=21606&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21606&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21606&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21606&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21606&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21606&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21606&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21606&r=gnused
#21607 [NEW]: output line to long
From: [EMAIL PROTECTED] Operating system: Solaris8 PHP version: 4.3.0 PHP Bug Type: Compile Failure Bug description: output line to long /bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 -L/usr/ucblib -L/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2 -R /usr/ucblib -R /opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2 ext/ctype/ctype.lo ext/mysql/php_mysql.lo ext/mysql/libmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo ext/mysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my_static.lo ext/mysql/libmysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo ext/mysql/libmysql/my_create.lo ext/mysql/libmysql/my_delete.lo ext/mysql/libmysql/my_tempnam.lo ext/mysql/libmysql/my_open.lo ext/mysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.lo ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/errors.lo ext/mysql/libmysql/my_error.lo ext/mysql/libmysql/my_getwd.lo ext/mysql/libmysql/my_div.lo ext/mysql/libmysql/mf_pack.lo ext/mysql/libmysql/my_messnc.lo ext/mysql/libmysql/mf_dirname.lo ext/mysql/libmysql/mf_fn_ext.lo ext/mysql/libmysql/mf_wcomp.lo ext/mysql/libmysql/typelib.lo ext/mysql/libmysql/safemalloc.lo ext/mysql/libmysql/my_alloc.lo ext/mysql/libmysql/mf_format.lo ext/mysql/libmysql/mf_path.lo ext/mysql/libmysql/mf_unixpath.lo ext/mysql/libmysql/my_fopen.lo ext/mysql/libmysql/mf_loadpath.lo ext/mysql/libmysql/my_pthread.lo ext/mysql/libmysql/my_thr_init.lo ext/mysql/libmysql/thr_mutex.lo ext/mysql/libmysql/mulalloc.lo ext/mysql/libmysql/string.lo ext/mysql/libmysql/default.lo ext/mysql/libmysql/my_compress.lo ext/mysql/libmysql/array.lo ext/mysql/libmysql/my_once.lo ext/mysql/libmysql/list.lo ext/mysql/libmysql/my_net.lo ext/mysql/libmysql/dbug.lo ext/mysql/libmysql/strmov.lo ext/mysql/libmysql/strxmov.lo ext/mysql/libmysql/strnmov.lo ext/mysql/libmysql/strmake.lo ext/mysql/libmysql/strend.lo ext/mysql/libmysql/strfill.lo ext/mysql/libmysql/is_prefix.lo ext/mysql/libmysql/int2str.lo ext/mysql/libmysql/str2int.lo ext/mysql/libmysql/strinstr.lo ext/mysql/libmysql/strcont.lo ext/mysql/libmysql/strcend.lo ext/mysql/libmysql/bchange.lo ext/mysql/libmysql/bmove.lo ext/mysql/libmysql/bmove_upp.lo ext/mysql/libmysql/longlong2str.lo ext/mysql/libmysql/strtoull.lo ext/mysql/libmysql/strtoll.lo ext/mysql/libmysql/charset.lo ext/mysql/libmysql/ctype.lo ext/overload/overload.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo ext/standard/versioning.lo ext/standard/assert.lo ext/standard/strnatcmp.lo ext/standard/levenshtein.lo ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo ext/standard/css.lo ext/standard/var_unserializer.lo ext/standard/ftok.lo ext/standard/aggregation.lo ext/standard/sha1.lo ext/tokenizer/tokenizer.lo ext/xml/xml.lo ext/xml/expat/xmlparse.lo ext/xml/expat/xmlrole.lo ext/xml/expat/xmltok.lo regex/regcomp.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo TSRM/TSRM.lo TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo main/fopen_wrappers.lo main/alloca.lo main/php_ini.lo main/SAPI.lo main/rfc1867.lo main/php_content_types.lo main/strlcpy.lo main/strlcat.lo main/mergesort.lo main/reentrancy.lo main/php_variables.lo main/php_ticks.lo main/streams.lo main/network.lo main/php_open_temporary_file.lo main/php_logos.lo main/output.lo main/memory_streams.lo main/user_streams.lo Zend/zend_language_parser.lo Zend/zend_language_scanner.lo Zend/zend_ini_parser.lo Zend/zend_ini_scanner.lo Zend/zend_alloc.lo Zend/zend_compile.lo Zend/zend_constants.lo Zend/zend_dyna
#21127 [Fbk->NoF]: CSRSS.exe 100%
ID: 21127 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Performance problem Operating System: Windows XP PHP Version: 4.3.0RC3 New Comment: No feedback was provided for this bug for over 2 weeks, 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". Previous Comments: [2002-12-28 13:31:54] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-20 22:17:54] [EMAIL PROTECTED] Whenever someone uploads to my FTP server, I use PHP to execute my scripts. Now, although I haven't pinpointed the problem yet, it seems like PHP is causing CSRSS.exe (Windows' client/server runtime server subsystem), a system process, to jump up to 100% CPU usage. I'll try looking into the problem in more detail, but I just thought I'd post this up for now. -- Edit this bug report at http://bugs.php.net/?id=21127&edit=1
#21206 [Fbk->NoF]: nesting level and recursive errors on make test... php fails
ID: 21206 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Compile Failure Operating System: RH Linux 7.2 PHP Version: 4.3.0RC4 New Comment: No feedback was provided for this bug for over 2 weeks, 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". Previous Comments: [2002-12-28 01:24:16] [EMAIL PROTECTED] The failed test was incorrect and is no longer present in 4.3.0. The other problem maybe due to the fact that your php.ini directives tell php to load shared extensions that are now either compiled into PHP core or were compiled for previous versions. This could resolve in all kinds of erroneous behaviour. Check your php.ini for the extensions you load dynamically and try to determine which one (or more) is reponsible. [2002-12-28 01:21:40] [EMAIL PROTECTED] I've also experienced this problem with the release version of PHP 4.3.0 on Redhat 7.2 My configure string is as follows './configure' 'i386-redhat-linux' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--prefix=/usr' '--with-config-file-path=/etc' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db3' '--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext=shared' '--with-ncurses' '--with-gmp' '--with-iconv-dir=/usr' '--with-jpeg-dir=/usr' '--with-openssl' '--with-pear' '--with-png' '--with-pspell-dir=/usr' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-debugger' '--enable-exif' '--enable-ftp=shared' '--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem=shared' '--enable-sysvshm=shared' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--without-oci8' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-ldap=shared' '--with-mysql=/usr' '--with-pgsql=shared' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring' '--enable-mbstr-enc-trans' '--disable-experimental-zts' '--with-apxs=/usr/sbin/apxs' [2002-12-26 19:54:03] [EMAIL PROTECTED] Well I have also tried using 4.4.0-dev and same issue. Now if I delete or move my original php.ini file and run I get one error still and it causes the same problem. If I install it any site using php fails. The error i get using make test if I delete the php.ini file is = FAILED TEST SUMMARY - Bug #20993 (referenced array key, makes array global) [tests/lang/bug20993.phpt] = [2002-12-26 17:31:57] [EMAIL PROTECTED] Warning: Nesting level too deep - recursive dependency? in Unknown on line 0 That error shows several times during the make test part of the install. During the install the ./configure... and make does ok with no errors. Then doing a make test fails on almost every test it performs. If I continue to do a make install afterwards it breaks the server down so that most to all sites using php do not work. I have verified this with the latest stable release, 4.3.0-dev, 4.3.0RC2, 4.3.0RC3, and now 4.3.0RC4. Right now I am running 4.2.4-dev and is working fine. I have also tried a few different configure commands to hopefully resolve this issue but with no luck. Current configure... './configure' 'i386-redhat-linux' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--prefix=/usr' '--with-config-file-path=/etc' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disa
#21231 [Fbk->NoF]: ./configure fails on cURL check
ID: 21231 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Compile Failure Operating System: Linux - Red Hat 7.3 PHP Version: 4.3.0 New Comment: No feedback was provided for this bug for over 2 weeks, 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". Previous Comments: [2002-12-28 05:19:20] [EMAIL PROTECTED] Check also config.log which may have some information on why the check failed... Derick [2002-12-28 01:14:53] [EMAIL PROTECTED] I have no trouble compiling PHP 4.3 against curl 7.10.2, it is possible that curl library is not in the path or the path you've specified is incorrect. Try putting the output of 'curl-config --prefix' as the value for --with-curl. Ex: --with-curl=`curl-config --prefix [2002-12-27 22:17:57] [EMAIL PROTECTED] Successfully obtained the PHP 4.3.0 release from anonymous CVS. ./buildconf ran successfully, however, ./configure fails with the following error: "checking for cURL 7.9.8 or greater... configure: error: cURL version 7.9.8 or later is required to compile php with cURL support" I updated cURL with the latest version (7.10.2) as evidenced by: "[root@server php4]# curl -V curl 7.10.2 (i686-pc-linux-gnu) libcurl/7.10.2 OpenSSL/0.9.6b zlib/1.1.3" however, I still get the error when attempting to run ./configure. -- Edit this bug report at http://bugs.php.net/?id=21231&edit=1
#21607 [Opn->Bgs]: output line to long
ID: 21607 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Solaris8 PHP Version: 4.3.0 New Comment: Due to a bug in the installed sed on your system the build fails. Install GNU sed and it should be okay. Thank you for your interest in PHP. Previous Comments: [2003-01-13 00:58:50] [EMAIL PROTECTED] /bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 -L/usr/ucblib -L/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2 -R /usr/ucblib -R /opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2 ext/ctype/ctype.lo ext/mysql/php_mysql.lo ext/mysql/libmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo ext/mysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my_static.lo ext/mysql/libmysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo ext/mysql/libmysql/my_create.lo ext/mysql/libmysql/my_delete.lo ext/mysql/libmysql/my_tempnam.lo ext/mysql/libmysql/my_open.lo ext/mysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.lo ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/errors.lo ext/mysql/libmysql/my_error.lo ext/mysql/libmysql/my_getwd.lo ext/mysql/libmysql/my_div.lo ext/mysql/libmysql/mf_pack.lo ext/mysql/libmysql/my_messnc.lo ext/mysql/libmysql/mf_dirname.lo ext/mysql/libmysql/mf_fn_ext.lo ext/mysql/libmysql/mf_wcomp.lo ext/mysql/libmysql/typelib.lo ext/mysql/libmysql/safemalloc.lo ext/mysql/libmysql/my_alloc.lo ext/mysql/libmysql/mf_format.lo ext/mysql/libmysql/mf_path.lo ext/mysql/libmysql/mf_unixpath.lo ext/mysql/libmysql/my_fopen.lo ext/mysql/libmysql/mf_loadpath.lo ext/mysql/libmysql/my_pthread.lo ext/mysql/libmysql/my_thr_init.lo ext/mysql/libmysql/thr_mutex.lo ext/mysql/libmysql/mulalloc.lo ext/mysql/libmysql/string.lo ext/mysql/libmysql/default.lo ext/mysql/libmysql/my_compress.lo ext/mysql/libmysql/array.lo ext/mysql/libmysql/my_once.lo ext/mysql/libmysql/list.lo ext/mysql/libmysql/my_net.lo ext/mysql/libmysql/dbug.lo ext/mysql/libmysql/strmov.lo ext/mysql/libmysql/strxmov.lo ext/mysql/libmysql/strnmov.lo ext/mysql/libmysql/strmake.lo ext/mysql/libmysql/strend.lo ext/mysql/libmysql/strfill.lo ext/mysql/libmysql/is_prefix.lo ext/mysql/libmysql/int2str.lo ext/mysql/libmysql/str2int.lo ext/mysql/libmysql/strinstr.lo ext/mysql/libmysql/strcont.lo ext/mysql/libmysql/strcend.lo ext/mysql/libmysql/bchange.lo ext/mysql/libmysql/bmove.lo ext/mysql/libmysql/bmove_upp.lo ext/mysql/libmysql/longlong2str.lo ext/mysql/libmysql/strtoull.lo ext/mysql/libmysql/strtoll.lo ext/mysql/libmysql/charset.lo ext/mysql/libmysql/ctype.lo ext/overload/overload.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo ext/standard/versioning.lo ext/standard/assert.lo ext/standard/strnatcmp.lo ext/standard/levenshtein.lo ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo ext/standard/css.lo ext/standard/var_unserializer.lo ext/standard/ftok.lo ext/standard/aggregation.lo ext/standard/sha1.lo ext/tokenizer/tokenizer.lo ext/xml/xml.lo ext/xml/expat/xmlparse.lo ext/xml/expat/xmlrole.lo ext/xml/expat/xmltok.lo regex/regcomp.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo TSRM/TSRM.lo TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo main/fopen_wrappers.lo main/alloca.lo main/php_ini.lo main/SAPI.lo main/rfc1867.lo main/php_content_types.lo main/strlcpy.lo main/strlcat.lo main/mergesort.lo main/reentrancy.l
#21600 [Ver]: assign by reference function call changes variable contents
ID: 21600
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Verified
-Bug Type: Variables related
+Bug Type: Scripting Engine problem
Operating System: Redhat 8
PHP Version: 4.3.0
New Comment:
backtrace (with php-5.0.0-dev):
#0 0x40749e49 in __sbrk (increment=1515880448) at
../sysdeps/generic/sbrk.c:33
#1 0x406e9d3c in __default_morecore (increment=1515880448)
at ../sysdeps/generic/morecore.c:47
#2 0x406e676d in chunk_alloc (ar_ptr=0x40798520, nb=1515878480)
at malloc.c:2583
#3 0x406e60bc in __libc_malloc (bytes=1515878476) at malloc.c:2817
#4 0x08256b63 in zend_mm_add_memory_block (heap=0x8333748,
block_size=1515878476) at
/dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:143
#5 0x08256de6 in zend_mm_alloc (heap=0x8333748, size=1515878448)
at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:236
#6 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448)
at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240
#7 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448)
at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240
#8 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448)
at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240
#9 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448)
at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240
#10 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448)
at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240
#11 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448)
at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240
#12 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448)
(last frame continues atleast 15.000 times)
Derick
Previous Comments:
[2003-01-12 15:56:50] [EMAIL PROTECTED]
Verified with HEAD(ZE2) and PHP_4_3(ZE1).
The provided script causes segmentation fault.
[2003-01-12 15:07:10] [EMAIL PROTECTED]
under 4.3.0 with apache 2.0.40 I see this strange behavior with
aliasing:
$foo = "Philip Johnson's \"Glass House\" remains one of the most famous
residences in the world.";
$foo =& bar($foo);
print $foo;
function bar($text){
return $text;
}
outputs: Philip Johnson's "Glass House" remains one of the most famous
residences in the worlh
This didn't happen under 4.2.3. Although really this was a mistake on
my part (I meant to do $foo = bar($foo)) it seems like strange behavior
nonetheless.
It's also strange to me that if I change
return $text;
to
return "$text";
it works as I would expect.
--
Edit this bug report at http://bugs.php.net/?id=21600&edit=1
