[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: allocate_string_data memory corruption
From: |
Stefan Monnier |
Subject: |
Re: allocate_string_data memory corruption |
Date: |
Sun, 22 Jan 2006 19:55:36 -0500 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
>> Maybe eassert(!handling_signal) should be added to allocate_string
>> (and maybe it will catch the current bug).
>> It seems worth a try.
Attached is another candidate for "random memory corruption" (tho, here it
uses allocate_vectorlike, whose code is almost completely wrapped in
BLOCK_INPUT except for:
p->next = all_vectors;
all_vectors = p;
so it's probably not causing too much memory corrpution).
Contrary to the previous one, I have no idea how to fix this one.
Stefan
(gdb) bt
#0 abort () at emacs.c:464
#1 0x081946fa in die (msg=0x8265950 "assertion failed: !handling_signal",
file=0x8265209 "alloc.c", line=2866) at alloc.c:6126
#2 0x08197013 in allocate_vectorlike (len=391, type=MEM_TYPE_VECTOR) at
alloc.c:2866
#3 0x081971f4 in allocate_vector (nslots=391) at alloc.c:2894
#4 0x08197223 in Fmake_vector (length=3128, init=138309641) at alloc.c:2990
#5 0x08197562 in Fmake_char_table (purpose=138537273, init=138309641) at
alloc.c:3015
#6 0x0811a984 in make_fontset (frame=142414076, name=138309641,
base=142390252) at fontset.c:401
#7 0x0811b03d in make_fontset_for_ascii_face (f=0x87d10f8, base_fontset_id=3)
at fontset.c:580
#8 0x080f49f9 in realize_face (cache=0x87d1780, attrs=0xbfffce90, c=0,
base_face=0x0, former_face_id=-1) at xfaces.c:7224
#9 0x080f6236 in lookup_face (f=0x87d10f8, attr=0xbfffce90, c=0,
base_face=0x0) at xfaces.c:5685
#10 0x080f66d3 in face_at_buffer_position (w=0x87d1258, pos=768, region_beg=0,
region_end=0, endptr=0xbfffd0b0, limit=769, mouse=1) at xfaces.c:7690
#11 0x0809dee9 in note_mouse_highlight (f=0x87d10f8, x=88, y=285) at
xdisp.c:22533
#12 0x080fd0ee in note_mouse_movement (frame=0x87d10f8, event=0xbfffd624) at
xterm.c:3614
#13 0x08103405 in handle_one_xevent (dpyinfo=0x871fb28, eventp=0xbfffd6f0,
finish=0xbfffd77c, hold_quit=0xbfffe7b0) at xterm.c:6573
#14 0x0810683b in XTread_socket (sd=0, expected=1, hold_quit=0xbfffe7b0) at
xterm.c:7021
#15 0x0813b1b9 in read_avail_input (expected=<value optimized out>) at
keyboard.c:6712
#16 0x0813b35a in handle_async_input () at keyboard.c:6858
#17 0x0813b389 in input_available_signal (signo=29) at keyboard.c:6900
#18 <signal handler called>
- Re: allocate_string_data memory corruption, (continued)
- Re: allocate_string_data memory corruption, Stefan Monnier, 2006/01/22
- Re: allocate_string_data memory corruption, Andreas Schwab, 2006/01/22
- Re: allocate_string_data memory corruption, Richard M. Stallman, 2006/01/22
- Re: allocate_string_data memory corruption, Ken Raeburn, 2006/01/22
- Re: allocate_string_data memory corruption, Stefan Monnier, 2006/01/22
- Re: allocate_string_data memory corruption, Stefan Monnier, 2006/01/22
- Re: allocate_string_data memory corruption, Richard M. Stallman, 2006/01/24
- Re: allocate_string_data memory corruption,
Stefan Monnier <=
- Re: allocate_string_data memory corruption, Richard M. Stallman, 2006/01/24
- Re: allocate_string_data memory corruption, Kim F. Storm, 2006/01/24
- Re: allocate_string_data memory corruption, Chong Yidong, 2006/01/24
- Re: allocate_string_data memory corruption, Richard M. Stallman, 2006/01/25
- Re: allocate_string_data memory corruption, Chong Yidong, 2006/01/25
- Re: allocate_string_data memory corruption, Richard M. Stallman, 2006/01/26
- Re: allocate_string_data memory corruption, Stefan Monnier, 2006/01/26
- Re: allocate_string_data memory corruption, Chong Yidong, 2006/01/26
- Re: allocate_string_data memory corruption, Richard M. Stallman, 2006/01/28
- Re: allocate_string_data memory corruption, Stefan Monnier, 2006/01/28