#40926 [Opn->Asn]: shared pgsql and curl extensions cause segfault

ID: 40926 Updated by: tony2001@php.net Reported By: seanius at debian dot org -Status: Open +Status: Assigned Bug Type: PostgreSQL related Operating System: Debian GNU/Linux PHP Version: 5.2.1 -Assigned To: +Assigned To: yohgaki New Comment: Assigned to the maintainer. See also bug #36152. Previous Comments: ------------------------------------------------------------------------ [2007-03-26 21:42:29] seanius at debian dot org Description: ------------ note that this might not be a bug in php, but php is certainly affected by it so it's worth at least a bogus entry in your db so other people can google their way to it. if you compile curl and pgsql as shared extensions and then load them in the same order from php.ini, any script that establishes a postgres connection will result in a segfault before the script quits. the problem seems to be that the postgresql libpq library registers a callback function (pq_lockingcallback) for openssl-related locking. around exit time, when php unloads the various extensions, if any modules reference openssl routines in their shutdown methods that indirectly call openssl locking routines, the ssl library will try and call the callback function, which now points at invalid memory since the libpq library has already been dlclose()'d somewhere. if it's been closed directly by php (you guys would know better than me) then i'd say it's a php bug, but if it's closed indirectly by some pq shutdown routine, then you're just innocent victims. anyway, there's a pretty simple workaround for the time being. if you reverse the module loading so order so that pgsql is loaded first (and thus unloaded last by the current php engine), then the callback function never references invalid memory and no segfault happens. btw this was reported a couple times in the debian bts, most of the information can be found at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411982 (this is for 5.2.0, but i've verified it against the latest 5.2.1 as well) also, i found #36152 in your bts after writing this up, but it seems that was marked closed in 2006. i think the suggestion in there about overriding libpq's callbacks with your own would probably be the most appropriate if possible. Reproduce code: --------------- <?php // curl.so is loaded before pgsql.so in php.ini $conn_string = "host=localhost dbname=data user=user password=pword"; $dbconn = pg_connect($conn_string); $query = "SELECT count(1) FROM table"; $result = pg_query($dbconn, $query); pg_close($dbconn); ?> Expected result: ---------------- either a successfull connection or error messages about failed connection Actual result: -------------- the expected errors/success, followed by a segfault: copelandia[~]23:30:08$ php foo.php Warning: pg_connect(): Unable to connect to PostgreSQL server: FATAL: password authentication failed for user "user" in /home/seanius/foo.php on line 6 Warning: pg_query(): supplied argument is not a valid PostgreSQL link resource in /home/seanius/foo.php on line 8 Warning: pg_close(): supplied argument is not a valid PostgreSQL link resource in /home/seanius/foo.php on line 9 zsh: segmentation fault php foo.php (gdb) bt #0 0x00002b71ee8889a0 in ?? () #1 0x00002b71edf446df in int_err_del () at err.c:353 #2 0x00002b71ee4e9ef9 in Curl_ossl_cleanup () at ../../../lib/ssluse.c:580 #3 0x00002b71ee4f93e2 in Curl_ssl_cleanup () at ../../../lib/sslgen.c:185 #4 0x00002b71ee4f2233 in curl_global_cleanup () at ../../../lib/easy.c:294 #5 0x00002b71ee3a3699 in zm_shutdown_curl (type=9, module_number=1) at /tmp/buildd/php5-5.2.0/ext/curl/interface.c:668 ... where 0x00002b71ee8889a0 was formerly the address of the above mentioned locking callback function ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=40926&edit=1