ID: 14529 User updated by: [EMAIL PROTECTED] Old Summary: script doesn't always finish output Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Output Control Operating System: Linux RH 7.2 Old PHP Version: 4.1.0 PHP Version: 4.1.1 New Comment:
Have tried using PHP 4.1.1 now and output is still being cut off. It seems to do this when there is a very long string in a variable. For example I have my one program create all the body of an HTML file into one variable such as $body. Other variables handle other sections of the HTML code such as $header, $body_tag, etc. This way many different modules can all have control over the page output regardless of when they are called. But if the output gets fairly large in one variable, then the script seems to stop output (NOT NECESSARILY while outputing that variable but could be in the middle of an echo statement further down. It's as if it can only handle echoing a limited amount HTML. I'm not talking about the variable being huge either, just a couple of pages worth of text. I tried changing the default 8MB of memory a script can use up to 20MB. Currently I have output buffering turned to Off. If I turn it on it seems to handle it better but still have problems. Previous Comments: ------------------------------------------------------------------------ [2001-12-19 18:32:00] [EMAIL PROTECTED] Sorry, What I first thought to be consistant is proving me wrong. The end bracket is now making no difference whether the page loads completely or not. It seemed to at first but now there is no difference. A new discovery is that on some pages even with Output_buffering set to On, it is also halting output to HTML code. It is also crashing many times whereas a request to a page (or simple refresh) is sometimes just hanging or returning very quickly that the page is not available (and upon a refresh it loads again). 4.1.0 had some wise moves made with the session handling so globals can be turned off. I've been waiting for this improvement for sometime, but 4.1.0 is simply too buggy and unstable. I've tried a couple of the new developments but am finding other problems with them the strongest being my code to connect to my MySQL database no longer works in the newer versions (4.2.0-dev). I am giving up and going back to 4.0.6 Until the serious bugs are removed from a version with the better session handling. If you need me to test other things I'd be happy to, just let me know. ------------------------------------------------------------------------ [2001-12-17 17:58:58] [EMAIL PROTECTED] Went back to PHP 4.1.0 and have tried numerous things and found a consistency causing the problem (don't understand why though). If the URL is something such as: http://www.domain.com/test/control_panel scripting stops part ways through unless I have output_buffering On if the URL is: http://www.domain.com/test/control_panel/ (notice the end /) it works just fine with output_buffering on OR off When I drop back to PHP4.0.6 it doesn't matter if the end '/' is there or not. I must point out that this script forces a virtual URL in that it actually is running a PHP script called test and everything else on the URL is simply virtual pages telling the test script what it is to be doing. On static pages I have not tested this to see if the '/' is missing that there is a problem. Perhaps apache needs different configuration when using PHP4.1.0 over PHP4.0.6 to overcome the end '/' tag. Now that I know this bug, I can easily overcome it in my code (all links already do this but for test pages I just manually type it in and have always left the end '/' off as it worked in previous versions of PHP). Just in case I tested it with both magic_quotes on and off in both 4.0.6 and 4.1.0 and it still works in 4.0.6 and not in 4.1.0 Either way this problem is not as serious anymore as this slight fix (in knowing the '/' is needed) means I'm no longer having half pages displayed. ------------------------------------------------------------------------ [2001-12-15 15:33:50] [EMAIL PROTECTED] Tried using the snap shot and it will no longer let me connect to my MySQL database so I couldn't run the page I've been doing the testing on. Did the format for mysql_connect change in this version? I can still connect to it from the Linux prompt itself so it's still running. In phpinfo() the section on mysql looks exactly the same except MYSQL_MODULE_TYPE (4.1.0 reports 'none' the 4.2.0-dev reports 'builtin') yet I used the same configure line (both used built in - I've never figured out how to get it to use the installed MySQL perhaps because it's installed from rpm files and library file just don't exist - but not too sure what I am supposed to be looking for there). ------------------------------------------------------------------------ [2001-12-15 06:35:00] [EMAIL PROTECTED] Can you please try a snapshot from snaps.php.net, and see if it's fixed in the 4.2.0dev version? Thanx, Derick ------------------------------------------------------------------------ [2001-12-14 20:16:49] [EMAIL PROTECTED] Having a problem like in bug ID# 9836 but was unable to submit comments to that thread. scripts sometimes stops outputing part ways through. (No errors just an uncompleted page displayed). Regardless of how many refreshes it stops at exact same place. Some pages have very little code others have a lot so length doesn't seem to be the issue. I tried setting a session variable after an echo statement that did not fully display and on a reload it had taken the new value. This would suggest the script doesn't really stop, just the output of HTML being returned stops. As a side note the time the setting of a session variable was added below the lines not displaying, upon a refresh it not only showed me the variable was set but it displayed the whole page. Sure enough if I pulled the session variable out (nothing relative to the page at all), restart the session it's back to stopping at the exact same spot before - right in the middle of an echo statement such as: echo "This is a sample"; would only output: Thi (and that would be the last of the page) It is not timing out (runs in less than a second). But I have discovered if I set the following in php.ini it works perfectly: output_buffering = On (formally set to 'Off') You would think that with it set to On you'd have more chances of a cut off than with it Off Here is my config line (same as when I run PHP4.0.6 which doesn't repeat this problem). ./configure --with-apxs --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --prefix=/u sr --with-config-file-path=/etc --disable-debug --enable-pic --disable-rpath --enable-inline-optimization --with-bz2 --with-curf --with-db3 --with-exec-dir=/usr/bin --with-gd --with-gdbm --with-gettext -with-jpeg-dir=/usr --enable-trans-sid --with-openssl --with-png --with-regex=system --with-ttl --with-zlib --with-layout=GNU --enable-debugger --enable-ftp --enable-magic-quotes --enable-safe-mode --enable-sockets --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-yp --enable-wddx --with-mysql --with-pgsql --without-unixODBC --without-oracle --without-oci8 --with-pspell --with-xml --with-pdf --with-cybercash I also am using Zend Optimizer (for 4.1.0) I should also point out that with PHP4.1.0 I can not use 'user' session handling (used MySQL to handle sessions in PHP4.0.6), now unless I turn it back to default 'files' it will not let me use old (session_register) or the new ($_SESSION['name']=)...though no errors occur the session just doesn't retrieve or store data anymore. I don't know if these two would be linked but I thought I'd bring it up ------------------------------------------------------------------------ Edit this bug report at http://bugs.php.net/?id=14529&edit=1 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
