From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27538 invoked from network); 3 Jun 2000 03:24:17 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 3 Jun 2000 03:24:17 -0000 Received: (qmail 8986 invoked by alias); 3 Jun 2000 03:24:03 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 11734 Received: (qmail 8979 invoked from network); 3 Jun 2000 03:24:02 -0000 Message-ID: <20000603032359.27133.qmail@web1303.mail.yahoo.com> Date: Fri, 2 Jun 2000 20:23:59 -0700 (PDT) From: Felix Rosencrantz Subject: PATCH: Small memory leak and doc fix To: zsh-workers MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1804289383-960002639=:27091" --0-1804289383-960002639=:27091 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here's another memory leak fix along with a small doc fix. There seems to be some situations when the following code will see uninitialized memory reads from the following stack: pattern_match [compmatch.c:1035] match_str [compmatch.c:577] comp_match [compmatch.c:941] addmatches [compcore.c:1954] bin_compadd [complete.c:595] I haven't looked into this, so if more details are needed let me know. --- Sven Wischnowsky wrote: >Hmm. Maybe we get this because some parameter setfn() neither uses nor >frees the string it gets. I took a look at some of the memory that wasn't freed, and found one of the strings had a value that only came out of the value of complist ("ambiguous packed rows"). So something that touches that value has a problem. Maybe a parameter operator. >I can't see where this comes from. mkautofn() creates the >autofn-program wich is then freed in loadautofn() (or >freeshfuncnode(), with ksh-autoloading). > >All these autofn-progs won't be freed at the end, though (together >with many other things). I can see these errors even before the shell exits. The memory checker will only list a memory leak if there are no pointers in memory to a memory block. We are probably losing the pointer to the memory from buitlin.c:2162. -FR __________________________________________________ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com --0-1804289383-960002639=:27091 Content-Type: text/plain; name="patch7.txt" Content-Description: patch7.txt Content-Disposition: inline; filename="patch7.txt" Index: Src/Zle/compcore.c =================================================================== --- zsh/Src/Zle/ocompcore.c Fri Jun 2 01:09:56 2000 +++ zsh/Src/Zle/compcore.c Fri Jun 2 19:16:33 2000 @@ -733,6 +733,7 @@ } compinsert = (useline < 0 ? tricat("tab ", "", compinsert) : ztrdup(compinsert)); + zsfree(compexact); if (useexact) compexact = ztrdup("accept"); else { Index: Doc/Zsh/mod_complist.yo =================================================================== --- zsh/Doc/Zsh/omod_complist.yo Sun May 21 11:27:36 2000 +++ zsh/Doc/Zsh/mod_complist.yo Fri Jun 2 19:33:20 2000 @@ -144,7 +144,7 @@ letter will be replaced with a string of fixed width, padded to the right with spaces, while the lowercase form will not be padded. -If the option att(LISTPROMPT) is set, the completion code will not ask if +If the parameter tt(LISTPROMPT) is set, the completion code will not ask if the list should be shown. Instead it immediately starts displaying the list, stopping after the first screenful, showing the prompt at the bottom, waiting for a keypress after temporarily switching to the tt(listscroll) --0-1804289383-960002639=:27091--