From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27850 invoked from network); 8 May 2002 17:24:22 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 8 May 2002 17:24:22 -0000 Received: (qmail 27591 invoked by alias); 8 May 2002 17:24:14 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 17103 Received: (qmail 27574 invoked from network); 8 May 2002 17:24:12 -0000 To: zsh-workers@sunsite.dk (Zsh hackers list) Subject: Re: PATCH: zselect builtin. In-reply-to: "Peter Stephenson"'s message of "Wed, 08 May 2002 14:26:44 BST." <21268.1020864404@csr.com> Date: Wed, 08 May 2002 18:23:45 +0100 Message-ID: <26624.1020878625@csr.com> From: Peter Stephenson Peter Stephenson wrote: > Warning: I used this overnight as part of a test and there seems to be > a memory leak somewhere, not necessarily zselect itself (where I can't > see where it would be). I was using ztcp, but it was the same TCP > connection all the time, so I don't think that's it either. It's just > possible I was accumulating some humongous array, but I couldn't see > where that would have been, either. Unfortunately I had to kill the > shell because I made it uninteruptible. /\ r I'm 90% sure I know what's causing this, and it's nothing to do with the modules. The memory is released when the code returns to the top level (at least by the application layer: it doesn't get returned to the system, but when I restart the function it takes a long while before it needs more memory from the system, indicating the shell has finished with the previous allocation). This indicates something is hogging it until the return to top-level processing. There is one obvious candidate. When a function is executed, it gets copied to a new structure tree. When this is finished with, it gets passed to freeeprog(). But that doesn't free it, in case something is still executing it. It only gets freed by freeeprogs() when control returns to the top level. As my function executes in a while loop, this never happens. I tested this by removing all function calls from the while loop and putting the builtins inline, and the memory stopped increasing. This is pretty disastrous. We need a better way of deciding whether to free Eprog's. I can't see why we shouldn't use some reference count mechanism. -- Peter Stephenson Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 392070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. **********************************************************************