libpq++ tracing considered harmful (was Re: libpq++ memory problems)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
Cc: Tim Brookes <tim(dot)brookes(at)mcmail(dot)com>, pgsql-interfaces(at)postgresql(dot)org
Subject: libpq++ tracing considered harmful (was Re: libpq++ memory problems)
Date: 2000-04-20 17:41:32
Message-ID: 8163.956252492@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

Ah-hah, figured it out. There *was* a recent relevant change, but the
log message for it didn't say anything about leaks. The problem is
in the "debug" code for PgConnection, which in 6.5.* looks like:

// PgConnection::connect
// establish a connection to a backend
ConnStatusType PgConnection::Connect(const char* conninfo)
{
ConnStatusType cst;
// Turn the trace on
#if defined(DEBUG)
FILE *debug = fopen("/tmp/trace.out","w");
PQtrace(pgConn, debug);
#endif

// Connect to the database
pgConn = PQconnectdb(conninfo);

This is busted in at least five ways:

1. "DEBUG" is a symbol defined in the backend header files (it's a
severity level constant for elog()). So although libpq++'s Makefile
thinks it can turn the code on or off via -DDEBUG, it's mistaken;
that debug-tracing code always gets compiled.
Oliver Elphick fixed that a month or so ago by changing the
controlling symbol to "DEBUGFILE". So that's why you see the leak
in 6.5.3 and I don't see it in current sources.

2. The fopen'd file is never closed. (The destructor calls PQuntrace
but that routine isn't responsible for closing the file.) That's
the direct cause of the memory and file descriptor leak you see:
a stdio file is fopen'd and never fclose'd for each PgConnection
created.

3. The whole thing is a complete waste of time because the pgConn
object doesn't exist yet --- it's not created till the next line!
So PQtrace is being handed either a null pgConn pointer (which I
believe it will silently ignore) or a garbage pointer (which could
have who-knows-what unpleasant consequences). But in no case will
any tracing actually occur. Sheesh.

4. If any tracing did occur, all of the output from (perhaps many)
different PgConnection objects in different program runs would all
get dumped into the same temp file, leaving it of doubtful use to
anybody.

5. One could reasonably doubt that it's a good idea to have a compiled-in
option to dump the entire trace of a program's interaction with the
backend into a publicly readable temp file. Can you say "security
hole"? Seems to me that this function should require a specific
request from the application, not be something that could accidentally
get installed as the default behavior of a system library. (Think
what would happen if RPMs containing such behavior got distributed...)

Perhaps something can be salvaged from the wreckage, but for now the
right answer is just to make sure that this code is not compiled.

regards, tom lane

In response to

Responses

Browse pgsql-interfaces by date

  From Date Subject
Next Message Lamar Owen 2000-04-20 18:06:19 Re: libpq++ tracing considered harmful (was Re: libpq++ memory problems)
Previous Message Ken J. Wright 2000-04-20 16:20:08 Re: Inserting NULL with pgaccess