Bug #17507 Updated: LDAP module fails to load
ID: 17507 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: LDAP related Operating System: Windows 2000 Advanced Server PHP Version: 4.2.1 New Comment: Aw well, my bad. Apparently there was an old php4ts.dll lying around in my $PATH - *that* was the older one, and not the ldap one. Sorry. :( Previous Comments: [2002-05-29 13:14:54] [EMAIL PROTECTED] The DLL included in the 4.2.1 win32 distribution definitely works. You have an old dll lying around somewhere which is loaded instead. [2002-05-29 13:14:54] [EMAIL PROTECTED] The DLL included in the 4.2.1 win32 distribution definitely works. You have an old dll lying around somewhere which is loaded instead. [2002-05-29 13:05:37] [EMAIL PROTECTED] Sorry, but the bug system is not the appropriate forum for asking support questions. 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 Thank you for your interest in PHP. You PHP is looking for older DLL most likely. [2002-05-29 11:23:35] [EMAIL PROTECTED] Scenario: Default PHP 4.2.1 installation on win2k / apache (as a service, PHP installed as dynamically linked module). php-ini-recommended used with one change: the extensions_dir points to c:/php/extensions/ On enabling the php_ldap.dll extension (removed ';' ) and then restarting the apache service, I get this popup: -- START -- Warning: ldap: Unable to initialize module Module compiled with module API=20020429, debug=0,thread-safety=1 PHP compiled with module API=20010901,debug=0,thread-safety=1 These options need to match -- END -- Can make an educated guess about the nature of the problem, cannot suggest a real fix. Thanks in advance for your time. -- Edit this bug report at http://bugs.php.net/?id=17507&edit=1
Bug #16098 Updated: Output line too long
ID: 16098 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.0CVS-2002-03-15 New Comment: OOPS, I meant: # mv /bin/sed /bin/broken_sed Although you might as well get rid of that broken sed Previous Comments: [2002-05-30 02:05:50] [EMAIL PROTECTED] Problem is that Solaris 8 sed is badly broken (tnxs to Rasmus's comment on #php). Just do: # rm /bin/sed /bin/broken_sed # cp /opt/sfw/bin/gsed /bin/sed Assuming you had installed the extra Gnu CD from the Solaris 8 set. That should do it. [2002-05-23 21:02:56] [EMAIL PROTECTED] I have tried the latest CVS (freshly updated at 2002-05-23, 17:50pm PST) in Solaris 2.8, using csh, tcsh, bash (2.03) and in all I also got the same problem. % uname -a SunOS redox 5.8 Generic_108528-07 sun4u sparc SUNW,Sun-Blade-100 % gcc --version 3.0.2 % make --version GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for sparc-sun-solaris2.8 Copyright (C) [... etc ...] Also, I used the configuration: ./configure --prefix=/export/dredox1/devel_server/php \ --with-config-file-path=/export/dredox1/devel_server/php \ --enable-track-vars --enable-magic-quotes \ --enable-inline-optimization \ --enable-xml \ --enable-pcntl \ --enable-cli \ --enable-aggregate \ --enable-overload \ --enable-wddx \ --enable-ftp --enable-calendar --enable-bcmath --enable-trans-id\ --with-zlib \ --with-gd=/asd/metallo1/server/libs/gd-1.8.4 \ --enable-freetype-4bit-antialias-hack \ --with-jpeg-dir=/opt/sfw \ --with-png-dir=/opt/sfw \ --with-xpm-dir=/opt/sfw \ --with-ttf=/opt/sfw \ --with-t1lib=/asd/metallo1/server/libs/t1 \ --with-xmlrpc \ --with-mysql=/export/dredox1/devel_server/mysql and the make lines where the problem happens are at the end (they are HUGE). I even tried "/bin/bash libtool ..." w/o success Here are the lines: /bin/sh libtool --mode=link gcc -export-dynamic -DPHP_ATOM_INC -I/home/jesusmc/devel/php/php4/include -I/home/jesusmc/devel/php/php4/main -I/home/jesusmc/devel/php/php4 -I/home/jesusmc/devel/php/php4/Zend -I/opt/sfw/include/freetype -I/asd/metallo1/server/libs/t1/include -I/asd/metallo1/server/libs/gd-1.8.4/include -I/export/dredox1/devel_server/mysql/include/mysql -I/home/jesusmc/devel/php/php4/ext/xml/expat -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -I/home/jesusmc/devel/php/php4/TSRM -g -O2 -L/usr/ucblib -L/opt/sfw/lib -L/asd/metallo1/server/libs/t1/lib -L/asd/metallo1/server/libs/gd-1.8.4/lib -L/export/dredox1/devel_server/mysql/lib/mysql -L/usr/local/lib -R /usr/ucblib -R /opt/sfw/lib -R /asd/metallo1/server/libs/t1/lib -R /asd/metallo1/server/libs/gd-1.8.4/lib -R /export/dredox1/devel_server/mysql/lib/mysql -R /usr/local/lib ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/bcmath/bcmath.lo ext/bcmath/number.lo ext/bcmath/libbcmath/src/add.lo ext/bcmath/libbcmath/src/div.lo ext/bcmath/libbcmath/src/init.lo ext/bcmath/libbcmath/src/neg.lo ext/bcmath/libbcmath/src/outofmem.lo ext/bcmath/libbcmath/src/raisemod.lo ext/bcmath/libbcmath/src/rt.lo ext/bcmath/libbcmath/src/sub.lo ext/bcmath/libbcmath/src/compare.lo ext/bcmath/libbcmath/src/divmod.lo ext/bcmath/libbcmath/src/int2num.lo ext/bcmath/libbcmath/src/num2long.lo ext/bcmath/libbcmath/src/output.lo ext/bcmath/libbcmath/src/recmul.lo ext/bcmath/libbcmath/src/sqrt.lo ext/bcmath/libbcmath/src/zero.lo ext/bcmath/libbcmath/src/debug.lo ext/bcmath/libbcmath/src/doaddsub.lo ext/bcmath/libbcmath/src/nearzero.lo ext/bcmath/libbcmath/src/num2str.lo ext/bcmath/libbcmath/src/raise.lo ext/bcmath/libbcmath/src/rmzero.lo ext/bcmath/libbcmath/src/str2num.lo ext/calendar/calendar.lo ext/calendar/dow.lo ext/calendar/french.lo ext/calendar/gregor.lo ext/calendar/jewish.lo ext/calendar/julian.lo ext/calendar/easter.lo ext/calendar/cal_unix.lo ext/ctype/ctype.lo ext/ftp/php_ftp.lo ext/ftp/ftp.lo ext/gd/gd.lo ext/gd/gdcache.lo ext/gd/gdttf.lo ext/gd/gdt1.lo ext/mbstring/mbfilter_ja.lo ext/mbstring/mbfilter_cn.lo ext/mbstring/mbfilter_tw.lo ext/mbstring/mbfilter_kr.lo ext/mbstring/mbfilter_ru.lo ext/mbstring/mbfilter.lo ext/mbstring/mbstring.lo ext/mbstring/mbregex.lo ext/mbstring/php_mbregex.lo ext/mysql/php_mysql.lo ext/overload/overload.lo ext/pcntl/pcntl.lo ext/pcntl/php_signal.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext
Bug #16098 Updated: Output line too long
ID: 16098 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.0CVS-2002-03-15 New Comment: Problem is that Solaris 8 sed is badly broken (tnxs to Rasmus's comment on #php). Just do: # rm /bin/sed /bin/broken_sed # cp /opt/sfw/bin/gsed /bin/sed Assuming you had installed the extra Gnu CD from the Solaris 8 set. That should do it. Previous Comments: [2002-05-23 21:02:56] [EMAIL PROTECTED] I have tried the latest CVS (freshly updated at 2002-05-23, 17:50pm PST) in Solaris 2.8, using csh, tcsh, bash (2.03) and in all I also got the same problem. % uname -a SunOS redox 5.8 Generic_108528-07 sun4u sparc SUNW,Sun-Blade-100 % gcc --version 3.0.2 % make --version GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for sparc-sun-solaris2.8 Copyright (C) [... etc ...] Also, I used the configuration: ./configure --prefix=/export/dredox1/devel_server/php \ --with-config-file-path=/export/dredox1/devel_server/php \ --enable-track-vars --enable-magic-quotes \ --enable-inline-optimization \ --enable-xml \ --enable-pcntl \ --enable-cli \ --enable-aggregate \ --enable-overload \ --enable-wddx \ --enable-ftp --enable-calendar --enable-bcmath --enable-trans-id\ --with-zlib \ --with-gd=/asd/metallo1/server/libs/gd-1.8.4 \ --enable-freetype-4bit-antialias-hack \ --with-jpeg-dir=/opt/sfw \ --with-png-dir=/opt/sfw \ --with-xpm-dir=/opt/sfw \ --with-ttf=/opt/sfw \ --with-t1lib=/asd/metallo1/server/libs/t1 \ --with-xmlrpc \ --with-mysql=/export/dredox1/devel_server/mysql and the make lines where the problem happens are at the end (they are HUGE). I even tried "/bin/bash libtool ..." w/o success Here are the lines: /bin/sh libtool --mode=link gcc -export-dynamic -DPHP_ATOM_INC -I/home/jesusmc/devel/php/php4/include -I/home/jesusmc/devel/php/php4/main -I/home/jesusmc/devel/php/php4 -I/home/jesusmc/devel/php/php4/Zend -I/opt/sfw/include/freetype -I/asd/metallo1/server/libs/t1/include -I/asd/metallo1/server/libs/gd-1.8.4/include -I/export/dredox1/devel_server/mysql/include/mysql -I/home/jesusmc/devel/php/php4/ext/xml/expat -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -I/home/jesusmc/devel/php/php4/TSRM -g -O2 -L/usr/ucblib -L/opt/sfw/lib -L/asd/metallo1/server/libs/t1/lib -L/asd/metallo1/server/libs/gd-1.8.4/lib -L/export/dredox1/devel_server/mysql/lib/mysql -L/usr/local/lib -R /usr/ucblib -R /opt/sfw/lib -R /asd/metallo1/server/libs/t1/lib -R /asd/metallo1/server/libs/gd-1.8.4/lib -R /export/dredox1/devel_server/mysql/lib/mysql -R /usr/local/lib ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/bcmath/bcmath.lo ext/bcmath/number.lo ext/bcmath/libbcmath/src/add.lo ext/bcmath/libbcmath/src/div.lo ext/bcmath/libbcmath/src/init.lo ext/bcmath/libbcmath/src/neg.lo ext/bcmath/libbcmath/src/outofmem.lo ext/bcmath/libbcmath/src/raisemod.lo ext/bcmath/libbcmath/src/rt.lo ext/bcmath/libbcmath/src/sub.lo ext/bcmath/libbcmath/src/compare.lo ext/bcmath/libbcmath/src/divmod.lo ext/bcmath/libbcmath/src/int2num.lo ext/bcmath/libbcmath/src/num2long.lo ext/bcmath/libbcmath/src/output.lo ext/bcmath/libbcmath/src/recmul.lo ext/bcmath/libbcmath/src/sqrt.lo ext/bcmath/libbcmath/src/zero.lo ext/bcmath/libbcmath/src/debug.lo ext/bcmath/libbcmath/src/doaddsub.lo ext/bcmath/libbcmath/src/nearzero.lo ext/bcmath/libbcmath/src/num2str.lo ext/bcmath/libbcmath/src/raise.lo ext/bcmath/libbcmath/src/rmzero.lo ext/bcmath/libbcmath/src/str2num.lo ext/calendar/calendar.lo ext/calendar/dow.lo ext/calendar/french.lo ext/calendar/gregor.lo ext/calendar/jewish.lo ext/calendar/julian.lo ext/calendar/easter.lo ext/calendar/cal_unix.lo ext/ctype/ctype.lo ext/ftp/php_ftp.lo ext/ftp/ftp.lo ext/gd/gd.lo ext/gd/gdcache.lo ext/gd/gdttf.lo ext/gd/gdt1.lo ext/mbstring/mbfilter_ja.lo ext/mbstring/mbfilter_cn.lo ext/mbstring/mbfilter_tw.lo ext/mbstring/mbfilter_kr.lo ext/mbstring/mbfilter_ru.lo ext/mbstring/mbfilter.lo ext/mbstring/mbstring.lo ext/mbstring/mbregex.lo ext/mbstring/php_mbregex.lo ext/mysql/php_mysql.lo ext/overload/overload.lo ext/pcntl/pcntl.lo ext/pcntl/php_signal.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/stand
Bug #17475 Updated: results of Virtual() is misplaced
ID: 17475 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Apache2 related Operating System: WinXP PHP Version: 4.2.1 New Comment: The problem has been solved by replacing the php.ini with a new fresh one. Previous Comments: [2002-05-28 12:15:30] [EMAIL PROTECTED] Both servers use the same setting since they are both on the same computer. All settings are default. Of course, one uses php4apache2.dll and the other uses php4apache.dll. I don't understand any strange behaviour. [2002-05-28 11:28:07] [EMAIL PROTECTED] You don't happen to have different ob_* settings for both servers? IIRC, virtual() doesn't wrap through the output buffering system. [2002-05-28 05:17:25] [EMAIL PROTECTED] This problem can be explained really simple with a script. And I am sure it's a problem with Apache2 because this problem doesn't arise in Apache. (Note: the content of ip.cgi and ip.html is simply IP.CGI and IP.HTML respectively.) The Code: 1. 2. Output (Apache2): IP.NETIP.HTML 1. 2. Output (Apache): 1. IP.NET2. IP.HTML In conclusion, the content prased by virtual() is misplaced. -- Edit this bug report at http://bugs.php.net/?id=17475&edit=1
Bug #17518: split function
From: [EMAIL PROTECTED] Operating system: Windows PHP version: 4.0CVS-2002-05-30 PHP Bug Type: Feature/Change Request Bug description: split function Don't you think that the split function should work if invoked as follows: print( split( "-", "2001-09-21" )[0] ); The function returns an array, so why shouldn't we be able to directly access the array indexes without having to assign the array to a variable then outputting the value? -- Edit bug report at http://bugs.php.net/?id=17518&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17518&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17518&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17518&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17518&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17518&r=support Expected behavior: http://bugs.php.net/fix.php?id=17518&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17518&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17518&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17518&r=globals
Bug #16904 Updated: output-error im multi-dimensional arrays
ID: 16904 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Arrays related Operating System: Suse Linux PHP Version: 4.1.2 New Comment: 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". Previous Comments: [2002-04-29 16:13:56] [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". [2002-04-29 10:32:27] [EMAIL PROTECTED] It works fine with complete numeric multi-dimensional arrays! [2002-04-29 10:23:27] [EMAIL PROTECTED] There is a problem with a multi-dimensional array coming from a web-formular. in my case, i have a 2 dimensional array, first dimension numeric, the second associative. when i pick up the second dimension by foreach($array as $key => $info), i cant output the elements by eg echo $info['name']. with print_r($info) I get the right information about the array, but its impossible to get an output of the elements with echo or print! -- Edit this bug report at http://bugs.php.net/?id=16904&edit=1
Bug #16898 Updated: type convertation problem in pow()
ID: 16898
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: No Feedback
Bug Type: *Math Functions
Operating System: Linux
PHP Version: 4.2.0
New Comment:
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".
Previous Comments:
[2002-05-06 22:20:34] [EMAIL PROTECTED]
This is a duplicate of 16944 which has been fixed.
[2002-05-06 22:18:14] [EMAIL PROTECTED]
Further to my last post, here is the code in question:
function NUM_HOLDS($level_hull)
{
global $level_factor;
return round(pow($level_factor, $level_hull) * 100);
}
as stated in the previous post, $level_factor = 2 and $level_hull = 0;
It also occurs on this line:
$shipspeed = pow($level_factor, $playerinfo[engines]);
Could it be because in my case, I am using an associative array as the
second value?
[2002-05-06 22:12:18] [EMAIL PROTECTED]
I have the same problem, but on windows xp.
The values are being selected back from mysql via ADODB. The values
being used (in variables) are 2 and 0 eg pow($value1,$value2) where
value1 = 2 and value2 = 0
[2002-04-29 06:28:21] [EMAIL PROTECTED]
PHP automagically tries to convert the passed data to a number
representation.
Please paste the exact values you are using to call this pow()
[2002-04-29 06:17:23] [EMAIL PROTECTED]
$result=mysql_query("SELECT id, cdate FROM newspaper WHERE
path='".substr($a, strrpos($a, "/")+1, strlen($a))."'") or die
(mysql_error());
$rec=mysql_fetch_array($result);
$e=pow(2, $rec[id]); //Warning!
it's looks like what pow() function can't convert $rec[id] variable
from string to integer automatically.
Using
$rec[id]=stettype($rec[id], "int");
helps
--
Edit this bug report at http://bugs.php.net/?id=16898&edit=1
Bug #15909 Updated: mysql and header() problem prevent saving session vars(?)
ID: 15909 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Session related Operating System: Linux (Debian) PHP Version: 4.1.1 New Comment: 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". Previous Comments: [2002-04-29 15:23:06] [EMAIL PROTECTED] Does this happen with latest CVS (stable branch) snapshot ? http://snaps.php.net/php4-STABLE-latest.tar.gz --Jani [2002-04-29 12:21:48] [EMAIL PROTECTED] MySQL is not the problem. We have not changed MySQL versions, just the PHP version. Some of the cases that fail do not do any database operations. They change a context variable and page jump (via header()) to another PHP page. If this were a MySQL problem, the work around I described above would not fix it. The problem appears to be with PHP and the management of session variables. Note: Status should be changed to Open but the only options I have are No Feedback or Closed. [2002-04-29 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-03-28 19:12:11] [EMAIL PROTECTED] There is bug report for MySQL. After serval database operation, calling heade() crashes PHP for some reason according to the bug report. Anyway, I don't use MySQL and I don't have this problem. We need backtrace or need where/how PHP is bailing out. Build with --enable-debug and check what is going to with debugger. [2002-03-27 12:02:40] [EMAIL PROTECTED] Sorry, I don't see where I would limit size of max text size returned from MySQL or what you are looking for. Please clarify. The applications that are not working are not using large text fields. Most are defined as TINYTEXT and TEXT. There are a couole of columns defined as MEDIUMTEXT (due to misunderstanding of field types) but the contents are less than 4000 bytes. 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/15909 -- Edit this bug report at http://bugs.php.net/?id=15909&edit=1
Bug #15873 Updated: special build error with apache using php module after system-compoment changed
ID: 15873 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Apache related Operating System: rh linux 7.2 PHP Version: 4.1.2 New Comment: 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". Previous Comments: [2002-04-22 23:43:09] [EMAIL PROTECTED] if u r using php as apache-module you should always re-run apache "configure" after php "make install" .. php# make install .. php# cd ..\apache .. apache# ./configure --with yor options .. apache# make .. apache# make install does this ok for u ? [2002-04-22 18:40:05] [EMAIL PROTECTED] I am experiencing the same problem. I have built freetype, libpng and gd myself, if theres a problem linking to the wrong gd (which there does not appear to be) it would be a php bug, as the path to gd was explicitly stated. gcc -DLINUX=22 -I/root/php-4.1.2 -I/root/php-4.1.2/main -I/root/php-4.1.2/main -I/root/php-4.1.2/Zend -I/root/php-4.1.2/Zend -I/root/php-4.1.2/TSRM -I/root/php-4.1.2/TSRM -I/root/php-4.1.2 -DNO_DL_NEEDED `./apaci`\ -o httpd buildmark.o modules.o modules/standard/libstandard.a modules/php4/libphp4.a main/libmain.a ./os/unix/libos.a ap/libap.a -Wl,-rpath,/usr/local/freetype-1.3.1//lib -Wl,-rpath,/usr/local/gd-1.8.4//lib -Wl,-rpath,/opt/sybase-11.9.2//lib -rdynamic -L/usr/local/freetype-1.3.1//lib -L/usr/local/gd-1.8.4//lib -L/opt/sybase-11.9.2//lib -Lmodules/php4 -L../modules/php4 -L../../modules/php4 -lmodphp4 -lpam -ldl -linsck -lsybtcl -lintl -lcomn -lct -lcs -lsnmp -lgd -lttf -lcrypt -lssl -lcrypto -lresolv -lm -ldl -lnsl -lresolv -lcrypt -lssl -lcrypto -lm -lcrypt -lexpat modules/php4/libphp4.a(gd.o): In function `zif_imagecreatefromstring': /root/php-4.1.2/ext/gd/gd.c:1043: undefined reference to `gdImageCreateFromJpegCtx' modules/php4/libphp4.a(gd.o): In function `zif_imagecreatefromjpeg': /root/php-4.1.2/ext/gd/gd.c:1216: undefined reference to `gdImageCreateFromJpegCtx' /root/php-4.1.2/ext/gd/gd.c:1216: undefined reference to `gdImageCreateFromJpeg' modules/php4/libphp4.a(gd.o): In function `zif_imagejpeg': [2002-03-06 13:16:32] [EMAIL PROTECTED] well, i did have uninstalled gd-1.4.8 (i didn't notice the version before), by "rpm -e gd-1.4.8" but the version i reinstall is also gd-1.4.8 source and compile/install to /usr/local/ (rpm version should be /usr/) i've done "rm -f config.cache" dunno why "configure" still think that nothing changed so can't link with gd and give out "undefined reference" error [2002-03-06 06:12:55] [EMAIL PROTECTED] This might be caused by multiple versions of GD being installed. Check if the old version is really gone and try again :) [2002-03-05 08:30:31] [EMAIL PROTECTED] what i did: step1: redhat7.2 with gd/jpeg/... support build php as apache module ok, works step2: uninstall some of the redhat rpm download gd/jpeg and build it reconfig php; make clean; make; make install; all passed; step3: now reconfig apache, rebuild apache failed! undefined reference to gdImageCreate gdImage and so on... i've tried so many times, still get such error. and by change, i did the following command in apache src-package directory: [apache]# rm src/modules/php4/libphp4.module and: [php]# make install [apache]# make all pass! it works. in a word, libphp4.module was not reinstalled correctly! -- Edit this bug report at http://bugs.php.net/?id=15873&edit=1
Bug #17312 Updated: Build problem with GCC 3.1
ID: 17312 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MySQL related Operating System: Redhat 7.2 PHP Version: 4.2.1 New Comment: Is this something that could be caught when ./configure is run? My concern is that ./configure checks for tempnam successfully eventhough it will not link. However, since this seems to be the behavior of AC_CHECK_FUNCS there might not be anything to do. Previous Comments: [2002-05-22 15:41:14] [EMAIL PROTECTED] Even better this one http://gcc.gnu.org/ml/gcc/2002-02/msg01071.html (one of the Follow-Ups) [2002-05-22 15:39:57] [EMAIL PROTECTED] I've found this line through google: http://gcc.gnu.org/ml/gcc/2002-02/msg00965.html [2002-05-22 15:32:59] [EMAIL PROTECTED] To me it looks like the linker has trouble with it somehow. Compiles OK, but fails in linking with the 'unhandled FORM value: 14' error. Again, it looks as if the routines in my_tempnam.c are not referenced anywhere in the extension, so to me it looks as if it would be safe to remove the source file. [2002-05-22 15:19:20] [EMAIL PROTECTED] Does this mean by chance the gcc 3.1 treats this as an error what used to be a warning only in 2.9x ? [2002-05-22 12:31:04] [EMAIL PROTECTED] It seems that the functions in my_tempnam.c are not used. If I removed my_tempnam.c from ext/mysql/config.m4 php builds and seems to run correctly. config.m4 53c53 < libmysql/my_delete.c libmysql/my_tempnam.c libmysql/my_open.c libmysql/mf_casecnv.c libmysql/my_read.c \ --- > libmysql/my_delete.c libmysql/my_open.c libmysql/mf_casecnv.c libmysql/my_read.c \ 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/17312 -- Edit this bug report at http://bugs.php.net/?id=17312&edit=1
Bug #17483 Updated: looks like a giant ant
ID: 17483 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Bogus Bug Type:Date/time related PHP Version: 4.1.2 Previous Comments: [2002-05-28 10:26:55] [EMAIL PROTECTED] Come on .. what is it ? :) [2002-05-28 10:26:13] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php ;) [2002-05-28 10:23:56] [EMAIL PROTECTED] looks like a giant ant. has red and black stripes. and it also has fur. and is about 3 inches long -- Edit this bug report at http://bugs.php.net/?id=17483&edit=1
Bug #17517: ucwords() returns false when it should return ''
From: [EMAIL PROTECTED]
Operating system: Linux and NT4
PHP version: 4.1.2
PHP Bug Type: Strings related
Bug description: ucwords() returns false when it should return ''
ucwords('') returns a type of boolean but it should return ''. This script
demonstrates the problem:
To get around it I do this after the ucwords() call:
if(!$s2)$s2='';
--
Edit bug report at http://bugs.php.net/?id=17517&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17517&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17517&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17517&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17517&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17517&r=support
Expected behavior: http://bugs.php.net/fix.php?id=17517&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17517&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17517&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17517&r=globals
Bug #15665 Updated: readdir() crashes
ID: 15665
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: FreeBSD 4.4-STABLE
PHP Version: 4.1.1
New Comment:
Please recompile php with debug symbols (--enable-debug) and provide a
backtrace.
Previous Comments:
[2002-05-29 18:21:10] [EMAIL PROTECTED]
I have very similar thing happening. Script is reading directory with
a
lot of image files, printing them in colors. The script crash as both
mod_php4 in apache and command-line. It crash every time at same
position, however it crash in different positions when called thru
apache and when run from command line. Relevant part of script:
$handle = opendir("/home/pav/images/fit");
while ($fajl = readdir($handle)) {
if ($fajl == "." || $fajl == "..") continue;
echo ''.$fajl."\n";
}
closedir($handle);
backtrace
#0 0x2836aaed in readdir_r () from /usr/lib/libc.so.4
(gdb) bt
#0 0x2836aaed in readdir_r () from /usr/lib/libc.so.4
#1 0x8091935 in php_if_readdir ()
#2 0x80ed79c in execute ()
#3 0x80d9171 in zend_execute_scripts ()
#4 0x8062406 in php_execute_script ()
#5 0x8060288 in main ()
#6 0x805f629 in _start ()
PHP 4.2.1, Apache 1.3.24, FreeBSD 4.5-STABLE
[2002-05-08 04:49:34] [EMAIL PROTECTED]
I had the mkdir problem in 4.1.1 under FreeBSD, but it appears to be
fixed in 4.2.1RC2:
http://bugs.php.net/bug.php?id=17034
[2002-05-08 04:35:09] [EMAIL PROTECTED]
Ok, ignore that :) Maybe its related?
[2002-05-08 04:33:49] [EMAIL PROTECTED]
See:
http://bugs.php.net/bug.php?id=16905 (closed)
&&
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/37825 (patch)
Jason
[2002-04-13 08:55:39] [EMAIL PROTECTED]
forgon to tell you...
apache 1.3.22 and php4.1.1 (both from the ports collection)
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/15665
--
Edit this bug report at http://bugs.php.net/?id=15665&edit=1
Bug #15665 Updated: readdir() crashes
ID: 15665
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: FreeBSD 4.4-STABLE
PHP Version: 4.1.1
New Comment:
I have very similar thing happening. Script is reading directory with
a
lot of image files, printing them in colors. The script crash as both
mod_php4 in apache and command-line. It crash every time at same
position, however it crash in different positions when called thru
apache and when run from command line. Relevant part of script:
$handle = opendir("/home/pav/images/fit");
while ($fajl = readdir($handle)) {
if ($fajl == "." || $fajl == "..") continue;
echo ''.$fajl."\n";
}
closedir($handle);
backtrace
#0 0x2836aaed in readdir_r () from /usr/lib/libc.so.4
(gdb) bt
#0 0x2836aaed in readdir_r () from /usr/lib/libc.so.4
#1 0x8091935 in php_if_readdir ()
#2 0x80ed79c in execute ()
#3 0x80d9171 in zend_execute_scripts ()
#4 0x8062406 in php_execute_script ()
#5 0x8060288 in main ()
#6 0x805f629 in _start ()
PHP 4.2.1, Apache 1.3.24, FreeBSD 4.5-STABLE
Previous Comments:
[2002-05-08 04:49:34] [EMAIL PROTECTED]
I had the mkdir problem in 4.1.1 under FreeBSD, but it appears to be
fixed in 4.2.1RC2:
http://bugs.php.net/bug.php?id=17034
[2002-05-08 04:35:09] [EMAIL PROTECTED]
Ok, ignore that :) Maybe its related?
[2002-05-08 04:33:49] [EMAIL PROTECTED]
See:
http://bugs.php.net/bug.php?id=16905 (closed)
&&
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/37825 (patch)
Jason
[2002-04-13 08:55:39] [EMAIL PROTECTED]
forgon to tell you...
apache 1.3.22 and php4.1.1 (both from the ports collection)
[2002-04-13 08:54:30] [EMAIL PROTECTED]
I have the same problems with a script under freebsd4.5-release.
It just started crasching out of nothing. No change in the dirscancode,
no change on the server. Worked just fine before yesterday. The only
way to run the script now is to press the updatebutton in
internetexplorer several times quite quickly, it works when I do so (I
get about 5-6 httpds wotrking in the background).
This is so strange.
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/15665
--
Edit this bug report at http://bugs.php.net/?id=15665&edit=1
Bug #16905 Updated: mkdir crashes
ID: 16905
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Scripting Engine problem
Operating System: FreeBSD 4.5
PHP Version: 4.2.0
New Comment:
Yeah sorry! Commented bad bug. Sorry. This apply to bug #15665. Sorry
again.
Previous Comments:
[2002-05-29 18:18:02] [EMAIL PROTECTED]
I have very similar thing happening. Script is reading directory with a
lot of image files, printing them in colors. The script crash as both
mod_php4 in apache and command-line. It crash every time at same
position, however it crash in different positions when called thru
apache and when run from command line. Relevant part of script:
$handle = opendir("/home/pav/images/fit");
while ($fajl = readdir($handle)) {
if ($fajl == "." || $fajl == "..") continue;
echo ''.$fajl."\n";
}
closedir($handle);
backtrace
#0 0x2836aaed in readdir_r () from /usr/lib/libc.so.4
(gdb) bt
#0 0x2836aaed in readdir_r () from /usr/lib/libc.so.4
#1 0x8091935 in php_if_readdir ()
#2 0x80ed79c in execute ()
#3 0x80d9171 in zend_execute_scripts ()
#4 0x8062406 in php_execute_script ()
#5 0x8060288 in main ()
#6 0x805f629 in _start ()
PHP 4.2.1, Apache 1.3.24, FreeBSD 4.5-STABLE
[2002-05-07 08:23:06] [EMAIL PROTECTED]
Hi,
I've submitted a pr to the FreeBSD php port maintainer, including a
patch.
The patch can be downloaded from:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/37825
Jason
[2002-05-06 13:35:58] [EMAIL PROTECTED]
This bug has been fixed in CVS. You can grab a snapshot of the
CVS version at http://snaps.php.net/
fix was merged into 4.2 branch, so it should be included in 4.2.1. (we
were passing a pointer to a mode_t, which is a short on freebsd, and it
was being treated elsewhere as a pointer to a long. this is the fun
sort of bug that usually only shows up on non-debug builds.)
[2002-05-06 11:37:39] [EMAIL PROTECTED]
Happens in 4.2.1RC1 as well. When compiled with --enable-debug, works
fine. When compiled with --disable-debug, it doesn't work
[2002-05-02 06:04:48] [EMAIL PROTECTED]
Just to further confuse the issue. If I build the 4.3.0-DEV snaphost
(php4-20020502) with --enable-debug then it behaves normally.
Jason
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/16905
--
Edit this bug report at http://bugs.php.net/?id=16905&edit=1
Bug #16905 Updated: mkdir crashes
ID: 16905
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Scripting Engine problem
Operating System: FreeBSD 4.5
PHP Version: 4.2.0
New Comment:
I have very similar thing happening. Script is reading directory with a
lot of image files, printing them in colors. The script crash as both
mod_php4 in apache and command-line. It crash every time at same
position, however it crash in different positions when called thru
apache and when run from command line. Relevant part of script:
$handle = opendir("/home/pav/images/fit");
while ($fajl = readdir($handle)) {
if ($fajl == "." || $fajl == "..") continue;
echo ''.$fajl."\n";
}
closedir($handle);
backtrace
#0 0x2836aaed in readdir_r () from /usr/lib/libc.so.4
(gdb) bt
#0 0x2836aaed in readdir_r () from /usr/lib/libc.so.4
#1 0x8091935 in php_if_readdir ()
#2 0x80ed79c in execute ()
#3 0x80d9171 in zend_execute_scripts ()
#4 0x8062406 in php_execute_script ()
#5 0x8060288 in main ()
#6 0x805f629 in _start ()
PHP 4.2.1, Apache 1.3.24, FreeBSD 4.5-STABLE
Previous Comments:
[2002-05-07 08:23:06] [EMAIL PROTECTED]
Hi,
I've submitted a pr to the FreeBSD php port maintainer, including a
patch.
The patch can be downloaded from:
http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/37825
Jason
[2002-05-06 13:35:58] [EMAIL PROTECTED]
This bug has been fixed in CVS. You can grab a snapshot of the
CVS version at http://snaps.php.net/
fix was merged into 4.2 branch, so it should be included in 4.2.1. (we
were passing a pointer to a mode_t, which is a short on freebsd, and it
was being treated elsewhere as a pointer to a long. this is the fun
sort of bug that usually only shows up on non-debug builds.)
[2002-05-06 11:37:39] [EMAIL PROTECTED]
Happens in 4.2.1RC1 as well. When compiled with --enable-debug, works
fine. When compiled with --disable-debug, it doesn't work
[2002-05-02 06:04:48] [EMAIL PROTECTED]
Just to further confuse the issue. If I build the 4.3.0-DEV snaphost
(php4-20020502) with --enable-debug then it behaves normally.
Jason
[2002-05-02 04:54:10] [EMAIL PROTECTED]
I've just tried a 4.3.0 snapshot using the same test file as
[EMAIL PROTECTED] posted above.
Operating system is FreeBSD 4.5.
-
php4-20020502# ./php ~/test.php
X-Powered-By: PHP/4.3.0-dev
Content-type: text/html
Warning: mkdir() failed (No such file or directory) in
/disk1/home/jase/bigmailbox/test.php on line 3
Segmentation fault (core dumped)
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/16905
--
Edit this bug report at http://bugs.php.net/?id=16905&edit=1
Bug #17397 Updated: PDF and Oracle 9i support don't seem to want to play together.
ID: 17397
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Compile Failure
Operating System: Linux 2.4.18
PHP Version: 4.2.1
New Comment:
This actually turned out to be a problem with the way Oracle was
configured/installed. After the issues with Oracle were resolved php
compiled and installed successfully. Here's a tip: Just installing
client and development libraries for Oracle doesn't work (I don't want
a db on this machine, only the necessary stuff to make php talk to a
remote db). You have to do a default install of 9i enterprise including
the test database and all the components, then remove the components
you don't need before php will compile successfully. Oracle really
needs to improve their crappy installer. Although, I still think it's
odd that php was reporting pdflib as the culprate on this one.
Previous Comments:
[2002-05-23 16:09:15] [EMAIL PROTECTED]
I can't seem to be able to find a way to compile php with oracle and
pdflib support. I am experiencing the following errors:
When running "configure" with the following options:
./configure \
--with-apxs=/usr/sbin/apxs \
--with-sybase \
--with-pdflib \
--with-oracle \
--with-zlib \
--with-gd \
--enable-sigchild \
--without-mysql \
--with-system-regex \
--with-config-file-path=/etc/httpd
configure dies and I recieve the following error message:
configure: error:
PDFlib extension requires at least pdflib 3.x. You may also need
libtiff, libjpeg, libpng and libz.
Use the options --with-tiff-dir=, --with-jpeg-dir=,
--with-png-dir= and --with-zlib-dir=
See config.log for more information.
config.log has the following message on the last several lines:
configure:51569: checking for PDF_show_boxed in -lpdf
configure:51588: gcc -o conftest -g -O2 -DLINUX=22 -DEAPI -DEAPI_MM
-DEAPI_MM_CORE_PATH=/var/run/httpd.mm
-Wl,-rpath,/home/oracle/OraHome1/lib -L/home/oracle/OraHome1/lib
conftest.c -lpdf -lz -lm -ldl -lm -ldl -lgd -lz -lcrypt -lresolv -lm
-ldl -lnsl -lresolv -lcrypt -lclntsh -lclntsh 1>&5
/usr/bin/ld: cannot find -lclntsh
collect2: ld returned 1 exit status
configure: failed program was:
#line 51577 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char PDF_show_boxed();
int main() {
PDF_show_boxed()
; return 0; }
I sat around for nearly an hour playing around with various options
until I discovered that if I attempt to configure php without the
"--with-oracle" option everything works without a problem and I can
compile successfully (without oracle support of course). PDF support
works without a problem (I generated a sample pdf document just to be
sure). If put back in the "--with-oracle" option and remove the
"--with-pdflib" option once again php compiles successfully (without
pdflib support) and Oracle support works correctly.
As always, any suggestions are greatly appriciated.
--
Ted
--
Edit this bug report at http://bugs.php.net/?id=17397&edit=1
Bug #17516: overriding constants in config.w32.h.in
From: [EMAIL PROTECTED]
Operating system: Windows
PHP version: 4.0CVS-2002-05-29
PHP Bug Type: Feature/Change Request
Bug description: overriding constants in config.w32.h.in
While working with PEAR installer it occurred that the pear.ini setting
file got placed in a newly created directory c:\php4. This dir is
hardcoded in:
http://cvs.php.net/co.php/php4/main/config.w32.h.in
To respect other php installations like in c:\php or c:\programme\php one
need a feature to override the constants given by the php core:
http://www.php.net/manual/en/reserved.constants.core.php
Since scripts in PEAR are designed using these constants, and constants
are not variable, there is probably only one way to override these values
in config.w32.h.in e.g. like:
#define PHP_SYSCONFDIR ( (getenv("PHP_SYSCONFDIR") != "c:\\php4" ) ?
getenv("PHP_SYSCONFDIR" ) : "c:\\php4" )
This allows the user to configure its paths by hand through setting the
environment variables like:
c:\>set PHP_SYSCONFDIR=c:\php
I propose to do this switch for all path related constants in
config.w32.h.in [DIRECTORY_SEPARATOR, PHP_SYSCONFDIR,
DEFAULT_INCLUDE_PATH, PEAR_INSTALL_DIR, PEAR_EXTENSION_DIR,
PHP_EXTENSION_DIR, PHP_BINDIR, PHP_LIBDIR, PHP_DATADIR, PHP_SYSCONFDIR,
PHP_LOCALSTATEDIR, PHP_CONFIG_FILE_PATH].
-urs
--
Edit bug report at http://bugs.php.net/?id=17516&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17516&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17516&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17516&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17516&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17516&r=support
Expected behavior: http://bugs.php.net/fix.php?id=17516&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17516&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17516&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17516&r=globals
Bug #17515: Repeatedly calling the mail function does not work.
From: [EMAIL PROTECTED] Operating system: Windows2000 and WindowsXP PHP version: 4.2.0 PHP Bug Type: Mail related Bug description: Repeatedly calling the mail function does not work. When calling the mail-function repeatedly, very quickly, only one in ~15 mails will actually be sent. However, the mail function returns true. This is on my local development machine, as well as on the servers at my internet-hosting-provider. I am using the SMTP service of Internet Information Server. When I do a 'Sleep(1)' between every call to the mail-function, all mails are properly sent. Regards, Peter. -- Edit bug report at http://bugs.php.net/?id=17515&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17515&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17515&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17515&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17515&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17515&r=support Expected behavior: http://bugs.php.net/fix.php?id=17515&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17515&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17515&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17515&r=globals
Bug #14688 Updated: session_register() doesn't register
ID: 14688
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Session related
Operating System: linux 2.2
PHP Version: 4.2.0RC2
New Comment:
I didn't miss the point. You should probably have stated that your
example showed the problem with simple hrefs as well. I scan things
quickly and if an obvious thing such as trying to do a setcookie and a
redirect in the same request is there, I comment on that and move on.
What you are seeing is a side-effect of having
$HTTP_SESSION_VARS['counter'] and $_SESSION['counter'] and $counter all
be references to the same data. unset($counter) only removes one
reference. It would be inconsistent to make unset() remove all
references, and the most common usage is simply $counter = new_value
which works correctly. Doing a second session_register() on the same
variable doesn't currently do anything since it is already registered
unless of course you have called session_unregister on it. So in
summary, I think this is a fringe case that needs documenting and not
necessarily fixing unless someone can come up with a clean and
consistent fix.
Previous Comments:
[2002-05-29 16:04:27] [EMAIL PROTECTED]
I see you miss the point. I have made that example of three scripts
with redirects to easy things. You can equaly put links into scripts
and then click them manualy with the same effect. All Set_Cookie and
Redirect headers look fine. Take a look at the first message here from
[EMAIL PROTECTED] I can only speculate why this does not work
in 4.1 or 4.2: when you register variable with session_register php it
puts a referense to variable. When unset function unsets variable,
session variable still hold reference to old variable, though it does
not exist anymore. When you try to reregister variable with
session_register it thinks that that variable already registered, and
does nothing. So whaterver new value you assign id does not reach
session module, even at exit of the script. But in theory session
should reference to the name of variable not variable itself, and if
variable is gone in context so must session registered one. And if you
use session_unregister in the same script as unset, you would get
correct result. (see ### uncomment this to see the difference #
session_unregister("counter");).
I don't want to insult anyone but I am amazed that such simple bug have
not been fixed several monthts yet.
[2002-05-11 00:06:17] [EMAIL PROTECTED]
Having a SetCookie and a Redirect in the same response causes
unpredictable behaviour and will be browser-dependant. I'd suggest not
relying on this. PHP does send both, so unless you can somehow show us
an example of PHP not actually sending both the Location and the
SetCookie then I don't see how this is a PHP issue.
[2002-05-11 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-25 12:43:34] [EMAIL PROTECTED]
4.2.0 final still has the problem. And it is a problem, not an
imagination.
[2002-04-11 04:18:27] [EMAIL PROTECTED]
FYI, with 4.0.5 my example scripts gives expected result - 4 with
register_globals = on, and the same nothing with register_globals =
off.
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/14688
--
Edit this bug report at http://bugs.php.net/?id=14688&edit=1
Bug #14688 Updated: session_register() doesn't register
ID: 14688
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Session related
Operating System: linux 2.2
PHP Version: 4.2.0RC2
New Comment:
I see you miss the point. I have made that example of three scripts
with redirects to easy things. You can equaly put links into scripts
and then click them manualy with the same effect. All Set_Cookie and
Redirect headers look fine. Take a look at the first message here from
[EMAIL PROTECTED] I can only speculate why this does not work
in 4.1 or 4.2: when you register variable with session_register php it
puts a referense to variable. When unset function unsets variable,
session variable still hold reference to old variable, though it does
not exist anymore. When you try to reregister variable with
session_register it thinks that that variable already registered, and
does nothing. So whaterver new value you assign id does not reach
session module, even at exit of the script. But in theory session
should reference to the name of variable not variable itself, and if
variable is gone in context so must session registered one. And if you
use session_unregister in the same script as unset, you would get
correct result. (see ### uncomment this to see the difference #
session_unregister("counter");).
I don't want to insult anyone but I am amazed that such simple bug have
not been fixed several monthts yet.
Previous Comments:
[2002-05-11 00:06:17] [EMAIL PROTECTED]
Having a SetCookie and a Redirect in the same response causes
unpredictable behaviour and will be browser-dependant. I'd suggest not
relying on this. PHP does send both, so unless you can somehow show us
an example of PHP not actually sending both the Location and the
SetCookie then I don't see how this is a PHP issue.
[2002-05-11 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-25 12:43:34] [EMAIL PROTECTED]
4.2.0 final still has the problem. And it is a problem, not an
imagination.
[2002-04-11 04:18:27] [EMAIL PROTECTED]
FYI, with 4.0.5 my example scripts gives expected result - 4 with
register_globals = on, and the same nothing with register_globals =
off.
[2002-04-10 11:10:21] [EMAIL PROTECTED]
With register_globals = off I get nothing, i.e. no number, just
newline, with or without session_unregister("counter"). Seems like
$counter does not exist at all.
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/14688
--
Edit this bug report at http://bugs.php.net/?id=14688&edit=1
Bug #15983 Updated: session variables lost between pages
ID: 15983 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Session related Operating System: Debian/Linux mips platform PHP Version: 4.1.2 and 4.2.0 New Comment: I'm working with win version 4.1.2, and while the very first example's code worked find for me (printed 'Hello world' as expected), the test script from [EMAIL PROTECTED] did not. >From my testing, it appears as though using $_SESSION just doesn't register a value with the session, although it maintains any changes to a variable once it has been registered with the session. If instead of, you use, the script will increment the variable just fine. But because $_SESSION['test'] = 0; doesn't set/register the variable the first time, each time you refresh you will find yourself stuck in the if statement, and the value still stuck at 0. -- foos Previous Comments: [2002-04-30 13:47:37] [EMAIL PROTECTED] This bug is killing me. Anyone tried 4.1.2 RC4 ? Otherwise, I am rolling back to 4.06. Don't really have time to do the workarounds [2002-04-28 07:31:44] [EMAIL PROTECTED] Tried the latest snapshort and I have started to debug the code myself using to computers a i386 as reference and the MIPS. We will see how much I can debug of this. Regards, Søren, [2002-04-26 21:07:56] [EMAIL PROTECTED] This _might_ be related to some fixes made recently.. Can you try with the latest CVS snapshot from http://snaps.php.net/ please? [2002-04-25 17:30:54] [EMAIL PROTECTED] Just compiled 4.2.0 tried the new script. The error is stille there. The session file in /tmp contains: test|i:1; But it displays 0 (Which is correct the first time). Change the filesystem from ext3 to ext2 to make sure that was not the problem. Updated the system with updated packages from debian. Regards, Søren, [2002-04-24 18:19:03] [EMAIL PROTECTED] Reopen if this script does not work for you with PHP 4.2.0: It works fine here..(reloading the page increases the count) --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/15983 -- Edit this bug report at http://bugs.php.net/?id=15983&edit=1
Bug #17469 Updated: After memory size exhaustion, Apache dies on next SIGUSR1
ID: 17469 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Apache related Operating System: Linux 2.4 PHP Version: 4.2.1 New Comment: Yes, I've just tried without Optimizer, same result. Previous Comments: [2002-05-28 07:52:16] [EMAIL PROTECTED] Does this also happen without the Zend Optimizer? [2002-05-28 03:33:03] [EMAIL PROTECTED] Everytime I have an "Allowed memory size of ... bytes exhausted" error in PHP, my Apache 1.3.24 dies on the next SIGUSR1 (graceful restart) it receives (only the Apache main process dies, without log entry). Config: - PHP 4.1.2 to 4.2.1 tested (compiled-in) - Apache mod_ssl 2.8.8 - ZendOptimizer 1.3.1 - Memory limit set to 8388608 -- Edit this bug report at http://bugs.php.net/?id=17469&edit=1
Bug #17513: Default Additional command of mail()
From: [EMAIL PROTECTED] Operating system: Redhat 7.1 PHP version: 4.1.2 PHP Bug Type: Mail related Bug description: Default Additional command of mail() Hello, when a user put in his script the mail() function, the mail is sent and we see in the log from: apache@localdomain If we set the additional command [EMAIL PROTECTED] so the log become from: [EMAIL PROTECTED] and any error return mail will be send to fromme (and no more apache)... Meanwhile, this news feature is not implemented by all projets in php, of course, a user can not set this additional command, so, the mail will be send from apache and it's not recommanded ... The best will be that if the additional header is not set, so the mail() function serach the From line in the header and put it as additional header ...(the Error-to line is not always set, but the from is always) So, the very best will that if the additional header is not set AND there is no From line in the normal header, so the mail() return false. This option can for example, be activated from the php.ini. So, if a administrator want it, it can force user to set the From line in the header and/or a additional command to identify mail in the log files and for not error mal return to apache (and not user) Thank you very much ... Best regards, -- Edit bug report at http://bugs.php.net/?id=17513&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17513&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17513&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17513&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17513&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17513&r=support Expected behavior: http://bugs.php.net/fix.php?id=17513&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17513&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17513&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17513&r=globals
Bug #17512: $_SESSION support may be inconsistent
From: [EMAIL PROTECTED] Operating system: Win XP PHP version: 4.2.1 PHP Bug Type: Session related Bug description: $_SESSION support may be inconsistent Situation: Working with PHP4's session functions, I've encountered a problem on a local install (PHP 4.2.1, Apache2 (could also be an Apache2 bug), Windows XP, MySQL 3.23.49) that does not exist with the same script on a Linux/Apache 1.x/PHP 4.1.2 installation with the same PHP configurations. It would appear to be a bug in PHP's handling of $_SESSION in certain situations, but it's possible something else is going on that has escaped my attention. Symptoms: Using $_SESSION as outlined in the PHP docs with session_start() and no session_register() for register_globals being turned off, logging into the script in question creates a session but does not write the actual session data (key/value pairs) to it. Just a session id and expiry. This happens with either the standard /tmp/ flatfile or MySQL (session_set_save_handler) session logging. Solution: The only thing I found that could get it to correctly write the session data is to replace $_SESSION with $HTTP_SESSION_VARS throughout the script. That doesn't make sense, since 4.2.1 is obviously more recent than the 4.1.0 release which added $_SESSION... Ok, one step down. More surprising is that on logging out, unset'ing the session variables is not "writing" the empty session to the database. It should leave the session id and expiry in place and wipe out the session data, but all remains untouched. The session variables themselves are being emptied (tested by echoing them to the browser), but that's it. unset($HTTP_SESSION_VARS['sess_id']); unset($HTTP_SESSION_VARS['sess_name']); or: unset($HTTP_SESSION_VARS); Neither of those approaches worked from the standpoint of changing the session (as opposed to the variables' values). The thing that I found which sort of works is to set the session variables to NULL instead of unset'ing them: $HTTP_SESSION_VARS['sess_id'] = NULL; $HTTP_SESSION_VARS['sess_name'] = NULL; That didn't exactly empty the session, but it did make it invalid, with the following session data resulting: sess_id|N;sess_name|N; as opposed to the valid format which might look like: sess_id|s:1:"1";sess_name|s:5:"admin"; For a username of "admin" and a id of "1". I guess that's better than nothing, but it isn't overly assuring that unset() doesn't work... I did find mention of what appears to be the same problem in another bug tracker report: http://bugs.php.net/bug.php?id=15923 Making the above outlined changes did not adversely affect the non-local installation of the script, so it appears to be a good balance if you need something to work on multiple server environments. A couple of other bug reports that are loosely related by may or may not be the same are: http://bugs.php.net/bug.php?id=17069 http://bugs.php.net/bug.php?id=16890 Thanks, Dan Kaplan -- Edit bug report at http://bugs.php.net/?id=17512&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17512&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17512&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17512&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17512&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17512&r=support Expected behavior: http://bugs.php.net/fix.php?id=17512&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17512&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17512&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17512&r=globals
Bug #5653 Updated: PIKE specific: with setcookie(), only the last cookie is written
ID: 5653 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Other web server Operating System: Linux PHP Version: 4.0.5 New Comment: i'm using apache 2.0.36 and php 4.2.1, and since I'm using apache the cookie problems appeared. Previous Comments: [2002-02-02 06:40:15] [EMAIL PROTECTED] No feedback was provided for this bug, so it is being suspended. If you are able to provide the information that was requested, please do so and change the status of the bug back to "Open". [2002-01-11 16:45:03] [EMAIL PROTECTED] Can this be reproduced with the PHP 4.1.1, and perhaps the latest roxen/pike? [2001-08-16 12:55:28] [EMAIL PROTECTED] [2001-08-16 12:24:36] [EMAIL PROTECTED] There is small problem in Roxen's SAPI, which arises when duplicate headers are sent out. While playing with some PHP apps with Roxen, I found that regardless how many cookies are set in PHP code, only one is sent to the browser. Investigation shows that Roxen's SAPI uses Pike's type "mapping" to send headers, which (of course) doesn't allow duplicate headers (in my case "Set-Cookie") to be sent, i.e. only last one is sent, since subsequesnt calls to set header with the same name will replace previous. Proposed solution: use array instead of mapping. It will require changes in Roxen module as well, of course, but this should not be difficult. [2001-08-14 20:08:47] [EMAIL PROTECTED] feedback -> open [2001-07-24 12:23:37] [EMAIL PROTECTED] OK here is the result... Variable Value PHP_SELF = /test.php HTTP_COOKIE_VARS["cookie3"] = phprocks if you don't believe you can try at www.delta7.de/test.php. The real problem is in source-file src/sapi/roxen/roxen.c about line 298 (in ver 4.0.6 of PHP)... this function (pike): mapping_string_insert(REQUEST_DATA, ind, &mappie); does not append headers of the same type (here cookies). this means: old cookies are deleted and replaced with the last one you set. The Problen is _not_ on the side of the webserver. I found out (and may proove) that the roxen-php-module will recieve more than only one cookie if you like, i would make some php-scripts that will show you... 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/5653 -- Edit this bug report at http://bugs.php.net/?id=5653&edit=1
Bug #17511: PATH_TRANSLATED variable incorrectly set since PHP 4.0.5
From: [EMAIL PROTECTED] Operating system: Linux 2.2/SuSE 6.4 PHP version: 4.1.2 PHP Bug Type: Variables related Bug description: PATH_TRANSLATED variable incorrectly set since PHP 4.0.5 Hi, I had to generate a new bug report, since a bug in your bug tracking system prevented me from editing the original one. between version 4.0.4 and 4.0.5 the setting of the PATH_TRANSLATED variable changed. In version 4.0.4, the following URL http://www1.jobpilot.de/test.phtml/bla/fasel resulted in the following PATH_TRANSLATED value: /JobsAdverts/OnlineServer/web/de/test.phtml (which is the correct script file name). ever since 4.0.5, the same URL results in the following value: /JobsAdverts/OnlineServer/web/de/bla/fasel which does not look right. According to the documentation, PATH_TRANSLATED is the "Filesystem- (not document root-) based path to the current script, after the server has done any virtual-to-real mapping. " BTW. the documentation should make it clear what is the difference between PATH_TRANSLATED and SCRIPT_FILENAME - from to the current explanation, I don't understand it. BTW we are using Apache 1.3.23. Best Regards, Arno Schaefer -- Edit bug report at http://bugs.php.net/?id=17511&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17511&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17511&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17511&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17511&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17511&r=support Expected behavior: http://bugs.php.net/fix.php?id=17511&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17511&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17511&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17511&r=globals
Bug #17490 Updated: serialize() generates a string that unserialize() can't handle
ID: 17490
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Session related
Operating System: linux rh7.2
PHP Version: 4.2.1
New Comment:
can you be more specific on why it's not a bug? if it's a spec, where
(and what) is that spec? or point me to the correct line of code in the
codebase.
unfortunately it's not easy for me to create a small script to
reproduce this, as the code that generates it includes a large library
of routines. it's obviously possible to generate it without all that,
but since i dont know exactly what's causing it it would be a lot of
trial and error figuring out how to reproduce it.
Previous Comments:
[2002-05-29 13:11:31] [EMAIL PROTECTED]
Oops sorry. I must go to bed now.
Could you make a short script for this bug?
[2002-05-29 13:09:34] [EMAIL PROTECTED]
This is not a bug, but it is the way session module serializes
variables. It's a spec.
It can be fixed, though.
[2002-05-28 15:41:40] [EMAIL PROTECTED]
this bug is filed under "Session related", but is not specific to the
session system, but rather the serialize/unserialize mechanism. I'm not
using the php session code to generate the bug.
compile info is ./configure --with-apxs --with-mysql on a linux rh 7.2
machine. tested with PHP 4.2.1 and 4.1.1
problem: while attempting to serialize a complex structure, PHP
generates a string that unserialize is not able to handle. the exact
error message is:
unserialize() failed at offset 1016 of 5327 bytes
unserialize() fails even when the previous statement serializes it,
ie:
$serVal = serialize($data);
$unSerVal = unserialize($serVal);
so the data is not mucked with between serializing and unserializing.
the exact data it's unserializing is included -- as you can see it's a
pretty complex data structure made up of just about every php type
there is. from just a glace, i don't see a problem with the actual byte
it's failing on.
please email me for more information on reproducing this.
--- begin data ---
a:8:{s:10:"__SM_mpv__";s:0:"";s:11:"connections";a:1:{s:32:"ec240bd77ee9043c536a9c9f1d1efeb0";a:4:{s:6:"dbType";s:5:"mysql";s:8:"userName";s:5:"x";s:8:"passWord";s:7:"xxx";s:8:"hostName";s:7:"lazarus";}}s:6:"curCon";a:4:{s:3:"cID";s:32:"ec240bd77ee9043c536a9c9f1d1efeb0";s:3:"cDB";s:6:"reCIMS";s:3:"cTB";s:7:"members";s:3:"cVF";s:8:"userName";}s:4:"cols";a:1:{s:56:"ec240bd77ee9043c536a9c9f1d1efeb0|reCIMS|members|userName";a:8:{s:6:"idxNum";O:11:"mycolumndef":22:{s:6:"target";s:46:"/sfbuilder/home/index.php?newColumnName=idxNum";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:0;s:6:"dbHook";s:7:"maxSize";i:10;s:4:"name";s:6:"idxNum";s:10:"needQuotes";b:0;s:10:"prettyName";s:7:"Idx
Num";s:8:"required";b:1;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"text";s:4:"size";i:10;s:9:"tableName";s:7:"members";s:10:"columnType";s:3:"int";}s:3:"uID";O:11:"mycolumndef":22:{s:6:"target";s:43:"/sfbuilder/home/index.php?newColumnName=uID";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:1;s:6:"dbHook";s:7:"maxSize";i:32;s:4:"name";s:3:"uID";s:10:"needQuotes";b:0;s:10:"prettyName";s:4:"U
ID";s:8:"required";b:1;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"text";s:4:"size";i:30;s:9:"tableName";s:7:"members";s:10:"columnType";s:6:"string";}s:8:"userName";O:11:"mycolumndef":22:{s:6:"target";s:48:"/sfbuilder/home/index.php?newColumnName=userName";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:1;s:6:"dbHook";s:7:"maxSize";i:30;s:4:"name";s:8:"userName";s:10:"needQuotes";b:0;s:10:"prettyName";s:9:"User
Name";s:8:"required";b:1;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"text";s:4:"size";i:30;s:9:"tableName";s:7:"members";s:10:"columnType";s:6:"string";}s:8:"passWord";O:11:"mycolumndef":22:{s:6:"target";s:48:"/sfbuilder/home/index.php?newColumnName=passWord";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:1;s:6:"dbHook";s:7:"maxSize";i:30;s:4:"name";s:8:"passWord";s:10:"needQuotes";b:0;s:10:"prettyName";s:9:"Pass
Word";s:8:"required";b:1;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfTyp
Bug #17507 Updated: LDAP module fails to load
ID: 17507 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: LDAP related Operating System: Windows 2000 Advanced Server PHP Version: 4.2.1 New Comment: The DLL included in the 4.2.1 win32 distribution definitely works. You have an old dll lying around somewhere which is loaded instead. Previous Comments: [2002-05-29 13:14:54] [EMAIL PROTECTED] The DLL included in the 4.2.1 win32 distribution definitely works. You have an old dll lying around somewhere which is loaded instead. [2002-05-29 13:05:37] [EMAIL PROTECTED] Sorry, but the bug system is not the appropriate forum for asking support questions. 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 Thank you for your interest in PHP. You PHP is looking for older DLL most likely. [2002-05-29 11:23:35] [EMAIL PROTECTED] Scenario: Default PHP 4.2.1 installation on win2k / apache (as a service, PHP installed as dynamically linked module). php-ini-recommended used with one change: the extensions_dir points to c:/php/extensions/ On enabling the php_ldap.dll extension (removed ';' ) and then restarting the apache service, I get this popup: -- START -- Warning: ldap: Unable to initialize module Module compiled with module API=20020429, debug=0,thread-safety=1 PHP compiled with module API=20010901,debug=0,thread-safety=1 These options need to match -- END -- Can make an educated guess about the nature of the problem, cannot suggest a real fix. Thanks in advance for your time. -- Edit this bug report at http://bugs.php.net/?id=17507&edit=1
Bug #17507 Updated: LDAP module fails to load
ID: 17507 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: LDAP related Operating System: Windows 2000 Advanced Server PHP Version: 4.2.1 New Comment: The DLL included in the 4.2.1 win32 distribution definitely works. You have an old dll lying around somewhere which is loaded instead. Previous Comments: [2002-05-29 13:05:37] [EMAIL PROTECTED] Sorry, but the bug system is not the appropriate forum for asking support questions. 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 Thank you for your interest in PHP. You PHP is looking for older DLL most likely. [2002-05-29 11:23:35] [EMAIL PROTECTED] Scenario: Default PHP 4.2.1 installation on win2k / apache (as a service, PHP installed as dynamically linked module). php-ini-recommended used with one change: the extensions_dir points to c:/php/extensions/ On enabling the php_ldap.dll extension (removed ';' ) and then restarting the apache service, I get this popup: -- START -- Warning: ldap: Unable to initialize module Module compiled with module API=20020429, debug=0,thread-safety=1 PHP compiled with module API=20010901,debug=0,thread-safety=1 These options need to match -- END -- Can make an educated guess about the nature of the problem, cannot suggest a real fix. Thanks in advance for your time. -- Edit this bug report at http://bugs.php.net/?id=17507&edit=1
Bug #17509 Updated: timeout after script finishes when using lots of memory
ID: 17509 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux 4.2.17 PHP Version: 4.1.2 New Comment: Sorry, I forgot to mention this in my original report. set_time_limit() works OK, because the script runs for about 40 minutes. Previous Comments: [2002-05-29 13:04:04] [EMAIL PROTECTED] Could you double check if your system actually changed max execution setting? print_r(ini_get_all()); [2002-05-29 11:54:59] [EMAIL PROTECTED] I have a script that consumes about 180MB of memory while running. Everything works OK, and it finishes successfully, but after it's done, it reports "Fatal error: Maximum execution time of 30 seconds exceeded in Unknown on line 0". Since this error doesn't happen if I configure it to consume less memory, my guess is that this happens while the memory is being released at the end of executing the script. The script uses no particular extensions, just string and array manipulation functions. set_time_limit(0) is called at the beginning. My PHP version is run through Apache 1.3.24 (static build). -- Edit this bug report at http://bugs.php.net/?id=17509&edit=1
Bug #17490 Updated: serialize() generates a string that unserialize() can't handle
ID: 17490
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Feedback
Bug Type: Session related
Operating System: linux rh7.2
PHP Version: 4.2.1
New Comment:
Oops sorry. I must go to bed now.
Could you make a short script for this bug?
Previous Comments:
[2002-05-29 13:09:34] [EMAIL PROTECTED]
This is not a bug, but it is the way session module serializes
variables. It's a spec.
It can be fixed, though.
[2002-05-28 15:41:40] [EMAIL PROTECTED]
this bug is filed under "Session related", but is not specific to the
session system, but rather the serialize/unserialize mechanism. I'm not
using the php session code to generate the bug.
compile info is ./configure --with-apxs --with-mysql on a linux rh 7.2
machine. tested with PHP 4.2.1 and 4.1.1
problem: while attempting to serialize a complex structure, PHP
generates a string that unserialize is not able to handle. the exact
error message is:
unserialize() failed at offset 1016 of 5327 bytes
unserialize() fails even when the previous statement serializes it,
ie:
$serVal = serialize($data);
$unSerVal = unserialize($serVal);
so the data is not mucked with between serializing and unserializing.
the exact data it's unserializing is included -- as you can see it's a
pretty complex data structure made up of just about every php type
there is. from just a glace, i don't see a problem with the actual byte
it's failing on.
please email me for more information on reproducing this.
--- begin data ---
a:8:{s:10:"__SM_mpv__";s:0:"";s:11:"connections";a:1:{s:32:"ec240bd77ee9043c536a9c9f1d1efeb0";a:4:{s:6:"dbType";s:5:"mysql";s:8:"userName";s:5:"x";s:8:"passWord";s:7:"xxx";s:8:"hostName";s:7:"lazarus";}}s:6:"curCon";a:4:{s:3:"cID";s:32:"ec240bd77ee9043c536a9c9f1d1efeb0";s:3:"cDB";s:6:"reCIMS";s:3:"cTB";s:7:"members";s:3:"cVF";s:8:"userName";}s:4:"cols";a:1:{s:56:"ec240bd77ee9043c536a9c9f1d1efeb0|reCIMS|members|userName";a:8:{s:6:"idxNum";O:11:"mycolumndef":22:{s:6:"target";s:46:"/sfbuilder/home/index.php?newColumnName=idxNum";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:0;s:6:"dbHook";s:7:"maxSize";i:10;s:4:"name";s:6:"idxNum";s:10:"needQuotes";b:0;s:10:"prettyName";s:7:"Idx
Num";s:8:"required";b:1;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"text";s:4:"size";i:10;s:9:"tableName";s:7:"members";s:10:"columnType";s:3:"int";}s:3:"uID";O:11:"mycolumndef":22:{s:6:"target";s:43:"/sfbuilder/home/index.php?newColumnName=uID";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:1;s:6:"dbHook";s:7:"maxSize";i:32;s:4:"name";s:3:"uID";s:10:"needQuotes";b:0;s:10:"prettyName";s:4:"U
ID";s:8:"required";b:1;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"text";s:4:"size";i:30;s:9:"tableName";s:7:"members";s:10:"columnType";s:6:"string";}s:8:"userName";O:11:"mycolumndef":22:{s:6:"target";s:48:"/sfbuilder/home/index.php?newColumnName=userName";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:1;s:6:"dbHook";s:7:"maxSize";i:30;s:4:"name";s:8:"userName";s:10:"needQuotes";b:0;s:10:"prettyName";s:9:"User
Name";s:8:"required";b:1;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"text";s:4:"size";i:30;s:9:"tableName";s:7:"members";s:10:"columnType";s:6:"string";}s:8:"passWord";O:11:"mycolumndef":22:{s:6:"target";s:48:"/sfbuilder/home/index.php?newColumnName=passWord";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:1;s:6:"dbHook";s:7:"maxSize";i:30;s:4:"name";s:8:"passWord";s:10:"needQuotes";b:0;s:10:"prettyName";s:9:"Pass
Word";s:8:"required";b:1;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"text";s:4:"size";i:30;s:9:"tableName";s:7:"members";s:10:"columnType";s:6:"string";}s:12:"emailAddress";O:11:"mycolumndef":22:{s:6:"target";s:52:"/sfbuilder/home/index.php?newColumnName=emailAddress";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:1;s:6:"dbHook";s:7:"maxSize";i:60;s:4:"name";s:12:"emailAddress";s:10:"needQuotes";b:0;s:10:"prettyName";s:13:"Email
Address";s:8:"required";b:1;s:12:"sfDirective
Bug #17490 Updated: serialize() generates a string that unserialize() can't handle
ID: 17490
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: linux rh7.2
PHP Version: 4.2.1
New Comment:
This is not a bug, but it is the way session module serializes
variables. It's a spec.
It can be fixed, though.
Previous Comments:
[2002-05-28 15:41:40] [EMAIL PROTECTED]
this bug is filed under "Session related", but is not specific to the
session system, but rather the serialize/unserialize mechanism. I'm not
using the php session code to generate the bug.
compile info is ./configure --with-apxs --with-mysql on a linux rh 7.2
machine. tested with PHP 4.2.1 and 4.1.1
problem: while attempting to serialize a complex structure, PHP
generates a string that unserialize is not able to handle. the exact
error message is:
unserialize() failed at offset 1016 of 5327 bytes
unserialize() fails even when the previous statement serializes it,
ie:
$serVal = serialize($data);
$unSerVal = unserialize($serVal);
so the data is not mucked with between serializing and unserializing.
the exact data it's unserializing is included -- as you can see it's a
pretty complex data structure made up of just about every php type
there is. from just a glace, i don't see a problem with the actual byte
it's failing on.
please email me for more information on reproducing this.
--- begin data ---
a:8:{s:10:"__SM_mpv__";s:0:"";s:11:"connections";a:1:{s:32:"ec240bd77ee9043c536a9c9f1d1efeb0";a:4:{s:6:"dbType";s:5:"mysql";s:8:"userName";s:5:"x";s:8:"passWord";s:7:"xxx";s:8:"hostName";s:7:"lazarus";}}s:6:"curCon";a:4:{s:3:"cID";s:32:"ec240bd77ee9043c536a9c9f1d1efeb0";s:3:"cDB";s:6:"reCIMS";s:3:"cTB";s:7:"members";s:3:"cVF";s:8:"userName";}s:4:"cols";a:1:{s:56:"ec240bd77ee9043c536a9c9f1d1efeb0|reCIMS|members|userName";a:8:{s:6:"idxNum";O:11:"mycolumndef":22:{s:6:"target";s:46:"/sfbuilder/home/index.php?newColumnName=idxNum";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:0;s:6:"dbHook";s:7:"maxSize";i:10;s:4:"name";s:6:"idxNum";s:10:"needQuotes";b:0;s:10:"prettyName";s:7:"Idx
Num";s:8:"required";b:1;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"text";s:4:"size";i:10;s:9:"tableName";s:7:"members";s:10:"columnType";s:3:"int";}s:3:"uID";O:11:"mycolumndef":22:{s:6:"target";s:43:"/sfbuilder/home/index.php?newColumnName=uID";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:1;s:6:"dbHook";s:7:"maxSize";i:32;s:4:"name";s:3:"uID";s:10:"needQuotes";b:0;s:10:"prettyName";s:4:"U
ID";s:8:"required";b:1;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"text";s:4:"size";i:30;s:9:"tableName";s:7:"members";s:10:"columnType";s:6:"string";}s:8:"userName";O:11:"mycolumndef":22:{s:6:"target";s:48:"/sfbuilder/home/index.php?newColumnName=userName";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:1;s:6:"dbHook";s:7:"maxSize";i:30;s:4:"name";s:8:"userName";s:10:"needQuotes";b:0;s:10:"prettyName";s:9:"User
Name";s:8:"required";b:1;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"text";s:4:"size";i:30;s:9:"tableName";s:7:"members";s:10:"columnType";s:6:"string";}s:8:"passWord";O:11:"mycolumndef":22:{s:6:"target";s:48:"/sfbuilder/home/index.php?newColumnName=passWord";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:1;s:6:"dbHook";s:7:"maxSize";i:30;s:4:"name";s:8:"passWord";s:10:"needQuotes";b:0;s:10:"prettyName";s:9:"Pass
Word";s:8:"required";b:1;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"text";s:4:"size";i:30;s:9:"tableName";s:7:"members";s:10:"columnType";s:6:"string";}s:12:"emailAddress";O:11:"mycolumndef":22:{s:6:"target";s:52:"/sfbuilder/home/index.php?newColumnName=emailAddress";s:7:"editing";b:0;s:13:"forceDbSelect";b:1;s:9:"dataField";s:6:"idxNum";s:8:"dataType";N;s:10:"dbOverRide";N;s:14:"dbSelectConfig";a:0:{}s:10:"directives";a:0:{}s:12:"defaultValue";N;s:7:"display";b:1;s:6:"dbHook";s:7:"maxSize";i:60;s:4:"name";s:12:"emailAddress";s:10:"needQuotes";b:0;s:10:"prettyName";s:13:"Email
Address";s:8:"required";b:1;s:12:"sfDirectives";a:0:{}s:9:"sfFilters";a:0:{}s:6:"sfType";s:4:"text";s:4:"size";i:30;s:9:"tableName";s:7:"members";s:10:"columnType";s:6:"string";}s:9:"firstName";O:11:"mycolumndef":22:{s:6:"target";s:49:"/sfbuilder/h
Bug #17498 Updated: still infinite loop in print_r
ID: 17498
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 4.2.1
New Comment:
You don't have to report the same bug report.
We know it, it's just nobody care to fix it.
Previous Comments:
[2002-05-28 20:35:39] [EMAIL PROTECTED]
There is a note in the documentation that since PHP 4.0.4 infinite loop
situations like print_r($GLOBALS) are handled and get stopped. But
there are still situations print_r() results in an infinite loop:
foreach($GLOBALS as $i)
{
print_r($GLOBALS);
}
--
Edit this bug report at http://bugs.php.net/?id=17498&edit=1
Bug #17507 Updated: LDAP module fails to load
ID: 17507 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: LDAP related Operating System: Windows 2000 Advanced Server PHP Version: 4.2.1 New Comment: Sorry, but the bug system is not the appropriate forum for asking support questions. 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 Thank you for your interest in PHP. You PHP is looking for older DLL most likely. Previous Comments: [2002-05-29 11:23:35] [EMAIL PROTECTED] Scenario: Default PHP 4.2.1 installation on win2k / apache (as a service, PHP installed as dynamically linked module). php-ini-recommended used with one change: the extensions_dir points to c:/php/extensions/ On enabling the php_ldap.dll extension (removed ';' ) and then restarting the apache service, I get this popup: -- START -- Warning: ldap: Unable to initialize module Module compiled with module API=20020429, debug=0,thread-safety=1 PHP compiled with module API=20010901,debug=0,thread-safety=1 These options need to match -- END -- Can make an educated guess about the nature of the problem, cannot suggest a real fix. Thanks in advance for your time. -- Edit this bug report at http://bugs.php.net/?id=17507&edit=1
Bug #17509 Updated: timeout after script finishes when using lots of memory
ID: 17509 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux 4.2.17 PHP Version: 4.1.2 New Comment: Could you double check if your system actually changed max execution setting? print_r(ini_get_all()); Previous Comments: [2002-05-29 11:54:59] [EMAIL PROTECTED] I have a script that consumes about 180MB of memory while running. Everything works OK, and it finishes successfully, but after it's done, it reports "Fatal error: Maximum execution time of 30 seconds exceeded in Unknown on line 0". Since this error doesn't happen if I configure it to consume less memory, my guess is that this happens while the memory is being released at the end of executing the script. The script uses no particular extensions, just string and array manipulation functions. set_time_limit(0) is called at the beginning. My PHP version is run through Apache 1.3.24 (static build). -- Edit this bug report at http://bugs.php.net/?id=17509&edit=1
Bug #17510 Updated: PHP module crash
ID: 17510
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 4.0CVS-2002-05-29
New Comment:
Please read instruction also
Previous Comments:
[2002-05-29 13:01:45] [EMAIL PROTECTED]
Thank you for taking the time to report a problem with PHP.
Unfortunately your version of PHP is too old -- the problem
might already be fixed. Please download a new PHP
version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.
[2002-05-29 11:59:50] [EMAIL PROTECTED]
PHP module 4.1.1 crash with message :
[Tue May 28 16:14:58 2002] [notice] child pid 11919 exit signal
Segmentation fault (11)
It's working in 4.0.4pl1 ( with 1.3.12 Apache) , not with 4.1.1 ( with
1.3.22 apache)
The page code is :
Renault Eurodrive - Location de voitures hors taxe pour vos
voyages en Europe
mailto:[EMAIL PROTECTED]";>
function confirmrep() {
if (confirm("Pour une information personnalisée, veuillez choisir
votre pays de résidence sur la page d'accueil puis cliquez à nouveau
sur la rubrique de votre choix : gamme, devis ou
réservation.\n\nVoulez-vous y accéder maintenant ?")) {
location.href="../../indexfr.php" ;
}
else {
window.history.go(-1);
}
}
function checkform(f)
{
var erreur;
erreur=0;
if
((erreur==0)&&(f.cmbpaysliv.options[f.cmbpaysliv.selectedIndex].value==""))
{
alert("Vous devez choisir un pays de livraison !");
f.cmbpaysliv.focus();
erreur=1;
}
if
((erreur==0)&&(f.cmbctrliv.options[f.cmbctrliv.selectedIndex].value==""))
{
alert("Vous devez choisir un centre de livraison !");
f.cmbctrliv.focus();
erreur=1;
}
if (erreur==0)
{
//document.form_reservation.submit();
f.submit();
}
}
function qstypobj(selObj, value_cmb, bk_cmb) {
value_cmb_select = selObj.options[selObj.selectedIndex].value ;
if ( value_cmb_select != "0" ) {
location.href="default.php?"+value_cmb+"="+value_cmb_select+"&"+bk_cmb+"=1"
;
}
else {
//alert("selectionnez un type d'objet !");
}
}
>
">Accueil
Hors taxes
Formule
Gamme
Devis
Réservation
Centres de livraison
Voyager en Europe
">
Pour
réserver,
choisissez :
Votre pays de
livraison\n");
}
else {
print("Votre pays de livraison\n");
}
$query="SELECT DISTINCT pays_ctr FROM centre_livraison";
$stmt = @OCIParse($conn, $query);
$exec_result = @OCIExecute($stmt,OCI_COMMIT_ON_SUCCESS);
if(!$exec_result) {
//echo OCIerror($stmt);
}
$i=1;
while (@OCIFetchInto($stmt,$data,OCI_ASSOC)) {
$paysCtr = trim($data['PAYS_CTR']);
if ($ppaysliv==$i) {
print("$paysCtr\n");
$paysLiv=$paysCtr;
}
else {
print("$paysCtr\n");
}
$i++;
}
?>
Votre centre de
livraison\n");
}
else {
print("Votre centre de livraison\n");
}
$query="SELECT id_ctr, nom_ctr, ville_ctr from centre_livraison where
pays_ctr='$paysLiv'";
$stmt = @OC
Bug #17510 Updated: PHP module crash
ID: 17510
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 4.0CVS-2002-05-29
New Comment:
Thank you for taking the time to report a problem with PHP.
Unfortunately your version of PHP is too old -- the problem
might already be fixed. Please download a new PHP
version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.
Previous Comments:
[2002-05-29 11:59:50] [EMAIL PROTECTED]
PHP module 4.1.1 crash with message :
[Tue May 28 16:14:58 2002] [notice] child pid 11919 exit signal
Segmentation fault (11)
It's working in 4.0.4pl1 ( with 1.3.12 Apache) , not with 4.1.1 ( with
1.3.22 apache)
The page code is :
Renault Eurodrive - Location de voitures hors taxe pour vos
voyages en Europe
mailto:[EMAIL PROTECTED]";>
function confirmrep() {
if (confirm("Pour une information personnalisée, veuillez choisir
votre pays de résidence sur la page d'accueil puis cliquez à nouveau
sur la rubrique de votre choix : gamme, devis ou
réservation.\n\nVoulez-vous y accéder maintenant ?")) {
location.href="../../indexfr.php" ;
}
else {
window.history.go(-1);
}
}
function checkform(f)
{
var erreur;
erreur=0;
if
((erreur==0)&&(f.cmbpaysliv.options[f.cmbpaysliv.selectedIndex].value==""))
{
alert("Vous devez choisir un pays de livraison !");
f.cmbpaysliv.focus();
erreur=1;
}
if
((erreur==0)&&(f.cmbctrliv.options[f.cmbctrliv.selectedIndex].value==""))
{
alert("Vous devez choisir un centre de livraison !");
f.cmbctrliv.focus();
erreur=1;
}
if (erreur==0)
{
//document.form_reservation.submit();
f.submit();
}
}
function qstypobj(selObj, value_cmb, bk_cmb) {
value_cmb_select = selObj.options[selObj.selectedIndex].value ;
if ( value_cmb_select != "0" ) {
location.href="default.php?"+value_cmb+"="+value_cmb_select+"&"+bk_cmb+"=1"
;
}
else {
//alert("selectionnez un type d'objet !");
}
}
>
">Accueil
Hors taxes
Formule
Gamme
Devis
Réservation
Centres de livraison
Voyager en Europe
">
Pour
réserver,
choisissez :
Votre pays de
livraison\n");
}
else {
print("Votre pays de livraison\n");
}
$query="SELECT DISTINCT pays_ctr FROM centre_livraison";
$stmt = @OCIParse($conn, $query);
$exec_result = @OCIExecute($stmt,OCI_COMMIT_ON_SUCCESS);
if(!$exec_result) {
//echo OCIerror($stmt);
}
$i=1;
while (@OCIFetchInto($stmt,$data,OCI_ASSOC)) {
$paysCtr = trim($data['PAYS_CTR']);
if ($ppaysliv==$i) {
print("$paysCtr\n");
$paysLiv=$paysCtr;
}
else {
print("$paysCtr\n");
}
$i++;
}
?>
Votre centre de
livraison\n");
}
else {
print("Votre centre de livraison\n");
}
$query="SELECT id_ctr, nom_ctr, ville_ctr from centre_livraison where
pays_ctr='$paysLiv'";
$stmt = @OCIParse($conn, $query);
$exec_result = @OCIExecute($stmt,OCI_COMMIT_ON_SUCCESS);
if(!$exec_result) {
//echo OCIerro
Bug #17510: PHP module crash
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.0CVS-2002-05-29
PHP Bug Type: Reproducible crash
Bug description: PHP module crash
PHP module 4.1.1 crash with message :
[Tue May 28 16:14:58 2002] [notice] child pid 11919 exit signal
Segmentation fault (11)
It's working in 4.0.4pl1 ( with 1.3.12 Apache) , not with 4.1.1 ( with
1.3.22 apache)
The page code is :
Renault Eurodrive - Location de voitures hors taxe pour vos
voyages en Europe
mailto:[EMAIL PROTECTED]";>
function confirmrep() {
if (confirm("Pour une information personnalisée, veuillez choisir votre
pays de résidence sur la page d'accueil puis cliquez à nouveau sur la
rubrique de votre choix : gamme, devis ou réservation.\n\nVoulez-vous y
accéder maintenant ?")) {
location.href="../../indexfr.php" ;
}
else {
window.history.go(-1);
}
}
function checkform(f)
{
var erreur;
erreur=0;
if
((erreur==0)&&(f.cmbpaysliv.options[f.cmbpaysliv.selectedIndex].value==""))
{
alert("Vous devez choisir un pays de livraison !");
f.cmbpaysliv.focus();
erreur=1;
}
if
((erreur==0)&&(f.cmbctrliv.options[f.cmbctrliv.selectedIndex].value==""))
{
alert("Vous devez choisir un centre de livraison !");
f.cmbctrliv.focus();
erreur=1;
}
if (erreur==0)
{
//document.form_reservation.submit();
f.submit();
}
}
function qstypobj(selObj, value_cmb, bk_cmb) {
value_cmb_select = selObj.options[selObj.selectedIndex].value ;
if ( value_cmb_select != "0" ) {
location.href="default.php?"+value_cmb+"="+value_cmb_select+"&"+bk_cmb+"=1"
;
}
else {
//alert("selectionnez un type d'objet !");
}
}
>
">Accueil
Hors taxes
Formule
Gamme
Devis
Réservation
Centres de livraison
Voyager en Europe
">
Pour
réserver,
choisissez :
Votre pays de livraison\n");
}
else {
print("Votre pays de livraison\n");
}
$query="SELECT DISTINCT pays_ctr FROM centre_livraison";
$stmt = @OCIParse($conn, $query);
$exec_result = @OCIExecute($stmt,OCI_COMMIT_ON_SUCCESS);
if(!$exec_result) {
//echo OCIerror($stmt);
}
$i=1;
while (@OCIFetchInto($stmt,$data,OCI_ASSOC)) {
$paysCtr = trim($data['PAYS_CTR']);
if ($ppaysliv==$i) {
print("$paysCtr\n");
$paysLiv=$paysCtr;
}
else {
print("$paysCtr\n");
}
$i++;
}
?>
Votre centre de livraison\n");
}
else {
print("Votre centre de livraison\n");
}
$query="SELECT id_ctr, nom_ctr, ville_ctr from centre_livraison where
pays_ctr='$paysLiv'";
$stmt = @OCIParse($conn, $query);
$exec_result = @OCIExecute($stmt,OCI_COMMIT_ON_SUCCESS);
if(!$exec_result) {
//echo OCIerror($stmt);
}
while (@OCIFetchInto($stmt,$data,OCI_ASSOC)) {
$idCtr = trim($data['ID_CTR']);
// $nomCtr= trim($data['NOM_CTR']);
$villeCtr= trim($data['VILLE_CTR']);
if ($pctrliv==$idCtr) {
print("$villeCtr\n");
}
else {
print("$villeCtr\n");
}
}
?>
Veuillez
indiquer votre date de livraison :
$listeMois[$mois]
$annee\n");
}
else {
Bug #17509: timeout after script finishes when using lots of memory
From: [EMAIL PROTECTED] Operating system: Linux 4.2.17 PHP version: 4.1.2 PHP Bug Type: Scripting Engine problem Bug description: timeout after script finishes when using lots of memory I have a script that consumes about 180MB of memory while running. Everything works OK, and it finishes successfully, but after it's done, it reports "Fatal error: Maximum execution time of 30 seconds exceeded in Unknown on line 0". Since this error doesn't happen if I configure it to consume less memory, my guess is that this happens while the memory is being released at the end of executing the script. The script uses no particular extensions, just string and array manipulation functions. set_time_limit(0) is called at the beginning. My PHP version is run through Apache 1.3.24 (static build). -- Edit bug report at http://bugs.php.net/?id=17509&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17509&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17509&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17509&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17509&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17509&r=support Expected behavior: http://bugs.php.net/fix.php?id=17509&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17509&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17509&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17509&r=globals
Bug #17508 Updated: Imap_open doesn't connect
ID: 17508
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IMAP related
Operating System: Solaris 2.8
PHP Version: 4.2.1
New Comment:
As saied i've tried a lot of connection string. Some examples:
{194.183.64.10:pop3/110}
{194.183.64.10:110/pop3}
{194.183.64.10:110/pop3}INBOX
{194.183.64.10:110}INBOX
etc, etc
Previous Comments:
[2002-05-29 11:36:52] [EMAIL PROTECTED]
Hi to all!
I'm tring to configure IMP 3.0 webmail. After many configuration I've
found a problem in imap_open function, it reply with this message:
"Warning: Couldn't open stream {194.183.64.10:110}". I've tried a lot
of connection string but don't work.
My platform has:
Solaris 2.8
Apache 2.0.36
C-client 2001a
PHP 4.2.1
IMP 3.0
HORDE 2.0
Thanks in advanced.
Alessandro Maioli
--
Edit this bug report at http://bugs.php.net/?id=17508&edit=1
Bug #17508: Imap_open doesn't connect
From: [EMAIL PROTECTED]
Operating system: Solaris 2.8
PHP version: 4.2.1
PHP Bug Type: IMAP related
Bug description: Imap_open doesn't connect
Hi to all!
I'm tring to configure IMP 3.0 webmail. After many configuration I've
found a problem in imap_open function, it reply with this message:
"Warning: Couldn't open stream {194.183.64.10:110}". I've tried a lot of
connection string but don't work.
My platform has:
Solaris 2.8
Apache 2.0.36
C-client 2001a
PHP 4.2.1
IMP 3.0
HORDE 2.0
Thanks in advanced.
Alessandro Maioli
--
Edit bug report at http://bugs.php.net/?id=17508&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17508&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17508&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17508&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17508&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17508&r=support
Expected behavior: http://bugs.php.net/fix.php?id=17508&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17508&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17508&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17508&r=globals
Bug #17507: LDAP module fails to load
From: [EMAIL PROTECTED] Operating system: Windows 2000 Advanced Server PHP version: 4.2.1 PHP Bug Type: LDAP related Bug description: LDAP module fails to load Scenario: Default PHP 4.2.1 installation on win2k / apache (as a service, PHP installed as dynamically linked module). php-ini-recommended used with one change: the extensions_dir points to c:/php/extensions/ On enabling the php_ldap.dll extension (removed ';' ) and then restarting the apache service, I get this popup: -- START -- Warning: ldap: Unable to initialize module Module compiled with module API=20020429, debug=0,thread-safety=1 PHP compiled with module API=20010901,debug=0,thread-safety=1 These options need to match -- END -- Can make an educated guess about the nature of the problem, cannot suggest a real fix. Thanks in advance for your time. -- Edit bug report at http://bugs.php.net/?id=17507&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17507&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17507&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17507&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17507&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17507&r=support Expected behavior: http://bugs.php.net/fix.php?id=17507&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17507&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17507&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17507&r=globals
Bug #17419 Updated: Complex objects not correctly stored in ssession
ID: 17419
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Session related
Operating System: Apache
PHP Version: 4.2.1
New Comment:
The correct operating system if BSDi 4.3
Previous Comments:
[2002-05-26 22:13:08] [EMAIL PROTECTED]
OK -- I have tried to telnet to the domain and cannot do that either.
Here is the URL:
http://sql.wash-gop.com/wyck/WebSiteII/html/simpleclass.php
[2002-05-26 12:04:35] [EMAIL PROTECTED]
You don't need telnet access for this. Just telnet from your local box
to the webserver, i.e.
telnet www.yourdomain.com 80
Alternatively, post an url of that page here (or mail it me, if you
prefer to keep it private) and I'll see what I can do.
[2002-05-26 08:20:25] [EMAIL PROTECTED]
I am developing on a web server to which I do not normally have telnet
privileges, but I will ask them if they can open this up to me.
I apologize for putting Apache rather than the OS. I'll get that for
you as soon as I can -- it is BSD something.
Thank you for looking at this!
Wyckham
[2002-05-25 04:41:22] [EMAIL PROTECTED]
Can you gice us some real error message instead of the junk you're
browser is giving you? Can you try to telnet'ing manually to your
webserver and give us the HTTP response?
Also, Apache is not an OS. Please update the field above.
[2002-05-24 16:47:42] [EMAIL PROTECTED]
Complex objects are not correctly stored in a session. This report is
similar to 8676, which was reported fixed. It now appears to be broken
in 4.2.1.
Here is a code scriplet to demonstrate the problem:
betavar =& new Beta(&$this); //Let Beta use Alpha's methods
and properties
$this->alpha1 = 22;
}
function getvar()
{
return $this->alpha1;
}
}
class Beta
{
var $beta1;
var $alphacall;
function Beta(&$par)
{
$this->alphacall = &$par; //alphacall will let Beta use
Alpha's
methods and properties
$this->beta1 = 5;
}
function getalphavar()
{
print("The value of the alphavar from within Beta is: " .
$this->alphacall->alpha1 );
}
}
session_start();
if (! session_is_registered("pm") )
{
session_register("pm"); // register and instantiate the variable
$pm =& new Alpha();
}
print("The vaue of alpha1 is: " . $pm->getvar() );
print("The value of beta1 is: " . $pm->betavar->beta1);
print("" . $pm->betavar->getalphavar() );
?>
OBSERVED BEHAVIOR:
When this page is loaded the first time, everything works as expected,
and the
values of alpha1, and beta 1 print out just fine. However, attempts
to refresh the page yield a browser error message "This page cannot be
displayed".
This structure worked (flakily) on 4.04pi1, and I was hoping that the
fix of 8676 would
have made it solid in 4.2.1. However, the situation is now worse--the
above structure
NEVER works.
--
Edit this bug report at http://bugs.php.net/?id=17419&edit=1
Bug #17319 Updated: zend.h:55:19: unix.h: No such file or directory
ID: 17319 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.2.1 Previous Comments: [2002-05-29 09:23:36] [EMAIL PROTECTED] Hi, this is a dupe of Bug #17417. I've experienced the same error but it turned out to be due to the problem described in #17417. Using "CC=gcc ./configure ..." compiled php-4.2.1 on Solaris 2.8 without any problems. Kind regards, Bert Courtin [2002-05-22 18:47:00] [EMAIL PROTECTED] see: http://bugs.php.net/bug.php?id=17362 I ran into this problem myself. I was using gcc version 3.0.3 on solaris 8 (php4.2.1). I got it to compile by installing the following packages (available from sunfreeware.com) ... milage may vary! m4-1.4-sol8-sparc-local.gz automake-1.6-sol8-sparc-local.gz autoconf-2.53-sol8-sparc-local.gz binutils-2.11.2-sol8-sparc-local.gz I rebuilt the configure file and ran it again (see bug id 17362). Seemed to compile after that. [2002-05-20 16:17:45] [EMAIL PROTECTED] Have you tried CC=/path/to/gcc ./configure ... ? [2002-05-20 16:13:12] [EMAIL PROTECTED] Using GCC download from www.sunfreeware.com # ./configure --with-mysql --with-apache=../apache_1.3.24/ # make Making all in Zend /bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main-D_POSIX_PTHREAD_SEMANTICS -I../TSRM -g -O2 -prefer-non-pic -static -c -o zend_language_parser.lo `test -f zend_language_parser.c || echo './'`zend_language_parser.c In file included from zend_compile.h:24, from zend_language_parser.c:147: zend.h:55:19: unix.h: No such file or directory *** Error code 1 make: Fatal error: Command failed for target `zend_language_parser.lo' Current working directory /scratch/src/php-4.2.1/Zend *** Error code 1 make: Fatal error: Command failed for target `all-recursive' I try some solutions that was report but don't work. Can some one help me? -- Edit this bug report at http://bugs.php.net/?id=17319&edit=1
Bug #17319 Updated: zend.h:55:19: unix.h: No such file or directory
ID: 17319 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.2.1 New Comment: Hi, this is a dupe of Bug #17417. I've experienced the same error but it turned out to be due to the problem described in #17417. Using "CC=gcc ./configure ..." compiled php-4.2.1 on Solaris 2.8 without any problems. Kind regards, Bert Courtin Previous Comments: [2002-05-22 18:47:00] [EMAIL PROTECTED] see: http://bugs.php.net/bug.php?id=17362 I ran into this problem myself. I was using gcc version 3.0.3 on solaris 8 (php4.2.1). I got it to compile by installing the following packages (available from sunfreeware.com) ... milage may vary! m4-1.4-sol8-sparc-local.gz automake-1.6-sol8-sparc-local.gz autoconf-2.53-sol8-sparc-local.gz binutils-2.11.2-sol8-sparc-local.gz I rebuilt the configure file and ran it again (see bug id 17362). Seemed to compile after that. [2002-05-20 16:17:45] [EMAIL PROTECTED] Have you tried CC=/path/to/gcc ./configure ... ? [2002-05-20 16:13:12] [EMAIL PROTECTED] Using GCC download from www.sunfreeware.com # ./configure --with-mysql --with-apache=../apache_1.3.24/ # make Making all in Zend /bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main-D_POSIX_PTHREAD_SEMANTICS -I../TSRM -g -O2 -prefer-non-pic -static -c -o zend_language_parser.lo `test -f zend_language_parser.c || echo './'`zend_language_parser.c In file included from zend_compile.h:24, from zend_language_parser.c:147: zend.h:55:19: unix.h: No such file or directory *** Error code 1 make: Fatal error: Command failed for target `zend_language_parser.lo' Current working directory /scratch/src/php-4.2.1/Zend *** Error code 1 make: Fatal error: Command failed for target `all-recursive' I try some solutions that was report but don't work. Can some one help me? -- Edit this bug report at http://bugs.php.net/?id=17319&edit=1
Bug #13660 Updated: store extra data in db file on create
ID: 13660 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: DBM/DBA related Operating System: Linux kernel 2.4.10 i686 PHP Version: 4.0.6 New Comment: I have seen the same thing. It only seems to happen to me when I am including other php files. If I take out all require()'s, the db is zero'ed out again. Any suggestions? Previous Comments: [2001-10-13 11:49:31] [EMAIL PROTECTED] Show the script below the text. When I create a new db file, extras data has been stored. In all cases, it was the script itself (ask me if you need the new db file directly). I think it's a bug (or a new backup feature ;). Config details : gdbm 1.8.0 libc6 kernel 2.4.10 data on a reiserfs partition Is it due to a default filesize ? If yes do you make a zero fill of the extra memory used ? -- Edit this bug report at http://bugs.php.net/?id=13660&edit=1
Bug #17506 Updated: --with-cli doesn't install built php binary with make install
ID: 17506 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: *Compile Issues Operating System: Linux Redhat 7.3 PHP Version: 4.2.1 New Comment: This is intentional, as cli is marked experimental in PHP 4.2.1. Previous Comments: [2002-05-29 09:16:49] [EMAIL PROTECTED] This bug has been fixed in CVS. You can grab a snapshot of the CVS version 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. Thank you for the report, and for helping us make PHP better. [2002-05-29 09:15:34] [EMAIL PROTECTED] The Summary says it. After make install I manually have to copy sapi/cli/php to /usr/bin (or whereever). -- Edit this bug report at http://bugs.php.net/?id=17506&edit=1
Bug #17506 Updated: --with-cli doesn't install built php binary with make install
ID: 17506 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: *Compile Issues Operating System: Linux Redhat 7.3 PHP Version: 4.2.1 New Comment: This bug has been fixed in CVS. You can grab a snapshot of the CVS version 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. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-05-29 09:15:34] [EMAIL PROTECTED] The Summary says it. After make install I manually have to copy sapi/cli/php to /usr/bin (or whereever). -- Edit this bug report at http://bugs.php.net/?id=17506&edit=1
Bug #17506: --with-cli doesn't install built php binary with make install
From: [EMAIL PROTECTED] Operating system: Linux Redhat 7.3 PHP version: 4.2.1 PHP Bug Type: *Compile Issues Bug description: --with-cli doesn't install built php binary with make install The Summary says it. After make install I manually have to copy sapi/cli/php to /usr/bin (or whereever). -- Edit bug report at http://bugs.php.net/?id=17506&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17506&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17506&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17506&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17506&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17506&r=support Expected behavior: http://bugs.php.net/fix.php?id=17506&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17506&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17506&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17506&r=globals
Bug #15511 Updated: readfile doesn't work correctly with WIndows XP
ID: 15511 Updated by: [EMAIL PROTECTED] -Summary: sablotron and php : segfault in Situation::generateMessage -Reported By: [EMAIL PROTECTED] +Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Sablotron XSL -Operating System: Linux mandrake 8.0 +Operating System: Windows XP (Professional) PHP Version: 4.1.1 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately your version of PHP is too old -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Previous Comments: [2002-02-11 15:02:09] [EMAIL PROTECTED] (this transcript originally posted to sablotron ml at address http://archive.gingerall.cz/archives/sablot/msg00252.html . they suggested me to post on php bugtracking too. An attached script was posted and it's available at the above address. This mail was transcripted here only for possible future reference. please contact me if you need more data) hi all... i'm using - apache 1.3.23 - php 4.1.1 - expat 1.95.2 - Sablotron 0.82 - Linux Mandrake 8.0 i'm tring to parse the xml/xsl files i provide as attachment. parsing them with sabcmd give me the correct output. Parsing it through apache lead to a brute connection closed that smells a lot of segfault. So i tried to track down the problem. I compiled php as cgi executable and tried to parse the php from gdb. this is the result (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/local/bin/php -f slashdot.php Program received signal SIGSEGV, Segmentation fault. 0x400d7765 in Situation::generateMessage (this=0x3e73746e, type=538976288, code=538976288, arg1=@0x20202020, arg2=@0x20202020, theMessage=@0x20202020) at situa.cpp:279 279 if (messenger && !(flags & SAB_NO_ERROR_REPORTING)) (gdb) good... stack corruption (gdb) bt #0 0x400d7765 in Situation::generateMessage (this=0x3e73746e, type=538976288, code=538976288, arg1=@0x20202020, arg2=@0x20202020, theMessage=@0x20202020) at situa.cpp:279 #1 0x656d6d6f in ?? () Cannot access memory at address 0x632f3c35 (gdb) please note that 0x656d6d6f is "emmo" which really seems "cOMMEnt" reversed. Also 0x632f3c35 is "c/<5" which is "5105". arg1 and arg2 are filled with spaces. as my file is (however, it crashes even without trailing spaces) If you need more data contact me. a few debug: (gdb) break *0x400d7cb8 Breakpoint 2 at 0x400d7cb8: file situa.cpp, line 350. (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/local/bin/php -f /usr/local/apache/htdocs/slashdot.php Breakpoint 2 at 0x400d7cb8 Breakpoint 2 at 0x400d7cb8: file situa.cpp, line 350. Breakpoint 2, Situation::message (this=0x81bc890, type=MT_LOG, code=L_START, arg1=@0xbfffdd10, arg2=@0xbfffdd20) at situa.cpp:350 350 if (code == E2_SDOM) (gdb) cont Continuing. Breakpoint 2, Situation::message (this=0x81bc890, type=MT_LOG, code=L1_PARSING, arg1=@0x81b3b88, arg2=@0xbfffda70) at situa.cpp:350 350 if (code == E2_SDOM) (gdb) n 357 if (type == MT_ERROR) (gdb) 361 Str temp; (gdb) 362 if (type == MT_ERROR) (gdb) 364 generateMessage(type, code, arg1, arg2, temp); (gdb) Program received signal SIGSEGV, Segmentation fault. 0x400d7765 in Situation::generateMessage (this=0x3e73746e, type=538976288, code=538976288, arg1=@0x20202020, arg2=@0x20202020, theMessage=@0x20202020) at situa.cpp:279 279 if (messenger && !(flags & SAB_NO_ERROR_REPORTING)) (gdb) --- (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/local/bin/php -f /usr/local/apache/htdocs/slashdot.php Breakpoint 2 at 0x400d7cb8 Breakpoint 2 at 0x400d7cb8: file situa.cpp, line 350. ciao Breakpoint 2, Situation::message (this=0x81bc890, type=MT_LOG, code=L_START, arg1=@0xbfffdd10, arg2=@0xbfffdd20) at situa.cpp:350 350 if (code == E2_SDOM) (gdb) cont Continuing. Breakpoint 2, Situation::message (this=0x81bc890, type=MT_LOG, code=L1_PARSING, arg1=@0x81b3b88, arg2=@0xbfffda70) at situa.cpp:350 350 if (code == E2_SDOM) (gdb) n 357 if (type == MT_ERROR) (gdb) 361 Str temp; (gdb) 362 if (type == MT_ERROR) (gdb) 364 generateMessage(type, code, arg1, arg2,
Bug #17280 Updated: readfile doesn't work correctly with WIndows XP
ID: 17280
Updated by: [EMAIL PROTECTED]
-Summary: FOPEN bug
-Reported By: [EMAIL PROTECTED]
+Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: *URL Functions
-Operating System: Freebsd 4.5
+Operating System: Windows XP (Professional)
-PHP Version: 4.2.0
+PHP Version: 4.1.1
New Comment:
This bug has been fixed in CVS. You can grab a snapshot of the
CVS version 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.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2002-05-16 18:51:27] [EMAIL PROTECTED]
Warning: fopen("http://www.google.com/search?q=test";, "r") - Message
too long in * on line 3
Error made by Fopen function... It was working before
--
Edit this bug report at http://bugs.php.net/?id=17280&edit=1
Bug #15862 Updated: readfile doesn't work correctly with WIndows XP
ID: 15862 Updated by: [EMAIL PROTECTED] -Summary: Reborn bug: "error is SSL: couldn't create a context!" -Reported By: [EMAIL PROTECTED] +Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: cURL related -Operating System: Freebsd 4.3 +Operating System: Windows XP (Professional) -PHP Version: 4.1.2 +PHP Version: 4.1.1 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately your version of PHP is too old -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Previous Comments: [2002-04-11 07:04:13] [EMAIL PROTECTED] Oops, I mistyped email address on last comment. Steve [2002-04-11 07:01:11] [EMAIL PROTECTED] The problem happens on Linux 2.4.15-pre8, PHP 4.1.2, CURL 7.8.1, openSSL 0.9.6 For me the problem is on a commercial hosted site so I can't recompile or change anything. If you are able to recompile and install things, try getting the latest cURL source release, (7.9.5 as of today). If it still happens with that version of CURL, then add some debug-printf statements into curl/lib/ssluse.c before the call to SSL_CTX_new(req_method) to see what value of req_method is being passed. The context error string is printed out right after this function call. Steve [2002-03-04 13:46:54] [EMAIL PROTECTED] When attempting to use cURL over https, php returns the error: "SSL: couldn't create a context!" Command-line operation in cURL works without error. A similar situation was reported, and reportedly fixed, in 4.1.1 CVS, but it has re-appeared in 4.1.2 release. The earlier problem was apparently related to compiling SSL into both PHP and cURL; I re-complied PHP without SSL but the problem persists. Any work-arounds will be greatly appreciated. -- Matt Daly ./configure --with-apxs=/usr/local/sbin/apxs --with-curl --with-config-file-path=/usr/local/etc --enable-versioning --with-system-regex --disable-debug --enable-track-vars --with-gd=/usr/local --with-ttf=/usr/local --with-zlib --with-mcrypt=/usr/local --with-mhash=/usr/local --with-mysql=/usr/local --with-xml=/usr/local --enable-ftp --with-gettext=/usr/local --enable-sockets --enable-trans-sid --prefix=/usr/local -- Edit this bug report at http://bugs.php.net/?id=15862&edit=1
Bug #13338 Updated: readfile doesn't work correctly with WIndows XP
ID: 13338 Updated by: [EMAIL PROTECTED] -Summary: PATH_TRANSLATED variable incorrectly set in v4.0.5 -Reported By: [EMAIL PROTECTED] +Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Unknown/Other Function -Operating System: Linux +Operating System: Windows XP (Professional) -PHP Version: 4.0.5 +PHP Version: 4.1.1 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately your version of PHP is too old -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Previous Comments: [2001-11-28 07:59:08] [EMAIL PROTECTED] Yes, the problem still exists: URL: http://luna.int.hq.jobpilot:8000/test.phtml/bla/fasel PHP Version: 4.1.0RC3 Zend Version: 1.1.0 PATH_TRANSLATED: /JobsAdverts/OnlineServer/web/de/bla/fasel Regards, Arno [2001-11-21 18:47:04] [EMAIL PROTECTED] Can you try latest RC and see if the problem still exists http://www.php.net/~zeev/php-4.1.0RC3.tar.gz Feedback. [2001-09-17 05:32:43] [EMAIL PROTECTED] Hi, between version 4.0.4 and 4.0.5 the setting of the PATH_TRANSLATED variable changed. In version 4.0.4, the following URL http://www1.jobpilot.de/test.phtml/bla/fasel resulted in the following PATH_TRANSLATED value: /JobsAdverts/OnlineServer/web/de/test.phtml (which is the correct script file name). in 4.0.5, the same URL results in the following value: /JobsAdverts/OnlineServer/web/de/bla/fasel which does not look right. According to the documentation, PATH_TRANSLATED is the "Filesystem- (not document root-) based path to the current script, after the server has done any virtual-to-real mapping. " BTW. the documentation should make it clear what is the difference between PATH_TRANSLATED and SCRIPT_FILENAME - from to the current explanation, I don't understand it. BTW we are using Apache 1.3.12. Best Regards, Arno Schaefer -- Edit this bug report at http://bugs.php.net/?id=13338&edit=1
Bug #17505: Output\warning reports sequence problem
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.5 PHP version: 4.2.1 PHP Bug Type: Scripting Engine problem Bug description: Output\warning reports sequence problem Warning reports (Then executing queries to MySQL) come to output ,before earlier placed "echo" directive. Produces X-Powered-By: PHP/4.1.2 Content-type: text/html PHP Warning: Supplied argument is not a valid MySQL-Link resource in . . test after 'test' message order of messages/echos seems to be restored to expected. Same problem in php 4.1.2 -- Edit bug report at http://bugs.php.net/?id=17505&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17505&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17505&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17505&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17505&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17505&r=support Expected behavior: http://bugs.php.net/fix.php?id=17505&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17505&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17505&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17505&r=globals
Bug #17504 Updated: Returning all email addresses found in a string with preg_match_all
ID: 17504
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Feedback
Bug Type: Documentation problem
Operating System: Linux
PHP Version: 4.2.1
New Comment:
What do you want us to do with this?
Previous Comments:
[2002-05-29 06:15:39] [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-05-29 05:49:15] [EMAIL PROTECTED]
This code searches a string and returns all the email addresses in it.
preg_match_all("(([a-z0-9_]|\\-|\\.)+@(([a-z0-9_]|\\-)+\\.)+[a-z]{2,4})",$StringToSearch,$matches);
for ($b=0; $b";
}
-toby
--
Edit this bug report at http://bugs.php.net/?id=17504&edit=1
Bug #17504 Updated: Returning all email addresses found in a string with preg_match_all
ID: 17504
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Documentation problem
Operating System: Linux
PHP Version: 4.2.1
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-05-29 05:49:15] [EMAIL PROTECTED]
This code searches a string and returns all the email addresses in it.
preg_match_all("(([a-z0-9_]|\\-|\\.)+@(([a-z0-9_]|\\-)+\\.)+[a-z]{2,4})",$StringToSearch,$matches);
for ($b=0; $b";
}
-toby
--
Edit this bug report at http://bugs.php.net/?id=17504&edit=1
Bug #17504: Returning all email addresses found in a string with preg_match_all
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.2.1
PHP Bug Type: Documentation problem
Bug description: Returning all email addresses found in a string with preg_match_all
This code searches a string and returns all the email addresses in it.
preg_match_all("(([a-z0-9_]|\\-|\\.)+@(([a-z0-9_]|\\-)+\\.)+[a-z]{2,4})",$StringToSearch,$matches);
for ($b=0; $b";
}
-toby
--
Edit bug report at http://bugs.php.net/?id=17504&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17504&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17504&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17504&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17504&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17504&r=support
Expected behavior: http://bugs.php.net/fix.php?id=17504&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17504&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17504&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17504&r=globals
Bug #17340 Updated: sscanf function requires "call by reference"
ID: 17340 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Strings related Operating System: Windows 2000 PHP Version: 4.2.1 New Comment: Can you not just try executing the "functions.php" script and you'll see the error. My PHP knowledge is somewhat limited, and the code is something I had run a while back just fine, and when I tried again I got this error. Basically, if call by reference is allowed for sscanf, as the php.net online documentation states, then the compiler is wrong. Otherwise the the documentation is now wrong, and the compiler should be more intelligent and not try to tell me to "modify the declaration of >sscanf()". Previous Comments: [2002-05-27 12:49:01] [EMAIL PROTECTED] Hm, can you make a simpler sample script? Just a couple of lines instead of a couple of files? [2002-05-23 04:14:24] [EMAIL PROTECTED] I have e-mailed you the code - the function is called within functions.php You're probably right, in that the code is now wrong, but if that's the case, then the online documentation for sscanf is also wrong. [2002-05-22 03:08:00] [EMAIL PROTECTED] I think you're doing something wrong... can you provide a simple & self-contained sample script? [2002-05-21 14:36:24] [EMAIL PROTECTED] When using the sscanf function, the complier warns that "Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of sscanf()" etc etc Apparently, sscanf requires the use of call-by reference to work - or is the online manual wrong? -- Edit this bug report at http://bugs.php.net/?id=17340&edit=1
Bug #17503 Updated: imap_mail_compose disposition.type problem
ID: 17503
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: IMAP related
Operating System: SuSE Linux 7.2
PHP Version: 4.2.1
New Comment:
This bug has been fixed in CVS. You can grab a snapshot of the
CVS version 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.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2002-05-29 04:34:32] [EMAIL PROTECTED]
Accoring to
http://www.php.net/manual/en/function.imap-mail-compose.php:
If I want to add a "Content-disposition" line to an attachment, I
should do something
like this:
$part['disposition.type'] = 'attachment';
$part['disposition'] = array ('filename'=>'file.txt');
But this does not work.
So I looked in the source, file ext/imap/php_imap.c, line 2998:
if (zend_hash_find(Z_ARRVAL_PP(data), "Z_TYPE(disposition)",
sizeof("Z_TYPE(disposition)"), (void **) &pvalue)== SUCCESS) {
... and tried a work-around:
$part['Z_TYPE(disposition)'] = 'attachment';
$part['disposition'] = array ('filename'=>'file.txt');
... which works fine.
Cound someone please repair the source or the Manual page?
--
Edit this bug report at http://bugs.php.net/?id=17503&edit=1
Bug #17503: imap_mail_compose disposition.type problem
From: [EMAIL PROTECTED]
Operating system: SuSE Linux 7.2
PHP version: 4.2.1
PHP Bug Type: IMAP related
Bug description: imap_mail_compose disposition.type problem
Accoring to http://www.php.net/manual/en/function.imap-mail-compose.php:
If I want to add a "Content-disposition" line to an attachment, I should
do something
like this:
$part['disposition.type'] = 'attachment';
$part['disposition'] = array ('filename'=>'file.txt');
But this does not work.
So I looked in the source, file ext/imap/php_imap.c, line 2998:
if (zend_hash_find(Z_ARRVAL_PP(data), "Z_TYPE(disposition)",
sizeof("Z_TYPE(disposition)"), (void **) &pvalue)== SUCCESS) {
... and tried a work-around:
$part['Z_TYPE(disposition)'] = 'attachment';
$part['disposition'] = array ('filename'=>'file.txt');
... which works fine.
Cound someone please repair the source or the Manual page?
--
Edit bug report at http://bugs.php.net/?id=17503&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17503&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17503&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17503&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17503&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17503&r=support
Expected behavior: http://bugs.php.net/fix.php?id=17503&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17503&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17503&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17503&r=globals
Bug #17502 Updated: trying to start service
ID: 17502 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows 2000 PHP Version: 4.2.1 New Comment: I think that it's a bug of PHP in the command "exec". Elena Previous Comments: [2002-05-29 04:27:36] [EMAIL PROTECTED] Sorry, but the bug system is not the appropriate forum for asking support questions. 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 Thank you for your interest in PHP. [2002-05-29 04:26:34] [EMAIL PROTECTED] Hello , I trying to start service Alerter on my machine. I am running command "net start Alerter" from my php script. For example: "> I receive "Access is denied. X-Powered-By: PHP/4.1.2 Content-type: text/html ">" What is a problem? Running "> doesn't cause a problem. Thanks, Elena. -- Edit this bug report at http://bugs.php.net/?id=17502&edit=1
Bug #17502 Updated: trying to start service
ID: 17502 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Windows 2000 PHP Version: 4.2.1 New Comment: Sorry, but the bug system is not the appropriate forum for asking support questions. 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 Thank you for your interest in PHP. Previous Comments: [2002-05-29 04:26:34] [EMAIL PROTECTED] Hello , I trying to start service Alerter on my machine. I am running command "net start Alerter" from my php script. For example: "> I receive "Access is denied. X-Powered-By: PHP/4.1.2 Content-type: text/html ">" What is a problem? Running "> doesn't cause a problem. Thanks, Elena. -- Edit this bug report at http://bugs.php.net/?id=17502&edit=1
Bug #17502: trying to start service
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.2.1 PHP Bug Type: Unknown/Other Function Bug description: trying to start service Hello , I trying to start service Alerter on my machine. I am running command "net start Alerter" from my php script. For example: "> I receive "Access is denied. X-Powered-By: PHP/4.1.2 Content-type: text/html ">" What is a problem? Running "> doesn't cause a problem. Thanks, Elena. -- Edit bug report at http://bugs.php.net/?id=17502&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=17502&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=17502&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17502&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17502&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17502&r=support Expected behavior: http://bugs.php.net/fix.php?id=17502&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17502&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17502&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=17502&r=globals
Bug #16109 Updated: zlib.output_compression and generated pictures
ID: 16109 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Zlib Related Operating System: linux PHP Version: 4.1.2 New Comment: Here's a short reproducing example script. Since the two pictures on the php info page are "generated" (inline) the script is very short: Make sure your zlib.output_compression = On and you use Netscape Communicator 4.79 (Maybe the "bug" is in other Netscape version too but in 4.79 it is for sure). Roger Previous Comments: [2002-05-28 15:47:52] [EMAIL PROTECTED] Welcome to the twilight zone ... After a question from Roger Wetzel, I made a few more tests. It seems the problem is on the netscape side : I tested Netscape 7.0PR1 and the pictures are ok even with zlib.output_compression enabled ... Using my old Netscape 4.77 the problem remains even if the apache httpd.conf contains a KeepAlive set to Off or MaxRequestsPerChild set to 1 ... So it's should not be a keep-alive problem. What still is in question is that when using mod_gzip, the problem doesn't occur. So there is a workaround , either disable zlib.output_compression or use a decent mozilla/netscape. Patrick [2002-05-28 10:23:51] [EMAIL PROTECTED] When I look at http://www.php.net/manual/en/function.ini-set.php it says that the value can be set anywhere (PHP_INI_ALL). Yes, that true what it has no effect. The master value on my computer is "on" and when I set it "off" at the beginning of my script it has no effect (even if phpinfo() tells the local value is "off"). So all pictures I read out from my database are not shown (broken image) in Netscape. Why can't I switch it "off" in a particular script? Is it a problem with the headers (Content-Encoding)? I really would like to have it switched "on" to keep the data transfer as low as possible. But if my pictures aren't shown in Netscape it's of no use. Actually, where is the bug? In the zlib? In Netscape? Roger [2002-04-03 15:03:30] [EMAIL PROTECTED] Thanks a lot Sniper ! After a little digging, the only bug report 'related' to the problem discussed here seems bug #10905 which was closed because of no feed back. The strange point about what is happening is that pictures .png or .jpeg are already compressed, due to the format itself ... Also, if I use apache's mod_gzip to compress again the pictures, it works, and other non script generated pictures are ok too. Sounds weird. ;-) Patrick [2002-04-03 08:47:40] [EMAIL PROTECTED] If you can't find the number for the other bug report, leave the report open.. [2002-04-03 06:32:06] [EMAIL PROTECTED] I'm 100% sure there is a bugreport for this. I don't know the number, I can't find it anymore... 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/16109 -- Edit this bug report at http://bugs.php.net/?id=16109&edit=1
Bug #17501 Updated: receiving "access violaton error"
ID: 17501 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Windows 2000 PHP Version: 4.2.1 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-05-29 02:12:33] [EMAIL PROTECTED] Hello, I am working with php version 4.2.1 , IIS 5.0, Windows 2000. I configured my IIS server using php4isapi.dll. After number of refreshes I receive: "Php has encountered an Access Violation at 01010290E". Since that I have to restart my IIS server in order to continue a work. I saw the similar problem with php , version 4.0. I hoped that the upgrade to 4.2.1 will solve this problem, but it doesn't. This problem doesn't occure working with php.exe. If you have any work around to this problem or other version of php that doesn't have this problem, please send it to me. Thanks, Elena. -- Edit this bug report at http://bugs.php.net/?id=17501&edit=1
Bug #12184 Updated: PHP has encountered an Access Violation at 0129E68A
ID: 12184 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IIS related Operating System: Windows 2000 Server PHP Version: 4.0.6 New Comment: I received the same problem.I am working with php version 4.2.1 , IIS 5.0, Windows 2000. I configured my IIS server using php4isapi.dll. After number of refreshes I receive: "Php has encountered an Access Violation at 01010290E". Since that I have to restart my IIS server in order to continue a work. I saw the similar problem with php , version 4.0. I hoped that the upgrade to 4.2.1 will solve this problem, but it doesn't. This problem doesn't occure working with php.exe. Elena Previous Comments: [2002-05-26 00:08:26] [EMAIL PROTECTED] 1. Make sure "Cache applications" is ticked. It's when PHP gets unloaded that it has Access Violations. 2. Run iisreset.exe [2001-07-16 04:55:59] [EMAIL PROTECTED] I'm following this step " Under 'Home Directory', click on the 'Configuration' button. Add a new entry to the Application Mappings. Use the path to the php4isapi.dll as the Executable, supply .php as the extension, leave Method exclusions blank, and check the Script engine checkbox." and when I get "PHP has encountered an Access Violation at 0129E68A" in my Web browser -- Edit this bug report at http://bugs.php.net/?id=12184&edit=1
