#24752 [Csd]: unknown column type uniqueidentifier, type 35
ID: 24752
User updated by: s dot sonnenberg at coolspot dot de
Reported By: s dot sonnenberg at coolspot dot de
Status: Closed
Bug Type: MSSQL related
Operating System: Linux
PHP Version: 4.3.2
New Comment:
I use exactly the combination : PHP 4.3.4 + FreeTDS 0.61.2.
And we have no such problems.
Could you please send your configure strings ?
Previous Comments:
[2004-02-20 11:54:47] rgesse at ndigital dot com
I ran into the same problem wih the latest version of PHP and Freetds
(as of Feb. 18, 2004). I found that the only way to SELECT from a
uniqueidentifier field is the following:
SELECT LEFT(CAST(uniqueidentifierfield as char(64)), 36) AS thisfield
FROM table
[2003-07-23 11:56:21] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-07-22 08:29:36] s dot sonnenberg at coolspot dot de
Description:
If you use the combination FreeTDS 0.61 + PHP 4.3.2 to access
data on a MS SQL Server 2000, columns of type uniqueidentifier (type
35) or causing php to barf, and you are not able to handle them.
I got it to work after a applying a patch, that I figure out :
for ext/mssql/php_mssql.c :
--- php-4.3.2/ext/mssql/php_mssql.c 2003-05-21 02:06:41.0
+0200
+++ php-4.3.2-LOCAL/ext/mssql/php_mssql.c 2003-07-22
13:34:35.0
+0200
@@ -800,6 +800,15 @@
Z_DVAL_P(result) = (double) floatcol8(offset);
Z_TYPE_P(result) = IS_DOUBLE;
break;
+ case SQLUNIQUE:
+ {
+ int length = 16;
+ char *data = charcol(offset);
+ Z_STRVAL_P(result) =
estrndup(data,length);
+ Z_STRLEN_P(result) = length;
+ Z_TYPE_P(result) = IS_STRING;
+ }
+ break;
case SQLVARBINARY:
case SQLBINARY:
case SQLIMAGE: {
and for ext/mssql/php_mssql.h
--- php-4.3.2/ext/mssql/php_mssql.h 2003-02-09 08:49:34.0
+0100
+++ php-4.3.2-LOCAL/ext/mssql/php_mssql.h 2003-07-22
13:32:42.0
+0200
@@ -32,7 +32,7 @@
#endif
-#define MSSQL_VERSION 7.0
+#define MSSQL_VERSION 8.0
#include sqlfront.h
#include sqldb.h
@@ -59,6 +59,7 @@
#define SQLIMAGE SYBIMAGE
#define SQLBINARY SYBBINARY
#define SQLVARBINARY SYBVARBINARY
+#define SQLUNIQUE SYBUNIQUE
#define DBERRHANDLE(a, b) dberrhandle(b)
#define DBMSGHANDLE(a, b) dbmsghandle(b)
#define DBSETOPT(a, b, c) dbsetopt(a, b, c, -1)
It works for me :
RedHat 9.0 + updates
FreeTDS 0.61 (configure --prefix=/usr/local/freetds/0.61/
--enable-msdblib
--with-tdsver=8.0)
PHP 4.3.2 (configure --prefix=/usr/local/php/4.3.2/
--with-mssql=/usr/local/freetds/0.61/ --without-mysql)
Windows 2000 BackOffice Server SP 4 + MS SQL Server 2000 SP 3
Perhaps +#define MSSQL_VERSION 8.0 is a bit heavy, but looks nicer
in
phpinfo() ...
You can test it, if you fetch such a field, and then pass that value to
mssql_guid_string. The output must be equal to CAST (field as
CHAR(64)), where field is of the uniqueidentifier type.
Reproduce code:
---
$sql = select * from tablename;
$res = mssql_query($sql);
/* causes php to barf, if you have a field of type uniqueidentifier */
--
Edit this bug report at http://bugs.php.net/?id=24752edit=1
#21228 [Csd]: output handler 'ob_gzhandler' cannot be used twice
ID: 21228
Updated by: [EMAIL PROTECTED]
Reported By: mlaukast1 at hotmail dot com
Status: Closed
Bug Type: Output Control
Operating System: All
PHP Version: 4.3.0/4.4.0-dev
Assigned To: iliaa
New Comment:
Have you check the ini? It must contain the following two settings:
output_handler =
zlib.output_compression = Off
Previous Comments:
[2004-02-25 02:13:39] ricko at garagegames dot com
Reproduced this bug in v4.3.5rc3 on Apache/Win32 with php beling loded
as a module.
?PHP
ob_start('ob_gzhandler');
?
Warning: (null)() [ref.outcontrol]: output handler 'ob_gzhandler'
cannot be used twice in Unknown on line 0
[2002-12-30 13:41:19] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2002-12-28 13:15:52] chris at de-punkt dot de
The error occurs on Linux, too. A customer reported it and it can
nicely be reproduced with
?php
ob_start(ob_gzhandler);
?
which yields the warning visible under
http://www.christopher-kunz.de/ob.php
Environment is http://www.christopher-kunz.de/info.php
[2002-12-27 19:40:31] mlaukast1 at hotmail dot com
If I use ob_start(ob_gzhandler) function I get an error message: PHP
Warning: ob_gzhandler() [a
href='http://www.php.net/ref.outcontrol'ref.outcontrol/a]: output
handler 'ob_gzhandler' cannot be used twice in c:\web\test.php3 on line
11. The same script runs fine on 4.2.3. Interestingly, on version
4.3.0 ob_get_level() returns 2 and on 4.2.3 the return value is 1. I'm
using Windows 2000 Server/IIS5. PHP is configured in CGI mode.
Here's the script:
//---start---
%
ob_start(ob_gzhandler);
%
html
body
h3This is a test. ob_get_level: % echo ob_get_level(); %/h3
/body
/html
%
if(ob_get_level()){
ob_end_flush();
}
%
//---end---
And here's the essential configurations from the 'php.ini' file:
output_buffering = 4096
output_handler =
zlib.output_compression = Off
implicit_flush = Off
unserialize_callback_func=
allow_call_time_pass_reference = Off
If I set output_handler = ob_gzhandler and remove the
ob_start(ob_gzhandler) from the script it's working on 4.3.0 as well.
However, this way the compression is always on and I can't determine
myself when to use it.
--
Edit this bug report at http://bugs.php.net/?id=21228edit=1
#27388 [Opn-WFx]: complete compatibility check in E_STRICT mode
ID: 27388 Updated by: [EMAIL PROTECTED] Reported By: agl at xs4all dot nl -Status: Open +Status: Wont fix Bug Type: Feature/Change Request -Operating System: any +Operating System: * PHP Version: 5.0.0b4 (beta4) New Comment: There is a compatibility mode that allows implicit object cloning as PHP 4 did, so this does not fit into E_STRICT. Previous Comments: [2004-02-24 23:15:36] agl at xs4all dot nl Description: Background: People need a migration path from PHP4 to PHP5. Some things that work in PHP5 won't work in PHP5, or work differently. PHP5 has an E_STRICT setting, which catches many of these issues. They can be logged, so a dev can enable this, go through their log for a while, until it stays empty Then their app should be relatively clean. Issue: Not all situations are checked. They need to be, otherwise the migration path is still not clear. For instance a pass-object-by-value which is allowed in PHP4 simply ends up being a pass-object-by-reference in PHP5. I would suggest that with E_STRICT enabled, PHP5 should issue a warning if no $obj is specified. Yes this is slightly ugly and perhaps there are nicer solutions possible. I'm merely pointing out the need to address the migration issue. All of it, not 90%. 90% is not enough for the real world. There are very big PHP apps out there, and just having people dig through all code hoping to spot all issues is unrealistic. Thanks. -- Edit this bug report at http://bugs.php.net/?id=27388edit=1
#26332 [NoF-Opn]: Using curl_multi_exec with curl_multi_fdset doesnt work
ID: 26332
User updated by: foxkill at gmx dot de
Reported By: foxkill at gmx dot de
-Status: No Feedback
+Status: Open
Bug Type: cURL related
Operating System: Linux
-PHP Version: 5CVS-2003-11-20 (dev)
+PHP Version: 5.0.0RC1-dev
New Comment:
You'll find the script to reproduce the error under:
http://www.secnow.de/websearch/websearch.txt
The script runs either in an endless loop or if it terminates it
prints:
Last leak repeated 2 times
/opt/local/src/lamp/php5-src/ext/curl/multi.c(62) : Freeing 0x40291A34
(8 bytes), script=websearch.php
=== Total 4 memory leaks detected ===
Previous Comments:
[2004-02-24 17:13:24] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Open. Thank you.
[2004-02-20 04:52:21] [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 ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
[2003-11-20 09:48:05] foxkill at gmx dot de
Description:
I try to use curl_multi_fdset() together with curl_multi_exec() in
php5. But this doesn't work.
I modelled my php code after the sample (multi-app.c) which is provided
by the curl-src package.
Reproduce code:
---
this is the code I use for php5 (three single curl handles were
added):
while (CURLM_CALL_MULTI_PERFORM == curl_multi_exec($m, $still_running))
;
while ($still_running) {
$fd = curl_multi_select($m, 1);
switch($fd) {
case -1:
break;
case 0:
default:
while (CURLM_CALL_MULTI_PERFORM == curl_multi_exec($m,
$still_running))
;
}
}
Expected result:
The code should behave like the multi-app.c sample. See
[curl-src]/docs/examples/multi-app.c.
Actual result:
--
The code runs in an endless loop. Because curl_multi_exec() (alias
curl_multi_perform()) needs to reference the variables readfds,
writefds which were set by a previous call to curl_multi_fdset(). But
these fdsets have gone out of scope. The C Code works because the
fdsets are still present on the stack. See man 3 curl_multi_fdset for
further details. curl --version gives:
curl 7.10.8 (i686-pc-linux-gnu) libcurl/7.10.8 OpenSSL/0.9.7c
zlib/1.1.4
Protocols: ftp gopher ldap http file https ftps
Features: SSL libz NTLM
--
Edit this bug report at http://bugs.php.net/?id=26332edit=1
#27391 [NEW]: typo in Fatal Error message
From: anselor at yahoo dot com Operating system: Linux PHP version: 5CVS-2004-02-25 (dev) PHP Bug Type: Unknown/Other Function Bug description: typo in Fatal Error message Description: The new error message for throwing a class that doesn't extend Exception has a typo. The message i got was: Fatal error: Exceptions must valid objects that are derived from class Exception in /home/anselor/var/www-data/htdocs/exceptiontest.phtml on line 20 Perhaps it should be something more like: Fatal error: Exceptions must BE valid objects that are derived from class Exception in /home/anselor/var/www-data/htdocs/exceptiontest.phtml on line 20 Very very very minor issue, just thought I'd let you know. -- Edit bug report at http://bugs.php.net/?id=27391edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27391r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27391r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27391r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27391r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27391r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27391r=needscript Try newer version: http://bugs.php.net/fix.php?id=27391r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27391r=support Expected behavior: http://bugs.php.net/fix.php?id=27391r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27391r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27391r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27391r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27391r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27391r=dst IIS Stability: http://bugs.php.net/fix.php?id=27391r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27391r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27391r=float
#27391 [Opn-Csd]: typo in Fatal Error message
ID: 27391 Updated by: [EMAIL PROTECTED] Reported By: anselor at yahoo dot com -Status: Open +Status: Closed Bug Type: Unknown/Other Function Operating System: Linux PHP Version: 5CVS-2004-02-25 (dev) New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2004-02-25 05:31:58] anselor at yahoo dot com Description: The new error message for throwing a class that doesn't extend Exception has a typo. The message i got was: Fatal error: Exceptions must valid objects that are derived from class Exception in /home/anselor/var/www-data/htdocs/exceptiontest.phtml on line 20 Perhaps it should be something more like: Fatal error: Exceptions must BE valid objects that are derived from class Exception in /home/anselor/var/www-data/htdocs/exceptiontest.phtml on line 20 Very very very minor issue, just thought I'd let you know. -- Edit this bug report at http://bugs.php.net/?id=27391edit=1
#27389 [Opn-Fbk]: $_POST variables not accessible from multiview
ID: 27389 Updated by: [EMAIL PROTECTED] Reported By: vanlei at yahoo dot com -Status: Open +Status: Feedback Bug Type: Apache related Operating System: Mac OS X PHP Version: 4.3.4 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. Apache version, how to configure httpd.conf, how PHP is configured (module/cgi), etc. Previous Comments: [2004-02-24 23:55:29] vanlei at yahoo dot com Description: $_POST variables aren't accessible from within a multiview if one configures the action of a form to be the child of a multiview. In other words, If I set the action of a form to be 'example.com/multi/sub' where multi is a PHP file called multi.php that catches the url 'example.com/ multi/sub/' (by using apache's multiviews), multi.php will not have access to the $_POST variable. It works if one sets the action as 'example.com/multi/ '. Reproduce code: --- Example code: form method=post action=http://example.com/multi/sub/; name=form input type=submit name=submit value=Value / /form multi.php: echo $_POST['submit'] Expected result: Expected: $_POST['submit'] == Value Actual result: -- Blank. I think PHP associates the $_POST variable with /multi/sub when sub isn't a script/file. Instead the request is handled by multi. -- Edit this bug report at http://bugs.php.net/?id=27389edit=1
#27385 [Opn-Ver]: GD: Eliptical fills don't work with translucent colours
ID: 27385 Updated by: [EMAIL PROTECTED] Reported By: nih at phlux dot co dot uk -Status: Open +Status: Verified Bug Type: GD related -Operating System: FreeBSD +Operating System: * -PHP Version: 4.3.4 +PHP Version: 4CVS, 5CVS (2004-02-24) Previous Comments: [2004-02-24 18:30:17] nih at phlux dot co dot uk I used the bundled GD library. [2004-02-24 18:14:25] [EMAIL PROTECTED] Did you use the bundled GD library or the external one. (In short: what is your configure line?) [2004-02-24 17:51:49] nih at phlux dot co dot uk Description: The elliptical drawing tools in the GD library that offer a fill function do not correctly render the fill when using a translucent colour. It would appear that the fill is drawn by a series of lines from the centre point to each pixel around the edge of the ellipse or arc, thus pixels near the centre are drawn over many times, thus increasing the effective alpha of those pixels. Reproduce code: --- ?php $img = imagecreatetruecolor(100, 100); imageantialias($img, FALSE); $blue = imagecolorallocatealpha($img, 0, 0, 255, 50); imagefilledarc($img, 5, 5, 170, 170, 0, 85, $blue, 4); header(Content-type: image/png); imagepng($img); imagedestroy($img); ? Expected result: There should be a PNG image output of an arc of a 170px diameter going from a bearing of 090 to a bearing of 175 in 50% transparent pure RGB blue (0, 0, 255). Actual result: -- The transparency isn't correct, the closer towards the centre of the arc the pixel is, the lower it's transparency (I'm almost certain it's because they are being redrawn over and over). -- Edit this bug report at http://bugs.php.net/?id=27385edit=1
#27291 [Opn-Asn]: get_browser matches browscap.ini patterns incorrectly
ID: 27291 Updated by: [EMAIL PROTECTED] Reported By: php-bug-NOSPAM-2004 at ryandesign dot com -Status: Open +Status: Assigned Bug Type: *General Issues Operating System: * PHP Version: 4CVS, 5CVS (2004-02-20) Assigned To: jay Previous Comments: [2004-02-24 18:43:35] [EMAIL PROTECTED] Forgot to assign this to myself. Pretty close to having a decent fix based on what I'm seeing in browscap.dll. J [2004-02-23 21:14:19] php_bug_27291 at garykeith dot com In looking at browscap.ini with all Gecko-based browsers now using Gecko/* instead of Gecko/ I can find no reason why Netscape 7.x should have a problem with my definitions. I mean, what's wrong with the following browscap.ini definition? Mozilla/5.0 (Windows; ?; Windows NT 5.2; *) Gecko/* Netscape7/7.2* By any reasonable standard it should recognize this user agent as Netscape 7.2. In my tests using browscap.dll that's exactly what it did. Have I found yet another bug? Or did I completely miss what you were trying to tell me? Thanks for the tip about Camino. I don't see it very often in my logs. I've added the plus version to my database but haven't published it yet. I will bundle up all the files you requested and make them available on one of my servers. I'll e-mail you privately once that's done as I do not want to publicize the URL, LOL. [2004-02-23 17:25:44] php-bug-NOSPAM-2004 at ryandesign dot com Yes, I'm sorry, I meant to mention that changing to match Gecko/* instead of Gecko/ would seem to adversely affect Netscape 7.x, whose UA string starts the same way, but ends, after the Gecko/xxx part, with Netscape/xxx. Other things you should look out for in your file: I think you may be missing a pattern for the Camino browser version 0.7+. That's what you get if you use the latest nightly builds, which is effortlessly achieved by using the program CaminoKnight, and since 0.7 proper is so ancient now, most Camino users probably are running the 0.7+ builds. The UA string ends with the + sign but seems otherwise the same to what you have in the 2/15/04 file. Confirmed that the new browscap.ini from 2/15/04 causes a parse error at Apache startup. Filed http:// bugs.php.net/27372 Sorry about my shorthand... by .tgz I just meant a compressed file. A Zip file would be fine too. If you could bundle up your huge UA list, and possibly also your script to feed these to browscap.dll, and put them on a web or ftp server like Jay did or just email them to me, that'd be great. [2004-02-23 16:46:16] php_bug_27291 at garykeith dot com Sorry I forgot to address your proposal. You do need IIS to use browscap.dll. The problem is you cannot pass a user agent to it directly like you can with PHP. I have a script (in ASP/VBScript obviously, but probably easily converted to PHP) that lets you pass a specific user agent to browscap.dll and get the resulting browser in return. [2004-02-23 16:39:22] php_bug_27291 at garykeith dot com Tell me what a .tgz file is and if I can do it I will. I'm working two new bugs that I hope someone will post bug reports about. The first deals with the exclamation point that's part of the new Yahoo! Slurp crawler. I'm not sure what PHP is doing since I don't speak PHP but I'm told it's throwing a parsing error. I've also had some complaints from people saying user agents aren't being recognized since I switched from using Gecko/ to Gecko/* as we discussed earlier. 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/27291 -- Edit this bug report at http://bugs.php.net/?id=27291edit=1
#27375 [Opn-Bgs]: $DOCUMENT_ROOT sometimes empty when register_globals=on
ID: 27375
Updated by: [EMAIL PROTECTED]
Reported By: oliver at update dot ch
-Status: Open
+Status: Bogus
Bug Type: Apache2 related
Operating System: Linux
PHP Version: 4.3.3.
New Comment:
If you had bothered searching the bug database first you would have
find couple of dozen similar reports. And also that this is most likely
FIXED in CVS. (get stable snapshot from http://snaps.php.net/ )
Previous Comments:
[2004-02-25 02:04:35] oliver at update dot ch
Sorry about that. I'm not the pro on stuff like this.
But I try again:
Configuration:
--
'./configure' '--with-apxs2=/opt/httpd-2.0.47/bin/apxs'
'--with-config-file-path=/etc/httpd2' '--prefix=/opt/
php-4.x' '--enable-versioning' '--with-gd' '--with-jpeg-
dir=/usr' '--with-xpm-dir=/usr' '--with-bz2' '--with-
freetype-dir=/usr' '--enable-gd-native-ttf' '--enable-
debug=no' '--with-exec-dir=/opt/php-4.x/run' '--enable-
track-vars=yes' '--disable-cgi' '--enable-calendar' '--
with-ttf' '--with-imap' '--with-ft' '--with-xml' '--
with-mhash' '--with-mcrypt' '--with-bcmath' '--with-
snmp' '--enable-ucd-snmp-hack' '--enable-ucd-snmp-
compatibility' '--with-pdflib=/opt/pdflib-4.0' '--with-
zlib' '--enable-trans-sid' '--with-openssl' '--with-
wddx' '--with-crack' '--with-kerberos' '--with-gettext'
Reproduce code:
---
register_globals: ?=ini_get('register_globals')?
$GLOBALS[DOCUMENT_ROOT] = ?
=$GLOBALS[DOCUMENT_ROOT];?
$DOCUMENT_ROOT: ?=$DOCUMENT_ROOT?
$_SERVER[DOCUMENT_ROOT]: ?=$_SERVER[ 'DOCUMENT_ROOT'
]?
Expected result:
register_globals: 1
$GLOBALS[DOCUMENT_ROOT] = /home/www/
$DOCUMENT_ROOT: /home/www/
$_SERVER[DOCUMENT_ROOT]: /home/www/
Result (tested on 02/24/04):
--
register_globals: 1
$GLOBALS[DOCUMENT_ROOT] =
$DOCUMENT_ROOT:
$_SERVER[DOCUMENT_ROOT]: /home/www/
PHP-Version is 4.3.3.
The thing is, that I couldn't reproduce the result today
(02/25). So I guess, you can really let vanish this
report. Thanks for the help anyway.
[2004-02-24 16:57:50] [EMAIL PROTECTED]
Second try. (If I have to ask these same things for the 3rd time, this
bug report will vanish mysteriously..)
1. How did you configure Apache? (configure line used)
2. What MPM are you using with Apache?
3. What is register_globals set to WHEN this happens?
(put var_dump(ini_get(register_globals)); in the beginning of your
script, see bug #24253 what a nice short test script looks like)
4. Are you sure there aren't any .htaccess files or vhosts setting
register_globals to something else? Or setting any other php.ini
options? (using php_value, php_admin_value, php_flag or php_admin_flag
directives)
5. How was PHP configured into Apache? (as module or CGI binary??)
[2004-02-24 12:59:58] oliver at update dot ch
register_globals is always set on. register_globals is
set to on in the php.ini file.
SERVER_SOFTWARE:
Apache/2.0.47 (Unix) mod_perl/1.99_09 Perl/v5.6.1
mod_ssl/2.0.47 OpenSSL/0.9.6c DAV/2 FrontPain/5.0.0.0
[2004-02-24 12:03:10] [EMAIL PROTECTED]
When this happens, is register_globals on or off?
Do you override it in some vhost ?
How do you do it?
In other words: Not enough information..
[2004-02-24 07:30:00] oliver at update dot ch
Description:
The Global Variable $GLOBALS[DOCUMENT_ROOT] or $DOCUMENT_ROOT is
sometimes empty.
After a reload $DOCUMENT_ROOT mostly contains the expected value.
see also http://bugs.php.net/bug.php?id=25172
--
Edit this bug report at http://bugs.php.net/?id=27375edit=1
#27231 [Ver]: Large-size PHP script crashes SunONE webserver
ID: 27231
User updated by: herman at frontier dot nl
Reported By: herman at frontier dot nl
Status: Verified
Bug Type: iPlanet related
Operating System: SunOS 5.8+
PHP Version: 4CVS-2004-02-13
New Comment:
As this bug prevent me from rolling-out an application to a client, I
was wondering if any of the PHP developers could elaborate on possible
causes and if there might be a work-around I can try until a solution
has been found. I'm not proficient enough with coding to be of any
assistance with fixing the bug, I'm afraid...
Previous Comments:
[2004-02-14 11:40:49] [EMAIL PROTECTED]
Can not reproduce with apache2-worker.
[2004-02-13 18:32:00] [EMAIL PROTECTED]
You do not need to test ist on your system. I can reproduce the crashs
here, even with the latest stable snapshot.
I think we should try to reproduce this with other multithreaded
servers to check if it is a ZTS bug (I think it is one).
[2004-02-13 09:00:58] [EMAIL PROTECTED]
Same on PHP 4.3.5 RC2 of SunOS 5.9. Tried to debug it but the crashing
process did not create a core dump.
If somebody of the others helps this:
# /opt/forte7/SUNWspro/bin/dbx
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.0' in
your .dbxrc
(dbx) attach 9702
...
...
detected a multithreaded program
Attached to process 9702 with 90 LWPs
[EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in __lwp_park at 0xfe3e5f88
0xfe3e5f88: __lwp_park+0x0010: ta %icc,%g0 + 8
(dbx) cont
- here starting of crashing test2.php
[EMAIL PROTECTED] ([EMAIL PROTECTED]) signal SEGV (no mapping at the fault address) in
zend_clean_garbage at line 25 in file zend_execute_locks.h
25 while (EG(garbage_ptr)) {
dbx: read of 4 bytes at address ee2cf748 failed -- Error 0
(dbx) where
current thread: [EMAIL PROTECTED]
=[1] zend_clean_garbage(tsrm_ls = bad address 0xee2cf7dc), line 25
in zend_execute_locks.h
dbx: read of 4 bytes at address ee2cf7b8 failed -- Error 0
dbx: attempt to read frame failed -- cannot derive frame pointer
(dbx)
seems to be a TSRM problem because in CLI it does not appear. And crash
is not in NSAPI code.
[2004-02-13 03:42:22] herman at frontier dot nl
Sorry, forgot to mention: no, using the CLI (at least scripts #1 and
#2) they run OK.
[2004-02-12 20:52:26] [EMAIL PROTECTED]
Does it crash with PHP-CLI?
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/27231
--
Edit this bug report at http://bugs.php.net/?id=27231edit=1
#27384 [Csd]: Function unpack incorrectly works with string with just one char
ID: 27384
Updated by: [EMAIL PROTECTED]
Reported By: hayk at mail dot ru
Status: Closed
Bug Type: Strings related
Operating System: *
PHP Version: 4.3.4
New Comment:
And fix was merged to the stable branch too..
Previous Comments:
[2004-02-24 16:42:55] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
I see what you're saying now. This has been fixed in
HEAD.
[2004-02-24 15:42:38] hayk at mail dot ru
Why this code works fine?
?
$sp = chr(0x20);
$a = unpack('C2', $sp.$sp);
?
pre
? print_r($a); ?
/pre
We get:
Array
(
[1] = 32
[2] = 32
)
[2004-02-24 15:30:15] [EMAIL PROTECTED]
You're not using unpack correctly. The format string is
Type.Multiplicity.Name
Name cannot begin with or be a number, as it would be
impossible to distinguish multiplicty from name.
[2004-02-24 15:23:26] hayk at mail dot ru
I muddle up Expected and Actual results in the my submission.
[2004-02-24 15:17:55] hayk at mail dot ru
Description:
When the function unpack returns an array with just one element, it
doesn't have an index.
Reproduce code:
---
?
$sp = chr(0x20);
$a = unpack('C1', $sp);
?
pre
? print_r($a); ?
/pre
Expected result:
Array
(
[] = 32
)
Actual result:
--
Array
(
[1] = 32
)
--
Edit this bug report at http://bugs.php.net/?id=27384edit=1
#27392 [NEW]: with SSL connection filled forms become empty
From: php at as-n dot de Operating system: Linux PHP version: Irrelevant PHP Bug Type: Apache related Bug description: with SSL connection filled forms become empty Description: Hello, I run the oscommerce shop an have the problem, that a lot of filled in forms become empty when the form was send. Credit card information or order status update are empty but the customer has filled in this fileds. When I update an order I set the status from open to proccesing, but somethimes the shop changed the status to nothing, I only see a empty field. The same is when customers try to log in, the fill in the correct username and password but the shop doesn't accept it, maybe he sees only empty fields. I think this proplem is only with SSL and (maybe) with IE but I'm not shure. Reproduce code: --- [25/Feb/2004:08:46:02 +0100] POST /catalog/checkout_confirmation.php?osCsid=930b87aba4b795ddc9df4cfdba7facbb HTTP/1.1 200 53327 [25/Feb/2004:08:46:05 +0100] POST /catalog/checkout_process.php?osCsid=930b87aba4b795ddc9df4cfdba7facbb HTTP/1.1 302 5 [25/Feb/2004:08:46:05 +0100] GET /catalog/checkout_success.php?osCsid=930b87aba4b795ddc9df4cfdba7facbb HTTP/1.1 200 40505 [25/Feb/2004:08:46:07 +0100] banktransfer_blz=XXXbanktransfer_bankname=XXXbanktransfer_number=1251450413banktransfer_owner=XXXbanktransfer_status=banktransfer_prz=96banktransfer_fax=x=54y=14POST /catalog/checkout_success.php/action/update?osCsid=930b87aba4b795ddc9df4cfdba7facbb HTTP/1.1 302 5 [25/Feb/2004:08:46:08 +0100] x=40y=11GET /catalog/default.php?osCsid=930b87aba4b795ddc9df4cfdba7facbb HTTP/1.1 200 57589 -- Edit bug report at http://bugs.php.net/?id=27392edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27392r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27392r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27392r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27392r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27392r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27392r=needscript Try newer version: http://bugs.php.net/fix.php?id=27392r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27392r=support Expected behavior: http://bugs.php.net/fix.php?id=27392r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27392r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27392r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27392r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27392r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27392r=dst IIS Stability: http://bugs.php.net/fix.php?id=27392r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27392r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27392r=float
#27392 [Opn-Bgs]: with SSL connection filled forms become empty
ID: 27392 Updated by: [EMAIL PROTECTED] Reported By: php at as-n dot de -Status: Open +Status: Bogus Bug Type: Apache related Operating System: Linux PHP Version: Irrelevant New Comment: This is not a PHP bug. Its a known issue with latest security update for IE: http://www.microsoft.com/downloads/details.aspx?FamilyId=254EB128-5053-48A7-8526-BD38215C74B2displaylang=en Previous Comments: [2004-02-25 07:35:32] php at as-n dot de Description: Hello, I run the oscommerce shop an have the problem, that a lot of filled in forms become empty when the form was send. Credit card information or order status update are empty but the customer has filled in this fileds. When I update an order I set the status from open to proccesing, but somethimes the shop changed the status to nothing, I only see a empty field. The same is when customers try to log in, the fill in the correct username and password but the shop doesn't accept it, maybe he sees only empty fields. I think this proplem is only with SSL and (maybe) with IE but I'm not shure. Reproduce code: --- [25/Feb/2004:08:46:02 +0100] POST /catalog/checkout_confirmation.php?osCsid=930b87aba4b795ddc9df4cfdba7facbb HTTP/1.1 200 53327 [25/Feb/2004:08:46:05 +0100] POST /catalog/checkout_process.php?osCsid=930b87aba4b795ddc9df4cfdba7facbb HTTP/1.1 302 5 [25/Feb/2004:08:46:05 +0100] GET /catalog/checkout_success.php?osCsid=930b87aba4b795ddc9df4cfdba7facbb HTTP/1.1 200 40505 [25/Feb/2004:08:46:07 +0100] banktransfer_blz=XXXbanktransfer_bankname=XXXbanktransfer_number=1251450413banktransfer_owner=XXXbanktransfer_status=banktransfer_prz=96banktransfer_fax=x=54y=14POST /catalog/checkout_success.php/action/update?osCsid=930b87aba4b795ddc9df4cfdba7facbb HTTP/1.1 302 5 [25/Feb/2004:08:46:08 +0100] x=40y=11GET /catalog/default.php?osCsid=930b87aba4b795ddc9df4cfdba7facbb HTTP/1.1 200 57589 -- Edit this bug report at http://bugs.php.net/?id=27392edit=1
#27321 [Bgs-Opn]: open_basedir setting leaking between vhosts
ID: 27321 User updated by: jg at execulink dot com Reported By: jg at execulink dot com -Status: Bogus +Status: Open Bug Type: Apache related Operating System: Redhat Linux 7.3 -PHP Version: 4CVS-2004-2-19 +PHP Version: 4.3.5RC3 New Comment: Actually this is not a configuration problem, since the open_basedir it's complaining about is NOT the one I have configured for that vhost. Previous Comments: [2004-02-24 17:12:12] [EMAIL PROTECTED] This is some configuration failure on user's side: File(/usr/ppp/p/pookie/public_html/index.php) is not within the allowed path(s): (/usr/ppp/p/pdipietro) in Unknown on line 0 (this is perfectly valid and expected error when you try to access file outside the open_basedir..) [2004-02-20 08:06:22] jg at execulink dot com I'm using Apache/1.3.27 (Unix) (Red-Hat/Linux) I've already tried running this snapshot: php4-STABLE-200402191630 with no luck. [2004-02-19 13:57:04] jg at execulink dot com Description: INI Settings, specificially open_basedir seems to be leaking between apache virtualhost settings. Bug seems to be very similar to #25753, but was not resolved for me in 4.3.5RC3. e.g., One user - pookie's php fails with the following error: (pdipietro is another user on the system, in another virtualhost). I would really appreciate either a workaround, patch, or fix! phpinfo(); PHP Version 4.3.5RC3 Warning: Unknown(): open_basedir restriction in effect. File(/usr/ppp/p/pookie/public_html/index.php) is not within the allowed path(s): (/usr/ppp/p/pdipietro) in Unknown on line 0 Warning: Unknown(/usr/ppp/p/pookie/public_html/index.php): failed to open stream: Operation not permitted in Unknown on line 0 Warning: (null)(): Failed opening '/usr/ppp/p/pookie/public_html/index.php' for inclusion (include_path='.:/usr/share/pear') in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=27321edit=1
#27321 [Opn-Fbk]: open_basedir setting leaking between vhosts
ID: 27321 Updated by: [EMAIL PROTECTED] Reported By: jg at execulink dot com -Status: Open +Status: Feedback Bug Type: Apache related Operating System: Redhat Linux 7.3 PHP Version: 4.3.5RC3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2004-02-25 08:08:59] jg at execulink dot com Actually this is not a configuration problem, since the open_basedir it's complaining about is NOT the one I have configured for that vhost. [2004-02-24 17:12:12] [EMAIL PROTECTED] This is some configuration failure on user's side: File(/usr/ppp/p/pookie/public_html/index.php) is not within the allowed path(s): (/usr/ppp/p/pdipietro) in Unknown on line 0 (this is perfectly valid and expected error when you try to access file outside the open_basedir..) [2004-02-20 08:06:22] jg at execulink dot com I'm using Apache/1.3.27 (Unix) (Red-Hat/Linux) I've already tried running this snapshot: php4-STABLE-200402191630 with no luck. [2004-02-19 13:57:04] jg at execulink dot com Description: INI Settings, specificially open_basedir seems to be leaking between apache virtualhost settings. Bug seems to be very similar to #25753, but was not resolved for me in 4.3.5RC3. e.g., One user - pookie's php fails with the following error: (pdipietro is another user on the system, in another virtualhost). I would really appreciate either a workaround, patch, or fix! phpinfo(); PHP Version 4.3.5RC3 Warning: Unknown(): open_basedir restriction in effect. File(/usr/ppp/p/pookie/public_html/index.php) is not within the allowed path(s): (/usr/ppp/p/pdipietro) in Unknown on line 0 Warning: Unknown(/usr/ppp/p/pookie/public_html/index.php): failed to open stream: Operation not permitted in Unknown on line 0 Warning: (null)(): Failed opening '/usr/ppp/p/pookie/public_html/index.php' for inclusion (include_path='.:/usr/share/pear') in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=27321edit=1
#27393 [NEW]: syntax highlighter uses obsolete font
From: mg at iceni dot pl
Operating system: any
PHP version: Irrelevant
PHP Bug Type: Unknown/Other Function
Bug description: syntax highlighter uses obsolete font
Description:
syntax highlighter uses font which is removed in xhtml.
nl2br is already xhtml compilant so highlight_[string|
file] should be too.
Here is simple patch (for php4 and php5) which replaces
font with span
diff -u2 Zend/zend_highlight.c
Zend-patched/zend_highlight.c
--- Zend/zend_highlight.c 2004-01-08
18:31:47.0 +0100
+++ Zend-patched/zend_highlight.c 2004-02-25
14:17:41.154198944 +0100
@@ -106,5 +106,5 @@
zend_printf(code);
- zend_printf(font color=\%s\\n, last_color);
+ zend_printf(span style=\color: %s\\n,
last_color);
/* highlight stuff coming back from zendlex() */
token.type = 0;
@@ -150,9 +150,9 @@
if (last_color != next_color) {
if (last_color !=
syntax_highlighter_ini-highlight_html) {
- zend_printf(/font);
+ zend_printf(/span);
}
last_color = next_color;
if (last_color !=
syntax_highlighter_ini-highlight_html) {
- zend_printf(font
color=\%s\, last_color);
+ zend_printf(span
style=\color: %s\, last_color);
}
}
@@ -185,7 +185,7 @@
}
if (last_color !=
syntax_highlighter_ini-highlight_html) {
- zend_printf(/font\n);
+ zend_printf(/span\n);
}
- zend_printf(/font\n);
+ zend_printf(/span\n);
zend_printf(/code);
}
--
Edit bug report at http://bugs.php.net/?id=27393edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27393r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27393r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27393r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27393r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27393r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27393r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27393r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27393r=support
Expected behavior: http://bugs.php.net/fix.php?id=27393r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27393r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27393r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27393r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27393r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27393r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27393r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27393r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27393r=float
#27387 [Opn-Csd]: mySQL Support Missing from Latest Development Build
ID: 27387 Updated by: [EMAIL PROTECTED] Reported By: Wendell at thePinegars dot com -Status: Open +Status: Closed -Bug Type: *General Issues +Bug Type: MySQL related Operating System: Windows Server 2003 PHP Version: 5CVS-2004-02-24 (dev) New Comment: Should be fixed now. (try snapshot about 3 hours from now) Previous Comments: [2004-02-24 20:46:33] Wendell at thePinegars dot com Description: The extension php_mysql.dll is no longer included with the most recient development build of PHP 5.0.0. Please correct. Reproduce code: --- mySQL is not supported in the latested build of PHP 5.0.0. Expected result: mySQL should be included. -- Edit this bug report at http://bugs.php.net/?id=27387edit=1
#27386 [Opn-Bgs]: phpinfo() ./configure listing is incorrect
ID: 27386 Updated by: [EMAIL PROTECTED] Reported By: jon dot bertsch at ucop dot edu -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: Mac 10.3.2 PHP Version: 5.0.0b4 (beta4) New Comment: # make clean Previous Comments: [2004-02-24 18:11:24] jon dot bertsch at ucop dot edu Description: After compiling php and setting it up on the server I check that it's working using phpinfo(). After adding several new modules and recompiling I have a working version of PHP but the compile information in phpinfo() is incorrect. I deleted the config.cache and tried again, still wrong. Reproduce code: --- ./configure' '--prefix=/usr' '--disable-all' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-apxs' '--with-mysql=/usr/local/mysql' '--with-pear' '--with-ldap=/usr' '--with-kerberos=/usr' '--enable-cli' '--with-zlib-dir=/usr' '--enable-trans-sid' '--enable-exif' '--enable-ftp' '--enable-mbstring' '--enable-dbx' '--enable-sockets' '--with-iodbc=/usr' '--with-config-file-path=/etc' '--with-unixODBC' '--enable-xml' '--with-pcre-regex' Expected result: This is my actual compile script: '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/ bin' '--sbindir=/usr/sbin' '--with-config-file-path=/ usr/local/php5' '--sysconfdir=/etc' '--datadir=/usr/ share' '--includedir=/usr/include' '--libdir=/usr/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-apxs' '--with-mysql=/usr/local/mysql' '--with- pear' '--with-pcre-regex' '--with-ldap=/usr' '--with- kerberos=/usr' '--enable-cli' '--with-zlib-dir=/usr' '-- enable-trans-sid' '--enable-exif' '--enable-ftp' '-- enable-mbstring' '--enable-dbx' '--enable-sockets' '-- with-iodbc=/usr' '--with-unixODBC' '--with-libxml- dir=/usr/local' '--with-expat-dir=/usr/local/php5' '-- with-dom=/usr/local/php5' '--with-dom-xslt=/usr/local' '--with-dom-exslt=/usr/local' '--with-xslt-sablot=/usr/ local/php5' '--enable-xslt' '--with-ldap' '--with-gd' '--with-png-dir=/usr/local/libpng' '--with-jpeg=/usr' '--with-jpeg-dir=/usr/local/jpeg' Actual result: -- Modules/extensions such as sessions, xml, dom_xml, gd, libxml etc. are all up and running as expected and show in phpinfo() listing. It's reading some incorrect file or some cache somewhere is not getting overwritten I would guess. -- Edit this bug report at http://bugs.php.net/?id=27386edit=1
#27393 [Opn-Fbk]: syntax highlighter uses obsolete font
ID: 27393
Updated by: [EMAIL PROTECTED]
Reported By: mg at iceni dot pl
-Status: Open
+Status: Feedback
Bug Type: Unknown/Other Function
Operating System: any
PHP Version: Irrelevant
New Comment:
Please provide a link to the patch as it got garbled here.
Previous Comments:
[2004-02-25 08:21:02] mg at iceni dot pl
Description:
syntax highlighter uses font which is removed in xhtml.
nl2br is already xhtml compilant so highlight_[string|
file] should be too.
Here is simple patch (for php4 and php5) which replaces
font with span
diff -u2 Zend/zend_highlight.c
Zend-patched/zend_highlight.c
--- Zend/zend_highlight.c 2004-01-08
18:31:47.0 +0100
+++ Zend-patched/zend_highlight.c 2004-02-25
14:17:41.154198944 +0100
@@ -106,5 +106,5 @@
zend_printf(code);
- zend_printf(font color=\%s\\n, last_color);
+ zend_printf(span style=\color: %s\\n,
last_color);
/* highlight stuff coming back from zendlex() */
token.type = 0;
@@ -150,9 +150,9 @@
if (last_color != next_color) {
if (last_color !=
syntax_highlighter_ini-highlight_html) {
- zend_printf(/font);
+ zend_printf(/span);
}
last_color = next_color;
if (last_color !=
syntax_highlighter_ini-highlight_html) {
- zend_printf(font
color=\%s\, last_color);
+ zend_printf(span
style=\color: %s\, last_color);
}
}
@@ -185,7 +185,7 @@
}
if (last_color !=
syntax_highlighter_ini-highlight_html) {
- zend_printf(/font\n);
+ zend_printf(/span\n);
}
- zend_printf(/font\n);
+ zend_printf(/span\n);
zend_printf(/code);
}
--
Edit this bug report at http://bugs.php.net/?id=27393edit=1
#27393 [Fbk-Opn]: syntax highlighter uses obsolete font
ID: 27393
User updated by: mg at iceni dot pl
Reported By: mg at iceni dot pl
-Status: Feedback
+Status: Open
Bug Type: Unknown/Other Function
Operating System: any
PHP Version: Irrelevant
New Comment:
http://iceni.pl/highlight.patch
Previous Comments:
[2004-02-25 08:32:37] [EMAIL PROTECTED]
Please provide a link to the patch as it got garbled here.
[2004-02-25 08:21:02] mg at iceni dot pl
Description:
syntax highlighter uses font which is removed in xhtml.
nl2br is already xhtml compilant so highlight_[string|
file] should be too.
Here is simple patch (for php4 and php5) which replaces
font with span
diff -u2 Zend/zend_highlight.c
Zend-patched/zend_highlight.c
--- Zend/zend_highlight.c 2004-01-08
18:31:47.0 +0100
+++ Zend-patched/zend_highlight.c 2004-02-25
14:17:41.154198944 +0100
@@ -106,5 +106,5 @@
zend_printf(code);
- zend_printf(font color=\%s\\n, last_color);
+ zend_printf(span style=\color: %s\\n,
last_color);
/* highlight stuff coming back from zendlex() */
token.type = 0;
@@ -150,9 +150,9 @@
if (last_color != next_color) {
if (last_color !=
syntax_highlighter_ini-highlight_html) {
- zend_printf(/font);
+ zend_printf(/span);
}
last_color = next_color;
if (last_color !=
syntax_highlighter_ini-highlight_html) {
- zend_printf(font
color=\%s\, last_color);
+ zend_printf(span
style=\color: %s\, last_color);
}
}
@@ -185,7 +185,7 @@
}
if (last_color !=
syntax_highlighter_ini-highlight_html) {
- zend_printf(/font\n);
+ zend_printf(/span\n);
}
- zend_printf(/font\n);
+ zend_printf(/span\n);
zend_printf(/code);
}
--
Edit this bug report at http://bugs.php.net/?id=27393edit=1
#27393 [Opn-Csd]: syntax highlighter uses obsolete font
ID: 27393
Updated by: [EMAIL PROTECTED]
Reported By: mg at iceni dot pl
-Status: Open
+Status: Closed
Bug Type: Unknown/Other Function
Operating System: any
PHP Version: Irrelevant
New Comment:
Thanks, I committed this for PHP 5. (But not for PHP 4 as that one is
in a bugfix only cycle).
Previous Comments:
[2004-02-25 08:47:12] mg at iceni dot pl
http://iceni.pl/highlight.patch
[2004-02-25 08:32:37] [EMAIL PROTECTED]
Please provide a link to the patch as it got garbled here.
[2004-02-25 08:21:02] mg at iceni dot pl
Description:
syntax highlighter uses font which is removed in xhtml.
nl2br is already xhtml compilant so highlight_[string|
file] should be too.
Here is simple patch (for php4 and php5) which replaces
font with span
diff -u2 Zend/zend_highlight.c
Zend-patched/zend_highlight.c
--- Zend/zend_highlight.c 2004-01-08
18:31:47.0 +0100
+++ Zend-patched/zend_highlight.c 2004-02-25
14:17:41.154198944 +0100
@@ -106,5 +106,5 @@
zend_printf(code);
- zend_printf(font color=\%s\\n, last_color);
+ zend_printf(span style=\color: %s\\n,
last_color);
/* highlight stuff coming back from zendlex() */
token.type = 0;
@@ -150,9 +150,9 @@
if (last_color != next_color) {
if (last_color !=
syntax_highlighter_ini-highlight_html) {
- zend_printf(/font);
+ zend_printf(/span);
}
last_color = next_color;
if (last_color !=
syntax_highlighter_ini-highlight_html) {
- zend_printf(font
color=\%s\, last_color);
+ zend_printf(span
style=\color: %s\, last_color);
}
}
@@ -185,7 +185,7 @@
}
if (last_color !=
syntax_highlighter_ini-highlight_html) {
- zend_printf(/font\n);
+ zend_printf(/span\n);
}
- zend_printf(/font\n);
+ zend_printf(/span\n);
zend_printf(/code);
}
--
Edit this bug report at http://bugs.php.net/?id=27393edit=1
#27364 [Bgs-Opn]: safe mode bypassed
ID: 27364 User updated by: support at nfrance dot com Reported By: support at nfrance dot com -Status: Bogus +Status: Open Bug Type: *Directory/Filesystem functions Operating System: OpenBSD/FreeBSD PHP Version: Irrelevant New Comment: Of course the problem seems to be environment-dependent, but should not PHP return an error in such situation when not able to get enough information on a directory owner instead of opening the file even with safe mode ? Previous Comments: [2004-02-24 17:07:42] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. I cannot verify this problem on Linux and it could not be verified on FreeBSD 4.9 by the people I've asked. The only reason I would imagine this would happen is if your OS would refuse to allow PHP to stat the directory where the file is located. [2004-02-23 10:36:39] support at nfrance dot com Description: When changing permissions on a directory safe mode restrictions for php scripts in this directory can be bypassed When directory in chmod 755 safe mode works as exepted, bot not anymore in chmod 751 (note that php run as apache module ans /etc/passwd is of course not owned by the same user as apache is running) This has been seen on 3 differents servers, 2 with OpenBSD and one with FreeBSD Tested with PHP 4.2.2 with follonwing configure commands : './configure' '--enable-safe-mode' '--enable-memory-limit' '--with-pgsql=/usr/local/pgsql/' '--with- mysql=/usr/local' '--with-imagic' '--enable-track-vars' '--with-imap=/usr/local/src/imap-2001a' '--with- gd=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-t1lib' '--with-ttf' '-- enable-magic-quotes' '--enable-roxen-zts' '--enable-ftp' '--enable-calendar' '--with-gdbm' '-- enable-zlib=/usr' '--with-gettext' '--with-xml' '--with-dom' '--with-zlib-dir=/usr' '--enable-bcmath' '--with-apache=/usr/local/src/apache_1.3.27' Tested again after having upgraded to PHP 4.3.4 (and having upgraded apache too) with a clean php.ini and the bug is still active However, we've tested on others FreeBSD servers with the same PHP version without any problem. Of course configuration was different ont those servers, but it is not normal that safe mode can be bypassed so easily whatever the environment. Please advise ! Reproduce code: --- ? $fp = fopen(/etc/passwd,r); $data = fgets($fp,255); echo $dataBR; fclose($fp); ? (bug has been see with readfile() too) Expected result: Current directory permissions : drwxr-xr-x 2 fred fred 512 Feb 17 10:58 . Result : Warning: SAFE MODE Restriction in effect. The script whose uid is 1003 is not allowed to access /etc/passwd owned by uid 0 in /home/fred/ test/etcpasswd.php on line 3 Warning: fopen(/etc/passwd, r) - Inappropriate ioctl for device in /home/fred/test/etcpasswd.php on line 3 Warning: fgets(): supplied argument is not a valid File-Handle resource in /home/fred/test/etcpasswd.php on line 5 Warning: fclose(): supplied argument is not a valid File-Handle resource in /home/fred/test/etcpasswd.php on line 9 Actual result: -- Current directory permissions (noting else changed) : drwxr-x--x 2 fred fred 512 Feb 17 10:58 . Result : # $FreeBSD: src/etc/master.passwd,v 1.25.2.5 2002/02/10 11:43:37 obrien Exp $ -- Edit this bug report at http://bugs.php.net/?id=27364edit=1
#27364 [Opn-Bgs]: safe mode bypassed
ID: 27364 Updated by: [EMAIL PROTECTED] Reported By: support at nfrance dot com -Status: Open +Status: Bogus Bug Type: *Directory/Filesystem functions Operating System: OpenBSD/FreeBSD PHP Version: Irrelevant New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Allowing access to directories about which PHP cannot determine information would be contrary to the whole concept of safe mode. If your system has a (strange) limitation of disallowing stat() of directories with just an executable bit set make sure the read bit is also set. Previous Comments: [2004-02-25 09:12:21] support at nfrance dot com Of course the problem seems to be environment-dependent, but should not PHP return an error in such situation when not able to get enough information on a directory owner instead of opening the file even with safe mode ? [2004-02-24 17:07:42] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. I cannot verify this problem on Linux and it could not be verified on FreeBSD 4.9 by the people I've asked. The only reason I would imagine this would happen is if your OS would refuse to allow PHP to stat the directory where the file is located. [2004-02-23 10:36:39] support at nfrance dot com Description: When changing permissions on a directory safe mode restrictions for php scripts in this directory can be bypassed When directory in chmod 755 safe mode works as exepted, bot not anymore in chmod 751 (note that php run as apache module ans /etc/passwd is of course not owned by the same user as apache is running) This has been seen on 3 differents servers, 2 with OpenBSD and one with FreeBSD Tested with PHP 4.2.2 with follonwing configure commands : './configure' '--enable-safe-mode' '--enable-memory-limit' '--with-pgsql=/usr/local/pgsql/' '--with- mysql=/usr/local' '--with-imagic' '--enable-track-vars' '--with-imap=/usr/local/src/imap-2001a' '--with- gd=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-t1lib' '--with-ttf' '-- enable-magic-quotes' '--enable-roxen-zts' '--enable-ftp' '--enable-calendar' '--with-gdbm' '-- enable-zlib=/usr' '--with-gettext' '--with-xml' '--with-dom' '--with-zlib-dir=/usr' '--enable-bcmath' '--with-apache=/usr/local/src/apache_1.3.27' Tested again after having upgraded to PHP 4.3.4 (and having upgraded apache too) with a clean php.ini and the bug is still active However, we've tested on others FreeBSD servers with the same PHP version without any problem. Of course configuration was different ont those servers, but it is not normal that safe mode can be bypassed so easily whatever the environment. Please advise ! Reproduce code: --- ? $fp = fopen(/etc/passwd,r); $data = fgets($fp,255); echo $dataBR; fclose($fp); ? (bug has been see with readfile() too) Expected result: Current directory permissions : drwxr-xr-x 2 fred fred 512 Feb 17 10:58 . Result : Warning: SAFE MODE Restriction in effect. The script whose uid is 1003 is not allowed to access /etc/passwd owned by uid 0 in /home/fred/ test/etcpasswd.php on line 3 Warning: fopen(/etc/passwd, r) - Inappropriate ioctl for device in /home/fred/test/etcpasswd.php on line 3 Warning: fgets(): supplied argument is not a valid File-Handle resource in /home/fred/test/etcpasswd.php on line 5 Warning: fclose(): supplied argument is not a valid File-Handle resource in /home/fred/test/etcpasswd.php on line 9 Actual result: -- Current directory permissions (noting else changed) : drwxr-x--x 2 fred fred 512 Feb 17 10:58 . Result : # $FreeBSD: src/etc/master.passwd,v 1.25.2.5 2002/02/10 11:43:37 obrien Exp $ -- Edit this bug report at http://bugs.php.net/?id=27364edit=1
#27394 [NEW]: specific array in session causes data not to store
From: rob_raux at redkeysolutions dot com
Operating system: Linux 2.4.18-14
PHP version: 4.3.4
PHP Bug Type: Session related
Bug description: specific array in session causes data not to store
Description:
My apologies if this is a dup, I've searched and searched and found
nothing.
php.ini [relevant]:
session.save_handler = files
session.save_path = /tmp
session.use_cookies = 1
session.use_only_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.serialize_handler = php
As commented in the code, the $_SESSION variable is not correctly set when
both $array[1] and $array['string'] are set.
Reproduce code:
---
?php
session_start();
//this is our goal, to get here.
if(isset($_SESSION['allSet'])){
print_r($_SESSION);
session_destroy();
}
//start the test.
else{
/* this numeric key creates the problem.
commented out $basic_array[0] = 4; and this code will work fine,
otherwise we have an infinite redirect. */
$basic_array[1] = 4;
$basic_array['user_id'] = 4;
$basic_array['email'] = [EMAIL PROTECTED];
foreach(array_keys($basic_array) AS $key){
$_SESSION[$key] = $basic_array[$key];
}
$_SESSION['allSet'] = 1;
header(Location: http://FULLPATHTOSERVER/LOGINTEST.php;);
}
Expected result:
The $_SESSION variable should contain all the relevant data.
Actual result:
--
$_SESSION contains no data, despite being set.
--
Edit bug report at http://bugs.php.net/?id=27394edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27394r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27394r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27394r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27394r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27394r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27394r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27394r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27394r=support
Expected behavior: http://bugs.php.net/fix.php?id=27394r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27394r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27394r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27394r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27394r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27394r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27394r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27394r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27394r=float
#25962 [Com]: php connect informix database caused memory leak
ID: 25962 Comment by: ht at eucomp dot net Reported By: liu-shan at mediaring dot com Status: No Feedback Bug Type: Informix related Operating System: sun PHP Version: 4.3.2 New Comment: The same memory leak bug is experienced using InformixphpAppacheLinux. httpd does not release all the allocated memory and the its size is growing and growing running in ENVIRONMENT: PHP Version 4.3.2 (Apache module) on SuSE/Linux 7.3 kernel version 2.4.10-4GB Apache/1.3.12 (Unix) (SuSE/Linux) Informix ESQL/C Version 9.16 Informix Dynamic Server Version 7.31.UD2-- On-Line + It is also reported with PHP 4.3.3 however !!! PHP 4.1.2 is working properly Previous Comments: [2003-11-03 14:08:04] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2003-10-27 10:50:34] [EMAIL PROTECTED] Provide a SHORT and COMPLETE example script. Anything over 20 lines is not accepted. [2003-10-23 04:40:54] liu-shan at mediaring dot com Description: I'm PHP programer, I write web application using PHP connect to informix database, informix CSDK version 2.7.1, no matter I SELECT, INSERT OR UPDATE data to database, once program exit, but memory still that, cannot release. it cause os memory leak, I have to reboot server frequently. How can I resolve this problem -- Edit this bug report at http://bugs.php.net/?id=25962edit=1
#27364 [Bgs-Opn]: safe mode bypassed
ID: 27364 User updated by: support at nfrance dot com Reported By: support at nfrance dot com -Status: Bogus +Status: Open Bug Type: *Directory/Filesystem functions Operating System: OpenBSD/FreeBSD PHP Version: Irrelevant New Comment: Allowing access to directories about which PHP cannot determine information would be contrary to the whole concept of safe mode. That's *exactly* the problem here : even with safe mode files can be opened on those servers when permissions are set too low on the current directory if your system has a (strange) limitation of disallowing stat() of directories with just an executable bit set make sure the read bit is also set. For your Information, we've jsut checked the stat() function and it works as expected in both situations. But even if it is an unexepected environment which prevent fopen() and others file-handling functions to check the uid/gid depending on permissions on directories, don't you think that there should be, when safe mode is active, en error in such situation ? If it happen on some of ours servers, it can happen on others too, and a simple error check should be able to prevent this potential security hole for all users In fact there's some others bugs report that could be about the same problem or similar : http://bugs.php.net/bug.php?id=19363 http://bugs.php.net/bug.php?id=22368 http://bugs.php.net/bug.php?id=24304 We can provide more informations on our environment if you wish, and perform any test needed Previous Comments: [2004-02-25 10:02:32] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Allowing access to directories about which PHP cannot determine information would be contrary to the whole concept of safe mode. If your system has a (strange) limitation of disallowing stat() of directories with just an executable bit set make sure the read bit is also set. [2004-02-25 09:12:21] support at nfrance dot com Of course the problem seems to be environment-dependent, but should not PHP return an error in such situation when not able to get enough information on a directory owner instead of opening the file even with safe mode ? [2004-02-24 17:07:42] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. I cannot verify this problem on Linux and it could not be verified on FreeBSD 4.9 by the people I've asked. The only reason I would imagine this would happen is if your OS would refuse to allow PHP to stat the directory where the file is located. [2004-02-23 10:36:39] support at nfrance dot com Description: When changing permissions on a directory safe mode restrictions for php scripts in this directory can be bypassed When directory in chmod 755 safe mode works as exepted, bot not anymore in chmod 751 (note that php run as apache module ans /etc/passwd is of course not owned by the same user as apache is running) This has been seen on 3 differents servers, 2 with OpenBSD and one with FreeBSD Tested with PHP 4.2.2 with follonwing configure commands : './configure' '--enable-safe-mode' '--enable-memory-limit' '--with-pgsql=/usr/local/pgsql/' '--with- mysql=/usr/local' '--with-imagic' '--enable-track-vars' '--with-imap=/usr/local/src/imap-2001a' '--with- gd=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-t1lib' '--with-ttf' '-- enable-magic-quotes' '--enable-roxen-zts' '--enable-ftp' '--enable-calendar' '--with-gdbm' '-- enable-zlib=/usr' '--with-gettext' '--with-xml' '--with-dom' '--with-zlib-dir=/usr' '--enable-bcmath' '--with-apache=/usr/local/src/apache_1.3.27' Tested again after having upgraded to PHP 4.3.4 (and having upgraded apache too) with a clean php.ini and the bug is still active However, we've tested on others FreeBSD servers with the same PHP version without any problem. Of course configuration was different ont those servers, but it is not normal that safe mode can be bypassed so easily whatever the environment. Please advise ! Reproduce code: --- ? $fp = fopen(/etc/passwd,r); $data = fgets($fp,255); echo $dataBR; fclose($fp); ? (bug has been see
#27395 [NEW]: arrays cannot be passed by value
From: jamesn at tocquigny dot com
Operating system: redhat linux
PHP version: 4.3.4
PHP Bug Type: Scripting Engine problem
Bug description: arrays cannot be passed by value
Description:
There appears to be a problem with php that doesn't allow arrays to be
passed by value. The fix appears to be something similar to:
http://bugs.php.net/bug.php?id=6417
if (PZVAL_IS_REF(*p))
{
SEPARATE_ZVAL(p);
} else {
zval_add_ref(p);
}
It would appear that that logic is missing in one place or another. I
could not track it down myself. Code similar to this appears to be
copy/pasted in various places.
Reproduce code:
---
$array = array(1);
// This line makes the call to theFunction() act as if passed by ref.?
$reference = $array[0];
echo $array[0], 'br';
theFunction($array);
echo $array[0], 'br';
function theFunction($array) {
$array[0] = 2;
}
Expected result:
you should get 1 and 1
Actual result:
--
instead you get 1 and 2!
--
Edit bug report at http://bugs.php.net/?id=27395edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27395r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27395r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27395r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27395r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27395r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27395r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27395r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27395r=support
Expected behavior: http://bugs.php.net/fix.php?id=27395r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27395r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27395r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27395r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27395r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27395r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27395r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27395r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27395r=float
#27388 [Com]: complete compatibility check in E_STRICT mode
ID: 27388 Comment by: papercrane at reversefold dot com Reported By: agl at xs4all dot nl Status: Wont fix Bug Type: Feature/Change Request Operating System: * PHP Version: 5.0.0b4 (beta4) New Comment: Does the compatibility mode show when old semantics are used? If not, this bug is still valid IMHO. People need a way to find incompatibilities between PHP4 code and PHP5 without having to eyeball everything or hunt down obscure errors. Previous Comments: [2004-02-25 03:26:52] [EMAIL PROTECTED] There is a compatibility mode that allows implicit object cloning as PHP 4 did, so this does not fit into E_STRICT. [2004-02-24 23:15:36] agl at xs4all dot nl Description: Background: People need a migration path from PHP4 to PHP5. Some things that work in PHP5 won't work in PHP5, or work differently. PHP5 has an E_STRICT setting, which catches many of these issues. They can be logged, so a dev can enable this, go through their log for a while, until it stays empty Then their app should be relatively clean. Issue: Not all situations are checked. They need to be, otherwise the migration path is still not clear. For instance a pass-object-by-value which is allowed in PHP4 simply ends up being a pass-object-by-reference in PHP5. I would suggest that with E_STRICT enabled, PHP5 should issue a warning if no $obj is specified. Yes this is slightly ugly and perhaps there are nicer solutions possible. I'm merely pointing out the need to address the migration issue. All of it, not 90%. 90% is not enough for the real world. There are very big PHP apps out there, and just having people dig through all code hoping to spot all issues is unrealistic. Thanks. -- Edit this bug report at http://bugs.php.net/?id=27388edit=1
#27394 [Opn-Bgs]: specific array in session causes data not to store
ID: 27394
Updated by: [EMAIL PROTECTED]
Reported By: rob_raux at redkeysolutions dot com
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: Linux 2.4.18-14
PHP Version: 4.3.4
New Comment:
RTFM:
The keys in the $_SESSION associative array are subject to the same
limitations as regular variable names in PHP, i.e. they cannot start
with a number and must start with a letter or underscore.
Previous Comments:
[2004-02-25 10:04:36] rob_raux at redkeysolutions dot com
Description:
My apologies if this is a dup, I've searched and searched and found
nothing.
php.ini [relevant]:
session.save_handler = files
session.save_path = /tmp
session.use_cookies = 1
session.use_only_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.serialize_handler = php
As commented in the code, the $_SESSION variable is not correctly set
when both $array[1] and $array['string'] are set.
Reproduce code:
---
?php
session_start();
//this is our goal, to get here.
if(isset($_SESSION['allSet'])){
print_r($_SESSION);
session_destroy();
}
//start the test.
else{
/* this numeric key creates the problem.
commented out $basic_array[0] = 4; and this code will work fine,
otherwise we have an infinite redirect. */
$basic_array[1] = 4;
$basic_array['user_id'] = 4;
$basic_array['email'] = [EMAIL PROTECTED];
foreach(array_keys($basic_array) AS $key){
$_SESSION[$key] = $basic_array[$key];
}
$_SESSION['allSet'] = 1;
header(Location: http://FULLPATHTOSERVER/LOGINTEST.php;);
}
Expected result:
The $_SESSION variable should contain all the relevant data.
Actual result:
--
$_SESSION contains no data, despite being set.
--
Edit this bug report at http://bugs.php.net/?id=27394edit=1
#27395 [Com]: arrays cannot be passed by value
ID: 27395
Comment by: papercrane at reversefold dot com
Reported By: jamesn at tocquigny dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: redhat linux
PHP Version: 4.3.4
New Comment:
I think you meant:
function theFunction($array)
Even with the it still won't work for me.
Previous Comments:
[2004-02-25 12:02:02] jamesn at tocquigny dot com
Description:
There appears to be a problem with php that doesn't allow arrays to be
passed by value. The fix appears to be something similar to:
http://bugs.php.net/bug.php?id=6417
if (PZVAL_IS_REF(*p))
{
SEPARATE_ZVAL(p);
} else {
zval_add_ref(p);
}
It would appear that that logic is missing in one place or another. I
could not track it down myself. Code similar to this appears to be
copy/pasted in various places.
Reproduce code:
---
$array = array(1);
// This line makes the call to theFunction() act as if passed by ref.?
$reference = $array[0];
echo $array[0], 'br';
theFunction($array);
echo $array[0], 'br';
function theFunction($array) {
$array[0] = 2;
}
Expected result:
you should get 1 and 1
Actual result:
--
instead you get 1 and 2!
--
Edit this bug report at http://bugs.php.net/?id=27395edit=1
#27395 [Opn-Bgs]: arrays cannot be passed by value
ID: 27395
Updated by: [EMAIL PROTECTED]
Reported By: jamesn at tocquigny dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: redhat linux
PHP Version: 4.3.4
New Comment:
It works exactly how it's supposed to work.
Previous Comments:
[2004-02-25 12:36:13] papercrane at reversefold dot com
I think you meant:
function theFunction($array)
Even with the it still won't work for me.
[2004-02-25 12:02:02] jamesn at tocquigny dot com
Description:
There appears to be a problem with php that doesn't allow arrays to be
passed by value. The fix appears to be something similar to:
http://bugs.php.net/bug.php?id=6417
if (PZVAL_IS_REF(*p))
{
SEPARATE_ZVAL(p);
} else {
zval_add_ref(p);
}
It would appear that that logic is missing in one place or another. I
could not track it down myself. Code similar to this appears to be
copy/pasted in various places.
Reproduce code:
---
$array = array(1);
// This line makes the call to theFunction() act as if passed by ref.?
$reference = $array[0];
echo $array[0], 'br';
theFunction($array);
echo $array[0], 'br';
function theFunction($array) {
$array[0] = 2;
}
Expected result:
you should get 1 and 1
Actual result:
--
instead you get 1 and 2!
--
Edit this bug report at http://bugs.php.net/?id=27395edit=1
#25118 [Com]: ODBC: can't store data in blob fields
ID: 25118 Comment by: jerome dot dury at cegedim dot fr Reported By: php at jschreiber dot com Status: Verified Bug Type: Feature/Change Request Operating System: GNU/Linux (Gentoo) PHP Version: 4.3.2 New Comment: Hello, I don't think this is really not useful, because we're trying to build a php script to insert blobs in a DB2 database. Our solution was pretty robust : it was to re-use some php objects and their relative methods that we implement in our php web site, in our back-office procedures... Because of this bug we are forced to rewrite our procedures with perl-dbi or visual basic, which provides blobs insertions. Are you planning to fix this bug ? Or do you leave it like this ? Thanks Jérome Previous Comments: [2003-10-22 19:46:59] [EMAIL PROTECTED] Marking this as a verified bug, in the sense that I know it exists. BLOB support in the ODBC system as it stands is relativly, umm, not useful. I haven't a good solution to this right now though. [2003-09-08 19:09:47] php at jschreiber dot com I looked at my last trace one more time and saw that SQLBindParameter( hStmt=1:1, iPar=1, fParamType=SQL_PARAM_INPUT, fCType=SQL_C_CHAR, fSQLType=SQL_BLOB, cbColDef=1048576, ibScale=0, rgbValue=000a, cbValueM ax=0, pcbValue=0820563c ) --- Time elapsed - +6.81E-004 seconds is being called with fCType=SQL_C_CHAR instead of SQL_BINARY. So I applied a part of Clara Lius patch to the code and changed the line containg SQL_LEN_DATA_AT_EXEC as described in my last comment. Now my blobtest script runs fine!! But the problem seems not to be totally solved - the odbc-test that comes with php seems to hang on some statements--sometimes it works, sometimes not... Anyway, I think that was a step in the right direction, so here is my patch: http://www.jschreiber.com/php/blobtest/blob-patch.txt Jan [2003-08-28 05:02:05] php at jschreiber dot com Sorry, guys...! It still doesn't work. I tried it with my blobtest (http://www.jschreiber.com/php/blobtest/). the insert statement gets executed, but the blob only contains an empty value (x''). I uploaded a new db2 trace to http://www.jschreiber.com/php/blobtest/db2trace_new.txt I hope that helps you!! Again, thank you for trying to fix that. Jan [2003-08-17 13:17:30] php at jschreiber dot com Description: I have a problem concerning BLOB fields and DB/2 V8.1.2. When I try to store a file with odbc_prepare() and odbc_execute($stmt, $params) no error code is returned, but the BLOB contains an empty value (x'', not a NULL value). I had this bug since I upgraded from DB/2 7.1 to DB/2 8.1 (and DB/2 8.1.2 as well). It's not a programming error--all script were working with DB/2 7.1. It even occurs with the odbc-test included in tests/ directory of the php source distribution. I tried all tricks mentioned at http://www7b.software.ibm.com/dmdd/library/techarticle/0301liu/0301liu.html but without success. Reproduce code: --- odbc-t5.php from the tests/ directory of the php source distribution. Expected result: Actual result: -- This is the output: --- snip --- ODBC Test 5 - Blobs Connecting to test as db2inst1 - OK Dropping table php_test - OK Creating table php_test: - OK Table Info: Name Type Length ID CHAR 32 GIF BLOB 10 Inserting data: /tmp/phpnyprAM - - - OK --- snap --- It looks like everythings works fine, but the the database contains just image1 and x''. -- Edit this bug report at http://bugs.php.net/?id=25118edit=1
#27395 [Bgs-Opn]: arrays cannot be passed by value
ID: 27395
User updated by: jamesn at tocquigny dot com
Reported By: jamesn at tocquigny dot com
-Status: Bogus
+Status: Open
Bug Type: Scripting Engine problem
Operating System: redhat linux
PHP Version: 4.3.4
New Comment:
in response to papercrane, no i didn't mean
function theFunction($array)
(this would pass by reference...by default php is doing this)
By flagging my bug as bogus are you stating the proper behavior is to
always pass by reference? (Which isn't proper at all IMO nor that of
coworkers or anyone that's worked w/ c/c++)
Previous Comments:
[2004-02-25 12:41:15] [EMAIL PROTECTED]
It works exactly how it's supposed to work.
[2004-02-25 12:36:13] papercrane at reversefold dot com
I think you meant:
function theFunction($array)
Even with the it still won't work for me.
[2004-02-25 12:02:02] jamesn at tocquigny dot com
Description:
There appears to be a problem with php that doesn't allow arrays to be
passed by value. The fix appears to be something similar to:
http://bugs.php.net/bug.php?id=6417
if (PZVAL_IS_REF(*p))
{
SEPARATE_ZVAL(p);
} else {
zval_add_ref(p);
}
It would appear that that logic is missing in one place or another. I
could not track it down myself. Code similar to this appears to be
copy/pasted in various places.
Reproduce code:
---
$array = array(1);
// This line makes the call to theFunction() act as if passed by ref.?
$reference = $array[0];
echo $array[0], 'br';
theFunction($array);
echo $array[0], 'br';
function theFunction($array) {
$array[0] = 2;
}
Expected result:
you should get 1 and 1
Actual result:
--
instead you get 1 and 2!
--
Edit this bug report at http://bugs.php.net/?id=27395edit=1
#27395 [Opn]: arrays cannot be passed by value
ID: 27395
User updated by: jamesn at tocquigny dot com
Reported By: jamesn at tocquigny dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: redhat linux
PHP Version: 4.3.4
New Comment:
further:
removing $reference = $array[0];
from the code causes the array to be passed by value...this is the bug
i'm concerned about.
Previous Comments:
[2004-02-25 12:56:51] jamesn at tocquigny dot com
in response to papercrane, no i didn't mean
function theFunction($array)
(this would pass by reference...by default php is doing this)
By flagging my bug as bogus are you stating the proper behavior is to
always pass by reference? (Which isn't proper at all IMO nor that of
coworkers or anyone that's worked w/ c/c++)
[2004-02-25 12:41:15] [EMAIL PROTECTED]
It works exactly how it's supposed to work.
[2004-02-25 12:36:13] papercrane at reversefold dot com
I think you meant:
function theFunction($array)
Even with the it still won't work for me.
[2004-02-25 12:02:02] jamesn at tocquigny dot com
Description:
There appears to be a problem with php that doesn't allow arrays to be
passed by value. The fix appears to be something similar to:
http://bugs.php.net/bug.php?id=6417
if (PZVAL_IS_REF(*p))
{
SEPARATE_ZVAL(p);
} else {
zval_add_ref(p);
}
It would appear that that logic is missing in one place or another. I
could not track it down myself. Code similar to this appears to be
copy/pasted in various places.
Reproduce code:
---
$array = array(1);
// This line makes the call to theFunction() act as if passed by ref.?
$reference = $array[0];
echo $array[0], 'br';
theFunction($array);
echo $array[0], 'br';
function theFunction($array) {
$array[0] = 2;
}
Expected result:
you should get 1 and 1
Actual result:
--
instead you get 1 and 2!
--
Edit this bug report at http://bugs.php.net/?id=27395edit=1
#27396 [NEW]: Can't Enable register_globals in Windows
From: bernardino_lopez at yahoo dot com Operating system: Windows 2000 PHP version: 4.3.5RC3 PHP Bug Type: Session related Bug description: Can't Enable register_globals in Windows Description: After Install PHP in Windows 2000, with Apache 2 and MySQL noticed a problem with Register_Globals. Warning: Unknown(): Your script possibly relies on a session side-effect which existed until PHP 4.2.3. Please be advised that the session extension does not consider global variables as a source of data, unless register_globals is enabled. You can disable this functionality and this warning by setting session.bug_compat_42 or session.bug_compat_warn to off, respectively. in Unknown on line 0 This is trying to create a MySQL Based session managment, when I modified the c:\winnt\system32\php.ini to modify register_globals On = Nothing seems to happen Reproduce code: --- ? # mysession.php Is the MySQL Based Session Management just # like SourceForge Require require mysession.php; echo hr; echo Page2 ; echo br Register Dino ; session_register(dino); $dino=Bernardino Lopez; echo hr; ? Expected result: Expected a successfull creation of a Record in the mysession table which means is a Custom Session. Actual result: -- Error on the page, no Session Variable is able to be declared and managed properly. Seems like no session support at all with the MySQL based session system -- Edit bug report at http://bugs.php.net/?id=27396edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27396r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27396r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27396r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27396r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27396r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27396r=needscript Try newer version: http://bugs.php.net/fix.php?id=27396r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27396r=support Expected behavior: http://bugs.php.net/fix.php?id=27396r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27396r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27396r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27396r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27396r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27396r=dst IIS Stability: http://bugs.php.net/fix.php?id=27396r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27396r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27396r=float
#27396 [Opn-Bgs]: Can't Enable register_globals in Windows
ID: 27396 Updated by: [EMAIL PROTECTED] Reported By: bernardino_lopez at yahoo dot com -Status: Open +Status: Bogus Bug Type: Session related Operating System: Windows 2000 PHP Version: 4.3.5RC3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. . Previous Comments: [2004-02-25 12:59:41] bernardino_lopez at yahoo dot com Description: After Install PHP in Windows 2000, with Apache 2 and MySQL noticed a problem with Register_Globals. Warning: Unknown(): Your script possibly relies on a session side-effect which existed until PHP 4.2.3. Please be advised that the session extension does not consider global variables as a source of data, unless register_globals is enabled. You can disable this functionality and this warning by setting session.bug_compat_42 or session.bug_compat_warn to off, respectively. in Unknown on line 0 This is trying to create a MySQL Based session managment, when I modified the c:\winnt\system32\php.ini to modify register_globals On = Nothing seems to happen Reproduce code: --- ? # mysession.php Is the MySQL Based Session Management just # like SourceForge Require require mysession.php; echo hr; echo Page2 ; echo br Register Dino ; session_register(dino); $dino=Bernardino Lopez; echo hr; ? Expected result: Expected a successfull creation of a Record in the mysession table which means is a Custom Session. Actual result: -- Error on the page, no Session Variable is able to be declared and managed properly. Seems like no session support at all with the MySQL based session system -- Edit this bug report at http://bugs.php.net/?id=27396edit=1
#27395 [Asn]: arrays cannot be passed by value
ID: 27395
Updated by: [EMAIL PROTECTED]
Reported By: jamesn at tocquigny dot com
Status: Assigned
-Bug Type: Zend Engine 2 problem
+Bug Type: Scripting Engine problem
-Operating System: redhat linux
+Operating System: *
-PHP Version: 4.3.4
+PHP Version: 4CVS, 5CVS (2004-02-25
Assigned To: zeev
New Comment:
Here's a bit better test script:
?php
function theFunction($arg) {
$arg[0] = 2;
}
$arr1 = array (1);
$reference = $arr1[0];
var_dump($reference);
var_dump($arr1);
theFunction($arr1);
var_dump($reference);
var_dump($arr1);
?
Previous Comments:
[2004-02-25 13:19:31] [EMAIL PROTECTED]
It's indeed a perfectly valid bug. Assigning to Zeev as he's the engine
guru.
[2004-02-25 13:12:32] [EMAIL PROTECTED]
RTFM:
http://www.php.net/manual/en/language.references.whatdo.php
[2004-02-25 12:58:11] jamesn at tocquigny dot com
further:
removing $reference = $array[0];
from the code causes the array to be passed by value...this is the bug
i'm concerned about.
[2004-02-25 12:56:51] jamesn at tocquigny dot com
in response to papercrane, no i didn't mean
function theFunction($array)
(this would pass by reference...by default php is doing this)
By flagging my bug as bogus are you stating the proper behavior is to
always pass by reference? (Which isn't proper at all IMO nor that of
coworkers or anyone that's worked w/ c/c++)
[2004-02-25 12:02:02] jamesn at tocquigny dot com
Description:
There appears to be a problem with php that doesn't allow arrays to be
passed by value. The fix appears to be something similar to:
http://bugs.php.net/bug.php?id=6417
if (PZVAL_IS_REF(*p))
{
SEPARATE_ZVAL(p);
} else {
zval_add_ref(p);
}
It would appear that that logic is missing in one place or another. I
could not track it down myself. Code similar to this appears to be
copy/pasted in various places.
Reproduce code:
---
$array = array(1);
// This line makes the call to theFunction() act as if passed by ref.?
$reference = $array[0];
echo $array[0], 'br';
theFunction($array);
echo $array[0], 'br';
function theFunction($array) {
$array[0] = 2;
}
Expected result:
you should get 1 and 1
Actual result:
--
instead you get 1 and 2!
--
Edit this bug report at http://bugs.php.net/?id=27395edit=1
#26005 [Csd-Opn]: Random cannot change the session's ini settings errors
ID: 26005
User updated by: parsnip11 at hotmail dot com
Reported By: parsnip11 at hotmail dot com
-Status: Closed
+Status: Open
Bug Type: Session related
Operating System: *
PHP Version: 4CVS-2003-10-31
New Comment:
Is there any way that I can apply this patch to php4isapi.dll?
Previous Comments:
[2004-02-24 03:42:35] [EMAIL PROTECTED]
Patch applied. Thanks!
[2004-02-23 07:11:43] jsnajdr at kerio dot com
This is a patch that stopped crashing for me:
*** php-4.3.4/ext/session/session.c Wed Oct 8 12:25:39 2003
--- php-4.3.4-n/ext/session/session.c Tue Dec 9 11:36:24 2003
***
*** 1543,1548
--- 1543,1556
}
}
+ static void php_session_init_globals(php_ps_globals *ps_globals
TSRMLS_DC)
+ {
+ ps_globals-id = NULL;
+ ps_globals-session_status = php_session_none;
+ ps_globals-mod_data = NULL;
+ ps_globals-http_session_vars = NULL;
+ }
+
static void php_rinit_session_globals(TSRMLS_D)
{
PS(id) = NULL;
***
*** 1618,1624
#ifdef ZTS
php_ps_globals *ps_globals;
! ts_allocate_id(ps_globals_id, sizeof(php_ps_globals), NULL, NULL);
ps_globals = ts_resource(ps_globals_id);
#endif
--- 1626,1632
#ifdef ZTS
php_ps_globals *ps_globals;
! ts_allocate_id(ps_globals_id, sizeof(php_ps_globals),
(ts_allocate_ctor) php_session_init_globals, NULL);
ps_globals = ts_resource(ps_globals_id);
#endif
[2003-12-08 14:29:29] jsnajdr at kerio dot com
I am experiencing this bug too and I think I found its cause. It can
occur when PHP is used in a multithreaded program - I embed PHP
interpreter in my own multithreaded server using a custom SAPI module,
original submitter of this bug uses ISAPI module, which is also
multithreaded.
The 'Session is active' warning is generated by the
PHP_INI_MH(OnUpdateSaveHandler) function that checks
PS(session_status), i.e. the session module globals structure. This
handler is also called when calling TSRMLS_FETCH() (which is a define
for ts_resource_ex() call) before executing a PHP script. See this call
stack from gdb:
#0 OnUpdateSaveHandler (entry=0xb303890, new_value=0x8700f48 files,
new_value_length=5, mh_arg1=0x0, mh_arg2=0x0, mh_arg3=0x0, stage=1,
tsrm_ls=0xb2dce18)
at /root/src/php-4.3.4/ext/session/session.c:93
#1 0x0865414c in zend_ini_refresh_cache (p=0xb303890, stage=1,
tsrm_ls=0xb2dce18) at /root/src/php-4.3.4/Zend/zend_ini.c:177
#2 0x0865006f in zend_hash_apply_with_argument (ht=0xb300ac8,
apply_func=0x8654124 zend_ini_refresh_cache, argument=0x1,
tsrm_ls=0xb2dce18)
at /root/src/php-4.3.4/Zend/zend_hash.c:717
#3 0x0865417d in zend_ini_refresh_caches (stage=1, tsrm_ls=0xb2dce18)
at /root/src/php-4.3.4/Zend/zend_ini.c:185
#4 0x08653f88 in zend_copy_ini_directives (tsrm_ls=0xb2dce18) at
/root/src/php-4.3.4/Zend/zend_ini.c:104
#5 0x0864b574 in zend_new_thread_end_handler (thread_id=4423709,
tsrm_ls=0xb2dce18) at /root/src/php-4.3.4/Zend/zend.c:374
#6 0x0862724f in allocate_new_resource
(thread_resources_ptr=0xabac72c, thread_id=4423709) at
/root/src/php-4.3.4/TSRM/TSRM.c:282
#7 0x08627305 in ts_resource_ex (id=0, th_id=0x0) at
/root/src/php-4.3.4/TSRM/TSRM.c:341
But this handler reads unitialized memory in the new thread's
ps_globals - the TSRM resource has NULL constructor and TSRMLS_FETCH is
called before php_request_startup(), where all the modules are
activated and where the PHP_RINIT_FUNCTION(session) is called to
construct the structure.
Solution: the ps_globals resource must have a non-null constructor
registered in ts_allocate_resource() call in ext/session/session.c
[2003-10-27 10:52:27] parsnip11 at hotmail dot com
Description:
I am recently upgraded to php 4.3.3 from 4.2.9 and am using the
php4isapi.dll on iis. My application has been working w/o any problems
for quite awhile and after the upgrade, without rhyme or reason I am
getting the following error every few days:
PHP Warning: Unknown(): A session is active. You cannot change the
session module's ini settings at this time. in Unknown on line 0
I have no ini_set statement in my application and have even set my
php.ini to read only in the event that it was somehow being modified.
My application is EXTREMELY simple... it's basically just consists of a
few html forms submitting to a sql db. Authentication happens via IIS
and I'm using $AUTH_USER to get the user id.
Since this error is extremely intermittent and only happens 2 or 3
times a week, I cant seem to figure out what line seems or even what
function
#27395 [Asn]: arrays cannot be passed by value
ID: 27395
Updated by: [EMAIL PROTECTED]
Reported By: jamesn at tocquigny dot com
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 4CVS, 5CVS (2004-02-25
Assigned To: zeev
New Comment:
Wrong test, this was the one:
?php
function theFunction($arg) {
$arg[0] = 2;
}
// Reference on array index
$arr1 = array (1);
$reference1 = $arr1[0];
var_dump($reference1);
var_dump($arr1);
theFunction($arr1);
var_dump($reference1);
var_dump($arr1);
echo \n;
// Reference on array
$arr2 = array (1);
$reference2 = $arr2;
var_dump($reference2);
var_dump($arr2);
theFunction($arr2);
var_dump($reference2);
var_dump($arr2);
?
Previous Comments:
[2004-02-25 13:26:08] [EMAIL PROTECTED]
Here's a bit better test script:
?php
function theFunction($arg) {
$arg[0] = 2;
}
$arr1 = array (1);
$reference = $arr1[0];
var_dump($reference);
var_dump($arr1);
theFunction($arr1);
var_dump($reference);
var_dump($arr1);
?
[2004-02-25 12:02:02] jamesn at tocquigny dot com
Description:
There appears to be a problem with php that doesn't allow arrays to be
passed by value. The fix appears to be something similar to:
http://bugs.php.net/bug.php?id=6417
if (PZVAL_IS_REF(*p))
{
SEPARATE_ZVAL(p);
} else {
zval_add_ref(p);
}
It would appear that that logic is missing in one place or another. I
could not track it down myself. Code similar to this appears to be
copy/pasted in various places.
Reproduce code:
---
$array = array(1);
// This line makes the call to theFunction() act as if passed by ref.?
$reference = $array[0];
echo $array[0], 'br';
theFunction($array);
echo $array[0], 'br';
function theFunction($array) {
$array[0] = 2;
}
Expected result:
you should get 1 and 1
Actual result:
--
instead you get 1 and 2!
--
Edit this bug report at http://bugs.php.net/?id=27395edit=1
#26005 [Opn-Csd]: Random cannot change the session's ini settings errors
ID: 26005
Updated by: [EMAIL PROTECTED]
Reported By: parsnip11 at hotmail dot com
-Status: Open
+Status: Closed
Bug Type: Session related
Operating System: *
PHP Version: 4CVS-2003-10-31
New Comment:
Get the latest stable CVS snapshot. And don't reopen closed bugs unless
you can still reproduce it with the snapshot..
Previous Comments:
[2004-02-25 13:28:20] parsnip11 at hotmail dot com
Is there any way that I can apply this patch to php4isapi.dll?
[2004-02-24 03:42:35] [EMAIL PROTECTED]
Patch applied. Thanks!
[2004-02-23 07:11:43] jsnajdr at kerio dot com
This is a patch that stopped crashing for me:
*** php-4.3.4/ext/session/session.c Wed Oct 8 12:25:39 2003
--- php-4.3.4-n/ext/session/session.c Tue Dec 9 11:36:24 2003
***
*** 1543,1548
--- 1543,1556
}
}
+ static void php_session_init_globals(php_ps_globals *ps_globals
TSRMLS_DC)
+ {
+ ps_globals-id = NULL;
+ ps_globals-session_status = php_session_none;
+ ps_globals-mod_data = NULL;
+ ps_globals-http_session_vars = NULL;
+ }
+
static void php_rinit_session_globals(TSRMLS_D)
{
PS(id) = NULL;
***
*** 1618,1624
#ifdef ZTS
php_ps_globals *ps_globals;
! ts_allocate_id(ps_globals_id, sizeof(php_ps_globals), NULL, NULL);
ps_globals = ts_resource(ps_globals_id);
#endif
--- 1626,1632
#ifdef ZTS
php_ps_globals *ps_globals;
! ts_allocate_id(ps_globals_id, sizeof(php_ps_globals),
(ts_allocate_ctor) php_session_init_globals, NULL);
ps_globals = ts_resource(ps_globals_id);
#endif
[2003-12-08 14:29:29] jsnajdr at kerio dot com
I am experiencing this bug too and I think I found its cause. It can
occur when PHP is used in a multithreaded program - I embed PHP
interpreter in my own multithreaded server using a custom SAPI module,
original submitter of this bug uses ISAPI module, which is also
multithreaded.
The 'Session is active' warning is generated by the
PHP_INI_MH(OnUpdateSaveHandler) function that checks
PS(session_status), i.e. the session module globals structure. This
handler is also called when calling TSRMLS_FETCH() (which is a define
for ts_resource_ex() call) before executing a PHP script. See this call
stack from gdb:
#0 OnUpdateSaveHandler (entry=0xb303890, new_value=0x8700f48 files,
new_value_length=5, mh_arg1=0x0, mh_arg2=0x0, mh_arg3=0x0, stage=1,
tsrm_ls=0xb2dce18)
at /root/src/php-4.3.4/ext/session/session.c:93
#1 0x0865414c in zend_ini_refresh_cache (p=0xb303890, stage=1,
tsrm_ls=0xb2dce18) at /root/src/php-4.3.4/Zend/zend_ini.c:177
#2 0x0865006f in zend_hash_apply_with_argument (ht=0xb300ac8,
apply_func=0x8654124 zend_ini_refresh_cache, argument=0x1,
tsrm_ls=0xb2dce18)
at /root/src/php-4.3.4/Zend/zend_hash.c:717
#3 0x0865417d in zend_ini_refresh_caches (stage=1, tsrm_ls=0xb2dce18)
at /root/src/php-4.3.4/Zend/zend_ini.c:185
#4 0x08653f88 in zend_copy_ini_directives (tsrm_ls=0xb2dce18) at
/root/src/php-4.3.4/Zend/zend_ini.c:104
#5 0x0864b574 in zend_new_thread_end_handler (thread_id=4423709,
tsrm_ls=0xb2dce18) at /root/src/php-4.3.4/Zend/zend.c:374
#6 0x0862724f in allocate_new_resource
(thread_resources_ptr=0xabac72c, thread_id=4423709) at
/root/src/php-4.3.4/TSRM/TSRM.c:282
#7 0x08627305 in ts_resource_ex (id=0, th_id=0x0) at
/root/src/php-4.3.4/TSRM/TSRM.c:341
But this handler reads unitialized memory in the new thread's
ps_globals - the TSRM resource has NULL constructor and TSRMLS_FETCH is
called before php_request_startup(), where all the modules are
activated and where the PHP_RINIT_FUNCTION(session) is called to
construct the structure.
Solution: the ps_globals resource must have a non-null constructor
registered in ts_allocate_resource() call in ext/session/session.c
[2003-10-27 10:52:27] parsnip11 at hotmail dot com
Description:
I am recently upgraded to php 4.3.3 from 4.2.9 and am using the
php4isapi.dll on iis. My application has been working w/o any problems
for quite awhile and after the upgrade, without rhyme or reason I am
getting the following error every few days:
PHP Warning: Unknown(): A session is active. You cannot change the
session module's ini settings at this time. in Unknown on line 0
I have no ini_set statement in my application and have even set my
php.ini to read only in the event that it was somehow being modified.
My application is EXTREMELY simple... it's basically just consists of a
few html forms submitting
#27397 [NEW]: debug_backtrace() not showing args pased to function
From: lance at monkeymental dot com
Operating system: Linux Kernel 2.4.22
PHP version: 5.0.0b4 (beta4)
PHP Bug Type: Unknown/Other Function
Bug description: debug_backtrace() not showing args pased to function
Description:
The debug_backtrace() call doesn't show what arguments where passed to a
function in PHP 5.0b4 bug does with PHP 4.3.4 using the same source file.
Reproduce code:
---
?
function test($a, $b)
{
print_r(debug_backtrace());
echo $a, $b\n;
}
test(Hello, World);
?
Expected result:
PHP 4.3.4 (cli) (built: Jan 5 2004 17:27:17)
Copyright (c) 1997-2003 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies
Array
(
[0] = Array
(
[file] = /root/scratch/xml/foo.php
[line] = 9
[function] = test
[args] = Array
(
[0] = Hello
[1] = World
)
)
)
Hello, World
Actual result:
--
PHP 5.0.0b4 (cli) (built: Feb 22 2004 21:45:34)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.0-dev, Copyright (c) 1998-2004 Zend Technologies
Array
(
[0] = Array
(
[file] = /root/scratch/xml/foo.php
[line] = 9
[function] = test
)
)
Hello, World
--
Edit bug report at http://bugs.php.net/?id=27397edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27397r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27397r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27397r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27397r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27397r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27397r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27397r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27397r=support
Expected behavior: http://bugs.php.net/fix.php?id=27397r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27397r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27397r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27397r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27397r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27397r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27397r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27397r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27397r=float
#26820 [Asn]: mssql_fetch_row BIT field problem
ID: 26820 Updated by: [EMAIL PROTECTED] Reported By: subspace at wanadoo dot nl Status: Assigned Bug Type: MSSQL related Operating System: Debian Linux 2.4.21 PHP Version: 4CVS-2004-02-06 Assigned To: fmk New Comment: On Win32 this is caused by a bug in dblib (the Microsoft library used to build the extension). Previous Comments: [2004-02-21 05:45:07] egarcia at egm dot as I have the same problem in Windows XP, Windows 2000, using MSSQL 2000. I call a store procedure that returns data using rollup over a bit field. In the sumarized data MSSQL return NULL in the bit field but PHP give me a zero (0). The expected result is to get the NULL value data. The example in the posted message is TOTALLY replicable in my system. [2004-02-06 13:44:31] subspace at wanadoo dot nl ./configure --with-mssql --without-mysql The mysql option is irrelevant though. FreeTDS package installed: freetds-dev0.61-5 X-Powered-By: PHP/4.3.5RC2 bit: int(0) tiny: int(0) bit: int(1) tiny: int(1) bit: int(0) tiny: NULL [2004-02-06 11:35:33] [EMAIL PROTECTED] One more information is needed: what was the configure line used to configure PHP? [2004-01-19 12:21:11] [EMAIL PROTECTED] Just to clarify: Expected behaviour is that return values are NULL for NULL. (definately NOT bool(false) like you suggested in your first comment) [2004-01-19 01:03:59] subspace at wanadoo dot nl Accidentally clicked hit Submit before I was done typing.. Using 4.3.5RC2-dev CVS 200401190430 and Debian package freetds-dev 0.61-5 the result is now: X-Powered-By: PHP/4.3.5RC2-dev bit: int(0) tiny: int(0) bit: int(1) tiny: int(1) bit: int(0) tiny: NULL All the strings are now ints, but as you can see the expected NULL value is still not there. 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/26820 -- Edit this bug report at http://bugs.php.net/?id=26820edit=1
#27383 [Csd-Opn]: uninitialized memory in http_fopen_wrapper.c error handling
ID: 27383
User updated by: remijnj at eidetica dot com
Reported By: remijnj at eidetica dot com
-Status: Closed
+Status: Open
Bug Type: HTTP related
Operating System: Linux (Slackware 9.1)
PHP Version: 4.3.5RC3
New Comment:
I reopened the bug because the tmp_line is still not initialized. See
my previous comment (forgot to open the bug again) which has a simple
patch from cvs diff -u.
Joost
Previous Comments:
[2004-02-24 17:51:34] remijnj at eidetica dot com
Thanks for adding it to CVS so quickly. I got the cvs version checked
out now and i notice one important bit missing (because i didn't
explain it properly i guess).
My initial problem (garbage bytes in HTTP request failed error) is
still there as far as i can see from the code. Let me explain.
The line :
php_stream_wrapper_log_error(wrapper, options TSRMLS_CC, HTTP request
failed! %s, tmp_line);
can be reached with tmp_line uninitialized. That is why i added the
'tmp_line[0] = '\0';' at the start of the function. Here an incremental
patch on top of this.
Index: ext/standard/http_fopen_wrapper.c
===
RCS file: /repository/php-src/ext/standard/http_fopen_wrapper.c,v
retrieving revision 1.53.2.15
diff -u -r1.53.2.15 http_fopen_wrapper.c
--- ext/standard/http_fopen_wrapper.c 24 Feb 2004 21:53:56 -
1.53.2.15
+++ ext/standard/http_fopen_wrapper.c 24 Feb 2004 22:51:56 -
@@ -107,6 +107,8 @@
size_t chunk_size = 0, file_size = 0;
int eol_detect, have_header = 0;
+ tmp_line[0] = '\0';
+
if (redirect_max 1) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Circular
redirect, aborting.);
return NULL;
[2004-02-24 16:46:30] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2004-02-24 14:19:26] remijnj at eidetica dot com
Here the patch which fixes it. I hope i've done it in the right patch
format (diff -urN).
diff -urN php-4.3.5RC3/ext/standard/http_fopen_wrapper.c
php-4.3.5RC3-mine/ext/standard/http_fopen_wrapper.c
--- php-4.3.5RC3/ext/standard/http_fopen_wrapper.c 2003-11-28
19:51:14.0 +0100
+++ php-4.3.5RC3-mine/ext/standard/http_fopen_wrapper.c 2004-02-24
19:51:07.0 +0100
@@ -107,6 +107,7 @@
size_t chunk_size = 0, file_size = 0;
int eol_detect, have_header = 0;
+ tmp_line = '\0';
if (redirect_max 1) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Circular redirect,
aborting.);
return NULL;
@@ -345,11 +346,24 @@
if (php_stream_gets(stream, tmp_line, sizeof(tmp_line)-1) !=
NULL) {
zval *http_response;
int response_code;
+ int tmp_line_len;
+
+ tmp_line_len = strlen(tmp_line);
MAKE_STD_ZVAL(http_response);
ZVAL_NULL(http_response);
- response_code = atoi(tmp_line + 9);
+ if (tmp_line_len 9) {
+ response_code = atoi(tmp_line + 9);
+ } else {
+ /*
+* short http_response, if not caught like
+* this we'd pass uninitialized memory to
+* atoi (SEGV if there is no '\0' byte in
+* there)
+*/
+ response_code = 0;
+ }
switch(response_code) {
case 200:
case 302:
@@ -365,7 +379,7 @@
tmp_line, response_code);
}
- Z_STRLEN_P(http_response) = strlen(tmp_line);
+ Z_STRLEN_P(http_response) = tmp_line_len;
Z_STRVAL_P(http_response) = estrndup(tmp_line,
Z_STRLEN_P(http_response));
if
(Z_STRVAL_P(http_response)[Z_STRLEN_P(http_response)-1]=='\n')
{
Z_STRVAL_P(http_response)[Z_STRLEN_P(http_response)-1]=0;
[2004-02-24 14:13:53] remijnj at eidetica dot com
Description:
I have seen uninitialized
#27384 [Csd]: unpack() misbehaves with 1 char string
ID: 27384
User updated by: hayk at mail dot ru
Reported By: hayk at mail dot ru
Status: Closed
Bug Type: Strings related
Operating System: *
PHP Version: 4.3.4
New Comment:
By the way, array indexes usually begin from 0, not from 1.
Previous Comments:
[2004-02-25 07:29:18] [EMAIL PROTECTED]
And fix was merged to the stable branch too..
[2004-02-24 16:42:55] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
I see what you're saying now. This has been fixed in
HEAD.
[2004-02-24 15:42:38] hayk at mail dot ru
Why this code works fine?
?
$sp = chr(0x20);
$a = unpack('C2', $sp.$sp);
?
pre
? print_r($a); ?
/pre
We get:
Array
(
[1] = 32
[2] = 32
)
[2004-02-24 15:30:15] [EMAIL PROTECTED]
You're not using unpack correctly. The format string is
Type.Multiplicity.Name
Name cannot begin with or be a number, as it would be
impossible to distinguish multiplicty from name.
[2004-02-24 15:23:26] hayk at mail dot ru
I muddle up Expected and Actual results in the my submission.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/27384
--
Edit this bug report at http://bugs.php.net/?id=27384edit=1
#27397 [Opn-Ver]: debug_backtrace() not showing args pased to function
ID: 27397
Updated by: [EMAIL PROTECTED]
Reported By: lance at monkeymental dot com
-Status: Open
+Status: Verified
Bug Type: Zend Engine 2 problem
-Operating System: Linux Kernel 2.4.22
+Operating System: *
-PHP Version: 5.0.0b4 (beta4)
+PHP Version: 5CVS-2004-02-25
Previous Comments:
[2004-02-25 14:27:14] lance at monkeymental dot com
Description:
The debug_backtrace() call doesn't show what arguments where passed to
a function in PHP 5.0b4 bug does with PHP 4.3.4 using the same source
file.
Reproduce code:
---
?
function test($a, $b)
{
print_r(debug_backtrace());
echo $a, $b\n;
}
test(Hello, World);
?
Expected result:
PHP 4.3.4 (cli) (built: Jan 5 2004 17:27:17)
Copyright (c) 1997-2003 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies
Array
(
[0] = Array
(
[file] = /root/scratch/xml/foo.php
[line] = 9
[function] = test
[args] = Array
(
[0] = Hello
[1] = World
)
)
)
Hello, World
Actual result:
--
PHP 5.0.0b4 (cli) (built: Feb 22 2004 21:45:34)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.0-dev, Copyright (c) 1998-2004 Zend Technologies
Array
(
[0] = Array
(
[file] = /root/scratch/xml/foo.php
[line] = 9
[function] = test
)
)
Hello, World
--
Edit this bug report at http://bugs.php.net/?id=27397edit=1
#27368 [Asn]: php.ini-(dist|recommended) have CR at end
ID: 27368 Updated by: [EMAIL PROTECTED] Reported By: danielc at analysisandsolutions dot com Status: Assigned Bug Type: *Configuration Issues Operating System: Windows 2000 PHP Version: 5CVS-2004-02-23 (dev) Assigned To: wez New Comment: The ini files indeed are borked. Quite weird. Previous Comments: [2004-02-23 13:48:16] [EMAIL PROTECTED] I have no idea about this. Assigning to Wez who introduced this bug too. [2004-02-23 13:21:52] danielc at analysisandsolutions dot com Where were you looking? In CVS or in the files distributed in a php5-win32-200402231530 snapshot? They are definitely there in the snapshot. I can email you the files if you don't believe me. This may be due to the new build system, which when it went into effect threw in loads of CR's even though the raw files in CVS were fine. I posted a note to internals and it seems someone fixed something to make all but one of the CR's disappeared. [2004-02-23 13:17:01] [EMAIL PROTECTED] In CVS: ; tab-width: 4 ; End: (there is no CR there) [2004-02-23 12:23:31] danielc at analysisandsolutions dot com Description: Minor problem... The php.ini-dist and php.ini-recommended files in the latest Windows snapshot (php5-win32-200402231530) are in Unix format, but have a CR thrown in at the end of each file: ... snip ... ; tab-width: 4 ; End ^ here -- Edit this bug report at http://bugs.php.net/?id=27368edit=1
#27398 [NEW]: Installing PEAR (go-pear.bat) causes Application Error
From: WPinegar at healthtech dot net Operating system: Windows Server 2003 PHP version: 5CVS-2004-02-25 (dev) PHP Bug Type: *General Issues Bug description: Installing PEAR (go-pear.bat) causes Application Error Description: While attempting to install PEAR via the command go-pear.bat (found in the \PHP directory) I received an application error in php.exe module php5ts.dll and PEAR does not extract properly. Reproduce code: --- Attempt to install PEAR via the command line utility go-pear.bat. You will receive an application error and PEAR will not extract properly. Expected result: PEAR should extract and install correctly. -- Edit bug report at http://bugs.php.net/?id=27398edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27398r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27398r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27398r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27398r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27398r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27398r=needscript Try newer version: http://bugs.php.net/fix.php?id=27398r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27398r=support Expected behavior: http://bugs.php.net/fix.php?id=27398r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27398r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27398r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27398r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27398r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27398r=dst IIS Stability: http://bugs.php.net/fix.php?id=27398r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27398r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27398r=float
#27383 [Opn-Csd]: uninitialized memory in http_fopen_wrapper.c error handling
ID: 27383
Updated by: [EMAIL PROTECTED]
Reported By: remijnj at eidetica dot com
-Status: Open
+Status: Closed
Bug Type: HTTP related
Operating System: Linux (Slackware 9.1)
PHP Version: 4.3.5RC3
New Comment:
In the CVS it cannot reach that line, if tmp_line is 9
then response_code is set to 0 and the code terminates
before that line is reached. In all other instances
tmp_line will contain a null terminated string.
Previous Comments:
[2004-02-25 15:09:45] remijnj at eidetica dot com
I reopened the bug because the tmp_line is still not initialized. See
my previous comment (forgot to open the bug again) which has a simple
patch from cvs diff -u.
Joost
[2004-02-24 17:51:34] remijnj at eidetica dot com
Thanks for adding it to CVS so quickly. I got the cvs version checked
out now and i notice one important bit missing (because i didn't
explain it properly i guess).
My initial problem (garbage bytes in HTTP request failed error) is
still there as far as i can see from the code. Let me explain.
The line :
php_stream_wrapper_log_error(wrapper, options TSRMLS_CC, HTTP request
failed! %s, tmp_line);
can be reached with tmp_line uninitialized. That is why i added the
'tmp_line[0] = '\0';' at the start of the function. Here an incremental
patch on top of this.
Index: ext/standard/http_fopen_wrapper.c
===
RCS file: /repository/php-src/ext/standard/http_fopen_wrapper.c,v
retrieving revision 1.53.2.15
diff -u -r1.53.2.15 http_fopen_wrapper.c
--- ext/standard/http_fopen_wrapper.c 24 Feb 2004 21:53:56 -
1.53.2.15
+++ ext/standard/http_fopen_wrapper.c 24 Feb 2004 22:51:56 -
@@ -107,6 +107,8 @@
size_t chunk_size = 0, file_size = 0;
int eol_detect, have_header = 0;
+ tmp_line[0] = '\0';
+
if (redirect_max 1) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Circular
redirect, aborting.);
return NULL;
[2004-02-24 16:46:30] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2004-02-24 14:19:26] remijnj at eidetica dot com
Here the patch which fixes it. I hope i've done it in the right patch
format (diff -urN).
diff -urN php-4.3.5RC3/ext/standard/http_fopen_wrapper.c
php-4.3.5RC3-mine/ext/standard/http_fopen_wrapper.c
--- php-4.3.5RC3/ext/standard/http_fopen_wrapper.c 2003-11-28
19:51:14.0 +0100
+++ php-4.3.5RC3-mine/ext/standard/http_fopen_wrapper.c 2004-02-24
19:51:07.0 +0100
@@ -107,6 +107,7 @@
size_t chunk_size = 0, file_size = 0;
int eol_detect, have_header = 0;
+ tmp_line = '\0';
if (redirect_max 1) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Circular redirect,
aborting.);
return NULL;
@@ -345,11 +346,24 @@
if (php_stream_gets(stream, tmp_line, sizeof(tmp_line)-1) !=
NULL) {
zval *http_response;
int response_code;
+ int tmp_line_len;
+
+ tmp_line_len = strlen(tmp_line);
MAKE_STD_ZVAL(http_response);
ZVAL_NULL(http_response);
- response_code = atoi(tmp_line + 9);
+ if (tmp_line_len 9) {
+ response_code = atoi(tmp_line + 9);
+ } else {
+ /*
+* short http_response, if not caught like
+* this we'd pass uninitialized memory to
+* atoi (SEGV if there is no '\0' byte in
+* there)
+*/
+ response_code = 0;
+ }
switch(response_code) {
case 200:
case 302:
@@ -365,7 +379,7 @@
tmp_line, response_code);
}
- Z_STRLEN_P(http_response) = strlen(tmp_line);
+ Z_STRLEN_P(http_response) = tmp_line_len;
Z_STRVAL_P(http_response) = estrndup(tmp_line,
Z_STRLEN_P(http_response));
if
#27399 [NEW]: Object copy neither shallow nor deep
From: php dot bugs at darwin dot no-ip dot com
Operating system: Linux 2.4.18
PHP version: 4.3.4
PHP Bug Type: Scripting Engine problem
Bug description: Object copy neither shallow nor deep
Description:
Copying an object doesn't appear to work as expected for either a shallow
or a deep copy.
Reproduce code:
---
class Dummy {}
$listA = new Dummy();
$listA-next = new Dummy();
$listA-next-previous = $listA;
$listA-value = one;
$listA-next-value = two;
$listA-next-previous-value = ONE;
echo ListA: ;
echo ( . $listA-value . , . $listA-next-value . ) \n;
$listB = $listA;
$listB-value = three;
$listB-next-value = four;
$listB-next-previous-value=THREE;
echo (modified listB)\n;
echo ListA: ;
echo ( . $listA-value . , . $listA-next-value . ) \n;
echo ListB: ;
echo ( . $listB-value . , . $listB-next-value . ) \n;
Expected result:
Expected output: (ie: if PHP does a deep copy)
ListA: (ONE, two)
(modified listB)
ListA: (ONE, two)
ListB: (three, four)
This should happen because $listB-next-previous is a copy of the
reference
to $listA. Modifying it should not modify ListA OR ListB.
Possible (wrong) output: (if PHP had done a shallow copy)
ListA: (ONE, two)
(modified listB)
ListA: (THREE, four)
ListB: (three, four)
This would be the case because listB's next would be a reference to
ListA's
next.
Actual result:
--
Actual output:
ListA: (ONE, two)
(modified listB)
ListA: (THREE, two)
ListB: (three, four)
This looks like PHP did something between a shallow and a deep copy.
while ListB-next is a copy, ListB-next-previous still points at ListA.
(!?!)
... For an added bonus, try replacing '= new' with '= new' and it looks
like
PHP does a shallow copy. From my reading of PHP documentation, I thought
PHP would always do deep (de-referencing) copies.
--
Edit bug report at http://bugs.php.net/?id=27399edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27399r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27399r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27399r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27399r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27399r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=27399r=needscript
Try newer version: http://bugs.php.net/fix.php?id=27399r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27399r=support
Expected behavior: http://bugs.php.net/fix.php?id=27399r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27399r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27399r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=27399r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27399r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=27399r=dst
IIS Stability: http://bugs.php.net/fix.php?id=27399r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27399r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27399r=float
#21760 [Ver-Csd]: socket_read PHP_NORMAL_READ problem
ID: 21760
Updated by: [EMAIL PROTECTED]
Reported By: sunday at csh dot rit dot edu
-Status: Verified
+Status: Closed
Bug Type: Sockets related
Operating System: FreeBSD 4.7
PHP Version: 4.3.0
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2004-02-24 08:43:13] [EMAIL PROTECTED]
I have the same problem with this function with PHP 4.3.4 on FreeBSD
4.9. (The file sockets.c is exactly the same in this version of PHP and
in php4-STABLE-200402241230.)
I think the patch suggested by uce at ftc dot gov looks like the
simplest solution. Contrary to what [EMAIL PROTECTED] indicate, this patch
does not in any way affect the result returned to the user, except for
fixing this bug.
I'm not at all surprised that [EMAIL PROTECTED] was unable to reproduce
this bug, because it only occurs if the buffer returned by emalloc() in
socket_read() begins with '\r' or '\n', and that is not neccessarily
the case, depending on configuration and operating system.
I don't think I have commit access to the sockets extension, but I hope
that somebody who has can fix this.
Regards,
David Eriksson
[2003-02-27 10:16:20] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Works fine here with latest stable CSV.
The path you prose is bogus because it overwrites the 1st byte in t
with a 0.
[2003-02-05 21:13:53] chip at cyan dot com
ah. found my windows 2000 socket_read bug:
http://bugs.php.net/bug.php?id=21197
[2003-02-05 21:08:07] chip at cyan dot com
I can repeat this bug.
here is an example script that i used:
http://force-elite.com/~chip/test/socket_phpreadnormal.phps
it is a modification of the basic HTTP client given as an example in
the PHP.net documentation.
When PHP_NORMAL_READ is used, and certen buffer sizes, it will resuilt
in socket_read returning bogus data, commonly all newlines(\n).
On both a FreeBSD-4.7-stable(built Fri Nov 29), and
FreeBSD-5.0-RC(built Wed Jan 8), both using PHP-4.3.0-cli, with a
buffer size of 2048 it would work, with a buffer size of 100,
socket_read() would return a stream of \n.
On Linux 2.4.18-18.7.x(Redhat Box) using PHP-4.3.0-cli, it would always
work, regardless of the buffer size.
On Linux 2.4.19-crypto-r7(Gentoo Box) using PHP-4.3.0-cli, it would
work with 2048 buffer size, but with 100 it would bail with:
Notice: Undefined offset: 0 in /path/socket_phpreadnormal.php on line
51
Warning: socket_read() expects parameter 1 to be resource,
null given in /path/socket_phpreadnormal.php on line 51
(I don't have direct access to this box, I didn't want to heavly debug
it, it is possibly an error in my script.)
On Windows 2000, using PHP-4.3.0-cli, it would always return 0(EOF)
from socket_read(). It Bailed with:
Warning: socket_read() unable to read from socket [0]: The operation
completed successfully.
(perhaps a seperate bug :-) )
[2003-02-05 09:53:04] uce at ftc dot gov
I believe this is caused by a comparison to an uninitialized buffer in
php_read (buffer emalloc'd in socket_read).
Patch:
--- php5/ext/sockets/sockets.c 2003-01-18 19:28:06.0 +
+++ php5-atropine/ext/sockets/sockets.c 2003-02-05 15:43:00.0
+
@@ -288,6 +288,7 @@
set_errno(0);
+ *t = 0;
while (*t != '\n' *t != '\r' n maxlen) {
if (m 0) {
t++;
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/21760
--
Edit this bug report at http://bugs.php.net/?id=21760edit=1
#27373 [Fbk-Opn]: Apache vs 1.3.27 and 1.3.29 with PHP 4.3.4 and 4.2.2 - libphp4.so not created
ID: 27373 User updated by: mattm at mattm dot net Reported By: mattm at mattm dot net -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Solaris 5.7 Sparc PHP Version: 4.3.4 New Comment: Thanks for the speedy reply -- I started with a very basic httpd.conf file, as this server is to have only two directories (Nagios install w/ php). I have wound up blowing away apache completely, and just trying to get it to work with the newly compiled Apache/PHP combo. Note that Apache compiles and works without PHP. As soon as I add it in I get probs. Just no I tried the same steps, omiting the --active-module=php4 line. Same results. The /usr/local/apache/libexec directory is empty The PHP entries for LoadModule / ClearModule were not added to httpd.conf Previous Comments: [2004-02-24 04:47:14] [EMAIL PROTECTED] What exactly do you have in httpd.conf ? And I don't think you need --enable-module=php4 in the last phase for Apache.. [2004-02-23 18:31:54] mattm at mattm dot net Description: Apache vs 1.3.27 and 1.3.29 with PHP 4.3.4 and 4.2.2 I'm almost bald now -- pulling out my hair for a week on this one. I have gone through all the bug-reports and tried all sorts of combinations. I am using the latest stable release from the website. Preconfigure APACHE # cd apache_1.3.27 # ./configure --prefix=/usr/local/apache PHP # cd php-4.3.3 # ./configure --with-apache=../apache_1.3.27 # make # make install # cp php.ini-dist /usr/local/lib/php.ini APACHE Final Install # cd apache_1.3.27 # ./configure --activate-module=src/modules/php4/libphp4.a \ --enable-module=php4 \ --prefix=/usr/local/apache \ # make # make install Error conditions now: a) The /usr/local/apache/libexec folder is empty. b) The htpasswd tool core-dumps c) httpd will not start when php4 is referenced in httpd.conf Things tried: a) configure, make, change libtool: build_libtool_libs=yes, make install -- the libphp4.so.0 is not in .libs as the workarounds indicate b) varios combinations of Apache and PHP as listed above. -- Edit this bug report at http://bugs.php.net/?id=27373edit=1
#26677 [Asn]: Errors when compiling with mbstring support
ID: 26677
Updated by: [EMAIL PROTECTED]
Reported By: behrens at takenet dot de
Status: Assigned
Bug Type: mbstring related
Operating System: IRIX64
PHP Version: 5CVS
Assigned To: moriyoshi
New Comment:
I'll report this problem to the author of the regex
engine.
Thanks.
Previous Comments:
[2004-02-13 10:09:04] [EMAIL PROTECTED]
Moriyoshi, maybe you could take a look?
[2003-12-19 20:58:00] behrens at takenet dot de
Description:
When compiling the php5b3 with mbstring support on a recent IRIX
version with latest mips cc 7.4.1 spells out some errors.
cc-1020 cc: ERROR File =
/usr2/MIPS/php-5.0.0b3RC2/ext/mbstring/oniguruma/regerror.c, Line =
149
The identifier code is undefined.
regex_error_code_to_str(UChar* s, code, va_alist)
^
cc-1020 cc: ERROR File =
/usr2/MIPS/php-5.0.0b3RC2/ext/mbstring/oniguruma/regerror.c, Line =
149
The identifier va_alist is undefined.
regex_error_code_to_str(UChar* s, code, va_alist)
^
cc-1137 cc: ERROR File =
/usr2/MIPS/php-5.0.0b3RC2/ext/mbstring/oniguruma/regerror.c, Line =
149
Unnamed prototyped parameters not allowed when body is present.
regex_error_code_to_str(UChar* s, code, va_alist)
^
cc-1129 cc: ERROR File =
/usr2/MIPS/php-5.0.0b3RC2/ext/mbstring/oniguruma/regerror.c, Line =
150
A left brace ({) is expected at this point.
int code;
^
cc-1012 cc: WARNING File =
/usr2/MIPS/php-5.0.0b3RC2/ext/mbstring/oniguruma/regerror.c, Line =
153
Parsing restarts here after previous syntax error.
{
^
cc-1020 cc: ERROR File =
/usr2/MIPS/php-5.0.0b3RC2/ext/mbstring/oniguruma/regerror.c, Line =
159
The identifier va_alist is undefined.
va_init_list(vargs, code);
^
cc-1020 cc: ERROR File =
/usr2/MIPS/php-5.0.0b3RC2/ext/mbstring/oniguruma/regerror.c, Line =
161
The identifier code is undefined.
switch (code) {
^
cc-1515 cc: WARNING File =
/usr2/MIPS/php-5.0.0b3RC2/ext/mbstring/oniguruma/regerror.c, Line =
166
A value of type char * cannot be assigned to an entity of type
UChar *.
q = regex_error_code_to_format(code);
^
cc-1515 cc: WARNING File =
/usr2/MIPS/php-5.0.0b3RC2/ext/mbstring/oniguruma/regerror.c, Line =
197
A value of type char * cannot be assigned to an entity of type
UChar *.
q = regex_error_code_to_format(code);
^
cc-1164 cc: WARNING File =
/usr2/MIPS/php-5.0.0b3RC2/ext/mbstring/oniguruma/regerror.c, Line =
198
Argument of type UChar * is incompatible with parameter of type
const char *.
len = strlen(q);
^
unable to proceed because of earlier errors
6 errors detected in the compilation of
/usr2/MIPS/php-5.0.0b3RC2/ext/mbstring/oniguruma/regerror.c.
[octane]:/usr2/MIPS/php-5.0.0b3RC2 $ cat config.nice.cli
#! /bin/sh
#
# Created by configure
rm config.cache
gmake distclean
CFLAGS='-O3 -apo -mp -mips4 -OPT:Olimit=0 -TARG:platform=IP30
-Xcpluscomm -I/usr/local/include -I/usr/freeware/include
-I/usr/include' \
CXXFLAGS='-O3 -mips4' \
LDFLAGS='-mp -W,rpath=/usr/freeware/lib32 -W,rpath=/usr/lib32 ' \
CC='cc' \
CXX='CC' \
'./configure' \
'--enable-wddx' \
'--enable-sysvmsg' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-tokenizer' \
'--enable-mbstring' \
'--enable-mbregex' \
'--enable-dbase' \
'--with-sqlite ' \
'--enable-sockets' \
$@
I hope someone can take a look on it
--
Edit this bug report at http://bugs.php.net/?id=26677edit=1
#27383 [Csd-Opn]: uninitialized memory in http_fopen_wrapper.c error handling
ID: 27383
User updated by: remijnj at eidetica dot com
Reported By: remijnj at eidetica dot com
-Status: Closed
+Status: Open
Bug Type: HTTP related
Operating System: Linux (Slackware 9.1)
PHP Version: 4.3.5RC3
New Comment:
It does reach that line if php_stream_eof(stream) evaluates to true
(seems to happen if the sending of the request times out or something).
I've seen it happen and my patch easily fixes the problem of printing
uninitialized data in that does not contain any '\0' char.
I'm not sure how the code all works but i've seen this exact error with
the HTTP request failed! bit and i don't see this string anywhere
else in the source so i'm pretty sure it reaches it. I could be
mistaken about why it is still unitialized though.
Point is i have applied this patch in our server and the errors are now
printed without the garbage bytes.
Joost
Previous Comments:
[2004-02-25 16:30:23] [EMAIL PROTECTED]
In the CVS it cannot reach that line, if tmp_line is 9
then response_code is set to 0 and the code terminates
before that line is reached. In all other instances
tmp_line will contain a null terminated string.
[2004-02-25 15:09:45] remijnj at eidetica dot com
I reopened the bug because the tmp_line is still not initialized. See
my previous comment (forgot to open the bug again) which has a simple
patch from cvs diff -u.
Joost
[2004-02-24 17:51:34] remijnj at eidetica dot com
Thanks for adding it to CVS so quickly. I got the cvs version checked
out now and i notice one important bit missing (because i didn't
explain it properly i guess).
My initial problem (garbage bytes in HTTP request failed error) is
still there as far as i can see from the code. Let me explain.
The line :
php_stream_wrapper_log_error(wrapper, options TSRMLS_CC, HTTP request
failed! %s, tmp_line);
can be reached with tmp_line uninitialized. That is why i added the
'tmp_line[0] = '\0';' at the start of the function. Here an incremental
patch on top of this.
Index: ext/standard/http_fopen_wrapper.c
===
RCS file: /repository/php-src/ext/standard/http_fopen_wrapper.c,v
retrieving revision 1.53.2.15
diff -u -r1.53.2.15 http_fopen_wrapper.c
--- ext/standard/http_fopen_wrapper.c 24 Feb 2004 21:53:56 -
1.53.2.15
+++ ext/standard/http_fopen_wrapper.c 24 Feb 2004 22:51:56 -
@@ -107,6 +107,8 @@
size_t chunk_size = 0, file_size = 0;
int eol_detect, have_header = 0;
+ tmp_line[0] = '\0';
+
if (redirect_max 1) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Circular
redirect, aborting.);
return NULL;
[2004-02-24 16:46:30] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2004-02-24 14:19:26] remijnj at eidetica dot com
Here the patch which fixes it. I hope i've done it in the right patch
format (diff -urN).
diff -urN php-4.3.5RC3/ext/standard/http_fopen_wrapper.c
php-4.3.5RC3-mine/ext/standard/http_fopen_wrapper.c
--- php-4.3.5RC3/ext/standard/http_fopen_wrapper.c 2003-11-28
19:51:14.0 +0100
+++ php-4.3.5RC3-mine/ext/standard/http_fopen_wrapper.c 2004-02-24
19:51:07.0 +0100
@@ -107,6 +107,7 @@
size_t chunk_size = 0, file_size = 0;
int eol_detect, have_header = 0;
+ tmp_line = '\0';
if (redirect_max 1) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Circular redirect,
aborting.);
return NULL;
@@ -345,11 +346,24 @@
if (php_stream_gets(stream, tmp_line, sizeof(tmp_line)-1) !=
NULL) {
zval *http_response;
int response_code;
+ int tmp_line_len;
+
+ tmp_line_len = strlen(tmp_line);
MAKE_STD_ZVAL(http_response);
ZVAL_NULL(http_response);
- response_code = atoi(tmp_line + 9);
+ if (tmp_line_len 9) {
+ response_code = atoi(tmp_line + 9);
+ } else {
+ /*
+* short http_response, if not caught like
+* this we'd pass uninitialized memory to
+
#27368 [Asn-Csd]: php.ini-(dist|recommended) have CR at end
ID: 27368 Updated by: [EMAIL PROTECTED] Reported By: danielc at analysisandsolutions dot com -Status: Assigned +Status: Closed Bug Type: *Configuration Issues Operating System: Windows 2000 PHP Version: 5CVS-2004-02-23 (dev) Assigned To: wez New Comment: Should be fixed in a few hours when next snapshot is due. Previous Comments: [2004-02-25 16:15:46] [EMAIL PROTECTED] Propably important note: This only happens with PHP 5 snaps, not PHP 4.. [2004-02-25 16:05:36] [EMAIL PROTECTED] The ini files indeed are borked. Quite weird. [2004-02-23 13:48:16] [EMAIL PROTECTED] I have no idea about this. Assigning to Wez who introduced this bug too. [2004-02-23 13:21:52] danielc at analysisandsolutions dot com Where were you looking? In CVS or in the files distributed in a php5-win32-200402231530 snapshot? They are definitely there in the snapshot. I can email you the files if you don't believe me. This may be due to the new build system, which when it went into effect threw in loads of CR's even though the raw files in CVS were fine. I posted a note to internals and it seems someone fixed something to make all but one of the CR's disappeared. [2004-02-23 13:17:01] [EMAIL PROTECTED] In CVS: ; tab-width: 4 ; End: (there is no CR there) 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/27368 -- Edit this bug report at http://bugs.php.net/?id=27368edit=1
#21197 [Asn-Fbk]: socket_read() outputs error with PHP_NORMAL_READ
ID: 21197
Updated by: [EMAIL PROTECTED]
Reported By: bool at boolsite dot net
-Status: Assigned
+Status: Feedback
Bug Type: Sockets related
Operating System: win32 only
PHP Version: 4CVS
Assigned To: wez
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Bug #21760 was fixed, and it's pretty likely this is the same issue.
Previous Comments:
[2004-01-10 20:30:41] [EMAIL PROTECTED]
Assigning to Wez who might know why streams are borked.
[2003-12-15 11:11:42] nunoplopes at sapo dot pt
I'm using latest snapshot and I have the same problem. With
PHP_BINARY_READ everything works but with PHP_NORMAL_READ I receive the
following error:
Warning: socket_read() unable to read from socket [0]: The operation
completed s
uccessfully.
[2003-08-26 02:00:58] bool at boolsite dot net
Ok, this is a short example : (a little echo server)
?php
error_reporting(E_ALL);
$Port=6669;
if(($Sock=socket_create(AF_INET,SOCK_STREAM,0))=0) {
echo 'socket_create() a échoué :
',socket_strerror(socket_last_error($Sock)),\r\n;
exit;
}
if(($Ret=socket_bind($Sock,0,$Port))=0) {
echo 'socket_bind() a échoué :
',socket_strerror(socket_last_error($Ret)),\r\n;
exit;
}
if(($Ret=socket_listen($Sock,5))=0) {
echo 'socket_listen() a échoué :
',socket_strerror(socket_last_error($Ret)),\r\n;
exit;
}
while(true){
$MsgSock=socket_accept($Sock);
if($MsgSock===false) {
echo 'socket_accept() a échoué :
',socket_strerror(socket_last_error($MsgSock)),\r\n;
break;
}
else {
echo '= Debut de la connexion...',\r\n;
$EndTime=time()+15;
do{
$buffer=socket_read($MsgSock,1024,PHP_NORMAL_READ);
if($buffer===false) {
echo 'socket_read() a échoué :
',socket_strerror(socket_last_error($MsgSock)),\r\n;
break;
}
elseif(!$buffer){
continue;
}
$buffer=trim($buffer);
echo ' ',$buffer,\r\n;
if($buffer=='quit') {
break;
}
$back='You sent : ['.$buffer.']';
echo ' ',$back,\r\n;
socket_write($MsgSock,$back.\r\n);
} while(time()$EndTime);
@socket_close($MsgSock);
echo '= End...',\r\n;
}
}
socket_close($Sock);
?
[2003-08-25 20:17:06] [EMAIL PROTECTED]
Please provide a complete but short example script that can be used to
reproduce this bug.
[2003-08-25 18:19:27] bool at boolsite dot net
It's not the same bugs than http://bugs.php.net/bug.php?id=21760 . Here
it's a Win32 PHP version bug only, since the PHP 4.3.0 version, and
there is always the bug in the last version 4.3.3.
socket_read() always return FALSE, and display this error : erreur [0]
avec socket_read : OpÚration rÚussie.
(in english it should be error [0] with socket_read : operation
completed.)
maybe it's because of the socket_select() before the socket_read() ?
PS : it affects all my codes, but only with PHP 4.3.x Win32 version. On
unix or with PHP 4.2.3 all works fine.
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/21197
--
Edit this bug report at http://bugs.php.net/?id=21197edit=1
#21197 [Fbk-Opn]: socket_read() outputs error with PHP_NORMAL_READ
ID: 21197
User updated by: bool at boolsite dot net
Reported By: bool at boolsite dot net
-Status: Feedback
+Status: Open
Bug Type: Sockets related
Operating System: win32 only
-PHP Version: 4CVS
+PHP Version: php 4.3.5RC4-dev
Assigned To: wez
New Comment:
it's again the same thing :
X-Powered-By: PHP/4.3.5RC4-dev
erreur [0] avec socket_read : OpÚration rÚussie.
Previous Comments:
[2004-02-25 18:38:44] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Bug #21760 was fixed, and it's pretty likely this is the same issue.
[2004-01-10 20:30:41] [EMAIL PROTECTED]
Assigning to Wez who might know why streams are borked.
[2003-12-15 11:11:42] nunoplopes at sapo dot pt
I'm using latest snapshot and I have the same problem. With
PHP_BINARY_READ everything works but with PHP_NORMAL_READ I receive the
following error:
Warning: socket_read() unable to read from socket [0]: The operation
completed s
uccessfully.
[2003-08-26 02:00:58] bool at boolsite dot net
Ok, this is a short example : (a little echo server)
?php
error_reporting(E_ALL);
$Port=6669;
if(($Sock=socket_create(AF_INET,SOCK_STREAM,0))=0) {
echo 'socket_create() a échoué :
',socket_strerror(socket_last_error($Sock)),\r\n;
exit;
}
if(($Ret=socket_bind($Sock,0,$Port))=0) {
echo 'socket_bind() a échoué :
',socket_strerror(socket_last_error($Ret)),\r\n;
exit;
}
if(($Ret=socket_listen($Sock,5))=0) {
echo 'socket_listen() a échoué :
',socket_strerror(socket_last_error($Ret)),\r\n;
exit;
}
while(true){
$MsgSock=socket_accept($Sock);
if($MsgSock===false) {
echo 'socket_accept() a échoué :
',socket_strerror(socket_last_error($MsgSock)),\r\n;
break;
}
else {
echo '= Debut de la connexion...',\r\n;
$EndTime=time()+15;
do{
$buffer=socket_read($MsgSock,1024,PHP_NORMAL_READ);
if($buffer===false) {
echo 'socket_read() a échoué :
',socket_strerror(socket_last_error($MsgSock)),\r\n;
break;
}
elseif(!$buffer){
continue;
}
$buffer=trim($buffer);
echo ' ',$buffer,\r\n;
if($buffer=='quit') {
break;
}
$back='You sent : ['.$buffer.']';
echo ' ',$back,\r\n;
socket_write($MsgSock,$back.\r\n);
} while(time()$EndTime);
@socket_close($MsgSock);
echo '= End...',\r\n;
}
}
socket_close($Sock);
?
[2003-08-25 20:17:06] [EMAIL PROTECTED]
Please provide a complete but short example script that can be used to
reproduce this bug.
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/21197
--
Edit this bug report at http://bugs.php.net/?id=21197edit=1
#27383 [Opn-Csd]: uninitialized memory in http_fopen_wrapper.c error handling
ID: 27383
Updated by: [EMAIL PROTECTED]
Reported By: remijnj at eidetica dot com
-Status: Open
+Status: Closed
Bug Type: HTTP related
Operating System: Linux (Slackware 9.1)
PHP Version: 4.3.5RC3
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2004-02-25 17:47:09] remijnj at eidetica dot com
It does reach that line if php_stream_eof(stream) evaluates to true
(seems to happen if the sending of the request times out or something).
I've seen it happen and my patch easily fixes the problem of printing
uninitialized data in that does not contain any '\0' char.
I'm not sure how the code all works but i've seen this exact error with
the HTTP request failed! bit and i don't see this string anywhere
else in the source so i'm pretty sure it reaches it. I could be
mistaken about why it is still unitialized though.
Point is i have applied this patch in our server and the errors are now
printed without the garbage bytes.
Joost
[2004-02-25 16:30:23] [EMAIL PROTECTED]
In the CVS it cannot reach that line, if tmp_line is 9
then response_code is set to 0 and the code terminates
before that line is reached. In all other instances
tmp_line will contain a null terminated string.
[2004-02-25 15:09:45] remijnj at eidetica dot com
I reopened the bug because the tmp_line is still not initialized. See
my previous comment (forgot to open the bug again) which has a simple
patch from cvs diff -u.
Joost
[2004-02-24 17:51:34] remijnj at eidetica dot com
Thanks for adding it to CVS so quickly. I got the cvs version checked
out now and i notice one important bit missing (because i didn't
explain it properly i guess).
My initial problem (garbage bytes in HTTP request failed error) is
still there as far as i can see from the code. Let me explain.
The line :
php_stream_wrapper_log_error(wrapper, options TSRMLS_CC, HTTP request
failed! %s, tmp_line);
can be reached with tmp_line uninitialized. That is why i added the
'tmp_line[0] = '\0';' at the start of the function. Here an incremental
patch on top of this.
Index: ext/standard/http_fopen_wrapper.c
===
RCS file: /repository/php-src/ext/standard/http_fopen_wrapper.c,v
retrieving revision 1.53.2.15
diff -u -r1.53.2.15 http_fopen_wrapper.c
--- ext/standard/http_fopen_wrapper.c 24 Feb 2004 21:53:56 -
1.53.2.15
+++ ext/standard/http_fopen_wrapper.c 24 Feb 2004 22:51:56 -
@@ -107,6 +107,8 @@
size_t chunk_size = 0, file_size = 0;
int eol_detect, have_header = 0;
+ tmp_line[0] = '\0';
+
if (redirect_max 1) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, Circular
redirect, aborting.);
return NULL;
[2004-02-24 16:46:30] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
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/27383
--
Edit this bug report at http://bugs.php.net/?id=27383edit=1
#27373 [Opn-Bgs]: Apache vs 1.3.27 and 1.3.29 with PHP 4.3.4 and 4.2.2 - libphp4.so not created
ID: 27373 Updated by: [EMAIL PROTECTED] Reported By: mattm at mattm dot net -Status: Open +Status: Bogus -Bug Type: Reproducible crash +Bug Type: Compile Failure Operating System: Solaris 5.7 Sparc PHP Version: 4.3.4 New Comment: If you follow the instructions in the INSTALL file for static build (and EXACTLY like it said there! Use _fresh_ apache sources!) it will work. Please ask further support questions elsewhere, there is no bug here. (libphp4.so is created ONLY when you use --with-apxs and have DSO enabled Apache) Previous Comments: [2004-02-25 17:25:52] mattm at mattm dot net Thanks for the speedy reply -- I started with a very basic httpd.conf file, as this server is to have only two directories (Nagios install w/ php). I have wound up blowing away apache completely, and just trying to get it to work with the newly compiled Apache/PHP combo. Note that Apache compiles and works without PHP. As soon as I add it in I get probs. Just no I tried the same steps, omiting the --active-module=php4 line. Same results. The /usr/local/apache/libexec directory is empty The PHP entries for LoadModule / ClearModule were not added to httpd.conf [2004-02-24 04:47:14] [EMAIL PROTECTED] What exactly do you have in httpd.conf ? And I don't think you need --enable-module=php4 in the last phase for Apache.. [2004-02-23 18:31:54] mattm at mattm dot net Description: Apache vs 1.3.27 and 1.3.29 with PHP 4.3.4 and 4.2.2 I'm almost bald now -- pulling out my hair for a week on this one. I have gone through all the bug-reports and tried all sorts of combinations. I am using the latest stable release from the website. Preconfigure APACHE # cd apache_1.3.27 # ./configure --prefix=/usr/local/apache PHP # cd php-4.3.3 # ./configure --with-apache=../apache_1.3.27 # make # make install # cp php.ini-dist /usr/local/lib/php.ini APACHE Final Install # cd apache_1.3.27 # ./configure --activate-module=src/modules/php4/libphp4.a \ --enable-module=php4 \ --prefix=/usr/local/apache \ # make # make install Error conditions now: a) The /usr/local/apache/libexec folder is empty. b) The htpasswd tool core-dumps c) httpd will not start when php4 is referenced in httpd.conf Things tried: a) configure, make, change libtool: build_libtool_libs=yes, make install -- the libphp4.so.0 is not in .libs as the workarounds indicate b) varios combinations of Apache and PHP as listed above. -- Edit this bug report at http://bugs.php.net/?id=27373edit=1
#27399 [Opn-Bgs]: Object copy neither shallow nor deep
ID: 27399
Updated by: [EMAIL PROTECTED]
Reported By: php dot bugs at darwin dot no-ip dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux 2.4.18
PHP Version: 4.3.4
New Comment:
To get the expected result, change every = new to = new.
Previous Comments:
[2004-02-25 16:39:02] php dot bugs at darwin dot no-ip dot com
Description:
Copying an object doesn't appear to work as expected for either a
shallow or a deep copy.
Reproduce code:
---
class Dummy {}
$listA = new Dummy();
$listA-next = new Dummy();
$listA-next-previous = $listA;
$listA-value = one;
$listA-next-value = two;
$listA-next-previous-value = ONE;
echo ListA: ;
echo ( . $listA-value . , . $listA-next-value . ) \n;
$listB = $listA;
$listB-value = three;
$listB-next-value = four;
$listB-next-previous-value=THREE;
echo (modified listB)\n;
echo ListA: ;
echo ( . $listA-value . , . $listA-next-value . ) \n;
echo ListB: ;
echo ( . $listB-value . , . $listB-next-value . ) \n;
Expected result:
Expected output: (ie: if PHP does a deep copy)
ListA: (ONE, two)
(modified listB)
ListA: (ONE, two)
ListB: (three, four)
This should happen because $listB-next-previous is a copy of the
reference
to $listA. Modifying it should not modify ListA OR ListB.
Possible (wrong) output: (if PHP had done a shallow copy)
ListA: (ONE, two)
(modified listB)
ListA: (THREE, four)
ListB: (three, four)
This would be the case because listB's next would be a reference to
ListA's
next.
Actual result:
--
Actual output:
ListA: (ONE, two)
(modified listB)
ListA: (THREE, two)
ListB: (three, four)
This looks like PHP did something between a shallow and a deep copy.
while ListB-next is a copy, ListB-next-previous still points at
ListA. (!?!)
... For an added bonus, try replacing '= new' with '= new' and it
looks like
PHP does a shallow copy. From my reading of PHP documentation, I
thought PHP would always do deep (de-referencing) copies.
--
Edit this bug report at http://bugs.php.net/?id=27399edit=1
#27395 [Asn-Bgs]: reference to an array index makes the array to be passed by reference always
ID: 27395
Updated by: [EMAIL PROTECTED]
Reported By: jamesn at tocquigny dot com
-Status: Assigned
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 4CVS, 5CVS (2004-02-25
Assigned To: zeev
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
See bug #20993 (where you seem to have got the example too..)
Previous Comments:
[2004-02-25 13:39:51] [EMAIL PROTECTED]
Wrong test, this was the one:
?php
function theFunction($arg) {
$arg[0] = 2;
}
// Reference on array index
$arr1 = array (1);
$reference1 = $arr1[0];
var_dump($reference1);
var_dump($arr1);
theFunction($arr1);
var_dump($reference1);
var_dump($arr1);
echo \n;
// Reference on array
$arr2 = array (1);
$reference2 = $arr2;
var_dump($reference2);
var_dump($arr2);
theFunction($arr2);
var_dump($reference2);
var_dump($arr2);
?
[2004-02-25 12:02:02] jamesn at tocquigny dot com
Description:
There appears to be a problem with php that doesn't allow arrays to be
passed by value. The fix appears to be something similar to:
http://bugs.php.net/bug.php?id=6417
if (PZVAL_IS_REF(*p))
{
SEPARATE_ZVAL(p);
} else {
zval_add_ref(p);
}
It would appear that that logic is missing in one place or another. I
could not track it down myself. Code similar to this appears to be
copy/pasted in various places.
Reproduce code:
---
$array = array(1);
// This line makes the call to theFunction() act as if passed by ref.?
$reference = $array[0];
echo $array[0], 'br';
theFunction($array);
echo $array[0], 'br';
function theFunction($array) {
$array[0] = 2;
}
Expected result:
you should get 1 and 1
Actual result:
--
instead you get 1 and 2!
--
Edit this bug report at http://bugs.php.net/?id=27395edit=1
#27399 [Bgs]: Object copy neither shallow nor deep
ID: 27399
User updated by: php dot bugs at darwin dot no-ip dot com
Reported By: php dot bugs at darwin dot no-ip dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux 2.4.18
PHP Version: 4.3.4
New Comment:
How is that not a bug? Documentation leads the user to believe that =
new and = new only differ in efficiency.
While I see that copying an object with references inside of it might
break those references, Dummy() has no internal references. It seems
the copy of Dummy() should work just as well as the original.
Previous Comments:
[2004-02-25 19:30:46] [EMAIL PROTECTED]
To get the expected result, change every = new to = new.
[2004-02-25 16:39:02] php dot bugs at darwin dot no-ip dot com
Description:
Copying an object doesn't appear to work as expected for either a
shallow or a deep copy.
Reproduce code:
---
class Dummy {}
$listA = new Dummy();
$listA-next = new Dummy();
$listA-next-previous = $listA;
$listA-value = one;
$listA-next-value = two;
$listA-next-previous-value = ONE;
echo ListA: ;
echo ( . $listA-value . , . $listA-next-value . ) \n;
$listB = $listA;
$listB-value = three;
$listB-next-value = four;
$listB-next-previous-value=THREE;
echo (modified listB)\n;
echo ListA: ;
echo ( . $listA-value . , . $listA-next-value . ) \n;
echo ListB: ;
echo ( . $listB-value . , . $listB-next-value . ) \n;
Expected result:
Expected output: (ie: if PHP does a deep copy)
ListA: (ONE, two)
(modified listB)
ListA: (ONE, two)
ListB: (three, four)
This should happen because $listB-next-previous is a copy of the
reference
to $listA. Modifying it should not modify ListA OR ListB.
Possible (wrong) output: (if PHP had done a shallow copy)
ListA: (ONE, two)
(modified listB)
ListA: (THREE, four)
ListB: (three, four)
This would be the case because listB's next would be a reference to
ListA's
next.
Actual result:
--
Actual output:
ListA: (ONE, two)
(modified listB)
ListA: (THREE, two)
ListB: (three, four)
This looks like PHP did something between a shallow and a deep copy.
while ListB-next is a copy, ListB-next-previous still points at
ListA. (!?!)
... For an added bonus, try replacing '= new' with '= new' and it
looks like
PHP does a shallow copy. From my reading of PHP documentation, I
thought PHP would always do deep (de-referencing) copies.
--
Edit this bug report at http://bugs.php.net/?id=27399edit=1
#27389 [Fbk-Opn]: $_POST variables not accessible from multiview
ID: 27389 User updated by: vanlei at yahoo dot com Reported By: vanlei at yahoo dot com -Status: Feedback +Status: Open Bug Type: Apache related Operating System: Mac OS X PHP Version: 4.3.4 New Comment: Apache: Server version: Apache/1.3.29 (Darwin) httpd.conf: Inside the config for the site, you need to add: Directory /site/to/www Options MultiViews /Directory PHP is configured as an apache mod. Version 4.3.4 Previous Comments: [2004-02-25 05:56:33] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. Apache version, how to configure httpd.conf, how PHP is configured (module/cgi), etc. [2004-02-24 23:55:29] vanlei at yahoo dot com Description: $_POST variables aren't accessible from within a multiview if one configures the action of a form to be the child of a multiview. In other words, If I set the action of a form to be 'example.com/multi/sub' where multi is a PHP file called multi.php that catches the url 'example.com/ multi/sub/' (by using apache's multiviews), multi.php will not have access to the $_POST variable. It works if one sets the action as 'example.com/multi/ '. Reproduce code: --- Example code: form method=post action=http://example.com/multi/sub/; name=form input type=submit name=submit value=Value / /form multi.php: echo $_POST['submit'] Expected result: Expected: $_POST['submit'] == Value Actual result: -- Blank. I think PHP associates the $_POST variable with /multi/sub when sub isn't a script/file. Instead the request is handled by multi. -- Edit this bug report at http://bugs.php.net/?id=27389edit=1
#27398 [Opn-Ver]: Installing PEAR (go-pear.bat) causes Application Error
ID: 27398 Updated by: [EMAIL PROTECTED] Reported By: WPinegar at healthtech dot net -Status: Open +Status: Verified -Bug Type: *General Issues +Bug Type: Zend Engine 2 problem -Operating System: Windows Server 2003 +Operating System: * -PHP Version: 5CVS-2004-02-25 (dev) +PHP Version: 5CVS-2004-02-26 New Comment: Here's the callstack when you run go-pear.bat: zend_fetch_obj_w_handler(_zend_execute_data * 0x0012f788, _zend_op * 0x015985c8, _zend_op_array * 0x01595ad8, void * * * 0x00972980) line 2044 + 12 bytes execute(_zend_op_array * 0x01595ad8, void * * * 0x00972980) line 1339 + 23 bytes zend_do_fcall_common_helper(_zend_execute_data * 0x0012f910, _zend_op * 0x015995c8, _zend_op_array * 0x01594868, void * * * 0x00972980) line 2675 + 34 bytes zend_do_fcall_by_name_handler(_zend_execute_data * 0x0012f910, _zend_op * 0x015995c8, _zend_op_array * 0x01594868, void * * * 0x00972980) line 2757 + 21 bytes execute(_zend_op_array * 0x01594868, void * * * 0x00972980) line 1339 + 23 bytes zend_do_fcall_common_helper(_zend_execute_data * 0x0012fa98, _zend_op * 0x00c1fd88, _zend_op_array * 0x00a9f818, void * * * 0x00972980) line 2675 + 34 bytes zend_do_fcall_by_name_handler(_zend_execute_data * 0x0012fa98, _zend_op * 0x00c1fd88, _zend_op_array * 0x00a9f818, void * * * 0x00972980) line 2757 + 21 bytes execute(_zend_op_array * 0x00a9f818, void * * * 0x00972980) line 1339 + 23 bytes zend_execute_scripts(int 8, void * * * 0x00972980, _zval_struct * * 0x, int 3) line 1041 + 34 bytes php_execute_script(_zend_file_handle * 0x0012ff48, void * * * 0x00972980) line 1650 + 27 bytes main(int 3, char * * 0x00972580) line 941 + 17 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e814c7() Previous Comments: [2004-02-25 16:12:40] WPinegar at healthtech dot net Description: While attempting to install PEAR via the command go-pear.bat (found in the \PHP directory) I received an application error in php.exe module php5ts.dll and PEAR does not extract properly. Reproduce code: --- Attempt to install PEAR via the command line utility go-pear.bat. You will receive an application error and PEAR will not extract properly. Expected result: PEAR should extract and install correctly. -- Edit this bug report at http://bugs.php.net/?id=27398edit=1
#27185 [Opn-Ver]: mysql_pconnect() causes a crash during shutdown
ID: 27185 Updated by: [EMAIL PROTECTED] Reported By: andrey at cherezov dot koenig dot su -Status: Open +Status: Verified Bug Type: MySQL related Operating System: win32 PHP Version: 4CVS, 5CVS (2004-02-23) New Comment: Unfortunately this works with debug build so I can not get a backtrace. Previous Comments: [2004-02-21 05:32:54] andrey at cherezov dot koenig dot su Btw, may be this helps, this script with the PHP 5 beta4 output this: H:\php\php-5.0.0b4-Win32\php.exe test.php PHP Warning: Unknown persistent list entry type in module shutdown (22) in Unknown on line 0 And with PHP 5 beta3 it also unable to work: window entry point mysql_character_set_name not found in DLL libmysql.dll. If I replace mysql_Pconnect with the mysql_connect - it works w/o error with PHP5 beta4 and with PHP 4.3.5rc4-dev OK too!! !!! Resume: there is problem in the cleanup code after usage of function mysql_Pconnect() !!! [2004-02-21 05:17:47] andrey at cherezov dot koenig dot su !!! Try this script: test.php ? mysql_pconnect( localhost, root, ); ? -- Run php.exe test.php It writes its output H:\php\php-4.3.5php.exe test.php Content-type: text/html X-Powered-By: PHP/4.3.5RC4-dev and then application failure window appears with bug info about php.exe+ntdll.dll [2004-02-08 17:59:11] andrey at cherezov dot koenig dot su Description: After installing PHP 4.3.5rc2 instead of 'old' stable 4.3.4 on my Win2003 Server Application Event Log started to fill with this report lines: = Event Type: Error Event Source: Application Error Event Category: (100) Event ID: 1000 Date: 08.02.2004 Time: 10:20:29 User: N/A Description: Faulting application php.exe, version 4.3.5.5, faulting module ntdll.dll, version 5.2.3790.0, fault address 0x7300.For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: Application Failure php.exe 4.3.5.5 in ntdll.dll 5.2.3790.0 at offset 7300 = About 1700 such events in past 6 hours. On my acWEB web-server PHP works in CGI mode. Now I've rolled back 4.3.4, and no more errors added to Event log. Reproduce code: --- Web-query to ANY php page on my site. Expected result: Expected no errors in Event log. Actual result: -- The script itself works w/o problems - result pages displayed OK. Seems this fault happens when PHP.EXE finished its work. -- Edit this bug report at http://bugs.php.net/?id=27185edit=1
#27381 [Com]: unset affects copies of an array
ID: 27381 Comment by: postings-php-bug at hans-spath dot de Reported By: abk at avatartechnology dot com Status: Feedback Bug Type: Arrays related Operating System: Win 2K pro PHP Version: 4.3.4 New Comment: I can't reproduce this under Windows XP (CLI) or Linux (Apache2 module). Version 4.3.4. Previous Comments: [2004-02-24 14:26:34] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Works fine for me... [2004-02-24 13:25:56] abk at avatartechnology dot com Description: Unsetting an element of an array unsets that element in copies of the array. This does not happen if you change the array or its copy in some other way after making the copy and before doing the unset. I haven't tested whether this affects other non-atomic types like objects, but it wouldn't surprise me if it does. My educated guess is there is some copy-on-write optomization that (wrongly) does not consider unset to be a write. Reproduce code: --- $x = array(1,2); $y = $x; # uncommenting the next line fixes the bug: #$x[0] = $x[0]; unset($x[0]); print_r($y); Expected result: Array(0=1,1=2) Actual result: -- Array(1=2) -- Edit this bug report at http://bugs.php.net/?id=27381edit=1
#27185 [Ver]: persistent resource destruction crashes
ID: 27185 Updated by: [EMAIL PROTECTED] -Summary: mysql_pconnect() causes a crash during shutdown Reported By: andrey at cherezov dot koenig dot su Status: Verified -Bug Type: MySQL related +Bug Type: Scripting Engine problem Operating System: win32 PHP Version: 4CVS, 5CVS (2004-02-26) New Comment: This causes the exactly same crash: ?php pfsockopen(www.php.net, 80, $errno, $errstr, 30); ? Previous Comments: [2004-02-25 23:53:29] [EMAIL PROTECTED] Unfortunately this works with debug build so I can not get a backtrace. [2004-02-21 05:32:54] andrey at cherezov dot koenig dot su Btw, may be this helps, this script with the PHP 5 beta4 output this: H:\php\php-5.0.0b4-Win32\php.exe test.php PHP Warning: Unknown persistent list entry type in module shutdown (22) in Unknown on line 0 And with PHP 5 beta3 it also unable to work: window entry point mysql_character_set_name not found in DLL libmysql.dll. If I replace mysql_Pconnect with the mysql_connect - it works w/o error with PHP5 beta4 and with PHP 4.3.5rc4-dev OK too!! !!! Resume: there is problem in the cleanup code after usage of function mysql_Pconnect() !!! [2004-02-21 05:17:47] andrey at cherezov dot koenig dot su !!! Try this script: test.php ? mysql_pconnect( localhost, root, ); ? -- Run php.exe test.php It writes its output H:\php\php-4.3.5php.exe test.php Content-type: text/html X-Powered-By: PHP/4.3.5RC4-dev and then application failure window appears with bug info about php.exe+ntdll.dll [2004-02-08 17:59:11] andrey at cherezov dot koenig dot su Description: After installing PHP 4.3.5rc2 instead of 'old' stable 4.3.4 on my Win2003 Server Application Event Log started to fill with this report lines: = Event Type: Error Event Source: Application Error Event Category: (100) Event ID: 1000 Date: 08.02.2004 Time: 10:20:29 User: N/A Description: Faulting application php.exe, version 4.3.5.5, faulting module ntdll.dll, version 5.2.3790.0, fault address 0x7300.For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: Application Failure php.exe 4.3.5.5 in ntdll.dll 5.2.3790.0 at offset 7300 = About 1700 such events in past 6 hours. On my acWEB web-server PHP works in CGI mode. Now I've rolled back 4.3.4, and no more errors added to Event log. Reproduce code: --- Web-query to ANY php page on my site. Expected result: Expected no errors in Event log. Actual result: -- The script itself works w/o problems - result pages displayed OK. Seems this fault happens when PHP.EXE finished its work. -- Edit this bug report at http://bugs.php.net/?id=27185edit=1
#26315 [Com]: mssql_fectch_* functions are returning a space char on empty fields
ID: 26315 Comment by: dneilsen at iprimus dot com dot au Reported By: webmaster at cbre dot fr Status: Bogus Bug Type: MSSQL related Operating System: Windows 2000 Server PHP Version: 4.3.4 New Comment: I too have encountered this bug with windows 2003 server using version 4.3.4 of php. Where as previously my empty varchar fields where returned as '' they are now returned as ' ' which has caused several of my applications to fail. Previous Comments: [2003-12-01 20:29:11] php at electricsurfer dot com THIS IS A BUG new to 4.3.4. Introduced by removing the auto-trimming While the change is a good one, if '' is in the DB, mssql_fetch_* should NOT return ' ' IN DB: '' (empty string) Returned by mssql_fetch_assoc(): ' ' (single space) [2003-11-21 11:33:13] jabberwocky at ibplanet dot com also, instead of returning 0 it is now also returning a space if there is a 0 in the DB [2003-11-21 07:56:06] w1lz0r at barrysworld dot net This is a bug, as there is no space in the database. The change from not auto-trimming is a good one IMO, but the behaviour of empty fields is different now. Any character field which is empty (e.g. '') and not null will be returned as a space. My application no longer worked correctly after the 4.3.4 change and I have to now manually do (if ($field==' ') $field='';). This is a major change from previous versions and a bug as the mssql functions should return what is IN the database. Maybe this is the reason why the rtrim was done in the past? Please re-evaluate. [2003-11-19 09:42:17] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php mssql extension no longer automatically trims varchar fields [2003-11-19 07:20:52] webmaster at cbre dot fr Description: mssql_fectch_* functions are returning a space char when selecting empty fields. The problem does not occur where MSSQL table fields are set to NULL value insteed of empty. It was not working this way with PHP 4.3.2 and previous versions. I can't see nothing in the change log about this. Kind regards Clement -- Edit this bug report at http://bugs.php.net/?id=26315edit=1
#27185 [Ver]: persistent resource destruction crashes
ID: 27185 Updated by: [EMAIL PROTECTED] Reported By: andrey at cherezov dot koenig dot su Status: Verified Bug Type: Scripting Engine problem Operating System: * (with ZTS enabled!) PHP Version: 4CVS, 5CVS (2004-02-26) New Comment: This isn't windows specific but ZTS issue. Previous Comments: [2004-02-26 01:34:10] [EMAIL PROTECTED] This causes the exactly same crash: ?php pfsockopen(www.php.net, 80, $errno, $errstr, 30); ? [2004-02-21 05:17:47] andrey at cherezov dot koenig dot su !!! Try this script: test.php ? mysql_pconnect( localhost, root, ); ? -- Run php.exe test.php It writes its output H:\php\php-4.3.5php.exe test.php Content-type: text/html X-Powered-By: PHP/4.3.5RC4-dev and then application failure window appears with bug info about php.exe+ntdll.dll [2004-02-08 17:59:11] andrey at cherezov dot koenig dot su Description: After installing PHP 4.3.5rc2 instead of 'old' stable 4.3.4 on my Win2003 Server Application Event Log started to fill with this report lines: = Event Type: Error Event Source: Application Error Event Category: (100) Event ID: 1000 Date: 08.02.2004 Time: 10:20:29 User: N/A Description: Faulting application php.exe, version 4.3.5.5, faulting module ntdll.dll, version 5.2.3790.0, fault address 0x7300.For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: Application Failure php.exe 4.3.5.5 in ntdll.dll 5.2.3790.0 at offset 7300 = About 1700 such events in past 6 hours. On my acWEB web-server PHP works in CGI mode. Now I've rolled back 4.3.4, and no more errors added to Event log. Reproduce code: --- Web-query to ANY php page on my site. Expected result: Expected no errors in Event log. Actual result: -- The script itself works w/o problems - result pages displayed OK. Seems this fault happens when PHP.EXE finished its work. -- Edit this bug report at http://bugs.php.net/?id=27185edit=1
