#21509 [NEW]: Duplication when creating a new Table
From: [EMAIL PROTECTED] Operating system: RedHat 8 PHP version: 4.2.2 PHP Bug Type: *General Issues Bug description: Duplication when creating a new Table I'm Not to sure if this is a problem with phpMyAdmin or if this is php problem Running php-4.2.2-8.0.5 httpd-2.0.40-8 mysql-3.23.52-3 RedHat 8 php configure line reads ./configure' '--host=i686-pc-linux-gnu' '--build=i686-pc-linux-gnu' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--prefix=/usr' '--with-config-file-path=/etc' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db3' '--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-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' '--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-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--with-apxs2=/usr/sbin/apxs' Which is standard install with RH 8 and as soon as try to create a new table with phpMyAdmin 2.3.0 This is the SQL it tries to run. NOTE it duplicates on line 5,6,7 1 CREATE TABLE `wt_test` ( 2 `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY , 3 `name` VARCHAR( 50 ) , 4 `what` VARCHAR( 50 ) , 5 `id` INT NOT NULL AUTO_INCREMENT, 6 `name` VARCHAR( 50 ) , 7 `what` VARCHAR( 50 ) 8 ) and all i wanted was line 1,2,3 Regards Marcus -- Edit bug report at http://bugs.php.net/?id=21509&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21509&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21509&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21509&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21509&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21509&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21509&r=support Expected behavior: http://bugs.php.net/fix.php?id=21509&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21509&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21509&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21509&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21509&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21509&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21509&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21509&r=gnused
#21704 [NEW]: parse_url() degraded since 4.2.3
From: [EMAIL PROTECTED]
Operating system: Mandrake 8.1/Ximian
PHP version: 4.3.0
PHP Bug Type: HTTP related
Bug description: parse_url() degraded since 4.2.3
$unit_test->print_r(parse_url("http://localhost?key3=value3";));
Gives...
Array
(
[scheme] => http
[host] => localhost?key3=value3
)
...rather than parsing the last part into the query field. This used to
work with 4.2.3 in an otherwise identical configuration.
yours, Marcus.
--
Edit bug report at http://bugs.php.net/?id=21704&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21704&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21704&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21704&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21704&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21704&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21704&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21704&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21704&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21704&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21704&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21704&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21704&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21704&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21704&r=gnused
#21776 [NEW]: Heisenbug after database code changes.
From: [EMAIL PROTECTED] Operating system: Windows and Linux PHP version: 4.2.3 PHP Bug Type: Unknown/Other Function Bug description: Heisenbug after database code changes. This is the bug from hell. It is random crashing in a section of our unit tests. On Windows the crash manifests itself as... The instruction "(1)" referenced memory at "(2)" which is not writable where (1) is :0x77fcb9b1 (once), 0x77fcb892 (twice), 0x77fcb9fb (once) on a random attempt of two dozen tries. There is too much code to post here and we cannot yet isolate it - our individual unit tests all pass. We are working on a backtrace from a Linux machine and will add to this bug soon. The code that was changed that started generating these problems was mysql related. There are a lot of references in that code (it is a persistent object library). The problem manifests itself in Linux with random fatal errors such as unknown function where the function name is simply "<()" !? It also happens both with version 3 and 4 of MySQL and versions 4.2.3 and 4.3.0 of PHP. It is a complete show stopper. yours, Marcus. -- Edit bug report at http://bugs.php.net/?id=21776&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21776&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21776&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21776&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21776&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21776&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21776&r=support Expected behavior: http://bugs.php.net/fix.php?id=21776&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21776&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21776&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21776&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21776&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21776&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21776&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21776&r=gnused
#21776 [Fbk->Opn]: Heisenbug after database code changes.
ID: 21776 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Windows and Linux PHP Version: 4.2.3 New Comment: Cannot get a backtrace from the instructions on bug submission. The PHP session does not actually crash, generating a core dump, but exits with a fatal error. The text of the error is gibberish, but nevertheless it does not die. How can we stop or investigate the process at the point of the error. It looks like PHP's symbol table gets corrupted during an earler part of the code. Is there anyway we can investigate this further. yours, Marcus. Previous Comments: [2003-01-20 10:46:44] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2003-01-20 10:31:29] [EMAIL PROTECTED] This is the bug from hell. It is random crashing in a section of our unit tests. On Windows the crash manifests itself as... The instruction "(1)" referenced memory at "(2)" which is not writable where (1) is :0x77fcb9b1 (once), 0x77fcb892 (twice), 0x77fcb9fb (once) on a random attempt of two dozen tries. There is too much code to post here and we cannot yet isolate it - our individual unit tests all pass. We are working on a backtrace from a Linux machine and will add to this bug soon. The code that was changed that started generating these problems was mysql related. There are a lot of references in that code (it is a persistent object library). The problem manifests itself in Linux with random fatal errors such as unknown function where the function name is simply "<()" !? It also happens both with version 3 and 4 of MySQL and versions 4.2.3 and 4.3.0 of PHP. It is a complete show stopper. yours, Marcus. -- Edit this bug report at http://bugs.php.net/?id=21776&edit=1
#21776 [NoF->Csd]: parse_url() degraded since 4.2.3
ID: 21776 User updated by: [EMAIL PROTECTED] -Summary: Heisenbug after database code changes. -Reported By: [EMAIL PROTECTED] +Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Closed Bug Type: Unknown/Other Function -Operating System: Windows and Linux +Operating System: Mandrake 8.1/Ximian PHP Version: 4.2.3 New Comment: Contrary to previous statement, the problem appears socket/network related. We are still trying to isolate the problem, but as the bug comes and goes this is done on an occasional basis. I am not sure installing yet another version of PHP will help (unless you know something we don't) so we are pursuing this alternate course for the time being. Previous Comments: [2003-02-07 23:46:00] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-01-24 11:13:45] [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 [2003-01-23 14:07:28] [EMAIL PROTECTED] Cannot get a backtrace from the instructions on bug submission. The PHP session does not actually crash, generating a core dump, but exits with a fatal error. The text of the error is gibberish, but nevertheless it does not die. How can we stop or investigate the process at the point of the error. It looks like PHP's symbol table gets corrupted during an earler part of the code. Is there anyway we can investigate this further. yours, Marcus. [2003-01-20 10:46:44] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2003-01-20 10:31:29] [EMAIL PROTECTED] This is the bug from hell. It is random crashing in a section of our unit tests. On Windows the crash manifests itself as... The instruction "(1)" referenced memory at "(2)" which is not writable where (1) is :0x77fcb9b1 (once), 0x77fcb892 (twice), 0x77fcb9fb (once) on a random attempt of two dozen tries. There is too much code to post here and we cannot yet isolate it - our individual unit tests all pass. We are working on a backtrace from a Linux machine and will add to this bug soon. The code that was changed that started generating these problems was mysql related. There are a lot of references in that code (it is a persistent object library). The problem manifests itself in Linux with random fatal errors such as unknown function where the function name is simply "<()" !? It also happens both with version 3 and 4 of MySQL and versions 4.2.3 and 4.3.0 of PHP. It is a complete show stopper. yours, Marcus. -- Edit this bug report at http://bugs.php.net/?id=21776&edit=1
#22174 [NEW]: php.ini being ignored - only in release version
From: [EMAIL PROTECTED] Operating system: OpenBSD 3.1-stable PHP version: 4.3.0 PHP Bug Type: PHP options/info functions Bug description: php.ini being ignored - only in release version This problem seems to take many forms, as evidenced by the bug database, but from all the entries I have read, none seems quite like what I'm seeing. I've been using 4.3 from CVS since about last June, and set up my php.ini around then, and I have not really touched it since (not the problem). I've stayed with CVS versions ever since, until today. I started having a compilation problem with the cvs version (Separate problem), but I still needed to rebuild PHP so I grabbed the release 4.3.0. This compiled (using the same configure I've been using all along) with no problems so I installed it and got file not found errors all over. phpinfo reveals that everything is at defaults (include_path at default value was causing my errors), i.e. php.ini is being ignored. I recompiled several times specifying many different locations for php.ini, but none worked. So now it looks like maybe a permissions problem, Except that the php.ini is the same file that has been working for many months with cvs versions up until yesterday - this is the first time I've tried using a release version. Whatever, all permissions look fine - the www user has no trouble reading the file. I thought perhaps the format or content of the ini file had changed, so I built a new one with my settings in from php.ini-recommended. Made no difference, but was probably a good idea anyway. Eventually I found the bug report about php preferring /php.ini over the compiled in location, so I copied my old php.ini there and it did indeed pick it up (a temporary workaround), So now I know there's nothing wrong with what's in either my old or new php.ini files (I don't seem to be seeing the current open bug about php.ini based on recommended not working). So the only remaining variable is that I'm using 4.3.0 release, and not a CVS version. Everything else is identical. I can only surmise that it must be a release version bug. I would like to confirm this by compiling a CVS version and have it work, but as I mentioned, it's not compiling for me right now, so I can't test that. Just for good measure, here's my configure: ./configure --with-apxs=/usr/sbin/apxs --with-mysql=/usr/local --enable-exif --with-gd --with-jpeg-dir=/usr/local/bin --with-bz2 --with-zlib --with-openssl --with-gettext --with-ldap --with-mhash --disable-overload --enable-sockets --with-mcrypt --enable-sysvshm --enable-pcntl --with-config-file-path=/var/www/conf --enable-mbstring --with-pear=/usr/local/lib/php --enable-bcmath --enable-gd-native-ttf --enable-gd-imgstrttf --with-freetype-dir=/usr/local Extracts from phpinfo: With /php.ini: Configuration File (php.ini) Path /php.ini Without /php.ini, (ini in specified place) Configuration File (php.ini) Path /var/www/conf/ -- Edit bug report at http://bugs.php.net/?id=22174&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22174&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22174&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22174&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22174&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22174&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22174&r=support Expected behavior: http://bugs.php.net/fix.php?id=22174&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22174&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22174&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22174&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22174&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22174&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22174&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22174&r=gnused
#22174 [Fbk->Opn]: php.ini being ignored - only in release version
ID: 22174 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: PHP options/info functions Operating System: OpenBSD 3.1-stable PHP Version: 4.3.0 New Comment: I'm already using libtool 1.4.3, so it's not that. I last rebuilt PHP from CVS yesterday morning and it was all ok. Up until switching to 4.3 release, I had never seen a problem with my ini file. Very strange I know... The compile problem seems to be something to do with gm4? It dumps lots of pages relating to bison? I'll do a more accurate bug report if it's still there tomorrow. Previous Comments: [2003-02-11 15:18:14] [EMAIL PROTECTED] I upgraded the libtool version in CVS and we now require libtool 1.4.3. Just install that and the compile problems should be gone..(and update your cvs checkout since I just fixed some other issue that came with the libtool upgrade) About the php.ini location..you're sure the bug is not present in the PHP_4_3 branch? [2003-02-11 14:15:42] [EMAIL PROTECTED] This problem seems to take many forms, as evidenced by the bug database, but from all the entries I have read, none seems quite like what I'm seeing. I've been using 4.3 from CVS since about last June, and set up my php.ini around then, and I have not really touched it since (not the problem). I've stayed with CVS versions ever since, until today. I started having a compilation problem with the cvs version (Separate problem), but I still needed to rebuild PHP so I grabbed the release 4.3.0. This compiled (using the same configure I've been using all along) with no problems so I installed it and got file not found errors all over. phpinfo reveals that everything is at defaults (include_path at default value was causing my errors), i.e. php.ini is being ignored. I recompiled several times specifying many different locations for php.ini, but none worked. So now it looks like maybe a permissions problem, Except that the php.ini is the same file that has been working for many months with cvs versions up until yesterday - this is the first time I've tried using a release version. Whatever, all permissions look fine - the www user has no trouble reading the file. I thought perhaps the format or content of the ini file had changed, so I built a new one with my settings in from php.ini-recommended. Made no difference, but was probably a good idea anyway. Eventually I found the bug report about php preferring /php.ini over the compiled in location, so I copied my old php.ini there and it did indeed pick it up (a temporary workaround), So now I know there's nothing wrong with what's in either my old or new php.ini files (I don't seem to be seeing the current open bug about php.ini based on recommended not working). So the only remaining variable is that I'm using 4.3.0 release, and not a CVS version. Everything else is identical. I can only surmise that it must be a release version bug. I would like to confirm this by compiling a CVS version and have it work, but as I mentioned, it's not compiling for me right now, so I can't test that. Just for good measure, here's my configure: ./configure --with-apxs=/usr/sbin/apxs --with-mysql=/usr/local --enable-exif --with-gd --with-jpeg-dir=/usr/local/bin --with-bz2 --with-zlib --with-openssl --with-gettext --with-ldap --with-mhash --disable-overload --enable-sockets --with-mcrypt --enable-sysvshm --enable-pcntl --with-config-file-path=/var/www/conf --enable-mbstring --with-pear=/usr/local/lib/php --enable-bcmath --enable-gd-native-ttf --enable-gd-imgstrttf --with-freetype-dir=/usr/local Extracts from phpinfo: With /php.ini: Configuration File (php.ini) Path /php.ini Without /php.ini, (ini in specified place) Configuration File (php.ini) Path /var/www/conf/ -- Edit this bug report at http://bugs.php.net/?id=22174&edit=1
#22174 [Fbk->Opn]: php.ini being ignored - only in release version
ID: 22174 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: PHP options/info functions Operating System: OpenBSD 3.1-stable PHP Version: 4.3.1-dev New Comment: Unfortunately there doesn't seem to be a working strace for OpenBSD, I can't get it to compile (reports unsupported OS) and it won't compile as FreeBSD on my system. PHP CLI works correctly if I specify -c and point to the ini file, but it too does not pick up the ini from the compiled-in location (and as noted elsewhere, it doesn't look in /php.ini either). Probably best to leave this bug open/feedback until I can get the CVS version working again (It's still broken for me today, so I'm reporting it now). Previous Comments: [2003-02-11 20:37:27] [EMAIL PROTECTED] Assuming you're using the PHP_4_3 branch, updated version. Did you mean 'm4' outputs errors? Check your m4 version, and if it's anything else than 1.4, update it. If the error comes within configure, you might have to rebuild your autoconf also with the new m4.. [2003-02-11 17:43:58] [EMAIL PROTECTED] If you have an strace utility try to strace the cli binary and see if it tries to open any ini files and if it successful openning any of them. This can be done using the following command: strace php -h 2>&1 | grep ".ini" [2003-02-11 16:46:59] [EMAIL PROTECTED] I'm already using libtool 1.4.3, so it's not that. I last rebuilt PHP from CVS yesterday morning and it was all ok. Up until switching to 4.3 release, I had never seen a problem with my ini file. Very strange I know... The compile problem seems to be something to do with gm4? It dumps lots of pages relating to bison? I'll do a more accurate bug report if it's still there tomorrow. [2003-02-11 15:18:14] [EMAIL PROTECTED] I upgraded the libtool version in CVS and we now require libtool 1.4.3. Just install that and the compile problems should be gone..(and update your cvs checkout since I just fixed some other issue that came with the libtool upgrade) About the php.ini location..you're sure the bug is not present in the PHP_4_3 branch? [2003-02-11 14:15:42] [EMAIL PROTECTED] This problem seems to take many forms, as evidenced by the bug database, but from all the entries I have read, none seems quite like what I'm seeing. I've been using 4.3 from CVS since about last June, and set up my php.ini around then, and I have not really touched it since (not the problem). I've stayed with CVS versions ever since, until today. I started having a compilation problem with the cvs version (Separate problem), but I still needed to rebuild PHP so I grabbed the release 4.3.0. This compiled (using the same configure I've been using all along) with no problems so I installed it and got file not found errors all over. phpinfo reveals that everything is at defaults (include_path at default value was causing my errors), i.e. php.ini is being ignored. I recompiled several times specifying many different locations for php.ini, but none worked. So now it looks like maybe a permissions problem, Except that the php.ini is the same file that has been working for many months with cvs versions up until yesterday - this is the first time I've tried using a release version. Whatever, all permissions look fine - the www user has no trouble reading the file. I thought perhaps the format or content of the ini file had changed, so I built a new one with my settings in from php.ini-recommended. Made no difference, but was probably a good idea anyway. Eventually I found the bug report about php preferring /php.ini over the compiled in location, so I copied my old php.ini there and it did indeed pick it up (a temporary workaround), So now I know there's nothing wrong with what's in either my old or new php.ini files (I don't seem to be seeing the current open bug about php.ini based on recommended not working). So the only remaining variable is that I'm using 4.3.0 release, and not a CVS version. Everything else is identical. I can only surmise that it must be a release version bug. I would like to confirm this by compiling a CVS version and have it work, but as I mentioned, it's not compiling for me right now, so I can't test that. Just for good measure, here's my configure: ./configure --with-apxs=/usr/sbin/apxs --with-mysql=/usr/local --enable-exif --with-gd --with-jpeg-dir=/usr/local/bin --with-bz2 --with-zlib --with-openssl --with-gettext --with-ldap --with-mhash --disable-overload --enable-sockets --with-mcrypt --enable-sysvshm --en
#22184 [NEW]: Compile fails looking for m4sugar
From: [EMAIL PROTECTED] Operating system: OpenBSD 3.1-stable PHP version: 4CVS-2003-02-12 (stable) PHP Bug Type: Compile Failure Bug description: Compile fails looking for m4sugar I'm having trouble compiling current 4.3.1 CVS. I've done a completely fresh checkout. I'm using a minimal configure of: ./configure --with-apxs=/usr/sbin/apxs I'm using autoconf 2.53, automake 1.6.3, libtool 1.4.3 and m4 1.4. It's using the stock OpenBSD Apache version which is 1.3.24. The same setup compiles 4.3.0-release with no difficulty. Configure goes ok, make fails with the following error: /usr/local/bin/gm4: m4sugar/m4sugar.m4: No such file or directory m4_changecom() m4_init() m4_define([b4_actions], [[ case 4: #line 208 "/usr/local/src/php4/ext/standard/parsedate.y" m4_divert_push(0)mv y.tab.c /usr/local/src/php4/ext/standard/parsedate.c mv: y.tab.c: No such file or directory *** Error code 1 A minor note, probably unrelated - when I do CVS updates, I get lots of errors reported saying files are in the way in the Zend and TSRM directories. Something I'm missing? -- Edit bug report at http://bugs.php.net/?id=22184&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22184&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22184&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22184&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22184&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22184&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22184&r=support Expected behavior: http://bugs.php.net/fix.php?id=22184&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22184&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22184&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22184&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22184&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22184&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22184&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22184&r=gnused
#22184 [Fbk->Opn]: Compile fails looking for m4sugar
ID: 22184 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: OpenBSD 3.1-stable PHP Version: 4CVS-2003-02-12 (stable) New Comment: When I said I was using a fresh checkout, I did mean completely fresh - I deleted everything and checked out an entirely new tree, so I'd already eliminated that. That snapshot compiles ok. I just checked out another brand-new tree and I get the same error as described originally, so the difference is somewhere between the current CVS and that snapshot. I did notice that the snapshot builds quite differently to the CVS version. for example, ./buildconf just outputs one line, and the build includes the creation of a whole load of symbolic links that I've not noticed before. Previous Comments: [2003-02-12 10:37:41] [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 Try getting a fresh tree (not updating the old one) the error you are seeing is probably due to corrupted CVS sources. [2003-02-12 04:39:41] [EMAIL PROTECTED] I'm having trouble compiling current 4.3.1 CVS. I've done a completely fresh checkout. I'm using a minimal configure of: ./configure --with-apxs=/usr/sbin/apxs I'm using autoconf 2.53, automake 1.6.3, libtool 1.4.3 and m4 1.4. It's using the stock OpenBSD Apache version which is 1.3.24. The same setup compiles 4.3.0-release with no difficulty. Configure goes ok, make fails with the following error: /usr/local/bin/gm4: m4sugar/m4sugar.m4: No such file or directory m4_changecom() m4_init() m4_define([b4_actions], [[ case 4: #line 208 "/usr/local/src/php4/ext/standard/parsedate.y" m4_divert_push(0)mv y.tab.c /usr/local/src/php4/ext/standard/parsedate.c mv: y.tab.c: No such file or directory *** Error code 1 A minor note, probably unrelated - when I do CVS updates, I get lots of errors reported saying files are in the way in the Zend and TSRM directories. Something I'm missing? -- Edit this bug report at http://bugs.php.net/?id=22184&edit=1
#22184 [Fbk->Opn]: Compile fails looking for m4sugar
ID: 22184 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: OpenBSD 3.1-stable PHP Version: 4CVS-2003-02-12 (stable) New Comment: >From my original posting: I'm using autoconf 2.53, automake 1.6.3, libtool 1.4.3 and m4 1.4. Just for good measure, I recompiled and reinstalled all of them. Any other programs I should check? Is the release version built like a snapshot? It does do a buildconf like the CVS version, but I don't get this error with it. Previous Comments: [2003-02-13 07:48:29] [EMAIL PROTECTED] The difference betweent the snapshots & the CVS is that with snapshots buildconf has already been run the the configure script has been built using the individual m4 files. Since you are having problem with the CVS I must conclude that the problem lies with one of the system utilities used during the buildconf process. What versions of autoconf & libtool are you using? [2003-02-13 05:41:38] [EMAIL PROTECTED] When I said I was using a fresh checkout, I did mean completely fresh - I deleted everything and checked out an entirely new tree, so I'd already eliminated that. That snapshot compiles ok. I just checked out another brand-new tree and I get the same error as described originally, so the difference is somewhere between the current CVS and that snapshot. I did notice that the snapshot builds quite differently to the CVS version. for example, ./buildconf just outputs one line, and the build includes the creation of a whole load of symbolic links that I've not noticed before. [2003-02-12 10:37:41] [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 Try getting a fresh tree (not updating the old one) the error you are seeing is probably due to corrupted CVS sources. [2003-02-12 04:39:41] [EMAIL PROTECTED] I'm having trouble compiling current 4.3.1 CVS. I've done a completely fresh checkout. I'm using a minimal configure of: ./configure --with-apxs=/usr/sbin/apxs I'm using autoconf 2.53, automake 1.6.3, libtool 1.4.3 and m4 1.4. It's using the stock OpenBSD Apache version which is 1.3.24. The same setup compiles 4.3.0-release with no difficulty. Configure goes ok, make fails with the following error: /usr/local/bin/gm4: m4sugar/m4sugar.m4: No such file or directory m4_changecom() m4_init() m4_define([b4_actions], [[ case 4: #line 208 "/usr/local/src/php4/ext/standard/parsedate.y" m4_divert_push(0)mv y.tab.c /usr/local/src/php4/ext/standard/parsedate.c mv: y.tab.c: No such file or directory *** Error code 1 A minor note, probably unrelated - when I do CVS updates, I get lots of errors reported saying files are in the way in the Zend and TSRM directories. Something I'm missing? -- Edit this bug report at http://bugs.php.net/?id=22184&edit=1
#22184 [Fbk->Opn]: Compile fails looking for m4sugar
ID: 22184 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: OpenBSD 3.1-stable PHP Version: 4CVS-2003-02-12 (stable) New Comment: I downgraded to autoconf 2.13 (and buildconf no longer complains about it), but I'm still getting the same error. Previous Comments: [2003-02-13 09:14:41] [EMAIL PROTECTED] Since the configure and the .h files are already built running buildconf does nothing beyond checking that they exists and moving on. Autoconf 2.53 is not recommended for building php configure, if possible try upgrading to a later version (2.57 is the latest) or downgrade to 2.13, which is known to work properly. [2003-02-13 08:56:47] [EMAIL PROTECTED] >From my original posting: I'm using autoconf 2.53, automake 1.6.3, libtool 1.4.3 and m4 1.4. Just for good measure, I recompiled and reinstalled all of them. Any other programs I should check? Is the release version built like a snapshot? It does do a buildconf like the CVS version, but I don't get this error with it. [2003-02-13 07:48:29] [EMAIL PROTECTED] The difference betweent the snapshots & the CVS is that with snapshots buildconf has already been run the the configure script has been built using the individual m4 files. Since you are having problem with the CVS I must conclude that the problem lies with one of the system utilities used during the buildconf process. What versions of autoconf & libtool are you using? [2003-02-13 05:41:38] [EMAIL PROTECTED] When I said I was using a fresh checkout, I did mean completely fresh - I deleted everything and checked out an entirely new tree, so I'd already eliminated that. That snapshot compiles ok. I just checked out another brand-new tree and I get the same error as described originally, so the difference is somewhere between the current CVS and that snapshot. I did notice that the snapshot builds quite differently to the CVS version. for example, ./buildconf just outputs one line, and the build includes the creation of a whole load of symbolic links that I've not noticed before. [2003-02-12 10:37:41] [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 Try getting a fresh tree (not updating the old one) the error you are seeing is probably due to corrupted CVS sources. 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/22184 -- Edit this bug report at http://bugs.php.net/?id=22184&edit=1
Bug #16712: pointers and globals don't work together
From: [EMAIL PROTECTED]
Operating system: Linux RedHat 7.2
PHP version: 4.1.2
PHP Bug Type: Class/Object related
Bug description: pointers and globals don't work together
While using classes, pointers and globals I noticed data not being migrated
to the globalsphere due to pointerassignments.
[Example]
class test {
var $v=0;
function set($i) { $this->v = $i; }
}
$a = new test();
$b =& new test();
$c =& $b;
function ta() {
global $a,$b,$c;
$a->set(1);
$b =& $a;
$c->set(2);
}
ta();
echo "$a->v,$b->v,$c->v";
[/example]
This should display 1,1,2 since $b has been set to $a, but this
pointer-assigment isn't emigrated to the global $b.
I have done many expirements with it to see if i could further specify the
bug... at first i thought it was destroying non-globals that got pointed
too at the end of the functioncall and thus (accidently) destroying the
pointers in the process, but then if i would point $a to $b and export
them both, neither should be destroyed, so the reference should stay
intact... it isn't.
So the only thing that remains is that function-local pointer-assigments
not seem to affect my global var.
--
Edit bug report at http://bugs.php.net/?id=16712&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16712&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16712&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16712&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16712&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16712&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16712&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16712&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16712&r=submittedtwice
Bug #16712 Updated: pointers and globals don't work together
ID: 16712
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Class/Object related
Operating System: Linux RedHat 7.2
PHP Version: 4.1.2
New Comment:
The assignment does work while staying local btw... so an echo $b->v;
within ta() would display 1 as it should.
I'm not sure about the exact implementation of PHP, but i think globals
ARE pointers, right ? That would explain it (though i'm not happy with
it).
If so the line
global $b;
would do the same as
$b(local) =& $b(global);
and thus a reassignment of $b to another point would seperate him from
$b(global).
Still i would like to re-reference my $b(global) in a local function.
Is there maybe a workaround or is it an impossibility ?
Previous Comments:
[2002-04-20 10:31:48] [EMAIL PROTECTED]
While using classes, pointers and globals I noticed data not being
migrated to the globalsphere due to pointerassignments.
[Example]
class test {
var $v=0;
function set($i) { $this->v = $i; }
}
$a = new test();
$b =& new test();
$c =& $b;
function ta() {
global $a,$b,$c;
$a->set(1);
$b =& $a;
$c->set(2);
}
ta();
echo "$a->v,$b->v,$c->v";
[/example]
This should display 1,1,2 since $b has been set to $a, but this
pointer-assigment isn't emigrated to the global $b.
I have done many expirements with it to see if i could further specify
the bug... at first i thought it was destroying non-globals that got
pointed too at the end of the functioncall and thus (accidently)
destroying the pointers in the process, but then if i would point $a to
$b and export them both, neither should be destroyed, so the reference
should stay intact... it isn't.
So the only thing that remains is that function-local
pointer-assigments not seem to affect my global var.
--
Edit this bug report at http://bugs.php.net/?id=16712&edit=1
Bug #15303 Updated: Error compiling
ID: 15303 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: rocklinux 1.4 PHP Version: 4.1.1 New Comment: It seems that when you install a new version of gd over an old one you have this problem, is there a way to uninstall the previous one ? Everyone that is having this problem instaled a newer version of gd over an older one ? Thanks for the oportunity I'm using php-4.2-dev Previous Comments: [2002-03-04 04:31:03] [EMAIL PROTECTED] same thing with php version 4.1.2 and gd 1.8.4 [2002-02-03 07:09:34] [EMAIL PROTECTED] that was the wrong message. [2002-02-03 07:08:53] [EMAIL PROTECTED] The version of PHP that this bug was reported in is too old. Please try to reproduce this bug in the latest version of PHP (available from http://www.php.net/downloads.php If you are still able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". [2002-01-30 16:31:10] [EMAIL PROTECTED] Hello Dont know if this is a gd or php issus. I downloaded gd to have it to work with gd cause i wanted to generate alpha blending images on the fly. therefore i choosed the 2.0.1 beta build. When i compile gd everything is allright but when i try to compile php i get this error message gcc -I. -I/usr/src/php-4.1.1/ext/gd -I/usr/src/php-4.1.1/main -I/usr/src/php -4.1.1 -I/usr/src/php-4.1.1/Zend -I/usr/src/php-4.1.1/ext/mysql/libmysql -I/ usr/src/php-4.1.1/ext/xml/expat -I/usr/src/php-4.1.1/TSRM -g -O2 -c gd.c && touch gd.lo In file included from /usr/include/gd.h:25, from php_gd.h:33, from gd.c:36: /usr/include/gd_io.h:21: undefined or invalid # directive In file included from gd.c:36: php_gd.h:69: warning: static declaration for `gdImageColorResolve' follows non-static gd.c:92: conflicting types for `gdIOCtx' /usr/include/gd_io.h:18: previous declaration of `gdIOCtx' make[3]: *** [gd.lo] Error 1 make[3]: Leaving directory `/usr/src/php-4.1.1/ext/gd' The only option i have supplied is ./configure --with-gd Im using rocklinux 1.4 and have tried to download and install zlib libpng libjpeg freetype several times. Whats wrong? Should i send a bugreport to php or is this a gd issue? Thanx for a good software /Alexander -- Edit this bug report at http://bugs.php.net/?id=15303&edit=1
Bug #15331 Updated: odbc_fetch_array gives a "Call to undefined function"
ID: 15331
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: ODBC related
Operating System: Linux
PHP Version: 4.2.0
New Comment:
It's possible to get odbc_fetch_array() and odbc_fetch_object() to work
without DBMAKER. This is achieved by removing a few #ifdef's in the
code:
php_odbc.h - line 216 => //#ifdef HAVE_DBMAKER
php_odbc.h - line 219 => //#endif
php_odbc.c - line 87 => //#ifdef HAVE_DBMAKER
php_odbc.c - line 90 => //#endif
php_odbc.c - line 87 => //#ifdef HAVE_DBMAKER
php_odbc.c - line 90 => //#endif
php_odbc.c - line 1229 => //#ifdef HAVE_DBMAKER
php_odbc.c - line 1280 => //#endif
I've tested this towards MySQL using MyODBC drivers and it seems to be
working just fine.
Previous Comments:
[2002-04-24 04:34:28] [EMAIL PROTECTED]
odbc_fetch_array() is only available if compiled with --with-dbmaker
support (note: not tested but that's what I gathered from reading the
sources). Can you try this please ?
[2002-04-24 04:26:46] [EMAIL PROTECTED]
same error on winNT4 and winXPpro and PHP 4.2.0
[2002-04-23 11:06:56] [EMAIL PROTECTED]
Doesn't work either with php 4.2.0 on WinNT4 / Win2K, same error.
[2002-02-01 14:16:31] [EMAIL PROTECTED]
./configure' '--prefix=/usr/share' '--datadir=/usr/share/php'
'--bindir=/usr/bin' '--libdir=/usr/share'
'--with-config-file-path=/etc'
'--with-exec-dir=/usr/lib/php/bin' '--with-sybase-ct=/opt/sybase'
'--with-mysql=/usr' '--with-gd=yes'
'--enable-gd-native-ttf' '--enable-gd-imgstrttf'
'--with-tiff-dir=/usr' '--with-jpeg-dir=/usr' '--with-png-dir=/usr'
'--with-xpm-dir=/usr/X11R6'
'--with-ldap=yes' '--with-zlib=yes' '--with-bz2' '--with-gmp'
'--with-xml' '--with-ttf' '--with-t1lib' '--with-mcal=/usr'
'--with-imap=yes'
'--with-sablot' '--with-ftp' '--with-ndbm' '--with-gdbm'
'--with-mcrypt' '--with-gettext' '--with-mm' '--with-gd=yes'
'--with-iodbc'
'--enable-versioning' '--enable-yp' '--enable-bcmath'
'--enable-trans-sid' '--enable-inline-optimization'
'--enable-track-vars'
'--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets'
'--enable-sysvsem' '--enable-sysvshm' '--enable-shmop'
'--enable-calendar'
'--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-exif'
'--enable-ftp' '--enable-memory-limit' '--enable-wddx'
'--enable-filepro'
'--enable-dbase' '--enable-ctype' '--disable-debug'
'--enable-force-cgi-redirect' '--enable-discard-path'
'--enable-sigchild' '--with-openssl'
'--with-imap-ssl' '--with-gd=yes'
'--with-apxs=/usr/sbin/apxs' '--with-pgsql=/usr' '--with-snmp'
'i386-suse-linux'
Compiles fine. This should work:
$value) {
echo "Key: $key; Value: $value\n";
}
odbc_close($db);
}
?>
But I get "Call to undefine function".
I used iODBC + FreeTDS. Other ODBC function seem to work fine.
--
Edit this bug report at http://bugs.php.net/?id=15331&edit=1
Bug #16742 Updated: odbc_fetch_row fails when parameters 2 set
ID: 16742
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: ODBC related
Operating System: win2000 sp2
PHP Version: 4.2.0
New Comment:
For MyODBC towards MySQL this problem is due to incorrect cursor type.
I the function odbc_exec/odbc_prepare(), the cursor is set to
SQL_CURSOR_FORWARD_ONLY which makes it impossible for MyODBC to use
SQLFetchExtended().
To make this function work with MyODBC, change to SQL_CURSOR_STATIC on
line 1184 in php_odbc.c. To make this work with odbc_prepare() i guess
line 820 has to be changed as well.
/* $Id: php_odbc.c,v 1.120.2.1 2002/04/08 22:21:30 sniper Exp $ */
Marcus Karlsson
Testbolaget AB
Previous Comments:
[2002-04-24 08:59:41] [EMAIL PROTECTED]
ODBC communication also fail with OS: NT40 (and Apache)
No error return!! (work with php 4.1.1)
Code:
";
$bzm++;
}
}
odbc_free_result($result);
?>
[2002-04-23 01:07:46] [EMAIL PROTECTED]
The following code works for the first sql statement however fails on
the odbc_fetch_row for the second when the second parmeter is set. This
works for php4.1.2 but fails on php4.2.0
ODBC connected to Access97 database, running Apache2
CODE
$DB_TMS = odbc_connect("tms", "", "");
$sql = "select * from users where name='Root' and pass=''";
$res = odbc_exec($DB_TMS, $sql);
if( odbc_fetch_row($res)) echo "Found Record ";
else echo "No Record Found ";
odbc_free_result($res);
$sql = "select * from users where name='Root' and pass=''";
$res = odbc_exec($DB_TMS, $sql);
if( odbc_fetch_row($res, 1)) echo "Found Record ";
else echo "No Record Found ";
odbc_free_result($res);
odbc_close_all( );
--
Edit this bug report at http://bugs.php.net/?id=16742&edit=1
#20098 [NEW]: POSTed variables are urldecoded twice
From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.7-RELEASE
PHP version: 4.2.3
PHP Bug Type: Scripting Engine problem
Bug description: POSTed variables are urldecoded twice
If you type a '+' in a field it get's converted to
'%2B' before sent to the server. php urldecodes it
twice: '%2B' -> '+' -> ' '.
The problem is in the file:
ext/mbstring/mbstring.c: lines 1033-1045:
val = strchr(var, '=');
val_list[n] = var;
len_list[n] = php_url_decode(var, strlen(var));
n++;
if (val) { /* have a value */
*val++ = '\0';
val_list[n] = val;
len_list[n] = php_url_decode(val, strlen(val));
} else {
val_list[n] = "";
len_list[n] = 0;
}
A possible bugfix is:
BEGIN diff ===
*** ext/mbstring/mbstring.c.ORIGThu Aug 1 07:47:56 2002
--- ext/mbstring/mbstring.c Fri Oct 25 21:36:40 2002
***
*** 1032,1041
while (var) {
val = strchr(var, '=');
val_list[n] = var;
len_list[n] = php_url_decode(var, strlen(var));
n++;
if (val) { /* have a value */
- *val++ = '\0';
val_list[n] = val;
len_list[n] = php_url_decode(val, strlen(val));
} else {
--- 1032,1042
while (var) {
val = strchr(var, '=');
val_list[n] = var;
+ if (val)
+ *val++ = '\0';
len_list[n] = php_url_decode(var, strlen(var));
n++;
if (val) { /* have a value */
val_list[n] = val;
len_list[n] = php_url_decode(val, strlen(val));
} else {
--
Edit bug report at http://bugs.php.net/?id=20098&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20098&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20098&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20098&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20098&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20098&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20098&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20098&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20098&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20098&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20098&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20098&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20098&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20098&r=isapi
#20242 [NEW]: Method call infront of class definition
From: [EMAIL PROTECTED]
Operating system:
PHP version: 4CVS-2002-11-04
PHP Bug Type: Scripting Engine problem
Bug description: Method call infront of class definition
While you can call functions in front or after current code you cannot do
so with classes. As this is documented nowhere this is an error with both
ZE1 and ZE2.
Following .phpt file:
--TEST--
Method call infront of class definition
--FILE--
show_method();
class test {
function show_static() {
echo "static\n";
}
function show_method() {
echo "method\n";
}
}
?>
--EXPECT--
static
method
=EOF
Produces following .out
Fatal error: Class 'test' not found in
/usr/src/php4-HEAD/tests/classes/classes001.php on line 3
/usr/src/php4-HEAD/tests/classes/classes001.php(3) : Fatal error -
Class 'test' not found
=EOF
--
Edit bug report at http://bugs.php.net/?id=20242&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20242&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20242&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20242&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20242&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20242&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20242&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20242&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20242&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20242&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20242&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20242&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20242&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20242&r=isapi
#20242 [Opn]: Method call infront of class definition
ID: 20242
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type:Scripting Engine problem
PHP Version: 4CVS-2002-11-04
New Comment:
Ups i rechecked it and now it works for ZE 1.3 maybe i
missconfigured the test for ZE1. But it still fails for ZE2. I guess i
should commit the test then.
Previous Comments:
[2002-11-04 06:25:39] [EMAIL PROTECTED]
Huh? It just works for me.
Hmm I'm rather interested in what causes it to fail in your
environment.
[2002-11-04 05:17:21] [EMAIL PROTECTED]
While you can call functions in front or after current code you cannot
do so with classes. As this is documented nowhere this is an error with
both ZE1 and ZE2.
Following .phpt file:
--TEST--
Method call infront of class definition
--FILE--
show_method();
class test {
function show_static() {
echo "static\n";
}
function show_method() {
echo "method\n";
}
}
?>
--EXPECT--
static
method
=EOF
Produces following .out
Fatal error: Class 'test' not found in
/usr/src/php4-HEAD/tests/classes/classes001.php on line 3
/usr/src/php4-HEAD/tests/classes/classes001.php(3) : Fatal error
- Class 'test' not found
=EOF
--
Edit this bug report at http://bugs.php.net/?id=20242&edit=1
Bug #15586: disable outputbuffering results in no global vars
From: [EMAIL PROTECTED] Operating system: Windows/Linux PHP version: 4.1.1 PHP Bug Type: Output Control Bug description: disable outputbuffering results in no global vars When i disable output buffering the following does not work anymore I read the request,check if the query part is a locatable file and store that one or a default one into a session variable. When the url contains a query i send a 'location:' header. Then i create a frameset with one frame showing the page stored in the session... -- Edit bug report at http://bugs.php.net/?id=15586&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=15586&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=15586&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=15586&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=15586&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=15586&r=support Expected behavior: http://bugs.php.net/fix.php?id=15586&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=15586&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=15586&r=submittedtwice
Bug #15333 Updated: strndup access violation
ID: 15333
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: IIS related
Operating System: Windows 2000 Pro
PHP Version: 4.2.0 RC2
New Comment:
I am getting this error with 4.2.0 RC2. I upgraded from 4.1.2 to 4.2.0
RC2 (both ISAPI) because 4.1.2 wasn't handling sessions correctly.
I tried setting the app protection to 'Low (IIS Process)' and all I
received were 'Invalid access to memory location' errors.
PHP 4.2.0 RC2 (ISAPI)
IIS5
Win2K Pro SP2
PIII 733MHz
384 MB RAM
Previous Comments:
[2002-04-17 01:29:45] [EMAIL PROTECTED]
I am also receiving this error with:
Win2k Server SP2 w/all security patches
But I am running PHP 4.1.2 ISAPI under IIS 5.0
Thanks.
[2002-04-09 08:14:55] [EMAIL PROTECTED]
I have been super busy lately, but, since I switched the app protection
down to 'Low (IIS Process)' a week ago I haven't gotten a single error
or lock up. Thanks for your persistance.
Still using 4.1.2.
[2002-04-08 12:04:38] [EMAIL PROTECTED]
Ok. It definitely happens with RC2. You can restart IIS without
rebooting, you've got to perform the following:
kill the inetinfo.exe process using the task manager
run from command line:
net stop w3svc
net stop iisadmin
net start iisadmin
net start w3svc
Marking this bug critical because it should be fixed before 4.2.0
release. Still looking for fix.
[2002-04-05 12:38:03] [EMAIL PROTECTED]
Nevermind. That's not the problem. Still looking.
[2002-04-04 13:23:18] [EMAIL PROTECTED]
I think I've found the problem:
ZEND_API char *zend_strndup(const char *s, uint length)
{
char *p;
p = (char *) malloc(length+1);
if (!p) {
return (char *)NULL;
}
if (length) {
memcpy(p, s, length);
}
p[length] = 0;
return p;
}
If this is changed to
ZEND_API char *zend_strndup(const char *s, uint length)
{
char *p;
p = (char *) malloc(length+1);
if (!p) {
return (char *)NULL;
}
if (length) {
memcpy(p, s, length);
p[length] = 0;
}
return p;
}
does that break anything? I think the problem comes in when length==0.
I can't really reproduce this problem though. I saw it once a couple
of days ago, but havn't seen it since.
Also will one of you that's having this problem please check to see if
4.2.0 RC 2 still has this problem? Since 4.2.0 is going to be released
really soon now, I'd like to get this worked through (but if it doesn't
happen anymore under 4.2.0 then we're worrying about nothing).
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/15333
--
Edit this bug report at http://bugs.php.net/?id=15333&edit=1
#31097 [NEW]: After 2-3 hours, POSTs stop working (randomly)
From: marcus at mysql dot com Operating system: Fedora Core 2 PHP version: 4.3.9 PHP Bug Type: Scripting Engine problem Bug description: After 2-3 hours, POSTs stop working (randomly) Description: After 2-3 hours of uptime, i start getting these log messages: PHP Warning: Unknown(): POST Content-Length of 52 bytes exceeds the limit of 0 bytes in Unknown on line 0, referer: https:// Fedora core 2 Apache 2 (2.0.51) PHP 4.3.9 (and 4.3.8) (from RPM's - tried the 4.3.9 RPM and got the exact same result as in 4.3.8) using mod_ssl Reproduce code: --- Any POST operation -- Edit bug report at http://bugs.php.net/?id=31097&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31097&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31097&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31097&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31097&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31097&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31097&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31097&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31097&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31097&r=support Expected behavior: http://bugs.php.net/fix.php?id=31097&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31097&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31097&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31097&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31097&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31097&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31097&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31097&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31097&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=31097&r=mysqlcfg
#31097 [Fbk->Opn]: After 2-3 hours, POSTs stop working (randomly)
ID: 31097 User updated by: marcus at mysql dot com Reported By: marcus at mysql dot com -Status: Feedback +Status: Open -Bug Type: Scripting Engine problem +Bug Type: Unknown/Other Function Operating System: Fedora Core 2 PHP Version: 4.3.9 New Comment: Might have been fixed by a kernel upgrade - server has been running for 30 hours without problem now Previous Comments: [2004-12-15 22:39:52] [EMAIL PROTECTED] Did you try apache 1? [2004-12-15 11:53:30] marcus at mysql dot com Description: After 2-3 hours of uptime, i start getting these log messages: PHP Warning: Unknown(): POST Content-Length of 52 bytes exceeds the limit of 0 bytes in Unknown on line 0, referer: https:// Fedora core 2 Apache 2 (2.0.51) PHP 4.3.9 (and 4.3.8) (from RPM's - tried the 4.3.9 RPM and got the exact same result as in 4.3.8) using mod_ssl Reproduce code: --- Any POST operation -- Edit this bug report at http://bugs.php.net/?id=31097&edit=1
#31449 [NEW]: Comparison of class with recursive references causes fatal
From: marcus at lastcraft dot com Operating system: Linux PHP version: 5.0.1 PHP Bug Type: Class/Object related Bug description: Comparison of class with recursive references causes fatal Description: Hi... The script below causes a fatal error. This is just the simplest example I could find of a whole class of these problems. Makes comparing any object problematical. yours, Marcus Reproduce code: --- me = $this; } } new Recursive() != new Recursive(); ?> Expected result: Nothing as the comparison is not output. Actual result: -- Fatal error with nesting too deep. -- Edit bug report at http://bugs.php.net/?id=31449&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31449&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31449&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31449&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31449&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31449&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31449&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31449&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31449&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31449&r=support Expected behavior: http://bugs.php.net/fix.php?id=31449&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31449&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31449&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31449&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31449&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31449&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31449&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31449&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31449&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31449&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31449&r=mysqlcfg
#31449 [Fbk->Opn]: Comparison of class with recursive references causes fatal
ID: 31449 User updated by: marcus at lastcraft dot com Reported By: marcus at lastcraft dot com -Status: Feedback +Status: Open Bug Type: Class/Object related Operating System: Linux PHP Version: 5.0.1 New Comment: Hi... Well thanks for the standard response in an attempt to stall. I had enough trouble getting version 5.01 onto my Mandrake 9 box without going through the whole thing again with an experimental version, and then having to uninstall it. It would take several hours (possibly days) out of my time, but for a developer with a CVS snapshot installed it would take seconds. I could hardly have made the code shorter. So in short, no thanks. Unless perhaps you have information that this part of the code base has been worked on with respect to this issue? yours, Marcus Previous Comments: [2005-01-10 02:24:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.0-win32-latest.zip [2005-01-08 05:31:19] marcus at lastcraft dot com Description: Hi... The script below causes a fatal error. This is just the simplest example I could find of a whole class of these problems. Makes comparing any object problematical. yours, Marcus Reproduce code: --- me = $this; } } new Recursive() != new Recursive(); ?> Expected result: Nothing as the comparison is not output. Actual result: -- Fatal error with nesting too deep. -- Edit this bug report at http://bugs.php.net/?id=31449&edit=1
#24949 [Com]: Requesting a nicer way of setting undefined variables to a default value.
ID: 24949
Comment by: marcus at deck16 dot com
Reported By: nickj-php at nickj dot org
Status: Open
Bug Type: Feature/Change Request
Operating System: Any
PHP Version: Irrelevant
New Comment:
I also came across that "problem" and voted for that "bug".
It is possible to write a function though. Just pass the var Name as a
string:
Previous Comments:
[2003-08-22 12:00:36] xuefer at 21cn dot com
it would be nice to use "?:" operator as new c++ language
$a = isset($a) ? $a : "";
->
$a = $a ?: "";
$a = $a ?: $b ?: $c ?: $d;
better than:
$a = default($a, $b, $c, $d);
[2003-08-18 21:27:38] hurst at webteks dot com
That there is no way to write a function to handle unset vars is also
something I have come across.
One solution would be to use the @-symbol:
print noUnset(@$x, "not set");
However, the @-symbol is not guaranteed to work, since
a user-defined error handler will ignore it.
Only isset(), unset(), and empty() can handle undefined variables
without implicitly declaring them.
Perhaps a new construct can be made available to handle
this common case.
default($var['not_a_key'],"default_value") => "default_value"
It would work like the following function, but using the
caller environment (which could be from within another function):
function default($var,$default="")
{
return isset($var)?$var:$default;
}
Using "" for the inherent default value makes sense
for web interfaces.
[2003-08-05 05:28:19] nickj-php at nickj dot org
Description:
Requesting a nicer way of setting undefined variables to a default
value.
It gets a bit repetitive and ugly having to use statements like:
$title = isset($vals["title"]) ? $vals["title"] :
"";
$first = isset($vals["first_name"]) ? $vals["first_name"] :
"";
$surname = isset($vals["surname"])? $vals["surname"]:
"";
This seems to be a recurrent requirement, so ideally there would be
some way of doing this, along the lines of :
function noUnset($val, $default="") {
return isset($val) ? $val : $default;
}
Unfortunately a user function such as the above cannot be defined to do
this, since the first argument passed to the function would be unset.
For example, this code will generate an error:
==
error_reporting (E_ALL);
function noUnset($val, $default="") {
return isset($val) ? $val : $default;
}
if (isset($x)) unset ($x);
// $x = 2; // works OK if this line is uncommented
print noUnset($x, "not set");
// Above line generates an error as noUnset cannot be called with $x,
because it is not set - catch-22 !
==
This code generates an "Undefined variable: x" error.
Ideally there would be slightly nicer way of setting defaults than a
bank is "isset" statements, that would work without generating an
error, even with all error reporting options turned on.
--
Edit this bug report at http://bugs.php.net/?id=24949&edit=1
#31449 [Asn]: Comparison of class with recursive references causes fatal
ID: 31449
User updated by: marcus at lastcraft dot com
Reported By: marcus at lastcraft dot com
Status: Assigned
Bug Type: Class/Object related
Operating System: Linux
PHP Version: 5.0.1
Assigned To: andi
New Comment:
Hi.
The workaround does not work here because the serialize() function is
nt canonical. That is two equivalent objects will not come out the
same. E.g...
serialize(array('a' => 'A', 'b' => 'B'))
...is not the same as...
serialize(array('b' => 'B', 'a' => 'A'))
An object ID misses the mark. I am trying to compare two different
objects for equality, that is the same value. Having unique IDs just
ensures they are different objects.
I am completely defeated by the Zend engine at this point. I have had
to come up with some tortuous workarounds involving dependency
injection which I would love to do without. Not least because it causes
me to keep references lying around, defeating the PHP garbage collector.
Makes any pattern which treats objects as messages rather problematical
for example.
yours, Marcus
Previous Comments:
[2005-02-11 13:14:25] lsblsb at gmx dot de
There is a workaround for this problem:
Serialize the references you want to compare, and compare their
serialized versions.
Or - give your Objects id's and compare their references by their
id's.
Hope this helps.
[2005-01-10 21:10:59] [EMAIL PROTECTED]
This one is for the Zend mastahs... but I'm not sure if this is very
easy to fix.
[2005-01-10 15:30:11] nospam at nospam dot com
C:\downloads\php5.0-win32-latest>php -v
PHP 5.0.4-dev (cli) (built: Jan 10 2005 10:20:12)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.4-dev, Copyright (c) 1998-2004 Zend Technologies
C:\downloads\php5.0-win32-latest>php recursive.php
Fatal error: Nesting level too deep - recursive dependency? in
C:\downloads\php5
.0-win32-latest\recursive.php on line 10
C:\downloads\php5.0-win32-latest>
[2005-01-10 08:14:17] [EMAIL PROTECTED]
If you don't want to test the latest version, we can't help.
[2005-01-10 04:25:49] marcus at lastcraft dot com
Hi...
Well thanks for the standard response in an attempt to stall. I had
enough trouble getting version 5.01 onto my Mandrake 9 box without
going through the whole thing again with an experimental version, and
then having to uninstall it. It would take several hours (possibly
days) out of my time, but for a developer with a CVS snapshot installed
it would take seconds. I could hardly have made the code shorter.
So in short, no thanks. Unless perhaps you have information that this
part of the code base has been worked on with respect to this issue?
yours, Marcus
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/31449
--
Edit this bug report at http://bugs.php.net/?id=31449&edit=1
#25006 [NEW]: Call-time pass-by-reference has been deprecated
From: marcus at gooseflesh dot de Operating system: Windos 2000 PHP version: 4.3.2 PHP Bug Type: Variables related Bug description: Call-time pass-by-reference has been deprecated Description: I have really big problems with your newest change to php. having Call-time pass-by-reference has been deprecated without having objects passed-by-reference makes the usability of your language really impractical. example: function foo($var); // is by-value if you pass an object it will be copied. function foo(&$var); // is by-reference but you cannot pass null or a value. foo(17); // error foo(null); // error function foo(&$var = null); // error Because you have unsuitable method signiture overloading and now no call-time pass-by-reference an efficient way of designing applications or libraries in your language is now impossible. It's a pity. At the moment I don't feel like to finish my php projects. Marcus -- Edit bug report at http://bugs.php.net/?id=25006&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25006&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25006&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25006&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25006&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25006&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25006&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25006&r=support Expected behavior: http://bugs.php.net/fix.php?id=25006&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25006&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25006&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25006&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25006&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25006&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25006&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25006&r=gnused
#29090 [Com]: Destructor Segfaults PHP5RC3
ID: 29090
Comment by: marcus at lucidix dot com
Reported By: derek at battams dot ca
Status: Feedback
Bug Type: Reproducible crash
Operating System: Linux 2.4
PHP Version: 5.0.0RC3
New Comment:
Description:
We are experiencing a similar seg fault, also in zend_hash_find.
Two servers running Linux 2.4, Apache 1.3, MySQL 4.0, PHP 5.0 (also
tested with CVS php5-200407242230.tar.bz2) segfault.
However, our application runs without issues on Windows XP, Apache 2.0,
MySQL 4.0, PHP 5.0.0.
The class this error occurs in is also part of a much larger system. We
have not yet been able to isolate the exact line of code causing this.
Additionally, the behavior is not consistent. Seg faults occur 95% of
the time, but occasionally it will run.
A few differences to the original bug report: We are not using
destructors, and no calls to md5 are made. The only common code between
our two code snippets is file_exists().
Please note: The following code snippet will not work by itself.
Reproduce code:
---
function _findstoredproc($storedproc)
{
// load the list of modules installed
$modmgr = lxModules::singleton();
$modules = $modmgr->modulelist();
// prepend the "core" module
$core = array(
'name' => 'core',
'type' => 'global',
'path' => GLOBALDIR . '/src/'
);
array_unshift($modules, $core);
// scan each module
foreach($modules as $module)
{
// assemble the file name, using module directory, drv/, proc
name
and driver extension
$filename = $module['path'] . 'drv/' . $storedproc . '.' .
$this->db_driver;
// check if the "stored proc" exists
if (file_exists($filename))
{
return $filename;
}
}
return false;
}
Expected Result:
Function returns a filename or false.
Actual Result:
"The page cannot be displayed" as the Apache child process seg faults.
Apache Error Log:
-
/usr/local/src/php5-200407242230/main/streams/streams.c(1551) : Block
0x0838E678 status:
Beginning: Overrun (magic=0x4020F0E4, expected=0x7312F8DC)
End: Unknown
---
[Sun Jul 25 13:25:31 2004] Script:
'/home/marcus/public_html/webapp/trunk/index.lx'
---
/usr/local/src/php5-200407242230/Zend/zend_constants.c(33) : Block
0x404D9CA3 status:
/usr/local/src/php5-200407242230/Zend/zend_variables.c(39) : Actual
location (location was relayed)
Beginning: Overrun (magic=0x75622E6E, expected=0x7312F8DC)
[Sun Jul 25 13:25:32 2004] [notice] child pid 18603 exit signal
Segmentation fault (11)
GDB Backtrace:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 14684)]
0x4076c9e0 in zend_hash_find (ht=0x8235e6c, arKey=0x823c3dc "filename",
nKeyLength=9,
pData=0xbfffeaf4) at /usr/local/src/php-5.0.0/Zend/zend_hash.c:854
854 if ((p->h == h) && (p->nKeyLength ==
nKeyLength)) {
(gdb) bt
#0 0x4076c9e0 in zend_hash_find (ht=0x8235e6c, arKey=0x823c3dc
"filename", nKeyLength=9,
pData=0xbfffeaf4) at /usr/local/src/php-5.0.0/Zend/zend_hash.c:854
#1 0x4078920f in zend_fetch_var_address (opline=0x823bc38,
Ts=0x833ea5c, type=0)
at /usr/local/src/php-5.0.0/Zend/zend_execute.c:762
#2 0x4078c5ef in zend_fetch_r_handler (execute_data=0xbfffeb60,
opline=0x823bc38,
op_array=0x82b6fc4) at
/usr/local/src/php-5.0.0/Zend/zend_execute.c:1996
#3 0x4078acc4 in execute (op_array=0x82b6fc4) at
/usr/local/src/php-5.0.0/Zend/zend_execute.c:1391
#4 0x4078edd5 in zend_do_fcall_common_helper (execute_data=0xbfffec50,
opline=0x823e9c4,
op_array=0x823c064) at
/usr/local/src/php-5.0.0/Zend/zend_execute.c:2728
#5 0x4078f2ef in zend_do_fcall_by_name_handler
(execute_data=0xbfffec50, opline=0x823e9c4,
op_array=0x823c064) at
/usr/local/src/php-5.0.0/Zend/zend_execute.c:2810
#6 0x4078acc4 in execute (op_array=0x823c064) at
/usr/local/src/php-5.0.0/Zend/zend_execute.c:1391
#7 0x4078edd5 in zend_do_fcall_common_helper (execute_data=0xbfffed40,
opline=0x82655fc,
op_array=0x8266174) at
/usr/local/src/php-5.0.0/Zend/zend_execute.c:2728
#8 0x4078f2ef in zend_do_fcall_by_name_handler
(execute_data=0xbfffed40, opline=0x82655fc,
op_array=0x8266174) at
/usr/local/src/php-5.0.0/Zend/zend_execute.c:2810
#9 0x4078acc4 in execute
#29336 [Com]: Segmentation fault
ID: 29336 Comment by: marcus at lucidix dot com Reported By: glorybox at s dot od dot ua Status: Feedback Bug Type: Session related Operating System: Linux 2.4.18-xfs-1.1 PHP Version: 5CVS-2004-07-22 (dev) New Comment: that patch fixes the problem for me. thanks! Previous Comments: [2004-07-23 09:13:29] [EMAIL PROTECTED] Please try this patch: http://tony2004.phpclub.net/dev/tmp/session.diff Does it happen with it too ? [2004-07-22 19:02:22] glorybox at s dot od dot ua Description: While starting session with session_start() PHP5 causes Apache to segfault. No changes were actually made to php.ini-dist Reproduce code: --- Expected result: Expected to start session. -- Edit this bug report at http://bugs.php.net/?id=29336&edit=1
[PHP-BUG] Bug #51505 [NEW]: strotime incorrect when looking at days this week or last
From:
Operating system: Linux
PHP version: 5.2.13
Package: Date/time related
Bug Type: Bug
Bug description:strotime incorrect when looking at days this week or last
Description:
When using strtotime to determine the date of a particular day last week or
next week using a given value for $now we get results that we would not be
expecting. I get the values I am expecting when using PHP 5.3.2
Test script:
---
$time = mktime(0, 0, 0, 4, 7, 2010);
echo date('Y-m-d H:i:s', strtotime('Tuesday last week', $time));
echo "\n";
echo date('Y-m-d H:i:s', strtotime('Tuesday this week', $time));
Expected result:
2010-03-30 00:00:00
2010-04-06 00:00:00
Actual result:
--
2010-04-06 00:00:00
2010-04-13 00:00:00
--
Edit bug report at http://bugs.php.net/bug.php?id=51505&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51505&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51505&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51505&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51505&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51505&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51505&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51505&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51505&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51505&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51505&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51505&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51505&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51505&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51505&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51505&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51505&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51505&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51505&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51505&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51505&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51505&r=mysqlcfg
[PHP-BUG] Bug #52050 [NEW]: PHP-FPM Dies after self-initiating reload
From:
Operating system: fc7
PHP version: 5.3.2
Package: FPM related
Bug Type: Bug
Bug description: PHP-FPM Dies after self-initiating reload
Description:
Just upgraded one of our machines to PHP-FPM from
http://svn.php.net/repository/php/php-src/branches/PHP_5_3/sapi/fpm
sapi/fpm with 5.3.2 stable, and everything was working fine until PHP-
FPM needed to initiate a reload.
Jun 11 00:44:54.935812 [WARNING] [pool www] child 26032 exited on
signal 7 SIGBUS after 0.000199 seconds from start
Jun 11 00:44:54.937079 [NOTICE] [pool www] child 26033 started
Jun 11 00:44:54.937113 [WARNING] [pool www] child 26033 exited on
signal 7 SIGBUS after 0.51 seconds from start
Jun 11 00:44:54.937139 [WARNING] failed processes threshold (10 in 60
sec) is reached, initiating reload
Jun 11 00:44:55.104446 [NOTICE] reloading: execvp("/usr/sbin/php-fpm",
{"/usr/sbin/php-fpm", "--fpm-config", "/etc/php-fpm.conf"})
php-fpm: event.c:268: event_base_free: Assertion `(((&base-
>eventqueue)->tqh_first) == ((void *)0))' failed.
--
Edit bug report at http://bugs.php.net/bug.php?id=52050&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52050&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52050&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52050&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52050&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52050&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52050&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52050&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52050&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52050&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52050&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52050&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52050&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52050&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52050&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52050&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52050&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52050&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52050&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52050&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52050&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52050&r=mysqlcfg
Bug #52050 [Opn]: PHP-FPM Dies after self-initiating reload
Edit report at http://bugs.php.net/bug.php?id=52050&edit=1 ID: 52050 User updated by: marcus at adolfsson dot com Reported by: marcus at adolfsson dot com Summary: PHP-FPM Dies after self-initiating reload Status: Open Type: Bug Package: FPM related Operating System: fc7 PHP Version: 5.3.2 New Comment: This is my conf file: ; ; FPM Configuration ; ; ;include=/etc/fpm.d/*.conf ;; ; Global Options ; ;; [global] pid = /usr/logs/php-fpm.pid error_log = /usr/logs/php-fpm.log ; Log level ; Possible Values: alert, error, warning, notice, debug log_level = notice ; If this number of child processes exit with SIGSEGV or SIGBUS within the time ; interval set by emergency_restart_interval then FPM will restart. A value ; of '0' means 'Off'. ; Default Value: 0 emergency_restart_threshold = 10 ; Interval of time used by emergency_restart_interval to determine when ; a graceful restart will be initiated. This can be useful to work around ; accidental corruptions in an accelerator's shared memory. ; Available Units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 emergency_restart_interval = 1m ; Time limit for child processes to wait for a reaction on signals from master. ; Available units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 process_control_timeout = 5s ; Send FPM to background. Set to 'no' to keep FPM in foreground for debugging. ; Default Value: yes daemonize = yes ; Pool Definitions ; ; Multiple pools of child processes may be started with different listening ; ports and different management options. The name of the pool will be ; used in logs and stats. There is no limitation on the number of pools which ; FPM can handle. Your system will tell you anyway :) ; Start a new pool named 'www'. [www] ; The address on which to accept FastCGI requests. ; Valid syntaxes are: ; 'ip.add.re.ss:port'- to listen on a TCP socket to a specific address on ;a specific port; ; 'port' - to listen on a TCP socket to all addresses on a ;specific port; ; '/path/to/unix/socket' - to listen on a unix socket. ; Note: This value is mandatory. listen = 127.0.0.1:9000 ; Set listen(2) backlog. A value of '-1' means unlimited. ; Default Value: -1 listen.backlog = -1 ; List of ipv4 addresses of FastCGI clients which are allowed to connect. ; Equivalent to the FCGI_WEB_SERVER_ADDRS environment variable in the original ; PHP FCGI (5.2.2+). Makes sense only with a tcp listening socket. Each address ; must be separated by a comma. If this value is left blank, connections will be ; accepted from any ip address. ; Default Value: any ;listen.allowed_clients = 127.0.0.1 ; Set permissions for unix socket, if one is used. In Linux, read/write ; permissions must be set in order to allow connections from a web server. Many ; BSD-derived systems allow connections regardless of permissions. ; Default Values: user and group are set as the running user ; mode is set to 0666 ;listen.owner = nobody ;listen.group = nobody ;listen.mode = 0666 ; Unix user/group of processes ; Note: The user is mandatory. If the group is not set, the default user's group ; will be used. user = phpfm group = phpfm ; Choose how the process manager will control the number of child processes. ; Possible Values: ; static - a fixed number (pm.max_children) of child processes; ; dynamic - the number of child processes are set dynamically based on the ; following directives: ; pm.max_children - the maximum number of children that can ;be alive at the same time. ; pm.start_servers - the number of children created on startup. ; pm.min_spare_servers - the minimum number of children in 'idle' ;state (waiting to process). If the number ;of 'idle' processes is less than this ;number then some children will be created. ; pm.max_spare_servers - the maximum number of children in 'idle' ;state (waiting to process). If the number ;of 'idle' processes is greater than this ;number then some children will be killed. ; Note: This value is mandatory. pm = static ; The number of child processes to be created when pm is set to 'static' an
Bug #52050 [Fbk->Opn]: PHP-FPM Dies after self-initiating reload
Edit report at http://bugs.php.net/bug.php?id=52050&edit=1 ID: 52050 User updated by: marcus at adolfsson dot com Reported by: marcus at adolfsson dot com Summary: PHP-FPM Dies after self-initiating reload -Status: Feedback +Status: Open Type: Bug Package: FPM related Operating System: fc7 PHP Version: 5.3.2 Assigned To: fat New Comment: ldd /usr/sbin/php-fpm libcrypt.so.1 => /lib64/libcrypt.so.1 (0x003a8300) libaspell.so.15 => /usr/lib64/libaspell.so.15 (0x003a8600) libpspell.so.15 => /usr/lib64/libpspell.so.15 (0x003a8640) librt.so.1 => /lib64/librt.so.1 (0x003a8180) libmysqlclient.so.15 => /usr/lib64/mysql/libmysqlclient.so.15 (0x0036a360) libmcrypt.so.4 => /usr/lib64/libmcrypt.so.4 (0x00357ba0) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0036a320) libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x0036a3e0) libz.so.1 => /usr/lib64/libz.so.1 (0x0035af40) libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x003a8700) libcurl.so.3 => /usr/lib64/libcurl.so.3 (0x0035af80) libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x003a8540) libpcre.so.0 => /lib64/libpcre.so.0 (0x0035b040) libm.so.6 => /lib64/libm.so.6 (0x003a80c0) libdl.so.2 => /lib64/libdl.so.2 (0x003a8080) libevent-1.4.so.1 => /usr/local/lib/libevent-1.4.so.1 (0x2aac3000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x0036a2e0) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x003a8440) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x003a8340) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x003a83c0) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x003a8280) libssl.so.6 => /lib64/libssl.so.6 (0x0035afc0) libcrypto.so.6 => /lib64/libcrypto.so.6 (0x0035b080) libresolv.so.2 => /lib64/libresolv.so.2 (0x003a82c0) libidn.so.11 => /usr/lib64/libidn.so.11 (0x003a8200) libc.so.6 => /lib64/libc.so.6 (0x003a8040) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x003a8400) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x003a84c0) libpthread.so.0 => /lib64/libpthread.so.0 (0x003a8100) /lib64/ld-linux-x86-64.so.2 (0x003a8000) libnsl.so.1 => /lib64/libnsl.so.1 (0x003a8240) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x003a8480) Previous Comments: [2010-06-11 16:10:16] tony2...@php.net Please also show the output of `ldd /path/to/php-fpm`. Thanks. [2010-06-11 15:36:27] marcus at adolfsson dot com This is my conf file: ; ; FPM Configuration ; ; ;include=/etc/fpm.d/*.conf ;; ; Global Options ; ;; [global] pid = /usr/logs/php-fpm.pid error_log = /usr/logs/php-fpm.log ; Log level ; Possible Values: alert, error, warning, notice, debug log_level = notice ; If this number of child processes exit with SIGSEGV or SIGBUS within the time ; interval set by emergency_restart_interval then FPM will restart. A value ; of '0' means 'Off'. ; Default Value: 0 emergency_restart_threshold = 10 ; Interval of time used by emergency_restart_interval to determine when ; a graceful restart will be initiated. This can be useful to work around ; accidental corruptions in an accelerator's shared memory. ; Available Units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 emergency_restart_interval = 1m ; Time limit for child processes to wait for a reaction on signals from master. ; Available units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 process_control_timeout = 5s ; Send FPM to background. Set to 'no' to keep FPM in foreground for debugging. ; Default Value: yes daemonize = yes ; Pool Definitions ; ; Multiple pools of child processes may be started with different listening ; ports and different management options. The name of the pool will be ; used in logs and stats. There is no limitation on the number of pools which ; FPM can handle. Your system will tell you anyway :) ; Start a new pool named 'www'. [www] ; The address on which to accept FastCGI requests. ; Valid syntaxes are: ; 'ip.add.re.ss:port'- to liste
Bug #52050 [Fbk->Opn]: PHP-FPM Dies after self-initiating reload
Edit report at http://bugs.php.net/bug.php?id=52050&edit=1 ID: 52050 User updated by: marcus at adolfsson dot com Reported by: marcus at adolfsson dot com Summary: PHP-FPM Dies after self-initiating reload -Status: Feedback +Status: Open Type: Bug Package: FPM related Operating System: fc7 PHP Version: 5.3.2 Assigned To: fat New Comment: Fedora Core 7, libevent-1.4.14-stable Previous Comments: [2010-06-13 13:02:12] f...@php.net Can you also provide the libevent version and the OS you're using. Thanks [2010-06-11 16:27:49] marcus at adolfsson dot com ldd /usr/sbin/php-fpm libcrypt.so.1 => /lib64/libcrypt.so.1 (0x003a8300) libaspell.so.15 => /usr/lib64/libaspell.so.15 (0x003a8600) libpspell.so.15 => /usr/lib64/libpspell.so.15 (0x003a8640) librt.so.1 => /lib64/librt.so.1 (0x003a8180) libmysqlclient.so.15 => /usr/lib64/mysql/libmysqlclient.so.15 (0x0036a360) libmcrypt.so.4 => /usr/lib64/libmcrypt.so.4 (0x00357ba0) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0036a320) libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x0036a3e0) libz.so.1 => /usr/lib64/libz.so.1 (0x0035af40) libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x003a8700) libcurl.so.3 => /usr/lib64/libcurl.so.3 (0x0035af80) libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x003a8540) libpcre.so.0 => /lib64/libpcre.so.0 (0x0035b040) libm.so.6 => /lib64/libm.so.6 (0x003a80c0) libdl.so.2 => /lib64/libdl.so.2 (0x003a8080) libevent-1.4.so.1 => /usr/local/lib/libevent-1.4.so.1 (0x2aac3000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x0036a2e0) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x003a8440) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x003a8340) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x003a83c0) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x003a8280) libssl.so.6 => /lib64/libssl.so.6 (0x0035afc0) libcrypto.so.6 => /lib64/libcrypto.so.6 (0x0035b080) libresolv.so.2 => /lib64/libresolv.so.2 (0x003a82c0) libidn.so.11 => /usr/lib64/libidn.so.11 (0x003a8200) libc.so.6 => /lib64/libc.so.6 (0x003a8040) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x003a8400) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x003a84c0) libpthread.so.0 => /lib64/libpthread.so.0 (0x003a8100) /lib64/ld-linux-x86-64.so.2 (0x003a8000) libnsl.so.1 => /lib64/libnsl.so.1 (0x003a8240) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x003a8480) [2010-06-11 16:10:16] tony2...@php.net Please also show the output of `ldd /path/to/php-fpm`. Thanks. [2010-06-11 15:36:27] marcus at adolfsson dot com This is my conf file: ; ; FPM Configuration ; ; ;include=/etc/fpm.d/*.conf ;; ; Global Options ; ;; [global] pid = /usr/logs/php-fpm.pid error_log = /usr/logs/php-fpm.log ; Log level ; Possible Values: alert, error, warning, notice, debug log_level = notice ; If this number of child processes exit with SIGSEGV or SIGBUS within the time ; interval set by emergency_restart_interval then FPM will restart. A value ; of '0' means 'Off'. ; Default Value: 0 emergency_restart_threshold = 10 ; Interval of time used by emergency_restart_interval to determine when ; a graceful restart will be initiated. This can be useful to work around ; accidental corruptions in an accelerator's shared memory. ; Available Units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 emergency_restart_interval = 1m ; Time limit for child processes to wait for a reaction on signals from master. ; Available units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 process_control_timeout = 5s ; Send FPM to background. Set to 'no' to keep FPM in foreground for debugging. ; Default Value: yes daemonize = yes ; Pool Definitions ; ; Multiple pools of child processes may be started with different listening ; ports and different managemen
Bug #52050 [Fbk->Opn]: PHP-FPM Dies after self-initiating reload
Edit report at http://bugs.php.net/bug.php?id=52050&edit=1
ID: 52050
User updated by: marcus at adolfsson dot com
Reported by: marcus at adolfsson dot com
Summary: PHP-FPM Dies after self-initiating reload
-Status: Feedback
+Status: Open
Type: Bug
Package: FPM related
Operating System: fc7
PHP Version: 5.3.2
Assigned To: fat
New Comment:
Manual reloads are successful
Jun 17 13:54:25.047532 [NOTICE] reloading: execvp("/usr/sbin/php-fpm",
{"/usr/sbin/php-fpm", "--fpm-config", "/etc/php-fpm.conf"})
Jun 17 13:54:25.084632 [NOTICE] using inherited socket fd=14,
"127.0.0.1:9000"
Jun 17 13:54:25.084986 [NOTICE] fpm is running, pid 2564
Is there a way to force the self-initiating reload to occur for testing
purposes?
Previous Comments:
[2010-06-17 19:12:30] f...@php.net
I can't reproduce the problem.
I tried to compile 5.3snap on rhel 5 server with libevent 1.1.14 and I
have no
problems.
Two questions:
1- does the bug appear when sending a USR2 signal to the master process
(reloading) ?
2- Can you compile the static modules (mysql, pspell, ...) as shared
modules so
that you will be able to run FPM without any module to check if there is
no bugs
running a specific module with FPM.
----
[2010-06-14 16:11:13] marcus at adolfsson dot com
Fedora Core 7, libevent-1.4.14-stable
[2010-06-13 13:02:12] f...@php.net
Can you also provide the libevent version and the OS you're using.
Thanks
--------
[2010-06-11 16:27:49] marcus at adolfsson dot com
ldd /usr/sbin/php-fpm
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x003a8300)
libaspell.so.15 => /usr/lib64/libaspell.so.15 (0x003a8600)
libpspell.so.15 => /usr/lib64/libpspell.so.15 (0x003a8640)
librt.so.1 => /lib64/librt.so.1 (0x003a8180)
libmysqlclient.so.15 => /usr/lib64/mysql/libmysqlclient.so.15
(0x0036a360)
libmcrypt.so.4 => /usr/lib64/libmcrypt.so.4 (0x00357ba0)
libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0036a320)
libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x0036a3e0)
libz.so.1 => /usr/lib64/libz.so.1 (0x0035af40)
libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x003a8700)
libcurl.so.3 => /usr/lib64/libcurl.so.3 (0x0035af80)
libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x003a8540)
libpcre.so.0 => /lib64/libpcre.so.0 (0x0035b040)
libm.so.6 => /lib64/libm.so.6 (0x003a80c0)
libdl.so.2 => /lib64/libdl.so.2 (0x003a8080)
libevent-1.4.so.1 => /usr/local/lib/libevent-1.4.so.1
(0x2aac3000)
libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x0036a2e0)
libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2
(0x003a8440)
libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x003a8340)
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x003a83c0)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x003a8280)
libssl.so.6 => /lib64/libssl.so.6 (0x0035afc0)
libcrypto.so.6 => /lib64/libcrypto.so.6 (0x0035b080)
libresolv.so.2 => /lib64/libresolv.so.2 (0x003a82c0)
libidn.so.11 => /usr/lib64/libidn.so.11 (0x003a8200)
libc.so.6 => /lib64/libc.so.6 (0x003a8040)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x003a8400)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x003a84c0)
libpthread.so.0 => /lib64/libpthread.so.0 (0x003a8100)
/lib64/ld-linux-x86-64.so.2 (0x003a8000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x003a8240)
libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0
(0x003a8480)
[2010-06-11 16:10:16] tony2...@php.net
Please also show the output of `ldd /path/to/php-fpm`. Thanks.
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/bug.php?id=52050
--
Edit this bug report at http://bugs.php.net/bug.php?id=52050&edit=1
[PHP-BUG] Bug #52884 [NEW]: FILTER_VALIDATE_INT treats float as integer
From: Operating system: Ubuntu 8.04.4 LTS PHP version: Irrelevant Package: Unknown/Other Function Bug Type: Bug Bug description:FILTER_VALIDATE_INT treats float as integer Description: PHP's filter extension erroneous validates a float (10.) as integer. The observed behaviour in filter extension is not consistent to is_int()/is_float() type checks whereas 10. is reported to be float. In addition, the formal structure of integers *1) does not mention dots to be part of a valid integer. *1) http://www.php.net/manual/en/language.types.integer.php Environment: Server OS: Ubuntu 8.04.4 LTS PHP package in use: 5.2.4-2ubuntu5.10 Test script: --- $variableToTest = 10.; echo "This variable type is " . (is_int($variableToTest) ? 'integer' : 'not integer') . "!\n"; echo "This variable type is " . (is_float($variableToTest) ? 'float' : 'not float') . "!\n"; // validate integer echo "This variable is considered to be " . ((FALSE !== filter_var($variableToTest, FILTER_VALIDATE_INT)) ? 'integer' : 'not integer') . "!\n"; echo "This variable is considered to be " . ((FALSE !== filter_var((string)$variableToTest, FILTER_VALIDATE_INT)) ? 'integer' : 'not integer') . "!\n"; // validate float echo "This variable is considered to be " . ((FALSE !== filter_var($variableToTest, FILTER_VALIDATE_FLOAT)) ? 'float' : 'not float') . "!\n"; echo "This variable is considered to be " . ((FALSE !== filter_var((string)$variableToTest, FILTER_VALIDATE_FLOAT)) ? 'float' : 'not float') . "!\n"; Expected result: This variable type is not integer! This variable type is float! This variable is considered to be not integer! This variable is considered to be not integer! This variable is considered to be float! This variable is considered to be float! Actual result: -- This variable type is not integer! This variable type is float! This variable is considered to be integer! This variable is considered to be integer! This variable is considered to be float! This variable is considered to be float! -- Edit bug report at http://bugs.php.net/bug.php?id=52884&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52884&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52884&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52884&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52884&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52884&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52884&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52884&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52884&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52884&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52884&r=support Expected behavior: http://bugs.php.net/fix.php?id=52884&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52884&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52884&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52884&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52884&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52884&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52884&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52884&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52884&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52884&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52884&r=mysqlcfg
Bug #52884 [Com]: FILTER_VALIDATE_INT treats float as integer
Edit report at http://bugs.php.net/bug.php?id=52884&edit=1 ID: 52884 Comment by: marcus at t3sec dot info Reported by:marcus at t3sec dot info Summary:FILTER_VALIDATE_INT treats float as integer Status: Bogus Type: Bug Package:Unknown/Other Function Operating System: Ubuntu 8.04.4 LTS PHP Version:Irrelevant Block user comment: N New Comment: We're talking about a validation filter here. And I consider 10. not to be an integer. Could you please present any other variable value that does not follow the structure of an integer (http://www.php.net/manual/en/language.types.integer.php ) but validates as integer in ext/filter? In addition, why does following piece of code neither validates the variable to test as integer nor as float: $variableToTest = '0x' . dechex(10) . '.'; $options['flags'] = FILTER_FLAG_ALLOW_HEX; echo "This variable is considered to be " . ((FALSE !== filter_var($variableToTest, FILTER_VALIDATE_INT, $options)) ? 'integer' : 'not integer') . "!\n"; echo "This variable is considered to be " . ((FALSE !== filter_var($variableToTest, FILTER_VALIDATE_FLOAT, $options)) ? 'float' : 'not float') . "!\n"; If you validate 10. as integer, I would expect you to validate 0xa. as integer too. Don't take it as offense but I don't care what conversions are done. I'm interested in a reproducible and consistent behaviour. Previous Comments: [2010-09-18 22:45:52] cataphr...@php.net The goal of FILTER_VALIDATE_INT is not to replicate the behavior of is_int. The filter extension aims to validate and sanitize string values. "(double) 10." is converted to the "10" (following the normal conversion to string rules) and that's what is validated as an integer. Notice that "10." (string) is not validated as an integer. [2010-09-18 21:49:05] marcus at t3sec dot info Description: PHP's filter extension erroneous validates a float (10.) as integer. The observed behaviour in filter extension is not consistent to is_int()/is_float() type checks whereas 10. is reported to be float. In addition, the formal structure of integers *1) does not mention dots to be part of a valid integer. *1) http://www.php.net/manual/en/language.types.integer.php Environment: Server OS: Ubuntu 8.04.4 LTS PHP package in use: 5.2.4-2ubuntu5.10 Test script: --- $variableToTest = 10.; echo "This variable type is " . (is_int($variableToTest) ? 'integer' : 'not integer') . "!\n"; echo "This variable type is " . (is_float($variableToTest) ? 'float' : 'not float') . "!\n"; // validate integer echo "This variable is considered to be " . ((FALSE !== filter_var($variableToTest, FILTER_VALIDATE_INT)) ? 'integer' : 'not integer') . "!\n"; echo "This variable is considered to be " . ((FALSE !== filter_var((string)$variableToTest, FILTER_VALIDATE_INT)) ? 'integer' : 'not integer') . "!\n"; // validate float echo "This variable is considered to be " . ((FALSE !== filter_var($variableToTest, FILTER_VALIDATE_FLOAT)) ? 'float' : 'not float') . "!\n"; echo "This variable is considered to be " . ((FALSE !== filter_var((string)$variableToTest, FILTER_VALIDATE_FLOAT)) ? 'float' : 'not float') . "!\n"; Expected result: This variable type is not integer! This variable type is float! This variable is considered to be not integer! This variable is considered to be not integer! This variable is considered to be float! This variable is considered to be float! Actual result: -- This variable type is not integer! This variable type is float! This variable is considered to be integer! This variable is considered to be integer! This variable is considered to be float! This variable is considered to be float! -- Edit this bug report at http://bugs.php.net/bug.php?id=52884&edit=1
Req #32100 [Com]: Request 'finally' support for exceptions
Edit report at http://bugs.php.net/bug.php?id=32100&edit=1
ID: 32100
Comment by: marcus at lastcraft dot com
Reported by:ceefour at gauldong dot net
Summary:Request 'finally' support for exceptions
Status: Closed
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: *
PHP Version:5.*
Block user comment: N
Private report: N
New Comment:
Hi...
The lack of finally causes us some crufty hard to debug code. The
comment about swallowing the source of the exception is not an academic
one - I've had grief over this.
As for exceptions being used for "control flow" - they are control flow,
that's the whole point. There is an antiquated argument from the C++ era
about this, mostly driven by outdated performance data. Exceptions are
not the same as errors, being more akin to a continuation when the usual
return path does not make sense.
Please, plase add finally to PHP as Java did to C++.
yours, Marcus
Previous Comments:
[2010-12-10 12:02:15] joshuaswift at gmail dot com
Please add a finally block for exception handling
[2010-10-03 07:58:34] matsubokkuri+php at gmail dot com
> c891652 at bofthew dot com
I'm disappointed about this request is closed without critical reasons.
The first comment author doesn't understand OOP correctly. The code
cannot raise
exception to upper class.
The code would be following without finally statement.
// create temporary file
try{
// write to temporary file
}catch(ConnectionException $e){
// delete temporary file
}
// delete temporary file
The "delete temporary file" sentence would be duplicate.
I can write with finally as following without duplicate "delete
temporary file".
// create temporary file
try{
// write to temporary file
}finally{
// delete temporary file
}
[2010-09-21 09:47:37] c891652 at bofthew dot com
I feel nothing but disappointed that this bug got closed, without "any"
reason being written in the comments.
I also stand for including "finally". It's a well known Exception
Handling control block, and others in this bug have shown clearly why it
is needed.
[2010-09-09 09:32:40] 128bitencrypted at gmail dot com
I noticed this bug because I have exactly the same problem atm and
finally could solve it. I found a great discussion about the "return"
problem and how it's solved in java. (IMHO I think that's the right
way)
stackoverflow dot com/questions/65035/in-java-does-return-trump-finally
In PHP it could be implemented like the following:
function example1()
{
try {
return "Return\n";
} finally {
echo "Finally\n";
}
}
echo example1();
Output:
Finally
Return
And it's important that finally has the right to overwrite return.
(Although I think that there only a few cases where that would be
useful)
function example2()
{
try {
return "Return wins\n";
} finally {
return "Finally wins\n";
}
}
echo example2();
Output:
Finally wins
I hope that helps a bit more why finally would be a very useful in php!
Thanks.
[2010-09-09 02:39:42] phplasma at gmail dot com
A finally block would indeed be useful, please reconsider.
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/bug.php?id=32100
--
Edit this bug report at http://bugs.php.net/bug.php?id=32100&edit=1
Bug #49858 [Com]: Compile flag --with-libxml-dir don't work as expected
Edit report at http://bugs.php.net/bug.php?id=49858&edit=1 ID: 49858 Comment by: marcus at lastcraft dot com Reported by:me at madjack dot ru Summary:Compile flag --with-libxml-dir don't work as expected Status: Bogus Type: Bug Package:Compile Failure Operating System: Mac Os X 10.5.7 PHP Version:5.3SVN-2009-10-13 (snap) Block user comment: N Private report: N New Comment: Hi... I have this same problem with a vanilla MacOS 10.4 machine. It's nothing to do with his libraries and everything to do with building with Postgres support. yours, Marcus Previous Comments: [2009-10-19 11:15:36] j...@php.net If you have messed up your system with several different versions of libraries, there's nothing we can do but wish you good luck.. [2009-10-13 07:41:00] me at madjack dot ru The only way to fix this bug for me: Configure php with all needed options, Then remove libxml2 binaries from /Library/PostgreSQL/8.4/lib compile and install php, restore libs to PostgreSQL home. [2009-10-13 07:18:30] me at madjack dot ru Description: I have 3 or more different libxml2 libraries in the system. Standard MacOS X libxml2 located in /usr/lib and has version 9.0. When i compile PHP of any version begin from 5.3.0 include last snap with flag --with- pdo-pgsql it compiles fine, but PostgreSQL 8.4 has own libxml2 version 10.0.1 and can't compile with libxml2 9.0. So without postgresql php compiles fine, but with postgresql it compiles fine but don't run. It says error: dyld: Library not loaded: libxml2.2.dylib Referenced from: /Volumes/DevHD/Developer/Sources/php/php5.3- 200910120830/sapi/cli/php Reason: Incompatible library version: php requires version 10.0.0 or later, but libxml2.2.dylib provides version 9.0.0 Reproduce code: --- Configure and make script cut here #!/bin/sh ./configure --disable-all \ --with-interbase \ --with-apxs2 \ --enable-libxml \ --with-pcre-regex=yes \ --with-regex=php \ --with-zend-vm=CALL \ --enable-zend-multibyte \ --disable-ipv6 \ --prefix=/usr/local \ --with-zlib \ --enable-soap \ --enable-dom \ --enable-session \ --enable-libxml \ --with-libxml-dir=/Library/PostgreSQL/8.4 \ --enable-simplexml \ --enable-xml \ --enable-tokenizer \ --enable-json \ --enable-pdo \ --with-pdo-firebird=/Library/Frameworks/Firebird.framework \ --with-pdo-pgsql=/Library/PostgreSQL/8.4 \ --with-pear \ --with-xsl make "EXTRA_INCLUDES=-I/Library/Frameworks/Firebird.framework/Versions/A/Headers/" \ "EXTRA_LIBS=-lresolv -lexslt -lpq -lfbclient -lz -lm -lxml2 -licucore -lxslt" echo "" echo "Test for compilance with libxml2" echo "" otool -L ./sapi/cli/php echo "" ./sapi/cli/php -v cut here Expected result: Php must use libxml2 not from /usr/lib. It must use libxml2 from /Library/PostgreSQL/8.4/lib. Actual result: -- Build complete. Don't forget to run 'make test'. Test for compilance with libxml2 ./sapi/cli/php: /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 25.0.2) /usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.10.0) libpq.5.dylib (compatibility version 5.0.0, current version 5.2.0) /Library/Frameworks/Firebird.framework/Versions/A/Firebird (compatibility version 2.0.5, current version 2.0.5) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) libxml2.2.dylib (compatibility version 10.0.0, current version 10.1.0) /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 36.0.0) /usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.12.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) dyld: Library not loaded: libxml2.2.dylib Referenced from: /Volumes/DevHD/Developer/Sources/php/php5.3- 200910120830/./sapi/cli/php Reason: Incompatible library version: php requires version 10.0.0 or later, but libxml2.2.dylib provides version 9.0.0 ./rebuild.sh: line 37: 1892 Trace/BPT trap ./sapi/cli/php -v -- Edit this bug report at http://bugs.php.net/bug.php?id=49858&edit=1
Bug #49858 [Com]: Compile flag --with-libxml-dir don't work as expected
Edit report at http://bugs.php.net/bug.php?id=49858&edit=1 ID: 49858 Comment by: marcus at lastcraft dot com Reported by:me at madjack dot ru Summary:Compile flag --with-libxml-dir don't work as expected Status: Bogus Type: Bug Package:Compile Failure Operating System: Mac Os X 10.5.7 PHP Version:5.3SVN-2009-10-13 (snap) Block user comment: N Private report: N New Comment: I've reproduced this back to PHP 5.2.3 without problem. Here is my configure: ./configure --with-apxs --with-cli --with-openssl --with-pgsql=/Library/PostgreSQL/8.3/ Note the older Postgres too. Everything is 2007 vintage here, which means this bug was probably present from the word go. yours, Marcus Previous Comments: [2010-12-12 18:31:35] marcus at lastcraft dot com Hi... I have this same problem with a vanilla MacOS 10.4 machine. It's nothing to do with his libraries and everything to do with building with Postgres support. yours, Marcus [2009-10-19 11:15:36] j...@php.net If you have messed up your system with several different versions of libraries, there's nothing we can do but wish you good luck.. [2009-10-13 07:41:00] me at madjack dot ru The only way to fix this bug for me: Configure php with all needed options, Then remove libxml2 binaries from /Library/PostgreSQL/8.4/lib compile and install php, restore libs to PostgreSQL home. [2009-10-13 07:18:30] me at madjack dot ru Description: I have 3 or more different libxml2 libraries in the system. Standard MacOS X libxml2 located in /usr/lib and has version 9.0. When i compile PHP of any version begin from 5.3.0 include last snap with flag --with- pdo-pgsql it compiles fine, but PostgreSQL 8.4 has own libxml2 version 10.0.1 and can't compile with libxml2 9.0. So without postgresql php compiles fine, but with postgresql it compiles fine but don't run. It says error: dyld: Library not loaded: libxml2.2.dylib Referenced from: /Volumes/DevHD/Developer/Sources/php/php5.3- 200910120830/sapi/cli/php Reason: Incompatible library version: php requires version 10.0.0 or later, but libxml2.2.dylib provides version 9.0.0 Reproduce code: --- Configure and make script cut here #!/bin/sh ./configure --disable-all \ --with-interbase \ --with-apxs2 \ --enable-libxml \ --with-pcre-regex=yes \ --with-regex=php \ --with-zend-vm=CALL \ --enable-zend-multibyte \ --disable-ipv6 \ --prefix=/usr/local \ --with-zlib \ --enable-soap \ --enable-dom \ --enable-session \ --enable-libxml \ --with-libxml-dir=/Library/PostgreSQL/8.4 \ --enable-simplexml \ --enable-xml \ --enable-tokenizer \ --enable-json \ --enable-pdo \ --with-pdo-firebird=/Library/Frameworks/Firebird.framework \ --with-pdo-pgsql=/Library/PostgreSQL/8.4 \ --with-pear \ --with-xsl make "EXTRA_INCLUDES=-I/Library/Frameworks/Firebird.framework/Versions/A/Headers/" \ "EXTRA_LIBS=-lresolv -lexslt -lpq -lfbclient -lz -lm -lxml2 -licucore -lxslt" echo "" echo "Test for compilance with libxml2" echo "" otool -L ./sapi/cli/php echo "" ./sapi/cli/php -v cut here Expected result: Php must use libxml2 not from /usr/lib. It must use libxml2 from /Library/PostgreSQL/8.4/lib. Actual result: -- Build complete. Don't forget to run 'make test'. Test for compilance with libxml2 ./sapi/cli/php: /usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 25.0.2) /usr/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.10.0) libpq.5.dylib (compatibility version 5.0.0, current version 5.2.0) /Library/Frameworks/Firebird.framework/Versions/A/Firebird (compatibility version 2.0.5, current version 2.0.5) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) libxml2.2.dylib (compatibility version 10.0.0, current version 10.1.0) /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 36.0.0) /usr/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.12.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) -
Bug #49858 [Com]: Compile flag --with-libxml-dir don't work as expected
Edit report at http://bugs.php.net/bug.php?id=49858&edit=1 ID: 49858 Comment by: marcus at lastcraft dot com Reported by:me at madjack dot ru Summary:Compile flag --with-libxml-dir don't work as expected Status: Bogus Type: Bug Package:Compile Failure Operating System: Mac Os X 10.5.7 PHP Version:5.3SVN-2009-10-13 (snap) Block user comment: N Private report: N New Comment: Hi... Should say that ./configure and make work fine. It's the make install that folds: Installing PHP SAPI module: apache [activating module `php5' in /private/etc/httpd/httpd.conf] cp libs/libphp5.so /usr/libexec/httpd/libphp5.so chmod 755 /usr/libexec/httpd/libphp5.so cp /private/etc/httpd/httpd.conf /private/etc/httpd/httpd.conf.bak cp /private/etc/httpd/httpd.conf.new /private/etc/httpd/httpd.conf rm /private/etc/httpd/httpd.conf.new Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing build environment: /usr/local/lib/php/build/ Installing header files: /usr/local/include/php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config Installing man pages: /usr/local/man/man1/ page: phpize.1 page: php-config.1 Installing PEAR environment: /usr/local/lib/php/ dyld: Library not loaded: libxml2.2.dylib Referenced from: /Users/aviva/downloads/php-5.2.3/sapi/cli/php Reason: Incompatible library version: php requires version 10.0.0 or later, but libxml2.2.dylib provides version 9.0.0 make[1]: *** [install-pear-installer] Trace/BPT trap make: *** [install-pear] Error 2 yours, Marcus Previous Comments: [2010-12-12 18:35:16] marcus at lastcraft dot com I've reproduced this back to PHP 5.2.3 without problem. Here is my configure: ./configure --with-apxs --with-cli --with-openssl --with-pgsql=/Library/PostgreSQL/8.3/ Note the older Postgres too. Everything is 2007 vintage here, which means this bug was probably present from the word go. yours, Marcus ---- [2010-12-12 18:31:35] marcus at lastcraft dot com Hi... I have this same problem with a vanilla MacOS 10.4 machine. It's nothing to do with his libraries and everything to do with building with Postgres support. yours, Marcus [2009-10-19 11:15:36] j...@php.net If you have messed up your system with several different versions of libraries, there's nothing we can do but wish you good luck.. [2009-10-13 07:41:00] me at madjack dot ru The only way to fix this bug for me: Configure php with all needed options, Then remove libxml2 binaries from /Library/PostgreSQL/8.4/lib compile and install php, restore libs to PostgreSQL home. [2009-10-13 07:18:30] me at madjack dot ru Description: I have 3 or more different libxml2 libraries in the system. Standard MacOS X libxml2 located in /usr/lib and has version 9.0. When i compile PHP of any version begin from 5.3.0 include last snap with flag --with- pdo-pgsql it compiles fine, but PostgreSQL 8.4 has own libxml2 version 10.0.1 and can't compile with libxml2 9.0. So without postgresql php compiles fine, but with postgresql it compiles fine but don't run. It says error: dyld: Library not loaded: libxml2.2.dylib Referenced from: /Volumes/DevHD/Developer/Sources/php/php5.3- 200910120830/sapi/cli/php Reason: Incompatible library version: php requires version 10.0.0 or later, but libxml2.2.dylib provides version 9.0.0 Reproduce code: --- Configure and make script cut here #!/bin/sh ./configure --disable-all \ --with-interbase \ --with-apxs2 \ --enable-libxml \ --with-pcre-regex=yes \ --with-regex=php \ --with-zend-vm=CALL \ --enable-zend-multibyte \ --disable-ipv6 \ --prefix=/usr/local \ --with-zlib \ --enable-soap \ --enable-dom \ --enable-session \ --enable-libxml \ --with-libxml-dir=/Library/PostgreSQL/8.4 \ --enable-simplexml \ --enable-xml \ --enable-tokenizer \ --enable-json \ --enable-pdo \ --with-pdo-firebird=/Library/Frameworks/Firebird.framework \ --with-pdo-pgsql=/Library/PostgreSQL/8.4 \ --with-pear \ --with-xsl make "EXTRA_INCLUDES=-I/Library/Frameworks/Firebird.framework/Versions/A/Headers/" \ "EXTRA_LIBS=-lresolv -lexslt -lpq -lfbclient -lz -lm -lxml2 -licucore -lxslt" echo "" echo "Test for compilance with libxml2" echo "--
#36295 [NEW]: Reflection returns broken parameter name for SplFileObject::flock()
From: marcus at lastcraft dot com
Operating system: Windows
PHP version: 5.1.2
PHP Bug Type: SPL related
Bug description: Reflection returns broken parameter name for
SplFileObject::flock()
Description:
Spurious "]" character on name of "wouldblock" parameter.
Reproduce code:
---
$reflection = new ReflectionClass('SplFileObject');
print_r($reflection->getMethod('flock')->getParameters());
Expected result:
Array
(
[0] => ReflectionParameter Object
(
[name] => operation
)
[1] => ReflectionParameter Object
(
[name] => wouldblock
)
)
Actual result:
--
Array
(
[0] => ReflectionParameter Object
(
[name] => operation
)
[1] => ReflectionParameter Object
(
[name] => wouldblock]
)
)
--
Edit bug report at http://bugs.php.net/?id=36295&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36295&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36295&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36295&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36295&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36295&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36295&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36295&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36295&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36295&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36295&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36295&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36295&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36295&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36295&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36295&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36295&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36295&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36295&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36295&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36295&r=mysqlcfg
#22184 [Fbk->Opn]: Compile fails looking for m4sugar
ID: 22184 User updated by: marcus at synchromedia dot co dot uk Reported By: marcus at synchromedia dot co dot uk -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: OpenBSD 3.1-stable PHP Version: 4CVS-2003-02-12 (stable) New Comment: After much frustration, I have now recompiled absolutely everything: kernel, whole OS, all the appropriate dev tools (m4, autoconf etc), pulled a fresh CVS copy of PHP, and now it finally compiles. I don't know where the problem was, but wherever it was, it's now gone away. As I don't know if the fix was done in PHP or my system, this should probably be marked as bogus. Previous Comments: [2003-02-13 12:20:38] [EMAIL PROTECTED] What is the EXACT output of 'm4 --version' ?? And did you get m4,libtool,autoconf from www.gnu.org ? And compiled yourself? (m4 needs to be first..) ---- [2003-02-13 10:31:29] marcus at synchromedia dot co dot uk I downgraded to autoconf 2.13 (and buildconf no longer complains about it), but I'm still getting the same error. [2003-02-13 09:14:41] [EMAIL PROTECTED] Since the configure and the .h files are already built running buildconf does nothing beyond checking that they exists and moving on. Autoconf 2.53 is not recommended for building php configure, if possible try upgrading to a later version (2.57 is the latest) or downgrade to 2.13, which is known to work properly. ---- [2003-02-13 08:56:47] marcus at synchromedia dot co dot uk >From my original posting: I'm using autoconf 2.53, automake 1.6.3, libtool 1.4.3 and m4 1.4. Just for good measure, I recompiled and reinstalled all of them. Any other programs I should check? Is the release version built like a snapshot? It does do a buildconf like the CVS version, but I don't get this error with it. [2003-02-13 07:48:29] [EMAIL PROTECTED] The difference betweent the snapshots & the CVS is that with snapshots buildconf has already been run the the configure script has been built using the individual m4 files. Since you are having problem with the CVS I must conclude that the problem lies with one of the system utilities used during the buildconf process. What versions of autoconf & libtool are you using? 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/22184 -- Edit this bug report at http://bugs.php.net/?id=22184&edit=1
#22184 [Opn->Bgs]: Compile fails looking for m4sugar
ID: 22184 User updated by: marcus at synchromedia dot co dot uk Reported By: marcus at synchromedia dot co dot uk -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: OpenBSD 3.1-stable PHP Version: 4CVS-2003-02-12 (stable) New Comment: Marking as bogus. Previous Comments: [2003-02-18 04:17:50] marcus at synchromedia dot co dot uk After much frustration, I have now recompiled absolutely everything: kernel, whole OS, all the appropriate dev tools (m4, autoconf etc), pulled a fresh CVS copy of PHP, and now it finally compiles. I don't know where the problem was, but wherever it was, it's now gone away. As I don't know if the fix was done in PHP or my system, this should probably be marked as bogus. [2003-02-13 12:20:38] [EMAIL PROTECTED] What is the EXACT output of 'm4 --version' ?? And did you get m4,libtool,autoconf from www.gnu.org ? And compiled yourself? (m4 needs to be first..) ---- [2003-02-13 10:31:29] marcus at synchromedia dot co dot uk I downgraded to autoconf 2.13 (and buildconf no longer complains about it), but I'm still getting the same error. [2003-02-13 09:14:41] [EMAIL PROTECTED] Since the configure and the .h files are already built running buildconf does nothing beyond checking that they exists and moving on. Autoconf 2.53 is not recommended for building php configure, if possible try upgrading to a later version (2.57 is the latest) or downgrade to 2.13, which is known to work properly. ---- [2003-02-13 08:56:47] marcus at synchromedia dot co dot uk >From my original posting: I'm using autoconf 2.53, automake 1.6.3, libtool 1.4.3 and m4 1.4. Just for good measure, I recompiled and reinstalled all of them. Any other programs I should check? Is the release version built like a snapshot? It does do a buildconf like the CVS version, but I don't get this error with it. 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/22184 -- Edit this bug report at http://bugs.php.net/?id=22184&edit=1
#22174 [Fbk->Csd]: php.ini being ignored - only in release version
ID: 22174 User updated by: marcus at synchromedia dot co dot uk Reported By: marcus at synchromedia dot co dot uk -Status: Feedback +Status: Closed Bug Type: PHP options/info functions Operating System: OpenBSD 3.1-stable -PHP Version: 4.3.1-dev +PHP Version: 4.3.2-dev New Comment: Now that I have finally got PHP-cvs compiling again, I'm happy to report that it's picking up my php.ini from the compiled in location. 4.3.0-release still does not, so I guess whatever the probem is, it's been fixed in CVS. Previous Comments: [2003-02-12 22:07:47] [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 (does anything work in openbsd? :) [2003-02-12 04:24:24] marcus at synchromedia dot co dot uk Unfortunately there doesn't seem to be a working strace for OpenBSD, I can't get it to compile (reports unsupported OS) and it won't compile as FreeBSD on my system. PHP CLI works correctly if I specify -c and point to the ini file, but it too does not pick up the ini from the compiled-in location (and as noted elsewhere, it doesn't look in /php.ini either). Probably best to leave this bug open/feedback until I can get the CVS version working again (It's still broken for me today, so I'm reporting it now). [2003-02-11 20:37:27] [EMAIL PROTECTED] Assuming you're using the PHP_4_3 branch, updated version. Did you mean 'm4' outputs errors? Check your m4 version, and if it's anything else than 1.4, update it. If the error comes within configure, you might have to rebuild your autoconf also with the new m4.. [2003-02-11 17:43:58] [EMAIL PROTECTED] If you have an strace utility try to strace the cli binary and see if it tries to open any ini files and if it successful openning any of them. This can be done using the following command: strace php -h 2>&1 | grep ".ini" ---- [2003-02-11 16:46:59] marcus at synchromedia dot co dot uk I'm already using libtool 1.4.3, so it's not that. I last rebuilt PHP from CVS yesterday morning and it was all ok. Up until switching to 4.3 release, I had never seen a problem with my ini file. Very strange I know... The compile problem seems to be something to do with gm4? It dumps lots of pages relating to bison? I'll do a more accurate bug report if it's still there tomorrow. 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/22174 -- Edit this bug report at http://bugs.php.net/?id=22174&edit=1
#26449 [NEW]: usleep doesnt work correctly
From: marcus at quintic dot co dot uk Operating system: Windows XP PHP version: 4.3.4 PHP Bug Type: Unknown/Other Function Bug description: usleep doesnt work correctly Description: (I know the manual says it doesnt work, but it should work because the Sleep function in windows works fine) usleep doesnt work on windows XP (on all windows platforms?). For some reason usleep returns immediately on windows and there doesnt seem to be any way in php of delaying for less than a second without chewing cpu cycles. Having looked at the code behind the usleep function all it does is call the win32 Sleep function which does work, so there must be a bug stopping this from being called. Reproduce code: --- Expected result: Should delay for 10 microseconds. Actual result: -- Returns immediately with no delay. -- Edit bug report at http://bugs.php.net/?id=26449&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26449&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26449&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26449&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26449&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26449&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26449&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26449&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26449&r=support Expected behavior: http://bugs.php.net/fix.php?id=26449&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26449&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26449&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26449&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26449&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26449&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26449&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26449&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26449&r=float
#26449 [Fbk->Opn]: usleep doesnt work correctly
ID: 26449 User updated by: marcus at quintic dot co dot uk Reported By: marcus at quintic dot co dot uk -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Windows XP PHP Version: 4.3.4 New Comment: Doesnt work. I only put 10 as an example (admittedly too small to notice if you're watching it), I should have put 1000 or something - put it in a loop that repeats a few thousand times and it still doesnt do anything. Previous Comments: [2003-11-28 11:17:28] [EMAIL PROTECTED] Try making the delay longer, usleep(10); will sleep for 1/10 of a second and is very hard to notice. [2003-11-28 10:54:52] marcus at quintic dot co dot uk Description: (I know the manual says it doesnt work, but it should work because the Sleep function in windows works fine) usleep doesnt work on windows XP (on all windows platforms?). For some reason usleep returns immediately on windows and there doesnt seem to be any way in php of delaying for less than a second without chewing cpu cycles. Having looked at the code behind the usleep function all it does is call the win32 Sleep function which does work, so there must be a bug stopping this from being called. Reproduce code: --- Expected result: Should delay for 10 microseconds. Actual result: -- Returns immediately with no delay. -- Edit this bug report at http://bugs.php.net/?id=26449&edit=1
#26449 [Fbk->Opn]: usleep doesnt work correctly
ID: 26449 User updated by: marcus at quintic dot co dot uk Reported By: marcus at quintic dot co dot uk -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Windows XP PHP Version: 4.3.4 New Comment: Ok - I wont be able to check until after the weekend. I tried the output of earlier (before submitting the bug) and it comes back with the same time twice so unless var_dump gives you any extra info that will help Previous Comments: [2003-11-28 14:01:25] [EMAIL PROTECTED] Try running the following: php -r " var_dump(time(), usleep(1000), time()); " [2003-11-28 11:25:36] marcus at quintic dot co dot uk Doesnt work. I only put 10 as an example (admittedly too small to notice if you're watching it), I should have put 1000 or something - put it in a loop that repeats a few thousand times and it still doesnt do anything. [2003-11-28 11:17:28] [EMAIL PROTECTED] Try making the delay longer, usleep(10); will sleep for 1/10 of a second and is very hard to notice. [2003-11-28 10:54:52] marcus at quintic dot co dot uk Description: (I know the manual says it doesnt work, but it should work because the Sleep function in windows works fine) usleep doesnt work on windows XP (on all windows platforms?). For some reason usleep returns immediately on windows and there doesnt seem to be any way in php of delaying for less than a second without chewing cpu cycles. Having looked at the code behind the usleep function all it does is call the win32 Sleep function which does work, so there must be a bug stopping this from being called. Reproduce code: --- Expected result: Should delay for 10 microseconds. Actual result: -- Returns immediately with no delay. -- Edit this bug report at http://bugs.php.net/?id=26449&edit=1
#26449 [Bgs->Opn]: usleep doesnt work correctly
ID: 26449 User updated by: marcus at quintic dot co dot uk Reported By: marcus at quintic dot co dot uk -Status: Bogus +Status: Open Bug Type: *General Issues Operating System: Windows XP PHP Version: 4.3.4 New Comment: So every other language I know manages to call Sleep under win32 and it works, but php doesnt? Previous Comments: [2003-11-29 06:15:27] [EMAIL PROTECTED] RTFM: Note: This function does not work on Windows systems. (Yes, manual might be correct?) The function exists, but it does absolutely nothing on windows. [2003-11-28 15:37:02] marcus at quintic dot co dot uk Ok - I wont be able to check until after the weekend. I tried the output of earlier (before submitting the bug) and it comes back with the same time twice so unless var_dump gives you any extra info that will help [2003-11-28 14:01:25] [EMAIL PROTECTED] Try running the following: php -r " var_dump(time(), usleep(1000), time()); " [2003-11-28 11:25:36] marcus at quintic dot co dot uk Doesnt work. I only put 10 as an example (admittedly too small to notice if you're watching it), I should have put 1000 or something - put it in a loop that repeats a few thousand times and it still doesnt do anything. [2003-11-28 11:17:28] [EMAIL PROTECTED] Try making the delay longer, usleep(10); will sleep for 1/10 of a second and is very hard to notice. 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/26449 -- Edit this bug report at http://bugs.php.net/?id=26449&edit=1
#26449 [Asn]: usleep doesnt work correctly
ID: 26449 User updated by: marcus at quintic dot co dot uk Reported By: marcus at quintic dot co dot uk Status: Assigned Bug Type: *General Issues Operating System: Windows XP PHP Version: 4.3.4 Assigned To: wez New Comment: :) Hell, who need microseconds anyway - being able to delay for less than a second without chewing cpu would be enough for me. Thanks. Previous Comments: [2003-11-29 16:08:22] [EMAIL PROTECTED] Sleep() has millisecond resolution, not microsecond resolution. I'll look into getting usleep working under win32, but make no promises. [2003-11-29 15:57:45] marcus at quintic dot co dot uk So every other language I know manages to call Sleep under win32 and it works, but php doesnt? [2003-11-29 06:15:27] [EMAIL PROTECTED] RTFM: Note: This function does not work on Windows systems. (Yes, manual might be correct?) The function exists, but it does absolutely nothing on windows. [2003-11-28 15:37:02] marcus at quintic dot co dot uk Ok - I wont be able to check until after the weekend. I tried the output of earlier (before submitting the bug) and it comes back with the same time twice so unless var_dump gives you any extra info that will help [2003-11-28 14:01:25] [EMAIL PROTECTED] Try running the following: php -r " var_dump(time(), usleep(1000), time()); " 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/26449 -- Edit this bug report at http://bugs.php.net/?id=26449&edit=1
#22919 [NEW]: Missing server variables
From: marcus at names dot co dot uk Operating system: Redhat Linux 7.2 PHP version: 4.3.1 PHP Bug Type: CGI related Bug description: Missing server variables When building PHP 4.3.1 as a cgi binary, some of the server variables do not get set correctlt. Most importantly, $PHP_SELF and $SCRIPT_NAME are missing altogether. Looking at cgi_main.c, it looks as though $PHP_SELF is inherited from $SCRIPT_NAME for the CGI version - so perhaps this is why they are both missing? I am running under Zeus Web Server 4.2, but the problem is the same when run from the command line. -- Edit bug report at http://bugs.php.net/?id=22919&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22919&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22919&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22919&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22919&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22919&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22919&r=support Expected behavior: http://bugs.php.net/fix.php?id=22919&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22919&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22919&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22919&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22919&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22919&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22919&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22919&r=gnused
#22920 [NEW]: Post variables problem with CGI version
From: marcus at names dot co dot uk Operating system: RedHat Linux 7.2 PHP version: 4.3.1 PHP Bug Type: Variables related Bug description: Post variables problem with CGI version When running 4.3.1 as a CGI binary, with register_globals set to 'on', the first post variable contains all post variables. For example, if you have a form with the variables (fields) and values var1=1, var2=2, var3=3, the following variables are set in the target script: var1=1&var2=2&var3=3 var2=2 var3=3 I am running the CGI under Zeus Web Server 4.2. I am not sure whether the $HTTP_POST_VARS array is set correctly, and cannot check this as I have had to revert back to 4.2.3. -- Edit bug report at http://bugs.php.net/?id=22920&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22920&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22920&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22920&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22920&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22920&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22920&r=support Expected behavior: http://bugs.php.net/fix.php?id=22920&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22920&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22920&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22920&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22920&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22920&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22920&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22920&r=gnused
#22919 [Bgs]: Missing server variables
ID: 22919 User updated by: marcus at names dot co dot uk Reported By: marcus at names dot co dot uk Status: Bogus Bug Type: CGI related Operating System: Redhat Linux 7.2 PHP Version: 4.3.1 New Comment: Thanks for the speedy reply - but how come it works in PHP 4.2.3? Has PHP changed the way in which these variables are set - ie did php not previously rely on SCRIPT_NAME being passed by the web server? Previous Comments: [2003-03-27 08:21: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 SCRIPT_NAME variable is not being exported by the command line or Zeus server, hence the lack of these two variables. [2003-03-27 03:34:30] marcus at names dot co dot uk When building PHP 4.3.1 as a cgi binary, some of the server variables do not get set correctlt. Most importantly, $PHP_SELF and $SCRIPT_NAME are missing altogether. Looking at cgi_main.c, it looks as though $PHP_SELF is inherited from $SCRIPT_NAME for the CGI version - so perhaps this is why they are both missing? I am running under Zeus Web Server 4.2, but the problem is the same when run from the command line. -- Edit this bug report at http://bugs.php.net/?id=22919&edit=1
#33321 [NEW]: Unknown '-export-symbols' flag passed to ld
From: marcus at synchromedia dot co dot uk Operating system: MacOS X 10.4.1 PHP version: 5.0.4 PHP Bug Type: Compile Failure Bug description: Unknown '-export-symbols' flag passed to ld Description: Configure goes OK, make gets nearly all the way through then fails near the end with this error: /usr/bin/ld: unknown flag: -export-symbols collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 I checked in the docs for OS X's ld and there doesn't seem to be an -export-symbols option defined. This option is in the original configure script, and ends up in the generated Makefile. Is there some alternative? Is ld broken on OS X? I have tried this on a clean OS install with a fresh copy of PHP source. The only mildly odd thing in my setup is that I'm linking to some libraries from fink (apache2, JPEG, PNG etc). I have tried building with a simpler configuration but still get the same result. Reproduce code: --- Here's my configure: CFLAGS='-I/sw/include' \ CXXFLAGS='-I/sw/include' \ CPPFLAGS='-I/sw/include' \ LDFLAGS='-L/sw/lib' \ './configure' \ '--disable-overload' \ '--enable-bcmath' \ '--enable-calendar' \ '--enable-exif' \ '--enable-ftp' \ '--enable-gd-imgstrttf' \ '--enable-gd-native-ttf' \ '--enable-inline-optimization' \ '--enable-mcal' \ '--enable-memory-limit' \ '--enable-pcntl' \ '--enable-pic' \ '--enable-shmop' \ '--enable-soap' \ '--enable-sockets' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-track-vars' \ '--enable-trans-sid' \ '--enable-versioning' \ '--enable-wddx' \ '--enable-yp' \ '--sysconfdir=/etc' \ '--with-apxs2=/sw/sbin/apxs' \ '--with-bz2' \ '--with-config-file-path=/etc' \ '--with-config-file-scan-dir=/etc/php.d' \ '--with-curl' \ '--with-dom=/usr' \ '--with-freetype2-dir=/sw' \ '--with-gd' \ '--with-gettext=/sw' \ '--with-iconv' \ '--with-imap-ssl=/sw' \ '--with-jpeg-dir=/sw' \ '--with-png-dir=/sw' \ '--with-ldap' \ '--with-mcrypt=/sw' \ '--with-mhash=/sw' \ '--with-mysql=/usr/local/mysql' \ '--with-openssl' \ '--with-pcre' \ '--with-pear' \ '--with-png' \ '--with-regex=system' \ '--with-ttf' \ '--with-xml' \ '--with-xsl' \ '--with-zlib' \ '--without-oci8' -- Edit bug report at http://bugs.php.net/?id=33321&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33321&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33321&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33321&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33321&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33321&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33321&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33321&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33321&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33321&r=support Expected behavior: http://bugs.php.net/fix.php?id=33321&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33321&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33321&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33321&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33321&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33321&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33321&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33321&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33321&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33321&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33321&r=mysqlcfg
#33321 [Opn->Bgs]: Unknown '-export-symbols' flag passed to ld
ID: 33321 User updated by: marcus at synchromedia dot co dot uk Reported By: marcus at synchromedia dot co dot uk -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: MacOS X 10.4.1 PHP Version: 5.0.4 New Comment: I don't know if the original problem of -export-symbols appearing is still a bug, but I checked through the docs from ./configure --help and removed a few apparently obsolete options and now it compiles and runs ok. My working config is now: './configure' \ '--disable-overload' \ '--enable-bcmath' \ '--enable-calendar' \ '--enable-dba' \ '--enable-exif' \ '--enable-ftp' \ '--enable-gd-imgstrttf' \ '--enable-gd-native-ttf' \ '--enable-mcal' \ '--enable-memory-limit' \ '--enable-pcntl' \ '--enable-shmop' \ '--enable-soap' \ '--enable-sockets' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-track-vars' \ '--enable-wddx' \ '--sysconfdir=/etc' \ '--with-apxs2=/sw/sbin/apxs' \ '--with-bz2' \ '--with-config-file-path=/etc' \ '--with-config-file-scan-dir=/etc/php.d' \ '--with-curl' \ '--with-dom=/usr' \ '--with-freetype2-dir=/sw' \ '--with-gd' \ '--with-gdbm=/sw' \ '--with-gettext=/sw' \ '--with-iconv' \ '--with-imap-ssl=/sw' \ '--with-jpeg-dir=/sw' \ '--with-png-dir=/sw' \ '--with-ldap' \ '--with-mcrypt=/sw' \ '--with-mhash=/sw' \ '--with-mysql=/usr/local/mysql' \ '--with-openssl' \ '--with-pcre' \ '--with-pear' \ '--with-png' \ '--with-ttf' \ '--with-xml' \ '--with-xsl' \ '--with-zlib' \ '--without-oci8' Apologies for any inconvenience, but I suspect this report may still be useful to anyone else running into similar problems. Previous Comments: [2005-06-13 12:28:55] marcus at synchromedia dot co dot uk Description: Configure goes OK, make gets nearly all the way through then fails near the end with this error: /usr/bin/ld: unknown flag: -export-symbols collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 I checked in the docs for OS X's ld and there doesn't seem to be an -export-symbols option defined. This option is in the original configure script, and ends up in the generated Makefile. Is there some alternative? Is ld broken on OS X? I have tried this on a clean OS install with a fresh copy of PHP source. The only mildly odd thing in my setup is that I'm linking to some libraries from fink (apache2, JPEG, PNG etc). I have tried building with a simpler configuration but still get the same result. Reproduce code: --- Here's my configure: CFLAGS='-I/sw/include' \ CXXFLAGS='-I/sw/include' \ CPPFLAGS='-I/sw/include' \ LDFLAGS='-L/sw/lib' \ './configure' \ '--disable-overload' \ '--enable-bcmath' \ '--enable-calendar' \ '--enable-exif' \ '--enable-ftp' \ '--enable-gd-imgstrttf' \ '--enable-gd-native-ttf' \ '--enable-inline-optimization' \ '--enable-mcal' \ '--enable-memory-limit' \ '--enable-pcntl' \ '--enable-pic' \ '--enable-shmop' \ '--enable-soap' \ '--enable-sockets' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-track-vars' \ '--enable-trans-sid' \ '--enable-versioning' \ '--enable-wddx' \ '--enable-yp' \ '--sysconfdir=/etc' \ '--with-apxs2=/sw/sbin/apxs' \ '--with-bz2' \ '--with-config-file-path=/etc' \ '--with-config-file-scan-dir=/etc/php.d' \ '--with-curl' \ '--with-dom=/usr' \ '--with-freetype2-dir=/sw' \ '--with-gd' \ '--with-gettext=/sw' \ '--with-iconv' \ '--with-imap-ssl=/sw' \ '--with-jpeg-dir=/sw' \ '--with-png-dir=/sw' \ '--with-ldap' \ '--with-mcrypt=/sw' \ '--with-mhash=/sw' \ '--with-mysql=/usr/local/mysql' \ '--with-openssl' \ '--with-pcre' \ '--with-pear' \ '--with-png' \ '--with-regex=system' \ '--with-ttf' \ '--with-xml' \ '--with-xsl' \ '--with-zlib' \ '--without-oci8' -- Edit this bug report at http://bugs.php.net/?id=33321&edit=1
#25379 [NoF->Opn]: 'make install' partially broken
ID: 25379 User updated by: marcus at synchromedia dot co dot uk Reported By: marcus at synchromedia dot co dot uk -Status: No Feedback +Status: Open Bug Type: Compile Failure Operating System: OpenBSD PHP Version: 4.3.3 New Comment: Sorry for the delay in responding. cc -v gives me: Reading specs from /usr/lib/gcc-lib/i386-unknown- openbsd3.1/2.95.3/specs gcc version 2.95.3 20010125 (prerelease) Previous Comments: [2003-09-29 05:58:18] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-09-23 22:11:41] [EMAIL PROTECTED] What compiler you have there? [2003-09-22 04:47:23] marcus at synchromedia dot co dot uk Unfortunately I can't. I'm running OpenBSD 3.1-stable, and the docs say: > The current ports tree may not be used with the > previous release. This is due to changes, typically > with the port make process, that require code based > upon the OpenBSD-current source tree. I guess a solution would be to upgrade to OpenBSD 3.4 when it comes out, but that's a whole load of work and downtime I can't afford right now. I can make do with 4.3.2 for now as I was planning on upgrading the whole system for PHP5. I don't know if you want to continue tracking this bug - 3.1 isn't that old (about 15 months), but I don't know how many users it may affect. FWIW, the current PHP5 beta installs ok. [2003-09-19 17:20:40] [EMAIL PROTECTED] Sigh, let me try that again: Have you tried the OpenBSD 3.4 port of PHP-4.3.3? It has quite a few patches to fix issues with the build process that I haven't had a chance to integrate properly with the PHP build process. ---- [2003-09-08 05:23:49] marcus at synchromedia dot co dot uk Thanks for looking at this. This snapshot doesn't generate errors, but the resulting installation is still not usable. I still get 'php -v' giving nothing, and 'pear -v' giving PHP info. the results of 'make install' still differ. In 4.3.2 I get: Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PHP SAPI module [activating module `php4' in /var/www/conf/httpd.conf] cp libs/libphp4.so /usr/lib/apache/modules/libphp4.so chmod 755 /usr/lib/apache/modules/libphp4.so cp /var/www/conf/httpd.conf /var/www/conf/ httpd.conf.bak cp /var/www/conf/httpd.conf.new /var/www/conf/ httpd.conf rm /var/www/conf/httpd.conf.new Installing shared extensions: /usr/local/lib/php/ extensions/no-debug-non-zts-20020429/ Installing PEAR environment: /usr/local/lib/php/ [PEAR] Archive_Tar- installed: 0.9 [PEAR] Console_Getopt - installed: 1.0 [PEAR] PEAR - installed: 1.1 [PEAR] DB - installed: 1.3 [PEAR] HTTP - installed: 1.2 [PEAR] Mail - installed: 1.0.1 [PEAR] Net_SMTP - installed: 1.0 [PEAR] Net_Socket - installed: 1.0.1 [PEAR] XML_Parser - installed: 1.0.1 [PEAR] XML_RPC- installed: 1.0.4 Installing build environment: /usr/local/lib/php/ build/ Installing header files: /usr/local/include/ php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config program: phpextdist and in this snapshot I get: Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PHP SAPI module: apache [activating module `php4' in /var/www/conf/httpd.conf] cp libs/libphp4.so /usr/lib/apache/modules/libphp4.so chmod 755 /usr/lib/apache/modules/libphp4.so cp /var/www/conf/httpd.conf /var/www/conf/ httpd.conf.bak cp /var/www/conf/httpd.conf.new /var/www/conf/ httpd.conf rm /var/www/conf/httpd.conf.new Installing shared extensions: /usr/local/lib/php/ extensions/no-debug-non-zts-20020429/ Installing PEAR environment: /usr/local/lib/php/ Installing build environment: /usr/local/lib/php/ build/ Installing header files: /usr/local/include/ php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config program: phpextdist i.e. you can see it's missing a load of PEAR stuff. The remainder of the comments for this report are too long. To view the rest of th
#25379 [Fbk->Opn]: 'make install' partially broken
ID: 25379 User updated by: marcus at synchromedia dot co dot uk Reported By: marcus at synchromedia dot co dot uk -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: OpenBSD PHP Version: 4.3.3 New Comment: make install-pear gives errors: Installing PEAR environment: /usr/local/lib/php/ PHP Parse error: parse error in /usr/local/src/php- 4.3.3/pear/package-Archive_Tar.xml on line 1 *** Error code 255 Stop in /usr/local/src/php-4.3.3 (line 274 of Makefile). *** Error code 1 Stop in /usr/local/src/php-4.3.3 (line 280 of Makefile). Previous Comments: [2003-09-29 08:27:08] [EMAIL PROTECTED] What does this do: # make install-pear [2003-09-29 07:51:22] marcus at synchromedia dot co dot uk Sorry for the delay in responding. cc -v gives me: Reading specs from /usr/lib/gcc-lib/i386-unknown- openbsd3.1/2.95.3/specs gcc version 2.95.3 20010125 (prerelease) [2003-09-23 22:11:41] [EMAIL PROTECTED] What compiler you have there? [2003-09-22 04:47:23] marcus at synchromedia dot co dot uk Unfortunately I can't. I'm running OpenBSD 3.1-stable, and the docs say: > The current ports tree may not be used with the > previous release. This is due to changes, typically > with the port make process, that require code based > upon the OpenBSD-current source tree. I guess a solution would be to upgrade to OpenBSD 3.4 when it comes out, but that's a whole load of work and downtime I can't afford right now. I can make do with 4.3.2 for now as I was planning on upgrading the whole system for PHP5. I don't know if you want to continue tracking this bug - 3.1 isn't that old (about 15 months), but I don't know how many users it may affect. FWIW, the current PHP5 beta installs ok. [2003-09-19 17:20:40] [EMAIL PROTECTED] Sigh, let me try that again: Have you tried the OpenBSD 3.4 port of PHP-4.3.3? It has quite a few patches to fix issues with the build process that I haven't had a chance to integrate properly with the PHP build process. 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/25379 -- Edit this bug report at http://bugs.php.net/?id=25379&edit=1
#29263 [Com]: Data not in $_REQUEST, but in $_POST or $_GET
ID: 29263
Comment by: marcus at synchromedia dot co dot uk
Reported By: dino at kataris dot de
Status: Open
Bug Type: Variables related
Operating System: Linux Debian
PHP Version: 5.0.0
New Comment:
I'm seeing exactly the same problem but running on a new
install of RedHat EL 3 with a fresh compile of PHP 5.0.1
The code I've been using (slightly more obvious than
previous example):
using test.php?a=1&b=2:
NULL
array(2) {
["a"]=>
string(1) "1"
["b"]=>
string(1) "2"
}
It's acting like EGPCS options are empty (they are set
correctly in my php.ini)?
Previous Comments:
[2004-08-09 18:05:23] jsgoupil at lookstrike dot com
Working fine for me ... PHP5.0.0
Even with your code.
[2004-07-19 18:45:45] dino at kataris dot de
Description:
I think I don't have to say more as in the summary I wrote,...
Data not in $_REQUEST, but in $_POST or $_GET
Reproduce code:
---
// works:
$page = 'start';
if(isset($_POST['page']))
{
$page = $_POST['page'];
}
if(isset($_GET['page']))
{
$page = $_GET['page'];
}
// doesn't works:
$page = 'start';
if(isset($_REQUEST['page']))
{
$page = $_REQUEST['page'];
}
Expected result:
The variable $page should have the value of the data, the script
request ;)
--
Edit this bug report at http://bugs.php.net/?id=29263&edit=1
#29263 [Com]: Data not in $_REQUEST, but in $_POST or $_GET
ID: 29263
Comment by: marcus at synchromedia dot co dot uk
Reported By: dino at kataris dot de
Status: Open
Bug Type: Variables related
Operating System: Linux Debian
PHP Version: 5.0.0
New Comment:
I just found this bug, which seems to be the same thing,
but is getting more attention:
http://bugs.php.net/bug.php?id=29176
Previous Comments:
[2004-08-19 22:47:42] marcus at synchromedia dot co dot uk
I'm seeing exactly the same problem but running on a new
install of RedHat EL 3 with a fresh compile of PHP 5.0.1
The code I've been using (slightly more obvious than
previous example):
using test.php?a=1&b=2:
NULL
array(2) {
["a"]=>
string(1) "1"
["b"]=>
string(1) "2"
}
It's acting like EGPCS options are empty (they are set
correctly in my php.ini)?
[2004-08-09 18:05:23] jsgoupil at lookstrike dot com
Working fine for me ... PHP5.0.0
Even with your code.
[2004-07-19 18:45:45] dino at kataris dot de
Description:
I think I don't have to say more as in the summary I wrote,...
Data not in $_REQUEST, but in $_POST or $_GET
Reproduce code:
---
// works:
$page = 'start';
if(isset($_POST['page']))
{
$page = $_POST['page'];
}
if(isset($_GET['page']))
{
$page = $_GET['page'];
}
// doesn't works:
$page = 'start';
if(isset($_REQUEST['page']))
{
$page = $_REQUEST['page'];
}
Expected result:
The variable $page should have the value of the data, the script
request ;)
--
Edit this bug report at http://bugs.php.net/?id=29263&edit=1
#29176 [Com]: $GLOBALS['_REQUEST'], $GLOBALS['_ENV'] AND $GLOBALS['_SERVER'] are empty
ID: 29176 Comment by: marcus at synchromedia dot co dot uk Reported By: webmaster at ragnarokonline dot de Status: Assigned Bug Type: Variables related Operating System: SuSE 9.0 PHP Version: 5.0.0 Assigned To: sesser New Comment: I'm seeing this in a fresh compile of 5.0.1 on RedHat EL 3. Again, turning register_long_arrays is a workaround until it's fixed properly. FWIW, I'm also using mmcache. Previous Comments: [2004-08-19 09:20:32] info at webaq dot com PHP File use "SafeGuard Suite 3.5.0" encode Apache 1.3.29 PHP 5.0.0 Zend Engine v2.0.0 Zend Optimizer v2.5.3 Notice: Undefined variable: _SERVER in /www/ZendEncode.php on line 2 Undefined variable: _SERVER!!! >_< [2004-07-16 09:35:12] tmgh at www dot deyang dot gov dot cn if set register_long_arrays=Off auto_globals_jit=off ,php5+mmcache2.4.7-cvs work greatly. can somebody tell me what's auto_globals_jit? [2004-07-16 03:09:03] webmaster at ragnarokonline dot de The dev replys, when he checked in a fix. So we have to wait, what the devs say ;) [2004-07-16 03:04:53] tmgh at www dot deyang dot gov dot cn at present,the cvs does not have newest source.maybe i have to wait for few time.thanks for your response. ps:it's mmcache's bug? [2004-07-16 02:53:48] webmaster at ragnarokonline dot de I have tested this now. The MMCache-Section was commented out, so its definately not related. PS: If a dev fixes this, this is checked into CVS, so you can simply compile or download the latest snapshot after the fix have been checked in. Regards, Christian Stadler 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/29176 -- Edit this bug report at http://bugs.php.net/?id=29176&edit=1
#29608 [Com]: OCi reports OCIStmtExecute: ORA-24324: service handle not initialized
ID: 29608
Comment by: marcus dot schuelke at juj dot de
Reported By: tomek at matrox dot pl
Status: No Feedback
Bug Type: OCI8 related
Operating System: W2k, Red Hat
PHP Version: 5.0.0
New Comment:
This Bug is caused by PHP 5
to fix the problem use
oci_new_connect ( username,password, db)
instead of ocilogon();
hope that will fix your problem..
Previous Comments:
[2004-09-01 02:51:44] cnichols at nmu dot edu
Same problem over here. Running PHP 5.0.1 with Apache2 and Oracle 10g.
I found a site saying that errmsg has to do with a soon-to-expire
password, but I doubt that's the case for all of you :)
[2004-08-30 10:21:46] symedeot at yahoo dot fr
I have exactly the same problem ! If works sometimes, sometime not. If
you ask the same page again, it should work or not...
Warning: oci_execute() [function.oci-execute]: OCIStmtExecute:
ORA-24324: descripteur de service non initialisé in ...
Warning: ocifetch() [function.ocifetch]: OCIFetch: ORA-24338:
descripteur d'instruction non exécuté in...
Just try to access Oracle like this :
$conn = OCILogon("GPE", "gpe","PLSE");
$stmt = OCIParse($conn,$myrequest);
OCI_Execute($stmt,OCI_DEFAULT);
while ( OCIFetch($stmt) )
{
}
OCIFreeStatement($stmt);
OCILogoff($conn);
Oracle 9.i under RedHat 9, php 5.00 and 5.01(same), any Apache 2
version.
Everything fine on same server when using PHP 4.3x
It is clearly a bug ! And we are quite a lot to report it !
[2004-08-19 01:00:08] php-bugs at lists dot php dot net
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".
[2004-08-12 11:02:53] izhekov at ppartner dot com
I've tried to reproduce this problem.
I've installed 2 apache services on different ports 80 and 81 - first
of them using PHP5 and the other using PHP4 then I restarted the
system.
When first I access my scripts using PHP5 on port 80 everythings goes
fine.
Running scripts afterthat with PHP4 on port 81 also worked fine.
When I tried to access again scripts on apache service running on 80
port, errors occured again:
-
Warning: ociexecute() [function.ociexecute]: OCIStmtExecute: ORA-24324:
service handle not initialized in
C:\SERVER\HTTPD\htdocs\service\db_modul.php on line 21
Warning: ocifetch() [function.ocifetch]: OCIFetch: ORA-24338: statement
handle not executed in C:\SERVER\HTTPD\htdocs\service\db_modul.php on
line 27
--
[2004-08-12 10:09:03] izhekov at ppartner dot com
I migrate from PHP 4 to PHP 5 on my Windows 2003 server. Everything
goes fine, but when I try to use an PHP application that uses Oracle
database I receive the error mentioned above. I restarted the Oracle
server but that not helped me. Other applications and PHP 4 works fine
with my Oracle server, but PHP 5 did not.
Last night the power supply goes down unexpectally and both Oracle
server and web server was restarted. Now everything seems to be fine,
but I'm sure the problem exists and many people will have the same
problems also.
Searching in Google for:
http://www.google.com/search?hl=bg&ie=UTF-8&q=%22service+handle+not+initialized+in%22+%2Bwarning&lr=
shows many sites with the same problem.
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/29608
--
Edit this bug report at http://bugs.php.net/?id=29608&edit=1
#29342 [Com]: strtotime(null) does not return -1
ID: 29342
Comment by: marcus at synchromedia dot co dot uk
Reported By: php dot net at gurugeek dot com
Status: Closed
Bug Type: Date/time related
Operating System: RHEL 3.0
PHP Version: 5.0.0
New Comment:
I'm running PHP5.0.2, and I'm seeing a very similar bug:
under PHP 4.3.9 this gives:
Tue, 12 Oct 2004 17:16:04 +0100
Tue, 12 Oct 2004 18:16:04 +0100
Tue, 12 Oct 2004 18:16:04 +0100
Under PHP 5.0.2:
Tue, 12 Oct 2004 00:00:00 +0100
Tue, 12 Oct 2004 01:00:00 +0100
Tue, 12 Oct 2004 01:00:00 +0100
so the description of this bug could be expanded to:
strtotime returns times relative to midnight of current
day instead of requested time.
Previous Comments:
[2004-09-13 20:55:16] jonathant at digbang dot com
error report:
Now (php 5.0.1) when you send null as a parameter to strtotime() it
returns an error instead of -1
[2004-08-24 21:22:15] kevin at brucecreative dot com
Is there a bug with strtotime in 5.0.1? strtotime("+11
minutes") doesn't work, when it worked fine in 4.x
[2004-07-28 03:45:02] [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-22 23:09:57] php dot net at gurugeek dot com
Description:
Executing strtotime(null) returns midnight of the current day. The same
happens with strtotime(false).
[EMAIL PROTECTED] libexec]$ php -r 'echo strtotime(null) . "\n";'
1090479600
[EMAIL PROTECTED] libexec]$ php -r 'echo date("r", strtotime(null)) .
"\n";'
Thu, 22 Jul 2004 00:00:00 -0700
Reproduce code:
---
echo strtotime(null);
echo strtotime("");
Expected result:
-1
Actual result:
--
Midnight of the current day:
Thu, 22 Jul 2004 00:00:00 -0700
--
Edit this bug report at http://bugs.php.net/?id=29342&edit=1
#32066 [NEW]: display_errors=off also suppresses output from php -l
From: marcus at synchromedia dot co dot uk Operating system: RedHat Enterprise Linux 3 PHP version: 5.0.3 PHP Bug Type: PHP options/info functions Bug description: display_errors=off also suppresses output from php -l Description: In php5, if php.ini contains a display_errors=off directive, it also suppresses error details from 'php -l' on a command line. I guess this could be a deliberate change in pHP5, but it is really not very helpful as php -l will only ever be run by developers. This is in contrast to php4, which always shows errors from php -l, even if display_errors is off. Reproduce code: --- execute this script (containing a deliberate error) using php -l on a command line with display_errors turned off Expected result: Parse error: parse error, unexpected ';' in /home/ username/error.php on line 2 Actual result: -- no output is generated at all. -- Edit bug report at http://bugs.php.net/?id=32066&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32066&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32066&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32066&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32066&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32066&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32066&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32066&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32066&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32066&r=support Expected behavior: http://bugs.php.net/fix.php?id=32066&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32066&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32066&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32066&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32066&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32066&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32066&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32066&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32066&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32066&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32066&r=mysqlcfg
#32111 [NEW]: Cookies separated by colon, not semicolon
From: daniel dot marcus at gmail dot com Operating system: windows 2000 server PHP version: 4.3.10 PHP Bug Type: Session related Bug description: Cookies separated by colon, not semicolon Description: The browser (nokia 3200 and others) sends the cookies in the form: name="value",name2="value2" instead of: name="value";name2="value2" In the first example above PHP will get only one cookie: "name" with it's value set to: "value,name2=value2". So all the others cookies are lost. How can i fix this on php for windows? session.save_handler = files session.save_path ="C:\AppServ\php\session" session.use_cookies = 1 session.use_only_cookies = 1 session.name = PHPSESSID session.auto_start = 0 session.cookie_lifetime = 0 session.cookie_path = / session.cookie_domain = session.serialize_handler = php session.gc_probability = 1 session.gc_divisor = 1000 session.gc_maxlifetime = 1440 session.bug_compat_42 = 0 session.bug_compat_warn = 1 session.referer_check = session.entropy_length = 0 session.entropy_file = session.cache_expire = 180 session.use_trans_sid = 0 -- Edit bug report at http://bugs.php.net/?id=32111&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32111&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32111&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32111&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32111&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32111&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32111&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32111&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32111&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32111&r=support Expected behavior: http://bugs.php.net/fix.php?id=32111&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32111&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32111&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32111&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32111&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32111&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32111&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32111&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32111&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32111&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32111&r=mysqlcfg
#32111 [Fbk->Opn]: Cookies separated by colon, not semicolon
ID: 32111 User updated by: daniel dot marcus at gmail dot com Reported By: daniel dot marcus at gmail dot com -Status: Feedback +Status: Open Bug Type: Session related Operating System: windows 2000 server PHP Version: 4.3.10 New Comment: Sorry Sniper. I rented some cellphones for testing my software and I had to take it back. Anyway I had some other problems. I decided no to use cookies, only for the session cookie. The problem was this: for every session cookie the phone (some nokias) hold it twice and therefore the session cookie I got was: PHPSESSID="6235123518263Ae4,PHPSESSID=6235123518263Ae4" and obviusly I would get the error "Session can be only numbers, letters, etc,etc". I decided to turn on trans_id in order to make it run on all phones but I may have problems with security issues. I don't believe it's a php bug onlybut maybe it becames a bug in conjunction with nokia browsers. It worked flawless with SonyEricsson, Samsung, Panasonic,Siemens,Sagem and Motorola phones. So I won't blame php for this problem and I won't ban nokia phones just for this. Hey! come on...a lot of people use nokia. Thanks Sniper just for answering. Previous Comments: [2005-02-27 10:47:23] [EMAIL PROTECTED] Can you please provide the full headers the client (the phone in this case) sends? ---- [2005-02-25 16:49:21] daniel dot marcus at gmail dot com Description: The browser (nokia 3200 and others) sends the cookies in the form: name="value",name2="value2" instead of: name="value";name2="value2" In the first example above PHP will get only one cookie: "name" with it's value set to: "value,name2=value2". So all the others cookies are lost. How can i fix this on php for windows? session.save_handler = files session.save_path ="C:\AppServ\php\session" session.use_cookies = 1 session.use_only_cookies = 1 session.name = PHPSESSID session.auto_start = 0 session.cookie_lifetime = 0 session.cookie_path = / session.cookie_domain = session.serialize_handler = php session.gc_probability = 1 session.gc_divisor = 1000 session.gc_maxlifetime = 1440 session.bug_compat_42 = 0 session.bug_compat_warn = 1 session.referer_check = session.entropy_length = 0 session.entropy_file = session.cache_expire = 180 session.use_trans_sid = 0 -- Edit this bug report at http://bugs.php.net/?id=32111&edit=1
#32066 [Bgs]: display_errors=off also suppresses output from php -l
ID: 32066 User updated by: marcus at synchromedia dot co dot uk Reported By: marcus at synchromedia dot co dot uk Status: Bogus Bug Type: PHP options/info functions Operating System: RedHat Enterprise Linux 3 PHP Version: 5.0.3 New Comment: You say: > Error display ini setting affects all error reporting. That's just not true. It may be that the behaviour has changed in PHP5 (in which case it should be documented here: http://www.php.net/manual/en/ ref.errorfunc.php#ini.display-errors), but in PHP4 having display_errors=off does NOT suppress error messages from php -l. It's very easy to reproduce in PHP4: The output from 'php -i|grep display_errors' is: display_errors => Off => Off and yet php -l on the example I gave produces: PHP Parse error: parse error, unexpected ';' in test.php on line 2 Errors parsing test.php Under PHP5 it does NOT work this way - the behaviour HAS changed to the behaviour you said. If what you said is MEANT to be true, then this bug should be closed, rephrased as 'display_errors=off does not suppress output from php -l' and re-reported as a PHP4 bug - it's got to be a bug one way or the other. Personally I'd like php-l to ignore the display_errors setting, just as it does in PHP4, which is why I reported the discrepancy in the first place. Previous Comments: [2005-02-23 19:32:55] [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 Error display ini setting affects all error reporting. ---- [2005-02-22 16:07:50] marcus at synchromedia dot co dot uk Description: In php5, if php.ini contains a display_errors=off directive, it also suppresses error details from 'php -l' on a command line. I guess this could be a deliberate change in pHP5, but it is really not very helpful as php -l will only ever be run by developers. This is in contrast to php4, which always shows errors from php -l, even if display_errors is off. Reproduce code: --- execute this script (containing a deliberate error) using php -l on a command line with display_errors turned off Expected result: Parse error: parse error, unexpected ';' in /home/ username/error.php on line 2 Actual result: -- no output is generated at all. -- Edit this bug report at http://bugs.php.net/?id=32066&edit=1
#24295 [NEW]: Sessions that pass documents back using fpassthru hang intermittently
From: marcus at quintic dot co dot uk
Operating system: Windows XP
PHP version: 4.3.2
PHP Bug Type: Session related
Bug description: Sessions that pass documents back using fpassthru hang intermittently
Description:
I have an application that uses multiple frames (anywhere from 5-10 at a
time). The frames get updated at roughly the same time - a user steps
through a flowchart that has multiple documents attached to each step that
can target any of the frames). Each of the frames is running in the same
session (in that the php that generates a requested page starts with
session_start()). The document to be displayed is passed through on the
url and this argument is looked up in an array which returns a path to a
local file. This path is then fed to fpassthru and the document gets
served up to the browser.
The session locks up randomly using fpassthru, but if the fpassthru is
replaced by a redirect (header("Location:")) to a web based copy of
the requested document the lock up stop occuring.
Obviously the workaround is to use the redirect but this means that a user
can get directly to a document without going through the session
authentication etc, so I'd prefer to get the fpassthru to work.
My php installation is the standard install with the following extensions
enabled:
extension=php_db.dll
extension=php_dba.dll
extension=php_dbx.dll
extension=php_domxml.dll
extension=php_gd2.dll
extension=php_mhash.dll
extension=php_pdf.dll
extension=php_shmop.dll
extension=php_sockets.dll
extension=php_xmlrpc.dll
I'm using the SAPI module. The problem still exists (although seems to
happen less frequently) with the cgi version.
Reproduce code:
---
start_session();
// lookup file and place in $path
// ... code removed ...
// send headers
header("Pragma: ");
header("Cache-Control: ");
// lookup mimetype and place in $mimetype
// ... code removed ...
header("Content-type: " . $mimetype );
$sizeh = "Content-length: " . filesize($path);
header($sizeh);
header("Content-transfer-encoding: binary\n");
// send file contents
$fp=fopen($path, "rb");
fpassthru($fp);
fclose($fp);
exit;
Expected result:
The document requested in the browser frame, which is what happens the
majority of times (approx 95%). Its definitely something to do with an
interaction between a session and fpassthru because removing either fixes
the problem.
Actual result:
--
Lockups approx 5% of the time - a new session can be started in a
different browser instance, but the current session is lost.
--
Edit bug report at http://bugs.php.net/?id=24295&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24295&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=24295&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24295&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24295&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24295&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24295&r=support
Expected behavior: http://bugs.php.net/fix.php?id=24295&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24295&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24295&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24295&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24295&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24295&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24295&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24295&r=gnused
#24295 [Opn]: Sessions that pass documents back using fpassthru hang intermittently
ID: 24295 User updated by: marcus at quintic dot co dot uk Reported By: marcus at quintic dot co dot uk Status: Open -Bug Type: Documentation problem +Bug Type: Session related Operating System: Windows XP PHP Version: 4.3.2 New Comment: File size seems not to matter - its a really annoying bug to try and reproduce as well. One day I'll have no problems at all, the next its falling over all the time. If I watch the apache logs there are no errors and once its locked no documents are being requested. If I switch on the php error logs nothing appears in there either. Is there anyway I can get more debug information? Its like a page is getting the session lock and not giving it up and so stopping all other pages from starting (because they all try to get the session). Whats wierd is that nothing gets put in the apache access log - I can click on a button in one of the frames that launches a new window (using javascript) that I know requests a certain php document (again, under the same session), but the request never makes it into the access log and the document never gets to the window. I think the original reply (after my submission) switched it to documentation - I've switched it back to session related. Previous Comments: [2003-06-23 08:15:40] [EMAIL PROTECTED] Sorry, 'use_trans_sid' of course ( shoudln't have written the reply in a hurry..) Whats the size of the files in question anyway? Does it work more reliable with small(er) files? I still don't the a documentation issue here..? ---- [2003-06-23 07:58:41] marcus at quintic dot co dot uk wrt disabling session.enable_trans_sid Assuming you mean the use_trans_sid option, its already disabled. [2003-06-23 06:56:53] [EMAIL PROTECTED] Disable session.enable_trans_sid in php.ini or by -Entry in http.conf and see if your problem is gone. ---- [2003-06-23 06:16:19] marcus at quintic dot co dot uk Mmmm - I may not have made myself clear enough in the bug report! By lockups I meant that the _whole_ session locks completely and never comes back to life. Once a frame gets into this state, none of the other frames will work and the browser appears to be completely locked up. A new instance of the browser works as normal though (different session). ---- [2003-06-23 06:11:42] marcus at quintic dot co dot uk Eh? I realise the session file should be locked to restrict access, what I dont expect is the browser to lockup completely. If any of the pages are requested/executed at the same time then surely each of the frames should just go about their business, wait for the session file lock to come free and continue to work. Whilst this may delay some of the documents it shouldnt be significant. It certainly shouldnt lock up the browser completely. 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/24295 -- Edit this bug report at http://bugs.php.net/?id=24295&edit=1
#22526 [Com]: session_start/popen hang
ID: 22526 Comment by: marcus at quintic dot co dot uk Reported By: iberry at raxnet dot net Status: Open Bug Type: Session related Operating System: Windows 2000 PHP Version: 4.3.2 New Comment: I have exactly the same problem with fopen+fpassthru instead of popen (just filed a bug that got closed as a duplicate #24295) on Windows XP. It makes session-based authentication next to useless for an app we are developing. CGI does not cure it, neither does disabling the trans_sid. The bug is apparent in 4.2.x and upwards in our case (on Apache 1.3.27) Previous Comments: [2003-06-06 11:03:10] mobrien at milleker dot org Same problem observed in 4.3.2 on Win2K with Apache 1.3.1 Benny - Read the section in the install.txt about running in CGI mode (if you have not already): this is a completely unacceptable situation for production environments, IMO. [2003-06-02 06:21:56] bbubble622 at yahoo dot com Finally I was able to switch to CGI based PHP. Although it is (very) slow, it gives the right results ! -benny [2003-06-01 12:18:32] iberry at raxnet dot net I experienced this problem under PHP 4.3.2 as well. [2003-06-01 11:50:06] bbubble622 at yahoo dot com yes ! [2003-06-01 10:50:51] [EMAIL PROTECTED] Does this happen with PHP 4.3.2 ? 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/22526 -- Edit this bug report at http://bugs.php.net/?id=22526&edit=1
#24329 [NEW]: Appending path info to a php script breaks under IIS
From: marcus at quintic dot co dot uk Operating system: XP and 2k PHP version: 4.3.2 PHP Bug Type: IIS related Bug description: Appending path info to a php script breaks under IIS Description: I have a page, test.php, that contains simply a call to phpinfo(). If I go to it in a browser as http://localhost/test.php it displays the php information as expected. If I attach some path_info to the url I get a cannot find page error under IIS5.1 on XP and a PHP error saying it cant find the test.php/whatever/I/have/here script. Clearly this is wrong. I have searched the bug tracking database and the following suggestions have been tried in both ISAPI and CGI mode (none of them work for us, although the bugs are getting closed presumably because they work for the people trying them): cgi.force_redirect = 0 (I've also tried 1) cgi.fix_pathinfo = 0 (I've also tried 1) Setting the IIS AllowPathInfo... variable to TRUE or FALSE makes no difference. I've also tried all combinations of the above. This isnt a one off either as it happens on all machines we've tried it on (5 separate IIS5 installations so far). The strange thing is, IIS looks like its requesting the correct document, test.php because thats whats coming up in the IIS logs - it looks like php is returning the error. On the 2k box this is more obvious because we get an error from php saying that it cant open a stream on c:/inetpub/wwwroot/whatever/I/have/here when IIS is allowing PATH_INFO and c:/inetpub/wwwroot/test.php/whatever/I/have/here when IIS does not allow PATH_INFO. Reproduce code: --- // IIS5.1, PHP 4.3.x // Goto URL http://localhost/test.php/path/info Expected result: I'd expect the test.php document to be displayed whether I entered path information or not. Note that this is not a bug about PATH_INFO being incorrect - we dont even get that far. PHP returns errors about not being able to open a stream to a document that _includes_ the path_info in its translated path. It also happens under ISAPI or CGI. -- Edit bug report at http://bugs.php.net/?id=24329&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24329&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24329&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24329&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24329&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24329&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24329&r=support Expected behavior: http://bugs.php.net/fix.php?id=24329&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24329&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24329&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24329&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24329&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24329&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24329&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24329&r=gnused
#24329 [Opn]: Appending path info to a php script breaks under IIS
ID: 24329 User updated by: marcus at quintic dot co dot uk Reported By: marcus at quintic dot co dot uk Status: Open Bug Type: IIS related Operating System: XP and 2k PHP Version: 4.3.2 New Comment: The first para should read: If I attach some path_info to the url I get a cannot find page error under IIS5.1 on XP and under 2k a PHP error saying it cant find the test.php/whatever/I/have/here script. Previous Comments: [2003-06-25 06:13:10] marcus at quintic dot co dot uk Description: I have a page, test.php, that contains simply a call to phpinfo(). If I go to it in a browser as http://localhost/test.php it displays the php information as expected. If I attach some path_info to the url I get a cannot find page error under IIS5.1 on XP and a PHP error saying it cant find the test.php/whatever/I/have/here script. Clearly this is wrong. I have searched the bug tracking database and the following suggestions have been tried in both ISAPI and CGI mode (none of them work for us, although the bugs are getting closed presumably because they work for the people trying them): cgi.force_redirect = 0 (I've also tried 1) cgi.fix_pathinfo = 0 (I've also tried 1) Setting the IIS AllowPathInfo... variable to TRUE or FALSE makes no difference. I've also tried all combinations of the above. This isnt a one off either as it happens on all machines we've tried it on (5 separate IIS5 installations so far). The strange thing is, IIS looks like its requesting the correct document, test.php because thats whats coming up in the IIS logs - it looks like php is returning the error. On the 2k box this is more obvious because we get an error from php saying that it cant open a stream on c:/inetpub/wwwroot/whatever/I/have/here when IIS is allowing PATH_INFO and c:/inetpub/wwwroot/test.php/whatever/I/have/here when IIS does not allow PATH_INFO. Reproduce code: --- // IIS5.1, PHP 4.3.x // Goto URL http://localhost/test.php/path/info Expected result: I'd expect the test.php document to be displayed whether I entered path information or not. Note that this is not a bug about PATH_INFO being incorrect - we dont even get that far. PHP returns errors about not being able to open a stream to a document that _includes_ the path_info in its translated path. It also happens under ISAPI or CGI. -- Edit this bug report at http://bugs.php.net/?id=24329&edit=1
#24329 [Fbk->Opn]: Appending path info to a php script breaks under IIS
ID: 24329 User updated by: marcus at quintic dot co dot uk Reported By: marcus at quintic dot co dot uk -Status: Feedback +Status: Open Bug Type: IIS related Operating System: XP and 2k PHP Version: 4.3.2 New Comment: This does not appear to fix it under the limited tests I've tried. I'll add more feedback when I can perform more testing. Previous Comments: [2003-08-14 00:35:31] [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 And check your php.ini settings. (this works fine for me in Linux/Apache) [2003-06-25 06:14:35] marcus at quintic dot co dot uk The first para should read: If I attach some path_info to the url I get a cannot find page error under IIS5.1 on XP and under 2k a PHP error saying it cant find the test.php/whatever/I/have/here script. [2003-06-25 06:13:10] marcus at quintic dot co dot uk Description: I have a page, test.php, that contains simply a call to phpinfo(). If I go to it in a browser as http://localhost/test.php it displays the php information as expected. If I attach some path_info to the url I get a cannot find page error under IIS5.1 on XP and a PHP error saying it cant find the test.php/whatever/I/have/here script. Clearly this is wrong. I have searched the bug tracking database and the following suggestions have been tried in both ISAPI and CGI mode (none of them work for us, although the bugs are getting closed presumably because they work for the people trying them): cgi.force_redirect = 0 (I've also tried 1) cgi.fix_pathinfo = 0 (I've also tried 1) Setting the IIS AllowPathInfo... variable to TRUE or FALSE makes no difference. I've also tried all combinations of the above. This isnt a one off either as it happens on all machines we've tried it on (5 separate IIS5 installations so far). The strange thing is, IIS looks like its requesting the correct document, test.php because thats whats coming up in the IIS logs - it looks like php is returning the error. On the 2k box this is more obvious because we get an error from php saying that it cant open a stream on c:/inetpub/wwwroot/whatever/I/have/here when IIS is allowing PATH_INFO and c:/inetpub/wwwroot/test.php/whatever/I/have/here when IIS does not allow PATH_INFO. Reproduce code: --- // IIS5.1, PHP 4.3.x // Goto URL http://localhost/test.php/path/info Expected result: I'd expect the test.php document to be displayed whether I entered path information or not. Note that this is not a bug about PATH_INFO being incorrect - we dont even get that far. PHP returns errors about not being able to open a stream to a document that _includes_ the path_info in its translated path. It also happens under ISAPI or CGI. -- Edit this bug report at http://bugs.php.net/?id=24329&edit=1
#26449 [NoF->Opn]: usleep doesnt work correctly
ID: 26449 User updated by: marcus at quintic dot co dot uk Reported By: marcus at quintic dot co dot uk -Status: No Feedback +Status: Open Bug Type: Feature/Change Request Operating System: Windows XP PHP Version: 4.3.4 Assigned To: wez New Comment: Looks like it works with PHP5 RC2 thanks! How about a backport to v4? Thanks again Previous Comments: [2004-01-12 21:05:15] [EMAIL PROTECTED] The next php5 snapshot should include a correctly working usleep(). [2004-01-12 19:45:57] antispammail at gmx dot de I also really NEEED this usleep function to work, but tested the latest php 5 as advised an it does not work :( Have you removed this feature allready again? why? according to this : http://groups.google.com/groups?q=usleep+win32&hl=de&lr=&ie=UTF-8&oe=UTF-8&selm=9401pp%242fgt%241%40FreeBSD.csie.NCTU.edu.tw&rnum=3 === [2001-01-15 18:22:56] [EMAIL PROTECTED] usleep exists on Win32 as the Sleep command (it takes a millisecond value as parameter) so here is the patch for making the usleep() php function to work on win32 platforms: in main/win95nt.h, line 27: #define php_sleep(t) Sleep(t*1000) add the following line so it looks like: #define php_sleep(t) Sleep(t*1000) #define usleep(t) Sleep(t) and in config.w32.h, line 93: /* Define if you have the usleep function. */ #undef HAVE_USLEEP change it to: /* Define if you have the usleep function. */ #define HAVE_USLEEP 1 -Christophe Thibault Nullsoft (www.nullsoft.com/www.winamp.com) === I just don't know how to do this change as a "user" of php ... PLEASE HELP and put this in the new release! Chris [2003-12-04 02:26:47] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-11-29 17:58:18] [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 I've implemented this in PHP 5. Since it requires win98 and later, it might not go into the php4 branch. Please try a php 5 snapshot and let us know how well it works for you. ---- [2003-11-29 16:11:37] marcus at quintic dot co dot uk :) Hell, who need microseconds anyway - being able to delay for less than a second without chewing cpu would be enough for me. Thanks. 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/26449 -- Edit this bug report at http://bugs.php.net/?id=26449&edit=1
Bug #49448 [Com]: Sunset/Sunrise Zenith default values wrong
Edit report at https://bugs.php.net/bug.php?id=49448&edit=1
ID: 49448
Comment by: marcus dot fritze at googlemail dot com
Reported by:the_good_technician at yahoo dot com
Summary:Sunset/Sunrise Zenith default values wrong
Status: Bogus
Type: Bug
Package:Date/time related
Operating System: *
PHP Version:5.3.0
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
I also don't understand where the 35/60 is coming from. Do you have any
reliable sources?
Description:
"Sunrise and sunset. For computational purposes, sunrise or sunset is defined
to occur when the geometric zenith distance of center of the Sun is 90.8333
degrees. That is, the center of the Sun is geometrically 50 arcminutes below a
horizontal plane. For an observer at sea level with a level, unobstructed
horizon, under average atmospheric conditions, the upper limb of the Sun will
then appear to be tangent to the horizon. The 50-arcminute geometric depression
of the Sun's center used for the computations is obtained by adding the average
apparent radius of the Sun (16 arcminutes) to the average amount of atmospheric
refraction at the horizon (34 arcminutes)."
Source:
http://www.usno.navy.mil/USNO/astronomical-applications/astronomical-information-center/rise-set-twi-defs
Previous Comments:
[2011-10-02 20:02:01] dronkert at gmail dot com
Derick is right that the value is correct according to the "algorithm"
(actually
just a statement) but the submitter is correct that the canonical value is
90º50'
or 90.833 degrees. Thus the problem is the source and perhaps validity of
the
code documentation. Where does the 90º35' value come from? I could only find
references to 90º50'.
[2010-03-07 16:30:18] der...@php.net
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
The algorithm code we use, clearly says:
* altit = the altitude which the Sun should cross
* Set to -35/60 degrees for rise/set, -6 degrees
* for civil, -12 degrees for nautical and -18
* degrees for astronomical twilight.
and -35/60 = â0.58333.
[2009-09-03 07:58:41] the_good_technician at yahoo dot com
Description:
This is an easy problem to fix. I'm surprised nobody has reported it so far.
The default configuration value for "date.sunrise_zenith" and
"date.sunset_zenith" is "90.58". But this value is incorrect!
The correct value for a sunrise/sunset zenith angle is 90 + (50/60)
WHICH EQUALS
90.833
NOT
90.583
Reproduce code:
---
echo ini_get("date.sunrise_zenith") . "\n";
echo ini_get("date.sunset_zenith") . "\n";
Expected result:
90.833
90.833
Actual result:
--
90.583
90.583
--
Edit this bug report at https://bugs.php.net/bug.php?id=49448&edit=1
[PHP-BUG] Bug #65478 [NEW]: Multi-string DNS records obtained with dns_get_record contain nulls
From: marcus at synchromedia dot co dot uk
Operating system: OS X
PHP version: 5.4.18
Package: Network related
Bug Type: Bug
Bug description:Multi-string DNS records obtained with dns_get_record contain
nulls
Description:
RFC4408 (SPF records in DNS) http://www.ietf.org/rfc/rfc4408.txt section
3.1.3
mentions the likely use of RFC1035's provision to allow a DNS record to
contain more
than one string. Specifically it says:
For example:
IN TXT "v=spf1 first" "second string..."
MUST be treated as equivalent to
IN TXT "v=spf1 firstsecond string..."
PHP's dns_get_record function does NOT work this way - it concatenates the
strings,
but inserts a null (\0) character between them, so in this example it would
produce
this string:
IN TXT "v=spf1 first\0second string..."
This is enough to break things like DKIM. The example code uses the DKIM
key for
google groups.
Notice that the string length in the actual result is off by one: the two
entries
are 183 and 218 chars, which should give 401 when concatenated, but there
are 402
chars in the result. The '\0' is visible in this result, but in some
circumstances
it may not be visible. I've seen this behaviour on all platforms (OS X,
Linux) and
versions (5.3, 5.4) I've tried.
A workaround is to strip the null from the resource record:
$rr = str_replace("\0", '', $rr);
The returned value from the dns_get_record includes the original separate
strings
under the 'entries' key, so there's no benefit in keeping the nulls for the
purpose
of being able to separate the strings.
This bug is related to bug #54821, but is not a dupe of it.
Test script:
---
var_dump(dns_get_record("20120806._domainkey.googlegroups.com", DNS_TXT));
Expected result:
array(1) {
[0] =>
array(6) {
'host' =>
string(36) "20120806._domainkey.googlegroups.com"
'class' =>
string(2) "IN"
'ttl' =>
int(4502)
'type' =>
string(3) "TXT"
'txt' =>
string(401) "k=rsa;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzb2fhKQxJYmlF+PNnOExrd8kRMlV2b/GBb
1mw4vpTGDVS8wD+6k8TEXSSsaS2B4uOrOfKBWBb6lMVbVmi/zy3Jc+YP5XkEt09UtXm4HWeAqgu0arqC
mjH6yhbUGlPipIqV00QMmWy5jnWJsHioAAN8G5S5t5qrCRzxv7ntDOOUhwEPCIIrfncOgBzF4XdJPiua
nUNOX5Jw5Q2H3wcOmBTKQ3t0ETvPYK/cqpe7rJ+4L06+QKE2kk/WDuHuxtSZbZUo2U6kM56CGxdvBiNR
fPLoMFnMddCQqXYJsJZJHfwBnLQxFwbkZS0idkSWLf8AUKbB0lVWQe4+F0M1CeOj8YimmQIDAQAB"
'entries' =>
array(2) {
[0] =>
string(183) "k=rsa;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzb2fhKQxJYmlF+PNnOExrd8kRMlV2b/GBb
1mw4vpTGDVS8wD+6k8TEXSSsaS2B4uOrOfKBWBb6lMVbVmi/zy3Jc+YP5XkEt09UtXm4HWeAqgu0arqC
mjH6yhbUGlPipIqV"
[1] =>
string(218)
"QMmWy5jnWJsHioAAN8G5S5t5qrCRzxv7ntDOOUhwEPCIIrfncOgBzF4XdJPiuanUNOX5Jw5Q2H3wcOm
BTKQ3t0ETvPYK/cqpe7rJ+4L06+QKE2kk/WDuHuxtSZbZUo2U6kM56CGxdvBiNRfPLoMFnMddCQqXYJs
JZJHfwBnLQxFwbkZS0idkSWLf8AUKbB0lVWQe4+F0M1CeOj8YimmQIDAQAB"
}
}
}
Actual result:
--
array(1) {
[0] =>
array(6) {
'host' =>
string(36) "20120806._domainkey.googlegroups.com"
'class' =>
string(2) "IN"
'ttl' =>
int(4502)
'type' =>
string(3) "TXT"
'txt' =>
string(402) "k=rsa;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzb2fhKQxJYmlF+PNnOExrd8kRMlV2b/GBb
1mw4vpTGDVS8wD+6k8TEXSSsaS2B4uOrOfKBWBb6lMVbVmi/zy3Jc+YP5XkEt09UtXm4HWeAqgu0arqC
mjH6yhbUGlPipIqV\000QMmWy5jnWJsHioAAN8G5S5t5qrCRzxv7ntDOOUhwEPCIIrfncOgBzF4XdJPi
uanUNOX5Jw5Q2H3wcOmBTKQ3t0ETvPYK/cqpe7rJ+4L06+QKE2kk/WDuHuxtSZbZUo2U6kM56CGxdvBi
NRfPLoMFnMddCQqXYJsJZJHfwBnLQxFwbkZS0idkSWLf8AUKbB0lVWQe4+F0M1CeOj8YimmQIDAQAB"
'entries' =>
array(2) {
[0] =>
string(183) "k=rsa;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzb2fhKQxJYmlF+PNnOExrd8kRMlV2b/GBb
1mw4vpTGDVS8wD+6k8TEXSSsaS2B4uOrOfKBWBb6lMVbVmi/zy3Jc+YP5XkEt09UtXm4HWeAqgu0arqC
mjH6yhbUGlPipIqV"
[1] =>
string(218)
"QMmWy5jnWJsHioAAN8G5S5t5qrCRzxv7ntDOOUhwEPCIIrfncOgBzF4XdJPiuanUNOX5Jw5Q2H3wcOm
BTKQ3t0ETvPYK/cqpe7rJ+4L06+QKE2kk/WDuHuxtSZbZUo2U6kM56CGxdvBiNRfPLoMFnMddCQqXYJs
JZJHfwBnLQxFwbkZS0idkSWLf8AUKbB0lVWQe4+F0M1CeOj8YimmQIDAQAB"
}
}
}
--
Edit bug report at https://bugs.php.net/bug.php?id=65478&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65478&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65478&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65478&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id
Bug #65478 [Opn]: Multi-string DNS records obtained with dns_get_record contain nulls
Edit report at https://bugs.php.net/bug.php?id=65478&edit=1
ID: 65478
User updated by:marcus at synchromedia dot co dot uk
Reported by:marcus at synchromedia dot co dot uk
Summary:Multi-string DNS records obtained with
dns_get_record contain nulls
Status: Open
Type: Bug
Package:Network related
Operating System: OS X
PHP Version:5.4.18
Block user comment: N
Private report: N
New Comment:
I've been playing with this some more and discovered it's not quite consistent.
The concat character seems not to be always null - I've also seen '/' and 'a'.
I've found a more reliable workaround is to implode the 'entries' array and
ignore
the txt response.
Previous Comments:
----
[2013-08-19 16:53:44] marcus at synchromedia dot co dot uk
Description:
RFC4408 (SPF records in DNS) http://www.ietf.org/rfc/rfc4408.txt section 3.1.3
mentions the likely use of RFC1035's provision to allow a DNS record to contain
more
than one string. Specifically it says:
For example:
IN TXT "v=spf1 first" "second string..."
MUST be treated as equivalent to
IN TXT "v=spf1 firstsecond string..."
PHP's dns_get_record function does NOT work this way - it concatenates the
strings,
but inserts a null (\0) character between them, so in this example it would
produce
this string:
IN TXT "v=spf1 first\0second string..."
This is enough to break things like DKIM. The example code uses the DKIM key
for
google groups.
Notice that the string length in the actual result is off by one: the two
entries
are 183 and 218 chars, which should give 401 when concatenated, but there are
402
chars in the result. The '\0' is visible in this result, but in some
circumstances
it may not be visible. I've seen this behaviour on all platforms (OS X, Linux)
and
versions (5.3, 5.4) I've tried.
A workaround is to strip the null from the resource record:
$rr = str_replace("\0", '', $rr);
The returned value from the dns_get_record includes the original separate
strings
under the 'entries' key, so there's no benefit in keeping the nulls for the
purpose
of being able to separate the strings.
This bug is related to bug #54821, but is not a dupe of it.
Test script:
---
var_dump(dns_get_record("20120806._domainkey.googlegroups.com", DNS_TXT));
Expected result:
array(1) {
[0] =>
array(6) {
'host' =>
string(36) "20120806._domainkey.googlegroups.com"
'class' =>
string(2) "IN"
'ttl' =>
int(4502)
'type' =>
string(3) "TXT"
'txt' =>
string(401) "k=rsa;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzb2fhKQxJYmlF+PNnOExrd8kRMlV2b/GBb
1mw4vpTGDVS8wD+6k8TEXSSsaS2B4uOrOfKBWBb6lMVbVmi/zy3Jc+YP5XkEt09UtXm4HWeAqgu0arqC
mjH6yhbUGlPipIqV00QMmWy5jnWJsHioAAN8G5S5t5qrCRzxv7ntDOOUhwEPCIIrfncOgBzF4XdJPiua
nUNOX5Jw5Q2H3wcOmBTKQ3t0ETvPYK/cqpe7rJ+4L06+QKE2kk/WDuHuxtSZbZUo2U6kM56CGxdvBiNR
fPLoMFnMddCQqXYJsJZJHfwBnLQxFwbkZS0idkSWLf8AUKbB0lVWQe4+F0M1CeOj8YimmQIDAQAB"
'entries' =>
array(2) {
[0] =>
string(183) "k=rsa;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzb2fhKQxJYmlF+PNnOExrd8kRMlV2b/GBb
1mw4vpTGDVS8wD+6k8TEXSSsaS2B4uOrOfKBWBb6lMVbVmi/zy3Jc+YP5XkEt09UtXm4HWeAqgu0arqC
mjH6yhbUGlPipIqV"
[1] =>
string(218)
"QMmWy5jnWJsHioAAN8G5S5t5qrCRzxv7ntDOOUhwEPCIIrfncOgBzF4XdJPiuanUNOX5Jw5Q2H3wcOm
BTKQ3t0ETvPYK/cqpe7rJ+4L06+QKE2kk/WDuHuxtSZbZUo2U6kM56CGxdvBiNRfPLoMFnMddCQqXYJs
JZJHfwBnLQxFwbkZS0idkSWLf8AUKbB0lVWQe4+F0M1CeOj8YimmQIDAQAB"
}
}
}
Actual result:
--
array(1) {
[0] =>
array(6) {
'host' =>
string(36) "20120806._domainkey.googlegroups.com"
'class' =>
string(2) "IN"
'ttl' =>
int(4502)
'type' =>
string(3) "TXT"
'txt' =>
string(402) "k=rsa;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzb2fhKQxJYmlF+PNnOExrd8kRMlV2b/GBb
1mw4vpTGDVS8wD+6k8TEXSSsaS2B4uOrOfKBWBb6lMVbVmi/zy3Jc+YP5XkEt09UtXm4HWeAqgu0arqC
mjH6yhbUGlPipIqV\000QMmWy5jnWJsHioAAN8G5S5t5qrCRzxv7ntDOOUhwEPCIIrfncOgBzF4XdJPi
uanUNOX5Jw5Q2H3wcOmBTKQ3t0ETvPYK/cqpe7rJ+4L06+QKE2kk/WDuHuxtSZbZUo2U6kM56CGxdvBi
NRfPLoMFnMddCQqXYJsJZJHfwBnLQxFwbkZS0idkSWLf8AUKbB0lVWQe4+F0M1CeOj8YimmQIDAQAB"
'entries' =>
array(2) {
[0] =>
string(183) "k=rsa;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzb2fhKQxJYmlF+PNnOExrd8kRMlV2b/GBb
1mw4vpTGDVS8wD+6k8TEXSSsaS2B4uOrO
#49298 [NEW]: mysqli_show_warnings isn't much use
From: marcus at synchromedia dot co dot uk
Operating system:
PHP version: 5.3.0
PHP Bug Type: MySQLi related
Bug description: mysqli_show_warnings isn't much use
Description:
mysqli_get_warnings only ever returns a single warning, even if more
than one is available.
Though its name implies a plural response, it doesn't deliver one.
Reproduce code:
---
Do this in a mysql CLI:
CREATE TABLE `blah` (
`x` varchar(100) NOT NULL,
`y` varchar(100) NOT NULL,
`z` varchar(100) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
INSERT INTO blah SET z = '1';
Query OK, 1 row affected, 2 warnings (0.00 sec)
mysql> show warnings;
+-+--++
| Level | Code | Message|
+-+--++
| Warning | 1364 | Field 'x' doesn't have a default value |
| Warning | 1364 | Field 'y' doesn't have a default value |
+-+--++
Now do the same insert from PHP then call mysqli_get_warnings()
(approximate code):
mysqli_query($db, "INSERT INTO blah SET z = '1'");
$a = mysqli_get_warnings($db);
var_dump($a);
Expected result:
I'd want something like this:
array (2) {
object(mysqli_warning)#4 (3) {
["message"]=>
string(38) "Field 'x' doesn't have a default value"
["sqlstate"]=>
string(5) "HY000"
["errno"]=>
int(1364)
},
object(mysqli_warning)#5 (3) {
["message"]=>
string(38) "Field 'y' doesn't have a default value"
["sqlstate"]=>
string(5) "HY000"
["errno"]=>
int(1364)
}
}
Actual result:
--
object(mysqli_warning)#4 (3) {
["message"]=>
string(38) "Field 'x' doesn't have a default value"
["sqlstate"]=>
string(5) "HY000"
["errno"]=>
int(1364)
}
--
Edit bug report at http://bugs.php.net/?id=49298&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49298&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49298&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49298&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49298&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49298&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49298&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49298&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49298&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49298&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49298&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49298&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49298&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49298&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49298&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49298&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49298&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49298&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49298&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49298&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49298&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49298&r=mysqlcfg
#49298 [Opn]: mysqli_get_warnings isn't much use
ID: 49298
User updated by: marcus at synchromedia dot co dot uk
-Summary: mysqli_show_warnings isn't much use
Reported By: marcus at synchromedia dot co dot uk
Status: Open
Bug Type:MySQLi related
PHP Version: 5.3.0
New Comment:
Sorry, misnamed function in title
Previous Comments:
[2009-08-19 14:15:26] marcus at synchromedia dot co dot uk
Description:
mysqli_get_warnings only ever returns a single warning, even if more
than one is available.
Though its name implies a plural response, it doesn't deliver one.
Reproduce code:
---
Do this in a mysql CLI:
CREATE TABLE `blah` (
`x` varchar(100) NOT NULL,
`y` varchar(100) NOT NULL,
`z` varchar(100) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
INSERT INTO blah SET z = '1';
Query OK, 1 row affected, 2 warnings (0.00 sec)
mysql> show warnings;
+-+--++
| Level | Code | Message|
+-+--++
| Warning | 1364 | Field 'x' doesn't have a default value |
| Warning | 1364 | Field 'y' doesn't have a default value |
+-+--++
Now do the same insert from PHP then call mysqli_get_warnings()
(approximate code):
mysqli_query($db, "INSERT INTO blah SET z = '1'");
$a = mysqli_get_warnings($db);
var_dump($a);
Expected result:
I'd want something like this:
array (2) {
object(mysqli_warning)#4 (3) {
["message"]=>
string(38) "Field 'x' doesn't have a default value"
["sqlstate"]=>
string(5) "HY000"
["errno"]=>
int(1364)
},
object(mysqli_warning)#5 (3) {
["message"]=>
string(38) "Field 'y' doesn't have a default value"
["sqlstate"]=>
string(5) "HY000"
["errno"]=>
int(1364)
}
}
Actual result:
--
object(mysqli_warning)#4 (3) {
["message"]=>
string(38) "Field 'x' doesn't have a default value"
["sqlstate"]=>
string(5) "HY000"
["errno"]=>
int(1364)
}
--
Edit this bug report at http://bugs.php.net/?id=49298&edit=1
#49298 [Opn]: mysqli_get_warnings isn't much use
ID: 49298
User updated by: marcus at synchromedia dot co dot uk
Reported By: marcus at synchromedia dot co dot uk
Status: Open
Bug Type:MySQLi related
PHP Version: 5.3.0
New Comment:
I've discovered that the mysqli_warning class has a next() method that
retrieves the next warning in the instance properties. It can be used
like this:
$r = mysqli_query($db, 'INSERT INTO blah SET z = '1');
if (mysqli_warning_count($db)) {
$e = mysqli_get_warnings($db);
do {
echo "Warning: $e->errno: $e->message\n";
} while ($e->next());
}
I think this is the first time I've ever needed a bottom-tested loop!
This looks like half-baked implementation of a traversable interface -
could it be finished off?
Overall I guess this amounts to a documentation problem, so I've added
notes to the appropriate page too.
Previous Comments:
--------
[2009-08-19 19:26:28] marcus at synchromedia dot co dot uk
Sorry, misnamed function in title
--------
[2009-08-19 14:15:26] marcus at synchromedia dot co dot uk
Description:
mysqli_get_warnings only ever returns a single warning, even if more
than one is available.
Though its name implies a plural response, it doesn't deliver one.
Reproduce code:
---
Do this in a mysql CLI:
CREATE TABLE `blah` (
`x` varchar(100) NOT NULL,
`y` varchar(100) NOT NULL,
`z` varchar(100) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
INSERT INTO blah SET z = '1';
Query OK, 1 row affected, 2 warnings (0.00 sec)
mysql> show warnings;
+-+--++
| Level | Code | Message|
+-+--++
| Warning | 1364 | Field 'x' doesn't have a default value |
| Warning | 1364 | Field 'y' doesn't have a default value |
+-+--++
Now do the same insert from PHP then call mysqli_get_warnings()
(approximate code):
mysqli_query($db, "INSERT INTO blah SET z = '1'");
$a = mysqli_get_warnings($db);
var_dump($a);
Expected result:
I'd want something like this:
array (2) {
object(mysqli_warning)#4 (3) {
["message"]=>
string(38) "Field 'x' doesn't have a default value"
["sqlstate"]=>
string(5) "HY000"
["errno"]=>
int(1364)
},
object(mysqli_warning)#5 (3) {
["message"]=>
string(38) "Field 'y' doesn't have a default value"
["sqlstate"]=>
string(5) "HY000"
["errno"]=>
int(1364)
}
}
Actual result:
--
object(mysqli_warning)#4 (3) {
["message"]=>
string(38) "Field 'x' doesn't have a default value"
["sqlstate"]=>
string(5) "HY000"
["errno"]=>
int(1364)
}
--
Edit this bug report at http://bugs.php.net/?id=49298&edit=1
#43230 [Com]: The MSI Installer crashes when trying to install
ID: 43230 Comment by: kempe dot marcus at gmail dot com Reported By: pamcallaway at pobox dot com Status: Open Bug Type: Unknown/Other Function Operating System: Win XP, SP2 PHP Version: 5.2.5 New Comment: I have the same problem, using Windows Vista Ultimate. I also tried the snapshot installers for both version 5.2 and 5.3 and experience the exact same error (2878). Previous Comments: [2007-11-09 22:03:29] pamcallaway at pobox dot com Description: Hi, I downloaded the PHP 5.2.5 MSI package, and it crashes when I try to Install it. It get to the directory selection page, and after you pick where to install it and the click next, it crashes. I was putting in C:\Program Files\PHP\. I click next and I get this error: PHP 5.2.5 Setup The installer has encountered and unexpected error installing this package. This may indicate a problem with this package. The error code is 2878. I tried all four servers in the US and still got this message. I will try the ZIP file next, but the MSI is definately not working on my system. Reproduce code: --- Run the installer. Expected result: I expected to have it successfully installed. Actual result: -- It gave me that error message: PHP 5.2.5 Setup The installer has encountered and unexpected error installing this package. This may indicate a problem with this package. The error code is 2878. -- Edit this bug report at http://bugs.php.net/?id=43230&edit=1
#43105 [Com]: PHP seems to fail to close open files.
ID: 43105 Comment by: marcus dot mueller at grintsch dot com Reported By: ian at onlineloop dot com Status: Assigned Bug Type: Apache2 related Operating System: Solaris 10 PHP Version: 5.2.5RC2-dev Assigned To: ab5602 New Comment: I doubt this is an Apache issue since we're experiencing the same symptons as hwallenstone at gmx dot here on two debian linux boxes, one using the 64bit version of Apache's httpd 2.2.4, the other using the 32bit version of httpd 2.0.59. httpd processes seem to hang i.e. they don't close the connection (telling from /server-status) resulting in the issues mentioned above. I first noticed this behaviour when switching from PHP 5.2.3 to PHP 5.2.4, both self-compiled using the same configure options. PHP 5.2.3, unlike 5.2.4 and 5.2.5, does not expose this behaviour. I hope this info might narrow down your search path a little bit. Previous Comments: [2007-11-25 14:21:58] hwallenstone at gmx dot de I think we have the same problem here. I have updated one server of a cluster of busy servers from a patched 5.2.1 to 5.2.5 . The number of apache processes is growing and as a consequence of this, the number of open files increases. We have about 50 processes running on average machines; on the 5.2.5-one the number constantly grows until it reaches my MaxClients Limit. Trying to stop apache, I get hundreds of entries like [Sun Nov 25 14:14:55 2007] [error] could not make child process 28546 exit, attempting to continue anyway This problem **definitely** has come with the upgrade from 5.2.1 to 5.2.5. Nothing else was changed. So it doesn't look like this is a old apache bug. [2007-11-20 09:40:33] [EMAIL PROTECTED] IIRC, this is actually an Apache bug. PHP is not the only module which suffers as 3rd party of it.. [2007-11-12 20:52:58] ian at onlineloop dot com Hi, I don't want to post the attahced file to the bug report as this may expose more information that I like about our web server. It is a pfiles output from the apache processes. I will send the file to you directly in an email. The exact situation is difficult to reproduce, and happened most frequently when the server was under load. We are typically handling about 100-120 requests per second, and under PHP 5.1.6 (we are back on it now), there was usually between 500 and 1000 open files at any one time between the apache processes. The symptom of the problem - system error messages, masses of open files, not being able to execute ssmtp and not being able to open files, also generally exists for just a couple of seconds, then goes away again. The total memory usage of apache climbs constantly, usually hitting 6-8Gb within 24 hours of an apache restart, and continuing to climb if apache is not restarted. After about 36 hours, the ram usage is over 10Gb, at which point I restart the server as we need it to be available. Since running 5.1.6 again (one week), the memory usage is constantly around 1.5-2Gb and there are no problems from 5.2.5rc-x. I fear reproducing this will be difficult for you. ssmtp is generally able to send mails, just occasionally it is hit by this problem. Apache also has problems opening other files under this condition, apparently mainly for writing. I have tried on the command line to send mails with ssmtp when the error messages start coming out, however that worked and the test mails came in. "cat"ing files into another file, and things like this also worked. The problem of not being able to open files also occurs when not trying to send mails, as such my impression the problem is more general than just being connected with mail function. I did put sendmail in briefly today to see what happened, the problem still occured. A restart in the middle of the day for the apache process is not an option here as the service needs to be available. I can only make changes to the system between 2 and 4am. I will do what I can to help pinpoint this problem, please however understand the restrictions I have as I do this on a productive system. [2007-11-11 19:18:31] [EMAIL PROTECTED] 1) What file(s) are being held open? (lsof/ptree may help). 2) Is 'ssmtp -t' successfully opening, delivering the email and closing it's own network connections under this condition? Every open network connection requires 2 file descriptors. 3) Does this happen without sending mail()? 4) Does this happen with other delivery programs such as 'sendmail -t'? Thanks, -Rob [2007-11-1
#43105 [Com]: PHP seems to fail to close open files.
ID: 43105 Comment by: marcus dot mueller at grintsch dot com Reported By: ian at onlineloop dot com Status: Assigned Bug Type: Apache2 related Operating System: Solaris 10 PHP Version: 5.2.5RC2-dev Assigned To: ab5602 New Comment: As I stated above we have this issue on two Linux boxes with self-compiled PHP binaries. These were compiled using gcc! Previous Comments: [2007-11-28 16:36:24] ian at onlineloop dot com Coming back to the bug report here now. In the meantime some private emails were exchanged, including a pfiles output from Solaris showing that PHP had over 210,000 open files after 24 hours running on our servers. Within 48 hours (we let it go this far onyl once), apache/php eats around 12Gb of RAM and has between 170 and 220 child processes with over 230,000 open files. Under 5.1.6 the usage is more around 1.5-2Gb ram, and 30-70 child processes, with rarely more than 100 open files (only when we are really under load do we get to more than about 800 open files at any one time). A small patch was sent to me to try, however this has changed nothing. I was also asked to compile with gcc if possible, however this is not feasible as too many other things would have to be recompiled. Besides, we specifically went away from gcc because everything we had that was compiled with gcc was seg faulting all the time, however with the Sun Studio compiler suite, everything is stable. I seriously doubt this is an apache bug, why were things working with previous versions of PHP, and not this one? [2007-11-28 15:02:11] grknight at iwon dot com I am also experiencing this issue. We are running Apache 2.2.3 on Redhat EL 3 and recently tried to update to 5.2.5 from 5.2.3 to fix the security issues. The moment 5.2.5 was activated, connections failed to close in apache and resulted in hung processes. I also tried 5.2.4 with the same results. No configurations were changed nor PHP scripts. Something changed in the PHP processes that prevents the apxs2handler from exiting between 5.2.3 and 5.2.4. Configs available on request. [2007-11-26 14:08:48] marcus dot mueller at grintsch dot com I doubt this is an Apache issue since we're experiencing the same symptons as hwallenstone at gmx dot here on two debian linux boxes, one using the 64bit version of Apache's httpd 2.2.4, the other using the 32bit version of httpd 2.0.59. httpd processes seem to hang i.e. they don't close the connection (telling from /server-status) resulting in the issues mentioned above. I first noticed this behaviour when switching from PHP 5.2.3 to PHP 5.2.4, both self-compiled using the same configure options. PHP 5.2.3, unlike 5.2.4 and 5.2.5, does not expose this behaviour. I hope this info might narrow down your search path a little bit. [2007-11-25 14:21:58] hwallenstone at gmx dot de I think we have the same problem here. I have updated one server of a cluster of busy servers from a patched 5.2.1 to 5.2.5 . The number of apache processes is growing and as a consequence of this, the number of open files increases. We have about 50 processes running on average machines; on the 5.2.5-one the number constantly grows until it reaches my MaxClients Limit. Trying to stop apache, I get hundreds of entries like [Sun Nov 25 14:14:55 2007] [error] could not make child process 28546 exit, attempting to continue anyway This problem **definitely** has come with the upgrade from 5.2.1 to 5.2.5. Nothing else was changed. So it doesn't look like this is a old apache bug. [2007-11-20 09:40:33] [EMAIL PROTECTED] IIRC, this is actually an Apache bug. PHP is not the only module which suffers as 3rd party of it.. 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/43105 -- Edit this bug report at http://bugs.php.net/?id=43105&edit=1
#31050 [Com]: SOAP class will not parse WSDL file located on a secure HTTPS connection
ID: 31050
Comment by: marcus dot uy at virtualthinking dot com
Reported By: dylanwoster at mac dot com
Status: No Feedback
Bug Type: SOAP related
Operating System: Mac OS X 10.3.6
PHP Version: 5.0.2
Assigned To: dmitry
New Comment:
Hi,
Having similar problem on Windows XP Pro:
Apache 2.2.8
PHP 5.2.5
OpenSSL 0.9.8g
In my case the connectiion works once, then fails on the next
connection attempt. I then have to restart apache because the
soapserver becomes completely unresponsive.
Previous Comments:
[2008-01-03 13:08:19] php at eflow dot dk
I have the problem too, on Gentoo Linux.
Apache 2.2.6
PHP 5.2.5
OpenSSL 0.9.8g
Configuration:
'./configure' '--prefix=/usr/lib/php5' '--host=i686-pc-linux-gnu'
'--mandir=/usr/lib/php5/man' '--infodir=/usr/lib/php5/info'
'--sysconfdir=/etc' '--cache-file=./config.cache' '--disable-cli'
'--with-apxs2=/usr/sbin/apxs2'
'--with-config-file-path=/etc/php/apache2-php5'
'--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active'
'--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar'
'--with-curl' '--with-curlwrappers' '--disable-dbase' '--disable-exif'
'--without-fbsql' '--without-fdftk' '--disable-filter' '--disable-ftp'
'--with-gettext' '--without-gmp' '--disable-hash' '--disable-json'
'--without-kerberos' '--enable-mbstring' '--with-mcrypt'
'--without-mhash' '--without-msql' '--without-mssql' '--with-ncurses'
'--with-openssl' '--with-openssl-dir=/usr' '--disable-pcntl'
'--disable-pdo' '--without-pgsql' '--disable-posix' '--with-pspell'
'--without-recode' '--disable-shmop' '--without-snmp' '--enable-soap'
'--disable-sockets' '--without-sybase' '--without-sybase-ct'
'--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm'
'--without-tidy' '--disable-wddx' '--with-xmlrpc' '--with-xsl'
'--enable-zip' '--with-zlib' '--disable-debug' '--enable-dba'
'--without-cdb' '--with-db4' '--without-flatfile' '--with-gdbm'
'--without-inifile' '--without-qdbm' '--with-freetype-dir=/usr'
'--with-t1lib=/usr' '--disable-gd-jis-conv' '--with-jpeg-dir=/usr'
'--with-png-dir=/usr' '--without-xpm-dir' '--with-gd' '--with-ldap'
'--with-ldap-sasl' '--with-mysql=/usr'
'--with-mysql-sock=/var/run/mysqld/mysqld.sock'
'--with-mysqli=/usr/bin/mysql_config' '--with-readline'
'--without-libedit' '--without-mm' '--with-sqlite=/usr'
'--enable-sqlite-utf8'
[2007-05-05 08:25:38] john at soundreal dot co dot uk
I'm getting the same problem Mac OS X 10.4.9 PHP 5.2.1
$SoapClient=new SoapClient('https://api.foo.com/fooService.wsdl'
,array("connection_timeout"=>5));
'./configure' '--prefix=/Library/PHP5' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--sysconfdir=/etc' '--with-zlib'
'--with-xml' '--with-zlib-dir=/usr' '--with-openssl' '--enable-exif'
'--enable-ftp' '--enable-mbstring' '--enable-mbregex' '--enable-sockets'
'--with-mysql=/usr/local/mysql'
'--with-mysqli=/usr/local/mysql/bin/mysql_config' '--with-apxs'
'--with-libjpeg' '--with-libtiff=/sw' '--with-libpng' '--with-gd'
'--with-gettext' '--enable-soap' '--with-curl'
[2007-04-19 02:47:58] kkallio at micorp dot com dot ve
Same problem on a modified Debian Sarge, PHP 5.2.0
'./configure' '--prefix=/usr' '--libexecdir=/usr/lib/php5.2.0/libexec'
'--datadir=/usr/share/php5.2.0' '--sysconfdir=/etc/php5.2.0'
'--includedir=/usr/include/php5.2.0'
'--with-config-file-path=/etc/php5.2.0' '--with-apxs2=/usr/bin/apxs2'
'--with-odbtp=/usr' '--with-kerberos' '--with-pcre-regex'
'--enable-versioning' '--enable-sigchild' '--enable-magic-quotes'
#45762 [Bgs]: Strange eval() behaviour
ID: 45762
User updated by: marcus dot mueller at grintsch dot com
Reported By: marcus dot mueller at grintsch dot com
Status: Bogus
Bug Type: *General Issues
Operating System: Linux 2.6.25-2-amd64 #1 SMP
PHP Version: 5.2.6
New Comment:
Thanks a lot for your response. I can see clearer now...
Previous Comments:
[2008-08-08 14:10:22] [EMAIL PROTECTED]
The parser currently has a stack size limit of 1.
AFAIK this means that the parser cannot handle more than this number of
tokens in the same expression.
If you need more you can change that by defining YYMAXDEPTH to a larger
number in zend_language_parser.y.
It is not eval() specific.
[2008-08-08 13:22:29] marcus dot mueller at grintsch dot com
Thank you for your quick reply.
> You have a parse error in your second block of code.
> eval('$foo='.$foo.' 1;var_dump($foo);');
>
> Essentially you have
> $foo = 9994! 1; var_dump($foo);
I beg to differ. Please look again.
There is no parse error in the second block.
$foo contains 9994 times the "!" followed by "1".
Please check again with the following code.
\n";
$bar = '$foo='.$foo.' 1;var_dump($foo);';
echo $bar."\n";
eval($bar);
?>
And as I mentioned before the example runs absolutely fine (no parse
rror, no memory exhausted error) when lowering 9994 to 9993.
[2008-08-08 13:09:24] [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. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
You have a parse error in your second block of code.
eval('$foo='.$foo.' 1;var_dump($foo);');
Essentially you have
$foo = 9994! 1; var_dump($foo);
[2008-08-08 12:59:02] marcus dot mueller at grintsch dot com
Description:
I'm not quite sure this is a bug, so if it isn't please excuse my
ignorance.
Running the script below on a produces a "PHP Parse error: memory
exhausted".
Lowering 9994 to 9993 doesn't expose this behaviour and produces the
expected result (well, "boolean false" oc).
>From the PHP manual: "PHP imposes no boundary on the size of a string;
the only limit is the available memory of the computer on which PHP is
running".
The box I'm running this on has 4GB.
Reproduce code:
---
Expected result:
int 9995
boolean true
Actual result:
--
int(9995)
Parse error: memory exhausted in not.php(10) : eval()'d code on line 1
--
Edit this bug report at http://bugs.php.net/?id=45762&edit=1
#45855 [NEW]: COM-Problem with GET/SET, using same method name (but with different arg count)
From: marcus dot kroschinsky at siemens dot com
Operating system: WinXP Prof. SP2
PHP version: 5.2.6
PHP Bug Type: COM related
Bug description: COM-Problem with GET/SET, using same method name (but with
different arg count)
Description:
The COM Application 'myApp' (some properitary inhouse product) throws
'com_exception' if a PHP5 script tries to execute a SET method of given
object. Other applications written in C/C++, Python and Excel VBS work
fine.
IDL of myApp:
[id(0x0038), propget] VARIANT DocumentParameterValue(BSTR
parameterName);
[id(0x0038), propput] voidDocumentParameterValue(BSTR
parameterName, VARIANT rhs);
Reproduce code:
---
DocumentParameterValue('project'); // get (ok
!)
$obj->DocumentParameterValue('project', strval('ZONK')); // set
(fails !)
?>
Expected result:
Output value of parameter 'project' and set it to string 'ZONK'.
Actual result:
--
First 2 lines execute ok, but the third line fails with following error:
Fatal error: Uncaught exception 'com_exception' with message 'Error
[0x8002000e] Invalid number of parameters.'
--
Edit bug report at http://bugs.php.net/?id=45855&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45855&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45855&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45855&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45855&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45855&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45855&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45855&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45855&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45855&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45855&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45855&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45855&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45855&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45855&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45855&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45855&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45855&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45855&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45855&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45855&r=mysqlcfg
#46195 [NEW]: odbc_prepare use SQLNumResultCols
From: marcus dot kunze at syntela dot de
Operating system: Windows
PHP version: 5.2.6
PHP Bug Type: ODBC related
Bug description: odbc_prepare use SQLNumResultCols
Description:
odbc_prepare use SQLNumResultCols to get the count and description of den
result column. The problem is a resultset the is depends on the paremeter
or a multiple resultset with differens column.
SQLNumResultCols return only the correct result after SQLExecute is call!
In odbc_execute is the same code, the code in odbc_prepare is needless.
Testet Solution on Windows, SQL Server 2005
php_odbc.c[908]
result->numcols = 0;
/*
SQLNumResultCols(result->stmt, &(result->numcols));
if (result->numcols > 0) {
if (!odbc_bindcols(result TSRMLS_CC)) {
efree(result);
RETURN_FALSE;
}
} else {
result->values = NULL;
}
*/
zend_list_addref(conn->id);
Reproduce code:
---
$connstr = "Driver={SQL Server};SERVER=localhost;DATABASE=master";
$sql = "select 1 as col1 \n".
"select 2 as col2, 3 as col3 \n".
"select 4 as col4, 5 as col5, 6 as col6";
$conn = odbc_connect($connstr, $username, $password);
$result = odbc_prepare($conn, $sql );
odbc_execute( $result );
do {
odbc_result_all( $result );
} while ( odbc_next_result( $result ) );
Expected result:
col1
1
col2col3
2 3
col4col5col6
4 5 6
Actual result:
--
col4col5col6
1 ÷xÈøx4[úøx÷x4[ú
col2col3
2 3
col4col5col6
4 5 6
--
Edit bug report at http://bugs.php.net/?id=46195&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46195&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46195&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46195&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=46195&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=46195&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=46195&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=46195&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=46195&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=46195&r=support
Expected behavior:http://bugs.php.net/fix.php?id=46195&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46195&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46195&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=46195&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46195&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=46195&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=46195&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=46195&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=46195&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=46195&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=46195&r=mysqlcfg
#46195 [Asn]: odbc_prepare use SQLNumResultCols
ID: 46195
User updated by: marcus dot kunze at syntela dot de
Reported By: marcus dot kunze at syntela dot de
Status: Assigned
Bug Type: ODBC related
Operating System: Windows
PHP Version: 5.2.6
Assigned To: iodbc
New Comment:
Hallo,
if the result depends on parameter from Execute, SQLNumResultCols can
not return die correct result.
Sample:
create procedure test ( @param int )
as
if @param = 1 select 1 as col1
else if @param = 2 select 2 as col2
else if @param = 3 select 3 as col3
else select 'other' as other
odbc_prepare('exec test(?)');
bevor not execute with the paramter vor ?, SQLNumResultCols can not
have the name vor the column.
Previous Comments:
[2008-11-07 12:03:43] [EMAIL PROTECTED]
Strictly speaking from an ODBC API point of view, you can call
SQLNumResultCols directly after SQLPrepare, but not all
drivers/databases evaluate the SQL statement at prepare time and
therefor can only return this information after SQLExecute.
I am working on a patch that will resolve calling SQLNumResultCols and
more importantly the odbc_bindcols call multiple times, without the
possibility of breaking backward compatibility on existing apps.
[2008-09-29 12:09:01] marcus dot kunze at syntela dot de
Description:
odbc_prepare use SQLNumResultCols to get the count and description of
den result column. The problem is a resultset the is depends on the
paremeter or a multiple resultset with differens column.
SQLNumResultCols return only the correct result after SQLExecute is
call! In odbc_execute is the same code, the code in odbc_prepare is
needless.
Testet Solution on Windows, SQL Server 2005
php_odbc.c[908]
result->numcols = 0;
/*
SQLNumResultCols(result->stmt, &(result->numcols));
if (result->numcols > 0) {
if (!odbc_bindcols(result TSRMLS_CC)) {
efree(result);
RETURN_FALSE;
}
} else {
result->values = NULL;
}
*/
zend_list_addref(conn->id);
Reproduce code:
---
$connstr = "Driver={SQL Server};SERVER=localhost;DATABASE=master";
$sql = "select 1 as col1 \n".
"select 2 as col2, 3 as col3 \n".
"select 4 as col4, 5 as col5, 6 as col6";
$conn = odbc_connect($connstr, $username, $password);
$result = odbc_prepare($conn, $sql );
odbc_execute( $result );
do {
odbc_result_all( $result );
} while ( odbc_next_result( $result ) );
Expected result:
col1
1
col2col3
2 3
col4col5col6
4 5 6
Actual result:
--
col4col5col6
1 ÷xÈøx4[úøx÷x4[ú
col2col3
2 3
col4col5col6
4 5 6
--
Edit this bug report at http://bugs.php.net/?id=46195&edit=1
[PHP-BUG] Bug #51650 [NEW]: gzinflate return values don't match docs
From: Operating system: all PHP version: 5.3.2 Package: Zlib Related Bug Type: Bug Bug description:gzinflate return values don't match docs Description: gzinflate is supposed to return false if it tries to inflate something that's not valid deflated data. It does this on PHP 5.2, but returns an empty string in 5.3. This is either a docs problem or a BC break between 5.2 and 5.3. I can't find anything in bugs, docs, release notes or the 5.2 to 5.3 upgrade guide about this. Test script: --- Expected result: (I get this under PHP 5.2.4 on linux) string(3) "abc" PHP Warning: gzinflate(): buffer error in test.php on line 5 bool(false) Actual result: -- (I get this from PHP 5.3.2 built from MacPorts on OS X) string(3) "abc" string(0) "" -- Edit bug report at http://bugs.php.net/bug.php?id=51650&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51650&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51650&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51650&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51650&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51650&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51650&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51650&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51650&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51650&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51650&r=support Expected behavior: http://bugs.php.net/fix.php?id=51650&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51650&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51650&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51650&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51650&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51650&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51650&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51650&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51650&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51650&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51650&r=mysqlcfg
#50309 [NEW]: Add plain-text sanitizing to filter
From: marcus at synchromedia dot co dot uk Operating system: PHP version: 5.3.1 PHP Bug Type: Feature/Change Request Bug description: Add plain-text sanitizing to filter Description: While the FILTER_FLAG_STRIP_LOW and FILTER_FLAG_STRIP_HIGH flags used with FILTER_SANITIZE_STRING work fine, They are just a bit blunt to be useful in practice. A more normal application would be to remove any 'funny' characters from plain text, so for example to allow chars 9, 10, 13, 32-126. This could be called FILTER_FLAG_PLAIN_TEXT. While this could be done using regex, it's probably the most common use case, so deserves a dedicated filter flag. This could be flipped around and be called FILTER_FLAG_ALLOW_WHITESPACE, overriding STRIP_LOW to allow chars 9, 10, 13 through. Similarly, a very common need is to normalize line breaks to \n, \r\n or \r. -- Edit bug report at http://bugs.php.net/?id=50309&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50309&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50309&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50309&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50309&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50309&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50309&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50309&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50309&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50309&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50309&r=support Expected behavior: http://bugs.php.net/fix.php?id=50309&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50309&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50309&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50309&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50309&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50309&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50309&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50309&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50309&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50309&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50309&r=mysqlcfg
#44093 [Com]: ignore_user_abort() sometimes do not work !
ID: 44093
Comment by: marcus dot mueller at grintsch dot com
Reported By: max at tehnomir dot com dot ua
Status: No Feedback
Bug Type: *General Issues
Operating System: Linux 2.6.20.2
PHP Version: 5.2.5
New Comment:
I can confirm this bug still being reproducible in PHP 5.2.6 on Linux
2.6.24 and above. Any news?
Previous Comments:
[2008-04-26 13:50:13] pcdinh at gmail dot com
This bug remains still. I can reproduce it on PHP 5.2.5 and latest PHP
5.3dev (Windows XP SP2)
Maximum execution time of 60 seconds exceeded in
D:\webroot\bugs\44093.php
[2008-04-02 01:00:02] php-bugs at lists dot php dot net
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".
[2008-03-25 14:01:43] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2008-02-10 19:57:36] max at tehnomir dot com dot ua
Description:
Hello !
ignore_user_abort( false ) sometimes do not work !
In this example when I press STOP button in my browser script does not
stop. It runs till max_execution_time is reached.
Server: 1.3.39.
Reproduce code:
---
";
flush();
fwrite($fp, date('d.m.Y H:i:s')."\n");
sleep( 1 );
}
fclose( $fp );
?>
Expected result:
Script must stop execution.
Actual result:
--
Script runs till max_execution_time is reached.
--
Edit this bug report at http://bugs.php.net/?id=44093&edit=1
#45762 [NEW]: Strange eval() behaviour
From: marcus dot mueller at grintsch dot com Operating system: Linux gdev 2.6.25-2-amd64 #1 SMP PHP version: 5.2.6 PHP Bug Type: *General Issues Bug description: Strange eval() behaviour Description: I'm not quite sure this is a bug, so if it isn't please excuse my ignorance. Running the script below on a produces a "PHP Parse error: memory exhausted". Lowering 9994 to 9993 doesn't expose this behaviour and produces the expected result (well, "boolean false" oc). >From the PHP manual: "PHP imposes no boundary on the size of a string; the only limit is the available memory of the computer on which PHP is running". The box I'm running this on has 4GB. Reproduce code: --- Expected result: int 9995 boolean true Actual result: -- int(9995) Parse error: memory exhausted in not.php(10) : eval()'d code on line 1 -- Edit bug report at http://bugs.php.net/?id=45762&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45762&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45762&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45762&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45762&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45762&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45762&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45762&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45762&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45762&r=support Expected behavior:http://bugs.php.net/fix.php?id=45762&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45762&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45762&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45762&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45762&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45762&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45762&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45762&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45762&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45762&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45762&r=mysqlcfg
#45762 [Bgs]: Strange eval() behaviour
ID: 45762
User updated by: marcus dot mueller at grintsch dot com
Reported By: marcus dot mueller at grintsch dot com
Status: Bogus
Bug Type: *General Issues
-Operating System: Linux gdev 2.6.25-2-amd64 #1 SMP
+Operating System: Linux 2.6.25-2-amd64 #1 SMP
PHP Version: 5.2.6
New Comment:
Thank you for your quick reply.
> You have a parse error in your second block of code.
> eval('$foo='.$foo.' 1;var_dump($foo);');
>
> Essentially you have
> $foo = 9994! 1; var_dump($foo);
I beg to differ. Please look again.
There is no parse error in the second block.
$foo contains 9994 times the "!" followed by "1".
Please check again with the following code.
\n";
$bar = '$foo='.$foo.' 1;var_dump($foo);';
echo $bar."\n";
eval($bar);
?>
And as I mentioned before the example runs absolutely fine (no parse
rror, no memory exhausted error) when lowering 9994 to 9993.
Previous Comments:
[2008-08-08 13:09:24] [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. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
You have a parse error in your second block of code.
eval('$foo='.$foo.' 1;var_dump($foo);');
Essentially you have
$foo = 9994! 1; var_dump($foo);
[2008-08-08 12:59:02] marcus dot mueller at grintsch dot com
Description:
I'm not quite sure this is a bug, so if it isn't please excuse my
ignorance.
Running the script below on a produces a "PHP Parse error: memory
exhausted".
Lowering 9994 to 9993 doesn't expose this behaviour and produces the
expected result (well, "boolean false" oc).
>From the PHP manual: "PHP imposes no boundary on the size of a string;
the only limit is the available memory of the computer on which PHP is
running".
The box I'm running this on has 4GB.
Reproduce code:
---
Expected result:
int 9995
boolean true
Actual result:
--
int(9995)
Parse error: memory exhausted in not.php(10) : eval()'d code on line 1
--
Edit this bug report at http://bugs.php.net/?id=45762&edit=1
#34891 [NEW]: Checksum error on install-pear-nozlib.phar
From: marcus at synchromedia dot co dot uk Operating system: * PHP version: 5CVS-2005-10-17 (snap) PHP Bug Type: Compile Failure Bug description: Checksum error on install-pear-nozlib.phar Description: Configure and make work fine, but on make install, I get a checksum error on the downloaded install-pear-nozlib.phar file. I see it on both OS X and Linux. I still end up with a working PHP build, but a fresh pear installation would be broken. Reproduce code: --- As usual: ./configure make make install Actual result: -- Installing PEAR environment: /usr/share/pear/ --13:04:17-- http://pear.php.net/install-pear-nozlib.phar => `/home/mbointon/php5-200510171030/pear/ install-pear-nozlib.phar' Resolving pear.php.net... 216.92.131.66 Connecting to pear.php.net|216.92.131.66|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 3,321,897 (3.2M) [text/plain] 100%[>] 3,321,897583.00K/sETA 00:00 13:04:23 (566.75 KB/s) - `/home/mbointon/php5-200510171030/ pear/install-pear-nozlib.phar' saved [3321897/3321897] Fatal error: Error: phar "/home/mbointon/php5-200510171030/ pear/install-pear-nozlib.phar" Checksum error on entry "" in /home/mbointon/php5-200510171030/pear/install-pear- nozlib.phar on line 376 make[1]: *** [install-pear-installer] Error 255 make: *** [install-pear] Error 2 -- Edit bug report at http://bugs.php.net/?id=34891&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34891&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34891&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34891&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34891&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34891&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34891&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34891&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34891&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34891&r=support Expected behavior: http://bugs.php.net/fix.php?id=34891&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34891&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34891&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34891&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34891&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34891&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34891&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34891&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34891&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34891&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34891&r=mysqlcfg
#34542 [Com]: register_long_arrays causes $_SESSIONS vars to disappear
ID: 34542 Comment by: marcus at synchromedia dot co dot uk Reported By: marcus dot uy at virtualthinking dot com Status: No Feedback Bug Type: Session related Operating System: WinXP Pro PHP Version: 5.1.0RC1 New Comment: I think I'm seeing this same bug in 5.1.0RC4. I'm not getting exactly the same symptom, but it's close. I'm finding that session files are created no problem, but when I change values in $_SESSION, the changes are not saved, even if I use session_write_close(). I've set up a small test case that is storing and changing exactly what I'm doing in my project and it doesn't happen, so I don't think it's a problem with the contents of the session. I also wrote a test that stuffed 5000 strings into $_SESSION and that worked ok too. Like the original bug report, it all works fine if I leave register_long_arrays turned on, even though I'm not using them anywhere in my code, or in libraries that I'm using. What I would like to do is do a trace with xdebug and look at everything that involves sessions, but I can't at present because xdebug-cvs won't run under 5.1.0RC4. Previous Comments: [2005-09-27 01:00:03] php-bugs at lists dot php dot net 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". [2005-09-19 13:47:45] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , 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 to avoid embedding huge scripts into the report. ---- [2005-09-19 12:38:07] marcus dot uy at virtualthinking dot com Hi just tried it with the CVS versions to popinted me to. No dice. Same problem. After the session is created as a zero-length file and updating $_SESSION in the script does nothing to change this. The values are accessible during the first run, and when re-read on subsequent runs, understandably return an empty $_SESSION array. FYI, my application is split into a public http system and a private https system. The session sticks in the http session, but as noted earlier, the number of session values used is significantly less than after a user has logged in the https session. I allow the script to generate a new SID for the https session as I do not need to pass over the values, and it is here that the values do not stick. Both the http and https sites share an *indentical* code base so it's not a program error. Erm, to be honest the code I posted is cut down to allow for it to be a reasonable length. It incorporates the essentials of the problem, but perhaps not the full environment. It still needs the register_long_arrays to be "on" before it will work. [2005-09-18 22:07:55] [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 I can't reproduce this on either Linux or Windows. (using sessions with cookies, of course, passing session ids in the URL is not wise) ---- [2005-09-18 15:34:38] marcus dot uy at virtualthinking dot com Description: hi, I have read through some earlier bug posts regarding similar-ish in later versions of php4 and early versions of php5. I want to report that this bug persists in version 5.0.4, 5.0.5, as well as 5.1.0rc1 too. Setting "register_long_arrays=off" causes $_SESSION to break, but in a very unusual way. For some reason putting 4 or 5 small items in the sessions array is fine (which is why most tests can pass), but putting more data or more items in the sessions array prevents the data from being written to the session file. You get a zero-length file and the session fails. There is no error that faults or reports from this. I haven't really measured the "breaking point", but it is real and I can consistently reproduce it on my system (the code is way too long to post here). I note that php.ini doesn't seem to indicate the default status of this setting, but if "off" is the default value then this bug does not seem to affect linux versions of php. Turning &quo
#34542 [NoF->Opn]: register_long_arrays causes $_SESSIONS vars to disappear
ID: 34542 User updated by: marcus dot uy at virtualthinking dot com Reported By: marcus dot uy at virtualthinking dot com -Status: No Feedback +Status: Open Bug Type: Session related Operating System: WinXP Pro PHP Version: 5.1.0RC1 New Comment: Hi, I think somebody else has a related problem with a workable test case. Previous Comments: [2005-11-03 09:36:44] marcus at synchromedia dot co dot uk I think I'm seeing this same bug in 5.1.0RC4. I'm not getting exactly the same symptom, but it's close. I'm finding that session files are created no problem, but when I change values in $_SESSION, the changes are not saved, even if I use session_write_close(). I've set up a small test case that is storing and changing exactly what I'm doing in my project and it doesn't happen, so I don't think it's a problem with the contents of the session. I also wrote a test that stuffed 5000 strings into $_SESSION and that worked ok too. Like the original bug report, it all works fine if I leave register_long_arrays turned on, even though I'm not using them anywhere in my code, or in libraries that I'm using. What I would like to do is do a trace with xdebug and look at everything that involves sessions, but I can't at present because xdebug-cvs won't run under 5.1.0RC4. [2005-09-27 01:00:03] php-bugs at lists dot php dot net 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". [2005-09-19 13:47:45] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , 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 to avoid embedding huge scripts into the report. ---- [2005-09-19 12:38:07] marcus dot uy at virtualthinking dot com Hi just tried it with the CVS versions to popinted me to. No dice. Same problem. After the session is created as a zero-length file and updating $_SESSION in the script does nothing to change this. The values are accessible during the first run, and when re-read on subsequent runs, understandably return an empty $_SESSION array. FYI, my application is split into a public http system and a private https system. The session sticks in the http session, but as noted earlier, the number of session values used is significantly less than after a user has logged in the https session. I allow the script to generate a new SID for the https session as I do not need to pass over the values, and it is here that the values do not stick. Both the http and https sites share an *indentical* code base so it's not a program error. Erm, to be honest the code I posted is cut down to allow for it to be a reasonable length. It incorporates the essentials of the problem, but perhaps not the full environment. It still needs the register_long_arrays to be "on" before it will work. [2005-09-18 22:07:55] [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 I can't reproduce this on either Linux or Windows. (using sessions with cookies, of course, passing session ids in the URL is not wise) 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/34542 -- Edit this bug report at http://bugs.php.net/?id=34542&edit=1
#34542 [NoF->Opn]: register_long_arrays causes $_SESSIONS vars to disappear
ID: 34542
User updated by: marcus dot uy at virtualthinking dot com
Reported By: marcus dot uy at virtualthinking dot com
-Status: No Feedback
+Status: Open
Bug Type: Session related
Operating System: WinXP Pro
PHP Version: 5.1.0RC4
New Comment:
There have been test cases posted for this bug. Please review.
Previous Comments:
[2005-11-11 01:00:24] php-bugs at lists dot php dot net
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".
[2005-11-10 17:06:42] uap-php at cheeky dot org
Hello,
Having similar problems on 5.0.5. Basically all I can say is, if you
have register_long_arrays=Off in your ini file, $_SESSION stuff does
work, apart from when you iterate over it. Run the code below, with
register_long_arrays=On and then with it off. The final result will be
different. It seems that if you iterate over $_SESSION, the
session_save handler does not get called and the session data is not
saved.
Hope this sheds some light on the problem,
$value){
$_SESSION[$key]='';
}
$step='empty session "search_test"';
$refresh='';
break;
case 1:
$step='nothing set in this step';
$refresh='';
break;
default:
$_SESSION['search_test'] = 'Hello!';
$step='set session "search_test" to "Hello"';
$refresh='';
}
?>
Session Data:';
print_r($_SESSION);
echo '';
?>
[2005-11-09 23:43:51] mail at lenzw dot de
see Bug #33811 for a reproduction code.
[2005-11-03 22:10:18] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
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 to avoid embedding huge scripts into the report.
[2005-11-03 16:47:25] marcus dot uy at virtualthinking dot com
Hi, I think somebody else has a related problem with a workable test
case.
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/34542
--
Edit this bug report at http://bugs.php.net/?id=34542&edit=1
#34542 [NoF->Opn]: register_long_arrays causes $_SESSIONS vars to disappear
ID: 34542
User updated by: marcus dot uy at virtualthinking dot com
Reported By: marcus dot uy at virtualthinking dot com
-Status: No Feedback
+Status: Open
Bug Type: Session related
-Operating System: WinXP Pro
+Operating System: ALL
PHP Version: 5.1.0RC4, 5.2.0
New Comment:
Hi,
I have resolved this issue. It's not that the long arrays that is
broken, but that $_SESSION has some unexpected behaviours.
It turns out that $_SESSION is NOT really a normal array. If you
assign a bunch of values to $_SESSION as an array, e.g.:
$_SESSION = array ("value1", "value2", "value3");
It destroy's the "magic" of $_SESSION and session becomes a standard
array (that vanishes on script exit), thus it does not save settings as
expected.
There have been some similar complaints in other bug reports. The
discussion breaks down into two camps:
1. This is a feature, so don't allocate the array
2. This fails the test of "least surprise", behaviour should be
"corrected"
Ah well, it works now, and I know why, so that's what matters.
Previous Comments:
[2006-12-13 01:00:00] php-bugs at lists dot php dot net
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".
[2006-12-05 15:37:58] [EMAIL PROTECTED]
>Like on Windows, "register_long_arrays=On" causes the
> described problem with the session too.
No, it doesn't.
With register_long_arrays=On I get the same result, as with Off. It
works perfectly fine.
I guess you have some kind of broken browser and/or some combination of
Apache modules or PHP/Zend extensions, which cause it. By the way, you
didn't answer my question on zend_extensions.
[2006-12-05 15:12:33] marcus dot uy at virtualthinking dot com
Just a quick update. A correction on the Linux settings. Like on
Windows, "register_long_arrays=On" causes the described problem with the
session too.
My bad. Did not notice that the option was commented out.
[2006-11-29 12:15:40] marcus dot uy at virtualthinking dot com
mod_security removed. Behaviour of PHP is still the same as my
previous post.
I have tested the same php.ini file on a separate linux server (with
path names adjusted for linux) that I own and it works with
register_long_arrays=off in the expected manner as documented.
The same settings on windows fail to work as noted earlier.
I cannot verify this, but is there some internal reference or
dependency in the session subsystem that uses the old long array
vars/buffer as the input source for the data that is written to the
session file?
Hence:
$_SESSION => can show up during the run
...but...
$HTTP_SESSION_VAR => written to disk, and thus empty
Any chance? Was discussing fault scenarios with a friend and this came
up as a plausible case that would result in this kind of oddity (a
difference in how the windows and linux compilers work might account for
the difference in behaviour on different platforms???).
[2006-11-29 10:08:15] [EMAIL PROTECTED]
First of all, please remove/disable mod_security.
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/34542
--
Edit this bug report at http://bugs.php.net/?id=34542&edit=1
#34542 [Bgs->Opn]: register_long_arrays causes $_SESSIONS vars to disappear
ID: 34542 User updated by: marcus dot uy at virtualthinking dot com Reported By: marcus dot uy at virtualthinking dot com -Status: Bogus +Status: Open Bug Type: Session related Operating System: WinXP Pro PHP Version: 5.1.0RC4 New Comment: This bug is still there in 5.2.0. BTW My environment does not use session cookies. I use the session passed via URL. The reason is that my code overcomes the problems associated with URL hijacking in-code, rather than depending on session cookies that could also get hijacked. The error stands. I swear that it is real. And, frankly, there seems to be many, many scripts and users that are reporting similar session issues. I don't think that we could all be wrong. Previous Comments: [2005-12-11 14:47:31] [EMAIL PROTECTED] This still doesn't happen. [2005-12-11 08:32:37] marcus dot uy at virtualthinking dot com There have been test cases posted for this bug. Please review. [2005-11-11 01:00:24] php-bugs at lists dot php dot net 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". [2005-11-09 23:43:51] mail at lenzw dot de see Bug #33811 for a reproduction code. [2005-11-03 22:10:18] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , 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 to avoid embedding huge scripts into the report. 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/34542 -- Edit this bug report at http://bugs.php.net/?id=34542&edit=1
