#29994 [NEW]: Execution Time Problem
From: tcmleung at yahoo dot com Operating system: Windows XP IIS 5 PHP version: 4.3.8 PHP Bug Type: Unknown/Other Function Bug description: Execution Time Problem Description: The Webserver is IIS 5, with Windows XP, IIS NTLM authentication and SSL encryption. No matter how I set the time limit, the download process would terminate after 5 minutes (300 seconds). See the following sample script. Reproduce code: --- -- Edit bug report at http://bugs.php.net/?id=29994&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29994&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29994&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29994&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=29994&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=29994&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29994&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29994&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29994&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=29994&r=support Expected behavior: http://bugs.php.net/fix.php?id=29994&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=29994&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=29994&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=29994&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29994&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=29994&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29994&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=29994&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29994&r=float
#27290 [Csd->Opn]: warning msg on missing function argument should mention file/line of caller too
ID: 27290 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type:Feature/Change Request PHP Version: 5CVS-2004-02-17 (dev) New Comment: Derick, while this would be the general way to solve this i still believe that the "Missing argument" message should tell the caller position by default, else the message us not really helpfull at all. This case is similar to "headers already sent" IMHO and deserves an error message that helps to solve the problem *without* additional error handling tweaks Previous Comments: [2004-09-06 08:10:18] [EMAIL PROTECTED] Override your error handling function with set_error_handler() and use debug_print_backtrace(), or install Xdebug which automatically does the printing of backtraces for you (http://xdebug.org) [2004-09-03 19:09:47] sean at acidreign dot net over the last few days, I've had to tack down dozens of errors, with out knowing the file/line they actually occur in. reporting the line of the function declaration rather then the line of the offending expression is completely useless. It makes tracking bugs extremely difficult, because it has to be done on a trial and error basis, looking for and testing every place a function is called. [2004-02-17 11:11:08] [EMAIL PROTECTED] Description: usually the location of the caller what you really want to know here, especially if you are trying to track this down from not-so-recent messages in your error_log ... Reproduce code: --- Expected result: Warning: Missing argument 1 for foo() in foo.php on line 2, called in foo.php on line 4 Actual result: -- Warning: Missing argument 1 for foo() in - on line 2 -- Edit this bug report at http://bugs.php.net/?id=27290&edit=1
#29144 [Opn->Fbk]: PHP is not executed/not handling files
ID: 29144 Updated by: [EMAIL PROTECTED] Reported By: php at soapi dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: RedHat Enterprise Linux 3.0 PHP Version: 5.0.0 Previous Comments: [2004-09-06 04:21:17] [EMAIL PROTECTED] Does it work with Apache1 for you? [2004-09-06 03:53:47] jesse at eonstreet dot com I have the same problem. Everything is fine except when I change the http.conf from libphp4 to libphp5. I too believe this is a bug and has something to do with a the way the libphp5.so is tell apache2 how to handle the files. I tried compiling "--with-apxs2" only but that did not work. Neither "--with-apxs2=/usr/sbin/apxs --with-apxs2filter=/usr/sbin/apxs" [2004-07-14 15:05:29] php at soapi dot com I fail to see how this is not a bug. I subscribe to all the relevant PHP newsgroups, and there has been nothing there to help. (The fact that the newsgroups suffer from so much spam probably has a lot to do with it.) I believe this is a bug for the simple reason that PHP4 works perfectly with the same settings, and PHP5 is not handling php scripts. That to me says some bug in how PHP5 is telling Apache what it can handle. If there is anything that should be done in addition to the standard steps of installation, that should be clearly marked out in the documentation. However, there is nothing to suggest that anything else is needed. Finally, please note that I *have* used the support system, and the mailing list/newsgroups, and spent many hours searching and testing before posting this report. I still believe this is a bug. [2004-07-14 14:53:54] [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. It\'s still not a bug, please ask for support on the mailinglist as it works fine for hundreds of others. [2004-07-14 14:41:24] php at soapi dot com Description: First of all, my apologies for adding a new bug, but bug 26492 has been marked as bogus, and although I have added a comment, I cannot reopen it. Therefore as I believe this is indeed a PHP problem, I have created a new entry. After building PHP5.0.0 final today, I am experiencing the exact same problem I have had with RC1, RC2, and RC3. I am currently running Apache 2.0.50, but I have tried with 2.0.48 and 2.0.49 as well. (I spent two full days a couple of weeks ago recompiling many different configurations, with no success.) PHP compiles and installs fine, and Apache loads with no problems. There are no errors listed in the error log (which is set to flag everything) and I don't get any problems other than this one, which is that PHP files are not being processed. I have PHP4.3.8 running right now, and every version of PHP4 has compiled, installed, and run with no problems. I am using an essentially identical configuration line for PHP5, and all I do to swap between the two is change the module that is loaded. Even if I use a very basic Apache and PHP setup, this problem occurs. I am using a standard PHP5 ini file, with only minor changes to point it at the right directories. So. Whenever I use PHP5, all PHP files are offered for download rather than being processed by PHP5. I have tried things like AddHandler php5-script and all sorts, with no success. As far as I am aware, I should not have to do anything substantially different to set up PHP5 than I do for PHP4. Apache info shows that mod_php5.c is loaded successfully, so why doesn't it handle the files? I'm going mad with this. The only thing that is different from a standard installation is that I install PHP4 and PHP5 into their own locations, in order to swap between them. For instance I use 'export EXTENSION_DIR=/usr/lib/php5' and then in the configure line I use '--program-suffix=5 --with-config-file-path=/etc/php5' with the other settings. This is simply to keep the two apart. It would appear that for some reason PHP5 is not properly registering with Apache2 that it can handle the application/x-httpd-php MIME-type, but I have no idea why, because I have 'AddType application/x-httpd-php php' in my httpd.conf file of course. How can I track down the problem? I'm not new to this - I have been a server admin for years (I run www.ithium.net) and I use PHP every day. I have compiled PHP and Apache countless times, and even written tutorials on the subject. So
#29991 [Opn->Fbk]: After compile and install the "php" command returns 'Segmentation fault'
ID: 29991 Updated by: [EMAIL PROTECTED] Reported By: jesse at eonstreet dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: RedHat as 3 PHP Version: 5.0.1 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2004-09-06 02:50:03] jesse at eonstreet dot com The config that I tried was: --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=i386-redhat-linux --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/lib/httpd/modules --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --cache-file=../config.cache --with-config-file-path=/etc --with-curl --with-dom=/usr --with-exec-dir=/usr/bin --with-freetype-dir=/usr --with-png-dir=/usr --with-gd --with-ttf --with-jpeg-dir=/usr --with-openssl --with-png --with-pspell --with-xml --with-zlib ---enable-exif --enable-ftp --enable-magic-quotes --with-pear=/usr/share/pear -with-ldap=shared --with-mysql=shared,/usr --enable-soap --with-libxml-dir=/usr/include/libxml2 --with-apxs2=/usr/sbin/apxs --with-apxs2filter=/usr/sbin/apxs [2004-09-06 02:06:17] jesse at eonstreet dot com Description: Hello, After configuring and compiling php 5.0.1 a number of times I can not get any result except 'Segmentation fault'. Neither the command line nor apache will give any response. I have updated the libxml2 to version 2.6.12 by geting the tar.gz from xmlsoft.org I do not have loadModule php4 anywhere in my httpd.conf [EMAIL PROTECTED] ./configure --(see below) [EMAIL PROTECTED] make [EMAIL PROTECTED] make install [EMAIL PROTECTED] php Segmentation fault if there is a list of extensions that no longer work in php5 or that cause this type of problem it woould be very helpful if someone whould post it or include it in the install docs. ### Configure line ### --host=i686-pc-linux-gnu' '--build=i686-pc-linux-gnu' '--target=i386-redhat-linux' '--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' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-pcre=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--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' '--enable-yp' '--enable-wddx' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-mbregex' '--without-oci8' '--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-ldap=shared' '--with-mysql=shared,/usr' '--with-pgsql=shared' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--with-apxs2filter=/usr/sbin/apxs' -- Edit this bug report at http://bugs.php.net/?id=29991&edit=1
#28382 [Asn]: the openssl_x509_parse function does not extract the certificate extensions
ID: 28382 User updated by: n_sergiu at hotmail dot com Reported By: n_sergiu at hotmail dot com Status: Assigned Bug Type: OpenSSL related Operating System: all PHP Version: 4.3.4 Assigned To: wez New Comment: I think every version have the same problem. You can take a look in the latest PHP source code (src/ext/openssl.c) and you'll see in the openssl_x509_parse function no code that should manage the extensions. Previous Comments: [2004-09-05 08:22:26] jadevree at mtu dot edu I suffer the same problem under 4.3.8 on Solaris 8 with Apache 1.3.31. Also using Apache 2.0.50 + php 4.3.8 from Debian SID. [2004-05-14 15:47:25] n_sergiu at hotmail dot com Here is a certificate for testing: -BEGIN CERTIFICATE- MIIEoDCCBAmgAwIBAgIBJzANBgkqhkiG9w0BAQQFADCBkDELMAkGA1UEBhMCUk8x EDAOBgNVBAgTB1JvbWFuaWExEDAOBgNVBAcTB0NyYWlvdmExDzANBgNVBAoTBlNl cmdpdTETMBEGA1UECxMKU2VyZ2l1IFNSTDESMBAGA1UEAxMJU2VyZ2l1IENBMSMw IQYJKoZIhvcNAQkBFhRuX3NlcmdpdUBob3RtYWlsLmNvbTAeFw0wNDA1MTQxMzM0 NTZaFw0wNTA1MTQxMzM0NTZaMIGaMQswCQYDVQQGEwJSTzEQMA4GA1UECBMHUm9t YW5pYTEQMA4GA1UEBxMHQ3JhaW92YTETMBEGA1UEChMKU2VyZ2l1IFNSTDETMBEG A1UECxMKU2VyZ2l1IFNSTDEYMBYGA1UEAxMPU2VyZ2l1IHBlcnNvbmFsMSMwIQYJ KoZIhvcNAQkBFhRuX3NlcmdpdUBob3RtYWlsLmNvbTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEApNj7XXz8T8FcLIWpBniPYom3QcT6T7u0xRPHqtqzj5oboBYp DJe5d354/y0gJTpiLt8+fTrPgWXnbHm3pOHgXzTcX6Arani0GDU0/xDi4VkCRGcS YqX2sJpcDzAbmK9UDMt3xf/O1B8AJan3RfO0Bm3ozTEPziLMkmsiYr5b/L8CAwEA AaOCAfwwggH4MAkGA1UdEwQCMAAwNQYJYIZIAYb4QgENBCgWJkZvciBHcmlkIHVz ZSBvbmx5OyByZXF1ZXN0IHRhZyB1c2VyVGFnMBEGCWCGSAGG+EIBAQQEAwIF4DA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vbW9iaWxlLmJsdWUtc29mdHdhcmUucm86 OTAvY2EvY3JsLnNodG1sMDUGCWCGSAGG+EIBCAQoFiZodHRwOi8vbW9iaWxlLmJs dWUtc29mdHdhcmUucm86OTAvcHViLzAhBgNVHREEGjAYgRZzZXJnaXVAYmx1ZXNv ZnR3YXJlLnJvMB0GA1UdDgQWBBSwp//5QRXeIzm93TEPl6CyonTg/DCBpwYDVR0j BIGfMIGcoYGWpIGTMIGQMQswCQYDVQQGEwJSTzEQMA4GA1UECBMHUm9tYW5pYTEQ MA4GA1UEBxMHQ3JhaW92YTEPMA0GA1UEChMGU2VyZ2l1MRMwEQYDVQQLEwpTZXJn aXUgU1JMMRIwEAYDVQQDEwlTZXJnaXUgQ0ExIzAhBgkqhkiG9w0BCQEWFG5fc2Vy Z2l1QGhvdG1haWwuY29tggEAMAsGA1UdDwQEAwIE8DAjBglghkgBhvhCAQIEFhYU aHR0cDovLzYyLjIzMS45OC41Mi8wCwYDKgMEBAQ+52I0MA0GCSqGSIb3DQEBBAUA A4GBAIBIOJ+iiLyQfNJEY+IMefayQea0nmuXYY+F+L1DFjSC7xChytgYoPNnKkhh 3dWPtxbswiqKYUnGi6y3Hi4UhDsOaDW29t2S305hSc2qgjOiNtRYQIVYQ8EHG1k7 Fl63S7uCOhnVJt+4MnUK1N6/pwgsp+Z2GvEsDG1qCKnvNpf6 -END CERTIFICATE- [2004-05-14 15:38:22] [EMAIL PROTECTED] Please provide the applicable certificate file so that we have something to test the code with. [2004-05-14 08:46:35] n_sergiu at hotmail dot com Sorry, the error is still there. No v3 extensions are returned by the openssl_x509_parse function. [2004-05-13 19:47:14] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip 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/28382 -- Edit this bug report at http://bugs.php.net/?id=28382&edit=1
#29989 [Opn->Asn]: --enable mbstring fails on "make" but no configure "error"
ID: 29989 Updated by: [EMAIL PROTECTED] Reported By: jesse at eonstreet dot com -Status: Open +Status: Assigned Bug Type: Compile Failure Operating System: Linx Red Hat Enterprise 3 AS PHP Version: 5.0.1 -Assigned To: +Assigned To: moriyoshi New Comment: Moriyoshi, any clue about this one? It works fine for me. Previous Comments: [2004-09-05 20:35:14] jesse at eonstreet dot com Description: Hello, This bug has been reported on other os and other PHP 5 versions but I feel it is benifical to report it on all versions and os in case one version is patched and the others aren't I have configured php with 'enable-mbstring' and it configures fine. But upon MAKE it fails. I am not sure how the exif and mbstring extensions are related but they complied fine whith 4.3.8. I have downloaded the most recent "snapshot" from sept 5 and copied the files for exif and mbstring but I receive the same error. gcc -Iext/exif/ -I/root/php-5.0.1/ext/exif/ -DPHP_ATOM_INC -I/root/php-5.0.1/include -I/root/php-5.0.1/main -I/root/php-5.0.1 -I/root/php-5.0.1/Zend -I/usr/include/libxml2 -I/usr/kerberos/include -I/usr/include/freetype2 -I/usr/include/imap -I/root/php-5.0.1/ext/mbstring/oniguruma -I/root/php-5.0.1/ext/mbstring/libmbfl -I/root/php-5.0.1/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/usr/include/ncurses -I/usr/include/pspell -I/root/php-5.0.1/TSRM -g -O2 -c /root/php-5.0.1/ext/exif/exif.c -o ext/exif/exif.o && echo > ext/exif/exif.lo In file included from /root/php-5.0.1/ext/mbstring/php_mbregex.h:28, from /root/php-5.0.1/ext/mbstring/mbstring.h:77, from /root/php-5.0.1/ext/exif/exif.c:76: /root/php-5.0.1/ext/mbstring/oniguruma/oniguruma.h:573: redefinition of `struct re_registers' make: *** [ext/exif/exif.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=29989&edit=1
#29950 [Opn->Bgs]: Nondeterministic behavior of array inner pointer
ID: 29950
Updated by: [EMAIL PROTECTED]
Reported By: tomas_matousek at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: all
PHP Version: 5.0.1
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
This is not a bug, but a design thing.
Previous Comments:
[2004-09-04 09:07:45] tomas_matousek at hotmail dot com
Of course, there is copy-on-write.
That's a reason why reseting array inner pointer on copy is a bug.
[2004-09-03 11:08:53] [EMAIL PROTECTED]
http://www.zend.com/zend/art/ref-count.php
[2004-09-03 10:53:26] [EMAIL PROTECTED]
I think it is mentioned in the manual that PHP uses copy-on-write
technique. This means that if
$a = array(1,2,3);
and
$b = $a;
there is _only_ 1 array and $b reference this array. When change has
been made the copy-on-write starts to work. AFAIK it is not only for
arrays...
Simple example :
php -r '$a=str_repeat("a", 1000);while ($i++<2000) ${"a".$i} = $a;
This thing creates a very long string ~ 10MB, and then reference it
2000 times. If there was no copy-on-write then I will need 2*10^10
memory, which is more than a process on 32bit architecture can
address.
[2004-09-02 14:22:19] tomas_matousek at hotmail dot com
Description:
In the manual page describing each() function is the following
caution:
"Because assigning an array to another variable resets the original
arrays pointer, ..."
I think that this is a bug, although it is documented and treated as
feature.
I realized that the pointer is reset when a copy of an array is made.
However, PHP makes some optimizations which prevents unnecessary array
copying (which is good feature).
Since these optimizations are not known for users (and shouldn't be)
the behavior of inner pointer is thus non-deterministic from user's
point of view.
See the follwoing code.
Its output depends on whether the statement $b[] = 1; is commented or
not.
Reproduce code:
---
function f($a) { $b = $a; /*$b[] = 1;*/ return $b; }
$arrayOuter = array("key1","key2");
$arrayInner = array("0","1");
while(list(,$o) = each($arrayOuter))
{
$q = f($arrayInner);
while(list(,$i) = each($arrayInner))
{
print "inloop $i for $o\n";
}
}
Expected result:
inloop 0 for key1
inloop 1 for key1
Actual result:
--
inloop 0 for key1
inloop 1 for key1
inloop 0 for key2
inloop 1 for key2
--
Edit this bug report at http://bugs.php.net/?id=29950&edit=1
#29988 [Opn->Bgs]: Errors with encoding
ID: 29988 Updated by: [EMAIL PROTECTED] Reported By: lehphyro at yahoo dot com dot br -Status: Open +Status: Bogus Bug Type: SimpleXML related Operating System: Windows PHP Version: 5.0.1 New Comment: Not a bug, SimpleXML always converts to utf-8 internally. (Like any XML extension in PHP). Previous Comments: [2004-09-05 17:17:45] lehphyro at yahoo dot com dot br Description: I tried to load a xml file with ISO-8859-1 encoding. I have tried several ways for loading, but I had no success because simplexml returns the loaded string with errors. I have tried iconv functions too. Reproduce code: --- file test.php: movie[0]->plot; ?> file example.php: Matrícula XML; ?> Expected result: Matrícula Actual result: -- MatrÃcula -- Edit this bug report at http://bugs.php.net/?id=29988&edit=1
#29968 [Csd->Bgs]: __destruct and xdebug
ID: 29968
Updated by: [EMAIL PROTECTED]
Reported By: grnick at mail dot ru
-Status: Closed
+Status: Bogus
Bug Type: Zend Engine 2 problem
Operating System: Linux
PHP Version: 5CVS-2004-09-03 (dev)
New Comment:
Not a PHP bug -> bogus.
Previous Comments:
[2004-09-06 07:57:16] grnick at mail dot ru
I'm sorry. The problem is not in PHP. This bug is caused by xdebug
1.3.1. It eliminates by upgrading xdebug to 1.3.2. Of course whithout
xdebug PHP works correct.
[2004-09-03 17:14:43] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
Tested and not reproduced. Please, provide a backtrace.
[2004-09-03 12:05:17] grnick at mail dot ru
Description:
Configure Command: './configure' '--with-pgsql' '--with-mysql'
'--with-apxs' '--with-apxs=/usr/local/apache/bin/apxs'
'--enable-sysvsem' '--enable-sockets'
Apache/1.3.24
Loaded Modules mod_php5, mod_setenvif, mod_so, mod_auth, mod_access,
mod_rewrite, mod_alias, mod_userdir, mod_actions, mod_imap, mod_asis,
mod_cgi, mod_dir, mod_autoindex, mod_include, mod_status,
mod_negotiation, mod_mime, mod_log_config, mod_env, http_core
Reproduce code:
---
Test();
}
public function __destruct() {}
}
$obj = new C2();
?>
Expected result:
Fatal error: Call to undefined method C1::Test() in test.php on line 8
Actual result:
--
Apache error_log
[notice] child pid 11402 exit signal Segmentation fault (11)
And without destructor that code works right.
--
Edit this bug report at http://bugs.php.net/?id=29968&edit=1
#29975 [Opn->Fbk]: memory leaks
ID: 29975 Updated by: [EMAIL PROTECTED] Reported By: guth at fiifo dot u-psud dot fr -Status: Open +Status: Feedback Bug Type: Performance problem Operating System: Linux (Mandrake 10) PHP Version: 5.0.1 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. Previous Comments: [2004-09-03 21:21:15] guth at fiifo dot u-psud dot fr Description: (i'm french, excuse me for my english) I try to develop a CMS and i take more time to debug PHP than code PHP... After 3 segmentation fault, I compiled PHP with --enable-debug, and my tests give the following errors. Reproduce code: --- /usr/src/php-5.0.1/Zend/zend_builtin_functions.c(1023) : Freeing 0x0846F864 (23 bytes), script=/www/haricow/0.4/haricow/test/runTests.php /usr/src/php-5.0.1/Zend/zend_variables.c(137) : Actual location (location was relayed) Last leak repeated 32 times /usr/src/php-5.0.1/Zend/zend_builtin_functions.c(1013) : Freeing 0x084702C4 (16 bytes), script=/www/haricow/0.4/haricow/test/runTests.php Last leak repeated 32 times /usr/src/php-5.0.1/Zend/zend_execute.c(3718) : Freeing 0x0844FA94 (44 bytes), script=/www/haricow/0.4/haricow/test/runTests.php /usr/src/php-5.0.1/Zend/zend_variables.c(149) : Actual location (location was relayed) Last leak repeated 1 time /usr/src/php-5.0.1/Zend/zend_execute.c(3252) : Freeing 0x0844DCCC (16 bytes), script=/www/haricow/0.4/haricow/test/runTests.php Last leak repeated 7 times /usr/src/php-5.0.1/Zend/zend_variables.c(150) : Freeing 0x0843597C (32 bytes), script=/www/haricow/0.4/haricow/test/runTests.php /usr/src/php-5.0.1/Zend/zend_hash.c(169) : Actual location (location was relayed) /usr/src/php-5.0.1/Zend/zend_execute.c(3389) : Freeing 0x084315DC (16 bytes), script=/www/haricow/0.4/haricow/test/runTests.php /usr/src/php-5.0.1/Zend/zend_hash.c(242) : Freeing 0x08233804 (40 bytes), script=/www/haricow/0.4/haricow/test/runTests.php === Total 79 memory leaks detected === Expected result: No memory leaks Actual result: -- About 3 Kb of memory leaks. I tryed to "insulate" them, but i didn't manage, because of the complexity of the script. -- Edit this bug report at http://bugs.php.net/?id=29975&edit=1
#27290 [Opn->Csd]: warning msg on missing function argument should mention file/line of caller too
ID: 27290 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type:Feature/Change Request PHP Version: 5CVS-2004-02-17 (dev) New Comment: Override your error handling function with set_error_handler() and use debug_print_backtrace(), or install Xdebug which automatically does the printing of backtraces for you (http://xdebug.org) Previous Comments: [2004-09-03 19:09:47] sean at acidreign dot net over the last few days, I've had to tack down dozens of errors, with out knowing the file/line they actually occur in. reporting the line of the function declaration rather then the line of the offending expression is completely useless. It makes tracking bugs extremely difficult, because it has to be done on a trial and error basis, looking for and testing every place a function is called. [2004-02-17 11:11:08] [EMAIL PROTECTED] Description: usually the location of the caller what you really want to know here, especially if you are trying to track this down from not-so-recent messages in your error_log ... Reproduce code: --- Expected result: Warning: Missing argument 1 for foo() in foo.php on line 2, called in foo.php on line 4 Actual result: -- Warning: Missing argument 1 for foo() in - on line 2 -- Edit this bug report at http://bugs.php.net/?id=27290&edit=1
#29973 [Opn->Fbk]: Comparing COM object variable with NULL throws an exception
ID: 29973
Updated by: [EMAIL PROTECTED]
Reported By: tetikr at spytech dot cz
-Status: Open
+Status: Feedback
Bug Type: COM related
Operating System: Win2000
PHP Version: 5.0.1
New Comment:
What is the full error message?
Previous Comments:
[2004-09-03 19:08:58] tetikr at spytech dot cz
Description:
Comparing COM object variable with NULL throws an exception
Reproduce code:
---
$a = new COM(.);
if (!$a)
{
..
}
else
{
.
}
Expected result:
If $a is non null, I expect the ELSE block to be performed.
Actual result:
--
PHP throws an exception when trying to evaluate !$a. I think it tries
to access the default COM object's property.
If this is a valid behavior, how should I test for null?
--
Edit this bug report at http://bugs.php.net/?id=29973&edit=1
#29992 [Opn]: foreach by reference corrupts the array
ID: 29992 User updated by: fletch at pobox dot com -Summary: problem with foreach by reference Reported By: fletch at pobox dot com Status: Open Bug Type: Zend Engine 2 problem Operating System: linux PHP Version: 5.0.1 New Comment: changed the summary Previous Comments: [2004-09-06 05:54:50] fletch at pobox dot com Description: foreach with a reference seems to corrupt the last element in an array Reproduce code: --- Expected result: Array ( [0] => 1 [1] => 2 [2] => 3 ) Array ( [0] => 1 [1] => 2 [2] => 3 ) Actual result: -- Array ( [0] => 1 [1] => 2 [2] => 3 ) Array ( [0] => 1 [1] => 2 [2] => 2 ) -- Edit this bug report at http://bugs.php.net/?id=29992&edit=1
#29968 [Fbk->Csd]: __destruct and xdebug
ID: 29968
User updated by: grnick at mail dot ru
-Summary: __destruct and calling non-existent function
Reported By: grnick at mail dot ru
-Status: Feedback
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Linux
PHP Version: 5CVS-2004-09-03 (dev)
New Comment:
I'm sorry. The problem is not in PHP. This bug is caused by xdebug
1.3.1. It eliminates by upgrading xdebug to 1.3.2. Of course whithout
xdebug PHP works correct.
Previous Comments:
[2004-09-03 17:14:43] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
Tested and not reproduced. Please, provide a backtrace.
[2004-09-03 12:05:17] grnick at mail dot ru
Description:
Configure Command: './configure' '--with-pgsql' '--with-mysql'
'--with-apxs' '--with-apxs=/usr/local/apache/bin/apxs'
'--enable-sysvsem' '--enable-sockets'
Apache/1.3.24
Loaded Modules mod_php5, mod_setenvif, mod_so, mod_auth, mod_access,
mod_rewrite, mod_alias, mod_userdir, mod_actions, mod_imap, mod_asis,
mod_cgi, mod_dir, mod_autoindex, mod_include, mod_status,
mod_negotiation, mod_mime, mod_log_config, mod_env, http_core
Reproduce code:
---
Test();
}
public function __destruct() {}
}
$obj = new C2();
?>
Expected result:
Fatal error: Call to undefined method C1::Test() in test.php on line 8
Actual result:
--
Apache error_log
[notice] child pid 11402 exit signal Segmentation fault (11)
And without destructor that code works right.
--
Edit this bug report at http://bugs.php.net/?id=29968&edit=1
#29993 [NEW]: mssql_connect returns NULL
From: mel dot boyce at gmail dot com
Operating system: Windows XP
PHP version: 5.0.1
PHP Bug Type: MSSQL related
Bug description: mssql_connect returns NULL
Description:
mssql_connect() returns NULL regardless of a sane and completed
connection.
PHP-5.0.1 zip file from http://www.php.net/
php.ini is identical to php.ini-recommended with the mssql extension
enabled.
Reproduce code:
---
$foo = mssql_connect("server", "user", "pass");
var_dump($foo);
Expected result:
$foo != NULL
Actual result:
--
$foo == NULL
--
Edit bug report at http://bugs.php.net/?id=29993&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29993&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29993&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29993&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=29993&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=29993&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29993&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29993&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29993&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=29993&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29993&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=29993&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=29993&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=29993&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29993&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=29993&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29993&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=29993&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29993&r=float
#29992 [NEW]: problem with foreach by reference
From: fletch at pobox dot com Operating system: linux PHP version: 5.0.1 PHP Bug Type: Zend Engine 2 problem Bug description: problem with foreach by reference Description: foreach with a reference seems to corrupt the last element in an array Reproduce code: --- Expected result: Array ( [0] => 1 [1] => 2 [2] => 3 ) Array ( [0] => 1 [1] => 2 [2] => 3 ) Actual result: -- Array ( [0] => 1 [1] => 2 [2] => 3 ) Array ( [0] => 1 [1] => 2 [2] => 2 ) -- Edit bug report at http://bugs.php.net/?id=29992&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29992&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29992&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29992&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=29992&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=29992&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29992&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29992&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29992&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=29992&r=support Expected behavior: http://bugs.php.net/fix.php?id=29992&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=29992&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=29992&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=29992&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29992&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=29992&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29992&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=29992&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29992&r=float
#28929 [Com]: PHP has encountered an Access Violation at 015B73DD
ID: 28929 Comment by: Ersan191 at evilxp dot com Reported By: remy at ourselves dot nl Status: Closed Bug Type: IIS related Operating System: Win XP Pro PHP Version: 5CVS-2004-06-25 (dev) New Comment: This bug only seems to occur when running php in isapi mode through IIS. I get this error 50% of the time with php4isapi.dll, but when I restart IIS it goes away for awhile. Previous Comments: [2004-07-30 16:48:20] g dot collins8 at ntlworld dot com I am running win 2000 server IIS 5 with php 5.0.0 & MySql 4.0.20d http://www.nx99.net/info.php I do not seem to have an error on this page however when I try to install phpmyadmin or vBulletin I get the following erro. PHP has encountered an Access Violation at 019573CD What can i do to fix this as I can not get anything to work. [2004-07-30 07:24:23] sak_cu at hotmail dot com I you CVS version both php and pecl I has no error When I restart "IIS Admin" error dialog will appear. But it can restart without problem and webserver can run normally... This is php bug or IIS Admin bug?? [2004-07-22 01:04:51] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2004-07-21 11:12:29] mattbta at gmail dot com Same error - different memory address...however - here's the kicker, only search engine spiders see it. I can't reproduce the error in any browser on windows, but going through search engine simulators, the error pops up in different spots on different pages. This only seems to be related to pages with MySQL connections/queries. Setup - w2k3, IIS6, PHP5.0.0 ISAPI, MySQL 4.0.18 Running the same pages on different port with Apache 2.50 eliminates the error. I've given the IUSR_COMPUTERNAME account full control to the php dir, mysql dir, web dir, and php/mysql dll's in %systemroot% and system32 and system. [2004-07-16 20:57:23] daseymour at 3hc dot org Same problem here (PHP has encountered an Access Violation at 011573CD). Running Windows 2000 5.00.2195, PHP 5.0.0, and IIS 5.0. 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/28929 -- Edit this bug report at http://bugs.php.net/?id=28929&edit=1
#29983 [Opn]: default_charset not set by ini_set
ID: 29983 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache2 related Operating System: all PHP Version: 5CVS-2004-09-05 (dev) New Comment: Verified. Doesn't look Apache2-specific to me. It has to do with the way we apply it, or rather don't apply it if we already see one set. Previous Comments: [2004-09-05 15:11:27] smacvicar at gmail dot com It doesn't appear to send a charset entry when specified and you end up with the AddDefaultCharset entry from Apache 2 which is ISO-8859-1. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23421 [2004-09-05 12:37:28] [EMAIL PROTECTED] Description: default_charset is marked as PHP_INI_ALL but I can't set it using ini_set. If I set it throught .htaccess it works fine. Reproduce code: --- Expected result: HTTP/1.1 200 OK (...) Content-Type: text/html; charset=UTF-8 Actual result: -- HTTP/1.1 200 OK (...) Content-Type: text/html; charset=ISO-8859-1 -- Edit this bug report at http://bugs.php.net/?id=29983&edit=1
#29144 [Opn]: PHP is not executed/not handling files
ID: 29144 Updated by: [EMAIL PROTECTED] Reported By: php at soapi dot com Status: Open Bug Type: Apache2 related Operating System: RedHat Enterprise Linux 3.0 PHP Version: 5.0.0 New Comment: Does it work with Apache1 for you? Previous Comments: [2004-09-06 03:53:47] jesse at eonstreet dot com I have the same problem. Everything is fine except when I change the http.conf from libphp4 to libphp5. I too believe this is a bug and has something to do with a the way the libphp5.so is tell apache2 how to handle the files. I tried compiling "--with-apxs2" only but that did not work. Neither "--with-apxs2=/usr/sbin/apxs --with-apxs2filter=/usr/sbin/apxs" [2004-07-14 15:05:29] php at soapi dot com I fail to see how this is not a bug. I subscribe to all the relevant PHP newsgroups, and there has been nothing there to help. (The fact that the newsgroups suffer from so much spam probably has a lot to do with it.) I believe this is a bug for the simple reason that PHP4 works perfectly with the same settings, and PHP5 is not handling php scripts. That to me says some bug in how PHP5 is telling Apache what it can handle. If there is anything that should be done in addition to the standard steps of installation, that should be clearly marked out in the documentation. However, there is nothing to suggest that anything else is needed. Finally, please note that I *have* used the support system, and the mailing list/newsgroups, and spent many hours searching and testing before posting this report. I still believe this is a bug. [2004-07-14 14:53:54] [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. It\'s still not a bug, please ask for support on the mailinglist as it works fine for hundreds of others. [2004-07-14 14:41:24] php at soapi dot com Description: First of all, my apologies for adding a new bug, but bug 26492 has been marked as bogus, and although I have added a comment, I cannot reopen it. Therefore as I believe this is indeed a PHP problem, I have created a new entry. After building PHP5.0.0 final today, I am experiencing the exact same problem I have had with RC1, RC2, and RC3. I am currently running Apache 2.0.50, but I have tried with 2.0.48 and 2.0.49 as well. (I spent two full days a couple of weeks ago recompiling many different configurations, with no success.) PHP compiles and installs fine, and Apache loads with no problems. There are no errors listed in the error log (which is set to flag everything) and I don't get any problems other than this one, which is that PHP files are not being processed. I have PHP4.3.8 running right now, and every version of PHP4 has compiled, installed, and run with no problems. I am using an essentially identical configuration line for PHP5, and all I do to swap between the two is change the module that is loaded. Even if I use a very basic Apache and PHP setup, this problem occurs. I am using a standard PHP5 ini file, with only minor changes to point it at the right directories. So. Whenever I use PHP5, all PHP files are offered for download rather than being processed by PHP5. I have tried things like AddHandler php5-script and all sorts, with no success. As far as I am aware, I should not have to do anything substantially different to set up PHP5 than I do for PHP4. Apache info shows that mod_php5.c is loaded successfully, so why doesn't it handle the files? I'm going mad with this. The only thing that is different from a standard installation is that I install PHP4 and PHP5 into their own locations, in order to swap between them. For instance I use 'export EXTENSION_DIR=/usr/lib/php5' and then in the configure line I use '--program-suffix=5 --with-config-file-path=/etc/php5' with the other settings. This is simply to keep the two apart. It would appear that for some reason PHP5 is not properly registering with Apache2 that it can handle the application/x-httpd-php MIME-type, but I have no idea why, because I have 'AddType application/x-httpd-php php' in my httpd.conf file of course. How can I track down the problem? I'm not new to this - I have been a server admin for years (I run www.ithium.net) and I use PHP every day. I have compiled PHP and Apache countless times, and even written tutorials on the subject. So you can see why this is so frustrating. Thanks Dan Williams
#29144 [Com]: PHP is not executed/not handling files
ID: 29144 Comment by: jesse at eonstreet dot com Reported By: php at soapi dot com Status: Open Bug Type: Apache2 related Operating System: RedHat Enterprise Linux 3.0 PHP Version: 5.0.0 New Comment: I have the same problem. Everything is fine except when I change the http.conf from libphp4 to libphp5. I too believe this is a bug and has something to do with a the way the libphp5.so is tell apache2 how to handle the files. I tried compiling "--with-apxs2" only but that did not work. Neither "--with-apxs2=/usr/sbin/apxs --with-apxs2filter=/usr/sbin/apxs" Previous Comments: [2004-07-14 15:05:29] php at soapi dot com I fail to see how this is not a bug. I subscribe to all the relevant PHP newsgroups, and there has been nothing there to help. (The fact that the newsgroups suffer from so much spam probably has a lot to do with it.) I believe this is a bug for the simple reason that PHP4 works perfectly with the same settings, and PHP5 is not handling php scripts. That to me says some bug in how PHP5 is telling Apache what it can handle. If there is anything that should be done in addition to the standard steps of installation, that should be clearly marked out in the documentation. However, there is nothing to suggest that anything else is needed. Finally, please note that I *have* used the support system, and the mailing list/newsgroups, and spent many hours searching and testing before posting this report. I still believe this is a bug. [2004-07-14 14:53:54] [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. It\'s still not a bug, please ask for support on the mailinglist as it works fine for hundreds of others. [2004-07-14 14:41:24] php at soapi dot com Description: First of all, my apologies for adding a new bug, but bug 26492 has been marked as bogus, and although I have added a comment, I cannot reopen it. Therefore as I believe this is indeed a PHP problem, I have created a new entry. After building PHP5.0.0 final today, I am experiencing the exact same problem I have had with RC1, RC2, and RC3. I am currently running Apache 2.0.50, but I have tried with 2.0.48 and 2.0.49 as well. (I spent two full days a couple of weeks ago recompiling many different configurations, with no success.) PHP compiles and installs fine, and Apache loads with no problems. There are no errors listed in the error log (which is set to flag everything) and I don't get any problems other than this one, which is that PHP files are not being processed. I have PHP4.3.8 running right now, and every version of PHP4 has compiled, installed, and run with no problems. I am using an essentially identical configuration line for PHP5, and all I do to swap between the two is change the module that is loaded. Even if I use a very basic Apache and PHP setup, this problem occurs. I am using a standard PHP5 ini file, with only minor changes to point it at the right directories. So. Whenever I use PHP5, all PHP files are offered for download rather than being processed by PHP5. I have tried things like AddHandler php5-script and all sorts, with no success. As far as I am aware, I should not have to do anything substantially different to set up PHP5 than I do for PHP4. Apache info shows that mod_php5.c is loaded successfully, so why doesn't it handle the files? I'm going mad with this. The only thing that is different from a standard installation is that I install PHP4 and PHP5 into their own locations, in order to swap between them. For instance I use 'export EXTENSION_DIR=/usr/lib/php5' and then in the configure line I use '--program-suffix=5 --with-config-file-path=/etc/php5' with the other settings. This is simply to keep the two apart. It would appear that for some reason PHP5 is not properly registering with Apache2 that it can handle the application/x-httpd-php MIME-type, but I have no idea why, because I have 'AddType application/x-httpd-php php' in my httpd.conf file of course. How can I track down the problem? I'm not new to this - I have been a server admin for years (I run www.ithium.net) and I use PHP every day. I have compiled PHP and Apache countless times, and even written tutorials on the subject. So you can see why this is so frustrating. Thanks Dan Williams -- Edit this bug report at http://bugs.php.net/?id=29144&edit=1
#29991 [Opn]: After compile and install the "php" command returns 'Segmentation fault'
ID: 29991 User updated by: jesse at eonstreet dot com Reported By: jesse at eonstreet dot com Status: Open Bug Type: Compile Failure Operating System: RedHat as 3 PHP Version: 5.0.1 New Comment: The config that I tried was: --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=i386-redhat-linux --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/lib/httpd/modules --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --cache-file=../config.cache --with-config-file-path=/etc --with-curl --with-dom=/usr --with-exec-dir=/usr/bin --with-freetype-dir=/usr --with-png-dir=/usr --with-gd --with-ttf --with-jpeg-dir=/usr --with-openssl --with-png --with-pspell --with-xml --with-zlib ---enable-exif --enable-ftp --enable-magic-quotes --with-pear=/usr/share/pear -with-ldap=shared --with-mysql=shared,/usr --enable-soap --with-libxml-dir=/usr/include/libxml2 --with-apxs2=/usr/sbin/apxs --with-apxs2filter=/usr/sbin/apxs Previous Comments: [2004-09-06 02:06:17] jesse at eonstreet dot com Description: Hello, After configuring and compiling php 5.0.1 a number of times I can not get any result except 'Segmentation fault'. Neither the command line nor apache will give any response. I have updated the libxml2 to version 2.6.12 by geting the tar.gz from xmlsoft.org I do not have loadModule php4 anywhere in my httpd.conf [EMAIL PROTECTED] ./configure --(see below) [EMAIL PROTECTED] make [EMAIL PROTECTED] make install [EMAIL PROTECTED] php Segmentation fault if there is a list of extensions that no longer work in php5 or that cause this type of problem it woould be very helpful if someone whould post it or include it in the install docs. ### Configure line ### --host=i686-pc-linux-gnu' '--build=i686-pc-linux-gnu' '--target=i386-redhat-linux' '--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' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-pcre=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--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' '--enable-yp' '--enable-wddx' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-mbregex' '--without-oci8' '--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-ldap=shared' '--with-mysql=shared,/usr' '--with-pgsql=shared' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--with-apxs2filter=/usr/sbin/apxs' -- Edit this bug report at http://bugs.php.net/?id=29991&edit=1
#29991 [NEW]: After compile and install the "php" command returns 'Segmentation fault'
From: jesse at eonstreet dot com Operating system: RedHat as 3 PHP version: 5.0.1 PHP Bug Type: Compile Failure Bug description: After compile and install the "php" command returns 'Segmentation fault' Description: Hello, After configuring and compiling php 5.0.1 a number of times I can not get any result except 'Segmentation fault'. Neither the command line nor apache will give any response. I have updated the libxml2 to version 2.6.12 by geting the tar.gz from xmlsoft.org I do not have loadModule php4 anywhere in my httpd.conf [EMAIL PROTECTED] ./configure --(see below) [EMAIL PROTECTED] make [EMAIL PROTECTED] make install [EMAIL PROTECTED] php Segmentation fault if there is a list of extensions that no longer work in php5 or that cause this type of problem it woould be very helpful if someone whould post it or include it in the install docs. ### Configure line ### --host=i686-pc-linux-gnu' '--build=i686-pc-linux-gnu' '--target=i386-redhat-linux' '--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' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-pcre=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--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' '--enable-yp' '--enable-wddx' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-mbregex' '--without-oci8' '--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-ldap=shared' '--with-mysql=shared,/usr' '--with-pgsql=shared' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--with-apxs2filter=/usr/sbin/apxs' -- Edit bug report at http://bugs.php.net/?id=29991&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29991&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29991&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29991&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=29991&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=29991&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29991&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29991&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29991&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=29991&r=support Expected behavior: http://bugs.php.net/fix.php?id=29991&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=29991&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=29991&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=29991&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29991&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=29991&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29991&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=29991&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29991&r=float
#10313 [Com]: ROUND inconsistency
ID: 10313 Comment by: tivnet at mail dot com Reported By: faxguy at deanox dot com Status: Closed Bug Type: *Math Functions Operating System: RedHat Linux 7.0 PHP Version: 4.0.4pl1 New Comment: The quick workaround seems to be using TRUNCATE in MySQL: TRUNCATE( 38.50 + 0.5, 0 ) = 39 while ROUND( 38.50, 0 ) = 38 TIV.NET http://tiv.net/ Previous Comments: [2004-09-06 01:35:04] tivnet at mail dot com The problem still exists - September 2004, latest PHP4 and MySql 4.0 [2001-04-13 14:35:03] [EMAIL PROTECTED] This isn't a bug. PHP uses the underlying C library to round, and all known C library's do this the same. Actually, you are reporting a bug for MySQL, so please ask on there bug list for this. [2001-04-12 22:20:44] faxguy at deanox dot com Using MySQL 3.23.32 on RedHat Linux 7.0... MySQL's ROUND function rounds 5 up when the preceding digit is odd and down when the preceding digit is even. mysql> select round(1.5); ++ | round(1.5) | ++ | 2 | ++ 1 row in set (0.00 sec) mysql> select round(2.5); ++ | round(2.5) | ++ | 2 | ++ 1 row in set (0.00 sec) I think that this is technically the correct behavior, scientifically, anyway. However, this is not the common "lay-man's" method of rounding, which is to always round 5 up, as exhibited by PHP-4.0.4pl1... Apache 1.3.14 output for this is: 2 3 This discrepancy causes a difficulty in programming PHP and MySQL together, for example, because all of the rounding must be done in either PHP or MySQL but not both partially unless you want conflicting data. I would like to see MySQL ROUND() syntax expand to be ROUND(X,D,M) where optional M value indicates the method of rounding, the default being the current method. I would also like to see PHP round() syntax expand to be double round (double val [, int precision] [, char method]) where the optional method value indicates the method of rounding, the default being the current method. Thanks. Lee Howard -- Edit this bug report at http://bugs.php.net/?id=10313&edit=1
#10313 [Com]: ROUND inconsistency
ID: 10313 Comment by: tivnet at mail dot com Reported By: faxguy at deanox dot com Status: Closed Bug Type: *Math Functions Operating System: RedHat Linux 7.0 PHP Version: 4.0.4pl1 New Comment: The problem still exists - September 2004, latest PHP4 and MySql 4.0 Previous Comments: [2001-04-13 14:35:03] [EMAIL PROTECTED] This isn't a bug. PHP uses the underlying C library to round, and all known C library's do this the same. Actually, you are reporting a bug for MySQL, so please ask on there bug list for this. [2001-04-12 22:20:44] faxguy at deanox dot com Using MySQL 3.23.32 on RedHat Linux 7.0... MySQL's ROUND function rounds 5 up when the preceding digit is odd and down when the preceding digit is even. mysql> select round(1.5); ++ | round(1.5) | ++ | 2 | ++ 1 row in set (0.00 sec) mysql> select round(2.5); ++ | round(2.5) | ++ | 2 | ++ 1 row in set (0.00 sec) I think that this is technically the correct behavior, scientifically, anyway. However, this is not the common "lay-man's" method of rounding, which is to always round 5 up, as exhibited by PHP-4.0.4pl1... Apache 1.3.14 output for this is: 2 3 This discrepancy causes a difficulty in programming PHP and MySQL together, for example, because all of the rounding must be done in either PHP or MySQL but not both partially unless you want conflicting data. I would like to see MySQL ROUND() syntax expand to be ROUND(X,D,M) where optional M value indicates the method of rounding, the default being the current method. I would also like to see PHP round() syntax expand to be double round (double val [, int precision] [, char method]) where the optional method value indicates the method of rounding, the default being the current method. Thanks. Lee Howard -- Edit this bug report at http://bugs.php.net/?id=10313&edit=1
#28487 [Fbk->NoF]: crash when function declared in switch is called
ID: 28487
Updated by: [EMAIL PROTECTED]
Reported By: tomas dot matousek at matfyz dot cz
-Status: Feedback
+Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: WinXP
PHP Version: 5.0.0RC2
New Comment:
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2004-08-29 12:59:30] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Seems to be fixed. Please, test it again.
[2004-07-29 09:59:44] stefan at hotpaenz dot de
I experienced this crash on Linux 2.6.3 with PHP 4.3.3 and
PHP 5.1.0-dev snapshot 200407271430. Perhaps somebody
should set the category to "reproducible crash".
This is the PHP 5.1.0-dev backtrace:
#0 0x08271843 in zend_switch_free_handler
(execute_data=0xbfffd5a0, opline=0x8726fe4,
op_array=0x8721970, tsrm_ls=0x8430018)
at /root/php/200407271430/php5-5.0.0/Zend/zend_execute.c:200
200 if (!T(opline->op1.u.var).var.ptr_ptr) {
(gdb) bt
#0 0x08271843 in zend_switch_free_handler
(execute_data=0xbfffd5a0, opline=0x8726fe4,
op_array=0x8721970, tsrm_ls=0x8430018)
at /root/php/200407271430/php5-5.0.0/Zend/zend_execute.c:200
#1 0x0826c0b5 in execute (op_array=0x8721970,
tsrm_ls=0x8430018)
at /root/php/200407271430/php5-5.0.0/Zend/zend_execute.c:1391
#2 0x0826fe63 in zend_do_fcall_common_helper
(execute_data=0xbfffd670, opline=0x8725ecc,
op_array=0x8721b94, tsrm_ls=0x8430018)
at /root/php/200407271430/php5-5.0.0/Zend/zend_execute.c:2728
#3 0x0826c0b5 in execute (op_array=0x8721b94,
tsrm_ls=0x8430018)
at /root/php/200407271430/php5-5.0.0/Zend/zend_execute.c:1391
#4 0x0824ce31 in zend_execute_scripts (type=8,
tsrm_ls=0x8430018, retval=0x0, file_count=3)
at /root/php/200407271430/php5-5.0.0/Zend/zend.c:1068
#5 0x08210044 in php_execute_script
(primary_file=0xba40, tsrm_ls=0x8430018)
at /root/php/200407271430/php5-5.0.0/main/main.c:1631
#6 0x08278bfc in main (argc=2, argv=0xbb04)
at /root/php/200407271430/php5-5.0.0/sapi/cgi/cgi_main.c:1568
[2004-07-24 21:22:29] Jared dot Williams1 at ntworld dot com
Just discovered this one with
PHP Version 5.1.0-dev
System Windows NT WIN2KS 5.0 build 2195
Build Date Jul 23 2004 16:22:08
and
PHP Version 5.1.0-dev
System Windows NT WIN2KS 5.0 build 2195
Build Date Jul 24 2004 20:15:28
[2004-07-20 16:35:29] jb-php at microbasic dot net
I have the same problem, example :
With php5 final, this code was working with php 4.3.7
[2004-07-13 18:07:43] fixxxer at php5 dot ru
The bug exists in the last snapshot php5-200407131230.
Tested under FreeBSD 4.9 and Windows XP.
(gdb) bt
#0 zend_switch_free_handler (execute_data=0xbfbfe314,
opline=0x84f8824, op_array=0x8504780)
at /usr/ports/lang/php5/work/php-5.0.0RC3/Zend/zend_execute.c:65
#1 0x823fbcf in execute (op_array=0x8504780) at
/usr/ports/lang/php5/work/php-5.0.0RC3/Zend/zend_execute.c:1391
#2 0x825d8c5 in zend_do_fcall_common_helper (execute_data=0xbfbfe404,
opline=0x850e368, op_array=0x8505124)
at /usr/ports/lang/php5/work/php-5.0.0RC3/Zend/zend_execute.c:2728
#3 0x825dd22 in zend_do_fcall_by_name_handler
(execute_data=0xbfbfe404, opline=0x850e368, op_array=0x8505124)
at /usr/ports/lang/php5/work/php-5.0.0RC3/Zend/zend_execute.c:2810
#4 0x823fbcf in execute (op_array=0x8505124) at
/usr/ports/lang/php5/work/php-5.0.0RC3/Zend/zend_execute.c:1391
#5 0x821e32e in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/ports/lang/php5/work/php-5.0.0RC3/Zend/zend.c:1061
#6 0x81e3ba5 in php_execute_script (primary_file=0xbfbffac0) at
/usr/ports/lang/php5/work/php-5.0.0RC3/main/main.c:1627
#7 0x82688ce in main (argc=3, argv=0xbfbffb3c) at
/usr/ports/lang/php5/work/php-5.0.0RC3/sapi/cli/php_cli.c:943
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/28487
--
Edit this bug report at http://bugs.php.net/?id=28487&edit=1
#29626 [Fbk->NoF]: Variables read from $_SESSION loose their values when using HTTP
ID: 29626
Updated by: [EMAIL PROTECTED]
Reported By: proteus at proteusworld dot com
-Status: Feedback
+Status: No Feedback
Bug Type: Session related
Operating System: Linux (might be Windows too)
PHP Version: Irrelevant
New Comment:
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
Previous Comments:
[2004-08-29 13:35:08] [EMAIL PROTECTED]
HTTP & HTTPS are two different sites for your browser, so you're mixing
two different sessions here.
Please, supply more readable example - a short reproduce script would
definitely help more than a verbose essay.
[2004-08-12 08:26:48] proteus at proteusworld dot com
Description:
I found a strange (to me at least) behaviour with sessions when using
HTTPS.
Let's say that $_SESSION["message"] contains "old_message". Take the
following code:
$old_message = $_SESSION["message"];
$_SESSION["message"] = "new message";
echo "The message was: ".$old_message;
Now, over HTTP you would get the expected output ("old_message"). But
over HTTPS the output will contain "new_message".
You can use session_unregister("message") if you want $old_message to
preserve its value, but this means you can't set anymore a new value
for $_SESSION["message"].
--
Edit this bug report at http://bugs.php.net/?id=29626&edit=1
#29735 [Fbk->NoF]: Segfault (11) / Possible stack corruption
ID: 29735 Updated by: [EMAIL PROTECTED] Reported By: sparkeh at btinternet dot com -Status: Feedback +Status: No Feedback Bug Type: Reproducible crash Operating System: Linux 2.6.7-gentoo-r9 PHP Version: 5.0.1 New Comment: No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2004-08-29 12:59:32] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Seems to be fixed. Please, test it again. [2004-08-21 03:56:14] sparkeh at btinternet dot com I've noticed that this is a duplicate of bug #28487 [2004-08-19 20:50:11] sparkeh at btinternet dot com gdb stack trace from the first script (Ref: 3:24pm CEST) #0 0x081e74a2 in _zval_ptr_dtor () #1 0x08216d9f in zend_switch_free_handler () #2 0x08211dff in execute () #3 0x0821567d in zend_do_fcall_common_helper () #4 0x08215993 in zend_do_fcall_by_name_handler () #5 0x08211dff in execute () #6 0x081f2b17 in zend_execute_scripts () #7 0x081b4d31 in php_execute_script () #8 0x in ?? () #9 0x0003 in ?? () #10 0x in ?? () ... #970 0x5f706870 in ?? () #971 0x69727473 in ?? () #972 0x68775f70 in ?? () #973 0x4083a6c4 in mallopt () from /lib/libc.so.6 Previous frame inner to this frame (corrupt stack?) (gdb) :o) [2004-08-19 18:27:58] hip at cs dot okstate dot edu I getting a seg. fault on a simple little script that's worked for years and it sure smells like stack corruption. connect(); $sql = "select from STUDENT_STATUS "; $sql .= "where STATUS='APPROVED' "; ?> On my solaris 9 x86 box this seq. faults. Change the last line it seq faults. Remove the last line it doesn't. After a hour of playing, I've discovered that I can prevent a seg. fault by place echo statements (or some other random statment) in key positions in the file. That sure smells like stack corruption. I ran gdb on the core dump and the last lines of the backtrace are: #20 0x81b65da in zend_deactivate () at /usr/local/src/php-5.0.1/Zend/zend.c:819 #21 0x8182007 in php_request_shutdown (dummy=0x0) at /usr/local/src/php-5.0.1/main/main.c:1212 #22 0x81db50f in main (argc=2, argv=0x8047a18) at /usr/local/src/php-5.0.1/sapi/cli/php_cli.c:1046 and from what little I know of gdb it looks like it's happening when php is trying to shutdown. [2004-08-18 20:36:46] sparkeh at btinternet dot com N.B. Original code tested and works as expected with PHP 4.3.3 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/29735 -- Edit this bug report at http://bugs.php.net/?id=29735&edit=1
#29616 [Fbk->NoF]: Error in checking APXS versionn
ID: 29616 Updated by: [EMAIL PROTECTED] Reported By: jpbarrette at savoirfairelinux dot net -Status: Feedback +Status: No Feedback Bug Type: Compile Failure Operating System: Mandrake linux 10.0 (Community) PHP Version: 5.0.0 New Comment: No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2004-08-29 14:59:40] [EMAIL PROTECTED] What shell do you use and what exactly did you remove from ./configure to make it work? Could plz show what's on line 3169? [2004-08-11 16:46:14] jpbarrette at savoirfairelinux dot net Description: When I run the configure script with these options: './configure' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--enable-discard-path' '--disable-force-cgi-redirect' '--enable-shared' '--disable-static' '--disable-debug' '--disable-rpath' '--enable-pic' '--enable-inline-optimization' '--enable-memory-limit' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php' '--with-pear=/usr/share/pear' '--enable-magic-quotes' '--enable-debugger' '--enable-track-vars' '--with-exec-dir=/usr/bin' '--with-versioning' '--with-mod_charset' '--with-regex=php' '--enable-track-vars' '--enable-trans-sid' '--enable-safe-mode' '--enable-ctype' '--enable-ftp' '--with-gettext=/usr' '--enable-posix' '--enable-session' '--enable-sysvsem' '--enable-sysvshm' '--enable-yp' '--with-openssl=/usr' '--without-kerberos' '--with-ttf' '--with-freetype-dir=/usr' '--with-zlib=/usr' '--with-zlib=/usr' '--with-zlib-dir=/usr' '--without-pear' '--with-apxs=/usr/sbin/apxs' I got this error: checking for Apache 1.x module support via DSO through APXS... expr: non-numeric argument ./configure: line 3169: test: : integer expression expected The only way I could resolve this is remove the version test on the lines next to line 3169 and this line too. It work fine after that. -- Edit this bug report at http://bugs.php.net/?id=29616&edit=1
#29548 [Opn]: Apache2/PHP Module crashes
ID: 29548 Updated by: [EMAIL PROTECTED] Reported By: tom at ideaweb dot de Status: Open Bug Type: XSLT related Operating System: Debian Testing PHP Version: 4.3.8 New Comment: We have moved completely to libxml2 and I don't think anybody is working with Sablotron anymore. I am sure you are right that there is a bug there, but I just don't think anybody is all that motivated to go back and try to fix it. Previous Comments: [2004-09-05 17:36:37] tom at ideaweb dot de it happens with sablot 1.0.1. with 0.98 there are no problems. [2004-09-04 21:47:43] [EMAIL PROTECTED] Use ext/domlxml and its xslt support instead. [2004-08-07 13:49:00] [EMAIL PROTECTED] Looks like a problem in the XSLT/Sablotron extension of PHP 4.3 (not my area ;) ) [2004-08-06 15:18:12] tom at ideaweb dot de Description: hi, i have a small content management system, which transforms xml documents to evaluated php templates. with huge data the apache2.0.50 crashes with the following message in the error log: httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:15:58 2004] [notice] child pid 20982 exit signal Aborted (6) httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:16:08 2004] [notice] child pid 21091 exit signal Aborted (6) httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:23:50 2004] [notice] child pid 21440 exit signal Aborted (6) httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:50:11 2004] [notice] child pid 28053 exit signal Aborted (6) httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:52:20 2004] [notice] child pid 28197 exit signal Aborted (6) if i change some content in cdata notes, the transformation over sabltron xsl works in some cases again. with small documents no problem. Reproduce code: --- sorry its to complex to post this in 20 line. if you have questions contact me. Expected result: no crashes at any kind programming failures... Actual result: -- root:/etc/firewall# /www/apache/current/bin/httpd -X Aborted the apache webserver quits only with "Aborted",the the same error message in the error log and without a core file. ??? -- Edit this bug report at http://bugs.php.net/?id=29548&edit=1
#29990 [NEW]: Unbuffered fgets or fgetc function.
From: louis at mulliemedia dot com
Operating system: Fedora
PHP version: Irrelevant
PHP Bug Type: Feature/Change Request
Bug description: Unbuffered fgets or fgetc function.
Description:
Hello,
First of all I'd like to thank all of you PHP community for your
commitment to PHP. This is what makes PHP the best web scripting language
on earth. If I could code this function in C, I would, however at this
moment I am only a begginner in C/C++ thats why I am posting here :)
Some applications (in my case, a socket server) wich have to be run from
the command line and will run forever, need to have some administration
functions from the CLI so that you can create basic functions (like
shutdown, etc.)
I think that an unbuffered fgetc or fegts function would be very nice so
that we can read from php://stdin only if there is something to read, and
so that it doesnt hang there waiting for input.
I'd like to give a few urls of other people in need of this, as I might
not have explained properly :
http://lists.nyphp.org/pipermail/talk/2003-September/005595.html
http://www.phpbuilder.com/lists/php-developer-list/2001121/1771.php
Thanks,
Louis
Reproduce code:
---
function getStdI() {
static $pStdn;
if(!$pStdn)
{
$pStdn = fopen("php://stdin", "r");
}
return trim(fgets($pStdn, 1024));
}
while(1) {
getStdI(); // will hang there until enter is pressed
// socket server code
}
--
Edit bug report at http://bugs.php.net/?id=29990&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29990&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29990&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29990&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=29990&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=29990&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29990&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29990&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29990&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=29990&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29990&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=29990&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=29990&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=29990&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29990&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=29990&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29990&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=29990&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29990&r=float
#29989 [NEW]: --enable mbstring fails on "make" but no configure "error"
From: jesse at eonstreet dot com Operating system: Linx Red Hat Enterprise 3 AS PHP version: 5.0.1 PHP Bug Type: Compile Failure Bug description: --enable mbstring fails on "make" but no configure "error" Description: Hello, This bug has been reported on other os and other PHP 5 versions but I feel it is benifical to report it on all versions and os in case one version is patched and the others aren't I have configured php with 'enable-mbstring' and it configures fine. But upon MAKE it fails. I am not sure how the exif and mbstring extensions are related but they complied fine whith 4.3.8. I have downloaded the most recent "snapshot" from sept 5 and copied the files for exif and mbstring but I receive the same error. gcc -Iext/exif/ -I/root/php-5.0.1/ext/exif/ -DPHP_ATOM_INC -I/root/php-5.0.1/include -I/root/php-5.0.1/main -I/root/php-5.0.1 -I/root/php-5.0.1/Zend -I/usr/include/libxml2 -I/usr/kerberos/include -I/usr/include/freetype2 -I/usr/include/imap -I/root/php-5.0.1/ext/mbstring/oniguruma -I/root/php-5.0.1/ext/mbstring/libmbfl -I/root/php-5.0.1/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/usr/include/ncurses -I/usr/include/pspell -I/root/php-5.0.1/TSRM -g -O2 -c /root/php-5.0.1/ext/exif/exif.c -o ext/exif/exif.o && echo > ext/exif/exif.lo In file included from /root/php-5.0.1/ext/mbstring/php_mbregex.h:28, from /root/php-5.0.1/ext/mbstring/mbstring.h:77, from /root/php-5.0.1/ext/exif/exif.c:76: /root/php-5.0.1/ext/mbstring/oniguruma/oniguruma.h:573: redefinition of `struct re_registers' make: *** [ext/exif/exif.lo] Error 1 -- Edit bug report at http://bugs.php.net/?id=29989&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29989&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29989&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29989&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=29989&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=29989&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29989&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29989&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29989&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=29989&r=support Expected behavior: http://bugs.php.net/fix.php?id=29989&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=29989&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=29989&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=29989&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29989&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=29989&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29989&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=29989&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29989&r=float
#26286 [Com]: Parent: child process exited with status 3221225477 -- Restarting
ID: 26286
Comment by: nuwp at mail dot com
Reported By: igg10 at alu dot ua dot es
Status: No Feedback
Bug Type: Apache2 related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
In my case, this happens when I turn off the cookies in Mozilla for the
site I am developing. The PHP scripts then use some classes stored in
$_SESSION[] during the requests. So if the cookies are not allowed,
session does not work, and then the Apache crashes.
Previous Comments:
[2004-08-30 23:17:11] ajvdhek at dds dot nl
Exact same bug for me... Win XP pro + XAMMP 1.4.6 (Apache/2.0.50
(Win32) mod_ssl/2.0.50 OpenSSL/0.9.7c PHP/5.0.1 MySQL 4.0.20a-nt)
[2004-07-05 16:23:19] adam dot phillips at orange dot net
Continuing from my post above, I tried replacing the switch statement
with if () {} elseif ... and still got the error so it appears it is
not the switch statement
[2004-07-05 16:01:24] adam dot phillips at orange dot net
I experienced the same problem on 2 systems - Win2k with Apache
2.0.48/PHP 4.3.4 and Red Hat Linux with Apache 1.3.29 and PHP 4.3.5.
So far as i can tell, the cause of the error is a switch statement. I
have a function withian a class module declared as follows:
function getsales($scope="", $returnasobjects=false) {
}
Inside this function is a switch statment based on $scope.
There are four cases. The first three perform different functions
which all return arrays and the fourth case (which is the default)
performs all 3 of the previous cases and merges the results into a
single array (I won't write out all the code since it all appears to
work outside of this switch statement. Please e-mail if needed). The
error occurs in the fourth case but originally the code was identical
to that of the first 3 'stuck together'. I have since tried a number
of alternatives none of which work. Most intriguing was when instead
of using default: for the fourth case i renamed it case "all". Then it
worked when called from another page but not when called from within the
same class module. I then renamed it "everything" and the opposite was
true. I then tried changed my function declaration to
function getsales($scope="all", $returnasobjects=false) {}
and it wouldn't work in either case. Similarly if i replaced "all"
with everything. The final bit of strangeness was that i tried using
the following code in the default case
return array_merge($this->getsales("case1"), $this->getsales("case2"),
$this->getsales("case3"))
which wouldn't work even tho each of the cases worked individually.
Each time i get the same error in my Apache Error Log
Parent: child process exited with status 3221225725 -- Restarting
[2004-06-28 16:54:47] joker at localfoo dot info
The snippet posted by ''hakk at email dot it'' reproduces the
...Restarting... problem with the following packages also under
WinXP/SP1
(not tested under Win2000)
===HOST:
P3-1GHz/256MB Notebook
Windows XP/SP1
Apache 2.0.49
PHP 4.3.7 (php4apache2.dll)
with/without ZendOptimizer 2.5.1
===TESTED WITH:
PHP 4-win32-STABLE-200406272030
(PHP 4.3.8-dev as module)
PHP 5-win32-200406271830
(PHP5.0.0-dev as module)
===SNIP OD SYSLOG:
Ereignistyp:Informationen
Ereignisquelle: Application Popup
Ereigniskategorie: Keine
Ereigniskennung:26
Datum: 28.06.2004
Zeit: 16:36:16
Benutzer: Nicht zutreffend
Computer: LT04
Beschreibung:
Anwendungspopup: apache.exe - Fehler in Anwendung: Die Anweisung in
"0x" verweist auf Speicher in "0x". Der Vorgang
"read" konnte nicht auf dem Speicher durchgeführt werden.
===END OF SNIP
This also occurs on some webapplications (e.g. mamboserver-cms,
mylansite). They RIP sometimes under several circumstances preferred
running with php as module. They work almost fine with PHP in CGI mode.
I also had a user reporting Error 128 instead of 3221225477
-
[Referring: http://bugs.php.net/bug.php?id=26771]
The author of Bug 26771 has similar problems (...restarting...)
executing the 'tick'-script (see the mentioned BUG report and
http://nl.php.net/manual/en/control-structures.declare.php) crashes my
constellation without ANY log (Apache2 error) entry. It doesn't even
make the ...Restarting... log entry in Apache2 but this occurs on
several applications as well. So the 'tick'-script might be an
appropriate script for reproducing this error...
My host closed with the following syslog message when executing the
'tick':
===SNIP OF SYSLOG:
Ereignistyp:Informationen
Ereignisquelle: Application Popup
Ereigniskategorie: Keine
Ereigniskennung:26
Datum: 28.06.2004
Zeit:
#29985 [Fbk->Csd]: unserialize()/ __PHP_Incomplete_class does not report correctly class name
ID: 29985
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Closed
Bug Type: Session related
Operating System: Linux
PHP Version: 5CVS-2004-09-05 (dev)
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2004-09-05 14:30:14] [EMAIL PROTECTED]
Hmm.. I really don't understand why incomplete_class_message() looks
for class_name in EG(This), while class_name is property of the object,
which could be easily passed to incomplete_class_message().
So, this patch should probably fix it:
http://tony2001.phpclub.net/dev/tmp/bug29985.diff
Comments are welcome.
[2004-09-05 13:47:38] [EMAIL PROTECTED]
Description:
The idea is that when an object is unserialized and the class
definition is still not loaded then it is converted to
__PHP_Incomplete_Class class. From the dump of the actual result one
can see that the name is stored in a member variable
__PHP_Incomplete_Class_Name. So far everything looks ok. But when one
tries to execute a method on incomplete class object it leads to a
fatal error. This is also correct. However the name of the class is
"unknown" is the message. This is not correct and the example works
with PHP 4.3.8(cli). However does not work with current HEAD (probably
not with the PHP_5 branch).
One additional thing is that the message is misleading. A serialized
object may not come always from a session but can be loaded from a file
by the user or ,like in my case where I found the error, from a socket.
Thanks
Reproduce code:
---
php -r 'class foo{function someFunc(){} var
$someProp=2;}$a=serialize(new foo());$b=str_replace('foo','bar',
$a);var_dump($c = unserialize($b));$c->someFunc();'
Expected result:
object(__PHP_Incomplete_Class)#1 (2) {
["__PHP_Incomplete_Class_Name"]=>
string(3) "bar"
["someProp"]=>
int(2)
}
Fatal error: Unknown: The script tried to execute a method or access a
property of an incomplete object. Please ensure that the class
definition bar of the object you are trying to operate on was
loaded _before_ the session was started in Command line code on line 1
Actual result:
--
object(__PHP_Incomplete_Class)#1 (2) {
["__PHP_Incomplete_Class_Name"]=>
string(3) "bar"
["someProp"]=>
int(2)
}
Fatal error: Unknown: The script tried to execute a method or access a
property of an incomplete object. Please ensure that the class
definition unknown of the object you are trying to operate on
was loaded _before_ the session was started in Command line code on
line 1
--
Edit this bug report at http://bugs.php.net/?id=29985&edit=1
#29548 [Opn]: Apache2/PHP Module crashes
ID: 29548 User updated by: tom at ideaweb dot de Reported By: tom at ideaweb dot de Status: Open Bug Type: XSLT related Operating System: Debian Testing PHP Version: 4.3.8 New Comment: it happens with sablot 1.0.1. with 0.98 there are no problems. Previous Comments: [2004-09-04 21:47:43] [EMAIL PROTECTED] Use ext/domlxml and its xslt support instead. [2004-08-07 13:49:00] [EMAIL PROTECTED] Looks like a problem in the XSLT/Sablotron extension of PHP 4.3 (not my area ;) ) [2004-08-06 15:18:12] tom at ideaweb dot de Description: hi, i have a small content management system, which transforms xml documents to evaluated php templates. with huge data the apache2.0.50 crashes with the following message in the error log: httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:15:58 2004] [notice] child pid 20982 exit signal Aborted (6) httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:16:08 2004] [notice] child pid 21091 exit signal Aborted (6) httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:23:50 2004] [notice] child pid 21440 exit signal Aborted (6) httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:50:11 2004] [notice] child pid 28053 exit signal Aborted (6) httpd: domprovider.h:269: virtual SXP_NodeType DOMProviderUniversal::getNodeType(void*): Assertion `!! (external)' failed. [Mon Aug 02 20:52:20 2004] [notice] child pid 28197 exit signal Aborted (6) if i change some content in cdata notes, the transformation over sabltron xsl works in some cases again. with small documents no problem. Reproduce code: --- sorry its to complex to post this in 20 line. if you have questions contact me. Expected result: no crashes at any kind programming failures... Actual result: -- root:/etc/firewall# /www/apache/current/bin/httpd -X Aborted the apache webserver quits only with "Aborted",the the same error message in the error log and without a core file. ??? -- Edit this bug report at http://bugs.php.net/?id=29548&edit=1
#29987 [Opn->Bgs]: Errors with encoding
ID: 29987 Updated by: [EMAIL PROTECTED] Reported By: lehphyro at yahoo dot com dot br -Status: Open +Status: Bogus Bug Type: SimpleXML related Operating System: Windows PHP Version: 5.0.1 New Comment: Duplicate of #29988. Previous Comments: [2004-09-05 17:17:17] lehphyro at yahoo dot com dot br Description: I tried to load a xml file with ISO-8859-1 encoding. I have tried several ways for loading, but I had no success because simplexml returns the loaded string with errors. I have tried iconv functions too. Reproduce code: --- file test.php: movie[0]->plot; ?> file example.php: Matrícula XML; ?> Expected result: Matrícula Actual result: -- MatrÃcula -- Edit this bug report at http://bugs.php.net/?id=29987&edit=1
#29987 [NEW]: Errors with encoding
From: lehphyro at yahoo dot com dot br Operating system: Windows PHP version: 5.0.1 PHP Bug Type: SimpleXML related Bug description: Errors with encoding Description: I tried to load a xml file with ISO-8859-1 encoding. I have tried several ways for loading, but I had no success because simplexml returns the loaded string with errors. I have tried iconv functions too. Reproduce code: --- file test.php: movie[0]->plot; ?> file example.php: Matrícula XML; ?> Expected result: Matrícula Actual result: -- MatrÃcula -- Edit bug report at http://bugs.php.net/?id=29987&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29987&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29987&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29987&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=29987&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=29987&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29987&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29987&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29987&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=29987&r=support Expected behavior: http://bugs.php.net/fix.php?id=29987&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=29987&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=29987&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=29987&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29987&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=29987&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29987&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=29987&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29987&r=float
#29988 [NEW]: Errors with encoding
From: lehphyro at yahoo dot com dot br Operating system: Windows PHP version: 5.0.1 PHP Bug Type: SimpleXML related Bug description: Errors with encoding Description: I tried to load a xml file with ISO-8859-1 encoding. I have tried several ways for loading, but I had no success because simplexml returns the loaded string with errors. I have tried iconv functions too. Reproduce code: --- file test.php: movie[0]->plot; ?> file example.php: Matrícula XML; ?> Expected result: Matrícula Actual result: -- MatrÃcula -- Edit bug report at http://bugs.php.net/?id=29988&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29988&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29988&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29988&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=29988&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=29988&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29988&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29988&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29988&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=29988&r=support Expected behavior: http://bugs.php.net/fix.php?id=29988&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=29988&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=29988&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=29988&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29988&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=29988&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29988&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=29988&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29988&r=float
#29986 [NEW]: Class constants won't work with predefined constants when using ReflectionClass
From: mitchel at sahertian dot com
Operating system: Linux 2.6.8.1 x86
PHP version: 5.0.1
PHP Bug Type: Zend Engine 2 problem
Bug description: Class constants won't work with predefined constants when using
ReflectionClass
Description:
I have a variable classname i have to get a constant/static property
from.
${$classname}::stuff
doesn't work, so i have to use the reflection api.
This works for strings and numbers, but when i try to use getConstant()
upon a constant that is defined as another constant, it returns
UNKNOWN:0.
This happens for user defined constants as well as things like `true'.
Reproduce code:
---
getConstant("foo"));
var_dump($o->getConstant("bar"));
var_dump($o->getConstant("works"));
?>
Expected result:
bool(true)
int(8)
string(11) "yes it does"
Actual result:
--
UNKNOWN:0
UNKNOWN:0
string(11) "yes it does"
--
Edit bug report at http://bugs.php.net/?id=29986&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29986&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29986&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29986&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=29986&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=29986&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29986&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29986&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29986&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=29986&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29986&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=29986&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=29986&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=29986&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29986&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=29986&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29986&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=29986&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29986&r=float
#29978 [Csd->Bgs]: Using acute in DomElements
ID: 29978
Updated by: [EMAIL PROTECTED]
Reported By: guillaume dot forget at espci dot fr
-Status: Closed
+Status: Bogus
Bug Type: DOM XML related
Operating System: NetBSD
PHP Version: Irrelevant
Previous Comments:
[2004-09-05 15:29:12] guillaume dot forget at espci dot fr
Ok thanks, it's work well now.
[2004-09-04 19:01:19] [EMAIL PROTECTED]
DOMXML expects UTF-8 encoded input for set_attribute (and all other
functions except loading a whole XML document, where the XML header is
recognized)
[2004-09-04 13:37:57] guillaume dot forget at espci dot fr
In the code, you have to read
$balise = $node->append_child($test_node);
instead of:
$balise = $node->append_child($poly_node);
[2004-09-04 13:33:49] guillaume dot forget at espci dot fr
Description:
Hi!
I'm using domxml function for modifying xml files.
But when I put acute (é,è,à,ô,ï,...), and try a
DomElement->set_attribute(...), the resulting dom object is truncated
at the acute place.
I do not think the problem come from the DomObj->dump_mem() or
DomObj->dump_file(...) functions because both gave the same result.
If I remove the acutes, it works fine.
Reproduce code:
---
$xmlfile="test.xml";
$text="c'est l'été !";
$domobj = domxml_open_file ($xmlfile);
$node = $domobj->last_child();
$test_node = $domobj->create_element("balise2");
$balise = $node->append_child($poly_node);
$balise->set_attribute (test,$text);
echo $domobj->dump_mem();
XML file (test.xml):
Expected result:
Actual result:
--
--
Edit this bug report at http://bugs.php.net/?id=29978&edit=1
#29978 [Bgs->Csd]: Using acute in DomElements
ID: 29978
User updated by: guillaume dot forget at espci dot fr
Reported By: guillaume dot forget at espci dot fr
-Status: Bogus
+Status: Closed
Bug Type: DOM XML related
Operating System: NetBSD
PHP Version: Irrelevant
New Comment:
Ok thanks, it's work well now.
Previous Comments:
[2004-09-04 19:01:19] [EMAIL PROTECTED]
DOMXML expects UTF-8 encoded input for set_attribute (and all other
functions except loading a whole XML document, where the XML header is
recognized)
[2004-09-04 13:37:57] guillaume dot forget at espci dot fr
In the code, you have to read
$balise = $node->append_child($test_node);
instead of:
$balise = $node->append_child($poly_node);
[2004-09-04 13:33:49] guillaume dot forget at espci dot fr
Description:
Hi!
I'm using domxml function for modifying xml files.
But when I put acute (é,è,à,ô,ï,...), and try a
DomElement->set_attribute(...), the resulting dom object is truncated
at the acute place.
I do not think the problem come from the DomObj->dump_mem() or
DomObj->dump_file(...) functions because both gave the same result.
If I remove the acutes, it works fine.
Reproduce code:
---
$xmlfile="test.xml";
$text="c'est l'été !";
$domobj = domxml_open_file ($xmlfile);
$node = $domobj->last_child();
$test_node = $domobj->create_element("balise2");
$balise = $node->append_child($poly_node);
$balise->set_attribute (test,$text);
echo $domobj->dump_mem();
XML file (test.xml):
Expected result:
Actual result:
--
--
Edit this bug report at http://bugs.php.net/?id=29978&edit=1
#29983 [Com]: default_charset not set by ini_set
ID: 29983 Comment by: smacvicar at gmail dot com Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache2 related Operating System: all PHP Version: 5CVS-2004-09-05 (dev) New Comment: It doesn't appear to send a charset entry when specified and you end up with the AddDefaultCharset entry from Apache 2 which is ISO-8859-1. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23421 Previous Comments: [2004-09-05 12:37:28] [EMAIL PROTECTED] Description: default_charset is marked as PHP_INI_ALL but I can't set it using ini_set. If I set it throught .htaccess it works fine. Reproduce code: --- Expected result: HTTP/1.1 200 OK (...) Content-Type: text/html; charset=UTF-8 Actual result: -- HTTP/1.1 200 OK (...) Content-Type: text/html; charset=ISO-8859-1 -- Edit this bug report at http://bugs.php.net/?id=29983&edit=1
#29985 [Opn->Fbk]: unserialize()/ __PHP_Incomplete_class does not report correctly class name
ID: 29985
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: Linux
PHP Version: 5CVS-2004-09-05 (dev)
New Comment:
Hmm.. I really don't understand why incomplete_class_message() looks
for class_name in EG(This), while class_name is property of the object,
which could be easily passed to incomplete_class_message().
So, this patch should probably fix it:
http://tony2001.phpclub.net/dev/tmp/bug29985.diff
Comments are welcome.
Previous Comments:
[2004-09-05 13:47:38] [EMAIL PROTECTED]
Description:
The idea is that when an object is unserialized and the class
definition is still not loaded then it is converted to
__PHP_Incomplete_Class class. From the dump of the actual result one
can see that the name is stored in a member variable
__PHP_Incomplete_Class_Name. So far everything looks ok. But when one
tries to execute a method on incomplete class object it leads to a
fatal error. This is also correct. However the name of the class is
"unknown" is the message. This is not correct and the example works
with PHP 4.3.8(cli). However does not work with current HEAD (probably
not with the PHP_5 branch).
One additional thing is that the message is misleading. A serialized
object may not come always from a session but can be loaded from a file
by the user or ,like in my case where I found the error, from a socket.
Thanks
Reproduce code:
---
php -r 'class foo{function someFunc(){} var
$someProp=2;}$a=serialize(new foo());$b=str_replace('foo','bar',
$a);var_dump($c = unserialize($b));$c->someFunc();'
Expected result:
object(__PHP_Incomplete_Class)#1 (2) {
["__PHP_Incomplete_Class_Name"]=>
string(3) "bar"
["someProp"]=>
int(2)
}
Fatal error: Unknown: The script tried to execute a method or access a
property of an incomplete object. Please ensure that the class
definition bar of the object you are trying to operate on was
loaded _before_ the session was started in Command line code on line 1
Actual result:
--
object(__PHP_Incomplete_Class)#1 (2) {
["__PHP_Incomplete_Class_Name"]=>
string(3) "bar"
["someProp"]=>
int(2)
}
Fatal error: Unknown: The script tried to execute a method or access a
property of an incomplete object. Please ensure that the class
definition unknown of the object you are trying to operate on
was loaded _before_ the session was started in Command line code on
line 1
--
Edit this bug report at http://bugs.php.net/?id=29985&edit=1
#29985 [NEW]: unserialize()/ __PHP_Incomplete_class does not report correctly class name
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 5CVS-2004-09-05 (dev)
PHP Bug Type: Session related
Bug description: unserialize()/ __PHP_Incomplete_class does not report correctly
class name
Description:
The idea is that when an object is unserialized and the class definition
is still not loaded then it is converted to __PHP_Incomplete_Class
class. From the dump of the actual result one can see that the name is
stored in a member variable __PHP_Incomplete_Class_Name. So far everything
looks ok. But when one tries to execute a method on incomplete class object
it leads to a fatal error. This is also correct. However the name of the
class is "unknown" is the message. This is not correct and the example
works with PHP 4.3.8(cli). However does not work with current HEAD
(probably not with the PHP_5 branch).
One additional thing is that the message is misleading. A serialized
object may not come always from a session but can be loaded from a file by
the user or ,like in my case where I found the error, from a socket.
Thanks
Reproduce code:
---
php -r 'class foo{function someFunc(){} var $someProp=2;}$a=serialize(new
foo());$b=str_replace('foo','bar', $a);var_dump($c =
unserialize($b));$c->someFunc();'
Expected result:
object(__PHP_Incomplete_Class)#1 (2) {
["__PHP_Incomplete_Class_Name"]=>
string(3) "bar"
["someProp"]=>
int(2)
}
Fatal error: Unknown: The script tried to execute a method or access a
property of an incomplete object. Please ensure that the class definition
bar of the object you are trying to operate on was loaded _before_
the session was started in Command line code on line 1
Actual result:
--
object(__PHP_Incomplete_Class)#1 (2) {
["__PHP_Incomplete_Class_Name"]=>
string(3) "bar"
["someProp"]=>
int(2)
}
Fatal error: Unknown: The script tried to execute a method or access a
property of an incomplete object. Please ensure that the class definition
unknown of the object you are trying to operate on was loaded
_before_ the session was started in Command line code on line 1
--
Edit bug report at http://bugs.php.net/?id=29985&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29985&r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29985&r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29985&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=29985&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=29985&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29985&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29985&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29985&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=29985&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29985&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=29985&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=29985&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=29985&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29985&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=29985&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29985&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=29985&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29985&r=float
#29979 [Opn->Bgs]: mysqli - compilation error
ID: 29979 Updated by: [EMAIL PROTECTED] Reported By: x-penguin at tut dot by -Status: Open +Status: Bogus Bug Type: MySQLi related Operating System: Linux PHP Version: 5CVS-2004-09-04 (dev) New Comment: x-penguin at tut dot by: Georg pointed you out the problem. Fix your mysql install and figure out why there are old headers in your system. Not a PHP bug -> bogus. Previous Comments: [2004-09-05 13:04:16] nospam at nospam dot org Guys, why don't ask your sys admins to install the things for you instead to bother php dev's with your broken systems? The errormessage indicates, that an include file is used, which is from versions < 4.1. Fix your broken installation first! [2004-09-04 22:16:01] x-penguin at tut dot by client libraries are located only in /usr/lib: /usr/lib/libmysqlclient_r.so /usr/lib/libmysqlclient.so /usr/lib/libmysqlclient_r.so.14 /usr/lib/libmysqlclient.so.14 /usr/lib/libmysqlclient_r.so.14.0.0 /usr/lib/libmysqlclient.so.14.0.0 [2004-09-04 21:52:25] schlueter at phpbar dot de As Georg wrote: Both - MySQL and MySQLi need the same library and you are using one in /usr and one in /opt [2004-09-04 20:06:22] x-penguin at tut dot by :) yes, I read this manual, and I use client libraries from mysql4.1... [2004-09-04 19:20:42] [EMAIL PROTECTED] RTFM! >From our fine manual: Installation To install the mysqli extension for PHP, use the --with-mysqli=mysql_config_path/mysql_config configuration option where mysql_config_path represents the location of the mysql_config program that comes with MySQL versions greater than 4.1. If you would like to install the mysql extension along with the mysqli extension you have to use the same client library to avoid any conflicts. 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/29979 -- Edit this bug report at http://bugs.php.net/?id=29979&edit=1
#29979 [Com]: mysqli - compilation error
ID: 29979 Comment by: nospam at nospam dot org Reported By: x-penguin at tut dot by Status: Open Bug Type: MySQLi related Operating System: Linux PHP Version: 5CVS-2004-09-04 (dev) New Comment: Guys, why don't ask your sys admins to install the things for you instead to bother php dev's with your broken systems? The errormessage indicates, that an include file is used, which is from versions < 4.1. Fix your broken installation first! Previous Comments: [2004-09-04 22:16:01] x-penguin at tut dot by client libraries are located only in /usr/lib: /usr/lib/libmysqlclient_r.so /usr/lib/libmysqlclient.so /usr/lib/libmysqlclient_r.so.14 /usr/lib/libmysqlclient.so.14 /usr/lib/libmysqlclient_r.so.14.0.0 /usr/lib/libmysqlclient.so.14.0.0 [2004-09-04 21:52:25] schlueter at phpbar dot de As Georg wrote: Both - MySQL and MySQLi need the same library and you are using one in /usr and one in /opt [2004-09-04 20:06:22] x-penguin at tut dot by :) yes, I read this manual, and I use client libraries from mysql4.1... [2004-09-04 19:20:42] [EMAIL PROTECTED] RTFM! >From our fine manual: Installation To install the mysqli extension for PHP, use the --with-mysqli=mysql_config_path/mysql_config configuration option where mysql_config_path represents the location of the mysql_config program that comes with MySQL versions greater than 4.1. If you would like to install the mysql extension along with the mysqli extension you have to use the same client library to avoid any conflicts. [2004-09-04 17:43:19] x-penguin at tut dot by Description: ./configure --prefix=/usr/ --with-apxs2 --with-gettext --with-iconv --with-mysql=/usr --with-mysql-sock=/tmp/mysql.sock --enable-mbstring=ru --enable-mbregex --enable-mbstr-enc-trans --disable-short-tags --with-xsl --with-libxml --without-sqlite --enable-soap --with-pgsql --with-mysqli=/opt/mysql-4.1.3/bin/mysql_config --with-mysqli-sock=/tmp/mysql-4.1.3.sock /bin/sh /mnt/data/Sources/php-src/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/mysqli/ -I/mnt/data/Sources/php-src/ext/mysqli/ -DPHP_ATOM_INC -I/mnt/data/Sources/php-src/include -I/mnt/data/Sources/php-src/main -I/mnt/data/Sources/php-src -I/mnt/data/Sources/php-src/Zend -I/usr//include/libxml2 -I/mnt/data/Sources/php-src/ext/mbstring/oniguruma -I/mnt/data/Sources/php-src/ext/mbstring/libmbfl -I/mnt/data/Sources/php-src/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/opt/mysql-4.1.3/include/mysql -I/usr//include -I/mnt/data/Sources/php-src/TSRM -g -O2 -prefer-pic -c /mnt/data/Sources/php-src/ext/mysqli/mysqli.c -o ext/mysqli/mysqli.lo In file included from /mnt/data/Sources/php-src/ext/mysqli/mysqli.c:31: /mnt/data/Sources/php-src/ext/mysqli/php_mysqli.h:48: error: syntax error before "MYSQL_STMT" /mnt/data/Sources/php-src/ext/mysqli/php_mysqli.h:48: warning: no semicolon at end of struct or union /mnt/data/Sources/php-src/ext/mysqli/php_mysqli.h:52: error: syntax error before '}' token /mnt/data/Sources/php-src/ext/mysqli/php_mysqli.h:52: warning: data definition has no type or storage class /mnt/data/Sources/php-src/ext/mysqli/php_mysqli.h:85: error: `LOCAL_INFILE_ERROR_LEN' undeclared here (not in a function) /mnt/data/Sources/php-src/ext/mysqli/php_mysqli.h:113: error: syntax error before '*' token /mnt/data/Sources/php-src/ext/mysqli/mysqli.c:91: error: syntax error before '*' token /mnt/data/Sources/php-src/ext/mysqli/mysqli.c: In function `php_clear_stmt_bind': /mnt/data/Sources/php-src/ext/mysqli/mysqli.c:93: error: `stmt' undeclared (first use in this function) /mnt/data/Sources/php-src/ext/mysqli/mysqli.c:93: error: (Each undeclared identifier is reported only once /mnt/data/Sources/php-src/ext/mysqli/mysqli.c:93: error: for each function it appears in.) /mnt/data/Sources/php-src/ext/mysqli/mysqli.c: In function `mysqli_objects_free_storage': /mnt/data/Sources/php-src/ext/mysqli/mysqli.c:140: error: syntax error before ')' token /mnt/data/Sources/php-src/ext/mysqli/mysqli.c: In function `mysqli_read_property': /mnt/data/Sources/php-src/ext/mysqli/mysqli.c:210: error: `MYSQL_STMT' undeclared (first use in this function) /mnt/data/Sources/php-src/ext/mysqli/mysqli.c:210: error: syntax error before ')' token /mnt/data/Sources/php-src/ext/mysqli/mysqli.c:210: error: syntax error before ')' token /mnt/data/Sources/php-src/ext/mysqli/mysqli.c: In function `zm_startup_mysqli': /mnt/data/Sources/php-src/ext/mysqli/mysqli.c:459: error: `STMT_ATTR_UPDATE_MAX_LENGTH' undeclared (first use in this function) /mnt/data/Sources/php-src/
#29983 [NEW]: default_charset not set by ini_set
From: [EMAIL PROTECTED] Operating system: all PHP version: 5CVS-2004-09-05 (dev) PHP Bug Type: Apache2 related Bug description: default_charset not set by ini_set Description: default_charset is marked as PHP_INI_ALL but I can't set it using ini_set. If I set it throught .htaccess it works fine. Reproduce code: --- Expected result: HTTP/1.1 200 OK (...) Content-Type: text/html; charset=UTF-8 Actual result: -- HTTP/1.1 200 OK (...) Content-Type: text/html; charset=ISO-8859-1 -- Edit bug report at http://bugs.php.net/?id=29983&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29983&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=29983&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=29983&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=29983&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=29983&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29983&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29983&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29983&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=29983&r=support Expected behavior: http://bugs.php.net/fix.php?id=29983&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=29983&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=29983&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=29983&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29983&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=29983&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29983&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=29983&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29983&r=float
#24843 [Com]: session_regenerate_id does not call user-defined session functions
ID: 24843 Comment by: hdNOSPAM at phportals dot de Reported By: luttgens at fusl dot ac dot be Status: Open Bug Type: Session related Operating System: * PHP Version: php >= 4.3.2 New Comment: PHP MUST call the user functions to destroy the old session data. The now working way is a high risk, because people expect another implementation than it is now. Previous Comments: [2004-07-13 07:20:17] support at spill dot nl Unless this is handled differently for the default (file-based) session handler, the current implementation of session_regenerate_id() would leave stale files (possibly containing sensitive session data). I agree with nathan php should go the long way and make sure to destroy the old session. About the calling of the write function of user defined session handlers even on empty sessions, ages ago I reported this bug: http://bugs.php.net/bug.php?id=25954 I think this should either be fixed in the documentation, or (if this is unwanted behaviour) in PHP itself. [2004-06-29 08:34:45] [EMAIL PROTECTED] if using a user based session handler, php should go the long way in changing a session id. Currently php just changes the session id on an existing session stored, this is fine and good with like files (havent tested sqlite), but with user, creates some problems. The session handler just creates a new session, so you have two active, and keeps the data in the first, and the second one empty. PHP should really copy all data, destroy the old session, create the new session, and import the data into the new session. This avoids any issues with some session handlers that exist these days. thats my opinion anyway, better compatibility, even though theres a little overhead added. [2003-07-29 06:38:44] [EMAIL PROTECTED] Yes, the documentation should be cleared up a bit. [2003-07-29 03:53:12] luttgens at fusl dot ac dot be Thanks for your reply, Sniper. This has been the opportunity to understand I've been somewhat too elliptic... So, if you allow, I will try to restate what I had in mind. Let's say I have defined my own session storage management through 6 functions (the args for session_set_save_handler()). On ***my*** system, the behavior seems to be as follows: Call to sessions_start(): 1. _open() gets called 2. _read($id) gets called 3. _gc($time) may be called (according to the "probability") Then, upon script completion: 4. _write($id, $data) gets called 5. _close() gets called Now, if session_regenerate_id() is called after session_start(), argument $id in step 4. indeed differs from what it was in step 2. And this could be used as an indication that an id regeneration has been performed, thus needing some housekeeping. BUT... Above description (steps 1. through 5.) is not explicitely documented, and thus by no means has an official status: it is just empirical. Thus, a first question is: "Does aforementioned change in $id occur through AND ONLY THROUGH a call to session_regenerate_id()?" Moreover, the documentation states: "The write handler is not executed if the session contains no data; this applies even if empty session variables are registered". On ***my*** system, _write($id, $data) seems to be allways called. But if the documentation is right (and my system being thus bogus), it couldn't be relied anymore upon a change in the value of argument id (as step 4. wouldn't occur). Another question is thus: "Could session_id() be reliably used in place to track a possible call to session_regenerate_id()?". Again, such a question occurs because trials tend to show that session_id() indeed reflects the effects of session_regenerate_id(), but this too is empirical only. I would feel more confident if the documentation established true and explicit cross-references for session_id() and session_regenerate_id(). Another formulation could be as follows. A. _read($id), _write($id, $data) and _destroy($id) all have an argument for a session-id. B. session_id() allows to read a "current" session-id. C. session_regenerate_id() allows to operate upon a "current" session-id. May it be taken for granted that all those things systematically refer to the same entity, so that they are allways in sync? Or does one really need some kind of feedback in the user-defined session functions upon a call of session_regenerate_id()? Could just be a kind of documentation "bug". Anyway, thanks again for the follow-up. [2003-07-28 10:21:10] [EMAIL PROTECTED] session_regenerate_id() only resets the current session id. Nothing else. -
#10202 [Com]: java script does not work in linux browser, what is the reason
ID: 10202 Comment by: asdfasdfsdf at one dot lt Reported By: prasad at vsnl dot com Status: Bogus Bug Type: *General Issues Operating System: linux PHP Version: 4.0.4pl1 New Comment: asfsdfafasdfasdf Previous Comments: [2001-04-06 06:59:02] [EMAIL PROTECTED] Not a PHP bug, and please read www.php.net/bugs-dos-and-donts.php if you encounter a real PHP bug in the future. [2001-04-06 06:58:17] [EMAIL PROTECTED] PHP is a server side language, java script and browsers are client side [2001-04-06 06:45:31] prasad at vsnl dot com -- Edit this bug report at http://bugs.php.net/?id=10202&edit=1
#29977 [Bgs->Opn]: bool cast of "0000000000000"
ID: 29977 Updated by: [EMAIL PROTECTED] Reported By: hd dot php at aimail dot de -Status: Bogus +Status: Open Bug Type: Feature/Change Request Operating System: linux PHP Version: 4.3.7 New Comment: "00" is a string, like any other string. The only other string that will evaluate to false is "0". This may, however, be something we should fix, and at the very least document - what do others think? TRUE: $ php -r 'var_dump((bool)"00");' FALSE: $ php -r 'var_dump((bool)"0");' Previous Comments: [2004-09-05 10:03:54] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php "00" is a string, like any other string. The only other string that will evaluate to false is "0". This may, however, be something we should fix, and at the very least document - what do others think? [2004-09-04 01:22:36] hd dot php at aimail dot de Description: * PHP Version 4.3.4 * bool cast of "0" should be false, not true. A "0" is returned from mysql timestamp fields. (bool)"0" should be consistent with (bool)(int)"0" At this point it is not. Reproduce code: --- Expected result: false Actual result: -- true -- Edit this bug report at http://bugs.php.net/?id=29977&edit=1
#29977 [Opn->Bgs]: bool cast of "0000000000000"
ID: 29977 Updated by: [EMAIL PROTECTED] Reported By: hd dot php at aimail dot de -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: linux PHP Version: 4.3.7 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 "00" is a string, like any other string. The only other string that will evaluate to false is "0". This may, however, be something we should fix, and at the very least document - what do others think? Previous Comments: [2004-09-04 01:22:36] hd dot php at aimail dot de Description: * PHP Version 4.3.4 * bool cast of "0" should be false, not true. A "0" is returned from mysql timestamp fields. (bool)"0" should be consistent with (bool)(int)"0" At this point it is not. Reproduce code: --- Expected result: false Actual result: -- true -- Edit this bug report at http://bugs.php.net/?id=29977&edit=1
#29980 [Opn]: Segfault
ID: 29980
Updated by: [EMAIL PROTECTED]
Reported By: guth at fiifo dot u-psud dot fr
Status: Open
Bug Type: Zend Engine 2 problem
Operating System: linux (Mandrake 10)
PHP Version: 5.0.1
New Comment:
I can reproduce it with HEAD:
#0 0x08191ee4 in zend_objects_destroy_object (object=0x8285434,
handle=2) at /home/dev/php-src/Zend/zend_objects.c:37
#1 0x08194a6c in zend_objects_store_del_ref (zobject=0x827289c) at
/home/dev/php-src/Zend/zend_objects_API.c:144
#2 0x0817b95e in _zval_dtor (zvalue=0x827289c,
__zend_filename=0x81e3520 "/home/dev/php-src/Zend/zend_execute_API.c",
__zend_lineno=390)
at /home/dev/php-src/Zend/zend_variables.c:55
#3 0x08170431 in _zval_ptr_dtor (zval_ptr=0x82727e8,
__zend_filename=0x81e4420 "/home/dev/php-src/Zend/zend_variables.c",
__zend_lineno=179)
at /home/dev/php-src/Zend/zend_execute_API.c:390
#4 0x0817bc63 in _zval_ptr_dtor_wrapper (zval_ptr=0x82727e8) at
/home/dev/php-src/Zend/zend_variables.c:179
#5 0x08185224 in zend_hash_destroy (ht=0x82802ac) at
/home/dev/php-src/Zend/zend_hash.c:519
#6 0x0819214a in zend_objects_free_object_storage (object=0x827279c)
at /home/dev/php-src/Zend/zend_objects.c:88
#7 0x081947c9 in zend_objects_store_free_object_storage
(objects=0x8201eac) at /home/dev/php-src/Zend/zend_objects_API.c:72
#8 0x0816ff60 in shutdown_executor () at
/home/dev/php-src/Zend/zend_execute_API.c:271
#9 0x0817d3ad in zend_deactivate () at
/home/dev/php-src/Zend/zend.c:826
#10 0x081376ce in php_request_shutdown (dummy=0x0) at
/home/dev/php-src/main/main.c:1216
#11 0x081b07e0 in main (argc=3, argv=0xb8d4) at
/home/dev/php-src/sapi/cli/php_cli.c:1046
Previous Comments:
[2004-09-05 09:08:05] [EMAIL PROTECTED]
Running your reproducable code on the latest CVS version (PHP
5.1.0-dev-200409050430)
$ php demo.php
PHP Fatal error: Call to undefined method
Cowllectif::jean_ai_marre_de_php() in /home/aidan/demo.php on line 10
Fatal error: Call to undefined method
Cowllectif::jean_ai_marre_de_php() in /home/aidan/demo.php on line 10
PHP Fatal error: Call to undefined method
Cowllectif::jean_ai_marre_de_php() in /home/aidan/demo.php on line 14
Fatal error: Call to undefined method
Cowllectif::jean_ai_marre_de_php() in /home/aidan/demo.php on line 14
Running on PHP 5.0.2-dev
$ php demo.php
Fatal error: Call to undefined method
Cowllectif::jean_ai_marre_de_php() in /home/aidan/demo.php on line 10
Fatal error: Call to undefined method
Cowllectif::jean_ai_marre_de_php() in /home/aidan/demo.php on line 14
Looks fine to me. Perhaps it was fixed in CVS, perhaps it is Bogus.
Could you try the latest CVS version and tell me if this bug still
exists?
[2004-09-04 19:33:56] guth at fiifo dot u-psud dot fr
Description:
I am happy to show you my fourth segmentation fault in PHP 5.0.1.
Segmentation faults don't help me to debug my code...
Reproduce code:
---
boom = new Cowllectif;
$this->boom->jean_ai_marre_de_php();
}
public function __destruct() {
$this->boom->jean_ai_marre_de_php();
}
}
$test = new CowllectifTest();
unset($test);
?>
Expected result:
Fatal error - Call to undefined method
Cowllectif::jean_ai_marre_de_php()
Actual result:
--
Two fatal errors (sic), then a segmentation fault...
Apache error log :
/www/haricow/0.4/test.php(10) : Fatal error - Call to undefined method
Cowllectif::jean_ai_marre_de_php()
/www/haricow/0.4/test.php(14) : Fatal error - Call to undefined method
Cowllectif::jean_ai_marre_de_php()
[Sat Sep 4 19:28:02 2004] [notice] child pid 9981 exit signal
Segmentation fault (11)
--
Edit this bug report at http://bugs.php.net/?id=29980&edit=1
#29980 [Opn]: Segfault
ID: 29980
Updated by: [EMAIL PROTECTED]
Reported By: guth at fiifo dot u-psud dot fr
Status: Open
Bug Type: Zend Engine 2 problem
Operating System: linux (Mandrake 10)
PHP Version: 5.0.1
New Comment:
Running your reproducable code on the latest CVS version (PHP
5.1.0-dev-200409050430)
$ php demo.php
PHP Fatal error: Call to undefined method
Cowllectif::jean_ai_marre_de_php() in /home/aidan/demo.php on line 10
Fatal error: Call to undefined method
Cowllectif::jean_ai_marre_de_php() in /home/aidan/demo.php on line 10
PHP Fatal error: Call to undefined method
Cowllectif::jean_ai_marre_de_php() in /home/aidan/demo.php on line 14
Fatal error: Call to undefined method
Cowllectif::jean_ai_marre_de_php() in /home/aidan/demo.php on line 14
Running on PHP 5.0.2-dev
$ php demo.php
Fatal error: Call to undefined method
Cowllectif::jean_ai_marre_de_php() in /home/aidan/demo.php on line 10
Fatal error: Call to undefined method
Cowllectif::jean_ai_marre_de_php() in /home/aidan/demo.php on line 14
Looks fine to me. Perhaps it was fixed in CVS, perhaps it is Bogus.
Could you try the latest CVS version and tell me if this bug still
exists?
Previous Comments:
[2004-09-04 19:33:56] guth at fiifo dot u-psud dot fr
Description:
I am happy to show you my fourth segmentation fault in PHP 5.0.1.
Segmentation faults don't help me to debug my code...
Reproduce code:
---
boom = new Cowllectif;
$this->boom->jean_ai_marre_de_php();
}
public function __destruct() {
$this->boom->jean_ai_marre_de_php();
}
}
$test = new CowllectifTest();
unset($test);
?>
Expected result:
Fatal error - Call to undefined method
Cowllectif::jean_ai_marre_de_php()
Actual result:
--
Two fatal errors (sic), then a segmentation fault...
Apache error log :
/www/haricow/0.4/test.php(10) : Fatal error - Call to undefined method
Cowllectif::jean_ai_marre_de_php()
/www/haricow/0.4/test.php(14) : Fatal error - Call to undefined method
Cowllectif::jean_ai_marre_de_php()
[Sat Sep 4 19:28:02 2004] [notice] child pid 9981 exit signal
Segmentation fault (11)
--
Edit this bug report at http://bugs.php.net/?id=29980&edit=1
