Bug 203330 - Postgresql threads fails with 'Segmentation fault' or 'Aborted'
Postgresql threads fails with 'Segmentation fault' or 'Aborted'
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: postgresql (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Lane
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2006-08-21 05:00 EDT by Jose Plans
Modified: 2013-07-02 23:10 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-01-10 22:02:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test_case (3.30 KB, text/x-csrc)
2006-08-21 05:00 EDT, Jose Plans
no flags Details
sql (4.52 KB, application/octet-stream)
2006-08-21 05:01 EDT, Jose Plans
no flags Details

  None (edit)
Description Jose Plans 2006-08-21 05:00:49 EDT
Description of problem:
The usage of a threaded client against rhel4 postgresql server (respecting the
advises from upstream) makes the client fail with either :
  - double-free
  - segmentation fault
However, using postgresql (8.1.3 from Fedora Core 5) solves the problem.
The problem comes from libpq/kerberos. If we remove kerberos from the build
process, the problem disappears.

# rpmbuild --rebuild --define='kerberos 0' postgresql-7.4.6-1.RHEL4.2.src.rpm

The trace received from the test case wrote for this case :
(gdb) bt
#0  0x0019a3fb in krb5_cc_close () from /usr/lib/libkrb5.so.3
#1  0x00a7e84a in pg_krb5_init (
   PQerrormsg=0xb07d0fa0 "pg_krb5_init: krb5_cc_get_principal: No credentials
cache found\n") at fe-auth.c:329
#2  0x00a7f0be in fe_getauthname (
   PQerrormsg=0xb07d0fa0 "pg_krb5_init: krb5_cc_get_principal: No credentials
cache found\n") at fe-auth.c:348
#3  0x00a81388 in conninfo_parse (conninfo=0xa8f3e3 "PGUSER",
   errorMessage=0x843c728) at fe-connect.c:2724
#4  0x00a81487 in connectOptions1 (conn=0x843c428, conninfo=0x0)
   at fe-connect.c:328
#5  0x00a82035 in PQsetdbLogin (pghost=0x0, pgport=0x0, pgoptions=0x0,
   pgtty=0x0, dbName=0x8048e3f "mttest", login=0x8048e3e "", pwd=0x8048e3e "")
   at fe-connect.c:541
#6  0x0804883f in testThread (n=16) at sample2.c:17
#7  0x00b47371 in start_thread () from /lib/tls/libpthread.so.0
#8  0x009d79be in clone () from /lib/tls/libc.so.6

Version-Release number of selected component (if applicable):
  postgresql-7.4.6-1.RHEL4.2 and the customer also tested (without success)

How reproducible:

Steps to Reproduce:
1. create a database test
   % createdb test
   % psql test
   # \i sql     (provided)
2. compile the test case showing the problem
   % gcc -g -o test_case test_case.c -lpq -lpthread

3. Execute the test case.
   % ./test_case 100
Actual results:
double-free or segmentation fault.

Expected results:
clean queries as in Fedora Core 5 or upstream postgresql.

Additional info:
We respected for the test_case to be sure we would have a thread-safe code :
Comment 1 Jose Plans 2006-08-21 05:00:49 EDT
Created attachment 134553 [details]
Comment 2 Jose Plans 2006-08-21 05:01:58 EDT
Created attachment 134554 [details]
Comment 4 Tom Lane 2006-08-21 09:17:20 EDT
The Kerberos (and also SSL) features of libpq are known not thread-safe in PG 7.* releases --- in the 
case of Kerberos, it's actually the Kerberos code itself that isn't thread safe, according to
This was repaired in PG 8.0 but I doubt that back-porting the changes would be a sane thing to do; 
there was an awful lot of interrelated stuff that changed in libpq around that time.  My recommendation 
is to use 8.0 or 8.1 libpq if multithread use of Kerberos connections is required.

I believe that the Kerberos-specific code is only invoked during connection establishment, so a possible 
workaround is to make the application code interlock database connection starts so that only one 
happens at a time.  (This would not help for SSL of course.)

My inclination is to close this bug as NEXTRELEASE, since the newer libpq will be available in RHEL5.
I don't think it's very practical to try to patch 7.4 libpq for it.
Comment 8 Tom Lane 2007-01-10 22:02:39 EST
Closing as NEXTRELEASE: newer libpq is available in RHEL4 Stacks product, and will be in RHEL5.

Note You need to log in before you can comment on or make changes to this bug.