#27471 [Opn]: variables in a function or script alter session variables
ID: 27471 Updated by: [EMAIL PROTECTED] Reported By: wxjasp02 at smumn dot edu Status: Open Bug Type: Session related Operating System: RedHat Linux 9.0 PHP Version: Irrelevant New Comment: What is register_globals set to? Previous Comments: [2004-03-02 20:30:32] wxjasp02 at smumn dot edu i altered the URL to my bug, as it was kinda hard to properly see the script as it is, the new one is: http://www.mytoast.net/phpbug.txt [2004-03-02 20:23:28] wxjasp02 at smumn dot edu Description: Whenever i use a variable declared $group or $username in a function or part of a script, and $_SESSION['group'] or $_SESSION['username'] are in a valid session, the $group or $username variables ALTER the respective $_SESSION variable by the time the script ends. This should NEVER occur. Reproduce code: --- http://www.mytoast.net/phpbug.html Expected result: It should complete all the if () statements safely, and execute them as if I were of the correct group type. Actual result: -- Basically, a $_SESSION['group'] is written to a session when a user logs in to my site. The form above, allows administrators of my site to alter user permissions and whatnot, but it seems if $group is a variable in the script, (and set), the $_SESSION['group'] gets altered to whatever that value is, and the real administrator loses all their admin privileges until they login again. This is extremely annoying. I found a workaround for the time being, but i don't like making more code than i have to... -- Edit this bug report at http://bugs.php.net/?id=27471&edit=1
#15400 [Com]: Queries Crashing PHP.EXE
ID: 15400 Comment by: sang6iru at yahoo dot com Reported By: john_woodhouse at hammond-logistics dot co dot uk Status: Closed Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.1.1 New Comment: I have the same problem,... Warning: MS SQL: Unable to connect to server: LOCAL in E:\Inetpub\wwwroot\dprd\include\koneksi.php on line 20 Warning: MS SQL message: Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection. (severity 14) in E:\Inetpub\wwwroot\dprd\include\koneksi.php on line 21 Warning: MS SQL: Unable to connect to server: (null) in E:\Inetpub\wwwroot\dprd\include\koneksi.php on line 21 Warning: MS SQL: A link to the server could not be established in E:\Inetpub\wwwroot\dprd\include\koneksi.php on line 21 >> I've fix some message : Warning: MS SQL: Unable to connect to server: (sangbiru) in E:\Inetpub\wwwroot\dprd\include\koneksi.php on line 21 by adding "sangbiru" user in > Computer Management > User&Group Management but when I try to fix this problem by adding "(null)" user, I get the message above... :( anyone could help me?? Previous Comments: [2002-04-02 04:02:44] john_woodhouse at hammond-logistics dot co dot uk Excellent.. this works... Thanks Adrian.. Ok you can close this now.. :) [2002-03-27 06:38:39] phpstuff at aweiler dot com *** SOLVED *** If the configuration option "mssql.compatability_mode" is missing, then php_mssql fails to initialize the procedure pointer for "get_column_content". Looks like a bug, but can be avoided simply by adding the configuration option: mssql.compatability_mode = Off May be it is the best to take php.ini-dist and copy the full [MSSQL] section in your active php.ini. Cheers, Adrian [2002-03-27 04:53:34] phpstuff at aweiler dot com The crash occurs only if the query returns any records. The following example crashes on the last query. All others run fine (appropriate access rights assumed ;-) Using NT4 SP5 and tried with both PHP4.1.1 and 4.1.2 [2002-03-13 14:14:25] nest at rts dot ru The same problem. Win2K Pro, PHP 4.1.2 ===PHP.INI error_reporting= E_ALL; display all errors, warnings and notices enable_dl=on extension_dir=c:\php\extensions extension=php_mssql.dll === Running from command line or as CGI results in the fatal application error. Any bug in query string results in normal PHP error message "MS SQL: Query failed in ". ODBC version works ok. [2002-02-06 09:19:17] john_woodhouse at hammond-logistics dot co dot uk the [] were just there to denote what I was putting into them 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/15400 -- Edit this bug report at http://bugs.php.net/?id=15400&edit=1
#27435 [Com]: php_mysql.dll does not work with new versions of libmysql.dll
ID: 27435 Comment by: sesamejt at hotmail dot com Reported By: raido dot valgevali at mail dot ee Status: Open Bug Type: MySQL related Operating System: Windows (all) PHP Version: 5.0.0b4 (beta4) New Comment: we know the problem. how/when do we get the recompiled version? I do not wish to go back to buggy old PHP. Any good old PHP version out there, AND doesn't result in error? Previous Comments: [2004-02-29 02:10:53] raido dot valgevali at mail dot ee Description: At least Visual Studio DLL dependency walker shows that in '5.0.0b4 win32 zip binary' the php_mysql.dll extension supports mysql_create_db() and mysql_drop_db() functions as do the mySQL 3.x client libraries. Fine. But these 2 functions are dropped in version 4.x and 5.x libmySQL.dll. So trying to use newer mysql client libraries with php5 (as suggested) results an error. In general it is a request to include both php_mysql3.dll and php_mysql45.dll in the package. Although it's sure easy to self-recompile the php_mysql.dll without these 2 functions. Additional information: Default manual install and conf of PHP5 and MySQL5 on W2K, IIS. Everything worked fine. As I needed MySQL new features (multiple recordsets), I followed the suggestions of both php.net and mysql.com and placed mysql.com provided client library libmysql.dll (version 5) into /system32. After restarting web server, get the following error at first php-file request: PHP Startup: Unable to load dynamic library 'c:\php\ext\php_mysql.dll' - The specified procedure could not be found. -- Edit this bug report at http://bugs.php.net/?id=27435&edit=1
#27476 [NEW]: Extends and parent vars
From: agigames at agigames dot com
Operating system: Windows XP
PHP version: 5.0.0b4 (beta4)
PHP Bug Type: Class/Object related
Bug description: Extends and parent vars
Description:
This problem occurs in both PHP 4.3.5RC3 and in PHP 5.0.0b4. The
constructor function of the child class does not have the proper var's set
in it from the parent class.
Reproduce code:
---
class parentclass {
public $var = 'test';
function parentclass() {
$this->var = 'test2';
}
}
class childclass extends parentclass {
function childclass() {
print $this->var;
}
}
$obj = new parentclass;
$obj2 = new childclass;
Expected result:
Well I expected it to print "test2".
Actual result:
--
But instead it prints the value that the public var was initialized as
"test".
--
Edit bug report at http://bugs.php.net/?id=27476&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27476&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27476&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27476&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27476&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27476&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27476&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27476&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27476&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27476&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27476&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27476&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27476&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27476&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27476&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27476&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27476&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27476&r=float
#27475 [Opn->Bgs]: Comparison fails for int(0) == string
ID: 27475 User updated by: tim dot lokot at printsoft dot com Reported By: tim dot lokot at printsoft dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Win2K Pro PHP Version: 4.3.4 New Comment: Just found this in the documentation ... "The value is given by the initial portion of the string. If the string starts with valid numeric data, this will be the value used. Otherwise, the value will be 0 (zero)." Not quite sure why the value zero was chosen, but hey, it's in the manual so I can live with that. Previous Comments: [2004-03-02 23:01:31] tim dot lokot at printsoft dot com Description: For some reason I cannot compare the integer zero to a string and get a valid response back. There are two ways that I can see to fix it: 1. Use the === operator 2. Typecast the integer to a string Both of the above solutions work, yet for some reason, the == comparison operator doesn't. Reproduce code: --- Expected result: int(0) Is not equal Actual result: -- int(0) Equals -- Edit this bug report at http://bugs.php.net/?id=27475&edit=1
#27474 [Opn]: 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: Open Bug Type: Win32API related Operating System: Windows2003 PHP Version: 4.3.4 New Comment: by the way,I downloaded new CVS version Built On: Mar 03, 2004 01:30 GMT,It always has same error results. Previous Comments: [2004-03-02 22:45:02] azsd at hotmail dot com Description: Dear developers: When I try to use w32api_register_function in my php test scripts comes from orginal phpmanel like this: It reports a fetal error like this: Fatal error: Call to undefined function: w32api_register_function() in E:\My Webs\\apitest.php on line 2 I am using 4.3.4 stable version of PHP. in php.ini set extension=php_w32api.dll and phpinfo() shows Win32 API Win32 API Support enabled other extension like gdlib works fine. My web server is IIS6,Windows 2003,Use ISAPI mode of PHP. some other guys using these version occoured same errors. somebody told me this win32api functions only works in older php version like php4.0.0,is that ture? or how can i get the functions back in PHP Version 4.3.4? thanks. Reproduce code: --- Expected result: popup a message box with title:Hello world Actual result: -- Fatal error: Call to undefined function: w32api_register_function() in E:\My Webs\\apitest.php on line 2 -- Edit this bug report at http://bugs.php.net/?id=27474&edit=1
#27475 [NEW]: Comparison fails for int(0) == string
From: tim dot lokot at printsoft dot com Operating system: Win2K Pro PHP version: 4.3.4 PHP Bug Type: Scripting Engine problem Bug description: Comparison fails for int(0) == string Description: For some reason I cannot compare the integer zero to a string and get a valid response back. There are two ways that I can see to fix it: 1. Use the === operator 2. Typecast the integer to a string Both of the above solutions work, yet for some reason, the == comparison operator doesn't. Reproduce code: --- Expected result: int(0) Is not equal Actual result: -- int(0) Equals -- Edit bug report at http://bugs.php.net/?id=27475&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27475&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27475&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27475&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27475&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27475&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27475&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27475&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27475&r=support Expected behavior: http://bugs.php.net/fix.php?id=27475&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27475&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27475&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27475&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27475&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27475&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27475&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27475&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27475&r=float
#27474 [NEW]: w32api_register_function missed in newer version php?
From: azsd at hotmail dot com Operating system: Windows2003 PHP version: 4.3.4 PHP Bug Type: Win32API related Bug description: w32api_register_function missed in newer version php? Description: Dear developers: When I try to use w32api_register_function in my php test scripts comes from orginal phpmanel like this: It reports a fetal error like this: Fatal error: Call to undefined function: w32api_register_function() in E:\My Webs\\apitest.php on line 2 I am using 4.3.4 stable version of PHP. in php.ini set extension=php_w32api.dll and phpinfo() shows Win32 API Win32 API Support enabled other extension like gdlib works fine. My web server is IIS6,Windows 2003,Use ISAPI mode of PHP. some other guys using these version occoured same errors. somebody told me this win32api functions only works in older php version like php4.0.0,is that ture? or how can i get the functions back in PHP Version 4.3.4? thanks. Reproduce code: --- Expected result: popup a message box with title:Hello world Actual result: -- Fatal error: Call to undefined function: w32api_register_function() in E:\My Webs\\apitest.php on line 2 -- Edit bug report at http://bugs.php.net/?id=27474&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27474&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27474&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27474&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27474&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27474&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27474&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27474&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27474&r=support Expected behavior: http://bugs.php.net/fix.php?id=27474&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27474&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27474&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27474&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27474&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27474&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27474&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27474&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27474&r=float
#27472 [NEW]: Segfault with dom nodelist and new domelement
From: info at rhalff dot com
Operating system: linux
PHP version: 5.0.0b4 (beta4)
PHP Bug Type: Reproducible crash
Bug description: Segfault with dom nodelist and new domelement
Description:
Just running the class Bug will work.
But running Segvault after that will crash the running
process.
The part causing problems is the coexistence of the
nodelist assignement to $k and a new domelement being
assigned to a property inside another class.
Reproduce code:
---
start();
$segv = new Segvault();
$segv->now();
class Segvault {
function now() {
/* These will work: */
// $x = new domdocument;
// $this->x = new stdClass;
/* This segvaults */
$this->x = new domdocument;
//$this->x = new domelement;
}
}
class Bug
{
function start()
{
$dom = new domdocument;
$dom->loadXml("");
//This works:
//echo $dom->getElementsByTagname('bug')->lenght;
$k = $dom->getElementsByTagname('bug');
echo $k->length;
}
}
?>
Expected result:
1
Actual result:
--
[EMAIL PROTECTED]:/www/hosts/www.rhalff.com/php5/test#
gdb /usr/sbin/httpd
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show
warranty" for details.
This GDB was configured as "i386-slackware-linux"...(no
debugging symbols found)...
(gdb) run -X -k start -f /etc/apache2/php5/httpd.conf
Starting program: /usr/sbin/httpd -X -k start
-f /etc/apache2/php5/httpd.conf
(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...
(no debugging symbols found)...[New Thread 1024 (LWP
16650)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 16650)]
0x40660790 in zend_get_extension ()
from /usr/lib/apache2/libphp5.so
(gdb) bt
#0 0x40660790 in zend_get_extension ()
from /usr/lib/apache2/libphp5.so
#1 0x40661d74 in zend_hash_destroy ()
from /usr/lib/apache2/libphp5.so
#2 0x404ea31b in dom_objects_free_storage ()
from /usr/lib/apache2/libphp5.so
#3 0x4066fa9b in zend_objects_store_del_ref ()
from /usr/lib/apache2/libphp5.so
#4 0x406588ec in _zval_dtor ()
from /usr/lib/apache2/libphp5.so
#5 0x4064f0c5 in _zval_ptr_dtor ()
from /usr/lib/apache2/libphp5.so
#6 0x40658c7a in _zval_ptr_dtor_wrapper ()
from /usr/lib/apache2/libphp5.so
#7 0x40661da7 in zend_hash_destroy ()
from /usr/lib/apache2/libphp5.so
#8 0x4066d03f in zend_objects_free_object_storage ()
from /usr/lib/apache2/libphp5.so
#9 0x4066f8d9 in zend_objects_store_free_object_storage
() from /usr/lib/apache2/libphp5.so
#10 0x4064ee09 in shutdown_executor ()
from /usr/lib/apache2/libphp5.so
#11 0x4065a1f5 in zend_deactivate ()
from /usr/lib/apache2/libphp5.so
#12 0x4061f038 in php_request_shutdown ()
from /usr/lib/apache2/libphp5.so
#13 0x406a4bf4 in zend_init_opcodes_handlers ()
from /usr/lib/apache2/libphp5.so
#14 0x406a5120 in zend_init_opcodes_handlers ()
from /usr/lib/apache2/libphp5.so
#15 0x806b7d9 in ap_run_handler () at eval.c:88
#16 0x806bd23 in ap_invoke_handler () at eval.c:88
#17 0x8069036 in ap_process_request () at eval.c:88
#18 0x80650aa in _start () at eval.c:88
#19 0x8073a28 in ap_run_process_connection () at eval.c:88
#20 0x8073ccc in ap_process_connection () at eval.c:88
#21 0x806a4b0 in ap_graceful_stop_signalled () at
eval.c:88
#22 0x806a56c in ap_graceful_stop_signalled () at
eval.c:88
#23 0x806a661 in ap_graceful_stop_signalled () at
eval.c:88
#24 0x806a95c in ap_mpm_run () at eval.c:88
#25 0x806ffee in main () at eval.c:88
#26 0x402c92eb in __libc_start_main (main=0x806f870
, argc=6, ubp_av=0xbb14, init=0x8062450 <_init>,
fini=0x808678c <_fini>,
rtld_fini=0x4000c130 <_dl_fini>, stack_end=0xbb0c)
at ../sysdeps/generic/libc-start.c:129
(gdb)
--
Edit bug report at http://bugs.php.net/?id=27472&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27472&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27472&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27472&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27472&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27472&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27472&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27472&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27472&r=support
Expected behavior: http://bugs.php.net/fix.php?id=2747
#27471 [Opn]: variables in a function or script alter session variables
ID: 27471 User updated by: wxjasp02 at smumn dot edu Reported By: wxjasp02 at smumn dot edu Status: Open Bug Type: Session related Operating System: RedHat Linux 9.0 PHP Version: Irrelevant New Comment: i altered the URL to my bug, as it was kinda hard to properly see the script as it is, the new one is: http://www.mytoast.net/phpbug.txt Previous Comments: [2004-03-02 20:23:28] wxjasp02 at smumn dot edu Description: Whenever i use a variable declared $group or $username in a function or part of a script, and $_SESSION['group'] or $_SESSION['username'] are in a valid session, the $group or $username variables ALTER the respective $_SESSION variable by the time the script ends. This should NEVER occur. Reproduce code: --- http://www.mytoast.net/phpbug.html Expected result: It should complete all the if () statements safely, and execute them as if I were of the correct group type. Actual result: -- Basically, a $_SESSION['group'] is written to a session when a user logs in to my site. The form above, allows administrators of my site to alter user permissions and whatnot, but it seems if $group is a variable in the script, (and set), the $_SESSION['group'] gets altered to whatever that value is, and the real administrator loses all their admin privileges until they login again. This is extremely annoying. I found a workaround for the time being, but i don't like making more code than i have to... -- Edit this bug report at http://bugs.php.net/?id=27471&edit=1
#27471 [NEW]: variables in a function or script alter session variables
From: wxjasp02 at smumn dot edu Operating system: RedHat Linux 9.0 PHP version: Irrelevant PHP Bug Type: Session related Bug description: variables in a function or script alter session variables Description: Whenever i use a variable declared $group or $username in a function or part of a script, and $_SESSION['group'] or $_SESSION['username'] are in a valid session, the $group or $username variables ALTER the respective $_SESSION variable by the time the script ends. This should NEVER occur. Reproduce code: --- http://www.mytoast.net/phpbug.html Expected result: It should complete all the if () statements safely, and execute them as if I were of the correct group type. Actual result: -- Basically, a $_SESSION['group'] is written to a session when a user logs in to my site. The form above, allows administrators of my site to alter user permissions and whatnot, but it seems if $group is a variable in the script, (and set), the $_SESSION['group'] gets altered to whatever that value is, and the real administrator loses all their admin privileges until they login again. This is extremely annoying. I found a workaround for the time being, but i don't like making more code than i have to... -- Edit bug report at http://bugs.php.net/?id=27471&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27471&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27471&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27471&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27471&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27471&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27471&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27471&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27471&r=support Expected behavior: http://bugs.php.net/fix.php?id=27471&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27471&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27471&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27471&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27471&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27471&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27471&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27471&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27471&r=float
#27469 [Opn]: zend_variables.c problem
ID: 27469
User updated by: friosa at pnpitalia dot it
Reported By: friosa at pnpitalia dot it
Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Linux 2.4.18-4GB
PHP Version: 5.0.0b4 (beta4)
New Comment:
Trying to make a short script I think to have seen a different bug in
the serialize function, this time the code to reproduce it is a lot
shorter:
buildMessagePart($mime_part);
/* @constant MIME_CONTENTS_CACHE The name of the URL parameter that
holds the MIME_Contents cache identifier. */
define('MIME_CONTENTS_CACHE', 'mimecache');
class MIME_Contents {
function MIME_Contents($messageOb, $viewID = array(), $contents =
array()) {}
function buildMessagePart(&$mime_part)
{
$msg = '';
// CRASH HERE
echo "" . addslashes(serialize($mime_part)) . "";
return $msg;
}
}
class IMP_Contents extends MIME_Contents {
function IMP_Contents($index)
{
}
}
?>
backtrace:
(gdb) run -X -f /TEST/apache/conf/httpd.conf
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /TEST/apache/bin/httpd -X -f
/TEST/apache/conf/httpd.conf
[New Thread 1024 (LWP 26563)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 26563)]
0x4035080f in memcpy () from /lib/libc.so.6
(gdb) bt
#0 0x4035080f in memcpy () from /lib/libc.so.6
#1 0x405f8b0b in php_var_serialize_class_name (buf=0xbfffc69c,
struc=0x16f1520) at /TEST/php5-200403022230/ext/standard/var.c:480
#2 0x40698d73 in zend_do_fcall_common_helper (execute_data=0xbfffca10,
opline=0xbfffc695, op_array=0xa) at
/TEST/php5-200403022230/Zend/zend_execute.c:2677
#3 0x406703b9 in zend_execute_scripts (type=1081403672,
retval=0x40d0936c, file_count=516) at
/TEST/php5-200403022230/Zend/zend.c:1041
(gdb)
It's the case to open another bug or they depend from the same source
?
In every case I think It's best speak about it tommorrow err.. today
after a good sleep.
Previous Comments:
[2004-03-02 18:33:15] friosa at pnpitalia dot it
Not so easy bring out 20 lines of code from a project like horde + imp
+ other (Megs of code). It was hard for me find the right point to look
for.
I will try but I think that it will be impossible for me.
Also the fact that var_dump and print_r change the flow of the script
make me think that there is something in the object variable that make
the difference.
P.S.
I've tryed the latest cvs snapshot with this results (!= the
previous):
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 26281)]
0x4067659b in _zend_is_inconsistent (ht=0x100, file=0x406f1520
"/TEST/php5-200403022230/Zend/zend_hash.c", line=504)
at /TEST/php5-200403022230/Zend/zend_hash.c:53
53 if (ht->inconsistent==HT_OK) {
(gdb) bt
#0 0x4067659b in _zend_is_inconsistent (ht=0x100, file=0x406f1520
"/TEST/php5-200403022230/Zend/zend_hash.c", line=504)
at /TEST/php5-200403022230/Zend/zend_hash.c:53
#1 0x0010 in ?? ()
#2 0x40698d73 in zend_do_fcall_common_helper (execute_data=0x100,
opline=0x40730980, op_array=0x4074eb40)
at /TEST/php5-200403022230/Zend/zend_execute.c:2677
#3 0x40698d73 in zend_do_fcall_common_helper (execute_data=0x100,
opline=0x40730980, op_array=0x4074eb40)
at /TEST/php5-200403022230/Zend/zend_execute.c:2677
#4 0x40698d73 in zend_do_fcall_common_helper (execute_data=0x100,
opline=0x40730980, op_array=0x4074eb40)
at /TEST/php5-200403022230/Zend/zend_execute.c:2677
#5 0x40698d73 in zend_do_fcall_common_helper (execute_data=0x100,
opline=0x40730980, op_array=0x4074eb40)
at /TEST/php5-200403022230/Zend/zend_execute.c:2677
#6 0x40698d73 in zend_do_fcall_common_helper (execute_data=0x100,
opline=0x40730980, op_array=0x4074eb40)
at /TEST/php5-200403022230/Zend/zend_execute.c:2677
#7 0x40698d73 in zend_do_fcall_common_helper (execute_data=0x100,
opline=0x40730980, op_array=0x4074eb40)
at /TEST/php5-200403022230/Zend/zend_execute.c:2677
#8 0x406703b9 in zend_execute_scripts (type=256, retval=0x4127cb4c,
file_count=1) at /TEST/php5-200403022230/Zend/zend.c:1041
(gdb)
[2004-03-02 18:20:14] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
[2004-03-02 18:00:40] friosa at pnpitalia dot it
Description:
I c
#27469 [Fbk->Opn]: zend_variables.c problem
ID: 27469
User updated by: friosa at pnpitalia dot it
Reported By: friosa at pnpitalia dot it
-Status: Feedback
+Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Linux 2.4.18-4GB
PHP Version: 5.0.0b4 (beta4)
New Comment:
Not so easy bring out 20 lines of code from a project like horde + imp
+ other (Megs of code). It was hard for me find the right point to look
for.
I will try but I think that it will be impossible for me.
Also the fact that var_dump and print_r change the flow of the script
make me think that there is something in the object variable that make
the difference.
P.S.
I've tryed the latest cvs snapshot with this results (!= the
previous):
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 26281)]
0x4067659b in _zend_is_inconsistent (ht=0x100, file=0x406f1520
"/TEST/php5-200403022230/Zend/zend_hash.c", line=504)
at /TEST/php5-200403022230/Zend/zend_hash.c:53
53 if (ht->inconsistent==HT_OK) {
(gdb) bt
#0 0x4067659b in _zend_is_inconsistent (ht=0x100, file=0x406f1520
"/TEST/php5-200403022230/Zend/zend_hash.c", line=504)
at /TEST/php5-200403022230/Zend/zend_hash.c:53
#1 0x0010 in ?? ()
#2 0x40698d73 in zend_do_fcall_common_helper (execute_data=0x100,
opline=0x40730980, op_array=0x4074eb40)
at /TEST/php5-200403022230/Zend/zend_execute.c:2677
#3 0x40698d73 in zend_do_fcall_common_helper (execute_data=0x100,
opline=0x40730980, op_array=0x4074eb40)
at /TEST/php5-200403022230/Zend/zend_execute.c:2677
#4 0x40698d73 in zend_do_fcall_common_helper (execute_data=0x100,
opline=0x40730980, op_array=0x4074eb40)
at /TEST/php5-200403022230/Zend/zend_execute.c:2677
#5 0x40698d73 in zend_do_fcall_common_helper (execute_data=0x100,
opline=0x40730980, op_array=0x4074eb40)
at /TEST/php5-200403022230/Zend/zend_execute.c:2677
#6 0x40698d73 in zend_do_fcall_common_helper (execute_data=0x100,
opline=0x40730980, op_array=0x4074eb40)
at /TEST/php5-200403022230/Zend/zend_execute.c:2677
#7 0x40698d73 in zend_do_fcall_common_helper (execute_data=0x100,
opline=0x40730980, op_array=0x4074eb40)
at /TEST/php5-200403022230/Zend/zend_execute.c:2677
#8 0x406703b9 in zend_execute_scripts (type=256, retval=0x4127cb4c,
file_count=1) at /TEST/php5-200403022230/Zend/zend.c:1041
(gdb)
Previous Comments:
[2004-03-02 18:20:14] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
[2004-03-02 18:00:40] friosa at pnpitalia dot it
Description:
I continue to get a core dump using imp with imap from the horde
project.
The crash is reproducible but the gdb backtrace has changed after i've
inserted the debug code.
Also I think it's important to mention that if u substitute the
"var_dump()" code below with "print_r()" the crash disappear !!!
so we can switch this three cases:
case "code without debug": crash();
case "code with vardump($mime_part)": crash();
case "code with print_r($mime_part)": --> continue (but I can't still
see the page)
If I can help with something else please contact me, I' will keep a
copy of the code, also I can send U a tar.gz of all this stuff (may be
not usefull with my conf.)
follow:
PHP compiling flags
APACHE
PRINT_R
VARDUMP
*
* PHP compiling flags
*
CFLAGS = CPPFLAGS = -march=k6 -O0 -pipe -fomit-frame-pointer -I[...]
./configure \
--prefix=/TEST/php \
--with-apxs2=/TEST/apache/bin/apxs \
--with-config-file-path=/TEST/php/lib/php.ini \
--with-informix=/opt/informix \
--with-mysql=/pnp/mysql \
--with-mysql-sock=/tmp/mysql.sock \
--enable-libgcc \
--with-curl=/pnp \
--disable-ipv6 \
--enable-ftp \
--with-openssl=/pnp \
--with-gd \
--enable-gd-native-ttf \
--with-zlib-dir=/usr \
--with-jpeg-dir=/usr \
--enable-exif \
--with-tiff-lib=/usr \
--with-png-dir=/usr \
--with-freetype-dir=/usr \
--with-pdflib=/TEST \
--enable-bcmath \
--enable-shmop \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--enable-mime-magic \
--with-qtdom \
--enable-pcntl \
--enable-sockets \
--x-includes=/usr/X11/include/X11 \
--x-libraries=/usr/X11/lib \
--with-readline \
--with-gnu-ld \
--enable-static \
--with-gettext \
--with-libxml-dir=/TEST \
--with-xml=/TEST \
--with-dom=/TEST \
--with-xsl=/TEST \
--with-dom-xslt=/TEST \
--with-dom-exslt=
#27470 [NEW]: Unexpected content of an array generated by the dbase_get_record()
From: carlos at qualinfo dot com dot br
Operating system: Linux MDK9.1 / WindowsXP PRO SP1
PHP version: 4.3.4
PHP Bug Type: dBase related
Bug description: Unexpected content of an array generated by the dbase_get_record()
Description:
This bug already was reported (bug # 4244), but was closed due to missing
user feedback.
When I try to print the content of an array - created for the functions
dbase_get_records() or dbase_get_records_by_name(), script returns trash
(each time a different trash).
Notes:
(1) This problem does not happen with all archives DBF that I try to
list;
(2) The archives (.DBF) are not corrupted;
(3) The garbage that appears includes, also, parts of proper script PHP
(parts of functions, variable, etc.);
(4) In both the tested operational systems (Windows and Linux), the result
is the same;
(5) Another version of the PHP was used (4.3.2), the result was the same;
Linux:
./configure --prefix=/usr/local/php
--with-apxs2=/usr/local/apache2/bin/apxs --with-mysql --with-dbase
Windows:
Default with php_dbase.dll.
(sorry for bad english)
Reproduce code:
---
$dbname1 = "/usr/temp/AAPFUN01.DBF";
$con1 = dbase_open($dbname1,0);
$rows = dbase_numrecords($con1);
$fields = dbase_numfields($con1);
for ($i=1;$i<=$rows;$i++) {
$registro = dbase_get_record($con1,$i) or die("erro");
for ($x=0; $x < $fields; $x++) {
$teste = $registro[$x];
echo($teste . "");
}
}
dbase_close($con1);
Expected result:
For example, in key #17 of the array, the expected result:
'20020301' (date type field)
Actual result:
--
But the actual result is:
'2002030119950901011 0.000 0 240.00
160.001422021975081110 020245AL 15 49800238163644712550714425
...(etc.)'
(this result is the rest of the fields (keys) concatenated. the next key
is trash, until the end of array).
--
Edit bug report at http://bugs.php.net/?id=27470&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27470&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27470&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27470&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27470&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27470&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27470&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27470&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27470&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27470&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27470&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27470&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27470&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27470&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27470&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27470&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27470&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27470&r=float
#27469 [Opn->Fbk]: zend_variables.c problem
ID: 27469
Updated by: [EMAIL PROTECTED]
Reported By: friosa at pnpitalia dot it
-Status: Open
+Status: Feedback
Bug Type: Zend Engine 2 problem
Operating System: Linux 2.4.18-4GB
PHP Version: 5.0.0b4 (beta4)
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
Previous Comments:
[2004-03-02 18:00:40] friosa at pnpitalia dot it
Description:
I continue to get a core dump using imp with imap from the horde
project.
The crash is reproducible but the gdb backtrace has changed after i've
inserted the debug code.
Also I think it's important to mention that if u substitute the
"var_dump()" code below with "print_r()" the crash disappear !!!
so we can switch this three cases:
case "code without debug": crash();
case "code with vardump($mime_part)": crash();
case "code with print_r($mime_part)": --> continue (but I can't still
see the page)
If I can help with something else please contact me, I' will keep a
copy of the code, also I can send U a tar.gz of all this stuff (may be
not usefull with my conf.)
follow:
PHP compiling flags
APACHE
PRINT_R
VARDUMP
*
* PHP compiling flags
*
CFLAGS = CPPFLAGS = -march=k6 -O0 -pipe -fomit-frame-pointer -I[...]
./configure \
--prefix=/TEST/php \
--with-apxs2=/TEST/apache/bin/apxs \
--with-config-file-path=/TEST/php/lib/php.ini \
--with-informix=/opt/informix \
--with-mysql=/pnp/mysql \
--with-mysql-sock=/tmp/mysql.sock \
--enable-libgcc \
--with-curl=/pnp \
--disable-ipv6 \
--enable-ftp \
--with-openssl=/pnp \
--with-gd \
--enable-gd-native-ttf \
--with-zlib-dir=/usr \
--with-jpeg-dir=/usr \
--enable-exif \
--with-tiff-lib=/usr \
--with-png-dir=/usr \
--with-freetype-dir=/usr \
--with-pdflib=/TEST \
--enable-bcmath \
--enable-shmop \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--enable-mime-magic \
--with-qtdom \
--enable-pcntl \
--enable-sockets \
--x-includes=/usr/X11/include/X11 \
--x-libraries=/usr/X11/lib \
--with-readline \
--with-gnu-ld \
--enable-static \
--with-gettext \
--with-libxml-dir=/TEST \
--with-xml=/TEST \
--with-dom=/TEST \
--with-xsl=/TEST \
--with-dom-xslt=/TEST \
--with-dom-exslt=/TEST \
--with-mcrypt=/pnp \
--with-imap \
--enable-debug \
&& make && make install
*
* APACHE
*
./httpd -V
Server version: Apache/2.1.0-dev
Server built: Jan 26 2004 12:02:10
Server's Module Magic Number: 20030821:3
Architecture: 32-bit
Server MPM: Prefork
threaded: no
forked: yes (variable process count)
Server compiled with
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/TEST/apache"
-D SUEXEC_BIN="/TEST/apache/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
*
* PRINT_R
*
MIME_Message Object
(
[_build] => 1
[_defaultServer] => www2.pnp
[_type] => text
[_subtype] => Array
(
[download] => download_attach
[view] => view_attach
)
[_contents] =>
[_transferEncoding] => 7bit
[_encode7bit] => 1
[_description] =>
[_disposition] => inline
[_dispositionParameters] => Array
(
)
[_contentTypeParameters] => 0
*
* VARDUMP
*
object(MIME_Message)#19 (19) {
["_build"]=>
bool(true)
["_defaultServer"]=>
string(8) "www2.pnp"
["_type"]=>
string(4) "text"
["_subtype"]=>
array(2) {
["download"]=>
string(15) "download_attach"
["view"]=>
string(11) "view_attach"
}
["_contents"]=>
string(0) ""
["_transferEncoding"]=>
string(4) "7bit"
["_encode7bit"]=>
bool(true)
["_description"]=>
string(0) ""
["_disposition"]=>
string(6) "inline"
["_dis
#16960 [Csd]: [Sybase-CT] sybase_fetch_row() and types
ID: 16960 Updated by: [EMAIL PROTECTED] Reported By: thekid at thekid dot de Status: Closed Bug Type: Feature/Change Request Operating System: All PHP Version: 4.0CVS-2002-05-02 Assigned To: thekid New Comment: Regarding the new behaviour of sybase_fetch_array() with multiple keys, use the following patch to accomplish pre-4.3.0 behaviour: http://sitten-polizei.de/php/sybase_bc.patch Previous Comments: [2003-11-17 10:43:33] alex dot bazan at bcn dot concatel dot com Hello, I was recently shocked when I discovered the implementation of Sybase "identical fields". The PHP manual for sybase_fetch_array() reads: Note: When selecting fields with identical names (for instance, in a join), the associative indices will have a sequential number prepended. See the example for details. I would like to say that I am against implementing these sort of repetitive field returns. If a programmer wants multiple (identically named) fields returned, they can always modify their SQL statement to reflect unique field names: select t1.id as id1, t2.id as id2 from t1,t2 PHP should NOT be mangling field names returned from the database driver, it should simply return the name-value of the LAST field of any given name. However, if this is to be kept in the code, there are a few important considerations that should be taken into account regarding the implementation: 1st. Upgading PHP. There are loads of cases where you can find in a database different tables with some identical field names. I know this is poor database design, but sometimes you find that you have to work with a design where this occurs. With this new feature on sybase_fetch_array() all the code where one just assumed that the returned value for field X was from the last table selected, MUST BE RE-WRITTEN. 2nd. IMHO, the implementation of this feature is very poor. When you have a JOIN over two tables and they have more that one field with the same name: table A: id date user afield table B: id date user bfield the resulting join will result in id date user id1 date2 user3 afield bfield A single numeric index is incremented for all repetitive fields, making it impossible to make it dynamic. (if you made a select using different fields you will get different field names!!!) I suggest correcting this implementation to return field names as follows: id date user id1 date1 user1 afield bfield One counter for each repeated field instead of one unique counter for ALL fields. 3rd. Last but not least... This is a feature only implemented in Sybase library functions, so when creating cross-db applications, it is much more difficult to implement generic code. I would appreciate hearing from the PHP Team about this. Thanks in advance, Alex Bazan [2002-11-05 15:07:33] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Committed numerous changes to ext/sybase_ct, see CVS log for ext/sybase_ct/php_sybase_ct.c and ext/sybase_ct/php_sybase_ct.h [2002-06-10 18:43:18] thekid at thekid dot de Sorry, here's an example script for sybase_set_message_handler(): The output is: Caught Sybase Server Message #137 [Severity 15, state 2] at line 1 'Must declare variable '@does_not_exist'.' Warning: Sybase: Server message #257: Implicit conversion from datatype 'VARCHAR' to 'NUMERIC' is not allowed. Use the CONVERT function to run this query. (severity 16, procedure N/A) in /usr/home/thekid/devel/php/sybase_test.php on line 23 [2002-06-10 15:50:15] thekid at thekid dot de With this last patch, you will be able to handle all of sybase's error messages via a callback function. This comes in quite handy when having to check for deadlocks (the 1205:-)). $deadlock= strstr($php_errormsg, 'deadlock'); is, of course, possible right now, but in my eyes not a very generalistic way of going about it... --- php4-200205012100/ext/sybase_ct/php_sybase_ct.h Thu Feb 28 09:38:19 2002 +++ __build__/ext/sybase_ct/php_sybase
#27469 [NEW]: zend_variables.c problem
From: friosa at pnpitalia dot it
Operating system: Linux 2.4.18-4GB
PHP version: 5.0.0b4 (beta4)
PHP Bug Type: Zend Engine 2 problem
Bug description: zend_variables.c problem
Description:
I continue to get a core dump using imp with imap from the horde project.
The crash is reproducible but the gdb backtrace has changed after i've
inserted the debug code.
Also I think it's important to mention that if u substitute the
"var_dump()" code below with "print_r()" the crash disappear !!!
so we can switch this three cases:
case "code without debug": crash();
case "code with vardump($mime_part)": crash();
case "code with print_r($mime_part)": --> continue (but I can't still see
the page)
If I can help with something else please contact me, I' will keep a copy
of the code, also I can send U a tar.gz of all this stuff (may be not
usefull with my conf.)
follow:
PHP compiling flags
APACHE
PRINT_R
VARDUMP
*
* PHP compiling flags
*
CFLAGS = CPPFLAGS = -march=k6 -O0 -pipe -fomit-frame-pointer -I[...]
./configure \
--prefix=/TEST/php \
--with-apxs2=/TEST/apache/bin/apxs \
--with-config-file-path=/TEST/php/lib/php.ini \
--with-informix=/opt/informix \
--with-mysql=/pnp/mysql \
--with-mysql-sock=/tmp/mysql.sock \
--enable-libgcc \
--with-curl=/pnp \
--disable-ipv6 \
--enable-ftp \
--with-openssl=/pnp \
--with-gd \
--enable-gd-native-ttf \
--with-zlib-dir=/usr \
--with-jpeg-dir=/usr \
--enable-exif \
--with-tiff-lib=/usr \
--with-png-dir=/usr \
--with-freetype-dir=/usr \
--with-pdflib=/TEST \
--enable-bcmath \
--enable-shmop \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--enable-mime-magic \
--with-qtdom \
--enable-pcntl \
--enable-sockets \
--x-includes=/usr/X11/include/X11 \
--x-libraries=/usr/X11/lib \
--with-readline \
--with-gnu-ld \
--enable-static \
--with-gettext \
--with-libxml-dir=/TEST \
--with-xml=/TEST \
--with-dom=/TEST \
--with-xsl=/TEST \
--with-dom-xslt=/TEST \
--with-dom-exslt=/TEST \
--with-mcrypt=/pnp \
--with-imap \
--enable-debug \
&& make && make install
*
* APACHE
*
./httpd -V
Server version: Apache/2.1.0-dev
Server built: Jan 26 2004 12:02:10
Server's Module Magic Number: 20030821:3
Architecture: 32-bit
Server MPM: Prefork
threaded: no
forked: yes (variable process count)
Server compiled with
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT="/TEST/apache"
-D SUEXEC_BIN="/TEST/apache/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
*
* PRINT_R
*
MIME_Message Object
(
[_build] => 1
[_defaultServer] => www2.pnp
[_type] => text
[_subtype] => Array
(
[download] => download_attach
[view] => view_attach
)
[_contents] =>
[_transferEncoding] => 7bit
[_encode7bit] => 1
[_description] =>
[_disposition] => inline
[_dispositionParameters] => Array
(
)
[_contentTypeParameters] => 0
*
* VARDUMP
*
object(MIME_Message)#19 (19) {
["_build"]=>
bool(true)
["_defaultServer"]=>
string(8) "www2.pnp"
["_type"]=>
string(4) "text"
["_subtype"]=>
array(2) {
["download"]=>
string(15) "download_attach"
["view"]=>
string(11) "view_attach"
}
["_contents"]=>
string(0) ""
["_transferEncoding"]=>
string(4) "7bit"
["_encode7bit"]=>
bool(true)
["_description"]=>
string(0) ""
["_disposition"]=>
string(6) "inline"
["_dispositionParameters"]=>
array(0) {
}
["_contentTypeParameters"]=>
&UNKNOWN:0
["_parts"]=>
array(0) {
}
["_information"]=>
UNKNOWN:0
["_bytes"]=>
object(MIME_Message)#19 (19) {
["_build"]=>
bool(true)
["_defaultServer"]=>
string(8) "www2.pnp"
["_type"]=>
string(4) "text"
["_subtype"]=>
array(2) {
["download"]=>
string(15) "download_attach"
["view"]=>
string(11) "view_attach"
}
["_contents"]=>
string(0) ""
["_transferEncoding"]=>
string(4) "7bit"
["_encode7bit"]=>
bool(true)
["_description"]=>
string(0) ""
#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:
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
Previous Comments:
[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?
[2004-03-02 05:35:37] hamid at wannameet dot nl
the include files could not be opened because sess_lang was empty, but
i changed my error reporting so that it will capture session_id en
sess_lang. You will receive the new log file as soon as it has some
entries.
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
#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:
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");
Previous Comments:
[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?
[2004-03-02 05:35:37] hamid at wannameet dot nl
the include files could not be opened because sess_lang was empty, but
i changed my error reporting so that it will capture session_id en
sess_lang. You will receive the new log file as soon as it has some
entries.
[2004-03-02 03:05:31] [EMAIL PROTECTED]
That error log only shows that some files can not be opened, and
sessions work fine for almost anybody (we had no other bug reports like
this), so can you show something that proves your point in the form of
a log?
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
#27451 [Com]: Losing Session vars for unknown reason
ID: 27451 Comment by: idong at gmx dot de Reported By: hamid at wannameet dot nl Status: Open Bug Type: Session related Operating System: FreeBSD PHP Version: 4.3.4 New Comment: 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 Previous Comments: [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? [2004-03-02 05:35:37] hamid at wannameet dot nl the include files could not be opened because sess_lang was empty, but i changed my error reporting so that it will capture session_id en sess_lang. You will receive the new log file as soon as it has some entries. [2004-03-02 03:05:31] [EMAIL PROTECTED] That error log only shows that some files can not be opened, and sessions work fine for almost anybody (we had no other bug reports like this), so can you show something that proves your point in the form of a log? [2004-03-01 19:07:07] hamid at wannameet dot nl i have also put the error_log of yesterday in the directory bug_php, for extra info 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
#27466 [Opn->Bgs]: fread bug reading large block of data from a socket
ID: 27466
Updated by: [EMAIL PROTECTED]
Reported By: tleaver at synchronics dot com
-Status: Open
+Status: Bogus
Bug Type: Sockets related
Operating System: Windows XP
PHP Version: 4.3.4
New Comment:
>From http://www.php.net/fread
--
fread() reads up to length bytes from the file pointer referenced by
handle. Reading stops when length bytes have been read, EOF (end of
file) is reached, or (for network streams) when a packet becomes
available, whichever comes first.
--
The length parameter for fread is a MAXIMUM length to be read, not a
minimum or an exact.
If you're expecting a specific number of bytes, you should use a loop
to repeatedly call fread() each itteration of which returns a new
network packet.
Note also that this is a duplicate bug report. The exact behavior you
describe has been reported and documented on bugs.php.net already.
Previous Comments:
[2004-03-02 13:48:49] tleaver at synchronics dot com
Description:
We have a commercial PHP-based product, basically a web app which
interfaces with our Counterpoint point of sale product, and is designed
to run on wireless handheld devices.
Communications with Counterpoint is handled via an application server,
which we communicate with from PHP via a socket connection.
Of the different types of messages we pass back and forth between PHP
and the application server, is a transaction describing a complex item
with multiple dimensions (size, color, etc). When retreiving this
large block of data from the socket using fread, we get unexpected
data.
Each packet which is exchanged consists of a beginning 1 byte marker
("\x02") which denotes the beginning of a package, followed by a
protocol version (internal designator), followed by 2 bytes indicating
the length of the packet. We then fread that number of bytes from the
socket, followed by 12 bytes of additional data tacked onto the end of
the information.
Certain communications are multi-packet, so the code loops until we
either hit an feof condition or do not receive the expected beginning
marker (which is an error).
Using PHP 4.3.1 and earlier, down to 4.1.1, the code works fine. With
PHP 4.3.2 and newer, including 4.3.5RC3, the code chokes on large
packets.
That's as precise as I've been able to be to date. We are not using a
debug tool as of yet, so I can't be very precise. The code necessary
to reproduce the problem would require Counterpoint and our application
server be installed, which isn't feasible.
Perhaps someone could look for changes in fread since 4.3.1 and see if
there is a problem?
--
Edit this bug report at http://bugs.php.net/?id=27466&edit=1
#27468 [Opn->Asn]: foreach in __destruct() causes segfault
ID: 27468 Updated by: [EMAIL PROTECTED] Reported By: davojan at mail dot ru -Status: Open +Status: Assigned Bug Type: Zend Engine 2 problem Operating System: FreeBSD 4.7-RELEASE PHP Version: 5CVS-2004-03-02 (dev) -Assigned To: +Assigned To: andi New Comment: Verified on Linux, assigning to Andi. Previous Comments: [2004-03-02 15:46:10] davojan at mail dot ru Description: PHP crashes if foreach for a member of the class called in __destruct(). It doesn't matter - does the member exist or not, is it array or not - result is the same. Note, that in php5b4 it works fine. Expected result is what I get from it. Reproduce code: --- x as $x); } } new foo(); echo 'OK'; ?> Expected result: Warning: Invalid argument supplied for foreach() in /usr/local/www/data-dist/ils/admin/test/static.php on line 4 OK Actual result: -- Program received signal SIGSEGV, Segmentation fault. 0x28531d8d in zend_objects_free_object_storage (object=0x) at /usr/ports/distfiles/php5-200403021630/Zend/zend_objects.c:88 88 zend_hash_destroy(object->properties); (gdb) bt #0 0x28531d8d in zend_objects_free_object_storage (object=0x) at /usr/ports/distfiles/php5-200403021630/Zend/zend_objects.c:88 #1 0x28534883 in zend_objects_store_del_ref (zobject=0x80e82f0) at /usr/ports/distfiles/php5-200403021630/Zend/zend_objects_API.c:139 #2 0x28519cde in _zval_dtor (zvalue=0x80e82f0, __zend_filename=0x2859dd20 "/usr/ports/distfiles/php5-200403021630/Zend/zend_execute_API.c", __zend_lineno=358) at /usr/ports/distfiles/php5-200403021630/Zend/zend_variables.c:61 #3 0x2850e5fe in _zval_ptr_dtor (zval_ptr=0xbfbfe120, __zend_filename=0x285a3160 "/usr/ports/distfiles/php5-200403021630/Zend/zend_execute.c", __zend_lineno=3820) at /usr/ports/distfiles/php5-200403021630/Zend/zend_execute_API.c:358 #4 0x28549472 in zend_jmp_no_ctor_handler (execute_data=0xbfbfe168, opline=0x80e85e0, op_array=0x80e80c8) at /usr/ports/distfiles/php5-200403021630/Zend/zend_execute.c:3820 #5 0x28541aeb in execute (op_array=0x80e80c8) at /usr/ports/distfiles/php5-200403021630/Zend/zend_execute.c:1339 #6 0x2851c4d0 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/ports/distfiles/php5-200403021630/Zend/zend.c:1041 #7 0x284d23b3 in php_execute_script (primary_file=0xbfbff7b0) at /usr/ports/distfiles/php5-200403021630/main/main.c:1650 #8 0x2854e83e in apache_php_module_main (r=0x81fb038, display_source_mode=0) at /usr/ports/distfiles/php5-200403021630/sapi/apache/sapi_apache.c:54 #9 0x2854f8c8 in send_php (r=0x81fb038, display_source_mode=0, filename=0x81fcb10 "/usr/local/www/data/ils/admin/test/static.php") at /usr/ports/distfiles/php5-200403021630/sapi/apache/mod_php5.c:621 #10 0x2854f93b in send_parsed_php (r=0x81fb038) at /usr/ports/distfiles/php5-200403021630/sapi/apache/mod_php5.c:636 #11 0x8053a44 in ap_invoke_handler () #12 0x806398d in process_request_internal () #13 0x80639ec in ap_process_request () #14 0x805cdae in child_main () #15 0x805cf40 in make_child () #16 0x805d05d in startup_children () #17 0x805d5b0 in standalone_main () #18 0x805dcab in main () #19 0x804fc39 in _start () -- Edit this bug report at http://bugs.php.net/?id=27468&edit=1
#27468 [NEW]: foreach in __destruct() causes segfault
From: davojan at mail dot ru Operating system: FreeBSD 4.7-RELEASE PHP version: 5CVS-2004-03-02 (dev) PHP Bug Type: Zend Engine 2 problem Bug description: foreach in __destruct() causes segfault Description: PHP crashes if foreach for a member of the class called in __destruct(). It doesn't matter - does the member exist or not, is it array or not - result is the same. Note, that in php5b4 it works fine. Expected result is what I get from it. Reproduce code: --- x as $x); } } new foo(); echo 'OK'; ?> Expected result: Warning: Invalid argument supplied for foreach() in /usr/local/www/data-dist/ils/admin/test/static.php on line 4 OK Actual result: -- Program received signal SIGSEGV, Segmentation fault. 0x28531d8d in zend_objects_free_object_storage (object=0x) at /usr/ports/distfiles/php5-200403021630/Zend/zend_objects.c:88 88 zend_hash_destroy(object->properties); (gdb) bt #0 0x28531d8d in zend_objects_free_object_storage (object=0x) at /usr/ports/distfiles/php5-200403021630/Zend/zend_objects.c:88 #1 0x28534883 in zend_objects_store_del_ref (zobject=0x80e82f0) at /usr/ports/distfiles/php5-200403021630/Zend/zend_objects_API.c:139 #2 0x28519cde in _zval_dtor (zvalue=0x80e82f0, __zend_filename=0x2859dd20 "/usr/ports/distfiles/php5-200403021630/Zend/zend_execute_API.c", __zend_lineno=358) at /usr/ports/distfiles/php5-200403021630/Zend/zend_variables.c:61 #3 0x2850e5fe in _zval_ptr_dtor (zval_ptr=0xbfbfe120, __zend_filename=0x285a3160 "/usr/ports/distfiles/php5-200403021630/Zend/zend_execute.c", __zend_lineno=3820) at /usr/ports/distfiles/php5-200403021630/Zend/zend_execute_API.c:358 #4 0x28549472 in zend_jmp_no_ctor_handler (execute_data=0xbfbfe168, opline=0x80e85e0, op_array=0x80e80c8) at /usr/ports/distfiles/php5-200403021630/Zend/zend_execute.c:3820 #5 0x28541aeb in execute (op_array=0x80e80c8) at /usr/ports/distfiles/php5-200403021630/Zend/zend_execute.c:1339 #6 0x2851c4d0 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/ports/distfiles/php5-200403021630/Zend/zend.c:1041 #7 0x284d23b3 in php_execute_script (primary_file=0xbfbff7b0) at /usr/ports/distfiles/php5-200403021630/main/main.c:1650 #8 0x2854e83e in apache_php_module_main (r=0x81fb038, display_source_mode=0) at /usr/ports/distfiles/php5-200403021630/sapi/apache/sapi_apache.c:54 #9 0x2854f8c8 in send_php (r=0x81fb038, display_source_mode=0, filename=0x81fcb10 "/usr/local/www/data/ils/admin/test/static.php") at /usr/ports/distfiles/php5-200403021630/sapi/apache/mod_php5.c:621 #10 0x2854f93b in send_parsed_php (r=0x81fb038) at /usr/ports/distfiles/php5-200403021630/sapi/apache/mod_php5.c:636 #11 0x8053a44 in ap_invoke_handler () #12 0x806398d in process_request_internal () #13 0x80639ec in ap_process_request () #14 0x805cdae in child_main () #15 0x805cf40 in make_child () #16 0x805d05d in startup_children () #17 0x805d5b0 in standalone_main () #18 0x805dcab in main () #19 0x804fc39 in _start () -- Edit bug report at http://bugs.php.net/?id=27468&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27468&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27468&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27468&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27468&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27468&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27468&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27468&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27468&r=support Expected behavior: http://bugs.php.net/fix.php?id=27468&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27468&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27468&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27468&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27468&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27468&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27468&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27468&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27468&r=float
#27384 [Opn->Csd]: unpack() misbehaves with 1 char string
ID: 27384 Updated by: [EMAIL PROTECTED] Reported By: hayk at mail dot ru -Status: Open +Status: Closed Bug Type: Strings related Operating System: * PHP Version: 4.3.4 Previous Comments: [2004-03-02 15:40:12] hayk at mail dot ru Why array indexes begins from 1, but not from 0? [2004-03-02 15:40:10] hayk at mail dot ru Why array indexes begins from 1, but not from 0? [2004-02-25 15:43:47] hayk at mail dot ru By the way, array indexes usually begin from 0, not from 1. [2004-02-25 07:29:18] [EMAIL PROTECTED] And fix was merged to the stable branch too.. [2004-02-24 16:42:55] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. I see what you're saying now. This has been fixed in HEAD. 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/27384 -- Edit this bug report at http://bugs.php.net/?id=27384&edit=1
#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: hi idong, i tried your example, but the result i am getting is de de de de with register_globals Off and On Previous Comments: [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? [2004-03-02 05:35:37] hamid at wannameet dot nl the include files could not be opened because sess_lang was empty, but i changed my error reporting so that it will capture session_id en sess_lang. You will receive the new log file as soon as it has some entries. [2004-03-02 03:05:31] [EMAIL PROTECTED] That error log only shows that some files can not be opened, and sessions work fine for almost anybody (we had no other bug reports like this), so can you show something that proves your point in the form of a log? [2004-03-01 19:07:07] hamid at wannameet dot nl i have also put the error_log of yesterday in the directory bug_php, for extra info [2004-03-01 18:52:19] hamid at wannameet dot nl i'm sorry you can find the files in http://www.wannameet.nl/bug_php/ is an open dir 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
#27384 [Opn]: unpack() misbehaves with 1 char string
ID: 27384 User updated by: hayk at mail dot ru Reported By: hayk at mail dot ru Status: Open Bug Type: Strings related Operating System: * PHP Version: 4.3.4 New Comment: Why array indexes begins from 1, but not from 0? Previous Comments: [2004-03-02 15:40:10] hayk at mail dot ru Why array indexes begins from 1, but not from 0? [2004-02-25 15:43:47] hayk at mail dot ru By the way, array indexes usually begin from 0, not from 1. [2004-02-25 07:29:18] [EMAIL PROTECTED] And fix was merged to the stable branch too.. [2004-02-24 16:42:55] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. I see what you're saying now. This has been fixed in HEAD. [2004-02-24 15:42:38] hayk at mail dot ru Why this code works fine? We get: Array ( [1] => 32 [2] => 32 ) 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/27384 -- Edit this bug report at http://bugs.php.net/?id=27384&edit=1
#27384 [Csd->Opn]: unpack() misbehaves with 1 char string
ID: 27384 User updated by: hayk at mail dot ru Reported By: hayk at mail dot ru -Status: Closed +Status: Open Bug Type: Strings related Operating System: * PHP Version: 4.3.4 New Comment: Why array indexes begins from 1, but not from 0? Previous Comments: [2004-02-25 15:43:47] hayk at mail dot ru By the way, array indexes usually begin from 0, not from 1. [2004-02-25 07:29:18] [EMAIL PROTECTED] And fix was merged to the stable branch too.. [2004-02-24 16:42:55] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. I see what you're saying now. This has been fixed in HEAD. [2004-02-24 15:42:38] hayk at mail dot ru Why this code works fine? We get: Array ( [1] => 32 [2] => 32 ) [2004-02-24 15:30:15] [EMAIL PROTECTED] You're not using unpack correctly. The format string is Type.Multiplicity.Name Name cannot begin with or be a number, as it would be impossible to distinguish multiplicty from name. 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/27384 -- Edit this bug report at http://bugs.php.net/?id=27384&edit=1
#27451 [Com]: Losing Session vars for unknown reason
ID: 27451 Comment by: idong at gmx dot de Reported By: hamid at wannameet dot nl Status: Open Bug Type: Session related Operating System: FreeBSD PHP Version: 4.3.4 New Comment: 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? Previous Comments: [2004-03-02 05:35:37] hamid at wannameet dot nl the include files could not be opened because sess_lang was empty, but i changed my error reporting so that it will capture session_id en sess_lang. You will receive the new log file as soon as it has some entries. [2004-03-02 03:05:31] [EMAIL PROTECTED] That error log only shows that some files can not be opened, and sessions work fine for almost anybody (we had no other bug reports like this), so can you show something that proves your point in the form of a log? [2004-03-01 19:07:07] hamid at wannameet dot nl i have also put the error_log of yesterday in the directory bug_php, for extra info [2004-03-01 18:52:19] hamid at wannameet dot nl i'm sorry you can find the files in http://www.wannameet.nl/bug_php/ is an open dir [2004-03-01 18:48:40] hamid at wannameet dot nl you can find an example in a frameset on http://www.wannameet.nl/bug_php/index.inc http://www.wannameet.nl/bug_php/output.inc rename the files to .php 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
#27467 [Opn->Asn]: domDocument::load() called from class method crashes
ID: 27467
Updated by: [EMAIL PROTECTED]
Reported By: ds at cyberspace dot co dot za
-Status: Open
+Status: Assigned
Bug Type: DOM XML related
Operating System: WinXP
PHP Version: 5CVS-2004-03-02 (dev)
-Assigned To:
+Assigned To: rrichards
New Comment:
Verified on Linux, backtrace follows. Also assigned to Rob (looks like
a double free to me somewhere).
0x0808af07 in dom_get_doc_props (document=0x845a5a5a)
at /dat/dev/php/php-5.0dev/ext/dom/php_dom.c:119
119 if (document && document->doc_props) {
(gdb) bt
#0 0x0808af07 in dom_get_doc_props (document=0x845a5a5a)
at /dat/dev/php/php-5.0dev/ext/dom/php_dom.c:119
#1 0x08092e96 in dom_document_parser (id=0x40562b08, mode=1,
source=0x40560470 "file.xsl")
at /dat/dev/php/php-5.0dev/ext/dom/document.c:1390
#2 0x0809319e in dom_parse_document (ht=1, return_value=0x4056057c,
this_ptr=0x40562b08, return_value_used=1, mode=1)
at /dat/dev/php/php-5.0dev/ext/dom/document.c:1497
#3 0x08093312 in zif_domdocument_load (ht=1, return_value=0x4056057c,
this_ptr=0x40562b08, return_value_used=1)
at /dat/dev/php/php-5.0dev/ext/dom/document.c:1536
#4 0x082ab827 in execute_internal (execute_data_ptr=0xbfffd300,
return_value_used=1) at
/dat/dev/php/php-5.0dev/Zend/zend_execute.c:1290
#5 0x4075afa3 in xdebug_execute_internal
(current_execute_data=0xbfffd300,
return_value_used=1) at /dat/dev/php/xdebug/xdebug.c:895
#6 0x082af124 in zend_do_fcall_common_helper
(execute_data=0xbfffd300,
opline=0x40561774, op_array=0x40562860)
at /dat/dev/php/php-5.0dev/Zend/zend_execute.c:2650
#7 0x082af708 in zend_do_fcall_by_name_handler
(execute_data=0xbfffd300,
opline=0x40561774, op_array=0x40562860)
at /dat/dev/php/php-5.0dev/Zend/zend_execute.c:2759
#8 0x082ab956 in execute (op_array=0x40562860)
at /dat/dev/php/php-5.0dev/Zend/zend_execute.c:1339
---Type to continue, or q to quit---
#9 0x4075ae5a in xdebug_execute (op_array=0x40562860)
at /dat/dev/php/xdebug/xdebug.c:863
#10 0x082af287 in zend_do_fcall_common_helper
(execute_data=0xbfffd550,
opline=0x4055ff34, op_array=0x4055fa9c)
at /dat/dev/php/php-5.0dev/Zend/zend_execute.c:2677
#11 0x082af708 in zend_do_fcall_by_name_handler
(execute_data=0xbfffd550,
opline=0x4055ff34, op_array=0x4055fa9c)
at /dat/dev/php/php-5.0dev/Zend/zend_execute.c:2759
#12 0x082ab956 in execute (op_array=0x4055fa9c)
at /dat/dev/php/php-5.0dev/Zend/zend_execute.c:1339
#13 0x4075ae5a in xdebug_execute (op_array=0x4055fa9c)
at /dat/dev/php/xdebug/xdebug.c:863
#14 0x08288e9b in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /dat/dev/php/php-5.0dev/Zend/zend.c:1041
#15 0x08244940 in php_execute_script (primary_file=0xb9e0)
at /dat/dev/php/php-5.0dev/main/main.c:1650
#16 0x082b816d in main (argc=1, argv=0xba74)
at /dat/dev/php/php-5.0dev/sapi/cli/php_cli.c:941
(gdb)
Previous Comments:
[2004-03-02 14:48:39] ds at cyberspace dot co dot za
Description:
Calling domDocument::load() from within a class method PHP crashes.
Reproduce code:
---
Expected result:
Should return object
Actual result:
--
Both PHP CLI and Apache module crash. Only when domDocument::load() is
called from a class method.
--
Edit this bug report at http://bugs.php.net/?id=27467&edit=1
#27455 [Csd->Bgs]: mdecrypt_generic() fails all but 'ecb' with mcrypt_module_close()
ID: 27455 Updated by: [EMAIL PROTECTED] Reported By: robert at peakepro dot com -Status: Closed +Status: Bogus Bug Type: mcrypt related Operating System: RH Linux, Mac OS X PHP Version: 4.3.4 New Comment: Yup, it's something mistaken by a lot of people. (I set the status back to bogus, as this is not a bug in PHP). Previous Comments: [2004-03-02 14:51:25] robert at peakepro dot com Thanks for the quick reply. I'll look into this and ammend my contribution to the manual as appropriate. I'm guessing if this wasn't clear to me it may not have been clear to a lot of people. [2004-03-02 03:31:35] [EMAIL PROTECTED] This is not a bug at all; you HAVE to use the same IV for both encrypting and decrypting otherwise the algorithm is pointed in the wrong way. The reason why it works with ECB is because that is the only mode not using an IV. See also: http://talks.php.net/show/encryption-vancouver/14 and further slides, and http://talks.php.net/show/encryption-vancouver/24 [2004-03-02 03:14:23] robert at peakepro dot com Description: I noticed all the examples in the online documentation do not actually close out the mcrypt module, they simply deinit. This is not an accurate simulation of a real- world use, where an encrypted string may be stored and later retreived long after the module has been closed. I encountered this potential bug when running the loop I posted on the mcrypt main page. It seems that in all modes except ecb, mcrypt fails to decrypt encrypted strings after the module has been closed. At first I thought it was just my system or my libmcrypt, but I have tried this on multiple machines with the same results. Reproduce code: --- http://www.peakepro.com/workbench/mcrypt Expected result: The same results as in the source code posted in mcrypt_module_open() i.e. the original string. Actual result: -- Garbled output that varies with each new call. -- Edit this bug report at http://bugs.php.net/?id=27455&edit=1
#27455 [Bgs->Csd]: mdecrypt_generic() fails all but 'ecb' with mcrypt_module_close()
ID: 27455 User updated by: robert at peakepro dot com Reported By: robert at peakepro dot com -Status: Bogus +Status: Closed Bug Type: mcrypt related Operating System: RH Linux, Mac OS X PHP Version: 4.3.4 New Comment: Thanks for the quick reply. I'll look into this and ammend my contribution to the manual as appropriate. I'm guessing if this wasn't clear to me it may not have been clear to a lot of people. Previous Comments: [2004-03-02 03:31:35] [EMAIL PROTECTED] This is not a bug at all; you HAVE to use the same IV for both encrypting and decrypting otherwise the algorithm is pointed in the wrong way. The reason why it works with ECB is because that is the only mode not using an IV. See also: http://talks.php.net/show/encryption-vancouver/14 and further slides, and http://talks.php.net/show/encryption-vancouver/24 [2004-03-02 03:14:23] robert at peakepro dot com Description: I noticed all the examples in the online documentation do not actually close out the mcrypt module, they simply deinit. This is not an accurate simulation of a real- world use, where an encrypted string may be stored and later retreived long after the module has been closed. I encountered this potential bug when running the loop I posted on the mcrypt main page. It seems that in all modes except ecb, mcrypt fails to decrypt encrypted strings after the module has been closed. At first I thought it was just my system or my libmcrypt, but I have tried this on multiple machines with the same results. Reproduce code: --- http://www.peakepro.com/workbench/mcrypt Expected result: The same results as in the source code posted in mcrypt_module_open() i.e. the original string. Actual result: -- Garbled output that varies with each new call. -- Edit this bug report at http://bugs.php.net/?id=27455&edit=1
#27467 [NEW]: domDocument::load() called from class method crashes
From: ds at cyberspace dot co dot za Operating system: WinXP PHP version: 5CVS-2004-03-02 (dev) PHP Bug Type: DOM XML related Bug description: domDocument::load() called from class method crashes Description: Calling domDocument::load() from within a class method PHP crashes. Reproduce code: --- Expected result: Should return object Actual result: -- Both PHP CLI and Apache module crash. Only when domDocument::load() is called from a class method. -- Edit bug report at http://bugs.php.net/?id=27467&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27467&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27467&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27467&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27467&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27467&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27467&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27467&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27467&r=support Expected behavior: http://bugs.php.net/fix.php?id=27467&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27467&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27467&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27467&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27467&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27467&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27467&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27467&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27467&r=float
#27465 [Fbk->Bgs]: using ereg and odbc in a script causes odbc driver error message
ID: 27465
User updated by: gary at koning dot com
Reported By: gary at koning dot com
-Status: Feedback
+Status: Bogus
Bug Type: ODBC related
Operating System: win2k
PHP Version: 4.3.4
New Comment:
after more testing, ereg() does not seem to be the problem
Previous Comments:
[2004-03-02 13:35:40] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
[2004-03-02 13:31:55] gary at koning dot com
Description:
I am converting an application to win2k/mssql from linux/mysql. Using
ereg to validate form field data.
Getting unuasual error message from the win2k odbc driver.
Reproduce code:
---
Validation code:
if( !ereg("^([EMAIL PROTECTED],18})$",$stmp) )
Using odbc_do(), almost any simple query returning rows
will result in the driver throwing an error message
like:
"Error converting data type varchar to numeric"
I say almost because sometimes a row of data was returned.
But even then, reloading the script would give the above error.
Expected result:
Valid data from the odbc driver or a known error message.
Actual result:
--
Removing the call to ereg() will cause the query to return proper
data.
No further info at this time. (Took me 2 days to track this down). I
beleive an old copy of active perl is installed on this box, if that
has any bearing.
--
Edit this bug report at http://bugs.php.net/?id=27465&edit=1
#25870 [Com]: Session variables do NOT work as expected
ID: 25870 Comment by: sambukkaa at hotmail dot com Reported By: memoimyself at yahoo dot com dot br Status: Bogus Bug Type: Session related Operating System: Windows 2000 SP 4 PHP Version: 4.3.3 New Comment: Well, I belive you and I have had many problems with sessions too. some are saved some are saved but empty and some are never saved. sessions do what they want and when they want it. I'm also not a newby and I write critics about programms. I'm sure that there is buffer over run problem in the sessions code and it will tack a while till someone would open his eyes. In the meanwhile do what all others do. 1) use mysql to save your sessions. 2) create and save them as files yourself. for this you already find a lot of solutions on net. and now comes the automaticaly copy and paste answer :) 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. Previous Comments: [2003-10-14 20:09:49] [EMAIL PROTECTED] Works fine for me under Windows. (using Apache 2.0.47 and a working script). Please don't reopen this, there is no bug here. [2003-10-14 18:25:02] memoimyself at yahoo dot com dot br First of all, thanks a lot for taking time to reply to my post so quickly. Now, while I have not taken any offence whatsoever and can only imagine how busy you must be, I am *not* a newby and have *always* called start.php before test.php. The session variable ($_SESSION['test']) simply will *not* be registered unless I *reload* start.php (i.e. load it twice). On the start.php page I have included a link to test.php, so that the second page is only called after the first, i.e. the session variable was *supposed* to have been initialized. Perhaps this is a bug only affecting PHP under Windows? [2003-10-14 17:57:17] [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. Works fine, if start.php which intializes the session variable is always started before test.php, which uses it. [2003-10-14 14:03:48] memoimyself at yahoo dot com dot br Description: I read in the manual that the use of session_register() is deprecated and that session variables should now be registered simply by creating, and assigning a value to, a member of the $_SESSION array. Well, try as I may, I just cannot register session variables without using session_register(). If, however, I use session_register() before assigning a value to the new session variable via $_SESSION['x'], everything works fine. Reproduce code: --- // PAGE A (start.php): /***/ // PAGE B (test.php, called after start.php, obviously): Expected result: OUTPUT TO SCREEN: my test Actual result: -- OUTPUT TO SCREEN: Notice: Undefined index: test in D:\htdocs\Test\session\test.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=25870&edit=1
#27466 [NEW]: fread bug reading large block of data from a socket
From: tleaver at synchronics dot com
Operating system: Windows XP
PHP version: 4.3.4
PHP Bug Type: Sockets related
Bug description: fread bug reading large block of data from a socket
Description:
We have a commercial PHP-based product, basically a web app which
interfaces with our Counterpoint point of sale product, and is designed to
run on wireless handheld devices.
Communications with Counterpoint is handled via an application server,
which we communicate with from PHP via a socket connection.
Of the different types of messages we pass back and forth between PHP and
the application server, is a transaction describing a complex item with
multiple dimensions (size, color, etc). When retreiving this large block
of data from the socket using fread, we get unexpected data.
Each packet which is exchanged consists of a beginning 1 byte marker
("\x02") which denotes the beginning of a package, followed by a protocol
version (internal designator), followed by 2 bytes indicating the length
of the packet. We then fread that number of bytes from the socket,
followed by 12 bytes of additional data tacked onto the end of the
information.
Certain communications are multi-packet, so the code loops until we either
hit an feof condition or do not receive the expected beginning marker
(which is an error).
Using PHP 4.3.1 and earlier, down to 4.1.1, the code works fine. With PHP
4.3.2 and newer, including 4.3.5RC3, the code chokes on large packets.
That's as precise as I've been able to be to date. We are not using a
debug tool as of yet, so I can't be very precise. The code necessary to
reproduce the problem would require Counterpoint and our application
server be installed, which isn't feasible.
Perhaps someone could look for changes in fread since 4.3.1 and see if
there is a problem?
--
Edit bug report at http://bugs.php.net/?id=27466&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27466&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27466&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27466&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27466&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27466&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27466&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27466&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27466&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27466&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27466&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27466&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27466&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27466&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27466&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27466&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27466&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27466&r=float
#27461 [Bgs]: fread($fp,0) generates warning
ID: 27461 User updated by: mark at quarella dot co dot uk Reported By: mark at quarella dot co dot uk Status: Bogus Bug Type: Filesystem function related Operating System: Linux PHP Version: 4.3.5RC3 New Comment: Sorry to be dumb but I can't find reference to the change in ChangeLog, NEWS, at php.net/fread - where should I be looking? (A Google for the text of the Warning message just shows up several sites running PHP which I guess have been broken by this change.) Previous Comments: [2004-03-02 12:39:59] [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 This was a deliberate change. [2004-03-02 11:58:42] mark at quarella dot co dot uk Description: fread($handle, 0) generates a warning where it did not in earlier versions. This typically occurs in situations where the filesize is calculated: fread($handle, filesize($filename)); (where $handle is the result of opening file $filename, and $filename is the name of a zero-byte file) Reproduce code: --- // Taken from fread documentation, will generate WARNING // if something.txt exists and is empty (0 bytes) // get contents of a file into a string $filename = "/usr/local/something.txt"; $handle = fopen($filename, "r"); $contents = fread($handle, filesize($filename)); fclose($handle); Expected result: Would expect $contents == '', no errors or warnings Actual result: -- Warning: fread(): Length parameter must be greater than 0. in xx on line yy -- Edit this bug report at http://bugs.php.net/?id=27461&edit=1
#27465 [Opn->Fbk]: using ereg and odbc in a script causes odbc driver error message
ID: 27465
Updated by: [EMAIL PROTECTED]
Reported By: gary at koning dot com
-Status: Open
+Status: Feedback
Bug Type: ODBC related
Operating System: win2k
PHP Version: 4.3.4
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
Previous Comments:
[2004-03-02 13:31:55] gary at koning dot com
Description:
I am converting an application to win2k/mssql from linux/mysql. Using
ereg to validate form field data.
Getting unuasual error message from the win2k odbc driver.
Reproduce code:
---
Validation code:
if( !ereg("^([EMAIL PROTECTED],18})$",$stmp) )
Using odbc_do(), almost any simple query returning rows
will result in the driver throwing an error message
like:
"Error converting data type varchar to numeric"
I say almost because sometimes a row of data was returned.
But even then, reloading the script would give the above error.
Expected result:
Valid data from the odbc driver or a known error message.
Actual result:
--
Removing the call to ereg() will cause the query to return proper
data.
No further info at this time. (Took me 2 days to track this down). I
beleive an old copy of active perl is installed on this box, if that
has any bearing.
--
Edit this bug report at http://bugs.php.net/?id=27465&edit=1
#27464 [Opn->Bgs]: Duplicate record inserts
ID: 27464
Updated by: [EMAIL PROTECTED]
Reported By: lecas92 at lybertysurf dot fr
-Status: Open
+Status: Bogus
Bug Type: MySQL related
Operating System: XP
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.
.
Previous Comments:
[2004-03-02 13:31:01] lecas92 at lybertysurf dot fr
Description:
When I insert a record in Mysql Database, I have a duplicate record
inserts
My database is a Mysql database
My operating system is XP
Reproduce code:
---
$name = "myname";
$compagny = "mycompagny";
$req = "INSERT INTO MYTABLES (DATA1, DATA2) VALUES ('".$name."',
'".$compagny."')";
$res = mysql_query ($req, $base);
// The record is inserted into the table correctly, except for the fact
that it appears twice;
Expected result:
// The record is inserted into the table correctly, except for the fact
that it appears twice;
Actual result:
--
// The record is inserted into the table correctly, except for the fact
that it appears twice;
--
Edit this bug report at http://bugs.php.net/?id=27464&edit=1
#27465 [NEW]: using ereg and odbc in a script causes odbc driver error message
From: gary at koning dot com
Operating system: win2k
PHP version: 4.3.4
PHP Bug Type: ODBC related
Bug description: using ereg and odbc in a script causes odbc driver error message
Description:
I am converting an application to win2k/mssql from linux/mysql. Using ereg
to validate form field data.
Getting unuasual error message from the win2k odbc driver.
Reproduce code:
---
Validation code:
if( !ereg("^([EMAIL PROTECTED],18})$",$stmp) )
Using odbc_do(), almost any simple query returning rows
will result in the driver throwing an error message
like:
"Error converting data type varchar to numeric"
I say almost because sometimes a row of data was returned.
But even then, reloading the script would give the above error.
Expected result:
Valid data from the odbc driver or a known error message.
Actual result:
--
Removing the call to ereg() will cause the query to return proper data.
No further info at this time. (Took me 2 days to track this down). I
beleive an old copy of active perl is installed on this box, if that has
any bearing.
--
Edit bug report at http://bugs.php.net/?id=27465&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27465&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27465&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27465&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27465&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27465&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27465&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27465&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27465&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27465&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27465&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27465&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27465&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27465&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27465&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27465&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27465&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27465&r=float
#27464 [NEW]: Duplicate record inserts
From: lecas92 at lybertysurf dot fr
Operating system: XP
PHP version: 4.3.4
PHP Bug Type: MySQL related
Bug description: Duplicate record inserts
Description:
When I insert a record in Mysql Database, I have a duplicate record
inserts
My database is a Mysql database
My operating system is XP
Reproduce code:
---
$name = "myname";
$compagny = "mycompagny";
$req = "INSERT INTO MYTABLES (DATA1, DATA2) VALUES ('".$name."',
'".$compagny."')";
$res = mysql_query ($req, $base);
// The record is inserted into the table correctly, except for the fact
that it appears twice;
Expected result:
// The record is inserted into the table correctly, except for the fact
that it appears twice;
Actual result:
--
// The record is inserted into the table correctly, except for the fact
that it appears twice;
--
Edit bug report at http://bugs.php.net/?id=27464&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27464&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27464&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27464&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27464&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27464&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27464&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27464&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27464&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27464&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27464&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27464&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27464&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27464&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27464&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27464&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27464&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27464&r=float
#27462 [Opn->Bgs]: Cookie Problem
ID: 27462
Updated by: [EMAIL PROTECTED]
Reported By: clarence_cheong at yahoo dot com
-Status: Open
+Status: Bogus
Bug Type: Performance problem
Operating System: Windows XP
PHP Version: 4.3.5RC3
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.
.
Previous Comments:
[2004-03-02 12:43:35] clarence_cheong at yahoo dot com
Description:
I am attempting to make a login system,
After a login, i the Login Page script
At every secured page, i do an if statement to check if the cookie is
there, before the information loads...
The problem happens at the logout page,
Cookie value refuse to change!
Changes done to php.ini are just register_global and display_error
Reproduce code:
---
#==
# Login Page
#==
function incTimeOut() {
include "config/config_dat.php";
setcookie("session", "true", time()+$timeout);
setcookie("session2", "true");
}
//$timeout can be found in config_dat.php
#==
# Logoff Page
#==
function logout() {
setcookie("session", "false", time()-10);
setcookie("session2", "false", time()-10);
}
Expected result:
Expected to see both the cookie value becoming false after running the
logout page.
Actual result:
--
I did an echo along the pages to see the cookie value, but
unfortunately, session and session2 kept remaining at "true" (At all
pages in that folder)
--
Edit this bug report at http://bugs.php.net/?id=27462&edit=1
#27462 [NEW]: Cookie Problem
From: clarence_cheong at yahoo dot com
Operating system: Windows XP
PHP version: 4.3.5RC3
PHP Bug Type: Performance problem
Bug description: Cookie Problem
Description:
I am attempting to make a login system,
After a login, i the Login Page script
At every secured page, i do an if statement to check if the cookie is
there, before the information loads...
The problem happens at the logout page,
Cookie value refuse to change!
Changes done to php.ini are just register_global and display_error
Reproduce code:
---
#==
# Login Page
#==
function incTimeOut() {
include "config/config_dat.php";
setcookie("session", "true", time()+$timeout);
setcookie("session2", "true");
}
//$timeout can be found in config_dat.php
#==
# Logoff Page
#==
function logout() {
setcookie("session", "false", time()-10);
setcookie("session2", "false", time()-10);
}
Expected result:
Expected to see both the cookie value becoming false after running the
logout page.
Actual result:
--
I did an echo along the pages to see the cookie value, but unfortunately,
session and session2 kept remaining at "true" (At all pages in that
folder)
--
Edit bug report at http://bugs.php.net/?id=27462&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27462&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27462&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27462&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27462&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27462&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27462&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27462&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27462&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27462&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27462&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27462&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27462&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27462&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27462&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27462&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27462&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27462&r=float
#27461 [Opn->Bgs]: fread($fp,0) generates warning
ID: 27461 Updated by: [EMAIL PROTECTED] Reported By: mark at quarella dot co dot uk -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: Linux PHP Version: 4.3.5RC3 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 This was a deliberate change. Previous Comments: [2004-03-02 11:58:42] mark at quarella dot co dot uk Description: fread($handle, 0) generates a warning where it did not in earlier versions. This typically occurs in situations where the filesize is calculated: fread($handle, filesize($filename)); (where $handle is the result of opening file $filename, and $filename is the name of a zero-byte file) Reproduce code: --- // Taken from fread documentation, will generate WARNING // if something.txt exists and is empty (0 bytes) // get contents of a file into a string $filename = "/usr/local/something.txt"; $handle = fopen($filename, "r"); $contents = fread($handle, filesize($filename)); fclose($handle); Expected result: Would expect $contents == '', no errors or warnings Actual result: -- Warning: fread(): Length parameter must be greater than 0. in xx on line yy -- Edit this bug report at http://bugs.php.net/?id=27461&edit=1
#27461 [NEW]: fread($fp,0) generates warning
From: mark at quarella dot co dot uk Operating system: Linux PHP version: 4.3.5RC3 PHP Bug Type: Filesystem function related Bug description: fread($fp,0) generates warning Description: fread($handle, 0) generates a warning where it did not in earlier versions. This typically occurs in situations where the filesize is calculated: fread($handle, filesize($filename)); (where $handle is the result of opening file $filename, and $filename is the name of a zero-byte file) Reproduce code: --- // Taken from fread documentation, will generate WARNING // if something.txt exists and is empty (0 bytes) // get contents of a file into a string $filename = "/usr/local/something.txt"; $handle = fopen($filename, "r"); $contents = fread($handle, filesize($filename)); fclose($handle); Expected result: Would expect $contents == '', no errors or warnings Actual result: -- Warning: fread(): Length parameter must be greater than 0. in xx on line yy -- Edit bug report at http://bugs.php.net/?id=27461&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27461&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27461&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27461&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27461&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27461&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27461&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27461&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27461&r=support Expected behavior: http://bugs.php.net/fix.php?id=27461&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27461&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27461&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27461&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27461&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27461&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27461&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27461&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27461&r=float
#21333 [Com]: Nesting level too deep - recursive dependency?
ID: 21333 Comment by: s dot macchi at computime dot it Reported By: webmaster at vplabs dot com Status: Closed Bug Type: Reproducible crash Operating System: RedHat Linux 8.0 PHP Version: 4.3.0 New Comment: RedHat Linux9 Apache 2.0.41 PHP 4.3.1 I've copied the newly-compiled modules in /etc/php4 and everithing is ok Bye from Rome Simone Previous Comments: [2004-01-29 20:15:31] suk at pobox dot com This happens with me as well, with a virgin install of phpBB2 on Libranet 2.8.1 (Debian Sarge, Kernel 2.4.21). Apache 1.3.29. [2004-01-21 16:50:31] mikemoser4 at hotmail dot com I rna the make test and received the same error Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0 I have checked and the modules imap.so and ldap.so do appear in the usr/lib/php4 directory and since the installation of PHP was new they cannot be old version. This is on a red hat 8 with php 4.3.1 [2003-02-07 04:44:04] alex at elhacker dot info Me too, with Apache 1.3.27, y php 4.3.0 using php-nuke 6.0 My solution: editing php.ini: change this line: extension_dir = /usr/lib/php4 for this: extension_dir = /usr/lib/php best regards from spain (barcelona) bye alex [2003-01-03 16:48:38] fiber_halo at yahoo dot com Okay, I solved my own problem with a little help from a comment in bug 21206. My /etc/php.ini file was pointing to the RedHat-supplied modules in /usr/lib/php4. I was able to fix the problem by changing the line in /etc/php.ini that says: extension_dir = /usr/lib/php4 to point to the new location of the modules. This is where the imap.so, ldap.so, mysql.so, etc are. Alternatively, you could copy the newly-compiled modules from the compile-directory/modules up to /usr/lib/php4. Now, mine works perfectly. [2003-01-03 02:20:07] fiber_halo at yahoo dot com I'm seeing the same problem with a very similar config: RH8.0, php4-STABLE-200301020430 even running the command line tool gives this result, so I believe this is independent of the apache version: echo "" | ./php Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0 I did a make test and submitted it to QA. I hope this helps. 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/21333 -- Edit this bug report at http://bugs.php.net/?id=21333&edit=1
#27458 [Fbk->Opn]: unserilizing doubles might crash
ID: 27458
User updated by: hoesh at dorsum dot hu
Reported By: hoesh at dorsum dot hu
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: WIN
PHP Version: Irrelevant
New Comment:
Hi Derick!
Which one? Microsoft ships the sources of the RTL with MSVC
distribution. The generic C implementation was taken from
http://minnie.tuhs.org/UnixTree/V7/usr/src/libc/gen/atof.c.html, found
by google with "atof.c" keyword. The var_unserializer.re is located at
ext/standard, but I'm sure you know it. The report was created by a M$
engineer, from a user dump. M$ was about to find the reason why IIS
stops without _any_ notice, warning or alert.
Under high load, the occourance of this problem increases
exponentially. I can't figure out, why.
An easy solution to solve this problem should be to put one '\0' at the
end of the loaded stream, instead of protecting each double's
unserialization, and all floats should go well under all Wind[+]ws.
Right now I'm about to store strings in the session instead of doubles,
and cast them runtime to double values.
Previous Comments:
[2004-03-02 09:30:38] [EMAIL PROTECTED]
Where did you get that code from?
[2004-03-02 09:19:25] hoesh at dorsum dot hu
Description:
When a double value stored within the session file, the web server
might crash. It was a mystical problem for us. To solve this issue,
there need some workaround at the VAR_UNSERIALIZER.RE source code:
"d:" (iv | nv | nvexp) ";" {
*p = YYCURSOR;
INIT_PZVAL(*rval);
ZVAL_DOUBLE(*rval, atof(start + 2));
return 1;
}
The problem is the difference in the implementation of the function
'atof'. While general C implementations looks ahead until a non digital
character found, microsoft C tries to determine the string's length
with a call to 'strlen'. This can couse the crash some times, when the
accessible memory doesn't contain '\0'. The report about the memory
dump is following in the 'Reproducible code' section. For a quick sight
I placed the various implementations of the 'atof' function within the
'Expected result' block.
As we figured out, this issue comes up only when unserializing
sessions, not zval represented strings, as those zvals are closed with
'\0'.
Reproduce code:
---
Here is the report from Microsoft. They thought somthings wrong with
PHP... :)
Call stack:
0c19e228 019240e2 1b0419d8 43e72508 03019af0 msvcrt!atof+0x25 (CONV:
cdecl)
[atof.c @ 57]
WARNING: Stack unwind information not available. Following frames may
be
wrong.
0c19e2d4 03019b88 1b097000 0c19e3b4 43e72508 php4ts+0x940e2
03019c88 00010002 0005006d 0x3019b88
00 0c19e1f8 780167f9 msvcrt!strlen(void)+0x20 [intel\strlen.asm @ 78]
01 0c19e228 019240e2 msvcrt!atof(char * nptr = 0x1b0419d8
"1077611306196.2860107421875;a:5:{s:5:"tabid";s:5:"tab_5";s:3:"ct0";s:13:"1077612213758";s:3:"ct1";a:1:{s:13:"403b0afeae402";s:13:"1077612210164";}}s:9:"post_vars";a:0:...
Expected result:
-- MICROSOFT C IMPLEMENTATION --
double __cdecl atof(
REG1 const char *nptr
)
{
#ifdef _MT
struct _flt fltstruct; /* temporary structure */
#endif /* _MT */
/* scan past leading space/tab characters */
while ( isspace((int)(unsigned char)*nptr) )
nptr++;
/* let _fltin routine do the rest of the work */
#ifdef _MT
return( *(double *)&(_fltin2( &fltstruct, nptr, strlen(nptr),
0, 0 )->
dval) );
#else /* _MT */
return( *(double *)&(_fltin( nptr, strlen(nptr), 0, 0 )->dval)
);
#endif /* _MT */
}
-- GENERAL C IMPLEMENTATION (may differ at some point) --
double
atof(p)
register char *p;
{
register c;
double fl, flexp, exp5;
double big = 72057594037927936.; /*2^56*/
double ldexp();
int nd;
register eexp, exp, neg, negexp, bexp;
neg = 1;
while((c = *p++) == ' ')
;
if (c == '-')
neg = -1;
else if (c=='+')
;
else
--p;
exp = 0;
fl = 0;
nd = 0;
while ((c = *p++), isdigit(c)) {
if (fl>= 1;
if (exp==0)
break;
exp5 *= exp5;
}
if (negexp<0)
fl /= flexp;
else
fl *= flexp;
fl = ldexp(fl, negexp*bexp);
if (neg<0)
fl = -fl;
return(fl);
}
--
Edit this bug report at http://bugs.php.net/?id=27458&edit=1
#27418 [Opn]: SimpleXML Object forgetting values.
ID: 27418
User updated by: wb at pro-net dot co dot uk
Reported By: wb at pro-net dot co dot uk
Status: Open
Bug Type: *XML functions
Operating System: FreeBSD, WindowsXP
PHP Version: 5.0.0b4 (beta4)
New Comment:
Thanks for your reply. I have been playing around as well as reading
some threads on the DEV mailing list.
I think the main issue is that the simpleXML documentation in the
online manual is misleading and needs to be updated, this i feel would
probably solve 80% of the issues :)
But the other, and to me more important, issue is the inconsistancy
when using print_r() or var_dump(). They should always refer to the
items as a simplexml_element Object and never as a string. The thing to
remember is that the quickest way to find out what a vairable is is to
just print_r() or var_dump() it. Now i feel that most people will be
doing this to try to get an understanding of the new PHP5 objects, they
want to see quickly what is available, and when they see a value as a
string they expect to be able to use it as a string and not have it
turn out to be an object later on. Alos the fact that it looks like an
empty object when it is a simplexml_element dosen't help either.
I have no problem with haveing to cast the variable as a string as it
does show exactly how the object is being used in that situation and
rightfully "a string" != $anElement.
What about haveing the following methods to the simplexml_element
Object:
->setText($string)
->getText()
Then people could use these to get and set the 'text' value for that
element. I added the setValue() method because from the documentation i
can't see how one would set it anyway.
Anyway those are my ideas and i would be interested to find out what
people think.
Previous Comments:
[2004-03-02 10:17:02] adam at trachtenberg dot com
To parphrase Arthur C Clarke: You get different answers
because of magic. Well, advanced PHP technology that is
indistinguishable from magic.
The current solution to your problem is to cast the
variable before passing it to the function, like this:
utf8_decode((string) $user->login)
It would be better if you didn't need to do this, but
there's no clean solution to this problem right now.
We're working on it.
[2004-03-02 08:10:51] wb at pro-net dot co dot uk
I hav ebeen reading through the PHP-DEV archive and found message:
http://marc.theaimsgroup.com/?l=php-dev&m=107807524506690&w=
Which contains...
foreach($xml->user as $user){
if (utf8_decode($user->login) == $login &&
utf8_decode($user->password) == $password) {
// valid users
}
}
Both seem like they should work, but neither do.
This infact does work in the example below with the php5 versions that
i have tried. Just thought that i would point it out even if i am not
quite doing things correctly (what should eb the correct way?).
My main issue/question for this bug is how do i traverse over multiple
site elements for each user? And why does is go from being
[site] => Array
(
[0] => www.pro-net.co.uk
[1] => www.example.com
)
)
To:
$user->site is:
Array
(
[0] => simplexml_element Object
(
)
[1] => simplexml_element Object
(
)
)
depending on how you call it?
[2004-02-27 09:43:44] wb at pro-net dot co dot uk
Description:
When using simpleXML you are unable to fetch some information. The
information is displayed with print_r() but you can't get it it
directly.
Use the example provided as an example.
Reproduce code:
---
user1
letMeIn
www.pro-net.co.uk
www.example.com
user2
myPassword
www.pro-net.co.uk
';
$nl = "\r\n";
$xml = simplexml_load_string($xmlstr);
print('Current PHP version is : '.phpversion().$nl.$nl);
print('$xml is:'.$nl);
print_r($xml);
print($nl.$nl);
// Test authentication to get the correct user information
$login = 'user1';
$password = 'letMeIn';
print($nl.$nl.'Trying to authenticate "'.$login.'" with password
"'.$password.'".'.$nl.$nl);
$isAuth = false;
foreach($xml->user as $user){
if(utf8_decode($user->login) == $login &&
utf8_decode($user->password) == $password){
$isAuth = true;
break;
}
}
if(!$isAuth){
print($nl.$nl.'Invalid User.'.$nl);
die();
}
// So lets output the variables to see what we have...
print('$user is:'.$nl);
print_r($user);
print($nl.$nl);
print('$user->site is:'.$nl);
print_r($user->site);
print($nl.$nl);
print('$user->site[0] is:'.$nl);
print_r($use
#27418 [Com]: SimpleXML Object forgetting values.
ID: 27418
Comment by: adam at trachtenberg dot com
Reported By: wb at pro-net dot co dot uk
Status: Open
Bug Type: *XML functions
Operating System: FreeBSD, WindowsXP
PHP Version: 5.0.0b4 (beta4)
New Comment:
To parphrase Arthur C Clarke: You get different answers
because of magic. Well, advanced PHP technology that is
indistinguishable from magic.
The current solution to your problem is to cast the
variable before passing it to the function, like this:
utf8_decode((string) $user->login)
It would be better if you didn't need to do this, but
there's no clean solution to this problem right now.
We're working on it.
Previous Comments:
[2004-03-02 08:10:51] wb at pro-net dot co dot uk
I hav ebeen reading through the PHP-DEV archive and found message:
http://marc.theaimsgroup.com/?l=php-dev&m=107807524506690&w=
Which contains...
foreach($xml->user as $user){
if (utf8_decode($user->login) == $login &&
utf8_decode($user->password) == $password) {
// valid users
}
}
Both seem like they should work, but neither do.
This infact does work in the example below with the php5 versions that
i have tried. Just thought that i would point it out even if i am not
quite doing things correctly (what should eb the correct way?).
My main issue/question for this bug is how do i traverse over multiple
site elements for each user? And why does is go from being
[site] => Array
(
[0] => www.pro-net.co.uk
[1] => www.example.com
)
)
To:
$user->site is:
Array
(
[0] => simplexml_element Object
(
)
[1] => simplexml_element Object
(
)
)
depending on how you call it?
[2004-02-27 09:43:44] wb at pro-net dot co dot uk
Description:
When using simpleXML you are unable to fetch some information. The
information is displayed with print_r() but you can't get it it
directly.
Use the example provided as an example.
Reproduce code:
---
user1
letMeIn
www.pro-net.co.uk
www.example.com
user2
myPassword
www.pro-net.co.uk
';
$nl = "\r\n";
$xml = simplexml_load_string($xmlstr);
print('Current PHP version is : '.phpversion().$nl.$nl);
print('$xml is:'.$nl);
print_r($xml);
print($nl.$nl);
// Test authentication to get the correct user information
$login = 'user1';
$password = 'letMeIn';
print($nl.$nl.'Trying to authenticate "'.$login.'" with password
"'.$password.'".'.$nl.$nl);
$isAuth = false;
foreach($xml->user as $user){
if(utf8_decode($user->login) == $login &&
utf8_decode($user->password) == $password){
$isAuth = true;
break;
}
}
if(!$isAuth){
print($nl.$nl.'Invalid User.'.$nl);
die();
}
// So lets output the variables to see what we have...
print('$user is:'.$nl);
print_r($user);
print($nl.$nl);
print('$user->site is:'.$nl);
print_r($user->site);
print($nl.$nl);
print('$user->site[0] is:'.$nl);
print_r($user->site[0]);
print($nl.$nl);
?>
Expected result:
$xml is:
simplexml_element Object
(
[user] => Array
(
[0] => simplexml_element Object
(
[login] => user1
[password] => letMeIn
[site] => Array
(
[0] => www.pro-net.co.uk
[1] => www.example.com
)
)
[1] => simplexml_element Object
(
[login] => user2
[password] => myPassword
[site] => www.pro-net.co.uk
)
)
)
Trying to authenticate "user1" with password "letMeIn".
$user is:
simplexml_element Object
(
[login] => user1
[password] => letMeIn
[site] => Array
(
[0] => www.pro-net.co.uk
[1] => www.example.com
)
)
$user->site is:
Array
(
[0] => www.pro-net.co.uk
[1] => www.example.com
)
$user->site[0] is:
www.pro-net.co.uk
Actual result:
--
$xml is:
simplexml_element Object
(
[user] => Array
(
[0] => simplexml_element Object
(
[login] => user1
[password] => letMeIn
[site] => Array
(
[0] => www.pro-net.co.uk
[1] => www.example.com
)
)
[1] => simplexml_element Object
#27425 [Ver->Csd]: Uncaught exception in try catch block
ID: 27425
Updated by: [EMAIL PROTECTED]
Reported By: kase at gmx dot net
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: linux
PHP Version: 5CVS-2004-02-27 (dev)
New Comment:
Cool, let's close it then. Please reopen if it doesn't seem fixed
again.
Previous Comments:
[2004-03-02 10:05:24] kase at gmx dot net
I tested this bug again, and i think, it is fixed in newest cvs, now.
Maybe related to these bugfixes:
1. http://news.php.net/article.php?group=php.internals&article=8268
2. http://news.php.net/article.php?group=php.internals&article=8280
[2004-02-27 13:02:56] kase at gmx dot net
Description:
If you throw an exception in a function, which is called in a try/catch
block, after creating 2 objects of a class, which has a function or
method in __destruct(), the exception won´t be caught.
If you create the objects $v1 and $v2 of 2 different classes, and both
classes _have_ the function __destruct(), and the second class (of $v2)
have a function or method in __destruct(), the problem will exist, too.
Reproduce code:
---
Expected result:
The exception should be caught
Actual result:
--
Fatal error: Uncaught exception 'exception' in
/var/www/legendz/web/test/test.php5:12 Stack trace: #0
/var/www/legendz/web/test/test.php5(16): test() #1 {main} thrown in
/var/www/legendz/web/test/test.php5 on line 12
--
Edit this bug report at http://bugs.php.net/?id=27425&edit=1
#27425 [Ver]: Uncaught exception in try catch block
ID: 27425
User updated by: kase at gmx dot net
Reported By: kase at gmx dot net
Status: Verified
Bug Type: Zend Engine 2 problem
Operating System: linux
PHP Version: 5CVS-2004-02-27 (dev)
New Comment:
I tested this bug again, and i think, it is fixed in newest cvs, now.
Maybe related to these bugfixes:
1. http://news.php.net/article.php?group=php.internals&article=8268
2. http://news.php.net/article.php?group=php.internals&article=8280
Previous Comments:
[2004-02-27 13:02:56] kase at gmx dot net
Description:
If you throw an exception in a function, which is called in a try/catch
block, after creating 2 objects of a class, which has a function or
method in __destruct(), the exception won´t be caught.
If you create the objects $v1 and $v2 of 2 different classes, and both
classes _have_ the function __destruct(), and the second class (of $v2)
have a function or method in __destruct(), the problem will exist, too.
Reproduce code:
---
Expected result:
The exception should be caught
Actual result:
--
Fatal error: Uncaught exception 'exception' in
/var/www/legendz/web/test/test.php5:12 Stack trace: #0
/var/www/legendz/web/test/test.php5(16): test() #1 {main} thrown in
/var/www/legendz/web/test/test.php5 on line 12
--
Edit this bug report at http://bugs.php.net/?id=27425&edit=1
#27460 [NEW]: base64_decode fails to follow RFC 3548 completely
From: naish at klanen dot net
Operating system: Suse Linux 9.0 (2.4.21)
PHP version: 4.3.4
PHP Bug Type: URL related
Bug description: base64_decode fails to follow RFC 3548 completely
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 bug report at http://bugs.php.net/?id=27460&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27460&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27460&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27460&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27460&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27460&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27460&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27460&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27460&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27460&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27460&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27460&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27460&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27460&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27460&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27460&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27460&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27460&r=float
#27458 [Opn->Fbk]: unserilizing doubles might crash
ID: 27458
Updated by: [EMAIL PROTECTED]
Reported By: hoesh at dorsum dot hu
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: WIN
PHP Version: Irrelevant
New Comment:
Where did you get that code from?
Previous Comments:
[2004-03-02 09:19:25] hoesh at dorsum dot hu
Description:
When a double value stored within the session file, the web server
might crash. It was a mystical problem for us. To solve this issue,
there need some workaround at the VAR_UNSERIALIZER.RE source code:
"d:" (iv | nv | nvexp) ";" {
*p = YYCURSOR;
INIT_PZVAL(*rval);
ZVAL_DOUBLE(*rval, atof(start + 2));
return 1;
}
The problem is the difference in the implementation of the function
'atof'. While general C implementations looks ahead until a non digital
character found, microsoft C tries to determine the string's length
with a call to 'strlen'. This can couse the crash some times, when the
accessible memory doesn't contain '\0'. The report about the memory
dump is following in the 'Reproducible code' section. For a quick sight
I placed the various implementations of the 'atof' function within the
'Expected result' block.
As we figured out, this issue comes up only when unserializing
sessions, not zval represented strings, as those zvals are closed with
'\0'.
Reproduce code:
---
Here is the report from Microsoft. They thought somthings wrong with
PHP... :)
Call stack:
0c19e228 019240e2 1b0419d8 43e72508 03019af0 msvcrt!atof+0x25 (CONV:
cdecl)
[atof.c @ 57]
WARNING: Stack unwind information not available. Following frames may
be
wrong.
0c19e2d4 03019b88 1b097000 0c19e3b4 43e72508 php4ts+0x940e2
03019c88 00010002 0005006d 0x3019b88
00 0c19e1f8 780167f9 msvcrt!strlen(void)+0x20 [intel\strlen.asm @ 78]
01 0c19e228 019240e2 msvcrt!atof(char * nptr = 0x1b0419d8
"1077611306196.2860107421875;a:5:{s:5:"tabid";s:5:"tab_5";s:3:"ct0";s:13:"1077612213758";s:3:"ct1";a:1:{s:13:"403b0afeae402";s:13:"1077612210164";}}s:9:"post_vars";a:0:...
Expected result:
-- MICROSOFT C IMPLEMENTATION --
double __cdecl atof(
REG1 const char *nptr
)
{
#ifdef _MT
struct _flt fltstruct; /* temporary structure */
#endif /* _MT */
/* scan past leading space/tab characters */
while ( isspace((int)(unsigned char)*nptr) )
nptr++;
/* let _fltin routine do the rest of the work */
#ifdef _MT
return( *(double *)&(_fltin2( &fltstruct, nptr, strlen(nptr),
0, 0 )->
dval) );
#else /* _MT */
return( *(double *)&(_fltin( nptr, strlen(nptr), 0, 0 )->dval)
);
#endif /* _MT */
}
-- GENERAL C IMPLEMENTATION (may differ at some point) --
double
atof(p)
register char *p;
{
register c;
double fl, flexp, exp5;
double big = 72057594037927936.; /*2^56*/
double ldexp();
int nd;
register eexp, exp, neg, negexp, bexp;
neg = 1;
while((c = *p++) == ' ')
;
if (c == '-')
neg = -1;
else if (c=='+')
;
else
--p;
exp = 0;
fl = 0;
nd = 0;
while ((c = *p++), isdigit(c)) {
if (fl>= 1;
if (exp==0)
break;
exp5 *= exp5;
}
if (negexp<0)
fl /= flexp;
else
fl *= flexp;
fl = ldexp(fl, negexp*bexp);
if (neg<0)
fl = -fl;
return(fl);
}
--
Edit this bug report at http://bugs.php.net/?id=27458&edit=1
#27458 [NEW]: unserilizing doubles might crash
From: hoesh at dorsum dot hu
Operating system: WIN
PHP version: Irrelevant
PHP Bug Type: Reproducible crash
Bug description: unserilizing doubles might crash
Description:
When a double value stored within the session file, the web server might
crash. It was a mystical problem for us. To solve this issue, there need
some workaround at the VAR_UNSERIALIZER.RE source code:
"d:" (iv | nv | nvexp) ";" {
*p = YYCURSOR;
INIT_PZVAL(*rval);
ZVAL_DOUBLE(*rval, atof(start + 2));
return 1;
}
The problem is the difference in the implementation of the function
'atof'. While general C implementations looks ahead until a non digital
character found, microsoft C tries to determine the string's length with a
call to 'strlen'. This can couse the crash some times, when the accessible
memory doesn't contain '\0'. The report about the memory dump is following
in the 'Reproducible code' section. For a quick sight I placed the various
implementations of the 'atof' function within the 'Expected result'
block.
As we figured out, this issue comes up only when unserializing sessions,
not zval represented strings, as those zvals are closed with '\0'.
Reproduce code:
---
Here is the report from Microsoft. They thought somthings wrong with
PHP... :)
Call stack:
0c19e228 019240e2 1b0419d8 43e72508 03019af0 msvcrt!atof+0x25 (CONV:
cdecl)
[atof.c @ 57]
WARNING: Stack unwind information not available. Following frames may be
wrong.
0c19e2d4 03019b88 1b097000 0c19e3b4 43e72508 php4ts+0x940e2
03019c88 00010002 0005006d 0x3019b88
00 0c19e1f8 780167f9 msvcrt!strlen(void)+0x20 [intel\strlen.asm @ 78]
01 0c19e228 019240e2 msvcrt!atof(char * nptr = 0x1b0419d8
"1077611306196.2860107421875;a:5:{s:5:"tabid";s:5:"tab_5";s:3:"ct0";s:13:"1077612213758";s:3:"ct1";a:1:{s:13:"403b0afeae402";s:13:"1077612210164";}}s:9:"post_vars";a:0:...
Expected result:
-- MICROSOFT C IMPLEMENTATION --
double __cdecl atof(
REG1 const char *nptr
)
{
#ifdef _MT
struct _flt fltstruct; /* temporary structure */
#endif /* _MT */
/* scan past leading space/tab characters */
while ( isspace((int)(unsigned char)*nptr) )
nptr++;
/* let _fltin routine do the rest of the work */
#ifdef _MT
return( *(double *)&(_fltin2( &fltstruct, nptr, strlen(nptr), 0, 0
)->
dval) );
#else /* _MT */
return( *(double *)&(_fltin( nptr, strlen(nptr), 0, 0 )->dval) );
#endif /* _MT */
}
-- GENERAL C IMPLEMENTATION (may differ at some point) --
double
atof(p)
register char *p;
{
register c;
double fl, flexp, exp5;
double big = 72057594037927936.; /*2^56*/
double ldexp();
int nd;
register eexp, exp, neg, negexp, bexp;
neg = 1;
while((c = *p++) == ' ')
;
if (c == '-')
neg = -1;
else if (c=='+')
;
else
--p;
exp = 0;
fl = 0;
nd = 0;
while ((c = *p++), isdigit(c)) {
if (fl>= 1;
if (exp==0)
break;
exp5 *= exp5;
}
if (negexp<0)
fl /= flexp;
else
fl *= flexp;
fl = ldexp(fl, negexp*bexp);
if (neg<0)
fl = -fl;
return(fl);
}
--
Edit bug report at http://bugs.php.net/?id=27458&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27458&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27458&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27458&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27458&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27458&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27458&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27458&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27458&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27458&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27458&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27458&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27458&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27458&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27458&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27458&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27458&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27458&r=float
#27418 [Opn]: SimpleXML Object forgetting values.
ID: 27418
User updated by: wb at pro-net dot co dot uk
Reported By: wb at pro-net dot co dot uk
Status: Open
Bug Type: *XML functions
Operating System: FreeBSD, WindowsXP
PHP Version: 5.0.0b4 (beta4)
New Comment:
I hav ebeen reading through the PHP-DEV archive and found message:
http://marc.theaimsgroup.com/?l=php-dev&m=107807524506690&w=
Which contains...
foreach($xml->user as $user){
if (utf8_decode($user->login) == $login &&
utf8_decode($user->password) == $password) {
// valid users
}
}
Both seem like they should work, but neither do.
This infact does work in the example below with the php5 versions that
i have tried. Just thought that i would point it out even if i am not
quite doing things correctly (what should eb the correct way?).
My main issue/question for this bug is how do i traverse over multiple
site elements for each user? And why does is go from being
[site] => Array
(
[0] => www.pro-net.co.uk
[1] => www.example.com
)
)
To:
$user->site is:
Array
(
[0] => simplexml_element Object
(
)
[1] => simplexml_element Object
(
)
)
depending on how you call it?
Previous Comments:
[2004-02-27 09:43:44] wb at pro-net dot co dot uk
Description:
When using simpleXML you are unable to fetch some information. The
information is displayed with print_r() but you can't get it it
directly.
Use the example provided as an example.
Reproduce code:
---
user1
letMeIn
www.pro-net.co.uk
www.example.com
user2
myPassword
www.pro-net.co.uk
';
$nl = "\r\n";
$xml = simplexml_load_string($xmlstr);
print('Current PHP version is : '.phpversion().$nl.$nl);
print('$xml is:'.$nl);
print_r($xml);
print($nl.$nl);
// Test authentication to get the correct user information
$login = 'user1';
$password = 'letMeIn';
print($nl.$nl.'Trying to authenticate "'.$login.'" with password
"'.$password.'".'.$nl.$nl);
$isAuth = false;
foreach($xml->user as $user){
if(utf8_decode($user->login) == $login &&
utf8_decode($user->password) == $password){
$isAuth = true;
break;
}
}
if(!$isAuth){
print($nl.$nl.'Invalid User.'.$nl);
die();
}
// So lets output the variables to see what we have...
print('$user is:'.$nl);
print_r($user);
print($nl.$nl);
print('$user->site is:'.$nl);
print_r($user->site);
print($nl.$nl);
print('$user->site[0] is:'.$nl);
print_r($user->site[0]);
print($nl.$nl);
?>
Expected result:
$xml is:
simplexml_element Object
(
[user] => Array
(
[0] => simplexml_element Object
(
[login] => user1
[password] => letMeIn
[site] => Array
(
[0] => www.pro-net.co.uk
[1] => www.example.com
)
)
[1] => simplexml_element Object
(
[login] => user2
[password] => myPassword
[site] => www.pro-net.co.uk
)
)
)
Trying to authenticate "user1" with password "letMeIn".
$user is:
simplexml_element Object
(
[login] => user1
[password] => letMeIn
[site] => Array
(
[0] => www.pro-net.co.uk
[1] => www.example.com
)
)
$user->site is:
Array
(
[0] => www.pro-net.co.uk
[1] => www.example.com
)
$user->site[0] is:
www.pro-net.co.uk
Actual result:
--
$xml is:
simplexml_element Object
(
[user] => Array
(
[0] => simplexml_element Object
(
[login] => user1
[password] => letMeIn
[site] => Array
(
[0] => www.pro-net.co.uk
[1] => www.example.com
)
)
[1] => simplexml_element Object
(
[login] => user2
[password] => myPassword
[site] => www.pro-net.co.uk
)
)
)
Trying to authenticate "user1" with password "letMeIn".
$user is:
simplexml_element Object
(
[login] => user1
[password] => letMeIn
[site] => Array
(
[0] => www.pro-net.co.uk
[1] => www.example.com
)
)
$user->site is:
Array
(
[0] => simplexml_element Object
(
)
[1] => simple
#27444 [Opn->Fbk]: mssql_pconnect kill php on shutdown
ID: 27444 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: MSSQL related Operating System: windows 2000 PHP Version: 4.3.5RC3 New Comment: Please disable third party extensions such as turckloader first. Previous Comments: [2004-03-02 05:22:51] [EMAIL PROTECTED] i have no 4.3.X debug development available but here is the microsoft bug report: http://moshe.i-com-it.com/issues/mssql_pconnect/appcompat.txt http://moshe.i-com-it.com/issues/mssql_pconnect/php.exe.mdmp [2004-03-01 03:33:04] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2004-03-01 03:19:54] [EMAIL PROTECTED] Description: the following bug was introduced on php 4.3.5: crash the php on shutdown (using apache 1.3.7 on windows). mssql_connect() works fine. -- Edit this bug report at http://bugs.php.net/?id=27444&edit=1
#27442 [Bgs]: Bugs on 2/0
ID: 27442 User updated by: kim at openphp dot cn Reported By: kim at openphp dot cn Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows Server 2003 PHP Version: 4.3.4 New Comment: Oh~My God ! Look At These two Pictures : http://www.openphp.cn/zero.gif http://www.openphp.cn/zero2.gif I don't know how to use CMD :) Previous Comments: [2004-03-02 05:21:41] [EMAIL PROTECTED] [EMAIL PROTECTED]:~$ php-4.3.5RC3 -n -derror_reporting=2047 -r '$value = @ (2/0);'; [EMAIL PROTECTED]:~$ php-5.0dev -n -derror_reporting=2047 -r '$value = @ (2/0);'; [EMAIL PROTECTED]:~$ no output... [2004-03-02 05:10:44] kim at openphp dot cn Sorry . My English is not good :( But , On PHP4.3.4(or higher) , the output is : Warning: Division by zero in Unknown on line 0 Not: This also has nothing to do with your earlier example: shows no output at all on php 4.3.2, 4.3.3,4.3.5rc1 and 5.0dev [2004-03-02 04:45:41] [EMAIL PROTECTED] This is not a bug, check_date() gives an E_WARNING error since PHP 4.3.4 in case the parameter passed is not an integer. Because you explode on a string, the first ($year) will contain the string and both $month and $day will contain NULL, which are automatically converted to '0', but the empty string for $year isn't. This also has nothing to do with your earlier example: shows no output at all on php 4.3.2, 4.3.3, 4.3.5rc1 and 5.0dev [2004-03-02 04:09:14] kim at openphp dot cn emm.the logs is: checkdate() expects parameter 3 to be long, string given (PHP 4.3.4 or higher / Apache2.0.48 / Windows Server 2003) [2004-03-02 03:46:35] kim at openphp dot cn The same ... I thank it is different between 4.3.4(or higher) and 4.3.3 . Or it is different between IIS and Apache . I haven't tested On IIS/php4.3.4 , but I tested the code on IIS/4.3.3 , everything is OK. The Error process have something wrong : --- --- On IIS5/PHP4.3.3 everything is OK . Output is "Array ( [0] => ) 1" On Apache2/PHP4.3.4(4.3.5RC4-dev) . Output is "Array ( [0] => ) here". I don't know why it is different . but it makes me puzzle . 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/27442 -- Edit this bug report at http://bugs.php.net/?id=27442&edit=1
#27451 [Fbk->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: Feedback +Status: Open Bug Type: Session related Operating System: FreeBSD PHP Version: 4.3.4 New Comment: the include files could not be opened because sess_lang was empty, but i changed my error reporting so that it will capture session_id en sess_lang. You will receive the new log file as soon as it has some entries. Previous Comments: [2004-03-02 03:05:31] [EMAIL PROTECTED] That error log only shows that some files can not be opened, and sessions work fine for almost anybody (we had no other bug reports like this), so can you show something that proves your point in the form of a log? [2004-03-01 19:07:07] hamid at wannameet dot nl i have also put the error_log of yesterday in the directory bug_php, for extra info [2004-03-01 18:52:19] hamid at wannameet dot nl i'm sorry you can find the files in http://www.wannameet.nl/bug_php/ is an open dir [2004-03-01 18:48:40] hamid at wannameet dot nl you can find an example in a frameset on http://www.wannameet.nl/bug_php/index.inc http://www.wannameet.nl/bug_php/output.inc rename the files to .php [2004-03-01 18:03:25] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/27451 -- Edit this bug report at http://bugs.php.net/?id=27451&edit=1
#27444 [Fbk->Opn]: mssql_pconnect kill php on shutdown
ID: 27444 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: MSSQL related Operating System: windows 2000 PHP Version: 4.3.5RC3 New Comment: i have no 4.3.X debug development available but here is the microsoft bug report: http://moshe.i-com-it.com/issues/mssql_pconnect/appcompat.txt http://moshe.i-com-it.com/issues/mssql_pconnect/php.exe.mdmp Previous Comments: [2004-03-01 03:33:04] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2004-03-01 03:19:54] [EMAIL PROTECTED] Description: the following bug was introduced on php 4.3.5: crash the php on shutdown (using apache 1.3.7 on windows). mssql_connect() works fine. -- Edit this bug report at http://bugs.php.net/?id=27444&edit=1
#27442 [Bgs]: Bugs on 2/0
ID: 27442 Updated by: [EMAIL PROTECTED] Reported By: kim at openphp dot cn Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows Server 2003 PHP Version: 4.3.4 New Comment: [EMAIL PROTECTED]:~$ php-4.3.5RC3 -n -derror_reporting=2047 -r '$value = @ (2/0);'; [EMAIL PROTECTED]:~$ php-5.0dev -n -derror_reporting=2047 -r '$value = @ (2/0);'; [EMAIL PROTECTED]:~$ no output... Previous Comments: [2004-03-02 05:10:44] kim at openphp dot cn Sorry . My English is not good :( But , On PHP4.3.4(or higher) , the output is : Warning: Division by zero in Unknown on line 0 Not: This also has nothing to do with your earlier example: shows no output at all on php 4.3.2, 4.3.3,4.3.5rc1 and 5.0dev [2004-03-02 04:45:41] [EMAIL PROTECTED] This is not a bug, check_date() gives an E_WARNING error since PHP 4.3.4 in case the parameter passed is not an integer. Because you explode on a string, the first ($year) will contain the string and both $month and $day will contain NULL, which are automatically converted to '0', but the empty string for $year isn't. This also has nothing to do with your earlier example: shows no output at all on php 4.3.2, 4.3.3, 4.3.5rc1 and 5.0dev [2004-03-02 04:09:14] kim at openphp dot cn emm.the logs is: checkdate() expects parameter 3 to be long, string given (PHP 4.3.4 or higher / Apache2.0.48 / Windows Server 2003) [2004-03-02 03:46:35] kim at openphp dot cn The same ... I thank it is different between 4.3.4(or higher) and 4.3.3 . Or it is different between IIS and Apache . I haven't tested On IIS/php4.3.4 , but I tested the code on IIS/4.3.3 , everything is OK. The Error process have something wrong : --- --- On IIS5/PHP4.3.3 everything is OK . Output is "Array ( [0] => ) 1" On Apache2/PHP4.3.4(4.3.5RC4-dev) . Output is "Array ( [0] => ) here". I don't know why it is different . but it makes me puzzle . [2004-03-01 02:27:30] [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 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/27442 -- Edit this bug report at http://bugs.php.net/?id=27442&edit=1
#27442 [Bgs]: Bugs on 2/0
ID: 27442 User updated by: kim at openphp dot cn Reported By: kim at openphp dot cn Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows Server 2003 PHP Version: 4.3.4 New Comment: Sorry . My English is not good :( But , On PHP4.3.4(or higher) , the output is : Warning: Division by zero in Unknown on line 0 Not: This also has nothing to do with your earlier example: shows no output at all on php 4.3.2, 4.3.3,4.3.5rc1 and 5.0dev Previous Comments: [2004-03-02 04:45:41] [EMAIL PROTECTED] This is not a bug, check_date() gives an E_WARNING error since PHP 4.3.4 in case the parameter passed is not an integer. Because you explode on a string, the first ($year) will contain the string and both $month and $day will contain NULL, which are automatically converted to '0', but the empty string for $year isn't. This also has nothing to do with your earlier example: shows no output at all on php 4.3.2, 4.3.3, 4.3.5rc1 and 5.0dev [2004-03-02 04:09:14] kim at openphp dot cn emm.the logs is: checkdate() expects parameter 3 to be long, string given (PHP 4.3.4 or higher / Apache2.0.48 / Windows Server 2003) [2004-03-02 03:46:35] kim at openphp dot cn The same ... I thank it is different between 4.3.4(or higher) and 4.3.3 . Or it is different between IIS and Apache . I haven't tested On IIS/php4.3.4 , but I tested the code on IIS/4.3.3 , everything is OK. The Error process have something wrong : --- --- On IIS5/PHP4.3.3 everything is OK . Output is "Array ( [0] => ) 1" On Apache2/PHP4.3.4(4.3.5RC4-dev) . Output is "Array ( [0] => ) here". I don't know why it is different . but it makes me puzzle . [2004-03-01 02:27:30] [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-01 00:39:41] kim at openphp dot cn Small bugs?I don't know. >From browser Ouput : Warning: Division by zero in Unknown on line 0 But From Zend Studio's "GO" (X-Powered-By: PHP/4.3.2) , Output is nothing... The correct is nothing output . 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/27442 -- Edit this bug report at http://bugs.php.net/?id=27442&edit=1
#25876 [Com]: session_start(): Failed to initialize storage module
ID: 25876
Comment by: ozone at sange dot fi
Reported By: golden at riscom dot com
Status: Closed
Bug Type: Session related
Operating System: freebsd 4.8
PHP Version: 4.3.3
New Comment:
As suggested by mivox on Feb 12 in comments to bug 26038, which seems
to be a duplicate of this one, I added a line in my apache.conf:
php_value session.save_handler files
(source: http://bugs.php.net/bug.php?id=260389 )
After this I haven't seen any problems (running for a bit less than a
day), but it's hard to say whether it really helped.
Maybe there are still problems with the initialization of session
parameters when PHP is running as a module and the same code is used to
serve lots of requests.
For me the problems started when using FreeBSD 4-STABLE (4.8 I think,
or even earlier) with PHP 4.2.x and continued with PHP 4.3.x, but they
were very infrequent when using Apache 1.3. Upgrading to Apache 2 made
problems turn up much more often and users started complaining loudly.
I applied the patch from CVS that was supposed to fix the problem to
PHP 4.3.4 (from FreeBSD ports) but it didn't help. Of course that's not
quite the same as trying a recent snapshot, but other people have tried
that and it didn't help either.
Previous Comments:
[2004-02-27 10:30:37] bernoico at netcabo dot pt
I also have made the change you sugested and the problem continues...
You have to reopen this bug report.
Thanks.
[2004-02-27 08:49:34] php at lathwood dot co dot uk
We are having the same problem described in this bug report.
I have tried both the patch and two CVS versions of PHP, none of which
have solved this problem yet.
We are currently running php4-STABLE-200402261430 which still causes
the errors reported above, the only thing I can see that is wrong is:
PHP Fatal error: session_start(): Failed to initialize storage module:
user (path: /tmp)
The storage module above is user but php.ini defines the storage module
as files which is what it should be and is being used.
[2004-02-26 05:44:15] zsubscriber at mail dot ru
I have such problem, but I tried to solve this by installing older
version of PHP. This problem persist and error appears in random time
and for all sites which using session modules. I have two questions:
Does this patch fully solving the problem or just stop generating fatal
error? Does php.ini settings affects to this error?
P.S. Sorry for my spelling
[2004-02-24 11:56:34] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2004-02-24 05:16:45] [EMAIL PROTECTED]
In the ext/session/mod_files.c inside the function PS_OPEN_FUNC(files)
replace the next content:
---
if ((p = strchr(save_path, ';'))) {
errno = 0;
data->dirdepth = (size_t) strtol(save_path, NULL, 10);
if (errno == ERANGE) {
efree(data);
PS_SET_MOD_DATA(0);
return FAILURE;
}
save_path = p + 1;
}
---
by this one:
---
if ((p = strrchr(save_path, ';'))) {
data->dirdepth = (size_t)atol(save_path);
save_path = p + 1;
}
---
Compile again and try your scripts.
The problem exists from old php versions, but in 4.3.4 was added the
errno control to generate an error. Now the functionality is the
correct one and never produce abnormal errors!
Carlos Vilasis Faura & Javier Tacon Iglesias
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/25876
--
Edit this bug report at http://bugs.php.net/?id=25876&edit=1
#27442 [Opn->Bgs]: Bugs on 2/0
ID: 27442 Updated by: [EMAIL PROTECTED] Reported By: kim at openphp dot cn -Status: Open +Status: Bogus -Bug Type: Performance problem +Bug Type: Unknown/Other Function Operating System: Windows Server 2003 PHP Version: 4.3.4 New Comment: This is not a bug, check_date() gives an E_WARNING error since PHP 4.3.4 in case the parameter passed is not an integer. Because you explode on a string, the first ($year) will contain the string and both $month and $day will contain NULL, which are automatically converted to '0', but the empty string for $year isn't. This also has nothing to do with your earlier example: shows no output at all on php 4.3.2, 4.3.3, 4.3.5rc1 and 5.0dev Previous Comments: [2004-03-02 04:09:14] kim at openphp dot cn emm.the logs is: checkdate() expects parameter 3 to be long, string given (PHP 4.3.4 or higher / Apache2.0.48 / Windows Server 2003) [2004-03-02 03:46:35] kim at openphp dot cn The same ... I thank it is different between 4.3.4(or higher) and 4.3.3 . Or it is different between IIS and Apache . I haven't tested On IIS/php4.3.4 , but I tested the code on IIS/4.3.3 , everything is OK. The Error process have something wrong : --- --- On IIS5/PHP4.3.3 everything is OK . Output is "Array ( [0] => ) 1" On Apache2/PHP4.3.4(4.3.5RC4-dev) . Output is "Array ( [0] => ) here". I don't know why it is different . but it makes me puzzle . [2004-03-01 02:27:30] [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-01 00:39:41] kim at openphp dot cn Small bugs?I don't know. >From browser Ouput : Warning: Division by zero in Unknown on line 0 But From Zend Studio's "GO" (X-Powered-By: PHP/4.3.2) , Output is nothing... The correct is nothing output . [2004-03-01 00:33:25] kim at openphp dot cn Description: Small bugs?I don't know. >From browser Ouput : Warning: Division by zero in Unknown on line 0 But From Zend Studio's "GO" , Output is nothing... The correct is nothing output . -- Edit this bug report at http://bugs.php.net/?id=27442&edit=1
#27457 [Opn]: Problem with strtr() and translation array
ID: 27457
Updated by: [EMAIL PROTECTED]
Reported By: solace at ezmail dot ru
Status: Open
-Bug Type: Strings related
+Bug Type: Zend Engine 2 problem
Operating System: Win2K
PHP Version: 5.0.0b4 (beta4)
-Assigned To:
+Assigned To: andi
New Comment:
Recategorize bug.
Previous Comments:
[2004-03-02 03:40:08] solace at ezmail dot ru
Description:
I wanted to test compatibility of my scripts with the latest php5 beta
and discovered very strange results.
Well, something is wrong with strtr() function working with translation
array. It worked fine with php 4.x.x.
But strtr() with strings still works.
I'm using command-line php.exe with -n switch, without php.ini or any
modules.
Reproduce code:
---
$test = "Dot in brackets [.]\n";
$test = strtr($test, array('.' => '0'));
// doesn't work ???
$test = strtr($test, array('0' => '.'));
echo $test;
// but this works!!!
$test = strtr($test, '0', '.');
echo $test;
Expected result:
Dot in brackets [.]
Actual result:
--
Dot in brackets [0]
--
Edit this bug report at http://bugs.php.net/?id=27457&edit=1
#27442 [Opn]: Bugs on 2/0
ID: 27442 User updated by: kim at openphp dot cn Reported By: kim at openphp dot cn Status: Open Bug Type: Performance problem Operating System: Windows Server 2003 PHP Version: 4.3.4 New Comment: emm.the logs is: checkdate() expects parameter 3 to be long, string given (PHP 4.3.4 or higher / Apache2.0.48 / Windows Server 2003) Previous Comments: [2004-03-02 03:46:35] kim at openphp dot cn The same ... I thank it is different between 4.3.4(or higher) and 4.3.3 . Or it is different between IIS and Apache . I haven't tested On IIS/php4.3.4 , but I tested the code on IIS/4.3.3 , everything is OK. The Error process have something wrong : --- --- On IIS5/PHP4.3.3 everything is OK . Output is "Array ( [0] => ) 1" On Apache2/PHP4.3.4(4.3.5RC4-dev) . Output is "Array ( [0] => ) here". I don't know why it is different . but it makes me puzzle . [2004-03-01 02:27:30] [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-01 00:39:41] kim at openphp dot cn Small bugs?I don't know. >From browser Ouput : Warning: Division by zero in Unknown on line 0 But From Zend Studio's "GO" (X-Powered-By: PHP/4.3.2) , Output is nothing... The correct is nothing output . [2004-03-01 00:33:25] kim at openphp dot cn Description: Small bugs?I don't know. >From browser Ouput : Warning: Division by zero in Unknown on line 0 But From Zend Studio's "GO" , Output is nothing... The correct is nothing output . -- Edit this bug report at http://bugs.php.net/?id=27442&edit=1
#27442 [Fbk->Opn]: Bugs on 2/0
ID: 27442 User updated by: kim at openphp dot cn Reported By: kim at openphp dot cn -Status: Feedback +Status: Open Bug Type: Performance problem Operating System: Windows Server 2003 PHP Version: 4.3.4 New Comment: The same ... I thank it is different between 4.3.4(or higher) and 4.3.3 . Or it is different between IIS and Apache . I haven't tested On IIS/php4.3.4 , but I tested the code on IIS/4.3.3 , everything is OK. The Error process have something wrong : --- --- On IIS5/PHP4.3.3 everything is OK . Output is "Array ( [0] => ) 1" On Apache2/PHP4.3.4(4.3.5RC4-dev) . Output is "Array ( [0] => ) here". I don't know why it is different . but it makes me puzzle . Previous Comments: [2004-03-01 02:27:30] [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-01 00:39:41] kim at openphp dot cn Small bugs?I don't know. >From browser Ouput : Warning: Division by zero in Unknown on line 0 But From Zend Studio's "GO" (X-Powered-By: PHP/4.3.2) , Output is nothing... The correct is nothing output . [2004-03-01 00:33:25] kim at openphp dot cn Description: Small bugs?I don't know. >From browser Ouput : Warning: Division by zero in Unknown on line 0 But From Zend Studio's "GO" , Output is nothing... The correct is nothing output . -- Edit this bug report at http://bugs.php.net/?id=27442&edit=1
#27457 [NEW]: Problem with strtr() and translation array
From: solace at ezmail dot ru
Operating system: Win2K
PHP version: 5.0.0b4 (beta4)
PHP Bug Type: Strings related
Bug description: Problem with strtr() and translation array
Description:
I wanted to test compatibility of my scripts with the latest php5 beta and
discovered very strange results.
Well, something is wrong with strtr() function working with translation
array. It worked fine with php 4.x.x.
But strtr() with strings still works.
I'm using command-line php.exe with -n switch, without php.ini or any
modules.
Reproduce code:
---
$test = "Dot in brackets [.]\n";
$test = strtr($test, array('.' => '0'));
// doesn't work ???
$test = strtr($test, array('0' => '.'));
echo $test;
// but this works!!!
$test = strtr($test, '0', '.');
echo $test;
Expected result:
Dot in brackets [.]
Actual result:
--
Dot in brackets [0]
--
Edit bug report at http://bugs.php.net/?id=27457&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27457&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27457&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27457&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27457&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27457&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27457&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27457&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27457&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27457&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27457&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27457&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27457&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27457&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27457&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27457&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27457&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27457&r=float
#27456 [NEW]: file upload with arrays loses $_POST vars
From: php at humbapa dot ch
Operating system: apache 2.0.48 @ Linux 2.6.2
PHP version: 4.3.5RC3
PHP Bug Type: Unknown/Other Function
Bug description: file upload with arrays loses $_POST vars
Description:
when I use a form with all input-fields named e.g. "foo[]" the fields
after an input-file-field will be lost in the $_POST var.
Reproduce code:
---
0) {
print_r($_POST);
print_r($_FILES);
}
?>
Expected result:
Array
(
[foo] => Array
(
[0] => bar1
[1] => bar2
)
)
Array
(
[foo] => Array
(
[name] => Array
(
[0] => file1
[1] => file2
)
...SKIP...
Actual result:
--
Array
(
[foo] => Array
(
[0] => bar1
)
)
Array
(
[foo] => Array
(
[name] => Array
(
[0] => file1
[1] => file2
)
...SKIP...
--
Edit bug report at http://bugs.php.net/?id=27456&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27456&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27456&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27456&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27456&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27456&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27456&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27456&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27456&r=support
Expected behavior: http://bugs.php.net/fix.php?id=27456&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27456&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27456&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27456&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27456&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27456&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27456&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27456&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27456&r=float
#27455 [Opn->Bgs]: mdecrypt_generic() fails all but 'ecb' with mcrypt_module_close()
ID: 27455 Updated by: [EMAIL PROTECTED] Reported By: robert at peakepro dot com -Status: Open +Status: Bogus Bug Type: mcrypt related Operating System: RH Linux, Mac OS X PHP Version: 4.3.4 New Comment: This is not a bug at all; you HAVE to use the same IV for both encrypting and decrypting otherwise the algorithm is pointed in the wrong way. The reason why it works with ECB is because that is the only mode not using an IV. See also: http://talks.php.net/show/encryption-vancouver/14 and further slides, and http://talks.php.net/show/encryption-vancouver/24 Previous Comments: [2004-03-02 03:14:23] robert at peakepro dot com Description: I noticed all the examples in the online documentation do not actually close out the mcrypt module, they simply deinit. This is not an accurate simulation of a real- world use, where an encrypted string may be stored and later retreived long after the module has been closed. I encountered this potential bug when running the loop I posted on the mcrypt main page. It seems that in all modes except ecb, mcrypt fails to decrypt encrypted strings after the module has been closed. At first I thought it was just my system or my libmcrypt, but I have tried this on multiple machines with the same results. Reproduce code: --- http://www.peakepro.com/workbench/mcrypt Expected result: The same results as in the source code posted in mcrypt_module_open() i.e. the original string. Actual result: -- Garbled output that varies with each new call. -- Edit this bug report at http://bugs.php.net/?id=27455&edit=1
#27455 [NEW]: mdecrypt_generic() fails all but 'ecb' with mcrypt_module_close()
From: robert at peakepro dot com Operating system: RH Linux, Mac OS X PHP version: 4.3.4 PHP Bug Type: mcrypt related Bug description: mdecrypt_generic() fails all but 'ecb' with mcrypt_module_close() Description: I noticed all the examples in the online documentation do not actually close out the mcrypt module, they simply deinit. This is not an accurate simulation of a real- world use, where an encrypted string may be stored and later retreived long after the module has been closed. I encountered this potential bug when running the loop I posted on the mcrypt main page. It seems that in all modes except ecb, mcrypt fails to decrypt encrypted strings after the module has been closed. At first I thought it was just my system or my libmcrypt, but I have tried this on multiple machines with the same results. Reproduce code: --- http://www.peakepro.com/workbench/mcrypt Expected result: The same results as in the source code posted in mcrypt_module_open() i.e. the original string. Actual result: -- Garbled output that varies with each new call. -- Edit bug report at http://bugs.php.net/?id=27455&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27455&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27455&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27455&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27455&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27455&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27455&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27455&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27455&r=support Expected behavior: http://bugs.php.net/fix.php?id=27455&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27455&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27455&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27455&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27455&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27455&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27455&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27455&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27455&r=float
#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: That error log only shows that some files can not be opened, and sessions work fine for almost anybody (we had no other bug reports like this), so can you show something that proves your point in the form of a log? Previous Comments: [2004-03-01 19:07:07] hamid at wannameet dot nl i have also put the error_log of yesterday in the directory bug_php, for extra info [2004-03-01 18:52:19] hamid at wannameet dot nl i'm sorry you can find the files in http://www.wannameet.nl/bug_php/ is an open dir [2004-03-01 18:48:40] hamid at wannameet dot nl you can find an example in a frameset on http://www.wannameet.nl/bug_php/index.inc http://www.wannameet.nl/bug_php/output.inc rename the files to .php [2004-03-01 18:03:25] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2004-03-01 17:53:38] hamid at wannameet dot nl // file settings.php // file 2 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
#27454 [Opn->Fbk]: Can not use interbase module
ID: 27454 Updated by: [EMAIL PROTECTED] Reported By: grechenyuk at obl dot zt dot energy dot gov dot ua -Status: Open +Status: Feedback Bug Type: InterBase related Operating System: Windows xp pro PHP Version: 4.3.4 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2004-03-02 01:52:01] grechenyuk at obl dot zt dot energy dot gov dot ua Description: in php.ini in Windows Extensions trying to use extension=php_interbase.dll i got an error in !ANY! my page webserver error: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. ... Apache/1.3.23 Server at grechenyuk Port 80 and OS (win xp pro) closes and php script interpriter and ask me to send bugreport if I remark line ;extension=php_interbase.dll error disappears. Apache web server logfile fragment [Tue Mar 02 08:44:30 2004] [error] [client 127.0.0.1] Premature end of script headers: c:/program files/apache group/apache/php4/php.exe what is the problem? -- Edit this bug report at http://bugs.php.net/?id=27454&edit=1
