From: | "Mike Rogers" <temp6453(at)hotmail(dot)com> |
---|---|
To: | "Brent R(dot) Matzelle" <bmatzelle(at)yahoo(dot)com>, <pgsql-php(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL / PHP Overrun Error |
Date: | 2001-09-26 20:42:45 |
Message-ID: | OE58mXL3zF6GEe6zLuy00002aed@hotmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers pgsql-php |
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(at)yahoo(dot)com>
To: "Mike Rogers" <temp6453(at)hotmail(dot)com>; <pgsql-php(at)postgresql(dot)org>
Sent: Wednesday, September 26, 2001 5:05 PM
Subject: Re: [PHP] PostgreSQL / PHP Overrun Error
> --- Mike Rogers <temp6453(at)hotmail(dot)com> 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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-09-26 21:10:29 | Re: Clustering error with present CVS |
Previous Message | Bruce Momjian | 2001-09-26 20:08:08 | Re: Bug #467: Can't insert a value of 0 (zero) into a Bytea |
From | Date | Subject | |
---|---|---|---|
Next Message | mlw | 2001-09-26 20:43:02 | Re: Spinlock performance improvement proposal |
Previous Message | Vince Vielhaber | 2001-09-26 20:30:52 | casting for dates |
From | Date | Subject | |
---|---|---|---|
Next Message | roypgsqlphp | 2001-09-26 22:09:43 | max length of varchar returned from a function |
Previous Message | Brent R. Matzelle | 2001-09-26 20:05:10 | Re: PostgreSQL / PHP Overrun Error |