[Top][All Lists]
[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
- Possible memory corruption problem, Piet van Oostrum, 2006/02/06
- Re: Possible memory corruption problem, Eli Zaretskii, 2006/02/06
- Re: Possible memory corruption problem,
Piet van Oostrum <=
- Re: Possible memory corruption problem, Richard M. Stallman, 2006/02/12
- Re: Possible memory corruption problem, Eli Zaretskii, 2006/02/13
- Re: Possible memory corruption problem, Piet van Oostrum, 2006/02/14
- Re: Possible memory corruption problem, Aidan Kehoe, 2006/02/14
- Re: Possible memory corruption problem, Richard M. Stallman, 2006/02/14
- Re: Possible memory corruption problem, Piet van Oostrum, 2006/02/16
- Re: Possible memory corruption problem, Richard M. Stallman, 2006/02/20
- Re: Possible memory corruption problem, Richard M. Stallman, 2006/02/14