Re: PQtrace doesn't work
От | Bruce Momjian |
---|---|
Тема | Re: PQtrace doesn't work |
Дата | |
Msg-id | 200509231731.j8NHVl510904@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: PQtrace doesn't work ("Daniel Verite" <daniel@manitou-mail.org>) |
Ответы |
Re: PQtrace doesn't work
Re: PQtrace doesn't work |
Список | pgsql-general |
Daniel Verite wrote: > Bruce Momjian wrote: > > > 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. > > 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
В списке pgsql-general по дате отправления: