Bug #63595 [Opn]: GMP memory management conflicts with other libraries using GMP
| From: | rasmus@php.net | Date: | Fri, 10 Oct 2014 23:43:26 +0000 |
| Subject: | Bug #63595 [Opn]: GMP memory management conflicts with other libraries using GMP | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-188014@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=63595&edit=1
ID: 63595
Updated by: rasmus@php.net
Reported by: arekm at maven dot pl
Summary: GMP memory management conflicts with other libraries
using GMP
Status: Open
Type: Bug
Package: GNU MP related
PHP Version: 5.3.19
Block user comment: N
Private report: N
New Comment:
ext/gmp calls mp_set_memory_functions() in the MINIT hook so it should be fine for any PHP
extensions that might use it. I don't see how a curl ssl call from PHP would end up having a
problem. However, I can see the cases Remi mentioned where non-php things like mod_gnutls gets in
the mix. Might have to set it back in RSHUTDOWN, but I would hate having to do that. Anything in the
per-request hooks end up getting called on every request regardless of whether anything used
anything from gmp on that request.
The other option would be to yank it from MINIT and do it for every gmp operation/object.
Previous Comments:
------------------------------------------------------------------------
[2014-10-10 08:39:10] remi@php.net
Another backtrace (php + odbc + freetds)
(gdb) bt
#0 0x0000555555798a78 in _zend_mm_free_int ()
#1 0x00007fffe6ace02a in mp_clear_multi () from /lib64/libgnutls.so.28
#2 0x00007fffe6acf64a in ecc_del_point () from /lib64/libgnutls.so.28
#3 0x00007fffe6acec9a in ecc_wmnaf_cache_free () from /lib64/libgnutls.so.28
#4 0x00007fffe6a382c1 in gnutls_global_deinit () from /lib64/libgnutls.so.28
#5 0x00007ffff7debb7a in _dl_fini () from /lib64/ld-linux-x86-64.so.2
#6 0x00007ffff472be59 in __run_exit_handlers () from /lib64/libc.so.6
#7 0x00007ffff472bea5 in exit () from /lib64/libc.so.6
#8 0x0000555555619ffa in main ()
------------------------------------------------------------------------
[2014-10-10 08:30:30] remi@php.net
Some other cases:
Apache HTTP + mod_php + mod_gnutls => segfaults
PHP + odbc + freetds (use gnutls) => segfaults
------------------------------------------------------------------------
[2012-11-24 10:15:29] arekm at maven dot pl
Description:
------------
php gmp module uses:
mp_set_memory_functions(gmp_emalloc, gmp_erealloc, gmp_efree);
to switch to Zend memory management functions.
The problem is that there are other modules that use gmp. One is php-curl in
case when curl uses gnutls for SSL connections (gnutls >= 3.1.1).
gnutls also uses gmp.
The problem happens when curl first uses gmp, gmp allocates some things (using
generic memory management functions) and then php-gmp module changes memory
management functions to own (Zend) one.
Then memory allocated by generic functions is going to be reallocated/freed
using Zend functions which causes segfault.
Probably the solution would be to immediately set
mp_set_memory_functions
to Zend functions, before any other module has a chance to initialize gmp.
More:
http://lists.gnu.org/archive/html/help-gnutls/2012-11/msg00050.html
http://lists.gnu.org/archive/html/help-gnutls/2012-11/msg00049.html
Test script:
---------------
- build php with curl and gmp
- libcurl library needs to be built with gnutls >= 3.1.1
- run php cli
- press ctrl+D
=> result = segfault
Expected result:
----------------
No segfault.
Actual result:
--------------
Segfault.
Program received signal SIGSEGV, Segmentation fault.
0x00007fffea23ef20 in ?? ()
(gdb) bt
#0 0x00007fffea23ef20 in ?? ()
#1 0x00007fffeb445d3b in mp_clear_multi (address@hidden) at multi.c:38
#2 0x00007fffeb4472ca in ecc_del_point (p=0xc63ed0) at ecc_points.c:62
#3 0x00007fffeb446972 in _ecc_wmnaf_cache_entry_free (p=<optimized out>) at
ecc_mulmod_cached.c:54
#4 ecc_wmnaf_cache_free () at ecc_mulmod_cached.c:68
#5 0x00007fffeb445685 in gnutls_crypto_deinit () at init.c:44
#6 0x00007fffeb3adb71 in gnutls_global_deinit () at gnutls_global.c:305
#7 0x00007fffee0c9a79 in Curl_gtls_cleanup () at gtls.c:182
#8 0x00007fffee0ca189 in Curl_ssl_cleanup () at sslgen.c:193
#9 0x00007fffee0bbbf5 in curl_global_cleanup () at easy.c:325
#10 0x00007fffee6f9bf8 in zm_shutdown_curl () from /usr/lib64/php/curl.so
#11 0x00007ffff7a96105 in module_destructor () from
/usr/lib64/libphp_common-5.3.18.so
#12 0x00007ffff7a9b4ae in ?? () from /usr/lib64/libphp_common-5.3.18.so
#13 0x00007ffff7a9cd08 in zend_hash_graceful_reverse_destroy () from
/usr/lib64/libphp_common-5.3.18.so
#14 0x00007ffff7a8f175 in zend_shutdown () from
/usr/lib64/libphp_common-5.3.18.so
#15 0x00007ffff7a3e01b in php_module_shutdown () from
/usr/lib64/libphp_common-5.3.18.so
#16 0x0000000000403406 in main ()
(gdb)
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=63595&edit=1