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
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) ... |