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 here. See the php bug report for more information. Version-Release number of selected component (if applicable): php-*-4.3.2-8.ent How reproducible: Always 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: <?php $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.
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
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.
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.
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: http://archives.postgresql.org/pgsql-bugs/2003-12/msg00019.php
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 ? ftp://ftp.easysoft.com/pub/unixODBC/unixODBC-2.2.9.tar.gz
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 conflicts.
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 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...
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 testing. Have you looked at why other symbols are linked into both libodbc and libodbcpgsql I mentioned in comment 11? Probably another static convenience library...
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. http://rhn.redhat.com/errata/RHBA-2004-128.html