#19349 [Fbk->NoF]: odbc_longreadlen() does not work
ID: 19349 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: ODBC related Operating System: SuSE 8.0 PHP Version: 4.2.1 New Comment: 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. Previous Comments: [2002-11-02 14:51:11] [EMAIL PROTECTED] can you please provide the full script sample for this? I think I do see what is wrong, but want to make sure. [2002-09-11 10:27:31] [EMAIL PROTECTED] I have a script that runs a select statement from a 10MB CLOB field (among others). I run the following : odbc_longreadlen($resultid, 300); Then I run: $document = odbc_result($resultid, 2); The problem is, $document ends up with 4096 bytes of data (the default, NOT 300). If I edit php.ini and set up odbc_lrl to 200 in there, then $document ends up with 2MBin it. It acts like the function odbc_longreadlen does not work at all. I don't know how much more information I can give other than odbc_longreadlen does not seem to do anything at all. [2002-09-11 09:49:21] [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. [2002-09-10 20:33:11] [EMAIL PROTECTED] I am using PHP with ODBC (IBM DB2) support and since upgrading to 4.2.1 from 4.0.4pl1, my odbc_longreadlen() function no longer works. I have to set it in the configuration file now, as that is the only place that it works properly. In addition, when it's set above 200 in the config file, httpd starts taking 75% of the CPU (system, not user) and the data never gets to PHP. Am I hitting some type of limitation? How else do I get my 10MB CLOB out of DB2? -- Edit this bug report at http://bugs.php.net/?id=19349&edit=1
#20219 [Fbk->NoF]: Socket dies if there's too much incoming data
ID: 20219 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Sockets related Operating System: Linux PHP Version: 4.2.1 New Comment: 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. Previous Comments: [2002-11-02 10:30:34] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Are your sockets using the sockets extension, or the native fsockopen calls? We can't really help unless you supply us with a self-contained script that illustrates the problem. Please try a snapshot (for the up and coming 4.3 release), and if you still experience problems, post a script that we can use to find out the cause. [2002-11-02 10:29:13] [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. Please supply a complete snippet with which we can reproduce the bug. [2002-11-02 10:20:37] [EMAIL PROTECTED] I'm working on a script to administrate half-life servers. When I try to dump a rules list, which consists of more then approx. 80 rules ( 1 Rule = 2 strings of about 20 and 3 chars ), the PHP script dies and waits forever. The same problem when I do a players dump and there are more than 16 players on a server. The fsockopen() and socket-functions don't seem too reliable, is there any possibility that this will change in the next versions? -- Edit this bug report at http://bugs.php.net/?id=20219&edit=1
#20215 [Fbk->NoF]: fputs(); (Line Feed / Carriage Return)
ID: 20215 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Filesystem function related Operating System: Windows 2000 PHP Version: 4.2.3 New Comment: 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. Previous Comments: [2002-11-01 16:16:31] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-01 16:05:39] [EMAIL PROTECTED] To every writings the function "fput" adds jumps of lines in too much. Sample script : -- Edit this bug report at http://bugs.php.net/?id=20215&edit=1
#20191 [Fbk->NoF]: Problems with mktime returns -1 value on some specific dates
ID: 20191 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Date/time related Operating System: FreeBSD 4.5-RELEASE #3 PHP Version: 4.2.2 New Comment: 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. Previous Comments: [2002-10-31 09:25:41] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-31 08:55:54] [EMAIL PROTECTED] echo mktime(0,0,0,10,33,2002); // returns 1036206000 echo mktime(0,0,0,10,34,2002); // returns -1 echo mktime(0,0,0,10,35,2002); // returns 1036375200 bug or what? the correct return for echo mktime(0,0,0,10,34,2002); is 1036290600 and not -1 ! -- Edit this bug report at http://bugs.php.net/?id=20191&edit=1
#20187 [Fbk->NoF]: serialize and __sleep function
ID: 20187
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Reproducible crash
Operating System: win2k /iis5
PHP Version: 4.2.3
New Comment:
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.
Previous Comments:
[2002-10-31 09:03:15] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
It still shouldn't cause Access Violation.
Could you check it with snapshot?
[2002-10-31 07:39:47] [EMAIL PROTECTED]
sorry !
it's a misreading of the __sleep function.
to solve the problem , you only just have to return an array
in this function.
However, i don't know why the server sen dme this message
[2002-10-31 05:05:25] [EMAIL PROTECTED]
i'm simply want to serialize a class wich contain
a __sleep function and i've got this message :
PHP has encountered an Access Violation at 019E7712
if i delete the __sleep function this message disappear.
config :
session_auto_start : off;
the following script reproduce the problem :
Sql = 1; }
}
session_save_path($GLOBALS['SessionPath']);
session_start();
list($action, $objet) = each($_GET);
switch($action){
case('start'):
$my_theme = new kuru_theme();
print 'essai';
$_SESSION['forum'] = serialize($my_theme);
break;
case('list'):
$my_theme = unserialize($_SESSION['forum']);
break;
}
?>
--
Edit this bug report at http://bugs.php.net/?id=20187&edit=1
#20186 [Fbk->NoF]: Segmentation fault (11) in recursive function call
ID: 20186
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Reproducible crash
Operating System: FreeBSD
PHP Version: 4.2.2
New Comment:
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.
Previous Comments:
[2002-10-31 09:05:14] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
Please try it with CVS version.
[2002-10-31 03:57:49] [EMAIL PROTECTED]
Sorry, might help to mention that I did try the function first without
using globals and returning the directory file_count and adding it up
and returning the total, also had the same problem.
[2002-10-31 03:50:10] [EMAIL PROTECTED]
I get this all the time when I include a recursive function call. I've
tried rewriting the function several ways and get intermitten
Segmentation faults, saw a SuSe Linux report about scripts terminating
with similar output in the web server error_log.
I"ve tried just opening the fh and going down recursive directories
with this, got the seg faults often.This version
buffers the file names in an array, closes the directory handle then
processes the array, to count certain types of files in the directory
tree. Still segfaults often enough to make it unreliable. I turned on
the autoflush in php.ini and it dies in this routine.
FreeBSD 4.5-RELEASE
Apache/1.3.26 (Unix) PHP/4.2.2 mod_ssl/2.8.9 OpenSSL/0.9.6g
RegisterGlobals = On :)
I use a perl script for my apache coplilation, here's my php_config
line.
--with-mysql=/usr/local --with-gd=/usr/local
--with-jpeg-dir=/usr/local/lib --with-png-dir=/usr/
local/lib --with-zlib-dir=/usr/lib $xpm
--with-freetype-dir=/usr/local/lib --with-mcrypt=/usr/local
--with-gettext --wit
h-xml --with-zlib=/usr --with-bz2=/usr/local --with-zip=/usr/local
--with-mm=/usr/local --with-apache=../$apache --enable-ftp
--disable-debug --enable-track-vars
Here's the current version of the function
function CountFiles($dir,$d) {
global $home;
global $prod_count;
$farray = array(); $d++;
if (is_dir("$home$dir")) {
print "\n";
if ($dfh = @opendir("$home$dir")) {
while (($fil = readdir($dfh)) !== false) {
if (!preg_match("/^\.+$/", $fil)) {
array_push($farray,"$fil");
}
}
closedir($dfh);
if (count($farray) > 0) {
while (list ($key, $file) = each ($farray)) {
if (is_dir("$home$dir/$file")) {
CountFiles("$dir/$file",$d);
flush();
} else if (preg_match("/^thumb_\w+\.|\.wav$|\.aif$/", $file)) {
$prod_count++;
print "\n";
flush();
}
}
}
}
}
flush();
}
It's not entirely reproducible, but once I got a directory where it
causes the segfault I can comment out this routine and it's okay,
comment it back and reload and it segfaults.
So in that sense it's reproducible. Restarting the web server has no
effect. Though if I reload enough times sometimes the script completes,
there is definitely some sort of bug, maybe the filehandle or array
declaration isn't local or leaks out, not sure.
Hope it's not something stupid I overlooked. :)
--
Edit this bug report at http://bugs.php.net/?id=20186&edit=1
#19731 [Fbk]: Compiler fails with --enable-sockets flag
ID: 19731 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Sockets related Operating System: SCO 5.0.5 PHP Version: 4.2.0 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Please try the more recent snapshot. Previous Comments: [2002-10-04 01:54:52] [EMAIL PROTECTED] Version php4-latest (php4-200210030300) : cc -Iext/sockets/ -I/u/stan/x/php4-200210030300/ext/sockets/ -DPHP_ATOM_INC-I/u/stan/x/php4-200210030300/include -I/u/stan/x/php4-200210030300/main -I/u/san/x/php4-200210030300 -I/u/stan/x/php4-200210030300/Zend -I/u/stan/x/php4-20020030300/ext/xml/expat -I/u/stan/x/php4-200210030300/TSRM -g -belf -c /u/stanx/php4-200210030300/ext/sockets/sockets.c -o ext/sockets/sockets.o && echo > et/sockets/sockets.lo "/u/stan/x/php4-200210030300/main/php_streams.h", line 311: warning: no macro rplacement within a string literal "/u/stan/x/php4-200210030300/main/php_streams.h", line 312: warning: no macro rplacement within a string literal "/usr/include/sys/regset.h", line 41: error: (struct) tag redeclared: _fpstate "/u/stan/x/php4-200210030300/ext/sockets/sockets.c", line 263: warning: argumen is incompatible with prototype: arg #3 "/u/stan/x/php4-200210030300/ext/sockets/sockets.c", line 383: error: undefined symbol: h_errno "/u/stan/x/php4-200210030300/ext/sockets/sockets.c", line 831: warning: argumen is incompatible with prototype: arg #3 [2002-10-03 07:55:31] [EMAIL PROTECTED] And http://snaps.php.net/php4-latest.tar.bz2 ? [2002-10-03 06:12:59] [EMAIL PROTECTED] Version 4.2.3 cc -I. -I/u/stan/x/php-4.2.3/ext/sockets -I/u/stan/x/php-4.2.3/main -I/u/stan/x/php-4.2.3 -I/u/stan/x/php-4.2.3/Zend -I/home/informix/incl/esql -I/home/informix/incl/tools -I/u/stan/x/php-4.2.3/ext/xml/expat -I/u/stan/x/php-4.2.3/TSRM -g -belf -c sockets.c && touch sockets.lo "/usr/include/sys/regset.h", line 41: error: (struct) tag redeclared: _fpstate "sockets.c", line 259: warning: argument is incompatible with prototype: arg #3 "sockets.c", line 367: error: undefined symbol: h_errno "sockets.c", line 775: warning: argument is incompatible with prototype: arg #3 [2002-10-03 05:16:38] [EMAIL PROTECTED] Please try a newer version (either 4.2.3 or more preferable the NON-stable snapshot from snaps.php.net) [2002-10-03 03:08:55] [EMAIL PROTECTED] Configuration options: ./configure --prefix=$DIR --with-informix=$INFORMIXDIR --without-mysql --enable-short-tags --enable-magic-quotes --enable-bcmath --enable-posix --enable-session --enable-debug --enable-discard-path --enable-force-cgi-redirect --enable-safe-mode --enable-sysvsem --enable-sysvshm --enable-trans-sid --enable-sockets Compilation : make[1]: Entering directory `/u/stan/x/php-4.2.0/ext/sockets' cc -I. -I/u/stan/x/php-4.2.0/ext/sockets -I/u/stan/x/php-4.2.0/main -I/u/stan/x/php-4.2.0 -I/u/stan/x/php-4.2.0/Zend -I/home/informix/incl/esql -I/home/informix/incl/tools -I/u/stan/x/php-4.2.0/ext/xml/expat -I/u/stan/x/php-4.2.0/TSRM -g -belf -c sockets.c && touch sockets.lo "sockets.c", line 1603: error: undefined symbol: h_errno "sockets.c", line 1607: warning: assignment type mismatch "sockets.c", line 1635: warning: assignment type mismatch "sockets.c", line 1677: warning: argument is incompatible with prototype: arg #5 "sockets.c", line 1694: warning: argument is incompatible with prototype: arg #5 "sockets.c", line 1710: warning: argument is incompatible with prototype: arg #5 make[1]: *** [sockets.lo] Error 1 make[1]: Leaving directory `/u/stan/x/php-4.2.0/ext/sockets' make: *** [all-recursive] Error 1 -- Edit this bug report at http://bugs.php.net/?id=19731&edit=1
#19524 [Fbk->NoF]: ./configure broken
ID: 19524 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Satellite CORBA related Operating System: Linux PHP Version: 4CVS-2002-09-20 New Comment: 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. Previous Comments: [2002-10-31 11:37:11] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-09-21 01:40:59] [EMAIL PROTECTED] I tried both phpize and copying the extension to php4/ext/satellite and both ways worked fine. (had latest CVS HEAD of php4 and the satellite extension) [2002-09-20 11:11:40] [EMAIL PROTECTED] I copied the directory to php4/ext/satellite and did a ./buildconf in php4/. Is this not supported? [2002-09-20 10:55:31] [EMAIL PROTECTED] How did you configure it? (phpize?) [2002-09-20 09:10:38] [EMAIL PROTECTED] checking for CORBA support via Satellite... yes ./configure: line 65714: syntax error near unexpected token `else' ./configure: line 65714: `else' -- Edit this bug report at http://bugs.php.net/?id=19524&edit=1
#17955 [Fbk->NoF]: GD and unicode maps/webdings
ID: 17955 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: GD related Operating System: RedHat 7.3 PHP Version: 4.2.1 New Comment: 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. Previous Comments: [2002-10-31 14:27:23] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip GD extension had undergone a number of revisions since the time this bug was opened. Is problem described still an issue? [2002-07-03 04:00:54] [EMAIL PROTECTED] No, this is in fact ours (all the relevant code is in gdttf.c). [2002-07-02 21:44:59] [EMAIL PROTECTED] So it's obviously not any bug in PHP. [2002-06-25 05:44:46] [EMAIL PROTECTED] Additional info: I talked again to the freetype guys. They asked me to try to use "" instead of the characters. This worked fine: If works but UTF-8 not then GD was compiled with the option JISX0208 which IMHO prevents decoding of UTF-8 encoded character codes. Then try to find out why this option was set. [2002-06-24 21:25:51] [EMAIL PROTECTED] 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/17955 -- Edit this bug report at http://bugs.php.net/?id=17955&edit=1
#18588 [Fbk->NoF]: pointer mismatch
ID: 18588 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Compile Warning Operating System: OSF1 V4.0 1530 (Tru64) PHP Version: 4CVS-2002-08-14 New Comment: 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. Previous Comments: [2002-11-01 10:06:46] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip And NOT the pre2! [2002-11-01 05:43:28] [EMAIL PROTECTED] In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/ctype/ctype.c:23: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:60: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:85: warning: redefinition of `uchar' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/sys/types.h:580: warning: `uchar' previously declared here /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c: In function `exif_process_IFD_in_JPEG': /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0pre2/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/ftp/php_ftp.c:26: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/ftp/ftp.c:22: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/mbstring/mbfilter_ja.c:86: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0pre2/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0pre2/main/php.h:34, from /usr/users/nohn/php-4.3.0pre2/ext/mbstring/mbfilter_cn.c:29: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36,
#17314 [Fbk->NoF]: CGI error with doc_root as in php.ini_dist
ID: 17314 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: IIS related Operating System: Win XP Pro PHP Version: 4.3.0 dev New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-10-31 11:55:53] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-07-01 16:08:43] [EMAIL PROTECTED] Veryfied with 4.3.0 snapshot of yesterday. Still the same phenomen. [2002-06-03 14:26:47] [EMAIL PROTECTED] No, I'm sure it's not cgi.force-redirect. The behaviour is changing when commenting out doc_root. Have verified it again. However, I didn't have the problem on a NT 4.0 Server SP6a with IIS 4. Christoph [2002-06-03 12:32:58] [EMAIL PROTECTED] Can't reproduce. Are you sure this is not actually the problem with having cgi.force_redirect set to 1 ? [2002-05-20 14:26:15] [EMAIL PROTECTED] PHP as CGI with IIS 5.1 doesn't work (CGI error) if doc_root is left as it is in php.ini-dist doc_root = However it works if doc_root is commented out: ; doc_root = Same for php.ini-recommended There's also a thread on that in the php-install mailing list. Christoph -- Edit this bug report at http://bugs.php.net/?id=17314&edit=1
#14897 [Fbk->NoF]: "unable to fork" - cause & solution (well, at least for me)
ID: 14897 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Program Execution Operating System: Windows 2000 PHP Version: 4.1.1 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-10-31 14:51:10] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-01-21 07:16:43] [EMAIL PROTECTED] re enable access to cmd.exe for php: if you are using IIS, then PHP will be run using the IWAM_ account. so you would have to set the right for cmd.exe to include this account. if you are using a different web server, then I have no idea what account would need access to cmd.exe re stopping php from prepending "cmd /c ": not that I know of, and hence the bug report that I posted requesting the developers changing it. [2002-01-21 06:32:42] [EMAIL PROTECTED] Is there a way to enable access to cmd.exe so that it is only available to php.exe? Or a way of stopping php prepending "cmd.exe /c " in front of any calls to exec? thanks. [2002-01-17 19:40:26] [EMAIL PROTECTED] this is a suggestion to the developers to do, because the only way for a script writer to solve this is to enabled access to cmd.exe which many would perfer to not have to do. [2002-01-17 05:56:27] [EMAIL PROTECTED] clarification: is this a suggestion of a way to fix the problem myself (so I can call programs), or a suggestion to the developers? 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/14897 -- Edit this bug report at http://bugs.php.net/?id=14897&edit=1
#19886 [Fbk->NoF]: readfile, fread, fpassthru won't work with large files!!!
ID: 19886
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: Filesystem function related
Operating System: Windows, any Version
PHP Version: 4CVS-2002-10-13
New Comment:
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2002-10-31 07:59:35] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
[2002-10-31 07:01:23] [EMAIL PROTECTED]
The problem can be reproduced using Apache/Win32 using the script
posted at 13 Oct 10:19am.
I tried the newest snapshot (31-Oct-2002 03:28). Furthermore, the
previous snaps and different release versions (>4.2.2) don't work. I
deleted versions < 4.2.1, so I can't test them any more.
[2002-10-31 05:17:56] [EMAIL PROTECTED]
I'm experiencing something similar on Linux Apache using Version 4.1.2.
As far as I know it worked before I upgraded from an earlier version.
My code looks like this:
$file="/path/to/file";
$fp = fopen($file, "r");
$size=filesize($file);
$contents = fread($fp, $size);
fclose($fp);
Header("Content-Type: $type");
Header("Content-Disposition: attachment; filename=$downloadname");
header("Content-Length: $size");
header("Content-Transfer-Encoding: binary");
echo $contents;
filesize() is reporting the size properly. The code works perfectly
for smaller files, but the fread() fails for files larger than 19 MB or
so and I got a page cannot be displayed error. All the files being
downloaded are PDF files.
[2002-10-31 04:34:57] [EMAIL PROTECTED]
None of them has been used (output buffering or ob_gzhandler, or
zlib.output_compression or transparent SID/session rewriting). The
fopen() -> $val = fread()-> echo $val worked fine. The response was
much quicker.
Never minad... I have solved the problem otherwise. And the data have
moved to a differen server with higher capacity.
Regards SelfMan
[2002-10-29 19:13:28] [EMAIL PROTECTED]
and did you try the most recent snapshot as I suggested
on the 13 Oct?
And could you reproduce the issue using a different web server?
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/19886
--
Edit this bug report at http://bugs.php.net/?id=19886&edit=1
#19113 [Fbk->NoF]: HTTP status 200 returned on HTTP CONNECT when mod_proxy not in use
ID: 19113 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Apache related Operating System: FreeBSD 4.6.2 PHP Version: 4.2.2 New Comment: No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2002-10-31 11:39:18] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-10-03 13:56:31] [EMAIL PROTECTED] I'm using PHP 4.2.2 and Apache 1.3.26 on RedHat 7.1 I can't get it to act properly at all (renaming the index file didn't work) DirectoryIndex index.html index.php index.htm I have 5 files and 3 directories in the root directory, the only file that is an index is index.html. I tried renaming that to 2index.html , but the CONNECT request just returned a 404. $SERVER['REQUEST_METHOD'] was 'CONNECT' when it parsed index.html, if that's any help. Chris P.S. When I voted on this bug I accidentaly stated it was a different version of PHP when it was in fact the same version. [2002-09-25 15:14:59] [EMAIL PROTECTED] This bug also applies to PHP 4.2.3. [2002-09-23 19:49:30] [EMAIL PROTECTED] A follow-up to the "quick-fix" configuration addition I posted: Despite working around the problem, it seems to partially mess up the default deny/allow setup that Apache comes with by default. For example, using those configuration directives globally will result in allow/deny directives to seemingly have no effect. So please, be cautious when using the configuration fix. This is just more proof that this bug need to be fixed on the Apache level or the PHP4 level (depending on where it is). [2002-08-26 15:14:58] [EMAIL PROTECTED] I believe the following to be a severe bug which relates directly to PHP4 and Apache 1.3: For those of you unfamiliar with HTTP, there is an HTTP command called "CONNECT" which is intended for use with HTTP proxying. Via telnet, one can test for proxy capability by doing the following (input is in bold): $ telnet www.somehost.com 80 Trying ###.###.###.###... Connected to www.somehost.com. Escape character is '^]'. CONNECT www.google.com:80 HTTP/1.0 Host: www.somehost.com Now hit [Enter] twice. If your Apache configuration is proper (and without mod_proxy installed), you should get the following response: HTTP/1.1 405 Method Not Allowed However, this is where the bug shows up. Here are the pre-requisites for it to appear: Must have PHP4 module loaded. Must have index.php listed in Apache DocumentIndex directive. Must have index.php file in the DocumentRoot of the website you're connecting to (in the above example, www.somehost.com). The result of the above HTTP CONNECT when all of the above pre-requistes are met: HTTP/1.1 200 OK [HTTP headers here] [Contents of parsed index.php here; as if visiting the website!] An HTTP response code of 200 should only be sent when the request was legitimate -- a HTTP CONNECT should not be legitimate just because the website in question has an index.php file. You can literally rename index.php to something else (even index.html!) and a correct HTTP status of 405 is returned. I have read the HTTP RFC in full, and it is fairly vague when it comes to dealing with HTTP CONNECT -- however, the Status code section applies to all sections, therefore a Status code of 200 on an HTTP CONNECT when mod_proxy is not loaded is incorrect. Again, this only happens with mod_php4 installed. So why is this a big deal? Well, a slew of online services use proxy scanners to ensure legitimate clients are being used to communicate with their servers; proxy scanners are also used for IRC. The scanners look for a status code of 200 on an HTTP CONNECT. There is a workaround, which is to add the following to your server configuration: Order deny,allow Deny from all This bug may be directly related to bug #17424. Footnote: If this is traced back to be a flaw in Apache's DSO code, then I expect to see it reported as such, so I can forward this entire thread on to the Apache team and make them deal with it. Thanks. -- Edit this bug report at http://bugs.php.net/?id=19113&edit=1
#20377 [Opn->Ver]: php_admin_value affects _only_ .htaccess
ID: 20377 Updated by: [EMAIL PROTECTED] -Summary: ini settings, per virtualhost Reported By: [EMAIL PROTECTED] -Status: Open +Status: Verified -Bug Type: Feature/Change Request +Bug Type: PHP options/info functions Operating System: All PHP Version: 4.3.0-pre2 New Comment: I'm reclassifying this and changing to other bug we found when digging into this mess.. :) If you set some directive in httpd.conf with php_admin_value it's not possible to change it anymore in .htaccess. This is okay and the correct behaviour. BUT it does not make PHP_INI_ALL settings not settable with ini_set() though. To test this: httpd.conf: php_admin_value html_errors 0 .htaccess: php_value html_errors 1 test.php: Previous Comments: [2002-11-15 22:23:43] [EMAIL PROTECTED] /me points to php_admin_flag and php_admin_value - Davey [2002-11-15 21:25:35] [EMAIL PROTECTED] ".htaccess also falls in the PERDIR class, and it's not a good idea to allow setting open_basedir and the other settings from this file especially for ISPs and stuff. --derick " [2002-11-11 20:15:05] [EMAIL PROTECTED] this is a feature I've put a lot of thought into and I really think webhosts specifically will benefit from this feature. It's basically allowing certain ini directives to be set using php_admin_flag/value on a virtualhost basis. The config options I think should be modified are these: open_basedir session.save_path upload_tmp_dir auto_prepend_file auto_append_file I don't know whats involved in changing these, but I would assume it's not a major change. I would love to see this in the forthcoming 4.3 release... - Davey -- Edit this bug report at http://bugs.php.net/?id=20377&edit=1
#20442 [Com]: xml_get_current_line_number produces segmentation fault
ID: 20442
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: XML related
Operating System: NetBSD 1.6
PHP Version: 4CVS-2002-11-15
New Comment:
okay, sorry. did not know that ;)
Previous Comments:
[2002-11-15 16:09:15] [EMAIL PROTECTED]
This bug is actually the result of a bug in the bundled expat library.
You can fix the problem by installing the latest expat from
http://sourceforge.net/project/showfiles.php?group_id=10127&release_id=109357
I am leaving the bug open, until the bunbled expat library is upgraded
to the latest stable release.
[2002-11-15 03:54:06] [EMAIL PROTECTED]
It looks like the xml_get_current_line_number of xml produces a
segmentation fault.
Here is the piece of code :
function parse($file)
{
if(!($fp = fopen($file, 'r')))
echo "xml_parser error: Could not open
$file.\n";
else
while($data = fgets($fp, 4096))
if(!xml_parse($this->parser, $data,
feof($fp)))
echo 'xml_parser error: ',
xml_error_string(xml_get_error_code($this->parser)),
' at line ',
xml_get_current_line_number($this->parser),
"\n";
fclose($fp);
return $this->struct;
}
If the data.xml looks like this for example :
Bla
Muh
I runned the xml example file in shell and here is the output :
Example
Test
Test
xml_parser error: mismatched tag at line 4
xml_parser error: mismatched tag at line Segmentation fault (core
dumped)
Now where is the problem ?
Does the XML parser try to get the line and is already at the end of
the file ?
--
Edit this bug report at http://bugs.php.net/?id=20442&edit=1
#20451 [Com]: imagepstext generates weird images since PHP 4.3.0-pre1
ID: 20451 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: GD related Operating System: Red Hat Linux 7.3 PHP Version: 4.3.0-pre2 New Comment: I forgot to mention that I use t1lib 1.3.1 from the following address to enable the imageps* functions in the gd extension (--with-t1lib configure option): ftp://sunsite.unc.edu/pub/Linux/libs/graphics/t1lib-1.3.1.tar.gz Previous Comments: [2002-11-15 23:03:00] [EMAIL PROTECTED] Yes, certainly, here's the whole code and the font in question: http://web.axelero.hu/fdsoft/temp/fonttest.zip There are some really ugly calculations and a brute force way of determining the size of the would-be image in the code, since imagepsbbox function didn't quite work well either. At least that was the case with PHP 4.2.x, and since I added this workaround, I've yet to re-check that in 4.3.0. Now for this weird output problem I can't figure out a workaround, and this was absolutely perfect with PHP 4.2.x., hence my bug report. It's likely that the fonts I use are of low quality or buggy or both; but that doesn't change the fact that this was working nicely with the older versions. Thanks [2002-11-15 21:18:24] [EMAIL PROTECTED] Can you please provide a complete and working example script? This one you added does not work. --Jani [2002-11-15 17:08:45] [EMAIL PROTECTED] I use the GD extension to generate .png images automatically for displaying text with a specific Type1 font, using the imagepstext function. PHP 4.2.x generates these images perfectly, while using PHP 4.3.0-pre1 and -pre2 results in some really weird output. Here are some examples to show the difference: http://web.axelero.hu/fdsoft/temp/images.html There actually seems to be two seperate problems: - the characters are not lined up properly any more - anti-aliasing produces weird output (most pronounced when the resulting image is viewed in IE 6, less ugly but still noticeable in Mozilla) The anti-aliasing problem pretty much goes away if I recompile PHP 4.3.0-pre2 to use my old GD 1.8.4 (from the Red Hat rpms) instead of PHP's built-in version of GD. The php code in question: $fonthandle=@imagepsloadfont(FONT_PATH.$font); imagepsencodefont($fonthandle, FONT_PATH.'IsoLatin1.enc'); $im = imagecreate($imgwidth, $imgheight); $background_color = imagecolorallocate ($im, $background[0], $background[1], $background[2]); imagecolortransparent($im, $background_color); $text_color = imagecolorallocate ($im, $color[0], $color[1], $color[2]); imagepstext($im, $txt, $fonthandle, $size, $text_color, $background_color,$x, $y, 0, 0, 0, 16); imagepng($im); Finally my php configure options: --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --prefix=/usr --with-config-file-path=/etc --with-exec-dir=/usr/bin --enable-force-cgi-redirect --disable-debug --enable-dbg=shared --with-dbg-profiler --enable-pic --disable-rpath --enable-inline-optimization --with-bz2 --with-db3 --with-curl=/usr/local --with-freetype-dir=/usr --with-png-dir=/usr --with-gd=shared --enable-gd-native-ttf --with-ttf --with-t1lib --with-gettext=shared --with-ncurses --with-iconv=shared --with-jpeg-dir=/usr --with-openssl --with-png --with-regex=system --with-expat-dir=/usr --with-zlib --with-layout=GNU --enable-bcmath --enable-exif --enable-ftp --enable-sockets --enable-sysvsem --enable-sysvshm --enable-discard-path --enable-track-vars --enable-trans-sid --enable-wddx --enable-exif --enable-memory-limit --enable-bcmath --enable-shmop --enable-versioning --enable-calendar --enable-dbx --enable-dio --enable-mcal --with-readline --with-mysql=shared,/usr --with-sybase-ct=shared,/usr/local --with-pgsql=shared --with-unixODBC=shared --with-interbase=shared,/opt/interbase --with-imap=shared --with-imap-ssl --with-kerberos=/usr/kerberos --with-zip=shared --with-pspell=shared --with-ming=shared --with-pdflib=shared --with-pear=/usr/share/pear --with-apxs=/usr/sbin/apxs The '--with-gd=shared' option was changed to '--with-gd=shared,/usr' to produce the "without built-in GD" output. -- Edit this bug report at http://bugs.php.net/?id=20451&edit=1
#20451 [Com]: imagepstext generates weird images since PHP 4.3.0-pre1
ID: 20451 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: GD related Operating System: Red Hat Linux 7.3 PHP Version: 4.3.0-pre2 New Comment: Yes, certainly, here's the whole code and the font in question: http://web.axelero.hu/fdsoft/temp/fonttest.zip There are some really ugly calculations and a brute force way of determining the size of the would-be image in the code, since imagepsbbox function didn't quite work well either. At least that was the case with PHP 4.2.x, and since I added this workaround, I've yet to re-check that in 4.3.0. Now for this weird output problem I can't figure out a workaround, and this was absolutely perfect with PHP 4.2.x., hence my bug report. It's likely that the fonts I use are of low quality or buggy or both; but that doesn't change the fact that this was working nicely with the older versions. Thanks Previous Comments: [2002-11-15 21:18:24] [EMAIL PROTECTED] Can you please provide a complete and working example script? This one you added does not work. --Jani [2002-11-15 17:08:45] [EMAIL PROTECTED] I use the GD extension to generate .png images automatically for displaying text with a specific Type1 font, using the imagepstext function. PHP 4.2.x generates these images perfectly, while using PHP 4.3.0-pre1 and -pre2 results in some really weird output. Here are some examples to show the difference: http://web.axelero.hu/fdsoft/temp/images.html There actually seems to be two seperate problems: - the characters are not lined up properly any more - anti-aliasing produces weird output (most pronounced when the resulting image is viewed in IE 6, less ugly but still noticeable in Mozilla) The anti-aliasing problem pretty much goes away if I recompile PHP 4.3.0-pre2 to use my old GD 1.8.4 (from the Red Hat rpms) instead of PHP's built-in version of GD. The php code in question: $fonthandle=@imagepsloadfont(FONT_PATH.$font); imagepsencodefont($fonthandle, FONT_PATH.'IsoLatin1.enc'); $im = imagecreate($imgwidth, $imgheight); $background_color = imagecolorallocate ($im, $background[0], $background[1], $background[2]); imagecolortransparent($im, $background_color); $text_color = imagecolorallocate ($im, $color[0], $color[1], $color[2]); imagepstext($im, $txt, $fonthandle, $size, $text_color, $background_color,$x, $y, 0, 0, 0, 16); imagepng($im); Finally my php configure options: --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --prefix=/usr --with-config-file-path=/etc --with-exec-dir=/usr/bin --enable-force-cgi-redirect --disable-debug --enable-dbg=shared --with-dbg-profiler --enable-pic --disable-rpath --enable-inline-optimization --with-bz2 --with-db3 --with-curl=/usr/local --with-freetype-dir=/usr --with-png-dir=/usr --with-gd=shared --enable-gd-native-ttf --with-ttf --with-t1lib --with-gettext=shared --with-ncurses --with-iconv=shared --with-jpeg-dir=/usr --with-openssl --with-png --with-regex=system --with-expat-dir=/usr --with-zlib --with-layout=GNU --enable-bcmath --enable-exif --enable-ftp --enable-sockets --enable-sysvsem --enable-sysvshm --enable-discard-path --enable-track-vars --enable-trans-sid --enable-wddx --enable-exif --enable-memory-limit --enable-bcmath --enable-shmop --enable-versioning --enable-calendar --enable-dbx --enable-dio --enable-mcal --with-readline --with-mysql=shared,/usr --with-sybase-ct=shared,/usr/local --with-pgsql=shared --with-unixODBC=shared --with-interbase=shared,/opt/interbase --with-imap=shared --with-imap-ssl --with-kerberos=/usr/kerberos --with-zip=shared --with-pspell=shared --with-ming=shared --with-pdflib=shared --with-pear=/usr/share/pear --with-apxs=/usr/sbin/apxs The '--with-gd=shared' option was changed to '--with-gd=shared,/usr' to produce the "without built-in GD" output. -- Edit this bug report at http://bugs.php.net/?id=20451&edit=1
#20377 [WFx->Opn]: ini settings, per virtualhost
ID: 20377 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Won't fix +Status: Open Bug Type: Feature/Change Request Operating System: All PHP Version: 4.3.0-pre2 New Comment: /me points to php_admin_flag and php_admin_value - Davey Previous Comments: [2002-11-15 21:25:35] [EMAIL PROTECTED] ".htaccess also falls in the PERDIR class, and it's not a good idea to allow setting open_basedir and the other settings from this file especially for ISPs and stuff. --derick " [2002-11-11 20:15:05] [EMAIL PROTECTED] this is a feature I've put a lot of thought into and I really think webhosts specifically will benefit from this feature. It's basically allowing certain ini directives to be set using php_admin_flag/value on a virtualhost basis. The config options I think should be modified are these: open_basedir session.save_path upload_tmp_dir auto_prepend_file auto_append_file I don't know whats involved in changing these, but I would assume it's not a major change. I would love to see this in the forthcoming 4.3 release... - Davey -- Edit this bug report at http://bugs.php.net/?id=20377&edit=1
#16542 [Com]: safe_mode_exec_dir and exec()
ID: 16542 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: IIS related Operating System: windows XP PHP Version: 4.1.2 New Comment: My host is running safe mode, and so I need to figure out how to tell them to give my directory access to exec() I would rather not run safe_mode at all. Previous Comments: [2002-11-15 22:07:32] [EMAIL PROTECTED] Just curious, are you guys really running a shared server on Windows? Because safe_mode makes very little sense in a non-shared environment. [2002-11-15 22:03:02] [EMAIL PROTECTED] By the way, this is being used as a module for Apache. [2002-11-15 22:02:29] [EMAIL PROTECTED] I am running Win2K with PHP 4.2.1 and I am experiencing this same type of problem. Hopefully I can provide a little more feedback. safe_mode = On safe_mode_exec_dir = "D:\web\test\" Here's what I've got. I've tried with frontslashes no trailing slash, you name it, I've tried it. No exec() or system(), etc. statement will work from this directory (or any other directory for that matter while safe_mode is on). If I take off safe_mode, everything is fine (obviously). I can provide more info if necessary. Please feel free to e-mail. [2002-11-03 11:05:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-05-13 06:36:03] [EMAIL PROTECTED] Reopening on user request: it doesn't work, even with forward slashes 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/16542 -- Edit this bug report at http://bugs.php.net/?id=16542&edit=1
#16542 [Fbk]: safe_mode_exec_dir and exec()
ID: 16542 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: IIS related Operating System: windows XP PHP Version: 4.1.2 New Comment: Just curious, are you guys really running a shared server on Windows? Because safe_mode makes very little sense in a non-shared environment. Previous Comments: [2002-11-15 22:03:02] [EMAIL PROTECTED] By the way, this is being used as a module for Apache. [2002-11-15 22:02:29] [EMAIL PROTECTED] I am running Win2K with PHP 4.2.1 and I am experiencing this same type of problem. Hopefully I can provide a little more feedback. safe_mode = On safe_mode_exec_dir = "D:\web\test\" Here's what I've got. I've tried with frontslashes no trailing slash, you name it, I've tried it. No exec() or system(), etc. statement will work from this directory (or any other directory for that matter while safe_mode is on). If I take off safe_mode, everything is fine (obviously). I can provide more info if necessary. Please feel free to e-mail. [2002-11-03 11:05:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-05-13 06:36:03] [EMAIL PROTECTED] Reopening on user request: it doesn't work, even with forward slashes [2002-05-12 00:00:03] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". 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/16542 -- Edit this bug report at http://bugs.php.net/?id=16542&edit=1
#16542 [Com]: safe_mode_exec_dir and exec()
ID: 16542 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: IIS related Operating System: windows XP PHP Version: 4.1.2 New Comment: By the way, this is being used as a module for Apache. Previous Comments: [2002-11-15 22:02:29] [EMAIL PROTECTED] I am running Win2K with PHP 4.2.1 and I am experiencing this same type of problem. Hopefully I can provide a little more feedback. safe_mode = On safe_mode_exec_dir = "D:\web\test\" Here's what I've got. I've tried with frontslashes no trailing slash, you name it, I've tried it. No exec() or system(), etc. statement will work from this directory (or any other directory for that matter while safe_mode is on). If I take off safe_mode, everything is fine (obviously). I can provide more info if necessary. Please feel free to e-mail. [2002-11-03 11:05:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-05-13 06:36:03] [EMAIL PROTECTED] Reopening on user request: it doesn't work, even with forward slashes [2002-05-12 00:00:03] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-04-11 06:19:28] [EMAIL PROTECTED] YOu're messing with backslashes and slashes. Try setting the safe_mode_exec_dir to something like c:/inetpub/cgi-bin Does it work now? 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/16542 -- Edit this bug report at http://bugs.php.net/?id=16542&edit=1
#16542 [Com]: safe_mode_exec_dir and exec()
ID: 16542
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: IIS related
Operating System: windows XP
PHP Version: 4.1.2
New Comment:
I am running Win2K with PHP 4.2.1 and I am experiencing this same type
of problem. Hopefully I can provide a little more feedback.
safe_mode = On
safe_mode_exec_dir = "D:\web\test\"
Here's what I've got. I've tried with frontslashes no trailing slash,
you name it, I've tried it. No exec() or system(), etc. statement will
work from this directory (or any other directory for that matter while
safe_mode is on).
If I take off safe_mode, everything is fine (obviously).
I can provide more info if necessary. Please feel free to e-mail.
Previous Comments:
[2002-11-03 11:05:45] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-05-13 06:36:03] [EMAIL PROTECTED]
Reopening on user request: it doesn't work, even with forward slashes
[2002-05-12 00:00:03] [EMAIL PROTECTED]
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2002-04-11 06:19:28] [EMAIL PROTECTED]
YOu're messing with backslashes and slashes. Try setting the
safe_mode_exec_dir to something like c:/inetpub/cgi-bin
Does it work now?
[2002-04-11 04:17:29] [EMAIL PROTECTED]
ISAPI mode. IIS 5.1
safe_mode_exec_dir = C:\\Inetpub\cgi-bin\
Calls to exec system with {safe mode = On} result in an extra "/"
being
prepended to the executable file's name:
Warning: Unable to fork [C:Inetpub\cgi-bin\\/myprog.exe] in
c:\inetpub\wwwroot\index.php4
(the fork error results from other issues, but notice the /myprog.exe)
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/16542
--
Edit this bug report at http://bugs.php.net/?id=16542&edit=1
#20377 [Opn->]: ini settings, per virtualhost
ID: 20377 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Won\'t fix Bug Type: Feature/Change Request Operating System: All PHP Version: 4.3.0-pre2 New Comment: ".htaccess also falls in the PERDIR class, and it's not a good idea to allow setting open_basedir and the other settings from this file especially for ISPs and stuff. --derick " Previous Comments: [2002-11-11 20:15:05] [EMAIL PROTECTED] this is a feature I've put a lot of thought into and I really think webhosts specifically will benefit from this feature. It's basically allowing certain ini directives to be set using php_admin_flag/value on a virtualhost basis. The config options I think should be modified are these: open_basedir session.save_path upload_tmp_dir auto_prepend_file auto_append_file I don't know whats involved in changing these, but I would assume it's not a major change. I would love to see this in the forthcoming 4.3 release... - Davey -- Edit this bug report at http://bugs.php.net/?id=20377&edit=1
#20451 [Opn->Fbk]: imagepstext generates weird images since PHP 4.3.0-pre1
ID: 20451 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: GD related Operating System: Red Hat Linux 7.3 PHP Version: 4.3.0-pre2 New Comment: Can you please provide a complete and working example script? This one you added does not work. --Jani Previous Comments: [2002-11-15 17:08:45] [EMAIL PROTECTED] I use the GD extension to generate .png images automatically for displaying text with a specific Type1 font, using the imagepstext function. PHP 4.2.x generates these images perfectly, while using PHP 4.3.0-pre1 and -pre2 results in some really weird output. Here are some examples to show the difference: http://web.axelero.hu/fdsoft/temp/images.html There actually seems to be two seperate problems: - the characters are not lined up properly any more - anti-aliasing produces weird output (most pronounced when the resulting image is viewed in IE 6, less ugly but still noticeable in Mozilla) The anti-aliasing problem pretty much goes away if I recompile PHP 4.3.0-pre2 to use my old GD 1.8.4 (from the Red Hat rpms) instead of PHP's built-in version of GD. The php code in question: $fonthandle=@imagepsloadfont(FONT_PATH.$font); imagepsencodefont($fonthandle, FONT_PATH.'IsoLatin1.enc'); $im = imagecreate($imgwidth, $imgheight); $background_color = imagecolorallocate ($im, $background[0], $background[1], $background[2]); imagecolortransparent($im, $background_color); $text_color = imagecolorallocate ($im, $color[0], $color[1], $color[2]); imagepstext($im, $txt, $fonthandle, $size, $text_color, $background_color,$x, $y, 0, 0, 0, 16); imagepng($im); Finally my php configure options: --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --prefix=/usr --with-config-file-path=/etc --with-exec-dir=/usr/bin --enable-force-cgi-redirect --disable-debug --enable-dbg=shared --with-dbg-profiler --enable-pic --disable-rpath --enable-inline-optimization --with-bz2 --with-db3 --with-curl=/usr/local --with-freetype-dir=/usr --with-png-dir=/usr --with-gd=shared --enable-gd-native-ttf --with-ttf --with-t1lib --with-gettext=shared --with-ncurses --with-iconv=shared --with-jpeg-dir=/usr --with-openssl --with-png --with-regex=system --with-expat-dir=/usr --with-zlib --with-layout=GNU --enable-bcmath --enable-exif --enable-ftp --enable-sockets --enable-sysvsem --enable-sysvshm --enable-discard-path --enable-track-vars --enable-trans-sid --enable-wddx --enable-exif --enable-memory-limit --enable-bcmath --enable-shmop --enable-versioning --enable-calendar --enable-dbx --enable-dio --enable-mcal --with-readline --with-mysql=shared,/usr --with-sybase-ct=shared,/usr/local --with-pgsql=shared --with-unixODBC=shared --with-interbase=shared,/opt/interbase --with-imap=shared --with-imap-ssl --with-kerberos=/usr/kerberos --with-zip=shared --with-pspell=shared --with-ming=shared --with-pdflib=shared --with-pear=/usr/share/pear --with-apxs=/usr/sbin/apxs The '--with-gd=shared' option was changed to '--with-gd=shared,/usr' to produce the "without built-in GD" output. -- Edit this bug report at http://bugs.php.net/?id=20451&edit=1
#20454 [NEW]: isset(eval("\$var".$n.";")) ===>> CRASH!!!
From: [EMAIL PROTECTED]
Operating system: Windows NT 5
PHP version: 4.2.3
PHP Bug Type: Variables related
Bug description: isset(eval("\$var".$n.";")) ===>> CRASH!!!
In this example, i´m triying to recover an indeterminate number of vars
from a form with the code below. The type of vars is like this: $var1,
$var2, $var3, ... but the succesion can be incomplete like this $var1,
$var5, $var6, ...
for ($n=0; n<=10; $n++) {
if (isset(eval("\$var".$n.";")) {
[...]
}
}
and the error message is:
Parse error: parse error, unexpected T_EVAL, expecting T_VARIABLE or '$'
in d:\inetpub\wwwroot\administracion\val_empextdb.php on line 14
Thanks.
--
Edit bug report at http://bugs.php.net/?id=20454&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20454&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20454&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20454&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20454&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20454&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20454&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20454&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20454&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20454&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20454&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20454&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20454&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20454&r=isapi
#20449 [Opn->Fbk]: sessions randomly fail
ID: 20449 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.3.0-dev New Comment: Can you add _short_ example script here that shows the problem, as I'm using sessions a lot and never have had any problems with them. Albeit I haven't tried to overload them too much either. Maybe you're doing something that isn't really been thought about when the session extension was written? Previous Comments: [2002-11-15 19:26:09] [EMAIL PROTECTED] Please put correct version number in the report.. I assume it's 4.3.0-dev but if it's something else, please change it. [2002-11-15 16:35:46] [EMAIL PROTECTED] I've experienced the same problem, on various platforms. SPARC Solaris 8 with PHP 4.2.2, Intel Linux 2.4 with PHP 4.2.3, and RedHat Alpha Linux 2.4 with PHP 4.2.3. However I'm not using it in the context of a shopping cart, my application is that of a "Checksheet" that we use to mark off Quality Assurance items. The Checksheet is large so I store the form contents in a session. They can move through all kinds of menus and parts of the Checksheet and the work is stored entirely in a session. About 8 people use this Checksheet system throughout the day 7 days a week, about once a day suddenly the Checksheet system will say they aren't logged in, and when they relogin in, their work is gone. I've implemented a quick and dirty save to database feature for long term storage and I've encouraged my users to frequently save. The save merely serializes the Checksheet object that is normally stored in a session, and saves it to a database. [2002-11-15 14:15:51] [EMAIL PROTECTED] Quick question. What should session.save_handler be in the php.ini file when using my own mysql session handlers? Should it remain files or should it get set to user to make the session_set_save_handler work properly? The documentation is somewhat unclear on this. [2002-11-15 13:58:51] [EMAIL PROTECTED] I am already using the save handler to use my own mysql backend. Please don't close this bug again. I am using CVS from a build on 11-14-2002. I still get random session failure. Here is a list of other bugs that are related to this. Bug #19029 Bug #17846 Bug #19972 Bug #19022 As far as I can tell, these other bugs were never fully resolved. BTW, while I allow php to set a cookie, I don't use it at all. I manually set session_id by using the session passed via the url. [2002-11-15 13:37:46] [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. 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/20449 -- Edit this bug report at http://bugs.php.net/?id=20449&edit=1
#20449 [Opn]: sessions randomly fail
ID: 20449 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: redhat 7.3 -PHP Version: 4.2.3 +PHP Version: 4.3.0-dev New Comment: Please put correct version number in the report.. I assume it's 4.3.0-dev but if it's something else, please change it. Previous Comments: [2002-11-15 16:35:46] [EMAIL PROTECTED] I've experienced the same problem, on various platforms. SPARC Solaris 8 with PHP 4.2.2, Intel Linux 2.4 with PHP 4.2.3, and RedHat Alpha Linux 2.4 with PHP 4.2.3. However I'm not using it in the context of a shopping cart, my application is that of a "Checksheet" that we use to mark off Quality Assurance items. The Checksheet is large so I store the form contents in a session. They can move through all kinds of menus and parts of the Checksheet and the work is stored entirely in a session. About 8 people use this Checksheet system throughout the day 7 days a week, about once a day suddenly the Checksheet system will say they aren't logged in, and when they relogin in, their work is gone. I've implemented a quick and dirty save to database feature for long term storage and I've encouraged my users to frequently save. The save merely serializes the Checksheet object that is normally stored in a session, and saves it to a database. [2002-11-15 14:15:51] [EMAIL PROTECTED] Quick question. What should session.save_handler be in the php.ini file when using my own mysql session handlers? Should it remain files or should it get set to user to make the session_set_save_handler work properly? The documentation is somewhat unclear on this. [2002-11-15 13:58:51] [EMAIL PROTECTED] I am already using the save handler to use my own mysql backend. Please don't close this bug again. I am using CVS from a build on 11-14-2002. I still get random session failure. Here is a list of other bugs that are related to this. Bug #19029 Bug #17846 Bug #19972 Bug #19022 As far as I can tell, these other bugs were never fully resolved. BTW, while I allow php to set a cookie, I don't use it at all. I manually set session_id by using the session passed via the url. [2002-11-15 13:37:46] [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-11-15 12:59:59] [EMAIL PROTECTED] What are these other bugs you mention? Please reference exact bug report numbers. And, what are you using for your session backend data store? Using your own db-based data store would probably be a good idea. See php.net/session_set_save_handler 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/20449 -- Edit this bug report at http://bugs.php.net/?id=20449&edit=1
#20453 [NEW]: $_SERVER['QUERY_STRING'] not set on 404 redirect
From: [EMAIL PROTECTED] Operating system: RedHat 7.3 PHP version: 4.2.3 PHP Bug Type: Apache related Bug description: $_SERVER['QUERY_STRING'] not set on 404 redirect $_SERVER['QUERY_STRING'] is empty in our 404-handling script, which is displayed when the user's URL is not found. The query string appears correctly in REQUEST_URI, so the data is there, it's just not getting into the QUERY_STRING var. Here are some dumps of the $_SERVER array, for an existing script, and a bad URL that displays the 404 script: (user: bugzilla; Pass: bugzz) http://clewis.myfonts.com/exists.php?stuff=things http://clewis.myfonts.com/notexist.php?stuff=things Using Apache 1.3.26, PHP 4.2.3, configured with './configure' '--prefix=/usr/local' '--with-apache=../apache' '--with-mysql=/usr/local' '--with-curl' '--with-gd' '--with-mcrypt' '--with-pspell' '--enable-apc' '--with-zlib' -Chris -- Edit bug report at http://bugs.php.net/?id=20453&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20453&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20453&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20453&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20453&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20453&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20453&r=support Expected behavior: http://bugs.php.net/fix.php?id=20453&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20453&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20453&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20453&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20453&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20453&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20453&r=isapi
#19045 [Opn->Fbk]: SELECT DISTINCT with just ONE table doesn't work
ID: 19045 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: ODBC related Operating System: IIS4 on NT4 PHP Version: 4.2.2 New Comment: Any chance you can check to see if this is still happening for you with the 4.3RC? Previous Comments: [2002-10-04 07:03:49] [EMAIL PROTECTED] I didn't find any tab with 'logging on' checkbox in ODBC Administrator program ; so, I changed the value of the 'Driver Logging' parameter to 17 in the oraodbc.ini file. I hope it can help you... Merci. // logging results when the request works fine (with two joined tables) Oracle ODBC 32 Bit Driver Version 08.00.6000 Oracle ODBC 32 Bit Driver File Version08.00.6000 0X0013BA50: php 0X 0X0013F078: php 0X 0X0013F8D0: php 0X 0X0013FC70: select distinct SOCIETE, POSTE from TEMPSCUMULES, GROUPE_MACHINE where poste=machine 0X0013FC70: select distinct SOCIETE, POSTE from TEMPSCUMULES, GROUPE_MACHINE where poste=machine 0X0013FC70: select distinct SOCIETE, POSTE from TEMPSCUMULES, GROUPE_MACHINE where poste=machine 0X0013FC70: Rows Fetched = 0X006E // logging results when the request doesn't work fine (with one table) Oracle ODBC 32 Bit Driver Version 08.00.6000 Oracle ODBC 32 Bit Driver File Version08.00.6000 0X0013BA50: php 0X 0X0013F078: php 0X 0X0013F8D0: php 0X 0X0013FC70: select distinct SOCIETE, POSTE from TEMPSCUMULES 0X0013FC70: select distinct SOCIETE, POSTE from TEMPSCUMULES 0X0013FC70: SELECT ROWID from TEMPSCUMULES 0X0013FC70: SELECT ROWID,distinct SOCIETE, POSTE from TEMPSCUMULES WHERE ROWID='' 0X0013FC70: select distinct SOCIETE, POSTE from TEMPSCUMULES [2002-10-03 07:48:10] [EMAIL PROTECTED] Open your ODBC Administrator and there should be tab that has a little check box that says "Turn Logging On" I believe it's on the same tab as the Pooling information. [2002-10-03 01:40:16] [EMAIL PROTECTED] how I can turn the logging on ? [2002-10-02 12:28:21] [EMAIL PROTECTED] Any chance you can re-do this with logging turned on? I did some research into this, and believe I've figured it out although I'd like to see if your actions fall into the same series of steps as mine. [2002-08-31 00:17:41] [EMAIL PROTECTED] Interestingly enough some digging into this results in the following data: The ODBC standard exec only supports the following options for a SELECT statement: FROM, WHERE, GROUP BY, HAVING, UNION, and ORDER BY. So technically doing a SELECT DISTINCT shouldn't ever work. Although your example seems to disprove this theory. I'm going to have to do more looking into this as I get time... as I don't think this should be an issue. It should be a SQL Driver issue, not an ODBC Driver issue. 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/19045 -- Edit this bug report at http://bugs.php.net/?id=19045&edit=1
#19871 [Opn->Bgs]: Query returning all the same data
ID: 19871 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: ODBC related Operating System: W2K Terminal Server PHP Version: 4.2.3 New Comment: Okay I'm going to assume that you're using the MS ODBC system, which is why the Access and Excel checks worked just fine. Given that nothing has changed base code wise, it suggests to me that the ODBC Driver for Progress is faulty and not PHP in this case. You can turn on SQL Logging to check if PHPs ODBC calls are sending the right requests. Marking this as bogus because if it works with 2 databases using the same ODBC Driver, and the third doesn't, it seems highly likely #3s implementation of ODBC isn't fully there. Previous Comments: [2002-10-11 13:41:56] [EMAIL PROTECTED] I am running a Progress Database with a ODBC data source entry. I have a test table with 4 records in it. Each record has three fields. ID, Name and Total. The information in the table is... Index on Name. ID Name Total 1 Horse 21 2 Cow30 3 Eagle 14 2 Cow34 Here is my actual code. $DBName = "php"; $TableName = "PUB.table1"; $Query = "SELECT * from $TableName"; $Link = odbc_connect ($DBName,$User,$Password); $Results = odbc_do($Link, $Query); print odbc_result_all($Results); What I expect to see was four lines of data display as above. What I got was... ID Name Total 2 Cow 30 2 Cow 30 2 Cow 30 2 Cow 30 I have tried 10-15 different ways to access the $Results to no avail. Then I decided to see if it was SQL problem. Using another SQL interface to the Progress Database, I performed the same query and got the expected results. Next I decided to see if it was an ODBC problem. My first approach was to set up a query within a MSExcel spreadsheet. This worked just fine and got the expected results. This told me that the ODBC driver used to access the Progress Database was working. Next I wanted to see if it was an PHP/ODBC command problem. So I set up an MS Access database and created an ODBC entry for it using the Microsoft driver for ODBC/mdb. I got the expected results. In fact the only difference between the php script for MS Access and Progress was the name of the Data Source. I also didn't need to use "PUB" in front of the table name. I used the exact same code to query and print the results. This leads me to believe that the problem here is the interaction of php and the driver for Progress. The ODBC driver that is shipped with Progress is MERANT 3.60 32-BIT Progress SQL92 v9.1C 3.60.00.00 Again, everything points to a problem between php and the driver for Progress. Using the same driver in both Excel, MS Word works just fine. I would appreciate it if someone would look into this for me. Thanks -- Edit this bug report at http://bugs.php.net/?id=19871&edit=1
#20203 [Opn->Fbk]: odbc_do() or odbc_exec() Always produces a segmentation fault core dump
ID: 20203 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: ODBC related Operating System: sparc solaris 2.8 and 2.6 PHP Version: 4.2.3 New Comment: After having spoken with some of the Openlink engineers, and doing my own tests, I don't believe this is a bug at all in PHP, but rather on your side. I haven't been able to reproduce this on any of the local sun boxes I have to test with either. Openlink has suggested building a clean version of the library, and testing further with that. Previous Comments: [2002-11-12 15:41:04] [EMAIL PROTECTED] 1. The sample script is exactly the same expet run on solaris 8so just the table name is different NOTHING ELSE. 2. here is the trace of SQL : php ptest3.php X-Powered-By: PHP/4.2.3 Content-type: text/html aaasa SQLAllocHandle ( ... ) SQLSetStmtAttr ( ... ) SQLAllocHandle ( ... ) SQLConnect ( ... ) SQLGetInfo ( ... ) SQLGetInfo ( ... ) CONNECTION ID = |Resource id #1| connected to DSN: test SQLAllocHandle ( ... ) SQLGetStmtAttr ( ... ) SQLGetStmtAttr ( ... ) SQLGetStmtAttr ( ... ) SQLGetStmtAttr ( ... ) SQLGetInfo ( ... ) SQLSetStmtAttr ( ... ) SQLExecDirect ( ... ) Segmentation Fault(coredump) 3. The version of iODBC is 3.0.6 (the latest) 4. I already tried the SQL_CUR_USE_ODBC option and the result is exacrly the same 5. odbc_prepare produces exactly the same at SQLPrepare instead of SQLExecDirect (see last line of SQL trace) 6. The variables are corectrly defined and exported in the environment But even if they exist in the php source the result is exactly the same I tried to compiel all in 64 bites (gcc 3.2) with -m64 But it failed Any idea if this could help ? and how can i compile php with -m64 ?? I would apreciate if you take a look please Best regards Christos [2002-11-05 17:45:08] [EMAIL PROTECTED] 1) Your sample script and your backtrace do not agree with each other on what is happening. If you feed me data for another run, I need to know how that script is working. I can't debug one, when the problem is in an entirely different format/layout. 2) You still haven't provided a SQL Log. You can enable this in your odbc.ini file, please read up on the odbc.ini for more information. 3) Which version of iODBC? 4) Did you try to connect using the SQL_CUR_USE_ODBC option? 5) Have you tried using an odbc_prepare command to see if that works. The error you're seeing is happening within the iODBC system, to which I have no access to. 6) Why have you commented out the ODBCINI putenv line? Thats generally a useful line for anything you're going to do with ODBC. This is as much debugging as I can do right now. My time is rather commited to other projects right now. [2002-11-05 17:10:47] [EMAIL PROTECTED] Not any idea ?? Pleas help !! I have a customer waiting Please if you have any idea Let me know Christos [2002-11-04 10:54:49] [EMAIL PROTECTED] I use iODBC but this is the log that is produced every time i run php. I have compiled with --without-mysql --with-iodbc Christos [2002-11-04 10:27:30] [EMAIL PROTECTED] Are you using FreeTDS or iOBDC? I'm very confused... 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/20203 -- Edit this bug report at http://bugs.php.net/?id=20203&edit=1
#20437 [Bgs->Opn]: static $m=1|2;
ID: 20437 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Scripting Engine problem Operating System: BSDI PHP Version: 4.2.1 New Comment: hmm, not so sure if this is expected or a bug, Andi? Derick Previous Comments: [2002-11-15 17:55:31] [EMAIL PROTECTED] i am not in the class, the whole file contains only [2002-11-15 01:03:46] [EMAIL PROTECTED] >From http://www.php.net/manual/en/language.oop.php: Note: In PHP 4, only constant initializers for var variables are allowed. To initialize variables with non-constant values, you need an initialization function which is called automatically when an object is being constructed from the class. Such a function is called a constructor (see below). [2002-11-14 21:45:20] [EMAIL PROTECTED] it seems that i cannot do static $m=1|2|4; getting rid of the static would compile it. -- Edit this bug report at http://bugs.php.net/?id=20437&edit=1
#20437 [Com]: static $m=1|2;
ID: 20437 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: BSDI PHP Version: 4.2.1 New Comment: i am not in the class, the whole file contains only Previous Comments: [2002-11-15 01:03:46] [EMAIL PROTECTED] >From http://www.php.net/manual/en/language.oop.php: Note: In PHP 4, only constant initializers for var variables are allowed. To initialize variables with non-constant values, you need an initialization function which is called automatically when an object is being constructed from the class. Such a function is called a constructor (see below). [2002-11-14 21:45:20] [EMAIL PROTECTED] it seems that i cannot do static $m=1|2|4; getting rid of the static would compile it. -- Edit this bug report at http://bugs.php.net/?id=20437&edit=1
#20452 [NEW]: Problems requiring/including when original file is a symlink
From: [EMAIL PROTECTED] Operating system: Linux Mandrake 9.0 PHP version: 4.2.3 PHP Bug Type: Scripting Engine problem Bug description: Problems requiring/including when original file is a symlink I'm requesting a page, the file that is called is index.php, but this file is a symlink from somewhere else. When I require a file from index.php, if there's no '..' (dots) on the path (a relative path, but not going back), the relative path is from where the original file is, but if there are '..' on the path, the relative path is from where the symlink is (although php identifies the script as the original file in the error message). -- Edit bug report at http://bugs.php.net/?id=20452&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20452&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20452&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20452&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20452&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20452&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20452&r=support Expected behavior: http://bugs.php.net/fix.php?id=20452&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20452&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20452&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20452&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20452&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20452&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20452&r=isapi
#20451 [NEW]: imagepstext generates weird images since PHP 4.3.0-pre1
From: [EMAIL PROTECTED] Operating system: Red Hat Linux 7.3 PHP version: 4.3.0-pre2 PHP Bug Type: GD related Bug description: imagepstext generates weird images since PHP 4.3.0-pre1 I use the GD extension to generate .png images automatically for displaying text with a specific Type1 font, using the imagepstext function. PHP 4.2.x generates these images perfectly, while using PHP 4.3.0-pre1 and -pre2 results in some really weird output. Here are some examples to show the difference: http://web.axelero.hu/fdsoft/temp/images.html There actually seems to be two seperate problems: - the characters are not lined up properly any more - anti-aliasing produces weird output (most pronounced when the resulting image is viewed in IE 6, less ugly but still noticeable in Mozilla) The anti-aliasing problem pretty much goes away if I recompile PHP 4.3.0-pre2 to use my old GD 1.8.4 (from the Red Hat rpms) instead of PHP's built-in version of GD. The php code in question: $fonthandle=@imagepsloadfont(FONT_PATH.$font); imagepsencodefont($fonthandle, FONT_PATH.'IsoLatin1.enc'); $im = imagecreate($imgwidth, $imgheight); $background_color = imagecolorallocate ($im, $background[0], $background[1], $background[2]); imagecolortransparent($im, $background_color); $text_color = imagecolorallocate ($im, $color[0], $color[1], $color[2]); imagepstext($im, $txt, $fonthandle, $size, $text_color, $background_color,$x, $y, 0, 0, 0, 16); imagepng($im); Finally my php configure options: --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --prefix=/usr --with-config-file-path=/etc --with-exec-dir=/usr/bin --enable-force-cgi-redirect --disable-debug --enable-dbg=shared --with-dbg-profiler --enable-pic --disable-rpath --enable-inline-optimization --with-bz2 --with-db3 --with-curl=/usr/local --with-freetype-dir=/usr --with-png-dir=/usr --with-gd=shared --enable-gd-native-ttf --with-ttf --with-t1lib --with-gettext=shared --with-ncurses --with-iconv=shared --with-jpeg-dir=/usr --with-openssl --with-png --with-regex=system --with-expat-dir=/usr --with-zlib --with-layout=GNU --enable-bcmath --enable-exif --enable-ftp --enable-sockets --enable-sysvsem --enable-sysvshm --enable-discard-path --enable-track-vars --enable-trans-sid --enable-wddx --enable-exif --enable-memory-limit --enable-bcmath --enable-shmop --enable-versioning --enable-calendar --enable-dbx --enable-dio --enable-mcal --with-readline --with-mysql=shared,/usr --with-sybase-ct=shared,/usr/local --with-pgsql=shared --with-unixODBC=shared --with-interbase=shared,/opt/interbase --with-imap=shared --with-imap-ssl --with-kerberos=/usr/kerberos --with-zip=shared --with-pspell=shared --with-ming=shared --with-pdflib=shared --with-pear=/usr/share/pear --with-apxs=/usr/sbin/apxs The '--with-gd=shared' option was changed to '--with-gd=shared,/usr' to produce the "without built-in GD" output. -- Edit bug report at http://bugs.php.net/?id=20451&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20451&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20451&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20451&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20451&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20451&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20451&r=support Expected behavior: http://bugs.php.net/fix.php?id=20451&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20451&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20451&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20451&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20451&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20451&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20451&r=isapi
#20449 [Com]: sessions randomly fail
ID: 20449 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.2.3 New Comment: I've experienced the same problem, on various platforms. SPARC Solaris 8 with PHP 4.2.2, Intel Linux 2.4 with PHP 4.2.3, and RedHat Alpha Linux 2.4 with PHP 4.2.3. However I'm not using it in the context of a shopping cart, my application is that of a "Checksheet" that we use to mark off Quality Assurance items. The Checksheet is large so I store the form contents in a session. They can move through all kinds of menus and parts of the Checksheet and the work is stored entirely in a session. About 8 people use this Checksheet system throughout the day 7 days a week, about once a day suddenly the Checksheet system will say they aren't logged in, and when they relogin in, their work is gone. I've implemented a quick and dirty save to database feature for long term storage and I've encouraged my users to frequently save. The save merely serializes the Checksheet object that is normally stored in a session, and saves it to a database. Previous Comments: [2002-11-15 14:15:51] [EMAIL PROTECTED] Quick question. What should session.save_handler be in the php.ini file when using my own mysql session handlers? Should it remain files or should it get set to user to make the session_set_save_handler work properly? The documentation is somewhat unclear on this. [2002-11-15 13:58:51] [EMAIL PROTECTED] I am already using the save handler to use my own mysql backend. Please don't close this bug again. I am using CVS from a build on 11-14-2002. I still get random session failure. Here is a list of other bugs that are related to this. Bug #19029 Bug #17846 Bug #19972 Bug #19022 As far as I can tell, these other bugs were never fully resolved. BTW, while I allow php to set a cookie, I don't use it at all. I manually set session_id by using the session passed via the url. [2002-11-15 13:37:46] [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-11-15 12:59:59] [EMAIL PROTECTED] What are these other bugs you mention? Please reference exact bug report numbers. And, what are you using for your session backend data store? Using your own db-based data store would probably be a good idea. See php.net/session_set_save_handler [2002-11-15 12:28:00] [EMAIL PROTECTED] I have seen this bug reported a couple of times. Forgive me for starting my own but I want to bring this back to the attention of the developers. I've got a fairly high traffic server. (30-50K uniques per day) For the most part, everything works ok. We get plenty of orders (between 70-90 a day). However, I also get complaints from people who say they keep losing their cart. To try and track down what was going on. I started storing some fairly simple stats from the site. Here is an example of one sent to me via e-mail from my order.html page. Person's cart failed? Referring url is: http://www.t-shirtking.com/cart.php User Agent is: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; DigExt; Roadrunner) Cookie output: c93856925c2ed796d3560d3729ebeb60 Other Session: http://www.t-shirtking.com/catalog/136-00813/c93856925c2ed796d3560d3729ebeb60 Other Session: addProduct new session is: c93856925c2ed796d3560d3729ebeb60 A quick description is as follows. If they come to the order.html page and the script doesn't see the $_SESSION["cart"] variable, it sends me this message. It sends me the referring url. (a lot of people hit checkout instead of add to cart for some odd reason, so this is proof that this particular person went through the cart) Then I grab the user agent to try and narrow down the browsers with problems. Then I see if the session id is in a cookie. Then, by looking at their session variable, I can see that they went to cart.php via the given url. (I store the http_refferer as a session variable on the cart.php page) Then, to prove to myself that the cart function ran, I store the fact that the person came from the catalo
#20450 [Fbk->Csd]: Acquisition of 2 vars with GET works not fine
ID: 20450 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Unknown/Other Function Operating System: MacOsX.2 PHP Version: 4.2.3 New Comment: Hi, it's not a bug : only a bad delimitor (it's must be & and i use +) Thank you, Nicolas. See you. Previous Comments: [2002-11-15 14:20:56] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-15 14:18:28] [EMAIL PROTECTED] I try to invoke with the URL http://192.168.0.4/~paul/test1.php?toto=ert+tutu=aze the following PHP script : Liste des arguments "; echo phpinfo() ; ?> Bad surprise i find in the tables : _GET["toto"]has value "ert tutu=aze" that is *NOT* good ! But in a line underneath we have: _SERVER["argv"] has value Array ( [0] => toto=ert [1] => tutu=aze ) with argc pointing on the value 2. That is *VERY* good for the GET method. I have find nothing in the bug reports related to the word GET. So i post this message. Yours PAUL DELANNOY http://tontonpol.dyndns.org PHP : SystemDarwin primavera.entropy.ch 6.1 Darwin Kernel Version 6.1: Fri Sep 6 23:24:34 PDT 2002; root:xnu/xnu-344.2.obj~2/RELEASE_PPC Power Macintosh powerpc Build Date Sep 24 2002 23:15:03 Configure Command './configure' '--disable-cli' '--with-apxs' '--with-mysql' '--with-pgsql' '--with-gd=/usr/local' '--with-png-dir=/usr/local' '--with-zlib-dir=/usr' '--with-jpeg-dir=/usr/local' '--with-freetype-dir=/usr/local' '--with-t1lib=/usr/local' '--enable-trans-sid' '--enable-exif' '--with-xml' '--enable-wddx' '--with-curl=/usr/local' '--with-pdflib=/usr/local' '--enable-ftp' '--enable-mbstring' '--enable-xslt' '--with-xslt-sablot=/usr/local' '--with-imap=../imap-2001a' '--enable-dbx' '--enable-dbase' '--with-mcrypt=/usr/local' '--enable-sockets' '--with-ldap' '--with-xmlrpc' '--with-iodbc' Server API Apache Virtual Directory Support disabled Configuration File (php.ini) Path /usr/local/lib Debug Build no Thread Safety disabled -- Edit this bug report at http://bugs.php.net/?id=20450&edit=1
#20442 [Opn->Ana]: xml_get_current_line_number produces segmentation fault
ID: 20442
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Analyzed
Bug Type: XML related
Operating System: NetBSD 1.6
PHP Version: 4CVS-2002-11-15
New Comment:
This bug is actually the result of a bug in the bundled expat library.
You can fix the problem by installing the latest expat from
http://sourceforge.net/project/showfiles.php?group_id=10127&release_id=109357
I am leaving the bug open, until the bunbled expat library is upgraded
to the latest stable release.
Previous Comments:
[2002-11-15 03:54:06] [EMAIL PROTECTED]
It looks like the xml_get_current_line_number of xml produces a
segmentation fault.
Here is the piece of code :
function parse($file)
{
if(!($fp = fopen($file, 'r')))
echo "xml_parser error: Could not open
$file.\n";
else
while($data = fgets($fp, 4096))
if(!xml_parse($this->parser, $data,
feof($fp)))
echo 'xml_parser error: ',
xml_error_string(xml_get_error_code($this->parser)),
' at line ',
xml_get_current_line_number($this->parser),
"\n";
fclose($fp);
return $this->struct;
}
If the data.xml looks like this for example :
Bla
Muh
I runned the xml example file in shell and here is the output :
Example
Test
Test
xml_parser error: mismatched tag at line 4
xml_parser error: mismatched tag at line Segmentation fault (core
dumped)
Now where is the problem ?
Does the XML parser try to get the line and is already at the end of
the file ?
--
Edit this bug report at http://bugs.php.net/?id=20442&edit=1
#20443 [Bgs->Csd]: Jpeg colors change
ID: 20443 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Closed Bug Type: GD related Operating System: Linux PHP Version: 4.2.3 New Comment: Derick, It's not a matter of what I'm willing to do. It's a matter of what a large percentage of users are able to do. I have no control over what version of PHP is installed on my server. From what I hear, that applies to 40-60 % of all site developers on the net. I don't think the fact that php is free is relavant to whether it is released with or without major bugs. It's a quality issue. (e.g. If it's worth doing, it's worth doing well.) Sure, it's wonderfull and truly fullfilling that php is available for free. But it's free to my ISP, not to me. I'm paying through the nose to use it. I've been using php extensively through at least two updates. This is the first one that broke critical core functions and caused failures on my site. I think I am justifiably annoyed. BTW - the classification of a bug report as "Bogus" is not a very polite terminology. It implies that a) I am a fool, and b) perhaps I just made it up for fun. Bogus to you too! Have wonderfull weekend! Previous Comments: [2002-11-15 15:24:27] [EMAIL PROTECTED] If you think that software without bugs exist, please show me one. Now, if you report a bug in some product, it is quite normal that the developers ask you retest a newer version from which _we_ (yes, the guys writing your software for free) think it's fixed. If you're not willing to do that it's not our problem. Have a nice day. Derick [2002-11-15 15:20:20] [EMAIL PROTECTED] I have tested it! That's how I know it's a bug. I searched the bug database and found no references to changed colors in 4.2.3. This system has a basic problem: just because something is "fixed" in CVS does not mean the problem is solved by any means. Why are buggy versions of php released at all? [2002-11-15 13:39:40] [EMAIL PROTECTED] Why do you report if you can't test? And this is already fixed btw.. [2002-11-15 13:34:59] [EMAIL PROTECTED] Due to ISP limitations, CVS is not an option. Does anyone know exactly where this bug resides? Must be in the GD, but is it in all the copy/resize functions? Any work-arounds? Thanks! [2002-11-15 09:11:07] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20443 -- Edit this bug report at http://bugs.php.net/?id=20443&edit=1
#20443 [Opn->Bgs]: Jpeg colors change
ID: 20443
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: GD related
Operating System: Linux
PHP Version: 4.2.3
New Comment:
If you think that software without bugs exist, please show me one. Now,
if you report a bug in some product, it is quite normal that the
developers ask you retest a newer version from which _we_ (yes, the
guys writing your software for free) think it's fixed. If you're not
willing to do that it's not our problem.
Have a nice day.
Derick
Previous Comments:
[2002-11-15 15:20:20] [EMAIL PROTECTED]
I have tested it! That's how I know it's a bug. I searched the bug
database and found no references to changed colors in 4.2.3.
This system has a basic problem: just because something is "fixed" in
CVS does not mean the problem is solved by any means. Why are buggy
versions of php released at all?
[2002-11-15 13:39:40] [EMAIL PROTECTED]
Why do you report if you can't test? And this is already fixed btw..
[2002-11-15 13:34:59] [EMAIL PROTECTED]
Due to ISP limitations, CVS is not an option.
Does anyone know exactly where this bug resides? Must be in the GD, but
is it in all the copy/resize functions? Any work-arounds?
Thanks!
[2002-11-15 09:11:07] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-11-15 04:20:02] [EMAIL PROTECTED]
Resized images generated from jpg files displaying botched or dimmed
colors after update from 4.2.2 to 4.2.3.
Example code:
# get the data from the original, large image
$src_img = ImageCreateFromJPEG($image);
# create new image
$dst_img = ImageCreate($new_w,$new_h);
# allocate colors for background and border
$mattecolor = ImageColorAllocate($dst_img,$mr,$mg,$mb);
$bordercolor = ImageColorAllocate($dst_img,$br,$bg,$bb);
# fill image with matte color
ImageFill($dst_img,0,0,$mattecolor);
# resize source image and place the copy in the destination image
ImageCopyResized($dst_img,$src_img,
$margin_x,$margin_y,
0,0,$thumb_w,$thumb_h,
$old_x,$old_y);
# if there is a border set, draw a rectangle around the thumbnail
if
($border==1){imageRectangle($dst_img,0,0,$new_w-1,$new_h-1,$bordercolor);}
# create final image and free up the memory
ImageJPEG($dst_img);
ImageDestroy($dst_img);
--
Edit this bug report at http://bugs.php.net/?id=20443&edit=1
#20443 [Bgs->Opn]: Jpeg colors change
ID: 20443
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: GD related
Operating System: Linux
PHP Version: 4.2.3
New Comment:
I have tested it! That's how I know it's a bug. I searched the bug
database and found no references to changed colors in 4.2.3.
This system has a basic problem: just because something is "fixed" in
CVS does not mean the problem is solved by any means. Why are buggy
versions of php released at all?
Previous Comments:
[2002-11-15 13:39:40] [EMAIL PROTECTED]
Why do you report if you can't test? And this is already fixed btw..
[2002-11-15 13:34:59] [EMAIL PROTECTED]
Due to ISP limitations, CVS is not an option.
Does anyone know exactly where this bug resides? Must be in the GD, but
is it in all the copy/resize functions? Any work-arounds?
Thanks!
[2002-11-15 09:11:07] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-11-15 04:20:02] [EMAIL PROTECTED]
Resized images generated from jpg files displaying botched or dimmed
colors after update from 4.2.2 to 4.2.3.
Example code:
# get the data from the original, large image
$src_img = ImageCreateFromJPEG($image);
# create new image
$dst_img = ImageCreate($new_w,$new_h);
# allocate colors for background and border
$mattecolor = ImageColorAllocate($dst_img,$mr,$mg,$mb);
$bordercolor = ImageColorAllocate($dst_img,$br,$bg,$bb);
# fill image with matte color
ImageFill($dst_img,0,0,$mattecolor);
# resize source image and place the copy in the destination image
ImageCopyResized($dst_img,$src_img,
$margin_x,$margin_y,
0,0,$thumb_w,$thumb_h,
$old_x,$old_y);
# if there is a border set, draw a rectangle around the thumbnail
if
($border==1){imageRectangle($dst_img,0,0,$new_w-1,$new_h-1,$bordercolor);}
# create final image and free up the memory
ImageJPEG($dst_img);
ImageDestroy($dst_img);
--
Edit this bug report at http://bugs.php.net/?id=20443&edit=1
#20450 [Opn->Fbk]: Acquisition of 2 vars with GET works not fine
ID: 20450 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: MacOsX.2 PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Previous Comments: [2002-11-15 14:18:28] [EMAIL PROTECTED] I try to invoke with the URL http://192.168.0.4/~paul/test1.php?toto=ert+tutu=aze the following PHP script : Liste des arguments "; echo phpinfo() ; ?> Bad surprise i find in the tables : _GET["toto"]has value "ert tutu=aze" that is *NOT* good ! But in a line underneath we have: _SERVER["argv"] has value Array ( [0] => toto=ert [1] => tutu=aze ) with argc pointing on the value 2. That is *VERY* good for the GET method. I have find nothing in the bug reports related to the word GET. So i post this message. Yours PAUL DELANNOY http://tontonpol.dyndns.org PHP : SystemDarwin primavera.entropy.ch 6.1 Darwin Kernel Version 6.1: Fri Sep 6 23:24:34 PDT 2002; root:xnu/xnu-344.2.obj~2/RELEASE_PPC Power Macintosh powerpc Build Date Sep 24 2002 23:15:03 Configure Command './configure' '--disable-cli' '--with-apxs' '--with-mysql' '--with-pgsql' '--with-gd=/usr/local' '--with-png-dir=/usr/local' '--with-zlib-dir=/usr' '--with-jpeg-dir=/usr/local' '--with-freetype-dir=/usr/local' '--with-t1lib=/usr/local' '--enable-trans-sid' '--enable-exif' '--with-xml' '--enable-wddx' '--with-curl=/usr/local' '--with-pdflib=/usr/local' '--enable-ftp' '--enable-mbstring' '--enable-xslt' '--with-xslt-sablot=/usr/local' '--with-imap=../imap-2001a' '--enable-dbx' '--enable-dbase' '--with-mcrypt=/usr/local' '--enable-sockets' '--with-ldap' '--with-xmlrpc' '--with-iodbc' Server API Apache Virtual Directory Support disabled Configuration File (php.ini) Path /usr/local/lib Debug Build no Thread Safety disabled -- Edit this bug report at http://bugs.php.net/?id=20450&edit=1
#20450 [NEW]: Acquisition of 2 vars with GET works not fine
From: [EMAIL PROTECTED] Operating system: MacOsX.2 PHP version: 4.2.3 PHP Bug Type: Unknown/Other Function Bug description: Acquisition of 2 vars with GET works not fine I try to invoke with the URL http://192.168.0.4/~paul/test1.php?toto=ert+tutu=aze the following PHP script : Liste des arguments "; echo phpinfo() ; ?> Bad surprise i find in the tables : _GET["toto"]has value "ert tutu=aze" that is *NOT* good ! But in a line underneath we have: _SERVER["argv"] has value Array ( [0] => toto=ert [1] => tutu=aze ) with argc pointing on the value 2. That is *VERY* good for the GET method. I have find nothing in the bug reports related to the word GET. So i post this message. Yours PAUL DELANNOY http://tontonpol.dyndns.org PHP : SystemDarwin primavera.entropy.ch 6.1 Darwin Kernel Version 6.1: Fri Sep 6 23:24:34 PDT 2002; root:xnu/xnu-344.2.obj~2/RELEASE_PPC Power Macintosh powerpc Build Date Sep 24 2002 23:15:03 Configure Command './configure' '--disable-cli' '--with-apxs' '--with-mysql' '--with-pgsql' '--with-gd=/usr/local' '--with-png-dir=/usr/local' '--with-zlib-dir=/usr' '--with-jpeg-dir=/usr/local' '--with-freetype-dir=/usr/local' '--with-t1lib=/usr/local' '--enable-trans-sid' '--enable-exif' '--with-xml' '--enable-wddx' '--with-curl=/usr/local' '--with-pdflib=/usr/local' '--enable-ftp' '--enable-mbstring' '--enable-xslt' '--with-xslt-sablot=/usr/local' '--with-imap=../imap-2001a' '--enable-dbx' '--enable-dbase' '--with-mcrypt=/usr/local' '--enable-sockets' '--with-ldap' '--with-xmlrpc' '--with-iodbc' Server API Apache Virtual Directory Support disabled Configuration File (php.ini) Path /usr/local/lib Debug Build no Thread Safety disabled -- Edit bug report at http://bugs.php.net/?id=20450&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20450&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20450&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20450&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20450&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20450&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20450&r=support Expected behavior: http://bugs.php.net/fix.php?id=20450&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20450&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20450&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20450&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20450&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20450&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20450&r=isapi
#20449 [Com]: sessions randomly fail
ID: 20449 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.2.3 New Comment: Quick question. What should session.save_handler be in the php.ini file when using my own mysql session handlers? Should it remain files or should it get set to user to make the session_set_save_handler work properly? The documentation is somewhat unclear on this. Previous Comments: [2002-11-15 13:58:51] [EMAIL PROTECTED] I am already using the save handler to use my own mysql backend. Please don't close this bug again. I am using CVS from a build on 11-14-2002. I still get random session failure. Here is a list of other bugs that are related to this. Bug #19029 Bug #17846 Bug #19972 Bug #19022 As far as I can tell, these other bugs were never fully resolved. BTW, while I allow php to set a cookie, I don't use it at all. I manually set session_id by using the session passed via the url. [2002-11-15 13:37:46] [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-11-15 12:59:59] [EMAIL PROTECTED] What are these other bugs you mention? Please reference exact bug report numbers. And, what are you using for your session backend data store? Using your own db-based data store would probably be a good idea. See php.net/session_set_save_handler [2002-11-15 12:28:00] [EMAIL PROTECTED] I have seen this bug reported a couple of times. Forgive me for starting my own but I want to bring this back to the attention of the developers. I've got a fairly high traffic server. (30-50K uniques per day) For the most part, everything works ok. We get plenty of orders (between 70-90 a day). However, I also get complaints from people who say they keep losing their cart. To try and track down what was going on. I started storing some fairly simple stats from the site. Here is an example of one sent to me via e-mail from my order.html page. Person's cart failed? Referring url is: http://www.t-shirtking.com/cart.php User Agent is: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; DigExt; Roadrunner) Cookie output: c93856925c2ed796d3560d3729ebeb60 Other Session: http://www.t-shirtking.com/catalog/136-00813/c93856925c2ed796d3560d3729ebeb60 Other Session: addProduct new session is: c93856925c2ed796d3560d3729ebeb60 A quick description is as follows. If they come to the order.html page and the script doesn't see the $_SESSION["cart"] variable, it sends me this message. It sends me the referring url. (a lot of people hit checkout instead of add to cart for some odd reason, so this is proof that this particular person went through the cart) Then I grab the user agent to try and narrow down the browsers with problems. Then I see if the session id is in a cookie. Then, by looking at their session variable, I can see that they went to cart.php via the given url. (I store the http_refferer as a session variable on the cart.php page) Then, to prove to myself that the cart function ran, I store the fact that the person came from the catalog url and did indeed pass the cart command addProduct (via the form post data). As a last test, I send myself the session_id that order.html is using (to make sure the session wasn't restarted) So, what can I gather from thisI only give one example. However, I get about 10 of these messages a day. I'm sure there are even more than that considering that some people may give up when they notice their cart isn't holding their products and don't bother going to order.html. As you can tell from above, it is clear that the session id is indeed intact. Also, I'm actually able to pull information out of the session that was stored on a previous page. (the addProduct command and the url stored in the session by the cart.php page) However, the cart variable, which is an object, is no longer there. (it is a simple object btw. Just an object with an array in it and a few member functions) I thought perhaps using the default php session manager, that it was having problems. So I recently switched it to a mysql based manager. (just using the
#20449 [Csd->Opn]: sessions randomly fail
ID: 20449 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.2.3 New Comment: I am already using the save handler to use my own mysql backend. Please don't close this bug again. I am using CVS from a build on 11-14-2002. I still get random session failure. Here is a list of other bugs that are related to this. Bug #19029 Bug #17846 Bug #19972 Bug #19022 As far as I can tell, these other bugs were never fully resolved. BTW, while I allow php to set a cookie, I don't use it at all. I manually set session_id by using the session passed via the url. Previous Comments: [2002-11-15 13:37:46] [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-11-15 12:59:59] [EMAIL PROTECTED] What are these other bugs you mention? Please reference exact bug report numbers. And, what are you using for your session backend data store? Using your own db-based data store would probably be a good idea. See php.net/session_set_save_handler [2002-11-15 12:28:00] [EMAIL PROTECTED] I have seen this bug reported a couple of times. Forgive me for starting my own but I want to bring this back to the attention of the developers. I've got a fairly high traffic server. (30-50K uniques per day) For the most part, everything works ok. We get plenty of orders (between 70-90 a day). However, I also get complaints from people who say they keep losing their cart. To try and track down what was going on. I started storing some fairly simple stats from the site. Here is an example of one sent to me via e-mail from my order.html page. Person's cart failed? Referring url is: http://www.t-shirtking.com/cart.php User Agent is: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; DigExt; Roadrunner) Cookie output: c93856925c2ed796d3560d3729ebeb60 Other Session: http://www.t-shirtking.com/catalog/136-00813/c93856925c2ed796d3560d3729ebeb60 Other Session: addProduct new session is: c93856925c2ed796d3560d3729ebeb60 A quick description is as follows. If they come to the order.html page and the script doesn't see the $_SESSION["cart"] variable, it sends me this message. It sends me the referring url. (a lot of people hit checkout instead of add to cart for some odd reason, so this is proof that this particular person went through the cart) Then I grab the user agent to try and narrow down the browsers with problems. Then I see if the session id is in a cookie. Then, by looking at their session variable, I can see that they went to cart.php via the given url. (I store the http_refferer as a session variable on the cart.php page) Then, to prove to myself that the cart function ran, I store the fact that the person came from the catalog url and did indeed pass the cart command addProduct (via the form post data). As a last test, I send myself the session_id that order.html is using (to make sure the session wasn't restarted) So, what can I gather from thisI only give one example. However, I get about 10 of these messages a day. I'm sure there are even more than that considering that some people may give up when they notice their cart isn't holding their products and don't bother going to order.html. As you can tell from above, it is clear that the session id is indeed intact. Also, I'm actually able to pull information out of the session that was stored on a previous page. (the addProduct command and the url stored in the session by the cart.php page) However, the cart variable, which is an object, is no longer there. (it is a simple object btw. Just an object with an array in it and a few member functions) I thought perhaps using the default php session manager, that it was having problems. So I recently switched it to a mysql based manager. (just using the session_save_handler). I still get the issue though. Therefore, I cancel out blaming php's file storage method. Where is my cart object going? It happens only randomly. It also happens only to users of IE. (though 90% of our traffic are IE users) It happens to IE6.0, IE5.5, IE5.0. It also happens at any time during the day (meaning, high traffic ti
#20443 [Opn->Bgs]: Jpeg colors change
ID: 20443
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: GD related
Operating System: Linux
PHP Version: 4.2.3
New Comment:
Why do you report if you can't test? And this is already fixed btw..
Previous Comments:
[2002-11-15 13:34:59] [EMAIL PROTECTED]
Due to ISP limitations, CVS is not an option.
Does anyone know exactly where this bug resides? Must be in the GD, but
is it in all the copy/resize functions? Any work-arounds?
Thanks!
[2002-11-15 09:11:07] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-11-15 04:20:02] [EMAIL PROTECTED]
Resized images generated from jpg files displaying botched or dimmed
colors after update from 4.2.2 to 4.2.3.
Example code:
# get the data from the original, large image
$src_img = ImageCreateFromJPEG($image);
# create new image
$dst_img = ImageCreate($new_w,$new_h);
# allocate colors for background and border
$mattecolor = ImageColorAllocate($dst_img,$mr,$mg,$mb);
$bordercolor = ImageColorAllocate($dst_img,$br,$bg,$bb);
# fill image with matte color
ImageFill($dst_img,0,0,$mattecolor);
# resize source image and place the copy in the destination image
ImageCopyResized($dst_img,$src_img,
$margin_x,$margin_y,
0,0,$thumb_w,$thumb_h,
$old_x,$old_y);
# if there is a border set, draw a rectangle around the thumbnail
if
($border==1){imageRectangle($dst_img,0,0,$new_w-1,$new_h-1,$bordercolor);}
# create final image and free up the memory
ImageJPEG($dst_img);
ImageDestroy($dst_img);
--
Edit this bug report at http://bugs.php.net/?id=20443&edit=1
#19848 [Opn->Csd]: Wrong $_REQUEST values ($_FILES appearance is wacky)
ID: 19848
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: HTTP related
Operating System: *any
PHP Version: 4.2.3,4,3.0-dev
Assigned To: sterling
Previous Comments:
[2002-11-15 12:45:06] [EMAIL PROTECTED]
Until import_request_variables() behavior is discussed in php-dev this
should remain open. IMHO $_REQUEST and import_request_variables()
should behave the same way as to remain consistent. As of PHP 4.3.0
$_FILES was only removed from $_REQUEST.
[2002-11-15 07:44:41] [EMAIL PROTECTED]
not sure if this is important, but import_request_variables imports the
wrong thing.
html:
code:
import_request_variables("GP", "__");
result:
$__d = array (
'name' => array ( 'file' => '' ),
'type' => array ( 'file' => '' ),
'tmp_name' => array ( 'file' => '' ),
'error' => array ( 'file' => 4 ),
'size' => array ( 'file' => 0 )
)
[2002-10-27 20:47:21] [EMAIL PROTECTED]
Fixed in CVS... $_FILES is no longer present in $_REQUEST...
[2002-10-24 18:42:14] [EMAIL PROTECTED]
This test form strips 3 characters from the posted variable:
2 dimensional array - this test form strips 8 characters from the
posted variable:
For every dimension added to the array, another 4 characters are
scripted from the beginning of the posted variable. Works on PHP
version less than 4.2.2 and earlier.
[2002-10-20 22:17:12] [EMAIL PROTECTED]
The 'voting' on php-dev was in favour for removing the $_FILES from
$_REQUEST..as it doesn't make much sense
to have them there. Just FYI. :)
--Jani
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/19848
--
Edit this bug report at http://bugs.php.net/?id=19848&edit=1
#20449 [Fbk->Csd]: sessions randomly fail
ID: 20449 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.2.3 New Comment: 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. Previous Comments: [2002-11-15 12:59:59] [EMAIL PROTECTED] What are these other bugs you mention? Please reference exact bug report numbers. And, what are you using for your session backend data store? Using your own db-based data store would probably be a good idea. See php.net/session_set_save_handler [2002-11-15 12:28:00] [EMAIL PROTECTED] I have seen this bug reported a couple of times. Forgive me for starting my own but I want to bring this back to the attention of the developers. I've got a fairly high traffic server. (30-50K uniques per day) For the most part, everything works ok. We get plenty of orders (between 70-90 a day). However, I also get complaints from people who say they keep losing their cart. To try and track down what was going on. I started storing some fairly simple stats from the site. Here is an example of one sent to me via e-mail from my order.html page. Person's cart failed? Referring url is: http://www.t-shirtking.com/cart.php User Agent is: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; DigExt; Roadrunner) Cookie output: c93856925c2ed796d3560d3729ebeb60 Other Session: http://www.t-shirtking.com/catalog/136-00813/c93856925c2ed796d3560d3729ebeb60 Other Session: addProduct new session is: c93856925c2ed796d3560d3729ebeb60 A quick description is as follows. If they come to the order.html page and the script doesn't see the $_SESSION["cart"] variable, it sends me this message. It sends me the referring url. (a lot of people hit checkout instead of add to cart for some odd reason, so this is proof that this particular person went through the cart) Then I grab the user agent to try and narrow down the browsers with problems. Then I see if the session id is in a cookie. Then, by looking at their session variable, I can see that they went to cart.php via the given url. (I store the http_refferer as a session variable on the cart.php page) Then, to prove to myself that the cart function ran, I store the fact that the person came from the catalog url and did indeed pass the cart command addProduct (via the form post data). As a last test, I send myself the session_id that order.html is using (to make sure the session wasn't restarted) So, what can I gather from thisI only give one example. However, I get about 10 of these messages a day. I'm sure there are even more than that considering that some people may give up when they notice their cart isn't holding their products and don't bother going to order.html. As you can tell from above, it is clear that the session id is indeed intact. Also, I'm actually able to pull information out of the session that was stored on a previous page. (the addProduct command and the url stored in the session by the cart.php page) However, the cart variable, which is an object, is no longer there. (it is a simple object btw. Just an object with an array in it and a few member functions) I thought perhaps using the default php session manager, that it was having problems. So I recently switched it to a mysql based manager. (just using the session_save_handler). I still get the issue though. Therefore, I cancel out blaming php's file storage method. Where is my cart object going? It happens only randomly. It also happens only to users of IE. (though 90% of our traffic are IE users) It happens to IE6.0, IE5.5, IE5.0. It also happens at any time during the day (meaning, high traffic times and low traffic times) I have also been able to immediately look at my sessions table in the database when I receive a message like the above. Sure enough, the session is there...it has data...just no cart. Of course, the biggest problem of allI can't reproduce the bug to save my life. I've tested on 10 different machines using a variety of Windows versions and IE versions. I've tested the cart well over 100 times. Yet, I never seem to be able to break it. I even try to add the product that I know the person who did lose the cart was trying to buy. I'm pretty sure I'm losing orders b
#20443 [Fbk->Opn]: Jpeg colors change
ID: 20443
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: GD related
Operating System: Linux
PHP Version: 4.2.3
New Comment:
Due to ISP limitations, CVS is not an option.
Does anyone know exactly where this bug resides? Must be in the GD, but
is it in all the copy/resize functions? Any work-arounds?
Thanks!
Previous Comments:
[2002-11-15 09:11:07] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-11-15 04:20:02] [EMAIL PROTECTED]
Resized images generated from jpg files displaying botched or dimmed
colors after update from 4.2.2 to 4.2.3.
Example code:
# get the data from the original, large image
$src_img = ImageCreateFromJPEG($image);
# create new image
$dst_img = ImageCreate($new_w,$new_h);
# allocate colors for background and border
$mattecolor = ImageColorAllocate($dst_img,$mr,$mg,$mb);
$bordercolor = ImageColorAllocate($dst_img,$br,$bg,$bb);
# fill image with matte color
ImageFill($dst_img,0,0,$mattecolor);
# resize source image and place the copy in the destination image
ImageCopyResized($dst_img,$src_img,
$margin_x,$margin_y,
0,0,$thumb_w,$thumb_h,
$old_x,$old_y);
# if there is a border set, draw a rectangle around the thumbnail
if
($border==1){imageRectangle($dst_img,0,0,$new_w-1,$new_h-1,$bordercolor);}
# create final image and free up the memory
ImageJPEG($dst_img);
ImageDestroy($dst_img);
--
Edit this bug report at http://bugs.php.net/?id=20443&edit=1
#20449 [Opn->Fbk]: sessions randomly fail
ID: 20449 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Session related Operating System: redhat 7.3 PHP Version: 4.2.3 New Comment: What are these other bugs you mention? Please reference exact bug report numbers. And, what are you using for your session backend data store? Using your own db-based data store would probably be a good idea. See php.net/session_set_save_handler Previous Comments: [2002-11-15 12:28:00] [EMAIL PROTECTED] I have seen this bug reported a couple of times. Forgive me for starting my own but I want to bring this back to the attention of the developers. I've got a fairly high traffic server. (30-50K uniques per day) For the most part, everything works ok. We get plenty of orders (between 70-90 a day). However, I also get complaints from people who say they keep losing their cart. To try and track down what was going on. I started storing some fairly simple stats from the site. Here is an example of one sent to me via e-mail from my order.html page. Person's cart failed? Referring url is: http://www.t-shirtking.com/cart.php User Agent is: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; DigExt; Roadrunner) Cookie output: c93856925c2ed796d3560d3729ebeb60 Other Session: http://www.t-shirtking.com/catalog/136-00813/c93856925c2ed796d3560d3729ebeb60 Other Session: addProduct new session is: c93856925c2ed796d3560d3729ebeb60 A quick description is as follows. If they come to the order.html page and the script doesn't see the $_SESSION["cart"] variable, it sends me this message. It sends me the referring url. (a lot of people hit checkout instead of add to cart for some odd reason, so this is proof that this particular person went through the cart) Then I grab the user agent to try and narrow down the browsers with problems. Then I see if the session id is in a cookie. Then, by looking at their session variable, I can see that they went to cart.php via the given url. (I store the http_refferer as a session variable on the cart.php page) Then, to prove to myself that the cart function ran, I store the fact that the person came from the catalog url and did indeed pass the cart command addProduct (via the form post data). As a last test, I send myself the session_id that order.html is using (to make sure the session wasn't restarted) So, what can I gather from thisI only give one example. However, I get about 10 of these messages a day. I'm sure there are even more than that considering that some people may give up when they notice their cart isn't holding their products and don't bother going to order.html. As you can tell from above, it is clear that the session id is indeed intact. Also, I'm actually able to pull information out of the session that was stored on a previous page. (the addProduct command and the url stored in the session by the cart.php page) However, the cart variable, which is an object, is no longer there. (it is a simple object btw. Just an object with an array in it and a few member functions) I thought perhaps using the default php session manager, that it was having problems. So I recently switched it to a mysql based manager. (just using the session_save_handler). I still get the issue though. Therefore, I cancel out blaming php's file storage method. Where is my cart object going? It happens only randomly. It also happens only to users of IE. (though 90% of our traffic are IE users) It happens to IE6.0, IE5.5, IE5.0. It also happens at any time during the day (meaning, high traffic times and low traffic times) I have also been able to immediately look at my sessions table in the database when I receive a message like the above. Sure enough, the session is there...it has data...just no cart. Of course, the biggest problem of allI can't reproduce the bug to save my life. I've tested on 10 different machines using a variety of Windows versions and IE versions. I've tested the cart well over 100 times. Yet, I never seem to be able to break it. I even try to add the product that I know the person who did lose the cart was trying to buy. I'm pretty sure I'm losing orders because of this. I can't imagine how many people are having issues. I have tried two things in the last couple of days. One, I downloaded and installed the cvs version of PHP. I also stopped storing the cart as an object and simply storing it as an array. Neither of these tests have worked. I still get the problem. Right now, we are going to setup a second server and split the traffic among each. Hopefully this will lower the loss of session data. The other wierd thing is that I don't lose the entire session. Just the part that contains the cart array. (and before that the cart object) Remember, the cart o
#16272 [NoF->Csd]: SegFault in MySQL
ID: 16272 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Closed Bug Type: MySQL related Operating System: Linux 2.4.x PHP Version: 4.1.2 New Comment: This is fixed in 4.3 Previous Comments: [2002-11-15 12:52:42] [EMAIL PROTECTED] Same problem: PHP 4.2.3 compiled from php.net sources Distro Red Hat 7.3 Dual Intel XEON 1.8GHz ...tons of Segmentation Faults SIG(11)... :( Any news? Please, contact me if you have!!! Everyone of you! Thank you! [2002-10-20 17:59:30] [EMAIL PROTECTED] hi people, i cant get a rest .. this issue just took me weeks for now .. is there some new knowledge around about this BUG? well ist it one .. is it just bad php-code .. i am totally lost in this issue .. plz anybody gives more info and a status about this .. i touched this problem using latest version am xams(.sourgeforge.net) .. its annoying [2002-10-02 01:12:50] [EMAIL PROTECTED] Getting the same problems as the last poster - lots of SIGSEGVs then the apache processes seem to hang - can't get any data out of them. [2002-08-12 06:37:18] [EMAIL PROTECTED] Please change the status of this bug.. This bug is really bothering me, all my users are affected by this bug because it gives them empty pages :\ Here's a snippet from my errorlog: [Mon Aug 12 12:01:16 2002] [notice] child pid 20887 exit signal Segmentation fault (11) [Mon Aug 12 12:03:09 2002] [notice] child pid 20929 exit signal Segmentation fault (11) [Mon Aug 12 12:03:28 2002] [notice] child pid 20938 exit signal Segmentation fault (11) [Mon Aug 12 12:05:09 2002] [notice] child pid 20562 exit signal Segmentation fault (11) [Mon Aug 12 12:05:18 2002] [notice] child pid 21044 exit signal Segmentation fault (11) [Mon Aug 12 12:06:30 2002] [notice] child pid 20925 exit signal Segmentation fault (11) [Mon Aug 12 12:07:07 2002] [notice] child pid 21078 exit signal Segmentation fault (11) [Mon Aug 12 12:07:13 2002] [notice] child pid 21086 exit signal Segmentation fault (11) [Mon Aug 12 12:07:17 2002] [notice] child pid 20559 exit signal Segmentation fault (11) [Mon Aug 12 12:07:29 2002] [notice] child pid 21091 exit signal Segmentation fault (11) [Mon Aug 12 12:07:37 2002] [notice] child pid 21094 exit signal Segmentation fault (11) [Mon Aug 12 12:10:19 2002] [notice] child pid 21237 exit signal Segmentation fault (11) [Mon Aug 12 12:10:26 2002] [notice] child pid 21240 exit signal Segmentation fault (11) [Mon Aug 12 12:10:57 2002] [notice] child pid 21249 exit signal Segmentation fault (11) Mainly using phpBB 2.0.1 on that site. Furthermore I'm using PHP version 4.2.2 on Linux 2.4.18-5, Apache/1.3.26 with MySQL 3.23.47. See http://www.bokt.nl/klad/info.php for phpinfo(). [2002-08-07 13:42:16] [EMAIL PROTECTED] I don't know if my uneducated comment will really contribute to the understanding of this bug, but I'll offer it up anyway: I encountered the same problem with the exact same Apache/PHP/MySQL setup as [EMAIL PROTECTED] When I changed the connection type from persistent (using mysql_pconnect) to a regular MySQL connection (using mysql_connect), the problem went away--the script worked fine and no further segfaults appeared in the http error log. If others find the same results, then it may be safe to assume the problem is limited to persistent connections only. 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/16272 -- Edit this bug report at http://bugs.php.net/?id=16272&edit=1
#16272 [Com]: SegFault in MySQL
ID: 16272 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: MySQL related Operating System: Linux 2.4.x PHP Version: 4.1.2 New Comment: Same problem: PHP 4.2.3 compiled from php.net sources Distro Red Hat 7.3 Dual Intel XEON 1.8GHz ...tons of Segmentation Faults SIG(11)... :( Any news? Please, contact me if you have!!! Everyone of you! Thank you! Previous Comments: [2002-10-20 17:59:30] [EMAIL PROTECTED] hi people, i cant get a rest .. this issue just took me weeks for now .. is there some new knowledge around about this BUG? well ist it one .. is it just bad php-code .. i am totally lost in this issue .. plz anybody gives more info and a status about this .. i touched this problem using latest version am xams(.sourgeforge.net) .. its annoying [2002-10-02 01:12:50] [EMAIL PROTECTED] Getting the same problems as the last poster - lots of SIGSEGVs then the apache processes seem to hang - can't get any data out of them. [2002-08-12 06:37:18] [EMAIL PROTECTED] Please change the status of this bug.. This bug is really bothering me, all my users are affected by this bug because it gives them empty pages :\ Here's a snippet from my errorlog: [Mon Aug 12 12:01:16 2002] [notice] child pid 20887 exit signal Segmentation fault (11) [Mon Aug 12 12:03:09 2002] [notice] child pid 20929 exit signal Segmentation fault (11) [Mon Aug 12 12:03:28 2002] [notice] child pid 20938 exit signal Segmentation fault (11) [Mon Aug 12 12:05:09 2002] [notice] child pid 20562 exit signal Segmentation fault (11) [Mon Aug 12 12:05:18 2002] [notice] child pid 21044 exit signal Segmentation fault (11) [Mon Aug 12 12:06:30 2002] [notice] child pid 20925 exit signal Segmentation fault (11) [Mon Aug 12 12:07:07 2002] [notice] child pid 21078 exit signal Segmentation fault (11) [Mon Aug 12 12:07:13 2002] [notice] child pid 21086 exit signal Segmentation fault (11) [Mon Aug 12 12:07:17 2002] [notice] child pid 20559 exit signal Segmentation fault (11) [Mon Aug 12 12:07:29 2002] [notice] child pid 21091 exit signal Segmentation fault (11) [Mon Aug 12 12:07:37 2002] [notice] child pid 21094 exit signal Segmentation fault (11) [Mon Aug 12 12:10:19 2002] [notice] child pid 21237 exit signal Segmentation fault (11) [Mon Aug 12 12:10:26 2002] [notice] child pid 21240 exit signal Segmentation fault (11) [Mon Aug 12 12:10:57 2002] [notice] child pid 21249 exit signal Segmentation fault (11) Mainly using phpBB 2.0.1 on that site. Furthermore I'm using PHP version 4.2.2 on Linux 2.4.18-5, Apache/1.3.26 with MySQL 3.23.47. See http://www.bokt.nl/klad/info.php for phpinfo(). [2002-08-07 13:42:16] [EMAIL PROTECTED] I don't know if my uneducated comment will really contribute to the understanding of this bug, but I'll offer it up anyway: I encountered the same problem with the exact same Apache/PHP/MySQL setup as [EMAIL PROTECTED] When I changed the connection type from persistent (using mysql_pconnect) to a regular MySQL connection (using mysql_connect), the problem went away--the script worked fine and no further segfaults appeared in the http error log. If others find the same results, then it may be safe to assume the problem is limited to persistent connections only. [2002-07-26 01:00:10] [EMAIL PROTECTED] No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". 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/16272 -- Edit this bug report at http://bugs.php.net/?id=16272&edit=1
#19848 [Csd->Opn]: Wrong $_REQUEST values ($_FILES appearance is wacky)
ID: 19848
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: HTTP related
Operating System: *any
PHP Version: 4.2.3,4,3.0-dev
Assigned To: sterling
New Comment:
Until import_request_variables() behavior is discussed in php-dev this
should remain open. IMHO $_REQUEST and import_request_variables()
should behave the same way as to remain consistent. As of PHP 4.3.0
$_FILES was only removed from $_REQUEST.
Previous Comments:
[2002-11-15 07:44:41] [EMAIL PROTECTED]
not sure if this is important, but import_request_variables imports the
wrong thing.
html:
code:
import_request_variables("GP", "__");
result:
$__d = array (
'name' => array ( 'file' => '' ),
'type' => array ( 'file' => '' ),
'tmp_name' => array ( 'file' => '' ),
'error' => array ( 'file' => 4 ),
'size' => array ( 'file' => 0 )
)
[2002-10-27 20:47:21] [EMAIL PROTECTED]
Fixed in CVS... $_FILES is no longer present in $_REQUEST...
[2002-10-24 18:42:14] [EMAIL PROTECTED]
This test form strips 3 characters from the posted variable:
2 dimensional array - this test form strips 8 characters from the
posted variable:
For every dimension added to the array, another 4 characters are
scripted from the beginning of the posted variable. Works on PHP
version less than 4.2.2 and earlier.
[2002-10-20 22:17:12] [EMAIL PROTECTED]
The 'voting' on php-dev was in favour for removing the $_FILES from
$_REQUEST..as it doesn't make much sense
to have them there. Just FYI. :)
--Jani
[2002-10-20 22:14:01] [EMAIL PROTECTED]
Sterling Hughes is working on this issue, according to posts to
php-dev.
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/19848
--
Edit this bug report at http://bugs.php.net/?id=19848&edit=1
#20449 [NEW]: sessions randomly fail
From: [EMAIL PROTECTED] Operating system: redhat 7.3 PHP version: 4.2.3 PHP Bug Type: Session related Bug description: sessions randomly fail I have seen this bug reported a couple of times. Forgive me for starting my own but I want to bring this back to the attention of the developers. I've got a fairly high traffic server. (30-50K uniques per day) For the most part, everything works ok. We get plenty of orders (between 70-90 a day). However, I also get complaints from people who say they keep losing their cart. To try and track down what was going on. I started storing some fairly simple stats from the site. Here is an example of one sent to me via e-mail from my order.html page. Person's cart failed? Referring url is: http://www.t-shirtking.com/cart.php User Agent is: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; DigExt; Roadrunner) Cookie output: c93856925c2ed796d3560d3729ebeb60 Other Session: http://www.t-shirtking.com/catalog/136-00813/c93856925c2ed796d3560d3729ebeb60 Other Session: addProduct new session is: c93856925c2ed796d3560d3729ebeb60 A quick description is as follows. If they come to the order.html page and the script doesn't see the $_SESSION["cart"] variable, it sends me this message. It sends me the referring url. (a lot of people hit checkout instead of add to cart for some odd reason, so this is proof that this particular person went through the cart) Then I grab the user agent to try and narrow down the browsers with problems. Then I see if the session id is in a cookie. Then, by looking at their session variable, I can see that they went to cart.php via the given url. (I store the http_refferer as a session variable on the cart.php page) Then, to prove to myself that the cart function ran, I store the fact that the person came from the catalog url and did indeed pass the cart command addProduct (via the form post data). As a last test, I send myself the session_id that order.html is using (to make sure the session wasn't restarted) So, what can I gather from thisI only give one example. However, I get about 10 of these messages a day. I'm sure there are even more than that considering that some people may give up when they notice their cart isn't holding their products and don't bother going to order.html. As you can tell from above, it is clear that the session id is indeed intact. Also, I'm actually able to pull information out of the session that was stored on a previous page. (the addProduct command and the url stored in the session by the cart.php page) However, the cart variable, which is an object, is no longer there. (it is a simple object btw. Just an object with an array in it and a few member functions) I thought perhaps using the default php session manager, that it was having problems. So I recently switched it to a mysql based manager. (just using the session_save_handler). I still get the issue though. Therefore, I cancel out blaming php's file storage method. Where is my cart object going? It happens only randomly. It also happens only to users of IE. (though 90% of our traffic are IE users) It happens to IE6.0, IE5.5, IE5.0. It also happens at any time during the day (meaning, high traffic times and low traffic times) I have also been able to immediately look at my sessions table in the database when I receive a message like the above. Sure enough, the session is there...it has data...just no cart. Of course, the biggest problem of allI can't reproduce the bug to save my life. I've tested on 10 different machines using a variety of Windows versions and IE versions. I've tested the cart well over 100 times. Yet, I never seem to be able to break it. I even try to add the product that I know the person who did lose the cart was trying to buy. I'm pretty sure I'm losing orders because of this. I can't imagine how many people are having issues. I have tried two things in the last couple of days. One, I downloaded and installed the cvs version of PHP. I also stopped storing the cart as an object and simply storing it as an array. Neither of these tests have worked. I still get the problem. Right now, we are going to setup a second server and split the traffic among each. Hopefully this will lower the loss of session data. The other wierd thing is that I don't lose the entire session. Just the part that contains the cart array. (and before that the cart object) Remember, the cart object had the same array in it that I am storing now. Perhaps the problem is with storing arrays??? Anyway, this is a major problem. I've seen it in past bug reports. The fact is, sessions are unreliable. And that is a shame. I see it as mission critical for PHP. If this doesn't get fixed soon, I guarantee that my client will want to move away from php. And that to me would be a nightmare. It is possible that sharing the load on 2 servers will solve my problem. B
#20432 [Fbk->Csd]: flush() outputs garbage
ID: 20432 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Apache2 related Operating System: Win32 PHP Version: 4.3.0-pre2 New Comment: closing this. i'll reopen if it will turn out to be a php issue, which most likely won't happen. Previous Comments: [2002-11-15 11:18:55] [EMAIL PROTECTED] There have been a couple of reports of Apache 2.0.x sending its chunk headers incorrectly. One was triggered by PHP running as a CGI. I'm 99% sure this is a bug in Apache2. [2002-11-15 11:03:37] [EMAIL PROTECTED] let's keep it @ feedback then. [2002-11-15 10:57:27] [EMAIL PROTECTED] no comment, derick :-) i looked through the sapi code which seems to be right, it might be related to the apache version i'm using (2.0.39). i'll test this asap. harald [2002-11-14 13:41:15] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-14 13:37:08] [EMAIL PROTECTED] flush() outputs garbage: script: -- -- output: -- HTTP/1.1 200 OK Date: Thu, 14 Nov 2002 19:30:32 GMT Server: Apache/2.0.39 (Win32) PHP/4.2.2 Accept-Ranges: bytes X-Powered-By: PHP/4.2.1 Transfer-Encoding: chunked Content-Type: text/html; charset=ISO-8859-1 0 -- -- Edit this bug report at http://bugs.php.net/?id=20432&edit=1
#20432 [Fbk]: flush() outputs garbage
ID: 20432 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Apache2 related Operating System: Win32 PHP Version: 4.3.0-pre2 New Comment: There have been a couple of reports of Apache 2.0.x sending its chunk headers incorrectly. One was triggered by PHP running as a CGI. I'm 99% sure this is a bug in Apache2. Previous Comments: [2002-11-15 11:03:37] [EMAIL PROTECTED] let's keep it @ feedback then. [2002-11-15 10:57:27] [EMAIL PROTECTED] no comment, derick :-) i looked through the sapi code which seems to be right, it might be related to the apache version i'm using (2.0.39). i'll test this asap. harald [2002-11-14 13:41:15] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-14 13:37:08] [EMAIL PROTECTED] flush() outputs garbage: script: -- -- output: -- HTTP/1.1 200 OK Date: Thu, 14 Nov 2002 19:30:32 GMT Server: Apache/2.0.39 (Win32) PHP/4.2.2 Accept-Ranges: bytes X-Powered-By: PHP/4.2.1 Transfer-Encoding: chunked Content-Type: text/html; charset=ISO-8859-1 0 -- -- Edit this bug report at http://bugs.php.net/?id=20432&edit=1
#20432 [Opn->Fbk]: flush() outputs garbage
ID: 20432 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Win32 PHP Version: 4.3.0-pre2 New Comment: let's keep it @ feedback then. Previous Comments: [2002-11-15 10:57:27] [EMAIL PROTECTED] no comment, derick :-) i looked through the sapi code which seems to be right, it might be related to the apache version i'm using (2.0.39). i'll test this asap. harald [2002-11-14 13:41:15] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-14 13:37:08] [EMAIL PROTECTED] flush() outputs garbage: script: -- -- output: -- HTTP/1.1 200 OK Date: Thu, 14 Nov 2002 19:30:32 GMT Server: Apache/2.0.39 (Win32) PHP/4.2.2 Accept-Ranges: bytes X-Powered-By: PHP/4.2.1 Transfer-Encoding: chunked Content-Type: text/html; charset=ISO-8859-1 0 -- -- Edit this bug report at http://bugs.php.net/?id=20432&edit=1
#20432 [Fbk->Opn]: flush() outputs garbage
ID: 20432 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Win32 PHP Version: 4.3.0-pre2 New Comment: no comment, derick :-) i looked through the sapi code which seems to be right, it might be related to the apache version i'm using (2.0.39). i'll test this asap. harald Previous Comments: [2002-11-14 13:41:15] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-14 13:37:08] [EMAIL PROTECTED] flush() outputs garbage: script: -- -- output: -- HTTP/1.1 200 OK Date: Thu, 14 Nov 2002 19:30:32 GMT Server: Apache/2.0.39 (Win32) PHP/4.2.2 Accept-Ranges: bytes X-Powered-By: PHP/4.2.1 Transfer-Encoding: chunked Content-Type: text/html; charset=ISO-8859-1 0 -- -- Edit this bug report at http://bugs.php.net/?id=20432&edit=1
#18336 [Com]: Loop in PHP code causes crash in Apache2 instead of PHP error message
ID: 18336 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Won't fix Bug Type: Reproducible crash Operating System: Windows NT PHP Version: 4.2.1 New Comment: apache/1.3.23, winnt, php/4.1.2 (or maybe 4.1.3-dev??): when calling a function recursive (infinite loop), the apache child will be shut down with an windows' dr.watson error message 'stack overflow in apache.exe'. in apache error log it will be noticed. Previous Comments: [2002-07-14 05:42:09] [EMAIL PROTECTED] PHP can not guard for these mistakes as discussed on a few occasions on the PHP Developers mailing list. Derick [2002-07-14 05:40:10] [EMAIL PROTECTED] I wrote a function that called itself occasionally. When I accidentally changed the selection criteria the wrong way, the function went in to a loop calling itself. Instead of getting a PHP error message, Apache2 crashed with: Apache.exe Exception stack overflow(oxc00fd), Address: 0x00801366 There were no error messages in any logs, Apache, NT, or PHP. At first I thought it an Apache error as I upgraded to Apache 2 with the release of Apache 2.0.35 and PHP 4.2.0. That combination produced occasional random errors on some new extensions, including DOMXML, but nothing I needed for a production environment. An upgrade to PHP 4.2.1 made matters worse as it made every test site crash. An upgrade to Apache 2.0.39 did nothing to help PHP's problems. I tried php4-win32-latest.zip today, 2002-07-14, but it crashed Apache on start up. (Apache worked with everything non PHP.) php4-win32-STABLE-latest.zip solved the start up crash and solved the crashes with the other test sites. Back to the code that induced the first problem. I had just turned sessions on in the test site and thought the PHP session code had failed under Apache but most of the other sites were running happily with PHP 4.2.0 sessions under Apache2. Eventually I discovered the exact line causing the problem. In the past when I created an infinite loop in PHP, it either produced a PHP time out message or a PHP memory limit error. Because I have hundreds of Mb available and set php.ini's memory usage to many times the default, tiny test programs rarely run out of memory before timing out. Under PHP 4.2.0 onwards and Apache 2, the result is an Apache crash instead of a PHP error. The Apache 2 httpd.conf contains the defaults for all process related settings. php.ini contains the defaults except for an increase in the memory allocation to 30 Mb and changing error reporting to report all errors. -- Edit this bug report at http://bugs.php.net/?id=18336&edit=1
#20448 [Opn->Bgs]: I can't concat a string with +=
ID: 20448
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Strings related
Operating System: Windows 2000
PHP Version: 4.2.3
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
strings should be concatinated using a '.'
ex: $b .= "a";
Previous Comments:
[2002-11-15 10:45:31] [EMAIL PROTECTED]
Hi! I have the following code:
$a_data = array("a","b","c");
$s_data = "";
foreach($a_data as $data){
$s_data += $data;
}
echo $s_data;
I was trying to make $s_data contain "abc" but instead I get a 0. It
seems that += cube of types returns an int ignoring that the user is
trying to concat an string.
--
Edit this bug report at http://bugs.php.net/?id=20448&edit=1
#20448 [NEW]: I can't concat a string with +=
From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version: 4.2.3
PHP Bug Type: Strings related
Bug description: I can't concat a string with +=
Hi! I have the following code:
$a_data = array("a","b","c");
$s_data = "";
foreach($a_data as $data){
$s_data += $data;
}
echo $s_data;
I was trying to make $s_data contain "abc" but instead I get a 0. It seems
that += cube of types returns an int ignoring that the user is trying to
concat an string.
--
Edit bug report at http://bugs.php.net/?id=20448&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20448&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20448&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20448&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20448&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20448&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20448&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20448&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20448&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20448&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20448&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20448&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20448&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20448&r=isapi
#19259 [Csd->Ctl]: sort-functions don't work
ID: 19259
Updated by: [EMAIL PROTECTED]
-Summary: usort() leaves array unsorted
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Critical
Bug Type: Arrays related
-Operating System: OSF1 V4.0 1229
+Operating System: OSF1 V4.0
-PHP Version: 4.2.2
+PHP Version: 4.3.0 RC1
New Comment:
Broken again in 4.3.0RC1:
/usr/users/nohn/php-4.3.0RC1/ext/standard/tests/array/002.phpt
EXPECTED OUTPUT
-- Testing arsort() --
No second argument:
array(8) {
["-2147483647"]=>
array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
}
["test"]=>
int(27)
[2147483647]=>
string(4) "test"
[-2147483648]=>
string(6) "monkey"
[5]=>
string(4) "Test"
[17]=>
string(27) "PHP: Hypertext Preprocessor"
[0]=>
string(3) "PHP"
[16777216]=>
float(-0.33)
}
Using SORT_REGULAR:
array(8) {
["-2147483647"]=>
array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
}
["test"]=>
int(27)
[2147483647]=>
string(4) "test"
[-2147483648]=>
string(6) "monkey"
[5]=>
string(4) "Test"
[17]=>
string(27) "PHP: Hypertext Preprocessor"
[0]=>
string(3) "PHP"
[16777216]=>
float(-0.33)
}
Using SORT_NUMERIC:
array(8) {
["test"]=>
int(27)
["-2147483647"]=>
array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
}
[0]=>
string(3) "PHP"
[17]=>
string(27) "PHP: Hypertext Preprocessor"
[-2147483648]=>
string(6) "monkey"
[5]=>
string(4) "Test"
[2147483647]=>
string(4) "test"
[16777216]=>
float(-0.33)
}
Using SORT_STRING
array(8) {
[2147483647]=>
string(4) "test"
[-2147483648]=>
string(6) "monkey"
[5]=>
string(4) "Test"
[17]=>
string(27) "PHP: Hypertext Preprocessor"
[0]=>
string(3) "PHP"
["-2147483647"]=>
array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
}
["test"]=>
int(27)
[16777216]=>
float(-0.33)
}
-- Testing asort() --
No second argument:
array(8) {
[16777216]=>
float(-0.33)
[0]=>
string(3) "PHP"
[17]=>
string(27) "PHP: Hypertext Preprocessor"
[5]=>
string(4) "Test"
[-2147483648]=>
string(6) "monkey"
[2147483647]=>
string(4) "test"
["test"]=>
int(27)
["-2147483647"]=>
array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
}
}
Using SORT_REGULAR:
array(8) {
[16777216]=>
float(-0.33)
[0]=>
string(3) "PHP"
[17]=>
string(27) "PHP: Hypertext Preprocessor"
[5]=>
string(4) "Test"
[-2147483648]=>
string(6) "monkey"
[2147483647]=>
string(4) "test"
["test"]=>
int(27)
["-2147483647"]=>
array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
}
}
Using SORT_NUMERIC:
array(8) {
[16777216]=>
float(-0.33)
[-2147483648]=>
string(6) "monkey"
[2147483647]=>
string(4) "test"
[5]=>
string(4) "Test"
[17]=>
string(27) "PHP: Hypertext Preprocessor"
[0]=>
string(3) "PHP"
["-2147483647"]=>
array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
}
["test"]=>
int(27)
}
Using SORT_STRING
array(8) {
[16777216]=>
float(-0.33)
["test"]=>
int(27)
["-2147483647"]=>
array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
}
[0]=>
string(3) "PHP"
[17]=>
string(27) "PHP: Hypertext Preprocessor"
[5]=>
string(4) "Test"
[-2147483648]=>
string(6) "monkey"
[2147483647]=>
string(4) "test"
}
-- Testing krsort() --
No second argument:
array(8) {
[2147483647]=>
string(4) "test"
[16777216]=>
float(-0.33)
[17]=>
string(27) "PHP: Hypertext Preprocessor"
[5]=>
string(4) "Test"
["test"]=>
int(27)
[0]=>
string(3) "PHP"
["-2147483647"]=>
array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
}
[-2147483648]=>
string(6) "monkey"
}
Using SORT_REGULAR:
array(8) {
[2147483647]=>
string(4) "test"
[16777216]=>
float(-0.33)
[17]=>
string(27) "PHP: Hypertext Preprocessor"
[5]=>
string(4) "Test"
["test"]=>
int(27)
[0]=>
string(3) "PHP"
["-2147483647"]=>
array(2) {
[0]=>
string(6) "banana"
[1]=>
string(6) "orange"
}
[-2147483648]=>
string(6) "monkey"
}
Using SORT_NUMERIC:
array(8) {
[2147483647]=>
string(4) "test"
[16777216]=>
float(-0.33)
[17]=>
string(27) "PHP: Hypertext Preprocessor"
[5]=>
string(4) "Test"
["test"]=>
int(27)
#17552 [Com]: PHP Apache DSO Compile Failure: Unresolved Symbol: pthread_getspecific
ID: 17552 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Compile Failure Operating System: Linux 2.4.18 Glibc PHP Version: 4.2.1 New Comment: This occurs using apache-1.3.26 and php-4.2.3 on SuSE7.1 when using --with-apxs. I've tried adding LDFLAGS="-lpthread" just to persuade it to link against that library, but it still doesn't like me - ldd on libphp4.so makes no difference that way. Am reverting to --with-apache instead on the off-chance it works... Previous Comments: [2002-09-11 11:14:10] [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. [2002-06-17 21:25:09] [EMAIL PROTECTED] Can not reproduce this with. Please try this snapshot: http://snaps.php.net/php4-latest.tar.gz [2002-06-01 07:00:04] [EMAIL PROTECTED] ah, ok, static module. I'm reopening this since it still should work as a true DSO though. [2002-06-01 06:52:27] [EMAIL PROTECTED] as a static module, aka ./configure --with-apache=../apache_1.3.24 --with-java=/usr/lib/java --with-mysql=/usr/mysql the problem is we need it as a DSO. [2002-06-01 06:45:37] [EMAIL PROTECTED] So how did you got it compile then? 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/17552 -- Edit this bug report at http://bugs.php.net/?id=17552&edit=1
#20446 [Bgs]: negative filesize() returned on large files > 2Gb
ID: 20446
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *Directory/Filesystem functions
Operating System: NT4 - SP 6
PHP Version: 4.2.3
New Comment:
Although the number is no longer negative the size is unfortunately
inaccurate by quite a bit. It's a shame as php was in the running as
our cli for scripting on NT. I doubt it will pass acceptance testing
now.
Thanks for all your help it was appreciated.
Regards
Andy
Previous Comments:
[2002-11-15 09:33:41] [EMAIL PROTECTED]
You could try doing:
printf("%u", filesize("your_file"));
[2002-11-15 09:30:28] [EMAIL PROTECTED]
disk_total_space() appears to cope very well with large volumes
(100Gb+). Are there any work arounds for filesize() ?
[2002-11-15 09:26:17] [EMAIL PROTECTED]
This is not really a bug, PHP simply doesn't support unsigned integers,
and a signed integer on Windows/i386 only goes to 2^31 - 1 (about
2GB).
Ddderick
[2002-11-15 09:23:22] [EMAIL PROTECTED]
the following works fine on small files (<2Gb) but returns negative
numbers for files larger.
while ( $file = readdir($dp) ){
clearstatcache();
if (! ereg("^[.]+$|^$",$file) ){
$stats = stat("$DIRNAME$file");
echo "$DIRNAME$file\t" . $stats[7] . "\t" filesize("$DIRNAME$file") .
"\n";
}
}
--
Edit this bug report at http://bugs.php.net/?id=20446&edit=1
#20446 [Bgs]: negative filesize() returned on large files > 2Gb
ID: 20446
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *Directory/Filesystem functions
Operating System: NT4 - SP 6
PHP Version: 4.2.3
New Comment:
You could try doing:
printf("%u", filesize("your_file"));
Previous Comments:
[2002-11-15 09:30:28] [EMAIL PROTECTED]
disk_total_space() appears to cope very well with large volumes
(100Gb+). Are there any work arounds for filesize() ?
[2002-11-15 09:26:17] [EMAIL PROTECTED]
This is not really a bug, PHP simply doesn't support unsigned integers,
and a signed integer on Windows/i386 only goes to 2^31 - 1 (about
2GB).
Ddderick
[2002-11-15 09:23:22] [EMAIL PROTECTED]
the following works fine on small files (<2Gb) but returns negative
numbers for files larger.
while ( $file = readdir($dp) ){
clearstatcache();
if (! ereg("^[.]+$|^$",$file) ){
$stats = stat("$DIRNAME$file");
echo "$DIRNAME$file\t" . $stats[7] . "\t" filesize("$DIRNAME$file") .
"\n";
}
}
--
Edit this bug report at http://bugs.php.net/?id=20446&edit=1
#20446 [Bgs]: negative filesize() returned on large files > 2Gb
ID: 20446
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *Directory/Filesystem functions
Operating System: NT4 - SP 6
PHP Version: 4.2.3
New Comment:
disk_total_space() appears to cope very well with large volumes
(100Gb+). Are there any work arounds for filesize() ?
Previous Comments:
[2002-11-15 09:26:17] [EMAIL PROTECTED]
This is not really a bug, PHP simply doesn't support unsigned integers,
and a signed integer on Windows/i386 only goes to 2^31 - 1 (about
2GB).
Ddderick
[2002-11-15 09:23:22] [EMAIL PROTECTED]
the following works fine on small files (<2Gb) but returns negative
numbers for files larger.
while ( $file = readdir($dp) ){
clearstatcache();
if (! ereg("^[.]+$|^$",$file) ){
$stats = stat("$DIRNAME$file");
echo "$DIRNAME$file\t" . $stats[7] . "\t" filesize("$DIRNAME$file") .
"\n";
}
}
--
Edit this bug report at http://bugs.php.net/?id=20446&edit=1
#20446 [Opn->Bgs]: negative filesize() returned on large files > 2Gb
ID: 20446
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: *Directory/Filesystem functions
Operating System: NT4 - SP 6
PHP Version: 4.2.3
New Comment:
This is not really a bug, PHP simply doesn't support unsigned integers,
and a signed integer on Windows/i386 only goes to 2^31 - 1 (about
2GB).
Ddderick
Previous Comments:
[2002-11-15 09:23:22] [EMAIL PROTECTED]
the following works fine on small files (<2Gb) but returns negative
numbers for files larger.
while ( $file = readdir($dp) ){
clearstatcache();
if (! ereg("^[.]+$|^$",$file) ){
$stats = stat("$DIRNAME$file");
echo "$DIRNAME$file\t" . $stats[7] . "\t" filesize("$DIRNAME$file") .
"\n";
}
}
--
Edit this bug report at http://bugs.php.net/?id=20446&edit=1
#20446 [NEW]: negative filesize() returned on large files > 2Gb
From: [EMAIL PROTECTED]
Operating system: NT4 - SP 6
PHP version: 4.2.3
PHP Bug Type: *Directory/Filesystem functions
Bug description: negative filesize() returned on large files > 2Gb
the following works fine on small files (<2Gb) but returns negative numbers
for files larger.
while ( $file = readdir($dp) ){
clearstatcache();
if (! ereg("^[.]+$|^$",$file) ){
$stats = stat("$DIRNAME$file");
echo "$DIRNAME$file\t" . $stats[7] . "\t" filesize("$DIRNAME$file") .
"\n";
}
}
--
Edit bug report at http://bugs.php.net/?id=20446&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20446&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20446&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20446&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20446&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20446&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20446&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20446&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20446&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20446&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20446&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20446&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20446&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20446&r=isapi
#20445 [Opn->Csd]: HTTP_POST_FILES empty
ID: 20445 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: HTTP related Operating System: RedHat 8.0 PHP Version: 4.2.2 New Comment: 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. Previous Comments: [2002-11-15 09:07:22] [EMAIL PROTECTED] Hello, I have upgrated from redhat 7.2 to 8.0. Looks like the php version is 4.2.2. I cannot post files anymore. The $HTTP_POST_FILES['file1']['name'] is empty. N.B. : The register_globals is on. What is happening -- Edit this bug report at http://bugs.php.net/?id=20445&edit=1
#20444 [Opn]: Various compile warnings and one error.
ID: 20444 Updated by: [EMAIL PROTECTED] -Summary: Various compile errors Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: OSF1/Tru64 PHP Version: 4.3.0-RC1 New Comment: feel free to come up with some patch to fix those _WARNINGS_... Previous Comments: [2002-11-15 05:32:56] [EMAIL PROTECTED] With built-in MySQL-Support it works. [2002-11-15 05:29:25] [EMAIL PROTECTED] The interesting part was cut off: Unresolved: mysql_character_set_name mysql_real_escape_string collect2: ld returned 1 exit status Stop. [2002-11-15 05:28:36] [EMAIL PROTECTED] updated Version [2002-11-15 05:28:21] [EMAIL PROTECTED] './configure' '--prefix=/usr/local' '--with-apache=/usr/local/Apachetoolbox-1.5.56/apache_1.3.24' '--enable-exif' '--enable-track-vars' '--with-calendar=shared' '--enable-safe-mode' '--enable-magic-quotes' '--enable-trans-sid' '--enable-wddx' '--enable-ftp' '--with-openssl=/usr/local' '--with-oci8=/appl/oracle/product/8.1.6' '--with-mysql=/usr/local/mysql': In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/ctype/ctype.c:23: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:60: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:85: warning: redefinition of `uchar' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/sys/types.h:580: warning: `uchar' previously declared here /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c: In function `exif_process_IFD_in_JPEG': /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/ftp/php_ftp.c:26: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/ftp/ftp.c:22: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/mysql/php_mysql.c:32: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here /usr/users/nohn/php-4.3.0RC1/ext/mysql/php_mysql.c: In function `zif_mysql_client_encoding': /usr/users/nohn/php-4.3.0RC1/ext/mysql/php_mysql.c:1121: warning: cast to pointer from integer of different size In file included from /usr/lo
#20410 [Opn->Bgs]: Multiple CPU Machines Lock Files
ID: 20410 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Windows 2000 Server PHP Version: 4.2.3 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2002-11-15 04:38:04] [EMAIL PROTECTED] Sorry, same issue as before. [2002-11-15 04:34:37] [EMAIL PROTECTED] Maybe it's not too much work to tell why you didn't get it to work? [2002-11-15 04:33:52] [EMAIL PROTECTED] Tried the compiled version (2nd one) and we couldn't actually get it to work. [2002-11-13 12:01:09] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-13 09:42:16] [EMAIL PROTECTED] You get what appear to be random parse errors on any page while running the eZ-publish content management system. We installed this on machines with a single processor and on machines with multiple processors and the results we saw were that on a single processor the content worked fine with multiple requests. Where as with the multiple processor machines even if we did two refreshes in quick succession we got a parse error. We checked the code to see if it was corrupt, this was proved not to be the case. What we think is going on is that the CPU's are locking the files that are being accessed. Therefore those which get accessed a lot such as the sessions are causing problems. -- Edit this bug report at http://bugs.php.net/?id=20410&edit=1
#20443 [Opn->Fbk]: Jpeg colors change
ID: 20443
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: GD related
Operating System: Linux
PHP Version: 4.2.3
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
Previous Comments:
[2002-11-15 04:20:02] [EMAIL PROTECTED]
Resized images generated from jpg files displaying botched or dimmed
colors after update from 4.2.2 to 4.2.3.
Example code:
# get the data from the original, large image
$src_img = ImageCreateFromJPEG($image);
# create new image
$dst_img = ImageCreate($new_w,$new_h);
# allocate colors for background and border
$mattecolor = ImageColorAllocate($dst_img,$mr,$mg,$mb);
$bordercolor = ImageColorAllocate($dst_img,$br,$bg,$bb);
# fill image with matte color
ImageFill($dst_img,0,0,$mattecolor);
# resize source image and place the copy in the destination image
ImageCopyResized($dst_img,$src_img,
$margin_x,$margin_y,
0,0,$thumb_w,$thumb_h,
$old_x,$old_y);
# if there is a border set, draw a rectangle around the thumbnail
if
($border==1){imageRectangle($dst_img,0,0,$new_w-1,$new_h-1,$bordercolor);}
# create final image and free up the memory
ImageJPEG($dst_img);
ImageDestroy($dst_img);
--
Edit this bug report at http://bugs.php.net/?id=20443&edit=1
#20441 [Opn->Bgs]: PHP_AUTH_USER isn't set
ID: 20441
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Apache related
Operating System: Redhat Linux 7.1 kernel 2.4.2-2
PHP Version: 4.3.0-pre2
New Comment:
It was fixed to be like it should be since PHP 3.
Previous Comments:
[2002-11-15 03:52:04] [EMAIL PROTECTED]
So I should use $_SERVER["REMOTE_USER"] if I use .htaccess and
$_SERVER["PHP_AUTH_USER"] when I header the authentication?
Why is this behaviour changed without notice?
[2002-11-15 03:10:35] [EMAIL PROTECTED]
You need to decide if you are using an external auth mechanism or http
auth from php. You can't do both.
[2002-11-15 02:58:24] [EMAIL PROTECTED]
I've upgraded PHP 4.2.3 to the beta 4.3.0-pre2 and I've set register
globals on in php.ini.
My Apache version is 1.3.24.
PHP configure:
./configure --with-apxs=/usr/local/apache/bin/apxs
--with-mysql=/usr/local/mysql --enable-ftp --with-openssl
The script is using this .htaccess-file
AuthType Basic
AuthName 'Urenregistratie'
AuthUserFile /htpasswd/urenreg
require valid-user
I am sure that Apache is setting the PHP_AUTH_USER because the
following script gives the correct output:
// begin dirty hack
$headers = apache_request_headers();
foreach ($headers as $header => $value) {
if ($header == "Authorization")
{
$value = str_replace(" ", "", $value);
$value = str_replace("Basic", "", $value);
$userArray = explode(":", base64_decode($value));
$PHP_AUTH_USER = $userArray[0];
}
}
echo $PHP_AUTH_USER;
// end dirty hack
If I echo $PHP_AUTH_USER or $_SERVER["PHP_AUTH_USER"] above this script
I am getting a empty result.
Note: the script was functioning 100% properly with php 4.2.3
--
Edit this bug report at http://bugs.php.net/?id=20441&edit=1
#20445 [NEW]: HTTP_POST_FILES empty
From: [EMAIL PROTECTED] Operating system: RedHat 8.0 PHP version: 4.2.2 PHP Bug Type: HTTP related Bug description: HTTP_POST_FILES empty Hello, I have upgrated from redhat 7.2 to 8.0. Looks like the php version is 4.2.2. I cannot post files anymore. The $HTTP_POST_FILES['file1']['name'] is empty. N.B. : The register_globals is on. What is happening -- Edit bug report at http://bugs.php.net/?id=20445&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20445&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20445&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20445&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20445&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20445&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20445&r=support Expected behavior: http://bugs.php.net/fix.php?id=20445&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20445&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20445&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20445&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20445&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20445&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20445&r=isapi
#19566 [Opn->Csd]: get_declared_classes() segfaults
ID: 19566 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Scripting Engine problem Operating System: Linux PPC PHP Version: 4.3.0-dev New Comment: 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. Previous Comments: [2002-11-07 12:36:54] [EMAIL PROTECTED] updated to latest PHP version this was reproduced with.. [2002-11-07 01:53:10] [EMAIL PROTECTED] reopen [2002-11-07 01:49:06] [EMAIL PROTECTED] It's not. For the record I'd like to point out the fact this is a Linux-PPC problem, not a Linux-i386 problem. ;-) [2002-11-07 01:40:25] [EMAIL PROTECTED] Sorry but I can't reproduce it with the latest CVS. [Thu Nov 7 - 08:37:50 - root ~/php4]# gdb php GNU gdb Red Hat Linux (5.1-1) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run test.php Starting program: /usr/local/bin/php test.php Program exited normally. (gdb) It looks fixed. [2002-11-07 01:31:31] [EMAIL PROTECTED] As of 12:00 (PST) today (2002/11/6) this crash was still an issue. I compiled the latest snap while trying to fix another segfault, and this segfault still occurs. 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/19566 -- Edit this bug report at http://bugs.php.net/?id=19566&edit=1
#19848 [Com]: Wrong $_REQUEST values ($_FILES appearance is wacky)
ID: 19848
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: HTTP related
Operating System: *any
PHP Version: 4.2.3,4,3.0-dev
Assigned To: sterling
New Comment:
not sure if this is important, but import_request_variables imports the
wrong thing.
html:
code:
import_request_variables("GP", "__");
result:
$__d = array (
'name' => array ( 'file' => '' ),
'type' => array ( 'file' => '' ),
'tmp_name' => array ( 'file' => '' ),
'error' => array ( 'file' => 4 ),
'size' => array ( 'file' => 0 )
)
Previous Comments:
[2002-10-27 20:47:21] [EMAIL PROTECTED]
Fixed in CVS... $_FILES is no longer present in $_REQUEST...
[2002-10-24 18:42:14] [EMAIL PROTECTED]
This test form strips 3 characters from the posted variable:
2 dimensional array - this test form strips 8 characters from the
posted variable:
For every dimension added to the array, another 4 characters are
scripted from the beginning of the posted variable. Works on PHP
version less than 4.2.2 and earlier.
[2002-10-20 22:17:12] [EMAIL PROTECTED]
The 'voting' on php-dev was in favour for removing the $_FILES from
$_REQUEST..as it doesn't make much sense
to have them there. Just FYI. :)
--Jani
[2002-10-20 22:14:01] [EMAIL PROTECTED]
Sterling Hughes is working on this issue, according to posts to
php-dev.
[2002-10-16 06:29:23] [EMAIL PROTECTED]
Also got the same cases.
print_r($_POST['server']);
it comes out:
---
Array
(
[0] => ASP
[1] => C#
[2] => FUSION
[3] =>
[4] =>
[5] => PHP
)
Apache/1.3.26, Win98
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/19848
--
Edit this bug report at http://bugs.php.net/?id=19848&edit=1
#20381 [Ver->Csd]: array_merge_recursive mangles input arrays
ID: 20381 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Verified +Status: Closed Bug Type: Arrays related Operating System: SuSE Linux 7.3 PHP Version: 4.3.0-dev New Comment: 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. Previous Comments: [2002-11-12 07:22:51] [EMAIL PROTECTED] They're actually mangled with CVS HEAD too..somehow I missed that or had those print_r() lines in wrong place. :I [2002-11-12 07:16:46] [EMAIL PROTECTED] In 4.3.2 the source arrays are mangled even when you don't add them to the result. This was just for a nicer, smaller example. Example // Same $a and $b as before $result = array_merge_recursive( $a, $b ); print_r( $c ); print_r( $a ); print_r( $b ); // have sadly the same effect [2002-11-12 06:33:56] [EMAIL PROTECTED] Reproduced using latest CVS. The original arrays are fine, but when they're added to the resulting array, then they get mangled. [2002-11-11 23:04:18] [EMAIL PROTECTED] Similar to #14990 (exept that the demo code there runs fine) and the first source array gets mangled. Example = 1, 'a2' => array( 1, 2, 3 ), 'a3' => array( 'a' => array( 10, 20, 30 ), 'b' => 'b' ) ); $b = array( 'a1' => 2, 'a2' => array( 3, 4, 5 ), 'a3' => array( 'c' => 'cc', 'a' => array( 10, 40 ) ) ); $c['result'] = array_merge_recursive( $a, $b ); $c['a'] = $a; $c['b'] = $b; print_r( $c ); ?> Example Output Array ( [result] => Array ( [a1] => Array ( [0] => 1 [1] => 2 ) [a2] => Array ( [0] => 1 [1] => 2 [2] => 3 [3] => 3 [4] => 4 [5] => 5 ) [a3] => Array ( [a] => Array ( [0] => 10 [1] => 20 [2] => 30 [3] => 10 [4] => 40 ) [b] => b [c] => cc ) ) [a] => Array ( [a1] => 1 [a2] => Array ( [0] => 1 [1] => 2 [2] => 3 [3] => 3 [4] => 4 [5] => 5 ) [a3] => Array ( [a] => Array ( [0] => 10 [1] => 20 [2] => 30 [3] => 10 [4] => 40 ) [b] => b [c] => cc ) ) [b] => Array ( [a1] => 2 [a2] => Array ( [0] => 3 [1] => 4 [2] => 5 ) [a3] => Array ( [c] => cc [a] => Array ( [0] => 10 [1] => 40 ) ) ) ) -- Edit this bug report at http://bugs.php.net/?id=20381&edit=1
#16828 [Com]: Excel remains resident in memory after using it via PHP+COM
ID: 16828
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: COM related
Operating System: Win 2000
PHP Version: 4.2.0
New Comment:
Tested this (stripped) script on PHP 4.2.3 and 4.3.0pre2 under a
Windows 2000 Advanced server with IIS and ISAPI interface:
---
$excel = new COM("Excel.Application");
$excel->Workbooks->open("sales.xls");
$book = $excel->ActiveWorkbook;
$cell = $excel->ActiveWorkbook->Worksheets[1]->Cells(1,1); // *
$cell->Activate(); // *
$cell->Value = "Debug-Test"; // *
$book->saveas("sales2.xls");
$book->Close();
unset($book);
$excel->Quit();
$excel->Release();
unset($excel);
---
Running this script will cause Excel to stay in memory on the server
and has to be removed manually. Commenting the lines ending with the
asterisk will prevent this (but makes this script useless).
I've tried many different ways to accomplish this task, for example:
$sheet = $excel->ActiveWorkbook->Worksheets(1);
$cell = $sheet->Cells(1,1);
instead of
$cell = $excel->ActiveWorkbook->Worksheets[1]->Cells(1,1);
Or, changing another element of the worksheet, like the title. Or,
creating a new sheet and entering data in that one. All resulted in a
hanging Excel in memory.
It seems to come down to changing something in the worksheet object,
which is messing something up internally.
This also seems to have something to do with bug #19156. I haven't
downloaded the latest snapshot, but I'm assuming that that bugfix is in
4.3.0pre2.
So... Please reopen this bug, I don't think it's fixed yet.
Previous Comments:
[2002-04-27 06:15:21] [EMAIL PROTECTED]
yes. i only wasn't able to test it thus i left the bugreport open. but
seems you are quicker than i am ;)
[2002-04-26 17:12:58] [EMAIL PROTECTED]
I produced this with 4.1.1 and the shorter script of :
$excel = new COM("Excel.Application");
$excel->application->DisplayAlerts = "False";
$excel->Quit();
$excel->Release();
$excel=null;
In the current development cvs version ( 4.3.0-dev 26/04/02), once the
script execution is complete excel appears to be closed correctly.
(maybe http://cvs.php.net/co.php/php4/ext/com/com.h?r=1.11 was the cvs
fix for this?)
[2002-04-25 14:32:28] [EMAIL PROTECTED]
When using Excel.Application via the COM interface with PHP version
(4.1.2 and 4.2.0), EXCEL.EXE stays resident in memory after script
execution.
To verify this is not an Excel issue, i created two separate scripts
that did the same thing; one in perl, and one in PHP.
After execution of the perl script, no EXCEL.EXE is in the Task list;
yet after execution of the PHP script, EXCEL.EXE is in the Task list.
Some more info and test scripts are available at:
http://www.furt.com/code/php/com_issues/
--
Edit this bug report at http://bugs.php.net/?id=16828&edit=1
#20433 [Opn]: Unaligned access error messages at runtime
ID: 20433 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Warning Operating System: Tru64 -PHP Version: 4.3.0-pre2 +PHP Version: 4.3.0-RC1 New Comment: Verified with 4.3.0RC1 Previous Comments: [2002-11-14 15:34:13] [EMAIL PROTECTED] When testing cli/cgi, unaligned access messages are displayed. Following modifications fixes problem. in main/php_globals.h int log_errors_max_len changed to long log_errors_max_len in ext/standard/file.h int default_socket_timeout int auto_detect_line_endings changed to long default_socket_timeout long auto_detect_line_endings -- Edit this bug report at http://bugs.php.net/?id=20433&edit=1
#20444 [Opn]: Various compile errors
ID: 20444 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: OSF1/Tru64 PHP Version: 4.3.0-RC1 New Comment: With built-in MySQL-Support it works. Previous Comments: [2002-11-15 05:29:25] [EMAIL PROTECTED] The interesting part was cut off: Unresolved: mysql_character_set_name mysql_real_escape_string collect2: ld returned 1 exit status Stop. [2002-11-15 05:28:36] [EMAIL PROTECTED] updated Version [2002-11-15 05:28:21] [EMAIL PROTECTED] './configure' '--prefix=/usr/local' '--with-apache=/usr/local/Apachetoolbox-1.5.56/apache_1.3.24' '--enable-exif' '--enable-track-vars' '--with-calendar=shared' '--enable-safe-mode' '--enable-magic-quotes' '--enable-trans-sid' '--enable-wddx' '--enable-ftp' '--with-openssl=/usr/local' '--with-oci8=/appl/oracle/product/8.1.6' '--with-mysql=/usr/local/mysql': In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/ctype/ctype.c:23: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:60: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:85: warning: redefinition of `uchar' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/sys/types.h:580: warning: `uchar' previously declared here /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c: In function `exif_process_IFD_in_JPEG': /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/ftp/php_ftp.c:26: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/ftp/ftp.c:22: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/mysql/php_mysql.c:32: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here /usr/users/nohn/php-4.3.0RC1/ext/mysql/php_mysql.c: In function `zif_mysql_client_encoding': /usr/users/nohn/php-4.3.0RC1/ext/mysql/php_mysql.c:1121: warning: cast to pointer from integer of different size In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /
#20444 [Opn]: Various compile errors
ID: 20444 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: OSF1/Tru64 PHP Version: 4.3.0-RC1 New Comment: The interesting part was cut off: Unresolved: mysql_character_set_name mysql_real_escape_string collect2: ld returned 1 exit status Stop. Previous Comments: [2002-11-15 05:28:36] [EMAIL PROTECTED] updated Version [2002-11-15 05:28:21] [EMAIL PROTECTED] './configure' '--prefix=/usr/local' '--with-apache=/usr/local/Apachetoolbox-1.5.56/apache_1.3.24' '--enable-exif' '--enable-track-vars' '--with-calendar=shared' '--enable-safe-mode' '--enable-magic-quotes' '--enable-trans-sid' '--enable-wddx' '--enable-ftp' '--with-openssl=/usr/local' '--with-oci8=/appl/oracle/product/8.1.6' '--with-mysql=/usr/local/mysql': In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/ctype/ctype.c:23: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:60: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:85: warning: redefinition of `uchar' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/sys/types.h:580: warning: `uchar' previously declared here /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c: In function `exif_process_IFD_in_JPEG': /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/ftp/php_ftp.c:26: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/ftp/ftp.c:22: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/mysql/php_mysql.c:32: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here /usr/users/nohn/php-4.3.0RC1/ext/mysql/php_mysql.c: In function `zif_mysql_client_encoding': /usr/users/nohn/php-4.3.0RC1/ext/mysql/php_mysql.c:1121: warning: cast to pointer from integer of different size In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/oci8/oci8.c:61: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_li
#20444 [Opn]: Various compile errors
ID: 20444 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: OSF1/Tru64 -PHP Version: 4.3.0-pre2 +PHP Version: 4.3.0-RC1 New Comment: updated Version Previous Comments: [2002-11-15 05:28:21] [EMAIL PROTECTED] './configure' '--prefix=/usr/local' '--with-apache=/usr/local/Apachetoolbox-1.5.56/apache_1.3.24' '--enable-exif' '--enable-track-vars' '--with-calendar=shared' '--enable-safe-mode' '--enable-magic-quotes' '--enable-trans-sid' '--enable-wddx' '--enable-ftp' '--with-openssl=/usr/local' '--with-oci8=/appl/oracle/product/8.1.6' '--with-mysql=/usr/local/mysql': In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/ctype/ctype.c:23: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:60: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:85: warning: redefinition of `uchar' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/sys/types.h:580: warning: `uchar' previously declared here /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c: In function `exif_process_IFD_in_JPEG': /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/ftp/php_ftp.c:26: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/ftp/ftp.c:22: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/mysql/php_mysql.c:32: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here /usr/users/nohn/php-4.3.0RC1/ext/mysql/php_mysql.c: In function `zif_mysql_client_encoding': /usr/users/nohn/php-4.3.0RC1/ext/mysql/php_mysql.c:1121: warning: cast to pointer from integer of different size In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/oci8/oci8.c:61: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36,
#20444 [NEW]: Various compile errors
From: [EMAIL PROTECTED] Operating system: OSF1/Tru64 PHP version: 4.3.0-pre2 PHP Bug Type: Compile Failure Bug description: Various compile errors './configure' '--prefix=/usr/local' '--with-apache=/usr/local/Apachetoolbox-1.5.56/apache_1.3.24' '--enable-exif' '--enable-track-vars' '--with-calendar=shared' '--enable-safe-mode' '--enable-magic-quotes' '--enable-trans-sid' '--enable-wddx' '--enable-ftp' '--with-openssl=/usr/local' '--with-oci8=/appl/oracle/product/8.1.6' '--with-mysql=/usr/local/mysql': In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/ctype/ctype.c:23: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:60: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:85: warning: redefinition of `uchar' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/sys/types.h:580: warning: `uchar' previously declared here /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c: In function `exif_process_IFD_in_JPEG': /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size /usr/users/nohn/php-4.3.0RC1/ext/exif/exif.c:3031: warning: cast from pointer to integer of different size In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/ftp/php_ftp.c:26: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/ftp/ftp.c:22: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/mysql/php_mysql.c:32: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here /usr/users/nohn/php-4.3.0RC1/ext/mysql/php_mysql.c: In function `zif_mysql_client_encoding': /usr/users/nohn/php-4.3.0RC1/ext/mysql/php_mysql.c:1121: warning: cast to pointer from integer of different size In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/oci8/oci8.c:61: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va-alpha.h:36: warning: redefinition of `va_list' /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/va_list.h:7: warning: `va_list' previously declared here In file included from /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.95.2/include/stdarg.h:36, from /usr/users/nohn/php-4.3.0RC1/Zend/zend.h:63, from /usr/users/nohn/php-4.3.0RC1/main/php.h:34, from /usr/users/nohn/php-4.3.0RC1/ext/openssl/openssl.c:27: /usr/local/lib/gcc-lib/alphaev6-dec-osf4.0f/2.9
#20425 [Opn->Bgs]: session file cleared after execution of header("location ...
ID: 20425
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: Linux
PHP Version: 4.2.3
Previous Comments:
[2002-11-15 04:38:12] [EMAIL PROTECTED]
Maybe it won't be a bug, but I wonder what it is.
I have fixed my problem by simply, recompiling PHP as a module
Now everything works fine again.
Thanks, Stefano
[2002-11-14 10:50:02] [EMAIL PROTECTED]
Ok, I corrected the errors as missing single quote and missing space
between location and otherfile.php.
The fact that induced me to think to a PHP bug, is that these same
scripts work fine on 2 different server with same configuration
(php+apache) as my local one.
Thanks, stefano
[2002-11-14 09:09:34] [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.
A number of mistakes in your script are likely causes of your script
not to working.
1) Instead of session_register("sessione"); add variables to the
session in this fassion $_SESSION['sessione'] = 'value';
2) $sessione[nome]=$fnome; is wrong, what's 'none', it probably should
be $sessione['nome']=$fnome;, no?
3) Your location header is wrong for 2 reasons, 1st you are using
relatives pathes, always a BAD idea and your
header("Location:otherfile.php?".SID); is missing a space between
Location: and otherfile.
4) Use session_id() and not SID to retrieve the session id.
[2002-11-14 08:41:24] [EMAIL PROTECTED]
You will find some useful information here: 2nd comment on
http://www.php.net/manual/en/function.session-register.php
[2002-11-14 05:03:09] [EMAIL PROTECTED]
After execution of header("Location:otherfile.php?".SID);
the session file previously created does not contain all the items
posted by a form.
My configuration:
Linux RH6.2 (tested also RH7.2 and RH 7.3)
Apache 1.3.27
PHP 4.2.3 compiled as a CGI
'./configure' '--enable-shared' '--with-system-regex'
'--with-gd=/usr/local' '--enable-ftp' '--with-mysql'
'--enable-track-vars' '--with-ttf=/usr' '--enable-gd-native-ttf'
'--with-jpeg-dir' '--with-png-dir' '--with-zlib'
'--enable-force-cgi-redirect' '--enable-dbase'
'--with-config-file-path=/usr/local/apache/conf'
register_globals=1
session_trans_sid=1 (tested also =0)
I have 2 files index.php and lib1.inc
When I start index.php a session file is created (under /tmp) and
contains the variable name ( !sessione| ).
When I post the form (in index.php), the session file under /tmp does
not get updated.
If I comment out the line header("Location:otherfile.php?".SID);
instead, the session file is updated with the values posted by the
form.
It behaves as if execution of header("location ... cleared the session
file.
These are the files involved:
LIB1.INC
INDEX.PHP
login
Login
Username
Password
--
Edit this bug report at http://bugs.php.net/?id=20425&edit=1
#20425 [Bgs->Opn]: session file cleared after execution of header("location ...
ID: 20425
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: Session related
Operating System: Linux
PHP Version: 4.2.3
New Comment:
Maybe it won't be a bug, but I wonder what it is.
I have fixed my problem by simply, recompiling PHP as a module
Now everything works fine again.
Thanks, Stefano
Previous Comments:
[2002-11-14 10:50:02] [EMAIL PROTECTED]
Ok, I corrected the errors as missing single quote and missing space
between location and otherfile.php.
The fact that induced me to think to a PHP bug, is that these same
scripts work fine on 2 different server with same configuration
(php+apache) as my local one.
Thanks, stefano
[2002-11-14 09:09:34] [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.
A number of mistakes in your script are likely causes of your script
not to working.
1) Instead of session_register("sessione"); add variables to the
session in this fassion $_SESSION['sessione'] = 'value';
2) $sessione[nome]=$fnome; is wrong, what's 'none', it probably should
be $sessione['nome']=$fnome;, no?
3) Your location header is wrong for 2 reasons, 1st you are using
relatives pathes, always a BAD idea and your
header("Location:otherfile.php?".SID); is missing a space between
Location: and otherfile.
4) Use session_id() and not SID to retrieve the session id.
[2002-11-14 08:41:24] [EMAIL PROTECTED]
You will find some useful information here: 2nd comment on
http://www.php.net/manual/en/function.session-register.php
[2002-11-14 05:03:09] [EMAIL PROTECTED]
After execution of header("Location:otherfile.php?".SID);
the session file previously created does not contain all the items
posted by a form.
My configuration:
Linux RH6.2 (tested also RH7.2 and RH 7.3)
Apache 1.3.27
PHP 4.2.3 compiled as a CGI
'./configure' '--enable-shared' '--with-system-regex'
'--with-gd=/usr/local' '--enable-ftp' '--with-mysql'
'--enable-track-vars' '--with-ttf=/usr' '--enable-gd-native-ttf'
'--with-jpeg-dir' '--with-png-dir' '--with-zlib'
'--enable-force-cgi-redirect' '--enable-dbase'
'--with-config-file-path=/usr/local/apache/conf'
register_globals=1
session_trans_sid=1 (tested also =0)
I have 2 files index.php and lib1.inc
When I start index.php a session file is created (under /tmp) and
contains the variable name ( !sessione| ).
When I post the form (in index.php), the session file under /tmp does
not get updated.
If I comment out the line header("Location:otherfile.php?".SID);
instead, the session file is updated with the values posted by the
form.
It behaves as if execution of header("location ... cleared the session
file.
These are the files involved:
LIB1.INC
INDEX.PHP
login
Login
Username
Password
--
Edit this bug report at http://bugs.php.net/?id=20425&edit=1
#20410 [Fbk->Opn]: Multiple CPU Machines Lock Files
ID: 20410 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Windows 2000 Server PHP Version: 4.2.3 New Comment: Sorry, same issue as before. Previous Comments: [2002-11-15 04:34:37] [EMAIL PROTECTED] Maybe it's not too much work to tell why you didn't get it to work? [2002-11-15 04:33:52] [EMAIL PROTECTED] Tried the compiled version (2nd one) and we couldn't actually get it to work. [2002-11-13 12:01:09] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-13 09:42:16] [EMAIL PROTECTED] You get what appear to be random parse errors on any page while running the eZ-publish content management system. We installed this on machines with a single processor and on machines with multiple processors and the results we saw were that on a single processor the content worked fine with multiple requests. Where as with the multiple processor machines even if we did two refreshes in quick succession we got a parse error. We checked the code to see if it was corrupt, this was proved not to be the case. What we think is going on is that the CPU's are locking the files that are being accessed. Therefore those which get accessed a lot such as the sessions are causing problems. -- Edit this bug report at http://bugs.php.net/?id=20410&edit=1
#20410 [Opn->Fbk]: Multiple CPU Machines Lock Files
ID: 20410 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Windows 2000 Server PHP Version: 4.2.3 New Comment: Maybe it's not too much work to tell why you didn't get it to work? Previous Comments: [2002-11-15 04:33:52] [EMAIL PROTECTED] Tried the compiled version (2nd one) and we couldn't actually get it to work. [2002-11-13 12:01:09] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-13 09:42:16] [EMAIL PROTECTED] You get what appear to be random parse errors on any page while running the eZ-publish content management system. We installed this on machines with a single processor and on machines with multiple processors and the results we saw were that on a single processor the content worked fine with multiple requests. Where as with the multiple processor machines even if we did two refreshes in quick succession we got a parse error. We checked the code to see if it was corrupt, this was proved not to be the case. What we think is going on is that the CPU's are locking the files that are being accessed. Therefore those which get accessed a lot such as the sessions are causing problems. -- Edit this bug report at http://bugs.php.net/?id=20410&edit=1
#20410 [Fbk->Opn]: Multiple CPU Machines Lock Files
ID: 20410 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Windows 2000 Server PHP Version: 4.2.3 New Comment: Tried the compiled version (2nd one) and we couldn't actually get it to work. Previous Comments: [2002-11-13 12:01:09] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-11-13 09:42:16] [EMAIL PROTECTED] You get what appear to be random parse errors on any page while running the eZ-publish content management system. We installed this on machines with a single processor and on machines with multiple processors and the results we saw were that on a single processor the content worked fine with multiple requests. Where as with the multiple processor machines even if we did two refreshes in quick succession we got a parse error. We checked the code to see if it was corrupt, this was proved not to be the case. What we think is going on is that the CPU's are locking the files that are being accessed. Therefore those which get accessed a lot such as the sessions are causing problems. -- Edit this bug report at http://bugs.php.net/?id=20410&edit=1
#12513 [Csd->Opn]: Automatic Rollback of open transactions in persistent links
ID: 12513 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open -Bug Type: MySQL related +Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.0.6 -Assigned To: zak +Assigned To: georg New Comment: Fix revoked. We have to wait until the libmysql-function mysql_restore_connection is available. Changed Status to Open Changed Category to Feature request Previous Comments: [2002-07-10 09:19:19] [EMAIL PROTECTED] Its fixed now in the current CVS-release [2002-05-26 13:43:06] [EMAIL PROTECTED] Looks like something for Zak to check... [2002-04-27 15:52:08] [EMAIL PROTECTED] this is a bug, not a feature request. [2001-08-01 09:07:32] [EMAIL PROTECTED] reclassified [2001-08-01 09:06:41] [EMAIL PROTECTED] When using mysql_pconnect() the connection to the database (abviously) persists. This has the site-effect that open transactions at the end of the page request remain open if you do not explicitly commit/rollback the transaction. This can happen very easily if you have an error in your script. The Postgres driver does an automatic rollback at request shutdown, the mysql driver should do the same. -- Edit this bug report at http://bugs.php.net/?id=12513&edit=1
#20443 [NEW]: Jpeg colors change
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.2.3
PHP Bug Type: GD related
Bug description: Jpeg colors change
Resized images generated from jpg files displaying botched or dimmed colors
after update from 4.2.2 to 4.2.3.
Example code:
# get the data from the original, large image
$src_img = ImageCreateFromJPEG($image);
# create new image
$dst_img = ImageCreate($new_w,$new_h);
# allocate colors for background and border
$mattecolor = ImageColorAllocate($dst_img,$mr,$mg,$mb);
$bordercolor = ImageColorAllocate($dst_img,$br,$bg,$bb);
# fill image with matte color
ImageFill($dst_img,0,0,$mattecolor);
# resize source image and place the copy in the destination image
ImageCopyResized($dst_img,$src_img,
$margin_x,$margin_y,
0,0,$thumb_w,$thumb_h,
$old_x,$old_y);
# if there is a border set, draw a rectangle around the thumbnail
if
($border==1){imageRectangle($dst_img,0,0,$new_w-1,$new_h-1,$bordercolor);}
# create final image and free up the memory
ImageJPEG($dst_img);
ImageDestroy($dst_img);
--
Edit bug report at http://bugs.php.net/?id=20443&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20443&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20443&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20443&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20443&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20443&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20443&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20443&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20443&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20443&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20443&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20443&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20443&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20443&r=isapi
#19207 [Ver->Ctl]: php-cgi.exe does not correctly set HTTP status
ID: 19207
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Verified
+Status: Critical
Bug Type: IIS related
Operating System: Windows 2000/.Net Server RC1
PHP Version: 4CVS-2002-08-30
New Comment:
Marking this critical (fix before 4.3.0 final).
See the related discussion
http://www.phpbuilder.com/mail/php-developer-list/2002092/0238.php
Previous Comments:
[2002-09-24 13:03:38] [EMAIL PROTECTED]
I'm currently using IIS 6.0 in Windows.Net Server RC1 (build 3663).
Again, CGI PHP 4.2.2/4.2.3 works fine just not CGI PHP 4.3.0.
[2002-09-24 11:48:11] [EMAIL PROTECTED]
what version of IIS are you using.. this works fine on Win XP Pro (No
service pack) so IIS 5.0.
- James
--
James Moore
[EMAIL PROTECTED]
[2002-09-05 11:22:02] [EMAIL PROTECTED]
Just tried the latest snapshot php4-win32-200209051400.zip and the
issue still exists. php-cgi.exe returns the following headers:
Status: 401
Content-type: text/html
WWW-authenticate: basic realm=Logon
The correct headers for php-cgi.exe to work in IIS should be:
HTTP/1.1 401 Unauthorized
Content-type: text/html
WWW-authenticate: basic realm=Logon
[2002-09-04 21:30:20] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
I believe there was just a patch submitted that fixes this. I could be
wrong though too, please test and update if still valid. :\
[2002-08-30 20:09:13] [EMAIL PROTECTED]
The following code fragment works great with PHP 4.2.2 on IIS:
Header("WWW-authenticate: basic realm=Logon");
Header("HTTP/1.1 401 Unauthorized");
echo "\n";
echo " \n";
echo " Authorization Required\n";
echo " \n";
echo " \n";
echo " Invalid username and password with which to access this
webpage.\n";
echo " \n";
echo "\n";
exit;
This code works correctly in 4.2.2. It sets the status of the page to
401 and makes the browser prompt for the password.
However using php-cgi.exe in the latest 4.3.0 development builds in IIS
the code does not work. The browser receive a "HTTP/1.1 200 OK"
instead of "HTTP/1.1 401 Unauthorized". If I simply run the CGI script
from the command prompt using php-cgi.exe in 4.3.0 I get the
following:
Status: 401
Content-type: text/html
WWW-authenticate: basic realm=Logon
Authorization Required
Invalid username and password with which to access this
webpage.
Running php.exe 4.2.2 from the console I get the following:
HTTP/1.1 401 Unauthorized
Content-type: text/html
WWW-authenticate: basic realm=Logon
Authorization Required
Invalid username and password with which to access this
webpage.
Noticed that php 4.2.2 correctly returns the HTTP page status as
"HTTP/1.1 401 Unauthorized" and php 4.3.0 only returns the tag "Status:
401".
The new tag "Status: 401" does not work in IIS, it needs to be the full
"HTTP/1.1 401 Unauthorized".
--
Edit this bug report at http://bugs.php.net/?id=19207&edit=1
#20442 [NEW]: xml_get_current_line_number produces segmentation fault
From: [EMAIL PROTECTED]
Operating system: NetBSD 1.6
PHP version: 4CVS-2002-11-15
PHP Bug Type: XML related
Bug description: xml_get_current_line_number produces segmentation fault
It looks like the xml_get_current_line_number of xml produces a
segmentation fault.
Here is the piece of code :
function parse($file)
{
if(!($fp = fopen($file, 'r')))
echo "xml_parser error: Could not open $file.\n";
else
while($data = fgets($fp, 4096))
if(!xml_parse($this->parser, $data,
feof($fp)))
echo 'xml_parser error: ',
xml_error_string(xml_get_error_code($this->parser)),
' at line ',
xml_get_current_line_number($this->parser),
"\n";
fclose($fp);
return $this->struct;
}
If the data.xml looks like this for example :
Bla
Muh
I runned the xml example file in shell and here is the output :
Example
Test
Test
xml_parser error: mismatched tag at line 4
xml_parser error: mismatched tag at line Segmentation fault (core dumped)
Now where is the problem ?
Does the XML parser try to get the line and is already at the end of the
file ?
--
Edit bug report at http://bugs.php.net/?id=20442&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20442&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20442&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20442&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20442&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20442&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20442&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20442&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20442&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20442&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20442&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20442&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20442&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20442&r=isapi
#20441 [Bgs->Opn]: PHP_AUTH_USER isn't set
ID: 20441
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: Apache related
Operating System: Redhat Linux 7.1 kernel 2.4.2-2
PHP Version: 4.3.0-pre2
New Comment:
So I should use $_SERVER["REMOTE_USER"] if I use .htaccess and
$_SERVER["PHP_AUTH_USER"] when I header the authentication?
Why is this behaviour changed without notice?
Previous Comments:
[2002-11-15 03:10:35] [EMAIL PROTECTED]
You need to decide if you are using an external auth mechanism or http
auth from php. You can't do both.
[2002-11-15 02:58:24] [EMAIL PROTECTED]
I've upgraded PHP 4.2.3 to the beta 4.3.0-pre2 and I've set register
globals on in php.ini.
My Apache version is 1.3.24.
PHP configure:
./configure --with-apxs=/usr/local/apache/bin/apxs
--with-mysql=/usr/local/mysql --enable-ftp --with-openssl
The script is using this .htaccess-file
AuthType Basic
AuthName 'Urenregistratie'
AuthUserFile /htpasswd/urenreg
require valid-user
I am sure that Apache is setting the PHP_AUTH_USER because the
following script gives the correct output:
// begin dirty hack
$headers = apache_request_headers();
foreach ($headers as $header => $value) {
if ($header == "Authorization")
{
$value = str_replace(" ", "", $value);
$value = str_replace("Basic", "", $value);
$userArray = explode(":", base64_decode($value));
$PHP_AUTH_USER = $userArray[0];
}
}
echo $PHP_AUTH_USER;
// end dirty hack
If I echo $PHP_AUTH_USER or $_SERVER["PHP_AUTH_USER"] above this script
I am getting a empty result.
Note: the script was functioning 100% properly with php 4.2.3
--
Edit this bug report at http://bugs.php.net/?id=20441&edit=1
#20441 [Opn->Bgs]: PHP_AUTH_USER isn't set
ID: 20441
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Apache related
Operating System: Redhat Linux 7.1 kernel 2.4.2-2
PHP Version: 4.3.0-pre2
New Comment:
You need to decide if you are using an external auth mechanism or http
auth from php. You can't do both.
Previous Comments:
[2002-11-15 02:58:24] [EMAIL PROTECTED]
I've upgraded PHP 4.2.3 to the beta 4.3.0-pre2 and I've set register
globals on in php.ini.
My Apache version is 1.3.24.
PHP configure:
./configure --with-apxs=/usr/local/apache/bin/apxs
--with-mysql=/usr/local/mysql --enable-ftp --with-openssl
The script is using this .htaccess-file
AuthType Basic
AuthName 'Urenregistratie'
AuthUserFile /htpasswd/urenreg
require valid-user
I am sure that Apache is setting the PHP_AUTH_USER because the
following script gives the correct output:
// begin dirty hack
$headers = apache_request_headers();
foreach ($headers as $header => $value) {
if ($header == "Authorization")
{
$value = str_replace(" ", "", $value);
$value = str_replace("Basic", "", $value);
$userArray = explode(":", base64_decode($value));
$PHP_AUTH_USER = $userArray[0];
}
}
echo $PHP_AUTH_USER;
// end dirty hack
If I echo $PHP_AUTH_USER or $_SERVER["PHP_AUTH_USER"] above this script
I am getting a empty result.
Note: the script was functioning 100% properly with php 4.2.3
--
Edit this bug report at http://bugs.php.net/?id=20441&edit=1
#20441 [NEW]: PHP_AUTH_USER isn't set
From: [EMAIL PROTECTED]
Operating system: Redhat Linux 7.1 kernel 2.4.2-2
PHP version: 4.3.0-pre2
PHP Bug Type: Apache related
Bug description: PHP_AUTH_USER isn't set
I've upgraded PHP 4.2.3 to the beta 4.3.0-pre2 and I've set register
globals on in php.ini.
My Apache version is 1.3.24.
PHP configure:
./configure --with-apxs=/usr/local/apache/bin/apxs
--with-mysql=/usr/local/mysql --enable-ftp --with-openssl
The script is using this .htaccess-file
AuthType Basic
AuthName 'Urenregistratie'
AuthUserFile /htpasswd/urenreg
require valid-user
I am sure that Apache is setting the PHP_AUTH_USER because the following
script gives the correct output:
// begin dirty hack
$headers = apache_request_headers();
foreach ($headers as $header => $value) {
if ($header == "Authorization")
{
$value = str_replace(" ", "", $value);
$value = str_replace("Basic", "", $value);
$userArray = explode(":", base64_decode($value));
$PHP_AUTH_USER = $userArray[0];
}
}
echo $PHP_AUTH_USER;
// end dirty hack
If I echo $PHP_AUTH_USER or $_SERVER["PHP_AUTH_USER"] above this script I
am getting a empty result.
Note: the script was functioning 100% properly with php 4.2.3
--
Edit bug report at http://bugs.php.net/?id=20441&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20441&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20441&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20441&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20441&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20441&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20441&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20441&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20441&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20441&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20441&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20441&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20441&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20441&r=isapi
#19775 [Com]: PHP crashes when trying to access 2d int matrix returned from java
ID: 19775
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Java related
Operating System: Windows XP Pro
PHP Version: 4.2.3
New Comment:
I determined that for some reason, these latest builds don't like to
run from folders that have names that include spaces.
I created a virtual directory on WinXP point to a directory with no
spaces to get around this on issue.
After I resolved that problem, php was able to open the file but this
is the error I received using the latest build time stamped 14-Nov-2002
23:29
---
CGI Error
The specified CGI application misbehaved by not returning a complete
set of HTTP headers. The headers it did return are:
imageMatrix[0][0]=20
imageMatrix[1][1]=22
2
9
21
-
I also received a windows error that says "PHP Script Interpreter has
encountered a problem".
I have created a stripped down version of the script I am using to test
this bug. This script responds the same way as my original php script
for version 4.2.3 (note that I did not post the entire original script
just the portion that called the Java class).
Here is the stripped down script to test the bug:
\n";
print "imageMatrix[1][1]=" . $imageMatrix[1][1] . "\n";
// Apply filter to image
$FilterObject = new Java("Filter");
$newImageMatrix = $FilterObject->applyFilter($filter, $filterDimension,
$imageMatrix, $imageSizeX, $imageSizeY);
$tempVal = $newImageMatrix[0][0];
print $tempVal . "\n";
$tempVal = $newImageMatrix[1][1];
print $tempVal . "\n";
$tempVal = $newImageMatrix[2][2];
print $tempVal . "\n";
?>
Previous Comments:
[2002-11-12 06:12:56] [EMAIL PROTECTED]
Error "Could not open input file." sounds like PHP does either not find
the file or doesn't have permission to access it..
[2002-11-12 00:14:49] [EMAIL PROTECTED]
Yes. I tried exactly the one at the url you posted not the STABLE one.
That error did strike me as a configuration error, but I did not change
any of my IIS settings so I'm not sure why that configuration error
would occur.
[2002-11-11 18:21:45] [EMAIL PROTECTED]
So did you try exactly that one found in the url?
and NOT the one with 'STABLE' in it's name?
That error seems more like a configuration error on your machine..
[2002-11-11 16:54:16] [EMAIL PROTECTED]
I'm not sure why the same comment was posted twice.
But anyways, I tried using the CVS snapshot for windows and this is the
error I get:
CGI Error
The specified CGI application misbehaved by not returning a complete
set of HTTP headers. The headers it did return are:
Could not open input file.
I can reproduce this bug 100% of the time if you would like the
complete php script with some comments, I can provide that, just let me
know.
[2002-11-11 10:10:49] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/19775
--
Edit this bug report at http://bugs.php.net/?id=19775&edit=1
#20356 [Opn->Bgs]: Wrong header, output broken
ID: 20356 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: linux PHP Version: 4CVS-2002-11-11 New Comment: As explained on the apache-users list, this cannot be a PHP bug. Previous Comments: [2002-11-15 01:46:00] [EMAIL PROTECTED] So now i've setup a 'test-suite'... HTTP-Version: http://xmail.linux-de.org/test/ HTTPS-Version: https://mail.linux-de.org/test/ There are php.html, perl.html and ruby.html... all cgi-scripts printing the ENV-Vars in a frameset. PHP will fail nearly every time in one frame at minimum, the others (perl and ruby) work nearly every time correct (it's absolutely acceptable). So now tell me, is it an PHP-Problem or Apache2? (I myself think again it's php). [2002-11-13 08:53:18] [EMAIL PROTECTED] I've to excuse. Recently i got the same problem with one of my ruby-scripts, i'm sorry for the rebukes. Best regards, simon [2002-11-13 08:02:06] [EMAIL PROTECTED] I've posted it to the apache-mailinglist... i need a solution, so i've to ask around :) If i've new informations, i'll post'em here. [2002-11-11 12:20:42] [EMAIL PROTECTED] Which one? PHP or another one? Ther error occours even if i let the script print "hello world". It's really boring... i only want to run php in a safe way... and because the perchild-mpm for apache2 isn't working yet, i have to use suexec, so every script runs with the right permission, that's the only reason why i'm using the cgi-version of php. If there's another safe way, i'll take a look at it. [2002-11-11 11:13:45] [EMAIL PROTECTED] Your CGI script does not send the HTTP/1.1 200 OK response, the web server does. No matter what the CGI script returns, the server cannot legally send anything before that header. If it does then the server is broken by definition. There is just no arguing that point. But what exactly does your cgi script generate when you run it from the command line? 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/20356 -- Edit this bug report at http://bugs.php.net/?id=20356&edit=1
#20440 [Opn->Bgs]: wrong output for simple calculation
ID: 20440 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: linux PHP Version: 4.2.3 New Comment: Read the part about Floating Point precision in our manual: http://www.php.net/manual/en/printwn/language.types.float.php Derick Previous Comments: [2002-11-15 02:18:31] [EMAIL PROTECTED] Try: outputs: 0.830001 should be just: 0.83 Gr, Wico -- Edit this bug report at http://bugs.php.net/?id=20440&edit=1
#20440 [NEW]: wrong output for simple calculation
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.2.3 PHP Bug Type: Scripting Engine problem Bug description: wrong output for simple calculation Try: outputs: 0.830001 should be just: 0.83 Gr, Wico -- Edit bug report at http://bugs.php.net/?id=20440&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20440&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20440&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20440&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20440&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20440&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20440&r=support Expected behavior: http://bugs.php.net/fix.php?id=20440&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20440&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20440&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20440&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20440&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20440&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20440&r=isapi
