#41046 [NEW]: PHP has encountered an Access Violation at 0227A495

[tech at juuce dot com]

From: tech at juuce dot com
Operating system: W2K3 Server - Web Editio
PHP version:  5.2.1
PHP Bug Type: IIS related
Bug description:  PHP has encountered an Access Violation at 0227A495

Description:

PHP has encountered an Access Violation at 0227A495

Setup : 
W2K3 - Web Edition
IIS6
PHP 5.2.1 (ISAPI) + Extensions (mysql...)
Zend - 3.2.2

This error is encountered on all sites running under IIS6 with PHP-5.2.1
as ISAPI module which request a php page. (note Zend Optimiser 3.2.2 is
running but reproducable when disabled)
This error Message only seems to appear when IIS is restarted and the page
is requested for the first time.

Once this error appears the file seems to be locked and it cannot be
deleted.

PHP.ini Changes are 
Extensions
Loaction of Log files and TMP upload directory.
WSDL temp directory


Reproduce code:
---
echo 'test';

Expected result:

See Test String

Actual result:
--
PHP has encountered an Access Violation at 0227A495

-- 
Edit bug report at http://bugs.php.net/?id=41046&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41046&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41046&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41046&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41046&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41046&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41046&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41046&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41046&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41046&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41046&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41046&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41046&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41046&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41046&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41046&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41046&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41046&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41046&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41046&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41046&r=mysqlcfg

#41045 [NEW]: intval returns different values, depending on the PHP version

[xris01 at free dot fr]

From: xris01 at free dot fr
Operating system: Debian Sarge
PHP version:  5.2.1
PHP Bug Type: Math related
Bug description:  intval returns different values, depending on the PHP version

Description:

I understand that floats are expected to overflow when converted to int.

What I don't, is why I don't have the same result on the same hardware
with 2 versions of PHP :



Reproduce code:
---
$var = -2302452860;
echo 'var_dump($var) = '; echo var_dump($var); echo "";
echo '$var = '; echo $var; echo "";
echo 'intval($var) = '; echo intval($var); echo "";

On PHP 5.2.1, it returns :
var_dump($var) = float(-2302452860)
$var = -2302452860
intval($var) = -2147483648

On PHP 5.1.6, it returns :
var_dump($var) = float(-2302452860)
$var = -2302452860
intval($var) = 1992514436

Is there anyway to get, in any case, the truncated result ? Any php.ini
parameter ?

Thanks.


-- 
Edit bug report at http://bugs.php.net/?id=41045&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41045&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41045&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41045&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41045&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41045&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41045&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41045&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41045&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41045&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41045&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41045&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41045&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41045&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41045&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41045&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41045&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41045&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41045&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41045&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41045&r=mysqlcfg

#40931 [Asn->Csd]: open_basedir bypass via symlink and move_uploaded_file()

[tony2001]

 ID:   40931
 Updated by:   [EMAIL PROTECTED]
 Reported By:  vladimir at petrov dot ks dot ua
-Status:   Assigned
+Status:   Closed
 Bug Type: Safe Mode/open_basedir
 Operating System: Linix
 PHP Version:  5.2.1
 Assigned To:  tony2001
 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:


[2007-03-27 21:19:24] vladimir at petrov dot ks dot ua

I have sent access information to my server to [EMAIL PROTECTED]
I see this bug really working.



[2007-03-27 20:33:26] [EMAIL PROTECTED]

Cannot reproduce.



[2007-03-27 19:59:46] vladimir at petrov dot ks dot ua

open_basedir actually used.
If I try to write directly to target directory by

move_uploaded_file($_FILES["userfile"]["tmp_name"],"/home/user2/public_html/file.ext")

I got proper error message in browser and in the apache error log.



[2007-03-27 18:40:17] [EMAIL PROTECTED]

Make sure the open_basedir option is actually used and not overriden in
another way.



[2007-03-27 18:30:13] vladimir at petrov dot ks dot ua

Description:

User can bypass open_basedir restriction by move_uploaded_file() if
target file path is symlink to any directory.



Reproduce code:
---
user1 will upload file to user2's /home/user2/public_html folder.

We have in /etc/passwd:
user1:x:32001:32001::/home/user1:/bin/bash
user2:x:32002:32002::/home/user2:/bin/bash

Target folder allows to write for anybody:
# ls -lA /home/user2
drwxrwxrwx  2 user2 user2 4096 Mar 27 17:31 public_html/

Apache have mod_php intalled. Apache config for user1:

ServerName user1.xxx.com
DocumentRoot /home/user1/public_html
User user1
php_admin_value open_basedir "/home/user1"



User user1 can do something like:

$ cd /home/user1/public_html/
$ ln -s /home/user2/public_html user2_public_html
$ echo ' 
 
 
 
 
 
 
 
' > upload.php




Expected result:

If we access http://user1.xxx.com/upload.php after file upload
expected message
"Upload failed"
and no file 
/home/user2/public_html/file.ext
in target folder.



Actual result:
--
If we access http://user1.xxx.com/upload.php after file upload we
got message
"Upload ok"
and file 
/home/user2/public_html/file.ext
well exist in target folder.







-- 
Edit this bug report at http://bugs.php.net/?id=40931&edit=1

#41034 [Asn]: json_encode ignores null byte started keys in arrays

[tony2001]

 ID:   41034
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at sameprecision dot org
 Status:   Assigned
 Bug Type: Unknown/Other Function
 Operating System: suse linux 10, windows XP sp2
 PHP Version:  5.2.1
-Assigned To:  tony2001
+Assigned To:  iliaa
 New Comment:

Reassigned to Ilia per his request.


Previous Comments:


[2007-04-10 18:06:09] php at sameprecision dot org

woops

if (key[0] == '\0' && keylen == 1) {
  /* Skip protected and private members. */
  continue;
}



[2007-04-10 17:53:11] php at sameprecision dot org

In /ext/json/json.c line 190:

if (key[0] == '\0') {
  /* Skip protected and private members. */
  continue;
}


Looks like condition should be (key[0] == '\0' && strlen(key)==1)



[2007-04-10 04:40:29] php at sameprecision dot org

Description:

If a key in an array starts with the null byte, json_encode ignores
that key=>value pair.

This seems wrong because json_encode doesn't care about null bytes
anywhere in the value (and neither does javascript, about keys or
values).

Reproduce code:
---
//works as expected:
echo json_encode(array(0,"a\0b"=>1,"\0null-prefixed value"));

echo "\n\n";

//ignores second element whose key begins with null byte:
echo json_encode(array(0,"\0ab"=>1,"\0null-prefixed value"));

Expected result:

{"0":0,"a\0b":1,"1":"\0null-prefixed value"}

{"0":0,"\0ab":1,"1":"\0null-prefixed value"}




// \0 represents an actual null byte here

Actual result:
--
{"0":0,"a\0b":1,"1":"\0null-prefixed value"}

{"0":0,"1":"\0null-prefixed value"}




// \0 represents an actual null byte here







-- 
Edit this bug report at http://bugs.php.net/?id=41034&edit=1

#41039 [Bgs]: SQL join with bound parameter fails with 'text, ntext, image' error.

[emil at troxy dot net]

 ID:   41039
 User updated by:  emil at troxy dot net
 Reported By:  emil at troxy dot net
 Status:   Bogus
 Bug Type: PDO related
 Operating System: Windows Server 2003
 PHP Version:  5.2.1
 New Comment:

I'm sorry if my bug submission doesn't belong here.
Anyway, I was able to reproduce this problem using a simple subquery
aswell.
So it seems like this is a resubmission of bug #36561.


Previous Comments:


[2007-04-10 15:20:00] [EMAIL PROTECTED]

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  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.





[2007-04-10 15:08:14] emil at troxy dot net

Description:

I'm trying to do a simple SQL join using a prepared statement with a
bound parameter as a part of the condition.
The execution of the statement fails with an exception saying that I'm
trying to do a compare on text, ntext or image data types, even though
the tables don't contain these types.

Reproduce code:
---
CREATE TABLE [table1] (
[id] [int] NOT NULL 
) ON [PRIMARY]

CREATE TABLE [table2] (
[id] [int] NOT NULL 
) ON [PRIMARY]

INSERT INTO [table1] VALUES(1)
INSERT INTO [table2] VALUES(1)

setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$stmt = $dbh->prepare("SELECT t1.id, t2.id FROM table1 t1 INNER JOIN
table2 t2 ON (t1.id = ?) AND (t2.id = 1)");
$stmt->bindValue(1, 1, PDO::PARAM_INT);
$stmt->execute();
?>

Expected result:

The statement should execute without errors and return TRUE.

Actual result:
--
PHP Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[42000]: Syntax error or access violation: 306 [Microsoft][ODBC
SQL Server Driver][SQL Server]The text, ntext, and image data types
cannot be compared or sorted, except when using IS NULL or LIKE
operator. (SQLExecute[306] at ext\pdo_odbc\odbc_stmt.c:133)' in
D:\Website\pdo.php:8 Stack trace: #0 D:\Website\pdo.php(8):
PDOStatement->execute() #1 {main} thrown in D:\Website\pdo.php on line 8





-- 
Edit this bug report at http://bugs.php.net/?id=41039&edit=1

#40970 [Bgs]: filemtime/stat slower on PHP5 vs PHP4

[stas]

 ID:   40970
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at edwardk dot info
 Status:   Bogus
 Bug Type: Performance problem
 Operating System: Windows 2003
 PHP Version:  5.2.1
 New Comment:

I tried to run php 4.4.6 vs. php 5.2.1 and on both examples I had PHP 5
faster than PHP 4. Maybe you have some other setting interfering? Try
testing with empty php.ini - it would use defaults for both. 


Previous Comments:


[2007-04-10 10:35:50] php at edwardk dot info

I have new information, the slowness is present only when safe mode is
on.
(for 1000 iterations)
For PHP 4.4.6
-
G:\>C:\php4\php.exe -n -d safe_mode=On filemtime.php
X-Powered-By: PHP/4.4.6
Content-type: text/plain

Took 7.451ms
G:\>C:\php4\php.exe -n -d safe_mode=Off filemtime.php
X-Powered-By: PHP/4.4.6
Content-type: text/plain

Took 0.152ms
G:\>



For PHP 5.2.1
-
G:\>C:\php5\php-cgi.exe -n -d safe_mode=On filemtime.php
X-Powered-By: PHP/5.2.1
Content-type: text/plain

Took 12.172ms
G:\>C:\php5\php-cgi.exe -n -d safe_mode=Off filemtime.php
X-Powered-By: PHP/5.2.1
Content-type: text/plain

Took 0.108ms
G:\>


Additionally, I checked with FileMon, and the requests made are
different for each version (Safe mode On).

PHP 4.4.6
6:03:02.751 AM  php.exe:2344OPENG:\ SUCCESS Options: Open Directory 
Access: 0011
6:03:02.751
AM  php.exe:2344DIRECTORY   G:\ SUCCESS 
FileBothDirectoryInformation:
filemtime.php   
6:03:02.751 AM  php.exe:2344CLOSE   G:\ SUCCESS 

PHP 5.2.1
6:03:04.158 AM  php-cgi.exe:2216QUERY
INFORMATION G:\filemtime.phpSUCCESS Attributes: A   
6:03:04.158 AM  php-cgi.exe:2216OPENG:\ SUCCESS Options: Open
Directory  Access: 0011 
6:03:04.158
AM  php-cgi.exe:2216DIRECTORY   G:\ SUCCESS 
FileBothDirectoryInformation:
filemtime.php   
6:03:04.158 AM  php-cgi.exe:2216CLOSE   G:\ SUCCESS 



note the additional "QUERY INFORMATION" access.


I've tried disabling safe mode and though performance has improved, it
is still slower than the PHP4 version on my script when run under an
apache module. The stats are now:

~40ms safe mode on (PHP5)
~15ms safe mode off (PHP5)

~5.5ms safe mode on (PHP4)
~0.7ms safe mode off (PHP4)



[2007-04-02 20:38:07] php at edwardk dot info

One thing I have noticed is that when the PHP5 version runs, Apache2's
kernel CPU time shoots up (measured in (Process Explorer) while
processing the request where as in PHP4, CPU use remains low.



[2007-04-02 20:32:03] php at edwardk dot info

Here's the new code:


and the results:
PHP 4.4.6
Took 5.232ms for 481 files
PHP 5.2.1
Took 107.762ms for 481 files



[2007-04-02 20:13:21] [EMAIL PROTECTED]

Might be related to stat cache usage... Try to see if you see the
difference stat'ing a set of files in random order, not the same file
repeatedly.



[2007-04-01 20:42:47] php at edwardk dot info

I have modified the code to use, $blah = stat('.htaccess');
This file does exist, it is 161 bytes on NTFS.

PHP 4.4.6: 1.641ms
PHP 5.1.2: 108.29ms

Normally, I would be using the commands on many small files (400ish) in
the current folder to determine if any of them had changed. This was
fast enough on PHP4, but on PHP5, the same code takes much longer.



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/40970

-- 
Edit this bug report at http://bugs.php.net/?id=40970&edit=1

#40633 [Asn]: disk_free_space returns a bad result on filesystems with negative free space

[stas]

 ID:   40633
 Updated by:   [EMAIL PROTECTED]
 Reported By:  adam-phpbugs at adam dot gs
 Status:   Assigned
 Bug Type: Filesystem function related
 Operating System: FreeBSD
 PHP Version:  5.2.1
 Assigned To:  tony2001
 New Comment:

Funny thing is that PHP doesn't use any unsigned numbers on the way -
it translates it directly from system call int64 to double. I guess
version of the system and header file defining struct statvfs would be
useful.


Previous Comments:


[2007-02-26 15:44:08] [EMAIL PROTECTED]

Please provide an SSH account on a machine where I can reproduce it.



[2007-02-26 13:33:03] adam-phpbugs at adam dot gs

changing OS to FreeBSD



[2007-02-26 13:32:36] adam-phpbugs at adam dot gs

This was FreeBSD

if you look at the FreeBSD manpage for tunefs(8), this is 
the intended behaviour.

http://www.freebsd.org/cgi/man.cgi?
query=tunefs&apropos=0&sektion=0&manpath=FreeBSD+6.2-
RELEASE&format=html


Basically, in FreeBSD (under UFS2 at least) avaliable space 
is calculated as total minus used minus reserved. A small % 
(8 by default) is reserved.

So, this is not really a bug, but actually an intended 
feature.



[2007-02-26 09:33:41] [EMAIL PROTECTED]

What kind of BSD is that and don't you think that negative free space
is a BSD bug?



[2007-02-26 00:55:02] adam-phpbugs at adam dot gs

Description:

on a filesystem with a negative amount of free space (this 
can happen on at least FreeBSD) disk_free_space returns 
unreasonable results.

-=[/some/path]=- -=[Sun Feb 25]=- -=[19:51:55]=-
[EMAIL PROTECTED] php -r 'print disk_free_space(".")."\n";'
3.77789318629E+22
-=[/some/path]=- -=[Sun Feb 25]=- -=[19:51:57]=-
[EMAIL PROTECTED] df -h .
FilesystemSizeUsed   Avail Capacity  Mounted on
/dev/ad7  289G289G-23G   109%/some/path
-=[/some/path]=- -=[Sun Feb 25]=- -=[19:51:58]=-
[EMAIL PROTECTED] df .
Filesystem 1K-blocks  Used Avail Capacity  Mounted 
on
/dev/ad7   302732078 302699550 -24186038   109%/some/
path


Reproduce code:
---
php -r 'print disk_free_space(".")."\n";'

Expected result:

-24186038

Actual result:
--
3.77789318629E+22





-- 
Edit this bug report at http://bugs.php.net/?id=40633&edit=1

#41043 [Opn->Csd]: pdo_oci crash when freeing error text with persistent connection

[tony2001]

 ID:   41043
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bpd at keynetics dot com
-Status:   Open
+Status:   Closed
 Bug Type: PDO related
 Operating System: linux
 PHP Version:  5.2.1
 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:


[2007-04-10 19:34:17] bpd at keynetics dot com

This patch seems to fix the problem. I think that the pefree() macro is
being used incorrectly as the code which populates the einfo.errmsg
member is not persistent aware.

--- oci_driver.c.orig   2007-04-10 11:33:52.0 -0600
+++ oci_driver.c2007-04-10 11:33:59.0 -0600
@@ -206,7 +206,7 @@
}

if (H->einfo.errmsg) {
-   pefree(H->einfo.errmsg, dbh->is_persistent);
+   efree(H->einfo.errmsg);
H->einfo.errmsg = NULL;
}



[2007-04-10 19:29:05] bpd at keynetics dot com

Description:

A segmentation fault results when the pdo_oci driver receives an error
message from the oracle server.

Reproduce code:
---
 true));
} catch (Exception $e) {
  echo "Caught exception: ", $e->getMessage(), "\n";
}


Expected result:

Caught exception: SQLSTATE[42S02]: pdo_oci_handle_factory: ORA-12154:
TNS:could not resolve the connect identifier specified
 (/opt/php/src/ext/pdo_oci/oci_driver.c:462)


Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1235028304 (LWP 19840)]
0xb6920a2f in free () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0xb6920a2f in free () from /lib/tls/i686/cmov/libc.so.6
#1  0x08212c8c in oci_handle_closer ()
#2  0x08213db1 in pdo_oci_handle_factory ()
#3  0x082068b1 in zim_PDO_dbh_constructor ()
#4  0x084978b9 in execute_internal ()
#5  0xb6589b51 in xdebug_execute_internal
(current_execute_data=0xbfaf1d40,
return_value_used=0, tsrm_ls=0x87b5038)
at /tmp/pear/cache/xdebug-2.0.0RC3/xdebug.c:1550
#6  0x0849810f in zend_do_fcall_common_helper_SPEC ()
#7  0x08498f87 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER ()
#8  0x08497bcb in execute ()
#9  0xb6589594 in xdebug_execute (op_array=0xb65f8d84,
tsrm_ls=0x87b5038)
at /tmp/pear/cache/xdebug-2.0.0RC3/xdebug.c:1487
#10 0x08474758 in zend_execute_scripts ()
#11 0x08415e88 in php_execute_script ()
#12 0x084f920e in main ()






-- 
Edit this bug report at http://bugs.php.net/?id=41043&edit=1

#41044 [Opn->Bgs]: informix extension not exist

[tony2001]

 ID:   41044
 Updated by:   [EMAIL PROTECTED]
 Reported By:  lpiccilli at gelre dot com dot br
-Status:   Open
+Status:   Bogus
 Bug Type: Informix related
 Operating System: linux
 PHP Version:  5.2.1
 New Comment:

http://php.net/ifx

Note: This extension has been moved to the PECL repository and is no
longer bundled with PHP as of PHP 5.2.1.


Previous Comments:


[2007-04-10 20:00:51] lpiccilli at gelre dot com dot br

Description:

The option --with-informix not exists in php 5.2.1. 

Reproduce code:
---
./configure --help not shows the option --with-informix

Expected result:

If the extension was removed, the documentation should be updated.
How to make php works with informix without that extension?







-- 
Edit this bug report at http://bugs.php.net/?id=41044&edit=1

#41044 [NEW]: informix extension not exist

[lpiccilli at gelre dot com dot br]

From: lpiccilli at gelre dot com dot br
Operating system: linux
PHP version:  5.2.1
PHP Bug Type: Informix related
Bug description:  informix extension not exist

Description:

The option --with-informix not exists in php 5.2.1. 

Reproduce code:
---
./configure --help not shows the option --with-informix

Expected result:

If the extension was removed, the documentation should be updated.
How to make php works with informix without that extension?



-- 
Edit bug report at http://bugs.php.net/?id=41044&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41044&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41044&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41044&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41044&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41044&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41044&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41044&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41044&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41044&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41044&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41044&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41044&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41044&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41044&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41044&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41044&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41044&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41044&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41044&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41044&r=mysqlcfg

#41043 [Opn]: pdo_oci crash when freeing error text with persistent connection

[bpd at keynetics dot com]

 ID:   41043
 User updated by:  bpd at keynetics dot com
 Reported By:  bpd at keynetics dot com
 Status:   Open
 Bug Type: PDO related
 Operating System: linux
 PHP Version:  5.2.1
 New Comment:

This patch seems to fix the problem. I think that the pefree() macro is
being used incorrectly as the code which populates the einfo.errmsg
member is not persistent aware.

--- oci_driver.c.orig   2007-04-10 11:33:52.0 -0600
+++ oci_driver.c2007-04-10 11:33:59.0 -0600
@@ -206,7 +206,7 @@
}

if (H->einfo.errmsg) {
-   pefree(H->einfo.errmsg, dbh->is_persistent);
+   efree(H->einfo.errmsg);
H->einfo.errmsg = NULL;
}


Previous Comments:


[2007-04-10 19:29:05] bpd at keynetics dot com

Description:

A segmentation fault results when the pdo_oci driver receives an error
message from the oracle server.

Reproduce code:
---
 true));
} catch (Exception $e) {
  echo "Caught exception: ", $e->getMessage(), "\n";
}


Expected result:

Caught exception: SQLSTATE[42S02]: pdo_oci_handle_factory: ORA-12154:
TNS:could not resolve the connect identifier specified
 (/opt/php/src/ext/pdo_oci/oci_driver.c:462)


Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1235028304 (LWP 19840)]
0xb6920a2f in free () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0xb6920a2f in free () from /lib/tls/i686/cmov/libc.so.6
#1  0x08212c8c in oci_handle_closer ()
#2  0x08213db1 in pdo_oci_handle_factory ()
#3  0x082068b1 in zim_PDO_dbh_constructor ()
#4  0x084978b9 in execute_internal ()
#5  0xb6589b51 in xdebug_execute_internal
(current_execute_data=0xbfaf1d40,
return_value_used=0, tsrm_ls=0x87b5038)
at /tmp/pear/cache/xdebug-2.0.0RC3/xdebug.c:1550
#6  0x0849810f in zend_do_fcall_common_helper_SPEC ()
#7  0x08498f87 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER ()
#8  0x08497bcb in execute ()
#9  0xb6589594 in xdebug_execute (op_array=0xb65f8d84,
tsrm_ls=0x87b5038)
at /tmp/pear/cache/xdebug-2.0.0RC3/xdebug.c:1487
#10 0x08474758 in zend_execute_scripts ()
#11 0x08415e88 in php_execute_script ()
#12 0x084f920e in main ()






-- 
Edit this bug report at http://bugs.php.net/?id=41043&edit=1

#41043 [NEW]: pdo_oci crash when freeing error text with persistent connection

[bpd at keynetics dot com]

From: bpd at keynetics dot com
Operating system: linux
PHP version:  5.2.1
PHP Bug Type: PDO related
Bug description:  pdo_oci crash when freeing error text with persistent 
connection

Description:

A segmentation fault results when the pdo_oci driver receives an error
message from the oracle server.

Reproduce code:
---
 true));
} catch (Exception $e) {
  echo "Caught exception: ", $e->getMessage(), "\n";
}


Expected result:

Caught exception: SQLSTATE[42S02]: pdo_oci_handle_factory: ORA-12154:
TNS:could not resolve the connect identifier specified
 (/opt/php/src/ext/pdo_oci/oci_driver.c:462)


Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1235028304 (LWP 19840)]
0xb6920a2f in free () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0  0xb6920a2f in free () from /lib/tls/i686/cmov/libc.so.6
#1  0x08212c8c in oci_handle_closer ()
#2  0x08213db1 in pdo_oci_handle_factory ()
#3  0x082068b1 in zim_PDO_dbh_constructor ()
#4  0x084978b9 in execute_internal ()
#5  0xb6589b51 in xdebug_execute_internal
(current_execute_data=0xbfaf1d40,
return_value_used=0, tsrm_ls=0x87b5038)
at /tmp/pear/cache/xdebug-2.0.0RC3/xdebug.c:1550
#6  0x0849810f in zend_do_fcall_common_helper_SPEC ()
#7  0x08498f87 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER ()
#8  0x08497bcb in execute ()
#9  0xb6589594 in xdebug_execute (op_array=0xb65f8d84, tsrm_ls=0x87b5038)
at /tmp/pear/cache/xdebug-2.0.0RC3/xdebug.c:1487
#10 0x08474758 in zend_execute_scripts ()
#11 0x08415e88 in php_execute_script ()
#12 0x084f920e in main ()


-- 
Edit bug report at http://bugs.php.net/?id=41043&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41043&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41043&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41043&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41043&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41043&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41043&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41043&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41043&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41043&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41043&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41043&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41043&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41043&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41043&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41043&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41043&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41043&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41043&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41043&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41043&r=mysqlcfg

#40701 [Opn->Fbk]: Memory allocation error

[tony2001]

 ID:   40701
 Updated by:   [EMAIL PROTECTED]
 Reported By:  michaeldaly at magma dot ca
-Status:   Open
+Status:   Feedback
 Bug Type: Unknown/Other Function
 Operating System: Win XP Pro
 PHP Version:  5.2.2
 New Comment:

We still have no idea on how to reproduce it.


Previous Comments:


[2007-04-10 18:06:36] michaeldaly at magma dot ca

Two snaps have been applied since the last suggestion with no chnage -
the problem still occurs.



[2007-04-05 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2007-03-28 08:41:53] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip





[2007-03-27 23:07:11] priyadi at priyadi dot net

I think I found the culprit. In my case it is my ulimits. my 
previous ulimits were (taken from 'ulimit -a'):

core file size (blocks, -c) 0
data seg size (kbytes, -d) 20480
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) 60
max user processes (-u) 20
virtual memory (kbytes, -v) 20480

now they are:

core file size (blocks, -c) 0
data seg size (kbytes, -d) 204800
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) 600
max user processes (-u) 200
virtual memory (kbytes, -v) 204800

so, my case is probably not related to this bug, sorry.



[2007-03-27 22:35:54] priyadi at priyadi dot net

this occurs to me too with PHP 5.2.1 and mediawiki 1.9.3. in my 
case, the error message stays constant: "Fatal error: Out of memory 
(allocated 5242880) (tried to allocate 1245184 bytes) in 
*/web/languages/messages/MessagesEn.php on line 2106.

this is on RHEL 3. memory_limit is set to 128M and PHP is using CGI 
API, so I don't think this problem is related to apache.

this works in my development machine though (gentoo, same PHP 
version running as apache module).



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/40701

-- 
Edit this bug report at http://bugs.php.net/?id=40701&edit=1

#40701 [NoF->Opn]: Memory allocation error

[michaeldaly at magma dot ca]

 ID:   40701
 User updated by:  michaeldaly at magma dot ca
-Summary:  Interesting observation
 Reported By:  michaeldaly at magma dot ca
-Status:   No Feedback
+Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: Win XP Pro
 PHP Version:  5.2.2
 New Comment:

Two snaps have been applied since the last suggestion with no chnage -
the problem still occurs.


Previous Comments:


[2007-04-05 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2007-03-28 08:41:53] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip





[2007-03-27 23:07:11] priyadi at priyadi dot net

I think I found the culprit. In my case it is my ulimits. my 
previous ulimits were (taken from 'ulimit -a'):

core file size (blocks, -c) 0
data seg size (kbytes, -d) 20480
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) 60
max user processes (-u) 20
virtual memory (kbytes, -v) 20480

now they are:

core file size (blocks, -c) 0
data seg size (kbytes, -d) 204800
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) 600
max user processes (-u) 200
virtual memory (kbytes, -v) 204800

so, my case is probably not related to this bug, sorry.



[2007-03-27 22:35:54] priyadi at priyadi dot net

this occurs to me too with PHP 5.2.1 and mediawiki 1.9.3. in my 
case, the error message stays constant: "Fatal error: Out of memory 
(allocated 5242880) (tried to allocate 1245184 bytes) in 
*/web/languages/messages/MessagesEn.php on line 2106.

this is on RHEL 3. memory_limit is set to 128M and PHP is using CGI 
API, so I don't think this problem is related to apache.

this works in my development machine though (gentoo, same PHP 
version running as apache module).



[2007-03-25 20:19:42] michaeldaly at magma dot ca

While testing a new php program, I inadvertently coded an infinite
loop.  While running it, the thing failed at over 400MB with an
allocation error.  

This shows the config is capable of using lots of memory and the
repeated failures at 0.7MB to 9MB seem anomalous.



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/40701

-- 
Edit this bug report at http://bugs.php.net/?id=40701&edit=1

#41034 [Asn]: json_encode ignores null byte started keys in arrays

[php at sameprecision dot org]

 ID:   41034
 User updated by:  php at sameprecision dot org
 Reported By:  php at sameprecision dot org
 Status:   Assigned
 Bug Type: Unknown/Other Function
 Operating System: suse linux 10, windows XP sp2
 PHP Version:  5.2.1
 Assigned To:  tony2001
 New Comment:

woops

if (key[0] == '\0' && keylen == 1) {
  /* Skip protected and private members. */
  continue;
}


Previous Comments:


[2007-04-10 17:53:11] php at sameprecision dot org

In /ext/json/json.c line 190:

if (key[0] == '\0') {
  /* Skip protected and private members. */
  continue;
}


Looks like condition should be (key[0] == '\0' && strlen(key)==1)



[2007-04-10 04:40:29] php at sameprecision dot org

Description:

If a key in an array starts with the null byte, json_encode ignores
that key=>value pair.

This seems wrong because json_encode doesn't care about null bytes
anywhere in the value (and neither does javascript, about keys or
values).

Reproduce code:
---
//works as expected:
echo json_encode(array(0,"a\0b"=>1,"\0null-prefixed value"));

echo "\n\n";

//ignores second element whose key begins with null byte:
echo json_encode(array(0,"\0ab"=>1,"\0null-prefixed value"));

Expected result:

{"0":0,"a\0b":1,"1":"\0null-prefixed value"}

{"0":0,"\0ab":1,"1":"\0null-prefixed value"}




// \0 represents an actual null byte here

Actual result:
--
{"0":0,"a\0b":1,"1":"\0null-prefixed value"}

{"0":0,"1":"\0null-prefixed value"}




// \0 represents an actual null byte here







-- 
Edit this bug report at http://bugs.php.net/?id=41034&edit=1

#41034 [Asn]: json_encode ignores null byte started keys in arrays

[php at sameprecision dot org]

 ID:   41034
 User updated by:  php at sameprecision dot org
 Reported By:  php at sameprecision dot org
 Status:   Assigned
 Bug Type: Unknown/Other Function
 Operating System: suse linux 10, windows XP sp2
 PHP Version:  5.2.1
 Assigned To:  tony2001
 New Comment:

In /ext/json/json.c line 190:

if (key[0] == '\0') {
  /* Skip protected and private members. */
  continue;
}


Looks like condition should be (key[0] == '\0' && strlen(key)==1)


Previous Comments:


[2007-04-10 04:40:29] php at sameprecision dot org

Description:

If a key in an array starts with the null byte, json_encode ignores
that key=>value pair.

This seems wrong because json_encode doesn't care about null bytes
anywhere in the value (and neither does javascript, about keys or
values).

Reproduce code:
---
//works as expected:
echo json_encode(array(0,"a\0b"=>1,"\0null-prefixed value"));

echo "\n\n";

//ignores second element whose key begins with null byte:
echo json_encode(array(0,"\0ab"=>1,"\0null-prefixed value"));

Expected result:

{"0":0,"a\0b":1,"1":"\0null-prefixed value"}

{"0":0,"\0ab":1,"1":"\0null-prefixed value"}




// \0 represents an actual null byte here

Actual result:
--
{"0":0,"a\0b":1,"1":"\0null-prefixed value"}

{"0":0,"1":"\0null-prefixed value"}




// \0 represents an actual null byte here







-- 
Edit this bug report at http://bugs.php.net/?id=41034&edit=1

#41041 [Bgs]: Relax NG validation fails with DTD defined entities

[bleathem at gmail dot com]

 ID:   41041
 User updated by:  bleathem at gmail dot com
 Reported By:  bleathem at gmail dot com
 Status:   Bogus
 Bug Type: DOM XML related
 Operating System: Max OS/X 10.4.9
 PHP Version:  5.2.1
 Assigned To:  rrichards
 New Comment:

Thanks, this solved my problem exactly.

And sorry for wasting your time.  I did read through the PHP
documentation extensively, I was however looking in the section on DOM,
rather than libxml.

Believe me, the effort involved in submitting a bug report (installing
the latest version, writing sample code, etc. etc.) makes it a last
resort!


Previous Comments:


[2007-04-10 16:11:25] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

you need to substitute the entities LIBXML_NOENT when loading the xml
into the DOM document.



[2007-04-10 15:50:45] bleathem at gmail dot com

Description:

I've created a xml file that uses a doctype to define html entities.
I've created an accompanying Relax NG file to validate the file. If the
xml element that contains the entity follows an Relax NG 
block, the validation fails. I have demonstrated this in the
accompanying source code. The variable $xml is validated against two
Relax NG schemas, where the preceding elements are contained in an
 block, and one where the are not. The validation fails in
the  case.

I have tried the validation using an online validator (java based, uses
jing), see:
http://hsivonen.iki.fi/validator/
so it is not the XML or the Relax NG, but rather the validator itself.

I have found other circumstances where the presence entities cause the
validation to fail, I can provided these if they are necessary.

Reproduce code:
---


]>
http://www.triumf.info/common/xml/eec";
  xmlns="http://www.w3.org/1999/xhtml";>

Isotope
sec_isotope
text
μ

EOF;

$rng = <<

http://relaxng.org/ns/structure/1.0";
 xmlns:eec="http://www.triumf.info/common/xml/eec";>
 
  

  
  
  
  
  
  

  


EOF;

$rng2 = <<

http://relaxng.org/ns/structure/1.0";
 xmlns:eec="http://www.triumf.info/common/xml/eec";>
 
  

  
  
  
  

  


EOF;

ini_set( 'track_errors', 1);
ini_set('error_reporting', E_ALL | E_STRICT);

$dom = new DOMDocument();
$dom->loadXML($xml, LIBXML_DTDLOAD|LIBXML_DTDATTR);

echo "1st Time";
if ($dom->relaxNGValidateSource($rng)) echo "Relax NG validated";
else echo $php_errormsg;

echo "2nd Time";
if ($dom->relaxNGValidateSource($rng2)) echo "Relax NG validated";
else echo $php_errormsg;
?> 

Expected result:

1st Time
Relax NG validated
2nd Time
Relax NG validated

Actual result:
--
1st Time
Element value has extra content: mu
2nd Time
Relax NG validated





-- 
Edit this bug report at http://bugs.php.net/?id=41041&edit=1

#41042 [Fbk]: PHP has encountered an access violation at 017d765e

[tony2001]

 ID:   41042
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tissuescar at gmail dot com
 Status:   Feedback
 Bug Type: IIS related
 Operating System: XP Professional
 PHP Version:  5.2.1
 New Comment:

Don't forget to remove/disable all zend_extension's.


Previous Comments:


[2007-04-10 16:57:08] [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.





[2007-04-10 16:48:33] tissuescar at gmail dot com

Description:

PHP has encountered an access violation at 017d765e.

I'm trying to call a basic php page to test the installation on my
machine.


Reproduce code:
---


 PHP test page 






Expected result:

date needs to be displayed in the browser

Actual result:
--
PHP has encountered an access violation at 017d765e





-- 
Edit this bug report at http://bugs.php.net/?id=41042&edit=1

#41042 [Opn->Fbk]: PHP has encountered an access violation at 017d765e

[tony2001]

 ID:   41042
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tissuescar at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: IIS related
 Operating System: XP Professional
 PHP Version:  5.2.1
 New Comment:

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.




Previous Comments:


[2007-04-10 16:48:33] tissuescar at gmail dot com

Description:

PHP has encountered an access violation at 017d765e.

I'm trying to call a basic php page to test the installation on my
machine.


Reproduce code:
---


 PHP test page 






Expected result:

date needs to be displayed in the browser

Actual result:
--
PHP has encountered an access violation at 017d765e





-- 
Edit this bug report at http://bugs.php.net/?id=41042&edit=1

#41042 [NEW]: PHP has encountered an access violation at 017d765e

[tissuescar at gmail dot com]

From: tissuescar at gmail dot com
Operating system: XP Professional
PHP version:  5.2.1
PHP Bug Type: IIS related
Bug description:  PHP has encountered an access violation at 017d765e

Description:

PHP has encountered an access violation at 017d765e.

I'm trying to call a basic php page to test the installation on my
machine.


Reproduce code:
---


 PHP test page 






Expected result:

date needs to be displayed in the browser

Actual result:
--
PHP has encountered an access violation at 017d765e

-- 
Edit bug report at http://bugs.php.net/?id=41042&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41042&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41042&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41042&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41042&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41042&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41042&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41042&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41042&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41042&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41042&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41042&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41042&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41042&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41042&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41042&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41042&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41042&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41042&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41042&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41042&r=mysqlcfg

#34158 [Opn->Fbk]: Wrong t.tm_isdst flag value.

[tony2001]

 ID:   34158
 Updated by:   [EMAIL PROTECTED]
 Reported By:  aesthete at telecenter dot ru
-Status:   Open
+Status:   Feedback
 Bug Type: InterBase related
 Operating System: Linux 2.6.12 (Fedora Core 3)
 PHP Version:  4.4.0/5.x.x
 New Comment:

Why do you think it should return non-empty string?
Did you try to run this query using other interfaces to Interbase?


Previous Comments:


[2007-04-10 16:11:51] aesthete at telecenter dot ru

Ok ... some code:

try {
$dbh = new PDO
('firebird:dbname=10.0.0.1:/home/dbase/prihod/zakupka.gdb', 'SYSDBA',
'1');
   foreach ($dbh->query('SELECT NAME FROM CARS ORDER BY NAME') as $row)

   {
  echo $row['NAME'].'';
   }
   $dbh = null;
} catch (PDOException $e) {
   print "Error!: " . $e->getMessage() . "";
   die();
  }
Return right strings.

But when i try 'SELECT GEN_ID(GEN_DOSTAVKA_ID,1) FROM RDB$DATABASE'
with  echo $row['GEN_ID'].'';
nothing return. Probably bug.



[2007-04-09 20:41:40] [EMAIL PROTECTED]

[5 Feb 2006 12:15pm UTC] [EMAIL PROTECTED] 
Did you try PDO_FIREBIRD ?



[2007-04-08 22:23:51] aesthete at telecenter dot ru

-



[2007-04-08 22:21:11] aesthete at telecenter dot ru

Is this bug will be fixed ?



[2006-09-17 09:49:41] mario dot perazzoli at tiscali dot it

I think the bug is related with an other bug into libc: in the version
4 and 5 of fedora core distribution, strftime don't work correctly with
tm_isdst = -1 (undefined). 
My question is: whi ib/fb should return another value ather than 0 for
tm_isdst?
I have been solved the bug whith a comment to the row t.tm_isdst = -1;
regards



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/34158

-- 
Edit this bug report at http://bugs.php.net/?id=34158&edit=1

#34158 [Fbk->Opn]: Wrong t.tm_isdst flag value.

[aesthete at telecenter dot ru]

 ID:   34158
 User updated by:  aesthete at telecenter dot ru
 Reported By:  aesthete at telecenter dot ru
-Status:   Feedback
+Status:   Open
 Bug Type: InterBase related
 Operating System: Linux 2.6.12 (Fedora Core 3)
 PHP Version:  4.4.0/5.x.x
 New Comment:

Ok ... some code:

try {
$dbh = new PDO
('firebird:dbname=10.0.0.1:/home/dbase/prihod/zakupka.gdb', 'SYSDBA',
'1');
   foreach ($dbh->query('SELECT NAME FROM CARS ORDER BY NAME') as $row)

   {
  echo $row['NAME'].'';
   }
   $dbh = null;
} catch (PDOException $e) {
   print "Error!: " . $e->getMessage() . "";
   die();
  }
Return right strings.

But when i try 'SELECT GEN_ID(GEN_DOSTAVKA_ID,1) FROM RDB$DATABASE'
with  echo $row['GEN_ID'].'';
nothing return. Probably bug.


Previous Comments:


[2007-04-09 20:41:40] [EMAIL PROTECTED]

[5 Feb 2006 12:15pm UTC] [EMAIL PROTECTED] 
Did you try PDO_FIREBIRD ?



[2007-04-08 22:23:51] aesthete at telecenter dot ru

-



[2007-04-08 22:21:11] aesthete at telecenter dot ru

Is this bug will be fixed ?



[2006-09-17 09:49:41] mario dot perazzoli at tiscali dot it

I think the bug is related with an other bug into libc: in the version
4 and 5 of fedora core distribution, strftime don't work correctly with
tm_isdst = -1 (undefined). 
My question is: whi ib/fb should return another value ather than 0 for
tm_isdst?
I have been solved the bug whith a comment to the row t.tm_isdst = -1;
regards



[2006-02-13 01:00:03] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



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/34158

-- 
Edit this bug report at http://bugs.php.net/?id=34158&edit=1

#41041 [Asn->Bgs]: Relax NG validation fails with DTD defined entities

[rrichards]

 ID:   41041
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bleathem at gmail dot com
-Status:   Assigned
+Status:   Bogus
 Bug Type: DOM XML related
 Operating System: Max OS/X 10.4.9
 PHP Version:  5.2.1
 Assigned To:  rrichards
 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

you need to substitute the entities LIBXML_NOENT when loading the xml
into the DOM document.


Previous Comments:


[2007-04-10 15:50:45] bleathem at gmail dot com

Description:

I've created a xml file that uses a doctype to define html entities.
I've created an accompanying Relax NG file to validate the file. If the
xml element that contains the entity follows an Relax NG 
block, the validation fails. I have demonstrated this in the
accompanying source code. The variable $xml is validated against two
Relax NG schemas, where the preceding elements are contained in an
 block, and one where the are not. The validation fails in
the  case.

I have tried the validation using an online validator (java based, uses
jing), see:
http://hsivonen.iki.fi/validator/
so it is not the XML or the Relax NG, but rather the validator itself.

I have found other circumstances where the presence entities cause the
validation to fail, I can provided these if they are necessary.

Reproduce code:
---


]>
http://www.triumf.info/common/xml/eec";
  xmlns="http://www.w3.org/1999/xhtml";>

Isotope
sec_isotope
text
μ

EOF;

$rng = <<

http://relaxng.org/ns/structure/1.0";
 xmlns:eec="http://www.triumf.info/common/xml/eec";>
 
  

  
  
  
  
  
  

  


EOF;

$rng2 = <<

http://relaxng.org/ns/structure/1.0";
 xmlns:eec="http://www.triumf.info/common/xml/eec";>
 
  

  
  
  
  

  


EOF;

ini_set( 'track_errors', 1);
ini_set('error_reporting', E_ALL | E_STRICT);

$dom = new DOMDocument();
$dom->loadXML($xml, LIBXML_DTDLOAD|LIBXML_DTDATTR);

echo "1st Time";
if ($dom->relaxNGValidateSource($rng)) echo "Relax NG validated";
else echo $php_errormsg;

echo "2nd Time";
if ($dom->relaxNGValidateSource($rng2)) echo "Relax NG validated";
else echo $php_errormsg;
?> 

Expected result:

1st Time
Relax NG validated
2nd Time
Relax NG validated

Actual result:
--
1st Time
Element value has extra content: mu
2nd Time
Relax NG validated





-- 
Edit this bug report at http://bugs.php.net/?id=41041&edit=1

#41041 [Opn->Asn]: Relax NG validation fails with DTD defined entities

[tony2001]

 ID:   41041
 Updated by:   [EMAIL PROTECTED]
 Reported By:  bleathem at gmail dot com
-Status:   Open
+Status:   Assigned
 Bug Type: DOM XML related
 Operating System: Max OS/X 10.4.9
 PHP Version:  5.2.1
-Assigned To:  
+Assigned To:  rrichards


Previous Comments:


[2007-04-10 15:50:45] bleathem at gmail dot com

Description:

I've created a xml file that uses a doctype to define html entities.
I've created an accompanying Relax NG file to validate the file. If the
xml element that contains the entity follows an Relax NG 
block, the validation fails. I have demonstrated this in the
accompanying source code. The variable $xml is validated against two
Relax NG schemas, where the preceding elements are contained in an
 block, and one where the are not. The validation fails in
the  case.

I have tried the validation using an online validator (java based, uses
jing), see:
http://hsivonen.iki.fi/validator/
so it is not the XML or the Relax NG, but rather the validator itself.

I have found other circumstances where the presence entities cause the
validation to fail, I can provided these if they are necessary.

Reproduce code:
---


]>
http://www.triumf.info/common/xml/eec";
  xmlns="http://www.w3.org/1999/xhtml";>

Isotope
sec_isotope
text
μ

EOF;

$rng = <<

http://relaxng.org/ns/structure/1.0";
 xmlns:eec="http://www.triumf.info/common/xml/eec";>
 
  

  
  
  
  
  
  

  


EOF;

$rng2 = <<

http://relaxng.org/ns/structure/1.0";
 xmlns:eec="http://www.triumf.info/common/xml/eec";>
 
  

  
  
  
  

  


EOF;

ini_set( 'track_errors', 1);
ini_set('error_reporting', E_ALL | E_STRICT);

$dom = new DOMDocument();
$dom->loadXML($xml, LIBXML_DTDLOAD|LIBXML_DTDATTR);

echo "1st Time";
if ($dom->relaxNGValidateSource($rng)) echo "Relax NG validated";
else echo $php_errormsg;

echo "2nd Time";
if ($dom->relaxNGValidateSource($rng2)) echo "Relax NG validated";
else echo $php_errormsg;
?> 

Expected result:

1st Time
Relax NG validated
2nd Time
Relax NG validated

Actual result:
--
1st Time
Element value has extra content: mu
2nd Time
Relax NG validated





-- 
Edit this bug report at http://bugs.php.net/?id=41041&edit=1

#40961 [Opn->Fbk]: problem with preg_replace and preg_match functions

[tony2001]

 ID:   40961
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jfgingras at cegep-ste-foy dot qc dot ca
-Status:   Open
+Status:   Feedback
 Bug Type: PCRE related
 Operating System: FreeBSD 6.1-RELEASE
 PHP Version:  5.2.1
 New Comment:

Using the latest snapshot and the code below I get "?" as the result.

Tested on Linux and FreeBSD.


Previous Comments:


[2007-04-10 14:58:21] jfgingras at cegep-ste-foy dot qc dot ca

Here's what I have about PCRE with phpinfo() :

pcre
PCRE (Perl Compatible Regular Expressions) Support  enabled
PCRE Library Version7.0 18-Dec-2006

Strangly, it's not the first time I have problem with PHP since I
upgrade from 5.1.6 to 5.2.1. See bug #40641.



[2007-04-10 14:21:58] [EMAIL PROTECTED]

also check if you are using the bundled pcre library or the system's
library. (you can see this in the phpinfo() page).



[2007-04-10 14:20:08] [EMAIL PROTECTED]

Cannot reproduce both on Linux and FreeBSD.




[2007-04-03 14:16:38] jfgingras at cegep-ste-foy dot qc dot ca

You're probably right. But still, if I use the following pattern
"/([^\x09\x0A\x0D\x20-\x7E\xA0-\xFF])/", preg_replace always return
NULL. But if I use "[^\x09\x0A\x0D\x20-\x7E\xA0-\xFF]" it "works", that
is, it will not return NULL.

If I use '/^[a-f\d]{32}$/i' on "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
preg_match always return false.

The exemples above occur on FreeBSD 6.1 with PHP 5.2.1.
I test thoses on Linux 2.6.9 with PHP 5.1.6 and it work.

Any idea ?



[2007-04-02 21:27:49] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Your regex is wrong, you cannot include the "$" (end of string) inside
a 
capturing sub-pattern.



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/40961

-- 
Edit this bug report at http://bugs.php.net/?id=40961&edit=1

#41041 [NEW]: Relax NG validation fails with DTD defined entities

[bleathem at gmail dot com]

From: bleathem at gmail dot com
Operating system: Max OS/X 10.4.9
PHP version:  5.2.1
PHP Bug Type: DOM XML related
Bug description:  Relax NG validation fails with DTD defined entities

Description:

I've created a xml file that uses a doctype to define html entities. I've
created an accompanying Relax NG file to validate the file. If the xml
element that contains the entity follows an Relax NG  block,
the validation fails. I have demonstrated this in the accompanying source
code. The variable $xml is validated against two Relax NG schemas, where
the preceding elements are contained in an  block, and one
where the are not. The validation fails in the  case.

I have tried the validation using an online validator (java based, uses
jing), see:
http://hsivonen.iki.fi/validator/
so it is not the XML or the Relax NG, but rather the validator itself.

I have found other circumstances where the presence entities cause the
validation to fail, I can provided these if they are necessary.

Reproduce code:
---


]>
http://www.triumf.info/common/xml/eec";
  xmlns="http://www.w3.org/1999/xhtml";>

Isotope
sec_isotope
text
μ

EOF;

$rng = <<

http://relaxng.org/ns/structure/1.0";
 xmlns:eec="http://www.triumf.info/common/xml/eec";>
 
  

  
  
  
  
  
  

  


EOF;

$rng2 = <<

http://relaxng.org/ns/structure/1.0";
 xmlns:eec="http://www.triumf.info/common/xml/eec";>
 
  

  
  
  
  

  


EOF;

ini_set( 'track_errors', 1);
ini_set('error_reporting', E_ALL | E_STRICT);

$dom = new DOMDocument();
$dom->loadXML($xml, LIBXML_DTDLOAD|LIBXML_DTDATTR);

echo "1st Time";
if ($dom->relaxNGValidateSource($rng)) echo "Relax NG validated";
else echo $php_errormsg;

echo "2nd Time";
if ($dom->relaxNGValidateSource($rng2)) echo "Relax NG validated";
else echo $php_errormsg;
?> 

Expected result:

1st Time
Relax NG validated
2nd Time
Relax NG validated

Actual result:
--
1st Time
Element value has extra content: mu
2nd Time
Relax NG validated

-- 
Edit bug report at http://bugs.php.net/?id=41041&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41041&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41041&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41041&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41041&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41041&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41041&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41041&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41041&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41041&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41041&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41041&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41041&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41041&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41041&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41041&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41041&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41041&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41041&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41041&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41041&r=mysqlcfg

#41039 [Opn->Bgs]: SQL join with bound parameter fails with 'text, ntext, image' error.

[tony2001]

 ID:   41039
 Updated by:   [EMAIL PROTECTED]
 Reported By:  emil at troxy dot net
-Status:   Open
+Status:   Bogus
 Bug Type: PDO related
 Operating System: Windows Server 2003
 PHP Version:  5.2.1
 New Comment:

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.




Previous Comments:


[2007-04-10 15:08:14] emil at troxy dot net

Description:

I'm trying to do a simple SQL join using a prepared statement with a
bound parameter as a part of the condition.
The execution of the statement fails with an exception saying that I'm
trying to do a compare on text, ntext or image data types, even though
the tables don't contain these types.

Reproduce code:
---
CREATE TABLE [table1] (
[id] [int] NOT NULL 
) ON [PRIMARY]

CREATE TABLE [table2] (
[id] [int] NOT NULL 
) ON [PRIMARY]

INSERT INTO [table1] VALUES(1)
INSERT INTO [table2] VALUES(1)

setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$stmt = $dbh->prepare("SELECT t1.id, t2.id FROM table1 t1 INNER JOIN
table2 t2 ON (t1.id = ?) AND (t2.id = 1)");
$stmt->bindValue(1, 1, PDO::PARAM_INT);
$stmt->execute();
?>

Expected result:

The statement should execute without errors and return TRUE.

Actual result:
--
PHP Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[42000]: Syntax error or access violation: 306 [Microsoft][ODBC
SQL Server Driver][SQL Server]The text, ntext, and image data types
cannot be compared or sorted, except when using IS NULL or LIKE
operator. (SQLExecute[306] at ext\pdo_odbc\odbc_stmt.c:133)' in
D:\Website\pdo.php:8 Stack trace: #0 D:\Website\pdo.php(8):
PDOStatement->execute() #1 {main} thrown in D:\Website\pdo.php on line 8





-- 
Edit this bug report at http://bugs.php.net/?id=41039&edit=1

#41039 [NEW]: SQL join with bound parameter fails with 'text, ntext, image' error.

[emil at troxy dot net]

From: emil at troxy dot net
Operating system: Windows Server 2003
PHP version:  5.2.1
PHP Bug Type: PDO related
Bug description:  SQL join with bound parameter fails with 'text, ntext, image' 
error.

Description:

I'm trying to do a simple SQL join using a prepared statement with a bound
parameter as a part of the condition.
The execution of the statement fails with an exception saying that I'm
trying to do a compare on text, ntext or image data types, even though the
tables don't contain these types.

Reproduce code:
---
CREATE TABLE [table1] (
[id] [int] NOT NULL 
) ON [PRIMARY]

CREATE TABLE [table2] (
[id] [int] NOT NULL 
) ON [PRIMARY]

INSERT INTO [table1] VALUES(1)
INSERT INTO [table2] VALUES(1)

setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$stmt = $dbh->prepare("SELECT t1.id, t2.id FROM table1 t1 INNER JOIN
table2 t2 ON (t1.id = ?) AND (t2.id = 1)");
$stmt->bindValue(1, 1, PDO::PARAM_INT);
$stmt->execute();
?>

Expected result:

The statement should execute without errors and return TRUE.

Actual result:
--
PHP Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[42000]: Syntax error or access violation: 306 [Microsoft][ODBC
SQL Server Driver][SQL Server]The text, ntext, and image data types cannot
be compared or sorted, except when using IS NULL or LIKE operator.
(SQLExecute[306] at ext\pdo_odbc\odbc_stmt.c:133)' in D:\Website\pdo.php:8
Stack trace: #0 D:\Website\pdo.php(8): PDOStatement->execute() #1 {main}
thrown in D:\Website\pdo.php on line 8

-- 
Edit bug report at http://bugs.php.net/?id=41039&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41039&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41039&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41039&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41039&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41039&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41039&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41039&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41039&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41039&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41039&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41039&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41039&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41039&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41039&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41039&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41039&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41039&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41039&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41039&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41039&r=mysqlcfg

#40961 [Fbk->Opn]: problem with preg_replace and preg_match functions

[jfgingras at cegep-ste-foy dot qc dot ca]

 ID:   40961
 User updated by:  jfgingras at cegep-ste-foy dot qc dot ca
 Reported By:  jfgingras at cegep-ste-foy dot qc dot ca
-Status:   Feedback
+Status:   Open
 Bug Type: PCRE related
 Operating System: FreeBSD 6.1-RELEASE
 PHP Version:  5.2.1
 New Comment:

Here's what I have about PCRE with phpinfo() :

pcre
PCRE (Perl Compatible Regular Expressions) Support  enabled
PCRE Library Version7.0 18-Dec-2006

Strangly, it's not the first time I have problem with PHP since I
upgrade from 5.1.6 to 5.2.1. See bug #40641.


Previous Comments:


[2007-04-10 14:21:58] [EMAIL PROTECTED]

also check if you are using the bundled pcre library or the system's
library. (you can see this in the phpinfo() page).



[2007-04-10 14:20:08] [EMAIL PROTECTED]

Cannot reproduce both on Linux and FreeBSD.




[2007-04-03 14:16:38] jfgingras at cegep-ste-foy dot qc dot ca

You're probably right. But still, if I use the following pattern
"/([^\x09\x0A\x0D\x20-\x7E\xA0-\xFF])/", preg_replace always return
NULL. But if I use "[^\x09\x0A\x0D\x20-\x7E\xA0-\xFF]" it "works", that
is, it will not return NULL.

If I use '/^[a-f\d]{32}$/i' on "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
preg_match always return false.

The exemples above occur on FreeBSD 6.1 with PHP 5.2.1.
I test thoses on Linux 2.6.9 with PHP 5.1.6 and it work.

Any idea ?



[2007-04-02 21:27:49] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Your regex is wrong, you cannot include the "$" (end of string) inside
a 
capturing sub-pattern.



[2007-04-02 15:53:05] jfgingras at cegep-ste-foy dot qc dot ca

Forget to mention that no php error are logged in the log file. I even
set 666 mode on phperror.log just to be sure that php can write in it.
But still no error shown.

Strangly, like I said preg_replace works if I remove the '/(' and ')/'
from the pattern, but preg_match always return false. But, it print an
error:

[02-Apr-2007 11:51:29] PHP Warning:  preg_match() [function.preg-match]: No ending delimiter
'^' found in /usr/local/www/f.php on line 6

And here's the line 6:

if(preg_match('^[a-f0-9]{32}$', $body)) echo "YEAH #2!";



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40961

-- 
Edit this bug report at http://bugs.php.net/?id=40961&edit=1

#40961 [Fbk]: problem with preg_replace and preg_match functions

[nlopess]

 ID:   40961
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jfgingras at cegep-ste-foy dot qc dot ca
 Status:   Feedback
 Bug Type: PCRE related
 Operating System: FreeBSD 6.1-RELEASE
 PHP Version:  5.2.1
 New Comment:

also check if you are using the bundled pcre library or the system's
library. (you can see this in the phpinfo() page).


Previous Comments:


[2007-04-10 14:20:08] [EMAIL PROTECTED]

Cannot reproduce both on Linux and FreeBSD.




[2007-04-03 14:16:38] jfgingras at cegep-ste-foy dot qc dot ca

You're probably right. But still, if I use the following pattern
"/([^\x09\x0A\x0D\x20-\x7E\xA0-\xFF])/", preg_replace always return
NULL. But if I use "[^\x09\x0A\x0D\x20-\x7E\xA0-\xFF]" it "works", that
is, it will not return NULL.

If I use '/^[a-f\d]{32}$/i' on "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
preg_match always return false.

The exemples above occur on FreeBSD 6.1 with PHP 5.2.1.
I test thoses on Linux 2.6.9 with PHP 5.1.6 and it work.

Any idea ?



[2007-04-02 21:27:49] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Your regex is wrong, you cannot include the "$" (end of string) inside
a 
capturing sub-pattern.



[2007-04-02 15:53:05] jfgingras at cegep-ste-foy dot qc dot ca

Forget to mention that no php error are logged in the log file. I even
set 666 mode on phperror.log just to be sure that php can write in it.
But still no error shown.

Strangly, like I said preg_replace works if I remove the '/(' and ')/'
from the pattern, but preg_match always return false. But, it print an
error:

[02-Apr-2007 11:51:29] PHP Warning:  preg_match() [function.preg-match]: No ending delimiter
'^' found in /usr/local/www/f.php on line 6

And here's the line 6:

if(preg_match('^[a-f0-9]{32}$', $body)) echo "YEAH #2!";



[2007-04-02 15:45:18] jfgingras at cegep-ste-foy dot qc dot ca

$body = "b2c3d4e5f6a7b8c9e0f1a2b3c4d5e6f7";
$body = preg_replace('/(^[a-f0-9]{32}$)/', '?', $body );
var_dump($body);

It is not even returning a empty string, it return NULL!

Here's what I have in my php.ini

error_reporting  =  E_ALL
log_errors = On
error_log = /var/log/phperror.log

Here's my php info

[EMAIL PROTECTED] ~]# php -v
PHP 5.2.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Mar 30 2007
10:03:24)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

Any help is more than welcome.

Thx!



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/40961

-- 
Edit this bug report at http://bugs.php.net/?id=40961&edit=1

#40961 [Opn->Fbk]: problem with preg_replace and preg_match functions

[tony2001]

 ID:   40961
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jfgingras at cegep-ste-foy dot qc dot ca
-Status:   Open
+Status:   Feedback
 Bug Type: PCRE related
 Operating System: FreeBSD 6.1-RELEASE
 PHP Version:  5.2.1
 New Comment:

Cannot reproduce both on Linux and FreeBSD.



Previous Comments:


[2007-04-03 14:16:38] jfgingras at cegep-ste-foy dot qc dot ca

You're probably right. But still, if I use the following pattern
"/([^\x09\x0A\x0D\x20-\x7E\xA0-\xFF])/", preg_replace always return
NULL. But if I use "[^\x09\x0A\x0D\x20-\x7E\xA0-\xFF]" it "works", that
is, it will not return NULL.

If I use '/^[a-f\d]{32}$/i' on "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
preg_match always return false.

The exemples above occur on FreeBSD 6.1 with PHP 5.2.1.
I test thoses on Linux 2.6.9 with PHP 5.1.6 and it work.

Any idea ?



[2007-04-02 21:27:49] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Your regex is wrong, you cannot include the "$" (end of string) inside
a 
capturing sub-pattern.



[2007-04-02 15:53:05] jfgingras at cegep-ste-foy dot qc dot ca

Forget to mention that no php error are logged in the log file. I even
set 666 mode on phperror.log just to be sure that php can write in it.
But still no error shown.

Strangly, like I said preg_replace works if I remove the '/(' and ')/'
from the pattern, but preg_match always return false. But, it print an
error:

[02-Apr-2007 11:51:29] PHP Warning:  preg_match() [function.preg-match]: No ending delimiter
'^' found in /usr/local/www/f.php on line 6

And here's the line 6:

if(preg_match('^[a-f0-9]{32}$', $body)) echo "YEAH #2!";



[2007-04-02 15:45:18] jfgingras at cegep-ste-foy dot qc dot ca

$body = "b2c3d4e5f6a7b8c9e0f1a2b3c4d5e6f7";
$body = preg_replace('/(^[a-f0-9]{32}$)/', '?', $body );
var_dump($body);

It is not even returning a empty string, it return NULL!

Here's what I have in my php.ini

error_reporting  =  E_ALL
log_errors = On
error_log = /var/log/phperror.log

Here's my php info

[EMAIL PROTECTED] ~]# php -v
PHP 5.2.1 with Suhosin-Patch 0.9.6.2 (cli) (built: Mar 30 2007
10:03:24)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies

Any help is more than welcome.

Thx!



[2007-03-30 22:33:13] tijnema at gmail dot com

$body = "b2c3d4e5f6a7b8c9e0f1a2b3c4d5e6f7";
$body = preg_replace('/(^[a-f0-9]{32}$)/', '?', $body );
var_dump($body);

Above code gives me string(1) "?" on PHP-5.1.6/5.2.1/6.0-dev on linux
using CLI or Apache.



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/40961

-- 
Edit this bug report at http://bugs.php.net/?id=40961&edit=1

#41035 [Fbk->Bgs]: "log_errors_max_len" has no effect for values over 1024 or 0

[tony2001]

 ID:   41035
 Updated by:   [EMAIL PROTECTED]
 Reported By:  sv_forums at fmethod dot com
-Status:   Feedback
+Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: Windows XP
 PHP Version:  5.2.1
 New Comment:

Do not file bugs when you have Zend extensions (zend_extension=)
loaded. Examples are Zend Optimizer, Zend Debugger, Turck MM Cache,
APC, Xdebug and ionCube loader.  These extensions often modify engine
behavior which is not related to PHP itself.




Previous Comments:


[2007-04-10 13:45:48] [EMAIL PROTECTED]

0 is a special values which means "no limit".
Other values, including the ones greater than 1024 work perfectly fine.



[2007-04-10 13:30:46] sv_forums at fmethod dot com

Description:

The "log_errors_max_len" config option should allow us to disable the
cap limit if we set it to 0. This has no effect and the actual limit
remains 1024. Same about entering values over 1024.

Reproduce code:
---
1. Use the following sample code:



2. Check the log.

Expected result:

Since in the example above I've set log_errors_max_len to 0, the log
stack traces should not be clipped at the 1024 boundary, but it is.

Actual result:
--
The error report log gets clipped at 1024 bytes.



[2007-04-10 13:17:52] webmaster at wiedmann-online dot de

'log_errors_max_len' is not the filesize of the logfile. It's the
maximum lenght of an error message, printed in each log entry.

Reproduce code:
---


Actual result:
--
[10-Apr-2007 15:13:58] PHP Warning:  - in C:\php-5.2.1\testlog.php on
line 13
[10-Apr-2007 15:13:58] PHP Warning:  -- in C:\php-5.2.1\testlog.php on
line 13
[10-Apr-2007 15:13:58] PHP Warning:  --- in C:\php-5.2.1\testlog.php on
line 13
[10-Apr-2007 15:13:58] PHP Warning:   in C:\php-5.2.1\testlog.php
on line 13
[10-Apr-2007 15:13:58] PHP Warning:  - in C:\php-5.2.1\testlog.php
on line 13



[2007-04-10 07:55:44] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.





[2007-04-10 05:11:40] sv_forums at fmethod dot com

Description:

The "log_errors_max_len" config option should allow us to disable the
cap limit if we set it to 0. This has no effect and the actual limit
remains 1024. Same about entering values over 1024.

Reproduce code:
---
1. Use the following error reporting settings:

error_reporting(E_ALL|E_STRICT);
ini_set('display_errors',0);
ini_set('log_errors',1);
ini_set('log_errors_max_len','0'); // alternatively use values larger
than 1024, they also don't work
ini_set('html_errors',0);

2. Produce a code with enough nested calls so when you throw an
exception, together with the full stack trace, it'll be over 1024 bytes

3. Throw exception inside the chain.

4. Check the log.

Expected result:

Since in the example above I've set log_errors_max_len to 0, the log
stack traces should not be clipped at the 1024 boundary, but it is.

Actual result:
--
The error report log gets clipped at 1024 bytes.





-- 
Edit this bug report at http://bugs.php.net/?id=41035&edit=1

#41010 [Opn->Fbk]: Bug #33480 still in php 4.4.6

[tony2001]

 ID:   41010
 Updated by:   [EMAIL PROTECTED]
 Reported By:  hack988 at gmail dot com
-Status:   Open
+Status:   Feedback
 Bug Type: dBase related
 Operating System: win32
 PHP Version:  4.4.6
 New Comment:

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.





Previous Comments:


[2007-04-06 12:58:43] hack988 at gmail dot com

Description:

Bug #33480 still in php 4.4.6
The dbase_add cannot
use associative matrix.







-- 
Edit this bug report at http://bugs.php.net/?id=41010&edit=1

#41027 [Opn->Asn]: Executing prepared statement changes type of bound parameters to string

[tony2001]

 ID:   41027
 Updated by:   [EMAIL PROTECTED]
 Reported By:  martin at bangaroo dot net
-Status:   Open
+Status:   Assigned
 Bug Type: PDO related
 Operating System: Gentoo Linux
 PHP Version:  5.2.1
-Assigned To:  
+Assigned To:  wez


Previous Comments:


[2007-04-09 14:31:34] martin at bangaroo dot net

Description:

Executing a prepared statement changes the type of bound parameters 
to string (Tested only with pgsql driver).

This bite me when I wanted to execute an insert statement only when 
the double value to be inserted actually changed, NULL being a 
possible value. Unfortunatly, comparing the new value with the old 
value with the !== operator didn't work, because the type-change 
made the test always evaluate to TRUE.


Reproduce code:
---
query("CREATE TABLE test_table ( val REAL )");
  $qry = $db->prepare("INSERT INTO test_table VALUES (:val)");
  $qry->bindParam(":val",$bound_val);

  $bound_val = 5.2;
  echo "Type before execute(): ".gettype($bound_val)."\n";
  $qry->execute();
  echo "Type after execute(): ".gettype($bound_val)."\n";

  $db->query("DROP TABLE test");
?>

Expected result:

Type before execute(): double
Type after execute(): double


Actual result:
--
Type before execute(): double
Type after execute(): string






-- 
Edit this bug report at http://bugs.php.net/?id=41027&edit=1

#41035 [Opn->Fbk]: "log_errors_max_len" has no effect for values over 1024 or 0

[tony2001]

 ID:   41035
 Updated by:   [EMAIL PROTECTED]
 Reported By:  sv_forums at fmethod dot com
-Status:   Open
+Status:   Feedback
-Bug Type: Feature/Change Request
+Bug Type: Unknown/Other Function
 Operating System: Windows XP
 PHP Version:  5.2.1
 New Comment:

0 is a special values which means "no limit".
Other values, including the ones greater than 1024 work perfectly fine.


Previous Comments:


[2007-04-10 13:30:46] sv_forums at fmethod dot com

Description:

The "log_errors_max_len" config option should allow us to disable the
cap limit if we set it to 0. This has no effect and the actual limit
remains 1024. Same about entering values over 1024.

Reproduce code:
---
1. Use the following sample code:



2. Check the log.

Expected result:

Since in the example above I've set log_errors_max_len to 0, the log
stack traces should not be clipped at the 1024 boundary, but it is.

Actual result:
--
The error report log gets clipped at 1024 bytes.



[2007-04-10 13:17:52] webmaster at wiedmann-online dot de

'log_errors_max_len' is not the filesize of the logfile. It's the
maximum lenght of an error message, printed in each log entry.

Reproduce code:
---


Actual result:
--
[10-Apr-2007 15:13:58] PHP Warning:  - in C:\php-5.2.1\testlog.php on
line 13
[10-Apr-2007 15:13:58] PHP Warning:  -- in C:\php-5.2.1\testlog.php on
line 13
[10-Apr-2007 15:13:58] PHP Warning:  --- in C:\php-5.2.1\testlog.php on
line 13
[10-Apr-2007 15:13:58] PHP Warning:   in C:\php-5.2.1\testlog.php
on line 13
[10-Apr-2007 15:13:58] PHP Warning:  - in C:\php-5.2.1\testlog.php
on line 13



[2007-04-10 07:55:44] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.





[2007-04-10 05:11:40] sv_forums at fmethod dot com

Description:

The "log_errors_max_len" config option should allow us to disable the
cap limit if we set it to 0. This has no effect and the actual limit
remains 1024. Same about entering values over 1024.

Reproduce code:
---
1. Use the following error reporting settings:

error_reporting(E_ALL|E_STRICT);
ini_set('display_errors',0);
ini_set('log_errors',1);
ini_set('log_errors_max_len','0'); // alternatively use values larger
than 1024, they also don't work
ini_set('html_errors',0);

2. Produce a code with enough nested calls so when you throw an
exception, together with the full stack trace, it'll be over 1024 bytes

3. Throw exception inside the chain.

4. Check the log.

Expected result:

Since in the example above I've set log_errors_max_len to 0, the log
stack traces should not be clipped at the 1024 boundary, but it is.

Actual result:
--
The error report log gets clipped at 1024 bytes.





-- 
Edit this bug report at http://bugs.php.net/?id=41035&edit=1

#41035 [Fbk->Opn]: "log_errors_max_len" has no effect for values over 1024 or 0

[sv_forums at fmethod dot com]

 ID:   41035
 User updated by:  sv_forums at fmethod dot com
 Reported By:  sv_forums at fmethod dot com
-Status:   Feedback
+Status:   Open
 Bug Type: PHP options/info functions
 Operating System: Windows XP
 PHP Version:  5.2.1
 New Comment:

Description:

The "log_errors_max_len" config option should allow us to disable the
cap limit if we set it to 0. This has no effect and the actual limit
remains 1024. Same about entering values over 1024.

Reproduce code:
---
1. Use the following sample code:



2. Check the log.

Expected result:

Since in the example above I've set log_errors_max_len to 0, the log
stack traces should not be clipped at the 1024 boundary, but it is.

Actual result:
--
The error report log gets clipped at 1024 bytes.


Previous Comments:


[2007-04-10 13:17:52] webmaster at wiedmann-online dot de

'log_errors_max_len' is not the filesize of the logfile. It's the
maximum lenght of an error message, printed in each log entry.

Reproduce code:
---


Actual result:
--
[10-Apr-2007 15:13:58] PHP Warning:  - in C:\php-5.2.1\testlog.php on
line 13
[10-Apr-2007 15:13:58] PHP Warning:  -- in C:\php-5.2.1\testlog.php on
line 13
[10-Apr-2007 15:13:58] PHP Warning:  --- in C:\php-5.2.1\testlog.php on
line 13
[10-Apr-2007 15:13:58] PHP Warning:   in C:\php-5.2.1\testlog.php
on line 13
[10-Apr-2007 15:13:58] PHP Warning:  - in C:\php-5.2.1\testlog.php
on line 13



[2007-04-10 07:55:44] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.





[2007-04-10 05:11:40] sv_forums at fmethod dot com

Description:

The "log_errors_max_len" config option should allow us to disable the
cap limit if we set it to 0. This has no effect and the actual limit
remains 1024. Same about entering values over 1024.

Reproduce code:
---
1. Use the following error reporting settings:

error_reporting(E_ALL|E_STRICT);
ini_set('display_errors',0);
ini_set('log_errors',1);
ini_set('log_errors_max_len','0'); // alternatively use values larger
than 1024, they also don't work
ini_set('html_errors',0);

2. Produce a code with enough nested calls so when you throw an
exception, together with the full stack trace, it'll be over 1024 bytes

3. Throw exception inside the chain.

4. Check the log.

Expected result:

Since in the example above I've set log_errors_max_len to 0, the log
stack traces should not be clipped at the 1024 boundary, but it is.

Actual result:
--
The error report log gets clipped at 1024 bytes.





-- 
Edit this bug report at http://bugs.php.net/?id=41035&edit=1

#41038 [Opn->WFx]: Problem with PHP parser in handling MIN_INT value.

[tony2001]

 ID:   41038
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mahesh dot vemula at in dot ibm dot com
-Status:   Open
+Status:   Wont fix
 Bug Type: *Compile Issues
 Operating System: RHEL 4
 PHP Version:  5CVS-2007-04-10 (snap)
 New Comment:

String "-2147483648" contains two tokens: "-" and "2147483648".
Since strtol() returns ERANGE when parsing "2147483648", the result
number is double.
>From what I can see, changing this fact would require major changes to
the parser which hopefully nobody is going to do.
Marking as "Won't fix".


Previous Comments:


[2007-04-10 12:58:00] mahesh dot vemula at in dot ibm dot com

Description:

The least integer value (i.e -2147483648 ) is  being treated as
float(-2147483648) by the parser. var_dump(-2147483648) returns
float(-2147483648).  A integer value should be treated as float, only if
the value is beyond the boundary of the integer type. 
The php documentation explains the same here :
http://in.php.net/manual/en/function.intval.php  & 
http://in.php.net/manual/en/language.types.integer.php

Remarks:
The Reproduce code confirms that the parser is not handling the Minimum
Integer value (i.e, -2147483648) as expected. 

Environment:
Operating System: RHEL 4
Linux Kernel : Linux 2.6.9
PHP Version: PHP 5.2 (Built on Apr 10, 2007 from snaps.php.net)
PHP Configure Setup: ./configure


Reproduce code:
---


Expected result:

int(-2147483648)
int(-2147483648)

Actual result:
--
float(-2147483648)
int(-2147483648)





-- 
Edit this bug report at http://bugs.php.net/?id=41038&edit=1

#41035 [Com]: "log_errors_max_len" has no effect for values over 1024 or 0

[webmaster at wiedmann-online dot de]

 ID:   41035
 Comment by:   webmaster at wiedmann-online dot de
 Reported By:  sv_forums at fmethod dot com
 Status:   Feedback
 Bug Type: PHP options/info functions
 Operating System: Windows XP
 PHP Version:  5.2.1
 New Comment:

'log_errors_max_len' is not the filesize of the logfile. It's the
maximum lenght of an error message, printed in each log entry.

Reproduce code:
---


Actual result:
--
[10-Apr-2007 15:13:58] PHP Warning:  - in C:\php-5.2.1\testlog.php on
line 13
[10-Apr-2007 15:13:58] PHP Warning:  -- in C:\php-5.2.1\testlog.php on
line 13
[10-Apr-2007 15:13:58] PHP Warning:  --- in C:\php-5.2.1\testlog.php on
line 13
[10-Apr-2007 15:13:58] PHP Warning:   in C:\php-5.2.1\testlog.php
on line 13
[10-Apr-2007 15:13:58] PHP Warning:  - in C:\php-5.2.1\testlog.php
on line 13


Previous Comments:


[2007-04-10 07:55:44] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.





[2007-04-10 05:11:40] sv_forums at fmethod dot com

Description:

The "log_errors_max_len" config option should allow us to disable the
cap limit if we set it to 0. This has no effect and the actual limit
remains 1024. Same about entering values over 1024.

Reproduce code:
---
1. Use the following error reporting settings:

error_reporting(E_ALL|E_STRICT);
ini_set('display_errors',0);
ini_set('log_errors',1);
ini_set('log_errors_max_len','0'); // alternatively use values larger
than 1024, they also don't work
ini_set('html_errors',0);

2. Produce a code with enough nested calls so when you throw an
exception, together with the full stack trace, it'll be over 1024 bytes

3. Throw exception inside the chain.

4. Check the log.

Expected result:

Since in the example above I've set log_errors_max_len to 0, the log
stack traces should not be clipped at the 1024 boundary, but it is.

Actual result:
--
The error report log gets clipped at 1024 bytes.





-- 
Edit this bug report at http://bugs.php.net/?id=41035&edit=1

#41038 [NEW]: Problem with PHP parser in handling MIN_INT value.

[mahesh dot vemula at in dot ibm dot com]

From: mahesh dot vemula at in dot ibm dot com
Operating system: RHEL 4
PHP version:  5CVS-2007-04-10 (snap)
PHP Bug Type: *Compile Issues
Bug description:  Problem with PHP parser in handling MIN_INT value.

Description:

The least integer value (i.e -2147483648 ) is  being treated as
float(-2147483648) by the parser. var_dump(-2147483648) returns
float(-2147483648).  A integer value should be treated as float, only if
the value is beyond the boundary of the integer type. 
The php documentation explains the same here :
http://in.php.net/manual/en/function.intval.php  & 
http://in.php.net/manual/en/language.types.integer.php

Remarks:
The Reproduce code confirms that the parser is not handling the Minimum
Integer value (i.e, -2147483648) as expected. 

Environment:
Operating System: RHEL 4
Linux Kernel : Linux 2.6.9
PHP Version: PHP 5.2 (Built on Apr 10, 2007 from snaps.php.net)
PHP Configure Setup: ./configure


Reproduce code:
---


Expected result:

int(-2147483648)
int(-2147483648)

Actual result:
--
float(-2147483648)
int(-2147483648)

-- 
Edit bug report at http://bugs.php.net/?id=41038&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41038&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41038&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41038&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41038&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41038&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41038&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41038&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41038&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41038&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41038&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41038&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41038&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41038&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41038&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41038&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41038&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41038&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41038&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41038&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41038&r=mysqlcfg

#13116 [Com]: setcookie would not work when expire is set

[senglathsamy at laodev dot com]

 ID:   13116
 Comment by:   senglathsamy at laodev dot com
 Reported By:  gotenforward at yahoo dot com
 Status:   No Feedback
 Bug Type: HTTP related
 Operating System: FreeBSD 4.3
 PHP Version:  4.0.6
 New Comment:

I also have problem as  above posted.
my script can not work on FC6 server but it's work well on Win Server

1 test:

setcookie("use","value"); // I can call cookie based on both win and
linux server

2 test:

setcookie("use","value",time()+3600); // I can call cookie based on win
only, But can't call cookie linux server

so, help me to fix this bug, Plz!


Previous Comments:


[2002-03-08 00:00:04] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".



[2002-02-07 23:05:03] [EMAIL PROTECTED]

Your code works for me, but I don't have a FreeBSD box to test on nor
an Internet Explorer browser.

However, let's not assume yet that this is a FreeBSD problem, since
that really seems unlikely with such a basic thing. The much more
probable case is that it is an IE bug, as IE has historically had
problems with adhering to HTTP standards specifically with cookies.

If your problem (as you say) is like the other bug you link to, then it
sounds like the problem lies in the browser not returning the cookie
rather than the cookie not being set.

To help investigate this, please check as many of the following things
as you know how:

1) HTTP response your PHP page generates
2) subsequent HTTP request from the browser (meaning, a request after
the cookie has been set)
3) Time (in GMT) on the browser
4) Time (in GMT) on the server
5) URL being used to access the page
6) Domain being used to set the cookie

If the problem doesn't reveal itself after inspecting these things, use
the header function as you did but with all hardcoded values to make
sure you're setting the cookie you think you are and that the date is
sufficiently far in the future to rule out any time synchronization
problems.

Thanks for your help!

Chris



[2001-09-03 16:47:38] gotenforward at yahoo dot com

Another user experience the same problem like mine

http://www.php.net/bugs.php?id=11492&edit=1

It looks like they are all using FreeBSD



[2001-09-03 16:33:11] gotenforward at yahoo dot com

I pretty much get the same error as this link

http://www.php.net/bugs.php?id=11478&edit=1

Over a couple hundreds of users, all of them works fine with IE 5.0+ 
However, some of the user can not login due to the cookie is not set.

Whenever I do

setcookie("username",$user,time()+3600,"/",".domain.com");

Some of the users using IE would not get the cookie.

But when i just change it to 

setcookie("username",$user,"","/",".domain.com");

It works.  But not setting expire time will not write the cookie to
harddisk, it just stored into memory, which is not what I want.

So, I tried to use the header function and see if that helps.

$time = mktime()+ $config[cookieTTL]; 
$date = gmdate("l, d-M-Y H:i:s", ($time)); 
header("Set-Cookie: $cookiename=$tmpstring; expires=$date GMT;
path=/;");

IE still do not pick up the cookie.


Here is a little function I use to store cookie

function putCookie($config,$cookiename, $varname, $data, $send="") { 

// function to store cookie, use serialize() to bypass the limit of
using 20 cookies per domain. 
// And make it easier to add new cookie later.

//keep this array always static so that when we get out of this
function, it still keep the variable.
static $tmpArray; 

$tmpArray[$varname] = $data;

if ($send != "") {
$tmpstring = serialize($tmpArray); 
$tmpstring = base64_encode($tmpstring);

$time = mktime()+ $config[cookieTTL]; 
$date = gmdate("l, d-M-Y H:i:s", ($time)); 

setCookie($cookiename, $tmpstring, "", $config[cookie_path],
$config[CookieURL]); // now we clean the static array after we send the
cookie  

unset($tmpstring); 
$tmpArray = "";
unset($tmpArray);
}
}   

 




-- 
Edit this bug report at http://bugs.php.net/?id=13116&edit=1

#3034 [Com]: SetCookie bug

[senglathsamy at laodev dot com]

 ID:   3034
 Comment by:   senglathsamy at laodev dot com
 Reported By:  mog at linux dot nu
 Status:   Wont Fix
 Bug Type: Reproducible Crash
 Operating System: win32 cgi
 PHP Version:  3.0.11 / 4b3
 New Comment:

I have problem with using setcookie with linux webserver.
my first test:
setcookie("use","text");

// by this code it's working well with both Windows and Linux (FC6)
pathform;

The second test:

setcookie("use","text",time()+3600);

// by this code it's working well with Windows pathform. 
// But it's have some problem with Linux (FC6)pathform, when I call
thge cookie by $_COOKIE["use"] is warmming as "Notice: Undefined index:
User in /var/www/html/test.php on line 2"

help me plz!


Previous Comments:


[2005-03-30 09:02:24] [EMAIL PROTECTED]

We are sorry, but we can not support PHP 3 related problems anymore.
Momentum is gathering for PHP 5, and we think supporting PHP 3 will
lead to a waste of resources which we want to put into getting PHP 5
ready. Of course PHP 4 will continue to be supported for the
forseeable future.





[1999-12-24 15:20:45] mog at linux dot nu

That's strange, i'm quite sure that it crashed with the code i sent.

However, it didn't now, and, this code with 71 "%" char's (problably
crashes with less) crashes php.

It crashes even if the header was already sent.


 _old_ report 
This code crashes php-3.11 win32 cgi and php4-b3
In win32 cgi mode this brings up a "Access Violation" box.

web server is Apache/1.3.9-win32.



php3.ini is unmodified except for modules stuff that wasn't working
anyway



[1999-12-23 20:16:03] rasmus at cvs dot php dot net

I can't reproduce this on Linux nor on Win98 running 4.0b3



[1999-12-23 20:10:46] mog at linux dot nu

This code crashes php-3.11 win32 cgi and php4-b3
In win32 cgi mode this brings up a "Access Violation" box.

web server is Apache/1.3.9-win32.




php3.ini is unmodified except for modules stuff that wasn't working
anyway




-- 
Edit this bug report at http://bugs.php.net/?id=3034&edit=1

#40935 [Fbk->Opn]: Error/Exception with PDO::fetch/fetchAll and disabled ATTR_EMULATE_PREPARES

[phpbugs at filofox dot com]

 ID:   40935
 User updated by:  phpbugs at filofox dot com
 Reported By:  phpbugs at filofox dot com
-Status:   Feedback
+Status:   Open
 Bug Type: PDO related
 Operating System: Linux Debian Sarge 3.1
 PHP Version:  5.2.1
 New Comment:

Revised test code:
==

setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );

// disable emulation <--- this triggers the problem
$db->setAttribute( PDO::ATTR_EMULATE_PREPARES, false );

// Create a dummy table
$db->exec("CREATE TABLE IF NOT EXISTS TestTable (id INT)");

$sql = 'INSERT INTO TestTable VALUES ( NULL )';
$query = $db->prepare( $sql );
if( $query->execute() )
{
$results = $query->fetchAll( PDO::FETCH_ASSOC );
}
$query->closeCursor();

?>


Previous Comments:


[2007-04-03 18:49:46] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.





[2007-03-28 13:28:58] phpbugs at filofox dot com

Description:

When using PDO with MySQL, if ATTR_EMULATE_PREPARES is disabled, an
exception (or error if not using ERRMODE_EXCEPTION) is thrown if you try
to fetch() or fetchAll() a null result set (i.e. after INSERT, UPDATE
etc.). However, if ATTR_EMULATE_PREPARES is enabled, the exception/error
is not triggered.

Clearly fetch on a null result set is redundant, but either it should
throw an exception/error or it shouldn't, regardless of the state of
ATTR_EMULATE_PREPARES. 



Reproduce code:
---
$db = new PDO( $dsn, $username, $password );
// enables exceptions
$db->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );

// disable emulation <--- this triggers the problem
$db->setAttribute( PDO::ATTR_EMULATE_PREPARES, false );

$sql = 'INSERT INTO TestTable VALUES ( NULL )';
$query = $db->prepare( $sql );
if( $query->execute() )
{
$results = $query->fetchAll( PDO::FETCH_ASSOC );
}
$query->closeCursor();


Expected result:

Either an exception/error should be thrown in both cases, or neither.

Actual result:
--
'PDOException' :: 'SQLSTATE[HY000]: General error: 2053 '






-- 
Edit this bug report at http://bugs.php.net/?id=40935&edit=1

#40970 [Bgs]: filemtime/stat slower on PHP5 vs PHP4

[php at edwardk dot info]

 ID:   40970
 User updated by:  php at edwardk dot info
 Reported By:  php at edwardk dot info
 Status:   Bogus
 Bug Type: Performance problem
 Operating System: Windows 2003
 PHP Version:  5.2.1
 New Comment:

I have new information, the slowness is present only when safe mode is
on.
(for 1000 iterations)
For PHP 4.4.6
-
G:\>C:\php4\php.exe -n -d safe_mode=On filemtime.php
X-Powered-By: PHP/4.4.6
Content-type: text/plain

Took 7.451ms
G:\>C:\php4\php.exe -n -d safe_mode=Off filemtime.php
X-Powered-By: PHP/4.4.6
Content-type: text/plain

Took 0.152ms
G:\>



For PHP 5.2.1
-
G:\>C:\php5\php-cgi.exe -n -d safe_mode=On filemtime.php
X-Powered-By: PHP/5.2.1
Content-type: text/plain

Took 12.172ms
G:\>C:\php5\php-cgi.exe -n -d safe_mode=Off filemtime.php
X-Powered-By: PHP/5.2.1
Content-type: text/plain

Took 0.108ms
G:\>


Additionally, I checked with FileMon, and the requests made are
different for each version (Safe mode On).

PHP 4.4.6
6:03:02.751 AM  php.exe:2344OPENG:\ SUCCESS Options: Open Directory 
Access: 0011
6:03:02.751
AM  php.exe:2344DIRECTORY   G:\ SUCCESS 
FileBothDirectoryInformation:
filemtime.php   
6:03:02.751 AM  php.exe:2344CLOSE   G:\ SUCCESS 

PHP 5.2.1
6:03:04.158 AM  php-cgi.exe:2216QUERY
INFORMATION G:\filemtime.phpSUCCESS Attributes: A   
6:03:04.158 AM  php-cgi.exe:2216OPENG:\ SUCCESS Options: Open
Directory  Access: 0011 
6:03:04.158
AM  php-cgi.exe:2216DIRECTORY   G:\ SUCCESS 
FileBothDirectoryInformation:
filemtime.php   
6:03:04.158 AM  php-cgi.exe:2216CLOSE   G:\ SUCCESS 



note the additional "QUERY INFORMATION" access.


I've tried disabling safe mode and though performance has improved, it
is still slower than the PHP4 version on my script when run under an
apache module. The stats are now:

~40ms safe mode on (PHP5)
~15ms safe mode off (PHP5)

~5.5ms safe mode on (PHP4)
~0.7ms safe mode off (PHP4)


Previous Comments:


[2007-04-02 20:38:07] php at edwardk dot info

One thing I have noticed is that when the PHP5 version runs, Apache2's
kernel CPU time shoots up (measured in (Process Explorer) while
processing the request where as in PHP4, CPU use remains low.



[2007-04-02 20:32:03] php at edwardk dot info

Here's the new code:


and the results:
PHP 4.4.6
Took 5.232ms for 481 files
PHP 5.2.1
Took 107.762ms for 481 files



[2007-04-02 20:13:21] [EMAIL PROTECTED]

Might be related to stat cache usage... Try to see if you see the
difference stat'ing a set of files in random order, not the same file
repeatedly.



[2007-04-01 20:42:47] php at edwardk dot info

I have modified the code to use, $blah = stat('.htaccess');
This file does exist, it is 161 bytes on NTFS.

PHP 4.4.6: 1.641ms
PHP 5.1.2: 108.29ms

Normally, I would be using the commands on many small files (400ish) in
the current folder to determine if any of them had changed. This was
fast enough on PHP4, but on PHP5, the same code takes much longer.



[2007-04-01 14:44:02] [EMAIL PROTECTED]

This is only the case when stat() fails.

If you change stat('.'); to stat(''); you will se that PHP5
is faster than php4. Almost 2x.



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/40970

-- 
Edit this bug report at http://bugs.php.net/?id=40970&edit=1

#41012 [WFx]: exception handling

[perching_eagle at yahoo dot com]

 ID:   41012
 User updated by:  perching_eagle at yahoo dot com
 Reported By:  perching_eagle at yahoo dot com
 Status:   Wont fix
 Bug Type: *Compile Issues
 Operating System: *
 PHP Version:  *
 New Comment:

to [EMAIL PROTECTED], thank you for your reasonable explanation.


Previous Comments:


[2007-04-10 05:19:01] [EMAIL PROTECTED]

Even though exceptions might be normalities in java and other languages
they keep having anexceptional role in PHP and stay theway they are. In
fact PHP is not a pure OO based language and needs to be able to deal
with its core errors in a non object oriented way. Further more PHP is
not perectly designed for applications have long run times but for web
share nothing web applications where the runtime depends on the time a
script needs to finish a request. For that reason a core error simply
needs to be logged rather than having a control mechanism that
reinitializes whatever should be running.



[2007-04-10 02:46:01] perching_eagle at yahoo dot com

correction= 
   for the first line of the python code in the post before this one.
   
   # add qoutes to the parameter in the function 'input()' 
   num=input("enter a number, do not enter zero:")


 the c programming language and other procedural languages can catch
errors just like object oriented laguages that use exceptions, if the
"try" keyword cannot force the compiler to overlook errors, then you
have to use an "if" statement, just like in "c" and actually write more
code. but if the "try" can suppress errors, you don't have to include
"if" statements and the "throw" keyword, you just write "catch"
statements that can catch each exception and error at runtime, and then
you can continue you code without stopping it or allow the program to
stop after sending a customized message on your site, rather than have
your site or program crash.  you just explicitly throw an exception that
closes the program, after sending a customized message for fatal errors
simple. 
**
to [EMAIL PROTECTED], a zero division error is an exception, it is not a
fatal error, fatal errors require that you reset the program.they are
errors that should not be caught such as linkage errors and thread death
errors and some machine errors. the program should be allowed to end
gracefully but could still catch them if you wish.



[2007-04-10 02:19:36] perching_eagle at yahoo dot com

well the logic behind exceptions is to help you handle ALL types of
errors and i will show you a similar example in python.

 python code:

 num=input('enter a number, do not enter zero:)
 try:
 print 34/int(num)
 except ZeroDivisionError:
 print "error,you entered zero"

 (if you enter 2) output: 17

 (if you enter 0) output: error, you entered zero
 
  #java does exactly the same thing.
 

simple code, i didn't have to explicitly throw any exception (using the
throw keyword) or include an "if" statement. this obeys the rule of keep
things simple, and the "try" keyword actually does something, as opposed
to being a mere decoration as it is now in PHP.



[2007-04-08 15:11:42] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Fatal errors are not exceptions and therefor try {} does nothing to 
catch them.



[2007-04-06 21:00:29] perching_eagle at yahoo dot com

 //this error is illegal

  however zend engine will flag the error in the second try block
  (an abnormal behavior) instead of ignoring it.

note: when flagging other posters comments as bogus, give logical
reasons for doing so.



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/41012

-- 
Edit this bug report at http://bugs.php.net/?id=41012&edit=1

#41034 [Opn->Asn]: json_encode ignores null byte started keys in arrays

[tony2001]

 ID:   41034
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at sameprecision dot org
-Status:   Open
+Status:   Assigned
 Bug Type: Unknown/Other Function
 Operating System: suse linux 10, windows XP sp2
 PHP Version:  5.2.1
-Assigned To:  
+Assigned To:  tony2001


Previous Comments:


[2007-04-10 04:40:29] php at sameprecision dot org

Description:

If a key in an array starts with the null byte, json_encode ignores
that key=>value pair.

This seems wrong because json_encode doesn't care about null bytes
anywhere in the value (and neither does javascript, about keys or
values).

Reproduce code:
---
//works as expected:
echo json_encode(array(0,"a\0b"=>1,"\0null-prefixed value"));

echo "\n\n";

//ignores second element whose key begins with null byte:
echo json_encode(array(0,"\0ab"=>1,"\0null-prefixed value"));

Expected result:

{"0":0,"a\0b":1,"1":"\0null-prefixed value"}

{"0":0,"\0ab":1,"1":"\0null-prefixed value"}




// \0 represents an actual null byte here

Actual result:
--
{"0":0,"a\0b":1,"1":"\0null-prefixed value"}

{"0":0,"1":"\0null-prefixed value"}




// \0 represents an actual null byte here







-- 
Edit this bug report at http://bugs.php.net/?id=41034&edit=1

#41037 [Asn->Csd]: unregister_tick_function() inside the tick function crash PHP

[tony2001]

 ID:   41037
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Assigned
+Status:   Closed
 Bug Type: Unknown/Other Function
 Operating System: *
 PHP Version:  5CVS-2007-04-10 (CVS)
 Assigned To:  tony2001
 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:


[2007-04-10 09:04:27] [EMAIL PROTECTED]

Description:

the given code segfaults (from a manual user note)

Reproduce code:
---







-- 
Edit this bug report at http://bugs.php.net/?id=41037&edit=1

#41037 [Opn->Asn]: unregister_tick_function() inside the tick function crash PHP

[tony2001]

 ID:   41037
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Assigned
 Bug Type: Unknown/Other Function
 Operating System: *
 PHP Version:  5CVS-2007-04-10 (CVS)
-Assigned To:  
+Assigned To:  tony2001


Previous Comments:


[2007-04-10 09:04:27] [EMAIL PROTECTED]

Description:

the given code segfaults (from a manual user note)

Reproduce code:
---







-- 
Edit this bug report at http://bugs.php.net/?id=41037&edit=1

#41037 [NEW]: unregister_tick_function() inside the tick function crash PHP

[[EMAIL PROTECTED]]

From: [EMAIL PROTECTED]
Operating system: *
PHP version:  5CVS-2007-04-10 (CVS)
PHP Bug Type: Unknown/Other Function
Bug description:  unregister_tick_function() inside the tick function crash PHP

Description:

the given code segfaults (from a manual user note)

Reproduce code:
---



-- 
Edit bug report at http://bugs.php.net/?id=41037&edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41037&r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41037&r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41037&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41037&r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41037&r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41037&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41037&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41037&r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41037&r=support
Expected behavior:http://bugs.php.net/fix.php?id=41037&r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41037&r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41037&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41037&r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41037&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41037&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41037&r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41037&r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41037&r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41037&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41037&r=mysqlcfg

#41035 [Opn->Fbk]: "log_errors_max_len" has no effect for values over 1024 or 0

[tony2001]

 ID:   41035
 Updated by:   [EMAIL PROTECTED]
 Reported By:  sv_forums at fmethod dot com
-Status:   Open
+Status:   Feedback
 Bug Type: PHP options/info functions
 Operating System: Windows XP
 PHP Version:  5.2.1
 New Comment:

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.




Previous Comments:


[2007-04-10 05:11:40] sv_forums at fmethod dot com

Description:

The "log_errors_max_len" config option should allow us to disable the
cap limit if we set it to 0. This has no effect and the actual limit
remains 1024. Same about entering values over 1024.

Reproduce code:
---
1. Use the following error reporting settings:

error_reporting(E_ALL|E_STRICT);
ini_set('display_errors',0);
ini_set('log_errors',1);
ini_set('log_errors_max_len','0'); // alternatively use values larger
than 1024, they also don't work
ini_set('html_errors',0);

2. Produce a code with enough nested calls so when you throw an
exception, together with the full stack trace, it'll be over 1024 bytes

3. Throw exception inside the chain.

4. Check the log.

Expected result:

Since in the example above I've set log_errors_max_len to 0, the log
stack traces should not be clipped at the 1024 boundary, but it is.

Actual result:
--
The error report log gets clipped at 1024 bytes.





-- 
Edit this bug report at http://bugs.php.net/?id=41035&edit=1

#41033 [Opn->Asn]: Patch to enable signing with DSA keys

[tony2001]

 ID:   41033
 Updated by:   [EMAIL PROTECTED]
 Reported By:  gordyf at google dot com
-Status:   Open
+Status:   Assigned
-Bug Type: OpenSSL related
+Bug Type: Feature/Change Request
 Operating System: any
 PHP Version:  5.2.1
-Assigned To:  
+Assigned To:  pajoye


Previous Comments:


[2007-04-10 00:47:11] gordyf at google dot com

It seems I shouldn't have used link tags, here they are without
trailing quotes.

Man page: http://www.die.net/doc/linux/man/man3/evp_digestinit.3.html
Patch: http://trigse.cx/php-openssl-patch.diff



[2007-04-10 00:43:02] gordyf at google dot com

Description:

This patch enables signing and verifying signatures with DSA keys. This
currently does not work because EVP_sha1() is called when signing with
SHA1 hash, and EVP_dss1() must be called for DSA-SHA1 signing.  It adds
the OPENSSL_ALGO_DSS1 constant which must be used with the last
parameter of openssl_sign and openssl_verify when using a DSA key.

>From the http://www.die.net/doc/linux/man/man3/evp_digestinit.3.html";>man
page: "The link between digests and signing algorithms results in a
situation where EVP_sha1() must be used with RSA and EVP_dss1() must be
used with DSS even though they are identical digests."

Patch available http://trigse.cx/php-openssl-patch.diff";>here.

Reproduce code:
---
$key = file_get_contents("keys/dsa.privkey.pem");
$prkeyid = openssl_get_privatekey($key);
$ct = "Hello I am some text!";
openssl_sign($ct, $signature, $prkeyid, OPENSSL_ALGO_DSS1);
echo "Signature: ".base64_encode($signature)."";

$key = file_get_contents("keys/dsa.pubkey.pem");
$pukeyid = openssl_get_publickey($key);
$valid = openssl_verify($ct, $signature, $pukeyid, OPENSSL_ALGO_DSS1);
echo "Signature validity: ".$valid;

Expected result:

(After patch)
Signature:
MCwCFGKwtl03QDikxpqoGMrr4+EPoZfZAhQYIl/Bhzur/CW50b3ZFf5dYig3PA==
Signature validity: 1

Actual result:
--
(Before patch)
Signature:
Signature validity: -1





-- 
Edit this bug report at http://bugs.php.net/?id=41033&edit=1

#41032 [Opn->Bgs]: Backreferences are not escaped properly

[tony2001]

 ID:   41032
 Updated by:   [EMAIL PROTECTED]
 Reported By:  phpcoder at cyberpimp dot sexventure dot com
-Status:   Open
+Status:   Bogus
 Bug Type: PCRE related
 Operating System: Win98SE
 PHP Version:  5.2.1
 New Comment:

The documentation is correct:

var_dump('\''); - 1 char
var_dump('\"'); - 2 chars
var_dump('\0'); - 2 chars
var_dump('\\'); - 1 char


Previous Comments:


[2007-04-09 23:07:21] phpcoder at cyberpimp dot sexventure dot com

Description:

According to the documentation for preg_replace(), double-quotes,
apostrophes/single-quotes, backslashes, and nulls are supposed to be
returned escaped.  However, only double-quotes and nulls are escaped;
apostrophes/single-quotes and backslashes are returned in their original
context.

Reproduce code:
---



Expected result:

2 chars returned (\')
2 chars returned (\")
2 chars returned (\0)
2 chars returned (\\)


Actual result:
--
1 chars returned (')
2 chars returned (\")
2 chars returned (\0)
1 chars returned (\)






-- 
Edit this bug report at http://bugs.php.net/?id=41032&edit=1

#41036 [Opn->Bgs]: [chm] bug on function.mssql-connect.html

[derick]

 ID:   41036
 Updated by:   [EMAIL PROTECTED]
 Reported By:  sourabh_2412 at yahoo dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Output Control
 Operating System: windows
 PHP Version:  5.2.1
 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.

You simply don't have the MSSQL extension properly enabled.


Previous Comments:


[2007-04-10 05:22:00] sourabh_2412 at yahoo dot com

Description:

I have found a bug on page function.mssql-connect.html
[chm date: 2007-03-27]...


Reproduce code:
---
PHP Fatal error: Call to undefined function mssql_connect() in
C:\Program Files\PHP\project1.php on line 7 






-- 
Edit this bug report at http://bugs.php.net/?id=41036&edit=1

#40806 [Csd->Bgs]: session id gets over-written by other server's cookie

[tony2001]

 ID:   40806
 Updated by:   [EMAIL PROTECTED]
 Reported By:  john at albin dot net
-Status:   Closed
+Status:   Bogus
 Bug Type: Session related
 Operating System: any
 PHP Version:  any
 Assigned To:  iliaa


Previous Comments:


[2007-04-10 00:22:26] john at albin dot net

Scott, I hadn't realized that the cookie spec didn't specify the order

with regards to the domain. Uh-oh.

My application (Drupal) specifies "/" as the path and also specifies a

domain when setting the cookie (both for other.example.com and 
example.com). And the "Live HTTP Headers" plug-in reports both cookies

are sent:

http://dev.albin.net/

GET / HTTP/1.1
Host: dev.albin.net
Cookie: PHPSESSID=fb4f595010d9cfbd8017dfc57eed6993; PHPSESSID 
=6cb4fca68cce1846cdccde82b151d5bb

HTTP/1.x 200 OK
Server: Apache/1.3.33 (Darwin) PHP/4.4.6 mod_perl/1.29
X-Powered-By: PHP/4.4.6
Content-Type: text/html; charset=utf-8

However, the fb4f5... cookie value is for .albin.net and the 6cb4... 
cookie value is for dev.albin.net.

The spirit of the cookie spec would suggest that the dev.albin.net 
should be sent first, but alas...

So this is a bug in the cookie spec. And not one in PHP or the web 
browser. Nuts.

The work-around for others in the situation is to set a unique 
cookie_name() for each installation of your PHP app.

I am already actively working with the Drupal (PHP-based CMS) 
community to get this work-around implemented.
http://drupal.org/node/56357

Thanks for your help, Scott! And Tony and Iliaa!



[2007-04-09 23:35:37] [EMAIL PROTECTED]

Just tested this with 5.2.2-dev and I can't reproduce the issue.

By default PHP doesn't set a domain parameter for the session cookies,
even when I did this the cookie for .example.com could be read by the
host other.example.com, since other.example.com didn't set another
session cookie I couldn't see an issue.

Can you provide an example of the HTTP header that is being sent? There
is an extension for Firefox called Live HTTP Headers that will provide
the information.



[2007-04-09 23:10:29] [EMAIL PROTECTED]

The RFC mentions that order in regards to domain is unspecified which I
think this bug is in regards to rather than the path issue.

Spec >>
   If multiple cookies satisfy the criteria above, they are ordered in
   the Cookie header such that those with more specific Path
attributes
   precede those with less specific.  Ordering with respect to other
   attributes (e.g., Domain) is unspecified.

Does the reporter have an example of a browser which demonstrates the
bug here?



[2007-04-09 22:32:40] john at albin dot net

Hi Tony, thanks for pointing at the source code reference. I am not 
familiar with PHP internals.

I'm using PHP 4.4.6 and it's version of main/php_varriables.c (lines 
201-209) does not (at first glance) appear to be analogous to the PHP 5

version (lines 209-218).

Perhaps there is something in those lines that are the problem in PHP
4?

(I have checked Firefox 2, IE 7, and Safari 2 and the problem persists,

so it can't be the browsers.)



[2007-04-09 21:52:26] [EMAIL PROTECTED]

http://cvs.php.net/viewvc.cgi/php-src/main/php_variables.c?annotate=1.104.2.10.2.7#l204
/* According to rfc2965, more specific paths are listed above the less
specific ones.
* we encounter a duplicate cookie name, we should skip it, since it is
not possible
* to have the same (plain text) cookie name for the same path and we
should not overwrite
* more specific cookies with the less specific ones.
*/

If your browser (whatever it is) does not comply with the standard, you
should complain to your browser developers, not PHP.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40806

-- 
Edit this bug report at http://bugs.php.net/?id=40806&edit=1