Re: GMP memory allocator, various issues
| From: | Remi Collet | Date: | Sat, 11 Oct 2014 05:37:24 +0000 |
| Subject: | Re: GMP memory allocator, various issues | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-77873@lists.php.net to get a copy of this message | ||
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 11/10/2014 02:24, Rasmus Lerdorf a écrit :
> On 10/10/2014 09:50 AM, Stas Malyshev wrote:
>> Hi!
>>
>>> Can you please elaborate a little ? Doesn't such leak have to
>>> be fixed in ext/gmp ?
>>
>> We clean up the memory at the end of the request. But if the
>> request ended abnormally and we had some active gmp objects, with
>> gmp data allocated outside emalloc we could not clean that and it
>> ends up being persistent memory leak. Also, of course, that also
>> excepts gmp objects from PHP memory limit, which makes it less
>> useful.
>
> At the same time we can't just switch libgmp to our allocator in
> MINIT since it gets called by other libraries outside of a PHP
> request as Remi pointed out via Apache's mod_gnutls. And also from
> within a PHP request but indirectly via freetds+gnutls where
> freetds has no idea we have switched the allocator on them.
>
> We need to make it more granular. gmp_init() should set it and set
> a flag and then in RSHUTDOWN we can check that flag and restore
> the default allocator to take care of the outside-request access,
> and for inside-request access like the freetds extension, we
> probably need to explicitly set it back to the default handler in
> that extension in each call that might call it. Huge PITA to catch
> all those cases though.
We cannot, as we are not always aware of it (in case of odbc =>
freetds => gnutls)
I think the only place we are aware of the need of our allocator is in
our gmp extension, which means
- - beginning of each gmp* function
- save current allocators => mp_get_memory_functions
- set ours => mp_set_memory_functions
- - end of end function
- restore allocators => mp_set_memory_functions
Yes, and probably lower perfs (but perhaps not significantly)
I will try to create a patch, for test, as we really need to fix this
problem, especially it gmp going to go into core (bigint patch).
Remi.
>
> -Rasmus
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlQ4whQACgkQYUppBSnxahiOPQCgwqFgYYTFp1sTFHyd0zaZuYwg
yqQAoMY3fAghfHjk+OFMabTIyuv1oiGF
=vH1h
-----END PGP SIGNATURE-----