From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Piet van Oostrum Newsgroups: gmane.emacs.devel Subject: Re: Possible memory corruption problem Date: Mon, 06 Feb 2006 23:14:51 +0100 Message-ID: <17383.51926.879627.828049@ordesa.cs.uu.nl> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT X-Trace: sea.gmane.org 1139264315 3557 80.91.229.2 (6 Feb 2006 22:18:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 6 Feb 2006 22:18:35 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 06 23:18:34 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F6EgS-0007iI-BX for ged-emacs-devel@m.gmane.org; Mon, 06 Feb 2006 23:18:09 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F6Ejm-0001jU-IK for ged-emacs-devel@m.gmane.org; Mon, 06 Feb 2006 17:21:34 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F6Eja-0001j5-Tn for emacs-devel@gnu.org; Mon, 06 Feb 2006 17:21:23 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F6EjW-0001iq-6l for emacs-devel@gnu.org; Mon, 06 Feb 2006 17:21:22 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F6EjW-0001in-38 for emacs-devel@gnu.org; Mon, 06 Feb 2006 17:21:18 -0500 Original-Received: from [195.121.247.10] (helo=smtp19.wxs.nl) by monty-python.gnu.org with esmtp (Exim 4.52) id 1F6Ej4-0005Fs-Al; Mon, 06 Feb 2006 17:20:50 -0500 Original-Received: from ordesa.cs.uu.nl (ip54573050.direct-adsl.nl [84.87.48.80]) by smtp19.wxs.nl (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IUA000HZDXML6@smtp19.wxs.nl>; Mon, 06 Feb 2006 23:17:46 +0100 (CET) Original-Received: by ordesa.cs.uu.nl (Postfix, from userid -2) id 30C5F2D9E93; Mon, 06 Feb 2006 23:17:42 +0100 (CET) Original-Received: from ordesa.cs.uu.nl (localhost [127.0.0.1]) by ordesa.cs.uu.nl (Postfix) with ESMTP id 816692D9E7A; Mon, 06 Feb 2006 23:17:40 +0100 (CET) In-reply-to: Original-To: Eli Zaretskii X-Mailer: emacs 22.0.50.2 (via feedmail 8 I); VM 7.19 under Emacs 22.0.50.2 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:50118 Archived-At: >>>>> Eli Zaretskii (EZ) wrote: >>> From: Piet van Oostrum >>> Date: Mon, 06 Feb 2006 16:36:01 +0100 >>> >>> I have had a few occasions when my mailboxes got corrupted. >>> I read my normal email with VM, and mail from mailing lists with gnus. I >>> have CVS emacs compiled about a month ago, running on Mac OS X 10.4.4. >>> >>> A few cases now, the last of which was last weekend, the mailboxes that I >>> had open got completely mixed up. I lost my INBOX (primary VM mailbox) >>> completely last night, and some of its messages where found in the middle >>> of another mailbox that I had open. The mixup also occurred around last >>> Christmas with VM and gnus mailboxes mixed up. Sometimes the corrupted >>> mailboxes appeared to contain garbage text from other files. >EZ> Sounds like some snafu with relocating buffers. See below. >>> I have tried to find the common circumstances when this happens and it >>> aeems to me that it happens when the machine is low on virtual memory >>> (including swap space). >EZ> Emacs should display a warning when the system is low on memory. Does >EZ> it? I haven't found a message. On the other hand I found an older crash dump with an alloc problem: Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x80040907 Thread 0 Crashed: 0 org.gnu.Emacs 0x000cc388 Fcons + 0x34 (alloc.c:2700) 1 org.gnu.Emacs 0x000cc744 Fmake_list + 0xec (alloc.c:2829) 2 org.gnu.Emacs 0x000eb6a0 concat + 0x370 (fns.c:656) 3 org.gnu.Emacs 0x000ec684 Fcopy_alist + 0x78 (fns.c:1224) 4 org.gnu.Emacs 0x00016d30 Fframe_parameters + 0x9c (frame.c:2090) 5 org.gnu.Emacs 0x000172d0 Fframe_parameter + 0x230 (frame.c:2237) 6 org.gnu.Emacs 0x000e6674 Ffuncall + 0x300 (eval.c:2866) 7 org.gnu.Emacs 0x00113a2c Fbyte_code + 0x97c (bytecode.c:691) 8 org.gnu.Emacs 0x000e6cb8 funcall_lambda + 0x2e8 (eval.c:3054) 9 org.gnu.Emacs 0x000e67c4 Ffuncall + 0x450 (eval.c:2917) 10 org.gnu.Emacs 0x00113a2c Fbyte_code + 0x97c (bytecode.c:691) 11 org.gnu.Emacs 0x000e6cb8 funcall_lambda + 0x2e8 (eval.c:3054) 12 org.gnu.Emacs 0x000e67c4 Ffuncall + 0x450 (eval.c:2917) 13 org.gnu.Emacs 0x00113a2c Fbyte_code + 0x97c (bytecode.c:691) 14 org.gnu.Emacs 0x000e6cb8 funcall_lambda + 0x2e8 (eval.c:3054) 15 org.gnu.Emacs 0x000e67c4 Ffuncall + 0x450 (eval.c:2917) 16 org.gnu.Emacs 0x00113a2c Fbyte_code + 0x97c (bytecode.c:691) 17 org.gnu.Emacs 0x000e6cb8 funcall_lambda + 0x2e8 (eval.c:3054) 18 org.gnu.Emacs 0x000e67c4 Ffuncall + 0x450 (eval.c:2917) 19 org.gnu.Emacs 0x00113a2c Fbyte_code + 0x97c (bytecode.c:691) 20 org.gnu.Emacs 0x000e6cb8 funcall_lambda + 0x2e8 (eval.c:3054) 21 org.gnu.Emacs 0x000e67c4 Ffuncall + 0x450 (eval.c:2917) 22 org.gnu.Emacs 0x00113a2c Fbyte_code + 0x97c (bytecode.c:691) 23 org.gnu.Emacs 0x000e6cb8 funcall_lambda + 0x2e8 (eval.c:3054) 24 org.gnu.Emacs 0x000e6968 apply_lambda + 0xfc (eval.c:2974) 25 org.gnu.Emacs 0x000e5adc Feval + 0x564 (eval.c:2262) 26 org.gnu.Emacs 0x000e2804 Fand + 0x48 (eval.c:354) 27 org.gnu.Emacs 0x000e592c Feval + 0x3b4 (eval.c:2205) 28 org.gnu.Emacs 0x000e4634 internal_condition_case_1 + 0x148 (eval.c:1494) 29 org.gnu.Emacs 0x00083cc0 menu_item_eval_property + 0x7c (keyboard.c:7160) 30 org.gnu.Emacs 0x00084db0 parse_tool_bar_item + 0x3e0 (keyboard.c:7837) 31 org.gnu.Emacs 0x000849b0 process_tool_bar_item + 0xbc (keyboard.c:7667) 32 org.gnu.Emacs 0x000848a4 tool_bar_items + 0x1e8 (keyboard.c:7619) 33 org.gnu.Emacs 0x00028680 update_tool_bar + 0x1b4 (xdisp.c:8996) 34 org.gnu.Emacs 0x00027fdc prepare_menu_bars + 0x170 (xdisp.c:8668) 35 org.gnu.Emacs 0x0002aa74 redisplay_internal + 0x36c (xdisp.c:10384) 36 org.gnu.Emacs 0x0002b9a0 redisplay_preserve_echo_area + 0x50 (xdisp.c:10989) 37 org.gnu.Emacs 0x0011acfc wait_reading_process_output + 0x3c0 (process.c:4167) 38 org.gnu.Emacs 0x00012eac sit_for + 0xcc (dispnew.c:6419) 39 org.gnu.Emacs 0x0007e138 read_char + 0xa1c (keyboard.c:2765) 40 org.gnu.Emacs 0x000863f4 read_key_sequence + 0x790 (keyboard.c:8829) 41 org.gnu.Emacs 0x0007b8c8 command_loop_1 + 0x42c (keyboard.c:1529) 42 org.gnu.Emacs 0x000e44c8 internal_condition_case + 0x140 (eval.c:1453) 43 org.gnu.Emacs 0x0007b254 command_loop_2 + 0x40 (keyboard.c:1315) 44 org.gnu.Emacs 0x000e3ee0 internal_catch + 0xf8 (eval.c:1211) 45 org.gnu.Emacs 0x0007b1ac command_loop + 0x90 (keyboard.c:1298) 46 org.gnu.Emacs 0x0007ab94 recursive_edit_1 + 0xa8 (keyboard.c:988) 47 org.gnu.Emacs 0x0007ad2c Frecursive_edit + 0xdc (keyboard.c:1049) 48 org.gnu.Emacs 0x0007982c main + 0xc38 (emacs.c:1783) 49 org.gnu.Emacs 0x0000a010 _start + 0x188 (crt.c:267) 50 org.gnu.Emacs 0x00009e84 start + 0x30 >>> So I suspect that some part of Emacs' buffer and memory management >>> fails to check the result of malloc calls or something similar. >EZ> I'd rather suspect something else: that some library function on your >EZ> platform is passed a pointer to buffer text, and that library function >EZ> calls malloc internally, which (especially when Emacs needs to >EZ> allocate a large amount of memory) causes Emacs to relocate buffer >EZ> text, which could easily invalidate the pointer(s) used by that >EZ> library function. But then it should occur at random times. And my observation is that in the 2 or 3 cases that this happened the systems disk was full, and/or the system warned about a lack of swap space. >>> I have written a test program and it appears that Mac OS X's malloc >>> and realloc correctly return NULL when the process runs out of >>> memory. >EZ> Does Emacs indeed use system malloc on your platform? Or does it use >EZ> gmalloc? darwin.h does define SYSTEM_MALLOC. And the configure says: Should Emacs use the GNU version of malloc? no (The GNU allocators don't work with this system configuration.) Should Emacs use a relocating allocator for buffers? no Should Emacs use mmap(2) for buffer allocation? no The kernel gives an error around the time that the buffers got mixed up: no space in available paging segments -- Piet van Oostrum URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4] Private email: piet@vanoostrum.org