emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Possible memory corruption problem


From: Piet van Oostrum
Subject: Re: Possible memory corruption problem
Date: Mon, 06 Feb 2006 23:14:51 +0100

>>>>> Eli Zaretskii <address@hidden> (EZ) wrote:

>>> From: Piet van Oostrum <address@hidden>
>>> 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 <address@hidden>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: address@hidden





reply via email to

[Prev in Thread] Current Thread [Next in Thread]