Bug #63595 [Opn]: GMP memory management conflicts with other libraries using GMP

From: 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

« previous php.bugs (#188014) next »