Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103078 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 91709 invoked from network); 11 Aug 2018 09:03:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Aug 2018 09:03:31 -0000 Authentication-Results: pb1.pair.com smtp.mail=nikita.ppv@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=nikita.ppv@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.196 as permitted sender) X-PHP-List-Original-Sender: nikita.ppv@gmail.com X-Host-Fingerprint: 209.85.223.196 mail-io0-f196.google.com Received: from [209.85.223.196] ([209.85.223.196:44382] helo=mail-io0-f196.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 34/F7-18754-266AE6B5 for ; Sat, 11 Aug 2018 05:03:31 -0400 Received: by mail-io0-f196.google.com with SMTP id q19-v6so9802949ioh.11 for ; Sat, 11 Aug 2018 02:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4wAUO9X/zg+Qfa3PGBcWbAZ4foVi6im1XdTR/FiaHIQ=; b=ZqU5qQBolC9qfPWP9B2iP5Tw0+sgQWamR8KDM/8dIa91mq5p1n7L8S6+TJ2Puo8MXf obs8OntNndGA5o0gge1QOVx55+Png5rZLqIs9QieDrjDn/QcXXDuWHvQTk23NmBNEzPd mg6rbaEzMY2vCWLYZshc1Ea108cwIBab+6a16Ye7mYWgLGEnnFucecJDS9KEARTnpMj6 9auZ9OG2WUvpkmf18ZHcEXzFbW8HMSN+3Ag3+gyGjmxzqGPFeAxft5asdJG7hq+UJ8Fy R7EidG5K+hS+J/bHlGubWW1yeM3umVHSvj80ya9sL/1wKQUDE+FLbFAqU0GsXUNf25+r kTkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4wAUO9X/zg+Qfa3PGBcWbAZ4foVi6im1XdTR/FiaHIQ=; b=pxeJNRaWnY45jFw06yEe80e+nHoHhj7pLCkr1KlydbEWaUJnguJq9cCz1EOf4EGpf7 CCKqIo4Ax8et5LER1PnMhZPFaUOth5ldiIvDYDGI8Lud83fv8xRqK/QlYBoKMNHy3ZJ7 zeCtiZT2jlbI5k9If4NraS0o7gb74YfDMVJIrJP0YMDQoswN6ZxnsiZacuNBoZLha1Ml IakgTVoflhUSbzcrnmMTrHjnrXPtFFHVBWdXM+9dLw4jKQRKMZvVR2dIrAA+RKHhUjT3 3sRkQqEGthF8vz3NRMgZeqGSO+qikF+Ty4+MEVffeYk/6L8f2sztjh2dqqneewYeqL69 f2EA== X-Gm-Message-State: AOUpUlFir4rakFVQfdtrdAXXMPgcwhrmDRGRwC+nRwhVbLahhqk+T5iv WxaByEpJ95XoGSQKXldTYialqaDsXnyMZdJ91rQ= X-Google-Smtp-Source: AA+uWPxQLD5d9whNQOrC2fK4tnj5P+lHg/rkjgahAd+GXAJ8EQdyeATqCerJY7tOazAjoYnWBhRMO8cqitq7hTPq+C0= X-Received: by 2002:a6b:c844:: with SMTP id y65-v6mr8180681iof.187.1533978208018; Sat, 11 Aug 2018 02:03:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:148a:0:0:0:0:0 with HTTP; Sat, 11 Aug 2018 02:03:27 -0700 (PDT) In-Reply-To: References: Date: Sat, 11 Aug 2018 11:03:27 +0200 Message-ID: To: Nicolai Scheer Cc: PHP Internals Content-Type: multipart/alternative; boundary="0000000000002ea73c0573252253" Subject: Re: [PHP-DEV] object destruction php 5.6 vs. 7.2 From: nikita.ppv@gmail.com (Nikita Popov) --0000000000002ea73c0573252253 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 8, 2018 at 11:09 PM, Nicolai Scheer wrote: > Hi, > > I'm currently facing difficulties to migrate one of our extension from php > 5.6 to 7.2. > > Basically everything works fine. > The extension defines its own resource, and since it's object oriented, > stores the resource inside a member variable, i.e. we register the custom > resource using zend_list_insert followed by calling zend_update_property. > > Every method then fetches the resource using zend_read_property and > zend_fetch_resource. > The resource itself has a dtor, which is registered > through zend_register_list_destructors_ex. > > The class itself does not have a __destruct method. > > Using php 5.6, when unsetting the object in userspace the resource dtor was > called immediately. > > In php 7.2 this does not seem to be the case anymore - i.e. I see that the > resource dtor is called at script end, but not when unsetting the object in > userspace. > This results in php holding a lot of connections (that's what the resource > is about) up to the point where no new connection can be created (which is > bad). > > I implemented and registered a __destruct method for testing purposes - > this one indeed gets called on object destruction triggered by unsetting > the variable in userspace. > > So my question here ist: Can anyone give me an insight what is happening > here? I know, I posted not quite much information, but there must be > something fundamental I'm missing. > > Basically I would expect, even if I do not implement a custom __destruct > method, that upon object deletion all members variables are deleted as well > - this would include the resource, and as such, the resource destructor > would be called. > That seems to be what is happening in php 5.6 but does not work in 7.2 > anymore. > > Of course I could move the code from the resource dtor to a __destruct > method - but what's the point in providing a resource destructor then (in > my case)? What is the correct way for a class to hold a (protected) > resource and make sure that resource gets destroyed correctly upon object > deletion? > > Thanks for your help! > > Greetings > > Nico > My guess would be some kind of refcounting issue. For example zend_update_property will already increment the refcount of the assigned value itself. So if you create a value with refcount 1 and then assign it to an object property, you likely need to do an explicit delref. If you don't, then the value is leaked and your resource destructor will not run until shutdown. Nikita --0000000000002ea73c0573252253--