SOLVED: Multi-threaded Qt app segfaults when using libpq with separate connections - Mailing list pgsql-interfaces

From Frank van Vugt
Subject SOLVED: Multi-threaded Qt app segfaults when using libpq with separate connections
Date
Msg-id 200308081046.10157.ftm.van.vugt@foxi.nl
Whole thread Raw
In response to Re: Multi-threaded user app segfaults when using libpq with separate connections  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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




pgsql-interfaces by date:

Previous
From: markw@osdl.org
Date:
Subject: Re: libpq ERROR: overflow on numeric ABS(value) ...
Next
From: Heinz-Peter Heidinger
Date:
Subject: pgSQL, ODBC and SERIAL (autoincrement) ...