#21381 [Opn->Bgs]: apache/gd/freetype/mod_perl
ID: 21381 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Apache related Operating System: RedHat 7.2 Kernel 2.4.19 PHP Version: 4.3.0 New Comment: Most likely a bug in perl. Reopen if you have proof that it is PHP's fault. Derick Previous Comments: [2003-01-03 01:33:10] [EMAIL PROTECTED] hi, if i compile php-4.3.0 with the builtin gd, pdflib 4.0.3, postgres support, freetype 2.0.3 as apache module, there is a problem with apache's mod_perl: now the perl GD library does not work any more, we get the error "libgd was not built with FreeType font support" although we compiled php with freetype support. if we install php WITHOUT gd, the mod_perl gd functions are working again fine. bug or what? :-) -- Edit this bug report at http://bugs.php.net/?id=21381&edit=1
#21333 [Com]: Nesting level too deep - recursive dependency?
ID: 21333 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: RedHat Linux 8.0 PHP Version: 4.3.0 New Comment: I'm seeing the same problem with a very similar config: RH8.0, php4-STABLE-200301020430 even running the command line tool gives this result, so I believe this is independent of the apache version: echo "" | ./php Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0 I did a make test and submitted it to QA. I hope this helps. Previous Comments: [2003-01-02 06:08:49] [EMAIL PROTECTED] Unfortunately I can not send the "make test" results because the company where I work has too much restrictive firewall rules (paranoid grade): Form upload limits, no pop3 clients, password protected proxy, ... All that I can currently tell you is that I have the same problem even with a much simpler PHP configuration: ./configure i386-redhat-linux \ --with-apxs2=/usr/sbin/apxs \ --with-config-file-path=/etc [2003-01-02 04:54:17] [EMAIL PROTECTED] Please run a "make test" after compiling PHP with "make" in the source directory and press "y" if it asks to send the information to the QA site. Derick [2003-01-02 04:47:34] [EMAIL PROTECTED] This error message appears on every script, even in this one: This is just as it looks at the end of ANY php page: "Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0" Environment: RedHat Linux8.0 Kernel 2.4.18-14 Apache 2.0.40 PHP 4.3.0 And this is how I compiled PHP: ./configure i386-redhat-linux \ --with-apxs2=/usr/sbin/apxs \ --with-config-file-path=/etc \ --with-gd \ --with-zlib \ --enable-ftp \ --with-mysql \ --with-informix=/opt/informix \ --enable-sockets -- Edit this bug report at http://bugs.php.net/?id=21333&edit=1
#21381 [Bgs]: apache/gd/freetype/mod_perl
ID: 21381 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache related Operating System: RedHat 7.2 Kernel 2.4.19 PHP Version: 4.3.0 New Comment: but mod_perl worked with gd before i installed php with gd support! i will report that issue to the perl bugzille, too. Previous Comments: [2003-01-03 02:09:22] [EMAIL PROTECTED] Most likely a bug in perl. Reopen if you have proof that it is PHP's fault. Derick [2003-01-03 01:33:10] [EMAIL PROTECTED] hi, if i compile php-4.3.0 with the builtin gd, pdflib 4.0.3, postgres support, freetype 2.0.3 as apache module, there is a problem with apache's mod_perl: now the perl GD library does not work any more, we get the error "libgd was not built with FreeType font support" although we compiled php with freetype support. if we install php WITHOUT gd, the mod_perl gd functions are working again fine. bug or what? :-) -- Edit this bug report at http://bugs.php.net/?id=21381&edit=1
#21151 [Com]: zlib and pcre as external modules don't work
ID: 21151 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Unknown/Other Function Operating System: Mandrake 9.0 PHP Version: 4.3.0RC4 New Comment: Oden, you're a modularization maniac ;-) Some extensions, like ftp, session, zlib and pcre should really remain in the PHP core, since: 1) they don't need extra libraries (try to install an RPM without libz.so ;-) 2) they are really small and don't add extra weigth to PHP 3) users need them and will complain if they're not installed by default (trust me on this one!) Jean-Michel Previous Comments: [2002-12-23 02:53:24] [EMAIL PROTECTED] Too many modules rely on zlib and pcre, the best thing would be to disallow them to be compiled as shared module. For now: just don't do it :) Derick [2002-12-22 19:18:39] [EMAIL PROTECTED] Hi. zlib and pcre won't build as external modules. Here's my configure line: ./configure \ --prefix=/usr \ --exec-prefix=/usr \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --datadir=/usr/share \ --sysconfdir=/etc \ --libdir=/usr/lib \ --includedir=/usr/include \ --infodir=/usr/share/info \ --mandir=/usr/share/man \ --with-apxs2=/usr/sbin/apxs \ --enable-force-cgi-redirect \ --enable-discard-path \ --enable-debug \ --with-layout=GNU \ --with-config-file-path=/etc \ --with-config-file-scan-dir=/etc/httpd/conf.d \ --with-pear=/usr/lib/php \ --enable-safe-mode \ --with-exec-dir=/usr/bin \ --enable-magic-quotes \ --disable-rpath \ --with-openssl=shared,/usr --with-zlib=shared,/usr --with-zlib-dir=/usr \ --enable-bcmath=shared \ --with-bz2=shared,/usr \ --enable-calendar=shared \ --without-cpdflib \ --with-jpeg-dir=/usr \ --with-tiff-dir=/usr \ --without-crack \ --with-ctype=shared \ --with-curl=shared,/usr \ --without-cyrus \ --without-db \ --enable-dba=shared,/usr \ --with-gdbm=shared,/usr \ --without-ndbm \ --without-db2 \ --without-db3 \ --with-db4=shared,/usr \ --without-dbm \ --with-cdb=shared,/usr \ --with-flatfile=shared \ --enable-dbase=shared \ --enable-dbx=shared,/usr \ --enable-dio=shared,/usr \ --with-dom=shared,/usr --with-zlib-dir=/usr --with-dom-xslt=shared,/usr --with-dom-exslt=shared,/usr \ --enable-exif=shared \ --without-fbsql \ --without-fdftk \ --enable-filepro=shared \ --without-fribidi \ --enable-ftp=shared \ --with-gd=shared --with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/usr --with-xpm-dir=/usr/X11R6/lib/ \ --with-ttf=/usr \ --with-freetype-dir=/usr \ --with-t1lib=/usr \ --enable-gd-native-ttf \ --with-gettext=shared,/usr \ --with-gmp=shared,/usr \ --without-hwapi \ --without-hyperwave \ --without-iconv \ --with-imap=shared,/usr \ --without-kerberos \ --with-imap-ssl=shared,/usr \ --without-informix \ --without-ingres \ --without-interbase \ --without-ircg \ --with-ircg-config=/dev/null \ --without-java \ --with-ldap=shared,/usr \ --enable-mbstring=shared \ --enable-mbregex=shared \ --without-mcal \ --with-mcrypt=shared,/usr \ --without-mcve \ --with-mhash=shared,/usr \ --enable-mime-magic=shared \ --with-ming=shared,/usr \ --with-mnogosearch=shared,/usr \ --without-msession \ --without-msql \ --without-mssql \ --with-mysql=shared,/usr --with-mysql-sock=/var/lib/mysql/mysql.sock --with-zlib-dir=/usr \ --with-ncurses=shared,/usr \ --without-oci8 \ --without-adabas \ --without-sapdb \ --without-solid \ --without-ibm-db2 \ --without-empress \ --without-empress-bcs \ --without-birdstep \ --without-custom-odbc \ --without-iodbc \ --without-esoob \ --with-unixODBC=shared,/usr \ --without-openlink \ --without-dbmaker \ --without-oracle \ --enable-overload=shared \ --without-ovrimos \ --disable-pcntl \ --without-pcre-regex \ --with-pcre-regex=shared,/usr \ --without-pdflib --with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/usr --with-tiff-dir=/usr \ --without-pfpro \ --with-pgsql=shared,/usr \ --enable-posix=shared \ --with-pspell=shared,/usr \ --without-qtdom \ --without-libedit \ --without-readline \ --with-recode=shared,/usr \ --enable-session=shared \ --without-mm \ --enable-shmop=shared \ --with-snmp=shared,/usr \ --enable-ucd-snmp-hack \ --enable-sockets=shared \ --with-regex=php \ --without-swf \ --without-sybase \ --with-sybase-ct
#21381 [Com]: apache/gd/freetype/mod_perl
ID: 21381 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache related Operating System: RedHat 7.2 Kernel 2.4.19 PHP Version: 4.3.0 New Comment: sorry, i forgot to say that ONLY mod_perl doesn't work anymore, the shell perl binary can use GD with even freetype support and does not exit with the error-message, that is produced by mod_perl. Previous Comments: [2003-01-03 02:25:15] [EMAIL PROTECTED] but mod_perl worked with gd before i installed php with gd support! i will report that issue to the perl bugzille, too. [2003-01-03 02:09:22] [EMAIL PROTECTED] Most likely a bug in perl. Reopen if you have proof that it is PHP's fault. Derick [2003-01-03 01:33:10] [EMAIL PROTECTED] hi, if i compile php-4.3.0 with the builtin gd, pdflib 4.0.3, postgres support, freetype 2.0.3 as apache module, there is a problem with apache's mod_perl: now the perl GD library does not work any more, we get the error "libgd was not built with FreeType font support" although we compiled php with freetype support. if we install php WITHOUT gd, the mod_perl gd functions are working again fine. bug or what? :-) -- Edit this bug report at http://bugs.php.net/?id=21381&edit=1
#21346 [Fbk->Opn]: Config fails: checking size of char
ID: 21346 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: OpenBSD 3.1-stable PHP Version: 4.3.0 New Comment: Taking --with-imagick off doesn't make any difference. The imagick module is available through pear at: http://pear.php.net/package-info.php?pacid=76 I've been using this configure line for several months with 4.3.0-dev, though I recently removed --with-vpopmail from it as I read it's been moved. That shouldn't have anything to do with this error though. Previous Comments: [2003-01-02 20:53:37] [EMAIL PROTECTED] If you do not use the --with-imagick (how did you get it btw?) does it compile properly? [2003-01-02 13:39:33] [EMAIL PROTECTED] This error seemed to appear with 4.3.0 final - I compiled a new version just a few days ago without seeing this error during configure: checking size of char... configure: error: cannot compute sizeof (char), 77 My configure command is: ./configure --with-apxs=/usr/sbin/apxs --with-mysql=/usr/local --with-pdflib --enable-exif --with-gd --with-jpeg-dir=/usr/local/bin --with-bz2 --with-zlib --with-openssl --with-gettext --with-ldap --with-mhash --disable-overload --enable-sockets --with-mcrypt --enable-sysvshm --enable-pcntl --with-config-file-path=/var/www/conf/php43/ --enable-mbstring --with-pear=/usr/local/lib/php --enable-bcmath --with-imagick -- Edit this bug report at http://bugs.php.net/?id=21346&edit=1
#21346 [Opn->Fbk]: Config fails: checking size of char
ID: 21346 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: OpenBSD 3.1-stable PHP Version: 4.3.0 New Comment: Please show us the relevant parts of config.log which show the failure of the char size test. Derick Previous Comments: [2003-01-03 03:05:28] [EMAIL PROTECTED] Taking --with-imagick off doesn't make any difference. The imagick module is available through pear at: http://pear.php.net/package-info.php?pacid=76 I've been using this configure line for several months with 4.3.0-dev, though I recently removed --with-vpopmail from it as I read it's been moved. That shouldn't have anything to do with this error though. [2003-01-02 20:53:37] [EMAIL PROTECTED] If you do not use the --with-imagick (how did you get it btw?) does it compile properly? [2003-01-02 13:39:33] [EMAIL PROTECTED] This error seemed to appear with 4.3.0 final - I compiled a new version just a few days ago without seeing this error during configure: checking size of char... configure: error: cannot compute sizeof (char), 77 My configure command is: ./configure --with-apxs=/usr/sbin/apxs --with-mysql=/usr/local --with-pdflib --enable-exif --with-gd --with-jpeg-dir=/usr/local/bin --with-bz2 --with-zlib --with-openssl --with-gettext --with-ldap --with-mhash --disable-overload --enable-sockets --with-mcrypt --enable-sysvshm --enable-pcntl --with-config-file-path=/var/www/conf/php43/ --enable-mbstring --with-pear=/usr/local/lib/php --enable-bcmath --with-imagick -- Edit this bug report at http://bugs.php.net/?id=21346&edit=1
#21384 [NEW]: windows 2000 server
From: [EMAIL PROTECTED] Operating system: windows 2000 server PHP version: 4.2.3 PHP Bug Type: IIS related Bug description: windows 2000 server My operating system is: Windows 2000 server; My php is: php-4.2.3-installer.exe; My mysql: mysql-3.23.42-win.zip; Php runs ok! But after installed the patch procedure of IIS, php can not connect to mysql. Can you tell me, how should I do? Thank you! -- Edit bug report at http://bugs.php.net/?id=21384&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21384&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21384&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21384&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21384&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21384&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21384&r=support Expected behavior: http://bugs.php.net/fix.php?id=21384&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21384&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21384&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21384&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21384&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21384&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21384&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21384&r=gnused
#21384 [Opn->Bgs]: windows 2000 server
ID: 21384 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: IIS related Operating System: windows 2000 server PHP Version: 4.2.3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Previous Comments: [2003-01-03 03:53:58] [EMAIL PROTECTED] My operating system is: Windows 2000 server; My php is: php-4.2.3-installer.exe; My mysql: mysql-3.23.42-win.zip; Php runs ok! But after installed the patch procedure of IIS, php can not connect to mysql. Can you tell me, how should I do? Thank you! -- Edit this bug report at http://bugs.php.net/?id=21384&edit=1
#21213 [Sus]: htmlspecialchars() misbehaviour
ID: 21213
User updated by: [EMAIL PROTECTED]
-Summary: invalid entities handling into set_attribute() and
set_content()
Reported By: [EMAIL PROTECTED]
Status: Suspended
Bug Type: DOM XML related
Operating System: All
PHP Version: 4.3.0RC4
New Comment:
Yes, i agree with you in this point, but it also means, that you should
provide a way to parse given text value and build NodeList of Text and
EntityReference nodes. libxml2 already have such function.
Previous Comments:
[2003-01-01 14:59:56] [EMAIL PROTECTED]
Hi
I will most certainly not add this options, since i prefer to stick to
the w3c standard at
http://www.zvon.org/xxl/DOM2reference/Output/interfaces/Element.html#setAttribute
And in my interpretation of this, php's domxml behaves correctly. The
only thing missing is setAttributeNode, which I maybe will implement,
if I find some time.
If there is setAttributeNode, then you can use the way the w3c
suggests.
chregu
[2002-12-27 10:05:50] [EMAIL PROTECTED]
Please take a look at following example:
');
$root = $xml->root();
$value = $root->set_attribute('a','a&b');
$value = $root->set_content('a&b');
echo $xml->dump_mem();
?>
It produces following results:
a&b
As you may see - & entity is treated as literals when it is being
set as attribute value while same entity is treated as entity reference
being set as node value.
I have checked PHP's DOMXML extension source, libxml2 sources and
discuss about this behaviour with Daniel Viellard (libxml2 maintainer)
and with some other people on public XML-related forums and here is
some information about this issue:
1. Such behaviour is not a libxml2 bug, it is expected behaviour.
Moreover it is more correct from a point of specifications.
2. There should be a way to access Attr DOM object as specified into
DOM Level 1 specification
3. There should be a way to control entites handling into passed
values.
As a way to go i want to propose you to add one additional argument to
set_attribute(), set_content() and maybe some other functions -
$options.
For now there will be 2 options:
XML_KEEP_ENTITIES - to treat all entities as entites and create them as
EntityReference DOM objects
XML_QUOTE_ENTITIES - to treat all entities as literals and hence quote
all special symbols in them (such as '&' char).
For compatibility reasons $options for set_attribute() may be set to
XML_QUOTE_ENTITIES as default value and $options for set_content() -
for XML_KEEP_ENTITIES.
Internally you probably should change xmlSetProp() call into
domxml_elem_set_attribute() to xmlNodeSetContentLen() when there is
$options=XML_KEEP_ENTITIES.
--
Edit this bug report at http://bugs.php.net/?id=21213&edit=1
#21213 [Sus]: invalid entities handling into set_attribute() and set_content()
ID: 21213
User updated by: [EMAIL PROTECTED]
-Summary: htmlspecialchars() misbehaviour
Reported By: [EMAIL PROTECTED]
Status: Suspended
Bug Type: DOM XML related
Operating System: All
PHP Version: 4.3.0RC4
New Comment:
Sorry for summary changing - its Mozilla bug :)
Previous Comments:
[2003-01-03 04:01:49] [EMAIL PROTECTED]
Yes, i agree with you in this point, but it also means, that you should
provide a way to parse given text value and build NodeList of Text and
EntityReference nodes. libxml2 already have such function.
[2003-01-01 14:59:56] [EMAIL PROTECTED]
Hi
I will most certainly not add this options, since i prefer to stick to
the w3c standard at
http://www.zvon.org/xxl/DOM2reference/Output/interfaces/Element.html#setAttribute
And in my interpretation of this, php's domxml behaves correctly. The
only thing missing is setAttributeNode, which I maybe will implement,
if I find some time.
If there is setAttributeNode, then you can use the way the w3c
suggests.
chregu
[2002-12-27 10:05:50] [EMAIL PROTECTED]
Please take a look at following example:
');
$root = $xml->root();
$value = $root->set_attribute('a','a&b');
$value = $root->set_content('a&b');
echo $xml->dump_mem();
?>
It produces following results:
a&b
As you may see - & entity is treated as literals when it is being
set as attribute value while same entity is treated as entity reference
being set as node value.
I have checked PHP's DOMXML extension source, libxml2 sources and
discuss about this behaviour with Daniel Viellard (libxml2 maintainer)
and with some other people on public XML-related forums and here is
some information about this issue:
1. Such behaviour is not a libxml2 bug, it is expected behaviour.
Moreover it is more correct from a point of specifications.
2. There should be a way to access Attr DOM object as specified into
DOM Level 1 specification
3. There should be a way to control entites handling into passed
values.
As a way to go i want to propose you to add one additional argument to
set_attribute(), set_content() and maybe some other functions -
$options.
For now there will be 2 options:
XML_KEEP_ENTITIES - to treat all entities as entites and create them as
EntityReference DOM objects
XML_QUOTE_ENTITIES - to treat all entities as literals and hence quote
all special symbols in them (such as '&' char).
For compatibility reasons $options for set_attribute() may be set to
XML_QUOTE_ENTITIES as default value and $options for set_content() -
for XML_KEEP_ENTITIES.
Internally you probably should change xmlSetProp() call into
domxml_elem_set_attribute() to xmlNodeSetContentLen() when there is
$options=XML_KEEP_ENTITIES.
--
Edit this bug report at http://bugs.php.net/?id=21213&edit=1
#16914 [Com]: Function zend_hash_index_update_or_next_insert crashes Tomcat.
ID: 16914 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Servlet related Operating System: SuSe Linux 7.3 PHP Version: 4.2.0 New Comment: Same problem with php-4.3.0 tomcat 4.1.18 sun jdk 1.4.1 php 4.3 do not compile with --with-servlet, I had to fix the makefile, opened another bug few days ago (http://bugs.php.net/?id=21291&edit=2) Previous Comments: [2002-10-25 01:00:10] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-10-09 11:30:51] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-08-29 14:10:53] [EMAIL PROTECTED] Same on Linux 7.2 JVM 1.4.1 Tomcat 4.0.3 it seems something is definitively wrong with phpinfo().. Always crashes the server with an 11 signal (SEGMENTATION VIOLATION) Hope it will be checked ASAP [2002-04-29 14:48:53] [EMAIL PROTECTED] An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4c5e00f8 Function name=zend_hash_index_update_or_next_insert Library=/usr/local/lib/php/libphp4.so Current Java thread: at net.php.reflect.setResultFromObject(Native Method) at net.php.reflect.setResult(reflect.java:105) at net.php.servlet.readCookies(servlet.java:92) at net.php.servlet.send(Native Method) at net.php.servlet.service(servlet.java:188) at net.php.servlet.service(servlet.java:212) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java) at org.apache.tomcat.core.Handler.service(Handler.java) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java) at org.apache.tomcat.core.ContextManager.service(ContextManager.java) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java) at java.lang.Thread.run(Thread.java:479) Dynamic libraries: 08048000-0804c000 r-xp 03:02 131867 /usr/local/jdk1.3.1/bin/i386/native_threads/java 0804c000-0804d000 rw-p 3000 03:02 131867 /usr/local/jdk1.3.1/bin/i386/native_threads/java 4000-40014000 r-xp 03:02 357650 /lib/ld-2.2.4.so 40014000-40015000 rw-p 00013000 03:02 357650 /lib/ld-2.2.4.so 40016000-40017000 r--p 03:02 601481 /usr/lib/locale/en_US/LC_IDENTIFICATION 40017000-40018000 r--p 03:02 650279 /usr/lib/locale/en_US/LC_MEASUREMENT 40018000-40019000 r--p 03:02 260134 /usr/lib/locale/en_US/LC_TELEPHONE 40019000-4001a000 r--p 03:02 260129 /usr/lib/locale/en_US/LC_ADDRESS 4001a000-4001b000 r--p 03:02 260133 /usr/lib/locale/en_US/LC_NAME 4001b000-4001c000 r--p 03:02 812834 /usr/lib/locale/en_US/LC_PAPER 4001c000-4001d000 r--p 03:02 406419 /usr/lib/locale/en_US/LC_MESSAGES/SYS_LC_MESSAGES 4001d000-4001e000 r--p 03:02 650280 /usr/lib/locale/en_US/LC_MONETARY 4001e000-40024000 r--p 03:02 113833 /usr/lib/locale/en_US/LC_COLLATE 40024000-40025000 r--p 03:02 601482 /usr/lib/locale/en_US/LC_TIME 40025000-40026000 r--p 03:02 65067 /usr/lib/locale/en_US/LC_NUMERIC 40026000-40028000 r--s 03:02 180491 /opt/jakarta/lib/jaxp.jar 40028000-40036000 r-xp 03:02 357672 /lib/libpthread.so.0 40036000-4003e000 rw-p d000 03:02 357672 /lib/libpthread.so.0 4003e000-40047000 r-xp 03:02 604049 /usr/local/jdk1.3.1/jre/lib/i386/native_threads/libhpi.so 40047000-40048000 rw-p 8000 03:02 604049 /usr/local/jdk1.3.1/jre/lib/i386/native_threads/libhpi.so 40048000-403c8000 r-xp 03:02 961678 /usr/local/jdk1.3.1/jre/lib/i386/server/libjvm.so 403c8000-4051d000 rw-p 0037f000 03:02 961678 /usr/local/jdk1.3.1/jre/lib/i386/server/libjvm.so 40536000-40538000 r-xp 03:02 357660 /lib/libdl.so.2 40538000-4053a000 rw-p 1000 03:02 357660 /lib/libdl.so.2 4053a000-40655000 r-xp 03:02 357656 /lib/libc.so.6
#21346 [Fbk->Opn]: Config fails: checking size of char
ID: 21346
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Compile Failure
Operating System: OpenBSD 3.1-stable
PHP Version: 4.3.0
New Comment:
This appears to be the relevant section:
long longval () { return (long) (sizeof (char)); }
unsigned long ulongval () { return (long) (sizeof (char));
}
#include
#include
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
FILE *f = fopen ("conftest.val", "w");
if (! f)
exit (1);
if (((long) (sizeof (char))) < 0)
{
long i = longval ();
if (i != ((long) (sizeof (char
exit (1);
fprintf (f, "%ld\n", i);
}
else
{
unsigned long i = ulongval ();
if (i != ((long) (sizeof (char
exit (1);
fprintf (f, "%lu\n", i);
}
exit (ferror (f) || fclose (f) != 0);
;
return 0;
}
configure:58861: error: cannot compute sizeof (char), 77
Previous Comments:
[2003-01-03 03:09:01] [EMAIL PROTECTED]
Please show us the relevant parts of config.log which show the failure
of the char size test.
Derick
[2003-01-03 03:05:28] [EMAIL PROTECTED]
Taking --with-imagick off doesn't make any difference.
The imagick module is available through pear at:
http://pear.php.net/package-info.php?pacid=76
I've been using this configure line for several months with
4.3.0-dev, though I recently removed --with-vpopmail from
it as I read it's been moved. That shouldn't have anything
to do with this error though.
[2003-01-02 20:53:37] [EMAIL PROTECTED]
If you do not use the --with-imagick (how did you get it btw?) does it
compile properly?
[2003-01-02 13:39:33] [EMAIL PROTECTED]
This error seemed to appear with 4.3.0 final - I compiled a
new version just a few days ago without seeing this error
during configure:
checking size of char... configure: error: cannot compute
sizeof (char), 77
My configure command is:
./configure --with-apxs=/usr/sbin/apxs
--with-mysql=/usr/local --with-pdflib --enable-exif
--with-gd --with-jpeg-dir=/usr/local/bin --with-bz2
--with-zlib --with-openssl --with-gettext --with-ldap
--with-mhash --disable-overload --enable-sockets
--with-mcrypt --enable-sysvshm --enable-pcntl
--with-config-file-path=/var/www/conf/php43/
--enable-mbstring --with-pear=/usr/local/lib/php
--enable-bcmath --with-imagick
--
Edit this bug report at http://bugs.php.net/?id=21346&edit=1
#21346 [Opn->Fbk]: Config fails: checking size of char
ID: 21346
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Compile Failure
Operating System: OpenBSD 3.1-stable
PHP Version: 4.3.0
New Comment:
Can you include the 20 lines above this fragment too? It should give us
some more hints.
Derick
Previous Comments:
[2003-01-03 04:20:16] [EMAIL PROTECTED]
This appears to be the relevant section:
long longval () { return (long) (sizeof (char)); }
unsigned long ulongval () { return (long) (sizeof (char));
}
#include
#include
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
FILE *f = fopen ("conftest.val", "w");
if (! f)
exit (1);
if (((long) (sizeof (char))) < 0)
{
long i = longval ();
if (i != ((long) (sizeof (char
exit (1);
fprintf (f, "%ld\n", i);
}
else
{
unsigned long i = ulongval ();
if (i != ((long) (sizeof (char
exit (1);
fprintf (f, "%lu\n", i);
}
exit (ferror (f) || fclose (f) != 0);
;
return 0;
}
configure:58861: error: cannot compute sizeof (char), 77
[2003-01-03 03:09:01] [EMAIL PROTECTED]
Please show us the relevant parts of config.log which show the failure
of the char size test.
Derick
[2003-01-03 03:05:28] [EMAIL PROTECTED]
Taking --with-imagick off doesn't make any difference.
The imagick module is available through pear at:
http://pear.php.net/package-info.php?pacid=76
I've been using this configure line for several months with
4.3.0-dev, though I recently removed --with-vpopmail from
it as I read it's been moved. That shouldn't have anything
to do with this error though.
[2003-01-02 20:53:37] [EMAIL PROTECTED]
If you do not use the --with-imagick (how did you get it btw?) does it
compile properly?
[2003-01-02 13:39:33] [EMAIL PROTECTED]
This error seemed to appear with 4.3.0 final - I compiled a
new version just a few days ago without seeing this error
during configure:
checking size of char... configure: error: cannot compute
sizeof (char), 77
My configure command is:
./configure --with-apxs=/usr/sbin/apxs
--with-mysql=/usr/local --with-pdflib --enable-exif
--with-gd --with-jpeg-dir=/usr/local/bin --with-bz2
--with-zlib --with-openssl --with-gettext --with-ldap
--with-mhash --disable-overload --enable-sockets
--with-mcrypt --enable-sysvshm --enable-pcntl
--with-config-file-path=/var/www/conf/php43/
--enable-mbstring --with-pear=/usr/local/lib/php
--enable-bcmath --with-imagick
--
Edit this bug report at http://bugs.php.net/?id=21346&edit=1
#21346 [Fbk->Opn]: Config fails: checking size of char
ID: 21346
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Compile Failure
Operating System: OpenBSD 3.1-stable
PHP Version: 4.3.0
New Comment:
That was quick!
Here's a bit from above. The shared library message looks
suspicious - /usr/libexec/ld.so exists, as does
/usr/local/lib/libiconv.so.2.4. Could this be some kind of
compiler flag/path problem?
configure:58518: checking for char
configure:58545: gcc -c -g -O2 -DDEV_RANDOM=/dev/arandom
-DMOD_SSL=208108 -DEAPI -DUSE_EXPAT conftest.c >&5
configure:58548: $? = 0
configure:58551: test -s conftest.o
configure:58554: $? = 0
configure:58564: result: yes
configure:58567: checking size of char
configure:58845: gcc -o conftest -g -O2
-DDEV_RANDOM=/dev/arandom -DMOD_SSL=208108 -DEAPI
-DUSE_EXPAT -R/usr/local/lib -L/usr/local/lib conftest.c
-lmhash -lmcrypt -lltdl -lldap -llber -lintl -lpng -lz
-ljpeg -lbz2 -lz -lssl -lcrypto -lm >&5
configure:58848: $? = 0
configure:58850: ./conftest
/usr/libexec/ld.so: conftest: libiconv.so.2.4: No such file
or directory
configure:58853: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 58803 "configure"
#include "confdefs.h"
#include
#if HAVE_SYS_TYPES_H
# include
#endif
#if HAVE_SYS_STAT_H
# include
#endif
#if STDC_HEADERS
# include
# include
#else
# if HAVE_STDLIB_H
# include
# endif
#endif
#if HAVE_STRING_H
# if !STDC_HEADERS && HAVE_MEMORY_H
# include
# endif
# include
#endif
#if HAVE_STRINGS_H
# include
#endif
#if HAVE_INTTYPES_H
# include
#else
# if HAVE_STDINT_H
# include
# endif
#endif
#if HAVE_UNISTD_H
# include
#endif
Previous Comments:
[2003-01-03 04:21:10] [EMAIL PROTECTED]
Can you include the 20 lines above this fragment too? It should give us
some more hints.
Derick
[2003-01-03 04:20:16] [EMAIL PROTECTED]
This appears to be the relevant section:
long longval () { return (long) (sizeof (char)); }
unsigned long ulongval () { return (long) (sizeof (char));
}
#include
#include
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
FILE *f = fopen ("conftest.val", "w");
if (! f)
exit (1);
if (((long) (sizeof (char))) < 0)
{
long i = longval ();
if (i != ((long) (sizeof (char
exit (1);
fprintf (f, "%ld\n", i);
}
else
{
unsigned long i = ulongval ();
if (i != ((long) (sizeof (char
exit (1);
fprintf (f, "%lu\n", i);
}
exit (ferror (f) || fclose (f) != 0);
;
return 0;
}
configure:58861: error: cannot compute sizeof (char), 77
[2003-01-03 03:09:01] [EMAIL PROTECTED]
Please show us the relevant parts of config.log which show the failure
of the char size test.
Derick
[2003-01-03 03:05:28] [EMAIL PROTECTED]
Taking --with-imagick off doesn't make any difference.
The imagick module is available through pear at:
http://pear.php.net/package-info.php?pacid=76
I've been using this configure line for several months with
4.3.0-dev, though I recently removed --with-vpopmail from
it as I read it's been moved. That shouldn't have anything
to do with this error though.
[2003-01-02 20:53:37] [EMAIL PROTECTED]
If you do not use the --with-imagick (how did you get it btw?) does it
compile properly?
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/21346
--
Edit this bug report at http://bugs.php.net/?id=21346&edit=1
#21346 [Opn->Fbk]: Config fails: checking size of char
ID: 21346
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Compile Failure
Operating System: OpenBSD 3.1-stable
PHP Version: 4.3.0
New Comment:
Can you check if both are in your PATH and if that path is listed in
/etc/ld.so.conf? You might also want to run 'ldconfig'.
Previous Comments:
[2003-01-03 04:26:21] [EMAIL PROTECTED]
That was quick!
Here's a bit from above. The shared library message looks
suspicious - /usr/libexec/ld.so exists, as does
/usr/local/lib/libiconv.so.2.4. Could this be some kind of
compiler flag/path problem?
configure:58518: checking for char
configure:58545: gcc -c -g -O2 -DDEV_RANDOM=/dev/arandom
-DMOD_SSL=208108 -DEAPI -DUSE_EXPAT conftest.c >&5
configure:58548: $? = 0
configure:58551: test -s conftest.o
configure:58554: $? = 0
configure:58564: result: yes
configure:58567: checking size of char
configure:58845: gcc -o conftest -g -O2
-DDEV_RANDOM=/dev/arandom -DMOD_SSL=208108 -DEAPI
-DUSE_EXPAT -R/usr/local/lib -L/usr/local/lib conftest.c
-lmhash -lmcrypt -lltdl -lldap -llber -lintl -lpng -lz
-ljpeg -lbz2 -lz -lssl -lcrypto -lm >&5
configure:58848: $? = 0
configure:58850: ./conftest
/usr/libexec/ld.so: conftest: libiconv.so.2.4: No such file
or directory
configure:58853: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 58803 "configure"
#include "confdefs.h"
#include
#if HAVE_SYS_TYPES_H
# include
#endif
#if HAVE_SYS_STAT_H
# include
#endif
#if STDC_HEADERS
# include
# include
#else
# if HAVE_STDLIB_H
# include
# endif
#endif
#if HAVE_STRING_H
# if !STDC_HEADERS && HAVE_MEMORY_H
# include
# endif
# include
#endif
#if HAVE_STRINGS_H
# include
#endif
#if HAVE_INTTYPES_H
# include
#else
# if HAVE_STDINT_H
# include
# endif
#endif
#if HAVE_UNISTD_H
# include
#endif
[2003-01-03 04:21:10] [EMAIL PROTECTED]
Can you include the 20 lines above this fragment too? It should give us
some more hints.
Derick
[2003-01-03 04:20:16] [EMAIL PROTECTED]
This appears to be the relevant section:
long longval () { return (long) (sizeof (char)); }
unsigned long ulongval () { return (long) (sizeof (char));
}
#include
#include
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
FILE *f = fopen ("conftest.val", "w");
if (! f)
exit (1);
if (((long) (sizeof (char))) < 0)
{
long i = longval ();
if (i != ((long) (sizeof (char
exit (1);
fprintf (f, "%ld\n", i);
}
else
{
unsigned long i = ulongval ();
if (i != ((long) (sizeof (char
exit (1);
fprintf (f, "%lu\n", i);
}
exit (ferror (f) || fclose (f) != 0);
;
return 0;
}
configure:58861: error: cannot compute sizeof (char), 77
[2003-01-03 03:09:01] [EMAIL PROTECTED]
Please show us the relevant parts of config.log which show the failure
of the char size test.
Derick
[2003-01-03 03:05:28] [EMAIL PROTECTED]
Taking --with-imagick off doesn't make any difference.
The imagick module is available through pear at:
http://pear.php.net/package-info.php?pacid=76
I've been using this configure line for several months with
4.3.0-dev, though I recently removed --with-vpopmail from
it as I read it's been moved. That shouldn't have anything
to do with this error though.
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/21346
--
Edit this bug report at http://bugs.php.net/?id=21346&edit=1
#21311 [Com]: strip_tags strips everything after
ID: 21311 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Strings related Operating System: WinXP PHP Version: 4.3.0 New Comment: Was this fixed in the 4.4 or in 4.3? Previous Comments: [2002-12-31 09:19:16] [EMAIL PROTECTED] Fixed in CVS [2002-12-31 07:32:40] [EMAIL PROTECTED] $str1 = "Hello World."; $str1 = strip_tags($str1); After this $str1 contains only 'Hello' and not 'Hello World.' -- Edit this bug report at http://bugs.php.net/?id=21311&edit=1
#21311 [Csd]: strip_tags strips everything after
ID: 21311 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Strings related Operating System: WinXP PHP Version: 4.3.0 New Comment: Trick questions: When was PHP 4.3.0 released? When did you report this bug? Previous Comments: [2003-01-03 04:32:48] [EMAIL PROTECTED] Was this fixed in the 4.4 or in 4.3? [2002-12-31 09:19:16] [EMAIL PROTECTED] Fixed in CVS [2002-12-31 07:32:40] [EMAIL PROTECTED] $str1 = "Hello World."; $str1 = strip_tags($str1); After this $str1 contains only 'Hello' and not 'Hello World.' -- Edit this bug report at http://bugs.php.net/?id=21311&edit=1
#21346 [Fbk->Opn]: Config fails: checking size of char
ID: 21346
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Compile Failure
Operating System: OpenBSD 3.1-stable
PHP Version: 4.3.0
New Comment:
There are no library directories listed in my path (nor
have there ever been, IIRC); I don't have an
/etc/ld.so.conf at all; ldconfig runs with no errors, but
makes no difference.
Hm. I just got a similar error when trying to use something
else that accessed a different shared library. Looks more
like it's a config problem at my end, though I have no idea
why this should suddenly have started happening.
Previous Comments:
[2003-01-03 04:28:48] [EMAIL PROTECTED]
Can you check if both are in your PATH and if that path is listed in
/etc/ld.so.conf? You might also want to run 'ldconfig'.
[2003-01-03 04:26:21] [EMAIL PROTECTED]
That was quick!
Here's a bit from above. The shared library message looks
suspicious - /usr/libexec/ld.so exists, as does
/usr/local/lib/libiconv.so.2.4. Could this be some kind of
compiler flag/path problem?
configure:58518: checking for char
configure:58545: gcc -c -g -O2 -DDEV_RANDOM=/dev/arandom
-DMOD_SSL=208108 -DEAPI -DUSE_EXPAT conftest.c >&5
configure:58548: $? = 0
configure:58551: test -s conftest.o
configure:58554: $? = 0
configure:58564: result: yes
configure:58567: checking size of char
configure:58845: gcc -o conftest -g -O2
-DDEV_RANDOM=/dev/arandom -DMOD_SSL=208108 -DEAPI
-DUSE_EXPAT -R/usr/local/lib -L/usr/local/lib conftest.c
-lmhash -lmcrypt -lltdl -lldap -llber -lintl -lpng -lz
-ljpeg -lbz2 -lz -lssl -lcrypto -lm >&5
configure:58848: $? = 0
configure:58850: ./conftest
/usr/libexec/ld.so: conftest: libiconv.so.2.4: No such file
or directory
configure:58853: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 58803 "configure"
#include "confdefs.h"
#include
#if HAVE_SYS_TYPES_H
# include
#endif
#if HAVE_SYS_STAT_H
# include
#endif
#if STDC_HEADERS
# include
# include
#else
# if HAVE_STDLIB_H
# include
# endif
#endif
#if HAVE_STRING_H
# if !STDC_HEADERS && HAVE_MEMORY_H
# include
# endif
# include
#endif
#if HAVE_STRINGS_H
# include
#endif
#if HAVE_INTTYPES_H
# include
#else
# if HAVE_STDINT_H
# include
# endif
#endif
#if HAVE_UNISTD_H
# include
#endif
[2003-01-03 04:21:10] [EMAIL PROTECTED]
Can you include the 20 lines above this fragment too? It should give us
some more hints.
Derick
[2003-01-03 04:20:16] [EMAIL PROTECTED]
This appears to be the relevant section:
long longval () { return (long) (sizeof (char)); }
unsigned long ulongval () { return (long) (sizeof (char));
}
#include
#include
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
FILE *f = fopen ("conftest.val", "w");
if (! f)
exit (1);
if (((long) (sizeof (char))) < 0)
{
long i = longval ();
if (i != ((long) (sizeof (char
exit (1);
fprintf (f, "%ld\n", i);
}
else
{
unsigned long i = ulongval ();
if (i != ((long) (sizeof (char
exit (1);
fprintf (f, "%lu\n", i);
}
exit (ferror (f) || fclose (f) != 0);
;
return 0;
}
configure:58861: error: cannot compute sizeof (char), 77
[2003-01-03 03:09:01] [EMAIL PROTECTED]
Please show us the relevant parts of config.log which show the failure
of the char size test.
Derick
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/21346
--
Edit this bug report at http://bugs.php.net/?id=21346&edit=1
#21370 [Bgs]: FastCGI -b option doesn't work
ID: 21370 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Other web server Operating System: WinXP PHP Version: 4.3.0 New Comment: This bug has been resubmitted 6 times in total. PLEASE do not do this again!! Previous Comments: [2003-01-02 20:50:58] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. [2003-01-02 20:10:13] [EMAIL PROTECTED] I've downloaded the full Win32 PHP binary and the "-b" argument that should "Bind Path for external FASTCGI server mode" doesn't work. What happens is: c:\php>php -b 5000 Error in argument 1, char 2: option not found b Error in argument 1, char 2: option not found b Error in argument 1, char 2: option not found b I read on php.dev newsgroup that this is the right way to start FastCGI support since SAPI/FastCGI was discontinued. But it doesn't work. -- Edit this bug report at http://bugs.php.net/?id=21370&edit=1
#21267 [Csd->Opn]: fopen() fails on some URLs
ID: 21267
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: *URL Functions
Operating System: FreeBSD
-PHP Version: 4.3.0
+PHP Version: 4.4.0-dev
New Comment:
Tnx for the fast change, and it is almost working. But one thing still
doesn't:
When you open:
http://www.smswhiz.com/http2sms/sendsms.asp
You get a redirect to sendfailed.htm. The new URL to open should be:
http://www.smswhiz.com/http2sms/sendfailed.htm
and this site exists. But when I try it with PHP (with the latest
snapshot ofcourse), I get a 404, so I think it opens:
http://www.smswhiz.com/sendfailed.htm
I know, IIS 5.0 really sucks in those redirects, but can you maybe fix
this problem too? Tnx!
Previous Comments:
[2002-12-29 14:03:03] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2002-12-29 12:06:44] [EMAIL PROTECTED]
But can you tell me why in version 4.2.3 this works perfect?
[2002-12-29 10:05:47] [EMAIL PROTECTED]
That's because of the silly 302 temporary redirect to a relative URL
with GET-method args that is done on that site. Open the right
location and it should work fine. We probably should support this at
some point though.
[2002-12-29 09:44:51] [EMAIL PROTECTED]
When trying fopen() on http://, it fails on some urls.
Example:
fopen("http://www.smswhiz.com/","r";);
Gives stream error. The site IS touched, but you do not receive any
data back from the site.
While for example:
fopen("http://www.tweakers.net/","r";);
Does work without any problem!
--
Edit this bug report at http://bugs.php.net/?id=21267&edit=1
#21385 [NEW]: php execution stops during processing
From: [EMAIL PROTECTED] Operating system: solaris 2.6 PHP version: 4.3.0 PHP Bug Type: iPlanet related Bug description: php execution stops during processing We are working on Iplanet 6.0 SP2. Some of our php pages are doing complex statement on Oracle database, and then can take more than a minute. But as soon as nothing is sent back to php (or the webserver) in less than 10 seconds, the webserver stop to load the page. We have set the max_execution_time to 60, and nothing change. We have tested the same pages on apache, and everything runs fine. -- Edit bug report at http://bugs.php.net/?id=21385&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21385&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21385&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21385&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21385&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21385&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21385&r=support Expected behavior: http://bugs.php.net/fix.php?id=21385&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21385&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21385&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21385&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21385&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21385&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21385&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21385&r=gnused
#21386 [NEW]: Hebrew problem...
From: [EMAIL PROTECTED] Operating system: Win Nt PHP version: 4.3.0 PHP Bug Type: Unknown/Other Function Bug description: Hebrew problem... Hi, I'm from Israel and I have a problem with Hebrew + PHP. I am using the function PREG but one of the Hebrew letters, PHP doesn't recognize as a letter (The letter is "÷"). That makes the following problems: \b- if the letter start or finish a word PHP won't consider her. \w-PHP doesn't consider her as a letter and more I hope there is something to do about it. P.S Excuse me for any spelling problems, I don't write so good in English Thank you very much. Ido. -- Edit bug report at http://bugs.php.net/?id=21386&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21386&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21386&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21386&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21386&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21386&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21386&r=support Expected behavior: http://bugs.php.net/fix.php?id=21386&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21386&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21386&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21386&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21386&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21386&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21386&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21386&r=gnused
#21387 [NEW]: Some configuration directives in php.ini are ignored
From: [EMAIL PROTECTED] Operating system: MS Windows NT 5.1 (XP) PHP version: 4.3.0 PHP Bug Type: *Configuration Issues Bug description: Some configuration directives in php.ini are ignored After installing PHP 4.3.0, some configuration directives in php.ini are ignored (extension_dir, post_max_size, arg_separator.input, etc.) according to phpinfo() output. I have changed asp_tags On and Off (every time with restarting of IIS 5.1) to ensure PHP loads correct php.ini file and it does. In PHP 4.2.3 all configuration directives are taken into account. So, I think, it can be a bug. Stepan -- Edit bug report at http://bugs.php.net/?id=21387&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21387&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21387&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21387&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21387&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21387&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21387&r=support Expected behavior: http://bugs.php.net/fix.php?id=21387&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21387&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21387&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21387&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21387&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21387&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21387&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21387&r=gnused
#21311 [Com]: strip_tags strips everything after
ID: 21311 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Strings related Operating System: WinXP PHP Version: 4.3.0 New Comment: Oh, funny new year questions... >When was PHP 4.3.0 released? 27-Dec-2002 >When did you report this bug? 31-Dec-2002 - Download of latest Stable (4.3.x-dev) does not help. In which version from http://snaps.php.net, Stable (4.3.x-dev) or Latest CVS (4.4.x-dev), is it fixed? Please can somebody answer clearly? Thanks, Claudio Previous Comments: [2003-01-03 04:33:42] [EMAIL PROTECTED] Trick questions: When was PHP 4.3.0 released? When did you report this bug? [2003-01-03 04:32:48] [EMAIL PROTECTED] Was this fixed in the 4.4 or in 4.3? [2002-12-31 09:19:16] [EMAIL PROTECTED] Fixed in CVS [2002-12-31 07:32:40] [EMAIL PROTECTED] $str1 = "Hello World."; $str1 = strip_tags($str1); After this $str1 contains only 'Hello' and not 'Hello World.' -- Edit this bug report at http://bugs.php.net/?id=21311&edit=1
#21311 [Csd]: strip_tags strips everything after
ID: 21311 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Strings related Operating System: WinXP PHP Version: 4.3.0 New Comment: All fixes go to the development snapshot unless the commiter thinks his fix should go to the stable branch too, so it's only in 4.4.0-dev right now. Because I think it should also be in the branch (4.3.1-dev) I'm going to merge this fix; it should be in both the stable and dev snapshot when they are regenerated. Previous Comments: [2003-01-03 06:12:28] [EMAIL PROTECTED] Oh, funny new year questions... >When was PHP 4.3.0 released? 27-Dec-2002 >When did you report this bug? 31-Dec-2002 - Download of latest Stable (4.3.x-dev) does not help. In which version from http://snaps.php.net, Stable (4.3.x-dev) or Latest CVS (4.4.x-dev), is it fixed? Please can somebody answer clearly? Thanks, Claudio [2003-01-03 04:33:42] [EMAIL PROTECTED] Trick questions: When was PHP 4.3.0 released? When did you report this bug? [2003-01-03 04:32:48] [EMAIL PROTECTED] Was this fixed in the 4.4 or in 4.3? [2002-12-31 09:19:16] [EMAIL PROTECTED] Fixed in CVS [2002-12-31 07:32:40] [EMAIL PROTECTED] $str1 = "Hello World."; $str1 = strip_tags($str1); After this $str1 contains only 'Hello' and not 'Hello World.' -- Edit this bug report at http://bugs.php.net/?id=21311&edit=1
#21385 [Opn]: php execution stops during processing
ID: 21385 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: iPlanet related Operating System: solaris 2.6 PHP Version: 4.3.0 New Comment: Can you please give more details so we can try to reproduce the problem to verify it's really PHP related? Try to run the scripts from the CLI too if you can and backtrace. Thank you. Previous Comments: [2003-01-03 05:36:38] [EMAIL PROTECTED] We are working on Iplanet 6.0 SP2. Some of our php pages are doing complex statement on Oracle database, and then can take more than a minute. But as soon as nothing is sent back to php (or the webserver) in less than 10 seconds, the webserver stop to load the page. We have set the max_execution_time to 60, and nothing change. We have tested the same pages on apache, and everything runs fine. -- Edit this bug report at http://bugs.php.net/?id=21385&edit=1
#21389 [NEW]: preg_match crash after some calls
From: [EMAIL PROTECTED]
Operating system: Windows NT 4 sp6a french
PHP version: 4.3.0
PHP Bug Type: Reproducible crash
Bug description: preg_match crash after some calls
PHP WIN32 4.3.0 + APACHE 2.2.43 + WINNT 4 SP6A FR
Does a DrWatson (Stack OverFlow)
The Script :
fichier_export = $_f_export;
$this->fichier_sql= $_f_sql;
$this->fichier_appel = $_f_appel;
$this->fichier_definition = $_f_def;
$this->debug = $_debug;
}
function trace($s) {
if ($this->debug) {
echo "==> Trace : $s <==";
flush;
}
}
/*
* Fonction extrait_sql : Extrait le code SQL d'une instruction PCode
SQLExec
* Parametre :
* $code : une instruction Pcode
*/
function extrait_sql(&$code) {
$this->trace("Avant extrait_sql");
$regs = array();
/*
* Matche la chaine sqlexec(" et récupère la chaine jusqu'a "
*/
$this->trace("$code");
/* === Crash Here ===*/
if (preg_match('/sqlexec\(\"(.*?)\"/i',$code,$regs)) {
echo "sql : $regs[1]";
}
$this->trace("Après extrait_sql");
}
/*
* Fonction extrait_fonction : Extrait le nom des fonction déclaré
* et utilisé dans une
liste d'instruction Pcode
* Parametres :
* $instruction : Liste des instructions Pcode
* $code: Instruction Pcode à analyser
*/
function extrait_fonction(&$instruction,&$code) {
$this->trace("Avant extrait_fonction");
/*
* Matche le declare et le peoplecode dans l'instruction à analyser
* et récupére le prototype de la fonction
*/
if (preg_match("/declare (.*) peoplecode (.*)/i",$code,$regs)) {
/*
* Match le mot clef function et recupere
* le nom de la fonction
*/
preg_match("/function (.*)\(/i",$regs[1],$nom);
/*
* Verifie pour chaque instruction si le nom précedement
trouvé
* est utilisé dans les instructions Pcode, en ignorant la
ligne de
déclaration
*/
foreach ($instruction as $key => $value) {
if (!preg_match("/declare (.*) peoplecode
(.*)/i",$value) &&
preg_match("/" . $nom[1] . "/i",$value)) {
$use = true;
break;
}
}
if ($use) {
echo "fct : $regs[2] => $regs[1] => $nom[1]";
}
}
$this->trace("Après extrait_fonction");
}
/*
* Fonction analyse_definition : analyse la définition d'une fonction
* Parametre :
* $definition : Liste d'instruction Pcode contenant la
definition de
fonction
*/
function analyse_definition (&$definition) {
$this->trace("Avant analyse_definition");
/*
* Macthe les mots clefs "declare fonction " et recupère le nom de
* la fonction analysée
*/
preg_match("/declare function (.*?) /i",$definition[0],$regs);
echo "fct : $regs[1]";
/*
* Extrait le SQL sur chaque instruction de la définition
*/
foreach($definition as $key => $val) {
$this->extrait_sql($val);
}
$this->trace("Après analyse_definition");
}
/*
* Fonction efface_commenataire : efface les commentaire du Pcode
* Parametre :
* $code : chaine de Pcode
*/
function efface_commentaire(&$code) {
$this->trace("Avant efface_commentaire");
/*
* Tant que les commentaire sont matché :
*/
while (preg_match("/(\/\*((.|\n)+?)\*\/)/i",$code,$reg)) {
/*
#21389 [Opn->Fbk]: preg_match crash after some calls
ID: 21389
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Windows NT 4 sp6a french
PHP Version: 4.3.0
New Comment:
Please strip your script down to the bare minimum and without the need
for external references so that "copy and paste" of the script shows
the crash. It's quite impossible to debug this for us right now.
Previous Comments:
[2003-01-03 06:46:12] [EMAIL PROTECTED]
PHP WIN32 4.3.0 + APACHE 2.2.43 + WINNT 4 SP6A FR
Does a DrWatson (Stack OverFlow)
The Script :
fichier_export = $_f_export;
$this->fichier_sql= $_f_sql;
$this->fichier_appel = $_f_appel;
$this->fichier_definition = $_f_def;
$this->debug = $_debug;
}
function trace($s) {
if ($this->debug) {
echo "==> Trace : $s <==";
flush;
}
}
/*
* Fonction extrait_sql : Extrait le code SQL d'une instruction PCode
SQLExec
* Parametre :
* $code : une instruction Pcode
*/
function extrait_sql(&$code) {
$this->trace("Avant extrait_sql");
$regs = array();
/*
* Matche la chaine sqlexec(" et récupère la chaine jusqu'a "
*/
$this->trace("$code");
/* === Crash Here ===*/
if (preg_match('/sqlexec\(\"(.*?)\"/i',$code,$regs)) {
echo "sql : $regs[1]";
}
$this->trace("Après extrait_sql");
}
/*
* Fonction extrait_fonction : Extrait le nom des fonction déclaré
* et utilisé dans une
liste d'instruction Pcode
* Parametres :
* $instruction : Liste des instructions Pcode
* $code: Instruction Pcode à analyser
*/
function extrait_fonction(&$instruction,&$code) {
$this->trace("Avant extrait_fonction");
/*
* Matche le declare et le peoplecode dans l'instruction à analyser
* et récupére le prototype de la fonction
*/
if (preg_match("/declare (.*) peoplecode (.*)/i",$code,$regs)) {
/*
* Match le mot clef function et recupere
* le nom de la fonction
*/
preg_match("/function (.*)\(/i",$regs[1],$nom);
/*
* Verifie pour chaque instruction si le nom précedement
trouvé
* est utilisé dans les instructions Pcode, en ignorant la
ligne de
déclaration
*/
foreach ($instruction as $key => $value) {
if (!preg_match("/declare (.*) peoplecode
(.*)/i",$value) &&
preg_match("/" . $nom[1] . "/i",$value)) {
$use = true;
break;
}
}
if ($use) {
echo "fct : $regs[2] => $regs[1] => $nom[1]";
}
}
$this->trace("Après extrait_fonction");
}
/*
* Fonction analyse_definition : analyse la définition d'une fonction
* Parametre :
* $definition : Liste d'instruction Pcode contenant la definition
de fonction
*/
function analyse_definition (&$definition) {
$this->trace("Avant analyse_definition");
/*
* Macthe les mots clefs "declare fonction " et recupère le nom de
* la fonction analysée
*/
preg_match("/declare function (.*?) /i",$definition[0],$regs);
echo "fct : $regs[1]";
/*
* Extrait le SQL sur chaque instruction de la définition
*/
foreach($definition as $key => $val) {
$this->extrait_sql($val);
}
$this->trace("Après analyse_definition");
}
/*
* Fonction efface_commenataire : efface les commentaire du Pcode
#21389 [Fbk->Opn]: preg_match crash after some calls
ID: 21389
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Windows NT 4 sp6a french
PHP Version: 4.3.0
New Comment:
function extrait_sql(&$code) {
$this->trace("Avant extrait_sql");
$regs = array();
/*
* Matche la chaine sqlexec(" et récupère la chaine jusqu'a "
*/
$this->trace("$code");
/* === Crash Here ===*/
if (preg_match('/sqlexec\(\"(.*?)\"/i',$code,$regs)) {
echo "sql : $regs[1]";
}
$this->trace("Après extrait_sql");
}
This function is crashing after about 300 calls.
It does a DrWatson (Stack Overflow).
Previous Comments:
[2003-01-03 06:47:48] [EMAIL PROTECTED]
Please strip your script down to the bare minimum and without the need
for external references so that "copy and paste" of the script shows
the crash. It's quite impossible to debug this for us right now.
[2003-01-03 06:46:12] [EMAIL PROTECTED]
PHP WIN32 4.3.0 + APACHE 2.2.43 + WINNT 4 SP6A FR
Does a DrWatson (Stack OverFlow)
The Script :
fichier_export = $_f_export;
$this->fichier_sql= $_f_sql;
$this->fichier_appel = $_f_appel;
$this->fichier_definition = $_f_def;
$this->debug = $_debug;
}
function trace($s) {
if ($this->debug) {
echo "==> Trace : $s <==";
flush;
}
}
/*
* Fonction extrait_sql : Extrait le code SQL d'une instruction PCode
SQLExec
* Parametre :
* $code : une instruction Pcode
*/
function extrait_sql(&$code) {
$this->trace("Avant extrait_sql");
$regs = array();
/*
* Matche la chaine sqlexec(" et récupère la chaine jusqu'a "
*/
$this->trace("$code");
/* === Crash Here ===*/
if (preg_match('/sqlexec\(\"(.*?)\"/i',$code,$regs)) {
echo "sql : $regs[1]";
}
$this->trace("Après extrait_sql");
}
/*
* Fonction extrait_fonction : Extrait le nom des fonction déclaré
* et utilisé dans une
liste d'instruction Pcode
* Parametres :
* $instruction : Liste des instructions Pcode
* $code: Instruction Pcode à analyser
*/
function extrait_fonction(&$instruction,&$code) {
$this->trace("Avant extrait_fonction");
/*
* Matche le declare et le peoplecode dans l'instruction à analyser
* et récupére le prototype de la fonction
*/
if (preg_match("/declare (.*) peoplecode (.*)/i",$code,$regs)) {
/*
* Match le mot clef function et recupere
* le nom de la fonction
*/
preg_match("/function (.*)\(/i",$regs[1],$nom);
/*
* Verifie pour chaque instruction si le nom précedement
trouvé
* est utilisé dans les instructions Pcode, en ignorant la
ligne de
déclaration
*/
foreach ($instruction as $key => $value) {
if (!preg_match("/declare (.*) peoplecode
(.*)/i",$value) &&
preg_match("/" . $nom[1] . "/i",$value)) {
$use = true;
break;
}
}
if ($use) {
echo "fct : $regs[2] => $regs[1] => $nom[1]";
}
}
$this->trace("Après extrait_fonction");
}
/*
* Fonction analyse_definition : analyse la définition d'une fonction
* Parametre :
* $definition : Liste d'instruction Pcode contenant la definition
de fonction
*/
function analyse_definition (&$definition) {
$this->trace("Avant analyse_definition");
/*
* Macthe les mots clefs "declare fonction " et recupère le nom de
* la fon
#21346 [Opn->Csd]: Config fails: checking size of char
ID: 21346
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Compile Failure
Operating System: OpenBSD 3.1-stable
PHP Version: 4.3.0
New Comment:
Managed to fix this - issuing a bare ldconfig makes it
forget all library directories except the system default
(/usr/lib). Issuing an ldconfig earlier had broken access
to libraries that configure needed. I can't seem to find
where the system sets up ldconfig at boot time - it's not
in any of my rc files - but I added /usr/local/lib manually
and it now works.
Whatever, bug closed, thanks for all your timely help.
Previous Comments:
[2003-01-03 04:46:56] [EMAIL PROTECTED]
There are no library directories listed in my path (nor
have there ever been, IIRC); I don't have an
/etc/ld.so.conf at all; ldconfig runs with no errors, but
makes no difference.
Hm. I just got a similar error when trying to use something
else that accessed a different shared library. Looks more
like it's a config problem at my end, though I have no idea
why this should suddenly have started happening.
[2003-01-03 04:28:48] [EMAIL PROTECTED]
Can you check if both are in your PATH and if that path is listed in
/etc/ld.so.conf? You might also want to run 'ldconfig'.
[2003-01-03 04:26:21] [EMAIL PROTECTED]
That was quick!
Here's a bit from above. The shared library message looks
suspicious - /usr/libexec/ld.so exists, as does
/usr/local/lib/libiconv.so.2.4. Could this be some kind of
compiler flag/path problem?
configure:58518: checking for char
configure:58545: gcc -c -g -O2 -DDEV_RANDOM=/dev/arandom
-DMOD_SSL=208108 -DEAPI -DUSE_EXPAT conftest.c >&5
configure:58548: $? = 0
configure:58551: test -s conftest.o
configure:58554: $? = 0
configure:58564: result: yes
configure:58567: checking size of char
configure:58845: gcc -o conftest -g -O2
-DDEV_RANDOM=/dev/arandom -DMOD_SSL=208108 -DEAPI
-DUSE_EXPAT -R/usr/local/lib -L/usr/local/lib conftest.c
-lmhash -lmcrypt -lltdl -lldap -llber -lintl -lpng -lz
-ljpeg -lbz2 -lz -lssl -lcrypto -lm >&5
configure:58848: $? = 0
configure:58850: ./conftest
/usr/libexec/ld.so: conftest: libiconv.so.2.4: No such file
or directory
configure:58853: $? = 1
configure: program exited with status 1
configure: failed program was:
#line 58803 "configure"
#include "confdefs.h"
#include
#if HAVE_SYS_TYPES_H
# include
#endif
#if HAVE_SYS_STAT_H
# include
#endif
#if STDC_HEADERS
# include
# include
#else
# if HAVE_STDLIB_H
# include
# endif
#endif
#if HAVE_STRING_H
# if !STDC_HEADERS && HAVE_MEMORY_H
# include
# endif
# include
#endif
#if HAVE_STRINGS_H
# include
#endif
#if HAVE_INTTYPES_H
# include
#else
# if HAVE_STDINT_H
# include
# endif
#endif
#if HAVE_UNISTD_H
# include
#endif
[2003-01-03 04:21:10] [EMAIL PROTECTED]
Can you include the 20 lines above this fragment too? It should give us
some more hints.
Derick
[2003-01-03 04:20:16] [EMAIL PROTECTED]
This appears to be the relevant section:
long longval () { return (long) (sizeof (char)); }
unsigned long ulongval () { return (long) (sizeof (char));
}
#include
#include
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
FILE *f = fopen ("conftest.val", "w");
if (! f)
exit (1);
if (((long) (sizeof (char))) < 0)
{
long i = longval ();
if (i != ((long) (sizeof (char
exit (1);
fprintf (f, "%ld\n", i);
}
else
{
unsigned long i = ulongval ();
if (i != ((long) (sizeof (char
exit (1);
fprintf (f, "%lu\n", i);
}
exit (ferror (f) || fclose (f) != 0);
;
return 0;
}
configure:58861: error: cannot compute sizeof (char), 77
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/21346
--
Edit this bug report at http://bugs.php.net/?id=21346&edit=1
#21286 [Com]: error while compile with IMAP
ID: 21286 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: IMAP related Operating System: rh 7.3 PHP Version: 4.3.0 New Comment: i try install with apache2, GOD!! they working. thanks for all help, perhaps i decide to use apache2 Previous Comments: [2002-12-30 09:36:15] [EMAIL PROTECTED] ok, installation done, but now apache produce segfault, this is not happen on 4.2.3, i downgrade again to 4.2.3 :( [Mon Dec 30 16:22:43 2002] [notice] Apache/1.3.27 (Unix) AuthMySQL/2.20 mod_perl/1.27 DAV/1.0.3 PHP/4.3.0 mod_ssl/2.8.11 OpenSSL/0.9.6h configured -- resuming normal operations [Mon Dec 30 16:22:43 2002] [notice] Accept mutex: sysvsem (Default: sysvsem) [Mon Dec 30 16:23:15 2002] [notice] child pid 12517 exit signal Segmentation fault (11) [Mon Dec 30 16:23:15 2002] [notice] child pid 12516 exit signal Segmentation fault (11) [2002-12-30 08:56:58] [EMAIL PROTECTED] That's not an error but a warning, ignore it. [2002-12-30 08:55:56] [EMAIL PROTECTED] i follow your instruction with --with-openssl, configuring now no error, but... i got an error while compile ( make ) it :( i try using from http://snaps.php.net/php4-latest.tar.gz ( php4-200212301430 )they procude same error error given on 4.3.0 and php4-200212301430 : /usr/local/src/imap-2002.RC7/c-client/osdep.c:287: the use of `tmpnam' is dangerous, better use `mkstemp' then prompt to shell config.log from php-4.3.0: configure:35413: checking whether IMAP works configure:35446: gcc -o conftest -g -O2 -Wl,-rpath,/usr/local/lib -L/usr/local/lib conftest.c -lcrypto -lssl -lc-client -l crypt -lpam -liconv -lt1 -lttf -lpng -lz -ljpeg -lz -lcrypt -lssl -lcrypto -lresolv -lm -ldl -lnsl -lcrypt 1>&5 /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libc-client.a(osdep.o): In function `ssl_onceonlyinit': /usr/local/src/imap-2002.RC7/c-client/osdep.c:287: the use of `tmpnam' is dangerous, better use `mkstemp' configure:35476: checking for Informix support config.log from php4-200212301430: configure:37927: checking whether IMAP works configure:37960: gcc -o conftest -g -O2 -Wl,-rpath,/usr/local/lib -L/usr/local/lib conftest.c -lc-client -lssl -lcrypto -l crypt -lpam -liconv -lt1 -lttf -lpng -lz -ljpeg -lz -lcrypt -lssl -lcrypto -lresolv -lm -ldl -lnsl -lcrypt 1>&5 /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../libc-client.a(osdep.o): In function `ssl_onceonlyinit': /usr/local/src/imap-2002.RC7/c-client/osdep.c:287: the use of `tmpnam' is dangerous, better use `mkstemp' configure:37990: checking for Informix support configure:38577: checking for Ingres II support [2002-12-30 05:49:07] [EMAIL PROTECTED] yeah! work, thanks for your help Derick. i love this answered fast as hell :) [2002-12-30 05:44:53] [EMAIL PROTECTED] It's actually a RedHat problem, add --with-openssl to your configure line and it should work fine. Derick 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/21286 -- Edit this bug report at http://bugs.php.net/?id=21286&edit=1
#17897 [Com]: POST form variables are empty
ID: 17897 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Apache2 related Operating System: Linux PHP Version: 4.2.1 New Comment: Following extraction helped me to solve the problem that, variables are missing in the *.php after submition. >>Hi there... The problem is actually that in PHP 4.2, Register Globals is automatically defaulted to OFF. This means that variables that were normally in the global space such as GET and POST variables are no longer in the global space by default. PHP Announcement: http://www.php.net/release_4_2_0.php You can still force the old default behavior by changing the php.ini file and set the value for register_globals to "On". This will allow you to access the variables as they are named in the forms Documentation: http://www.php.net/manual/en/configuration.php#ini.register-globals << By the way, I found this Information on expert-exchange.com http://www.experts-exchange.com/Web/Web_Languages/PHP/Q_20293768.html My configuration: PHP 4.2.3 Apache 2.0.43 Windows 2k Previous Comments: [2002-12-13 21:25:05] [EMAIL PROTECTED] I think the problem is PHP4. Because I installed PHP on both Apache and IIS of W2k. I got the same problem. The following are the test program (test.php). TEST I always get empty Arrays. I never imagine that such simple function have bugs in PHP, or I know to little about the PHP settings! Who can HELP!!! My system cannot progress!!! [2002-11-18 03:03:47] [EMAIL PROTECTED] ok the solution to my problem is simple - I am using AddOutputFilter PHP;INCLUDES .php so the post variables are missing - thats because you need also to set AddInputFilter PHP .php otherwise Apache2 will not forward the POST vars! [2002-09-21 02:20:42] [EMAIL PROTECTED] Thanks [EMAIL PROTECTED]! Adding "AddType application/x-httpd-php .php" to the conf file worked for me. PHP 4.2.3 APACHE 2.0.40 on WindowsXP [2002-09-06 14:12:36] [EMAIL PROTECTED] this helped me... LoadModule php4_module php4apache2.dll AddType application/x-httpd-php .php this doen't work #LoadModule php4_module php4apache2.dll # #SetOutputFilter PHP # [2002-09-06 14:05:20] [EMAIL PROTECTED] Untitled both echo are empty... oh yea and file is called t.php... and i have gloabal = on and populoating varibles with post data... help... 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/17897 -- Edit this bug report at http://bugs.php.net/?id=17897&edit=1
#21390 [NEW]: php.exe does not work - needs Kernel32.dll::CancelIo
From: [EMAIL PROTECTED] Operating system: Windows 95 PHP version: 4.3.0 PHP Bug Type: Reproducible crash Bug description: php.exe does not work - needs Kernel32.dll::CancelIo PHP.exe (45056 bytes) does not work on Win95. It imports CancelIo from Kernel32.dll, but this routine does not exist in Kernel32 on Windows 95! Previous version (4.2.3) works correctly. There is nothing about it in PHP documentation and install.txt, maybe documenation problem? P.S. mod_php under Apache works OK. CLI version works too. There is only non-CLI php.exe 4.3.0 problem. -- Edit bug report at http://bugs.php.net/?id=21390&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21390&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21390&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21390&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21390&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21390&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21390&r=support Expected behavior: http://bugs.php.net/fix.php?id=21390&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21390&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21390&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21390&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21390&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21390&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21390&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21390&r=gnused
#21346 [Csd->Bgs]: Config fails: checking size of char
ID: 21346 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Bogus Bug Type: Compile Failure Operating System: OpenBSD 3.1-stable PHP Version: 4.3.0 Previous Comments: [2003-01-03 07:05:53] [EMAIL PROTECTED] Managed to fix this - issuing a bare ldconfig makes it forget all library directories except the system default (/usr/lib). Issuing an ldconfig earlier had broken access to libraries that configure needed. I can't seem to find where the system sets up ldconfig at boot time - it's not in any of my rc files - but I added /usr/local/lib manually and it now works. Whatever, bug closed, thanks for all your timely help. [2003-01-03 04:46:56] [EMAIL PROTECTED] There are no library directories listed in my path (nor have there ever been, IIRC); I don't have an /etc/ld.so.conf at all; ldconfig runs with no errors, but makes no difference. Hm. I just got a similar error when trying to use something else that accessed a different shared library. Looks more like it's a config problem at my end, though I have no idea why this should suddenly have started happening. [2003-01-03 04:28:48] [EMAIL PROTECTED] Can you check if both are in your PATH and if that path is listed in /etc/ld.so.conf? You might also want to run 'ldconfig'. [2003-01-03 04:26:21] [EMAIL PROTECTED] That was quick! Here's a bit from above. The shared library message looks suspicious - /usr/libexec/ld.so exists, as does /usr/local/lib/libiconv.so.2.4. Could this be some kind of compiler flag/path problem? configure:58518: checking for char configure:58545: gcc -c -g -O2 -DDEV_RANDOM=/dev/arandom -DMOD_SSL=208108 -DEAPI -DUSE_EXPAT conftest.c >&5 configure:58548: $? = 0 configure:58551: test -s conftest.o configure:58554: $? = 0 configure:58564: result: yes configure:58567: checking size of char configure:58845: gcc -o conftest -g -O2 -DDEV_RANDOM=/dev/arandom -DMOD_SSL=208108 -DEAPI -DUSE_EXPAT -R/usr/local/lib -L/usr/local/lib conftest.c -lmhash -lmcrypt -lltdl -lldap -llber -lintl -lpng -lz -ljpeg -lbz2 -lz -lssl -lcrypto -lm >&5 configure:58848: $? = 0 configure:58850: ./conftest /usr/libexec/ld.so: conftest: libiconv.so.2.4: No such file or directory configure:58853: $? = 1 configure: program exited with status 1 configure: failed program was: #line 58803 "configure" #include "confdefs.h" #include #if HAVE_SYS_TYPES_H # include #endif #if HAVE_SYS_STAT_H # include #endif #if STDC_HEADERS # include # include #else # if HAVE_STDLIB_H # include # endif #endif #if HAVE_STRING_H # if !STDC_HEADERS && HAVE_MEMORY_H # include # endif # include #endif #if HAVE_STRINGS_H # include #endif #if HAVE_INTTYPES_H # include #else # if HAVE_STDINT_H # include # endif #endif #if HAVE_UNISTD_H # include #endif [2003-01-03 04:21:10] [EMAIL PROTECTED] Can you include the 20 lines above this fragment too? It should give us some more hints. Derick 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/21346 -- Edit this bug report at http://bugs.php.net/?id=21346&edit=1
#21386 [Com]: Hebrew problem...
ID: 21386 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Unknown/Other Function Operating System: Win Nt PHP Version: 4.3.0 New Comment: This might be a locale problem. Try setting your locale, e.g. like so: setlocale(LC_CTYPE,"Hebrew"); Without knowing your locale, PHP (or the underlying C library) has no chance of knowing which character codes are letters and which are punctuation (the letter you wrote looks like a division symbol in my locale with its ISO-8859-1 character set). Previous Comments: [2003-01-03 05:42:02] [EMAIL PROTECTED] Hi, I'm from Israel and I have a problem with Hebrew + PHP. I am using the function PREG but one of the Hebrew letters, PHP doesn't recognize as a letter (The letter is "÷"). That makes the following problems: \b- if the letter start or finish a word PHP won't consider her. \w-PHP doesn't consider her as a letter and more I hope there is something to do about it. P.S Excuse me for any spelling problems, I don't write so good in English Thank you very much. Ido. -- Edit this bug report at http://bugs.php.net/?id=21386&edit=1
#21386 [Com]: Hebrew problem...
ID: 21386 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Unknown/Other Function Operating System: Win Nt PHP Version: 4.3.0 New Comment: Thank you very much, You helped me a lot. I don't understand why only this letter had this problem, but... It's working know so who cares. Thanks. Previous Comments: [2003-01-03 08:17:29] [EMAIL PROTECTED] This might be a locale problem. Try setting your locale, e.g. like so: setlocale(LC_CTYPE,"Hebrew"); Without knowing your locale, PHP (or the underlying C library) has no chance of knowing which character codes are letters and which are punctuation (the letter you wrote looks like a division symbol in my locale with its ISO-8859-1 character set). [2003-01-03 05:42:02] [EMAIL PROTECTED] Hi, I'm from Israel and I have a problem with Hebrew + PHP. I am using the function PREG but one of the Hebrew letters, PHP doesn't recognize as a letter (The letter is "÷"). That makes the following problems: \b- if the letter start or finish a word PHP won't consider her. \w-PHP doesn't consider her as a letter and more I hope there is something to do about it. P.S Excuse me for any spelling problems, I don't write so good in English Thank you very much. Ido. -- Edit this bug report at http://bugs.php.net/?id=21386&edit=1
#21167 [Csd->Opn]: ldapclose() SEGFAULTs
ID: 21167
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: Reproducible crash
Operating System: Linux Redhat 8.0
PHP Version: 4.2.2
New Comment:
Erroneously closed.
The above code segfaults spuriously on 4.2.2, 4.3.0 and 4.4.0-dev
(latest CVS snapshot) on RH-8.0 linux system with the following ldap
libraries installed:
[root@avipsa64 root]# rpm -qa |grep ldap
nss_ldap-198-3
openldap-devel-2.0.25-1
openldap-clients-2.0.25-1
openldap-2.0.25-1
SIGSEGVs with CGI and DSO versions.
the stack backtrace on the core file shows:
[root@avipsa64 vmps]# gdb -c core.22324
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux".
Core was generated by `/home/rsaura/php-4.3.0/sapi/cgi/php -f
pp.php4'.
Program terminated with signal 11, Segmentation fault.
#0 0x40055615 in ?? ()
(gdb) bt
#0 0x40055615 in ?? ()
#1 0x4004e62c in ?? ()
#2 0x4004e38b in ?? ()
#3 0x4004e66f in ?? ()
#4 0x0807bbab in ?? ()
#5 0x081165c1 in ?? ()
#6 0x081152cb in ?? ()
#7 0x081163e1 in ?? ()
#8 0x0807c160 in ?? ()
#9 0x0811ca3a in ?? ()
#10 0x08111f0b in ?? ()
#11 0x080f175c in ?? ()
#12 0x08120b0f in ?? ()
#13 0x420158d4 in ?? ()
(gdb) q
[root@avipsa64 vmps]# ldd /home/rsaura/php-4.3.0/sapi/cgi/php
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4001c000)
libldap.so.2 => /usr/lib/libldap.so.2 (0x4003d000)
liblber.so.2 => /usr/lib/liblber.so.2 (0x40067000)
libz.so.1 => /usr/lib/libz.so.1 (0x40072000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4008)
libresolv.so.2 => /lib/libresolv.so.2 (0x400ad000)
libm.so.6 => /lib/i686/libm.so.6 (0x400bf000)
libdl.so.2 => /lib/libdl.so.2 (0x400e2000)
libnsl.so.1 => /lib/libnsl.so.1 (0x400e5000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x400fa000)
libc.so.6 => /lib/i686/libc.so.6 (0x4200)
libsasl.so.7 => /usr/lib/libsasl.so.7 (0x401a2000)
libssl.so.2 => /lib/libssl.so.2 (0x401ad000)
libcrypto.so.2 => /lib/libcrypto.so.2 (0x401de000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x402b2000)
libpam.so.0 => /lib/libpam.so.0 (0x402b9000)
[root@avipsa64 vmps]#
the faults seems to happen inside libldap.
best regards.
Previous Comments:
[2002-12-23 12:27:43] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
The 4.3.0 release will soon be released as 'stable', the RC4 is
probably 99.5% of what the 4.3.0 final will be. If using 4.3.0 solves
the bug, that is the release you should probably use.
[2002-12-23 12:25:47] [EMAIL PROTECTED]
It works with php4-200212231630.
Does anybody know if this is patched on a production release?
[2002-12-23 12:07:27] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-12-23 12:06:48] [EMAIL PROTECTED]
The following code will segfault with php-4.2.2 on RH-8.0
It queries a Microsoft Active Directory via LDAPv3.
It is suposed to create a session if a given user exists in the
directory, belongs to a given group and can bind to the directory with
the given password.
$ds=ldap_connect($LDAP_SERVER);
if($ds){
ldap_bind($ds, $QUERYUSER_DN, $QUERYUSER_PASS);
$err=ldap_errno($ds);
if($err==0){
$sr=ldap_search($ds, $BASE_DN, "samaccountname=rsaura",
array ("distinguishedName"), 0, 1, 30, LDAP_DEREF_NEVER);
$entry = ldap_first_entry($ds, $sr);
if($entry == FALSE){
exit;
}
$attrs = ldap_get_attributes($ds, $entry);
$dn = $attrs["distinguishedNa
#21386 [Opn->Csd]: Hebrew problem...
ID: 21386 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Unknown/Other Function Operating System: Win Nt PHP Version: 4.3.0 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2003-01-03 08:26:17] [EMAIL PROTECTED] Thank you very much, You helped me a lot. I don't understand why only this letter had this problem, but... It's working know so who cares. Thanks. [2003-01-03 08:17:29] [EMAIL PROTECTED] This might be a locale problem. Try setting your locale, e.g. like so: setlocale(LC_CTYPE,"Hebrew"); Without knowing your locale, PHP (or the underlying C library) has no chance of knowing which character codes are letters and which are punctuation (the letter you wrote looks like a division symbol in my locale with its ISO-8859-1 character set). [2003-01-03 05:42:02] [EMAIL PROTECTED] Hi, I'm from Israel and I have a problem with Hebrew + PHP. I am using the function PREG but one of the Hebrew letters, PHP doesn't recognize as a letter (The letter is "÷"). That makes the following problems: \b- if the letter start or finish a word PHP won't consider her. \w-PHP doesn't consider her as a letter and more I hope there is something to do about it. P.S Excuse me for any spelling problems, I don't write so good in English Thank you very much. Ido. -- Edit this bug report at http://bugs.php.net/?id=21386&edit=1
#21213 [Sus]: invalid entities handling into set_attribute() and set_content()
ID: 21213
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Suspended
Bug Type: DOM XML related
Operating System: All
PHP Version: 4.3.0RC4
New Comment:
As said before, we need set_attribute_node($attrNode) and
append_child() et al. working in attribute Nodes, then it should work.
Don't know, when I have the time to do it, if someone else wants to
take over this part, feel free ;)
chregu
Previous Comments:
[2003-01-03 04:06:32] [EMAIL PROTECTED]
Sorry for summary changing - its Mozilla bug :)
[2003-01-03 04:01:49] [EMAIL PROTECTED]
Yes, i agree with you in this point, but it also means, that you should
provide a way to parse given text value and build NodeList of Text and
EntityReference nodes. libxml2 already have such function.
[2003-01-01 14:59:56] [EMAIL PROTECTED]
Hi
I will most certainly not add this options, since i prefer to stick to
the w3c standard at
http://www.zvon.org/xxl/DOM2reference/Output/interfaces/Element.html#setAttribute
And in my interpretation of this, php's domxml behaves correctly. The
only thing missing is setAttributeNode, which I maybe will implement,
if I find some time.
If there is setAttributeNode, then you can use the way the w3c
suggests.
chregu
[2002-12-27 10:05:50] [EMAIL PROTECTED]
Please take a look at following example:
');
$root = $xml->root();
$value = $root->set_attribute('a','a&b');
$value = $root->set_content('a&b');
echo $xml->dump_mem();
?>
It produces following results:
a&b
As you may see - & entity is treated as literals when it is being
set as attribute value while same entity is treated as entity reference
being set as node value.
I have checked PHP's DOMXML extension source, libxml2 sources and
discuss about this behaviour with Daniel Viellard (libxml2 maintainer)
and with some other people on public XML-related forums and here is
some information about this issue:
1. Such behaviour is not a libxml2 bug, it is expected behaviour.
Moreover it is more correct from a point of specifications.
2. There should be a way to access Attr DOM object as specified into
DOM Level 1 specification
3. There should be a way to control entites handling into passed
values.
As a way to go i want to propose you to add one additional argument to
set_attribute(), set_content() and maybe some other functions -
$options.
For now there will be 2 options:
XML_KEEP_ENTITIES - to treat all entities as entites and create them as
EntityReference DOM objects
XML_QUOTE_ENTITIES - to treat all entities as literals and hence quote
all special symbols in them (such as '&' char).
For compatibility reasons $options for set_attribute() may be set to
XML_QUOTE_ENTITIES as default value and $options for set_content() -
for XML_KEEP_ENTITIES.
Internally you probably should change xmlSetProp() call into
domxml_elem_set_attribute() to xmlNodeSetContentLen() when there is
$options=XML_KEEP_ENTITIES.
--
Edit this bug report at http://bugs.php.net/?id=21213&edit=1
#21392 [NEW]: use of
From: [EMAIL PROTECTED] Operating system: I think all PHP version: 4.3.0 PHP Bug Type: Feature/Change Request Bug description: use of
#21392 [Opn]: use of
ID: 21392 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request -Operating System: I think all +Operating System: Windows PHP Version: 4.3.0 New Comment: Enter the bugs as Windows only since I don't have a way to confirm on Linux, Unix, or Mac. Previous Comments: [2003-01-03 09:39:16] [EMAIL PROTECTED]
#21370 [Bgs]: FastCGI -b option doesn't work
ID: 21370 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Other web server Operating System: WinXP PHP Version: 4.3.0 New Comment: It was totally not my fault. The bugs.php.net page kept saying that : "This bug could not be sent. Please try by e-mail." or something like that. I didn't know it was being sent. Sorry. Previous Comments: [2003-01-03 05:08:55] [EMAIL PROTECTED] This bug has been resubmitted 6 times in total. PLEASE do not do this again!! [2003-01-02 20:50:58] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. [2003-01-02 20:10:13] [EMAIL PROTECTED] I've downloaded the full Win32 PHP binary and the "-b" argument that should "Bind Path for external FASTCGI server mode" doesn't work. What happens is: c:\php>php -b 5000 Error in argument 1, char 2: option not found b Error in argument 1, char 2: option not found b Error in argument 1, char 2: option not found b I read on php.dev newsgroup that this is the right way to start FastCGI support since SAPI/FastCGI was discontinued. But it doesn't work. -- Edit this bug report at http://bugs.php.net/?id=21370&edit=1
#19783 [Com]: A big problem with fread() with PHP4.3.0
ID: 19783
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Filesystem function related
Operating System: WindowsNT/XP/2000/9x
PHP Version: 4CVS-2002-10-06
New Comment:
I got a similar problem with :
apache 1.3.27
PHP 4.2.3
Os : Win NT 4
I do :
$fp = @fopen($localfile, "rb");
while (!feof($fp)) {
fwrite($file2,fread($file1, filesize($localfile)));
}
The size are differents on some test file (not all)
When the probleme occured the dest file is all the time smaller than
the source file ...
}
fclose($fp);
Previous Comments:
[2002-10-13 09:09:20] [EMAIL PROTECTED]
Sorry, my previous submitted problem is not related to this bug.
Please see Bug #19886.
[2002-10-13 08:52:31] [EMAIL PROTECTED]
Reopened this bug.
readfile() on 4.0, 4.2.4-dev and latest CVS-snapshot (13-Oct-2002
03:27) won't work with large files in Windows.
Even
$ptfp=fopen($ipoc_passthru_fn,"rb");
while(!feof($ptfp))
{
print fread($ptfp,4096);
}
fclose($ptfp);
won't work.
Files <100k work fine, larger don't.
This error is reproductive on various computers with different
Windows-Systems and occurs while trying to pass through PDF-files.
[2002-10-06 20:56:44] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2002-10-06 20:28:21] [EMAIL PROTECTED]
This bug looks really important.
I dont know if it is because of the new handling of streams but I just
verified that its working with PHP4.2.3 and not wit h 4_3 latest.
[2002-10-06 14:14:32] [EMAIL PROTECTED]
on some of my code I use the following:
$fd=fopen($filename,"rb");
echo fread($fd,filesize($filename));
fclose($fd);
It looks fread is limited to a certain value. I can't get more than a
certain size. With bigs files, I dont get all of them but just a part
so I had to use fgets.
Can someone check if something changed on the fread()'s function that
would limit it?
--
Edit this bug report at http://bugs.php.net/?id=19783&edit=1
#21393 [NEW]: Apache crashes when loading oracle dlls
From: [EMAIL PROTECTED] Operating system: windows 2000 prof. sp3 PHP version: 4.3.0 PHP Bug Type: Oracle related Bug description: Apache crashes when loading oracle dlls The Apache service (1.3.27) just crashes if my php.ini tries to load both php_oci8.dll and php_oracle.dll. My oracle client version is the last 8.1.7. My pc is a P4 2.5Ghz. My configuration is very simple. If I try to load each of the dlls alone it works fine. I hope this isn't a normal result, I didn't find this information in the php.ini or somewhere else. I have to say that I didn't search very well. Kamal -- Edit bug report at http://bugs.php.net/?id=21393&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21393&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21393&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21393&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21393&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21393&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21393&r=support Expected behavior: http://bugs.php.net/fix.php?id=21393&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21393&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21393&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21393&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21393&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21393&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21393&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21393&r=gnused
#21393 [Opn->Fbk]: Apache crashes when loading oracle dlls
ID: 21393 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Oracle related Operating System: windows 2000 prof. sp3 PHP Version: 4.3.0 New Comment: I don't understand why you want to load both. The OCI8 extension supports the oci7 protocol. Previous Comments: [2003-01-03 10:04:13] [EMAIL PROTECTED] The Apache service (1.3.27) just crashes if my php.ini tries to load both php_oci8.dll and php_oracle.dll. My oracle client version is the last 8.1.7. My pc is a P4 2.5Ghz. My configuration is very simple. If I try to load each of the dlls alone it works fine. I hope this isn't a normal result, I didn't find this information in the php.ini or somewhere else. I have to say that I didn't search very well. Kamal -- Edit this bug report at http://bugs.php.net/?id=21393&edit=1
#21393 [Fbk->Bgs]: Apache crashes when loading oracle dlls
ID: 21393 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Bogus Bug Type: Oracle related Operating System: windows 2000 prof. sp3 PHP Version: 4.3.0 New Comment: There is no need to load both the .dll's as the oci8 one supports the Oracle versions supported by the oracle dll. They both make use of the libraries installed on your system and it's simply asking for problems if you load both .dll due to symbol clashes. Not a bug -> bogus Previous Comments: [2003-01-03 10:17:16] [EMAIL PROTECTED] I don't understand why you want to load both. The OCI8 extension supports the oci7 protocol. [2003-01-03 10:04:13] [EMAIL PROTECTED] The Apache service (1.3.27) just crashes if my php.ini tries to load both php_oci8.dll and php_oracle.dll. My oracle client version is the last 8.1.7. My pc is a P4 2.5Ghz. My configuration is very simple. If I try to load each of the dlls alone it works fine. I hope this isn't a normal result, I didn't find this information in the php.ini or somewhere else. I have to say that I didn't search very well. Kamal -- Edit this bug report at http://bugs.php.net/?id=21393&edit=1
#18363 [Com]: [chm] bug on function.fread.html
ID: 18363
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: No Feedback
Bug Type: Reproducible crash
Operating System: windows
PHP Version: 4.2.1
New Comment:
I got a similar problem with file which containt 1A (hexa) but no crash
the fread only skip the 1A ... on Win NT with Apache/1.3.27 (Win32)
PHP/4.2.3
I have the same probleme with : Apache/1.3.27 (Win32) PHP/4.4.0-dev
for example a 7437824 bytes files become a 7.437.722 Bytes files
here is the code I use :
$file1 = @fopen($localfile, "rb");
$file2 = @fopen($destfile, "w");
while (!feof($fp)) {
fwrite($file2,fread($file1, filesize($localfile)));
}
Previous Comments:
[2002-10-17 01:00:01] [EMAIL PROTECTED]
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2002-10-01 18:09:49] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
I've tried opening various exe and com files and I am unable to
replicate the crash you've reported. Please try the latest release and
see if the problem still occurs.
[2002-07-23 00:59:02] [EMAIL PROTECTED]
When reading with the function fread I have found an error when read
hexadecimal "1A", not, but I believe that they must more of the sort
have.
[2002-07-17 02:52:42] [EMAIL PROTECTED]
for example:(abc.exe is execution file)
$fp=fopen("abc.exe","rb");
$exe_get=fread($fp,filesize("abc.exe"));
[2002-07-17 02:18:43] [EMAIL PROTECTED]
oops...misunderstood (!) this.
Can you please show us a SHORT example script which
causes this crash?
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/18363
--
Edit this bug report at http://bugs.php.net/?id=18363&edit=1
#21312 [Opn->Fbk]: session_register doesnt like null values
ID: 21312
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: Windows 2000 Server
PHP Version: 4.3.0
New Comment:
Try adding this to your php.ini file:
session.bug_compat_42 = 1
session.bug_compat_warn = 0
Previous Comments:
[2003-01-01 12:19:47] [EMAIL PROTECTED]
i've the same problem with linux (apache 1.3.27) + mysql.
contents of nearly all variable are exchanged!
with a small function i had fixed this temporarly:
function dp_session_register($variable) {
global ${$variable};
if(is_null(${$variable}))
${$variable}="";
return session_register($variable);
}
i hope, this will fixed as soon as posible. thanks.
daniel prior
[2002-12-31 08:59:20] [EMAIL PROTECTED]
";
$sql_result = mssql_query($sql,$connection);
$num = mssql_num_rows($sql_result);
$retVal = "Records = ".$num;
if ($num > 0) {
mssql_data_seek($sql_result,0);
$row = mssql_fetch_object($sql_result);
$retVal = $row->Text;
}
mssql_free_result($sql_result);
echo $retVal;
?>
In this case the mssql_query fails with:
PHP Warning: mssql_query(): supplied argument is not a valid MS
SQL-Link resource.
if I simply comment the $source = $_SERVER... it succeeds.
If I change session_register to $_SESSION["source"] = $source; it
succeeds.
I am not sure how these are related.
What is even weirder is the echo "$sql $connection";
They echo what is expected when it works. When it doesnt whichever was
defined first is the value for both.
IE When it fails as it is written
select * from tbl_Texts; select * from tbl_Texts;
If you change
$connection = mssql_connect('server','UserName','password');
$sql = "select * from tbl;";
to
$sql = "select * from tbl;";
$connection = mssql_connect('server','UserName','password');
it echos
Resource id #3 Resource id #3
I will in the future use $_SESSION but there are alot of files to
change if this wont be fixed.
Thanks
Charles Killmer
--
Edit this bug report at http://bugs.php.net/?id=21312&edit=1
#21267 [Opn->Csd]: fopen() fails on some URLs
ID: 21267
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: *URL Functions
Operating System: FreeBSD
PHP Version: 4.4.0-dev
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
404 means the page cannot be found, openning 404 error handler URL is
counter intuitive since it implies that the fopen() succeeded opening
the request page, even though the requested page does not exist.
This will not be fixed.
Previous Comments:
[2003-01-03 05:12:10] [EMAIL PROTECTED]
Tnx for the fast change, and it is almost working. But one thing still
doesn't:
When you open:
http://www.smswhiz.com/http2sms/sendsms.asp
You get a redirect to sendfailed.htm. The new URL to open should be:
http://www.smswhiz.com/http2sms/sendfailed.htm
and this site exists. But when I try it with PHP (with the latest
snapshot ofcourse), I get a 404, so I think it opens:
http://www.smswhiz.com/sendfailed.htm
I know, IIS 5.0 really sucks in those redirects, but can you maybe fix
this problem too? Tnx!
[2002-12-29 14:03:03] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2002-12-29 12:06:44] [EMAIL PROTECTED]
But can you tell me why in version 4.2.3 this works perfect?
[2002-12-29 10:05:47] [EMAIL PROTECTED]
That's because of the silly 302 temporary redirect to a relative URL
with GET-method args that is done on that site. Open the right
location and it should work fine. We probably should support this at
some point though.
[2002-12-29 09:44:51] [EMAIL PROTECTED]
When trying fopen() on http://, it fails on some urls.
Example:
fopen("http://www.smswhiz.com/","r";);
Gives stream error. The site IS touched, but you do not receive any
data back from the site.
While for example:
fopen("http://www.tweakers.net/","r";);
Does work without any problem!
--
Edit this bug report at http://bugs.php.net/?id=21267&edit=1
#21340 [Com]: numerics can overflow php numeric datatypes
ID: 21340 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Sybase-ct (ctlib) related Operating System: redhat linux 7.3 PHP Version: 4.3.0 New Comment: Update: this patch doesn't quite work, a value of '0' is returned as NULL. In the meantime, I've downgraded to 4.2.3 and will look into this issue more as I get time. Previous Comments: [2003-01-02 17:27:56] [EMAIL PROTECTED] Looks like I forgot to seperate CS_DECIMAL_TYPE from the CS_NUMERIC_TYPE string conversion. As far as I can tell, DECIMAL types should still be returned as float/real datatypes, though I am not very familiar with them. I can upload another patch if wanted, but the changes are so minor and straightforward that I don't see a need right now. :) [2003-01-02 10:57:49] [EMAIL PROTECTED] Large NUMERIC (20,0) fields can easily overflow the built-in php datatypes (float, real), causing truncation to 2147483647 (2^31 - 1). Some solutions: 1) Return numerics as string 2) Return numerics as gmp val 3) redesign my database Until (2) becomes a builtin datatype in PHP, I don't see this as a good solution. (3) is out of the question, so I elected to use (1); patch follows. I also have the CS_NUMERIC_TYPE ident as "numeric". --- php_sybase_ct.c.old Thu Jan 2 11:42:57 2003 +++ php_sybase_ct.c Thu Jan 2 11:46:18 2003 @@ -1166,9 +1166,9 @@ break; case CS_NUMERIC_TYPE: case CS_DECIMAL_TYPE: - result->datafmt[i].maxlength = result->datafmt[i].precision + 3; - /* numeric(10) vs numeric(10, 1) */ - result->numerics[i] = (result->datafmt[i].scale == 0) ? 1 : 2; + /* numerics can overflow real and long types, return as a string */ + result->datafmt[i].maxlength++; + result->numerics[i] = 0; break; default: result->datafmt[i].maxlength++; @@ -1769,10 +1769,12 @@ break; case CS_REAL_TYPE: case CS_FLOAT_TYPE: - case CS_NUMERIC_TYPE: case CS_DECIMAL_TYPE: return "real"; break; + case CS_NUMERIC_TYPE: + return "numeric"; + break; case CS_MONEY_TYPE: case CS_MONEY4_TYPE: return "money"; -- Edit this bug report at http://bugs.php.net/?id=21340&edit=1
#21312 [Fbk->Opn]: session_register doesnt like null values
ID: 21312
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: Windows 2000 Server
PHP Version: 4.3.0
New Comment:
Tryed that and still the same results.
Previous Comments:
[2003-01-03 10:22:52] [EMAIL PROTECTED]
Try adding this to your php.ini file:
session.bug_compat_42 = 1
session.bug_compat_warn = 0
[2003-01-01 12:19:47] [EMAIL PROTECTED]
i've the same problem with linux (apache 1.3.27) + mysql.
contents of nearly all variable are exchanged!
with a small function i had fixed this temporarly:
function dp_session_register($variable) {
global ${$variable};
if(is_null(${$variable}))
${$variable}="";
return session_register($variable);
}
i hope, this will fixed as soon as posible. thanks.
daniel prior
[2002-12-31 08:59:20] [EMAIL PROTECTED]
";
$sql_result = mssql_query($sql,$connection);
$num = mssql_num_rows($sql_result);
$retVal = "Records = ".$num;
if ($num > 0) {
mssql_data_seek($sql_result,0);
$row = mssql_fetch_object($sql_result);
$retVal = $row->Text;
}
mssql_free_result($sql_result);
echo $retVal;
?>
In this case the mssql_query fails with:
PHP Warning: mssql_query(): supplied argument is not a valid MS
SQL-Link resource.
if I simply comment the $source = $_SERVER... it succeeds.
If I change session_register to $_SESSION["source"] = $source; it
succeeds.
I am not sure how these are related.
What is even weirder is the echo "$sql $connection";
They echo what is expected when it works. When it doesnt whichever was
defined first is the value for both.
IE When it fails as it is written
select * from tbl_Texts; select * from tbl_Texts;
If you change
$connection = mssql_connect('server','UserName','password');
$sql = "select * from tbl;";
to
$sql = "select * from tbl;";
$connection = mssql_connect('server','UserName','password');
it echos
Resource id #3 Resource id #3
I will in the future use $_SESSION but there are alot of files to
change if this wont be fixed.
Thanks
Charles Killmer
--
Edit this bug report at http://bugs.php.net/?id=21312&edit=1
#21267 [Csd->Opn]: fopen() fails on some URLs
ID: 21267 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: *URL Functions Operating System: FreeBSD PHP Version: 4.4.0-dev New Comment: No, you didn't understand the problem. In reality it doesn't return a 404 error, but because a 302 is given back in the form: newpage.htm but is handled as /newpage.htm, it opens the wrong redirect and that returns a 404. In PHP 4.2.x this works fine. The URL: http://www.smswhiz.com/http2sms/sendsms.asp Does not return a 404-error when you follow it manually! Previous Comments: [2003-01-03 10:25:46] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. 404 means the page cannot be found, openning 404 error handler URL is counter intuitive since it implies that the fopen() succeeded opening the request page, even though the requested page does not exist. This will not be fixed. [2003-01-03 05:12:10] [EMAIL PROTECTED] Tnx for the fast change, and it is almost working. But one thing still doesn't: When you open: http://www.smswhiz.com/http2sms/sendsms.asp You get a redirect to sendfailed.htm. The new URL to open should be: http://www.smswhiz.com/http2sms/sendfailed.htm and this site exists. But when I try it with PHP (with the latest snapshot ofcourse), I get a 404, so I think it opens: http://www.smswhiz.com/sendfailed.htm I know, IIS 5.0 really sucks in those redirects, but can you maybe fix this problem too? Tnx! [2002-12-29 14:03:03] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-12-29 12:06:44] [EMAIL PROTECTED] But can you tell me why in version 4.2.3 this works perfect? [2002-12-29 10:05:47] [EMAIL PROTECTED] That's because of the silly 302 temporary redirect to a relative URL with GET-method args that is done on that site. Open the right location and it should work fine. We probably should support this at some point though. 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/21267 -- Edit this bug report at http://bugs.php.net/?id=21267&edit=1
#21267 [Opn->Csd]: fopen() fails on some URLs
ID: 21267 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: *URL Functions Operating System: FreeBSD PHP Version: 4.4.0-dev New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-01-03 10:40:51] [EMAIL PROTECTED] No, you didn't understand the problem. In reality it doesn't return a 404 error, but because a 302 is given back in the form: newpage.htm but is handled as /newpage.htm, it opens the wrong redirect and that returns a 404. In PHP 4.2.x this works fine. The URL: http://www.smswhiz.com/http2sms/sendsms.asp Does not return a 404-error when you follow it manually! [2003-01-03 10:25:46] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. 404 means the page cannot be found, openning 404 error handler URL is counter intuitive since it implies that the fopen() succeeded opening the request page, even though the requested page does not exist. This will not be fixed. [2003-01-03 05:12:10] [EMAIL PROTECTED] Tnx for the fast change, and it is almost working. But one thing still doesn't: When you open: http://www.smswhiz.com/http2sms/sendsms.asp You get a redirect to sendfailed.htm. The new URL to open should be: http://www.smswhiz.com/http2sms/sendfailed.htm and this site exists. But when I try it with PHP (with the latest snapshot ofcourse), I get a 404, so I think it opens: http://www.smswhiz.com/sendfailed.htm I know, IIS 5.0 really sucks in those redirects, but can you maybe fix this problem too? Tnx! [2002-12-29 14:03:03] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-12-29 12:06:44] [EMAIL PROTECTED] But can you tell me why in version 4.2.3 this works perfect? 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/21267 -- Edit this bug report at http://bugs.php.net/?id=21267&edit=1
#19783 [Csd]: A big problem with fread() with PHP4.3.0
ID: 19783
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Filesystem function related
Operating System: WindowsNT/XP/2000/9x
PHP Version: 4CVS-2002-10-06
New Comment:
You have a while(!feof) that does fwrite which is completly wrong. You
should READ the whole file (with fread and !feof), then fwrite it.
Bogus.
Thank for your report.
Previous Comments:
[2003-01-03 10:03:49] [EMAIL PROTECTED]
I got a similar problem with :
apache 1.3.27
PHP 4.2.3
Os : Win NT 4
I do :
$fp = @fopen($localfile, "rb");
while (!feof($fp)) {
fwrite($file2,fread($file1, filesize($localfile)));
}
The size are differents on some test file (not all)
When the probleme occured the dest file is all the time smaller than
the source file ...
}
fclose($fp);
[2002-10-13 09:09:20] [EMAIL PROTECTED]
Sorry, my previous submitted problem is not related to this bug.
Please see Bug #19886.
[2002-10-13 08:52:31] [EMAIL PROTECTED]
Reopened this bug.
readfile() on 4.0, 4.2.4-dev and latest CVS-snapshot (13-Oct-2002
03:27) won't work with large files in Windows.
Even
$ptfp=fopen($ipoc_passthru_fn,"rb");
while(!feof($ptfp))
{
print fread($ptfp,4096);
}
fclose($ptfp);
won't work.
Files <100k work fine, larger don't.
This error is reproductive on various computers with different
Windows-Systems and occurs while trying to pass through PDF-files.
[2002-10-06 20:56:44] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2002-10-06 20:28:21] [EMAIL PROTECTED]
This bug looks really important.
I dont know if it is because of the new handling of streams but I just
verified that its working with PHP4.2.3 and not wit h 4_3 latest.
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/19783
--
Edit this bug report at http://bugs.php.net/?id=19783&edit=1
#21167 [Opn->Fbk]: ldapclose() SEGFAULTs
ID: 21167
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Linux Redhat 8.0
PHP Version: 4.2.2
New Comment:
Could you compile your PHP with --enable-debug flag, so that your
backtrace contains more information.
Previous Comments:
[2003-01-03 09:21:29] [EMAIL PROTECTED]
Erroneously closed.
The above code segfaults spuriously on 4.2.2, 4.3.0 and 4.4.0-dev
(latest CVS snapshot) on RH-8.0 linux system with the following ldap
libraries installed:
[root@avipsa64 root]# rpm -qa |grep ldap
nss_ldap-198-3
openldap-devel-2.0.25-1
openldap-clients-2.0.25-1
openldap-2.0.25-1
SIGSEGVs with CGI and DSO versions.
the stack backtrace on the core file shows:
[root@avipsa64 vmps]# gdb -c core.22324
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux".
Core was generated by `/home/rsaura/php-4.3.0/sapi/cgi/php -f
pp.php4'.
Program terminated with signal 11, Segmentation fault.
#0 0x40055615 in ?? ()
(gdb) bt
#0 0x40055615 in ?? ()
#1 0x4004e62c in ?? ()
#2 0x4004e38b in ?? ()
#3 0x4004e66f in ?? ()
#4 0x0807bbab in ?? ()
#5 0x081165c1 in ?? ()
#6 0x081152cb in ?? ()
#7 0x081163e1 in ?? ()
#8 0x0807c160 in ?? ()
#9 0x0811ca3a in ?? ()
#10 0x08111f0b in ?? ()
#11 0x080f175c in ?? ()
#12 0x08120b0f in ?? ()
#13 0x420158d4 in ?? ()
(gdb) q
[root@avipsa64 vmps]# ldd /home/rsaura/php-4.3.0/sapi/cgi/php
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4001c000)
libldap.so.2 => /usr/lib/libldap.so.2 (0x4003d000)
liblber.so.2 => /usr/lib/liblber.so.2 (0x40067000)
libz.so.1 => /usr/lib/libz.so.1 (0x40072000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4008)
libresolv.so.2 => /lib/libresolv.so.2 (0x400ad000)
libm.so.6 => /lib/i686/libm.so.6 (0x400bf000)
libdl.so.2 => /lib/libdl.so.2 (0x400e2000)
libnsl.so.1 => /lib/libnsl.so.1 (0x400e5000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x400fa000)
libc.so.6 => /lib/i686/libc.so.6 (0x4200)
libsasl.so.7 => /usr/lib/libsasl.so.7 (0x401a2000)
libssl.so.2 => /lib/libssl.so.2 (0x401ad000)
libcrypto.so.2 => /lib/libcrypto.so.2 (0x401de000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x402b2000)
libpam.so.0 => /lib/libpam.so.0 (0x402b9000)
[root@avipsa64 vmps]#
the faults seems to happen inside libldap.
best regards.
[2002-12-23 12:27:43] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
The 4.3.0 release will soon be released as 'stable', the RC4 is
probably 99.5% of what the 4.3.0 final will be. If using 4.3.0 solves
the bug, that is the release you should probably use.
[2002-12-23 12:25:47] [EMAIL PROTECTED]
It works with php4-200212231630.
Does anybody know if this is patched on a production release?
[2002-12-23 12:07:27] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-latest.zip
[2002-12-23 12:06:48] [EMAIL PROTECTED]
The following code will segfault with php-4.2.2 on RH-8.0
It queries a Microsoft Active Directory via LDAPv3.
It is suposed to create a session if a given user exists in the
directory, belongs to a given group and can bind to the directory with
the given password.
$ds=ldap_connect($LDAP_SERVER);
if($ds){
ldap_bind($ds, $QUERYUSER_DN, $QUERYUSER_PASS);
$err=ldap_errno($ds);
if($err==0){
$sr=ldap_search($ds, $BASE_DN, "samaccountname=rsaura",
array ("distinguishedName"), 0, 1, 30, LDAP_DEREF_NEVER);
$entry = l
#21279 [Opn->Bgs]: odbc_fetch_into returns empty strings for columns with NULL values
ID: 21279 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: ODBC related Operating System: Windows PHP Version: 4.3.0 New Comment: Which other API's are you talking about? Oracle? It's the only other extension that uses fetch into really. As for the statement, there is no way for ODBC to really tell either. The API itself defines this to be rather ambiguous so it becomes difficult to deal with. At this time the result leaves it to the PHP user to decide if one is really an emtpy string or NULL rather than the PHP engine. I tend to think this is a better solution. Previous Comments: [2002-12-29 19:47:04] [EMAIL PROTECTED] odbc_fetch_into returns empty strings for columns with NULL values. This makes it impossible to distinguish whether a result column value is a real empty string or a NULL, unlike with API functions for the same purpose but for other databases. -- Edit this bug report at http://bugs.php.net/?id=21279&edit=1
#20665 [Opn->]: Memory leaks on SIGHUP
ID: 20665 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Won\'t fix Bug Type: Apache related Operating System: BSD/OS 4.2 PHP Version: 4.3.0RC1 New Comment: When PHP recieves the signal it stops the current execution and immidiately goes to the shutdown code. The result is that there are some non-freed buffers, who's memory you see the shutdown code free and report as memory leaks. These are not actual leaks and they can be safely ignored. Previous Comments: [2002-12-03 04:38:39] [EMAIL PROTECTED] Just ran into the same 'Unable to allocate 129bytes' error with a totally different script. This is actually a bug in spprintf. The 129bytes are the allocation for the 'Maximum executions time of %d second%s execeeded' error message. Relaying to new bug. RC2 will be installed later today, to check the memory leaks. Updated summary [2002-11-30 03:36:43] [EMAIL PROTECTED] Traced the segfaults to an infinite loop in one script in a situation that shouldn't normally occur (iow sloppy coding :). I used squid in accellerator mode, to find out which script it was (For reference: grep for 'HTTP/1.[01]" 503' and use emulate_httpd_log On). It would really be nice, if emalloc failures could report some more info than 'oops, I failed'. The memleaks are still there on SIGHUP and are unrelated. Will try RC2 this weekend. [2002-11-28 09:00:07] [EMAIL PROTECTED] CFLAGS='-O0' \ ./configure \ --prefix=/phpct \ --with-apache=../apache_1.3.27 \ --enable-cli \ --disable-cgi \ --enable-debug \ --enable-magic-quotes \ --disable-short-tags \ --with-zlib \ --with-zlib-dir=/usr \ --enable-calendar \ --enable-ftp \ --with-mhash=/weblib/local \ --enable-shmop \ --enable-sysvmsg \ --enable-sysvsem \ --enable-sysvshm waiting for a coredump.. :) [2002-11-28 08:17:25] [EMAIL PROTECTED] As a security procution Apache does not write core files, in order to make it do so you must tell it where to write core files using: CoreDumpDirectory /tmp. In debug builds Zend will segfault if emalloc() fails to allocate memory. Also, could you please include the list of extensions you've compiled your PHP with (put config.nice online somewhere?). [2002-11-28 06:34:38] [EMAIL PROTECTED] Yes, it does put out the scriptname, with the mem leaks -it's always the same script, which is nothing more than a static file which echo's the current timestamp into 8 different places for banners - that's why it doesn't make sence. However - when an emalloc call fails, it doesn't output the scriptname nor the c file, which called the emalloc. It only happens a few times a day, so the cause could be the memory leaks or it could be a script which isn't requested too much. I see a SIGSEV afterwards, but no core dump and it's not like I can startup Apache from gdb and request a certain file to reproduce it, since I have no idea where to look. I will recheck settings to make it dump core. What's also strange is that these leaks only get reported on a SIGHUP. Through the entire error log, there are no other leak reports. This would suggest something in the SIGCHILD and therefore the shutdown handler. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20665 -- Edit this bug report at http://bugs.php.net/?id=20665&edit=1
#17098 [Com]: apache sending 304 - not modified header
ID: 17098 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache2 related Operating System: linux PHP Version: 4.0CVS-2002-10-17 New Comment: As another possible temporary workaround, I tried adding the directive RequestHeader unset If-Modified-Since into my Apache configuration when processing PHP scripts. This removes the If-Modified-Since header entirely, causing Apache to always return a 200 response. The resulting configuration looks like: SetOutputFilter PHP SetInputFilter PHP LimitRequestBody 524288 RequestHeader unset If-Modified-Since Anyone know of a reason why this might be bad or otherwise won't work? Pm Previous Comments: [2002-12-29 15:56:05] [EMAIL PROTECTED] Try a NON stable snapshot, it's fixed in CVS> Derick [2002-12-29 15:51:59] [EMAIL PROTECTED] Isn't fixed in php4-STABLE-200212290030 Daniel [datenPUNK] Khan [2002-12-27 14:13:19] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-12-27 13:55:15] [EMAIL PROTECTED] ... and the bug is present in 4.3.0 release. [2002-12-25 18:03:55] [EMAIL PROTECTED] ... and it's not fixed in 4.3.0 RC4 either... Daniel 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/17098 -- Edit this bug report at http://bugs.php.net/?id=17098&edit=1
#21395 [NEW]: [chm] bug on function.ftp-connect.html
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.2.3 PHP Bug Type: Other web server Bug description: [chm] bug on function.ftp-connect.html I have found a bug on page function.ftp-connect.html [chm date: 2002-12-27]... http://bugs.php.net/?id=21395&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21395&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21395&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21395&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21395&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21395&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21395&r=support Expected behavior: http://bugs.php.net/fix.php?id=21395&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21395&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21395&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21395&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21395&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21395&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21395&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21395&r=gnused
#21395 [Com]: [chm] bug on function.ftp-connect.html
ID: 21395 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Other web server Operating System: linux PHP Version: 4.2.3 New Comment: You should add a @ for the ftp_connect and ftp_login, etc . Previous Comments: [2003-01-03 13:56:56] [EMAIL PROTECTED] I have found a bug on page function.ftp-connect.html [chm date: 2002-12-27]... http://bugs.php.net/?id=21395&edit=1
#21395 [Opn->Csd]: [chm] bug on function.ftp-connect.html
ID: 21395 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Other web server Operating System: linux PHP Version: 4.2.3 New Comment: This is NOT a bug. You need to enable FTP extension with --enable-ftp, then the functions will work. Thank for your report. Previous Comments: [2003-01-03 14:05:19] [EMAIL PROTECTED] You should add a @ for the ftp_connect and ftp_login, etc . [2003-01-03 13:56:56] [EMAIL PROTECTED] I have found a bug on page function.ftp-connect.html [chm date: 2002-12-27]... http://bugs.php.net/?id=21395&edit=1
#21167 [Fbk->Opn]: ldapclose() SEGFAULTs
ID: 21167 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Linux Redhat 8.0 PHP Version: 4.2.2 New Comment: I've configured PHP-4.3.0 this way: ./configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --prefix=/usr --with-config-file-path=/etc --enable-force-cgi-redirect --enable-debug --enable-pic --disable-rpath --enable-inline-optimization --with-dom=/usr --with-exec-dir=/usr/bin --with-gettext --with-regex=system --with-xml --with-expat-dir=/usr --with-zlib --with-layout=GNU --enable-exif --enable-ftp --enable-magic-quotes --enable-safe-mode --enable-sockets --enable-sysvsem --enable-sysvshm --enable-discard-path --enable-track-vars --enable-trans-sid --with-pear=/usr/share/pear --with-ldap --enable-memory-limit --enable-shmop --enable-versioning but the new core file does not show any debug symbol: [root@avipsa64 vmps]# gdb -c core.23469 GNU gdb Red Hat Linux (5.2.1-4) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux". Core was generated by `/home/rsaura/php-4.3.0/sapi/cgi/php -f pp.php4'. Program terminated with signal 11, Segmentation fault. #0 0x40055615 in ?? () (gdb) bt #0 0x40055615 in ?? () #1 0x4004e62c in ?? () #2 0x4004e38b in ?? () #3 0x4004e66f in ?? () #4 0x08084347 in ?? () #5 0x08155369 in ?? () #6 0x081534e7 in ?? () #7 0x081550c9 in ?? () #8 0x08084aad in ?? () #9 0x0815e1b6 in ?? () #10 0x0814e864 in ?? () #11 0x0811fb1a in ?? () #12 0x08164322 in ?? () #13 0x420158d4 in ?? () (gdb) Previous Comments: [2003-01-03 11:49:36] [EMAIL PROTECTED] Could you compile your PHP with --enable-debug flag, so that your backtrace contains more information. [2003-01-03 09:21:29] [EMAIL PROTECTED] Erroneously closed. The above code segfaults spuriously on 4.2.2, 4.3.0 and 4.4.0-dev (latest CVS snapshot) on RH-8.0 linux system with the following ldap libraries installed: [root@avipsa64 root]# rpm -qa |grep ldap nss_ldap-198-3 openldap-devel-2.0.25-1 openldap-clients-2.0.25-1 openldap-2.0.25-1 SIGSEGVs with CGI and DSO versions. the stack backtrace on the core file shows: [root@avipsa64 vmps]# gdb -c core.22324 GNU gdb Red Hat Linux (5.2.1-4) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux". Core was generated by `/home/rsaura/php-4.3.0/sapi/cgi/php -f pp.php4'. Program terminated with signal 11, Segmentation fault. #0 0x40055615 in ?? () (gdb) bt #0 0x40055615 in ?? () #1 0x4004e62c in ?? () #2 0x4004e38b in ?? () #3 0x4004e66f in ?? () #4 0x0807bbab in ?? () #5 0x081165c1 in ?? () #6 0x081152cb in ?? () #7 0x081163e1 in ?? () #8 0x0807c160 in ?? () #9 0x0811ca3a in ?? () #10 0x08111f0b in ?? () #11 0x080f175c in ?? () #12 0x08120b0f in ?? () #13 0x420158d4 in ?? () (gdb) q [root@avipsa64 vmps]# ldd /home/rsaura/php-4.3.0/sapi/cgi/php libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4001c000) libldap.so.2 => /usr/lib/libldap.so.2 (0x4003d000) liblber.so.2 => /usr/lib/liblber.so.2 (0x40067000) libz.so.1 => /usr/lib/libz.so.1 (0x40072000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4008) libresolv.so.2 => /lib/libresolv.so.2 (0x400ad000) libm.so.6 => /lib/i686/libm.so.6 (0x400bf000) libdl.so.2 => /lib/libdl.so.2 (0x400e2000) libnsl.so.1 => /lib/libnsl.so.1 (0x400e5000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0x400fa000) libc.so.6 => /lib/i686/libc.so.6 (0x4200) libsasl.so.7 => /usr/lib/libsasl.so.7 (0x401a2000) libssl.so.2 => /lib/libssl.so.2 (0x401ad000) libcrypto.so.2 => /lib/libcrypto.so.2 (0x401de000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x402b2000)
#21396 [NEW]: after $var =pack(...) with 'N' flag, if use $var in $tmp[$var]='v' key is empty
From: [EMAIL PROTECTED]
Operating system: w2k, linux
PHP version: 4.2.3
PHP Bug Type: Arrays related
Bug description: after $var =pack(...) with 'N' flag, if use $var in $tmp[$var]='v'
key is empty
just see code
output:
A
;Ð÷
array(3) {
[""]=>
string(2) "aa"
^^^ but needed [""] => "aa" ???
[""]=>
string(2) "bb"
[";Ð÷"]=>
string(2) "cc"
}
WHY ?
--
Edit bug report at http://bugs.php.net/?id=21396&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21396&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21396&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21396&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21396&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21396&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21396&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21396&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21396&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21396&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21396&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21396&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21396&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21396&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21396&r=gnused
#21397 [NEW]: magic_quotes? or some thing is wrongfully modifying specific strings
From: [EMAIL PROTECTED] Operating system: FreeBSD 4.6 Stable PHP version: 4.3.0 PHP Bug Type: Unknown/Other Function Bug description: magic_quotes? or some thing is wrongfully modifying specific strings Something about magic_qoutes (or the URL=>_GET) is adding extra '>' in specific situations. (As if it was trying to close the tags.) For example (magic quotes on). Input$_GET has <[< <[>< <-< <->< And in addition the ,"\n\n" seams to be adding its own '>'. A script showing this problem is below: "; echo "\n"; if ($_GET['text']) echo "htmlentities returns: ",htmlentities($_GET['text']),"\n"; ?> -- Edit bug report at http://bugs.php.net/?id=21397&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21397&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21397&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21397&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21397&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21397&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21397&r=support Expected behavior: http://bugs.php.net/fix.php?id=21397&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21397&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21397&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21397&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21397&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21397&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21397&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21397&r=gnused
#21397 [Opn]: magic_quotes? or some thing is wrongfully modifying specific strings
ID: 21397 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Unknown/Other Function Operating System: FreeBSD 4.6 Stable PHP Version: 4.3.0 New Comment: Thank you for your time, if you have any questions about the script, or need to see it run on our system, please feel free to contact me. -daniel Previous Comments: [2003-01-03 14:28:16] [EMAIL PROTECTED] Something about magic_qoutes (or the URL=>_GET) is adding extra '>' in specific situations. (As if it was trying to close the tags.) For example (magic quotes on). Input$_GET has <[< <[>< <-< <->< And in addition the ,"\n\n" seams to be adding its own '>'. A script showing this problem is below: "; echo "\n"; if ($_GET['text']) echo "htmlentities returns: ",htmlentities($_GET['text']),"\n"; ?> -- Edit this bug report at http://bugs.php.net/?id=21397&edit=1
#17414 [Opn]: Segfaults on restart
ID: 17414
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache2 related
Operating System: Linux
-PHP Version: 4.3.0-dev
+PHP Version: 4.3.0
Assigned To: aaron
New Comment:
Still occurs in 4.3.0
Previous Comments:
[2002-12-10 16:00:46] [EMAIL PROTECTED]
4.3.0 RC2 configured with:
'./configure' '--enable-experimental-zts'
'--with-apxs2=/usr/local/apache2-php/bin/apxs' '--enable-debug'
the phpinfo() function generates the page that is dumped to:
http://samizdat.positive-internet.com/~thom/phpinfo.html
the sequence is:
in ServerRoot:
bin/apachectl start
make connection to verify the server is running, resulting in the above
page.
bin/apachectl restart
apache dies at this point.
this is the error log:
[Tue Dec 10 21:40:23 2002] [notice] Apache/2.0.44-dev (Unix)
PHP/4.3.0RC2 configured -- resuming normal operations
[Tue Dec 10 21:41:51 2002] [notice] SIGHUP received. Attempting to
restart
[Tue Dec 10 21:41:54 2002] [notice] seg fault or similar nasty error
detected in the parent process
(gdb) where
#0 0x4031e2d9 in php_output_activate (tsrm_ls=0x813c0c0)
at /home/thom/php-4.3.0RC2/main/output.c:85
#1 0x4030e86a in php_module_startup (sf=0x4039c460,
additional_modules=0x4039c640, num_additional_modules=1)
at /home/thom/php-4.3.0RC2/main/main.c:1021
#2 0x4035d65e in php_apache2_startup (sapi_module=0x4039c460)
at /home/thom/php-4.3.0RC2/sapi/apache2filter/sapi_apache2.c:269
#3 0x4035dded in php_apache_server_startup (pconf=0x80b60c8,
plog=0x80ee1a8,
ptemp=0x80b80d0, s=0x80f4a60)
at /home/thom/php-4.3.0RC2/sapi/apache2filter/sapi_apache2.c:551
#4 0x0807c381 in ap_run_post_config (pconf=0x80b60c8, plog=0x80ee1a8,
ptemp=0x80b80d0, s=0x80f4a60) at config.c:130
#5 0x08080bbc in main (argc=3, argv=0xbd54) at main.c:640
(gdb) frame 0
#0 0x4031e2d9 in php_output_activate (tsrm_ls=0x813c0c0)
at /home/thom/php-4.3.0RC2/main/output.c:85
85 OG(php_body_write) = php_ub_body_write;
(gdb) frame 1
#1 0x4030e86a in php_module_startup (sf=0x4039c460,
additional_modules=0x4039c640, num_additional_modules=1)
at /home/thom/php-4.3.0RC2/main/main.c:1021
1021php_output_activate(TSRMLS_C);
(gdb) frame 2
#2 0x4035d65e in php_apache2_startup (sapi_module=0x4039c460)
at /home/thom/php-4.3.0RC2/sapi/apache2filter/sapi_apache2.c:269
269 if (php_module_startup(sapi_module, &php_apache_module,
1)==FAILURE) {
(gdb) frame 3
#3 0x4035dded in php_apache_server_startup (pconf=0x80b60c8,
plog=0x80ee1a8,
ptemp=0x80b80d0, s=0x80f4a60)
at /home/thom/php-4.3.0RC2/sapi/apache2filter/sapi_apache2.c:551
551 apache2_sapi_module.startup(&apache2_sapi_module);
[2002-12-08 17:55:57] [EMAIL PROTECTED]
That´s pure luck as GD is not threadsafe.
[2002-12-08 17:53:10] [EMAIL PROTECTED]
If you are compiling Apache 2.0 with worker model you should've used
the --enable-experimental-zts, which enables threading support in PHP,
you didn't do that.
Did you personally see it crash with prefork? I did not and I am
running Apache 2.0.43 (prefork) with PHP 4.3.0-dev and surprisingly it
served some 10,000 requests to PHP script doing GD image manipulations
without a single crash.
[2002-12-08 17:40:58] [EMAIL PROTECTED]
How else do you explain the fact that all current versions of apache2
segfault reproducibly with no options to php barring --enable-debug and
--with-apxs2?
And the *exact* same install functions *perfectly* when php is not
loaded.
I've been told this is producible with prefork, too.
*Please* reread the back traces i've put on this bug. I'm happy to help
in anyway, just don't close valid bugs as bogus.
[2002-12-08 17:29:26] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
GD & freetype libraries are not thread-safe, which means they'll cause
problems in the worker mpm. Use the prefork mpm if you want to use GD
inside your PHP.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/17414
--
Edit this bug report at http://bugs.php.net/?id=17414&edit=1
#21397 [Opn->Csd]: magic_quotes? or some thing is wrongfully modifying specific strings
ID: 21397 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Unknown/Other Function Operating System: FreeBSD 4.6 Stable PHP Version: 4.3.0 New Comment: This seams to be something about my computer. I don't know what is causing it. It happens on IE/NS/Opera Previous Comments: [2003-01-03 14:29:07] [EMAIL PROTECTED] Thank you for your time, if you have any questions about the script, or need to see it run on our system, please feel free to contact me. -daniel [2003-01-03 14:28:16] [EMAIL PROTECTED] Something about magic_qoutes (or the URL=>_GET) is adding extra '>' in specific situations. (As if it was trying to close the tags.) For example (magic quotes on). Input$_GET has <[< <[>< <-< <->< And in addition the ,"\n\n" seams to be adding its own '>'. A script showing this problem is below: "; echo "\n"; if ($_GET['text']) echo "htmlentities returns: ",htmlentities($_GET['text']),"\n"; ?> -- Edit this bug report at http://bugs.php.net/?id=21397&edit=1
#21395 [Csd->Bgs]: [chm] bug on function.ftp-connect.html
ID: 21395 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Bogus Bug Type: Other web server Operating System: linux PHP Version: 4.2.3 Previous Comments: [2003-01-03 14:07:07] [EMAIL PROTECTED] This is NOT a bug. You need to enable FTP extension with --enable-ftp, then the functions will work. Thank for your report. [2003-01-03 14:05:19] [EMAIL PROTECTED] You should add a @ for the ftp_connect and ftp_login, etc . [2003-01-03 13:56:56] [EMAIL PROTECTED] I have found a bug on page function.ftp-connect.html [chm date: 2002-12-27]... http://bugs.php.net/?id=21395&edit=1
#21397 [Csd->Opn]: magic_quotes? or some thing is wrongfully modifying specific strings
ID: 21397 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Unknown/Other Function Operating System: FreeBSD 4.6 Stable PHP Version: 4.3.0 New Comment: I ran that script, and the output was as could be expected might I ask what version of PHP you are running? i might be a very old one which had a bug like that, though that is quite unlikely Previous Comments: [2003-01-03 14:46:24] [EMAIL PROTECTED] This seams to be something about my computer. I don't know what is causing it. It happens on IE/NS/Opera [2003-01-03 14:29:07] [EMAIL PROTECTED] Thank you for your time, if you have any questions about the script, or need to see it run on our system, please feel free to contact me. -daniel [2003-01-03 14:28:16] [EMAIL PROTECTED] Something about magic_qoutes (or the URL=>_GET) is adding extra '>' in specific situations. (As if it was trying to close the tags.) For example (magic quotes on). Input$_GET has <[< <[>< <-< <->< And in addition the ,"\n\n" seams to be adding its own '>'. A script showing this problem is below: "; echo "\n"; if ($_GET['text']) echo "htmlentities returns: ",htmlentities($_GET['text']),"\n"; ?> -- Edit this bug report at http://bugs.php.net/?id=21397&edit=1
#21398 [NEW]: absolute path problems when include_path is set...
From: [EMAIL PROTECTED] Operating system: Win2K PHP version: 4.3.0 PHP Bug Type: Scripting Engine problem Bug description: absolute path problems when include_path is set... If include_path in php.ini is set, absolute paths with include and include_once do not work. If include_path is commented out with ; in php.ini they work fine. \ -- Edit bug report at http://bugs.php.net/?id=21398&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21398&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21398&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21398&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21398&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21398&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21398&r=support Expected behavior: http://bugs.php.net/fix.php?id=21398&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21398&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21398&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21398&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21398&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21398&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21398&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21398&r=gnused
#21397 [Opn]: magic_quotes? or some thing is wrongfully modifying specific strings
ID: 21397 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Unknown/Other Function Operating System: FreeBSD 4.6 Stable PHP Version: 4.3.0 New Comment: Thank you for your time, It is something about my computer, I tried this bug on netscape, ie, opera (latests), and it appeared on all of them, but when I checked on another computer, it didn't have that problem. I have no idea whats going on. I think re-install windows 2000 -again. (I do this about 2 or 3 times a year.) -daniel Previous Comments: [2003-01-03 15:32:47] [EMAIL PROTECTED] I ran that script, and the output was as could be expected might I ask what version of PHP you are running? i might be a very old one which had a bug like that, though that is quite unlikely [2003-01-03 14:46:24] [EMAIL PROTECTED] This seams to be something about my computer. I don't know what is causing it. It happens on IE/NS/Opera [2003-01-03 14:29:07] [EMAIL PROTECTED] Thank you for your time, if you have any questions about the script, or need to see it run on our system, please feel free to contact me. -daniel [2003-01-03 14:28:16] [EMAIL PROTECTED] Something about magic_qoutes (or the URL=>_GET) is adding extra '>' in specific situations. (As if it was trying to close the tags.) For example (magic quotes on). Input$_GET has <[< <[>< <-< <->< And in addition the ,"\n\n" seams to be adding its own '>'. A script showing this problem is below: "; echo "\n"; if ($_GET['text']) echo "htmlentities returns: ",htmlentities($_GET['text']),"\n"; ?> -- Edit this bug report at http://bugs.php.net/?id=21397&edit=1
#21397 [Opn->Csd]: magic_quotes? or some thing is wrongfully modifying specific strings
ID: 21397 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Unknown/Other Function Operating System: FreeBSD 4.6 Stable PHP Version: 4.3.0 New Comment: I am closing this bug, as it is a problem on my client (W2k) side, and the server (FreeBSD) is ok. -daniel Previous Comments: [2003-01-03 16:01:29] [EMAIL PROTECTED] Thank you for your time, It is something about my computer, I tried this bug on netscape, ie, opera (latests), and it appeared on all of them, but when I checked on another computer, it didn't have that problem. I have no idea whats going on. I think re-install windows 2000 -again. (I do this about 2 or 3 times a year.) -daniel [2003-01-03 15:32:47] [EMAIL PROTECTED] I ran that script, and the output was as could be expected might I ask what version of PHP you are running? i might be a very old one which had a bug like that, though that is quite unlikely [2003-01-03 14:46:24] [EMAIL PROTECTED] This seams to be something about my computer. I don't know what is causing it. It happens on IE/NS/Opera [2003-01-03 14:29:07] [EMAIL PROTECTED] Thank you for your time, if you have any questions about the script, or need to see it run on our system, please feel free to contact me. -daniel [2003-01-03 14:28:16] [EMAIL PROTECTED] Something about magic_qoutes (or the URL=>_GET) is adding extra '>' in specific situations. (As if it was trying to close the tags.) For example (magic quotes on). Input$_GET has <[< <[>< <-< <->< And in addition the ,"\n\n" seams to be adding its own '>'. A script showing this problem is below: "; echo "\n"; if ($_GET['text']) echo "htmlentities returns: ",htmlentities($_GET['text']),"\n"; ?> -- Edit this bug report at http://bugs.php.net/?id=21397&edit=1
#21398 [Opn->Fbk]: absolute path problems when include_path is set...
ID: 21398 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Win2K PHP Version: 4.3.0 New Comment: Can you please give us a script that reproduce your problem so we can really check the issue? Thank you for your report. Previous Comments: [2003-01-03 15:49:30] [EMAIL PROTECTED] If include_path in php.ini is set, absolute paths with include and include_once do not work. If include_path is commented out with ; in php.ini they work fine. \ -- Edit this bug report at http://bugs.php.net/?id=21398&edit=1
#11468 [Com]: Cannot execute stored procedures
ID: 11468 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: InterBase related Operating System: Win32, Linux PHP Version: 4.0.5 New Comment: This feature is still missing in PHP 4.3.0. Patch is available and working (I am using it for more than one year by now). Is there a reason why this should not be implemented? Previous Comments: [2002-08-13 23:49:58] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- 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-02-13 12:12:47] [EMAIL PROTECTED] Stored procedures may be executed, but if stored procedure return some data, I don't want how to get it. Yes some way is by select SQL command and SUSPEND in procedure, but it is not ideal way. May someone tell me how do it? [2001-06-13 12:25:03] [EMAIL PROTECTED] Hello, when I wrote some scripts that inserting some data to database, I must call stored procedures for getting some data (typically id from generator). I want execute stored procedures, that return next row id. I add some code to interbase PHP module, that support execution of stored procedures. With my patch, procedure is executed by $res = ibase_query($db, "execute procedure procedure_name"); $row = ibase_fetch_row($res); In $row is row returned by procedure. Patch may be found on http://www.penguin.cz/~michlv/software/phpibase/ If any question write me. Vladimir Michl <[EMAIL PROTECTED]> PS: Patch is ported from 4.0.3pl1 where is functional. -- Edit this bug report at http://bugs.php.net/?id=11468&edit=1
#21399 [NEW]: strtotime() request
From: [EMAIL PROTECTED] Operating system: PHP version: 4CVS-2003-01-03 (dev) PHP Bug Type: Feature/Change Request Bug description: strtotime() request Derick, Make strtotime() recognize "MMDDhhmmss [ZZZ]" strings. Pretty please. - Colin -- Edit bug report at http://bugs.php.net/?id=21399&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21399&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21399&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21399&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21399&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21399&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21399&r=support Expected behavior: http://bugs.php.net/fix.php?id=21399&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21399&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21399&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21399&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21399&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21399&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21399&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21399&r=gnused
#21399 [Opn->Asn]: strtotime() request
ID: 21399 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type:Feature/Change Request PHP Version: 4CVS-2003-01-03 (dev) Assigned To: derick New Comment: blah blah blah do it yourself :-) (assigned to me) Previous Comments: [2003-01-03 16:46:56] [EMAIL PROTECTED] Derick, Make strtotime() recognize "MMDDhhmmss [ZZZ]" strings. Pretty please. - Colin -- Edit this bug report at http://bugs.php.net/?id=21399&edit=1
#21333 [Com]: Nesting level too deep - recursive dependency?
ID: 21333 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: RedHat Linux 8.0 PHP Version: 4.3.0 New Comment: Okay, I solved my own problem with a little help from a comment in bug 21206. My /etc/php.ini file was pointing to the RedHat-supplied modules in /usr/lib/php4. I was able to fix the problem by changing the line in /etc/php.ini that says: extension_dir = /usr/lib/php4 to point to the new location of the modules. This is where the imap.so, ldap.so, mysql.so, etc are. Alternatively, you could copy the newly-compiled modules from the compile-directory/modules up to /usr/lib/php4. Now, mine works perfectly. Previous Comments: [2003-01-03 02:20:07] [EMAIL PROTECTED] I'm seeing the same problem with a very similar config: RH8.0, php4-STABLE-200301020430 even running the command line tool gives this result, so I believe this is independent of the apache version: echo "" | ./php Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0 I did a make test and submitted it to QA. I hope this helps. [2003-01-02 06:08:49] [EMAIL PROTECTED] Unfortunately I can not send the "make test" results because the company where I work has too much restrictive firewall rules (paranoid grade): Form upload limits, no pop3 clients, password protected proxy, ... All that I can currently tell you is that I have the same problem even with a much simpler PHP configuration: ./configure i386-redhat-linux \ --with-apxs2=/usr/sbin/apxs \ --with-config-file-path=/etc [2003-01-02 04:54:17] [EMAIL PROTECTED] Please run a "make test" after compiling PHP with "make" in the source directory and press "y" if it asks to send the information to the QA site. Derick [2003-01-02 04:47:34] [EMAIL PROTECTED] This error message appears on every script, even in this one: This is just as it looks at the end of ANY php page: "Fatal error: Nesting level too deep - recursive dependency? in Unknown on line 0" Environment: RedHat Linux8.0 Kernel 2.4.18-14 Apache 2.0.40 PHP 4.3.0 And this is how I compiled PHP: ./configure i386-redhat-linux \ --with-apxs2=/usr/sbin/apxs \ --with-config-file-path=/etc \ --with-gd \ --with-zlib \ --enable-ftp \ --with-mysql \ --with-informix=/opt/informix \ --enable-sockets -- Edit this bug report at http://bugs.php.net/?id=21333&edit=1
#21400 [NEW]: Problem writing to Excel spreadsheet via COM
From: [EMAIL PROTECTED] Operating system: Win 2000 PHP version: 4.3.0 PHP Bug Type: COM related Bug description: Problem writing to Excel spreadsheet via COM When using COM to write to an Excel spreadsheet, my PHP script can write to cells in column "A", but when I try to write to cells in any other column, the script appears to terminate without sending anything to the browser (a 404 response). The script works OK with 4.2.3, except an Excel "zombie" process remains after the script is finished (this "zombie" bug appears to be fixed with 4.3.0, only to introduce this new problem). -- Edit bug report at http://bugs.php.net/?id=21400&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21400&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21400&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21400&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21400&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21400&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21400&r=support Expected behavior: http://bugs.php.net/fix.php?id=21400&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21400&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21400&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21400&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21400&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21400&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21400&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21400&r=gnused
#21279 [Bgs->Opn]: odbc_fetch_into returns empty strings for columns with NULL values
ID: 21279
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: ODBC related
Operating System: Windows
PHP Version: 4.3.0
New Comment:
What I meant is that every SQL based PHP database API has a function to
fetch rows into an array. When it is not not *_fetch_into is
*_fetch_row.
I do not see any ambiguity in figuring if a result column has a NULL.
As a matter of fact in the current odbc_function of php_odbc.c you
have:
http://cvs.php.net/co.php/php4/ext/odbc/php_odbc.c?r=1.143.2.1
if (result->values[i].vallen == SQL_NULL_DATA) {
Z_STRVAL_P(tmp) = empty_string;
break;
}
Since NULL is always NULL regardless of the data type of a column, all
that needs to be done is to leave undefined (NULL) the respective
column position of the PHP array value returned by the odbc_fetch_into.
Previous Comments:
[2003-01-03 12:10:44] [EMAIL PROTECTED]
Which other API's are you talking about? Oracle? It's the only other
extension that uses fetch into really.
As for the statement, there is no way for ODBC to really tell either.
The API itself defines this to be rather ambiguous so it becomes
difficult to deal with. At this time the result leaves it to the PHP
user to decide if one is really an emtpy string or NULL rather than the
PHP engine. I tend to think this is a better solution.
[2002-12-29 19:47:04] [EMAIL PROTECTED]
odbc_fetch_into returns empty strings for columns with NULL values.
This makes it impossible to distinguish whether a result column value
is a real empty string or a NULL, unlike with API functions for the
same purpose but for other databases.
--
Edit this bug report at http://bugs.php.net/?id=21279&edit=1
#21399 [Asn]: strtotime() request
ID: 21399 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type:Feature/Change Request PHP Version: 4CVS-2003-01-03 (dev) Assigned To: derick New Comment: you're a famous man derick ;) Previous Comments: [2003-01-03 16:48:28] [EMAIL PROTECTED] blah blah blah do it yourself :-) (assigned to me) [2003-01-03 16:46:56] [EMAIL PROTECTED] Derick, Make strtotime() recognize "MMDDhhmmss [ZZZ]" strings. Pretty please. - Colin -- Edit this bug report at http://bugs.php.net/?id=21399&edit=1
#21398 [Fbk->Opn]: absolute path problems when include_path is set...
ID: 21398
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Win2K
PHP Version: 4.3.0
New Comment:
I've tried to write a script to regenerate the behavior. I think I've
missed something or php.ini settings were cached somehow. Now,
everything seems working fine. Sorry for bothering you guys. But I
still have a question. In old versions (4.1.x) when giving an absolute
path like :
include ("\includesdir\includedfile.php");
everything was working fine. With 4.3.0 the leading backslash is
causing problems and makes php report "failed to create stream". But
include ("includesdir\includedfile.php");
works.
Is there something I'm missing? If the reason is a structural change, I
thought, there should be a switch to set this behavior but couldn't
find anything related.
Thanks for the quick reply and I'm really sorry to waste your time.
I'd really appreciate it if you can answer my question.
Previous Comments:
[2003-01-03 16:25:32] [EMAIL PROTECTED]
Can you please give us a script that reproduce your problem so we can
really check the issue?
Thank you for your report.
[2003-01-03 15:49:30] [EMAIL PROTECTED]
If include_path in php.ini is set, absolute paths with include and
include_once do not work. If include_path is commented out with ; in
php.ini they work fine. \
--
Edit this bug report at http://bugs.php.net/?id=21398&edit=1
#21398 [Opn->Bgs]: absolute path problems when include_path is set...
ID: 21398
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Win2K
PHP Version: 4.3.0
New Comment:
No problem.
About your question, we now have a new stream handler (thanks Wez).
Since you're working on Windows you need to give the complete directory
if you are starting with '\' so like C:\includedir\lala\lala.php but
I'm sure you should prefer to use C:/ and not C:\ so you will not need
to use \\ Sometimes.
If you need more help about the way directories work,please ask in
[EMAIL PROTECTED]
Thank for your report.
Previous Comments:
[2003-01-03 17:24:05] [EMAIL PROTECTED]
I've tried to write a script to regenerate the behavior. I think I've
missed something or php.ini settings were cached somehow. Now,
everything seems working fine. Sorry for bothering you guys. But I
still have a question. In old versions (4.1.x) when giving an absolute
path like :
include ("\includesdir\includedfile.php");
everything was working fine. With 4.3.0 the leading backslash is
causing problems and makes php report "failed to create stream". But
include ("includesdir\includedfile.php");
works.
Is there something I'm missing? If the reason is a structural change, I
thought, there should be a switch to set this behavior but couldn't
find anything related.
Thanks for the quick reply and I'm really sorry to waste your time.
I'd really appreciate it if you can answer my question.
[2003-01-03 16:25:32] [EMAIL PROTECTED]
Can you please give us a script that reproduce your problem so we can
really check the issue?
Thank you for your report.
[2003-01-03 15:49:30] [EMAIL PROTECTED]
If include_path in php.ini is set, absolute paths with include and
include_once do not work. If include_path is commented out with ; in
php.ini they work fine. \
--
Edit this bug report at http://bugs.php.net/?id=21398&edit=1
#20195 [Opn->Fbk]: make install doesnt set permissions
ID: 20195 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *General Issues Operating System: linux PHP Version: 4.2.3 New Comment: Do you still experiment the problem with PHP 4.3.0 ? (can you verify the permission of pear in /usr/local/bin/pear by default too? ) Thank you for your report. Previous Comments: [2002-11-04 00:09:35] [EMAIL PROTECTED] no comments anymore, sniper? [2002-10-31 14:23:54] [EMAIL PROTECTED] POSTs are infected as the php binary is created correctly (gcc gives it the right permission) but include files and other folders have wrong permissions, so POSTs dont work. Using the "install" programm with its arguments to set permissions, owner and group would solve this problem. [2002-10-31 13:51:46] [EMAIL PROTECTED] Hardly every files are installed incorrectly, even directories are not set to 755. Normally "make install" uses "install" i think (apache does so) and they use the options -g, -m and -o to set group, mode and owner of the files, php does not, it just creates the files and this normaly uses the permission a user set with 'umask' like you create a file with touch or so. [2002-10-31 12:01:58] [EMAIL PROTECTED] Exactly what files are installed with wrong permissions?? (and how can this affect the POSTs at all? :) [2002-10-31 11:30:16] [EMAIL PROTECTED] make install doesnt set proper permissions to the installed files. (All other programs do so). If you have set "umask 077" you'll get an unusable php installation, and for example POST-data cant be submitted in a form. This thing caused me compiling php 20 times and loosing the whole day. -- Edit this bug report at http://bugs.php.net/?id=20195&edit=1
#21400 [Opn]: Problem writing to Excel spreadsheet via COM
ID: 21400 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: COM related Operating System: Win 2000 PHP Version: 4.3.0 New Comment: Here's some more info: It should be noted that the Excel spreadsheet and its macros *actually do work*, even though PHP or Apache or whoever it is is sending a 404. I know this, because after I'm done with Excel, I stream its HTML output file using readfile() and flush(). If I put a sleep() right after the readfile() and flush(), I can see the spreadsheet and chart in the browser. As soon as the sleep() expires and the script terminates, I get the 404. The HTML file that Excel created still exists, I can enter its URL in my browser and view it OK. Working back and commenting out stuff, I found that selecting or writing to cells in any column other than "A" causes the 404 to happen. Unfortunately, my Excel macros don't work too well when I do that. ;-) Previous Comments: [2003-01-03 17:01:58] [EMAIL PROTECTED] When using COM to write to an Excel spreadsheet, my PHP script can write to cells in column "A", but when I try to write to cells in any other column, the script appears to terminate without sending anything to the browser (a 404 response). The script works OK with 4.2.3, except an Excel "zombie" process remains after the script is finished (this "zombie" bug appears to be fixed with 4.3.0, only to introduce this new problem). -- Edit this bug report at http://bugs.php.net/?id=21400&edit=1
#20195 [Fbk->Opn]: make install doesnt set permissions
ID: 20195 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: *General Issues Operating System: linux PHP Version: 4.2.3 New Comment: no, i changed my umask for root back to 022, since some other apps had the same problems, but i still think, that we should use "install" to copy the files Previous Comments: [2003-01-03 17:37:21] [EMAIL PROTECTED] Do you still experiment the problem with PHP 4.3.0 ? (can you verify the permission of pear in /usr/local/bin/pear by default too? ) Thank you for your report. [2002-11-04 00:09:35] [EMAIL PROTECTED] no comments anymore, sniper? [2002-10-31 14:23:54] [EMAIL PROTECTED] POSTs are infected as the php binary is created correctly (gcc gives it the right permission) but include files and other folders have wrong permissions, so POSTs dont work. Using the "install" programm with its arguments to set permissions, owner and group would solve this problem. [2002-10-31 13:51:46] [EMAIL PROTECTED] Hardly every files are installed incorrectly, even directories are not set to 755. Normally "make install" uses "install" i think (apache does so) and they use the options -g, -m and -o to set group, mode and owner of the files, php does not, it just creates the files and this normaly uses the permission a user set with 'umask' like you create a file with touch or so. [2002-10-31 12:01:58] [EMAIL PROTECTED] Exactly what files are installed with wrong permissions?? (and how can this affect the POSTs 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/20195 -- Edit this bug report at http://bugs.php.net/?id=20195&edit=1
#21401 [NEW]: Apache doesn't start with php 4.3.0 php4ts.dll
From: [EMAIL PROTECTED] Operating system: Windows XP Professional PHP version: 4.3.0 PHP Bug Type: Apache related Bug description: Apache doesn't start with php 4.3.0 php4ts.dll Windows XP Professional Service Pack 1, Apache 1.3.27, php 4.3.0 as apache-modul, phplib + tomcat 3.3.1 testing apache: httpd.conf Syntax O.K. But I can't start Apache with php 4.3.0 Starting Apache has as result only the Windows-Error-Massage: "Apache.exe hat ein Problem festgestellt und muss beendet werden.", what means: "Apache.exe has detected a problem and must be shut down" Problemsignatur: szAppName : Apache.exe szAppVer : 0.0.0.0 szModName : php4ts.dll szModVer : 4.3.0.0 offset : 000af8ee Files send to M$ C:\DOKUME~1\Michael\LOKALE~1\Temp\WERA.tmp.dir00\Apache.exe.mdmp C:\DOKUME~1\Michael\LOKALE~1\Temp\WERA.tmp.dir00\appcompat.txt If I substitute the php4ts.dll in C:\Windows\system32 with the "old" 4.2.3-version, everything works well, allthough the php.ini and all other *.dll-files are version 4.3.0. The failure is only with the php4ts.dll-file and Windows. I have downloaded the Zip-file from another mirror, because I thought, the file might be demaged. No result. I think the failure is rather Windows ?? than php and reportet the failure to M$ too. Thanks for help. If there is no solution I work with the old version. Michael. -- Edit bug report at http://bugs.php.net/?id=21401&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21401&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21401&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21401&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21401&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21401&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21401&r=support Expected behavior: http://bugs.php.net/fix.php?id=21401&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21401&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21401&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21401&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21401&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21401&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21401&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21401&r=gnused
#21405 [NEW]: Application popup: php.exe - Application Error
From: [EMAIL PROTECTED] Operating system: windows2000 PHP version: 4.2.3 PHP Bug Type: Compile Failure Bug description: Application popup: php.exe - Application Error Application popup: php.exe - Application Error : The instruction at "0x77fca8ac" referenced memory at "0x00080101". The memory could not be "written". (The instruction address here may vary by about 16 bytes; the memory address has always been 0x00080101 or 0x00080100) The requests are in fact processed correctly and there is no trace of a message in the PHP error logs. -- Edit bug report at http://bugs.php.net/?id=21405&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21405&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21405&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21405&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21405&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21405&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21405&r=support Expected behavior: http://bugs.php.net/fix.php?id=21405&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21405&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21405&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21405&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21405&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21405&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21405&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21405&r=gnused
#21405 [Opn]: Application popup: php.exe - Application Error
ID: 21405 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: windows2000 PHP Version: 4.2.3 New Comment: just wanted add some more Previous Comments: [2003-01-03 22:12:02] [EMAIL PROTECTED] Application popup: php.exe - Application Error : The instruction at "0x77fca8ac" referenced memory at "0x00080101". The memory could not be "written". (The instruction address here may vary by about 16 bytes; the memory address has always been 0x00080101 or 0x00080100) The requests are in fact processed correctly and there is no trace of a message in the PHP error logs. -- Edit this bug report at http://bugs.php.net/?id=21405&edit=1
#21405 [Opn]: Application popup: php.exe - Application Error
ID: 21405 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: windows2000 PHP Version: 4.2.3 New Comment: just wanted add some more comments after displaying this error the compilation stops at that particular instance and rest is left uncompiled Previous Comments: [2003-01-03 22:13:50] [EMAIL PROTECTED] just wanted add some more [2003-01-03 22:12:02] [EMAIL PROTECTED] Application popup: php.exe - Application Error : The instruction at "0x77fca8ac" referenced memory at "0x00080101". The memory could not be "written". (The instruction address here may vary by about 16 bytes; the memory address has always been 0x00080101 or 0x00080100) The requests are in fact processed correctly and there is no trace of a message in the PHP error logs. -- Edit this bug report at http://bugs.php.net/?id=21405&edit=1
#21406 [NEW]: Appending same filter twice causes segfault
From: [EMAIL PROTECTED]
Operating system: linux
PHP version: 4CVS-2003-01-03 (dev)
PHP Bug Type: Filesystem function related
Bug description: Appending same filter twice causes segfault
The following code works fine when "stream_filter_append()" is called only
once. Adding the second call causes a segfault when fclose() is called.
= 'A' AND $tempstr[$i] <= 'M') OR
($tempstr[$i] >= 'a' AND $tempstr[$i] <= 'm')) $tempstr[$i] =
chr(ord($tempstr[$i]) + 13);
else if (($tempstr[$i] >= 'N' AND $tempstr[$i] <= 'Z') OR
($tempstr[$i] >= 'n' AND $tempstr[$i] <= 'z')) $tempstr[$i]
= chr(ord($tempstr[$i]) - 13);
return $tempstr;
}
function write($data) {
for($i = 0; $i < strlen($data); $i++)
if (($data[$i] >= 'A' AND $data[$i] <= 'M') OR
($data[$i] >= 'a' AND $data[$i] <= 'm')) $data[$i] =
chr(ord($data[$i]) + 13);
else if (($data[$i] >= 'N' AND $data[$i] <= 'Z') OR
($data[$i] >= 'n' AND $data[$i] <= 'z')) $data[$i] =
chr(ord($data[$i]) - 13);
return parent::write($data);
}
}
stream_register_filter("rot13", "rot13_filter")
or die("Failed to register filter");
$fp = fopen("foo-bar.txt", "r");
stream_filter_append($fp, "rot13");
stream_filter_append($fp, "rot13");
fwrite($fp, "Line1\n");
fwrite($fp, "Word - 2\n");
fwrite($fp, "Easy As 123\n");
fclose($fp);
?>
--
Edit bug report at http://bugs.php.net/?id=21406&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21406&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21406&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21406&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21406&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21406&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21406&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21406&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21406&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21406&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21406&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21406&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21406&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21406&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21406&r=gnused
#21407 [NEW]: the use of `tempnam' is dangerous, better use `mkstemp'
From: [EMAIL PROTECTED] Operating system: redhat 8 PHP version: 4.3.0 PHP Bug Type: Compile Failure Bug description: the use of `tempnam' is dangerous, better use `mkstemp' I upgrade to php-4.3.0 from 4.2.3 thru mysql 3.23.54a rpm packages in redhat 8. mysql started already then install php in static module style cd apache_1.3.27 ./configure cd php-4.3.0 ./configure \ --with-apache=../apache_1.3.27 \ --with-config-file-path=/var/www/conf \ --with-mysql \ --enable-bcmath \ --disable-debug \ --enable-track-vars \ --enable-i18n \ --enable-mbregex \ make then error is ... -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -o sapi/cli/php ext/mysql/libmysql/my_tempnam.o: In function `my_tempnam': /root/php-4.3.0/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp' -- Edit bug report at http://bugs.php.net/?id=21407&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21407&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21407&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21407&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21407&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21407&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21407&r=support Expected behavior: http://bugs.php.net/fix.php?id=21407&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21407&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21407&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21407&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21407&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21407&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21407&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21407&r=gnused
#21406 [Opn]: Appending same filter twice causes segfault
ID: 21406
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Filesystem function related
Operating System: linux
PHP Version: 4CVS-2003-01-03 (dev)
New Comment:
Correction... Any two filters:
stream_filter_append($fp, "rot13");
stream_filter_append($fp, "rot13");
or
stream_filter_append($fp, "rot13");
stream_filter_append($fp, "default");
or
stream_filter_append($fp, "default");
stream_filter_append($fp, "default");
all produce the same segfault when fclose()ing (presumably during the
calls to write() or flush() in the filters).
Note: "default" was previously registered using:
stream_register_filter("default", "php_user_filter");
Previous Comments:
[2003-01-03 22:30:11] [EMAIL PROTECTED]
The following code works fine when "stream_filter_append()" is called
only once. Adding the second call causes a segfault when fclose() is
called.
= 'A' AND $tempstr[$i] <= 'M') OR
($tempstr[$i] >= 'a' AND $tempstr[$i] <= 'm')) $tempstr[$i] =
chr(ord($tempstr[$i]) + 13);
else if (($tempstr[$i] >= 'N' AND $tempstr[$i] <= 'Z') OR
($tempstr[$i] >= 'n' AND $tempstr[$i] <= 'z'))
$tempstr[$i] = chr(ord($tempstr[$i]) - 13);
return $tempstr;
}
function write($data) {
for($i = 0; $i < strlen($data); $i++)
if (($data[$i] >= 'A' AND $data[$i] <= 'M') OR
($data[$i] >= 'a' AND $data[$i] <= 'm')) $data[$i] =
chr(ord($data[$i]) + 13);
else if (($data[$i] >= 'N' AND $data[$i] <= 'Z') OR
($data[$i] >= 'n' AND $data[$i] <= 'z')) $data[$i] =
chr(ord($data[$i]) - 13);
return parent::write($data);
}
}
stream_register_filter("rot13", "rot13_filter")
or die("Failed to register filter");
$fp = fopen("foo-bar.txt", "r");
stream_filter_append($fp, "rot13");
stream_filter_append($fp, "rot13");
fwrite($fp, "Line1\n");
fwrite($fp, "Word - 2\n");
fwrite($fp, "Easy As 123\n");
fclose($fp);
?>
--
Edit this bug report at http://bugs.php.net/?id=21406&edit=1
#21407 [Opn->Bgs]: the use of `tempnam' is dangerous, better use `mkstemp'
ID: 21407 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: redhat 8 PHP Version: 4.3.0 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. Please use the advanced search feature of the bugs.php.net website. Several people have reported this warning (yes: warning, not failure) and have been given an explanation for why it occours. I'll be nice and save you the trouble of clicking "search" just this once: Your compile was successful. While compiling sapi/cli/php a WARNING was issued. You probably saw the same error a few lines up during the compile of sapi/cgi/php. Note: warnings do not stop compilations, only errors do that. Ignore this error for now. It has been resolved in CVS already so that the next release of PHP will not show this. Previous Comments: [2003-01-03 22:33:20] [EMAIL PROTECTED] I upgrade to php-4.3.0 from 4.2.3 thru mysql 3.23.54a rpm packages in redhat 8. mysql started already then install php in static module style cd apache_1.3.27 ./configure cd php-4.3.0 ./configure \ --with-apache=../apache_1.3.27 \ --with-config-file-path=/var/www/conf \ --with-mysql \ --enable-bcmath \ --disable-debug \ --enable-track-vars \ --enable-i18n \ --enable-mbregex \ make then error is ... -lcrypt -lresolv -lm -ldl -lnsl -lcrypt -o sapi/cli/php ext/mysql/libmysql/my_tempnam.o: In function `my_tempnam': /root/php-4.3.0/ext/mysql/libmysql/my_tempnam.c:103: the use of `tempnam' is dangerous, better use `mkstemp' -- Edit this bug report at http://bugs.php.net/?id=21407&edit=1
#19113 [Com]: HTTP status 200 returned on HTTP CONNECT when mod_proxy not in use
ID: 19113 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: FreeBSD 4.6.2 PHP Version: 4.2.2 New Comment: Problem still exists in PHP 4.3.0, i'm running Apache 1.3.27 on FreeBSD. Previous Comments: [2003-01-02 06:32:47] [EMAIL PROTECTED] I apologise for not being able to test 4.3.0 or any of the "snap" releases prior to now -- we use FreeBSD, and we rely on the FreeBSD port of mod_php4. The port author has not upgraded to 4.3.0 yet, and therefore we were stuck using 4.2.3 until earlier this evening when I removed the port and went with the old method of installing off source manually. It seems that this problem may in fact be fixed in 4.3.0. The problem documented no longer appears. [2002-12-28 01:00:02] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2002-12-18 07:09:42] [EMAIL PROTECTED] Sorry, you don't understand the problem. The problem is that apache returns "HTTP 200 OK" on CONNECT request, but does NOT really connect to specified addrress. If it is possible to connect through your server to outside, then it's problem of your misconfigured proxy. [2002-12-16 13:54:03] [EMAIL PROTECTED] This bug is VERY serious. Our web servers have be attacked and used for relaying SPAM. Spammers are using the CONNECT command to proxy to open relay servers masking their IP addresses with ours. [2002-12-12 05:52:03] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19113 -- Edit this bug report at http://bugs.php.net/?id=19113&edit=1
