From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: EMACS and valgrind Date: 22 Jan 2004 17:26:30 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <16383.8247.758985.411260@nick.uklinux.net> <9743-Sat10Jan2004143440+0200-eliz@elta.co.il> <16393.51090.62851.168340@nick.uklinux.net> <9178-Sun18Jan2004211534+0200-eliz@elta.co.il> <16396.24781.247776.602605@nick.uklinux.net> <1438-Tue20Jan2004082138+0200-eliz@elta.co.il> <16400.17585.198467.331774@nick.uklinux.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1074810741 1401 80.91.224.253 (22 Jan 2004 22:32:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 22 Jan 2004 22:32:21 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Jan 22 23:32:12 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AjnMx-0002YD-00 for ; Thu, 22 Jan 2004 23:32:11 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AjnMx-0004e5-00 for ; Thu, 22 Jan 2004 23:32:11 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AjnK2-0001Y8-U8 for emacs-devel@quimby.gnus.org; Thu, 22 Jan 2004 17:29:10 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AjnIV-0001Bv-Eh for emacs-devel@gnu.org; Thu, 22 Jan 2004 17:27:35 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AjnHY-0000nL-C3 for emacs-devel@gnu.org; Thu, 22 Jan 2004 17:27:07 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AjnHX-0000mW-8g for emacs-devel@gnu.org; Thu, 22 Jan 2004 17:26:35 -0500 Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 0FE9720D19; Thu, 22 Jan 2004 17:26:31 -0500 (EST) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id A6F018C6F3; Thu, 22 Jan 2004 17:26:30 -0500 (EST) Original-To: Nick Roberts In-Reply-To: <16400.17585.198467.331774@nick.uklinux.net> Original-Lines: 46 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=0, requis 5) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:19440 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19440 >> Well, with my USE_LSB_TAG patch, you might be able to go a bit further >> since it does not assume that malloc returns blocks of memory close to >> address 0 (instead it assumes the blocks are aligned on 8byte boundaries). > Well, I've rebuilt Emacs with make "MYCPPFLAGS=-DUSE_LSB_TAG". Is that right? > Valgrind complains that the memory is exhausted again, but from a different > location in the Emacs code (shown below). To give me a handle on this matter, > can you please provide a bit of background to this patch? The patch changes the place where tag bits are kept in Lisp_Object values. I.e. instead of using the top 3 bits (so we can only use pointers whose values are smaller than 2^29) it now uses the low 3 bits (so we can use pointers that point anywhere within the address space so long as they are aligned on an 8-byte boundary). Now, I have no idea whether the problem you se without USE_LSB_TAG is due to the fact that valgrind uses a malloc implementation that returns pointers whose value is larger than 2^29, but it seemed like a possible cause. > ==2395== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. > ==2395== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. > ==2395== Using valgrind-2.0.0, a program supervision framework for x86-linux. > ==2395== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. > ==2395== Estimated CPU clock rate is 200 MHz > ==2395== For more details, rerun with: -v > ==2395== > ==2395== Invalid free() / delete / delete[] > ==2395== at 0x4002668F: realloc (vg_replace_malloc.c:310) > ==2395== by 0x812E694: xrealloc (alloc.c:547) > ==2395== by 0x81267BE: regex_compile (regex.c:2721) > ==2395== by 0x812D8BF: re_compile_pattern (regex.c:5997) > ==2395== Address 0x8575778 is not stack'd, malloc'd or free'd > ==2395== > ==2395== Invalid free() / delete / delete[] > ==2395== at 0x400263A8: free (vg_replace_malloc.c:231) > ==2395== by 0x812E595: memory_full (alloc.c:478) > ==2395== by 0x812E6D8: xrealloc (alloc.c:552) > ==2395== by 0x81267BE: regex_compile (regex.c:2721) > ==2395== Address 0x83D2F60 is not stack'd, malloc'd or free'd > emacs: Memory exhausted--use M-x save-some-buffers then exit and restart Emacs This does not look like exhausted memory but rather looks like corruption (c.f. "Invalid free"). Stefan