Random segfaults when using M-x.

Random segfaults when using M-x.

[Zack Piper]

I get the following backtrace (seemingly at random) when pressing M-x,
this happens sometimes 2 times a day, I didn't report a bug because I
couldn't reproduce it reliably, but it randomly happened 2 times just
now when trying to debug what was happening (both times during trying
to use M-x). Shall I try disecting my Emacs configuration
(https://github.com/zackp30/dotfiles) or wait to see if that's not
needed and it's a known bug?

```
$ sed -n 's/.*\[\(.*\)]$/\1/p' backtrace | addr2line -C -f -i -p -e $(which emacs)
emacs_backtrace at /home/zack/emacs/src/sysdep.c:2188
terminate_due_to_signal at /home/zack/emacs/src/emacs.c:374
handle_fatal_signal at /home/zack/emacs/src/sysdep.c:1604
deliver_thread_signal.constprop.6 at
/home/zack/emacs/src/sysdep.c:1578
handle_sigsegv at /home/zack/emacs/src/sysdep.c:1654
?? ??:0
turn_on_face at /home/zack/emacs/src/term.c:1902 (discriminator 3)
tty_write_glyphs at /home/zack/emacs/src/term.c:777
update_frame_line at /home/zack/emacs/src/dispnew.c:4832
update_frame_1 at /home/zack/emacs/src/dispnew.c:4534
update_frame at /home/zack/emacs/src/dispnew.c:3123
redisplay_internal at /home/zack/emacs/src/xdisp.c:13786
(discriminator 2)
read_char at /home/zack/emacs/src/keyboard.c:2544
read_key_sequence at /home/zack/emacs/src/keyboard.c:9156
command_loop_1 at /home/zack/emacs/src/keyboard.c:1407
internal_condition_case at /home/zack/emacs/src/eval.c:1350
command_loop_2 at /home/zack/emacs/src/keyboard.c:1140 (discriminator
1)
internal_catch at /home/zack/emacs/src/eval.c:1110
command_loop at /home/zack/emacs/src/keyboard.c:1111
recursive_edit_1 at /home/zack/emacs/src/keyboard.c:729
XUNTAG at /home/zack/emacs/src/lisp.h:844
(inlined by) XWINDOW at /home/zack/emacs/src/lisp.h:1010
(inlined by) read_minibuf at /home/zack/emacs/src/minibuf.c:684
Fread_from_minibuffer at /home/zack/emacs/src/minibuf.c:970
Ffuncall at /home/zack/emacs/src/eval.c:2748
exec_byte_code at /home/zack/emacs/src/bytecode.c:919
funcall_lambda at /home/zack/emacs/src/eval.c:2951
backtrace_debug_on_exit at /home/zack/emacs/src/eval.c:159
(inlined by) Ffuncall at /home/zack/emacs/src/eval.c:2791
exec_byte_code at /home/zack/emacs/src/bytecode.c:919
funcall_lambda at /home/zack/emacs/src/eval.c:2951
backtrace_debug_on_exit at /home/zack/emacs/src/eval.c:159
(inlined by) Ffuncall at /home/zack/emacs/src/eval.c:2791
exec_byte_code at /home/zack/emacs/src/bytecode.c:919
funcall_lambda at /home/zack/emacs/src/eval.c:2951
backtrace_debug_on_exit at /home/zack/emacs/src/eval.c:159
(inlined by) Ffuncall at /home/zack/emacs/src/eval.c:2791
exec_byte_code at /home/zack/emacs/src/bytecode.c:919
funcall_lambda at /home/zack/emacs/src/eval.c:2951
backtrace_debug_on_exit at /home/zack/emacs/src/eval.c:159
(inlined by) Ffuncall at /home/zack/emacs/src/eval.c:2791
exec_byte_code at /home/zack/emacs/src/bytecode.c:919
funcall_lambda at /home/zack/emacs/src/eval.c:2951
backtrace_debug_on_exit at /home/zack/emacs/src/eval.c:159
(inlined by) Ffuncall at /home/zack/emacs/src/eval.c:2791
SPECPDL_INDEX at /home/zack/emacs/src/lisp.h:2998
(inlined by) Ffuncall_interactively at
/home/zack/emacs/src/callint.c:246
Ffuncall at /home/zack/emacs/src/eval.c:2698
Fapply at /home/zack/emacs/src/eval.c:2341
```

Thanks!

-- 
Zack Piper <zack@apertron.net> http://apertron.net

Re: Random segfaults when using M-x.

[Zack Piper]

Gah! Forgot the extra details:

- Operating system: openSUSE 13.2.
- Emacs version: commit 58eeddf56bfd0492930395d601cc3f63bd9223c9
- Packages:

A *lot* I'll try and disect my config soon.

-- 
Zack Piper <zack@apertron.net> http://apertron.net

Re: Random segfaults when using M-x.

[Eli Zaretskii]

> Date: Fri, 5 Jun 2015 10:24:18 +0000
> From: Zack Piper <zack@apertron.net>
> 
> Gah! Forgot the extra details:

"M-x report-emacs-bug RET" would have reported them automagically ;-)

Re: Random segfaults when using M-x.

[Stephen Leake]

Zack Piper <zack@apertron.net> writes:

> I get the following backtrace (seemingly at random) when pressing M-x,
> this happens sometimes 2 times a day, I didn't report a bug because I
> couldn't reproduce it reliably, but it randomly happened 2 times just
> now when trying to debug what was happening (both times during trying
> to use M-x). 

I don't know if this is related, but I also get a random crash on
Windows.

When it happens, it is soon after starting Emacs, on the first use of
completion. I have (setq icomplete-show-matches-on-no-input t), so
completion is doing a lot of work after a short delay. I have not tried
disabling that to see if it helps, but I'll do that now.

If I wait some time (not clear how long), I don't get a crash on
completion. So there seems to be some race condition.

-- 
-- Stephe

Re: Random segfaults when using M-x.

[Przemysław Wojnowski]

> When it happens, it is soon after starting Emacs, on the first use of
> completion. I have (setq icomplete-show-matches-on-no-input t), so
> completion is doing a lot of work after a short delay. I have not tried
> disabling that to see if it helps, but I'll do that now.

I also had a crash once when doing completion. AFAIR it was just a word 
completion in an org-mode buffer. I has happened only once.
I run Emacs master on Kubuntu 15.04, so it seems not to be OS related.

Re: Random segfaults when using M-x.

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Fri, 05 Jun 2015 08:07:47 -0500
> 
> Zack Piper <zack@apertron.net> writes:
> 
> > I get the following backtrace (seemingly at random) when pressing M-x,
> > this happens sometimes 2 times a day, I didn't report a bug because I
> > couldn't reproduce it reliably, but it randomly happened 2 times just
> > now when trying to debug what was happening (both times during trying
> > to use M-x). 
> 
> I don't know if this is related, but I also get a random crash on
> Windows.

Please show a backtrace from running Emacs under GDB.

> If I wait some time (not clear how long), I don't get a crash on
> completion. So there seems to be some race condition.

Or a Heisenbug.

Re: Random segfaults when using M-x.

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stephen Leake <stephen_leake@stephe-leake.org>
>> Date: Fri, 05 Jun 2015 08:07:47 -0500
>> 
>> Zack Piper <zack@apertron.net> writes:
>> 
>> > I get the following backtrace (seemingly at random) when pressing M-x,
>> > this happens sometimes 2 times a day, I didn't report a bug because I
>> > couldn't reproduce it reliably, but it randomly happened 2 times just
>> > now when trying to debug what was happening (both times during trying
>> > to use M-x). 
>> 
>> I don't know if this is related, but I also get a random crash on
>> Windows.
>
> Please show a backtrace from running Emacs under GDB.

I'll try. Right now I'm playing with not showing all completions
immediately; no crashes yet, but it's too soon to tell.

-- 
-- Stephe

Re: Random segfaults when using M-x.

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Fri, 05 Jun 2015 08:07:47 -0500
> 
> I don't know if this is related, but I also get a random crash on
> Windows.

Does this happen in a GUI session or a text-mode session?

Re: Random segfaults when using M-x.

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stephen Leake <stephen_leake@stephe-leake.org>
>> Date: Fri, 05 Jun 2015 08:07:47 -0500
>> 
>> I don't know if this is related, but I also get a random crash on
>> Windows.
>
> Does this happen in a GUI session 

GUI; native Windows 7 64 bit.

-- 
-- Stephe

Re: Random segfaults when using M-x.

[Zack Piper]

I was using smex.el (which is backed by ido), but I use Helm for
everything else, perhaps there was a conflict?

I have since switched to helm-M-x. I have yet to get a crash now.

When using undo-tree.el I also get a segfault, but the backtrace
doesn't appear at all.


-- 
Zack Piper <zack@apertron.net> http://apertron.net

Re: Random segfaults when using M-x.

[Zack Piper]

> When using undo-tree.el I also get a segfault, but the backtrace
> doesn't appear at all.
> 

*sigh* Sorry for the noise, I meant to say:

When using undo-tree, and when I'm scrolling down the undo list fast
(holding down the key) I can (sometimes) get a segfault.

-- 
Zack Piper <zack@apertron.net> http://apertron.net

Re: Random segfaults when using M-x.

[Eli Zaretskii]

> Date: Fri, 5 Jun 2015 13:32:49 +0000
> From: Zack Piper <zack@apertron.net>
> 
> > When using undo-tree.el I also get a segfault, but the backtrace
> > doesn't appear at all.
> > 
> 
> *sigh* Sorry for the noise, I meant to say:
> 
> When using undo-tree, and when I'm scrolling down the undo list fast
> (holding down the key) I can (sometimes) get a segfault.

Please run Emacs under GDB, produce a backtrace when this happens, and
post all the info using "M-x report-emacs-bug RET".

Thanks.

Re: Random segfaults when using M-x.

[Zack Piper]

> Please run Emacs under GDB, produce a backtrace when this happens, and
> post all the info using "M-x report-emacs-bug RET".

Done, sorry for the delay I've been busy.

-- 
Zack Piper <zack@apertron.net> http://apertron.net

Re: Random segfaults when using M-x.

[Eli Zaretskii]

> Date: Fri, 5 Jun 2015 10:20:49 +0000
> From: Zack Piper <zack@apertron.net>
> 
> I get the following backtrace (seemingly at random) when pressing M-x,
> this happens sometimes 2 times a day, I didn't report a bug because I
> couldn't reproduce it reliably, but it randomly happened 2 times just
> now when trying to debug what was happening (both times during trying
> to use M-x). Shall I try disecting my Emacs configuration
> (https://github.com/zackp30/dotfiles) or wait to see if that's not
> needed and it's a known bug?

This is a strange backtrace: how come XUNTAG called recursive_edit_1?
I'm guessing this is because your binary is optimized, and so the
backtrace is not really reliable.

Can you rebuild Emacs without optimizations, preferably configured
with --enable-checking=yes, and run Emacs under GDB, so that we could
both catch the error before the crash and get a better backtrace?

Also, please report all this via "M-x report-emacs-bug RET", so that
it's recorded in the bug tracker.

Anyway, this cannot be due to your configuration, because the reason
for the crash is most probably an invalid NULL face, which should
never happen.

Thanks.