#32589 [Bgs->Opn]: imap_mail_compose doesn´t work properly
ID: 32589 User updated by: svoboda at svoon dot net Reported By: svoboda at svoon dot net -Status: Bogus +Status: Open Bug Type: IMAP related Operating System: debian PHP Version: 4.4.0 New Comment: Hello, have you red my text carefuly? I wrote, that version php4-STABLE-200412272330 was OK, but not, that this snapshost is version 4.4.0. This snapshot, as You can see in his name, is a half year old and I wrote it only becouse of explaining, that on the same system with the same configuration command the old version works well, and the new version does not. btw. You can be sure I am using all versions downloaded from php.net - strictli speaking from http://cz.php.net/get/php-4.4.0.tar.gz/from/cz.php.net/mirror ie. Ondrej. Previous Comments: [2005-07-19 21:17:57] [EMAIL PROTECTED] You're not really using PHP 4.4.0 downloaded from php.net. The snapshot and release packages do NOT differ anywhere near IMAP stuff. [2005-07-19 12:16:20] svoboda at svoon dot net hello, in new version php 4.4.0 the bug remains. Script outputs no data, error log is empty too, only processing exit. If I compile version php4-STABLE-200412272330 with the same configure command, it works well. I have c-client with kerberos from debian packages libc-client-dev libc-client-ssl2001 libc-client2002edebian If you need some more info, pleas let me know. thank you a lot [2005-04-09 09:46:25] [EMAIL PROTECTED] I can not reproduce this either with latest CVS (any branch). (and snapshots are fine too) Get the latest here: http://snaps.php.net/php4-STABLE-latest.tar.gz [2005-04-09 04:55:09] svoboda at svoon dot net I have tryied php4-STABLE-200504090239, but the problem still remains. [2005-04-05 16:49:22] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. 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/32589 -- Edit this bug report at http://bugs.php.net/?id=32589&edit=1
#33780 [Opn]: Adding dictionaries to Aspell forces recompilation of PHP
ID: 33780 User updated by: phpbugs at w-wins dot com Reported By: phpbugs at w-wins dot com Status: Open -Bug Type: Feature/Change Request +Bug Type: Pspell related Operating System: GNU/Linux (Crux 2.1) PHP Version: 5.1.0b3 New Comment: I guess it's not a feature request as such, but a modification of the Pspell feature, changed categories Previous Comments: [2005-07-20 06:32:38] phpbugs at w-wins dot com Description: Using PHP 5.1.0b3 with the configure line ./configure --with-pear --with-pgsql --with-config-file-path=/etc --with-apxs2=/usr/apache2/bin/apxs --with-pspell --enable-ftp --enable-mbstring --enable-soap --with-gd --with-zlib --with-openssl --enable-gd-native-ttf --with-readline --with-gmp --with-ncurses and GNU Aspell 0.60.3 When I install new dictionaries, Aspell picks them up at once, and can use them without any recompilation, but when I try to use the language in PHP I get a warning from the Pspell module. When I recompile PHP, the new dictionary becomes available without errors. I assume the PHP Pspell module determines dictionaries at compile time, and I don't know whether this is intended behaviour, whether there is some good reason for it, or if it's simply a bug. Either way I would much like it if I was able to install (and uninstall) dictionaries without recompiling anything but the actual dictionaries. Reproduce code: --- Expected result: bool(true) Actual result: -- Warning: pspell_new(): PSPELL couldn't open the dictionary. reason: No word lists can be found for the language "no". in - on line 2 Warning: pspell_check(): 0 is not a PSPELL result index in - on line 3 bool(false) -- Edit this bug report at http://bugs.php.net/?id=33780&edit=1
#33780 [NEW]: Adding dictionaries to Aspell forces recompilation of PHP
From: phpbugs at w-wins dot com Operating system: GNU/Linux (Crux 2.1) PHP version: 5.1.0b3 PHP Bug Type: Feature/Change Request Bug description: Adding dictionaries to Aspell forces recompilation of PHP Description: Using PHP 5.1.0b3 with the configure line ./configure --with-pear --with-pgsql --with-config-file-path=/etc --with-apxs2=/usr/apache2/bin/apxs --with-pspell --enable-ftp --enable-mbstring --enable-soap --with-gd --with-zlib --with-openssl --enable-gd-native-ttf --with-readline --with-gmp --with-ncurses and GNU Aspell 0.60.3 When I install new dictionaries, Aspell picks them up at once, and can use them without any recompilation, but when I try to use the language in PHP I get a warning from the Pspell module. When I recompile PHP, the new dictionary becomes available without errors. I assume the PHP Pspell module determines dictionaries at compile time, and I don't know whether this is intended behaviour, whether there is some good reason for it, or if it's simply a bug. Either way I would much like it if I was able to install (and uninstall) dictionaries without recompiling anything but the actual dictionaries. Reproduce code: --- Expected result: bool(true) Actual result: -- Warning: pspell_new(): PSPELL couldn't open the dictionary. reason: No word lists can be found for the language "no". in - on line 2 Warning: pspell_check(): 0 is not a PSPELL result index in - on line 3 bool(false) -- Edit bug report at http://bugs.php.net/?id=33780&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33780&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33780&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33780&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33780&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33780&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33780&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33780&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33780&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33780&r=support Expected behavior: http://bugs.php.net/fix.php?id=33780&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33780&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33780&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33780&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33780&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33780&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33780&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33780&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33780&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33780&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33780&r=mysqlcfg
#33778 [Csd]: PHP compile fails --with-t1lib when SUSE 9.1 upgraded to t1lib-5.0.2-3
ID: 33778 User updated by: sibaz at sibaz dot com Reported By: sibaz at sibaz dot com Status: Closed Bug Type: Compile Failure Operating System: Suse 9.1 (Upgraded) PHP Version: 5.0.4 New Comment: Perhaps configure should be fixed to correctly identify the error as missing glibc symbols instead of a missing t1lib Having said that I should never have been able to install t1lib without glibc 2.3.4 anyway. Previous Comments: [2005-07-20 04:53:25] sibaz at sibaz dot com t1lib-5.0.2-3 required glibc 2.3.4 which is not installed on SUSE 9.1 force and 'upgrade' to t1lib-5.0.2-1 (for Fedora 3 Extras for i386) and all is OK [2005-07-20 04:51:21] sibaz at sibaz dot com Description: Having upgraded my system with t1lib-5.0.2-3 (Fedora 4 Extras for i386, because latest SUSE rpm is t1lib-1.3.x) compile breaks with --with-t1lib=/usr Reproduce code: --- ./configure --with-gd --with-t1lib=/usr Expected result: It should configure Actual result: -- configure complains about the lack of libt1.(a|so) which does exist. -- Edit this bug report at http://bugs.php.net/?id=33778&edit=1
#33778 [Opn->Csd]: PHP compile fails --with-t1lib when SUSE 9.1 upgraded to t1lib-5.0.2-3
ID: 33778 User updated by: sibaz at sibaz dot com Reported By: sibaz at sibaz dot com -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Suse 9.1 (Upgraded) PHP Version: 5.0.4 New Comment: t1lib-5.0.2-3 required glibc 2.3.4 which is not installed on SUSE 9.1 force and 'upgrade' to t1lib-5.0.2-1 (for Fedora 3 Extras for i386) and all is OK Previous Comments: [2005-07-20 04:51:21] sibaz at sibaz dot com Description: Having upgraded my system with t1lib-5.0.2-3 (Fedora 4 Extras for i386, because latest SUSE rpm is t1lib-1.3.x) compile breaks with --with-t1lib=/usr Reproduce code: --- ./configure --with-gd --with-t1lib=/usr Expected result: It should configure Actual result: -- configure complains about the lack of libt1.(a|so) which does exist. -- Edit this bug report at http://bugs.php.net/?id=33778&edit=1
#33778 [NEW]: PHP compile fails --with-t1lib when SUSE 9.1 upgraded to t1lib-5.0.2-3
From: sibaz at sibaz dot com Operating system: Suse 9.1 (Upgraded) PHP version: 5.0.4 PHP Bug Type: Compile Failure Bug description: PHP compile fails --with-t1lib when SUSE 9.1 upgraded to t1lib-5.0.2-3 Description: Having upgraded my system with t1lib-5.0.2-3 (Fedora 4 Extras for i386, because latest SUSE rpm is t1lib-1.3.x) compile breaks with --with-t1lib=/usr Reproduce code: --- ./configure --with-gd --with-t1lib=/usr Expected result: It should configure Actual result: -- configure complains about the lack of libt1.(a|so) which does exist. -- Edit bug report at http://bugs.php.net/?id=33778&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33778&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33778&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33778&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33778&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33778&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33778&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33778&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33778&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33778&r=support Expected behavior: http://bugs.php.net/fix.php?id=33778&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33778&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33778&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33778&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33778&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33778&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33778&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33778&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33778&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33778&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33778&r=mysqlcfg
#33777 [Opn]: PHP fastcgi returns "No input file specified" only when it finds a valid script
ID: 33777 User updated by: sibaz at sibaz dot com Reported By: sibaz at sibaz dot com Status: Open Bug Type: CGI related Operating System: Upgraded Suse (2.6.5-7.155.29) PHP Version: 5.0.4 New Comment: I removed the php.ini file I was using and it seems to have sorted the problem. In testing I had the same problem using /usr/local/apache2/htdocs and /home/sites as DocumentRoot and DocumentRoot respectively. I'm guessing there is still a bug somewhere, but I can't figure it out. offending-php.ini is availiable at :- http://linuxnotes.sibaz.com/offending-php.ini Previous Comments: [2005-07-20 03:36:27] sibaz at sibaz dot com I've just compiled a fresh version of Apache 1.3.33 with mod_fastcgi as an APACI module and attempted to use the same running PHP5 daemon, with identical results. I hope this at least elliminates Apache from the problem (if not mod_fastcgi) [2005-07-20 03:01:52] sibaz at sibaz dot com Description: When accessing valid pages from Apache2 server, PHP comes back with No input file specified. Logs show a page was correctly accessed, but with a 404 error code. Specifying a .html file or a non-existant file, returns a valid page or a 404 error page correcty. I believe the problem lies in the PHP fastcgi daemon some how. I believe I have removed all other possible problems. I'm confused: I have recompiled PHP5 and Apache2 removing everything that seems unneccesary I have PHP5 compiled using ./configure --enable-fastcgi --prefix=/usr/local/php5 --program-suffix=-fastcgi --without-pear and running as a separate daemon using -b 127.0.0.1:8002 I have Apache2 compiled with ./configure --prefix=/usr/local/apache2 Apache2 Config portion is below Notes: /usr/local/apache2/fastcgi is a valid, but empty directory I had the server working at one point, but I added a few compile options and it stopped, and I've since removed all but the basic compile options and it still dies. I have done a make clean before building and I have tried this from the original clean tarball sources. I'm clueless. I'm not used to this kind of problem under Linux. Reproduce code: --- Apache2 Config, which I had problems figuring out. LoadModule fastcgi_module modules/mod_fastcgi.so Alias /fcgi-bin/ /usr/local/apache2/fastcgi/ FastCGIExternalServer /usr/local/apache2/fastcgi/php-fastcgi -host 127.0.0.1:8002 AddType application/x-httpd-fastphp .php Action application/x-httpd-fastphp /fcgi-bin/php-fastcgi Expected result: Apache Works fine except for when defering requests to the PHP daemon. Something, Anything from the PHP daemon. Even an error code would be nice. If I point it at a .html file with a .php extension just containing 'Hello World' it still returns "No input file specified" It would be handy if the php -b daemon could log some indication as to what it was doing to the console its running on. This seems a noticable ommission for a daemon (normally -D makes a daemon single action and debug to screen). Actual result: -- "No input file specified" on screen 127.0.0.1 - - [20/Jul/2005:00:52:42 +0100] "GET /test.php HTTP/1.1" 404 25 in the access.log -- Edit this bug report at http://bugs.php.net/?id=33777&edit=1
#33777 [Opn]: PHP fastcgi returns "No input file specified" only when it finds a valid script
ID: 33777 User updated by: sibaz at sibaz dot com Reported By: sibaz at sibaz dot com Status: Open Bug Type: CGI related Operating System: Upgraded Suse (2.6.5-7.155.29) PHP Version: 5.0.4 New Comment: I've just compiled a fresh version of Apache 1.3.33 with mod_fastcgi as an APACI module and attempted to use the same running PHP5 daemon, with identical results. I hope this at least elliminates Apache from the problem (if not mod_fastcgi) Previous Comments: [2005-07-20 03:01:52] sibaz at sibaz dot com Description: When accessing valid pages from Apache2 server, PHP comes back with No input file specified. Logs show a page was correctly accessed, but with a 404 error code. Specifying a .html file or a non-existant file, returns a valid page or a 404 error page correcty. I believe the problem lies in the PHP fastcgi daemon some how. I believe I have removed all other possible problems. I'm confused: I have recompiled PHP5 and Apache2 removing everything that seems unneccesary I have PHP5 compiled using ./configure --enable-fastcgi --prefix=/usr/local/php5 --program-suffix=-fastcgi --without-pear and running as a separate daemon using -b 127.0.0.1:8002 I have Apache2 compiled with ./configure --prefix=/usr/local/apache2 Apache2 Config portion is below Notes: /usr/local/apache2/fastcgi is a valid, but empty directory I had the server working at one point, but I added a few compile options and it stopped, and I've since removed all but the basic compile options and it still dies. I have done a make clean before building and I have tried this from the original clean tarball sources. I'm clueless. I'm not used to this kind of problem under Linux. Reproduce code: --- Apache2 Config, which I had problems figuring out. LoadModule fastcgi_module modules/mod_fastcgi.so Alias /fcgi-bin/ /usr/local/apache2/fastcgi/ FastCGIExternalServer /usr/local/apache2/fastcgi/php-fastcgi -host 127.0.0.1:8002 AddType application/x-httpd-fastphp .php Action application/x-httpd-fastphp /fcgi-bin/php-fastcgi Expected result: Apache Works fine except for when defering requests to the PHP daemon. Something, Anything from the PHP daemon. Even an error code would be nice. If I point it at a .html file with a .php extension just containing 'Hello World' it still returns "No input file specified" It would be handy if the php -b daemon could log some indication as to what it was doing to the console its running on. This seems a noticable ommission for a daemon (normally -D makes a daemon single action and debug to screen). Actual result: -- "No input file specified" on screen 127.0.0.1 - - [20/Jul/2005:00:52:42 +0100] "GET /test.php HTTP/1.1" 404 25 in the access.log -- Edit this bug report at http://bugs.php.net/?id=33777&edit=1
#33737 [Opn->Fbk]: PDO::SQLite crashes
ID: 33737 Updated by: [EMAIL PROTECTED] Reported By: leon at lost dot co dot nz -Status: Open +Status: Feedback Bug Type: PDO related Operating System: Linux 2.6 / Apache2 PHP Version: PHP 5 CVS Assigned To: wez New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Need a backtrace and/or a short, self-contained reproducing test case; when you can provide either or both of these, re-open this report. Until then, your comments won't really help us to track down the problem. Previous Comments: [2005-07-20 02:01:37] leon at lost dot co dot nz Just rebuilt the above build with --enable-debug to try to generate a backtrace for you. It has so far refused to segfault, but I am getting this error appearing on the end of my unit-test page: Warning: String is not zero-terminated (�̏**̏*�) (source: /tmp/php5-200507192230/Zend/zend_variables.h:35) in Unknown on line 0 Needless to say, I don't have any variables that look even close to that! :-) [2005-07-20 01:22:40] leon at lost dot co dot nz Tried again this morning with CVS snapshot php5-200507192230. Same install routine which, this time, created and install the .so file properly. My test script now works fine, and I can run the unit tests successfully. Big improvement! However... I'm still getting intermittent (like about half of the time I run the PDO::SQLite tests) segfaults reported in Apache's error log. Prehaps more worryingly, after trying to run the SQLite unit tests for a while, I have seen what looks like some of the apache2 stuck in infinite loops (three processs each using ~33% CPU -- I'm using the Apache2 prefork MPM with APXS2 to build PHP). [2005-07-18 23:45:06] leon at lost dot co dot nz Hmmm... I think something screwy happened with the install of the latest snapshot, making my last (good news/bad news) report suspect. I did my usual install routine (on Debian 3.1): make apache2ctl stop make install apache2ctl start Then tested the snippet using the CLI: $ php -v PHP 5.1.0-dev (cli) (built: Jul 19 2005 08:45:23 NZ) $ php test.php $ (no segfault!) The 'bad news' came when I browsed to the unit test page normally -- but on further investigation it seems that the normal install process failed on the snapshot. For some reason 'make install' put the files libphp5.[a|la] in my /usr/lib/apache2/modules, rather than the usual libphp5.so... Has the build process changed, or have I done something stupid? ;-) ./configure --with-apxs2=/usr/bin/apxs2 \ --with-config-file-dir=/etc/php --with-mcrypt --with-gd \ --with-zlib --enable-exif --with-freetype-dir \ --with-jpeg-dir --enable-debug [2005-07-18 23:15:18] [EMAIL PROTECTED] Let's see the backtrace(s) for the problems here, before deciding what else to do. [2005-07-18 22:59:55] leon at lost dot co dot nz Just rebuilt and retested with php5-200507182030, thanks for the quick response! I've got good news and bad news: The good news is that the latest snapshot doesn't segfault on the test snippet above. The bad news is that my full unit tests still cause PHP to segfault on the SQLite tests... What would you like me to do? I could: 1) Put together another snippet and post it here 2) As above, but create a new bug report 3) Post my classes somewhere for you to look at directly Cheers, Leon 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/33737 -- Edit this bug report at http://bugs.php.net/?id=33737&edit=1
#33777 [NEW]: PHP fastcgi returns "No input file specified" only when it finds a valid script
From: sibaz at sibaz dot com Operating system: Upgraded Suse (2.6.5-7.155.29) PHP version: 5.0.4 PHP Bug Type: CGI related Bug description: PHP fastcgi returns "No input file specified" only when it finds a valid script Description: When accessing valid pages from Apache2 server, PHP comes back with No input file specified. Logs show a page was correctly accessed, but with a 404 error code. Specifying a .html file or a non-existant file, returns a valid page or a 404 error page correcty. I believe the problem lies in the PHP fastcgi daemon some how. I believe I have removed all other possible problems. I'm confused: I have recompiled PHP5 and Apache2 removing everything that seems unneccesary I have PHP5 compiled using ./configure --enable-fastcgi --prefix=/usr/local/php5 --program-suffix=-fastcgi --without-pear and running as a separate daemon using -b 127.0.0.1:8002 I have Apache2 compiled with ./configure --prefix=/usr/local/apache2 Apache2 Config portion is below Notes: /usr/local/apache2/fastcgi is a valid, but empty directory I had the server working at one point, but I added a few compile options and it stopped, and I've since removed all but the basic compile options and it still dies. I have done a make clean before building and I have tried this from the original clean tarball sources. I'm clueless. I'm not used to this kind of problem under Linux. Reproduce code: --- Apache2 Config, which I had problems figuring out. LoadModule fastcgi_module modules/mod_fastcgi.so Alias /fcgi-bin/ /usr/local/apache2/fastcgi/ FastCGIExternalServer /usr/local/apache2/fastcgi/php-fastcgi -host 127.0.0.1:8002 AddType application/x-httpd-fastphp .php Action application/x-httpd-fastphp /fcgi-bin/php-fastcgi Expected result: Apache Works fine except for when defering requests to the PHP daemon. Something, Anything from the PHP daemon. Even an error code would be nice. If I point it at a .html file with a .php extension just containing 'Hello World' it still returns "No input file specified" It would be handy if the php -b daemon could log some indication as to what it was doing to the console its running on. This seems a noticable ommission for a daemon (normally -D makes a daemon single action and debug to screen). Actual result: -- "No input file specified" on screen 127.0.0.1 - - [20/Jul/2005:00:52:42 +0100] "GET /test.php HTTP/1.1" 404 25 in the access.log -- Edit bug report at http://bugs.php.net/?id=33777&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33777&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33777&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33777&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33777&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33777&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33777&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33777&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33777&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33777&r=support Expected behavior: http://bugs.php.net/fix.php?id=33777&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33777&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33777&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33777&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33777&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33777&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33777&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33777&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33777&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33777&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33777&r=mysqlcfg
#33737 [Opn]: PDO::SQLite crashes
ID: 33737 User updated by: leon at lost dot co dot nz Reported By: leon at lost dot co dot nz Status: Open Bug Type: PDO related Operating System: Linux 2.6 / Apache2 PHP Version: PHP 5 CVS Assigned To: wez New Comment: Just rebuilt the above build with --enable-debug to try to generate a backtrace for you. It has so far refused to segfault, but I am getting this error appearing on the end of my unit-test page: Warning: String is not zero-terminated (�̏**̏*�) (source: /tmp/php5-200507192230/Zend/zend_variables.h:35) in Unknown on line 0 Needless to say, I don't have any variables that look even close to that! :-) Previous Comments: [2005-07-20 01:22:40] leon at lost dot co dot nz Tried again this morning with CVS snapshot php5-200507192230. Same install routine which, this time, created and install the .so file properly. My test script now works fine, and I can run the unit tests successfully. Big improvement! However... I'm still getting intermittent (like about half of the time I run the PDO::SQLite tests) segfaults reported in Apache's error log. Prehaps more worryingly, after trying to run the SQLite unit tests for a while, I have seen what looks like some of the apache2 stuck in infinite loops (three processs each using ~33% CPU -- I'm using the Apache2 prefork MPM with APXS2 to build PHP). [2005-07-18 23:45:06] leon at lost dot co dot nz Hmmm... I think something screwy happened with the install of the latest snapshot, making my last (good news/bad news) report suspect. I did my usual install routine (on Debian 3.1): make apache2ctl stop make install apache2ctl start Then tested the snippet using the CLI: $ php -v PHP 5.1.0-dev (cli) (built: Jul 19 2005 08:45:23 NZ) $ php test.php $ (no segfault!) The 'bad news' came when I browsed to the unit test page normally -- but on further investigation it seems that the normal install process failed on the snapshot. For some reason 'make install' put the files libphp5.[a|la] in my /usr/lib/apache2/modules, rather than the usual libphp5.so... Has the build process changed, or have I done something stupid? ;-) ./configure --with-apxs2=/usr/bin/apxs2 \ --with-config-file-dir=/etc/php --with-mcrypt --with-gd \ --with-zlib --enable-exif --with-freetype-dir \ --with-jpeg-dir --enable-debug [2005-07-18 23:15:18] [EMAIL PROTECTED] Let's see the backtrace(s) for the problems here, before deciding what else to do. [2005-07-18 22:59:55] leon at lost dot co dot nz Just rebuilt and retested with php5-200507182030, thanks for the quick response! I've got good news and bad news: The good news is that the latest snapshot doesn't segfault on the test snippet above. The bad news is that my full unit tests still cause PHP to segfault on the SQLite tests... What would you like me to do? I could: 1) Put together another snippet and post it here 2) As above, but create a new bug report 3) Post my classes somewhere for you to look at directly Cheers, Leon [2005-07-18 16:49:44] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Works for me with CVS HEAD. Please try the snap dated after this message to confirm. 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/33737 -- Edit this bug report at http://bugs.php.net/?id=33737&edit=1
#33776 [Opn->Bgs]: sessions does not saved
ID: 33776
Updated by: [EMAIL PROTECTED]
Reported By: fatih at muzikkutusu dot com
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: mandrake linux
PHP Version: 4.4.0
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2005-07-20 00:53:41] fatih at muzikkutusu dot com
Description:
I have compiled php in my mandrake linux, with apache 1.3.33. However
when i tried to work with session it does not save anything in
$_SESSION.
My configuration :
session.save_handler = files
session.use_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.serialize_handler = php
session.gc_probability = 1
session.gc_divisor = 100
session.use_trans_sid = 0
This lines of code does not work, everytime ir prints "cookie was set"
session_start();
if(!isset($_SESSION['test']))
{
$_SESSION['test'] = 'test';
echo 'cookie was set';
}
else
{
echo $_SESSION['test'];
echo session_id();
}
There must be an error with the session functions..
--
Edit this bug report at http://bugs.php.net/?id=33776&edit=1
#33737 [Opn]: PDO::SQLite crashes
ID: 33737 User updated by: leon at lost dot co dot nz Reported By: leon at lost dot co dot nz Status: Open Bug Type: PDO related Operating System: Linux 2.6 / Apache2 PHP Version: PHP 5 CVS Assigned To: wez New Comment: Tried again this morning with CVS snapshot php5-200507192230. Same install routine which, this time, created and install the .so file properly. My test script now works fine, and I can run the unit tests successfully. Big improvement! However... I'm still getting intermittent (like about half of the time I run the PDO::SQLite tests) segfaults reported in Apache's error log. Prehaps more worryingly, after trying to run the SQLite unit tests for a while, I have seen what looks like some of the apache2 stuck in infinite loops (three processs each using ~33% CPU -- I'm using the Apache2 prefork MPM with APXS2 to build PHP). Previous Comments: [2005-07-18 23:45:06] leon at lost dot co dot nz Hmmm... I think something screwy happened with the install of the latest snapshot, making my last (good news/bad news) report suspect. I did my usual install routine (on Debian 3.1): make apache2ctl stop make install apache2ctl start Then tested the snippet using the CLI: $ php -v PHP 5.1.0-dev (cli) (built: Jul 19 2005 08:45:23 NZ) $ php test.php $ (no segfault!) The 'bad news' came when I browsed to the unit test page normally -- but on further investigation it seems that the normal install process failed on the snapshot. For some reason 'make install' put the files libphp5.[a|la] in my /usr/lib/apache2/modules, rather than the usual libphp5.so... Has the build process changed, or have I done something stupid? ;-) ./configure --with-apxs2=/usr/bin/apxs2 \ --with-config-file-dir=/etc/php --with-mcrypt --with-gd \ --with-zlib --enable-exif --with-freetype-dir \ --with-jpeg-dir --enable-debug [2005-07-18 23:15:18] [EMAIL PROTECTED] Let's see the backtrace(s) for the problems here, before deciding what else to do. [2005-07-18 22:59:55] leon at lost dot co dot nz Just rebuilt and retested with php5-200507182030, thanks for the quick response! I've got good news and bad news: The good news is that the latest snapshot doesn't segfault on the test snippet above. The bad news is that my full unit tests still cause PHP to segfault on the SQLite tests... What would you like me to do? I could: 1) Put together another snippet and post it here 2) As above, but create a new bug report 3) Post my classes somewhere for you to look at directly Cheers, Leon [2005-07-18 16:49:44] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Works for me with CVS HEAD. Please try the snap dated after this message to confirm. [2005-07-18 01:31:49] leon at lost dot co dot nz Whew... All done... I've pared my script from > 1800 lines of PHP scattered accross 7 files to three lines in one file! Turns out to be a SQLite PDO problem... query($sql); ?> This snippet causes PHP5.1b3 to segfault everytime (I'm using the bundled SQLite library). One of my other unit tests still throws up that corruption I talked about before, but I'll try to isolate that and submit a brand new bug report for that. 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/33737 -- Edit this bug report at http://bugs.php.net/?id=33737&edit=1
#33776 [NEW]: sessions does not saved
From: fatih at muzikkutusu dot com
Operating system: mandrake linux
PHP version: 4.4.0
PHP Bug Type: Session related
Bug description: sessions does not saved
Description:
I have compiled php in my mandrake linux, with apache 1.3.33. However when
i tried to work with session it does not save anything in $_SESSION.
My configuration :
session.save_handler = files
session.use_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.serialize_handler = php
session.gc_probability = 1
session.gc_divisor = 100
session.use_trans_sid = 0
This lines of code does not work, everytime ir prints "cookie was set"
session_start();
if(!isset($_SESSION['test']))
{
$_SESSION['test'] = 'test';
echo 'cookie was set';
}
else
{
echo $_SESSION['test'];
echo session_id();
}
There must be an error with the session functions..
--
Edit bug report at http://bugs.php.net/?id=33776&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33776&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33776&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33776&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33776&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33776&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33776&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33776&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33776&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33776&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33776&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33776&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33776&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33776&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33776&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33776&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33776&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33776&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33776&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33776&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33776&r=mysqlcfg
#33770 [Fbk->Opn]: file() does not work with https when curl wrappers are compiled in
ID: 33770 User updated by: subscription at nazarenko dot net -Summary: file() does not work with https on 64-bit Linux Reported By: subscription at nazarenko dot net -Status: Feedback +Status: Open Bug Type: OpenSSL related Operating System: Linux SuSE 9.3 PHP Version: 5CVS-2005-07-19 New Comment: Thank you for a speedy response. Indeed, with the minimal configure, it started working again. After 1 hour of mixing and matching the modules I found the culprit. It is: curl-7.13.0 libraries compiled in with the following parameters: --with-curl --with-curlwrappers Actually, without "--with-curlwrappers" it works fine. Tested both for 5.0.4 and 5CVS Previous Comments: [2005-07-19 21:32:47] [EMAIL PROTECTED] Works fine for me under FC4 x86_64smp. Try with this configure line: ./configure --disable-all --disable-cgi --with-openssl And use sapi/cli/php to run your script. [2005-07-19 21:23:47] [EMAIL PROTECTED] subscription at nazarenko dot net: "Tried the latest snapshot as advised. Same effect as before, the problem persists. Test script: https://host2/";)); ?> Both "host1" and "host2" are on the same subnet. " (do NOT add any huge outputs of anything unless asked for!) [2005-07-19 14:38:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-07-19 14:35:37] subscription at nazarenko dot net Description: I have 64bit SuSE 9.3 and try to use file() function to read a webpage via http/https. The http protocol is ok, however https returns empty result without any errors/notices (E_ALL is on). I have compiled in OpenSSL support (OpenSSL is v0.9.7e). I have another machine with 32bit Linux on it in the same network, I have compiled PHP with similar settings and https works fine on it. Reproduce code: --- Using the following configure: ./configure --with-snmp --enable-cli --with-curl \ -disable-dom --prefix=/usr --disable-cgi \ --disable-spl --disable-xml --without-pear \ --disable-ipv6 --enable-shmop --enable-pcntl \ --without-iconv --disable-ctype --disable-libxml \ --enable-sysvsem --enable-sysvshm --enable-sockets \ --without-sqlite --disable-session --enable-sigchild \ --disable-simplexml --disable-tokenizer \ --with-curlwrappers --enable-memory-limit \ --enable-discard-path --program-suffix=-net \ --enable-ucd-snmp-hack --with-config-file-path=/etc \ --with-mysqli=/usr/bin/mysql_config -- Edit this bug report at http://bugs.php.net/?id=33770&edit=1
#33635 [Asn->Bgs]: "couldn't fetch mysqli" error when attempting to write session data to db
ID: 33635 Updated by: [EMAIL PROTECTED] Reported By: tony at marston-home dot demon dot co dot uk -Status: Assigned +Status: Bogus Bug Type: MySQLi related Operating System: Windows XP PHP Version: 5CVS-2005-07-10 (dev) Assigned To: georg New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. See bug #33772 which has a nice and short script that demonstrates the same issue. (it's not Mysqli only issue after all) Previous Comments: [2005-07-15 09:41:17] tony at marston-home dot demon dot co dot uk This problem only occurs when writing out session data to a database when the script terminates, and also because I am using a shared database connection (the one created when the session data was forst read in). I conducted a little experiment by replacing the exit function with session_write_close(), and this did not produce the error. I therefore strongly suspect that the order of events at script termination has been altered to: (a) close all resources (b) write session data (to database) This will fail if (b) uses a resource closed in (a) [2005-07-12 01:08:12] [EMAIL PROTECTED] Assigned to the author of the extension, who can propably explain this better.. [2005-07-11 23:55:55] tony at marston-home dot demon dot co dot uk You are completely mistaken. I am not mixing both OO and procedural ways of accessing the DB - all my calls to the mysqli_* functions are in the procedural style. The fact that I am making these calls inside my own OO class should be totally irrelevant. The same code has worked perfectly through php 5.0.0 to 5.0.4, and with 5.0.5-dev only fails when I try to write my session data to the database. SOMETHING HAS BEEN INTRODUCED IN 5.0.5-dev THAT CAUSES THIS FAILURE. My use of static variables follows the documentation for the singleton pattern at http://www.php.net/manual/en/language.oop5.patterns.php. It allows to to call mysqli_connect() only once for a request. [2005-07-11 22:48:09] [EMAIL PROTECTED] Please read the friendly manual about Mysqli. You're trying to mix both OO and procedural way of accessing the DB. Choose one and stick to that. (And I don't get the idea of making the connection 'static' either..especially if you deal with OOP) [2005-07-11 12:33:45] tony at marston-home dot demon dot co dot uk Whoops. That URL should be http://www.tonymarston.net/test.zip The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/33635 -- Edit this bug report at http://bugs.php.net/?id=33635&edit=1
#33762 [Opn->Bgs]: Setting error_reporting doesn't turn off strict warning messages
ID: 33762 Updated by: [EMAIL PROTECTED] Reported By: russell at flora dot ca -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: 2.6.12-1.1398_FC4 Linux PHP Version: 5.0.4 New Comment: What we mean with latest is something build from the source WE provide, not some heavily patched RH binary. Previous Comments: [2005-07-19 14:40:07] russell at flora dot ca I am running the RPM that comes with Fedora Core 4 updates, which is the latest you list. (Their version information is php-5.0.4-10.3). From: http://www.forumonpublicdomain.ca/info.php PHP Version 5.0.4 [2005-07-19 10:06:50] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. [2005-07-19 05:38:35] russell at flora dot ca Description: I know this has been said to not be a bug, and many bug reports have been ignored, but I have tried everything suggested. This is the right php.ini file, and I am modifying the ini file and not some other way to set variables that might happen at run-time. I have gone so far as to set: error_reporting = 0 in my php.ini. I can then go to phpinfo() and it displays as I would expect: Directive Local Value Master Value error_reporting 0 0 Error warnings are still coming out on the output of the pages, even though display_errors Off Off Example errors from: http://forumonpublicdomain.ca/ (I may be forced to downgrade PHP to fix this problem. PHP5 isn't useable for me until this problem is fixed. phpinfo() is at http://www.forumonpublicdomain.ca/info.php ) strict warning: Assigning the return value of new by reference is deprecated in /home/forumonpublicdomain.ca/www.forumonpublicdomain.ca/themes/engines/phptemplate/phptemplate.engine on line 335. strict warning: var: Deprecated. Please use the public/private/protected modifiers in /home/forumonpublicdomain.ca/www.forumonpublicdomain.ca/themes/engines/phptemplate/template.php on line 27. strict warning: var: Deprecated. Please use the public/private/protected modifiers in /home/forumonpublicdomain.ca/www.forumonpublicdomain.ca/themes/engines/phptemplate/template.php on line 28. -- Edit this bug report at http://bugs.php.net/?id=33762&edit=1
#33770 [Opn->Fbk]: file() does not work with https on 64-bit Linux
ID: 33770 Updated by: [EMAIL PROTECTED] Reported By: subscription at nazarenko dot net -Status: Open +Status: Feedback Bug Type: OpenSSL related Operating System: Linux SuSE 9.3 PHP Version: 5CVS-2005-07-19 New Comment: Works fine for me under FC4 x86_64smp. Try with this configure line: ./configure --disable-all --disable-cgi --with-openssl And use sapi/cli/php to run your script. Previous Comments: [2005-07-19 21:23:47] [EMAIL PROTECTED] subscription at nazarenko dot net: "Tried the latest snapshot as advised. Same effect as before, the problem persists. Test script: https://host2/";)); ?> Both "host1" and "host2" are on the same subnet. " (do NOT add any huge outputs of anything unless asked for!) [2005-07-19 14:38:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-07-19 14:35:37] subscription at nazarenko dot net Description: I have 64bit SuSE 9.3 and try to use file() function to read a webpage via http/https. The http protocol is ok, however https returns empty result without any errors/notices (E_ALL is on). I have compiled in OpenSSL support (OpenSSL is v0.9.7e). I have another machine with 32bit Linux on it in the same network, I have compiled PHP with similar settings and https works fine on it. Reproduce code: --- Using the following configure: ./configure --with-snmp --enable-cli --with-curl \ -disable-dom --prefix=/usr --disable-cgi \ --disable-spl --disable-xml --without-pear \ --disable-ipv6 --enable-shmop --enable-pcntl \ --without-iconv --disable-ctype --disable-libxml \ --enable-sysvsem --enable-sysvshm --enable-sockets \ --without-sqlite --disable-session --enable-sigchild \ --disable-simplexml --disable-tokenizer \ --with-curlwrappers --enable-memory-limit \ --enable-discard-path --program-suffix=-net \ --enable-ucd-snmp-hack --with-config-file-path=/etc \ --with-mysqli=/usr/bin/mysql_config -- Edit this bug report at http://bugs.php.net/?id=33770&edit=1
#33770 [Opn]: file() does not work with https on 64-bit Linux
ID: 33770 Updated by: [EMAIL PROTECTED] Reported By: subscription at nazarenko dot net Status: Open Bug Type: OpenSSL related Operating System: Linux SuSE 9.3 PHP Version: 5.0.4 & 5.1.x-devel New Comment: subscription at nazarenko dot net: "Tried the latest snapshot as advised. Same effect as before, the problem persists. Test script: https://host2/";)); ?> Both "host1" and "host2" are on the same subnet. " (do NOT add any huge outputs of anything unless asked for!) Previous Comments: [2005-07-19 15:23:26] subscription at nazarenko dot net Tried the latest snapshot as advised. Same effect as before, the problem persists. The configure line was given wrong. The actual is: ./configure \ --with-snmp \ --enable-cli \ --with-curl \ --disable-dom \ --prefix=/usr \ --disable-cgi \ --disable-spl \ --disable-xml \ --without-pear \ --disable-ipv6 \ --enable-shmop \ --enable-pcntl \ --without-iconv \ --disable-ctype \ --disable-libxml \ --enable-sysvsem \ --enable-sysvshm \ --enable-sockets \ --without-sqlite \ --disable-session \ --enable-sigchild \ --with-openssl=/usr \ --disable-simplexml \ --disable-tokenizer \ --with-curlwrappers \ --enable-memory-limit \ --enable-discard-path \ --program-suffix=-net \ --enable-ucd-snmp-hack \ --with-openssl-dir=/usr \ --with-config-file-path=/etc \ --with-mysqli=/usr/bin/mysql_config And here is the tcpdump output for the following script run on the machine "host1": https://host2/";)); ?> Both "host1" and "host2" are on the same subnet. listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes 15:00:48.017717 IP host2.57868 > host.https: S 1342601093:1342601093(0) win 5840 0x: 4500 003c 6968 4000 4006 f142 ac11 43fa E..<[EMAIL PROTECTED]@..B..C. 0x0010: ac11 43f4 e20c 01bb 5006 7785 ..C.P.w. 0x0020: a002 16d0 824c 0204 05b4 0402 080a .L.. 0x0030: 0497 1eed 0103 0302 15:00:48.017867 IP host.https > host2.57868: S 3439729057:3439729057(0) ack 1342601094 win 5792 0x: 4500 003c 12b7 4000 4006 47f4 ac11 43f4 E..<[EMAIL PROTECTED]@.G...C. 0x0010: ac11 43fa 01bb e20c cd06 19a1 5006 7786 ..C.P.w. 0x0020: a012 16a0 1591 0204 05b4 0402 080a 0x0030: 00cd 8567 0497 1eed 0103 0300...g 15:00:48.017888 IP host2.57868 > host.https: . ack 1 win 1460 0x: 4500 0034 696a 4000 4006 f148 ac11 43fa [EMAIL PROTECTED]@..H..C. 0x0010: ac11 43f4 e20c 01bb 5006 7786 cd06 19a2 ..C.P.w. 0x0020: 8010 05b4 5541 0101 080a 0497 1eee UA.. 0x0030: 00cd 8567...g 15:00:48.023936 IP host2.57868 > host.https: F 1:1(0) ack 1 win 1460 0x: 4500 0034 696c 4000 4006 f146 ac11 43fa [EMAIL PROTECTED]@..F..C. 0x0010: ac11 43f4 e20c 01bb 5006 7786 cd06 19a2 ..C.P.w. 0x0020: 8011 05b4 553a 0101 080a 0497 1ef4 U:.. 0x0030: 00cd 8567...g 15:00:48.024125 IP host.https > host2.57868: F 1:1(0) ack 2 win 5792 0x: 4500 0034 12b1 4000 4006 4802 ac11 43f4 [EMAIL PROTECTED]@.H...C. 0x0010: ac11 43fa 01bb e20c cd06 19a2 5006 7787 ..C.P.w. 0x0020: 8011 16a0 444c 0101 080a 00cd 8568 DL.h 0x0030: 0497 1ef4 15:00:48.024141 IP host2.57868 > host.https: . ack 2 win 1460 0x: 4500 0034 696e 4000 4006 f144 ac11 43fa [EMAIL PROTECTED]@..D..C. 0x0010: ac11 43f4 e20c 01bb 5006 7787 cd06 19a3 ..C.P.w. 0x0020: 8010 05b4 5538 0101 080a 0497 1ef4 U8.. 0x0030: 00cd 8568...h [2005-07-19 14:38:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-07-19 14:35:37] subscription at nazarenko dot net Description: I have 64bit SuSE 9.3 and try to use file() function to read a webpage via http/https. The http protocol is ok, however https returns empty result without any errors/notices (E_ALL is on). I have compiled in OpenSSL support (OpenSSL is v0.9.7e). I have another machine with 32bit Linux on it in the same network, I have compiled PHP with similar settings and https works fine on it. Reproduce code: --- Using the following configure: ./configure --with-snmp --enable-cli --with-curl \ -disable-dom --prefix=/usr --disable-cgi \ --disable-spl --disable-xml --without-pear \ --disable-ipv6 --enable-shmop
#33772 [Opn->Ctl]: __destruct happens befor "hes" time
ID: 33772 Updated by: [EMAIL PROTECTED] Reported By: msipria at suomi24 dot fi -Status: Open +Status: Critical Bug Type: Class/Object related -Operating System: Windows XP +Operating System: * -PHP Version: 5.1.0b3 +PHP Version: 5CVS-2005-07-19 New Comment: I need this fixed too, it's not possible to use e.g. mysqli as save handler otherwise.. Previous Comments: [2005-07-19 16:47:51] msipria at suomi24 dot fi Description: I have session handling class and i have db class that i pass to the session handling class. As of PHP 5.1.0b1 order of going throu __destructers have been changed, so at end eaven DB class exsist its __destucter has been runned. removing __destruct from DB class will not help, coz mysql link has own __destruct function that it will run. i realy hope this is bug (that can fix) and it will be fixed, other whay i'm stuck with 5.0.x or have to re write lots of source code. Reproduce code: --- http://www.wiofso.com/~msipria/testi.txt Expected result: In PHP 5.0.x (working) __construct = LINK open = LINK read = LINK write = LINK close = LINK __destruct = KILLED LINK Actual result: -- In PHP 5.1.0b3 (tested b1-b3) (not working) __construct = LINK open = LINK read = LINK __destruct = KILLED LINK write = KILLED LINK close = KILLED LINK -- Edit this bug report at http://bugs.php.net/?id=33772&edit=1
#33758 [Opn->Asn]: segfault in imap_mail_compose
ID: 33758 Updated by: [EMAIL PROTECTED] Reported By: 0602 at eq dot cz -Status: Open +Status: Assigned Bug Type: IMAP related Operating System: Slackware Linux PHP Version: 4.4.0 -Assigned To: +Assigned To: iliaa New Comment: Assigned to Ilia who said he could reproduce this. Previous Comments: [2005-07-19 02:19:22] 0602 at eq dot cz The crash is reproducible with c-client from pine 4.62 and 4.63, build script is similar to this one: ftp://ftp.slackware.com/pub/slackware/slackware-current/source/n/php/php.SlackBuild with the exception that I use apache2, i.e. different apxs. I don't get the segfault with php 4.3.10 and c-client from pine 4.63. [2005-07-19 00:07:00] [EMAIL PROTECTED] I can not reproduce this. Exactly what c-client version are you compiling PHP with? What configure line did you use? [2005-07-18 23:58:38] 0602 at eq dot cz # gdb /usr/local/apache2/bin/httpd GNU gdb 5.3 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-slackware-linux"... (gdb) run -X Starting program: /usr/local/apache2/bin/httpd -X [New Thread 16384 (LWP 7894)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 7894)] 0x003ba3bd in pthread_mutex_lock () from /lib/libpthread.so.0 (gdb) bt #0 0x003ba3bd in pthread_mutex_lock () from /lib/libpthread.so.0 #1 0x0047e880 in free () from /lib/libc.so.6 #2 0x00785bee in fs_give () from /usr/local/apache2/modules/libphp4.so #3 0x00795199 in mail_free_body_parameter () from /usr/local/apache2/modules/libphp4.so #4 0x00794f94 in mail_free_body_data () from /usr/local/apache2/modules/libphp4.so #5 0x007951c5 in mail_free_body_part () from /usr/local/apache2/modules/libphp4.so #6 0x00795140 in mail_free_body_data () from /usr/local/apache2/modules/libphp4.so #7 0x00794f4d in mail_free_body () from /usr/local/apache2/modules/libphp4.so #8 0x006540dc in zif_imap_mail_compose () from /usr/local/apache2/modules/libphp4.so #9 0x00774c60 in execute () from /usr/local/apache2/modules/libphp4.so #10 0x00761471 in zend_execute_scripts () from /usr/local/apache2/modules/libphp4.so #11 0x0072ca3c in php_execute_script () from /usr/local/apache2/modules/libphp4.so #12 0x0077ab2c in execute () from /usr/local/apache2/modules/libphp4.so #13 0x0806712a in ap_run_handler (r=0x822a7f0) at config.c:153 #14 0x08067642 in ap_invoke_handler (r=0x822a7f0) at config.c:364 #15 0x08064a3f in ap_process_request (r=0x822a7f0) at http_request.c:249 #16 0x08060af9 in ap_process_http_connection (c=0x82248b0) at http_core.c:251 #17 0x0806f3f6 in ap_run_process_connection (c=0x82248b0) at connection.c:43 #18 0x08065ca3 in child_main (child_num_arg=3) at prefork.c:610 #19 0x08065e4e in make_child (s=0x809c340, slot=0) at prefork.c:650 #20 0x08065ea7 in startup_children (number_to_start=2) at prefork.c:722 #21 0x080665b5 in ap_mpm_run (_pconf=0x806566c, plog=0x80c4638, s=0x809c340) at prefork.c:941 #22 0x0806b56a in main (argc=2, argv=0xba24) at main.c:618 #23 0x0041ebb4 in __libc_start_main () from /lib/libc.so.6 (gdb) [2005-07-18 20:55:08] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2005-07-18 20:46:03] 0602 at eq dot cz Description: Whenever I run following code with imap_mail_compose() function, something like this gets logged: "[notice] child pid 11556 exit signal Segmentation fault (11)". Functions imap_listmailbox(), imap_headers() and imap_open() are working fine. Reproduce code: --- -- Edit this bug report at http://bugs.php.net/?id=33758&edit=1
#32589 [Opn->Bgs]: imap_mail_compose doesn´t work properly
ID: 32589 Updated by: [EMAIL PROTECTED] Reported By: svoboda at svoon dot net -Status: Open +Status: Bogus Bug Type: IMAP related Operating System: debian PHP Version: 4.4.0 New Comment: You're not really using PHP 4.4.0 downloaded from php.net. The snapshot and release packages do NOT differ anywhere near IMAP stuff. Previous Comments: [2005-07-19 12:16:20] svoboda at svoon dot net hello, in new version php 4.4.0 the bug remains. Script outputs no data, error log is empty too, only processing exit. If I compile version php4-STABLE-200412272330 with the same configure command, it works well. I have c-client with kerberos from debian packages libc-client-dev libc-client-ssl2001 libc-client2002edebian If you need some more info, pleas let me know. thank you a lot [2005-04-09 09:46:25] [EMAIL PROTECTED] I can not reproduce this either with latest CVS (any branch). (and snapshots are fine too) Get the latest here: http://snaps.php.net/php4-STABLE-latest.tar.gz [2005-04-09 04:55:09] svoboda at svoon dot net I have tryied php4-STABLE-200504090239, but the problem still remains. [2005-04-05 16:49:22] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2005-04-05 14:59:05] svoboda at svoon dot net Description: when use charset field in part array, fction exit with segmentation fault. Reproduce code: --- $m_envelope["To"] = "[EMAIL PROTECTED]"; $m_part1["type"] = TYPEMULTIPART; $m_part1["subtype"] = "mixed"; $m_part2["type"] = TYPETEXT; $m_part2["subtype"] = "plain"; $m_part2["description"] = "text_message"; $m_part2["charset"] = "ISO-8859-2"; $m_part2["contents.data"] = "hello"; $m_body[1] = $m_part1; $m_body[2] = $m_part2; echo nl2br(imap_mail_compose($m_envelope, $m_body)); -- Edit this bug report at http://bugs.php.net/?id=32589&edit=1
#33708 [Opn->Fbk]: Problem with php module recode
ID: 33708
Updated by: [EMAIL PROTECTED]
Reported By: kirameku at email dot cz
-Status: Open
+Status: Feedback
Bug Type: Recode related
Operating System: RedHat ES4 x86_64
-PHP Version: 4.4.0
+PHP Version: 4CVS, 5CVS (2005-07-19)
Previous Comments:
[2005-07-19 20:58:29] [EMAIL PROTECTED]
Please don't attach the same backtrace more than once.
I deleted that comment. You reported that your compiler is:
gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.1)
Try this:
# rm config.cache && ./configure --disable-all --disable-cgi
--with-recode
# make clean && make
# run -r 'echo recode_string("utf-8..html_4.0","Hello, World !");'
[2005-07-19 10:39:45] kirameku at email dot cz
I used CVS snapshot php5-200507190630, but the problem persisting.
gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.1)
/home/Develop/php5-200507190630/ext/recode/recode.c: In function
`zif_recode_string':
/home/Develop/php5-200507190630/ext/recode/recode.c:152: warning:
passing arg 5 of `recode_buffer_to_buffer' from incompatible pointer
type
/home/Develop/php5-200507190630/ext/recode/recode.c:152: warning:
passing arg 6 of `recode_buffer_to_buffer' from incompatible pointer
type
# ./php test.php
Segmentation fault (core dumped)
[EMAIL PROTECTED] cli]# gdb ./php core.5723
GNU gdb Red Hat Linux (6.3.0.0-0.31rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host
libthread_db library "/lib64/tls/libthread_db.so.1".
Core was generated by `./php test.php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib64/libcrypt.so.1...done.
Loaded symbols for /lib64/libcrypt.so.1
Reading symbols from /usr/lib64/librecode.so.0...done.
Loaded symbols for /usr/lib64/librecode.so.0
Reading symbols from /usr/lib64/libpng12.so.0...done.
Loaded symbols for /usr/lib64/libpng12.so.0
Reading symbols from /usr/lib64/libz.so.1...done.
Loaded symbols for /usr/lib64/libz.so.1
Reading symbols from /usr/lib64/libjpeg.so.62...done.
Loaded symbols for /usr/lib64/libjpeg.so.62
Reading symbols from /lib64/libresolv.so.2...done.
Loaded symbols for /lib64/libresolv.so.2
Reading symbols from /lib64/tls/libm.so.6...done.
Loaded symbols for /lib64/tls/libm.so.6
Reading symbols from /lib64/libdl.so.2...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/libnsl.so.1...done.
Loaded symbols for /lib64/libnsl.so.1
Reading symbols from /lib64/libssl.so.4...done.
Loaded symbols for /lib64/libssl.so.4
Reading symbols from /lib64/libcrypto.so.4...done.
Loaded symbols for /lib64/libcrypto.so.4
Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done.
Loaded symbols for /usr/lib64/libgssapi_krb5.so.2
Reading symbols from /usr/lib64/libkrb5.so.3...done.
Loaded symbols for /usr/lib64/libkrb5.so.3
Reading symbols from /lib64/libcom_err.so.2...done.
Loaded symbols for /lib64/libcom_err.so.2
Reading symbols from /usr/lib64/libk5crypto.so.3...done.
Loaded symbols for /usr/lib64/libk5crypto.so.3
Reading symbols from /usr/lib64/libxml2.so.2...done.
Loaded symbols for /usr/lib64/libxml2.so.2
Reading symbols from /lib64/tls/libpthread.so.0...done.
Loaded symbols for /lib64/tls/libpthread.so.0
Reading symbols from /lib64/tls/libc.so.6...done.
Loaded symbols for /lib64/tls/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libnss_files.so.2...done.
Loaded symbols for /lib64/libnss_files.so.2
#0 0x0038693b7865 in delmodule_flat () from
/usr/lib64/librecode.so.0
(gdb) bt
#0 0x0038693b7865 in delmodule_flat () from
/usr/lib64/librecode.so.0
#1 0x0038693aa50d in recode_new_task () from
/usr/lib64/librecode.so.0
#2 0x0038693aa82e in recode_perform_task () from
/usr/lib64/librecode.so.0
#3 0x0038693a924c in recode_buffer_to_buffer () from
/usr/lib64/librecode.so.0
#4 0x0053d5dd in zif_recode_string (ht=72,
return_value=0xc5ba48, return_value_ptr=0x48, this_ptr=0xc60f60,
return_value_used=-1073771232)
at /home/Develop/php5-200507190630/ext/recode/recode.c:152
#5 0x0069a1db in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fbfffd090) at
/home/Develop/php5-200507190630/Zend/zend_vm_execute.h:184
#6 0x006999dc in execute (op_array=0xc5c5f8) at
/home/Develop/php5-200507190630/Zend/zend_vm_execute.h:87
#7 0x00673cb9 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/Develop/php5-200507190630/Zend/zend.c:1087
#8 0x0063661f in php_execute_s
#33708 [Opn]: Problem with php module recode
ID: 33708
Updated by: [EMAIL PROTECTED]
Reported By: kirameku at email dot cz
Status: Open
Bug Type: Recode related
Operating System: RedHat ES4 x86_64
PHP Version: 4.4.0
New Comment:
Please don't attach the same backtrace more than once.
I deleted that comment. You reported that your compiler is:
gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.1)
Try this:
# rm config.cache && ./configure --disable-all --disable-cgi
--with-recode
# make clean && make
# run -r 'echo recode_string("utf-8..html_4.0","Hello, World !");'
Previous Comments:
[2005-07-19 10:39:45] kirameku at email dot cz
I used CVS snapshot php5-200507190630, but the problem persisting.
gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.1)
/home/Develop/php5-200507190630/ext/recode/recode.c: In function
`zif_recode_string':
/home/Develop/php5-200507190630/ext/recode/recode.c:152: warning:
passing arg 5 of `recode_buffer_to_buffer' from incompatible pointer
type
/home/Develop/php5-200507190630/ext/recode/recode.c:152: warning:
passing arg 6 of `recode_buffer_to_buffer' from incompatible pointer
type
# ./php test.php
Segmentation fault (core dumped)
[EMAIL PROTECTED] cli]# gdb ./php core.5723
GNU gdb Red Hat Linux (6.3.0.0-0.31rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host
libthread_db library "/lib64/tls/libthread_db.so.1".
Core was generated by `./php test.php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib64/libcrypt.so.1...done.
Loaded symbols for /lib64/libcrypt.so.1
Reading symbols from /usr/lib64/librecode.so.0...done.
Loaded symbols for /usr/lib64/librecode.so.0
Reading symbols from /usr/lib64/libpng12.so.0...done.
Loaded symbols for /usr/lib64/libpng12.so.0
Reading symbols from /usr/lib64/libz.so.1...done.
Loaded symbols for /usr/lib64/libz.so.1
Reading symbols from /usr/lib64/libjpeg.so.62...done.
Loaded symbols for /usr/lib64/libjpeg.so.62
Reading symbols from /lib64/libresolv.so.2...done.
Loaded symbols for /lib64/libresolv.so.2
Reading symbols from /lib64/tls/libm.so.6...done.
Loaded symbols for /lib64/tls/libm.so.6
Reading symbols from /lib64/libdl.so.2...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/libnsl.so.1...done.
Loaded symbols for /lib64/libnsl.so.1
Reading symbols from /lib64/libssl.so.4...done.
Loaded symbols for /lib64/libssl.so.4
Reading symbols from /lib64/libcrypto.so.4...done.
Loaded symbols for /lib64/libcrypto.so.4
Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done.
Loaded symbols for /usr/lib64/libgssapi_krb5.so.2
Reading symbols from /usr/lib64/libkrb5.so.3...done.
Loaded symbols for /usr/lib64/libkrb5.so.3
Reading symbols from /lib64/libcom_err.so.2...done.
Loaded symbols for /lib64/libcom_err.so.2
Reading symbols from /usr/lib64/libk5crypto.so.3...done.
Loaded symbols for /usr/lib64/libk5crypto.so.3
Reading symbols from /usr/lib64/libxml2.so.2...done.
Loaded symbols for /usr/lib64/libxml2.so.2
Reading symbols from /lib64/tls/libpthread.so.0...done.
Loaded symbols for /lib64/tls/libpthread.so.0
Reading symbols from /lib64/tls/libc.so.6...done.
Loaded symbols for /lib64/tls/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libnss_files.so.2...done.
Loaded symbols for /lib64/libnss_files.so.2
#0 0x0038693b7865 in delmodule_flat () from
/usr/lib64/librecode.so.0
(gdb) bt
#0 0x0038693b7865 in delmodule_flat () from
/usr/lib64/librecode.so.0
#1 0x0038693aa50d in recode_new_task () from
/usr/lib64/librecode.so.0
#2 0x0038693aa82e in recode_perform_task () from
/usr/lib64/librecode.so.0
#3 0x0038693a924c in recode_buffer_to_buffer () from
/usr/lib64/librecode.so.0
#4 0x0053d5dd in zif_recode_string (ht=72,
return_value=0xc5ba48, return_value_ptr=0x48, this_ptr=0xc60f60,
return_value_used=-1073771232)
at /home/Develop/php5-200507190630/ext/recode/recode.c:152
#5 0x0069a1db in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fbfffd090) at
/home/Develop/php5-200507190630/Zend/zend_vm_execute.h:184
#6 0x006999dc in execute (op_array=0xc5c5f8) at
/home/Develop/php5-200507190630/Zend/zend_vm_execute.h:87
#7 0x00673cb9 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/Develop/php5-200507190630/Zend/zend.c:1087
#8 0x0063661f in php_execute_script
(primary_file=0x7fb830) at
/home/Develop/php5-200507190630/main/main.c:1672
#9 0x007074c0 in main (argc=2, argv=0x7fb988) at
/home/Develop/php5-20050
#33750 [Opn->Bgs]: Solution to ID's 8527 & 8588 not working for me
ID: 33750 Updated by: [EMAIL PROTECTED] Reported By: checkforabcd at yahoo dot com -Status: Open +Status: Bogus Bug Type: Session related Operating System: WinXP PHP Version: 4.3.11 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2005-07-19 13:59:07] checkforabcd at yahoo dot com ok.. My windows internet settings were perfectly fine. The sessions cookies were supported by default. As for the mozilla stuff, it didn't work either & no errors or headers were shown. Now what should I do to solve the problem [2005-07-18 19:34:51] [EMAIL PROTECTED] 1) Don't touch session.cookie.path 2) Fix your browser and make it to support session cookies (it's known winblows "security improvement"). 3) Check what headers you get with some sniffer (or just use Mozilla). [2005-07-18 17:21:01] checkforabcd at yahoo dot com Description: I have checked the bug reports with ID 8527 & 8588 which were having exactly the same problem as mine with the only difference that the solution given for them isn't working in my case, ie, I set the "session.cookie_path" to "/" & still the problem just won't go away. Please help... Reproduce code: --- checkuser.php //location :surevin.com/tender/checkuser.php http://www.surevin.com/tender/radmin/secondpage.php'); exit(); ?> secondpage.php Expected result: The value of madmin is : abcd Actual result: -- The value of madmin is : -- Edit this bug report at http://bugs.php.net/?id=33750&edit=1
#33774 [Opn->Fbk]: Recieving "FATAL: emalloc()" error
ID: 33774 Updated by: [EMAIL PROTECTED] Reported By: brandonnimon at comcast dot net -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: Windows XP SP2 PHP Version: 4.4.0 New Comment: Please reread my previous post. Reopen the report only when you have a *single* script max. 10-20 lines long (it can be bigger, but I doubt that someone will have enough willingness to debug 300Kb of code). Previous Comments: [2005-07-19 19:58:31] brandonnimon at comcast dot net Available source: http://67.181.154.141:81/guestbookadminsource/ The errors in my program are fixed, but that is not this bug is about (read expected result). The program was just missing a couple variables from a newly created function. I did not update the source, so the bug can be analized. [2005-07-19 19:12:29] [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-07-19 19:05:46] brandonnimon at comcast dot net I think you will also need entryformat.php once you have some entries in. [2005-07-19 19:02:06] brandonnimon at comcast dot net Description: I am programming a PHP program and have recently upgraded to PHP 4.4.0 (from 4.3.11). The current program I had did not have any issues. But I wrote more of the program and ran into a "FATAL: emalloc() [could not allocate 25948985 bytes]". I don't have the exact error, since my error log got wiped. I reverted back to 4.3.11 to see if it would give me any real errors (since I knew there were some core updates in 4.4.0). It gave me 1.8GB of real errors and corrupted my error log. I ran the test again on a fresh error log, stopped it sooner (less than a second) which gave me 66 lines of errors. There are some problems with my program (and they happened to be in/cause and infinite loop: [Tue Jul 19 09:10:21 2005] [error] PHP Warning: array_shift(): The argument should be an array in c:\\program files\\apache group\\apache\\htdocs\\guestbookadmin\\commoncode.php on line 170 [Tue Jul 19 09:10:21 2005] [error] PHP Notice: Undefined variable: active_entries in c:\\program files\\apache group\\apache\\htdocs\\guestbookadmin\\commoncode.php on line 169 But it seems that 4.3.11 should limit the number of errors logged, and 4.4.0 should display more than an emalloc() error. The only change I've made to my PHP file, other than upload settings, is the max script time is set to 24 hours and max memory alotment is 250MB (plenty of memory to go around). Reproduce code: --- http://67.181.154.141:81/guestbookadminsource/ there should be a list of the page's .source files. This site is only up while I am awake (7:30am - 11:00pm PST -weekdays; 10:00am - 12:00am PST -weekends). You can either click on each file to show highlighted source, or click the "edit" link on the right to get the source. The files you need (I think -- worst comes to worst, copy all the files as PHP files and run the program, it will self-install) to reproduce the errors are commoncode.php, logintest.php, settings.php, manage.php, hycodeii.php, inout.php. To reproduce: -open inout.php and add a few posts (enter the info at the top). -login to guestbook admin by opening manage.php and type "admin", password: "password". -You should see a list of the entries you just put in. Hit "accept" on any of them. -The system will seem to lockup. Hit "stop" and check your error log. Expected result: If you are running my program, it should say "entry #.. has been accepted" and move that entry to the active entry list. As for PHP, it shouldn't just say "FATAL: emalloc()..." it should have what actually happend (like with 4.3.11, but shorter). Actual result: -- I think you've gotten the drift of what actually happens. To recap: 4.4.0 stops the browser, and posts "FATAL: emalloc()..." to the error log. 4.3.11 posts an infinite amout of errors to the error log. -- Edit this bug report at http://bugs.php.net/?id=33774&edit=1
#33774 [Fbk->Opn]: Recieving "FATAL: emalloc()" error
ID: 33774 User updated by: brandonnimon at comcast dot net Reported By: brandonnimon at comcast dot net -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Windows XP SP2 PHP Version: 4.4.0 New Comment: Available source: http://67.181.154.141:81/guestbookadminsource/ The errors in my program are fixed, but that is not this bug is about (read expected result). The program was just missing a couple variables from a newly created function. I did not update the source, so the bug can be analized. Previous Comments: [2005-07-19 19:12:29] [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-07-19 19:05:46] brandonnimon at comcast dot net I think you will also need entryformat.php once you have some entries in. [2005-07-19 19:02:06] brandonnimon at comcast dot net Description: I am programming a PHP program and have recently upgraded to PHP 4.4.0 (from 4.3.11). The current program I had did not have any issues. But I wrote more of the program and ran into a "FATAL: emalloc() [could not allocate 25948985 bytes]". I don't have the exact error, since my error log got wiped. I reverted back to 4.3.11 to see if it would give me any real errors (since I knew there were some core updates in 4.4.0). It gave me 1.8GB of real errors and corrupted my error log. I ran the test again on a fresh error log, stopped it sooner (less than a second) which gave me 66 lines of errors. There are some problems with my program (and they happened to be in/cause and infinite loop: [Tue Jul 19 09:10:21 2005] [error] PHP Warning: array_shift(): The argument should be an array in c:\\program files\\apache group\\apache\\htdocs\\guestbookadmin\\commoncode.php on line 170 [Tue Jul 19 09:10:21 2005] [error] PHP Notice: Undefined variable: active_entries in c:\\program files\\apache group\\apache\\htdocs\\guestbookadmin\\commoncode.php on line 169 But it seems that 4.3.11 should limit the number of errors logged, and 4.4.0 should display more than an emalloc() error. The only change I've made to my PHP file, other than upload settings, is the max script time is set to 24 hours and max memory alotment is 250MB (plenty of memory to go around). Reproduce code: --- http://67.181.154.141:81/guestbookadminsource/ there should be a list of the page's .source files. This site is only up while I am awake (7:30am - 11:00pm PST -weekdays; 10:00am - 12:00am PST -weekends). You can either click on each file to show highlighted source, or click the "edit" link on the right to get the source. The files you need (I think -- worst comes to worst, copy all the files as PHP files and run the program, it will self-install) to reproduce the errors are commoncode.php, logintest.php, settings.php, manage.php, hycodeii.php, inout.php. To reproduce: -open inout.php and add a few posts (enter the info at the top). -login to guestbook admin by opening manage.php and type "admin", password: "password". -You should see a list of the entries you just put in. Hit "accept" on any of them. -The system will seem to lockup. Hit "stop" and check your error log. Expected result: If you are running my program, it should say "entry #.. has been accepted" and move that entry to the active entry list. As for PHP, it shouldn't just say "FATAL: emalloc()..." it should have what actually happend (like with 4.3.11, but shorter). Actual result: -- I think you've gotten the drift of what actually happens. To recap: 4.4.0 stops the browser, and posts "FATAL: emalloc()..." to the error log. 4.3.11 posts an infinite amout of errors to the error log. -- Edit this bug report at http://bugs.php.net/?id=33774&edit=1
#33717 [Opn->Csd]: PDO_SQLITE: crash when a query contains ':memory:'
ID: 33717 Updated by: [EMAIL PROTECTED] Reported By: fhenninot at freesurf dot fr -Status: Open +Status: Closed Bug Type: PDO related Operating System: Linux PHP Version: 5.1.0b3 Assigned To: wez New Comment: Marking as "closed" then. Previous Comments: [2005-07-19 20:05:10] fhenninot at freesurf dot fr Yes that perfectly works. Thank you very much! Fred [2005-07-18 16:49:08] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Seems to work for me with CVS HEAD. Please try the snap dated after this message to confirm; a self-contained test case will help to really nail the problem if it persists. [2005-07-18 02:28:19] [EMAIL PROTECTED] See also bug #33737 [2005-07-16 20:04:49] fhenninot at freesurf dot fr The two problem seem identical! I've generate the backtrace! #0 _efree (ptr=0x0) at /usr/src/php-5.1.0b3/Zend/zend_alloc.c:285 #1 0x4042f880 in free_statement (stmt=0x821ae24) at /usr/src/php-5.1.0b3/ext/pdo/pdo_stmt.c:1937 #2 0x40568d09 in zend_objects_store_del_ref (zobject=0x821ae24) at /usr/src/php-5.1.0b3/Zend/zend_objects_API.c:161 #3 0x405487f1 in _zval_ptr_dtor (zval_ptr=0x82184b0) at zend_variables.h:35 #4 0x4055ba6d in zend_hash_apply_deleter (ht=0x406c8c50, p=0x82184a4) at /usr/src/php-5.1.0b3/Zend/zend_hash.c:574 #5 0x4055bad7 in zend_hash_graceful_reverse_destroy (ht=0x406c8c50) at /usr/src/php-5.1.0b3/Zend/zend_hash.c:640 #6 0x40548e54 in shutdown_executor () at /usr/src/php-5.1.0b3/Zend/zend_execute_API.c:216 #7 0x40554433 in zend_deactivate () at /usr/src/php-5.1.0b3/Zend/zend.c:823 #8 0x4051d777 in php_request_shutdown (dummy=0x0) at /usr/src/php-5.1.0b3/main/main.c:1238 #9 0x405d7d94 in php_handler (r=0x8209c30) at /usr/src/php-5.1.0b3/sapi/apache2handler/sapi_apache2.c:443 #10 0x0807e86b in ap_run_handler (r=0x8209c30) at config.c:151 #11 0x0807edee in ap_invoke_handler (r=0x8209c30) at config.c:363 #12 0x0806d4cb in ap_process_request (r=0x8209c30) at http_request.c:246 #13 0x080691ec in ap_process_http_connection (c=0x82053b8) at http_core.c:250 #14 0x0808861b in ap_run_process_connection (c=0x82053b8) at connection.c:42 #15 0x0807d346 in child_main (child_num_arg=0) at prefork.c:609 #16 0x0807d45d in make_child (s=0x80be7e0, slot=0) at prefork.c:649 #17 0x0807d524 in startup_children (number_to_start=5) at prefork.c:721 #18 0x0807db8d in ap_mpm_run (_pconf=0x80ba0a8, plog=0x80f2188, s=0x80be7e0) at prefork.c:940 #19 0x08082fda in main (argc=2, argv=0xb7d4) at main.c:617 [2005-07-16 16:09:25] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Please provide a backtrace for both of those crashes 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/33717 -- Edit this bug report at http://bugs.php.net/?id=33717&edit=1
#33717 [Fbk->Opn]: PDO_SQLITE: crash when a query contains ':memory:'
ID: 33717 User updated by: fhenninot at freesurf dot fr Reported By: fhenninot at freesurf dot fr -Status: Feedback +Status: Open Bug Type: PDO related Operating System: Linux PHP Version: 5.1.0b3 Assigned To: wez New Comment: Yes that perfectly works. Thank you very much! Fred Previous Comments: [2005-07-18 16:49:08] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Seems to work for me with CVS HEAD. Please try the snap dated after this message to confirm; a self-contained test case will help to really nail the problem if it persists. [2005-07-18 02:28:19] [EMAIL PROTECTED] See also bug #33737 [2005-07-16 20:04:49] fhenninot at freesurf dot fr The two problem seem identical! I've generate the backtrace! #0 _efree (ptr=0x0) at /usr/src/php-5.1.0b3/Zend/zend_alloc.c:285 #1 0x4042f880 in free_statement (stmt=0x821ae24) at /usr/src/php-5.1.0b3/ext/pdo/pdo_stmt.c:1937 #2 0x40568d09 in zend_objects_store_del_ref (zobject=0x821ae24) at /usr/src/php-5.1.0b3/Zend/zend_objects_API.c:161 #3 0x405487f1 in _zval_ptr_dtor (zval_ptr=0x82184b0) at zend_variables.h:35 #4 0x4055ba6d in zend_hash_apply_deleter (ht=0x406c8c50, p=0x82184a4) at /usr/src/php-5.1.0b3/Zend/zend_hash.c:574 #5 0x4055bad7 in zend_hash_graceful_reverse_destroy (ht=0x406c8c50) at /usr/src/php-5.1.0b3/Zend/zend_hash.c:640 #6 0x40548e54 in shutdown_executor () at /usr/src/php-5.1.0b3/Zend/zend_execute_API.c:216 #7 0x40554433 in zend_deactivate () at /usr/src/php-5.1.0b3/Zend/zend.c:823 #8 0x4051d777 in php_request_shutdown (dummy=0x0) at /usr/src/php-5.1.0b3/main/main.c:1238 #9 0x405d7d94 in php_handler (r=0x8209c30) at /usr/src/php-5.1.0b3/sapi/apache2handler/sapi_apache2.c:443 #10 0x0807e86b in ap_run_handler (r=0x8209c30) at config.c:151 #11 0x0807edee in ap_invoke_handler (r=0x8209c30) at config.c:363 #12 0x0806d4cb in ap_process_request (r=0x8209c30) at http_request.c:246 #13 0x080691ec in ap_process_http_connection (c=0x82053b8) at http_core.c:250 #14 0x0808861b in ap_run_process_connection (c=0x82053b8) at connection.c:42 #15 0x0807d346 in child_main (child_num_arg=0) at prefork.c:609 #16 0x0807d45d in make_child (s=0x80be7e0, slot=0) at prefork.c:649 #17 0x0807d524 in startup_children (number_to_start=5) at prefork.c:721 #18 0x0807db8d in ap_mpm_run (_pconf=0x80ba0a8, plog=0x80f2188, s=0x80be7e0) at prefork.c:940 #19 0x08082fda in main (argc=2, argv=0xb7d4) at main.c:617 [2005-07-16 16:09:25] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. Please provide a backtrace for both of those crashes [2005-07-16 10:53:34] fhenninot at freesurf dot fr hi wez! thank you for your help! but!! If i use parameters, this don't crash apache!! ok! but if my table haven't record like the parameter (now not only '::memory') then that kill the PHP script!! I've test it on beta2 and this work properly but with beta3 crashed. 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/33717 -- Edit this bug report at http://bugs.php.net/?id=33717&edit=1
#33773 [Opn->Csd]: str_replace recursion
ID: 33773
User updated by: tomlove at gmail dot com
-Summary: str_replace - recursive replace for arrays is
dangerous
Reported By: tomlove at gmail dot com
-Status: Open
+Status: Closed
Bug Type: Feature/Change Request
Operating System: Linux / Windows
PHP Version: 4.3.11
New Comment:
Actually, I realise it wouldn't be a trivial to change this behaviour.
Probably better to leave checks for recursive cases to the script.
Previous Comments:
[2005-07-19 18:14:12] tomlove at gmail dot com
Description:
I assume this is a feature: str_replace recursively replaces when both
$search and $replace are arrays.
It's too easy for this to cause runaway memory consumption though.
I've never needed to take advantage of the recursive nature of the
function, and wouldn't expect many others to.
The code below is enough to hang my system.
Reproduce code:
---
for ($i = 0; $i < 50; $i++) {
$arr1[$i] = "foo";
$arr2[$i] = "foobarfoo";
}
$str = "foobar";
echo str_replace($arr1, $arr2, $str);
Expected result:
Ideally:
foobarfoobar
Actual result:
--
foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar
--
Edit this bug report at http://bugs.php.net/?id=33773&edit=1
#33774 [Opn->Fbk]: Recieving "FATAL: emalloc()" error
ID: 33774 Updated by: [EMAIL PROTECTED] Reported By: brandonnimon at comcast dot net -Status: Open +Status: Feedback -Bug Type: Reproducible crash +Bug Type: Unknown/Other Function Operating System: Windows XP SP2 PHP Version: 4.4.0 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. Previous Comments: [2005-07-19 19:05:46] brandonnimon at comcast dot net I think you will also need entryformat.php once you have some entries in. [2005-07-19 19:02:06] brandonnimon at comcast dot net Description: I am programming a PHP program and have recently upgraded to PHP 4.4.0 (from 4.3.11). The current program I had did not have any issues. But I wrote more of the program and ran into a "FATAL: emalloc() [could not allocate 25948985 bytes]". I don't have the exact error, since my error log got wiped. I reverted back to 4.3.11 to see if it would give me any real errors (since I knew there were some core updates in 4.4.0). It gave me 1.8GB of real errors and corrupted my error log. I ran the test again on a fresh error log, stopped it sooner (less than a second) which gave me 66 lines of errors. There are some problems with my program (and they happened to be in/cause and infinite loop: [Tue Jul 19 09:10:21 2005] [error] PHP Warning: array_shift(): The argument should be an array in c:\\program files\\apache group\\apache\\htdocs\\guestbookadmin\\commoncode.php on line 170 [Tue Jul 19 09:10:21 2005] [error] PHP Notice: Undefined variable: active_entries in c:\\program files\\apache group\\apache\\htdocs\\guestbookadmin\\commoncode.php on line 169 But it seems that 4.3.11 should limit the number of errors logged, and 4.4.0 should display more than an emalloc() error. The only change I've made to my PHP file, other than upload settings, is the max script time is set to 24 hours and max memory alotment is 250MB (plenty of memory to go around). Reproduce code: --- http://67.181.154.141:81/guestbookadminsource/ there should be a list of the page's .source files. This site is only up while I am awake (7:30am - 11:00pm PST -weekdays; 10:00am - 12:00am PST -weekends). You can either click on each file to show highlighted source, or click the "edit" link on the right to get the source. The files you need (I think -- worst comes to worst, copy all the files as PHP files and run the program, it will self-install) to reproduce the errors are commoncode.php, logintest.php, settings.php, manage.php, hycodeii.php, inout.php. To reproduce: -open inout.php and add a few posts (enter the info at the top). -login to guestbook admin by opening manage.php and type "admin", password: "password". -You should see a list of the entries you just put in. Hit "accept" on any of them. -The system will seem to lockup. Hit "stop" and check your error log. Expected result: If you are running my program, it should say "entry #.. has been accepted" and move that entry to the active entry list. As for PHP, it shouldn't just say "FATAL: emalloc()..." it should have what actually happend (like with 4.3.11, but shorter). Actual result: -- I think you've gotten the drift of what actually happens. To recap: 4.4.0 stops the browser, and posts "FATAL: emalloc()..." to the error log. 4.3.11 posts an infinite amout of errors to the error log. -- Edit this bug report at http://bugs.php.net/?id=33774&edit=1
#33774 [Opn]: Recieving "FATAL: emalloc()" error
ID: 33774 User updated by: brandonnimon at comcast dot net Reported By: brandonnimon at comcast dot net Status: Open Bug Type: Reproducible crash Operating System: Windows XP SP2 PHP Version: 4.4.0 New Comment: I think you will also need entryformat.php once you have some entries in. Previous Comments: [2005-07-19 19:02:06] brandonnimon at comcast dot net Description: I am programming a PHP program and have recently upgraded to PHP 4.4.0 (from 4.3.11). The current program I had did not have any issues. But I wrote more of the program and ran into a "FATAL: emalloc() [could not allocate 25948985 bytes]". I don't have the exact error, since my error log got wiped. I reverted back to 4.3.11 to see if it would give me any real errors (since I knew there were some core updates in 4.4.0). It gave me 1.8GB of real errors and corrupted my error log. I ran the test again on a fresh error log, stopped it sooner (less than a second) which gave me 66 lines of errors. There are some problems with my program (and they happened to be in/cause and infinite loop: [Tue Jul 19 09:10:21 2005] [error] PHP Warning: array_shift(): The argument should be an array in c:\\program files\\apache group\\apache\\htdocs\\guestbookadmin\\commoncode.php on line 170 [Tue Jul 19 09:10:21 2005] [error] PHP Notice: Undefined variable: active_entries in c:\\program files\\apache group\\apache\\htdocs\\guestbookadmin\\commoncode.php on line 169 But it seems that 4.3.11 should limit the number of errors logged, and 4.4.0 should display more than an emalloc() error. The only change I've made to my PHP file, other than upload settings, is the max script time is set to 24 hours and max memory alotment is 250MB (plenty of memory to go around). Reproduce code: --- http://67.181.154.141:81/guestbookadminsource/ there should be a list of the page's .source files. This site is only up while I am awake (7:30am - 11:00pm PST -weekdays; 10:00am - 12:00am PST -weekends). You can either click on each file to show highlighted source, or click the "edit" link on the right to get the source. The files you need (I think -- worst comes to worst, copy all the files as PHP files and run the program, it will self-install) to reproduce the errors are commoncode.php, logintest.php, settings.php, manage.php, hycodeii.php, inout.php. To reproduce: -open inout.php and add a few posts (enter the info at the top). -login to guestbook admin by opening manage.php and type "admin", password: "password". -You should see a list of the entries you just put in. Hit "accept" on any of them. -The system will seem to lockup. Hit "stop" and check your error log. Expected result: If you are running my program, it should say "entry #.. has been accepted" and move that entry to the active entry list. As for PHP, it shouldn't just say "FATAL: emalloc()..." it should have what actually happend (like with 4.3.11, but shorter). Actual result: -- I think you've gotten the drift of what actually happens. To recap: 4.4.0 stops the browser, and posts "FATAL: emalloc()..." to the error log. 4.3.11 posts an infinite amout of errors to the error log. -- Edit this bug report at http://bugs.php.net/?id=33774&edit=1
#33774 [NEW]: Recieving "FATAL: emalloc()" error
From: brandonnimon at comcast dot net Operating system: Windows XP SP2 PHP version: 4.4.0 PHP Bug Type: Reproducible crash Bug description: Recieving "FATAL: emalloc()" error Description: I am programming a PHP program and have recently upgraded to PHP 4.4.0 (from 4.3.11). The current program I had did not have any issues. But I wrote more of the program and ran into a "FATAL: emalloc() [could not allocate 25948985 bytes]". I don't have the exact error, since my error log got wiped. I reverted back to 4.3.11 to see if it would give me any real errors (since I knew there were some core updates in 4.4.0). It gave me 1.8GB of real errors and corrupted my error log. I ran the test again on a fresh error log, stopped it sooner (less than a second) which gave me 66 lines of errors. There are some problems with my program (and they happened to be in/cause and infinite loop: [Tue Jul 19 09:10:21 2005] [error] PHP Warning: array_shift(): The argument should be an array in c:\\program files\\apache group\\apache\\htdocs\\guestbookadmin\\commoncode.php on line 170 [Tue Jul 19 09:10:21 2005] [error] PHP Notice: Undefined variable: active_entries in c:\\program files\\apache group\\apache\\htdocs\\guestbookadmin\\commoncode.php on line 169 But it seems that 4.3.11 should limit the number of errors logged, and 4.4.0 should display more than an emalloc() error. The only change I've made to my PHP file, other than upload settings, is the max script time is set to 24 hours and max memory alotment is 250MB (plenty of memory to go around). Reproduce code: --- http://67.181.154.141:81/guestbookadminsource/ there should be a list of the page's .source files. This site is only up while I am awake (7:30am - 11:00pm PST -weekdays; 10:00am - 12:00am PST -weekends). You can either click on each file to show highlighted source, or click the "edit" link on the right to get the source. The files you need (I think -- worst comes to worst, copy all the files as PHP files and run the program, it will self-install) to reproduce the errors are commoncode.php, logintest.php, settings.php, manage.php, hycodeii.php, inout.php. To reproduce: -open inout.php and add a few posts (enter the info at the top). -login to guestbook admin by opening manage.php and type "admin", password: "password". -You should see a list of the entries you just put in. Hit "accept" on any of them. -The system will seem to lockup. Hit "stop" and check your error log. Expected result: If you are running my program, it should say "entry #.. has been accepted" and move that entry to the active entry list. As for PHP, it shouldn't just say "FATAL: emalloc()..." it should have what actually happend (like with 4.3.11, but shorter). Actual result: -- I think you've gotten the drift of what actually happens. To recap: 4.4.0 stops the browser, and posts "FATAL: emalloc()..." to the error log. 4.3.11 posts an infinite amout of errors to the error log. -- Edit bug report at http://bugs.php.net/?id=33774&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33774&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33774&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33774&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33774&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33774&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33774&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33774&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33774&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33774&r=support Expected behavior: http://bugs.php.net/fix.php?id=33774&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33774&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33774&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33774&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33774&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33774&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33774&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33774&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33774&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33774&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33774&r=mysqlcfg
#33773 [NEW]: str_replace - recursive replace for arrays is dangerous
From: tomlove at gmail dot com
Operating system: Linux / Windows
PHP version: 4.3.11
PHP Bug Type: Feature/Change Request
Bug description: str_replace - recursive replace for arrays is dangerous
Description:
I assume this is a feature: str_replace recursively replaces when both
$search and $replace are arrays.
It's too easy for this to cause runaway memory consumption though.
I've never needed to take advantage of the recursive nature of the
function, and wouldn't expect many others to.
The code below is enough to hang my system.
Reproduce code:
---
for ($i = 0; $i < 50; $i++) {
$arr1[$i] = "foo";
$arr2[$i] = "foobarfoo";
}
$str = "foobar";
echo str_replace($arr1, $arr2, $str);
Expected result:
Ideally:
foobarfoobar
Actual result:
--
foobarfoobarfoobarfoobarfoobarfoobarfoobarfoobar
--
Edit bug report at http://bugs.php.net/?id=33773&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33773&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33773&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33773&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33773&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33773&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33773&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33773&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33773&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33773&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33773&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33773&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33773&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33773&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33773&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33773&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33773&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33773&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33773&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33773&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33773&r=mysqlcfg
#33533 [Asn->Csd]: PDO_ODBC: Segmentation Fault with selecting informix text column
ID: 33533 Updated by: [EMAIL PROTECTED] Reported By: scott dot barnett at thuringowa dot qld dot gov dot au -Status: Assigned +Status: Closed Bug Type: PDO related Operating System: CentOS 4.1 / Redhat Enterprise 4 PHP Version: 5CVS-2005-07-04 Assigned To: wez New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Current CVS (and thus the next snapshot) now handle arbitrary length columns; enjoy! Previous Comments: [2005-07-19 05:42:25] [EMAIL PROTECTED] I've added an arbitrary limit of 64k per text column for now, so that PHP doesn't kill your apache instance off (it was trying to allocate 2GB + 1 bytes per text column). It is likely that PDO_ODBC will now truncate any text columns that are longer than 64k; I'm working on a better long term fix. The very next snapshot should give you a more decent experience until then. [2005-07-19 05:27:40] scott dot barnett at thuringowa dot qld dot gov dot au (gdb) bt #0 0x0060f7a2 in ?? () from /lib/ld-linux.so.2 #1 0x0064fc76 in kill () from /lib/tls/libc.so.6 #2 0x00ec4f14 in _emalloc (size=2147483648, __zend_filename=0xf5c5b4 "/usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c", __zend_lineno=393, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/apache/php5-200507122030/Zend/zend_alloc.c:191 #3 0x00d58c90 in odbc_stmt_describe (stmt=0x8a1616c, colno=1) at /usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c:393 #4 0x00d5140c in pdo_stmt_describe_columns (stmt=0x8a1616c) at /usr/src/apache/php5-200507122030/ext/pdo/pdo_stmt.c:168 #5 0x00d508c3 in zif_PDO_query (ht=2, return_value=0x89b3b84, return_value_ptr=0x0, this_ptr=0x89b39dc, return_value_used=1) at /usr/src/apache/php5-200507122030/ext/pdo/pdo_dbh.c:912 #6 0x00f03eaa in zend_do_fcall_common_helper_SPEC (execute_data=0xbfe0d160) at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:184 #7 0x00f04713 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfe0d160) at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:299 #8 0x00f03b8b in execute (op_array=0x89aeaec) at /usr/src/apache/php5-200507122030/Zend/zend_vm_execute.h:87 #9 0x00edd699 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/apache/php5-200507122030/Zend/zend.c:1087 #10 0x00e9c995 in php_execute_script (primary_file=0xbfe0f4e0) at /usr/src/apache/php5-200507122030/main/main.c:1672 #11 0x00f48616 in php_handler (r=0x899fbe0) at /usr/src/apache/php5-200507122030/sapi/apache2handler/sapi_apache2.c:555 #12 0x0809953a in ap_run_handler (r=0x899fbe0) at config.c:152 #13 0x08099905 in ap_invoke_handler (r=0x899fbe0) at config.c:364 #14 0x0808255d in ap_process_request (r=0x899fbe0) at http_request.c:249 #15 0x0807e225 in ap_process_http_connection (c=0x848) at http_core.c:251 #16 0x080a2a02 in ap_run_process_connection (c=0x848) at connection.c:43 #17 0x08097d15 in child_main (child_num_arg=0) at prefork.c:610 #18 0x08097f09 in make_child (s=0x882ea08, slot=0) at prefork.c:650 #19 0x08097fd0 in startup_children (number_to_start=5) at prefork.c:722 #20 0x080986a3 in ap_mpm_run (_pconf=0xbfe0f830, plog=0x8863190, s=0xbfe0f834) at prefork.c:941 #21 0x0809d7a3 in main (argc=2, argv=0xbfe0f9d4) at main.c:618 (gdb) f 3 #3 0x00d58c90 in odbc_stmt_describe (stmt=0x8a1616c, colno=1) at /usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c:393 393 S->cols[colno].data = emalloc(colsize+1); (gdb) info locals S = (pdo_odbc_stmt *) 0x8a16794 col = (struct pdo_column_data *) 0x8a12134 dyn = 0 '\0' rc = 0 colnamelen = 7 colsize = 2147483647 [2005-07-18 17:19:36] [EMAIL PROTECTED] Can you do that again, this time type in: bt f 3 info locals thanks! [2005-07-15 00:10:11] scott dot barnett at thuringowa dot qld dot gov dot au Program received signal SIGSEGV, Segmentation fault. 0x0060f7a2 in ?? () from /lib/ld-linux.so.2 (gdb) bt #0 0x0060f7a2 in ?? () from /lib/ld-linux.so.2 #1 0x0064fc76 in kill () from /lib/tls/libc.so.6 #2 0x00ec4f14 in _emalloc (size=2147483648, __zend_filename=0xf5c5b4 "/usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c", __zend_lineno=393, __zend_orig_filename=0x0, __zend_orig_lineno=0) at /usr/src/apache/php5-200507122030/Zend/zend_alloc.c:191 #3 0x00d58c90 in odbc_stmt_describe (stmt=0x9979184, colno=1) at /usr/src/apache/php5-200507122030/ext/pdo_odbc/odbc_stmt.c:393 #4 0x00d5140c in pdo_stmt_describe_columns (stmt=0x9979184) at /usr/src/apache/php5-2005
#33772 [NEW]: __destruct happens befor "hes" time
From: msipria at suomi24 dot fi Operating system: Windows XP PHP version: 5.1.0b3 PHP Bug Type: Class/Object related Bug description: __destruct happens befor "hes" time Description: I have session handling class and i have db class that i pass to the session handling class. As of PHP 5.1.0b1 order of going throu __destructers have been changed, so at end eaven DB class exsist its __destucter has been runned. removing __destruct from DB class will not help, coz mysql link has own __destruct function that it will run. i realy hope this is bug (that can fix) and it will be fixed, other whay i'm stuck with 5.0.x or have to re write lots of source code. Reproduce code: --- http://www.wiofso.com/~msipria/testi.txt Expected result: In PHP 5.0.x (working) __construct = LINK open = LINK read = LINK write = LINK close = LINK __destruct = KILLED LINK Actual result: -- In PHP 5.1.0b3 (tested b1-b3) (not working) __construct = LINK open = LINK read = LINK __destruct = KILLED LINK write = KILLED LINK close = KILLED LINK -- Edit bug report at http://bugs.php.net/?id=33772&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33772&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33772&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33772&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33772&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33772&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33772&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33772&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33772&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33772&r=support Expected behavior: http://bugs.php.net/fix.php?id=33772&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33772&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33772&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33772&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33772&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33772&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33772&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33772&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33772&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33772&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33772&r=mysqlcfg
#33648 [Csd]: Using --with-regex=system causes compile failure
ID: 33648 User updated by: ergin at ergin dot dyndns dot org Reported By: ergin at ergin dot dyndns dot org Status: Closed Bug Type: Compile Failure Operating System: * PHP Version: 5CVS, 4CVS (2005-07-18) Assigned To: andrei New Comment: Conifrming, it works... Previous Comments: [2005-07-19 01:20:56] [EMAIL PROTECTED] It's fixed. [2005-07-18 19:35:03] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2005-07-15 13:03:31] [EMAIL PROTECTED] This is not fixed yet. I added the necessary configure checks and now HAVE_REGEX_T_RE_MAGIC is defined if re_magic exists in regext_t struct. Andrei: Please check it out. [2005-07-14 22:25:38] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2005-07-12 15:41:55] [EMAIL PROTECTED] Assigned to Andrei, he broke it. As to the problem: remove --with-regex=system from your configure line and it will work fine. 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/33648 -- Edit this bug report at http://bugs.php.net/?id=33648&edit=1
#33771 [Opn->Asn]: error_reporting falls to 0 level after some try/catch block
ID: 33771
Updated by: [EMAIL PROTECTED]
Reported By: s6urik at mail dot ee
-Status: Open
+Status: Assigned
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 5.0.4
-Assigned To:
+Assigned To: dmitry
New Comment:
Dmitry, could you check it plz?
Previous Comments:
[2005-07-19 15:42:40] [EMAIL PROTECTED]
I'm not sure if we can qualify this as a bug actually. But atleast I
can offer an explanation. If you use @ the error reporting level will
be set to 0 before an expression (make_exception()) and set's it back
to the original value after it. Because the throwing of the exception
immediately jumps to the catch block, the error reporting level is not
reset back to it's old value. I'm not sure how easy this is to fix.
[2005-07-19 15:33:13] s6urik at mail dot ee
Description:
If exception is throwed with error suppression (@) and catched by
try/catch block error_reporting will fall to 0
Reproduce code:
---
ini_set('display_errors', 1);
error_reporting(E_ALL | E_STRICT);
echo "1. error_reporting = " . error_reporting() . "\n";
function make_exception()
{
throw new Exception();
}
try {
@make_exception();
} catch (Exception $e) {}
echo "2. error_reporting = " . error_reporting() . "\n";
Expected result:
1. error_reporting = 4095
2. error_reporting = 4095
Actual result:
--
1. error_reporting = 4095
2. error_reporting = 0
--
Edit this bug report at http://bugs.php.net/?id=33771&edit=1
#33733 [Opn->Asn]: PHP segfaults when using the pspell extension
ID: 33733 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: CGI related Operating System: linux PHP Version: 5CVS-2005-07-17 (dev) -Assigned To: +Assigned To: helly New Comment: Marcus, you're the author of CLI completion, plz take a look at the patch. Previous Comments: [2005-07-19 15:36:05] [EMAIL PROTECTED] Well, after some debugging I've found the problem. it was much simpler that I though. The problem was that strcpy() was copying 1 more char than the memory allocated, corrupting it. Patch: http://mega.ist.utl.pt/~ncpl/php_cli_interactive.txt [2005-07-19 14:26:17] [EMAIL PROTECTED] Now the program receives a SIGABRT and backtrace shows readline. In fact it seems I cannot reproduce the problem if I execute the script from a file, just when I run PHP in interactive mode (and when I use the auto-completition feature). I'll try to debug this stupid thing. [2005-07-19 13:26:19] [EMAIL PROTECTED] config.nice: './configure' \ '--disable-cgi' \ '--enable-pcntl' \ '--with-ftp' \ '--with-tidy' \ '--with-apxs2=/usr/local/apache2/bin/apxs' \ '--with-readline' \ '--with-bz2' \ '--with-zlib' \ '--with-openssl' \ '--with-pspell' \ '--with-zend-vm=GOTO' [2005-07-18 18:44:52] [EMAIL PROTECTED] If you bothered to read the "how-to-report" page you would know what I want to know. I won't bother explaining this anymore, we've had this same discussion before and if you didn't learn from that -> bogus. [2005-07-18 13:02:30] [EMAIL PROTECTED] I don't know what kind of info you want... Well, here it is the script used (which is above): 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/33733 -- Edit this bug report at http://bugs.php.net/?id=33733&edit=1
#33771 [Opn]: error_reporting falls to 0 level after some try/catch block
ID: 33771
Updated by: [EMAIL PROTECTED]
Reported By: s6urik at mail dot ee
Status: Open
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 5.0.4
New Comment:
I'm not sure if we can qualify this as a bug actually. But atleast I
can offer an explanation. If you use @ the error reporting level will
be set to 0 before an expression (make_exception()) and set's it back
to the original value after it. Because the throwing of the exception
immediately jumps to the catch block, the error reporting level is not
reset back to it's old value. I'm not sure how easy this is to fix.
Previous Comments:
[2005-07-19 15:33:13] s6urik at mail dot ee
Description:
If exception is throwed with error suppression (@) and catched by
try/catch block error_reporting will fall to 0
Reproduce code:
---
ini_set('display_errors', 1);
error_reporting(E_ALL | E_STRICT);
echo "1. error_reporting = " . error_reporting() . "\n";
function make_exception()
{
throw new Exception();
}
try {
@make_exception();
} catch (Exception $e) {}
echo "2. error_reporting = " . error_reporting() . "\n";
Expected result:
1. error_reporting = 4095
2. error_reporting = 4095
Actual result:
--
1. error_reporting = 4095
2. error_reporting = 0
--
Edit this bug report at http://bugs.php.net/?id=33771&edit=1
#33733 [Opn]: PHP segfaults when using the pspell extension
ID: 33733 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Pspell related +Bug Type: CGI related Operating System: linux PHP Version: 5CVS-2005-07-17 (dev) New Comment: Well, after some debugging I've found the problem. it was much simpler that I though. The problem was that strcpy() was copying 1 more char than the memory allocated, corrupting it. Patch: http://mega.ist.utl.pt/~ncpl/php_cli_interactive.txt Previous Comments: [2005-07-19 14:26:17] [EMAIL PROTECTED] Now the program receives a SIGABRT and backtrace shows readline. In fact it seems I cannot reproduce the problem if I execute the script from a file, just when I run PHP in interactive mode (and when I use the auto-completition feature). I'll try to debug this stupid thing. [2005-07-19 13:26:19] [EMAIL PROTECTED] config.nice: './configure' \ '--disable-cgi' \ '--enable-pcntl' \ '--with-ftp' \ '--with-tidy' \ '--with-apxs2=/usr/local/apache2/bin/apxs' \ '--with-readline' \ '--with-bz2' \ '--with-zlib' \ '--with-openssl' \ '--with-pspell' \ '--with-zend-vm=GOTO' [2005-07-18 18:44:52] [EMAIL PROTECTED] If you bothered to read the "how-to-report" page you would know what I want to know. I won't bother explaining this anymore, we've had this same discussion before and if you didn't learn from that -> bogus. [2005-07-18 13:02:30] [EMAIL PROTECTED] I don't know what kind of info you want... Well, here it is the script used (which is above): [2005-07-18 02:30:30] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. 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/33733 -- Edit this bug report at http://bugs.php.net/?id=33733&edit=1
#33771 [NEW]: error_reporting falls to 0 level after some try/catch block
From: s6urik at mail dot ee
Operating system: Linux
PHP version: 5.0.4
PHP Bug Type: Scripting Engine problem
Bug description: error_reporting falls to 0 level after some try/catch block
Description:
If exception is throwed with error suppression (@) and catched by
try/catch block error_reporting will fall to 0
Reproduce code:
---
ini_set('display_errors', 1);
error_reporting(E_ALL | E_STRICT);
echo "1. error_reporting = " . error_reporting() . "\n";
function make_exception()
{
throw new Exception();
}
try {
@make_exception();
} catch (Exception $e) {}
echo "2. error_reporting = " . error_reporting() . "\n";
Expected result:
1. error_reporting = 4095
2. error_reporting = 4095
Actual result:
--
1. error_reporting = 4095
2. error_reporting = 0
--
Edit bug report at http://bugs.php.net/?id=33771&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33771&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33771&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33771&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33771&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33771&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33771&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33771&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33771&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33771&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33771&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33771&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33771&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33771&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33771&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33771&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33771&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33771&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33771&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33771&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33771&r=mysqlcfg
#33770 [Fbk->Opn]: file() does not work with https on 64-bit Linux
ID: 33770 User updated by: subscription at nazarenko dot net Reported By: subscription at nazarenko dot net -Status: Feedback +Status: Open Bug Type: OpenSSL related Operating System: Linux SuSE 9.3 -PHP Version: 5.0.4 +PHP Version: 5.0.4 & 5.1.x-devel New Comment: Tried the latest snapshot as advised. Same effect as before, the problem persists. The configure line was given wrong. The actual is: ./configure \ --with-snmp \ --enable-cli \ --with-curl \ --disable-dom \ --prefix=/usr \ --disable-cgi \ --disable-spl \ --disable-xml \ --without-pear \ --disable-ipv6 \ --enable-shmop \ --enable-pcntl \ --without-iconv \ --disable-ctype \ --disable-libxml \ --enable-sysvsem \ --enable-sysvshm \ --enable-sockets \ --without-sqlite \ --disable-session \ --enable-sigchild \ --with-openssl=/usr \ --disable-simplexml \ --disable-tokenizer \ --with-curlwrappers \ --enable-memory-limit \ --enable-discard-path \ --program-suffix=-net \ --enable-ucd-snmp-hack \ --with-openssl-dir=/usr \ --with-config-file-path=/etc \ --with-mysqli=/usr/bin/mysql_config And here is the tcpdump output for the following script run on the machine "host1": https://host2/";)); ?> Both "host1" and "host2" are on the same subnet. listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes 15:00:48.017717 IP host2.57868 > host.https: S 1342601093:1342601093(0) win 5840 0x: 4500 003c 6968 4000 4006 f142 ac11 43fa E..<[EMAIL PROTECTED]@..B..C. 0x0010: ac11 43f4 e20c 01bb 5006 7785 ..C.P.w. 0x0020: a002 16d0 824c 0204 05b4 0402 080a .L.. 0x0030: 0497 1eed 0103 0302 15:00:48.017867 IP host.https > host2.57868: S 3439729057:3439729057(0) ack 1342601094 win 5792 0x: 4500 003c 12b7 4000 4006 47f4 ac11 43f4 E..<[EMAIL PROTECTED]@.G...C. 0x0010: ac11 43fa 01bb e20c cd06 19a1 5006 7786 ..C.P.w. 0x0020: a012 16a0 1591 0204 05b4 0402 080a 0x0030: 00cd 8567 0497 1eed 0103 0300...g 15:00:48.017888 IP host2.57868 > host.https: . ack 1 win 1460 0x: 4500 0034 696a 4000 4006 f148 ac11 43fa [EMAIL PROTECTED]@..H..C. 0x0010: ac11 43f4 e20c 01bb 5006 7786 cd06 19a2 ..C.P.w. 0x0020: 8010 05b4 5541 0101 080a 0497 1eee UA.. 0x0030: 00cd 8567...g 15:00:48.023936 IP host2.57868 > host.https: F 1:1(0) ack 1 win 1460 0x: 4500 0034 696c 4000 4006 f146 ac11 43fa [EMAIL PROTECTED]@..F..C. 0x0010: ac11 43f4 e20c 01bb 5006 7786 cd06 19a2 ..C.P.w. 0x0020: 8011 05b4 553a 0101 080a 0497 1ef4 U:.. 0x0030: 00cd 8567...g 15:00:48.024125 IP host.https > host2.57868: F 1:1(0) ack 2 win 5792 0x: 4500 0034 12b1 4000 4006 4802 ac11 43f4 [EMAIL PROTECTED]@.H...C. 0x0010: ac11 43fa 01bb e20c cd06 19a2 5006 7787 ..C.P.w. 0x0020: 8011 16a0 444c 0101 080a 00cd 8568 DL.h 0x0030: 0497 1ef4 15:00:48.024141 IP host2.57868 > host.https: . ack 2 win 1460 0x: 4500 0034 696e 4000 4006 f144 ac11 43fa [EMAIL PROTECTED]@..D..C. 0x0010: ac11 43f4 e20c 01bb 5006 7787 cd06 19a3 ..C.P.w. 0x0020: 8010 05b4 5538 0101 080a 0497 1ef4 U8.. 0x0030: 00cd 8568...h Previous Comments: [2005-07-19 14:38:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-07-19 14:35:37] subscription at nazarenko dot net Description: I have 64bit SuSE 9.3 and try to use file() function to read a webpage via http/https. The http protocol is ok, however https returns empty result without any errors/notices (E_ALL is on). I have compiled in OpenSSL support (OpenSSL is v0.9.7e). I have another machine with 32bit Linux on it in the same network, I have compiled PHP with similar settings and https works fine on it. Reproduce code: --- Using the following configure: ./configure --with-snmp --enable-cli --with-curl \ -disable-dom --prefix=/usr --disable-cgi \ --disable-spl --disable-xml --without-pear \ --disable-ipv6 --enable-shmop --enable-pcntl \ --without-iconv --disable-ctype --disable-libxml \ --enable-sysvsem --enable-sysvshm --enable-sockets \ --without-sqlite --disable-session --enable-sigchild \ --disable-simplexml --disable-tokenizer \ --with-curlwrappers --enable-memory-limit \ --enable-discard-path --program-suffix=-net \ --enable-ucd-snmp-hack -
#23877 [Com]: ob_implicit_flush does not work
ID: 23877 Comment by: jeff at tillwicks dot us Reported By: sthomas at townnews dot com Status: Open Bug Type: Feature/Change Request Operating System: Redhat Linux PHP Version: 4.3.2 New Comment: I agree with sthomas totally on this. I have been promised that there is a way to get the output preformance of perl with php using output buffering and flush. I use the cli version and have yet to get it working once. I have followed every example (copy and pasted exact) that is featured in php's own documentation. With every attempt all data is sent after the entire page has finished loading. It is just lack of support on this issue. Previous Comments: [2004-07-22 11:16:48] everyone at example dot com Look dude, you don't have to be so damn obnoxious about it. Be a bit more polite and you will get a more favorable response. [2003-06-30 11:05:43] sthomas at townnews dot com Implicit flush is turned off in the php.ini file, but that's only the default status. Calling ob_implicit_flush should enable autoflushing. The CLI *does* work if I set the output_buffering setting to 0, but here's the screwy part: Set it to any non-zero value, and flushing doesn't occur at all. Setting output_buffering to 1024 would imply that after 1024 characters are sent to the buffer, the buffer is sent to screen/browser. This is not the case. So not only is ob_implict_flush completely ignored when output_buffering is set to a non-zero value, but output_buffering doesn't flush after the designated value either. At least not with the CLI. But don't take my word for it. Set output_buffering to *anything* above 0, then run this script with the CLI: You'll see that no flushing is taking place... at all. Even with an explicit call to flush(), and even though ob_implicit_flush says that output buffering should now be disabled. Yes ob_end_flush() works, however the PHP documentation says ob_implicit_flush does an implied call to ob_end_flush(). So either the documentation is wrong, or PHP is broken. If the documentation is wrong, why have ob_implicit_flush in the first place if it doesn't actually do anything? Because so far with recent versions of PHP, I haven't been able to create a single test case where ob_implicit_flush actually did anything. [2003-06-30 09:33:08] [EMAIL PROTECTED] There's a second level of buffering after the ob_ buffering. What is your implicit_flush setting? Please also refer to http://www.php.net/flush [2003-06-30 08:02:09] sthomas at townnews dot com So... did you read the report at all? Did you see the part where I quoted the PHP documentation? Let me do it again: "Turning implicit flushing on will disable output buffering, the output buffers current output will be sent as if ob_end_flush() had been called." Therefore, according to this, calling ob_implicit_flush *IMPLIES A CALL TO OB_END_FLUSH*! What part of YOUR OWN DOCUMENTATION do you not understand? Either the documentation is wrong, or PHP is wrong. Whichever it is, fix it so there's at least some consistancy. [2003-06-29 21:07:05] [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 You should've used ob_end_flush(); instead of ob_implicit_flush();. 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/23877 -- Edit this bug report at http://bugs.php.net/?id=23877&edit=1
#33762 [Bgs->Opn]: Setting error_reporting doesn't turn off strict warning messages
ID: 33762 User updated by: russell at flora dot ca Reported By: russell at flora dot ca -Status: Bogus +Status: Open Bug Type: *Configuration Issues Operating System: 2.6.12-1.1398_FC4 Linux -PHP Version: 5.0.3 +PHP Version: 5.0.4 New Comment: I am running the RPM that comes with Fedora Core 4 updates, which is the latest you list. (Their version information is php-5.0.4-10.3). From: http://www.forumonpublicdomain.ca/info.php PHP Version 5.0.4 Previous Comments: [2005-07-19 10:06:50] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. [2005-07-19 05:38:35] russell at flora dot ca Description: I know this has been said to not be a bug, and many bug reports have been ignored, but I have tried everything suggested. This is the right php.ini file, and I am modifying the ini file and not some other way to set variables that might happen at run-time. I have gone so far as to set: error_reporting = 0 in my php.ini. I can then go to phpinfo() and it displays as I would expect: Directive Local Value Master Value error_reporting 0 0 Error warnings are still coming out on the output of the pages, even though display_errors Off Off Example errors from: http://forumonpublicdomain.ca/ (I may be forced to downgrade PHP to fix this problem. PHP5 isn't useable for me until this problem is fixed. phpinfo() is at http://www.forumonpublicdomain.ca/info.php ) strict warning: Assigning the return value of new by reference is deprecated in /home/forumonpublicdomain.ca/www.forumonpublicdomain.ca/themes/engines/phptemplate/phptemplate.engine on line 335. strict warning: var: Deprecated. Please use the public/private/protected modifiers in /home/forumonpublicdomain.ca/www.forumonpublicdomain.ca/themes/engines/phptemplate/template.php on line 27. strict warning: var: Deprecated. Please use the public/private/protected modifiers in /home/forumonpublicdomain.ca/www.forumonpublicdomain.ca/themes/engines/phptemplate/template.php on line 28. -- Edit this bug report at http://bugs.php.net/?id=33762&edit=1
#33770 [Opn->Fbk]: file() does not work with https on 64-bit Linux
ID: 33770 Updated by: [EMAIL PROTECTED] Reported By: subscription at nazarenko dot net -Status: Open +Status: Feedback Bug Type: OpenSSL related Operating System: Linux SuSE 9.3 PHP Version: 5.0.4 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Previous Comments: [2005-07-19 14:35:37] subscription at nazarenko dot net Description: I have 64bit SuSE 9.3 and try to use file() function to read a webpage via http/https. The http protocol is ok, however https returns empty result without any errors/notices (E_ALL is on). I have compiled in OpenSSL support (OpenSSL is v0.9.7e). I have another machine with 32bit Linux on it in the same network, I have compiled PHP with similar settings and https works fine on it. Reproduce code: --- Using the following configure: ./configure --with-snmp --enable-cli --with-curl \ -disable-dom --prefix=/usr --disable-cgi \ --disable-spl --disable-xml --without-pear \ --disable-ipv6 --enable-shmop --enable-pcntl \ --without-iconv --disable-ctype --disable-libxml \ --enable-sysvsem --enable-sysvshm --enable-sockets \ --without-sqlite --disable-session --enable-sigchild \ --disable-simplexml --disable-tokenizer \ --with-curlwrappers --enable-memory-limit \ --enable-discard-path --program-suffix=-net \ --enable-ucd-snmp-hack --with-config-file-path=/etc \ --with-mysqli=/usr/bin/mysql_config -- Edit this bug report at http://bugs.php.net/?id=33770&edit=1
#33770 [NEW]: file() does not work with https on 64-bit Linux
From: subscription at nazarenko dot net Operating system: Linux SuSE 9.3 PHP version: 5.0.4 PHP Bug Type: OpenSSL related Bug description: file() does not work with https on 64-bit Linux Description: I have 64bit SuSE 9.3 and try to use file() function to read a webpage via http/https. The http protocol is ok, however https returns empty result without any errors/notices (E_ALL is on). I have compiled in OpenSSL support (OpenSSL is v0.9.7e). I have another machine with 32bit Linux on it in the same network, I have compiled PHP with similar settings and https works fine on it. Reproduce code: --- Using the following configure: ./configure --with-snmp --enable-cli --with-curl \ -disable-dom --prefix=/usr --disable-cgi \ --disable-spl --disable-xml --without-pear \ --disable-ipv6 --enable-shmop --enable-pcntl \ --without-iconv --disable-ctype --disable-libxml \ --enable-sysvsem --enable-sysvshm --enable-sockets \ --without-sqlite --disable-session --enable-sigchild \ --disable-simplexml --disable-tokenizer \ --with-curlwrappers --enable-memory-limit \ --enable-discard-path --program-suffix=-net \ --enable-ucd-snmp-hack --with-config-file-path=/etc \ --with-mysqli=/usr/bin/mysql_config -- Edit bug report at http://bugs.php.net/?id=33770&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33770&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33770&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33770&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33770&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33770&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33770&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33770&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33770&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33770&r=support Expected behavior: http://bugs.php.net/fix.php?id=33770&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33770&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33770&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33770&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33770&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33770&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33770&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33770&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33770&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33770&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33770&r=mysqlcfg
#33733 [Opn]: PHP segfaults when using the pspell extension
ID: 33733
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Pspell related
Operating System: linux
PHP Version: 5CVS-2005-07-17 (dev)
New Comment:
Now the program receives a SIGABRT and backtrace shows readline.
In fact it seems I cannot reproduce the problem if I execute the script
from a file, just when I run PHP in interactive mode (and when I use the
auto-completition feature).
I'll try to debug this stupid thing.
Previous Comments:
[2005-07-19 13:26:19] [EMAIL PROTECTED]
config.nice:
'./configure' \
'--disable-cgi' \
'--enable-pcntl' \
'--with-ftp' \
'--with-tidy' \
'--with-apxs2=/usr/local/apache2/bin/apxs' \
'--with-readline' \
'--with-bz2' \
'--with-zlib' \
'--with-openssl' \
'--with-pspell' \
'--with-zend-vm=GOTO'
[2005-07-18 18:44:52] [EMAIL PROTECTED]
If you bothered to read the "how-to-report" page you would know what I
want to know. I won't bother explaining this anymore, we've had this
same discussion before and if you didn't learn from that -> bogus.
[2005-07-18 13:02:30] [EMAIL PROTECTED]
I don't know what kind of info you want...
Well, here it is the script used (which is above):
[2005-07-18 02:30:30] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2005-07-17 13:21:54] [EMAIL PROTECTED]
Description:
I'm not sure if this is a PHP bug, but here it is:
(gdb) run -a
Starting program: /usr/local/bin/php -a
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 18864)]
Interactive mode enabled
php > $pspell_link = pspell_new('en');
php > pspell_config_mode($pspell_link, PSPELL_FAST);
*** glibc detected *** corrupted double-linked list: 0x0844e7f0 ***
Program received signal SIGABRT, Aborted.
[Switching to Thread 16384 (LWP 18864)]
0xb79b43e1 in kill () from /lib/libc.so.6
(gdb) bt
#0 0xb79b43e1 in kill () from /lib/libc.so.6
#1 0xb7aac131 in pthread_kill () from /lib/libpthread.so.0
#2 0xb7aac4ab in raise () from /lib/libpthread.so.0
#3 0xb79b4174 in raise () from /lib/libc.so.6
#4 0xb79b564d in abort () from /lib/libc.so.6
#5 0xb79f0030 in mallopt () from /lib/libc.so.6
#6 0xb79ef03c in mallopt () from /lib/libc.so.6
#7 0xb79ee6ea in mallopt () from /lib/libc.so.6
#8 0xb79ed803 in malloc () from /lib/libc.so.6
#9 0x081fbd51 in _emalloc (size=18864) at
/cvs/php-src/Zend/zend_alloc.c:181
#10 0x0820909d in op_array_alloc_ops (op_array=0x84a0b54)
at /cvs/php-src/Zend/zend_opcode.c:48
#11 0x08209107 in init_op_array (op_array=0x84a0b54, type=4 '\004',
initial_ops_size=8192) at /cvs/php-src/Zend/zend_opcode.c:68
#12 0x081f64c5 in compile_string (source_string=0xb410,
filename=0x0)
at zend_language_scanner.l:541
#13 0x08207934 in zend_eval_string (str=0x1 ,
retval_ptr=0x0, string_name=0x0)
at /cvs/php-src/Zend/zend_execute_API.c:1030
#14 0x0827fadc in main (argc=2, argv=0xb644)
at /cvs/php-src/sapi/cli/php_cli.c:1024
I have glib 2.3.4 and aspell 0.60.3.
BTW, PHP segfaults when using aspell 0.50.5, so we should probably bump
the version requirements (reference:
http://sf.net/tracker/?func=detail&atid=100245&aid=1238839&group_id=245
--
Edit this bug report at http://bugs.php.net/?id=33733&edit=1
#33750 [Fbk->Opn]: Solution to ID's 8527 & 8588 not working for me
ID: 33750 User updated by: checkforabcd at yahoo dot com Reported By: checkforabcd at yahoo dot com -Status: Feedback +Status: Open Bug Type: Session related Operating System: WinXP PHP Version: 4.3.11 New Comment: ok.. My windows internet settings were perfectly fine. The sessions cookies were supported by default. As for the mozilla stuff, it didn't work either & no errors or headers were shown. Now what should I do to solve the problem Previous Comments: [2005-07-18 19:34:51] [EMAIL PROTECTED] 1) Don't touch session.cookie.path 2) Fix your browser and make it to support session cookies (it's known winblows "security improvement"). 3) Check what headers you get with some sniffer (or just use Mozilla). [2005-07-18 17:21:01] checkforabcd at yahoo dot com Description: I have checked the bug reports with ID 8527 & 8588 which were having exactly the same problem as mine with the only difference that the solution given for them isn't working in my case, ie, I set the "session.cookie_path" to "/" & still the problem just won't go away. Please help... Reproduce code: --- checkuser.php //location :surevin.com/tender/checkuser.php http://www.surevin.com/tender/radmin/secondpage.php'); exit(); ?> secondpage.php Expected result: The value of madmin is : abcd Actual result: -- The value of madmin is : -- Edit this bug report at http://bugs.php.net/?id=33750&edit=1
#33768 [Opn->Fbk]: PHP test script - run-tests.php crashes with Access Voilation Error.
ID: 33768 Updated by: [EMAIL PROTECTED] Reported By: mjoy_2003 at yahoo dot co dot in -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Windows Server 2003 PHP Version: 4.3.11 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2005-07-19 12:48:48] mjoy_2003 at yahoo dot co dot in Description: Script: run-tests.php from the PHP distribution is used to test the installation. Execute this on a Windows Server 2003 and the crash is reproducible. Installation: 1. Install with the following options: --with-apxs --with-oci8 --enable-sigchild --disable-rpath Webserver : Apache 1.3.33 Reproduce code: --- 1. PHP test script - run-tests.php This file is a part of the PHP distribution in the tests/ fodler. This test has produced the same result (Access voilation error) on Windows Server 2003 and suceeds on NT and 2000. Expected result: All the tests should suceed! Actual result: -- After the first script - 001.phpt is executed and Access voilation error occurs. The trace is as follows: 'php.exe': Loaded 'C:\test\Apache\htdocs\php_tests_srg\php.exe', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', No symbols loaded. 'php.exe': Loaded 'C:\test\Apache\htdocs\php_tests_srg\php4ts.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\user32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\gdi32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\advapi32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\wsock32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\ws2_32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\msvcrt.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\ws2help.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\ole32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\oleaut32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\odbc32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.1830_x-ww_1B6F474A\comctl32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\comdlg32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\shell32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\shlwapi.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.1830_x-ww_7AE38CCF\comctl32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\odbcint.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\mswsock.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\dnsapi.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\winrnr.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\wldap32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\rasadhlp.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\hnetcfg.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\wshtcpip.dll', No symbols loaded. Unhandled exception at 0x7c83247a in php.exe: 0xC005: Access violation reading location 0x54434552. -- Edit this bug report at http://bugs.php.net/?id=33768&edit=1
#33757 [Fbk->Bgs]: Duplicidade de registros - insert
ID: 33757
Updated by: [EMAIL PROTECTED]
Reported By: manzoli at cisi dot coppe dot ufrj dot br
-Status: Feedback
+Status: Bogus
Bug Type: Sybase-ct (ctlib) related
Operating System: PHP
PHP Version: 4.4.0
New Comment:
it's not a bug report, just a couple of questions.
Previous Comments:
[2005-07-18 20:40:01] [EMAIL PROTECTED]
Speak english here.
[2005-07-18 20:39:51] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
[2005-07-18 20:36:30] manzoli at cisi dot coppe dot ufrj dot br
Description:
Estou realizando um insert.
Consigo gravar no banco, porém está me ocasionando erro de
duplicidade.
É como se o IIS guardasse o comando e o enviasse novamente.
Reproduce code:
---
Trabalho com php e estou fazendo uma conexão sybase.
Primeiro - como sei no php se estou usando sybase-ct ou sybase-db?
Segundo - o que e melhor para se trabalhar sybase_pconnect ou
sybase_connect?
Olha só estou fazendo o seguinte insert:
for ($i = 0; $i <= $total_itens; $i++) {
include "inc_busca_conexao_syb.php";
// Grava dados do formulário.
$item = $_POST["item_$i"];
$descricao = $_POST["descricao_$i"];
if ($item)
{
$sql = "INSERT INTO tabela ";
$sql .= "(coi_item, cos_prot_destino, dat_solicitacao, stv_descricao,
";
$sql .= "cos_prot_origem, stc_status) ";
$sql .= "values (";
$sql .= "$item, '$prot_destino', convert(datetime,'$data_solicitacao',
103), ";
$sql .= "'$descricao','$prot_origem', 'N' ";
$sql .= ")";
$resultado = sybase_query(trim($sql),$db_conexao->db_connect_id);
sybase_free_result($resultado);
sybase_close($db_conexao->db_connect_id);
}
precisei abrir e fechar a conexão dentro do for, pois estava dando erro
de
duplicidade o tempo todo. Não consegui descobrir o porque.
Minha conexão está da seguinte forma:
$db_user = "x"; //usuario do banco
$db_passwd = "y"; //senha do usuario
$db_database = "B"; //nome da base de dados
$db_server = "CCC"; //nome da base de dados
require("inc_conectardb_syb.php");
$db_conexao = new sql_db;
$db_conexao->sql_db($db_server,$db_user,$db_passwd,$db_database) or die
("Falha na chamada de conexão");
sybase_select_db($db_database, $db_conexao->db_connect_id) or die
("Falha na
seleção do database");
define("SQL_LAYER","sql-sybase");
class sql_db
{
var $db_connect_id;
var $result;
var $next_id;
var $num_rows = array();
var $current_row = array();
var $field_names = array();
var $field_types = array();
var $result_rowset = array();
var $num_queries = 0;
//
// Constructor
//
function sql_db($sqlserver, $sqluser, $sqlpassword, $database,
$persistency = false)
{
$this->persistency = $persistency;
$this->server = $sqlserver;
$this->user = $sqluser;
$this->password = $sqlpassword;
$this->dbname = $database;
($this->db_connect_id = ($this->persistency) ? sybase_pconnect
($this->server, $this->user, $this->password) :
sybase_connect($this->server,
$this->user, $this->password));
return ( $this->db_connect_id ) ? $this->db_connect_id :
false;
}
}
TEM COMO ME AJUDAR. NÃO QUERIA ABRIR E FECHAR CONEXÃO A CADA PASSADA NO
FOR.
1 usuário(s) lendo este tópico (0 visitantes e 0 usuários anônimos)
--
Edit this bug report at http://bugs.php.net/?id=33757&edit=1
#33755 [Opn->Bgs]: Segmentation fault when compiled
ID: 33755 Updated by: [EMAIL PROTECTED] Reported By: arnie at imagestate dot co dot uk -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: LINUX PHP Version: 5.1.0b3 New Comment: Do not file bugs when you have Zend extensions (zend_extension=) loaded. Examples are Zend Optimizer, Zend Debugger, Turck MM Cache, APC, Xdebug and ionCube loader. These extensions often modify engine behavior which is not related to PHP itself. Previous Comments: [2005-07-19 13:26:12] arnie at imagestate dot co dot uk gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) gdm bt below [EMAIL PROTECTED] bin]# gdb ./php ./core.520 GNU gdb Red Hat Linux (5.2.1-4) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `./php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /usr/local/pgsql/lib/libpq.so.3...done. Loaded symbols for /usr/local/pgsql/lib/libpq.so.3 Reading symbols from /usr/local/mysql/lib/mysql/libmysqlclient.so.12...done. Loaded symbols for /usr/local/mysql/lib/mysql/libmysqlclient.so.12 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/i686/libm.so.6...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /usr/lib/libxml2.so.2...done. Loaded symbols for /usr/lib/libxml2.so.2 Reading symbols from /lib/i686/libpthread.so.0...done. Loaded symbols for /lib/i686/libpthread.so.0 Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/local/Zend/lib/ZendExtensionManager.so...done. Loaded symbols for /usr/local/Zend/lib/ZendExtensionManager.so #0 0xeddce853 in ?? () (gdb) bt #0 0xeddce853 in ?? () Cannot access memory at address 0x85d8b10 [2005-07-18 19:29:11] [EMAIL PROTECTED] Thank you for not reading the 'how-to-report' and wasting my time. Remove the non-PHP extensions first. There is no such thing as '--with-odbtp' in PHP. If the segfault still occurs, provide a gdb backtrace of it. Also provide the versions of the related build tools, such as GCC. [2005-07-18 19:27:08] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2005-07-18 19:22:52] arnie at imagestate dot co dot uk I configured php as described here. After make installing, I tried to run the cli, having previously failed to get apache to start. The details are below. Apache version 1.3.28 PHP 5.1.0b3 Postgresql 7.4.1 Mysql 4.0.21 ODBTP v 1.1.3 make install Installing PHP SAPI module: apache [activating module `php5' in /usr/local/apache/conf/httpd.conf] cp libs/libphp5.so /usr/local/apache/libexec/libphp5.so chmod 755 /usr/local/apache/libexec/libphp5.so cp /usr/local/apache/conf/httpd.conf /usr/local/apache/conf/httpd.conf.bak cp /usr/local/apache/conf/httpd.conf.new /usr/local/apache/conf/httpd.conf rm /usr/local/apache/conf/httpd.conf.new Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PEAR environment: /usr/local/lib/php/ [PEAR] Archive_Tar- already installed: 1.1 [PEAR] Console_Getopt - already installed: 1.2 [PEAR] PEAR - already installed: 1.3.5 Wrote PEAR system config file at: /usr/local/etc/pear.conf You may want to add: /usr/local/lib/php to your php.ini include_path [PEAR] HTML_Template_IT- already installed: 1.1 [PEAR] Net_UserAgent_Detect- already installed: 2.0.1 [PEAR] XML_RPC- already installed: 1.3.1 Installing build environment: /usr/local/lib/php/build/ Installing header files: /usr
#33733 [Bgs->Opn]: PHP segfaults when using the pspell extension
ID: 33733
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: Pspell related
Operating System: linux
PHP Version: 5CVS-2005-07-17 (dev)
New Comment:
config.nice:
'./configure' \
'--disable-cgi' \
'--enable-pcntl' \
'--with-ftp' \
'--with-tidy' \
'--with-apxs2=/usr/local/apache2/bin/apxs' \
'--with-readline' \
'--with-bz2' \
'--with-zlib' \
'--with-openssl' \
'--with-pspell' \
'--with-zend-vm=GOTO'
Previous Comments:
[2005-07-18 18:44:52] [EMAIL PROTECTED]
If you bothered to read the "how-to-report" page you would know what I
want to know. I won't bother explaining this anymore, we've had this
same discussion before and if you didn't learn from that -> bogus.
[2005-07-18 13:02:30] [EMAIL PROTECTED]
I don't know what kind of info you want...
Well, here it is the script used (which is above):
[2005-07-18 02:30:30] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2005-07-17 13:21:54] [EMAIL PROTECTED]
Description:
I'm not sure if this is a PHP bug, but here it is:
(gdb) run -a
Starting program: /usr/local/bin/php -a
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 18864)]
Interactive mode enabled
php > $pspell_link = pspell_new('en');
php > pspell_config_mode($pspell_link, PSPELL_FAST);
*** glibc detected *** corrupted double-linked list: 0x0844e7f0 ***
Program received signal SIGABRT, Aborted.
[Switching to Thread 16384 (LWP 18864)]
0xb79b43e1 in kill () from /lib/libc.so.6
(gdb) bt
#0 0xb79b43e1 in kill () from /lib/libc.so.6
#1 0xb7aac131 in pthread_kill () from /lib/libpthread.so.0
#2 0xb7aac4ab in raise () from /lib/libpthread.so.0
#3 0xb79b4174 in raise () from /lib/libc.so.6
#4 0xb79b564d in abort () from /lib/libc.so.6
#5 0xb79f0030 in mallopt () from /lib/libc.so.6
#6 0xb79ef03c in mallopt () from /lib/libc.so.6
#7 0xb79ee6ea in mallopt () from /lib/libc.so.6
#8 0xb79ed803 in malloc () from /lib/libc.so.6
#9 0x081fbd51 in _emalloc (size=18864) at
/cvs/php-src/Zend/zend_alloc.c:181
#10 0x0820909d in op_array_alloc_ops (op_array=0x84a0b54)
at /cvs/php-src/Zend/zend_opcode.c:48
#11 0x08209107 in init_op_array (op_array=0x84a0b54, type=4 '\004',
initial_ops_size=8192) at /cvs/php-src/Zend/zend_opcode.c:68
#12 0x081f64c5 in compile_string (source_string=0xb410,
filename=0x0)
at zend_language_scanner.l:541
#13 0x08207934 in zend_eval_string (str=0x1 ,
retval_ptr=0x0, string_name=0x0)
at /cvs/php-src/Zend/zend_execute_API.c:1030
#14 0x0827fadc in main (argc=2, argv=0xb644)
at /cvs/php-src/sapi/cli/php_cli.c:1024
I have glib 2.3.4 and aspell 0.60.3.
BTW, PHP segfaults when using aspell 0.50.5, so we should probably bump
the version requirements (reference:
http://sf.net/tracker/?func=detail&atid=100245&aid=1238839&group_id=245
--
Edit this bug report at http://bugs.php.net/?id=33733&edit=1
#33755 [Fbk->Opn]: Segmentation fault when compiled
ID: 33755 User updated by: arnie at imagestate dot co dot uk Reported By: arnie at imagestate dot co dot uk -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: LINUX PHP Version: 5.1.0b3 New Comment: gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) gdm bt below [EMAIL PROTECTED] bin]# gdb ./php ./core.520 GNU gdb Red Hat Linux (5.2.1-4) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... Core was generated by `./php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /usr/local/pgsql/lib/libpq.so.3...done. Loaded symbols for /usr/local/pgsql/lib/libpq.so.3 Reading symbols from /usr/local/mysql/lib/mysql/libmysqlclient.so.12...done. Loaded symbols for /usr/local/mysql/lib/mysql/libmysqlclient.so.12 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/i686/libm.so.6...done. Loaded symbols for /lib/i686/libm.so.6 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /usr/lib/libxml2.so.2...done. Loaded symbols for /usr/lib/libxml2.so.2 Reading symbols from /lib/i686/libpthread.so.0...done. Loaded symbols for /lib/i686/libpthread.so.0 Reading symbols from /lib/i686/libc.so.6...done. Loaded symbols for /lib/i686/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/local/Zend/lib/ZendExtensionManager.so...done. Loaded symbols for /usr/local/Zend/lib/ZendExtensionManager.so #0 0xeddce853 in ?? () (gdb) bt #0 0xeddce853 in ?? () Cannot access memory at address 0x85d8b10 Previous Comments: [2005-07-18 19:29:11] [EMAIL PROTECTED] Thank you for not reading the 'how-to-report' and wasting my time. Remove the non-PHP extensions first. There is no such thing as '--with-odbtp' in PHP. If the segfault still occurs, provide a gdb backtrace of it. Also provide the versions of the related build tools, such as GCC. [2005-07-18 19:27:08] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. [2005-07-18 19:22:52] arnie at imagestate dot co dot uk I configured php as described here. After make installing, I tried to run the cli, having previously failed to get apache to start. The details are below. Apache version 1.3.28 PHP 5.1.0b3 Postgresql 7.4.1 Mysql 4.0.21 ODBTP v 1.1.3 make install Installing PHP SAPI module: apache [activating module `php5' in /usr/local/apache/conf/httpd.conf] cp libs/libphp5.so /usr/local/apache/libexec/libphp5.so chmod 755 /usr/local/apache/libexec/libphp5.so cp /usr/local/apache/conf/httpd.conf /usr/local/apache/conf/httpd.conf.bak cp /usr/local/apache/conf/httpd.conf.new /usr/local/apache/conf/httpd.conf rm /usr/local/apache/conf/httpd.conf.new Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PEAR environment: /usr/local/lib/php/ [PEAR] Archive_Tar- already installed: 1.1 [PEAR] Console_Getopt - already installed: 1.2 [PEAR] PEAR - already installed: 1.3.5 Wrote PEAR system config file at: /usr/local/etc/pear.conf You may want to add: /usr/local/lib/php to your php.ini include_path [PEAR] HTML_Template_IT- already installed: 1.1 [PEAR] Net_UserAgent_Detect- already installed: 2.0.1 [PEAR] XML_RPC- already installed: 1.3.1 Installing build environment: /usr/local/lib/php/build/ Installing header files: /usr/local/include/php/ Installing helper programs: /usr/local/bin/ program: phpize program: php-config Installing man pages: /usr/local/man/man1/ page: phpize.1 page: php-config.1 [EMAIL PROTECTED] php-5.1.0b3]# /usr/local/bin/php Segmentation fault [2005-07-18 19:
#33768 [NEW]: PHP test script - run-tests.php crashes with Access Voilation Error.
From: mjoy_2003 at yahoo dot co dot in Operating system: Windows Server 2003 PHP version: 4.3.11 PHP Bug Type: Reproducible crash Bug description: PHP test script - run-tests.php crashes with Access Voilation Error. Description: Script: run-tests.php from the PHP distribution is used to test the installation. Execute this on a Windows Server 2003 and the crash is reproducible. Installation: 1. Install with the following options: --with-apxs --with-oci8 --enable-sigchild --disable-rpath Webserver : Apache 1.3.33 Reproduce code: --- 1. PHP test script - run-tests.php This file is a part of the PHP distribution in the tests/ fodler. This test has produced the same result (Access voilation error) on Windows Server 2003 and suceeds on NT and 2000. Expected result: All the tests should suceed! Actual result: -- After the first script - 001.phpt is executed and Access voilation error occurs. The trace is as follows: 'php.exe': Loaded 'C:\test\Apache\htdocs\php_tests_srg\php.exe', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', No symbols loaded. 'php.exe': Loaded 'C:\test\Apache\htdocs\php_tests_srg\php4ts.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\user32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\gdi32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\advapi32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\wsock32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\ws2_32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\msvcrt.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\ws2help.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\ole32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\oleaut32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\odbc32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.1830_x-ww_1B6F474A\comctl32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\comdlg32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\shell32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\shlwapi.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.1830_x-ww_7AE38CCF\comctl32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\odbcint.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\mswsock.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\dnsapi.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\winrnr.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\wldap32.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\rasadhlp.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\hnetcfg.dll', No symbols loaded. 'php.exe': Loaded 'C:\WINDOWS\system32\wshtcpip.dll', No symbols loaded. Unhandled exception at 0x7c83247a in php.exe: 0xC005: Access violation reading location 0x54434552. -- Edit bug report at http://bugs.php.net/?id=33768&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33768&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33768&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33768&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33768&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33768&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33768&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33768&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33768&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33768&r=support Expected behavior: http://bugs.php.net/fix.php?id=33768&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33768&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33768&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33768&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33768&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33768&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33768&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33768&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33768&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33768&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33768&r=mysqlcfg
#32589 [Csd->Opn]: imap_mail_compose doesn´t work properly
ID: 32589 User updated by: svoboda at svoon dot net Reported By: svoboda at svoon dot net -Status: Closed +Status: Open Bug Type: IMAP related Operating System: debian -PHP Version: 4.3.11 +PHP Version: 4.4.0 New Comment: hello, in new version php 4.4.0 the bug remains. Script outputs no data, error log is empty too, only processing exit. If I compile version php4-STABLE-200412272330 with the same configure command, it works well. I have c-client with kerberos from debian packages libc-client-dev libc-client-ssl2001 libc-client2002edebian If you need some more info, pleas let me know. thank you a lot Previous Comments: [2005-04-09 09:46:25] [EMAIL PROTECTED] I can not reproduce this either with latest CVS (any branch). (and snapshots are fine too) Get the latest here: http://snaps.php.net/php4-STABLE-latest.tar.gz [2005-04-09 04:55:09] svoboda at svoon dot net I have tryied php4-STABLE-200504090239, but the problem still remains. [2005-04-08 17:05:14] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Another part of the patch was missing, should be fine now. [2005-04-05 16:49:22] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2005-04-05 14:59:05] svoboda at svoon dot net Description: when use charset field in part array, fction exit with segmentation fault. Reproduce code: --- $m_envelope["To"] = "[EMAIL PROTECTED]"; $m_part1["type"] = TYPEMULTIPART; $m_part1["subtype"] = "mixed"; $m_part2["type"] = TYPETEXT; $m_part2["subtype"] = "plain"; $m_part2["description"] = "text_message"; $m_part2["charset"] = "ISO-8859-2"; $m_part2["contents.data"] = "hello"; $m_body[1] = $m_part1; $m_body[2] = $m_part2; echo nl2br(imap_mail_compose($m_envelope, $m_body)); -- Edit this bug report at http://bugs.php.net/?id=32589&edit=1
#33751 [Bgs->Csd]: jpeg support
ID: 33751 User updated by: rob at tdd dot org dot uk Reported By: rob at tdd dot org dot uk -Status: Bogus +Status: Closed Bug Type: GD related Operating System: Debian GNU/Linux 3.0 PHP Version: 5.0.4 New Comment: I downloaded the source again and did a difference check # diff -Naur php-5.0.4old php-5.0.4new > php.diff There were differences (apart from generated files by configure, make etc) so I compiled again with the newly downloaded source and everything has worked fine. Obviously not a problem with my system then! Previous Comments: [2005-07-18 19:55:41] rob at tdd dot org dot uk Okay I have compiled php-5.0.3 and php-5.0.4 with the configure options. ./configure --with-gd --with-mysql=/usr/local/mysql --with-apxs2=/usr/local/apache2/bin/apxs --enable-track-vars --with-pspell --with-memcache --enable-soap --enable-exif --with-tidy --with-curl --with-png-dir=/usr/local --with-zlib-dir=/usr --enable-force-cgi-redirect --with-gettext --with-freetype-dir=/usr/local --with-jpeg-dir=/usr/local I have tested the script below on the command line. # cat ../imagecheck.php With php-5.0.3 # ./sapi/cli/php ../imagecheck.php Function imagecreatefromjpeg exists With php-5.0.4 # ./sapi/cli/php ../imagecheck.php Function imagecreatefromjpeg does not exist If there was a problem with the system and nothing had changed between the versions then the same problem would occur in php-5.0.3 [2005-07-18 18:23:51] [EMAIL PROTECTED] Works fine for me (and there weren't any changes between 5.0.3 and 5.0.4 which could have broken it). There's just something wrong with your system. (check config.log, there you most likely will find the reason the check failed) Also: paths like /usr/lib do NOT WORK! (they never did and they never will, drop the /lib part from those!) [2005-07-18 17:30:03] rob at tdd dot org dot uk Description: I upgraded from php-5.0.3 to php-5.0.4. I used EXACTLY the same configuration options as php-5.0.3 and jpeg support was removed from gd in php-5.0.4. Both versions of php build and install successfully. ./configure --with-gd --with-mysql=/usr/local/mysql --with-apxs2=/usr/local/apache2/bin/apxs --enable-track-vars --with-pspell --with-memcache --enable-soap --enable-exif --with-tidy --with-curl --with-png-dir=/usr/local --with-zlib-dir=/usr/lib --enable-force-cgi-redirect --with-gettext --with-freetype-dir=/usr/local --with-jpeg-dir=/usr/local -- Edit this bug report at http://bugs.php.net/?id=33751&edit=1
#33723 [Fbk->Opn]: php_value overrides php_admin_value
ID: 33723 User updated by: ezmlm at mail dot ru Reported By: ezmlm at mail dot ru -Status: Feedback +Status: Open Bug Type: Apache related Operating System: Linux PHP Version: 5CVS-2005-07-18 New Comment: It doesn't make any difference. php_admin_value may be in VirtualHost block or in global scope. It is reset by php_value in .htaccess in both cases. That was just a simple example to reproduce the bug. safe_mode is also only example. You can reset any options marked as PHP_INI_SYSTEM (which shouldn't be settable with php_value at all) like safe_mode or open_basedir or any other, disabling any security limitations defined in VirtualHost Previous Comments: [2005-07-19 10:46:39] [EMAIL PROTECTED] Isn't the php_admin_value inside any block?? [2005-07-19 08:41:21] ezmlm at mail dot ru This problem does not exist in php5 module for Apache2. It only exists in php5 module for Apache1 cause those are completly different modules. Using php_admin_value safe_mode 1 didn't change anything. again the steps to reproduce the problem. Apache 1.3.33 is configured with ./configure --enable-module=so and installed with make && make install php is configured with ./configure --with-apxs=/usr/local/apache/bin/apxs then installed with make && make install In httpd.conf added: AddType application/x-httpd-php .php .phtml php_admin_value safe_mode on In section set AllowOverride Options to allow php_flag and php_value in .htaccess In /usr/local/apache/htdocs created info.phtml: The result is that safe_mode is ON and content of /etc/passwd IS NOT displayed. Now create .htaccess in /usr/local/apache/htdocs: php_flag safe_mode off The result is that phpinfo() shows safe_mode is OFF and content of /etc/passwd IS displayed. [2005-07-19 00:45:21] [EMAIL PROTECTED] Try change that php_admin_value line in httpd.conf to this: php_admin_value safe_mode 1 [2005-07-19 00:43:19] [EMAIL PROTECTED] I can't reproduce this override problem when using Apache2. [2005-07-19 00:37:23] [EMAIL PROTECTED] Solved. I had wrong permissions and owners set on the path and script I used. safe-mode works as expected. 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/33723 -- Edit this bug report at http://bugs.php.net/?id=33723&edit=1
#33767 [NEW]: array_filter: support for additional callback arguments
From: tjerk dot meesters at gmail dot com Operating system: PHP version: 5.1.0b3 PHP Bug Type: Arrays related Bug description: array_filter: support for additional callback arguments Description: It would be desirable to add arguments to the callback function during the execution of array_filter(), like so: -- Edit bug report at http://bugs.php.net/?id=33767&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33767&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=33767&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=33767&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=33767&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=33767&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=33767&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=33767&r=needscript Try newer version: http://bugs.php.net/fix.php?id=33767&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=33767&r=support Expected behavior: http://bugs.php.net/fix.php?id=33767&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=33767&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=33767&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=33767&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33767&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=33767&r=dst IIS Stability: http://bugs.php.net/fix.php?id=33767&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=33767&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=33767&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=33767&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=33767&r=mysqlcfg
#33723 [Opn->Fbk]: php_value overrides php_admin_value
ID: 33723 Updated by: [EMAIL PROTECTED] Reported By: ezmlm at mail dot ru -Status: Open +Status: Feedback Bug Type: Apache related Operating System: Linux PHP Version: 5CVS-2005-07-18 New Comment: Isn't the php_admin_value inside any block?? Previous Comments: [2005-07-19 08:41:21] ezmlm at mail dot ru This problem does not exist in php5 module for Apache2. It only exists in php5 module for Apache1 cause those are completly different modules. Using php_admin_value safe_mode 1 didn't change anything. again the steps to reproduce the problem. Apache 1.3.33 is configured with ./configure --enable-module=so and installed with make && make install php is configured with ./configure --with-apxs=/usr/local/apache/bin/apxs then installed with make && make install In httpd.conf added: AddType application/x-httpd-php .php .phtml php_admin_value safe_mode on In section set AllowOverride Options to allow php_flag and php_value in .htaccess In /usr/local/apache/htdocs created info.phtml: The result is that safe_mode is ON and content of /etc/passwd IS NOT displayed. Now create .htaccess in /usr/local/apache/htdocs: php_flag safe_mode off The result is that phpinfo() shows safe_mode is OFF and content of /etc/passwd IS displayed. [2005-07-19 00:45:21] [EMAIL PROTECTED] Try change that php_admin_value line in httpd.conf to this: php_admin_value safe_mode 1 [2005-07-19 00:43:19] [EMAIL PROTECTED] I can't reproduce this override problem when using Apache2. [2005-07-19 00:37:23] [EMAIL PROTECTED] Solved. I had wrong permissions and owners set on the path and script I used. safe-mode works as expected. [2005-07-18 19:18:20] [EMAIL PROTECTED] I can't get safe-mode to work at all when using PHP CVS HEAD (5.1-dev). No matter where I set it, be it php.ini or httpd.conf 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/33723 -- Edit this bug report at http://bugs.php.net/?id=33723&edit=1
#33765 [Opn->Asn]: SOAP one-way is not fire-and-forget
ID: 33765
Updated by: [EMAIL PROTECTED]
Reported By: php at sowen dot de
-Status: Open
+Status: Assigned
Bug Type: SOAP related
Operating System: Gentoo Linux
PHP Version: 5.1.0b3
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2005-07-19 09:20:37] php at sowen dot de
Description:
When I try to make a SOAP call to a server that doesn't reply with an
answer, my client keeps on waiting until the server finished it's work.
Shouldn't one-way operation be "fire-and-forget" in order to make more
sense?
This could be solved by returning a HTTP 200 response and closing the
socket, right after the SOAP call was received by the server.
Reproduce code:
---
Server code:
public function onewaytest() {
sleep(50);
}
Client code:
$soap = new SoapClient(null, '...');
$starttime=time();
$soap->onewaytest();
echo time()-$starttime." sec\n";
Expected result:
Just the network time-overhead caused by HTTP connect and POST.
Actual result:
--
Above 50 sec.
--
Edit this bug report at http://bugs.php.net/?id=33765&edit=1
#33708 [Fbk->Opn]: Problem with php module recode
ID: 33708 User updated by: kirameku at email dot cz Reported By: kirameku at email dot cz -Status: Feedback +Status: Open Bug Type: Recode related Operating System: RedHat ES4 x86_64 PHP Version: 4.4.0 New Comment: I used CVS snapshot php5-200507190630, but the problem persisting. gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.1) /home/Develop/php5-200507190630/ext/recode/recode.c: In function `zif_recode_string': /home/Develop/php5-200507190630/ext/recode/recode.c:152: warning: passing arg 5 of `recode_buffer_to_buffer' from incompatible pointer type /home/Develop/php5-200507190630/ext/recode/recode.c:152: warning: passing arg 6 of `recode_buffer_to_buffer' from incompatible pointer type # ./php test.php Segmentation fault (core dumped) [EMAIL PROTECTED] cli]# gdb ./php core.5723 GNU gdb Red Hat Linux (6.3.0.0-0.31rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/tls/libthread_db.so.1". Core was generated by `./php test.php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib64/libcrypt.so.1...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /usr/lib64/librecode.so.0...done. Loaded symbols for /usr/lib64/librecode.so.0 Reading symbols from /usr/lib64/libpng12.so.0...done. Loaded symbols for /usr/lib64/libpng12.so.0 Reading symbols from /usr/lib64/libz.so.1...done. Loaded symbols for /usr/lib64/libz.so.1 Reading symbols from /usr/lib64/libjpeg.so.62...done. Loaded symbols for /usr/lib64/libjpeg.so.62 Reading symbols from /lib64/libresolv.so.2...done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /lib64/tls/libm.so.6...done. Loaded symbols for /lib64/tls/libm.so.6 Reading symbols from /lib64/libdl.so.2...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libnsl.so.1...done. Loaded symbols for /lib64/libnsl.so.1 Reading symbols from /lib64/libssl.so.4...done. Loaded symbols for /lib64/libssl.so.4 Reading symbols from /lib64/libcrypto.so.4...done. Loaded symbols for /lib64/libcrypto.so.4 Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done. Loaded symbols for /usr/lib64/libgssapi_krb5.so.2 Reading symbols from /usr/lib64/libkrb5.so.3...done. Loaded symbols for /usr/lib64/libkrb5.so.3 Reading symbols from /lib64/libcom_err.so.2...done. Loaded symbols for /lib64/libcom_err.so.2 Reading symbols from /usr/lib64/libk5crypto.so.3...done. Loaded symbols for /usr/lib64/libk5crypto.so.3 Reading symbols from /usr/lib64/libxml2.so.2...done. Loaded symbols for /usr/lib64/libxml2.so.2 Reading symbols from /lib64/tls/libpthread.so.0...done. Loaded symbols for /lib64/tls/libpthread.so.0 Reading symbols from /lib64/tls/libc.so.6...done. Loaded symbols for /lib64/tls/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib64/libnss_files.so.2...done. Loaded symbols for /lib64/libnss_files.so.2 #0 0x0038693b7865 in delmodule_flat () from /usr/lib64/librecode.so.0 (gdb) bt #0 0x0038693b7865 in delmodule_flat () from /usr/lib64/librecode.so.0 #1 0x0038693aa50d in recode_new_task () from /usr/lib64/librecode.so.0 #2 0x0038693aa82e in recode_perform_task () from /usr/lib64/librecode.so.0 #3 0x0038693a924c in recode_buffer_to_buffer () from /usr/lib64/librecode.so.0 #4 0x0053d5dd in zif_recode_string (ht=72, return_value=0xc5ba48, return_value_ptr=0x48, this_ptr=0xc60f60, return_value_used=-1073771232) at /home/Develop/php5-200507190630/ext/recode/recode.c:152 #5 0x0069a1db in zend_do_fcall_common_helper_SPEC (execute_data=0x7fbfffd090) at /home/Develop/php5-200507190630/Zend/zend_vm_execute.h:184 #6 0x006999dc in execute (op_array=0xc5c5f8) at /home/Develop/php5-200507190630/Zend/zend_vm_execute.h:87 #7 0x00673cb9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/Develop/php5-200507190630/Zend/zend.c:1087 #8 0x0063661f in php_execute_script (primary_file=0x7fb830) at /home/Develop/php5-200507190630/main/main.c:1672 #9 0x007074c0 in main (argc=2, argv=0x7fb988) at /home/Develop/php5-200507190630/sapi/cli/php_cli.c:1039 Previous Comments: [2005-07-18 21:51:44] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip I can not reproduce this with PHP 5.1-dev. Also, I have GCC-4.0.0, if that makes any difference..
#33296 [Com]: popen (passthru etc.) doesn't work correct
ID: 33296 Comment by: screen at brainkrash dot com Reported By: thomas dot wetzler at siemens dot com Status: No Feedback Bug Type: Program Execution Operating System: SUN OS PHP Version: 4.3.10 New Comment: Tested script from on php4.4.0 cli/apache2 and php4-STABLE-200507190640 on Linux server and ALL samples worked. Found this bug searching for a similar (maybe the same) issue related to popen/freads calling SVN. I modified this test script and ran tests using 4.4.0 and php4-STABLE-200507190640 with the following results: script -- #!/usr/local/apache2/php/bin/php # results --- /usr/local/apache2/php/bin/php -f test.php > test440_cli.txt > works wget -O test440_apache2.txt http://brainkrash.com/~screen/test/test.php > all 10 fail with no return from fgets /usr/local/apache2/php/bin/php -f test.php > test4-200507190640_cli.txt > works wget -O test4-200507190640_apache2.txt http://brainkrash.com/~screen/test/test.php > all 10 fail with no return from fgets expected result --- 0*** Subprozess: 'Resource id #4'; resource usage: svn [options] [args] Subversion command-line client, version 1.2.1. Type 'svn help ' for help on a specific subcommand. Most subcommands take file and/or directory arguments, recursing on the directories. If no arguments are supplied to such a command, it recurses on the current directory (inclusive) by default. Available subcommands: add blame (praise, annotate, ann) ... failure results --- 0*** Subprozess: 'Resource id #2'; resource Previous Comments: [2005-06-23 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-06-15 19:16:03] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Try also the latest PHP 4 snapshot. [2005-06-15 15:54:16] thomas dot wetzler at siemens dot com We tried out PHP Version 5. With the commandline (php.exe) it seems to work but with the mod_php-module we get the same failure. Because the testing of our application take a long time, it would be good if you can find a solution for Version 4. [2005-06-11 15:18:48] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-06-10 10:54:44] thomas dot wetzler at siemens dot com Description: While sequentially opening and closing several processes via popen (or passthru, exec and '' command) php looses some processes. This takes place if, for instance, the user presses the reload-button on a website several times. With the coding below, you can reproduce the failure (takes place on commandline (php.exe) and in apache module (mod_php)). Reproduce code: --- #!/wir/webadmin/share/php4/bin/php # programcall: > Expected result: Within the result-file, there should be 900 times the same result from the system command (here ls -l command). 255*** Subprozess: 'Resource id #259'; resource total 2526 -rw-r--r-- 1 webadmin oracle572135 Jun 10 09:52 _test1.txt drwxr-xr-x 2 wir oracle96 May 2 15:27 mail -rw-r--r-- 1 wir oracle258956 Jun 10 10:42 test -rwxrwx--- 1 wir oracle 698 Jun 10 10:41 test.php -rw-r--r-- 1 webadmin oracle105326 Jun 10 09:52 test1 -rwxrwx--- 1 wir oracle 656 Jun 10 09:48 test1.php -rwxr-x--- 1 wir oracle 321 Jun 10 10:43 thomas.php -rw-r--r-- 1 wir oracle148274 Jun 10 10:43 thw.txt Actual result: -- Some results are missing. The same programm written in perl or shellscript is working correct. -rwxr-x--- 1 wir oracle 321 Jun 10 10:43 thomas.php -rw-r--r-- 1 wir oracle148274 Jun 10 10:43 thw.txt 256*** Subprozess: 'Resource id #260'; resource 257*** Subprozess: 'Resource id #261'; resource total 2526 -rw-r--r-- 1 webadmin oracle572135 Jun 10 09:52 _test1.txt drwxr-xr-x 2 wir oracle96 May -- Edit this bug report
#33747 [Fbk->Opn]: php5: Too many Oracle-Sessions on INSERT Statements
ID: 33747 User updated by: alfred dot trapp at tvi-services dot de Reported By: alfred dot trapp at tvi-services dot de -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: Linux PHP Version: 5.0.4 New Comment: Hi sniper, thanks for the proposal, but first tests with latest win32 PHP/5.1.0-dev indicates the same bug. Previous Comments: [2005-07-18 18:41:13] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-07-18 13:05:22] alfred dot trapp at tvi-services dot de Description: We have an application currently running without problems (Fedora 3 + PHP 4.3.3(from source) + apache 1.3.33(from source) + Oracle Client 9.2 oci8). Now we have tested php 5.0.4 with Oracle Client 9.2 / 10.1 connecting to an Oracle 9.2 Database with either ocilogon, ocinlogon and ociplogon making around 500 INSERTS in a loop. On database side we get a so called Oracle Session Explode while inserting, doing around 30 inserts with data and the rest are empty INSERTS without any (NULL) values. Actually there are around 50 Oracle Sessions opened, most of them without any data (detected with PL/SQL-Developer from Allround Automations). Also we get >>Number of Sessions exceeded<< from the Database. On the productive version with php 4.3.3 we have one Oracle Session with all 500 rows full of correct data inserted. Reproduce code: --- Configure Command './configure' '--build=i686-redhat-linux-gnu' '--host=i686-redhat-linux-gnu' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-libdir=lib' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' '--with-apxs2' '--disable-rpath' '--with-bz2' '--with-curl' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-expat-dir=/usr' '--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--with-pear=/usr/share/pear' '--with-kerberos' '--enable-ucd-snmp-hack' '--with-unixODBC=shared,/usr' '--enable-memory-limit' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--with-oci8=/db/oracle/product/10.1/client' '--with-mime-magic=/usr/share/file/magic.mime' '--without-sqlite' '--with-libxml-dir=/usr' '--with-xml' '--with-apxs2=/usr/sbin/apxs' '--without-mysql' '--without-gd' '--without-odbc' '--disable-dom' '--disable-dba' Program Code $connection=ocilogon($g_tvp_user, $g_tvp_pw, $g_tvp_sid); $tabellenname="ERGEBNISSE_".$_SESSION['tvipilot']['user_id']; for($i=0;$ihttp://bugs.php.net/?id=33747&edit=1
#33764 [Opn->Fbk]: Dllhosts Crash on shutdown
ID: 33764 Updated by: [EMAIL PROTECTED] Reported By: support at fudashi dot com -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Windows XP PHP Version: 5.0.4 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Previous Comments: [2005-07-19 08:17:04] support at fudashi dot com Description: I am running Windows XP with IIS 5.1. I am running the PHP Zend engine as an ISAPI filter. I get a windows popup error on shutdown stating the following : dllhost.exe Application error the instruction at "0x77f83aef" referenced memory at "0x00060009". The memory could not be "written". Click on OK to terminate the program Click on CANCEL to debug the program. It doesnt matter what I run I will always get this error at shutdown. My scripts run great no problems, the error only occurs on shutdown. -- Edit this bug report at http://bugs.php.net/?id=33764&edit=1
#33762 [Opn->Bgs]: Setting error_reporting doesn't turn off strict warning messages
ID: 33762 Updated by: [EMAIL PROTECTED] Reported By: russell at flora dot ca -Status: Open +Status: Bogus -Bug Type: Compile Warning +Bug Type: *Configuration Issues Operating System: 2.6.12-1.1398_FC4 Linux PHP Version: 5.0.3 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Previous Comments: [2005-07-19 05:38:35] russell at flora dot ca Description: I know this has been said to not be a bug, and many bug reports have been ignored, but I have tried everything suggested. This is the right php.ini file, and I am modifying the ini file and not some other way to set variables that might happen at run-time. I have gone so far as to set: error_reporting = 0 in my php.ini. I can then go to phpinfo() and it displays as I would expect: Directive Local Value Master Value error_reporting 0 0 Error warnings are still coming out on the output of the pages, even though display_errors Off Off Example errors from: http://forumonpublicdomain.ca/ (I may be forced to downgrade PHP to fix this problem. PHP5 isn't useable for me until this problem is fixed. phpinfo() is at http://www.forumonpublicdomain.ca/info.php ) strict warning: Assigning the return value of new by reference is deprecated in /home/forumonpublicdomain.ca/www.forumonpublicdomain.ca/themes/engines/phptemplate/phptemplate.engine on line 335. strict warning: var: Deprecated. Please use the public/private/protected modifiers in /home/forumonpublicdomain.ca/www.forumonpublicdomain.ca/themes/engines/phptemplate/template.php on line 27. strict warning: var: Deprecated. Please use the public/private/protected modifiers in /home/forumonpublicdomain.ca/www.forumonpublicdomain.ca/themes/engines/phptemplate/template.php on line 28. -- Edit this bug report at http://bugs.php.net/?id=33762&edit=1
#33745 [Bgs]: Errors compiling on x86_64 platform
ID: 33745
User updated by: jap1968 at yahoo dot es
Reported By: jap1968 at yahoo dot es
Status: Bogus
Bug Type: Compile Failure
Operating System: Fedora Core 4
PHP Version: 5.0.4
New Comment:
Now I have recompiled my other modules (freeTDS) generating libs in
'lib64' (As you should have noticed, this is my first time working on a
64 bit platform).
Using the option '--with-libdir=lib64' works right in the CVS version,
but fails in the 5.0.4 version when trying to include the gd library
(it still complains about libpng not found).
Even on the CVS version, there is a minor problem with the location of
zlib: You must tell either '--with-zlib' or
'--with-zlib-dir=/usr/lib64'. Otherwise, if you let the script search
zlib (required by libpng, from gd) it is not able to find the library,
even being on the same dir (/usr/lib64) as the rest of the libraries.
So, I have finally been able to compile (The CVS version, not the
5.0.4) PHP with this configuration:
./configure \
--with-libdir=lib64 \
--with-apxs2=/usr/sbin/apxs \
--with-config-file-path=/etc \
--with-gd \
--with-zlib \
--with-mssql=/usr/local/freetds \
--without-sqlite \
--with-mysql \
--enable-ftp \
--enable-sockets
Previous Comments:
[2005-07-18 18:43:03] [EMAIL PROTECTED]
When you want to compile 32bit binary, the libs are supposed to be
under /lib, when you compile 64bit binary they're supposed to be under
/lib64. Just use the option, that's what it's there for. (no, we're not
going to add any magical detection for this)
[2005-07-18 14:57:06] jap1968 at yahoo dot es
I have just the same behaviour using the CVS (php5-200507181030)
version.
If you have a look to the lines 2874..2880 of the configure script,
you'll see:
# Check whether --with-libdir or --without-libdir was given.
if test "${with_libdir+set}" = set; then
withval="$with_libdir"
q=$withval
else
PHP_LIBDIR=lib
fi
The PHP_LIBDIR var is set to 'lib' by default. So the solution is
execute the configure script with an additional parameter:
./configure --with-libdir=lib64 ...
Could the configure script be modified in such way that it does some
kind of test as that?
if uname -m == x86_64 then PHP_LIBDIR=lib64
Sorry, but I'm not very familiar with the shell scripting syntax.
With the additional parameter it seems to work, but I have to recompile
some other modules to place their compiled libs in 'lib64' instead of
'lib' (as they do right now) to do a test with all the modules which I
need in my PHP.
[2005-07-18 12:15:12] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-07-18 12:13:02] jap1968 at yahoo dot es
Description:
I am having a lot of problems when trying to compile PHP on a Fedora
Core 4 (x86_64) just out of the box.
They seem to be related to problems in finding the 64bit versions of
the libraries
Initially I had problems to compile with MySQL support, but those where
solved adding
LDFLAGS=' -L/usr/lib64/mysql'
when launching the '.configure' command. Then, manually replacing
'-L/usr/lib/mysql' with '-L/usr/lib64/mysql' when running the libtool
command (just at the end of the 'make' process).
With these changes I can compile PHP with MySQL both in 64 bit version,
but I am having a similar problem compiling with the graphic library GD
(--wityh-gd) and even telling explicitly the path of the 64 bit
libraries, it always complain about not finding the libraries.
As I told before, Is a FC4-x86_64 distro just installed, 'out of the
box' without any changes.
Reproduce code:
---
LDFLAGS=' -L/usr/lib64 -L/usr/lib64/mysql' ./configure \
--with-apxs2=/usr/sbin/apxs \
--with-config-file-path=/etc \
--with-zlib \
--without-sqlite \
--with-gd \
--with-jpeg-dir=/usr/lib64 \
--with-png-dir=/usr/lib64
Expected result:
Makefile created!
Actual result:
--
checking for GD support... yes
checking for the location of libjpeg... /usr/lib64
checking for the location of libpng... /usr/lib64
..
configure: error: libjpeg.(a|so) not found.
Note: Both, libjpeg.a and libjpeg.so are located on my /usr/lib64
directory
--
Edit this bug report at http://bugs.php.net/?id=33745&edit=1
#33763 [Opn->Bgs]: array_multisort() affects copy of an array in function
ID: 33763
Updated by: [EMAIL PROTECTED]
Reported By: marceloburegio at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: Fedora Core 4 and Windows 2000
PHP Version: 5.0.4
New Comment:
This is duplicate of bug #25359.
Behavior is different but reason exactly the same.
array_multisort() - recieves array by value and wotk with tham as with
references.
Previous Comments:
[2005-07-19 06:28:28] marceloburegio at gmail dot com
Description:
Using array_multisort() in a function with copy of local array, this
affects the original array.
It's same to bug #32031
I solve this changing the code:
$arrSort = $arr;
to:
$arrSort = $arr + array();
Reproduce code:
---
function bug_array($arr) {
$arrSort = $arr;
array_multisort($arrSort);
}
$arr = array(1, 0);
print_r($arr);
bug_array($arr);
print_r($arr);
Expected result:
Array
(
[0] => 1
[1] => 0
)
Array
(
[0] => 1
[1] => 0
)
Actual result:
--
Array
(
[0] => 1
[1] => 0
)
Array
(
[0] => 0
[1] => 1
)
--
Edit this bug report at http://bugs.php.net/?id=33763&edit=1
#33710 [Ver->Csd]: ArrayAccess objects doen't initialize $this
ID: 33710
Updated by: [EMAIL PROTECTED]
Reported By: pornel at despammed dot com
-Status: Verified
+Status: Closed
Bug Type: Class/Object related
Operating System: *
PHP Version: 5.1.0b3
-Assigned To:
+Assigned To: dmitry
New Comment:
Fixed in CVS HEAD and PHP_5_0.
The test case produces memory leaks in PHP_5_0.
These leaks are fixed in HEAD only.
Previous Comments:
[2005-07-15 15:14:35] pornel at despammed dot com
Description:
In object that implements ArrayAccess and accesses itself as array
inside its own method, $this is not available ("Undefined variable:
this")
Reproduce code:
---
succeed();
$bar->fail();
Expected result:
No error. Both methods should work.
Actual result:
--
Notice: Undefined variable: this in c:\www\test.php5 on line 13
--
Edit this bug report at http://bugs.php.net/?id=33710&edit=1
#33765 [NEW]: SOAP one-way is not fire-and-forget
From: php at sowen dot de
Operating system: Gentoo Linux
PHP version: 5.1.0b3
PHP Bug Type: SOAP related
Bug description: SOAP one-way is not fire-and-forget
Description:
When I try to make a SOAP call to a server that doesn't reply with an
answer, my client keeps on waiting until the server finished it's work.
Shouldn't one-way operation be "fire-and-forget" in order to make more
sense?
This could be solved by returning a HTTP 200 response and closing the
socket, right after the SOAP call was received by the server.
Reproduce code:
---
Server code:
public function onewaytest() {
sleep(50);
}
Client code:
$soap = new SoapClient(null, '...');
$starttime=time();
$soap->onewaytest();
echo time()-$starttime." sec\n";
Expected result:
Just the network time-overhead caused by HTTP connect and POST.
Actual result:
--
Above 50 sec.
--
Edit bug report at http://bugs.php.net/?id=33765&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33765&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33765&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33765&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33765&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33765&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33765&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33765&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33765&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33765&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33765&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33765&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33765&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33765&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33765&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33765&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33765&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33765&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33765&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33765&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33765&r=mysqlcfg
