I use gdb and attach to the connection, then let it run and look at the
backtrace.
1) build postres with the --enable-debug option
2) gdb /usr/local/pgsql/bin/postgres
3) in another window start your java process and halt it after it makes
the connection
4) attach to that connection's process
5) continue in gdb
6) continue in java process
7) when it dumps look at the backtrace
--dc--
On Tue, 2003-12-02 at 20:57, Marcus Andree S. Magalhaes wrote:
> Could a sniffing program help to clarify this issue?
> I mean, by capturing data right from the tcp/ip stack,
> maybe it would be possible to identify what caused the
> server back end to crash, even if there wasn't anything
> sent to log files or syslog.
>
>
>
> > On Tue, Dec 02, 2003 at 01:57:37PM -0500, Ethan Perry wrote:
> >> I'm using a user-defined function that refers to a shared library that
> >> I've built out of a third party C++ application.
> >>
> >> The function returns a string of values and works fine in the psql
> >> command line environment. When I call this function over JDBC,
> >> however, the string of values sometimes has garbage characters
> >> interspersed in: for instance, "???B???B??????)??????)???g)Affect
> >> 1.85" instead of just "Affect 1.85"
> >>
> >> After these characters are in the resulting string from the ResultSet
> >> multiple times, the postgreqsql server eventually sometimes goes down,
> >> and JDBC reports the following error:
> >>
> >> The backend has broken the connection. Possibly the action you have
> >> attempted has caused it to close. Exception in updateMsg msgId9106The
> >> backend has broken the connection. Possibly the action you have
> >> attempted has caused it to close.
> >> at org.postgresql.PG_Stream.ReceiveChar(PG_Stream.java:143)
> >> at org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:68)
> >> at org.postgresql.Connection.ExecSQL(Connection.java:398)
> >> at org.postgresql.jdbc2.Statement.execute(Statement.java:130)
> >> at org.postgresql.jdbc2.Statement.executeQuery(Statement.java:54) at
> >> anthroViz.model.MessageReader.updateMsg(MessageReader.java:72)
> >>
> >> Any suggestions on what to look for that could be causing this would
> >> be very appreciated.
> >
> > It seems unlikely this is a problem with the JDBC driver. I'd point the
> > finger at the shared library code -- the postmaster should not go down
> > as a result of a normal query from a client. Have you investigated the
> > cause of the backend crashes (examining coredumps etc)? What is logged
> > by the postmaster when it goes down?
> >
> > -O
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 7: don't forget to increase your free space map settings
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>
>
