Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:19449
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <002801c5ca9f$917e9510$ad6c0646@lighthammer>
To: "\"Ron Korving\"" <r.korving@xit.nl>
Cc: <internals@lists.php.net>
References: <E2.19.54476.1A5E4434@pb1.pair.com>
Date: Thu, 6 Oct 2005 10:57:43 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: CLI in PHP6
From: pollita@php.net ("Sara Golemon")

> There was once (can't remember when exactly, so it must be a long time 
> ago)
> here on PHP CLI scripts in which it came forward that one should not rely 
> on
> such a script to run forever. And it's true; the scripts sometimes 
> magically
> and suddenly die. Now I have no clue where this instability (for lack of a
> better word) comes from, but could it be possible for this to be resolved
> for PHP6 so that PHP becomes an extremely viable solution for CLI daemon
> scripts?
>
The short answer is that PHP plays a little "fast-and-loose" with the data 
it tracks because it has no idea what you plan on doing with that data.  In 
*theory* allocated resources get cleaned up within a request the minute they 
no longer have any possible relevance (i.e. A database connection is created 
within a function, then that function leaves making the variable it was 
placed in no longer accessible from anywhere).

In 99% of the engine/core/exts this happens seemlessly, however there *may* 
be (and most likely is) a lingering leak somewhere because a file descriptor 
wasn't closed, or a couple bytes of memory wern't freed.   In a "normal" 
webserver environment these resources get forcibly cleaned up by the 
end-of-request garbage collection process so they don't get noticed by the 
bulk of PHP users out there.  In a long-running daemon process this GC phase 
never triggers and those piccune leaks pile up.

Things you can do to help locate these issues:

#1) Compile PHP with --enable-debug and run a version of your daemon 
designed to kill itself off after a short period (how long may vary: a 
minute, an hour, a day, a week.... try different periods).   At the end of 
execution, Zend will report what memory was leaked by the request and where 
it was allocated.  Though often the allocation was done by the engine but 
the free was the responsibility of an ext, so this is only partially useful.

#2) Do the same as #1, but run the process through valgrind enabling 
reporting of memory leaks and unclosed file descriptors and other debug 
data.  This is much more verbose output, but it helps track down the origin 
of such leaks more precisely and efficiently.

#3) Report back what you find.  The best way to do this is to post (A) Your 
code, (B) Output from #1, and (C) Ouput from #2 on a webserver somewhere and 
provide links to those pages in a message to php.internals.   At that point, 
someone here will either:
(I) identify the problem and just fix it,
(II) Ask for more information,
(III) Provide some insight but ask that you reformat the problem into a bug 
report,
(IV) Shrug and say "I dunno", and/or ignore it

-Sara