As you can see here, I commented out the efree line and instead just set it
to none. This means that PHP is simply freeing it in it's own memory-leak
cleanup. It means the logs gets:
pgsql.c(170) : Freeing 0x085D3AAC (62 bytes),
script=/path/to/index.html
Last leak repeated 7 times
instead of segmentation faulting.
If you efree() something which was not emalloc()'ed nor estrdup()'ed you
will probably get a segmentation fault. That's my understanding of efree()-
I'd say that's probably be what's going on... So by me just NULL'ing
PGG(last_notice) instead of efree'ing it, it means that should it not have
been emalloc'd or estrdup'd then it won't crash miserably... And it's not.
static void
_notice_handler(void *arg, const char *message)
{
PGLS_FETCH();
if (! PGG(ignore_notices)) {
php_log_err((char *) message);
if (PGG(last_notice) != NULL) {
/* efree(PGG(last_notice)); */
PGG(last_notice) = NULL;
}
PGG(last_notice) = estrdup(message);
}
}
So yes- I wish there was a real solution rather than relying on php's
internal cleanup mechanism... But I will happily start from here as a point
to move from... I will send patches once i get the problem completely
fixed- in a better solution than this trial.
--
Mike
----- Original Message -----
From: "Brent R. Matzelle" <bmatzelle@xxxxxxxxx>
To: "Mike Rogers" <temp6453@xxxxxxxxxxx>; <pgsql-php@xxxxxxxxxxxxxx>
Sent: Wednesday, September 26, 2001 5:05 PM
Subject: Re: [PHP] PostgreSQL / PHP Overrun Error
> --- Mike Rogers <temp6453@xxxxxxxxxxx> wrote:
> > I am currently running PHP-4.0.6 (with the memory leak patch
> > as posted to
> > correct a problem in this release [it is on the download
> > page]).
> > The script that causes them mostly "includes" other scripts to
> > do it's job.
> > The home page uses some of the scripts that it uses and I've
> > seen the errors
> > there too. There errors seem infrequent, and just occur
> > randomly... Maybe
> > every 2-10 minutes on a reasonably high-volume server. The
> > commands that
> > seem to be getting executed by the script [it's not my
> > script]:
> > pg_exec
> > pg_errormessage
> > pg_fetch_array
> > pg_errormessage
> > pg_freeresult
> > pg_fieldname
> > pg_fieldtype
> > pg_fieldsize
> > pg_cmdtuples
> > pg_numrows
> > pg_numfields
>
> All of those functions are okay to use except that I would
> commment out the calls to pg_freeresult(). I have seen various
> older bug reports that have noted that this function can be
> troublesome. Plus, PHP frees this memory automatically whether
> you call this function or not. I rarely use this function,
> unless I am making queries that return enormous amounts of data,
> and even then I really do not require it.
>
> Last note, the PHP debug information that you gathered seemed to
> be cleaning up the pg_notice memory if I was not mistaken. I
> would not be surprised if this function was called by
> pg_freeresult.
>
> Brent
>
> __________________________________________________
> Do You Yahoo!?
> Get email alerts & NEW webcam video instant messaging with Yahoo!
Messenger. http://im.yahoo.com
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
