emacs-devel
[Top][All Lists]
Advanced

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

Re: "corrupted size vs. prev_size"


From: Lars Ingebrigtsen
Subject: Re: "corrupted size vs. prev_size"
Date: Tue, 12 Apr 2022 13:45:02 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Hm.

And I've now managed to catch a backtrace in gdb twice.  The error
happens here both times:

__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x00007ffff52b7546 in __GI_abort () at abort.c:79
#2  0x00007ffff530eeb8 in __libc_message
    (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff542ca78 "%s\n")
    at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007ffff531691a in malloc_printerr
    (str=str@entry=0x7ffff542a714 "corrupted size vs. prev_size")
    at malloc.c:5628
#4  0x00007ffff5317816 in unlink_chunk
    (p=p@entry=0x55557db01da0, av=0x7ffff5463ba0 <main_arena>) at malloc.c:1608
#5  0x00007ffff531806b in _int_free
    (av=0x7ffff5463ba0 <main_arena>, p=0x55557da7efd0, have_lock=<optimized 
out>) at malloc.c:4575
#6  0x00007ffff531b9b4 in __GI___libc_free (mem=<optimized out>)
    at malloc.c:3309
#7  0x00007ffff7223a0f in  () at /lib/x86_64-linux-gnu/libcairo.so.2
#8  0x00007ffff728349f in cairo_surface_destroy ()
    at /lib/x86_64-linux-gnu/libcairo.so.2
#9  0x00007ffff725f340 in cairo_pattern_destroy ()
    at /lib/x86_64-linux-gnu/libcairo.so.2
#10 0x00005555557de342 in image_clear_image_1
    (flags=7, img=<optimized out>, f=0x555555fde088) at image.c:1684
#11 image_clear_image (img=0x55556eb958d0, f=0x555555fde088) at image.c:1696
#12 gif_clear_image (f=0x555555fde088, img=0x55556eb958d0) at image.c:8610
#13 0x00005555557dc80c in free_image
    (f=f@entry=0x555555fde088, img=0x55556eb958d0) at image.c:1366
#14 0x00005555557def4f in clear_image_cache
    (f=0x555555fde088, filter=filter@entry=0x0) at image.c:1943
#15 0x00005555557e7319 in clear_image_caches (filter=filter@entry=0x0)
    at image.c:1981
#16 0x00005555555f7387 in redisplay_internal () at xdisp.c:16825
#17 0x00005555555f7c45 in redisplay_preserve_echo_area
    (from_where=from_where@entry=8) at xdisp.c:16878
#18 0x00005555556ca78e in detect_input_pending_run_timers
    (do_display=do_display@entry=true) at keyboard.c:10758
#19 0x000055555579d98a in wait_reading_process_output
    (time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, 
read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, 
wait_for_cell=wait_for_cell@entry=0x0, wait_proc=wait_proc@entry=0x0, 
just_wait_proc=0) at process.c:5695
#20 0x00005555555b14c0 in sit_for
    (timeout=timeout@entry=0x7a, reading=reading@entry=true, 
display_option=display_option@entry=1) at dispnew.c:6154
#21 0x00005555556cd11b in read_char
    (commandflag=1, map=0x55556e8c9b33, prev_event=0x0, 
used_mouse_menu=0x7fffffffdb8b, end_time=0x0) at 
/home/larsi/src/emacs/trunk/src/lisp.h:753
#22 0x00005555556cd899 in read_key_sequence

That may just be because I'm doing out-of-bounds writes somewhere, but
it's odd that it happened the same place both times, perhaps.  Hm.  Does
this suggest anything to anybody?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



reply via email to

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