From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1076 invoked by alias); 28 Jul 2018 18:06:03 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 43220 Received: (qmail 6133 invoked by uid 1010); 28 Jul 2018 18:06:03 -0000 X-Qmail-Scanner-Diagnostics: from rcpt-mqugw.biglobe.ne.jp by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(133.208.100.1):SA:0(-2.6/5.0):. Processed in 1.19378 secs); 28 Jul 2018 18:06:03 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: takimoto-j@kba.biglobe.ne.jp X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | X-Biglobe-Sender: From: "Jun T." Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH] fix several memory leaks Date: Sun, 29 Jul 2018 02:20:00 +0900 References: <8CE35533-3221-4A9D-94D9-07B4DEF54C80@kba.biglobe.ne.jp> To: zsh-workers@zsh.org In-Reply-To: <8CE35533-3221-4A9D-94D9-07B4DEF54C80@kba.biglobe.ne.jp> Message-Id: <1EDE433F-887D-4E9B-865D-8BFBE9825D9F@kba.biglobe.ne.jp> X-Mailer: Apple Mail (2.3273) X-Biglobe-Spnum: 60711 > 2018/07/29 01:34, I wrote: > > V01zmodload.ztst has another type of leaks, but I will discuss > it in a separate post because how to fix it (or whether it must > be fixed or not) is not clear. Here is the other leaks in V01zmodload.zsh: [7] V01zmodload.ztst (part2: example.c) The second type of leaks can be reproduced by: zsh% zmodload -ab zsh/example example zsh% zmodload -u zsh/example zsh% builtin example zsh% zmodload -u zsh/example The 'builtin example' autoloads the builtin, and then calls bin_example(), which allocates memory for 'strparam' and 'arrparam' at lines 71 and 74 in example.c. But these are not freed by cleanup_(). At this point 'p:exstr' and 'p:exarr' are not enabled, and setfeatureenables() takes care of only enabled features. If the first 'zomdload -u' is ommited then the leak does not occur. In this case, all the features are enabled by 'builtin example', and the last 'zmodload -u' correctly frees the memory for 'p:exstr' and 'p:exarr'. Do we need to fix this leak? If builtin and parameter are independent features, then "a builtin depending on parameters" may not be a good "example". The patch below is NOT a fix; it is just to confirm that what are leaking is 'strparam' and 'arrparam'. Parameters are supposed to be freed by setfeatureenables(,,NULL), and explicitly freeing them in cleanup_() is not a good example. diff --git a/Src/Modules/example.c b/Src/Modules/example.c index c80c9e7b2..0cae3477d 100644 --- a/Src/Modules/example.c +++ b/Src/Modules/example.c @@ -234,6 +234,10 @@ boot_(Module m) int cleanup_(Module m) { + zsfree(strparam); + strparam = NULL; + freearray(arrparam); + arrparam = NULL; deletewrapper(m, wrapper); return setfeatureenables(m, &module_features, NULL); }