[PHP-BUG] Bug #64771 [NEW]: Error: require_once(): Unable to allocate memory for pool.
From: tech at neodynamics dot com Operating system: Linux PHP version: 5.3.24 Package: Apache2 related Bug Type: Bug Bug description:Error: require_ÂonceÂ(Â)Â: Unable to allocate memory for pool. Description: I have a x-cart 4.4.2 Pro based store having the following configurations- Environment info- Component Status X-Cart version 4.4.2 X-Cart directory/var/www/html/mydomain.com/httpdocs PHP 5.3.10-1ubuntu3.5 GD 2.0 MySQL server5.1.45 MySQL client5.5.29 DB size 415.349Mb Web server Apache/2.2.22 (Ubuntu) Operation systemLinux Perl5.014002Details >> XML parser (expat) found X-Cart directory size Estimate the directory size HTTPS modules Net::SSLeay 1.42 libCURL 7.22.0 Active >> CURL executable curl 7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 OpenSSL executable OpenSSL 1.0.1 14 Mar 2012 I am facing the following problems and site become down. Test script: --- 1)/home.php raised Error: require_ÂonceÂ(Â)Â: Unable to allocate memory for pool. … called at /var/www/html/mydomain.com/httpdocs/include/func/ func.core.php (70) in x_load called at /var/www/html/mydomain.com/httpdocs/init.php (61) in include_once called at /var/www/html/mydomain.com/httpdocs/preauth.php (69) in require called at /var/www/html/mydomain.com/httpdocs/auth.php (63) in require called at /var/www/html/mydomain.com/httpdocs/home.php (52) 2)/dispatcher.php raised Error: require_ÂonceÂ(Â)Â: Unable to allocate memory for pool. … called at /var/www/html/mydomain.com/httpdocs/include/func/ func.core.php (70) in x_load called at /var/www/html/mydomain.com/httpdocs/init.php (61) in include_once called at /var/www/html/mydomain.com/httpdocs/preauth.php (69) in require called at /var/www/html/mydomain.com/httpdocs/dispatcher.php (50) 3)/adaptive.php raised Error: require_ÂonceÂ(Â)Â: Unable to allocate memory for pool. … called at /var/www/html/mydomain.com/httpdocs/include/func/ func.core.php (70) in x_load called at /var/www/html/mydomain.com/httpdocs/init.php (61) in require called at /var/www/html/mydomain.com/httpdocs/adaptive.php (51) Expected result: My site frequently down and facing error. -- Edit bug report at https://bugs.php.net/bug.php?id=64771&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64771&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64771&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64771&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64771&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64771&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64771&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64771&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64771&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64771&r=support Expected behavior: https://bugs.php.net/fix.php?id=64771&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64771&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64771&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64771&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64771&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64771&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64771&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64771&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64771&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64771&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64771&r=mysqlcfg
[PHP-BUG] Bug #62677 [NEW]: preg_match_all: Useless without optional parameters
From: David dot Dvorak at bnv-tech dot cz Operating system: ubuntu3.2 PHP version: Irrelevant Package: *Regular Expressions Bug Type: Bug Bug description:preg_match_all: Useless without optional parameters Description: The preg_match_all function always returns false if it is used with only mandatory parameters. Test script: --- var_dump(preg_match_all('/[^0-9\.]/', '455asdf')); Expected result: int(4) -- Edit bug report at https://bugs.php.net/bug.php?id=62677&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62677&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62677&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62677&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62677&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62677&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62677&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62677&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62677&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62677&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62677&r=support Expected behavior: https://bugs.php.net/fix.php?id=62677&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62677&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62677&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62677&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62677&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62677&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62677&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62677&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62677&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62677&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62677&r=mysqlcfg
[PHP-BUG] Bug #55575 [NEW]: strtotime() returns erroneous result on nonsense DATE_RSS format date strings
From: Operating system: Linux & Darwin PHP version: 5.3.8 Package: Date/time related Bug Type: Bug Bug description:strtotime() returns erroneous result on nonsense DATE_RSS format date strings Description: (Note: I was only able to test on 5.2.16, 5.3.0, and 5.3.4. Since there is no evidence of it being fixed in the changelog of 5.3.8, I assume it's still there.) The ninth of May, 2010, was a Sunday. However, if you assert to strtotime() that it was a Monday, it will return the Unix timestamp for Monday, May 10th. Likewise if you assert the ninth was a Tuesday, it will return the timestamp for the 11th; a Wednesday the 12th, and so on right up to returning a Unix timestamp for Saturday, 15 May 2010 if you provide it with "Saturday, 9 May 2010". Presumably, the correct behavior is one of (1) to throw an error given a self- contradictory date, (2) to return nothing at all, or (3) to ignore the day-of-the- week element and return the Unix timestamp for the date specified (e.g. 9 May 2010). Returning the timestamp for another date altogether is wrong. Test script: --- $datestring="9 May 2010 04:24:36 GMT"; print "\"\": ".strtotime($datestring)." ".date($dateformat, strtotime($datestri\ ng)) ."\n"; $datestring="Sun, 9 May 2010 04:24:36 GMT"; print "Sun: ".strtotime($datestring)." ".date($dateformat, strtotime($datestrin\ g)) ."\n"; $datestring="Mon, 9 May 2010 04:24:36 GMT"; print "Mon: ".strtotime($datestring)." ".date($dateformat, strtotime($datestrin\ g)) ."\n"; $datestring="Tue, 9 May 2010 04:24:36 GMT"; print "Tue: ".strtotime($datestring)." ".date($dateformat, strtotime($datestrin\ g)) ."\n"; Expected result: "": 1273379076 Sun, 09 May 2010 00:24:36 -0400 Sun: 1273379076 Sun, 09 May 2010 00:24:36 -0400 Mon: 1273379076 Sun, 09 May 2010 00:24:36 -0400 Tue: 1273379076 Sun, 09 May 2010 00:24:36 -0400 (Alternatively: "": 1273379076 Sun, 09 May 2010 00:24:36 -0400 Sun: 1273379076 Sun, 09 May 2010 00:24:36 -0400 Mon: Tue: ) Actual result: -- "": 1273379076 Sun, 09 May 2010 00:24:36 -0400 Sun: 1273379076 Sun, 09 May 2010 00:24:36 -0400 Mon: 1273465476 Mon, 10 May 2010 00:24:36 -0400 Tue: 1273551876 Tue, 11 May 2010 00:24:36 -0400 -- Edit bug report at https://bugs.php.net/bug.php?id=55575&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55575&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55575&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55575&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55575&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55575&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55575&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55575&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55575&r=needscript Try newer version: https://bugs.php.net/fix.php?id=55575&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55575&r=support Expected behavior: https://bugs.php.net/fix.php?id=55575&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55575&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55575&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55575&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55575&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55575&r=dst IIS Stability: https://bugs.php.net/fix.php?id=55575&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55575&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55575&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55575&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55575&r=mysqlcfg
[PHP-BUG] Bug #54068 [NEW]: php installation could not be completed
From: Operating system: Windows 7 64bit PHP version: 5.3.5 Package: Windows Installer Bug Type: Bug Bug description:php installation could not be completed Description: Hello, I've got Windows 7 64bit. I installed Apache HTTP Server (httpd) 2.2.17 (it is stated, that it is the best available version) - i tried it with both install packages: # Win32 Binary without crypto (no mod_ssl) (MSI Installer): httpd-2.2.17-win32-x86-no_ssl.msi [PGP] [MD5] [SHA1] # Win32 Binary including OpenSSL 0.9.8o (MSI Installer): httpd-2.2.17-win32-x86-openssl-0.9.8o.msi But I am still not able to install php, using following package: VC6 x86 Thread Safe (2011-Jan-06 18:56:08) php-5.3.5-Win32-VC6-x86.msi (VC6 should be used for Apache Web Server - VC9 only for IIS, right?) (I did choose the Thread Safe version, because it features the "Apache 2.2.x Module" integration in the install wizzard. - Is this correct? What is the actual differance to Non Thread Safe?) ERROR: The error message which I am receiving at the very end of the install process is following: "There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your support personnel or package vendor." I did also read following bug requests: http://bugs.php.net/bug.php?id=43639 http://bugs.php.net/bug.php?id=47134 But the snaps do not include Windows a version and giving full access rights to the Apache Web Server folder did not have any effect. - I am lost! :( Please help. -- Edit bug report at http://bugs.php.net/bug.php?id=54068&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54068&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54068&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54068&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54068&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54068&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54068&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54068&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54068&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54068&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54068&r=support Expected behavior: http://bugs.php.net/fix.php?id=54068&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54068&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54068&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54068&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54068&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54068&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54068&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54068&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54068&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54068&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54068&r=mysqlcfg
#49151 [Opn]: relocation must bind locally
ID: 49151 User updated by: tech at uscki dot nl Reported By: tech at uscki dot nl Status: Open Bug Type: Compile Failure Operating System: Sun Solaris 5.10 (i386) PHP Version: 5.3.0 Assigned To: nlopess New Comment: Yeah, got it compiling! I removed "-fvisibility=hidden" from the Makefile after running ./configure, guess that boils down to the same result, though your suggestion is a bit tidier. Compiler: gcc (GCC) 4.0.1 Thanks for all your help! Previous Comments: [2009-08-14 21:54:04] nlop...@php.net sorry, I forgot to say that before ./configure you must run ./buildconf [2009-08-14 16:49:14] nlop...@php.net you can disable the visibility patch by editing the configure.in file and removing the occurrence of "-fvisibility=hidden". Then do a ./vcsclean && ./configure && make. Then please report if it worked, and which compiler version you used. thanks. [2009-08-14 10:08:07] tech at uscki dot nl Hmmm, adding static isn't trivial, these first two methods were the tip of the iceberg... Looks like I'll be adding it all through the code if I go through with this (I stopped after about 10 changes in various files). How do I "disable the visibility thing", as Nuno noted? [2009-08-13 10:01:53] j...@php.net in ext/date/php_date.c:485, add static in front of this line: ZEND_DECLARE_MODULE_GLOBALS(date) [2009-08-13 09:50:30] tech at uscki dot nl Hi, the suggestion of making date_ce_date static seems to help! But I'm not quite there yet :( , date_globals gives a similar error: ld: fatal: relocation error: R_386_GOTOFF: file ext/date/.libs/php_date.o: symbol date_globals: relocation must bind locally I'm not quite able to find its definition to make that one static as well (due to my lousy C-skills ... ;) ). Any ideas where to do this? 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/49151 -- Edit this bug report at http://bugs.php.net/?id=49151&edit=1
#49151 [Fbk->Opn]: relocation must bind locally
ID: 49151 User updated by: tech at uscki dot nl Reported By: tech at uscki dot nl -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Sun Solaris 5.10 (i386) PHP Version: 5.3.0 Assigned To: nlopess New Comment: Hmmm, adding static isn't trivial, these first two methods were the tip of the iceberg... Looks like I'll be adding it all through the code if I go through with this (I stopped after about 10 changes in various files). How do I "disable the visibility thing", as Nuno noted? Previous Comments: [2009-08-13 10:01:53] j...@php.net in ext/date/php_date.c:485, add static in front of this line: ZEND_DECLARE_MODULE_GLOBALS(date) [2009-08-13 09:50:30] tech at uscki dot nl Hi, the suggestion of making date_ce_date static seems to help! But I'm not quite there yet :( , date_globals gives a similar error: ld: fatal: relocation error: R_386_GOTOFF: file ext/date/.libs/php_date.o: symbol date_globals: relocation must bind locally I'm not quite able to find its definition to make that one static as well (due to my lousy C-skills ... ;) ). Any ideas where to do this? [2009-08-10 22:51:29] nlop...@php.net If adding static doesn't help, we can disable the visibility thing on solaris. (due to the apparently broken compiler/assembler). [2009-08-05 14:48:12] j...@php.net Would this help: ext/date/php_date.c:511 -zend_class_entry *date_ce_date, *date_ce_timezone, *date_ce_interval, *date_ce_period; +static zend_class_entry *date_ce_date, *date_ce_timezone, *date_ce_interval, *date_ce_period; (add static there :) [2009-08-05 14:39:14] j...@php.net Assigned to Nuno who's patch broke this. 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/49151 -- Edit this bug report at http://bugs.php.net/?id=49151&edit=1
#49151 [Fbk->Opn]: relocation must bind locally
ID: 49151 User updated by: tech at uscki dot nl Reported By: tech at uscki dot nl -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Sun Solaris 5.10 (i386) PHP Version: 5.3.0 Assigned To: nlopess New Comment: Hi, the suggestion of making date_ce_date static seems to help! But I'm not quite there yet :( , date_globals gives a similar error: ld: fatal: relocation error: R_386_GOTOFF: file ext/date/.libs/php_date.o: symbol date_globals: relocation must bind locally I'm not quite able to find its definition to make that one static as well (due to my lousy C-skills ... ;) ). Any ideas where to do this? Previous Comments: [2009-08-10 22:51:29] nlop...@php.net If adding static doesn't help, we can disable the visibility thing on solaris. (due to the apparently broken compiler/assembler). [2009-08-05 14:48:12] j...@php.net Would this help: ext/date/php_date.c:511 -zend_class_entry *date_ce_date, *date_ce_timezone, *date_ce_interval, *date_ce_period; +static zend_class_entry *date_ce_date, *date_ce_timezone, *date_ce_interval, *date_ce_period; (add static there :) [2009-08-05 14:39:14] j...@php.net Assigned to Nuno who's patch broke this. [2009-08-05 08:26:45] tech at uscki dot nl Not sure what you mean exactly with that post, but the LDFLAGS are set before compilation to the following: export LDFLAGS="$LDFLAGS -L/phil/sw/sunos/i386/lib" export LDFLAGS="$LDFLAGS -R/phil/sw/sunos/i386/lib" This all worked fine with php 5.2.9 . Anyway thanks for the help so far! I will be out for about a week, so I will look at it again by that time (hopefully with fresh new insight! ;) ) Kind regards, Coert [2009-08-04 19:15:30] j...@php.net http://www.opensolaris.org/jive/thread.jspa? threadID=35812&tstart=0#145783 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/49151 -- Edit this bug report at http://bugs.php.net/?id=49151&edit=1
#49151 [Fbk->Opn]: relocation must bind locally
ID: 49151 User updated by: tech at uscki dot nl Reported By: tech at uscki dot nl -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Sun Solaris 5.10 (i386) PHP Version: 5.3.0 New Comment: Not sure what you mean exactly with that post, but the LDFLAGS are set before compilation to the following: export LDFLAGS="$LDFLAGS -L/phil/sw/sunos/i386/lib" export LDFLAGS="$LDFLAGS -R/phil/sw/sunos/i386/lib" This all worked fine with php 5.2.9 . Anyway thanks for the help so far! I will be out for about a week, so I will look at it again by that time (hopefully with fresh new insight! ;) ) Kind regards, Coert Previous Comments: [2009-08-04 19:15:30] j...@php.net http://www.opensolaris.org/jive/thread.jspa? threadID=35812&tstart=0#145783 [2009-08-04 17:04:26] tech at uscki dot nl Alas, same result [2009-08-04 14:31:08] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-08-04 13:02:50] tech at uscki dot nl Description: Compiling php 5.3.0 on SunOS 5.10 (i386) fails on "fatal: relocation error" Reproduce code: --- Compile was tried with both: - GNU ld (GNU Binutils) 2.18 - ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.478 and also with and w/o addition of the make parameter: -fvisibility=hidden ./configure \ --prefix=/phil/usr/local/php-$VERSION \ --with-config-file-path=/phil/etc \ --with-apxs2=/phil/sw/sunos/i386/bin/apxs \ --with-db4=/phil/sw/sunos/i386 \ --with-jpeg-dir=/phil/sw/sunos/i386 \ --with-png-dir=/phil/sw/sunos/i386 \ --with-ldap=/phil/sw/sunos/i386 \ --with-openssl=/phil/sw/sunos/i386 \ --with-zlib \ --enable-zip \ --with-pgsql=/phil/sw/sunos/i386 \ --with-gettext \ --with-gd \ --enable-exif \ --with-pdo-pgsql=/phil/sw/sunos/i386 \ --with-iconv-dir=/phil/sw/sunos/i386 \ --with-libxml-dir=/phil/sw/sunos/i386 \ --with-tidy=/phil/usr/local \ --with-freetype-dir=/phil/sw/sunos/i386 \ --enable-gd-native-ttf \ --with-gnu-ld \ --with-xsl=/phil/sw/sunos/i386/pkg/libxslt-1.1.15 \ --enable-soap \ --with-mysql=mysqlnd make CFLAGS="-fvisibility=hidden -mimpure-text -m32 -I/phil/sw/sunos/i386/include --with-gnu-ld --with-ld=/phil/sw/sunos/i386/bin/ld" Expected result: Clean compile Actual result: -- /bin/sh /home/gemeren/php/php-5.3.0/libtool --silent --preserve-dup-deps --mode=compile gcc -IZend/ -I/home/gemeren/php/php-5.3.0/Zend/ -DPHP_ATOM_INC -I/home/gemeren/php/php-5.3.0/include -I/home/gemeren/php/php-5.3.0/main -I/home/gemeren/php/php-5.3.0 -I/home/gemeren/php/php-5.3.0/ext/date/lib -I/home/gemeren/php/php-5.3.0/ext/ereg/regex -I/phil/sw/sunos/i386/pkg/libxml2-2.6.22/include/libxml2 -I/phil/sw/sunos/i386/include -I/phil/sw/sunos/i386/include/freetype2 -I/phil/sw/sunos/i386/pkg/postgresql-8.1.1/include -I/home/gemeren/php/php-5.3.0/ext/sqlite3/libsqlite -I/phil/usr/local/include/tidy -I/phil/sw/sunos/i386/pkg/libxslt-1.1.15/include -I/home/gemeren/php/php-5.3.0/TSRM -I/home/gemeren/php/php-5.3.0/Zend -D_POSIX_PTHREAD_SEMANTICS -I/usr/include -g -O2 -fvisibility=hidden -c /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c -o Zend/zend_object_handlers.lo /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c: In function 'zend_std_object_get_class': /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c:1199: warning: visibility attribute not supported in this configuration; ignored /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c: In function 'zend_std_object_get_class_name': /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c:1220: warning: visibility attribute not supported in this configuration; ignored /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c: In function 'zend_std_get_closure': /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c:1317: warning: visibility attribute not supported in this configuration; ignored /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c: In function 'zend_std_read_dimension': /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c:503: warning: visibility attribute not supported in this configuration; ignored /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c: In function 'zend_std_read_property': ext/standard/var.lo ext/standard/versioning.lo ext/standard/assert.lo ext/standard/strnatcmp.lo ext/standard/levenshtein.lo ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo ext/standard/php_fopen_wrappe
#49151 [Fbk->Opn]: relocation must bind locally
ID: 49151 User updated by: tech at uscki dot nl -Reported By: coert dot vangemeren at phil dot uu dot nl +Reported By: tech at uscki dot nl -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Sun Solaris 5.10 (i386) PHP Version: 5.3.0 New Comment: Alas, same result Previous Comments: [2009-08-04 14:31:08] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-08-04 13:02:50] tech at uscki dot nl Description: Compiling php 5.3.0 on SunOS 5.10 (i386) fails on "fatal: relocation error" Reproduce code: --- Compile was tried with both: - GNU ld (GNU Binutils) 2.18 - ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.478 and also with and w/o addition of the make parameter: -fvisibility=hidden ./configure \ --prefix=/phil/usr/local/php-$VERSION \ --with-config-file-path=/phil/etc \ --with-apxs2=/phil/sw/sunos/i386/bin/apxs \ --with-db4=/phil/sw/sunos/i386 \ --with-jpeg-dir=/phil/sw/sunos/i386 \ --with-png-dir=/phil/sw/sunos/i386 \ --with-ldap=/phil/sw/sunos/i386 \ --with-openssl=/phil/sw/sunos/i386 \ --with-zlib \ --enable-zip \ --with-pgsql=/phil/sw/sunos/i386 \ --with-gettext \ --with-gd \ --enable-exif \ --with-pdo-pgsql=/phil/sw/sunos/i386 \ --with-iconv-dir=/phil/sw/sunos/i386 \ --with-libxml-dir=/phil/sw/sunos/i386 \ --with-tidy=/phil/usr/local \ --with-freetype-dir=/phil/sw/sunos/i386 \ --enable-gd-native-ttf \ --with-gnu-ld \ --with-xsl=/phil/sw/sunos/i386/pkg/libxslt-1.1.15 \ --enable-soap \ --with-mysql=mysqlnd make CFLAGS="-fvisibility=hidden -mimpure-text -m32 -I/phil/sw/sunos/i386/include --with-gnu-ld --with-ld=/phil/sw/sunos/i386/bin/ld" Expected result: Clean compile Actual result: -- /bin/sh /home/gemeren/php/php-5.3.0/libtool --silent --preserve-dup-deps --mode=compile gcc -IZend/ -I/home/gemeren/php/php-5.3.0/Zend/ -DPHP_ATOM_INC -I/home/gemeren/php/php-5.3.0/include -I/home/gemeren/php/php-5.3.0/main -I/home/gemeren/php/php-5.3.0 -I/home/gemeren/php/php-5.3.0/ext/date/lib -I/home/gemeren/php/php-5.3.0/ext/ereg/regex -I/phil/sw/sunos/i386/pkg/libxml2-2.6.22/include/libxml2 -I/phil/sw/sunos/i386/include -I/phil/sw/sunos/i386/include/freetype2 -I/phil/sw/sunos/i386/pkg/postgresql-8.1.1/include -I/home/gemeren/php/php-5.3.0/ext/sqlite3/libsqlite -I/phil/usr/local/include/tidy -I/phil/sw/sunos/i386/pkg/libxslt-1.1.15/include -I/home/gemeren/php/php-5.3.0/TSRM -I/home/gemeren/php/php-5.3.0/Zend -D_POSIX_PTHREAD_SEMANTICS -I/usr/include -g -O2 -fvisibility=hidden -c /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c -o Zend/zend_object_handlers.lo /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c: In function 'zend_std_object_get_class': /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c:1199: warning: visibility attribute not supported in this configuration; ignored /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c: In function 'zend_std_object_get_class_name': /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c:1220: warning: visibility attribute not supported in this configuration; ignored /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c: In function 'zend_std_get_closure': /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c:1317: warning: visibility attribute not supported in this configuration; ignored /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c: In function 'zend_std_read_dimension': /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c:503: warning: visibility attribute not supported in this configuration; ignored /home/gemeren/php/php-5.3.0/Zend/zend_object_handlers.c: In function 'zend_std_read_property': ext/standard/var.lo ext/standard/versioning.lo ext/standard/assert.lo ext/standard/strnatcmp.lo ext/standard/levenshtein.lo ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo ext/standard/ftp_fopen_wrapper.lo ext/standard/http_fopen_wrapper.lo ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo ext/standard/css.lo ext/standard/var_unserializer.lo ext/standard/ftok.lo ext/standard/sha1.lo ext/standard/user_filters.lo ext/standard/uuencode.lo ext/standard/filters.lo ext/standard/proc_open.lo ext/standard/streamsfuncs.lo ext/standard/http.lo ext/tidy/tidy.lo ext/tokenizer/tokenizer.lo ext/tokenizer/tokenizer_data.lo ext/xml/xml.lo ext/xml/compat.lo ext/xmlreader/php_xmlreader.lo ext/xmlwriter/php_xmlwriter.lo ext/xsl/php_xsl.lo ext/xsl/xsltprocessor.lo ext/zip/php_zip.lo ext/zip/zip_stream.lo ext/zip/lib/zip_add.lo ext/zip/lib/zip_error.lo ext/zip/lib/zip_fclose.lo ext/zip/lib/zip_fread.lo ext/zip/lib/zip_open.lo ext/zip/lib/zip_source_fil
#47120 [NEW]: Function "strtotime" work incorrect
From: poczta at kab-tech dot pl Operating system: Windows Vista PHP version: 5.2.8 PHP Bug Type: Unknown/Other Function Bug description: Function "strtotime" work incorrect Description: Function "strtotime" don't work for some event. Reproduce code: --- //incorrect $data_po = "24.2"; $po = strtotime($data_po); echo $po; //correct $data_po = "24.2.2009"; $po = strtotime($data_po); echo $po; //for $data_po = "01.02"; to $data_po = "23.02"; //work OK Expected result: Something like: 1232118060 Actual result: -- empty field -- Edit bug report at http://bugs.php.net/?id=47120&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47120&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47120&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47120&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47120&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47120&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47120&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47120&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47120&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47120&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47120&r=support Expected behavior: http://bugs.php.net/fix.php?id=47120&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47120&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47120&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47120&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47120&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47120&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47120&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47120&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47120&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47120&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47120&r=mysqlcfg
#45867 [NEW]: get_var_dump();
From: bholbrook at tech-monkeys dot org Operating system: any PHP version: 5.2.6 PHP Bug Type: Feature/Change Request Bug description: get_var_dump(); Description: Add function get_var_dump() to relieve the inconveniences associated with var_dump() automatically outputting. Reproduce code: --- //for expected result $getDump = get_var_dump($_GET); mail("[EMAIL PROTECTED]", "GET dump from [EMAIL PROTECTED]", $getDump); header("content-type:{$_GET['type']}"); //for actual result var_dump($_GET); header("content-type:{$_GET['type']}"); //can be emulated with, but cumbersome, and not always enabled on remote hosts ob_start(); var_dump($_GET); $getDump = ob_get_contents(); ob_end_clean(); mail("[EMAIL PROTECTED]", "GET dump from [EMAIL PROTECTED]", $getDump); header("content-type:{$_GET['type']}"); Expected result: 1) No error. 2) Ability to send / manipulate (convert to json for ajax apps) var dump data outside of php Actual result: -- 1) Header fails 2) var_dump must be seen as processed by tester and cannot be collected in a beta environment. -- Edit bug report at http://bugs.php.net/?id=45867&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45867&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45867&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45867&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45867&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45867&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45867&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45867&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45867&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45867&r=support Expected behavior:http://bugs.php.net/fix.php?id=45867&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45867&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45867&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45867&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45867&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45867&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45867&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45867&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45867&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45867&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45867&r=mysqlcfg
#30327 [Com]: --with-config-file-path option name, phpinfo() output mislead users
ID: 30327 Comment by: dominic dot clifton at gr-tech dot net Reported By: gk at proliberty dot com Status: Open Bug Type: Feature/Change Request Operating System: Linux ; kernel 2.4.18 PHP Version: 5.0.2 New Comment: I totally agree, it's very misleading. In older versions of php it was also even more confusing that the value changes from a directory to a file in the phpinfo() output once php actually read a file from the directory! Show a directory in all cases, even when php has read a file. Show the actual file that was read seperately. It appears some work on thus bug has been addresses already: php 5.2.6 shows this: Configuration File (php.ini) Path => /opt/php5/etc Loaded Configuration File => /opt/php5/etc/php.ini however it still needs to be changed. the configure option and the documentation needs to change from: --with-config-file-path to --with-config-file-dir then it'll be inline with: --with-config-file-scan-dir (feel free to support the current option for legacy reasons) The php info output should also change from: Configuration File (php.ini) Path => /opt/php5/etc Loaded Configuration File => /opt/php5/etc/php.ini Scan this dir for additional .ini files => /opt/php5/etc/conf.d to Configuration File (php.ini) Directory => /opt/php5/etc Loaded Configuration File => /opt/php5/etc/php.ini Scan this dir for additional .ini files => /opt/php5/etc/conf.d Previous Comments: [2004-10-05 06:39:52] gk at proliberty dot com Description: Bug #26735 described this problem but was closed as 'bogus' when it is really a valid feature request (bug) which needs to be addressed. Please do not 'bogusify' this request since it could have saved me a lot of time if not closed previously. Both the configure option ('--with-config-file-path') and the phpinfo() output ('Configuration File (php.ini) Path /usr/local/php5/lib/php5.ini') imply that this option refers to a 'file' when in fact it refers only to a directory - the name of the config file can ONLY be 'php.ini'. This fact is completely hidden from the user. This could be corrected by renaming option to: '--with-config-file-dir' And changing phpinfo() output to: 'Configuration File (php.ini) Directory' Oddly, php tries to read /usr/local/php5/lib/php5.ini/php.ini instead of the file reported by phpinfo(): /usr/local/php5/lib/php5.ini strace -eopen php -r '' 2>&1 | grep ini ... open("/usr/local/php5/lib/php5.ini/php.ini", O_RDONLY) = -1 ENOTDIR (Not a directory) Bug #26735 said the following: ... the documentation (specifically ./configure --help) is unclear, as well phpinfo() is unclear as it labels the value supplied with --with-config-file-path as Configuration File (php.ini) Path, and typically Path of a file would include the filename. Request that the flag be renamed --with-config-file-dir and the corrosponding phpinfo() label be changed as well... i suspect that labels is trivial compared to making the programs obey the labels. Reproduce code: --- ./configure \ --with-config-file-path=/usr/local/php5/lib/php5.ini; Expected result: Configuration File (php.ini) Path /usr/local/php5/lib/ ... Actual result: -- Configuration File (php.ini) Path /usr/local/php5/lib/php5.ini ... php5.ini file is NOT read -- Edit this bug report at http://bugs.php.net/?id=30327&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: tech at dragonara dot net Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: We have the same bug, and really - cPanel does not support 5.1 anymore, so we are really in stupid situation. Previous Comments: [2008-02-09 13:20:23] lhfagundes at gmail dot com This gets bad if the float is casted to string (which happens if it goes through requests): $x = 12.00; echo $x . "\n"; echo (int)$x . "\n"; $x = "$x"; echo (int) $x . "\n"; In PHP 4.4.2 (I guess in earlier php5 too) 12 12 12 now: 1.2E+9 12 1 [2008-01-28 13:39:47] gcleaves at yahoo dot com dot au Same problem: PHP Version 5.2.4 Windows NT HGCT-SQL 5.2 build 3790 Apache 2.0 Handler [2008-01-26 02:18:38] [EMAIL PROTECTED] This issue is still present in PHP 5.2.5 (FreeBSD). It only happens on some floats. If there is a reason for using E-notation in this case - which could be argued, although I feel changing past behavior is not necessary, especially as MySQL has trouble handling these values in common scenarios - it should be made consistent so people can depend on it and prevent problems by testing. devwh:~> php floats.php 5.2.1 270 280 290 test:~> php floats.php 5.2.4 270 2.8E+6 290 toms1:~> php floats.php 5.2.5 270 2.8E+6 290 [2008-01-18 21:42:38] nate at recoverydatabase dot net We just got bit by this on one of our servers running Fedora 7 and PHP 5.2.4 installed via yum. The others not causing any headaches are running Fedora 6 and PHP 5.1.6. It's not just a display problem - we have a mysql database with very large values in the primary keys, and when this server tries to insert data, or display, or lookup information based on those values it fails miserably. A php.ini option to disable the notation behavior would be nice. As for right now I must get back to downgrading. :( [2007-12-29 01:50:56] daniel at fanetworks dot net I also noticed results coming as scientific notation for larger numbers in 5.1.6. Honestly, it should always come out in interger format with an option to return as notation. Having data not return in a reliable format is a serious issue. Its like $array = array(1=>2, 3=>4); sometimes returning with a serialized version of the array as a string instead of an actual array. Its hard to code when data is returning in an uncontrolled format :( 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#41967 [Csd]: file_get_contents or fopen produce my_thread_global_end error
ID: 41967 User updated by: tech at millennium dot ab dot ca Reported By: tech at millennium dot ab dot ca Status: Closed Bug Type: Reproducible crash Operating System: Windows 2000 SBS PHP Version: 5.2.3 New Comment: I did search. I just did another search and this is the only submission regarding this issue? Can you please supply a link to the fix you are talking about? Previous Comments: [2007-07-11 18:38:33] [EMAIL PROTECTED] Already fixed in CVS. (why didn't you search before reporting?!) [2007-07-11 18:07:09] tech at millennium dot ab dot ca Forgot to mention, I use this function for an XML call, not specifically google, but that example will produce the same error as I get. This only started happening after the update to 5.2.3, I never had this problem before and I'm using all the same code as I have been for a number of years. [2007-07-11 17:51:15] tech at millennium dot ab dot ca Description: After upgrading to PHP 5.2.3 I began seeing "Error in my_thread_global_end(): 1 threads didn't exit" whenever using the fopen or file_get_contents with a URL. I get it regardless of SSL or not. This has nothing to do with the MySQL thing, I've tryed those DLL's and it's not that. MySQL is working fine without any errors, this only happens when using the functions mentioned above. Reproduce code: --- http://www.google.ca";);?> Expected result: responce from server stored in $Contents Actual result: -- responce from server stored in $Contents + "Error in my_thread_global_end(): 1 threads didn't exit" -- Edit this bug report at http://bugs.php.net/?id=41967&edit=1
#41967 [Opn]: file_get_contents or fopen produce my_thread_global_end error
ID: 41967 User updated by: tech at millennium dot ab dot ca Reported By: tech at millennium dot ab dot ca Status: Open Bug Type: Reproducible crash Operating System: Windows 2000 SBS PHP Version: 5.2.3 New Comment: Forgot to mention, I use this function for an XML call, not specifically google, but that example will produce the same error as I get. This only started happening after the update to 5.2.3, I never had this problem before and I'm using all the same code as I have been for a number of years. Previous Comments: [2007-07-11 17:51:15] tech at millennium dot ab dot ca Description: After upgrading to PHP 5.2.3 I began seeing "Error in my_thread_global_end(): 1 threads didn't exit" whenever using the fopen or file_get_contents with a URL. I get it regardless of SSL or not. This has nothing to do with the MySQL thing, I've tryed those DLL's and it's not that. MySQL is working fine without any errors, this only happens when using the functions mentioned above. Reproduce code: --- http://www.google.ca";);?> Expected result: responce from server stored in $Contents Actual result: -- responce from server stored in $Contents + "Error in my_thread_global_end(): 1 threads didn't exit" -- Edit this bug report at http://bugs.php.net/?id=41967&edit=1
#41967 [NEW]: file_get_contents or fopen produce my_thread_global_end error
From: tech at millennium dot ab dot ca Operating system: Windows 2000 SBS PHP version: 5.2.3 PHP Bug Type: Reproducible crash Bug description: file_get_contents or fopen produce my_thread_global_end error Description: After upgrading to PHP 5.2.3 I began seeing "Error in my_thread_global_end(): 1 threads didn't exit" whenever using the fopen or file_get_contents with a URL. I get it regardless of SSL or not. This has nothing to do with the MySQL thing, I've tryed those DLL's and it's not that. MySQL is working fine without any errors, this only happens when using the functions mentioned above. Reproduce code: --- http://www.google.ca";);?> Expected result: responce from server stored in $Contents Actual result: -- responce from server stored in $Contents + "Error in my_thread_global_end(): 1 threads didn't exit" -- Edit bug report at http://bugs.php.net/?id=41967&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41967&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41967&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41967&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41967&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41967&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41967&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41967&r=needscript Try newer version:http://bugs.php.net/fix.php?id=41967&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41967&r=support Expected behavior:http://bugs.php.net/fix.php?id=41967&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41967&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41967&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41967&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41967&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41967&r=dst IIS Stability:http://bugs.php.net/fix.php?id=41967&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41967&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41967&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41967&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41967&r=mysqlcfg
#41046 [Fbk->Opn]: PHP has encountered an Access Violation at 0227A495
ID: 41046 User updated by: tech at juuce dot com Reported By: tech at juuce dot com -Status: Feedback +Status: Open Bug Type: IIS related Operating System: W2K3 Server - Web Editio PHP Version: 5.2.1 New Comment: PHP code Previous Comments: [2007-04-11 13:59:05] [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 the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2007-04-11 02:56:47] tech at juuce dot com Description: PHP has encountered an Access Violation at 0227A495 Setup : W2K3 - Web Edition IIS6 PHP 5.2.1 (ISAPI) + Extensions (mysql...) Zend - 3.2.2 This error is encountered on all sites running under IIS6 with PHP-5.2.1 as ISAPI module which request a php page. (note Zend Optimiser 3.2.2 is running but reproducable when disabled) This error Message only seems to appear when IIS is restarted and the page is requested for the first time. Once this error appears the file seems to be locked and it cannot be deleted. PHP.ini Changes are Extensions Loaction of Log files and TMP upload directory. WSDL temp directory Reproduce code: --- echo 'test'; Expected result: See Test String Actual result: -- PHP has encountered an Access Violation at 0227A495 -- Edit this bug report at http://bugs.php.net/?id=41046&edit=1
#41046 [NEW]: PHP has encountered an Access Violation at 0227A495
From: tech at juuce dot com Operating system: W2K3 Server - Web Editio PHP version: 5.2.1 PHP Bug Type: IIS related Bug description: PHP has encountered an Access Violation at 0227A495 Description: PHP has encountered an Access Violation at 0227A495 Setup : W2K3 - Web Edition IIS6 PHP 5.2.1 (ISAPI) + Extensions (mysql...) Zend - 3.2.2 This error is encountered on all sites running under IIS6 with PHP-5.2.1 as ISAPI module which request a php page. (note Zend Optimiser 3.2.2 is running but reproducable when disabled) This error Message only seems to appear when IIS is restarted and the page is requested for the first time. Once this error appears the file seems to be locked and it cannot be deleted. PHP.ini Changes are Extensions Loaction of Log files and TMP upload directory. WSDL temp directory Reproduce code: --- echo 'test'; Expected result: See Test String Actual result: -- PHP has encountered an Access Violation at 0227A495 -- Edit bug report at http://bugs.php.net/?id=41046&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41046&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41046&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41046&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41046&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41046&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41046&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41046&r=needscript Try newer version:http://bugs.php.net/fix.php?id=41046&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41046&r=support Expected behavior:http://bugs.php.net/fix.php?id=41046&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41046&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41046&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41046&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41046&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41046&r=dst IIS Stability:http://bugs.php.net/fix.php?id=41046&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41046&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41046&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41046&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41046&r=mysqlcfg
#40426 [NEW]: POST problem with input image
From: develop at in-tech dot us Operating system: Windows XP Pro, Windows 2000 Svr PHP version: 4.4.4 PHP Bug Type: *General Issues Bug description: POST problem with input image Description: Using: I.E. 6, Firefox 2.0.0.1 and Opera 9, PHP 4.4.4, IIS 5.1 on XP PRO (development machine) and IIS 5 on Windows 2000 Server (production server). When using an input type of 'image' to submit a form, the name value is not initialized by my switch() script. If I change this to a standard input type of 'submit', the variable is initialized and recognized just fine: Reproduce code: --- //DOES NOT work if(!empty($_POST['somevalue'])) { switch($_POST['hiddenfieldname']) { case 'somecase': include 'page1.php'; break; } } else { include 'page2.php'; } //Works Fine if(!empty($_POST['somevalue'])) { switch($_POST['hiddenfieldname']) { case 'somecase': include 'page1.php'; break; } } else { include 'page2.php'; } Expected result: Script should include() page1.php Actual result: -- Includes() page2.php -- Edit bug report at http://bugs.php.net/?id=40426&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=40426&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=40426&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=40426&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=40426&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=40426&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=40426&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=40426&r=needscript Try newer version:http://bugs.php.net/fix.php?id=40426&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=40426&r=support Expected behavior:http://bugs.php.net/fix.php?id=40426&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=40426&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=40426&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=40426&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=40426&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=40426&r=dst IIS Stability:http://bugs.php.net/fix.php?id=40426&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=40426&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=40426&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=40426&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=40426&r=mysqlcfg
#15841 [Com]: CRLF to separate mail headers is incorrect
ID: 15841 Comment by: tech+ohtf dot cuc dot arg at onlineopinion dot com dot au Reported By: rha at juggernaut dot com dot au Status: No Feedback Bug Type: Mail related Operating System: Linux PHP Version: 4.1.2 Assigned To: yohgaki New Comment: The PHP documentation now asks for "\n" , which is correct for its implementation in Unix systems, so the bug as originally reported is solved. I can't comment on whether this change might have caused problems in Windows, but I assume not. Note: This was not just an issue with qmail; it also affected postfix's implementation of 'sendmail'. Previous Comments: [2006-07-11 20:03:01] bug at bug dot com nevermind, please delete my previous comment. qmail is broken and dead. let's just move forward instead of trying to support legacy software and holding technology back. please close this ticket and label it as "will not fix," which i suppose is the correct status. [2006-07-11 18:30:19] bug at bug dot com what php needs is to make the $headers argument for the mail() function an array instead of a string and then php will automagically put the correct line endings depending on what OS it's running on. \n for unix, \r\n for windows, \r for mac you can keep it backwards compatiable by accepting a string as well. also add another option in the php.ini to enable/disable the mangling of the header line endings. could we get an update on this bug please? [2005-07-27 16:01:55] mark at thelecks dot com So has there been any resolution to this? Has PHP made any modifications to their mail function? or provided a better work around? [2005-06-27 21:41:34] guy dot kastenbaum at filnet dot net I agree with @patpro, mail() should reformate the headers. This is my quick-and-dirty workaround (from a Q&D specialist) , in /etc/php.ini : sendmail_path = "unix2dos|dos2unix|sendmail -t -i" Guyzmo -- (don't let me programm after midnight) [2004-09-28 00:41:06] zap at cyborganic dot net I suddenly had header problems. Perhaps my host changed mail configs or updated PHP (they never reply to my email, so I don't ask many question). In any case, all my beautiful HTML emails were being sent out with broken headers that yturned them into ugly unreadable text and code. I am on a Unix server, so I changed all my /r/n newlines to /n. This fixed the issue immediately. If you find this happens to you, just use the appropriate newline characters for your host OS. THANKS for pointing out this bug! 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/15841 -- Edit this bug report at http://bugs.php.net/?id=15841&edit=1
#38771 [Fbk->Opn]: string POST data are converted to int
ID: 38771 User updated by: satanas at tech-at dot be Reported By: satanas at tech-at dot be -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Apache 10336100 PHP Version: 4.4.4 New Comment: Quite difficult to have the script side, this issue is coming from a module of Xoops CMS, and I've got no other issues with others forms, either no issue with the second form included in the page. If needed, I can create an access to the page that create the issue, a var_dump($POST) has been added to the PHP page to display the result. Previous Comments: [2006-09-10 18:27:20] [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 the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2006-09-10 18:20:58] satanas at tech-at dot be Here is a trace of the Ip packet transmitted Transmission Control Protocol, Src Port: 3470 (3470), Dst Port: http (80), Seq: 1468, Ack: 15177, Len: 108 Source port: 3470 (3470) Destination port: http (80) Sequence number: 1468(relative sequence number) Next sequence number: 1576(relative sequence number) Acknowledgement number: 15177(relative ack number) Header length: 20 bytes Flags: 0x0018 (PSH, ACK) Window size: 4984 Checksum: 0x4af3 [correct] Hypertext Transfer Protocol Content-Type: application/x-www-form-urlencoded\r\n Content-Length: 37\r\n \r\n Line-based text data: application/x-www-form-urlencoded to_userid=mhm&post_messages=Soumettre [2006-09-10 18:12:05] satanas at tech-at dot be Description: When submitting a form that contain a string value and defined as text, the POST variable is displayed as a integer. When filling the form with a text, the POST value is 0, when filling the form with ex 1234, the POST value is 1234. But strange is another form in the HTML page work perfectly Reproduce code: --- The Form that works: Trouver un utilisateur Recherche ChoixLes mots clés de moins de 3 caractères seront ignorés The form that create the issue: Ajouter un Contact Contact(s) Séparer par une , Maximum 3 Utilisateur(s) Expected result: on the form that create the issue if mhm is submitted to_userid=mhm (string(3)) post_messages= Soumettre (string(9)) Actual result: -- on the form that create the issue if mhm is submitted to_userid=0 (int(0)) post_messages= Soumettre (string(9)) if 1234 is submitted to_userid=int(1234) post_messages= Soumettre (string(9)) -- Edit this bug report at http://bugs.php.net/?id=38771&edit=1
#38771 [Opn]: string POST data are converted to int
ID: 38771 User updated by: satanas at tech-at dot be Reported By: satanas at tech-at dot be Status: Open Bug Type: Unknown/Other Function Operating System: Apache 10336100 PHP Version: 4.4.4 New Comment: Here is a trace of the Ip packet transmitted Transmission Control Protocol, Src Port: 3470 (3470), Dst Port: http (80), Seq: 1468, Ack: 15177, Len: 108 Source port: 3470 (3470) Destination port: http (80) Sequence number: 1468(relative sequence number) Next sequence number: 1576(relative sequence number) Acknowledgement number: 15177(relative ack number) Header length: 20 bytes Flags: 0x0018 (PSH, ACK) Window size: 4984 Checksum: 0x4af3 [correct] Hypertext Transfer Protocol Content-Type: application/x-www-form-urlencoded\r\n Content-Length: 37\r\n \r\n Line-based text data: application/x-www-form-urlencoded to_userid=mhm&post_messages=Soumettre Previous Comments: [2006-09-10 18:12:05] satanas at tech-at dot be Description: When submitting a form that contain a string value and defined as text, the POST variable is displayed as a integer. When filling the form with a text, the POST value is 0, when filling the form with ex 1234, the POST value is 1234. But strange is another form in the HTML page work perfectly Reproduce code: --- The Form that works: Trouver un utilisateur Recherche ChoixLes mots clés de moins de 3 caractères seront ignorés The form that create the issue: Ajouter un Contact Contact(s) Séparer par une , Maximum 3 Utilisateur(s) Expected result: on the form that create the issue if mhm is submitted to_userid=mhm (string(3)) post_messages= Soumettre (string(9)) Actual result: -- on the form that create the issue if mhm is submitted to_userid=0 (int(0)) post_messages= Soumettre (string(9)) if 1234 is submitted to_userid=int(1234) post_messages= Soumettre (string(9)) -- Edit this bug report at http://bugs.php.net/?id=38771&edit=1
#38771 [NEW]: string POST data are converted to int
From: satanas at tech-at dot be Operating system: Apache 10336100 PHP version: 4.4.4 PHP Bug Type: Unknown/Other Function Bug description: string POST data are converted to int Description: When submitting a form that contain a string value and defined as text, the POST variable is displayed as a integer. When filling the form with a text, the POST value is 0, when filling the form with ex 1234, the POST value is 1234. But strange is another form in the HTML page work perfectly Reproduce code: --- The Form that works: Trouver un utilisateur Recherche ChoixLes mots clés de moins de 3 caractères seront ignorés The form that create the issue: Ajouter un Contact Contact(s) Séparer par une , Maximum 3 Utilisateur(s) Expected result: on the form that create the issue if mhm is submitted to_userid=mhm (string(3)) post_messages= Soumettre (string(9)) Actual result: -- on the form that create the issue if mhm is submitted to_userid=0 (int(0)) post_messages= Soumettre (string(9)) if 1234 is submitted to_userid=int(1234) post_messages= Soumettre (string(9)) -- Edit bug report at http://bugs.php.net/?id=38771&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38771&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38771&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38771&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38771&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38771&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38771&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38771&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38771&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38771&r=support Expected behavior:http://bugs.php.net/fix.php?id=38771&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38771&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38771&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38771&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38771&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38771&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38771&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38771&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38771&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38771&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38771&r=mysqlcfg
#37445 [Com]: Reproducible segfault
ID: 37445 Comment by: greg dot smith at gr-tech dot net Reported By: dhrubab at gmail dot com Status: Assigned Bug Type: PDO related Operating System: Linux PHP Version: 5.1.4 Assigned To: wez New Comment: I have reproduced the bug on Centos 4 64bit and 32 bit and Fedora core 5 as well as Suse 10.1 Previous Comments: [2006-05-15 12:40:11] indeyets at gmail dot com reverting this diff helps to solve problem, while the proper resolution is not available: http://cvs.php.net/viewcvs.cgi/php-src/ext/pdo_mysql/mysql_statement.c?r1=1.48.2.12&r2=1.48.2.13 [2006-05-15 10:20:58] dhrubab at gmail dot com A note to say I'm using latest php (5.1.4), mysql (5.0.21), pecl-pdo (1.0.3) and pecl-pdo-mysql (1.0.2). The example code relies on mysql5 default tables being there. [2006-05-15 10:01:57] dhrubab at gmail dot com Description: The provided code causes a segfault. My php.ini settings are as below. short_open_tag = Off allow_call_time_pass_reference = Off error_reporting = E_ALL display_errors = On display_startup_errors = On log_errors = Off variables_order = "GPCS" register_globals = Off register_long_arrays = Off register_argc_argv = Off magic_quotes_gpc = Off magic_quotes_runtime = Off allow_url_fopen = On session.name = GRTSESSID session.use_trans_sid = 0 session.hash_function = 1 session.hash_bits_per_character = 5 My configure is as below. './configure' '--prefix=/usr/lib/php5' '--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=shared' '--enable-calendar=shared' '--with-curl=shared' '--with-curlwrappers=shared' '--disable-dbase' '--enable-exif=shared' '--without-fbsql' '--without-fdftk' '--disable-filepro' '--enable-ftp=shared' '--with-gettext=shared' '--without-gmp' '--without-hwapi' '--without-informix' '--disable-ipv6' '--without-kerberos' '--enable-mbstring=shared' '--with-mcrypt=shared' '--disable-memory-limit' '--with-mhash=shared' '--without-ming' '--without-msql' '--without-mssql' '--with-ncurses=shared' '--with-openssl' '--with-openssl-dir=/usr' '--enable-pcntl=shared' '--disable-pdo' '--without-pgsql' '--with-pspell=shared' '--without-recode' '--disable-shmop' '--without-snmp' '--enable-soap=shared' '--enable-sockets=shared' '--without-sybase' '--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem' '--disable-sysvshm' '--with-tidy=shared' '--enable-wddx=shared' '--with-xmlrpc=shared' '--with-xsl=shared' '--with-zlib=shared' '--enable-debug' '--without-cdb' '--without-db4' '--without-flatfile' '--without-gdbm' '--without-inifile' '--without-qdbm' '--with-freetype-dir=/usr' '--with-t1lib=/usr' '--disable-gd-jis-conv' '--enable-gd-native-ttf' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--without-xpm-dir' '--with-gd' '--with-imap=shared' '--with-imap-ssl' '--with-mysql=shared,/usr/lib/mysql' '--with-mysql-sock=/var/run/mysqld/mysqld.sock' '--with-mysqli=shared,/usr/bin/mysql_config' '--with-readline' '--without-libedit' '--without-mm' '--enable-sqlite-utf8' My full phpinfo() is below. http://www.dhruba.net/files/segfault.phpinfo.html This is simply one example of a segfault. Our application is segfaulting left, right and centre and I am trying to narrow down other test cases that result in segfaults. The main point is that PHP or PDO whichever is the culprit is not giving error messages or exceptions as it should when there's something wrong and instead segfaulting. When you use a method name that doesn't exist or a class constant that doesn't exist or when you violate allow_call_time_pass_reference = Off then a segfault occurs. This has been reproduced on three machines with three different linux distributions. Reproduce code: --- The source code is below.
#30712 [Com]: Error Message
ID: 30712 Comment by: tech at juuce dot com Reported By: Colin at wnds dot co dot uk Status: No Feedback Bug Type: *Web Server problem Operating System: Windows server 200 PHP Version: 4.3.9 New Comment: I am experiencing the exact same error on WINDOWS IIS6 PHP 4.3.10 PHP has encountered an Access Violation at 77F470FE Script dies when ONLY when I use HTTPS and works fine on standard http request. Also will add that I use nuSOAP(recommended) to connect to the service. cURL and openSSL extensions are visible (and required) on the phoinfo(); page. I have noticed a few posts on this bug but they were mainly for php 5.0 and I believe these were fixed in the latest 5 release. My problem is that I cannot upgrade to 5. I cannot find a resolution for phpv4x Hopefully, at time of writing 4.4.2 will have it resolved...? I have also heard that it only happens when the server has a heavey load... My error seems to happen constantly. Previous Comments: [2004-11-15 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". [2004-11-07 12:53:50] [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 avoid embedding huge scripts into the report. [2004-11-07 12:49:25] Colin at wnds dot co dot uk Description: Hi I am getting the following error on my site and no one know what it means, can you help? PHP has encountered an Access Violation at 77F470FE It happens when customers follow links to next page, but only happens 1 in 10 times. Regards Colin -- Edit this bug report at http://bugs.php.net/?id=30712&edit=1
#36490 [Bgs]: Constructor method name for the inherited Exception class
ID: 36490 User updated by: tech at vosys dot com dot br Reported By: tech at vosys dot com dot br Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux / Windows PHP Version: 5.1.2 New Comment: Sorry, really so sorry. Previous Comments: [2006-02-22 21:57:27] [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 The name should be __construct, not __constructor... [2006-02-22 21:52:27] tech at vosys dot com dot br Description: I used the constructor method name like __constructor for an Exception class. When I tried get a attribute value from a catch{} block this is not returned. When I set the constructor method name like the class name works well. Reproduce code: --- class Except extends Exception{// SIMPLE CLASS FOR ERROR MANAGEMENT private $e = ''; public function __construcor($msg){ $this->e = $msg; } public function getErrorMessage(){ return $this->e; } } class Test{// CLASS FOR SIMPLE TEST public function Test($info){ try{ if ($info != 'ok'){ throw new Except('Error Simulation'); }else{ throw new Except('Positive Simulation'); } }catch(Exception $e){ throw $e; } } } try{// ERROR SIMULATION $objXtpo = new Test('hi'); }catch(Exception $e){ echo('Exception is: '. $e->getErrorMessage()); } Expected result: Exception is: Error Simulation Actual result: -- Exception is: -- Edit this bug report at http://bugs.php.net/?id=36490&edit=1
#36490 [NEW]: Constructor method name for the inherited Exception class
From: tech at vosys dot com dot br Operating system: Linux / Windows PHP version: 5.1.2 PHP Bug Type: Scripting Engine problem Bug description: Constructor method name for the inherited Exception class Description: I used the constructor method name like __constructor for an Exception class. When I tried get a attribute value from a catch{} block this is not returned. When I set the constructor method name like the class name works well. Reproduce code: --- class Except extends Exception{// SIMPLE CLASS FOR ERROR MANAGEMENT private $e = ''; public function __construcor($msg){ $this->e = $msg; } public function getErrorMessage(){ return $this->e; } } class Test{// CLASS FOR SIMPLE TEST public function Test($info){ try{ if ($info != 'ok'){ throw new Except('Error Simulation'); }else{ throw new Except('Positive Simulation'); } }catch(Exception $e){ throw $e; } } } try{// ERROR SIMULATION $objXtpo = new Test('hi'); }catch(Exception $e){ echo('Exception is: '. $e->getErrorMessage()); } Expected result: Exception is: Error Simulation Actual result: -- Exception is: -- Edit bug report at http://bugs.php.net/?id=36490&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=36490&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=36490&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=36490&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=36490&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=36490&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=36490&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=36490&r=needscript Try newer version:http://bugs.php.net/fix.php?id=36490&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=36490&r=support Expected behavior:http://bugs.php.net/fix.php?id=36490&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=36490&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=36490&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=36490&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36490&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=36490&r=dst IIS Stability:http://bugs.php.net/fix.php?id=36490&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=36490&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=36490&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=36490&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=36490&r=mysqlcfg
#25876 [Com]: session_start(): Failed to initialize storage module
ID: 25876 Comment by: tech at c64-wiki dot de Reported By: golden at riscom dot com Status: No Feedback Bug Type: Session related Operating System: freebsd 4.8 PHP Version: 4.3.9-4.3.10 Assigned To: sniper New Comment: I added the following line near the beginning of my PHP code: ini_set("session.save_handler", "files"); I have not seen the bug again after that, so far (clicked around like an idiot and everything worked fine). Which does not mean a lot, of course, due to the extremely random nature of that bug. Can anybody else confirm that this workaround works (or maybe not)? If it does "solve" the problem, the root cause may seem to be that PHP sometimes takes the wrong session handler (not the one which is defined in PHP.INI, which is "files" as well (while the error message seems to indicate "user"?)). Best regards, Klaus Previous Comments: ---- [2005-06-08 14:18:42] tech at c64-wiki dot de Same problem here as described by "gul_murjani at yahoo dot com". PHP 4.3.10 is the version in use (phpinfo() can be seen at http://www.c64-wiki.de/test.php). I tried to change session.save_path to a different path (by adding a php_value line into .htaccess), made the new directory world-writeable and verified that the session files do indeed appear there. They do appear there, and there's plenty of space for that directoty available (about 1GB, should be 'nuff for a few of these session files with <100 bytes each). And the bug still appears at extremely random intervals! Best regards, Klaus [2005-05-22 12:06:42] dmih at in-solve dot ru Please someone in PHP team confirm that you are reading from this bug (it has 'No Feedback' status). Or may be we are writing for ourselves here? [2005-05-21 14:30:13] gul_murjani at yahoo dot com Hi, I'm experiencing this problem in at least 2 sites. Since it's a error that appears in random, I wrote a simple script to try and reproduce the error. This is the script: All it does is invoke "session_start()" and use one session variable. It then reloads itself every 10 seconds. On HOSTMANIL.ORG and HOSTMANIL.NET, the error comes up. But there is no pattern at all. Sometimes out of 20 refreshes, there's an error, half the time. If the error comes up, I have to do a manual refresh. I notice that the session variable is not destroyed at all. It continues counting from where it stopped. The problem is at one point in HOSTMANILA.ORG, it kept on coming up every 2 auto refreshes (and I do an F5). But now, it's was good for 45 straign auto refreshes before the error came up. That's how random the error is. I do a lot of programming, mostly in PHP but I'm not "deep" technical. So I'm not sure if I'm missing something. I'm running the scripts on 5 sites. These are all on different servers although all of them are from shared hosting services using cPanel / WHM. http://www.hostmanila.org/test.php http://www.hostmanila.biz/test.php http://www.hostmanila.net/test.php http://www.vcdpix.com/test.php http://www.smokedbangus.com/test.php So far, it's only happened on HOSTMANILA.ORG and HOSTMANILA.NET. Here's the rundown on each site: HOSTMANILA.ORG (error) Linux 2.4.30-gator_r1 Apache 1.3.33 (Unix) PERL 5.8.4 PHP 4.3.11 cPanel 9.9.9-STABLE 15 HOSTMANILA.BIZ (fine) Linux 2.4.30-1-s5 Apache 1.3.33 (Unix) PERL 5.8.3 PHP 4.3.11 cPanel 10.2.0-RELEASE 82 HOSTMANILA.NET (error) Linux 2.4.26-grsec Apache 1.3.33 (Unix) PERL 5.8.0 PHP 4.3.11 cPanel 10.0.0-RELEASE 7 VCDPIX.COM (fine) Linux 2.4.20-24.9 Apache 1.3.33 (Unix) PERL 5.8.1 PHP 4.3.9 cPanel 10.0.0-RELEASE 7 SMOKEDBANGUS.COM (fine) Linux 2.4.20-20.7smp Apache 1.3.33 (Unix) PERL 5.8.4 PHP 4.3.10 cPanel 10.0.0-CURRENT 107 I can't imagine developing anything in PHP without making use of session_start() so I hope the issue is resolved. Regards, Gul hostmanila.com [2005-05-21 01:24:55] jspec at bellsouth dot net I have now experienced this beast with a completely different hosting company. They are both running 4.3.10 - is this fixed in 4.3.11? [2005-05-18 22:48:45] dmih at in-solve dot ru We (as hosting company) are hoping that PHP team will track this bug down some day. Indeed, we can do not much to help or to fix it. This bug is hard to fix because it appears randomly, and there is no definite recreate scenario. There is assumption that this is http://bugs.php.net/bug.php?id=32330 bug, but I am not completely sure
#25876 [Com]: session_start(): Failed to initialize storage module
ID: 25876 Comment by: tech at c64-wiki dot de Reported By: golden at riscom dot com Status: No Feedback Bug Type: Session related Operating System: freebsd 4.8 PHP Version: 4.3.9-4.3.10 Assigned To: sniper New Comment: Same problem here as described by "gul_murjani at yahoo dot com". PHP 4.3.10 is the version in use (phpinfo() can be seen at http://www.c64-wiki.de/test.php). I tried to change session.save_path to a different path (by adding a php_value line into .htaccess), made the new directory world-writeable and verified that the session files do indeed appear there. They do appear there, and there's plenty of space for that directoty available (about 1GB, should be 'nuff for a few of these session files with <100 bytes each). And the bug still appears at extremely random intervals! Best regards, Klaus Previous Comments: [2005-05-22 12:06:42] dmih at in-solve dot ru Please someone in PHP team confirm that you are reading from this bug (it has 'No Feedback' status). Or may be we are writing for ourselves here? [2005-05-21 14:30:13] gul_murjani at yahoo dot com Hi, I'm experiencing this problem in at least 2 sites. Since it's a error that appears in random, I wrote a simple script to try and reproduce the error. This is the script: All it does is invoke "session_start()" and use one session variable. It then reloads itself every 10 seconds. On HOSTMANIL.ORG and HOSTMANIL.NET, the error comes up. But there is no pattern at all. Sometimes out of 20 refreshes, there's an error, half the time. If the error comes up, I have to do a manual refresh. I notice that the session variable is not destroyed at all. It continues counting from where it stopped. The problem is at one point in HOSTMANILA.ORG, it kept on coming up every 2 auto refreshes (and I do an F5). But now, it's was good for 45 straign auto refreshes before the error came up. That's how random the error is. I do a lot of programming, mostly in PHP but I'm not "deep" technical. So I'm not sure if I'm missing something. I'm running the scripts on 5 sites. These are all on different servers although all of them are from shared hosting services using cPanel / WHM. http://www.hostmanila.org/test.php http://www.hostmanila.biz/test.php http://www.hostmanila.net/test.php http://www.vcdpix.com/test.php http://www.smokedbangus.com/test.php So far, it's only happened on HOSTMANILA.ORG and HOSTMANILA.NET. Here's the rundown on each site: HOSTMANILA.ORG (error) Linux 2.4.30-gator_r1 Apache 1.3.33 (Unix) PERL 5.8.4 PHP 4.3.11 cPanel 9.9.9-STABLE 15 HOSTMANILA.BIZ (fine) Linux 2.4.30-1-s5 Apache 1.3.33 (Unix) PERL 5.8.3 PHP 4.3.11 cPanel 10.2.0-RELEASE 82 HOSTMANILA.NET (error) Linux 2.4.26-grsec Apache 1.3.33 (Unix) PERL 5.8.0 PHP 4.3.11 cPanel 10.0.0-RELEASE 7 VCDPIX.COM (fine) Linux 2.4.20-24.9 Apache 1.3.33 (Unix) PERL 5.8.1 PHP 4.3.9 cPanel 10.0.0-RELEASE 7 SMOKEDBANGUS.COM (fine) Linux 2.4.20-20.7smp Apache 1.3.33 (Unix) PERL 5.8.4 PHP 4.3.10 cPanel 10.0.0-CURRENT 107 I can't imagine developing anything in PHP without making use of session_start() so I hope the issue is resolved. Regards, Gul hostmanila.com [2005-05-21 01:24:55] jspec at bellsouth dot net I have now experienced this beast with a completely different hosting company. They are both running 4.3.10 - is this fixed in 4.3.11? [2005-05-18 22:48:45] dmih at in-solve dot ru We (as hosting company) are hoping that PHP team will track this bug down some day. Indeed, we can do not much to help or to fix it. This bug is hard to fix because it appears randomly, and there is no definite recreate scenario. There is assumption that this is http://bugs.php.net/bug.php?id=32330 bug, but I am not completely sure. You may suggest your hosting company to lower average server load - it will help this bug to happen rarely or even at no times. Lower - I mean - something lower than 50% avg CPU load on 1CPU server or 80% on 2+ CPU server. But that is only our hosting company workaround, not the solution. [2005-05-17 18:00:36] jspec at bellsouth dot net My hosting company is unable to fix the random "Failed to initialize storage module" error and it is making my account unusable. They cannot seem to fix it. What is the story with this!? 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/25876 -- Edit this bug report at http://bugs.php.net/?id=25876&edit=1
#31931 [Com]: image upload returns path and red cross
ID: 31931 Comment by: tech at rzpressure dot co dot uk Reported By: website at cellpacksolutions dot com Status: Open Bug Type: HTTP related Operating System: linux PHP Version: 4CVS-2005-02-11 (stable) Assigned To: iliaa New Comment: i get this to, it seems as though basename is no longer stripping windows paths. mind this seems to only affect ie browsers! Previous Comments: [2005-02-14 12:36:35] website at cellpacksolutions dot com I have tried using the basic upload code posted on the following thread: http://www.phpfreaks.com/forums/index.php?showtopic=52077&pid=202571&st=0&#entry202571 which returns: File (C:\\SEARCH PROGRAM\\product_pics\\3b880.jpg) uploaded! testupload C:\\SEARCH PROGRAM\\product_pics\\3b880.jpg jpg scrolling over and selecting properties of the link shows: http://domainname.co.uk/testupload/C://SEARCH this is using the latest cvs version 9 am this morning! [2005-02-14 12:23:52] website at cellpacksolutions dot com just recieved this comment from our hosts this morning: We have tested the most recent available snapshot (9:30am) and the bug regarding PHP file uploads is still present. I would advise using the temporary workaround (all it does is remove everything upto and include the final \ thus providing you with only the filename) until the issue is resolved with PHP 4.3.11. As advised, unfortunately we are unable to revert back to 4.3.10 as this contains severe vulnerabilities which we are unable to allow to exist on our systems. I will leave this ticket suspended in our queue and when we have further information for you we will mail you again. [2005-02-12 17:48:18] [EMAIL PROTECTED] Already fixed in CVS. (Can't reproduce with it) [2005-02-12 02:33:53] [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-02-11 18:13:36] [EMAIL PROTECTED] Ilia, you "broke" it. :) For the reportee: Provide 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/31931 -- Edit this bug report at http://bugs.php.net/?id=31931&edit=1
#31830 [NEW]: mssql_query do not return any thing while the query really executed
From: tsaid at sana-tech dot com Operating system: windows PHP version: 5.0.3 PHP Bug Type: *Database Functions Bug description: mssql_query do not return any thing while the query really executed Description: When you use mssql_query to insert or update data, the returned result is false but the query is really executed. So you don't know if the query was really executed or not :/ -- Edit bug report at http://bugs.php.net/?id=31830&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31830&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31830&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31830&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31830&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31830&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31830&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31830&r=needscript Try newer version: http://bugs.php.net/fix.php?id=31830&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31830&r=support Expected behavior: http://bugs.php.net/fix.php?id=31830&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31830&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31830&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31830&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31830&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31830&r=dst IIS Stability: http://bugs.php.net/fix.php?id=31830&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31830&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31830&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31830&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31830&r=mysqlcfg
#31108 [Com]: Upgrading to PHP 4.3.10 brakes several applications
ID: 31108 Comment by: php-bugs-041216 at Tech dot FutureQuest dot net Reported By: pierre at zenutech dot com Status: Open Bug Type: *General Issues Operating System: Red Hat 9 - Linux PHP Version: 4.3.10 New Comment: Ran into the same problem with 'foreach' during preliminary testing... The solution is to ensure that your ZendOptimizer has been upgraded to a minimum of 2.5.7... -- Terra Previous Comments: [2004-12-16 03:22:49] pierre at zenutech dot com Description: Hi, We are running php-4.3.9 with Apache 1.3.33 on red hat 9 linux, kernel 2.4.x (latest version). Upgrading to php-4.3.10 broke several web sites using "postnuke" software, and also broke our webmail application. (and perhaps other things but decided to revert back to avoid frustrating customers) We were using the exact same config (php.ini and apache) between the two versions. In postnuke, we received: Fatal error: Call to undefined function: themeheader() in /home/(userhere)/public_html/header.php on line 206 Now looking at the error log of this user before the upgrade, we see: round-4.gif [Wed Dec 15 17:17:08 2004] [error] [client 156.34.155.69] File does not exist: /home/(userhere)/public_html/themes/CorpBlue/images/backg round-4.gif [Wed Dec 15 17:17:15 2004] [error] [client 24.141.52.184] File does not exist: /home/(userhere)/public_html/themes/CorpBlue/images/backg round-4.gif [Wed Dec 15 17:17:16 2004] [error] [client 209.217.93.107] File does not exist: /home/(userhere)/public_html/themes/CorpBlue/images/back ground-4.gif Now after upgrading to php-4.3.10, we see: [Wed Dec 15 17:17:53 2004] [error] [client 24.222.246.27] File does not exist: /home/(userhere)/public_html/themes//style/styleNN.css [Wed Dec 15 17:17:53 2004] [error] [client 24.222.246.27] File does not exist: /home/(userhere)/public_html/themes//style/style.css [Wed Dec 15 17:17:56 2004] [error] [client 209.217.93.107] File does not exist: /home/(userhere)/public_html/themes//style/styleNN.css As you can see, the "style" variable doesn't seem to get properly defined. At first I thought it was a postnuke (http://www.postnuke.com) bug, but after it also crashed our webmail application v-webmail (http://webmail.zenutech.com), I doubt it would be postnuke's fault. V-webmail doesn't provide stuff in error log, but have found what seems to be causing problems: * Get list of languages. Needs formating * into usable array. */ foreach($LANGUAGES as $key => $value){ $selected = $key == $CONFIG['default_lang'] ? 'selected="selected"' : ''; $languages[] = array('code' => $key, 'desc' => $value, 'selected' => $selected); } appears to return 0 results, whereas in the previous version of php (php-4.3.9), it works fine. I understand that the information I have submitted doesn't give you much to work with, but to be honest with you, it is the most I could find. For now I am obligated to run on 4.3.9 and I cannot provide more info regarding 4.3.10 because I don't really have the flexibility and time of setting up a "test" box. I hope we can find a solution. Regards, Pierre Grandmaison -- Edit this bug report at http://bugs.php.net/?id=31108&edit=1
#30958 [Fbk->Opn]: Wrong instance returned with 2 singletons
ID: 30958 User updated by: schaa101 at tech dot nhl dot nl Reported By: schaa101 at tech dot nhl dot nl -Status: Feedback +Status: Open Bug Type: Class/Object related Operating System: Windows XP Pro SP2 PHP Version: 5.0.2 New Comment: instance == null ) $this->instance = new Singleton1(); return $this->instance; } public function Write( $message ) { print "Singleton1 - " . $message; } } class Singleton2 { private $instance = null; private function __Construct() { } public function & GetInstance() { if( $this->instance == null ) $this->instance = new Singleton2(); return $this->instance; } public function Write( $message ) { print "Singleton2 - " . $message; } } class Main { public function __Construct() { Singleton1::GetInstance()->Write( "Singleton1" ); echo ""; Singleton2::GetInstance()->Write( "Singleton2" ); } } new Main(); ?> Previous Comments: [2004-12-02 11:10:41] [EMAIL PROTECTED] Please post the code here. ---- [2004-12-02 11:09:30] schaa101 at tech dot nhl dot nl Description: When you use 2 singletons, the second singeleton also returns the instance of the first. If you change the name of the variables, that store the instance of the singleton class, inside the singletons and make them both unique, the problem is solved though. Reproduce code: --- http://klaas.fiskaaf.com/singleton-bug.rar or try http://klaas.fiskaaf.com/singleton-bug.zip Expected result: Singleton1 - Singleton1 Singleton2 - Singleton2 Actual result: -- Singleton1 - Singleton1 Singleton1 - Singleton2 -- Edit this bug report at http://bugs.php.net/?id=30958&edit=1
#30958 [NEW]: Wrong instance returned with 2 singletons
From: schaa101 at tech dot nhl dot nl Operating system: Windows XP Pro SP2 PHP version: 5.0.2 PHP Bug Type: Class/Object related Bug description: Wrong instance returned with 2 singletons Description: When you use 2 singletons, the second singeleton also returns the instance of the first. If you change the name of the variables, that store the instance of the singleton class, inside the singletons and make them both unique, the problem is solved though. Reproduce code: --- http://klaas.fiskaaf.com/singleton-bug.rar or try http://klaas.fiskaaf.com/singleton-bug.zip Expected result: Singleton1 - Singleton1 Singleton2 - Singleton2 Actual result: -- Singleton1 - Singleton1 Singleton1 - Singleton2 -- Edit bug report at http://bugs.php.net/?id=30958&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30958&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30958&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30958&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30958&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30958&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30958&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30958&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30958&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30958&r=support Expected behavior: http://bugs.php.net/fix.php?id=30958&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30958&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30958&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30958&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30958&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30958&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30958&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30958&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30958&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30958&r=mysqlcfg
#30290 [NEW]: float comparison doesn't work
From: tech at mediaforest dot net Operating system: Linux Debian 3 PHP version: 4.3.8 PHP Bug Type: *Math Functions Bug description: float comparison doesn't work Description: When comparing two floats php find them different Bug already reported but not solved : Bug #17984, Bug #25936, Bug #17282, Bug #23780, -- Edit bug report at http://bugs.php.net/?id=30290&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30290&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30290&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30290&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=30290&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=30290&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=30290&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=30290&r=needscript Try newer version: http://bugs.php.net/fix.php?id=30290&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=30290&r=support Expected behavior: http://bugs.php.net/fix.php?id=30290&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=30290&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=30290&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=30290&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30290&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=30290&r=dst IIS Stability: http://bugs.php.net/fix.php?id=30290&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=30290&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=30290&r=float MySQL Configuration Error: http://bugs.php.net/fix.php?id=30290&r=mysqlcfg
#28438 [NEW]: #ifdef ZTS missing around zend_execute_API.c:1107
From: ericb at summit-tech dot ca Operating system: Win2k PHP version: 5.0.0RC2 PHP Bug Type: Compile Failure Bug description: #ifdef ZTS missing around zend_execute_API.c:1107 Description: In zend_execute_API.c:1107 , >tsrm_ls = ts_resource_ex(0, &wParam); should only be included if ZTS is defined, since ts_resource_ex in TSRM.h needs /DZTS . Should be wrapped in an #ifdef ZTS / #endif block. This effectively prevents win32 builds with -disable-zts. Did not test unix build. -- Edit bug report at http://bugs.php.net/?id=28438&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28438&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28438&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28438&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28438&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28438&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28438&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28438&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28438&r=support Expected behavior: http://bugs.php.net/fix.php?id=28438&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28438&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28438&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28438&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28438&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28438&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28438&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28438&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28438&r=float
#27124 [NEW]: Serious problem in php application
From: info at websight-tech dot com Operating system: FreeBSD PHP version: 4.3.4 PHP Bug Type: Performance problem Bug description: Serious problem in php application Description: Hello, I have a PHP web application. While Iam browse it through IE, when I navigate through navigation buttons of the browser, I got some white blank space in my page under the menu. Menu is a php file,I am including it in my main file. Is it any problem related to the include file. If you want to recreate the problem,follow these steps. 1) url: www.quikmenu.com, browse it through IE 2)select "about us" link from menu 3)then simply go back with the back button of the browser, then u can see a blank white space under the menu In the about us page text in white sapce is the only thing that comes from about.php. Rest of the whole thing in blue is come from a page called uheader.php. I hope you understand my problem. Could you please send the solution as early as possible to [EMAIL PROTECTED] Regards, Websight Team. -- Edit bug report at http://bugs.php.net/?id=27124&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27124&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27124&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27124&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27124&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27124&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27124&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27124&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27124&r=support Expected behavior: http://bugs.php.net/fix.php?id=27124&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27124&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27124&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27124&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27124&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27124&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27124&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27124&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27124&r=float
#25129 [NEW]: Array_diff gives a bad result
From: tech at mediaforest dot net Operating system: Linux PHP version: Irrelevant PHP Bug Type: Arrays related Bug description: Array_diff gives a bad result Description: As this script shows, the array_diff function doesn't give the expected result on a php4.2.3 : Reproduce code: --- Expected result: array(1) { [0]=> string(12) "pic_0910.jpg" } Actual result: -- array(0) { } -- Edit bug report at http://bugs.php.net/?id=25129&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25129&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25129&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25129&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25129&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25129&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25129&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25129&r=support Expected behavior: http://bugs.php.net/fix.php?id=25129&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25129&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25129&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25129&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25129&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25129&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25129&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25129&r=gnused
#24003 [NEW]: after several connections to Oracle 9i, program dies
From: dkruger at stevens-tech dot edu Operating system: Redhat 8.0 PHP version: 4.3.2 PHP Bug Type: OCI8 related Bug description: after several connections to Oracle 9i, program dies The following code used to work on Oracle 8.0 on Solaris. Now, under Redhat 8.0 and Oracle 9i, when you run it several times in a row, it eventually seg faults and the only way to re-establish the connection is by restarting apache. Our PHP is built with ./configure --prefix=usr/local/php --with-gd=/usr/local --with-png-dir=/usr/local --with-oci8=/oracle --with-apx2=/usr/local/apache/bin/apxs --with-jpeg-dir=/usr --with-zlib-dir=/usr --with-xpm-dir=/usr --enable-debug --enable-sigchild This is not my code, and I do not use PHP, so I want to know first if there is a better way of writing this code. Can it successfully recover given that it dies for some reason on a query? Is there any more recoverable way of writing it? Even if it's not optimal code, it should be slightly more recoverable than this. print "Test"; putenv("ORACLE_SID=coastal"); putenv("ORACLE_HOME=/oracle"); putenv("TNS_ADMIN=/oracle/network/admin/tnsnames.ora"); $connection = OCILogon("user","xxx", "mydb") or die("Couldn't logon."); $sql = "select count(*) from x"; $sql_statement = OCIParse($connection,$sql) or die("Couldn't parse statement."); OCIExecute($sql_statement, OCI_DEFAULT) or die("Couldn't execute statement."); $num_columns = OCINumCols($sql_statement); OCIFreeStatement($sql_statement); OCILogoff($connection); PHP still runs after this code, as long as the page does not involve any other Oracle interaction. thanks! Dov -- Edit bug report at http://bugs.php.net/?id=24003&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=24003&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=24003&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24003&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24003&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24003&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24003&r=support Expected behavior: http://bugs.php.net/fix.php?id=24003&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24003&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24003&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24003&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24003&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24003&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24003&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24003&r=gnused
Bug #16886: Seg. fault on socket_close if socket died
From: [EMAIL PROTECTED] Operating system: Linux RedHat 7.2 PHP version: 4.0CVS-2002-04-28 PHP Bug Type: Sockets related Bug description: Seg. fault on socket_close if socket died I had that issue : I use a non blocking socket to read a data stream. I was assuming that if socket_read($socket) !== false then I should close the socket !! NO ! I must not ! If I close that socket, I have an error : 9975 Segmentation fault /usr/local/php-cgi/bin/php -q ./core.php I checked socket_last_error and I found : 104 : Connexion reset by peer It would be nice if the socket is checked before socket_close or socket_shutdown ... I don't know sockets system under Linux . I can't fix that :( To have the same error, create a socket, listen on it, accept accept that connexion. On the remote machine, close the telnet (kill or other :D) and then do socket_close on your socket. Then you have a seg. fault ! -- Edit bug report at http://bugs.php.net/?id=16886&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16886&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16886&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16886&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16886&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16886&r=support Expected behavior: http://bugs.php.net/fix.php?id=16886&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16886&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16886&r=submittedtwice
Bug #16852: Apache2 not compatible with php_admin_value, php_value, php_flag ....
From: [EMAIL PROTECTED] Operating system: Any PHP version: 4.0CVS-2002-04-26 PHP Bug Type: Apache2 related Bug description: Apache2 not compatible with php_admin_value, php_value, php_flag I'm running Apache 2.0.35 / PHP 4.2.0 under win32 (php as a module of Apache) and I can use php_admin,value, etc... I'm also running Apache 2.0.35 / PHP4.3.0-dev (Auto-updated at Midnight GMT+0200) and here too I can't use php_admin_value etc... I have friends with also PHP4.2.0 and Apache2 and they can't use php_admin_value . It seems to be a bug or something that isn't already done in the Apache2 module of php. Apache2's answer is : php_admin_value not allowed here. -- Edit bug report at http://bugs.php.net/?id=16852&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16852&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16852&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16852&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16852&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16852&r=support Expected behavior: http://bugs.php.net/fix.php?id=16852&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16852&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16852&r=submittedtwice
Bug #16680: socket_read() does not have the described behaviour ...
From: [EMAIL PROTECTED] Operating system: Windows 9x PHP version: 4.2.0 PHP Bug Type: Sockets related Bug description: socket_read() does not have the described behaviour ... In the documentation, it's written that socket_read() reads data from the socket until a \n, \t, \0 or until the end of the buffer. But under win32 it reads only 1 char. This would be fixed. Just use instead : $buf=""; while (substr($buf,-1)!="\n") { $buf.=socket_read($socket,1); } I've put 1 here, but you can write 16777216 it'll continue to give back only 1 char. -- Edit bug report at http://bugs.php.net/?id=16680&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16680&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16680&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16680&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16680&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16680&r=support Expected behavior: http://bugs.php.net/fix.php?id=16680&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16680&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16680&r=submittedtwice
Bug #16678: PHP crashes after some commands
From: [EMAIL PROTECTED] Operating system: Windows 9x PHP version: 4.2.0 PHP Bug Type: Sockets related Bug description: PHP crashes after some commands In the bug 16664 I saw an error on socket_bind(). This PHP crash isn't anymore present in the PHP 4.2.0RC4-win32 but (in the same version) there is the same crash (same error & call, same DLL ) on the socket_accept() command on non-blocking sockets. I think the person who fix the bug in the socket_bind command would be able to do the same on the socket_accept (after socket_set_nonblock) . Thx -- Edit bug report at http://bugs.php.net/?id=16678&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16678&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16678&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16678&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16678&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16678&r=support Expected behavior: http://bugs.php.net/fix.php?id=16678&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16678&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16678&r=submittedtwice
Bug #16664 Updated: PHP crashes on socket_bind
ID: 16664 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Sockets related Operating System: Windows 9x PHP Version: 4.2.0 New Comment: Oops !! I made an error, socket_bind returns 1 on success. True = -1 Previous Comments: [2002-04-18 09:17:28] [EMAIL PROTECTED] The CSV version doesn't include this bug anymore. Just one more thing : socket_bind() returns '' on success ... [2002-04-18 07:34:08] [EMAIL PROTECTED] This problem doesn't happens on w2k ... It's w9x specific problem (win95 is also concerned). PS: My test code was found in the documentation. I've updated my code ... PS2: I'll look in the source and do some tries to find a way to fix this bug (I have VC++, I could use another compiler but I have only this one). I know it's a bind error and if the IP is changed to "" no error happens ... [2002-04-18 07:21:39] [EMAIL PROTECTED] Ok, I can't reproduce this on w2k (I don't have a w98 system to test). First, try if it works on w2k for you. If it works, we know it's w98 system problem and we can dig furhter into that direction. Second, your return checking's aren't very good. socket_create() returns either resource or false, but not something which we would say is '< 0'. The same for socket_bind(), it returns an boolean, true or false, nothing else. (that's from the source, the documentation on php.net is outdated as there have been recent changes to the sources). [2002-04-18 06:20:11] [EMAIL PROTECTED] The category has changed to PDF functions (I made a mistake while filling the form ?? ). Changing back to 'Socket related' ... [2002-04-18 06:18:49] [EMAIL PROTECTED] Here is a small example of script ... if (($sock = socket_create (AF_INET, SOCK_STREAM, 0)) < 0) { echo "socket_create() failed: reason: " . socket_strerror ($sock) . "\n"; } if (($ret = socket_bind ($sock, '127.0.0.1', 1)) < 0) { echo "socket_bind() failed: reason: " . socket_strerror ($ret) . "\n"; } PHP crashes here, on the socket_bind command. This script was found on the page about the socket functions. I've downloaded the last RC version but it also crashes. I have the window's dialog with 'Close', 'Debug' or 'Deltails >>' ... 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/16664 -- Edit this bug report at http://bugs.php.net/?id=16664&edit=1
Bug #16664 Updated: PHP crashes on socket_bind
ID: 16664 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Sockets related Operating System: Windows 9x PHP Version: 4.2.0 New Comment: The CSV version doesn't include this bug anymore. Just one more thing : socket_bind() returns '' on success ... Previous Comments: [2002-04-18 07:34:08] [EMAIL PROTECTED] This problem doesn't happens on w2k ... It's w9x specific problem (win95 is also concerned). PS: My test code was found in the documentation. I've updated my code ... PS2: I'll look in the source and do some tries to find a way to fix this bug (I have VC++, I could use another compiler but I have only this one). I know it's a bind error and if the IP is changed to "" no error happens ... [2002-04-18 07:21:39] [EMAIL PROTECTED] Ok, I can't reproduce this on w2k (I don't have a w98 system to test). First, try if it works on w2k for you. If it works, we know it's w98 system problem and we can dig furhter into that direction. Second, your return checking's aren't very good. socket_create() returns either resource or false, but not something which we would say is '< 0'. The same for socket_bind(), it returns an boolean, true or false, nothing else. (that's from the source, the documentation on php.net is outdated as there have been recent changes to the sources). [2002-04-18 06:20:11] [EMAIL PROTECTED] The category has changed to PDF functions (I made a mistake while filling the form ?? ). Changing back to 'Socket related' ... [2002-04-18 06:18:49] [EMAIL PROTECTED] Here is a small example of script ... if (($sock = socket_create (AF_INET, SOCK_STREAM, 0)) < 0) { echo "socket_create() failed: reason: " . socket_strerror ($sock) . "\n"; } if (($ret = socket_bind ($sock, '127.0.0.1', 1)) < 0) { echo "socket_bind() failed: reason: " . socket_strerror ($ret) . "\n"; } PHP crashes here, on the socket_bind command. This script was found on the page about the socket functions. I've downloaded the last RC version but it also crashes. I have the window's dialog with 'Close', 'Debug' or 'Deltails >>' ... [2002-04-17 16:03:32] [EMAIL PROTECTED] Please provide a short, self-contained sample (see the bug's do's and don'ts). 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/16664 -- Edit this bug report at http://bugs.php.net/?id=16664&edit=1
Bug #16664 Updated: PHP crashes on socket_bind
ID: 16664 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Sockets related -Operating System: Windows 98 +Operating System: Windows 9x PHP Version: 4.2.0 New Comment: This problem doesn't happens on w2k ... It's w9x specific problem (win95 is also concerned). PS: My test code was found in the documentation. I've updated my code ... PS2: I'll look in the source and do some tries to find a way to fix this bug (I have VC++, I could use another compiler but I have only this one). I know it's a bind error and if the IP is changed to "" no error happens ... Previous Comments: [2002-04-18 07:21:39] [EMAIL PROTECTED] Ok, I can't reproduce this on w2k (I don't have a w98 system to test). First, try if it works on w2k for you. If it works, we know it's w98 system problem and we can dig furhter into that direction. Second, your return checking's aren't very good. socket_create() returns either resource or false, but not something which we would say is '< 0'. The same for socket_bind(), it returns an boolean, true or false, nothing else. (that's from the source, the documentation on php.net is outdated as there have been recent changes to the sources). [2002-04-18 06:20:11] [EMAIL PROTECTED] The category has changed to PDF functions (I made a mistake while filling the form ?? ). Changing back to 'Socket related' ... [2002-04-18 06:18:49] [EMAIL PROTECTED] Here is a small example of script ... if (($sock = socket_create (AF_INET, SOCK_STREAM, 0)) < 0) { echo "socket_create() failed: reason: " . socket_strerror ($sock) . "\n"; } if (($ret = socket_bind ($sock, '127.0.0.1', 1)) < 0) { echo "socket_bind() failed: reason: " . socket_strerror ($ret) . "\n"; } PHP crashes here, on the socket_bind command. This script was found on the page about the socket functions. I've downloaded the last RC version but it also crashes. I have the window's dialog with 'Close', 'Debug' or 'Deltails >>' ... [2002-04-17 16:03:32] [EMAIL PROTECTED] Please provide a short, self-contained sample (see the bug's do's and don'ts). [2002-04-17 13:32:08] [EMAIL PROTECTED] When I attempt to bind a socket with socket_bind, PHP crashes. It doesn't crash if the IP to bind to is an mepty string ("") ... I have this error in the crash dialog : PHP a causé une défaillance de page dans le module MSVCRT.DLL à 0167:78011f41. Registres : EAX=2741 CS=0167 EIP=78011f41 EFLGS=00010206 EBX=0073 SS=016f ESP=0063ee90 EBP=0063f0e4 ECX=2741 DS=016f ESI=7ffe FS=c617 EDX=7fff ES=016f EDI=01447538 GS= Octets à CS : EIP : 80 38 00 74 03 40 eb f1 2b c1 e9 85 fe ff ff c7 État de la pile : 0002 01172d94 000c 00023c30 bff7b30e 0041 bff7b317 0041 0001 00413768 00023c30 0041374c 0063ef0c bff7b953 0041 (it's in French and my windows is French ... sorry :D ) -- Edit this bug report at http://bugs.php.net/?id=16664&edit=1
Bug #16664 Updated: PHP crashes on socket_bind
ID: 16664 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: *PDF functions +Bug Type: Sockets related Operating System: Windows 98 PHP Version: 4.2.0 New Comment: The category has changed to PDF functions (I made a mistake while filling the form ?? ). Changing back to 'Socket related' ... Previous Comments: [2002-04-18 06:18:49] [EMAIL PROTECTED] Here is a small example of script ... if (($sock = socket_create (AF_INET, SOCK_STREAM, 0)) < 0) { echo "socket_create() failed: reason: " . socket_strerror ($sock) . "\n"; } if (($ret = socket_bind ($sock, '127.0.0.1', 1)) < 0) { echo "socket_bind() failed: reason: " . socket_strerror ($ret) . "\n"; } PHP crashes here, on the socket_bind command. This script was found on the page about the socket functions. I've downloaded the last RC version but it also crashes. I have the window's dialog with 'Close', 'Debug' or 'Deltails >>' ... [2002-04-17 16:03:32] [EMAIL PROTECTED] Please provide a short, self-contained sample (see the bug's do's and don'ts). [2002-04-17 13:32:08] [EMAIL PROTECTED] When I attempt to bind a socket with socket_bind, PHP crashes. It doesn't crash if the IP to bind to is an mepty string ("") ... I have this error in the crash dialog : PHP a causé une défaillance de page dans le module MSVCRT.DLL à 0167:78011f41. Registres : EAX=2741 CS=0167 EIP=78011f41 EFLGS=00010206 EBX=0073 SS=016f ESP=0063ee90 EBP=0063f0e4 ECX=2741 DS=016f ESI=7ffe FS=c617 EDX=7fff ES=016f EDI=01447538 GS= Octets à CS : EIP : 80 38 00 74 03 40 eb f1 2b c1 e9 85 fe ff ff c7 État de la pile : 0002 01172d94 000c 00023c30 bff7b30e 0041 bff7b317 0041 0001 00413768 00023c30 0041374c 0063ef0c bff7b953 0041 (it's in French and my windows is French ... sorry :D ) -- Edit this bug report at http://bugs.php.net/?id=16664&edit=1
Bug #16664 Updated: PHP crashes on socket_bind
ID: 16664 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open -Bug Type: Sockets related +Bug Type: *PDF functions Operating System: Windows 98 PHP Version: 4.2.0 New Comment: Here is a small example of script ... if (($sock = socket_create (AF_INET, SOCK_STREAM, 0)) < 0) { echo "socket_create() failed: reason: " . socket_strerror ($sock) . "\n"; } if (($ret = socket_bind ($sock, '127.0.0.1', 1)) < 0) { echo "socket_bind() failed: reason: " . socket_strerror ($ret) . "\n"; } PHP crashes here, on the socket_bind command. This script was found on the page about the socket functions. I've downloaded the last RC version but it also crashes. I have the window's dialog with 'Close', 'Debug' or 'Deltails >>' ... Previous Comments: [2002-04-17 16:03:32] [EMAIL PROTECTED] Please provide a short, self-contained sample (see the bug's do's and don'ts). [2002-04-17 13:32:08] [EMAIL PROTECTED] When I attempt to bind a socket with socket_bind, PHP crashes. It doesn't crash if the IP to bind to is an mepty string ("") ... I have this error in the crash dialog : PHP a causé une défaillance de page dans le module MSVCRT.DLL à 0167:78011f41. Registres : EAX=2741 CS=0167 EIP=78011f41 EFLGS=00010206 EBX=0073 SS=016f ESP=0063ee90 EBP=0063f0e4 ECX=2741 DS=016f ESI=7ffe FS=c617 EDX=7fff ES=016f EDI=01447538 GS= Octets à CS : EIP : 80 38 00 74 03 40 eb f1 2b c1 e9 85 fe ff ff c7 État de la pile : 0002 01172d94 000c 00023c30 bff7b30e 0041 bff7b317 0041 0001 00413768 00023c30 0041374c 0063ef0c bff7b953 0041 (it's in French and my windows is French ... sorry :D ) -- Edit this bug report at http://bugs.php.net/?id=16664&edit=1
Bug #16664: PHP crashes on socket_bind
From: [EMAIL PROTECTED] Operating system: Windows 98 PHP version: 4.2.0 PHP Bug Type: Sockets related Bug description: PHP crashes on socket_bind When I attempt to bind a socket with socket_bind, PHP crashes. It doesn't crash if the IP to bind to is an mepty string ("") ... I have this error in the crash dialog : PHP a causé une défaillance de page dans le module MSVCRT.DLL à 0167:78011f41. Registres : EAX=2741 CS=0167 EIP=78011f41 EFLGS=00010206 EBX=0073 SS=016f ESP=0063ee90 EBP=0063f0e4 ECX=2741 DS=016f ESI=7ffe FS=c617 EDX=7fff ES=016f EDI=01447538 GS= Octets à CS : EIP : 80 38 00 74 03 40 eb f1 2b c1 e9 85 fe ff ff c7 État de la pile : 0002 01172d94 000c 00023c30 bff7b30e 0041 bff7b317 0041 0001 00413768 00023c30 0041374c 0063ef0c bff7b953 0041 (it's in French and my windows is French ... sorry :D ) -- Edit bug report at http://bugs.php.net/?id=16664&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16664&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16664&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16664&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16664&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16664&r=support Expected behavior: http://bugs.php.net/fix.php?id=16664&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16664&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16664&r=submittedtwice
Bug #16533: Apache 2 can't start using PHP as a module
From: [EMAIL PROTECTED] Operating system: Windows 98 PHP version: 4.1.2 PHP Bug Type: Apache2 related Bug description: Apache 2 can't start using PHP as a module When I try to use PHP with Apache 2 (last stable version), Apache don't start, telling me that he couldn't load the dll module file. I've checked depencies of that file and found that it requires APACHECORE.DLL that isn't anymore with Apache 2 (as it seems ...) PHP work well as a CGI :) -- Edit bug report at http://bugs.php.net/?id=16533&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16533&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16533&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16533&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16533&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16533&r=support Expected behavior: http://bugs.php.net/fix.php?id=16533&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16533&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16533&r=submittedtwice