#27474 [Bgs->Csd]: w32api_register_function missed in newer version php?
ID: 27474
User updated by: azsd at hotmail dot com
Reported By: azsd at hotmail dot com
-Status: Bogus
+Status: Closed
Bug Type: Win32API related
Operating System: Windows2003
PHP Version: 4.3.4
New Comment:
sorry.
close it and wishes new entry add to manual.
Previous Comments:
[2004-03-07 01:01:55] azsd at hotmail dot com
I am sorry,I have wrong point.
In 4.3.4 the win32apu extensions changes to Win32::RegisterFunction,
It's old version in php manual so that confused most new guys like me.
Suggust add this Win32::RegisterFunction description entry to old
w32api_register_function page in manual.
thx
[2004-03-06 01:35:12] azsd at hotmail dot com
I am sure it's php_w32api.dll's error now.
May be win32api.dsp settings mistake.
hope it can fix in next release of PHP.
[2004-03-06 01:25:39] azsd at hotmail dot com
er
why problemes still exists in newst cvs.
I think the problem occured in php_w32api.dll.
may be it havent contain function strings to getmodual.
strange things other extension dlls are release version,
except php_w32api.dll were debug version,may be some codes are
commented using macro in debug compiler environment?
I am a pascal code,I am hardly trying to find where the bugs in code
now.
[2004-03-03 04:02:17] azsd at hotmail dot com
thanks your reply,Dear sir
mmm,in ISAPI mode dl() been disabled automaticly.
surely I setted the extension_dir,other extensions like
GDlib,Zip,Sockets all works fine.
this condition once comes in 4.2.0 RC2,and fixed on CVS by developers,
Right now it comes back.
Is that mean-es someone who always use some part code earlier(than that
fix) version to rewrited the fixed codes??
I am not much know CVS,:P
[2004-03-03 02:52:47] [EMAIL PROTECTED]
The php_w32api.dll extension must be loaded in php.ini:
extension=php_w32api.dll
(check that extension_dir is correct)
or using dl('php_w32api.dll')
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/27474
--
Edit this bug report at http://bugs.php.net/?id=27474&edit=1
#27474 [Bgs]: w32api_register_function missed in newer version php?
ID: 27474
User updated by: azsd at hotmail dot com
Reported By: azsd at hotmail dot com
Status: Bogus
Bug Type: Win32API related
Operating System: Windows2003
PHP Version: 4.3.4
New Comment:
I am sorry,I have wrong point.
In 4.3.4 the win32apu extensions changes to Win32::RegisterFunction,
It's old version in php manual so that confused most new guys like me.
Suggust add this Win32::RegisterFunction description entry to old
w32api_register_function page in manual.
thx
Previous Comments:
[2004-03-06 01:35:12] azsd at hotmail dot com
I am sure it's php_w32api.dll's error now.
May be win32api.dsp settings mistake.
hope it can fix in next release of PHP.
[2004-03-06 01:25:39] azsd at hotmail dot com
er
why problemes still exists in newst cvs.
I think the problem occured in php_w32api.dll.
may be it havent contain function strings to getmodual.
strange things other extension dlls are release version,
except php_w32api.dll were debug version,may be some codes are
commented using macro in debug compiler environment?
I am a pascal code,I am hardly trying to find where the bugs in code
now.
[2004-03-03 04:02:17] azsd at hotmail dot com
thanks your reply,Dear sir
mmm,in ISAPI mode dl() been disabled automaticly.
surely I setted the extension_dir,other extensions like
GDlib,Zip,Sockets all works fine.
this condition once comes in 4.2.0 RC2,and fixed on CVS by developers,
Right now it comes back.
Is that mean-es someone who always use some part code earlier(than that
fix) version to rewrited the fixed codes??
I am not much know CVS,:P
[2004-03-03 02:52:47] [EMAIL PROTECTED]
The php_w32api.dll extension must be loaded in php.ini:
extension=php_w32api.dll
(check that extension_dir is correct)
or using dl('php_w32api.dll')
[2004-03-02 23:04:17] azsd at hotmail dot com
by the way,I downloaded new CVS version Built On: Mar 03, 2004 01:30
GMT,It always has same error results.
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/27474
--
Edit this bug report at http://bugs.php.net/?id=27474&edit=1
#27512 [Fbk->Opn]: Apache 1.3.29 crashes when loading extensions
ID: 27512 User updated by: jl at lusidor dot nu Reported By: jl at lusidor dot nu -Status: Feedback +Status: Open Bug Type: Apache related Operating System: Win XP pro PHP Version: 5.0.0b4 (beta4) New Comment: I tried latest but it crashes even without any extensions loaded in php.ini. http://snaps.php.net/win32/php5-win32-latest.zip Anything else I can test? I'd be happy to supply you with any data you might need, just mail me. Previous Comments: [2004-03-06 13:38:01] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2004-03-06 07:13:29] jl at lusidor dot nu I forgot to mention that without any extensions enabled apache runs without any problems. [2004-03-06 07:11:40] jl at lusidor dot nu Description: I'm on windows xp. I'm trying to load extensions with apache 1.3.29. I enable the extension in the php.ini. That causes apache to crash after 3 seconds without any notice in the error-log. When I try to run PHP5 by it self it loads the extension just fine. according to phpinfo. I have the following setup: /php5 (php5 directory) /program/apache-php5 (apache dir with php.ini, php5apache.dll, php5ts.dll) php.ini with the following changes include_path = ".;\php5\includes" ;extension_dir = ".\" (I've tried both) extension_dir = "\php5\ext\" extension=php_mhash.dll I've tried placing the libmhash.dll in every possible location, /windows/system32, /program/apache-php5 and /php5 dir to no avail. I have a similiar setup where I run PHP 4.3.4 as an apache mod with the identical setup loads just fine. So I see this as a bug related to running PHP5 b4 as an apache module. Reproduce code: --- Just start apache. It crashes within about 6 seconds -- Edit this bug report at http://bugs.php.net/?id=27512&edit=1
#27515 [NEW]: php -b still not working
From: verdy_p at wanadoo dot fr Operating system: Windows PHP version: 4.3.4 PHP Bug Type: CGI related Bug description: php -b still not working Description: I know this bug has already been submitted, but as it has been closed multiple times and developers only look at open bugs, they don't see this one which affects the current LATEST stable version of PHP for Windows, both in the installer version and in the manually installed ZIP file. When will FastCGI work on Windows? Why is it said to have been fixed when "php -b" is simply not supported. C:\> php\php -v PHP 4.3.4 (cgi-fcgi) (built: Nov 2 2003 23:47:22) Copyright (c) 1997-2003 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies Expected result: FastCGI is the MOST important SAPI for PHP, the MSOT secure, the fastest and the one chosen by almost all ISPs for these reasons, notably because of the complete separation from the web server, and the possibility to run it on multiple hosts working in parallel for a cluster of webservers. Please enable it on a stable version. Or at least come back to the latest stable version and branch it to include the needed fix for options, and recreate the distributions for Windows (ZIP and installer). Then make sure the fix is applied in the next release by looking at release candidate branches, so that the fix is not forgotten! Actual result: -- C:\> php\php -b 127.0.0.1:6000 Error in argument 1, char 2: option not found b Usage: php [-q] [-h] [-s] [-v] [-i] [-f ] php [args...] -a Run interactively -b | Bind Path for external FASTCGI Server mode -C Do not chdir to the script's directory -c | Look for php.ini file in this directory -n No php.ini file will be used -d foo[=bar] Define INI entry foo with value 'bar' -e Generate extended information for debugger/profiler -f Parse . Implies `-q' -h This help -i PHP information -l Syntax check only (lint) -m Show compiled in modules -q Quiet-mode. Suppress HTTP Header output. -s Display colour syntax highlighted source. -v Version number -w Display source with stripped comments and whitespace. -z Load Zend extension . -- Edit bug report at http://bugs.php.net/?id=27515&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27515&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27515&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27515&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27515&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27515&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27515&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27515&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27515&r=support Expected behavior: http://bugs.php.net/fix.php?id=27515&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27515&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27515&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27515&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27515&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27515&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27515&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27515&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27515&r=float
#26039 [Com]: -b listed in the available options under win32
ID: 26039 Comment by: verdy_p at wanadoo dot fr Reported By: ken dot davis at experioronline dot com Status: Closed Bug Type: CGI related Operating System: windows 2000 PHP Version: 4.3.4RC3 New Comment: Still not fixed in the last stable version: PHP 4.3.4 (cgi-fcgi) (built: Nov 2 2003 23:47:22) -b is said to be supported, and the release notes say that FastCGI has been fixed to work on Win32, but it does not! Now 4 months later, it is still not fixed... When will be the next stable correction? I mean even before PHP5 gets released... For now people still need to use a "stable" version but they cannot use it on Windows without fixing the bug in optstring, i.e. by compiling it. The Release notes are still wrong as people think it works in PHP 4.3.4 when it does not. Which precompiled version for Windows as this bug corrected? Previous Comments: [2003-10-30 20:27:34] [EMAIL PROTECTED] Ah, I see. Fixed in CVS now. (the option is not shown anymore) [2003-10-30 15:06:31] ken dot davis at experioronline dot com I did php -h and it returned: Usage: php [-q] [-h] [-s] [-v] [-i] [-f ] php [args...] -a Run interactively -b | Bind Path for external FASTCGI Server mode -C Do not chdir to the script's directory -c | Look for php.ini file in this directory -n No php.ini file will be used -d foo[=bar] Define INI entry foo with value 'bar' -e Generate extended information for debugger/profiler -f Parse . Implies `-q' -h This help -i PHP information -l Syntax check only (lint) -m Show compiled in modules -q Quiet-mode. Suppress HTTP Header output. -s Display colour syntax highlighted source. -v Version number -w Display source with stripped comments and whitespace. -z Load Zend extension . This is the same as the usage info returned after the error message. [2003-10-30 13:57:56] [EMAIL PROTECTED] doing 'php -h' would have shown that such option really does not exist. (It doesn't exist under win32) [2003-10-30 08:55:51] ken dot davis at experioronline dot com Description: using the win32 binary php -b localhost:8080 returns: Error in argument 1, char 2: option not found b along with usage information which includes: -b | Bind Path for external FASTCGI Server mode php -v returns: PHP 4.3.4RC3 (cgi-fcgi) (built: Oct 29 2003 14:56:30) looking at previous bugs and news.txt it seems this should have been fixed. Reproduce code: --- d:\php\php-4.3.4RC3-Win32\php -b localhost:8080 Expected result: php running in fastcgi server mode on port 8080 Actual result: -- Error in argument 1, char 2: option not found b -- Edit this bug report at http://bugs.php.net/?id=26039&edit=1
#21303 [Com]: FastCGI Support
ID: 21303 Comment by: verdy_p at wanadoo dot fr Reported By: fserb at terra dot com dot br Status: Bogus Bug Type: *General Issues Operating System: WinXP PHP Version: 4.3.0 New Comment: Still not fixed in PHP 4.3.4 ! At least in the latest stable version for Win32 (both e installer version, and the manually installed ZIP version) C:\> php\php -b 6000 Error in argument 1, char 2: option not found b Usage: php [-q] [-h] [-s] [-v] [-i] [-f ] php [args...] -a Run interactively -b | Bind Path for external FASTCGI Server mode -C Do not chdir to the script's directory -c | Look for php.ini file in this directory -n No php.ini file will be used -d foo[=bar] Define INI entry foo with value 'bar' -e Generate extended information for debugger/profiler -f Parse . Implies `-q' -h This help -i PHP information -l Syntax check only (lint) -m Show compiled in modules -q Quiet-mode. Suppress HTTP Header output. -s Display colour syntax highlighted source. -v Version number -w Display source with stripped comments and whitespace. -z Load Zend extension . C:\> php\php -b 127.0.0.1:6000 Error in argument 1, char 2: option not found b Usage: php [-q] [-h] [-s] [-v] [-i] [-f ] php [args...] -a Run interactively -b | Bind Path for external FASTCGI Server mode -C Do not chdir to the script's directory -c | Look for php.ini file in this directory -n No php.ini file will be used -d foo[=bar] Define INI entry foo with value 'bar' -e Generate extended information for debugger/profiler -f Parse . Implies `-q' -h This help -i PHP information -l Syntax check only (lint) -m Show compiled in modules -q Quiet-mode. Suppress HTTP Header output. -s Display colour syntax highlighted source. -v Version number -w Display source with stripped comments and whitespace. -z Load Zend extension . C:\> php\php -v PHP 4.3.4 (cgi-fcgi) (built: Nov 2 2003 23:47:22) Copyright (c) 1997-2003 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies Please fix it! FastCGI cannot work without it! Previous Comments: [2004-03-06 17:32:44] verdy_p at wanadoo dot fr Still not fixed in PHP 4.3.4 ! At least in the latest stable version for Win32 (both e installer version, and the manually installed ZIP version) C:\> php\php -b 6000 Error in argument 1, char 2: option not found b Usage: php [-q] [-h] [-s] [-v] [-i] [-f ] php [args...] -a Run interactively -b | Bind Path for external FASTCGI Server mode -C Do not chdir to the script's directory -c | Look for php.ini file in this directory -n No php.ini file will be used -d foo[=bar] Define INI entry foo with value 'bar' -e Generate extended information for debugger/profiler -f Parse . Implies `-q' -h This help -i PHP information -l Syntax check only (lint) -m Show compiled in modules -q Quiet-mode. Suppress HTTP Header output. -s Display colour syntax highlighted source. -v Version number -w Display source with stripped comments and whitespace. -z Load Zend extension . C:\> php\php -b 127.0.0.1:6000 Error in argument 1, char 2: option not found b Usage: php [-q] [-h] [-s] [-v] [-i] [-f ] php [args...] -a Run interactively -b | Bind Path for external FASTCGI Server mode -C Do not chdir to the script's directory -c | Look for php.ini file in this directory -n No php.ini file will be used -d foo[=bar] Define INI entry foo with value 'bar' -e Generate extended information for debugger/profiler -f Parse . Implies `-q' -h This help -i PHP information -l Syntax check only (lint) -m Show compiled in modules -q Quiet-mode. Suppress HTTP Header output. -s Display colour syntax highlighted source. -v Version number -w Display source with stripped comments and whitespace. -z Load Zend extension . C:\> php\php -v PHP 4.3.4 (cgi-fcgi) (built: Nov 2 2003 23:47:22) Copyright (c) 1997-2003 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies
#21303 [Com]: FastCGI Support
ID: 21303 Comment by: verdy_p at wanadoo dot fr Reported By: fserb at terra dot com dot br Status: Bogus Bug Type: *General Issues Operating System: WinXP PHP Version: 4.3.0 New Comment: Still not fixed in PHP 4.3.4 ! At least in the latest stable version for Win32 (both e installer version, and the manually installed ZIP version) C:\> php\php -b 6000 Error in argument 1, char 2: option not found b Usage: php [-q] [-h] [-s] [-v] [-i] [-f ] php [args...] -a Run interactively -b | Bind Path for external FASTCGI Server mode -C Do not chdir to the script's directory -c | Look for php.ini file in this directory -n No php.ini file will be used -d foo[=bar] Define INI entry foo with value 'bar' -e Generate extended information for debugger/profiler -f Parse . Implies `-q' -h This help -i PHP information -l Syntax check only (lint) -m Show compiled in modules -q Quiet-mode. Suppress HTTP Header output. -s Display colour syntax highlighted source. -v Version number -w Display source with stripped comments and whitespace. -z Load Zend extension . C:\> php\php -b 127.0.0.1:6000 Error in argument 1, char 2: option not found b Usage: php [-q] [-h] [-s] [-v] [-i] [-f ] php [args...] -a Run interactively -b | Bind Path for external FASTCGI Server mode -C Do not chdir to the script's directory -c | Look for php.ini file in this directory -n No php.ini file will be used -d foo[=bar] Define INI entry foo with value 'bar' -e Generate extended information for debugger/profiler -f Parse . Implies `-q' -h This help -i PHP information -l Syntax check only (lint) -m Show compiled in modules -q Quiet-mode. Suppress HTTP Header output. -s Display colour syntax highlighted source. -v Version number -w Display source with stripped comments and whitespace. -z Load Zend extension . C:\> php\php -v PHP 4.3.4 (cgi-fcgi) (built: Nov 2 2003 23:47:22) Copyright (c) 1997-2003 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies Please fix it! FastCGI cannot work without it! Previous Comments: [2003-05-16 14:28:13] krip at openisis dot org OF COURSE it does imply a bug in php itself, if it doesn't recognize it's own options! The bug is having cgi_main lacking a b in OPTSTRING. This is apparently fixed in 4.3.2 (but still not working for some other reason ...) [2002-12-31 08:06:06] [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. [2002-12-30 20:48:55] fserb at terra dot com dot br Hi, what has happened with FastCGI support on the 4.3 version? On changelog I saw that SAPI/FastCGI was discontinued. But when I do phpinfo() it reports "Server API : CGI/FastCGI" and when I go with "php -v" the answer is: PHP 4.3.0 (cgi-fcgi), Copyright (c) 1997-2002 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies and when I go with "php -h" there's an option : -b | Bind Path for external FASTCGI Server mode But when I do "php -b localhost:5000" it says there's no "b" command. I don't know if this is a real bug or something else. But what's up with FastCGI? Was it really discontinued? If so, where can I find good alternatives to FastCGI and the reasons that lead to this? thankz Fernando -- Edit this bug report at http://bugs.php.net/?id=21303&edit=1
#27514 [NEW]: fix modules' PHP info
From: verdy_p at wanadoo dot fr Operating system: Win32 PHP version: 4.3.5RC3 PHP Bug Type: Feature/Change Request Bug description: fix modules' PHP info Description: The php_info() output is quite ugly in its format, which is inconsistent across its modules, and still not XHTML/1.1 ready. But more importantly, some info are still missing... Please make the modules info consistant in their format: * Win32 API: missing a "Win32 API version | information" row; * bcmath: missing a "bcmath version | information" row; * calendar: missing a "calendar version | information" row; * com: missing a "com support | enabled" information row; missing a "com version | information" row; * crack: wrong head style, should use the information rows style; missing a "crack version | information" row; * ctype: change "ctype functions" to "ctype support"; missing a "ctype version | information" row; * curl: change "CURL information" to "CURL version" * db: wrong single column style, change to "db Flat file support | enabled"; missing a "db Version | information" row; * dba: missing a "DBA Version | information" row; etc... Reproduce code: --- On Windows command line with the default CGI/FastCGI version: php -i > php_info.html start php_info.html Expected result: More generally there should exist a way to format the module supported in a single table displaying a "enabled/disabled" column, and a version. Then there would be specific items below that list additional information variables and/or configurable directives, possibly with anchors linked from the main table of modules with an additional "details" column. This may require some modifications in each module so that they export their information in a common way through a single API. Searching in this configuration screen is not immediate, and this is the only way that PHP hosting ISPs provide information about their installation of PHP, and this should become a way to compare these installations. -- Edit bug report at http://bugs.php.net/?id=27514&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27514&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27514&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27514&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27514&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27514&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27514&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27514&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27514&r=support Expected behavior: http://bugs.php.net/fix.php?id=27514&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27514&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27514&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27514&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27514&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27514&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27514&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27514&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27514&r=float
#27509 [Fbk]: fsockopen() failed with "Addr family not supported by protocol" error
ID: 27509 Updated by: [EMAIL PROTECTED] Reported By: scott at abcoa dot com Status: Feedback Bug Type: Sockets related Operating System: AIX 4.3.3 PHP Version: 4.3.4 New Comment: If that doesn't work, try configuring PHP using --disable-ipv6 Previous Comments: [2004-03-06 13:29:13] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-03-05 18:16:39] scottmacvicar at ntlworld dot com Should be tcp:// not tcp:\\ since \ is an escape character and will end up being evaluated to tcp:\ How about a local IP do they work? [2004-03-05 17:59:13] scott at abcoa dot com Description: I had no trouble with the fsockopen() until I upgraded to PHP 4.3.4. My last working version was 4.2.3 before the upgrade. It sure look like a fsockopen() issue. Enclosed below is the source code that produce the same error result with both the Apache/Browser and the Shell Environment. I tried variety of URL Address and still get the same result, like www.google.com, www.cnn.com, www.php.net, etc... Been trying different ways with the scripts, machine and network and yet get the same result. I tried with and without the "tcp:\\" and still get the same result. (One more thing, could error 66 meant 6 with an one digit, not two??) Reproduce code: --- Expected result: Should expect to see an successful connection to www.google.com Actual result: -- Warning: fsockopen() [http://www.php.net/function.fsockopen]: php_hostconnect: connect failed in <> on line 5 Warning: fsockopen() [http://www.php.net/function.fsockopen]: unable to connect to www.google.com:80 in <> on line 5 66 Addr family not supported by protocol -- Edit this bug report at http://bugs.php.net/?id=27509&edit=1
#27428 [Fbk->Opn]: serialize brakes output for unserialize, returning garbage
ID: 27428
User updated by: black at scene-si dot org
Reported By: black at scene-si dot org
-Status: Feedback
+Status: Open
Bug Type: Strings related
Operating System: debian unstable
PHP Version: Irrelevant
New Comment:
the first thing i tried was to disable it, but nothing was changed.
then i tried compiling php without oracle support, nothing. then i
tried compiling latest snapshots, stable relases, release candidates,
older snapshots i had lying around.. everything with the same result..
of late i made a workaround by not using the database, but i still use
the serialize/unserialize functions, so it probablly has something to
do with the escape string / query functions (so strings related
category shouldnt apply anymore?)..
unserialize caused garbage to spew out because of the incorrect
reported length from serialize, and the difference of length in the
actual field.. (check description, original post), this behaviour is
valid, but checks should still be made so that doesnt happen (accessing
memory not used by the string that gets passed to is, bad thing).
something seriously goes wrong, either with serialize.. or
mysql_escape_string (or the acctual mysql application)..
why serialize wouldnt fuck up with files is beyond me..
[anyway, as to your feedback request, i tried just about everything
except compiling php in debug mode]
Previous Comments:
[2004-03-06 14:14:17] [EMAIL PROTECTED]
Try to see if you can replicate the bug when turckmmcache
is not being used.
[2004-02-28 17:38:50] black at scene-si dot org
i've also tried using mysql_real_escape_string, but it didnt solve
anything (for long anyway, the garbage output came back at the worst of
moments.)
the phpinfo above is still valid - any help would be appreciated, as i
really dont know what to do
[2004-02-27 20:31:55] black at scene-si dot org
Description:
The following has been tested on:
php-4.3.2
php-4.3.4
php-4.3.5rc2
php-4.3.5rc3
php4-STABLE-200310032330
php4-STABLE-200402101030
php4-STABLE-200402272030
with various compile options turned on/off (oracle support &
turckmmcache), always giving same result
basically with every version of this some or most serialize() calls
result in an incorrectlly constructed serialized string... given i only
input plaintext, the serialized string must have a length of
6+strlen(original), albeit:
["cache_data"]=> string(9277) "s:9309:"... (oops!)
["cache_data"]=> string(24259) "s:24248:"... (correct.)
["cache_data"]=> string(23850) "s:23881:"... (oops!)
["cache_data"]=> string(224081) "s:224069:"... (correct.)
["cache_data"]=> string(21055) "s:21107:"... (WTF!)
["cache_data"]=> string(19590) "s:19663:"... (wrong)
...
http://scene-si.org/test.tgz - 800kb, contains 15Mb output of the
reproduce code.
http://193.77.198.80/phpinfo.php for phpinfo()
Linux dahim 2.4.23-1-686 #1 Sun Nov 30 20:51:10 EST 2003 i686 GNU/Linux
(thats the server this runs on).
the funny part is, that this code (the same code to generate the
entries in condor_dbcache) works also on other servers, also debian,
iis, apache-win, redhat, mandrake, openbsd, freebsd.. it only fucked
here..
after the serialize is done, the ONLY command it goes trough is
mysql_escape_string, so there is no character or other conversions
which could explain the wrong length in serialized() output
Reproduce code:
---
";'
... but the content length is 9277..
the content was input with serialize in the following way:
$content = serialize($content);
mysql_query("update condor_dbcache set cache_timestamp='".time()."',
cache_data='".mysql_escape_string($content)."' where
cache_filename='".mysql_escape_string($filename)."'");
filename beeing the correspondant key to this dbcache table.
--
Edit this bug report at http://bugs.php.net/?id=27428&edit=1
#27492 [Opn->Fbk]: /(\n|.)*<\/tag1>/ - this expression crash PHP, while processing long text
ID: 27492 Updated by: [EMAIL PROTECTED] Reported By: jakerator at mail dot ru -Status: Open +Status: Feedback Bug Type: *Regular Expressions Operating System: win32/linux PHP Version: 4.3.4, HEAD New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2004-03-05 05:03:06] jakerator at mail dot ru But how I can process large texts, wich much more than 40kb? [2004-03-04 08:05:35] [EMAIL PROTECTED] confirmed with HEAD. see backtrace below. --- #18038 0x4026aaf7 in match ( eptr=0x4144c88b "esttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest---Type to continue, or q to quit--- testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttestt"..., ecode=0x8193cce "=", offset_top=4, md=0xbfffbf30, ims=0, eptrb=0xbfffb688, flags=2) at /root/CVS/php-src/ext/pcre/pcrelib/pcre.c:5676 #18039 0x4026a229 in match ( eptr=0x4144c88b "esttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttestt"..., ecode=0x8193cd2 "?", offset_top=4, md=0xbfffbf30, ims=0, eptrb=0xbfffba28, flags=2) at /root/CVS/php-src/ext/pcre/pcrelib/pcre.c:6207 #18040 0x4026aaf7 in match ( eptr=0x4144c88a "testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest"..., ecode=0x8193cce "=", offset_top=2, md=0xbfffbf30, ims=0, eptrb=0xbfffba28, flags=2) at /root/CVS/php-src/ext/pcre/pcrelib/pcre.c:5676 #18041 0x4026a9d8 in match ( eptr=0x4144c88a "testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest"..., ecode=0x8193cc7 "IM", offset_top=2, md=0xbfffbf30, ims=0, eptrb=0xbfffbbf8, flags=2) at /root/CVS/php-src/ext/pcre/pcrelib/pcre.c:6081 #18042 0x402658c7 in match ( eptr=0x4144c884 "testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttestte"..., ecode=0x8193cbc "L", offset_top=2, md=0xbfffbf30, ims=0, eptrb=0xbfffbdc8, flags=2) at /root/CVS/php-src/ext/pcre/pcrelib/pcre.c:5706 #18043 0x4026afe8 in php_pcre_exec (external_re=0x8193ca0, extra_data=0xbfffbf30, subject=0x4144c884 "testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttestte"..., length=40012, start_offset=0, options=1095026820, offsets=0x4143b22c, offsetcount=6) at /root/CVS/php-src/ext/pcre/pcrelib/pcre.c:8240 #18044 0x4026be79 in php_pcre_match (ht=1095026820, return_value=0x4145fc0c, this_ptr=0x0, return_value_used=1, global=0) at /root/CVS/php-src/ext/pcre/php_pcre.c:475 #18045 0x4026c75e in zif_preg_match (ht=-1073758416, return_value=0xbfffbf30, this_ptr=0xbfffbf30, return_value_used=-1073758416) at /root/CVS/php-src/ext/pcre/php_pcre.c:611 #18046 0x4034ac74 in zend_do_fcall_common_helper (execute_data=0xbfffcfe0, opline=0x414481cc, op_array=0x41426ce4) at /root/CVS/php-src/Zend/zend_execute.c:2642 #18047 0x4034aded in zend_do_fcall_handler (execute_data=0xbfffcfe0, opline=0x414481cc, op_array=0xbfffbf30) at /root/CVS/php-src/Zend/zend_execute.c:2771 #18048 0x403471da in execute (op_array=0x41426ce4) at /root/CVS/php-src/Zend/zend_execute.c:1339 #18049 0x40329a23 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/CVS/php-src/Zend/zend.c:1053 #18050 0x402f2231 in php_execute_script (primary_file=0xb340) at /root/CVS/php-src/main/main.c:1647 #18051 0x403512ee in apache_php_module_main (r=0x817fe9c, display_source_mode=0) at /root/CVS/php-src/sapi/apache/sapi_apache.c:54 #18052 0x40351e4b in send_php (r=0x817fe9c, display_source_mode=0, filename=0x0) at /root/CVS/php-src/sapi/apache/mod_php5.c:621 #18053 0x40352015 in send_parsed_php (r=0x817fe9c) at /root/CVS/php-src/sapi/apache/mod_php5.c:636 #18054 0x0806b1d6 in ap_invoke_handler () #18055 0x080811fe in process_request_internal () #18056 0x08081668 in ap_internal_redirect () #18057 0x0806000a in handle_dir () ---Type to continue, or q to quit--- #18058 0x0806b1d6 in ap_invoke_handler () #18059 0x080811fe in process_request_intern
#27414 [Opn->Fbk]: setlocale doesn't work when called in an included file
ID: 27414
Updated by: [EMAIL PROTECTED]
Reported By: rmarth at firemail dot de
-Status: Open
+Status: Feedback
Bug Type: *Languages/Translation
Operating System: Win2k SP4
PHP Version: 4.3.5RC3
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Cannot reproduce on Linux.
Previous Comments:
[2004-02-27 04:47:45] rmarth at firemail dot de
Description:
Calling setlocale() in an included file doesn't change the format of
strftime().
System: Apache/1.3.29 (Win32) PHP/4.3.5RC3
Short Testcase:
foo1.php
-->
echo setlocale (LC_ALL, array('de_DE', '[EMAIL PROTECTED]', 'de', 'ge',
'german');
strftime("%A, %d.%B.");
<--
Output: German_Germany.1252
Donnerstag, 26.Februar
Works.
bar.php
-->
echo setlocale (LC_ALL, array('de_DE', '[EMAIL PROTECTED]', 'de', 'ge',
'german');
<-
foo2.php
-->
require('bar.php');
strftime("%A, %d.%m.");
<-
Output: German_Germany.1252
Thursday, 26.February
Doesn't Work.
--
Edit this bug report at http://bugs.php.net/?id=27414&edit=1
#27451 [Opn->Fbk]: Losing Session vars for unknown reason
ID: 27451
Updated by: [EMAIL PROTECTED]
Reported By: hamid at wannameet dot nl
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: FreeBSD
PHP Version: 4.3.4
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Previous Comments:
[2004-03-06 11:53:58] hamid at wannameet dot nl
Here is a screenshot of my sessions db-table to prove the point of
losing session vars.
http://www.wannameet.nl/error/session_screen.gif
[2004-03-02 16:48:12] hamid at wannameet dot nl
hi idong,
yeh i find it really strange too. Also because i am not getting any
errors concerning the session itself.
And other annoying thing is the randomness of this problem, because
when i try to invoke the error it is not occuring.
So i am really lost :( ;)
Although i am starting to suspect my hostingcompany
[2004-03-02 16:36:50] hamid at wannameet dot nl
i have put my latest error_log in the directory php_bug
as you can see the session exists but sess_lang and sess_referer are
empty.
// error function
session_start();
$sess_lang = $_SESSION['lang'];
$sess_referer = $_SESSION['referer'];
$session_id = session_id();
$errorString .= "Session_id: $session_id\n";
$errorString .= "Sess_lang: $sess_lang\n";
$errorString .= "Sess_referer: $sess_referer\n";
//
the format for the include files is:
include("content/$sess_lang/filename.inc");
[2004-03-02 16:35:14] idong at gmx dot de
Hello Hamid,
Really strange...
I tried this again, after reading your comment and now I get:
lang test
1 - de
2 - en
no_lang test
1 - de
2 - en
I swear that I just copied and pastet the results of the script - both
with my first posting and now with this one.
I tried it with register_globals on and register_globals off. This is
really getting strange since you get a completely different result from
my example and me, I got a different result (than the first time) too.
Anyway, the result from my last test (see above) isn't the expected
behaviour either or am I making a mistake?
Ok, lets resume the problem at this point of time:
1. With the same example I got two different results. I changed nothing
in between, only some time went by.
2. Again, using my example, YOU got a completely different result - the
result I would have also expected from my own tests.
3. looking at my latest results, I can say that my first analysis (bug
occurs on use of "lang" as session var name) was wrong.
4. YOU have the problem, that you are "losing vars from my session
occassionaly"
Any help from the PHP crew?
Thanks a lot, idong
[2004-03-02 15:42:21] hamid at wannameet dot nl
hi idong,
i tried your example, but the result i am getting is
de
de
de
de
with register_globals Off and On
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/27451
--
Edit this bug report at http://bugs.php.net/?id=27451&edit=1
#27389 [Opn->Bgs]: $_POST variables not accessible from multiview
ID: 27389 Updated by: [EMAIL PROTECTED] Reported By: vanlei at yahoo dot com -Status: Open +Status: Bogus Bug Type: Apache related Operating System: Mac OS X PHP Version: 4.3.4 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The POST & GET data does not get passed to the ErrorDocument handler, only the missing URL is. Previous Comments: [2004-03-01 12:46:15] vanlei at yahoo dot com I traced the problem a little better. I wasn't coming in through the overriden php file, but through ErrorDocument. Now I'm not sure if it is a bug or not, but ErrorDocument doesn't see POST. In any case I solved it in a more elegant way, but I'll leave this here for comment. Should ErrorDocument receive POST requests? [2004-02-26 06:00:10] postings-php-bug at hans-spath dot de You should perhaps reread the Apache documentation. As far as I understand it, Multiviews are used for automatic language selection and aren't involved in your problem. I've run some tests with http://my-server/script.php/morestuff/ using GET and POST requests. Linux, Apache 2, PHP 4.3.4 module: works Windows, Apache 2, PHP 4.3.4 module: works Windows, Apache 2, PHP 4.3.4 CGI: doesn't work (maybe misconfiguration) And it works even with MultiViews disabled. Although I haven't tested Apache 1, I don't think there is a PHP problem. Try if a normal GET request works on such URLs, and if it doesn't, it might be a problem with your apache configuration. [2004-02-25 21:31:44] vanlei at yahoo dot com Apache: Server version: Apache/1.3.29 (Darwin) httpd.conf: Inside the config for the site, you need to add: Options MultiViews PHP is configured as an apache mod. Version 4.3.4 [2004-02-25 05:56:33] [EMAIL PROTECTED] 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. Apache version, how to configure httpd.conf, how PHP is configured (module/cgi), etc. [2004-02-24 23:55:29] vanlei at yahoo dot com Description: $_POST variables aren't accessible from within a multiview if one configures the action of a form to be the child of a multiview. In other words, If I set the action of a form to be 'example.com/multi/sub' where multi is a PHP file called multi.php that catches the url 'example.com/ multi/sub/' (by using apache's multiviews), multi.php will not have access to the $_POST variable. It works if one sets the action as 'example.com/multi/ '. Reproduce code: --- Example code: http://example.com/multi/sub/"; name="form"> multi.php: echo $_POST['submit'] Expected result: Expected: $_POST['submit'] == "Value" Actual result: -- Blank. I think PHP associates the $_POST variable with /multi/sub when sub isn't a script/file. Instead the request is handled by multi. -- Edit this bug report at http://bugs.php.net/?id=27389&edit=1
#27421 [Opn->Csd]: mbstring.func_overload set in .htaccess becomes global
ID: 27421 Updated by: [EMAIL PROTECTED] Reported By: php at strategma dot bg -Status: Open +Status: Closed Bug Type: mbstring related Operating System: Slackware 9.1 kernel: 2.4.22 PHP Version: 4.3.4 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2004-02-27 10:12:38] php at strategma dot bg Description: ./configure \ --with-apxs=/usr/local/apache/bin/apxs \ --prefix=/usr/local/php --enable-mbstring \ --with-mbregex apache version 1.3.29 we set in .htaccess PHP_VALUE mbstring.internal_encoding UTF-8 PHP_VALUE default_charset UTF-8 PHP_VALUE mbstring.http_output UTF-8 PHP_VALUE mbstring.encoding_translation On PHP_VALUE mbstring.detect_order UTF-8 PHP_VALUE mbstring.func_overload 7 for specific site, but string functions on other web sites at the same apache doest work (other sites use CP1251 enconding). The string functions stop to work when anyone access the unicode site. When we stop apache and start it again cp1251 string functions work properly. we tryed the same configuration in the directive at apache's httpd.conf for the UNICODE site and in the but it is the same result With or without setlocale(LC_ALL,"bg_BG.CP1251") or bg_BG or bg_BG.UTF-8 we have tryed all combinations and it still doesnt work. thanks in advance Reproduce code: --- Expected result: Òîâà å òåñò Actual result: -- Òîâà -- Edit this bug report at http://bugs.php.net/?id=27421&edit=1
#27428 [Opn->Fbk]: serialize brakes output for unserialize, returning garbage
ID: 27428
Updated by: [EMAIL PROTECTED]
Reported By: black at scene-si dot org
-Status: Open
+Status: Feedback
Bug Type: Strings related
Operating System: debian unstable
PHP Version: Irrelevant
New Comment:
Try to see if you can replicate the bug when turckmmcache
is not being used.
Previous Comments:
[2004-02-28 17:38:50] black at scene-si dot org
i've also tried using mysql_real_escape_string, but it didnt solve
anything (for long anyway, the garbage output came back at the worst of
moments.)
the phpinfo above is still valid - any help would be appreciated, as i
really dont know what to do
[2004-02-27 20:31:55] black at scene-si dot org
Description:
The following has been tested on:
php-4.3.2
php-4.3.4
php-4.3.5rc2
php-4.3.5rc3
php4-STABLE-200310032330
php4-STABLE-200402101030
php4-STABLE-200402272030
with various compile options turned on/off (oracle support &
turckmmcache), always giving same result
basically with every version of this some or most serialize() calls
result in an incorrectlly constructed serialized string... given i only
input plaintext, the serialized string must have a length of
6+strlen(original), albeit:
["cache_data"]=> string(9277) "s:9309:"... (oops!)
["cache_data"]=> string(24259) "s:24248:"... (correct.)
["cache_data"]=> string(23850) "s:23881:"... (oops!)
["cache_data"]=> string(224081) "s:224069:"... (correct.)
["cache_data"]=> string(21055) "s:21107:"... (WTF!)
["cache_data"]=> string(19590) "s:19663:"... (wrong)
...
http://scene-si.org/test.tgz - 800kb, contains 15Mb output of the
reproduce code.
http://193.77.198.80/phpinfo.php for phpinfo()
Linux dahim 2.4.23-1-686 #1 Sun Nov 30 20:51:10 EST 2003 i686 GNU/Linux
(thats the server this runs on).
the funny part is, that this code (the same code to generate the
entries in condor_dbcache) works also on other servers, also debian,
iis, apache-win, redhat, mandrake, openbsd, freebsd.. it only fucked
here..
after the serialize is done, the ONLY command it goes trough is
mysql_escape_string, so there is no character or other conversions
which could explain the wrong length in serialized() output
Reproduce code:
---
";'
... but the content length is 9277..
the content was input with serialize in the following way:
$content = serialize($content);
mysql_query("update condor_dbcache set cache_timestamp='".time()."',
cache_data='".mysql_escape_string($content)."' where
cache_filename='".mysql_escape_string($filename)."'");
filename beeing the correspondant key to this dbcache table.
--
Edit this bug report at http://bugs.php.net/?id=27428&edit=1
#27407 [Opn->Fbk]: socket_select crashes
ID: 27407 Updated by: [EMAIL PROTECTED] Reported By: flapc at pobox dot sk -Status: Open +Status: Feedback Bug Type: Sockets related Operating System: Linux PHP Version: 4.3.4 New Comment: Sockets extension was compiled directly into your PHP, there is no need to load sockets.so. Previous Comments: [2004-03-04 11:10:39] flapc at pobox dot sk That i've found out .. But I've no idea of compiling from sources. After unpacking it i runned './configure' '--enable-inline-optimization' '--enable-pic' '--enable-calendar' '--enable-ctype' '--enable-dbase' '--enable-ftp' '--enable-bcmath' '--enable-exif' '--enable-ctype' '--with-imap-ssl=/usr' '--with-openssl=/usr' '--enable-sockets' '--enable-trans-sid' '--enable-sigchild' '--enable-magic-quotes' '--enable-zend-multibyte' '--with-bz2' '--enable-shared' '--enable-memory-limit' '--disable-posix' '--disable-tokenizer' '--disable-rpath' '--enable-mbstring' '--enable-mbregex' '--enable-wddx' and then make but i'm not allowed to run make install I got cli version of php, but THERE WAS no SOCKETS(.SO) .. how to build the sockets? [2004-03-04 09:06:25] [EMAIL PROTECTED] Right, and that's why the first URL he posted was to a linux source snapshot, please test with that one. [2004-03-04 09:03:42] flapc at pobox dot sk There is no problem on Windows. The problem is on LINUX.. [2004-02-26 15:21:20] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-02-26 14:26:21] flapc at pobox dot sk Description: socket_select crashes. Even I get no input from the script sent before the call. I cannot check it deeply because I experienced the problem on my webhosting server. On Win distribution everthing runs fine... Reproduce code: --- http://dave.dapond.com/socketselect.php.txt -- Edit this bug report at http://bugs.php.net/?id=27407&edit=1
#27511 [Opn->Bgs]: fread crashes Apache with mistakenly big length
ID: 27511 Updated by: [EMAIL PROTECTED] Reported By: patrick at borgeat dot de -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: Windows 2000 SR4 PHP Version: 5.0.0b4 (beta4) New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php When you call fread() PHP will try to allocate enough memory to store all of the data that you want to read. Meaning that in your case it'll try to allocate approximately 1078508183 bytes. This fails and causes the script to exit OR if you have enough memory and/or swap try to allocate this much memory which would take a VERY long time. Previous Comments: [2004-03-06 07:07:46] patrick at borgeat dot de I forgot a Semikolon (;) after "echo $res", sorry! [2004-03-06 04:53:43] patrick at borgeat dot de Description: As I mistakenly tried to read a very large number of bytes (1078508183) (more than are in the file) with fread, the Site doesn't react anymore and i get a apache.exe Task in my Tasklist consuming an average of 80% CPU Load (with a 1300 Mhz Machine) which can't be stopped (maybe also due to missing rights). Also the file is blocked. Never tested this on Linux, but I think if a server does this mistakenly several times at once the whole server enviroment would crash. I run Apache 2.0.48 with PHP 5.0.0b4 as Apache2 Handler on Windows 2000 SR4 on FAT32 Filesystem. Reproduce code: --- (in my case test was a textfile with the 3 Letters "AAA") Expected result: I expected PHP to be as smart (as it is with smaller numbers for example like 50 000) to write only 3 Bytes and output "AAA". Actual result: -- Apache Task isn't stopable and runs @ Average of 80% CPU Load -- Edit this bug report at http://bugs.php.net/?id=27511&edit=1
#27480 [Opn->Fbk]: session problem with session.start()
ID: 27480 Updated by: [EMAIL PROTECTED] Reported By: ricardo at aganp dot go dot gov dot br -Status: Open +Status: Feedback Bug Type: Session related Operating System: SUSE 8 PHP Version: Irrelevant New Comment: Are you using output buffering and can you verify the error with latest CVS? Previous Comments: [2004-03-03 09:35:42] ricardo at aganp dot go dot gov dot br I have a PHP file name top.php where I open the postgre conection and start the session. Another php file name button.php where I close my postgre conection. This two files are put into all my php files. The first one, top.php, on the top of my index.php and the button.php on button, like this: top.php button.php index.php 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. [2004-03-03 07:56:43] ricardo at aganp dot go dot gov dot br Description: When session.start() PHP document is loaded at the first time it´s necessary to refresh the page to view the contents. We are using the PHP version 4.0.4pl1 before this new version 4.2.2 and this problem not happened. There is some BUG on this 4.2.2 PHP Version about session? How can I solve my problem? -- Edit this bug report at http://bugs.php.net/?id=27480&edit=1
#27487 [Opn->Csd]: yet another session_decode crash
ID: 27487 Updated by: [EMAIL PROTECTED] Reported By: xuefer at 21cn dot com -Status: Open +Status: Closed Bug Type: Session related Operating System: winxp/linux PHP Version: 4.3.5RC3 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2004-03-04 09:46:32] [EMAIL PROTECTED] That's some nasty session data. It crashes 4.3.2 and 5.0 CVS with a Segmentation Fault, which occurs *after* script execution (probably when PHP attempts to write the session to a file). [2004-03-04 04:02:10] xuefer at 21cn dot com can you reproduce the crash? i used sql as session save handler corrupted data may not bug of sedssion_encode(), it's bug of GBK mysql( http://bugs.mysql.com/bug.php?id=369 ), as when i use file, no crash but it IS bug of session_decode(), it shouldn't crash on corrupted data. e.g.: saving session data but crashed by other thread, data is corrupted. when page load again, session_decode crash. and anyone who use vhost, can write a simple script to make php crash the server admin can hardly track who and what make the crash. and if possible, pls make session_encode() do base64_encode, because may ppl use his own sql-save-handler e.g.: session_use_text_encode(true); [2004-03-04 03:36:36] [EMAIL PROTECTED] I fail to see how I can reproduce it. Can you tell me how you did get this corrupted data? As it looks to me that there is a bug in serializing here, not deserializing. I think it has to do with the binary stuff inside the _cached_html part though and Windows ;-) Can you provide the variable before serialization (use var_export($_SESSION) to obtain it). [2004-03-04 01:58:50] xuefer at 21cn dot com Description: tested on php4.3.4 and 4.3.5RC3 the data is produced by session_decode() but corrupted the corrupted-data is base64 encoded in script, just for easy download Reproduce code: --- http://www.our-sky.com/misc/session.phps (will be removed when bug closed) -- Edit this bug report at http://bugs.php.net/?id=27487&edit=1
#27283 [Ver]: Exception not caught if more than two catch blocks are used
ID: 27283
User updated by: benjcarson at digitaljunkies dot ca
Reported By: benjcarson at digitaljunkies dot ca
Status: Verified
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2004-02-16
New Comment:
For now we've had to use this workaround:
getMessage() . "\n");
else if ($e instanceof Ex2)
echo ("Ex2: " . $e->getMessage() . "\n");
else if ($e instanceof Ex3)
echo ("Ex3: " . $e->getMessage() . "\n");
else
echo ("Exception: " . $e->getMessage() . "\n");
}
Previous Comments:
[2004-03-06 13:10:21] kase at gmx dot net
Still NOT fixed in latest CVS (6 Mar)
I think, it is very important to fix for users working intensively with
exceptions ?!
[2004-02-16 21:09:43] benjcarson at digitaljunkies dot ca
Description:
If an exception is thrown within a try block and more than two catch
blocks follow, the exception may not be caught. If the exception
matches either of the first two catch blocks then the exception will be
caught. However, if the exception does not match the first two catch
blocks, it will skip any remaining catch blocks and remain uncaught.
In the code below, the exception is caught properly if the second catch
block is commented out. Once it is included again though, the
exception is not caught.
Reproduce code:
---
getMessage() ."\n");
} catch (Ex2 $e) {
echo ("Ex2: " . $e->getMessage() ."\n");
} catch (Exception $e) { // Note: trying to catch Ex3 also fails
echo ("Exception: " . $e->getMessage() . "\n");
}
exit(0);
?>
Expected result:
Execption: Ex3
Actual result:
--
Fatal error: Uncaught exception 'Ex3' with message 'Ex3'
exception.php:8
Stack trace:
#0 {main}
thrown in exception.php on line 8
--
Edit this bug report at http://bugs.php.net/?id=27283&edit=1
#25118 [Ver]: ODBC: can't store data in blob fields
ID: 25118
User updated by: php at jschreiber dot com
Reported By: php at jschreiber dot com
Status: Verified
Bug Type: Feature/Change Request
Operating System: GNU/Linux (Gentoo)
-PHP Version: 4.3.2
+PHP Version: 4.3.4
New Comment:
I think I've finally fixed this bug. Here is my patch:
http://www.jschreiber.com/php/blobtest/patch.txt
The patch worked with PHP 4.3.x and IBM DB/2 8.1 Fixpack 3 and 4. It
has been tested using Linux and Solaris.
Apply this patch with
cd /path/to/source/php-4.3.4/ext/odbc
patch -p1 < /path/to/patch/patch.txt
Hope this helps somebody!
Regards, Jan
Previous Comments:
[2004-02-25 12:55:29] jerome dot dury at cegedim dot fr
Hello,
I don't think this is really not useful, because we're trying to build
a php script to insert blobs in a DB2 database. Our solution was pretty
robust : it was to re-use some php objects and their relative methods
that we implement in our php web site, in our back-office
procedures...
Because of this bug we are forced to rewrite our procedures with
perl-dbi or visual basic, which provides blobs insertions.
Are you planning to fix this bug ? Or do you leave it like this ?
Thanks
Jérome
[2003-10-22 19:46:59] [EMAIL PROTECTED]
Marking this as a verified bug, in the sense that I know it exists.
BLOB support in the ODBC system as it stands is relativly, umm, not
useful. I haven't a good solution to this right now though.
[2003-09-08 19:09:47] php at jschreiber dot com
I looked at my last trace one more time and saw that
SQLBindParameter( hStmt=1:1, iPar=1,
fParamType=SQL_PARAM_INPUT, fCType=SQL_C_CHAR,
fSQLType=SQL_BLOB, cbColDef=1048576, ibScale=0,
rgbValue=&000a, cbValueM
ax=0, pcbValue=&0820563c )
---> Time elapsed - +6.81E-004 seconds
is being called with fCType=SQL_C_CHAR instead of
SQL_BINARY. So I applied a part of Clara Lius patch to the
code and changed the line containg SQL_LEN_DATA_AT_EXEC as
described in my last comment. Now my "blobtest" script
runs fine!!
But the problem seems not to be totally solved - the
odbc-test that comes with php seems to "hang" on some
statements--sometimes it works, sometimes not...
Anyway, I think that was a step in the right direction, so
here is my patch:
http://www.jschreiber.com/php/blobtest/blob-patch.txt
Jan
[2003-08-28 05:02:05] php at jschreiber dot com
Sorry, guys...! It still doesn't work. I tried it with my "blobtest"
(http://www.jschreiber.com/php/blobtest/). the insert statement
gets executed, but the blob only contains an empty value (x'').
I uploaded a new db2 trace to
http://www.jschreiber.com/php/blobtest/db2trace_new.txt
I hope that helps you!! Again, thank you for trying to fix that. Jan
[2003-08-17 13:17:30] php at jschreiber dot com
Description:
I have a problem concerning BLOB fields and DB/2 V8.1.2.
When I try to store a file with odbc_prepare() and
odbc_execute($stmt, $params) no error code is returned, but the
BLOB contains an empty value ("x''", not a NULL value).
I had this bug since I upgraded from DB/2 7.1 to DB/2 8.1 (and
DB/2 8.1.2 as well).
It's not a programming error--all script were working with DB/2
7.1. It even occurs with the odbc-test included in tests/ directory
of the php source distribution.
I tried all tricks mentioned at
http://www7b.software.ibm.com/dmdd/library/techarticle/0301liu/0301liu.html
but without success.
Reproduce code:
---
odbc-t5.php from the tests/ directory of the php source distribution.
Expected result:
Actual result:
--
This is the output:
--- snip ---
ODBC Test 5 - Blobs
Connecting to test as db2inst1 - OK
Dropping table "php_test" - OK
Creating table "php_test": - OK
Table Info:
Name Type Length
ID CHAR 32
GIF BLOB 10
Inserting data: /tmp/phpnyprAM - - - OK
--- snap ---
It looks like everythings works fine, but the the database contains
just "image1" and "x''".
--
Edit this bug report at http://bugs.php.net/?id=25118&edit=1
#27460 [Opn->Csd]: base64_decode fails to follow RFC 3548 completely
ID: 27460
Updated by: [EMAIL PROTECTED]
Reported By: naish at klanen dot net
-Status: Open
+Status: Closed
Bug Type: URL related
Operating System: Suse Linux 9.0 (2.4.21)
PHP Version: 4.3.4
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2004-03-02 09:43:21] naish at klanen dot net
Description:
If a base64 encoded string contains a non-needed "=" at the end of the
string base64_decode returns false even though the string has been
correctly decoded.
The standard for base64 even specifies that a file may contain
non-needed padding chars.
http://www.faqs.org/rfcs/rfc3548.html
- snip -
Furthermore, such specifications may consider the pad character, "=",
as not part of the base alphabet until the end of the string. If more
than the allowed number of pad characters are found at the end of the
string, e.g., a base 64 string terminated with "===", the excess pad
characters could be ignored.
- /snip -
The fix is simple. In ext/standard/base64.c insert the following code:
if (ch == base64_pad) {
switch(i % 4) {
case 1:
efree(result);
return NULL;
case 2:
k++;
case 3:
result[k++] = 0;
}
}
in the base64_decode function. Notice that the only thing I did was
remove "case 0:" on line 191.
Reproduce code:
---
Expected result:
$string should been encoded to base64 and later decoded with 1 extra
"=" added at the end.
Actual result:
--
PHP fails to decode the string properly.
--
Edit this bug report at http://bugs.php.net/?id=27460&edit=1
#27479 [Opn->Fbk]: Dont report errors on domxml_open_mem
ID: 27479
Updated by: [EMAIL PROTECTED]
Reported By: pet at iv dot ua
-Status: Open
+Status: Feedback
Bug Type: DOM XML related
Operating System: FreeBSD 5.2.1
PHP Version: 4.3.4
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Works fine (prints errors found) with latest CVS.
Previous Comments:
[2004-03-03 07:51:26] pet at iv dot ua
Sorry.
xml must be:
$xml = '
]>';
[2004-03-03 07:34:44] pet at iv dot ua
DOM/XML API Version 20020815
libxml Version 20607
Configure Command
'./configure' '--enable-versioning' '--enable-memory-limit'
'--with-layout=GNU' '--with-zlib-dir=/usr' '--disable-all'
'--with-regex=php' '--disable-cli' '--enable-ctype'
'--with-dom=/usr/local' '--with-dom-xslt=/usr/local'
'--with-dom-exslt=/usr/local' '--with-iconv-dir=/usr/local'
'--with-iconv=/usr/local' '--with-mnogosearch=/usr/local'
'--with-mysql=/usr/local' '--enable-overload' '--with-pcre-regex=yes'
'--enable-posix' '--enable-tokenizer' '--with-expat-dir=/usr/local'
'--enable-xml' '--enable-xslt' '--with-xslt-sablot=/usr/local'
'--with-zlib=yes' '--with-apxs2=/usr/local/sbin/apxs'
'--prefix=/usr/local' 'i386-portbld-freebsd5.2.1'
[2004-03-03 06:10:45] [EMAIL PROTECTED]
Works for me.
Which libxml2 version are you using (phpinfo() should
tell you that)?
chregu
[2004-03-03 06:02:56] pet at iv dot ua
Description:
Its undocumented arguments of function domxml_open_mem
but on previous version php all work.
Note: no return "well-formed" errors.
If document not valid errors returned
Reproduce code:
---
//not well-formed document
$xml = '';
$dom = domxml_open_mem($xml, DOMXML_LOAD_VALIDATING, $Errors);
if(!Empty($Errors)){
echo "Error found"
}else{
echo "Document valid"
}
Expected result:
Error found
Actual result:
--
Document valid
--
Edit this bug report at http://bugs.php.net/?id=27479&edit=1
#27512 [Opn->Fbk]: Apache 1.3.29 crashes when loading extensions
ID: 27512 Updated by: [EMAIL PROTECTED] Reported By: jl at lusidor dot nu -Status: Open +Status: Feedback Bug Type: Apache related Operating System: Win XP pro PHP Version: 5.0.0b4 (beta4) New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Previous Comments: [2004-03-06 07:13:29] jl at lusidor dot nu I forgot to mention that without any extensions enabled apache runs without any problems. [2004-03-06 07:11:40] jl at lusidor dot nu Description: I'm on windows xp. I'm trying to load extensions with apache 1.3.29. I enable the extension in the php.ini. That causes apache to crash after 3 seconds without any notice in the error-log. When I try to run PHP5 by it self it loads the extension just fine. according to phpinfo. I have the following setup: /php5 (php5 directory) /program/apache-php5 (apache dir with php.ini, php5apache.dll, php5ts.dll) php.ini with the following changes include_path = ".;\php5\includes" ;extension_dir = ".\" (I've tried both) extension_dir = "\php5\ext\" extension=php_mhash.dll I've tried placing the libmhash.dll in every possible location, /windows/system32, /program/apache-php5 and /php5 dir to no avail. I have a similiar setup where I run PHP 4.3.4 as an apache mod with the identical setup loads just fine. So I see this as a bug related to running PHP5 b4 as an apache module. Reproduce code: --- Just start apache. It crashes within about 6 seconds -- Edit this bug report at http://bugs.php.net/?id=27512&edit=1
#27498 [Opn->Bgs]: wrong error message generated by opendir when safe mode is in effect
ID: 27498
Updated by: [EMAIL PROTECTED]
Reported By: troels at kyberfabrikken dot dk
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: red hat linux
PHP Version: 4.3.4
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Not a bug.
Previous Comments:
[2004-03-05 13:56:26] troels at kyberfabrikken dot dk
why is this not a bug ?
i get the message that my script is not allowed to access
/home/virtual/site1/fst/var/www/html/data/
but that is false - it DOES in fact have thoose rights.
[2004-03-05 13:44:54] [EMAIL PROTECTED]
This is definitely a bug.
[EMAIL PROTECTED]:~$ php -d'safe_mode=on' -r 'opendir("/home/et/nonexistant");'
Warning: opendir(): SAFE MODE Restriction in effect. The script whose
uid is 500 is not allowed to access /home/et owned by uid 0 in Command
line code on line 1
Warning: opendir(/home/et/nonexistant): failed to open dir: No such
file or directory in Command line code on line 1
[EMAIL PROTECTED]:~$ ls -dla /home/et
drwxr-xr-x 61 et et 4096 Mar 5 19:41 /home/et
[2004-03-05 13:36:17] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
.
[2004-03-04 16:57:19] troels at kyberfabrikken dot dk
Description:
while trying to open a dir that diddent exist, i recieved a wrong
error-message. this caused me to waste a lot of time, before i finally
figured out the real problem.
1. php is running as module under apache in safe mode. version = 4.3.3
2. /home/virtual/site1/fst/var/www/html/ is my www root
3. /home/virtual/site1/fst/var/www/html/data/ is a dir, end it's CHMOD
777
4. /home/virtual/site1/fst/var/www/html/data/subdir is non-existent
i recieve this error message :
Warning in line 3 of file
/home/virtual/site1/fst/var/www/html/index.php
[2] opendir(): SAFE MODE Restriction in effect. The script whose uid is
503 is not allowed to access
/home/virtual/site1/fst/var/www/html/data/subdir owned by uid 0
witch gave my a few hours messing around until i finally discovered
that i just forgot to create the dir in mention.
however - if php had given me a more precise error, i would have saved
a lot of time. when it comes down to it, safemode had nothing to do
with the real problem.
Reproduce code:
---
[index.php : begin]
[index.php : end]
--
Edit this bug report at http://bugs.php.net/?id=27498&edit=1
#27494 [Opn->Bgs]: Multiple clients messing up file reading
ID: 27494
Updated by: [EMAIL PROTECTED]
Reported By: csaba at alum dot mit dot edu
-Status: Open
+Status: Bogus
Bug Type: Output Control
Operating System: Win2K
PHP Version: 4.3.4
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
Support request are to be addressed of PHP's general
mailing list, not the bug system.
Previous Comments:
[2004-03-04 08:48:19] csaba at alum dot mit dot edu
Description:
I'm way sorry for posting this here since the culprit is unclear, but
you guys have the best response. I've written a (non polling) script
to simulate sockets on localhost. Web page A at
http://localhost/test/In.php is a page that the user enters some text
with and it gets written into a file.
Meanwhile, web page B at http://localhost/test/Out.php is looking at
this file and when it changes, it will update web page B with the new
text. This is working fine.
Now introduce web page C at the same http://localhost/test/Out.php In
this case, the second page of B and C to be user refreshed/invoked will
notice the change from page A, and after that it stops refreshing,
too.
Something is clearly wrong, but is it PHP 4.3, Apache 2.0.43, IE 5.5,
or (gasp) my code? I have also coded file_get_contents manually with
the same results.
Reproduce code:
---
In the test directory have 3 files:
In.php:
Input page
Enter a word:
Out.php:
Output page
function openSocket() { document.scripts[0].src = "socket.php"; }
Your output word is:
Socket.php
http://localhost/test/Out.php that they will all update right
away when In.php changes the contents of myWord.txt
Actual result:
--
Only the latter of the two Out.php windows is updated a single time.
--
Edit this bug report at http://bugs.php.net/?id=27494&edit=1
#27499 [Opn->Bgs]: problem with imap_append
ID: 27499 Updated by: [EMAIL PROTECTED] Reported By: vincent1 at cegetel dot net -Status: Open +Status: Bogus Bug Type: IMAP related Operating System: windows 2000 PHP Version: Irrelevant New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. PHP function is a simple wrapper around the imap's library mail_append_full() function, which appears to have the limitation you have mentioned. Please report this bug to the IMAP library developers. Previous Comments: [2004-03-04 17:46:32] vincent1 at cegetel dot net Description: Sorry for my english When i want to do a mail copy by imap_append, imap_append return false if the attachment(s) exceed approximately 900 Ko. If the attachment(s) dont exceed the 900 Ko, imap_append return true. Reproduce code: --- Expected result: Normally, imap_append would have send the message with attachement(s) in Sent Items box same when the attachment(s) exceed approximately 900 Ko Actual result: -- If the attachment(s) exceed approximately 900 Ko, imap_append not send the message in Sent Items box -- Edit this bug report at http://bugs.php.net/?id=27499&edit=1
#27509 [Opn->Fbk]: fsockopen() failed with "Addr family not supported by protocol" error
ID: 27509 Updated by: [EMAIL PROTECTED] Reported By: scott at abcoa dot com -Status: Open +Status: Feedback Bug Type: Sockets related Operating System: AIX 4.3.3 PHP Version: 4.3.4 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2004-03-05 18:16:39] scottmacvicar at ntlworld dot com Should be tcp:// not tcp:\\ since \ is an escape character and will end up being evaluated to tcp:\ How about a local IP do they work? [2004-03-05 17:59:13] scott at abcoa dot com Description: I had no trouble with the fsockopen() until I upgraded to PHP 4.3.4. My last working version was 4.2.3 before the upgrade. It sure look like a fsockopen() issue. Enclosed below is the source code that produce the same error result with both the Apache/Browser and the Shell Environment. I tried variety of URL Address and still get the same result, like www.google.com, www.cnn.com, www.php.net, etc... Been trying different ways with the scripts, machine and network and yet get the same result. I tried with and without the "tcp:\\" and still get the same result. (One more thing, could error 66 meant 6 with an one digit, not two??) Reproduce code: --- Expected result: Should expect to see an successful connection to www.google.com Actual result: -- Warning: fsockopen() [http://www.php.net/function.fsockopen]: php_hostconnect: connect failed in <> on line 5 Warning: fsockopen() [http://www.php.net/function.fsockopen]: unable to connect to www.google.com:80 in <> on line 5 66 Addr family not supported by protocol -- Edit this bug report at http://bugs.php.net/?id=27509&edit=1
#27505 [Opn->Csd]: htmlentities fail to escape BIG5 characters correctly
ID: 27505
Updated by: [EMAIL PROTECTED]
Reported By: ywliu at hotmail dot com
-Status: Open
+Status: Closed
Bug Type: *Languages/Translation
Operating System: linux
PHP Version: 4.3.4
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2004-03-05 03:43:06] ywliu at hotmail dot com
Description:
In ext/standard/html.c , htmlentities() fails to identify BIG5 Chinese
characters correctly.
I have checked CVS version 1.87, the bug is still there.
Reproduce code:
---
In html.c, look for this piece of code :
case cs_big5:
case cs_gb2312:
case cs_big5hkscs:
{
/* check if this is the first of a 2-byte sequence */
if (this_char >= 0xa1 && this_char <= 0xf9) {
/* peek at the next char */
unsigned char next_char = str[pos];
if ((next_char >= 0x40 && next_char <= 0x73) ||(next_char >= 0xa1 &&
next_char <= 0xfe)) {
Expected result:
In fact, the first byte should be from 0xa1 to 0xfe, and the second
byte should be from 0x40-0x7e and 0xa1-0xfe.
(from page 88, "Understanding Japanese Information Processing" by Ken
Lunde , O'Reilly.)
Actual result:
--
So it should be :
if (this_char >= 0xa1 && this_char <= 0xfe) {
and
if ((next_char >= 0x40 && next_char <= 0x7e) ||(next_char >= 0xa1 &&
next_char <= 0xfe)) {
--
Edit this bug report at http://bugs.php.net/?id=27505&edit=1
#27437 [Opn->Csd]: Wrong includes in ext/gd/libgd/gdft.c
ID: 27437 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: GD related Operating System: Debian 3 Unstable PHP Version: 4.3.4 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2004-02-29 10:06:04] [EMAIL PROTECTED] Description: Produces Erros during make process. Reproduce code: --- #include "freetype/ftglyph.h" should be #include FT_GLYPH_H -- Edit this bug report at http://bugs.php.net/?id=27437&edit=1
#27283 [Com]: Exception not caught if more than two catch blocks are used
ID: 27283
Comment by: kase at gmx dot net
Reported By: benjcarson at digitaljunkies dot ca
Status: Verified
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2004-02-16
New Comment:
Still NOT fixed in latest CVS (6 Mar)
I think, it is very important to fix for users working intensively with
exceptions ?!
Previous Comments:
[2004-02-16 21:09:43] benjcarson at digitaljunkies dot ca
Description:
If an exception is thrown within a try block and more than two catch
blocks follow, the exception may not be caught. If the exception
matches either of the first two catch blocks then the exception will be
caught. However, if the exception does not match the first two catch
blocks, it will skip any remaining catch blocks and remain uncaught.
In the code below, the exception is caught properly if the second catch
block is commented out. Once it is included again though, the
exception is not caught.
Reproduce code:
---
getMessage() ."\n");
} catch (Ex2 $e) {
echo ("Ex2: " . $e->getMessage() ."\n");
} catch (Exception $e) { // Note: trying to catch Ex3 also fails
echo ("Exception: " . $e->getMessage() . "\n");
}
exit(0);
?>
Expected result:
Execption: Ex3
Actual result:
--
Fatal error: Uncaught exception 'Ex3' with message 'Ex3'
exception.php:8
Stack trace:
#0 {main}
thrown in exception.php on line 8
--
Edit this bug report at http://bugs.php.net/?id=27283&edit=1
#27513 [Com]: strrpos() using the offset
ID: 27513 Comment by: scottmacvicar at ntlworld dot com Reported By: asterisk at email dot it Status: Open Bug Type: Strings related Operating System: windows xp PHP Version: 4.3.4 New Comment: http://www.php.net/strrpos Quote from that page --- Note: As of PHP 5.0.0 offset may be specified to begin searching an arbitrary number of characters into the string. Negative values will stop searching at an arbitrary point prior to the end of the string. --- Your using PHP4 hence the error Previous Comments: [2004-03-06 12:10:31] asterisk at email dot it Description: when is used 3rd parameter, the offset, the function produce a warning and don't return nothing Reproduce code: --- Expected result: 1 Actual result: -- Warning: Wrong parameter count for strrpos() in C:\WWW\strrpos.php on line 4 -- Edit this bug report at http://bugs.php.net/?id=27513&edit=1
#27238 [Opn->Csd]: iptcparse() function misses some fields
ID: 27238 Updated by: [EMAIL PROTECTED] Reported By: philip at nancarrow dot net -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Windows and Linux PHP Version: 4.3.4 -Assigned To: +Assigned To: pajoye New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2004-02-13 10:40:02] philip at nancarrow dot net Pierre, OK sure, I've put two JPEGs that include IIM record 1 at: http://www.nancarrow.net/download/testpic1_latin1.jpg [Latin1 encoded English] and http://www.nancarrow.net/download/testpic2_utf8.jpg [UTF8 encoded Chinese] The IPTC/NAA (aka "IIM") spec is freely downloadable from http://www.iptc.org/download/download.php?fn=IIMV4.1.pdf and this details all records include record 1. Appendix C lists the currently defined character sets, which is specified in dataset 1:90. Note the strange IPTC terminology - an "octet" is a byte, so "octet 2/5" means 0x25. The character set sequence starts with ESC, so where it says ISO-8859-1 is "intermediate character 2/12 to 2/15" followed by "octet 4/1" this would be something like: ESC,0x2F,0x41 or "ESC/A". Similarly UTF8 is ESC,2/5,4/7 or "ESC%G". Where the spec says "intermediate character 2/12 to 2/15" most creators writing the file use the end character, ie. 2/15 in this case. I'm not sure that PHP really needs to know about the encoding, does it ? Since strings are just byte sequences in PHP I guess it's down to the application to do the appropriate encoding/decoding... as long as they have access to the character set of course ! Thanks Philip [2004-02-13 09:29:23] [EMAIL PROTECTED] > I can provide you with JPEG files containing IIM record 1 > if required; they're quite common in the news industry. Please do :) If you can provide an URL with some images with the required fields and a txt file for the expected result. Note that I never read the charset part in any docs about IPTC standart. Have you a link that describes it? pierre [2004-02-13 06:27:10] philip at nancarrow dot net Description: The iptcparse() function (GD extension) only returns IPTC/NAA records 2 and upward, skipping past record 1. This appears to be by design, but means that the returned data is incomplete, for example the "destination" dataset 1:05 is missing. Worse that this is the fact that "coded character set" (1:90) is missing, and without this value the encoding of the data is unknown (for example if 1:90 specifies ESC,%,G the data is UTF8 encoded). I assume that the current implementation is defaulting to ASCII or Latin1 encoding. I can provide you with JPEG files containing IIM record 1 if required; they're quite common in the news industry. Thank you -- Edit this bug report at http://bugs.php.net/?id=27238&edit=1
#27513 [NEW]: strrpos() using the offset
From: asterisk at email dot it Operating system: windows xp PHP version: 4.3.4 PHP Bug Type: Strings related Bug description: strrpos() using the offset Description: when is used 3rd parameter, the offset, the function produce a warning and don't return nothing Reproduce code: --- Expected result: 1 Actual result: -- Warning: Wrong parameter count for strrpos() in C:\WWW\strrpos.php on line 4 -- Edit bug report at http://bugs.php.net/?id=27513&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27513&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27513&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27513&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27513&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27513&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27513&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27513&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27513&r=support Expected behavior: http://bugs.php.net/fix.php?id=27513&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27513&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27513&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27513&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27513&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27513&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27513&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27513&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27513&r=float
#27451 [Opn]: Losing Session vars for unknown reason
ID: 27451
User updated by: hamid at wannameet dot nl
Reported By: hamid at wannameet dot nl
Status: Open
Bug Type: Session related
Operating System: FreeBSD
PHP Version: 4.3.4
New Comment:
Here is a screenshot of my sessions db-table to prove the point of
losing session vars.
http://www.wannameet.nl/error/session_screen.gif
Previous Comments:
[2004-03-02 16:48:12] hamid at wannameet dot nl
hi idong,
yeh i find it really strange too. Also because i am not getting any
errors concerning the session itself.
And other annoying thing is the randomness of this problem, because
when i try to invoke the error it is not occuring.
So i am really lost :( ;)
Although i am starting to suspect my hostingcompany
[2004-03-02 16:36:50] hamid at wannameet dot nl
i have put my latest error_log in the directory php_bug
as you can see the session exists but sess_lang and sess_referer are
empty.
// error function
session_start();
$sess_lang = $_SESSION['lang'];
$sess_referer = $_SESSION['referer'];
$session_id = session_id();
$errorString .= "Session_id: $session_id\n";
$errorString .= "Sess_lang: $sess_lang\n";
$errorString .= "Sess_referer: $sess_referer\n";
//
the format for the include files is:
include("content/$sess_lang/filename.inc");
[2004-03-02 16:35:14] idong at gmx dot de
Hello Hamid,
Really strange...
I tried this again, after reading your comment and now I get:
lang test
1 - de
2 - en
no_lang test
1 - de
2 - en
I swear that I just copied and pastet the results of the script - both
with my first posting and now with this one.
I tried it with register_globals on and register_globals off. This is
really getting strange since you get a completely different result from
my example and me, I got a different result (than the first time) too.
Anyway, the result from my last test (see above) isn't the expected
behaviour either or am I making a mistake?
Ok, lets resume the problem at this point of time:
1. With the same example I got two different results. I changed nothing
in between, only some time went by.
2. Again, using my example, YOU got a completely different result - the
result I would have also expected from my own tests.
3. looking at my latest results, I can say that my first analysis (bug
occurs on use of "lang" as session var name) was wrong.
4. YOU have the problem, that you are "losing vars from my session
occassionaly"
Any help from the PHP crew?
Thanks a lot, idong
[2004-03-02 15:42:21] hamid at wannameet dot nl
hi idong,
i tried your example, but the result i am getting is
de
de
de
de
with register_globals Off and On
[2004-03-02 15:06:54] idong at gmx dot de
Seems to me that if it is a special problem of $_SESSION along with
session var name 'lang'. Try this:
lang test';
$_SESSION['lang'] = 'de';
echo '1 - '.$_SESSION['lang'];
$lang = 'en';
echo '2 - '.$_SESSION['lang'];
echo 'no_lang test';
$_SESSION['no_lang'] = 'de';
echo '1 - '.$_SESSION['no_lang'];
$no_lang = 'en';
echo '2 - '.$_SESSION['no_lang'];
?>
What I get is this:
lang test
1 - de
2 - en
no_lang test
1 - de
2 - de
Maybe there are some more variable names one shouldn't use with
sessions?
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/27451
--
Edit this bug report at http://bugs.php.net/?id=27451&edit=1
#25933 [Opn]: stream_select
ID: 25933 User updated by: flape at pobox dot sk Reported By: flape at pobox dot sk Status: Open Bug Type: Filesystem function related Operating System: Win2K PHP Version: 4.3.3 Assigned To: wez New Comment: Even if the files weren't selectable on Wins, it could be done anyway. good file editors notice, when the file, that is open in it, has been changet by another process... Previous Comments: [2004-03-04 12:00:21] flape at pobox dot sk With newest php5 snap I got: Warning: stream_select() [function.stream-select]: unable to select [0]: No error (max_fd=0) [2004-03-04 11:44:37] flape at pobox dot sk I experience the same problem even With 4.3.5RC4-dev. [2003-12-04 02:23:43] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-11-28 17:32:02] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Can you try using a PHP *5* snapshot (dated today)? If it works in PHP 5, I can port the changes down to PHP 4; otherwise, I don't think it will be possible to select on files under win32. [2003-11-05 10:05:41] flape at pobox dot sk I've done it in blocking and even in non-blocking mode with the same result 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/25933 -- Edit this bug report at http://bugs.php.net/?id=25933&edit=1
#27512 [Opn]: Apache 1.3.29 crashes when loading extensions
ID: 27512 User updated by: jl at lusidor dot nu Reported By: jl at lusidor dot nu Status: Open Bug Type: Apache related Operating System: Win XP pro PHP Version: 5.0.0b4 (beta4) New Comment: I forgot to mention that without any extensions enabled apache runs without any problems. Previous Comments: [2004-03-06 07:11:40] jl at lusidor dot nu Description: I'm on windows xp. I'm trying to load extensions with apache 1.3.29. I enable the extension in the php.ini. That causes apache to crash after 3 seconds without any notice in the error-log. When I try to run PHP5 by it self it loads the extension just fine. according to phpinfo. I have the following setup: /php5 (php5 directory) /program/apache-php5 (apache dir with php.ini, php5apache.dll, php5ts.dll) php.ini with the following changes include_path = ".;\php5\includes" ;extension_dir = ".\" (I've tried both) extension_dir = "\php5\ext\" extension=php_mhash.dll I've tried placing the libmhash.dll in every possible location, /windows/system32, /program/apache-php5 and /php5 dir to no avail. I have a similiar setup where I run PHP 4.3.4 as an apache mod with the identical setup loads just fine. So I see this as a bug related to running PHP5 b4 as an apache module. Reproduce code: --- Just start apache. It crashes within about 6 seconds -- Edit this bug report at http://bugs.php.net/?id=27512&edit=1
#27512 [NEW]: Apache 1.3.29 crashes when loading extensions
From: jl at lusidor dot nu Operating system: Win XP pro PHP version: 5.0.0b4 (beta4) PHP Bug Type: Apache related Bug description: Apache 1.3.29 crashes when loading extensions Description: I'm on windows xp. I'm trying to load extensions with apache 1.3.29. I enable the extension in the php.ini. That causes apache to crash after 3 seconds without any notice in the error-log. When I try to run PHP5 by it self it loads the extension just fine. according to phpinfo. I have the following setup: /php5 (php5 directory) /program/apache-php5 (apache dir with php.ini, php5apache.dll, php5ts.dll) php.ini with the following changes include_path = ".;\php5\includes" ;extension_dir = ".\" (I've tried both) extension_dir = "\php5\ext\" extension=php_mhash.dll I've tried placing the libmhash.dll in every possible location, /windows/system32, /program/apache-php5 and /php5 dir to no avail. I have a similiar setup where I run PHP 4.3.4 as an apache mod with the identical setup loads just fine. So I see this as a bug related to running PHP5 b4 as an apache module. Reproduce code: --- Just start apache. It crashes within about 6 seconds -- Edit bug report at http://bugs.php.net/?id=27512&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27512&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27512&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27512&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27512&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27512&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27512&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27512&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27512&r=support Expected behavior: http://bugs.php.net/fix.php?id=27512&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27512&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27512&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27512&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27512&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27512&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27512&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27512&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27512&r=float
#27511 [Opn]: fread crashes Apache with mistakenly big length
ID: 27511 User updated by: patrick at borgeat dot de Reported By: patrick at borgeat dot de Status: Open Bug Type: Filesystem function related Operating System: Windows 2000 SR4 PHP Version: 5.0.0b4 (beta4) New Comment: I forgot a Semikolon (;) after "echo $res", sorry! Previous Comments: [2004-03-06 04:53:43] patrick at borgeat dot de Description: As I mistakenly tried to read a very large number of bytes (1078508183) (more than are in the file) with fread, the Site doesn't react anymore and i get a apache.exe Task in my Tasklist consuming an average of 80% CPU Load (with a 1300 Mhz Machine) which can't be stopped (maybe also due to missing rights). Also the file is blocked. Never tested this on Linux, but I think if a server does this mistakenly several times at once the whole server enviroment would crash. I run Apache 2.0.48 with PHP 5.0.0b4 as Apache2 Handler on Windows 2000 SR4 on FAT32 Filesystem. Reproduce code: --- (in my case test was a textfile with the 3 Letters "AAA") Expected result: I expected PHP to be as smart (as it is with smaller numbers for example like 50 000) to write only 3 Bytes and output "AAA". Actual result: -- Apache Task isn't stopable and runs @ Average of 80% CPU Load -- Edit this bug report at http://bugs.php.net/?id=27511&edit=1
#27511 [NEW]: fread crashes Apache with mistakenly big length
From: patrick at borgeat dot de Operating system: Windows 2000 SR4 PHP version: 5.0.0b4 (beta4) PHP Bug Type: Filesystem function related Bug description: fread crashes Apache with mistakenly big length Description: As I mistakenly tried to read a very large number of bytes (1078508183) (more than are in the file) with fread, the Site doesn't react anymore and i get a apache.exe Task in my Tasklist consuming an average of 80% CPU Load (with a 1300 Mhz Machine) which can't be stopped (maybe also due to missing rights). Also the file is blocked. Never tested this on Linux, but I think if a server does this mistakenly several times at once the whole server enviroment would crash. I run Apache 2.0.48 with PHP 5.0.0b4 as Apache2 Handler on Windows 2000 SR4 on FAT32 Filesystem. Reproduce code: --- (in my case test was a textfile with the 3 Letters "AAA") Expected result: I expected PHP to be as smart (as it is with smaller numbers for example like 50 000) to write only 3 Bytes and output "AAA". Actual result: -- Apache Task isn't stopable and runs @ Average of 80% CPU Load -- Edit bug report at http://bugs.php.net/?id=27511&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27511&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27511&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27511&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27511&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27511&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27511&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27511&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27511&r=support Expected behavior: http://bugs.php.net/fix.php?id=27511&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27511&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27511&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27511&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27511&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27511&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27511&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27511&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27511&r=float
