Re: PostgreSQL / PHP Overrun Error

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
>

In response to

Browse pgsql-bugs by date

  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

Browse pgsql-hackers by date

  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

Browse pgsql-php by date

  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