#24666 [NoF->Opn]: random blank pages for any code on any php page
ID: 24666 User updated by: dhunter at uta dot edu Reported By: dhunter at uta dot edu -Status: No Feedback +Status: Open Bug Type: Apache related Operating System: Solaris 8 PHP Version: 4.3.2 New Comment: I haven't had a chance to try the snapshot, but I am still experiencing the problem. Previous Comments: [2003-08-18 19:43:15] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-08-13 21:41:04] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-08-05 15:54:51] dhunter at uta dot edu I did this prior to submitting the bug. See Description. - Thanks [2003-08-05 15:10:25] [EMAIL PROTECTED] Take at a look @ your apache's primary error log file, see if there are any messages from php or reports of crashed apache children. [2003-07-22 22:26:14] dhunter at uta dot edu I've had php logging on the entire time. That's the reason I haven't been able to track this down. We have been using php extensively for a long time and I've never experienced this before. When a page prints blank the access log entry is: www.uta.edu 64.12.96.203 - - [22/Jul/2003:21:59:00 -0500] "GET /uta/current HTTP/1.1" 200 5 "http://www.uta.edu/"; "Mozilla/4.0 (compatible; MSIE 5.0; AOL 8.0; Windows 98; DigExt)" The same page should report 22430 bytes like the following: www.uta.edu 67.66.182.19 - - [22/Jul/2003:22:09:57 -0500] "GET /uta/current HTTP/1.1" 200 22430 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6 StumbleUpon/1.73" What could have changed between 4.3.1 and 4.3.2 that could cause this. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/24666 -- Edit this bug report at http://bugs.php.net/?id=24666&edit=1
#24666 [Fbk->Opn]: random blank pages for any code on any php page
ID: 24666 User updated by: dhunter at uta dot edu Reported By: dhunter at uta dot edu -Status: Feedback +Status: Open Bug Type: Apache related Operating System: Solaris 8 PHP Version: 4.3.2 New Comment: I did this prior to submitting the bug. See Description. - Thanks Previous Comments: [2003-08-05 15:10:25] [EMAIL PROTECTED] Take at a look @ your apache's primary error log file, see if there are any messages from php or reports of crashed apache children. [2003-07-22 22:26:14] dhunter at uta dot edu I've had php logging on the entire time. That's the reason I haven't been able to track this down. We have been using php extensively for a long time and I've never experienced this before. When a page prints blank the access log entry is: www.uta.edu 64.12.96.203 - - [22/Jul/2003:21:59:00 -0500] "GET /uta/current HTTP/1.1" 200 5 "http://www.uta.edu/"; "Mozilla/4.0 (compatible; MSIE 5.0; AOL 8.0; Windows 98; DigExt)" The same page should report 22430 bytes like the following: www.uta.edu 67.66.182.19 - - [22/Jul/2003:22:09:57 -0500] "GET /uta/current HTTP/1.1" 200 22430 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6 StumbleUpon/1.73" What could have changed between 4.3.1 and 4.3.2 that could cause this. [2003-07-21 18:03:13] [EMAIL PROTECTED] Try to enable logging of php errors and see if the php error contains any errors that could explain the cause for the blank pages. -------- [2003-07-20 17:35:31] dhunter at uta dot edu Thanks for the input. I wasn't able to reproduce the error in debug mode. Maybe increased traffic increases the frequency of occurrence. Here is what I have done. I rebuilt all of the web server components, apache, ssl, php, using a newer version of gcc (3.2.3), and I removed some of php's configuration options. As I mentioned I wasn't able to reproduce the problem in apache's debug mode, and gdb didn't have anything to report. The problem continues to occur with the rebuilt components, so I am continuing to use 4.3.1 for now. I'll build the snapshot and see if the error is still present. Summary: - plain html pages are ok. - php pages randomly print blanks regardless of code. - occurs with apache 1.3.27 or 1.3.28, and php 4.3.2 on sparc solaris 8 - php 4.3.1 works great [2003-07-16 21:05:01] [EMAIL PROTECTED] Oopps, made a slight mistake, run it like: # gdb httpd (gdb) run -X -DSSL 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/24666 -- Edit this bug report at http://bugs.php.net/?id=24666&edit=1
#24666 [Fbk->Opn]: random blank pages for any code on any php page
ID: 24666 User updated by: dhunter at uta dot edu Reported By: dhunter at uta dot edu -Status: Feedback +Status: Open Bug Type: Apache related Operating System: Solaris 8 PHP Version: 4.3.2 New Comment: I've had php logging on the entire time. That's the reason I haven't been able to track this down. We have been using php extensively for a long time and I've never experienced this before. When a page prints blank the access log entry is: www.uta.edu 64.12.96.203 - - [22/Jul/2003:21:59:00 -0500] "GET /uta/current HTTP/1.1" 200 5 "http://www.uta.edu/"; "Mozilla/4.0 (compatible; MSIE 5.0; AOL 8.0; Windows 98; DigExt)" The same page should report 22430 bytes like the following: www.uta.edu 67.66.182.19 - - [22/Jul/2003:22:09:57 -0500] "GET /uta/current HTTP/1.1" 200 22430 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6 StumbleUpon/1.73" What could have changed between 4.3.1 and 4.3.2 that could cause this. Previous Comments: [2003-07-21 18:03:13] [EMAIL PROTECTED] Try to enable logging of php errors and see if the php error contains any errors that could explain the cause for the blank pages. ---- [2003-07-20 17:35:31] dhunter at uta dot edu Thanks for the input. I wasn't able to reproduce the error in debug mode. Maybe increased traffic increases the frequency of occurrence. Here is what I have done. I rebuilt all of the web server components, apache, ssl, php, using a newer version of gcc (3.2.3), and I removed some of php's configuration options. As I mentioned I wasn't able to reproduce the problem in apache's debug mode, and gdb didn't have anything to report. The problem continues to occur with the rebuilt components, so I am continuing to use 4.3.1 for now. I'll build the snapshot and see if the error is still present. Summary: - plain html pages are ok. - php pages randomly print blanks regardless of code. - occurs with apache 1.3.27 or 1.3.28, and php 4.3.2 on sparc solaris 8 - php 4.3.1 works great [2003-07-16 21:05:01] [EMAIL PROTECTED] Oopps, made a slight mistake, run it like: # gdb httpd (gdb) run -X -DSSL [2003-07-16 21:01:24] [EMAIL PROTECTED] Could you try if you can reproduce this when you run apache like this: # gdb httpd -X (if you need SSL, add -DSSL there) You should test the snapshot on separate instance/machine. e.g. have another apache with PHP build from the snapshot running in other port. (separate development server would be best choice though :) [2003-07-16 15:56:42] dhunter at uta dot edu Thanks, I'll try the latest snapshot. I'll also try to cut down the configuration, but we use most of the options. Answers to your questions: - output buffering is on - i'm using the php.ini-recommended that comes with 4.3.2. no differences except that i have safe mode on. - i don't set any php.ini settings in .htaccess or httpd.conf. - exactly right, any script randomly produces output and randomly produces no output as evidenced by observation and as recorded in the apache access log. I downgraded to 4.3.1 to correct the problem for now. 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/24666 -- Edit this bug report at http://bugs.php.net/?id=24666&edit=1
#24666 [Fbk->Opn]: random blank pages for any code on any php page
ID: 24666 User updated by: dhunter at uta dot edu Reported By: dhunter at uta dot edu -Status: Feedback +Status: Open Bug Type: Apache related Operating System: Solaris 8 PHP Version: 4.3.2 New Comment: Thanks for the input. I wasn't able to reproduce the error in debug mode. Maybe increased traffic increases the frequency of occurrence. Here is what I have done. I rebuilt all of the web server components, apache, ssl, php, using a newer version of gcc (3.2.3), and I removed some of php's configuration options. As I mentioned I wasn't able to reproduce the problem in apache's debug mode, and gdb didn't have anything to report. The problem continues to occur with the rebuilt components, so I am continuing to use 4.3.1 for now. I'll build the snapshot and see if the error is still present. Summary: - plain html pages are ok. - php pages randomly print blanks regardless of code. - occurs with apache 1.3.27 or 1.3.28, and php 4.3.2 on sparc solaris 8 - php 4.3.1 works great Previous Comments: [2003-07-16 21:05:01] [EMAIL PROTECTED] Oopps, made a slight mistake, run it like: # gdb httpd (gdb) run -X -DSSL [2003-07-16 21:01:24] [EMAIL PROTECTED] Could you try if you can reproduce this when you run apache like this: # gdb httpd -X (if you need SSL, add -DSSL there) You should test the snapshot on separate instance/machine. e.g. have another apache with PHP build from the snapshot running in other port. (separate development server would be best choice though :) ---- [2003-07-16 15:56:42] dhunter at uta dot edu Thanks, I'll try the latest snapshot. I'll also try to cut down the configuration, but we use most of the options. Answers to your questions: - output buffering is on - i'm using the php.ini-recommended that comes with 4.3.2. no differences except that i have safe mode on. - i don't set any php.ini settings in .htaccess or httpd.conf. - exactly right, any script randomly produces output and randomly produces no output as evidenced by observation and as recorded in the apache access log. I downgraded to 4.3.1 to correct the problem for now. [2003-07-15 22:10:51] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip and cut down your configure line to bare minimum that you need for your pages to work. Are you using output buffering features? (php.ini) What is the diff between your php.ini and the php.ini-dist in the 4.3.2 release? (diff -u) Do you set any php.ini settings in httpd.conf / .htaccess parts that might affect the pages involved? Are you sure it's any script? Even plain style script? ---- [2003-07-15 10:31:06] dhunter at uta dot edu Description: Pages that worked in 4.3.1 randomly print blank pages in version 4.3.2. There isn't any specific code that produces this quirk. A simple call to the header function to redirect a browser will produce a blank page. Also note the following: 1) error reporting is turned on 2) Using Apache 1.3.27 3) Apache does not segfault, no segfault occurs and child process does not die 4) no errors are reported in apache logs Although the PHP engine and Apache do not report errors, the access log reports a 5 byte file size when a blank page is printed. For example, a page that is normally reported in the access log as 10,000 bytes is reported as 5 bytes when the PHP engine fails. './configure' '--prefix=/usr/local/apache_1327/php-4.3.1' '--with-apxs=/usr/local/apache_1327/bin/apxs' '--enable-sigchild' '--enable-magic-quotes' '--with-openssl=/usr/local/openssl' '--with-zlib=/usr/local' '--enable-bcmath' '--enable-calendar' '--with-gdbm=/usr/local/gdbm-1.8.0' '--with-db3=/usr/local/BerkeleyDB.3.3' '--enable-dbase' '--enable-dbx' '--enable-dio' '--enable-exif' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-zlib-dir=/usr/local' '--with-ttf' '--enable-gd-native-ttf' '--with-java=/usr/java1.2' '--with-ldap=/usr' '--enable-mbstring' '--enable-mbregex' '--with-mssql=/usr/local/freetds' '--with-mysql=/usr/local/mysql' '--with-mysql-sock=/usr/local/mysql/tmp/mysql.sock' '--with-zlib-dir=/usr/l
#24666 [Fbk->Opn]: random blank pages for any code on any php page
ID: 24666 User updated by: dhunter at uta dot edu Reported By: dhunter at uta dot edu -Status: Feedback +Status: Open Bug Type: *General Issues Operating System: Solaris 8 PHP Version: 4.3.2 New Comment: Thanks, I'll try the latest snapshot. I'll also try to cut down the configuration, but we use most of the options. Answers to your questions: - output buffering is on - i'm using the php.ini-recommended that comes with 4.3.2. no differences except that i have safe mode on. - i don't set any php.ini settings in .htaccess or httpd.conf. - exactly right, any script randomly produces output and randomly produces no output as evidenced by observation and as recorded in the apache access log. I downgraded to 4.3.1 to correct the problem for now. Previous Comments: [2003-07-15 22:10:51] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip and cut down your configure line to bare minimum that you need for your pages to work. Are you using output buffering features? (php.ini) What is the diff between your php.ini and the php.ini-dist in the 4.3.2 release? (diff -u) Do you set any php.ini settings in httpd.conf / .htaccess parts that might affect the pages involved? Are you sure it's any script? Even plain style script? ---- [2003-07-15 10:31:06] dhunter at uta dot edu Description: Pages that worked in 4.3.1 randomly print blank pages in version 4.3.2. There isn't any specific code that produces this quirk. A simple call to the header function to redirect a browser will produce a blank page. Also note the following: 1) error reporting is turned on 2) Using Apache 1.3.27 3) Apache does not segfault, no segfault occurs and child process does not die 4) no errors are reported in apache logs Although the PHP engine and Apache do not report errors, the access log reports a 5 byte file size when a blank page is printed. For example, a page that is normally reported in the access log as 10,000 bytes is reported as 5 bytes when the PHP engine fails. './configure' '--prefix=/usr/local/apache_1327/php-4.3.1' '--with-apxs=/usr/local/apache_1327/bin/apxs' '--enable-sigchild' '--enable-magic-quotes' '--with-openssl=/usr/local/openssl' '--with-zlib=/usr/local' '--enable-bcmath' '--enable-calendar' '--with-gdbm=/usr/local/gdbm-1.8.0' '--with-db3=/usr/local/BerkeleyDB.3.3' '--enable-dbase' '--enable-dbx' '--enable-dio' '--enable-exif' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-zlib-dir=/usr/local' '--with-ttf' '--enable-gd-native-ttf' '--with-java=/usr/java1.2' '--with-ldap=/usr' '--enable-mbstring' '--enable-mbregex' '--with-mssql=/usr/local/freetds' '--with-mysql=/usr/local/mysql' '--with-mysql-sock=/usr/local/mysql/tmp/mysql.sock' '--with-zlib-dir=/usr/local' '--with-mm=/usr/local' '--enable-sockets' '--enable-wddx' '--enable-xslt' '--with-xslt-sablot=/usr/local' '--enable-memory-limit=yes' '--with-gnu-ld' Reproduce code: --- No specific code produces the bug. All pages are randomly printed nothing, blank. Expected result: output Actual result: -- no output -- Edit this bug report at http://bugs.php.net/?id=24666&edit=1
#24666 [NEW]: random blank pages for any code on any php page
From: dhunter at uta dot edu Operating system: Solaris 8 PHP version: 4.3.2 PHP Bug Type: Scripting Engine problem Bug description: random blank pages for any code on any php page Description: Pages that worked in 4.3.1 randomly print blank pages in version 4.3.2. There isn't any specific code that produces this quirk. A simple call to the header function to redirect a browser will produce a blank page. Also note the following: 1) error reporting is turned on 2) Using Apache 1.3.27 3) Apache does not segfault, no segfault occurs and child process does not die 4) no errors are reported in apache logs Although the PHP engine and Apache do not report errors, the access log reports a 5 byte file size when a blank page is printed. For example, a page that is normally reported in the access log as 10,000 bytes is reported as 5 bytes when the PHP engine fails. './configure' '--prefix=/usr/local/apache_1327/php-4.3.1' '--with-apxs=/usr/local/apache_1327/bin/apxs' '--enable-sigchild' '--enable-magic-quotes' '--with-openssl=/usr/local/openssl' '--with-zlib=/usr/local' '--enable-bcmath' '--enable-calendar' '--with-gdbm=/usr/local/gdbm-1.8.0' '--with-db3=/usr/local/BerkeleyDB.3.3' '--enable-dbase' '--enable-dbx' '--enable-dio' '--enable-exif' '--enable-ftp' '--with-gd' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-zlib-dir=/usr/local' '--with-ttf' '--enable-gd-native-ttf' '--with-java=/usr/java1.2' '--with-ldap=/usr' '--enable-mbstring' '--enable-mbregex' '--with-mssql=/usr/local/freetds' '--with-mysql=/usr/local/mysql' '--with-mysql-sock=/usr/local/mysql/tmp/mysql.sock' '--with-zlib-dir=/usr/local' '--with-mm=/usr/local' '--enable-sockets' '--enable-wddx' '--enable-xslt' '--with-xslt-sablot=/usr/local' '--enable-memory-limit=yes' '--with-gnu-ld' Reproduce code: --- No specific code produces the bug. All pages are randomly printed nothing, blank. Expected result: output Actual result: -- no output -- Edit bug report at http://bugs.php.net/?id=24666&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24666&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24666&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24666&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24666&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24666&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24666&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24666&r=support Expected behavior: http://bugs.php.net/fix.php?id=24666&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24666&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24666&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24666&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24666&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24666&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24666&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24666&r=gnused
#21400 [Opn]: Problem writing to Excel spreadsheet via COM
ID: 21400 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: COM related Operating System: Win 2000 PHP Version: 4.3.0 New Comment: Here's some more info: It should be noted that the Excel spreadsheet and its macros *actually do work*, even though PHP or Apache or whoever it is is sending a 404. I know this, because after I'm done with Excel, I stream its HTML output file using readfile() and flush(). If I put a sleep() right after the readfile() and flush(), I can see the spreadsheet and chart in the browser. As soon as the sleep() expires and the script terminates, I get the 404. The HTML file that Excel created still exists, I can enter its URL in my browser and view it OK. Working back and commenting out stuff, I found that selecting or writing to cells in any column other than "A" causes the 404 to happen. Unfortunately, my Excel macros don't work too well when I do that. ;-) Previous Comments: [2003-01-03 17:01:58] [EMAIL PROTECTED] When using COM to write to an Excel spreadsheet, my PHP script can write to cells in column "A", but when I try to write to cells in any other column, the script appears to terminate without sending anything to the browser (a 404 response). The script works OK with 4.2.3, except an Excel "zombie" process remains after the script is finished (this "zombie" bug appears to be fixed with 4.3.0, only to introduce this new problem). -- Edit this bug report at http://bugs.php.net/?id=21400&edit=1
#21400 [NEW]: Problem writing to Excel spreadsheet via COM
From: [EMAIL PROTECTED] Operating system: Win 2000 PHP version: 4.3.0 PHP Bug Type: COM related Bug description: Problem writing to Excel spreadsheet via COM When using COM to write to an Excel spreadsheet, my PHP script can write to cells in column "A", but when I try to write to cells in any other column, the script appears to terminate without sending anything to the browser (a 404 response). The script works OK with 4.2.3, except an Excel "zombie" process remains after the script is finished (this "zombie" bug appears to be fixed with 4.3.0, only to introduce this new problem). -- Edit bug report at http://bugs.php.net/?id=21400&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21400&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21400&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21400&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21400&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21400&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21400&r=support Expected behavior: http://bugs.php.net/fix.php?id=21400&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21400&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21400&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21400&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21400&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21400&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21400&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21400&r=gnused
#19133 [Csd]: imagecopymerge doesn't work correctly in gd2
ID: 19133 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: GD related Operating System: Win2K -PHP Version: 4.2.2 +PHP Version: 4.2.3 New Comment: I tried this in 4.2.3, and my tests still fail. Can you tell me what you did in your tests? Previous Comments: [2002-10-06 02:08:00] [EMAIL PROTECTED] I verified that this works correctly in the bundled GD2 in PHP 4.3. [2002-08-29 16:32:16] [EMAIL PROTECTED] Sorry, we have to stick with version 4.2.2 for now. Can anyone think of any possible workarounds? [2002-08-28 13:57:34] [EMAIL PROTECTED] This might be fixed with the bundled verion of GD2 available with 4.3.0. Please try a snapshot from http://snaps.php.net. [2002-08-28 13:02:59] [EMAIL PROTECTED] Sample script: > > > > Note that with php_gd2, the composite image "$Timg" ends up identical to $Png3. With php_gd, it looks identical to the three PNGs layered atop one another using CSS (which is what I believe to be the proper behavior). [2002-08-28 12:27:46] [EMAIL PROTECTED] sample script? 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/19133 -- Edit this bug report at http://bugs.php.net/?id=19133&edit=1
