Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77873
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fedoraproject.org from 217.70.183.195 cause and error)
Message-ID: <5438C214.60107@fedoraproject.org>
Date: Sat, 11 Oct 2014 07:37:24 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1
MIME-Version: 1.0
To: PHP Internals <internals@lists.php.net>
References: <54379B40.6020403@fedoraproject.org> <BEA816C6-CF09-4843-8E75-FDA5B81D16E2@ajf.me> <5437CC48.6060806@fedoraproject.org> <54380E49.3060401@sugarcrm.com> <543878D2.1080008@lerdorf.com>
In-Reply-To: <543878D2.1080008@lerdorf.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] GMP memory allocator, various issues
From: remi@fedoraproject.org (Remi Collet)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 11/10/2014 02:24, Rasmus Lerdorf a =C3=A9crit :
> On 10/10/2014 09:50 AM, Stas Malyshev wrote:
>> Hi!
>>=20
>>> Can you please elaborate a little ? Doesn't such leak have to
>>> be fixed in ext/gmp ?
>>=20
>> 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.
>=20
> 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.
>=20
> 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 =3D>
freetds =3D> 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 =3D> mp_get_memory_functions
  - set ours =3D> mp_set_memory_functions
- - end of end function
  - restore allocators =3D> 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.



>=20
> -Rasmus
>=20

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlQ4whQACgkQYUppBSnxahiOPQCgwqFgYYTFp1sTFHyd0zaZuYwg
yqQAoMY3fAghfHjk+OFMabTIyuv1oiGF
=3DvH1h
-----END PGP SIGNATURE-----