From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18585 invoked from network); 27 Apr 2007 21:36:50 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.8 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 27 Apr 2007 21:36:50 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 64109 invoked from network); 27 Apr 2007 21:36:43 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 27 Apr 2007 21:36:43 -0000 Received: (qmail 551 invoked by alias); 27 Apr 2007 21:36:40 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23339 Received: (qmail 536 invoked from network); 27 Apr 2007 21:36:39 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 27 Apr 2007 21:36:39 -0000 Received: (qmail 63811 invoked from network); 27 Apr 2007 21:36:39 -0000 Received: from mtaout02-winn.ispmail.ntl.com (81.103.221.48) by a.mx.sunsite.dk with SMTP; 27 Apr 2007 21:36:36 -0000 Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20070427213635.FLOL19810.mtaout02-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com> for ; Fri, 27 Apr 2007 22:36:35 +0100 Received: from pwslaptop.csr.com ([81.107.41.251]) by aamtaout04-winn.ispmail.ntl.com with ESMTP id <20070427213635.PXZX29112.aamtaout04-winn.ispmail.ntl.com@pwslaptop.csr.com> for ; Fri, 27 Apr 2007 22:36:35 +0100 Received: from pwslaptop.csr.com (pwslaptop.csr.com [127.0.0.1]) by pwslaptop.csr.com (8.13.8/8.13.7) with ESMTP id l3RLZE1d005051 for ; Fri, 27 Apr 2007 22:35:14 +0100 Message-Id: <200704272135.l3RLZE1d005051@pwslaptop.csr.com> From: Peter Stephenson To: zsh-workers@sunsite.dk (Zsh hackers list) Subject: PATCH: and query for malloc(0). Date: Fri, 27 Apr 2007 22:35:14 +0100 Playing with POSIX regexes, I found some errors coming from zsh's memory allocation with debugging on. These turned out to resolve to some malloc()s and free()s for zero length and the following oddity in malloc(): /* some systems want malloc to return the highest valid address plus one if it is called with an argument of zero */ if (!size) return (MALLOC_RET_T) m_high; Wuh...err...wuh...err...? As I've commented in the patch below, TODO: really? Suppose we allocate more memory, so that this is now in bounds, then a more rational application that thinks it can free() anything it malloc'ed, even of zero length, calls free for it? Aren't we in big trouble? Wouldn't it be safer just to allocate some memory anyway? Actually, what was causing the immediate problem was a free() on the address when it *was* still m_high, which was (correctly) being flagged as an error by memory debugging (valgrind agreed something was rotten). But actually I think that's a side effect of the odd code above. This code already seemed to be ancient at the first mention of mem.c in the mailing list archive in 1995. If anyone knows anything, please speak. Otherwise I will commit the following patch. valgrind and the shell's own routines are much happier with it. Index: Src/mem.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/mem.c,v retrieving revision 1.14 diff -u -r1.14 mem.c --- Src/mem.c 30 May 2006 22:35:03 -0000 1.14 +++ Src/mem.c 27 Apr 2007 21:24:56 -0000 @@ -830,10 +830,26 @@ #endif /* some systems want malloc to return the highest valid address plus one - if it is called with an argument of zero */ + if it is called with an argument of zero. + + TODO: really? Suppose we allocate more memory, so + that this is now in bounds, then a more rational application + that thinks it can free() anything it malloc'ed, even + of zero length, calls free for it? Aren't we in big + trouble? Wouldn't it be safer just to allocate some + memory anyway? + + If the above comment is really correct, then at least + we need to check in free() if we're freeing memory + at m_high. + */ if (!size) +#if 1 + size = 1; +#else return (MALLOC_RET_T) m_high; +#endif queue_signals(); /* just queue signals rather than handling them */ -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/