Red Hat Bugzilla – Bug 117211
PHP Crashes when calling pg_lo_create with php-odbc and php-pgsql rpms installed
Last modified: 2013-07-02 23:00:27 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6)
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):
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.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1226627936 (LWP 28034)]
0xb69f7987 in CC_send_function () from /usr/lib/libodbcpsql.so.2
#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,
#4 0xb697a542 in zend_assign_to_variable_reference ()
#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.
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 ()
Absolutely. It's reproduceable when using php from the commandline too.
Here's the BT without the zend optimizer, and from the command line:
#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.
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
Hmm, it seems like a really bad idea to unilaterally rename API
functions. I wonder why the upstream hasn't heard this complaint?
Here's what I submitted to pgsql-bugs:
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.
...with *no* impact to the API/ABI, I meant, of course :)
I have created a snapshot 2.2.9 unixODBC with the offending symbols
renamed. Can someone give it a try under these conditions ?
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*
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).
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
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 ...
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
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...
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
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.
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.
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.