Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:77870 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 10366 invoked from network); 11 Oct 2014 00:24:57 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Oct 2014 00:24:57 -0000 Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.216.170 cause and error) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 209.85.216.170 mail-qc0-f170.google.com Received: from [209.85.216.170] ([209.85.216.170:54317] helo=mail-qc0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 28/76-06615-7D878345 for ; Fri, 10 Oct 2014 20:24:57 -0400 Received: by mail-qc0-f170.google.com with SMTP id m20so2839557qcx.1 for ; Fri, 10 Oct 2014 17:24:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=96fzSz9pBZ4nZtj9Ouc8G1QV/n0uEwGG4Jlu4vxUX2s=; b=Bni2Ho3cP5QwicDVWkJIJObdItdO4S2YDlA/rFpMqa/bU1qplVMVIdNBFCE7ZJj7Ts XboDJuMi8xDHQsVlvUsbY9wYdJv29tVr7buNJnmg9J+l1WwnN+Bk4i0VmtFVlRbWVwWf j19/lR69g6RxKKye7pLaxBDAy1CGBvMqUlvYnHv8ICqmTwStULSo3E22DqRQlu91DI19 TY4JM+QzVr5Ni8uxyo41Bm65yO2Cp09JjSneJkdBtscZGbUiUzKEDVDgIExoyoKe7AXW 4G5DHFNC7+dQNg15531soy0V+f/8m14RktQW30+3mVB79mtVjb+hiQnsrRiQZ48Xs/U6 TE/w== X-Gm-Message-State: ALoCoQn3M+k3OSGa1JEVtmeBRKSVvSbrDoAChtyaONNU2WvJVdokFnSQ3YOpY8ZDFVPBWsOwBE06 X-Received: by 10.224.79.67 with SMTP id o3mr14223061qak.103.1412987093023; Fri, 10 Oct 2014 17:24:53 -0700 (PDT) Received: from [192.168.200.14] (c-50-131-44-225.hsd1.ca.comcast.net. [50.131.44.225]) by mx.google.com with ESMTPSA id l5sm6301493qai.20.2014.10.10.17.24.51 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Oct 2014 17:24:52 -0700 (PDT) Message-ID: <543878D2.1080008@lerdorf.com> Date: Fri, 10 Oct 2014 17:24:50 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Stas Malyshev , Remi Collet , PHP Internals References: <54379B40.6020403@fedoraproject.org> <5437CC48.6060806@fedoraproject.org> <54380E49.3060401@sugarcrm.com> In-Reply-To: <54380E49.3060401@sugarcrm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] GMP memory allocator, various issues From: rasmus@lerdorf.com (Rasmus Lerdorf) 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. -Rasmus