From: Eli Zaretskii <eliz@gnu.org>
To: ams@gnu.org
Cc: emacs-devel@gnu.org
Subject: Re: emacs from head segfaults when run with -nw
Date: Mon, 05 Apr 2010 17:06:41 +0300 [thread overview]
Message-ID: <837homyowe.fsf@gnu.org> (raw)
In-Reply-To: <E1NymSB-00036u-Oe@fencepost.gnu.org>
> From: "Alfred M. Szmidt" <ams@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Mon, 05 Apr 2010 09:34:59 -0400
>
> > When I start emacs with -nw, it segfaults, if I run with -Q it
> > segfaults in a different place,
>
> Does this still happen with current bzr, and after you make a clean
> bootstrap? If so, could you please post a backtrace from the
> segfault you get in "emacs -Q"?
>
> Tried a clean bootstrap today, still get the segfault with -nw -Q:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x081692bd in mark_object (arg=-7552029) at alloc.c:5595
> 5595 if (XMISCANY (obj)->gcmarkbit)
> (gdb) bt full
> #0 0x081692bd in mark_object (arg=-7552029) at alloc.c:5595
> obj = -7552029
> cdr_count = <value optimized out>
Thanks. It's different from what I see, but given that this seems to
be a Heisenbug (it disappears in a non-optimized build), perhaps it is
not surprising.
Can you see if this is the first GC since startup? It is for me: if
I set a breakpoint in Fgarbage_collect, it breaks only once, and if I
let Emacs continue from there, it crashes in a subroutine of GC.
Also, do you get the crash in a non-optimized (-O0) build? It's hard
to do anything with all those "value optimized out" variables.
If a non-optimized build does not crash, the only way I know of to
find out which data structure is invalid is by stepping with GDB
through a non-optimized build, trying to match the frames and local
variables that do appear in the backtrace of the crashed Emacs, and
compare the values between the optimized and non-optimized builds to
see what got corrupted.
In my case, I found so far that one of the submaps of
Buffer-menu-mode-map is corrupted (a NULL pointer):
#2 0x01068682 in mark_char_table (ptr=0x2fee200) at alloc.c:5393
5393 mark_char_table (XVECTOR (val));
(gdb) p *ptr
$33 = {
size = 3222274066,
next = 0x2ff3000,
contents = {4}
}
(gdb) p ptr->contents[0]
$34 = 4
(gdb) p size
$35 = 18
(gdb) p ptr->contents[1]
$36 = 0
(gdb) p ptr->contents[2]
$37 = 50252549
(gdb) xtype
Lisp_Vectorlike
PVEC_SUB_CHAR_TABLE
(gdb) xvector
$38 = (struct Lisp_Vector *) 0x0 <<<<<<<<<<<<<<<<
Cannot access memory at address 0x0 <<<<<<<<<<<<<<<<
(gdb)
whereas in a non-optimized build, the same submap seems to be okay:
#1 0x0102b3f0 in mark_char_table (ptr=0x3019200) at alloc.c:5393
5393 mark_char_table (XVECTOR (val));
(gdb) p size
$31 = 18
(gdb) p i
$32 = 2
(gdb) p ptr->contents[0]
$33 = 4
(gdb) p ptr->contents[1]
$34 = 0
(gdb) p ptr->contents[2]
$35 = 50404101
(gdb) xtype
Lisp_Vectorlike
PVEC_SUB_CHAR_TABLE
(gdb) xvector
$36 = (struct Lisp_Vector *) 0x3011b00
0
(gdb) p *$36
$37 = {
size = 3222274082,
next = 0x3019200,
contents = {8}
}
(gdb)
next prev parent reply other threads:[~2010-04-05 14:06 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-02 19:02 emacs from head segfaults when run with -nw Alfred M. Szmidt
2010-04-02 20:49 ` Dan Nicolaescu
2010-04-02 23:07 ` Juri Linkov
2010-04-02 23:48 ` Dan Nicolaescu
2010-04-03 10:42 ` Alfred M. Szmidt
2010-04-03 19:19 ` Dan Nicolaescu
2010-04-03 22:12 ` Juri Linkov
2010-04-03 23:56 ` Ken Hori
2010-04-04 11:06 ` Juri Linkov
2010-04-04 8:10 ` Jan Djärv
2010-04-05 17:22 ` Dan Nicolaescu
2010-04-14 15:05 ` Randal L. Schwartz
2010-04-18 2:35 ` Randal L. Schwartz
2010-04-18 3:05 ` Randal L. Schwartz
2010-04-05 9:04 ` Eli Zaretskii
2010-04-05 13:34 ` Alfred M. Szmidt
2010-04-05 14:06 ` Eli Zaretskii [this message]
2010-04-05 15:03 ` Alfred M. Szmidt
2010-04-05 15:24 ` Eli Zaretskii
2010-04-06 21:08 ` Alfred M. Szmidt
2010-04-07 3:06 ` Eli Zaretskii
2010-04-08 20:03 ` Alfred M. Szmidt
2010-04-05 16:49 ` Eli Zaretskii
2010-04-05 16:59 ` Juri Linkov
2010-04-05 21:39 ` Eli Zaretskii
2010-04-06 0:41 ` Stefan Monnier
2010-04-05 13:52 ` Stefan Monnier
2010-04-05 14:17 ` Eli Zaretskii
2010-04-05 20:00 ` Sean Sieger
2010-04-05 21:49 ` Eli Zaretskii
2010-04-06 18:49 ` Andreas Schwab
2010-04-07 3:25 ` Eli Zaretskii
2010-04-07 3:57 ` Stefan Monnier
2010-04-07 5:35 ` Eli Zaretskii
2010-04-07 11:11 ` Juanma Barranquero
2010-04-09 11:10 ` Eli Zaretskii
2010-04-10 1:25 ` Stefan Monnier
2010-04-05 14:11 ` Chong Yidong
2010-04-05 14:19 ` Eli Zaretskii
2010-04-16 14:18 ` Juanma Barranquero
2010-04-16 21:06 ` Eli Zaretskii
2010-04-16 23:18 ` Juanma Barranquero
2010-04-17 7:55 ` Eli Zaretskii
2010-04-17 16:19 ` Juanma Barranquero
2010-04-17 16:37 ` Eli Zaretskii
2010-04-17 19:12 ` Juanma Barranquero
2010-04-17 19:18 ` Eli Zaretskii
2010-04-17 19:20 ` Juanma Barranquero
2010-04-17 21:02 ` Eli Zaretskii
2010-04-16 8:26 ` Sascha Wilde
2010-04-16 21:01 ` Eli Zaretskii
2010-04-17 10:28 ` Sascha Wilde
2010-04-17 12:39 ` Eli Zaretskii
2010-04-17 18:49 ` Sascha Wilde
2010-04-19 12:31 ` Eli Zaretskii
2010-04-20 10:30 ` Sascha Wilde
2010-04-20 12:03 ` Eli Zaretskii
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=837homyowe.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=ams@gnu.org \
--cc=emacs-devel@gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).