all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Mark Oteiza <mvoteiza@udel.edu>
Cc: 21676@debbugs.gnu.org
Subject: bug#21676: 25.0.50; crash in code_convert_string
Date: Tue, 13 Oct 2015 17:55:21 +0300	[thread overview]
Message-ID: <83lhb6zuli.fsf@gnu.org> (raw)
In-Reply-To: <87eggzsprg.fsf@udel.edu>

> From: Mark Oteiza <mvoteiza@udel.edu>
> Date: Mon, 12 Oct 2015 18:09:23 -0400
> 
> I have no idea why this happened or how to reproduce.
> Perhaps related to bug#21602? In any case, here's a backtrace.

No, it doesn't seem to be related to 21602.  And it's not even a crash
in code_convert_string, it's an abort during GC, due to some
corruption in memory allocation data:

> #9  0x0000000000556d9d in shut_down_emacs (sig=6, stuff=0) at emacs.c:2018
> No locals.
> #10 0x00000000005548a8 in terminate_due_to_signal (sig=6, backtrace_limit=40)
>     at emacs.c:382
> No locals.
> #11 0x000000000057a231 in handle_fatal_signal (sig=6) at sysdep.c:1593
> No locals.
> #12 0x000000000057a202 in deliver_thread_signal (sig=6, 
>     handler=0x57a217 <handle_fatal_signal>) at sysdep.c:1567
>         old_errno = 6
> #13 0x000000000057a268 in deliver_fatal_thread_signal (sig=6) at sysdep.c:1605
> No locals.
> #14 <signal handler called>
> No symbol table info available.
> #15 0x00007f20158995f8 in raise () from /usr/lib/libc.so.6
> No symbol table info available.
> #16 0x00007f201589aa7a in abort () from /usr/lib/libc.so.6
> No symbol table info available.
> #17 0x00007f20158d805a in __libc_message () from /usr/lib/libc.so.6
> No symbol table info available.
> #18 0x00007f20158dd9a6 in malloc_printerr () from /usr/lib/libc.so.6
> No symbol table info available.
> #19 0x00007f20158de18e in _int_free () from /usr/lib/libc.so.6
> No symbol table info available.
> #20 0x00000000005d028b in xfree (block=0x40b8da0) at alloc.c:765
> No locals.
> #21 0x000000000067cebe in ftcrfont_close (font=0x462fd30) at ftcrfont.c:184
>         ftcrfont_info = 0x462fd30
>         i = 2
> #22 0x00000000005d2926 in cleanup_vector (vector=0x462fd30) at alloc.c:2971
>         drv = 0xc98da0
> #23 0x00000000005d2a6e in sweep_vectors () at alloc.c:3023
>         total_bytes = 48
>         free_this_block = false
>         nbytes = 48
>         block = 0x462fd00
>         bprev = 0x46630f8
>         lv = 0x661008 <balance_intervals+31>
>         lvprev = 0xc636f0
>         vector = 0x462fd00
>         next = 0x462fd30
> #24 0x00000000005d8e14 in gc_sweep () at alloc.c:6708
> No locals.
> #25 0x00000000005d6b5e in garbage_collect_1 (end=0x7ffeedb5a2f0) at alloc.c:5536
>         nextb = 0x0
>         stack_top_variable = 0 '\000'
>         i = 582
>         message_p = false
>         count = 26
>         start = {
>           tv_sec = 1444684638, 
>           tv_nsec = 913808806
>         }
>         retval = 0
>         tot_before = 0
>         total = {140732886524664, 83643444, 0, 3, 13157648, 7, 0, 140732886524608, 
>           5572695, 2, 140732886524800}
> #26 0x00000000005d718e in Fgarbage_collect () at alloc.c:5720
>         end = 0x7ffeedb5a2f0
> #27 0x00000000005526ca in maybe_gc () at lisp.h:4517
> No locals.

Emacs then tried to auto-save the session, and segfaulted during that,
probably because doing that during (a failed) GC is almost certainly
going to crash.





  reply	other threads:[~2015-10-13 14:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-12 22:09 bug#21676: 25.0.50; crash in code_convert_string Mark Oteiza
2015-10-13 14:55 ` Eli Zaretskii [this message]
2016-02-13 22:13   ` Mark Oteiza
2019-10-01 15:56     ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83lhb6zuli.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=21676@debbugs.gnu.org \
    --cc=mvoteiza@udel.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.