Thread: PostgreSQL / PHP Overrun Error
I have just upgraded to the new PostgreSQL 7.1.3 (from 7.0.3) and have been
experiencing a pretty serious problem:
On one particular page, in what seems to be completely random instances,
I get buffer overruns and either 0-rows or a crashed apache child. Turning
on PHP's --enable-debug, I receive the following:
[Wed Sep 26 06:21:12 2001] Script: '/path/to/script.php'
---------------------------------------
pgsql.c(167) : Block 0x086A6DF8 status:
Beginning: Overrun (magic=0x00000000, expected=0x7312F8DC)
End: Unknown
---------------------------------------
Sometimes it will actually crash mid-way (probably overwrote some valuable
code):
---------------------------------------
pgsql.c(167) : Block 0x08684290 status:
Beginning: Overrun (magic=0x0000111A, expected=0x7312F8DC)
[Wed Sep 26 09:22:46 2001] [notice] child pid 8710 exit signal Segmentation
fault (11)
This problem is of great concern to me and I have been working for days
trying to debug it myself and find other reports, with little success. The
line it claims to be failing on is PHP's ext/pgsql/pgsql.c on line 167 (by
what this claims) which is the following function [the
efree(PGG(last_notice)) line].
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) = estrdup(message);
}
}
Can anyone provide further input as to why this is causing problems? The
PHP code works sometimes and not others, and it seems to be only that one
script, so I do not believe it to be a hardware issue.
Any thoughts? I can provide any further system information if needed. I
have tried recompiling pgsql, php and apache with different optimizations
[including none at all and debug mode on as i have now] with little change
in the result.
Thanks in advance;
--
Mike
cc: pgsql-hackers; pgsql-php; pgsql_bugs
"Mike Rogers" <temp6453@hotmail.com> writes:
> This problem is of great concern to me and I have been working for days
> trying to debug it myself and find other reports, with little success. The
> line it claims to be failing on is PHP's ext/pgsql/pgsql.c on line 167 (by
> what this claims) which is the following function [the
> efree(PGG(last_notice)) line].
This isn't our code, so you'd likely have better luck complaining on
some PHP-related list. But it looks to me like this code is simply
trying to free any previous notice message before it stores the new
one into PGG(last_notice) (whatever the heck that is). I'm guessing
that that pointer is uninitialized or has been clobbered somehow.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
Well it really isn't your code (true), but the only thing that is changed is the 7.0-7.1- Was a data length changed on the return or something that could affect this? -- Mike ----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> To: "Mike Rogers" <temp6453@hotmail.com> Cc: <pgsql-hackers@postgresql.org>; <pgsql-php@postgresql.org>; <pgsql-bugs@postgresql.org> Sent: Wednesday, September 26, 2001 1:23 PM Subject: Re: [BUGS] PostgreSQL / PHP Overrun Error > "Mike Rogers" <temp6453@hotmail.com> writes: > > This problem is of great concern to me and I have been working for days > > trying to debug it myself and find other reports, with little success. The > > line it claims to be failing on is PHP's ext/pgsql/pgsql.c on line 167 (by > > what this claims) which is the following function [the > > efree(PGG(last_notice)) line]. > > This isn't our code, so you'd likely have better luck complaining on > some PHP-related list. But it looks to me like this code is simply > trying to free any previous notice message before it stores the new > one into PGG(last_notice) (whatever the heck that is). I'm guessing > that that pointer is uninitialized or has been clobbered somehow. > > regards, tom lane >
--- Mike Rogers <temp6453@hotmail.com> wrote: > Well it really isn't your code (true), but the only thing that > is changed is > the 7.0-7.1- Was a data length changed on the return or > something that > could affect this? I believe that it is unlikely that the problem is with Postgres. I have been running PostgreSQL 7.1.3 with PHP 4.0.4pl1 for months now with no problems. I believe this bug was introduced in PHP 4.0.6. Brent __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com
Mike Rogers wrote: > Well it really isn't your code (true), but the only thing that is changed is > the 7.0-7.1- Was a data length changed on the return or something that > could affect this? What version of PHP are you using? ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
--- Mike Rogers <temp6453@hotmail.com> wrote: > Can anyone provide further input as to why this is causing > problems? The > PHP code works sometimes and not others, and it seems to be > only that one > script, so I do not believe it to be a hardware issue. > > Any thoughts? I can provide any further system information if > needed. I > have tried recompiling pgsql, php and apache with different > optimizations > [including none at all and debug mode on as i have now] with > little change > in the result. I performed a search on http://bugs.php.net/ but I did not find your problem. If it persists then I would suggest submitting a new bug report. PHP 4.0.6 is the first version of PHP to have the pg_last_notice() function which apparently the problem is tied in with. Is that the version that you are running? What PHP pg_* commands are you using on this PHP script that you are not using on other pages? Brent __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com
Sorry:
PHP 4.0.6 (with memory leak patch [download listed right below
php-4.0.6.tar.gz download- It was a problem])
PostgreSQL 7.1.3
Apache 1.3.20 (with mod_ssl- but it does the same thing without mod_ssl)
--
Mike
----- Original Message -----
From: "mlw" <markw@mohawksoft.com>
To: "Mike Rogers" <temp6453@hotmail.com>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>; <pgsql-hackers@postgresql.org>;
<pgsql-php@postgresql.org>; <pgsql-bugs@postgresql.org>
Sent: Wednesday, September 26, 2001 1:55 PM
Subject: Re: [BUGS] PostgreSQL / PHP Overrun Error
> Mike Rogers wrote:
>
> > Well it really isn't your code (true), but the only thing that is
changed is
> > the 7.0-7.1- Was a data length changed on the return or something that
> > could affect this?
>
> What version of PHP are you using?
>
>
>
Interesting. I am using that same configuration. We are using the same thing on
our website as well. I have never seen this problem. Weird.
My guess is that you are getting an error. The PHP code is some how mucking
this up. But I would try executing the query in psql and see what comes up.
The PHP code than handles the error may have a fixed langth buffer for speed,
and it is to short for a longer 7.1 error message. Again, I am guessing.
My bet is that the query is failing with an error, so you really have two
problems. A problem in your SQL which is causing you to see a bug in PHP.
Mike Rogers wrote:
> Sorry:
> PHP 4.0.6 (with memory leak patch [download listed right below
> php-4.0.6.tar.gz download- It was a problem])
> PostgreSQL 7.1.3
> Apache 1.3.20 (with mod_ssl- but it does the same thing without mod_ssl)
> --
> Mike
>
> ----- Original Message -----
> From: "mlw" <markw@mohawksoft.com>
> To: "Mike Rogers" <temp6453@hotmail.com>
> Cc: "Tom Lane" <tgl@sss.pgh.pa.us>; <pgsql-hackers@postgresql.org>;
> <pgsql-php@postgresql.org>; <pgsql-bugs@postgresql.org>
> Sent: Wednesday, September 26, 2001 1:55 PM
> Subject: Re: [BUGS] PostgreSQL / PHP Overrun Error
>
> > Mike Rogers wrote:
> >
> > > Well it really isn't your code (true), but the only thing that is
> changed is
> > > the 7.0-7.1- Was a data length changed on the return or something that
> > > could affect this?
> >
> > What version of PHP are you using?
> >
> >
> >
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
--- Mike Rogers <temp6453@hotmail.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
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
I have been trying minor modifications to the code to ensure that there are
no minor erorrs (such as setting things to null in case functions don't) but
am trying to track it down further.
I truly wish there was a way to get a status report from the script as
it goes [see what line it stopped on]- Unfortunatly, I don't think that's
really possible.
Thanks;
--
Mike
----- Original Message -----
From: "Brent R. Matzelle" <bmatzelle@yahoo.com>
To: <pgsql-php@postgresql.org>
Sent: Wednesday, September 26, 2001 1:55 PM
Subject: Re: [PHP] PostgreSQL / PHP Overrun Error
> --- Mike Rogers <temp6453@hotmail.com> wrote:
> > Can anyone provide further input as to why this is causing
> > problems? The
> > PHP code works sometimes and not others, and it seems to be
> > only that one
> > script, so I do not believe it to be a hardware issue.
> >
> > Any thoughts? I can provide any further system information if
> > needed. I
> > have tried recompiling pgsql, php and apache with different
> > optimizations
> > [including none at all and debug mode on as i have now] with
> > little change
> > in the result.
>
> I performed a search on http://bugs.php.net/ but I did not find
> your problem. If it persists then I would suggest submitting a
> new bug report.
>
> PHP 4.0.6 is the first version of PHP to have the
> pg_last_notice() function which apparently the problem is tied
> in with. Is that the version that you are running? What PHP
> pg_* commands are you using on this PHP script that you are not
> using on other pages?
>
> Brent
>
> __________________________________________________
> Do You Yahoo!?
> Get email alerts & NEW webcam video instant messaging with Yahoo!
Messenger. http://im.yahoo.com
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
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@yahoo.com>
To: "Mike Rogers" <temp6453@hotmail.com>; <pgsql-php@postgresql.org>
Sent: Wednesday, September 26, 2001 5:05 PM
Subject: Re: [PHP] PostgreSQL / PHP Overrun Error
> --- Mike Rogers <temp6453@hotmail.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
>
Have you recompiled PHP to link against the new postgres libraries? Chris > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Mike Rogers > Sent: Thursday, 27 September 2001 1:07 AM > To: mlw > Cc: pgsql-hackers@postgresql.org; pgsql-php@postgresql.org; > pgsql-bugs@postgresql.org > Subject: Re: [HACKERS] [BUGS] PostgreSQL / PHP Overrun Error > > > Sorry: > PHP 4.0.6 (with memory leak patch [download listed right below > php-4.0.6.tar.gz download- It was a problem]) > PostgreSQL 7.1.3 > Apache 1.3.20 (with mod_ssl- but it does the same thing > without mod_ssl) > -- > Mike > > ----- Original Message ----- > From: "mlw" <markw@mohawksoft.com> > To: "Mike Rogers" <temp6453@hotmail.com> > Cc: "Tom Lane" <tgl@sss.pgh.pa.us>; <pgsql-hackers@postgresql.org>; > <pgsql-php@postgresql.org>; <pgsql-bugs@postgresql.org> > Sent: Wednesday, September 26, 2001 1:55 PM > Subject: Re: [BUGS] PostgreSQL / PHP Overrun Error > > > > Mike Rogers wrote: > > > > > Well it really isn't your code (true), but the only thing that is > changed is > > > the 7.0-7.1- Was a data length changed on the return or > something that > > > could affect this? > > > > What version of PHP are you using? > > > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
There is a problem in PHP-4.0.6. Please use PHP4.0.7 or 4.0.8 and the problem will be solved. This can be obtained from CVS -- Mike ----- Original Message ----- From: "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> To: "Mike Rogers" <temp6453@hotmail.com>; "mlw" <markw@mohawksoft.com> Cc: <pgsql-hackers@postgresql.org>; <pgsql-php@postgresql.org>; <pgsql-bugs@postgresql.org> Sent: Wednesday, September 26, 2001 10:31 PM Subject: RE: [HACKERS] [BUGS] PostgreSQL / PHP Overrun Error > Have you recompiled PHP to link against the new postgres libraries? > > Chris > > > -----Original Message----- > > From: pgsql-hackers-owner@postgresql.org > > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Mike Rogers > > Sent: Thursday, 27 September 2001 1:07 AM > > To: mlw > > Cc: pgsql-hackers@postgresql.org; pgsql-php@postgresql.org; > > pgsql-bugs@postgresql.org > > Subject: Re: [HACKERS] [BUGS] PostgreSQL / PHP Overrun Error > > > > > > Sorry: > > PHP 4.0.6 (with memory leak patch [download listed right below > > php-4.0.6.tar.gz download- It was a problem]) > > PostgreSQL 7.1.3 > > Apache 1.3.20 (with mod_ssl- but it does the same thing > > without mod_ssl) > > -- > > Mike > > > > ----- Original Message ----- > > From: "mlw" <markw@mohawksoft.com> > > To: "Mike Rogers" <temp6453@hotmail.com> > > Cc: "Tom Lane" <tgl@sss.pgh.pa.us>; <pgsql-hackers@postgresql.org>; > > <pgsql-php@postgresql.org>; <pgsql-bugs@postgresql.org> > > Sent: Wednesday, September 26, 2001 1:55 PM > > Subject: Re: [BUGS] PostgreSQL / PHP Overrun Error > > > > > > > Mike Rogers wrote: > > > > > > > Well it really isn't your code (true), but the only thing that is > > changed is > > > > the 7.0-7.1- Was a data length changed on the return or > > something that > > > > could affect this? > > > > > > What version of PHP are you using? > > > > > > > > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 4: Don't 'kill -9' the postmaster > > > >
On Mié 26 Sep 2001 22:51, Mike Rogers wrote:
> There is a problem in PHP-4.0.6. Please use PHP4.0.7 or 4.0.8 and the
> problem will be solved. This can be obtained from CVS
Sorry, but 4.0.6 is the last version out (there may be some RC of 4.0.7), but
how can we get those, and how much can we trust a RC version?
Saludos... :-)
--
Porqué usar una base de datos relacional cualquiera,
si podés usar PostgreSQL?
-----------------------------------------------------------------
Martín Marqués | mmarques@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica
Universidad Nacional
del Litoral
-----------------------------------------------------------------
I'm using the current CVS (4.0.8-dev)- It's spectacular. Lower memory
usage, more descriptive debug, better control over it. Tons more options,
smaller code, much much faster.
Can you trust it- sure. It isn't a release candidate. It is the
current development version. As they find problems, they get fixed. As
long as you keep a bit on top you are fine. If anything it is _MORE_ secure
than the current version, as any security problems were fixed earlier as
soon as they get found, and new bugs aren't known yet. I'm seriously
impressed with it and feel like I will be using the CVS code quite a bit
more. Any bugs Zend memory manager cleans up anyway.
Note: if you are not having the problem of 0 rows or buffer overruns,
don't bother upgrading as it will not benefit you. Clearly I was and the
new code fixed the flaws in the existing code for my usage.
--
Mike
----- Original Message -----
From: "Martín Marqués" <martin@bugs.unl.edu.ar>
To: "Mike Rogers" <temp6453@hotmail.com>
Cc: <pgsql-hackers@postgresql.org>; <pgsql-php@postgresql.org>
Sent: Thursday, September 27, 2001 5:55 PM
Subject: Re: [PHP] [HACKERS] [BUGS] PostgreSQL / PHP Overrun Error
> On Mié 26 Sep 2001 22:51, Mike Rogers wrote:
> > There is a problem in PHP-4.0.6. Please use PHP4.0.7 or 4.0.8 and the
> > problem will be solved. This can be obtained from CVS
>
> Sorry, but 4.0.6 is the last version out (there may be some RC of 4.0.7),
but
> how can we get those, and how much can we trust a RC version?
>
> Saludos... :-)
>
> --
> Porqué usar una base de datos relacional cualquiera,
> si podés usar PostgreSQL?
> -----------------------------------------------------------------
> Martín Marqués | mmarques@unl.edu.ar
> Programador, Administrador, DBA | Centro de Telematica
> Universidad Nacional
> del Litoral
> -----------------------------------------------------------------
>
> I'm using the current CVS (4.0.8-dev)- It's spectacular. Lower memory > usage, more descriptive debug, better control over it. Tons more options, > smaller code, much much faster. > > Can you trust it- sure. It isn't a release candidate. It is the > current development version. As they find problems, they get fixed. As > long as you keep a bit on top you are fine. If anything it is _MORE_ secure > than the current version, as any security problems were fixed earlier as > soon as they get found, and new bugs aren't known yet. I'm seriously > impressed with it and feel like I will be using the CVS code quite a bit > more. Any bugs Zend memory manager cleans up anyway. > > Note: if you are not having the problem of 0 rows or buffer overruns, > don't bother upgrading as it will not benefit you. Clearly I was and the > new code fixed the flaws in the existing code for my usage. Keep in mind we can change the on-disk structure or system tasbles anytime so you may have trouble moving between different CVS versions. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Fri, Sep 28, 2001 at 03:50:12PM -0400, Bruce Momjian wrote: > > I'm using the current CVS (4.0.8-dev)- It's spectacular. Lower memory > > usage, more descriptive debug, better control over it. Tons more options, > > smaller code, much much faster. <snip> > > Note: if you are not having the problem of 0 rows or buffer overruns, > > don't bother upgrading as it will not benefit you. Clearly I was and the > > new code fixed the flaws in the existing code for my usage. > > Keep in mind we can change the on-disk structure or system tasbles > anytime so you may have trouble moving between different CVS versions. Also note that Bruce is talking about using PostgreSQL CVS version, rather than the PHP CVS version (as one can tell from the version number 4.0.8) that everyone else is discussing. ;-) Ross
--- "Ross J. Reedstrom" <reedstrm@rice.edu> wrote: > On Fri, Sep 28, 2001 at 03:50:12PM -0400, Bruce Momjian wrote: > > > I'm using the current CVS (4.0.8-dev)- It's spectacular. > Lower memory > > > usage, more descriptive debug, better control over it. > Tons more options, > > > smaller code, much much faster. > <snip> > > > Note: if you are not having the problem of 0 rows or > buffer overruns, > > > don't bother upgrading as it will not benefit you. > Clearly I was and the > > > new code fixed the flaws in the existing code for my > usage. > > > > Keep in mind we can change the on-disk structure or system > tasbles > > anytime so you may have trouble moving between different CVS > versions. > > Also note that Bruce is talking about using PostgreSQL CVS > version, rather > than the PHP CVS version (as one can tell from the version > number 4.0.8) > that everyone else is discussing. ;-) I just tried to access the CVS version but the CVS web and CVS pages for PostgreSQL are missing: http://www.postgresql.org/cgi/cvsweb.cgi/pgsql and http://www.postgresql.org/devel-corner/docs/postgres/cvs.html How can I get this new version? Has this new code been submitted to the PHP guys yet? Have any of you been successful in building a pgsql PHP extension (pgsql.so)? I have not been able to locate the document that describes how to compile one. Thanks. Brent __________________________________________________ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com
It is not the CVS version of Postgres ((*shudders* The actual release version is buggy enough)). The CVS version of PHP http://www.php.net/cvsup.php -- Mike ----- Original Message ----- From: "Brent R. Matzelle" <bmatzelle@yahoo.com> To: <pgsql-php@postgresql.org> Sent: Monday, October 01, 2001 2:46 PM Subject: Re: [PHP] [HACKERS] [BUGS] PostgreSQL / PHP Overrun Error > > --- "Ross J. Reedstrom" <reedstrm@rice.edu> wrote: > > On Fri, Sep 28, 2001 at 03:50:12PM -0400, Bruce Momjian wrote: > > > > I'm using the current CVS (4.0.8-dev)- It's spectacular. > > Lower memory > > > > usage, more descriptive debug, better control over it. > > Tons more options, > > > > smaller code, much much faster. > > <snip> > > > > Note: if you are not having the problem of 0 rows or > > buffer overruns, > > > > don't bother upgrading as it will not benefit you. > > Clearly I was and the > > > > new code fixed the flaws in the existing code for my > > usage. > > > > > > Keep in mind we can change the on-disk structure or system > > tasbles > > > anytime so you may have trouble moving between different CVS > > versions. > > > > Also note that Bruce is talking about using PostgreSQL CVS > > version, rather > > than the PHP CVS version (as one can tell from the version > > number 4.0.8) > > that everyone else is discussing. ;-) > > I just tried to access the CVS version but the CVS web and CVS > pages for PostgreSQL are missing: > > http://www.postgresql.org/cgi/cvsweb.cgi/pgsql and > http://www.postgresql.org/devel-corner/docs/postgres/cvs.html > > How can I get this new version? Has this new code been > submitted to the PHP guys yet? > > Have any of you been successful in building a pgsql PHP > extension (pgsql.so)? I have not been able to locate the > document that describes how to compile one. > > Thanks. > > Brent > > __________________________________________________ > Do You Yahoo!? > Listen to your Yahoo! Mail messages from any phone. > http://phone.yahoo.com > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
Oh come on now, let's not start that kind of thread-- they don't serve any purpose but to piss people off :-) Have a good one.. -Mitch > It is not the CVS version of Postgres ((*shudders* The actual release > version is buggy enough)). The CVS version of PHP > > http://www.php.net/cvsup.php > > -- > Mike
--- Mike Rogers <temp6453@hotmail.com> wrote: > It is not the CVS version of Postgres ((*shudders* The actual > release > version is buggy enough)). The CVS version of PHP > > http://www.php.net/cvsup.php My mistake, that last message made it seem like PG had their own branch of PHP. Regardless, has anyone compiled the pgsql extension? I do not want to build PG support directly into PHP. Brent __________________________________________________ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com
On Lun 01 Oct 2001 17:39, you wrote: > --- Mike Rogers <temp6453@hotmail.com> wrote: > > It is not the CVS version of Postgres ((*shudders* The actual > > release > > version is buggy enough)). The CVS version of PHP > > > > http://www.php.net/cvsup.php > > My mistake, that last message made it seem like PG had their own > branch of PHP. Regardless, has anyone compiled the pgsql > extension? I do not want to build PG support directly into PHP. In all my compilations, I used the extensions. What do yoy mean by "build PG support directly into PHP"? Saludos... :-) -- Porqué usar una base de datos relacional cualquiera, si podés usar PostgreSQL? ----------------------------------------------------------------- Martín Marqués | mmarques@unl.edu.ar Programador, Administrador, DBA | Centro de Telematica Universidad Nacional del Litoral ----------------------------------------------------------------- ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
--- Mart�n Marqu�s <martin@bugs.unl.edu.ar> wrote: > On Lun 01 Oct 2001 17:39, you wrote: > > --- Mike Rogers <temp6453@hotmail.com> wrote: > > > It is not the CVS version of Postgres ((*shudders* The > actual > > > release > > > version is buggy enough)). The CVS version of PHP > > > > > > http://www.php.net/cvsup.php > > > > My mistake, that last message made it seem like PG had their > own > > branch of PHP. Regardless, has anyone compiled the pgsql > > extension? I do not want to build PG support directly into > PHP. > > In all my compilations, I used the extensions. What do yoy > mean by "build PG > support directly into PHP"? I use the php-4.0.4pl1 and php-pgsql RPMs from RedHat. I just want to re-build the php-pgsql extension (/usr/lib/php4/pgsql.so) for php-4.0.4pl1 rather than with php-4.0.6. I do not want to re-compile PHP --with-pgsql. Brent __________________________________________________ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com
Mike Rogers wrote: > Well it really isn't your code (true), but the only thing that is changed is > the 7.0-7.1- Was a data length changed on the return or something that > could affect this? What version of PHP are you using? ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
"Mike Rogers" <temp6453@hotmail.com> writes:
> This problem is of great concern to me and I have been working for days
> trying to debug it myself and find other reports, with little success. The
> line it claims to be failing on is PHP's ext/pgsql/pgsql.c on line 167 (by
> what this claims) which is the following function [the
> efree(PGG(last_notice)) line].
This isn't our code, so you'd likely have better luck complaining on
some PHP-related list. But it looks to me like this code is simply
trying to free any previous notice message before it stores the new
one into PGG(last_notice) (whatever the heck that is). I'm guessing
that that pointer is uninitialized or has been clobbered somehow.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
Interesting. I am using that same configuration. We are using the same thing on
our website as well. I have never seen this problem. Weird.
My guess is that you are getting an error. The PHP code is some how mucking
this up. But I would try executing the query in psql and see what comes up.
The PHP code than handles the error may have a fixed langth buffer for speed,
and it is to short for a longer 7.1 error message. Again, I am guessing.
My bet is that the query is failing with an error, so you really have two
problems. A problem in your SQL which is causing you to see a bug in PHP.
Mike Rogers wrote:
> Sorry:
> PHP 4.0.6 (with memory leak patch [download listed right below
> php-4.0.6.tar.gz download- It was a problem])
> PostgreSQL 7.1.3
> Apache 1.3.20 (with mod_ssl- but it does the same thing without mod_ssl)
> --
> Mike
>
> ----- Original Message -----
> From: "mlw" <markw@mohawksoft.com>
> To: "Mike Rogers" <temp6453@hotmail.com>
> Cc: "Tom Lane" <tgl@sss.pgh.pa.us>; <pgsql-hackers@postgresql.org>;
> <pgsql-php@postgresql.org>; <pgsql-bugs@postgresql.org>
> Sent: Wednesday, September 26, 2001 1:55 PM
> Subject: Re: [BUGS] PostgreSQL / PHP Overrun Error
>
> > Mike Rogers wrote:
> >
> > > Well it really isn't your code (true), but the only thing that is
> changed is
> > > the 7.0-7.1- Was a data length changed on the return or something that
> > > could affect this?
> >
> > What version of PHP are you using?
> >
> >
> >
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
On Lun 01 Oct 2001 17:39, you wrote: > --- Mike Rogers <temp6453@hotmail.com> wrote: > > It is not the CVS version of Postgres ((*shudders* The actual > > release > > version is buggy enough)). The CVS version of PHP > > > > http://www.php.net/cvsup.php > > My mistake, that last message made it seem like PG had their own > branch of PHP. Regardless, has anyone compiled the pgsql > extension? I do not want to build PG support directly into PHP. In all my compilations, I used the extensions. What do yoy mean by "build PG support directly into PHP"? Saludos... :-) -- Porqué usar una base de datos relacional cualquiera, si podés usar PostgreSQL? ----------------------------------------------------------------- Martín Marqués | mmarques@unl.edu.ar Programador, Administrador, DBA | Centro de Telematica Universidad Nacional del Litoral ----------------------------------------------------------------- ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
This is a known problem with PHP 4.0.6. You might want to upgrade to 4.1.0RC2, or try patches made by one of the PHP developers: ftp://ftp.sra.co.jp/pub/cmd/postgres/php/php-4.0.6-patches.tar.gz > Mike Rogers wrote: > > > Sorry: > > PHP 4.0.6 (with memory leak patch [download listed right below > > php-4.0.6.tar.gz download- It was a problem]) > > PostgreSQL 7.1.3 > > Apache 1.3.20 (with mod_ssl- but it does the same thing without mod_ssl) > > -- > > Mike > > > > ----- Original Message ----- > > From: "mlw" <markw@mohawksoft.com> > > To: "Mike Rogers" <temp6453@hotmail.com> > > Cc: "Tom Lane" <tgl@sss.pgh.pa.us>; <pgsql-hackers@postgresql.org>; > > <pgsql-php@postgresql.org>; <pgsql-bugs@postgresql.org> > > Sent: Wednesday, September 26, 2001 1:55 PM > > Subject: Re: [BUGS] PostgreSQL / PHP Overrun Error > > > > > Mike Rogers wrote: > > > > > > > Well it really isn't your code (true), but the only thing that is > > changed is > > > > the 7.0-7.1- Was a data length changed on the return or something that > > > > could affect this? > > > > > > What version of PHP are you using? > > > > > > > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html >
Why did it just send out tons of mail since September of this year- every message? -- Mike
someone, either intentially or accidentally, sent out a load to the lists ... On Fri, 16 Nov 2001, Mike Rogers wrote: > Why did it just send out tons of mail since September of this year- every > message? > -- > Mike > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
if you look at the originating time for all of the messages that got sent out of when it was sent from the host machine (with HELO host). Clearly it was done on an admin side. -- Mike ----- Original Message ----- From: "Marc G. Fournier" <scrappy@hub.org> To: "Mike Rogers" <temp6453@hotmail.com> Cc: <pgsql-hackers@postgresql.org>; <pgsql-php@postgresql.org>; <pgsql-bugs@postgresql.org> Sent: Friday, November 16, 2001 3:26 PM Subject: Re: [BUGS] [HACKERS] [PG MAIL LISTS] SEND OUT ALL???? > > someone, either intentially or accidentally, sent out a load to the lists > ... > > > On Fri, 16 Nov 2001, Mike Rogers wrote: > > > Why did it just send out tons of mail since September of this year- every > > message? > > -- > > Mike > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 4: Don't 'kill -9' the postmaster > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org >