Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:102040 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 17427 invoked from network); 14 Apr 2018 09:34:29 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Apr 2018 09:34:29 -0000 Authentication-Results: pb1.pair.com header.from=HMWiesinger@liwjatan.at; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=HMWiesinger@liwjatan.at; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain liwjatan.at designates 81.19.149.136 as permitted sender) X-PHP-List-Original-Sender: HMWiesinger@liwjatan.at X-Host-Fingerprint: 81.19.149.136 mx26lb.world4you.com Received: from [81.19.149.136] ([81.19.149.136:39098] helo=mx26lb.world4you.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 25/B4-36099-02BC1DA5 for ; Sat, 14 Apr 2018 05:34:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=liwjatan.at; s=dkim11; h=Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From; bh=9BvDdIDVstBNNbOKZmwyV0ZMZjyj7JgT8mO8zjndzlw=; b=g7Chi5TfGMF+2QN1FUXoZYpKaKPPLZMUiZEqXRc7nqsYavqfbI8rGDi54KVCjpDln5uXDHvV2/RcSq5TJr5KGZOdi2pGXnziFnotDtf/Q12TiuqQZ6/8/BhyKxTFxAwZ58apgPuIdyj+wbg+KwXNgGAUi7lHDDvCp6L71X0t67E=; Received: from [89.98.171.157] (helo=titania.liwjatan.org) by mx26lb.world4you.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1f7HZd-0005w2-Uz; Sat, 14 Apr 2018 11:34:22 +0200 To: Nikita Popov Cc: internals@lists.php.net Date: Sat, 14 Apr 2018 11:35:18 +0200 Message-ID: <6395034.frFR8FNLf6@titania.liwjatan.org> In-Reply-To: <10384487.RTP3OaIAjh@titania.liwjatan.org> References: <1695946.AXCnACv0zz@titania.liwjatan.org> <10384487.RTP3OaIAjh@titania.liwjatan.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2571985.tJRNFOHWVF"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-SA-Do-Not-Run: Yes X-AV-Do-Run: Yes X-SA-Exim-Connect-IP: 89.98.171.157 X-SA-Exim-Mail-From: HMWiesinger@liwjatan.at X-SA-Exim-Scanned: No (on mx26lb.world4you.com); SAEximRunCond expanded to false Subject: Re: [PHP-DEV] Request-global hashtable initialization From: HMWiesinger@liwjatan.at (Heinz Wiesinger) --nextPart2571985.tJRNFOHWVF Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Friday, 13 April 2018 08:16:24 CEST Heinz Wiesinger wrote: > On Thursday, 12 April 2018 22:34:52 CEST Nikita Popov wrote: > > On Thu, Apr 12, 2018 at 9:53 PM, Heinz Wiesinger > > > > wrote: > > > Hi everyone! > > > > > > I ventured into writing my first PHP extension and did pretty well so > > > far > > > following the existing documentation and example code inside the php > > > source. > > > > > > However, I hit an odd bug in my code that I can't quite explain. I'm > > > obviously > > > missing something and I hope someone here can point me in the right > > > direction > > > > > > :) > > > > > > I'd like to set up a request global hashtable. For now I'm running > > > ALLOC_HASHTABLE() and zend_hash_init() inside PHP_GINIT_FUNCTION. I then > > > have > > > a user function that's supposed to add entries to that hashtable and > > > another > > > user function that reads entries from the hashtable. > > > > > > I tested with code passed directly on the command line (using php -r) > > > and > > > that > > > works just like I would expect it too. The value gets written to the > > > hashtable > > > and I can read it afterwards from the other function. I also verified > > > it's > > > the > > > same value that I first stored, so from what I can tell the basic > > > functionality is good. > > > > > > When I take the same testcode and write it into a file, and then run php > > > on > > > that file, execution aborts trying to allocate almost 2GB of memory when > > > trying to store the value in the hashtable (using zend_hash_update()). I > > > can > > > see PHP_GINIT_FUNCTION being executed in that case as well so I'd assume > > > the > > > hashtable is setup just fine. Yet something is different. > > > > > > What's the difference between " php -r '' " and "php test.php" in that > > > regard? > > > > > > I uploaded my current state of the extension to github in case someone > > > would > > > like to take a closer look at the code: https://github.com/pprkut/ > > > autoload-psr > > > > > > Thanks in advance! > > > > > > Grs, > > > Heinz > > > > https://github.com/pprkut/autoload-psr/blob/27cfc53c864116cf0b65b8f7e69464 > > e1 5b3fdef5/autoload_psr.c#L175 should be using ZVAL_STR_COPY. The > > hashtable API does not automatically incref stored values. > > > > I'd suggest running under USE_ZEND_ALLOC=0 valgrind to check for further > > memory issues. Differences in the mode of execution are likely just > > incidental. > > Thanks for the pointers! I tried running it under valgrind, but couldn't > find anything. So I tried without valgrind, but with USE_ZEND_ALLOC=0 and > found that I can't reproduce the problem like that. Looks to me that > something I do doesn't play well with the zend allocator. > > Incidentally valgrind also doesn't tell me about the issue with ZVAL_STR > that you pointed out. Maybe I'm using it wrong? I tried > > USE_ZEND_ALLOC=0 valgrind --tool=memcheck --leak-check=full php - > dextension=modules/autoload_psr.so test2.php I moved the hashtable initialization out of PHP_GINIT_FUNCTION and do it on- demand now in the respective user functions. That seems to have done the trick, as segfaults and oom messages are gone now. Grs, Heinz --nextPart2571985.tJRNFOHWVF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iHUEABEIAB0WIQQRpqSSOxrcqQ33x62nXtwz5SpGygUCWtHLVgAKCRCnXtwz5SpG yvTUAP92X/mIx/cJ7m5qxfcR87fX9KwDVbgi2HGBiuXL3PEaeQD/R4CS1sxfXc+x ttPUiTBy+etFgoQKNfu9pXsMSXv9+JI= =fQgl -----END PGP SIGNATURE----- --nextPart2571985.tJRNFOHWVF--