PostgreSQL Discussion - PQtrace doesn't work

Author

PQtrace doesn't work

W. van den Akker

2005-09-12, 8:24 pm

Hello,

I've send this message also on 29-1-2004 and have since no solution for
this problem .. >:o .
I have a little test program (see at the end of the message).
The program crashes when PQTrace is called (instruction xxxx referenced
memory at "0x00000010", the
memory could not be written" (obvious ... ). I use the library
libpqdll.lib and postgresql v8.0.1, but also happens
in 7.4.9.
Running under W2000 sp4, VC++ 6 SP5. If compiling under Linux then there
is no problem. Obvious there is
something wrong with the use under windows

If I comment traceoption all works fine.

Any ideas?

gr,

Willem.

#include <stdio.h>
#include <stdlib.h>
#include <libpq-fe.h>
#include <winsock.h>

void main ()
{
int nFields;
int i, j;

PGconn *conn;
PGresult *res;

char *pghost = "linux";
char *dbName = "some_db";

FILE *debug;

WSADATA wsadata;
WSAStartup(0x0101, &wsadata);

conn = PQsetdbLogin (pghost, NULL, NULL, NULL, dbName, "user","");

if (PQstatus(conn) == CONNECTION_BAD)
{
printf ("Connection to database %s is failed\n", dbName);
printf ("%s", PQerrorMessage (conn));
PQfinish (conn);
exit (1);
}

debug = fopen ("trace.out", "w");
--->> PQtrace (conn, debug);

res = PQexec (conn, "BEGIN");
if (!res || PQresultStatus (res) != PGRES_COMMAND_OK)
{
printf ("BEGIN command failed\n");
PQclear (res);
PQfinish (conn);
exit (1);
}

PQclear (res);

res = PQexec (conn, "DECLARE mycursor CURSOR FOR select sum(id) from
relaties");
if (!res || PQresultStatus (res) != PGRES_COMMAND_OK)
{
printf ("DECLARE CURSOR command failed\n");
PQclear (res);
PQfinish (conn);
exit (1);
}

PQclear (res);
res = PQexec (conn, "FETCH ALL in mycursor");
if (!res || PQresultStatus (res) != PGRES_TUPLES_OK)
{
printf ("FETCH ALL command didn't return tuples properly\n");
PQclear (res);
PQfinish (conn);
exit (1);
}

nFields = PQnfields (res);
for (i = 0; i < nFields; i++)
printf ("%-15s", PQfname (res, i));

printf ("\n\n");

for (i = 0; i < PQntuples (res); i++)
{
for (j = 0; j < nFields; j++)
printf ("%-15s", PQgetvalue (res, i, j));
printf ("\n");
}

PQclear (res);

res = PQexec (conn, "CLOSE mycursor");
PQclear (res);

res = PQexec (conn, "COMMIT");
PQclear (res);
PQfinish (conn);

fclose (debug);

WSACleanup();
}

---------------------------(end of broadcast)---------------------------
TIP 1: 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

Bruce Momjian

2005-09-23, 3:23 am

W. van den Akker wrote:
> Hello,
>
> I've send this message also on 29-1-2004 and have since no solution for
> this problem .. >:o .
> I have a little test program (see at the end of the message).
> The program crashes when PQTrace is called (instruction xxxx referenced
> memory at "0x00000010", the
> memory could not be written" (obvious ... ). I use the library
> libpqdll.lib and postgresql v8.0.1, but also happens
> in 7.4.9.
> Running under W2000 sp4, VC++ 6 SP5. If compiling under Linux then there
> is no problem. Obvious there is
> something wrong with the use under windows
>
> If I comment traceoption all works fine.

Looking at the code, the only thing I see done by PQtrace are some calls
to fprintf to that file descriptor, like this:

fe-misc.c: fprintf(conn->Pfdebug, libpq_gettext("To backend> Msg %c\n"),

Hard to imagine what would fail there, unless libpq_gettext() doesn't
work, but you are probably not use NLS, so it would be a noop:

#define libpq_gettext(x) (x)

Can you send us a backtrace of the failure from VC++? We don't have too
many internals guys using that setup, but the backtrace should suggest a
cause.

---------------------------------------------------------------------------

>
> Any ideas?
>
> gr,
>
> Willem.
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <libpq-fe.h>
> #include <winsock.h>
>
> void main ()
> {
> int nFields;
> int i, j;
>
> PGconn *conn;
> PGresult *res;
>
> char *pghost = "linux";
> char *dbName = "some_db";
>
> FILE *debug;
>
> WSADATA wsadata;
> WSAStartup(0x0101, &wsadata);
>
>
> conn = PQsetdbLogin (pghost, NULL, NULL, NULL, dbName, "user","");
>
> if (PQstatus(conn) == CONNECTION_BAD)
> {
> printf ("Connection to database %s is failed\n", dbName);
> printf ("%s", PQerrorMessage (conn));
> PQfinish (conn);
> exit (1);
> }
>
> debug = fopen ("trace.out", "w");
> --->> PQtrace (conn, debug);
>
> res = PQexec (conn, "BEGIN");
> if (!res || PQresultStatus (res) != PGRES_COMMAND_OK)
> {
> printf ("BEGIN command failed\n");
> PQclear (res);
> PQfinish (conn);
> exit (1);
> }
>
> PQclear (res);
>
> res = PQexec (conn, "DECLARE mycursor CURSOR FOR select sum(id) from
> relaties");
> if (!res || PQresultStatus (res) != PGRES_COMMAND_OK)
> {
> printf ("DECLARE CURSOR command failed\n");
> PQclear (res);
> PQfinish (conn);
> exit (1);
> }
>
> PQclear (res);
> res = PQexec (conn, "FETCH ALL in mycursor");
> if (!res || PQresultStatus (res) != PGRES_TUPLES_OK)
> {
> printf ("FETCH ALL command didn't return tuples properly\n");
> PQclear (res);
> PQfinish (conn);
> exit (1);
> }
>
> nFields = PQnfields (res);
> for (i = 0; i < nFields; i++)
> printf ("%-15s", PQfname (res, i));
>
> printf ("\n\n");
>
> for (i = 0; i < PQntuples (res); i++)
> {
> for (j = 0; j < nFields; j++)
> printf ("%-15s", PQgetvalue (res, i, j));
> printf ("\n");
> }
>
> PQclear (res);
>
> res = PQexec (conn, "CLOSE mycursor");
> PQclear (res);
>
> res = PQexec (conn, "COMMIT");
> PQclear (res);
> PQfinish (conn);
>
> fclose (debug);
>
> WSACleanup();
> }
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: 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
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Bruce Momjian

2005-09-23, 1:23 pm

Daniel Verite wrote:
> Bruce Momjian wrote:
>
>
> Having a similar setup, I've tried enabling PQtrace and it also crashes
> for me, apparently as soon as libpq tries to write into the stream.
>
> In the hope of debugging at the point of the fprintf call,
> I've built a libpq.lib to link with, as opposed to libpqdll.lib,
> but the statically-linked version doesn't crash, it works as
> expected.
>
> So it looks like the problem would be DLL-related?

Is there a problem with a DLL writing to a file descriptor opened by
application code? I would think not, but perhaps.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Tom Lane

2005-09-23, 1:23 pm

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Daniel Verite wrote:
[color=darkred]
> Is there a problem with a DLL writing to a file descriptor opened by
> application code? I would think not, but perhaps.

Hmm .... malloc/free are broken in exactly that way in Windows DLLs,
maybe stdio has the same kind of issue? I'd think this would be pretty
well known if true, though.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: 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

Bruce Momjian

2005-09-25, 3:23 am

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>
>
> Hmm .... malloc/free are broken in exactly that way in Windows DLLs,
> maybe stdio has the same kind of issue? I'd think this would be pretty
> well known if true, though.

Ah, I have found the cause of the crash, and added documentation about
the cause:

On Win32, if the <application>libpq</> and the application are
compiled with different flags, this function call will crash the
application because the internal representation of the <literal>FILE</>
pointers differ.

While such a mismatch is a problem on all platforms, it is more common
on Win32 where the FILE structure changes for debug, for example.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Daniel Verite

2005-09-25, 8:23 pm

Bruce Momjian wrote:

> Is there a problem with a DLL writing to a file descriptor opened by
> application code? I would think not, but perhaps.

After some more testing, I've found out that it works only if the
application code uses the shared version of the C library
(msvcrt.dll)
That means compiling with the /MD or /MDd options, or in
the GUI, selecting in the project settings,
C/C++ -> Code Generation -> Use runtime library -> Multithread DLL
(or Debug Multithreaded DLL)
That's apparently not the default when creating a new application
with Visual Studio.

libpq.dll must also having been compiled with /MD as well, but
that should be the case unless the OP changed that himself
in libpq/win32.mak

--
Daniel
PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Bruce Momjian

2005-09-25, 8:23 pm

Daniel Verite wrote:
> Bruce Momjian wrote:
>
>
> After some more testing, I've found out that it works only if the
> application code uses the shared version of the C library
> (msvcrt.dll)
> That means compiling with the /MD or /MDd options, or in
> the GUI, selecting in the project settings,
> C/C++ -> Code Generation -> Use runtime library -> Multithread DLL
> (or Debug Multithreaded DLL)
> That's apparently not the default when creating a new application
> with Visual Studio.
>
> libpq.dll must also having been compiled with /MD as well, but
> that should be the case unless the OP changed that himself
> in libpq/win32.mak

Yep, library version mismatch --- now documented.

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Sponsored Links