Bug 117211 - PHP Crashes when calling pg_lo_create with php-odbc and php-pgsql rpms installed
PHP Crashes when calling pg_lo_create with php-odbc and php-pgsql rpms installed
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: unixODBC (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tom Lane
Depends On:
  Show dependency treegraph
Reported: 2004-03-01 12:34 EST by Joseph Tate
Modified: 2013-07-02 23:00 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-05-12 00:21:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joseph Tate 2004-03-01 12:34:03 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6)
Gecko/20040206 Firefox/0.8

Description of problem:
If php, php-odbc and php-pgsql rpms are installed, and during a
connection to a postgresql database a call is made to pg_lo_create,
the libodbcpgsql.so library is called rather than the libpq.so.  

I'm not sure if this is a PostgreSQL or a RH bug, so I'm reporting it

See the php bug report for more information.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. install php php-odbc and php-pgsql with their dependencies
2. create a file in /tmp/dqj.tmp
3. Run the following php code via php-cli or through httpd:
$res = pg_connect( "host=myhost dbname=mytest user=myuser password=zzz"
pg_exec( $res, "BEGIN" );
$oid = pg_lo_import( $res, "/tmp/dqj.tmp" );
pg_exec( $res, "COMMIT" );
echo "RES: $res, OID: $oid<br/>"; flush();

Actual Results:  Sigv recorded in /var/log/httpd/error_log

Expected Results:  No seg fault, OID created in the database.

Additional info:

Stack Trace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1226627936 (LWP 28034)]
0xb69f7987 in CC_send_function () from /usr/lib/libodbcpsql.so.2
(gdb) where
#0  0xb69f7987 in CC_send_function () from /usr/lib/libodbcpsql.so.2
#1  0xb6a06940 in lo_creat () from /usr/lib/libodbcpsql.so.2
#2  0xb69c6c23 in lo_import () from /usr/lib/libpq.so.3
#3  0xb69e4121 in zif_pg_lo_import (ht=2, return_value=0x8307424,
    this_ptr=0x0, return_value_used=1)
    at /usr/src/debug/php-4.3.2/ext/pgsql/pgsql.c:2099
#4  0xb697a542 in zend_assign_to_variable_reference ()
   from /usr/local/Zend/lib/Optimizer-2.1.0/php-4.3.x/ZendOptimizer.so
#5  0x00000002 in ?? ()
#6  0x08307424 in ?? ()

removing the php-odbc package fixes the crash, but makes ODBC calls
from PHP impossible.

Is this a link error when building PHP?  Or is it a symbol referencing
error when loading the shared libraries?  Both the libpq and
libodbcpgsql libraries have lo_creat and lo_import functions.

Also occurs on RHL 9.
Comment 1 Joe Orton 2004-03-01 15:32:10 EST
Hello, thanks for the report.  I take it this this reproducible when
not using the third-party ZendOptimiser module?

#4  0xb697a542 in zend_assign_to_variable_reference ()
   from /usr/local/Zend/lib/Optimizer-2.1.0/php-4.3.x/ZendOptimizer.so

Comment 2 Joseph Tate 2004-03-01 15:46:50 EST
Absolutely.  It's reproduceable when using php from the commandline too.

Here's the BT without the zend optimizer, and from the command line:
(gdb) bt
#0  0xb6b23987 in CC_send_function () from /usr/lib/libodbcpsql.so.2
#1  0xb6b32940 in lo_creat () from /usr/lib/libodbcpsql.so.2
#2  0xb6af0c23 in lo_import () from /usr/lib/libpq.so.3
#3  0xb6b10121 in zif_pg_lo_import () from /usr/lib/php4/pgsql.so
#4  0x081c0b28 in execute ()
#5  0x081b2486 in zend_execute_scripts ()
#6  0x081870d3 in php_execute_script ()
#7  0x081c6274 in main ()

libodbcpsql should not be invoked at all for this test script.
Comment 3 Joe Orton 2004-03-01 15:50:14 EST
Thanks for confirming that Joseph.

Since lo_creat etc are part of the Postgres API, php-pgsql must use
those symbol names.  unixODBC, on the other hand, is re-implementing
new functions under those names, so needs to be changed to use
different names.
Comment 5 Tom Lane 2004-03-01 17:03:29 EST
Hmm, it seems like a really bad idea to unilaterally rename API
functions.  I wonder why the upstream hasn't heard this complaint?
Comment 6 Joseph Tate 2004-03-01 17:20:13 EST
Here's what I submitted to pgsql-bugs:
Comment 7 Joe Orton 2004-03-01 17:23:53 EST
Changing this in the postgres API is clearly not going to wash.  But
the functions are not part of the API in unixODBC, they are just
internal symbols used in the Postgresql driver; so they can be safely
renamed in unixODBC with impact to the API/ABI.
Comment 8 Joe Orton 2004-03-01 17:25:36 EST
...with *no* impact to the API/ABI, I meant, of course :)
Comment 10 Nick Gorham 2004-03-02 04:46:43 EST
I have created a snapshot 2.2.9 unixODBC with the offending symbols
renamed. Can someone give it a try under these conditions ?

Comment 11 Joe Orton 2004-03-02 05:08:52 EST
Nick, there are a bunch of other symbols which are defined in both
/usr/lib/libodbc.so.1 /usr/lib/libodbcpsql.so.2, it looks like a
static library has been linked into both:

all of the symbols from the ltdl library, check_ini_cache,
file_not_found, all ini* symbols, log* symbols, SQL*
Comment 12 Tom Lane 2004-03-08 14:07:45 EST
I believe that the ltdl conflicts aren't a big issue; presumably the
same ltdl would be linked into both libraries, and anyway if there
were a problem there the upstream would certainly have seen it.

I propose fixing this by updating to 2.2.8 and applying a patch to
rename lo_xxx to odbc_lo_xxx (which is what Nick has done for 2.2.9,
but we can't wait for 2.2.9 to become official).
Comment 13 Joe Orton 2004-03-08 15:02:20 EST
But what if another library gets linked into httpd via a different
module which uses a *different* version of libltdl?  That's why
namespace pollution is a bad thing.  Since a shared version of libltdl
exists on the system everything should dynamically link that rather
than statically link their own copies, it saves space and avoids
Comment 14 Tom Lane 2004-03-08 15:23:33 EST
You have a point.  unixODBC actually ships with an ancient version of
libltdl that doesn't work at all on some RHEL architectures.  As of
the present RPM I'm working around this by blowing away what's in the
source tarball and copying /usr/share/libtool/* in instead.  Evidently
that's not picking up the shared-library version of ltdl though. 
Wonder why not ...
Comment 15 Tom Lane 2004-03-08 16:44:43 EST
I've confirmed that I can build libltdl-less versions of the unixodbc
libraries by replacing AC_LIBLTDL_CONVENIENCE with
AC_LIBLTDL_INSTALLABLE in its configure.in.  It occurs to me however
that this is a packaging change and thus maybe not such a hot idea for
RHEL3: with this revision we'd create a runtime dependency that was
not previously there, and also a new build-time requirement for anyone
who's statically linking libodbc.a (got to say -lltdl too).  Perhaps
we should leave the ltdl change out of the RHEL3 branch.  Joe, what do
you think?

BTW, a comment for Nick: the libtool documentation specifically
discourages using the convenience libltdl in libraries that might get
linked into programs containing other copies of libltdl.  AFAICS this
advice certainly applies to the unixODBC libraries.  So you might
wanna think about making this change upstream too...
Comment 16 Joe Orton 2004-03-09 03:56:17 EST
Yes for RHEL3 leaving in the static libltdl for the time being is
sensible since we've not seen any practical problems from that; but
make the change for the next Fedora Core release so it can get wider

Have you looked at why other symbols are linked into both libodbc and
libodbcpgsql I mentioned in comment 11? Probably another static
convenience library...
Comment 17 Tom Lane 2004-03-09 11:45:11 EST
The impression I got from Nick was that the unixODBC code is
deliberately designed to use the same names for database-independent
functions and the database-dependent functions they call.  The latter
are in dynamically loaded modules that never get linked directly to
client apps.  So it may be okay; at least, if it's not okay it seems
like the upstream's issue to fix.  It would be a much bigger patch
than I care to make.
Comment 18 Tom Lane 2004-03-09 23:03:37 EST
I've pushed unixODBC 2.2.8 with the lo_xxx rename into RHEL3 U2.  I
will make the additional change for libltdl and push that into FC2 in
the next day or so.
Comment 19 John Flanagan 2004-05-12 00:21:19 EDT
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.


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