From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Brown Newsgroups: gmane.emacs.bugs Subject: bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping Date: Wed, 23 May 2012 11:23:21 -0400 Message-ID: <4FBD00E9.1060401@cornell.edu> References: <83d360yw48.fsf@gnu.org> <834nrazrtl.fsf@gnu.org> <831umez1p7.fsf@gnu.org> <83vcjpxw18.fsf@gnu.org> <83k404xcpt.fsf@gnu.org> <83hav8xak1.fsf@gnu.org> <83ehqby542.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1337786671 6044 80.91.229.3 (23 May 2012 15:24:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 23 May 2012 15:24:31 +0000 (UTC) Cc: lekktu@gmail.com, schwab@linux-m68k.org, Richard Stallman , 11519@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 23 17:24:30 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SXDQJ-0000aN-8o for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 May 2012 17:24:27 +0200 Original-Received: from localhost ([::1]:42517 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXDQI-0007w3-Q3 for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 May 2012 11:24:26 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57429) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXDQC-0007vx-Mn for bug-gnu-emacs@gnu.org; Wed, 23 May 2012 11:24:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXDQ4-0006Ys-VY for bug-gnu-emacs@gnu.org; Wed, 23 May 2012 11:24:20 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59489) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXDQ4-0006Yo-SP for bug-gnu-emacs@gnu.org; Wed, 23 May 2012 11:24:12 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SXDQr-00069K-VY for bug-gnu-emacs@gnu.org; Wed, 23 May 2012 11:25:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ken Brown Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 May 2012 15:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11519 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11519-submit@debbugs.gnu.org id=B11519.133778666923599 (code B ref 11519); Wed, 23 May 2012 15:25:01 +0000 Original-Received: (at 11519) by debbugs.gnu.org; 23 May 2012 15:24:29 +0000 Original-Received: from localhost ([127.0.0.1]:40802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXDQL-00068a-FZ for submit@debbugs.gnu.org; Wed, 23 May 2012 11:24:29 -0400 Original-Received: from granite1.mail.cornell.edu ([128.253.83.141]:35014 helo=authusersmtp.mail.cornell.edu) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SXDQJ-00068S-HU for 11519@debbugs.gnu.org; Wed, 23 May 2012 11:24:28 -0400 Original-Received: from [192.168.1.4] (cpe-67-249-194-47.twcny.res.rr.com [67.249.194.47]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id q4NFNZNQ002237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 May 2012 11:23:36 -0400 (EDT) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 In-Reply-To: X-PMX-CORNELL-SPAM-CHECKED: Pawpaw X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.5.23.150915 X-Original-Sender: kbrown@cornell.edu - Wed May 23 11:23:37 2012 X-PMX-CORNELL-REASON: CU_White_List_Override X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:60307 Archived-At: On 5/23/2012 10:16 AM, Stefan Monnier wrote: >> Which other places use C pointers to buffer text and call functions >> that can allocate memory? > > IIUC any place that uses STRING_CHAR_AND_LENGTH on buffer text is > vulnerable to the problem. > >> Anyway, are you against committing this to the release branch? I'd be >> very sad if you were, having invested so much time in hunting this >> bug, but I guess I'll survive. > > I'm not dead set against it, and I'm glad we found the culprit so we can > fix it: fixing it on the release branch is not that important, since this > bug has been with us since Emacs-23.1, AFAICT. > > If you really want to install your workaround on the emacs-24 branch, go > for it but let's try to find a real fix for the trunk. > >>>>> I wonder: why do we use REL_ALLOC? >>>> AFAIK, we do that only on platforms that don't support mmap for >>>> allocating buffer text. >>> So, IIUC the only reason to use it is so that we can more often return >>> memory to the OS even for the non-mmap case? Is that because returning >>> memory can only be done via sbrk style memory management? >> I don't think this is only about _returning_ memory. It is first and >> foremost about not _asking_ for more memory when we can come up with >> it by reshuffling buffer text. > > So you're saying it's use for fragmentation reasons? > But on other platforms where we use mmap, we do suffer from this > fragmentation, and yet it doesn't seem to be a real source of problem. > That's why I think the only real reason is because memory can only be > returned via sbrk-style memory management (i.e. only free memory at the > end of the heap can be returned). Is that right? > > I guess my question turns into "why do we use gmalloc.c instead of > a malloc library that uses mmap (or some other mechanism that lets it > return large free chunks to the OS)"? > > AFAIK, Windows is pretty much the only system where we use gmalloc.c and > ralloc.c nowadays. Does anyone remember why we don't use the system > malloc under Windows (and Cygwin)? Cygwin uses gmalloc.c but not ralloc.c; it uses mmap for buffers. There are two reasons for using gmalloc.c on Cygwin. The first, which may or may not be important, is that Cygwin's malloc doesn't support __after_morecore_hook, malloc_get_state, or malloc_set_state. The second has to do with the way emacs is dumped on Cygwin. See the comment starting at line 302 in gmalloc.c. I would love to find a better way to deal with this and be able to use the system malloc on Cygwin. Ken