#5311 [Com]: implement checkdnsrr() and getmxrr() on windows
ID: 5311
Comment by: dsfsd at hotmail dot com
Reported By: steve at tradinglinx dot com
Status: Analyzed
Bug Type: Feature/Change Request
Operating System: W2000
PHP Version: 4.0.1
New Comment:
sdasdasds
Previous Comments:
[2007-06-10 15:43:48] john at naevius dot com
i like it :)
http://www.naevius.com/
[2003-01-28 18:28:49] [EMAIL PROTECTED]
Windows users can get this functionality from the PEAR class Net_DNS.
http://pear.php.net/net_dns
[2001-02-24 13:47:02] [EMAIL PROTECTED]
Both of these are #Defined out in the source code.. someone needs too
look for a win32 implmentation of these at some point (dns.c:170 #if
HAVE_BINDLIB !(defined(__BEOS__)||defined(PHP_WIN32))).
Changing to Feature Change Request.
[2000-08-12 13:50:49] [EMAIL PROTECTED]
user comment:
Neither checkdnsrr nor getmxrr appear work under Windows NT
4/SP6a with IIS
4.
I'm running with the downloaded Windows binary 4.0.1pl2 and
the provided
.ini file. OS is NT 4.0/sp6a, IIS 4.
Under Windows, checkdnsrr always returns true (no matter
whether the
provided domain name could even possibly be valid) and
getmxrr returns 0
hosts.
(append ?domain=domaintotest.com to the URL when calling
this script)
?
echo(pcheckdnsrr:
.(checkdnsrr($domain,MX)?true:false));
getmxrr($domain,$mxhosts);
echo(pgetmxrr: [.count($mxhosts).] );
for ( $i = 0; $i count ( $mxhosts ); $i++ ) {
echo($mxhosts[$i]. );
}
?
[2000-07-01 16:36:45] steve at tradinglinx dot com
OS : Windows 2000 Pro
Server : Apache 1.3.12 Win32
PHP4 : PHP 4.01 Win32
Script : -
list($user,$domain)=split(@,$email,2);
echo P$user @ $domain
if (checkdnsrr($domain,MX)){
echo PValid Domain/P
}
else{
echo PUnValid Domain/P
}
---
Test is already Unvalid Domain, But split is OK.
I supposed that it's checkdnsrr not working.
--
Edit this bug report at http://bugs.php.net/?id=5311edit=1
#44714 [NEW]: Mcrypt decrypt output bug in Firefox
From: isedc at yahoo dot com Operating system: Windows Vista PHP version: 5.2.5 PHP Bug Type: mcrypt related Bug description: Mcrypt decrypt output bug in Firefox Description: Following an MCRYPT example on php.net, when decrypting a string that is less than 8 characters, will output in firefox and appended with ? marks to fill the other characters. Example: ecrypted string is 4 characters long (abcd), when decrypting the string and outputting to firefox displays: abcd This was tested with Firefox 2.0.13. This does not appear to affect Internet Explorer 7. Reproduce code: --- $key = d9Qg%R*; $text = abcd; $iv_size = mcrypt_get_iv_size(MCRYPT_XTEA, MCRYPT_MODE_ECB); $iv = mcrypt_create_iv($iv_size, MCRYPT_RAND); $enc = mcrypt_encrypt(MCRYPT_XTEA, $key, $text, MCRYPT_MODE_ECB, $iv); $crypttext = mcrypt_decrypt(MCRYPT_XTEA, $key, $enc, MCRYPT_MODE_ECB, $iv); echo $crypttext; Expected result: echo output should be: abcd Actual result: -- echo output is actually: abcd -- Edit bug report at http://bugs.php.net/?id=44714edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44714r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44714r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44714r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44714r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44714r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44714r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44714r=needscript Try newer version:http://bugs.php.net/fix.php?id=44714r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44714r=support Expected behavior:http://bugs.php.net/fix.php?id=44714r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44714r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44714r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44714r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44714r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44714r=dst IIS Stability:http://bugs.php.net/fix.php?id=44714r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44714r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44714r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44714r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44714r=mysqlcfg
#44327 [Opn]: PDORow::queryString property numeric offsets / Crash
ID: 44327
User updated by: uwendel at mysql dot com
-Summary: PDORow::queryString property numeric offsets
Reported By: uwendel at mysql dot com
Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3CVS-2008-03-04 (snap)
New Comment:
Adding Crash to Summary.
Previous Comments:
[2008-04-14 09:03:12] uwendel at mysql dot com
Crash with CVS snapshot
[EMAIL PROTECTED]:~/php53_libmysql sapi/cli/php -v
PHP 5.3.0-dev (cli) (built: Apr 11 2008 12:02:49)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies
[EMAIL PROTECTED]:~/php53_libmysql sapi/cli/php -r '$db = new
PDO(sqlite:/tmp/foo); $stmt = $db-query(SELECT 1); $row =
$stmt-fetch(PDO::FETCH_LAZY); var_dump($row-{0});
var_dump($row-queryString); get_class($row);'
string(1) 1
string(1) 1
Speicherzugriffsfehler
[2008-03-04 17:21:29] uwendel at mysql dot com
Description:
What kind of thing is the PDORow::queryString property?
PDORow objects are generated and returned by
PDOStatement::fetch(PDO::FETCH_LAZY). PDORow objects seem a bit special
in some ways.
1) PDO::FETCH_LAZY = PDO::FETCH_OBJ + PDO::FETCH_BOTH
PDO::FETCH_BOTH means that the returned data is both indexed by the
column name and a column offset number. For example, a query like SELECT
id FROM test should return an object (resp. array) with the properties
{0} and id. You can access both properties and you get what you want.
But var_dump() will report only the column name based property and not
the property based on the numeric column offset.
I have no idea if this is a var_dump() or a PDO flaw.
2) The magic queryString property
var_dump() reports a queryString property for PDORow objects returned
by PDOStatement::fetch(). In all my testing I found the queryString
propery value to be the query string which has constructed the
corresponding PDOStatement object. However, I cannot access this
property. I see it, but I have no access. That makes it a bit magic.
Also, note how var_dump(), var_export() and debug_zval_dump report
different things. Johannes already explained to me that the functions
might do different things, but anyway it looks confusing to me.
Reproduce code:
---
1, FETCH_LAZY and numeric offset --
sapi/cli/php -r '$db = new
PDO(mysql:dbname=phptest;unix_socket=/tmp/mysql.sock, root, root);
$stmt = $db-prepare(SELECT 1 AS \one\); $stmt-execute(); $row =
$stmt-fetch(PDO::FETCH_LAZY); var_dump($row); var_dump($row-{0});
var_dump($row-one); '
object(PDORow)#3 (2) {
[queryString]=
string(17) SELECT 1 AS one
[one]=
string(1) 1
}
--
string(1) 1
string(1) 1
2, magic PDORow::queryString() -
sapi/cli/php -r '$db = new
PDO(mysql:dbname=phptest;unix_socket=/tmp/mysql.sock, root, root);
$stmt = $db-prepare(SELECT 1 AS \one\); $stmt-execute(); $row =
$stmt-fetch(PDO::FETCH_LAZY); var_dump($row);
var_dump($row-queryString); '
object(PDORow)#3 (2) {
[queryString]=
string(17) SELECT 1 AS one
[one]=
string(1) 1
}
--
UNKNOWN:0
sapi/cli/php -r '$db = new
PDO(mysql:dbname=phptest;unix_socket=/tmp/mysql.sock, root, root);
$db-exec(DROP TABLE test); $db-exec(CREATE TABLE test (id INT));
$db-exec(INSERT INTO test(id) VALUES (1)); $stmt =
$db-prepare(SELECT id FROM test); $stmt-execute(); $row =
$stmt-fetch(PDO::FETCH_LAZY); var_dump($row);
var_dump($row-queryString); var_export($row-queryString); print \n;
debug_zval_dump($row-queryString);'
--
UNKNOWN:0
NULL
UNKNOWN:0
--
Edit this bug report at http://bugs.php.net/?id=44327edit=1
#44327 [Opn]: PDORow::queryString property numeric offsets
ID: 44327
User updated by: uwendel at mysql dot com
Reported By: uwendel at mysql dot com
Status: Open
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3CVS-2008-03-04 (snap)
New Comment:
Crash with CVS snapshot
[EMAIL PROTECTED]:~/php53_libmysql sapi/cli/php -v
PHP 5.3.0-dev (cli) (built: Apr 11 2008 12:02:49)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2008 Zend Technologies
[EMAIL PROTECTED]:~/php53_libmysql sapi/cli/php -r '$db = new
PDO(sqlite:/tmp/foo); $stmt = $db-query(SELECT 1); $row =
$stmt-fetch(PDO::FETCH_LAZY); var_dump($row-{0});
var_dump($row-queryString); get_class($row);'
string(1) 1
string(1) 1
Speicherzugriffsfehler
Previous Comments:
[2008-03-04 17:21:29] uwendel at mysql dot com
Description:
What kind of thing is the PDORow::queryString property?
PDORow objects are generated and returned by
PDOStatement::fetch(PDO::FETCH_LAZY). PDORow objects seem a bit special
in some ways.
1) PDO::FETCH_LAZY = PDO::FETCH_OBJ + PDO::FETCH_BOTH
PDO::FETCH_BOTH means that the returned data is both indexed by the
column name and a column offset number. For example, a query like SELECT
id FROM test should return an object (resp. array) with the properties
{0} and id. You can access both properties and you get what you want.
But var_dump() will report only the column name based property and not
the property based on the numeric column offset.
I have no idea if this is a var_dump() or a PDO flaw.
2) The magic queryString property
var_dump() reports a queryString property for PDORow objects returned
by PDOStatement::fetch(). In all my testing I found the queryString
propery value to be the query string which has constructed the
corresponding PDOStatement object. However, I cannot access this
property. I see it, but I have no access. That makes it a bit magic.
Also, note how var_dump(), var_export() and debug_zval_dump report
different things. Johannes already explained to me that the functions
might do different things, but anyway it looks confusing to me.
Reproduce code:
---
1, FETCH_LAZY and numeric offset --
sapi/cli/php -r '$db = new
PDO(mysql:dbname=phptest;unix_socket=/tmp/mysql.sock, root, root);
$stmt = $db-prepare(SELECT 1 AS \one\); $stmt-execute(); $row =
$stmt-fetch(PDO::FETCH_LAZY); var_dump($row); var_dump($row-{0});
var_dump($row-one); '
object(PDORow)#3 (2) {
[queryString]=
string(17) SELECT 1 AS one
[one]=
string(1) 1
}
--
string(1) 1
string(1) 1
2, magic PDORow::queryString() -
sapi/cli/php -r '$db = new
PDO(mysql:dbname=phptest;unix_socket=/tmp/mysql.sock, root, root);
$stmt = $db-prepare(SELECT 1 AS \one\); $stmt-execute(); $row =
$stmt-fetch(PDO::FETCH_LAZY); var_dump($row);
var_dump($row-queryString); '
object(PDORow)#3 (2) {
[queryString]=
string(17) SELECT 1 AS one
[one]=
string(1) 1
}
--
UNKNOWN:0
sapi/cli/php -r '$db = new
PDO(mysql:dbname=phptest;unix_socket=/tmp/mysql.sock, root, root);
$db-exec(DROP TABLE test); $db-exec(CREATE TABLE test (id INT));
$db-exec(INSERT INTO test(id) VALUES (1)); $stmt =
$db-prepare(SELECT id FROM test); $stmt-execute(); $row =
$stmt-fetch(PDO::FETCH_LAZY); var_dump($row);
var_dump($row-queryString); var_export($row-queryString); print \n;
debug_zval_dump($row-queryString);'
--
UNKNOWN:0
NULL
UNKNOWN:0
--
Edit this bug report at http://bugs.php.net/?id=44327edit=1
#44637 [Asn-Bgs]: Problem with first use of imagefill
ID: 44637
Updated by: [EMAIL PROTECTED]
Reported By: dpenezic at srce dot hr
-Status: Assigned
+Status: Bogus
Bug Type: GD related
Operating System: Fedora Core 4
PHP Version: 5.2.5
Assigned To: pajoye
New Comment:
Not a but, not able toreproduce.
Previous Comments:
[2008-04-04 12:20:16] dpenezic at srce dot hr
Sent to your email address
[2008-04-04 12:07:57] [EMAIL PROTECTED]
Please provide the file 'some/some/some.png'
What does that mean:
# Nothing happend on image after thiss command
# From this point on everything work correct
...
I really need a script to *reproduce* your problem.
[2008-04-04 12:01:35] dpenezic at srce dot hr
Basic code :
?PHP
$image = @imagecreatefrompng('some/some/some.png');
if ($image === false) {
die ('Unable to open image');
}
$color = imagecolorallocate($image, 0, 0, 0);
imagefill($image, 200, 200, $color);
# Nothing happend on image after thiss command
# From this point on everything work correctly
imagefill($image, 500, 500, $color);
header(Content-type: image/png);
header(Content-Disposition: inline; filename=map.png);
imagepng($image);
?
I have map of country and fill some section with color, then show image
in browser.
[2008-04-04 11:39:18] [EMAIL PROTECTED]
I don't understand what you are trying to describe. Please provide a
small script to reproduce your problem and add links to images if you
need image to illustrate the problem or to show what you would like to
achieve.
[2008-04-04 11:21:17] dpenezic at srce dot hr
Description:
After loading image with imagecreatefrompng, seting colore with
imagecolorallocate , and invoking first imagefill result with no effect
(return code is TRUE). Next imagefill work correctly.
--
Edit this bug report at http://bugs.php.net/?id=44637edit=1
#16263 [Com]: session.start() create new empty session file and not resume existing session
ID: 16263 Comment by: olivieri at onyrix dot com Reported By: kur at natur dot cuni dot cz Status: No Feedback Bug Type: Session related Operating System: ANY PHP Version: 4.3.0-dev New Comment: set in php.ini: session.use_cookies = 1 this works for win xp + apache, and is more secure for id attack to user sessions... Bye dino http://www.onyrix.com Previous Comments: [2008-04-08 16:31:33] mlavoice at netsync dot net I have this issue PHP Version 5.1.6 [2008-03-07 15:41:09] josuaher at hotmail dot com I have the same problem, a new session is created everytime a page is load. I'm using PHP 5.2.5 on Apache 2.0.63 Windows XP. I just don`t know what else to try!! [2008-03-06 22:51:22] smola85 at o2 dot pl Same problem here. Debian 4.0 Apache 2.0 Handler PHP 4.3.10 It works only if I'm not using session_regenerate_id(). When I put session_regenerate_id() before $_SESSION... it doesn't work. [2008-02-20 04:22:24] snakk at inet dot co dot th My same code is work fine on following system. FreeBSD 5.4-RELEASE Apache 2.0 Handler PHP 4.3.10 [2008-02-20 04:18:32] snakk at inet dot co dot th I'm facing the same problem. Waiting for solution or suggestion, please. FreeBSD 6.0-RELEASE Apache 2.0.59 PHP 5.2.4 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/16263 -- Edit this bug report at http://bugs.php.net/?id=16263edit=1
#43229 [Asn]: array_walk() crashes with a segmentation fault
ID: 43229 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Scripting Engine problem Operating System: CentOS PHP Version: 5.2CVS-2008-03-25 (CVS) Assigned To: dmitry New Comment: The crash is not related to variable name. It occurs because the script unset()s the element of array which is still referenced from the array_walk() function. So later array_walk() tries to access freed memory and may crash. The array_walk() manual says: Users may not change the array itself from the callback function. e.g. Add/delete elements, unset elements, etc. If the array that array_walk() is applied to is changed, the behavior of this function is undefined, and unpredictable. I think this bug shouldn't be fixed. Previous Comments: [2008-04-12 14:54:09] [EMAIL PROTECTED] Dmitry, can you please check this out? It's pretty bad if just a certain name of variable causes a crash. [2008-03-25 13:52:12] [EMAIL PROTECTED] Still crashes using latest 5.2 snapshot. [2008-02-09 01:10:05] [EMAIL PROTECTED] Still creashes for me in 5.3CVS. Please do not re-close without ensuring a fix - UMRs or memory corruption can be elusive and not show on some environments while existing on others. [2008-01-22 13:45:26] [EMAIL PROTECTED] Works fine to me. PHP 5.3.0-dev (cli) (built: Jan 18 2008 12:20:16) [2007-12-03 15:13:24] david at grant dot org dot uk Reproduced on PHP 5.2.5 on RHEL 4. #0 zend_call_function (fci=0xbff5f4e0, fci_cache=0xbff5f510) at /home/wdierkes/buildroot/BUILD/php-5.2.5/Zend/zend_execute_API.c:911 #1 0x0309aa8b in php_array_walk (target_hash=0xb7aa1208, userdata=0xbff5f578, recursive=0) at /home/wdierkes/buildroot/BUILD/php-5.2.5/ext/standard/array.c:1114 #2 0x0309ae64 in zif_array_walk (ht=3, return_value=0xb7ab3a78, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /home/wdierkes/buildroot/BUILD/php-5.2.5/ext/standard/array.c:1171 #3 0x0318a244 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff5f7f0) at /home/wdierkes/buildroot/BUILD/php-5.2.5/Zend/zend_vm_execute.h:200 #4 0x0318971a in execute (op_array=0xb7b8d50c) at /home/wdierkes/buildroot/BUILD/php-5.2.5/Zend/zend_vm_execute.h:92 #5 0x03189a1f in zend_do_fcall_common_helper_SPEC (execute_data=0xbff5ffc0) at /home/wdierkes/buildroot/BUILD/php-5.2.5/Zend/zend_vm_execute.h:234 #6 0x0318971a in execute (op_array=0xb7b8cd50) at /home/wdierkes/buildroot/BUILD/php-5.2.5/Zend/zend_vm_execute.h:92 #7 0x03189a1f in zend_do_fcall_common_helper_SPEC (execute_data=0xbff602f0) at /home/wdierkes/buildroot/BUILD/php-5.2.5/Zend/zend_vm_execute.h:234 #8 0x0318971a in execute (op_array=0xb7b891f8) at /home/wdierkes/buildroot/BUILD/php-5.2.5/Zend/zend_vm_execute.h:92 #9 0x03189a1f in zend_do_fcall_common_helper_SPEC (execute_data=0xbff60650) at /home/wdierkes/buildroot/BUILD/php-5.2.5/Zend/zend_vm_execute.h:234 #10 0x0318971a in execute (op_array=0xb7b37e24) at /home/wdierkes/buildroot/BUILD/php-5.2.5/Zend/zend_vm_execute.h:92 #11 0x03189a1f in zend_do_fcall_common_helper_SPEC (execute_data=0xbff625f0) at /home/wdierkes/buildroot/BUILD/php-5.2.5/Zend/zend_vm_execute.h:234 #12 0x0318971a in execute (op_array=0xb7cd7930) at /home/wdierkes/buildroot/BUILD/php-5.2.5/Zend/zend_vm_execute.h:92 #13 0x03168d4b in zend_execute_scripts (type=8, retval=0x1a4, file_count=3) at /home/wdierkes/buildroot/BUILD/php-5.2.5/Zend/zend.c:1134 #14 0x031214fb in php_execute_script (primary_file=0xbff648e0) at /home/wdierkes/buildroot/BUILD/php-5.2.5/main/main.c:2004 #15 0x0320caee in php_handler (r=0x96a8480) at /home/wdierkes/buildroot/BUILD/php-5.2.5/sapi/apache2handler/sapi_apache2.c:631 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/43229 -- Edit this bug report at http://bugs.php.net/?id=43229edit=1
#44716 [NEW]: progress notifications incorrec
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 5.2.5
PHP Bug Type: Streams related
Bug description: progress notifications incorrec
Description:
The stream progress notifications are reporting twice as high numbers (and
twice as often) as they should.
Reproduce code:
---
?php
function stream_notification_callback($notification_code, $severity,
$message, $message_code, $bytes_transferred, $bytes_max) {
switch($notification_code) {
case STREAM_NOTIFY_PROGRESS:
var_dump($bytes_transferred);
break;
}
}
$ctx = stream_context_create();
stream_context_set_params($ctx, array(notification =
stream_notification_callback));
$str =
file_get_contents(http://no.php.net/get/php_manual_en.tar.gz/from/this/mirror;,
null, $ctx, 0, 8192);
var_dump(strlen($str));
echo \nDone!\n;
Expected result:
int(0)
int(0)
int(1440)
int(2880)
int(4320)
int(5760)
int(7200)
int(8192)
Done!
Actual result:
--
int(0)
int(0)
int(1440)
int(2880)
int(4320)
int(5760)
int(7200)
int(8640)
int(10080)
int(11520)
int(12960)
int(14400)
int(8192)
--
Edit bug report at http://bugs.php.net/?id=44716edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44716r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44716r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44716r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44716r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44716r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44716r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44716r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44716r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44716r=support
Expected behavior:http://bugs.php.net/fix.php?id=44716r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44716r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44716r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44716r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44716r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44716r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44716r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44716r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44716r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44716r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44716r=mysqlcfg
#44716 [Opn-Csd]: Progress notifications incorrect
ID: 44716
Updated by: [EMAIL PROTECTED]
-Summary: progress notifications incorrec
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Streams related
Operating System: Linux
PHP Version: 5.2.5
-Assigned To:
+Assigned To: bjori
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2008-04-14 12:14:36] [EMAIL PROTECTED]
Description:
The stream progress notifications are reporting twice as high numbers
(and twice as often) as they should.
Reproduce code:
---
?php
function stream_notification_callback($notification_code, $severity,
$message, $message_code, $bytes_transferred, $bytes_max) {
switch($notification_code) {
case STREAM_NOTIFY_PROGRESS:
var_dump($bytes_transferred);
break;
}
}
$ctx = stream_context_create();
stream_context_set_params($ctx, array(notification =
stream_notification_callback));
$str =
file_get_contents(http://no.php.net/get/php_manual_en.tar.gz/from/this/mirror;,
null, $ctx, 0, 8192);
var_dump(strlen($str));
echo \nDone!\n;
Expected result:
int(0)
int(0)
int(1440)
int(2880)
int(4320)
int(5760)
int(7200)
int(8192)
Done!
Actual result:
--
int(0)
int(0)
int(1440)
int(2880)
int(4320)
int(5760)
int(7200)
int(8640)
int(10080)
int(11520)
int(12960)
int(14400)
int(8192)
--
Edit this bug report at http://bugs.php.net/?id=44716edit=1
#44717 [NEW]: Magic constants: Don't work
From: pazpog at yahoo dot co dot uk Operating system: XP SP2 PHP version: 5.2.5 PHP Bug Type: CGI related Bug description: Magic constants: Don't work Description: Magic constants do not work in CLI. It simply returns the name of the constant - For example, if the constant is called __DIR__, it would just return __DIR__ instead of the directory the script is in. Reproduce code: --- ?php echo(__DIR__); ? Expected result: I expected it to echo the directory the script is in. Eg; E:\phpHuman. Actual result: -- It echos __DIR__ (the name of the constant). -- Edit bug report at http://bugs.php.net/?id=44717edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44717r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44717r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44717r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44717r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44717r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44717r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44717r=needscript Try newer version:http://bugs.php.net/fix.php?id=44717r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44717r=support Expected behavior:http://bugs.php.net/fix.php?id=44717r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44717r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44717r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44717r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44717r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44717r=dst IIS Stability:http://bugs.php.net/fix.php?id=44717r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44717r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44717r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44717r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44717r=mysqlcfg
#44717 [Opn]: Magic constants: Don't work
ID: 44717 User updated by: pazpog at yahoo dot co dot uk Reported By: pazpog at yahoo dot co dot uk Status: Open -Bug Type: CGI related +Bug Type: Directory function related Operating System: XP SP2 PHP Version: 5.2.5 New Comment: Changed the Category (I chose the wrong one). Previous Comments: [2008-04-14 14:44:32] pazpog at yahoo dot co dot uk Description: Magic constants do not work in CLI. It simply returns the name of the constant - For example, if the constant is called __DIR__, it would just return __DIR__ instead of the directory the script is in. Reproduce code: --- ?php echo(__DIR__); ? Expected result: I expected it to echo the directory the script is in. Eg; E:\phpHuman. Actual result: -- It echos __DIR__ (the name of the constant). -- Edit this bug report at http://bugs.php.net/?id=44717edit=1
#44717 [Opn-Bgs]: Magic constants: Don't work
ID: 44717 Updated by: [EMAIL PROTECTED] Reported By: pazpog at yahoo dot co dot uk -Status: Open +Status: Bogus Bug Type: Directory function related Operating System: XP SP2 PHP Version: 5.2.5 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. This is only available in PHP 5.3+ Previous Comments: [2008-04-14 14:48:06] pazpog at yahoo dot co dot uk Changed the Category (I chose the wrong one). [2008-04-14 14:44:32] pazpog at yahoo dot co dot uk Description: Magic constants do not work in CLI. It simply returns the name of the constant - For example, if the constant is called __DIR__, it would just return __DIR__ instead of the directory the script is in. Reproduce code: --- ?php echo(__DIR__); ? Expected result: I expected it to echo the directory the script is in. Eg; E:\phpHuman. Actual result: -- It echos __DIR__ (the name of the constant). -- Edit this bug report at http://bugs.php.net/?id=44717edit=1
#44718 [NEW]: PHP has encountered an Access Violation at 7333F15A
From: tormans at telenet dot be Operating system: Windows XP Pro PHP version: 5.2.5 PHP Bug Type: Reproducible crash Bug description: PHP has encountered an Access Violation at 7333F15A Description: After installing PHP it produces always 'PHP has encountered an Access Violation at 7333F15A' Only page with php_info() works fine! Every page with mssql_ functions give same error What did I do: reinstalled IIS 5.1 reinstalled PHP reconfigured IIS and PHP (Previously installed PHP and IIS and MSSSQL on other computers gave no problems!) Expected result: To work fine like all other installations on laptops! Actual result: -- Mayby something about permissions or rights? On what directories? -- Edit bug report at http://bugs.php.net/?id=44718edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44718r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44718r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44718r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44718r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44718r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44718r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44718r=needscript Try newer version:http://bugs.php.net/fix.php?id=44718r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44718r=support Expected behavior:http://bugs.php.net/fix.php?id=44718r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44718r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44718r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44718r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44718r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44718r=dst IIS Stability:http://bugs.php.net/fix.php?id=44718r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44718r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44718r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44718r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44718r=mysqlcfg
#44719 [NEW]: session_cache_expire() fails to allocate large amount of memory
From: antphill at uk dot ibm dot com Operating system: SUSE Linux PHP version: 6CVS-2008-04-14 (snap) PHP Bug Type: Session related Bug description: session_cache_expire() fails to allocate large amount of memory Description: When I call session_cache_expire() on Linux to get the current cache time (but not set it) I get this weird error message saying that a large amount of memory is being allocated. This does not reproduce on Windows but also appears on a separate Linux build server we have. This scenario occurs with both unicode enabled and disabled. = PHP : /home/ant/php/php6.0/install/bin/php PHP_SAPI: cli PHP_VERSION : 6.0.0-dev ZEND_VERSION: 3.0.0-dev PHP_OS : Linux - Linux linux 2.6.16.21-0.8-default #1 Mon Jul 3 18:25:39 UTC 2006 i686 UNICODE : OFF INI actual : /home/ant/php/php6.0/install/bin More .INIs : CWD : /home/ant/php/php6.0/install/bin Extra dirs : VALGRIND: Not used = R Reproduce code: --- ?php var_dump(session_cache_expire()); ? Expected result: int(180) Actual result: -- [EMAIL PROTECTED]:~/php/php6.0/install/bin ./php /mnt/hgfs/Projects/Session/php-6.0/Test.php Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 3067441245 bytes) in /mnt/hgfs/Projects/Session/php-6.0/Test.php on line 3 -- Edit bug report at http://bugs.php.net/?id=44719edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44719r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44719r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44719r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44719r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44719r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44719r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44719r=needscript Try newer version:http://bugs.php.net/fix.php?id=44719r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44719r=support Expected behavior:http://bugs.php.net/fix.php?id=44719r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44719r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44719r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44719r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44719r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44719r=dst IIS Stability:http://bugs.php.net/fix.php?id=44719r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44719r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44719r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44719r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44719r=mysqlcfg
#44720 [NEW]: Encoding $_SESSION crashes with recusive arrays
From: antphill at uk dot ibm dot com Operating system: Linux PHP version: 5.2.6RC5 PHP Bug Type: Session related Bug description: Encoding $_SESSION crashes with recusive arrays Description: If I add create a global variable array which contains recursive entries it causes PHP to crash when I register it by calling session_register. This appears to be because the PS_ENCODE_LOOP macro does not check for recursion. Reproduce code: --- ?php $array = array(); $array[foo] = NULL; $array[bar] = NULL; $array[guff] = NULL; $array[blah] = $array; var_dump(session_start()); var_dump(session_register($array)); echo Done!\n; ? Expected result: Perhaps we should check for recusion rather like the JSON extension does (see json_encode_array() in JSON.c)? Actual result: -- bool(true) -- Edit bug report at http://bugs.php.net/?id=44720edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44720r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44720r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44720r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44720r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44720r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44720r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44720r=needscript Try newer version:http://bugs.php.net/fix.php?id=44720r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44720r=support Expected behavior:http://bugs.php.net/fix.php?id=44720r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44720r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44720r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44720r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44720r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44720r=dst IIS Stability:http://bugs.php.net/fix.php?id=44720r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44720r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44720r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44720r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44720r=mysqlcfg
#44721 [NEW]: Calling session_register() can create inaccessible array entries
From: antphill at uk dot ibm dot com
Operating system: Windows XP and Linux
PHP version: 5.2.6RC5
PHP Bug Type: Session related
Bug description: Calling session_register() can create inaccessible array
entries
Description:
If I call session_register with a string key that is in fact an integer,
then it creates an entry in $_SESSION that is inaccessible using array
indexes by a script. I think this is because the extension is adding the
key to the array directly rather than using the hash APIs that convert
string keys to integers where possible.
Reproduce code:
---
?php
session_start();
session_register(123);
var_dump($_SESSION);
var_dump($_SESSION[123]);
var_dump($_SESSION[123]);
?
Actual result:
--
array(1) {
[123]=
NULL
}
Notice: Undefined index: 123 in D:\ant.php on line 5
NULL
Notice: Undefined offset: 123 in D:\ant.php on line 6
NULL
--
Edit bug report at http://bugs.php.net/?id=44721edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44721r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44721r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44721r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44721r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44721r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44721r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44721r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44721r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44721r=support
Expected behavior:http://bugs.php.net/fix.php?id=44721r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44721r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44721r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44721r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44721r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44721r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44721r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44721r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44721r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44721r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44721r=mysqlcfg
#44722 [NEW]: The save_path cannot contain NULL characters
From: antphill at uk dot ibm dot com Operating system: SUSE Linux PHP version: 6CVS-2008-04-14 (snap) PHP Bug Type: Session related Bug description: The save_path cannot contain NULL characters Description: Calling session_save_path() with no arguments produces a warning: The save_path cannot contain NULL characters and returns FALSE instead of an empty string. This only reproduces on Linux, on Windows the test passes as expected. Reproduce code: --- ?php ob_start(); echo *** Testing session_save_path() : error functionality ***\n; $directory = dirname(__FILE__); var_dump(session_save_path()); var_dump(session_save_path($directory)); var_dump(session_save_path()); echo Done; ob_end_flush(); ? Expected result: --EXPECTF-- *** Testing session_save_path() : error functionality *** string(0) string(0) string(%d) %s Done --UEXPECTF-- *** Testing session_save_path() : error functionality *** unicode(0) unicode(0) unicode(%d) %s Done Actual result: -- *** Testing session_save_path() : error functionality *** Warning: session_save_path(): The save_path cannot contain NULL characters. in /mnt/hgfs/Projects/Session/php-6.0/session_save_path_basic.php on line 14 bool(false) string(0) string(34) /mnt/hgfs/Projects/Session/php-6.0 Done -- Edit bug report at http://bugs.php.net/?id=44722edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44722r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44722r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44722r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44722r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44722r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44722r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44722r=needscript Try newer version:http://bugs.php.net/fix.php?id=44722r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44722r=support Expected behavior:http://bugs.php.net/fix.php?id=44722r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44722r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44722r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44722r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44722r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44722r=dst IIS Stability:http://bugs.php.net/fix.php?id=44722r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44722r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44722r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44722r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44722r=mysqlcfg
#44722 [Opn]: The save_path cannot contain NULL characters
ID: 44722 User updated by: antphill at uk dot ibm dot com Reported By: antphill at uk dot ibm dot com Status: Open Bug Type: Session related Operating System: SUSE Linux PHP Version: 6CVS-2008-04-14 (snap) New Comment: Forgot to ssay, this happens with both unicode semantics enabled and disabled. Previous Comments: [2008-04-14 16:20:43] antphill at uk dot ibm dot com Description: Calling session_save_path() with no arguments produces a warning: The save_path cannot contain NULL characters and returns FALSE instead of an empty string. This only reproduces on Linux, on Windows the test passes as expected. Reproduce code: --- ?php ob_start(); echo *** Testing session_save_path() : error functionality ***\n; $directory = dirname(__FILE__); var_dump(session_save_path()); var_dump(session_save_path($directory)); var_dump(session_save_path()); echo Done; ob_end_flush(); ? Expected result: --EXPECTF-- *** Testing session_save_path() : error functionality *** string(0) string(0) string(%d) %s Done --UEXPECTF-- *** Testing session_save_path() : error functionality *** unicode(0) unicode(0) unicode(%d) %s Done Actual result: -- *** Testing session_save_path() : error functionality *** Warning: session_save_path(): The save_path cannot contain NULL characters. in /mnt/hgfs/Projects/Session/php-6.0/session_save_path_basic.php on line 14 bool(false) string(0) string(34) /mnt/hgfs/Projects/Session/php-6.0 Done -- Edit this bug report at http://bugs.php.net/?id=44722edit=1
#44722 [Opn]: The save_path cannot contain NULL characters
ID: 44722 User updated by: antphill at uk dot ibm dot com Reported By: antphill at uk dot ibm dot com Status: Open Bug Type: Session related Operating System: SUSE Linux PHP Version: 6CVS-2008-04-14 (snap) New Comment: In fact just this script causes the segmentation fault: ?php var_dump(session_save_path()); ? Note I have no php.ini actually being used, just the default settings! Previous Comments: [2008-04-14 16:22:20] antphill at uk dot ibm dot com Forgot to ssay, this happens with both unicode semantics enabled and disabled. [2008-04-14 16:20:43] antphill at uk dot ibm dot com Description: Calling session_save_path() with no arguments produces a warning: The save_path cannot contain NULL characters and returns FALSE instead of an empty string. This only reproduces on Linux, on Windows the test passes as expected. Reproduce code: --- ?php ob_start(); echo *** Testing session_save_path() : error functionality ***\n; $directory = dirname(__FILE__); var_dump(session_save_path()); var_dump(session_save_path($directory)); var_dump(session_save_path()); echo Done; ob_end_flush(); ? Expected result: --EXPECTF-- *** Testing session_save_path() : error functionality *** string(0) string(0) string(%d) %s Done --UEXPECTF-- *** Testing session_save_path() : error functionality *** unicode(0) unicode(0) unicode(%d) %s Done Actual result: -- *** Testing session_save_path() : error functionality *** Warning: session_save_path(): The save_path cannot contain NULL characters. in /mnt/hgfs/Projects/Session/php-6.0/session_save_path_basic.php on line 14 bool(false) string(0) string(34) /mnt/hgfs/Projects/Session/php-6.0 Done -- Edit this bug report at http://bugs.php.net/?id=44722edit=1
#44719 [Opn]: session_cache_expire() fails to allocate large amount of memory
ID: 44719
User updated by: antphill at uk dot ibm dot com
Reported By: antphill at uk dot ibm dot com
Status: Open
Bug Type: Session related
Operating System: SUSE Linux
PHP Version: 6CVS-2008-04-14 (snap)
New Comment:
This weirdness also seems to affect session_cache_expire():
--TEST--
Test session_cache_expire() function : variation
--SKIPIF--
?php include('skipif.inc'); ?
--FILE--
?php
ob_start();
/*
* Prototype : int session_cache_expire([int $new_cache_expire])
* Description : Return current cache expire
* Source code : ext/session/session.c
*/
echo *** Testing session_cache_expire() : variation ***\n;
ini_set(session.cache_expire, 360);
var_dump(session_cache_expire());
var_dump(session_cache_expire(999));
var_dump(session_cache_expire(180));
var_dump(session_start());
var_dump(session_cache_expire());
var_dump(session_destroy());
var_dump(session_cache_expire());
echo Done;
ob_end_flush();
?
--EXPECTF--
*** Testing session_cache_expire() : variation ***
int(360)
int(0)
int(999)
bool(true)
int(180)
bool(true)
int(0)
Done
Previous Comments:
[2008-04-14 15:47:49] antphill at uk dot ibm dot com
Description:
When I call session_cache_expire() on Linux to get the current cache
time (but not set it) I get this weird error message saying that a large
amount of memory is being allocated. This does not reproduce on Windows
but also appears on a separate Linux build server we have.
This scenario occurs with both unicode enabled and disabled.
=
PHP : /home/ant/php/php6.0/install/bin/php
PHP_SAPI: cli
PHP_VERSION : 6.0.0-dev
ZEND_VERSION: 3.0.0-dev
PHP_OS : Linux - Linux linux 2.6.16.21-0.8-default #1 Mon Jul 3
18:25:39 UTC 2006 i686
UNICODE : OFF
INI actual : /home/ant/php/php6.0/install/bin
More .INIs :
CWD : /home/ant/php/php6.0/install/bin
Extra dirs :
VALGRIND: Not used
=
R
Reproduce code:
---
?php
var_dump(session_cache_expire());
?
Expected result:
int(180)
Actual result:
--
[EMAIL PROTECTED]:~/php/php6.0/install/bin ./php
/mnt/hgfs/Projects/Session/php-6.0/Test.php
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 3067441245 bytes) in
/mnt/hgfs/Projects/Session/php-6.0/Test.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=44719edit=1
#44714 [Opn-Bgs]: Mcrypt decrypt output bug in Firefox
ID: 44714 Updated by: [EMAIL PROTECTED] Reported By: isedc at yahoo dot com -Status: Open +Status: Bogus Bug Type: mcrypt related Operating System: Windows Vista PHP Version: 5.2.5 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 XTEA is a block algorithm, so it only encrypts/decrypts in blocks. It will therefore pad the string with \0 bytes up until the block size. Those you see as ? when outputting the decrypted result. Previous Comments: [2008-04-14 07:12:09] isedc at yahoo dot com Description: Following an MCRYPT example on php.net, when decrypting a string that is less than 8 characters, will output in firefox and appended with ? marks to fill the other characters. Example: ecrypted string is 4 characters long (abcd), when decrypting the string and outputting to firefox displays: abcd This was tested with Firefox 2.0.13. This does not appear to affect Internet Explorer 7. Reproduce code: --- $key = d9Qg%R*; $text = abcd; $iv_size = mcrypt_get_iv_size(MCRYPT_XTEA, MCRYPT_MODE_ECB); $iv = mcrypt_create_iv($iv_size, MCRYPT_RAND); $enc = mcrypt_encrypt(MCRYPT_XTEA, $key, $text, MCRYPT_MODE_ECB, $iv); $crypttext = mcrypt_decrypt(MCRYPT_XTEA, $key, $enc, MCRYPT_MODE_ECB, $iv); echo $crypttext; Expected result: echo output should be: abcd Actual result: -- echo output is actually: abcd -- Edit this bug report at http://bugs.php.net/?id=44714edit=1
#44724 [NEW]: file_get_contents() returns wrong url
From: carlwenrich at yahoo dot com Operating system: Windows or Linux PHP version: 5.2.5 PHP Bug Type: URL related Bug description: file_get_contents() returns wrong url Description: PROBLEM: The file_get_contents() function returns the wrong url. OVERVIEW: If you point your browser to http://finance.yahoo.com/q/op?s=A; you will get the first set of options (in this case April 2008) for Agilent. If you point it to http://finance.yahoo.com/q/op?s=Am=2008-05; you will get the second set (in this case May 2008). HOWEVER: If you use the file_get_contents() function you will get the first set regardless of which url you use. It ignores the m=2008-05. Reproduce code: --- $url = http://finance.yahoo.com/q/op?s=Am=2008-05;; $content = file_get_contents($url); Expected result: I expected the May 2008 options page. Actual result: -- I got the April 2008 options page. -- Edit bug report at http://bugs.php.net/?id=44724edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44724r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44724r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44724r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44724r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44724r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44724r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44724r=needscript Try newer version:http://bugs.php.net/fix.php?id=44724r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44724r=support Expected behavior:http://bugs.php.net/fix.php?id=44724r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44724r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44724r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44724r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44724r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44724r=dst IIS Stability:http://bugs.php.net/fix.php?id=44724r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44724r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44724r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44724r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44724r=mysqlcfg
#44724 [Opn-Bgs]: file_get_contents() returns wrong url
ID: 44724 Updated by: [EMAIL PROTECTED] Reported By: carlwenrich at yahoo dot com -Status: Open +Status: Bogus Bug Type: URL related Operating System: Windows or Linux PHP Version: 5.2.5 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Can't reproduce Previous Comments: [2008-04-14 16:43:20] carlwenrich at yahoo dot com Description: PROBLEM: The file_get_contents() function returns the wrong url. OVERVIEW: If you point your browser to http://finance.yahoo.com/q/op?s=A; you will get the first set of options (in this case April 2008) for Agilent. If you point it to http://finance.yahoo.com/q/op?s=Am=2008-05; you will get the second set (in this case May 2008). HOWEVER: If you use the file_get_contents() function you will get the first set regardless of which url you use. It ignores the m=2008-05. Reproduce code: --- $url = http://finance.yahoo.com/q/op?s=Am=2008-05;; $content = file_get_contents($url); Expected result: I expected the May 2008 options page. Actual result: -- I got the April 2008 options page. -- Edit this bug report at http://bugs.php.net/?id=44724edit=1
#44711 [Opn]: parser crashes with ibase_query
ID: 44711 User updated by: m dot muncke at computer1020 dot at Reported By: m dot muncke at computer1020 dot at Status: Open Bug Type: Reproducible crash Operating System: freeBSD-7.0-RELEASE PHP Version: 5.2.5 New Comment: I am sorry, but I can not follow the procedures as stated in the document you indicated because gdb crashes in both scenarios. Previous Comments: [2008-04-13 21:11:45] m dot muncke at computer1020 dot at gdb gdb /var/gdb.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd...(no debugging symbols found)... Core was generated by `gdb'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libreadline.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libreadline.so.7 Reading symbols from /lib/libncurses.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libncurses.so.7 Reading symbols from /usr/lib/libgnuregex.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgnuregex.so.4 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/lib/libthread_db.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libthread_db.so Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x2837594d in calloc () from /lib/libc.so.7 [2008-04-13 21:05:29] m dot muncke at computer1020 dot at Problem is, when I run httpd -X and execute phpbug.php I receive a Segfault with gdb.core !!! [2008-04-13 20:01:12] [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 for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2008-04-13 19:36:13] m dot muncke at computer1020 dot at php is running in mod_php apache22 php modules installed: php-interbase, php-ftp, php-imap, php-pcre [2008-04-13 19:32:17] m dot muncke at computer1020 dot at Description: while parsing a script that contains $x-query(select * from table); I know that it is during parse because before query I can add jdsgjg; and there is no error message I use a db_fbsql.php include file that contains the class DB; I get Segmentation fault when I run httpd -X and execute the php but I do not find a core file When I run gdb httpd run -X I get a segfault in gdb The same script was running under php 5.2.3 but does not under php 5.2.5 Reproduce code: --- http://www.trackseller.com/phpbug.txt Expected result: execute php - echo finished; page returns empty. Actual result: -- I get a segfault but i do not find the core. Can you tell me where I find that under freeBSD ? -- Edit this bug report at http://bugs.php.net/?id=44711edit=1
#44721 [Opn-Bgs]: Calling session_register() can create inaccessible array entries
ID: 44721
Updated by: [EMAIL PROTECTED]
Reported By: antphill at uk dot ibm dot com
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: Windows XP and Linux
PHP Version: 5.2.6RC5
New Comment:
RTFM.
Previous Comments:
[2008-04-14 16:09:00] antphill at uk dot ibm dot com
Description:
If I call session_register with a string key that is in fact an
integer, then it creates an entry in $_SESSION that is inaccessible
using array indexes by a script. I think this is because the extension
is adding the key to the array directly rather than using the hash APIs
that convert string keys to integers where possible.
Reproduce code:
---
?php
session_start();
session_register(123);
var_dump($_SESSION);
var_dump($_SESSION[123]);
var_dump($_SESSION[123]);
?
Actual result:
--
array(1) {
[123]=
NULL
}
Notice: Undefined index: 123 in D:\ant.php on line 5
NULL
Notice: Undefined offset: 123 in D:\ant.php on line 6
NULL
--
Edit this bug report at http://bugs.php.net/?id=44721edit=1
#44720 [Opn-Bgs]: Encoding $_SESSION crashes with recusive arrays
ID: 44720 Updated by: [EMAIL PROTECTED] Reported By: antphill at uk dot ibm dot com -Status: Open +Status: Bogus Bug Type: Session related Operating System: Linux PHP Version: 5.2.6RC5 New Comment: session_register() is deprecated. DO NOT USE. Ever. RTFM about $_SESSION. Previous Comments: [2008-04-14 16:04:14] antphill at uk dot ibm dot com Description: If I add create a global variable array which contains recursive entries it causes PHP to crash when I register it by calling session_register. This appears to be because the PS_ENCODE_LOOP macro does not check for recursion. Reproduce code: --- ?php $array = array(); $array[foo] = NULL; $array[bar] = NULL; $array[guff] = NULL; $array[blah] = $array; var_dump(session_start()); var_dump(session_register($array)); echo Done!\n; ? Expected result: Perhaps we should check for recusion rather like the JSON extension does (see json_encode_array() in JSON.c)? Actual result: -- bool(true) -- Edit this bug report at http://bugs.php.net/?id=44720edit=1
#44718 [Opn-Bgs]: PHP has encountered an Access Violation at 7333F15A
ID: 44718 Updated by: [EMAIL PROTECTED] Reported By: tormans at telenet dot be -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Windows XP Pro PHP Version: 5.2.5 New Comment: We are aware of PHP's problems with stability under IIS and are working to rectify the problem. Unfortunatly your bug report does not contain any extra useful information and we already have enough bug reports open about this issue. If you can provide more detailed information such as a reproducable crash or a backtrace please do so and reopen this bug. Otherwise please keep trying new releases as we are working to resolve the problems on this platform Thanks for your interest in PHP. Previous Comments: [2008-04-14 14:53:16] tormans at telenet dot be Description: After installing PHP it produces always 'PHP has encountered an Access Violation at 7333F15A' Only page with php_info() works fine! Every page with mssql_ functions give same error What did I do: reinstalled IIS 5.1 reinstalled PHP reconfigured IIS and PHP (Previously installed PHP and IIS and MSSSQL on other computers gave no problems!) Expected result: To work fine like all other installations on laptops! Actual result: -- Mayby something about permissions or rights? On what directories? -- Edit this bug report at http://bugs.php.net/?id=44718edit=1
#44711 [Opn-Bgs]: parser crashes with ibase_query
ID: 44711 Updated by: [EMAIL PROTECTED] Reported By: m dot muncke at computer1020 dot at -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: freeBSD-7.0-RELEASE PHP Version: 5.2.5 New Comment: Fix your system. No PHP bug here. Previous Comments: [2008-04-14 17:11:01] m dot muncke at computer1020 dot at I am sorry, but I can not follow the procedures as stated in the document you indicated because gdb crashes in both scenarios. [2008-04-13 21:11:45] m dot muncke at computer1020 dot at gdb gdb /var/gdb.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd...(no debugging symbols found)... Core was generated by `gdb'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libreadline.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libreadline.so.7 Reading symbols from /lib/libncurses.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libncurses.so.7 Reading symbols from /usr/lib/libgnuregex.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgnuregex.so.4 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/lib/libthread_db.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libthread_db.so Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x2837594d in calloc () from /lib/libc.so.7 [2008-04-13 21:05:29] m dot muncke at computer1020 dot at Problem is, when I run httpd -X and execute phpbug.php I receive a Segfault with gdb.core !!! [2008-04-13 20:01:12] [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 for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2008-04-13 19:36:13] m dot muncke at computer1020 dot at php is running in mod_php apache22 php modules installed: php-interbase, php-ftp, php-imap, php-pcre 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/44711 -- Edit this bug report at http://bugs.php.net/?id=44711edit=1
#44711 [Bgs]: parser crashes with ibase_query
ID: 44711 User updated by: m dot muncke at computer1020 dot at Reported By: m dot muncke at computer1020 dot at Status: Bogus Bug Type: Reproducible crash Operating System: freeBSD-7.0-RELEASE PHP Version: 5.2.5 New Comment: I installed gdb 6.6 and received the following executing phpbug.php : ---Type return to continue, or q return to quit--- Program received signal SIGSEGV, Segmentation fault. 0x28b5adff in ThreadData::restoreSpecific () from /usr/local/lib/libfbclient.so.2 (gdb) (gdb) (gdb) bt #0 0x28b5adff in ThreadData::restoreSpecific () from /usr/local/lib/libfbclient.so.2 #1 0x28b6fd1f in error () from /usr/local/lib/libfbclient.so.2 #2 0x28b7733a in REM_attach_database () from /usr/local/lib/libfbclient.so.2 #3 0x28b64b1b in isc_attach_database () from /usr/local/lib/libfbclient.so.2 #4 0x28b2f411 in _php_ibase_attach_db () from /usr/local/lib/php/20060613-debug/interbase.so #5 0x28b2f845 in _php_ibase_connect () from /usr/local/lib/php/20060613-debug/interbase.so #6 0x289107a0 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfbfcc78) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_vm_execute.h:200 #7 0x28916299 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbfbfcc78) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_vm_execute.h:1681 #8 0x289102f2 in execute (op_array=0x28c48168) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_vm_execute.h:92 #9 0x2891091a in zend_do_fcall_common_helper_SPEC (execute_data=0xbfbfd018) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_vm_execute.h:234 #10 0x2891143d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfbfd018) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_vm_execute.h:322 #11 0x289102f2 in execute (op_array=0x28c483cc) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_vm_execute.h:92 #12 0x2891091a in zend_do_fcall_common_helper_SPEC (execute_data=0xbfbfd398) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_vm_execute.h:234 ---Type return to continue, or q return to quit--- #13 0x2891143d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfbfd398) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_vm_execute.h:322 #14 0x289102f2 in execute (op_array=0x28c32258) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_vm_execute.h:92 #15 0x288ea902 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend.c:1215 #16 0x28896406 in php_execute_script (primary_file=0xbfbfe98c) at /usr/ports/lang/php5/work/php-5.2.5/main/main.c:2025 #17 0x289665b2 in php_handler (r=0x28cc3050) at /usr/ports/lang/php5/work/php-5.2.5/sapi/apache2handler/sapi_apache2.c:635 #18 0x08074559 in ap_run_handler () #19 0x08077827 in ap_invoke_handler () #20 0x08082650 in ap_process_request () #21 0x0807f8eb in ap_process_http_connection () #22 0x0807b759 in ap_run_process_connection () #23 0x08086c97 in child_main () #24 0x08086f63 in make_child () #25 0x08087b11 in ap_mpm_run () #26 0x08061fe5 in main () Previous Comments: [2008-04-14 17:48:53] [EMAIL PROTECTED] Fix your system. No PHP bug here. [2008-04-14 17:11:01] m dot muncke at computer1020 dot at I am sorry, but I can not follow the procedures as stated in the document you indicated because gdb crashes in both scenarios. [2008-04-13 21:11:45] m dot muncke at computer1020 dot at gdb gdb /var/gdb.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd...(no debugging symbols found)... Core was generated by `gdb'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libreadline.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libreadline.so.7 Reading symbols from /lib/libncurses.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libncurses.so.7 Reading symbols from /usr/lib/libgnuregex.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgnuregex.so.4 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/lib/libthread_db.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libthread_db.so Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for
#44711 [Bgs]: parser crashes with ibase_query
ID: 44711 Updated by: [EMAIL PROTECTED] Reported By: m dot muncke at computer1020 dot at Status: Bogus Bug Type: Reproducible crash Operating System: freeBSD-7.0-RELEASE PHP Version: 5.2.5 New Comment: It's still bogus, the crash obviously happens outside PHP, in some 3rd party library. Previous Comments: [2008-04-14 17:54:14] m dot muncke at computer1020 dot at I installed gdb 6.6 and received the following executing phpbug.php : ---Type return to continue, or q return to quit--- Program received signal SIGSEGV, Segmentation fault. 0x28b5adff in ThreadData::restoreSpecific () from /usr/local/lib/libfbclient.so.2 (gdb) (gdb) (gdb) bt #0 0x28b5adff in ThreadData::restoreSpecific () from /usr/local/lib/libfbclient.so.2 #1 0x28b6fd1f in error () from /usr/local/lib/libfbclient.so.2 #2 0x28b7733a in REM_attach_database () from /usr/local/lib/libfbclient.so.2 #3 0x28b64b1b in isc_attach_database () from /usr/local/lib/libfbclient.so.2 #4 0x28b2f411 in _php_ibase_attach_db () from /usr/local/lib/php/20060613-debug/interbase.so #5 0x28b2f845 in _php_ibase_connect () from /usr/local/lib/php/20060613-debug/interbase.so #6 0x289107a0 in zend_do_fcall_common_helper_SPEC (execute_data=0xbfbfcc78) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_vm_execute.h:200 #7 0x28916299 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (execute_data=0xbfbfcc78) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_vm_execute.h:1681 #8 0x289102f2 in execute (op_array=0x28c48168) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_vm_execute.h:92 #9 0x2891091a in zend_do_fcall_common_helper_SPEC (execute_data=0xbfbfd018) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_vm_execute.h:234 #10 0x2891143d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfbfd018) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_vm_execute.h:322 #11 0x289102f2 in execute (op_array=0x28c483cc) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_vm_execute.h:92 #12 0x2891091a in zend_do_fcall_common_helper_SPEC (execute_data=0xbfbfd398) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_vm_execute.h:234 ---Type return to continue, or q return to quit--- #13 0x2891143d in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfbfd398) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_vm_execute.h:322 #14 0x289102f2 in execute (op_array=0x28c32258) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend_vm_execute.h:92 #15 0x288ea902 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/ports/lang/php5/work/php-5.2.5/Zend/zend.c:1215 #16 0x28896406 in php_execute_script (primary_file=0xbfbfe98c) at /usr/ports/lang/php5/work/php-5.2.5/main/main.c:2025 #17 0x289665b2 in php_handler (r=0x28cc3050) at /usr/ports/lang/php5/work/php-5.2.5/sapi/apache2handler/sapi_apache2.c:635 #18 0x08074559 in ap_run_handler () #19 0x08077827 in ap_invoke_handler () #20 0x08082650 in ap_process_request () #21 0x0807f8eb in ap_process_http_connection () #22 0x0807b759 in ap_run_process_connection () #23 0x08086c97 in child_main () #24 0x08086f63 in make_child () #25 0x08087b11 in ap_mpm_run () #26 0x08061fe5 in main () [2008-04-14 17:48:53] [EMAIL PROTECTED] Fix your system. No PHP bug here. [2008-04-14 17:11:01] m dot muncke at computer1020 dot at I am sorry, but I can not follow the procedures as stated in the document you indicated because gdb crashes in both scenarios. [2008-04-13 21:11:45] m dot muncke at computer1020 dot at gdb gdb /var/gdb.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd...(no debugging symbols found)... Core was generated by `gdb'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libreadline.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libreadline.so.7 Reading symbols from /lib/libncurses.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libncurses.so.7 Reading symbols from /usr/lib/libgnuregex.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgnuregex.so.4 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from
#44725 [NEW]: more byte output in flush function
From: hack988 at gamil dot com
Operating system: CentOS release 5
PHP version: 5.2.6RC5
PHP Bug Type: Apache2 related
Bug description: more byte output in flush function
Description:
flush function output for html body in some times.it disappear at begin
and end of html body.
exsample code:
?php
define('XML_RPC', TRUE);
$XMLRPCVersion=1.0;
flush();
exit;
more code
?
it display:
0
?php
define('XML_RPC', TRUE);
$XMLRPCVersion=1.0;
ob_flush();
exit;
more code
?
it display nothing
compare with to http headers i found that:
Content-Length: 0
exist when use ob_flush but not exist in flush
so i add this in my php codes like this
?php
define('XML_RPC', TRUE);
$XMLRPCVersion=1.0;
header(Content-Length: 0);
flush();
exit;
more code
?
now all thing is work will!
i download php source code an compare flush with ob_flush.
in ob_flush:
if (send_buffer) {
if (just_flush) { /* if flush is called prior to proper end,
ensure
presence of NUL */
final_buffer[final_buffer_length] = '\0';
}
OG(php_body_write)(final_buffer, final_buffer_length TSRMLS_CC);
}
in flush:
if (sapi_module.flush) {
sapi_module.flush(SG(server_context));
return SUCCESS;
} else {
return FAILURE;
}
i can't understand well with this codes but i think maybe some buffer is
not zeromemory befor used.
--
Edit bug report at http://bugs.php.net/?id=44725edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44725r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44725r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44725r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44725r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44725r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44725r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44725r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44725r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44725r=support
Expected behavior:http://bugs.php.net/fix.php?id=44725r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44725r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44725r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44725r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44725r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44725r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44725r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44725r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44725r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44725r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44725r=mysqlcfg
#44726 [NEW]: date_timezone_set function feature request
From: danik at mit dot edu Operating system: centos4 PHP version: 5.2CVS-2008-04-14 (snap) PHP Bug Type: Feature/Change Request Bug description: date_timezone_set function feature request Description: Dear Derick and Date Developers, First of all, thank you adding timezone and dst support to PHP. I'm so glad that I don't have to write this class myself and deal with maintaining the backend. I would like to request automatic dst handling for the DateTime object. Currently, there is no automatic way to apply a timezone dst offset to the DateTime object. I'm in the process of writing code that iterates through the timezone transitions array, similar to the sample code from your 2007 talk. I would love to refactor my code to use a call like this: void date_timezone_set( DateTime $object, DateTimeZone $timezone, [, int $apply_dst_offset] ) Similarly, the date_create function could also take the same optional argument. Please let me know if this realistic. Thank you for your time, Dan -- Edit bug report at http://bugs.php.net/?id=44726edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44726r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44726r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44726r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44726r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44726r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44726r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44726r=needscript Try newer version:http://bugs.php.net/fix.php?id=44726r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44726r=support Expected behavior:http://bugs.php.net/fix.php?id=44726r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44726r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44726r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44726r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44726r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44726r=dst IIS Stability:http://bugs.php.net/fix.php?id=44726r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44726r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44726r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44726r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44726r=mysqlcfg
#44727 [NEW]: PHP installs but will not serve pages
From: stevenhunt_ at hotmail dot com Operating system: Vista Ultimate 64bit PHP version: 5.2.5 PHP Bug Type: IIS related Bug description: PHP installs but will not serve pages Description: After successfully installing PHP i ryed to run a basic php info page and got an extension error. as best i can see this is due to it beinf a 32bit application but changeing the proccess thread to allow 32 bit applications then causes a service unavailable and crashed the process thread. Reproduce code: --- install and try PHP on vista ultimate 64bit edition. Expected result: phpinfo() to execute and pages to run Actual result: -- HTTP Error 500.21 - Internal Server Error Handler PHP-ISAPI has a bad module IsapiModule in its module list Module IIS Web Core Notification ExecuteRequestHandler Handler PHP-ISAPI Error Code 0x8007000d Requested URL http://localhost:80/info.php Physical Path C:\inetpub\wwwroot\info.php Logon Method Anonymous Logon User Anonymous -- Edit bug report at http://bugs.php.net/?id=44727edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44727r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44727r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44727r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44727r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44727r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44727r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44727r=needscript Try newer version:http://bugs.php.net/fix.php?id=44727r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44727r=support Expected behavior:http://bugs.php.net/fix.php?id=44727r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44727r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44727r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44727r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44727r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44727r=dst IIS Stability:http://bugs.php.net/fix.php?id=44727r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44727r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44727r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44727r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44727r=mysqlcfg
#44686 [Opn]: SOAP-ERROR: Parsing WSDL
ID: 44686
User updated by: dmittner at llnw dot com
Reported By: dmittner at llnw dot com
Status: Open
Bug Type: SOAP related
Operating System: Gentoo
PHP Version: 5.2.5
New Comment:
I've narrowed it down, I think.
Relevant excerpts from the WSDL:
s:element name=ProvisionMonitors
s:complexType
s:sequence
s:element minOccurs=0 maxOccurs=1 ref=ProvisioningOrder /
/s:sequence
/s:complexType
/s:element
s:element name=ProvisioningOrder type=ProvisioningOrder /
s:complexType name=ProvisioningOrder
s:complexContent mixed=false
s:extension base=CServiceObject
s:sequence
s:element minOccurs=0 maxOccurs=1 name=MonitorOrders
type=ArrayOfMonitorOrder /
...
/s:sequence
s:attribute name=name type=s:string /
...
/s:extension
/s:complexContent
/s:complexType
No name is specified in the upper block of XML, for the line with the
ref=. If I specify a name the WSDL parses. I believe the correct
behavior would be for PHP to acquire the name from the complexType
declaration. I don't know if this should always be the case for
references, or only when no name is provided - if providing a name is
even valid for them.
This is just a guess, though. I've dealt very little with references so
do not know the standards surrounding them; only what digging into the
XML has revealed.
Previous Comments:
[2008-04-11 05:54:01] dmittner at llnw dot com
I have also found this to occur on PHP 5.0.5, also on Gentoo.
[2008-04-10 23:52:37] dmittner at llnw dot com
Description:
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
Schema: unresolved element 'ref' attribute.
C# generated WSDL. I saw an older bug with similar characteristics, but
that was 4 years old, supposedly resolved, and on a different OS.
Several validators I tried are able to consume the WSDL.
Reproduce code:
---
?php
$wsdl =
http://gpn.webservice.gomez.com/GpnProvisioningService/ProvisioningWS.asmx?wsdl;;
$soap = new
SoapClient($wsdl,array(trace=true,features=SOAP_SINGLE_ELEMENT_ARRAYS));
?
Expected result:
No explicit output.
Actual result:
--
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
Schema: unresolved element 'ref' attribute in /home/dmittner/temp.php:3
Stack trace:
#0 /home/dmittner/temp.php(3):
SoapClient-SoapClient('http://gpn.webs...', Array)
#1 {main}
thrown in /home/dmittner/temp.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=44686edit=1
#44728 [NEW]: fnmatch() is undefined
From: alex dot offshore at gmail dot com
Operating system: Windows Vista
PHP version: 5.2.5
PHP Bug Type: *Directory/Filesystem functions
Bug description: fnmatch() is undefined
Description:
Fatal error occures when trying to call fnmatch(): the function is
undefined.
Reproduce code:
---
fnmatch('anypattern', 'anystring');
--
Edit bug report at http://bugs.php.net/?id=44728edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44728r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44728r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44728r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44728r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44728r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44728r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44728r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44728r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44728r=support
Expected behavior:http://bugs.php.net/fix.php?id=44728r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44728r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44728r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44728r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44728r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44728r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44728r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44728r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44728r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44728r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44728r=mysqlcfg
#44728 [Opn-Bgs]: fnmatch() is undefined
ID: 44728
Updated by: [EMAIL PROTECTED]
Reported By: alex dot offshore at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: *Directory/Filesystem functions
Operating System: Windows Vista
PHP Version: 5.2.5
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
http://www.php.net/fnmatch
For now this function is not available on Windows or other non-POSIX
compliant systems.
Previous Comments:
[2008-04-15 00:07:10] alex dot offshore at gmail dot com
Description:
Fatal error occures when trying to call fnmatch(): the function is
undefined.
Reproduce code:
---
fnmatch('anypattern', 'anystring');
--
Edit this bug report at http://bugs.php.net/?id=44728edit=1
#44726 [Opn-Bgs]: date_timezone_set function feature request
ID: 44726 Updated by: [EMAIL PROTECTED] Reported By: danik at mit dot edu -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: centos4 PHP Version: 5.2CVS-2008-04-14 (snap) New Comment: DST is automatically taken into account by the date functions, that's why you define the location and not just a particular offset. Previous Comments: [2008-04-14 19:40:12] danik at mit dot edu Description: Dear Derick and Date Developers, First of all, thank you adding timezone and dst support to PHP. I'm so glad that I don't have to write this class myself and deal with maintaining the backend. I would like to request automatic dst handling for the DateTime object. Currently, there is no automatic way to apply a timezone dst offset to the DateTime object. I'm in the process of writing code that iterates through the timezone transitions array, similar to the sample code from your 2007 talk. I would love to refactor my code to use a call like this: void date_timezone_set( DateTime $object, DateTimeZone $timezone, [, int $apply_dst_offset] ) Similarly, the date_create function could also take the same optional argument. Please let me know if this realistic. Thank you for your time, Dan -- Edit this bug report at http://bugs.php.net/?id=44726edit=1
#44722 [Opn-Csd]: The save_path cannot contain NULL characters
ID: 44722 Updated by: [EMAIL PROTECTED] Reported By: antphill at uk dot ibm dot com -Status: Open +Status: Closed Bug Type: Session related Operating System: SUSE Linux PHP Version: 6CVS-2008-04-14 (snap) New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-04-14 16:27:37] antphill at uk dot ibm dot com In fact just this script causes the segmentation fault: ?php var_dump(session_save_path()); ? Note I have no php.ini actually being used, just the default settings! [2008-04-14 16:22:20] antphill at uk dot ibm dot com Forgot to ssay, this happens with both unicode semantics enabled and disabled. [2008-04-14 16:20:43] antphill at uk dot ibm dot com Description: Calling session_save_path() with no arguments produces a warning: The save_path cannot contain NULL characters and returns FALSE instead of an empty string. This only reproduces on Linux, on Windows the test passes as expected. Reproduce code: --- ?php ob_start(); echo *** Testing session_save_path() : error functionality ***\n; $directory = dirname(__FILE__); var_dump(session_save_path()); var_dump(session_save_path($directory)); var_dump(session_save_path()); echo Done; ob_end_flush(); ? Expected result: --EXPECTF-- *** Testing session_save_path() : error functionality *** string(0) string(0) string(%d) %s Done --UEXPECTF-- *** Testing session_save_path() : error functionality *** unicode(0) unicode(0) unicode(%d) %s Done Actual result: -- *** Testing session_save_path() : error functionality *** Warning: session_save_path(): The save_path cannot contain NULL characters. in /mnt/hgfs/Projects/Session/php-6.0/session_save_path_basic.php on line 14 bool(false) string(0) string(34) /mnt/hgfs/Projects/Session/php-6.0 Done -- Edit this bug report at http://bugs.php.net/?id=44722edit=1
#44719 [Opn-Csd]: session_cache_expire() fails to allocate large amount of memory
ID: 44719
Updated by: [EMAIL PROTECTED]
Reported By: antphill at uk dot ibm dot com
-Status: Open
+Status: Closed
Bug Type: Session related
Operating System: SUSE Linux
PHP Version: 6CVS-2008-04-14 (snap)
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2008-04-14 16:13:57] antphill at uk dot ibm dot com
This weirdness also seems to affect session_cache_expire():
--TEST--
Test session_cache_expire() function : variation
--SKIPIF--
?php include('skipif.inc'); ?
--FILE--
?php
ob_start();
/*
* Prototype : int session_cache_expire([int $new_cache_expire])
* Description : Return current cache expire
* Source code : ext/session/session.c
*/
echo *** Testing session_cache_expire() : variation ***\n;
ini_set(session.cache_expire, 360);
var_dump(session_cache_expire());
var_dump(session_cache_expire(999));
var_dump(session_cache_expire(180));
var_dump(session_start());
var_dump(session_cache_expire());
var_dump(session_destroy());
var_dump(session_cache_expire());
echo Done;
ob_end_flush();
?
--EXPECTF--
*** Testing session_cache_expire() : variation ***
int(360)
int(0)
int(999)
bool(true)
int(180)
bool(true)
int(0)
Done
[2008-04-14 15:47:49] antphill at uk dot ibm dot com
Description:
When I call session_cache_expire() on Linux to get the current cache
time (but not set it) I get this weird error message saying that a large
amount of memory is being allocated. This does not reproduce on Windows
but also appears on a separate Linux build server we have.
This scenario occurs with both unicode enabled and disabled.
=
PHP : /home/ant/php/php6.0/install/bin/php
PHP_SAPI: cli
PHP_VERSION : 6.0.0-dev
ZEND_VERSION: 3.0.0-dev
PHP_OS : Linux - Linux linux 2.6.16.21-0.8-default #1 Mon Jul 3
18:25:39 UTC 2006 i686
UNICODE : OFF
INI actual : /home/ant/php/php6.0/install/bin
More .INIs :
CWD : /home/ant/php/php6.0/install/bin
Extra dirs :
VALGRIND: Not used
=
R
Reproduce code:
---
?php
var_dump(session_cache_expire());
?
Expected result:
int(180)
Actual result:
--
[EMAIL PROTECTED]:~/php/php6.0/install/bin ./php
/mnt/hgfs/Projects/Session/php-6.0/Test.php
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to
allocate 3067441245 bytes) in
/mnt/hgfs/Projects/Session/php-6.0/Test.php on line 3
--
Edit this bug report at http://bugs.php.net/?id=44719edit=1
#44720 [Bgs-Csd]: Encoding $_SESSION crashes with recusive arrays
ID: 44720 Updated by: [EMAIL PROTECTED] Reported By: antphill at uk dot ibm dot com -Status: Bogus +Status: Closed Bug Type: Session related Operating System: Linux PHP Version: 5.2.6RC5 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Even though session_register has been removed in 6.0, I don't agree with leaving a segfault. I've fixed this in 5.3 and I'll backport to 5.2 once I check with ilia. Previous Comments: [2008-04-14 17:47:45] [EMAIL PROTECTED] session_register() is deprecated. DO NOT USE. Ever. RTFM about $_SESSION. [2008-04-14 16:04:14] antphill at uk dot ibm dot com Description: If I add create a global variable array which contains recursive entries it causes PHP to crash when I register it by calling session_register. This appears to be because the PS_ENCODE_LOOP macro does not check for recursion. Reproduce code: --- ?php $array = array(); $array[foo] = NULL; $array[bar] = NULL; $array[guff] = NULL; $array[blah] = $array; var_dump(session_start()); var_dump(session_register($array)); echo Done!\n; ? Expected result: Perhaps we should check for recusion rather like the JSON extension does (see json_encode_array() in JSON.c)? Actual result: -- bool(true) -- Edit this bug report at http://bugs.php.net/?id=44720edit=1
#44729 [NEW]: display_errors = Off not respected
From: hsbrown2 at verizon dot net Operating system: Windows Server 2008 PHP version: 5.2.5 PHP Bug Type: PHP options/info functions Bug description: display_errors = Off not respected Description: On Windows Server 2008 fcgi, display_errors = Off is not respected running PHP 5.2.5 NTS. The php.ini is loaded. I have logging going to a file, and I can see the errors being logged in the file. I have a sanitized copy of my phpinfo() ready when needed. Reproduce code: --- N/A Expected result: I expect errors to not be displayed in the browser, but rather, logged to the file only (it is doing both). Actual result: -- As output to Browser: MyJSpace Notice: Constant DS already defined in E:\wwwroot\modules\mod_myjspace\mod_myjspace.php on line 25 Please login to create or modify your page ViewMJSPages Notice: Constant _MJSEXEC already defined in E:\wwwroot\modules\mod_viewmjspages\mod_viewmjspages.php on line 21 Notice: Constant DS already defined in E:\wwwroot\modules\mod_viewmjspages\mod_viewmjspages.php on line 22 No pages created -- Edit bug report at http://bugs.php.net/?id=44729edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44729r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44729r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44729r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44729r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44729r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44729r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44729r=needscript Try newer version:http://bugs.php.net/fix.php?id=44729r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44729r=support Expected behavior:http://bugs.php.net/fix.php?id=44729r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44729r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44729r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44729r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44729r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44729r=dst IIS Stability:http://bugs.php.net/fix.php?id=44729r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44729r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44729r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44729r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44729r=mysqlcfg
