SOLVED: Multi-threaded Qt app segfaults when using libpq with separate connections

From: Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: SOLVED: Multi-threaded Qt app segfaults when using libpq with separate connections
Date: 2003-08-08 08:46:10
Message-ID: 200308081046.10157.ftm.van.vugt@foxi.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

Hi,

I *finally* nailed this thing, turns out NOT to be a PG problem, more like
PEBKC.

Tom Lane wrote:
> I get the impression that something is clobbering memory with abandon.

He was write (duh..).

What wasn't clear (at least to me) from the Qt-docs is that a name given to a
supplementary database connection must be unique, otherwise the new one will
replace the old one. Expecting to be able to handle the connections by the
pointers an addDatabase() call returned, I had been creating new connections
in separate threads whose names weren't always unique.

Since 'connection' here implicates a PGconn structure, I had been 'switching'
PGconn structures while in use. It seems one can even get away with that for
a limited number of threads, but at a certain point newly created result
structures (PGresult, PQntubles, PQnfields, etc.) will be allocated space on
top of the older structures belonging the replaced connections, which is
obviously the point where things get very messy....

I've asked the Trolls (Qt) to emphasize this potential problem in their docs.

Thanks to Tom Lane (PostgreSQL) and Harald Fernengel (TrollTech) for their
pointers ;)

Best,

Frank van Vugt

In response to

Browse pgsql-interfaces by date

  From Date Subject
Next Message Heinz-Peter Heidinger 2003-08-08 09:40:58 pgSQL, ODBC and SERIAL (autoincrement) ...
Previous Message markw 2003-08-08 00:02:12 Re: libpq ERROR: overflow on numeric ABS(value) ...