Can you please try a snapshot from snaps.php.net, and see if it's fixed in the 4.2.0dev version?

Thanx,

Derick

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).

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.

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.

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.

Derick was asking if you have problem with 4.2.0-dev....
http://snaps.php.net/

I tried the latest snapshot a few weeks ago and after some difficulty getting it to run this script (as I discovered it won't let me connect to mysql using localhost) it crashed my IE when I tried loading the script.

When I use another browser (on my linux box) it gives me the connection lost error again.

I haven't tried it with the latest snapshot (so it's a few weeks outdated).  I'll go get it and try it right now.

http://snaps.php.net seems to be down now (get message 
saying host doesn't exist) so I'll have to try it another 
day

Ok. Please test it when the site is up.
If you find any new problem in snapshots, please submit bug report for it :)

BTW, output control code differs in 4.2.0, so this problem may be fixed in 4.2.0.

found some new things that may help.

On the pages that didn't finish loading I discovered my PHP generated code missed a end </font> tag.  So I added it in and it displays the entire page now (weird that PHP4.0.6 didn't have this problem).

BUT the problem of it crashing IE6.0 still happens in PHP4.1.1.  It is as if there is header information that isn't being sent properly.  When I use a linux box rather than crashing it pops up an error window saying Error, connection to server was dropped.

The way to duplicate this is simply go to a page that loaded fine a minute ago and click refresh (and 1/3 will crash).  I've tried this on smaller scripts and it doesn't crash but it does on this larger program which uses many different functions of PHP so I'm wondering if a function that is used is what causes the problem.  

Any ideas of how I can narrow the test down to find what exactly causes the conflict (maybe a combination of functions)?

The script varies depending on the pages function (many includes) and can be as many as 5000 lines long in some places.  It runs perfectly smooth in PHP4.0.1 -> PHP4.0.6 but not in PHP4.1.0 or newer.  I'll try todays latest snap again (previous one didn't work either).

This is 4th time to ask. Do you have problem with 4.2.0-dev?

I've answered that before (I've tried 3 different snaps versions).  I tried todays php-200201191500 and still the same problem.  I even re-compiled my kernel to the latest stable version this morning just in case it was a RH default compile thing.  

I'm recompiling php-4.0.6 from scratch (rather than the RPM) as we speak with the exact same options on ./configure line just to be sure that it is just 4.1.0 or newer giving me the grief.

PHP4.0.6 compiled with the same ./configure line works flawless so it's only happening in 4.1.0 - 4.2.0-dev

In linux the pages almost never load simply gives me error reports (some sort of connection error so drops connection), IE loads about 60-70% of the time (but I've noticed it is only displaying old cached information even though I've got it set to nocache in php.ini and tried sending headers to force no caching).  I even tried forcing IE not to cache in it's settings but it still does it or else it locks up forever (ALT-CTL-DEL to finally end that task - I've left it for as long as an hour to see if it'd time out first or do something).

I've tried reducing the code to force it not to do any includes except the main one.  So I could test a much smaller script and it still gives me the problem.  Yet if I do a very simple page (like with <? phpinfo() ?>) there is no problems at all.  I'm reading through other bugs trying to find similarities with various functions I use and other bugs to see if I can narrow this down.

Please update Version :)
Here comes more questions.

Do you use trans-sid? (If yes, do you have "register_globals=On"?)
Do you use ob_end_flush(), ob_end_clean() anywher in your scripts?

I guess you have already checked, but 
Do you see any error logs for "Apache" and "PHP"?

Could you try to run httpd under gdb to see if you get any signal or exit code.

Never thought to look at apache logs.  Here is a very common error.
[Sat Jan 19 20:49:54 2002] [notice] child pid 14822 exit signal Segmentation fault (11)
[Sat Jan 19 21:25:20 2002] [warn] child process 14826 still did not exit, sending a SIGTERM
[Sat Jan 19 21:25:24 2002] [error] child process 14826 still did not exit, sending a SIGKILL

The first line has at least 20 of them in a row and then the last two occasionally show up at the end of it.  It happens on every page load.

I was using trans-sid for most tests.  Register globals has been Off for most tests as well.

No use of ob_end_flush() or ob_end_clean() anywhere in my scripts.  (I have output_buffering set to Off - but have tried, On and 4K).

I'm not sure what you mean by gdb for running httpd under.  I tried using tail on the error_log and when the page locks the error message (above) is what I got.

I am also experiencing this problem with PHP.  On some pages no output is generated whatsoever (http://ged.dynodns.net/band/events.php [events.phps for source]).  But the main page (http://ged.dynodns.net/band/index.php [index.phps for source]) works fine until GET var's are passed to it (ie: index.php?func=article&oid=19288), in which case it doesn't work at all.

It cuts output off when I have output buffering off, but appears to work OK when I have output buffering enabled.

./configure \
--with-apxs \
--disable-short-tags \
--without-mysql \
--with-pgsql=/usr/pgsql

and the php.ini file can be viewed here:
http://ged.dynodns.net/band/php.ini

I also, do not get any error reports or crashes when running Apache in gdb for debugging.  I have all logging in PHP set to E_ALL so I should see any cought source errors, and Apache set to 'debug' so I should get verbose error messages there, and none are showing up for this problem.

I have verified this bug with the latest 4.2.0-dev version.  Output problems are still the same: corrupt output with buffering off, and correct output with buffering on, without any HTTP GET variables.

(http://ged.dynodns.net/band/index.php?func=article&oid=19288)

But only on some pages, for some reason.  (E.G. events.php never works)

I'm backing up to 4.0.6 to get the site to a production status again. (If 4.0.6 doesn't work, I'll post again...)

Anyone have short complete script for this bug?

And what happens when you get rid of 
--enable-trans-sid 
from your confiugre line?

When I use simple little scripts it seems to work fine.  The pages where I have problems is where there are dynamically called include_once and variable variables used.

For me the output seemed to work at first with output.buffering on but it turns out there was problems on other pages then (that weren't bothered by it being off).  And IE6 would simply load pages from cache of old pages (and Netscape would simply crash with a connection lost error)

I also discovered that some environmental variables working with sessions would fail to if there was a tiny error on html output at least in one consistent test.  
Example:
If I had page (such as index.php) generate a basic HTML page but within the html code generated there was an <img> tag with an image name that did not exist on the server anymore (I had renamed it and forgot to update that script).  The browser just shows standard little box with x in it where image should be as usual.  When this was happening, if I echoed the value of $HTTP_SERVER_VARS['PHP_SELF'] it would return index.php (or the name of the page).  However, if I saved that value to a session, then even though a test before the script end showed it correctly set, upon reloading it would be set to the page name (image.gif).

I have tried the compiling with AND without --enable-trans-sid and these errors still continue with no change.

I have to keep my production server on php 4.0.6 as it simply is way to unreliable in 4.1.0 or newer (including 4.2.2-dev).  I use a lot of serialize/unserialize and really was hoping to upgrade for the performance differences.

To properly diagnose this bug, 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".

I've followed the instructions on the gdb backtrace page but I can not find a core file anywhere on the site.  When I tried running httpd -X in the gdb itself I can not access the page.

I'm using RedHat 7.2 on my test server.  I ran the command (to test it)

/usr/sbin/httpd -X
 and it starts fine and no prompt comes back (which I think is normal).  The moment I open a webpage it returns the line:
Segmentation fault
and then goes back to the command prompt.

So this would tell me I found the right command line to run but when I try:

gdb /usr/sbin/httpd
run -X   (from inside the gdb prompt)
it says starting new thread and then locks up.

If I try opening a web page it comes up as not found (just like it does when the httpd server is not running at all).

Any tips on what I'm doing wrong.  At least I've finally confirmed it is PHP crashing.  I've tried compiling with various options enabled or disabled.  I've got the --enable-debug take and I did not set the --enable-trans-sid this time.

Thanks

I think i had something similar happen to me. It would just stop printing to the screen and either spit out crazy characters or stop altogether.

I commented out every line and brought it back one by one until i located the problem. Although i'm still not exactly sure what's going on I might have a solution. (worked in my case) I put a flush() every now and then. It seemed to fix the problem.

We are getting closer, I've got a small team of people at this end working on solving this bug and are now trying to dedicate much more time and money into getting this bug solved!  (Our business success depends on it)  The problem, we only know PHP programming well and are weaker in the server end of things (I'm the only one with some Linux knowledge) so we need your help to solve this.  Here is a summary of all things done so far to narrow this down (much already due to your help).  We've seperated everything into sections below.

PROBLEM:
While running some more complex PHP scripts they will not work on anything newer than 4.0.6 but works 100% on 4.0 -> 4.0.6.  The page simply stops displaying part ways through a script (usually right in the middle of an echo statement or between echo statements).  The script seemed to finish commands past the point of where it stopped but is only known through the sessions (seeing nothing else is being displayed to screen) But, we've discovered when this crash happens where it has been giving us problems as well so we can not confirm this anymore.



APACHE ERROR_LOG:
When a page is loaded with my problem scripts I get either 1 or 2 errors in my apache error_log:
[date] [notice] child pid #### exit signal Segmentation fault (11)
(if two errors the second is the same except different pid number)



SCRIPTS CAUSING CRASHES:
These scripts that cause the problems have been in development for almost 3 years now and are fairly complex.  Not all scripts give me hassles, but from the tests I have done, it appears only scripts that have sessions AND use fairly large hashes (passed into and out from sessions via serialize() functions) is where I have problems.  Even complex or large scripts without this in it seem to run fine.  All scripts run fine in PHP versions 4.0.6 or older but not since 4.1.0 or newer (up to 4.2.2)




PHP compiling configurations:
Have tried compiling with various combinations of options trying to narrow down if a particular option is what is causing the problems.  So far I can not find anything consistent.



GDB RESULTS:
You gave me the link to the generating bug-traces and I'm having problems getting it to run apache properly.
I could not find a core file on my server.  (Apache isn't generating them, or I simply can not find them).  So I've been using your suggested method of running the script through gdb itself.  Here is what I've done so far.

Stopped the apache server (tested going to web page and confirmed it was down), I then typed:
gdb /usr/sbin/httpd
run -X   (from inside the gdb prompt)
It then says it's starting /usr/sbin/httpd with a new thread and then starts a new blank line (while it's waiting for an apache crash signal).
If at this point I use my browser and go to plain html web page it works (so that tells me the apache server is running again), BUT if I go to a php page, I get a page not available error.  This means I am unable to load the pages that will make apache crash.


What am I doing wrong to get apache running with PHP through the gdb?

Also, once httpd is started through gdb, how do I stop it and exit gdb - I can CNTL-C but apache keeps running and I can't find the process to kill it.  There must be a cleaner way.

Regarding the configure line and your MySQL problems.  You should NEVER (okay this is my opinion) use the bundled MySQL libs.  On your configure line you should do

--with-mysql=/usr | --with-mysql=/usr/local

Just depends on where it put your libs, which you can find like so

[root@somemachine /]# ldconfig -p | grep mysql
        libmysqlclient.so.10 (libc6) => /usr/local/lib/mysql/libmysqlclient.so.10
        libmysqlclient.so (libc6) => /usr/local/lib/mysql/libmysqlclient.so

I think the RPM puts it in /usr.

-Chris

I've been seeing the same thing in 4.1.2.  In some cases, it partially displays pages.  In others (I think 
this may be related), it doesn't acknowledge a POST until it's been submitted multiple times (3 or 4 
generally).  Both behaviors are very inconsistent (they happen frequently on a site with moderate use, but I 
can't reproduce them).

Here's a backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x402ad693 in _zend_is_inconsistent (ht=0x5a5a5a5a,
    file=0x403fcb84 "zend_hash.c", line=975) at zend_hash.c:84
84              if (ht->inconsistent==HT_OK) {
(gdb) bt
#0  0x402ad693 in _zend_is_inconsistent (ht=0x5a5a5a5a,
    file=0x403fcb84 "?
>???>????\025???G?F?????k?l?\205uTv??????Uv?????v?v??????????x@z@u@??v@w@?????@?@?@???@\017y????\204A\205A\203A???A?A?A????????UB??PBLBHB??SB??WBTBNBJBQB????IBKBcB?????B?B?B???????|?|????e~N~\027C??\026C????cC????\202\177??{C|C??"..., 
line=975) at zend_hash.c:84
#1  0x4046b258 in ?? () from /usr/local/apache/libexec/libphp4.so
#2  0x402aff9f in zend_hash_internal_pointer_reset_ex (ht=0x5a5a5a5a,
    pos=0xbffff090) at zend_hash.c:975
First symbol in segment of executable not a source symbol

I'm seeing the same problem with 4.1.2.  Can reproduce, but with no consistency.

I'm also seeing a problem where PHP isn't responded to POSTs (watching it in ethereal, I had to post 
repeatedly to get a response; the responding page was to set a couple cookies and do a redirect).  Any 
possibility that they might be related?

(Had added a comment with a backtrace, but this one looks much more useful):
#0  0x402ad693 in _zend_is_inconsistent (ht=0x0,
    file=0x403fcb84 "zend_hash.c", line=975) at zend_hash.c:84
#1  0x402aff9f in zend_hash_internal_pointer_reset_ex (ht=0x0, pos=0xbffff090)
    at zend_hash.c:975
#2  0x4031da18 in php_session_save_current_state () at session.c:544
#3  0x40320579 in php_session_flush () at session.c:1381
#4  0x403205bd in zm_deactivate_session (type=1, module_number=3)
    at session.c:1393
#5  0x402ac614 in module_registry_cleanup (module=0x8054dc8) at zend_API.c:1165
#6  0x402af394 in zend_hash_apply (ht=0x404808c0,
    apply_func=0x402ac5d0 <module_registry_cleanup>) at zend_hash.c:669
#7  0x402a8a4e in zend_deactivate_modules () at zend.c:585
#8  0x402b9eb0 in php_request_shutdown (dummy=0x0) at main.c:723
#9  0x402b63ff in apache_php_module_main (r=0x80ab44c, display_source_mode=0)
    at sapi_apache.c:96
#10 0x402b71d0 in send_php (r=0x80ab44c, display_source_mode=0,
    filename=0x80ab9cc "/usr/local/apache/htdocs/planworld/index.php")
    at mod_php4.c:575
#11 0x402b724c in send_parsed_php (r=0x80ab44c) at mod_php4.c:590
#12 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1
#13 0x400630b9 in ?? () from /lib/libdb.so.3
#14 0x40063529 in ?? () from /lib/libdb.so.3
#15 0x400354e2 in ?? () from /lib/libcrypt.so.1
#16 0x4004b743 in _ufc_foobar () from /lib/libcrypt.so.1
#17 0x400630b9 in ?? () from /lib/libdb.so.3
#18 0x4006312f in ?? () from /lib/libdb.so.3
#19 0x4005910d in _ufc_foobar () from /lib/libcrypt.so.1
#20 0x400592e3 in _ufc_foobar () from /lib/libcrypt.so.1
#21 0x40059476 in _ufc_foobar () from /lib/libcrypt.so.1
#22 0x40059c34 in _ufc_foobar () from /lib/libcrypt.so.1
#23 0x4005a645 in _ufc_foobar () from /lib/libcrypt.so.1
#24 0x80486dd in ?? () from /usr/local/apache/libexec/mod_caucho.so
#25 0x401589cb in __gconv_transform_internal_utf16 (step=0x80486c0, data=0x2,
    inbuf=0xbffffaa4, inbufend=0x8048560 "U\211?S?", written=0x804877c,
    do_flush=1073786464) at ../iconv/loop.c:151

It looks you are having session bug.

It seems you are unset()ing $HTTP_SESSION_VARS or $_SESSION somewhere in your script, aren't you?

Can you please try a shapshot from snaps.php.net, my guess is that this is already fixed.

Derick

Yasuo - nope.  I'm *using* sessions, but the pages that crash it aren't doing any creating, destroying or unsetting.

In any case, I've been running this morning's snapshot all day without any problems.  It seems to have been fixed (the POST problems went away as well).

Thanks.

Tried the new snapshot (4.3.0-dev) and the crash still occurs.

As I work things through I am wondering if it is a problem with sessions hashes being used.

For example I will have $_SESSION['prefs']['page_name1'] set and $_SESSION['prefs']['page_name2'] set and if page_name2 is no longer needed it will unset($_SESSION['prefs']['page_name2']).  Could this be causing the problem in anything newer than PHP4.0.6 ???

RH 7.2 / PHP 4.1.1 & 4.1.2 (tried both).

My one comment that may be useful is that I am only having this problem on pages that include HTML forms and form elements.  If I remove a few form elements from a form it happily renders the page.

I have a few very simple pages that contain very little in the way of PHP but keep getting truncated at certain points.

No segfault and no errors in the log files to correspond to the time of the failure.

There doesn't seem to be a particular pattern or size issue.  I've tried other recommendations in this group but have not been able to get any success.

There seems to be a size issue somewhere of some sort because I stripped a page back a line at a time until it all rendered, and then started adding in extra PHP until it started truncating again.

Please e-mail me if you would like the HTML/PHP pages that contain the HTML forms. In the mean time I heading for PHP 4.0.6...

Further to my previous comment.  I downgraded to 4.0.6 with the last file upload patch and I am still getting the problem.

Which webserver and version do you use?

Derick

i faintly remember issues with the gcc version
RedHat uses (experimental gcc prerelease from
their own labs or something)

there were definetly problems in the past that 
where RedHat-only :(

do you have a chance to test on another linux
distribution or to compile on another one and
transfer the binaries to your RH system?

A question for s.waight@gold.ac.uk :
Did you try it before the patch was applied in 4.0.6

Of the pages giving me grief, some of them have forms and some of them don't.

I don't have the access at my end to try my scripts on a different linux version.

We MAY have seen a similar problem (not using Zend Optimizer, though -- whew!).  We had problems with locutions like

function postprocess($buf)
{
  $buf = preg_replace("/some stuff/","some other stuff",$buf);
  return $buf;
}

ob_start("postprocess");

Changing the postprocess function to

function postprocess($ibuf)
{
  $obuf = preg_replace("/some stuff/","some other stuff",$ibuf);
  return $obuf;
}

seems to have eliminated the problem.

Apologies for not including web server details (did so in another post on another bug). Apache 1.3.20 with PHP as a DSO (no CGI compile).  My local Unix guru has suggested trying a more recent Apache release which I will do when I get chance.

I haven't tried with 4.0.6 pre-file upload and I am loathed to do so as I've now built PHP about a dozen times in the last week or so.

I don't have access to another linux ditro unfortunately although we are running a production environment on Solaris.  I haven't tried anything on that yet due to its production status but can do if it helps.

GCC details (gcc -v)

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)

I found an interesting detail. On my windows box running PHP 4.1.1 and Apache 1.3.23, it only stops on "=" signs.
I had a template that has some "=" signs in it, and by replacing the first accurence, it goes on until the next one.
I'm using output buffering, but it outputs the content anyway. The interesting fact is that it only turncates the output while echoing the buffer.

Sorry, don't mind my previous post. I had a bug in my template system.

I'm experiencing the same problem. Pages sometimes get cut off, always in the same place. I'm having the problem on some of my pages and not all of them. The most annoying occrunce is on a login-page which loads correctly way to seldom and makes it almost impossible to login. The bug wasn't there in 4.0.x but when we upgraded to 4.1.x it is... We haven't been able to go back to 4.0.x to ensure that it isn't apache that messes up but we don't think so.
Example of bug:
www.svenskamagic.com
(the last part of the page shows up corrupted sometimes)
www.svenskamagic.com/club_login.php
(page stops at the same spot all the time and it's hard to login when posting data with the form. An interesting point is that when the page works and you make a faulty login it shows an error-output "Wrong user/pass", but when the page doesn't work upon logging in, it doesn't. It's like it just reloads the page without any form data sent to it.(if the form data would be there it would leave the error mess))
www.svenskamagic.com/phpinfo.php
(info about the server)

Sorry...
About the loginpage in my previous comment: I explained wrong and I think I have an interesting point to notice.
The loginpage sometime crashes in one of two ways:
 It stops loading at the same spot,
 and when posting data to login the script doesn't ignores the header(location call) as if the session i just registered isn't there.

My point is that it seems like the session doensn't register correctly even if it does so half the time and it always did with 4.0.x. Nuf said...

Is it just me or does the output bug show up more often after a session_destory and then a header("location to another page?

When I successfully use my login page it redirects me to a startpage which NEVER shows up wrong. When I logout from this page via a logout link it destoys the session and the redirects me to the login page. The login page NEVER EVER shoes up correctly upon using this "route". If I reload it it shows up nicely.

/Fabbe

Well it looks like I isolated the problem... and it's not PHP related.

The FTP package I've been using has been truncating files that it has been sending to our server for some reason.  I only just discovered this today as it did it to a non-PHP document that I sent (one of only a few).

I've changed to another FTP package and sent the PHP docs I was having trouble with to our server (RH 7.2/Apache 1.3.20/PHP 4.0.6) and they ran OK. I'm not sure whether it was an FTP client or server problem (client more likely, but maybe clients are having problems dumping php files onto a specific FTP server build?)

The FTPD we're running is WU FTPD 2.6.1 - others with this problem might want to check this isn't happening to their too.

My problems are definately not ftp, I run all my scripts first here on my local test server where they are created in the first place.  My scripts ran fine on PHP4.0.6 or older but not properly on any new version since then.

My problem isn't ftp-related either.

Read the whole thread, concluded that I've got the same problems as described by jay1
First we thought that it maybe was an Apacheproblem, so we installed an older version than 1.3.23, namely 1.3.20
This didn't help, same bugs appeared.
Fiddled around with fopen, nothing there.
Read this thread and came to the idea to set session.save_handler to files instead of user (wich setting actually IS necesary, because we loadbalance our site with three mirrored servers). And since then, no problems at all.
My question now is to jay1: how is session.save_handler in your php-config?

Check out bug-report #15940, talking about propably the same problems there

Responding to albert.
My system also needed to have session.save_handler set to user for load balancing.  However, I tried using files instead and at first I thought it worked fine but it turned out it still crashed, only less often and at different points.  (Previously code output always stopped at specific spots when it crashed and only on some pages, this just changed the point at which it would crash and other pages that before had no problems didn't appear correctly.

Some have suggested they removed sessions all together and still had the problem and others claim the problems stop if sessions are not used.  (Maybe there is two completely different bugs causing similar problems).

It seems as if this bug has nothing that anyone has been able to narrow down as what causes the problem.  

Besides apache crashing (Segmentation fault)I have noticed that other small things don't opperate properly since version 4.0.6 that should.  Here are two other things I've seen give problems and confirmed through test scripts.

4.2.x (or 4.3.x) unserialize() does not recognizing values set by serialize() in PHP 4.0.x.  My system stores arrays using the serialize() function into a database (such as a color scheme).  When I upgrade to 4.2.x or new snaps, when those strings are pulled from the database, the unserialize() function will gives an error that it couldn't read the string (this is not a magic_quote issue as settings are the same).

Session variable values getting corrupted:
For example at one point I had a transparent graphic shim.gif used on a page to keep columns widths in line.  That graphic was moved to a new location but a php's script was not updated from <img src="shim.gif> to <img src="/images/shim.gif">.  This meant the HTML that PHP returned to the visitors browser had a simple invalid link in it and the page should load normally with just an empty placeholder where the image shim.gif was to be.  However, even though this did happen it also did mess up session variable values.  A simple test created that had the HTML code with the invalid location for shim.gif in the image tag along with the lines:

echo $HTTP_SERVER_VARS['PHP_SELF'].'<br>';
$HTTP_SESSION_VAR['lastpage']=$HTTP_SERVER_VARS['PHP_SELF'];
echo $HTTP_SERVER_VARS['PHP_SELF'].'<br>';

would output correctly:
pagename.php
pagename.php

BUT the session $HTTP_SESSION_VAR['lastpage'] upon the next page load would be equal to 'shim.gif' and not 'pagename.php' like you'd expect.  So even though $HTTP_SERVER_VARS['PHP_SELF'] returned (and must have set the correct value), setting it into a session changed the value of it.

These problems did not happen in version 4.0.6 or older, so they may have something to do with the bug of shutting down apache but I don't know enough of how PHP is written to really know.


Hope this helps.

http://www.php.net/manual/en/function.session-set-save-handler.php

On this page are a lot of comments, one of them was striking:
<quote>
04-Mar-2002 02:57 
 
I just want to mention, that it's critical to return a string value with
the read function, because there can be strange errors if - for example -
the return value is null. In my case the php program stopped in the middle
of an "echo" command, so it was really hard to find, that the
real problem was with that session read callback function.
The easyest way to handle this, that you should cast the return value
before return. For example:
function read ($id) {
	/*	code here to produce $retval   */
    return (string)$retval;
}
</quote>

Weird, isn't it, but maybe it helps getting more close to solving the problem.

ps: we've got php4.1.2 now installed as a CGI, session.save_handler=files, still using the session_set_save_handler function (although it doesn't say so in the tutorial -explicitly- it does override the 'files'-setting, see one of the other comments) and I don't have any problems anymore. At least, not until now, fingers crossed.

YEAH! IT WORKS! I've solved my problem! It was related to my session_handling and the session_read function. When I forced the function to ALWAYS return a string, even if it was an empty one apache stopped crashing!

return (string)$value;

Previously I sometimes returned other values such as the boolean false. This didn't make apache crash with 4.0.6 but it does with the later versions.

*happy happy happy*

The page works like a charm again! No cut off pages! No messed up posted forms! No more weird sessions that doesn't register! I LOVE IT!

I did the same thing a while back and things appeared to work again.  My screens were not getting cut off on every page load.  But apache still crashed on almost every page viewed.  Somehow, IE was able to display the page (I'm thinking though cache but it caught some of the newer info - but not always) but Netscape, Opera and some linux browsers simply displayed an error that they could not connect and eventually even in IE the pages started getting cut off again.

It's as if apache crashed anyways for me only crashed sooner if the session read function returned false instead of an empty string.

I've cut my program very small and eliminated all include/require statements thinking I'd add them until the problem occured, only as a base program (still fairly complex) the problem still occurs.  Yet I've written some very simple pages and they don't crash.  It's almost like it's a combination of tasks that cause it.

After all, it's a session bug.
I'm sure this is reported, but I couldn't find one.

Ok, so after all that, the summary of this bug is that returning a non-string from the read() function from a custom  session handler causes a problem.  I tried to reproduce this in current CVS by returning either false, null and random integers/floats and could not get a segfault.  Please test a current snapshot and provide a short script that reproduces this.

No feedback was provided for this bug for over a month, 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".

hi there .. can anyone now give a straight answer how to get rid of this bug .. or a really workaround ??

tnx4reply

-c-

What bug?  Like I said, I cannot reproduce it with the current code.  Please verify that it is still happening with a current 4.3 snapshot.

Sorry, I had given up and hadn't tried any newer versions in a while.  Just set up a box with 4.2.3 installed and this was manually compiled with the same options so it would suggest that the bug no longer exists.

Sorry, cut and pasted part of my previous response out by mistake.  It should of said, I installed 4.2.3 and compiled it with same options and tested the same scripts and this time there was no problems.  Thus seeing same compile options were used it appears to be fixed.

well .. so this is PHP Version 4.2.3 .. build from latest freebsd-ports (updated via cvs) .. hope that is what you would call latest ! .. in attach the much saying compile spam. THIS issue occours .. it occours on my station .. and as one could see in dev newsgroups ,also on others .. yes , apache 10327100 is also new from scratch .. but all this doesnt really happen if i put this 'return;' in place ... so : any ideas .. 

 './configure' '--with-apxs=/usr/local/sbin/apxs' '--with-config-file-path=/usr/local/etc' '--enable-versioning' '--with-regex=system' '--without-gd' '--without-mysql' '--with-gd=/usr/local' '--enable-gd-native-ttf' '--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-zlib' '--with-bz2=/usr' '--with-mcrypt=/usr/local' '--with-mhash=/usr/local' '--with-pdflib=/usr/local' '--with-zlib-dir=/usr' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-tiff-dir=/usr/local' '--with-imap=/usr/local' '--with-imap-ssl=/usr/local' '--with-mysql=/usr/local' '--with-dbase' '--with-ldap=/usr/local' '--with-openssl=/usr' '--with-snmp=/usr/local' '--enable-ucd-snmp-hack' '--with-openssl=/usr' '--with-expat-dir=/usr/local' '--with-dom=/usr/local' '--enable-ftp' '--with-curl=/usr/local' '--with-gettext=/usr/local' '--with-iconv=/usr/local' '--with-pspell=/usr/local' '--with-ming=/usr/local' '--with-mcal=/usr/local' '--enable-sockets' '--enable-trans-sid' '--with-gd=/usr/local' '--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-zlib' '--with-bz2=/usr' '--with-mcrypt=/usr/local' '--with-mhash=/usr/local' '--with-imap-ssl=/usr/local' '--with-mysql=/usr/local' '--with-ldap=/usr/local' '--with-openssl=/usr' '--with-expat-dir=/usr/local' '--enable-ftp' '--with-curl=/usr/local' '--with-gettext=/usr/local' '--with-ming=/usr/local' '--with-mcal=/usr/local' '--enable-trans-sid' '--with-imap=/usr/local' '--prefix=/usr/local' 'i386-portbld-freebsd4.5'