ID: 36152
User updated by: misiek at dione dot ids dot pl
-Summary: problems with curl+ssl and pgsql+ssl in same PHP
Reported By: misiek at dione dot ids dot pl
Status: Assigned
Bug Type: cURL related
Operating System: *
PHP Version: 5CVS, 4CVS (2006-01-25) (snap)
Assigned To: mike
New Comment:
This is how I see it. It's not problem in curl module. It's problem
with callback handling in entire php. openssl allows only single
callback function for entire application. curl and pgsql are just two
things that happen to trigger the problem.
Now curl tries to initialize openssl and then to setup own callbacks.
pgsql via libpq does the same thing. It again initializes already
initialized openssl and setupts own callbacks again.
Every next module which uses openssl callbacks will be problematic
unless initialization and callback handling will be done in upper layer
(php itself) once for all modules. Maybe other solution (like
initializing only once in first module) would also work...
Previous Comments:
------------------------------------------------------------------------
[2006-01-25 10:55:59] [EMAIL PROTECTED]
Mike. this is related to your patch for #33760.
Please take a look.
------------------------------------------------------------------------
[2006-01-25 10:55:49] [EMAIL PROTECTED]
See also bug #33760
------------------------------------------------------------------------
[2006-01-25 10:42:49] misiek at dione dot ids dot pl
This also happens in php4.4.2.
openssl uses globals to store callbacks data which makes things
complicated. libpq and curl allow to manage ssl lockig in application
code (see PQregisterThreadLock() and PQinitSSL() for libpq) so doing
ssl lock management in one place for all modules sounds like possible
solution.
------------------------------------------------------------------------
[2006-01-25 10:28:17] misiek at dione dot ids dot pl
[EMAIL PROTECTED] 16112]# gdb --args /tmp/qq/bin/php config.php
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i686-pld-linux"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".
(gdb) b CRYPTO_set_locking_callback
Function "CRYPTO_set_locking_callback" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (CRYPTO_set_locking_callback) pending.
(gdb) b int_err_del
Function "int_err_del" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (int_err_del) pending.
(gdb) r
Starting program: /tmp/qq/bin/php config.php
Breakpoint 3 at 0xb78ee736: file cryptlib.c, line 349.
Pending breakpoint "CRYPTO_set_locking_callback" resolved
Breakpoint 4 at 0xb795341a: file err.c, line 354.
Pending breakpoint "int_err_del" resolved
Breakpoint 3, CRYPTO_set_locking_callback (func=0xb7728428
<pq_lockingcallback>) at cryptlib.c:349
349 locking_callback=func;
(gdb) print func
$1 = (void (*)(int, int, const char *, int)) 0xb7728428
<pq_lockingcallback>
(gdb) c
Continuing.
X-Powered-By: PHP/5.1.3-dev
Content-type: text/html
Breakpoint 4, int_err_del () at err.c:354
354 CRYPTO_w_lock(CRYPTO_LOCK_ERR);
(gdb) s
CRYPTO_lock (mode=9, type=1, file=0xb79bf3ad "err.c", line=354) at
cryptlib.c:414
414 if (type < 0)
(gdb) n
429 if (locking_callback != NULL)
(gdb) print locking_callback
$2 = (void (*)(int, int, const char *, int)) 0xb7728428.
(gdb) print *locking_callback
Cannot access memory at address 0xb7728428
(gdb)
this trace shows that pq_lockingcallback() was lost somewhere and code
issued from curl tries to use it (callback from pgsql).
Maybe openssl initialization and deinitialization should be somehow
made once for all php modules that use openssl instead of doing per
module init?
------------------------------------------------------------------------
[2006-01-25 10:21:24] misiek at dione dot ids dot pl
Now I'm testing php with ZTS disabled and it still segfaults, seems
that's unrelated to thread safety.
(gdb) r
Starting program: /tmp/qq/bin/php config.php
X-Powered-By: PHP/5.1.3-dev
Content-type: text/html
Program received signal SIGSEGV, Segmentation fault.
0xb766b428 in ?? ()
(gdb) bt
#0 0xb766b428 in ?? ()
#1 0xb783187e in CRYPTO_lock (mode=9, type=1, file=0xb79023ad "err.c",
line=354) at cryptlib.c:430
#2 0xb7896440 in int_err_del () at err.c:354
#3 0xb7896deb in ERR_free_strings () at err.c:651
#4 0xb79a9e43 in Curl_ossl_cleanup () at ssluse.c:569
#5 0xb79bc570 in Curl_ssl_cleanup () at sslgen.c:185
#6 0xb79b45a9 in curl_global_cleanup () at easy.c:269
#7 0xb7ef7efb in zm_shutdown_curl (type=1, module_number=21)
at /home/users/arekm/php5.1-200601242130/ext/curl/interface.c:491
#8 0x0822f160 in module_destructor (module=0x8396d40) at
/home/users/arekm/php5.1-200601242130/Zend/zend_API.c:1757
#9 0x08232b98 in zend_hash_apply_deleter (ht=0x8363c20, p=0x8396d10)
at /home/users/arekm/php5.1-200601242130/Zend/zend_hash.c:574
#10 0x08232c3c in zend_hash_graceful_reverse_destroy (ht=0x8363c20)
at /home/users/arekm/php5.1-200601242130/Zend/zend_hash.c:640
#11 0x0822a61e in zend_shutdown () at
/home/users/arekm/php5.1-200601242130/Zend/zend.c:720
#12 0x081f26cf in php_module_shutdown () at
/home/users/arekm/php5.1-200601242130/main/main.c:1604
#13 0x0828f732 in main (argc=2, argv=0xbfc153a4) at
/home/users/arekm/php5.1-200601242130/sapi/cgi/cgi_main.c:1661
(gdb) frame 1
#1 0xb783187e in CRYPTO_lock (mode=9, type=1, file=0xb79023ad "err.c",
line=354) at cryptlib.c:430
430 locking_callback(mode,type,file,line);
(gdb) print locking_callback
$1 = (void (*)(int, int, const char *, int)) 0xb766b428
(gdb) print *locking_callback
Cannot access memory at address 0xb766b428
(gdb)
something bad happens with callback function pointer (I guess it's
callback set by libpg.so library)
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/36152
--
Edit this bug report at http://bugs.php.net/?id=36152&edit=1
