Re: SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu)

Re: SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu)

[Richard M. Stallman]

    > Please describe exactly what actions triggered the bug
    > and the precise symptoms of the bug:

    `<f1> k [Ctrl <tool-bar> <help>]'  (But it's not reproducible.)

    Program received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 182940272320 (LWP 4018)]
    x_catch_errors_unwind (dummy=9829361)
	at [...]/emacs/src/xterm.c:7530

The first question is, what was the immediate cause of the crash?
Could you please see what instruction crashed, and what data it was
looking at?

Maybe it was examining x_error_message->dpy.
What is the value of x_error_message?

Re: SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu)

[Reiner Steib]

On Mon, Feb 13 2006, Richard M. Stallman wrote:

>     > Please describe exactly what actions triggered the bug
>     > and the precise symptoms of the bug:
>
>     `<f1> k [Ctrl <tool-bar> <help>]'  (But it's not reproducible.)

Today I got another crash at the same point (using the same built as
before):

Program received signal SIGSEGV, Segmentation fault.
x_catch_errors_unwind (dummy=9829361)
    at [...]/emacs/src/xterm.c:7530
7530      Display *dpy = x_error_message->dpy;
(gdb) bt full
#0  x_catch_errors_unwind (dummy=9829361)
    at [...]/emacs/src/xterm.c:7530
        dpy = Variable "dpy" is not available.
(gdb) xbacktrace 
"face-attr-match-p"
"face-spec-match-p"
"frame-set-background-mode"
"x-create-frame-with-faces"
"make-frame"
"make-frame-command"
"call-interactively"
(gdb) 

>     Program received signal SIGSEGV, Segmentation fault.
>     [Switching to Thread 182940272320 (LWP 4018)]
>     x_catch_errors_unwind (dummy=9829361)
> 	at [...]/emacs/src/xterm.c:7530
>
> The first question is, what was the immediate cause of the crash?
> Could you please see what instruction crashed, and what data it was
> looking at?
>
> Maybe it was examining x_error_message->dpy.
> What is the value of x_error_message?

In both gdb sessions I get:

(gdb) p x_error_message
$1 = (struct x_error_message_stack *) 0x0
(gdb) pr
0
(gdb) p x_error_message->dpy
Cannot access memory at address 0xc8

(If this is not what you asked for, could you please tell me which gdb
command I should use?)

As I didn't have any crash since November [1] and now two crashes at
the same spot with the 2006-02-08 built, I suspect that one of these
changes (from Stefan) might trigger it:

,----
| revision 1.893
| date: 2006-01-23 22:08:13 +0000;  author: monnier;  state: Exp;  lines: +2 -1
| (x_catch_errors_unwind): Yet another int/Lisp_Object mixup.
| ----------------------------
| revision 1.892
| date: 2006-01-23 02:44:02 +0000;  author: monnier;  state: Exp;  lines: +36 -20
| Avoid allocating Lisp data from code that can be run from a signal handler.
| (x_error_message): New var to replace x_error_message_string.
| (x_error_catcher, x_catch_errors, x_catch_errors_unwind)
| (x_check_errors, x_had_errors_p, x_clear_errors, x_error_handler)
| (syms_of_xterm): Use it instead of x_error_message_string.
`----

Should I build again?  Should I enable additional checks
(ENABLE_CHECKING?)?

Bye, Reiner.

[1] http://thread.gmane.org/gmane.emacs.pretest.bugs/10235
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu)

[Stefan Monnier]

> As I didn't have any crash since November [1] and now two crashes at
> the same spot with the 2006-02-08 built, I suspect that one of these
> changes (from Stefan) might trigger it:

> ,----
> | revision 1.893
> | date: 2006-01-23 22:08:13 +0000;  author: monnier;  state: Exp;  lines: +2 -1
> | (x_catch_errors_unwind): Yet another int/Lisp_Object mixup.
> | ----------------------------
> | revision 1.892
> | date: 2006-01-23 02:44:02 +0000;  author: monnier;  state: Exp;  lines: +36 -20
> | Avoid allocating Lisp data from code that can be run from a signal handler.
> | (x_error_message): New var to replace x_error_message_string.
> | (x_error_catcher, x_catch_errors, x_catch_errors_unwind)
> | (x_check_errors, x_had_errors_p, x_clear_errors, x_error_handler)
> | (syms_of_xterm): Use it instead of x_error_message_string.
> `----

Indeed, it looks like a likely culprit :-(

> Should I build again?  Should I enable additional checks
> (ENABLE_CHECKING?)?

Yes, please try ENABLE_CHECKING.


        Stefan

Re: SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu)

[Richard M. Stallman]

He gave this crucial piece of information:

    In both gdb sessions I get:

    (gdb) p x_error_message
    $1 = (struct x_error_message_stack *) 0x0

>From that, can you see a bug in your code?

    (gdb) xbacktrace 
    "face-attr-match-p"

That ought to localize it pretty well too.

Re: SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu)

[Reiner Steib]

On Mon, Feb 13 2006, Stefan Monnier wrote:

>> Should I build again?  Should I enable additional checks
>> (ENABLE_CHECKING?)?
>
> Yes, please try ENABLE_CHECKING.

I updated and recompiled with ENABLE_CHECKING some days ago.  Now I
got another crash:

--8<---------------cut here---------------start------------->8---
Emacs fatal error: [...]/emacs/src/alloc.c:3212: assertion failed: !handling_signal

Breakpoint 1, abort ()
    at [...]/emacs/src/emacs.c:463
463     {
(gdb) bt full
#0  abort () at [...]/emacs/src/emacs.c:463
No locals.
#1  0x00000000005a2304 in die (msg=Variable "msg" is not available.
)   
    at [...]/emacs/src/alloc.c:6193
No locals.
#2  0x00000000005a6334 in Fmake_symbol (name=62320131)
    at [...]/emacs/src/alloc.c:3236
        val = Variable "val" is not available.
(gdb) xbacktrace
"read-event"
"byte-code"
"mouse-show-mark"
"mouse-drag-track"
"mouse-drag-region"
"call-interactively"
"widget-button-click"
"call-interactively"
(gdb) p x_error_message
$1 = (struct x_error_message_stack *) 0x0
(gdb) 
--8<---------------cut here---------------end--------------->8---

If I can provide more information, please tell me which gdb commands I
should use.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Reproducible crashes: dropping an URL (was: SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu))

[Reiner Steib]

On Fri, Feb 17 2006, Reiner Steib wrote:

> I updated and recompiled with ENABLE_CHECKING some days ago.  Now I
> got another crash:
[...]
> If I can provide more information, please tell me which gdb commands I
> should use.

I found out a recipe to reproduce the crash with a current trunk build
on both, x86_64 and i586:

- Start with `-Q'

- Open www.gnu.org in Firefox.

- Drag/drop any URL into Emacs' scratch buffer, e.g. "GNU Project".

=> crash.  (My 2006-01-27 built doesn't crash here.)

Nick, does this recipe crash your Emacs too?

Often `bt full' and `xbacktrace' didn't provide much output, if any.
Here is a gdb session on x86_64 with a quite verbose backtrace:

--8<---------------cut here---------------start------------->8---
GNU gdb 6.2.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-suse-linux"...Using host libthread_db library "/lib64/tls/libthread_db.so.1".

DISPLAY = :0.0
TERM = screen
Breakpoint 1 at 0x52f910: file [...]/emacs/src/emacs.c, line 463.
Breakpoint 2 at 0x558db0: file [...]/emacs/src/sysdep.c, line 1373.
(gdb) r -Q
Starting program: [...]/x86_64/src/emacs -Q
[Thread debugging using libthread_db enabled]
[New Thread 182940272320 (LWP 29178)]
[Switching to Thread 182940272320 (LWP 29178)]
Breakpoint 3 at 0x4fc280: file [...]/emacs/src/xterm.c, line 7814.

Emacs fatal error: [...]/emacs/src/alloc.c:3212: assertion failed: !handling_signal

Breakpoint 1, abort ()
    at [...]/emacs/src/emacs.c:463
463     {
(gdb) bt
#0  abort () at [...]/emacs/src/emacs.c:463
#1  0x00000000005a2304 in die (msg=Variable "msg" is not available.
)
    at [...]/emacs/src/alloc.c:6193
#2  0x00000000005a6334 in Fmake_symbol (name=16370227)
    at [...]/emacs/src/alloc.c:3236
#3  0x00000000005e6764 in Fintern (string=16370227, obarray=10809332)
    at [...]/emacs/src/lread.c:3218
#4  0x0000000000510cfb in x_atom_to_symbol (dpy=0xf63e40, atom=Variable "atom" is not available.
)
    at [...]/emacs/src/xselect.c:383
#5  0x00000000005113de in x_handle_dnd_message (f=0x10119c0, 
    event=0x7fbfffadc0, dpyinfo=Variable "dpyinfo" is not available.
)
    at [...]/emacs/src/xselect.c:2718
#6  0x0000000000500dfe in handle_one_xevent (dpyinfo=0xf99b10, 
    eventp=0x7fbfffb430, finish=0x9e67d4, hold_quit=0x7fbfffc7b0)
    at [...]/emacs/src/xterm.c:5846
#7  0x0000000000502fbc in event_handler_gdk (gxev=Variable "gxev" is not available.
)
    at [...]/emacs/src/xterm.c:5627
#8  0x0000002a95aa02b5 in gdk_event_apply_filters ()
   from /opt/gnome/lib64/libgdk-x11-2.0.so.0
#9  0x0000002a95aa1bf8 in gdk_event_translate ()
   from /opt/gnome/lib64/libgdk-x11-2.0.so.0
#10 0x0000002a95aa3041 in _gdk_events_queue ()
   from /opt/gnome/lib64/libgdk-x11-2.0.so.0
#11 0x0000002a95aa33fc in gdk_event_dispatch ()
   from /opt/gnome/lib64/libgdk-x11-2.0.so.0
#12 0x0000002a96623025 in g_main_context_dispatch ()
   from /opt/gnome/lib64/libglib-2.0.so.0
#13 0x0000002a96625669 in g_main_context_iterate ()
   from /opt/gnome/lib64/libglib-2.0.so.0
#14 0x0000002a96625763 in g_main_context_iteration ()
   from /opt/gnome/lib64/libglib-2.0.so.0
#15 0x0000002a9577e66f in gtk_main_iteration ()
   from /opt/gnome/lib64/libgtk-x11-2.0.so.0
#16 0x00000000004fc0ff in XTread_socket (sd=Variable "sd" is not available.
)
    at [...]/emacs/src/xterm.c:7057
#17 0x000000000053abc6 in read_avail_input (expected=1)
    at [...]/emacs/src/keyboard.c:6720
#18 0x000000000053ad6a in handle_async_input ()
    at [...]/emacs/src/keyboard.c:6863
#19 0x000000000053ae22 in input_available_signal (signo=29)
    at [...]/emacs/src/keyboard.c:6905
#20 <signal handler called>
#21 0x0000002a974a42a5 in __select_nocancel () from /lib64/tls/libc.so.6
#22 0x000000000060b1fe in wait_reading_process_output (time_limit=0, 
    microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=10808305, 
    wait_proc=0x0, just_wait_proc=0)
    at [...]/emacs/src/process.c:4490
#23 0x0000000000542bd6 in read_char (commandflag=1, nmaps=2, 
    maps=0x7fbfffd4e0, prev_event=10808305, used_mouse_menu=0x7fbfffd554)
    at [...]/emacs/src/keyboard.c:3940
#24 0x0000000000546e3b in read_key_sequence (keybuf=0x7fbfffd6f0, bufsize=30, 
    prompt=10808305, dont_downcase_last=0, can_return_switch_frame=1, 
    fix_current_buffer=1)
    at [...]/emacs/src/keyboard.c:8874
#25 0x000000000054a672 in command_loop_1 ()
    at [...]/emacs/src/keyboard.c:1536
#26 0x00000000005c3581 in internal_condition_case (
    bfun=0x54a3b0 <command_loop_1>, handlers=10901729, 
    hfun=0x540ed0 <cmd_error>)
    at [...]/emacs/src/eval.c:1465
#27 0x000000000053fcfa in command_loop_2 ()
    at [...]/emacs/src/keyboard.c:1328
#28 0x00000000005c36d0 in internal_catch (tag=Variable "tag" is not available.
)
    at [...]/emacs/src/eval.c:1211
#29 0x00000000005408f8 in command_loop ()
    at [...]/emacs/src/keyboard.c:1307
#30 0x0000000000540991 in recursive_edit_1 ()
    at [...]/emacs/src/keyboard.c:1000
#31 0x0000000000540b30 in Frecursive_edit ()
    at [...]/emacs/src/keyboard.c:1061
#32 0x0000000000530756 in main (argc=2, argv=0x7fbfffdf78)
    at [...]/emacs/src/emacs.c:1789
(gdb) xbacktrace 
(gdb) 
(gdb) p x_error_message
$1 = (struct x_error_message_stack *) 0x0
--8<---------------cut here---------------end--------------->8---

Here's is a gdb session on i586:

--8<---------------cut here---------------start------------->8---
GNU gdb 6.2.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-suse-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

DISPLAY = localhost:13.0
TERM = screen
Breakpoint 1 at 0x81612a6: file [...]/emacs/src/emacs.c, line 464.
Breakpoint 2 at 0x8187b19: file [...]/emacs/src/sysdep.c, line 1393.
(gdb) r -Q
Starting program: [...]/i686/src/emacs -Q
[Thread debugging using libthread_db enabled]
[New Thread 1083362592 (LWP 28407)]
[Switching to Thread 1083362592 (LWP 28407)]
Breakpoint 3 at 0x812fdfc: file [...]/emacs/src/xterm.c, line 7820.

Emacs fatal error: [...]/emacs/src/alloc.c:3212: assertion failed: !handling_signal

Breakpoint 1, abort ()
    at [...]/emacs/src/emacs.c:464
464       kill (getpid (), SIGABRT);
(gdb) bt full
#0  abort () at [...]/emacs/src/emacs.c:464
No locals.
#1  0x081cdb1b in die (msg=0x82a9e00 "assertion failed: !handling_signal", 
    file=0x82a9614 "[...]/emacs/src/alloc.c", line=3212) at [...]/emacs/src/alloc.c:6193
No locals.
#2  0x081d15d5 in Fmake_symbol (name=146264523)
    at [...]/emacs/src/alloc.c:3236
        val = Variable "val" is not available.
(gdb) xbacktrace 
(gdb) p x_error_message
$1 = (struct x_error_message_stack *) 0x0
(gdb) 
--8<---------------cut here---------------end--------------->8---

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Reproducible crashes: dropping an URL

[Stefan Monnier]

> I found out a recipe to reproduce the crash with a current trunk build
> on both, x86_64 and i586:
> - Start with `-Q'
> - Open www.gnu.org in Firefox.
> - Drag/drop any URL into Emacs' scratch buffer, e.g. "GNU Project".
> => crash.  (My 2006-01-27 built doesn't crash here.)
[...]
> Emacs fatal error: [...]/emacs/src/alloc.c:3212: assertion failed: !handling_signal

Try the patch below (which I just installed).


        Stefan


--- alloc.c	17 Feb 2006 10:49:33 -0500	1.390
+++ alloc.c	17 Feb 2006 10:59:16 -0500	
@@ -3209,7 +3209,7 @@
 
   CHECK_STRING (name);
 
-  eassert (!handling_signal);
+  /* eassert (!handling_signal); */
 
 #ifndef SYNC_INPUT
   BLOCK_INPUT;

Reproducible crashes: dropping an URL (was: SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu))

[Nick Roberts]

Reiner Steib writes:
 > On Fri, Feb 17 2006, Reiner Steib wrote:
 > 
 > > I updated and recompiled with ENABLE_CHECKING some days ago.  Now I
 > > got another crash:
 > [...]
 > > If I can provide more information, please tell me which gdb commands I
 > > should use.
 > 
 > I found out a recipe to reproduce the crash with a current trunk build
 > on both, x86_64 and i586:
 > 
 > - Start with `-Q'
 > 
 > - Open www.gnu.org in Firefox.
 > 
 > - Drag/drop any URL into Emacs' scratch buffer, e.g. "GNU Project".
 > 
 > => crash.  (My 2006-01-27 built doesn't crash here.)
 > 
 > Nick, does this recipe crash your Emacs too?

No, but I haven't recompiled with ENABLE_CHECKING.  Should I?


-- 
Nick                                           http://www.inet.net.nz/~nickrob

SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu) (was: Reproducible crashes: dropping an URL)

[Reiner Steib]

On Fri, Feb 17 2006, Stefan Monnier wrote:

>> - Drag/drop any URL into Emacs' scratch buffer, e.g. "GNU Project".
>> => crash.  (My 2006-01-27 built doesn't crash here.)
> [...]
>> Emacs fatal error: [...]/emacs/src/alloc.c:3212: assertion failed: !handling_signal
>
> Try the patch below (which I just installed).
[...]
> -  eassert (!handling_signal);
> +  /* eassert (!handling_signal); */

I recompiled with this change on 2006-02-17.  I can't reproduce the
Drag/drop crash anymore.  

Today I got another "x_error_message == 0x0" crash:

--8<---------------cut here---------------start------------->8---
Program received signal SIGSEGV, Segmentation fault.
0x00000000004fe8b0 in x_catch_errors_unwind (dummy=20426868)
    at [...]/emacs/src/xterm.c:7543
warning: Source file is more recent than executable.

7543      Display *dpy = x_error_message->dpy;
(gdb) bt full
#0  0x00000000004fe8b0 in x_catch_errors_unwind (dummy=20426868)
    at [...]/emacs/src/xterm.c:7543
        dpy = Variable "dpy" is not available.
(gdb) xbacktrace 
(gdb) p x_error_message
$1 = (struct x_error_message_stack *) 0x0
(gdb) 
--8<---------------cut here---------------end--------------->8---

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu)

[Stefan Monnier]

> I recompiled with this change on 2006-02-17.  I can't reproduce the
> Drag/drop crash anymore.  

Good.

> Today I got another "x_error_message == 0x0" crash:

> --8<---------------cut here---------------start------------->8---
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000004fe8b0 in x_catch_errors_unwind (dummy=20426868)
>     at [...]/emacs/src/xterm.c:7543
> warning: Source file is more recent than executable.

> 7543      Display *dpy = x_error_message->dpy;
> (gdb) bt full
> #0  0x00000000004fe8b0 in x_catch_errors_unwind (dummy=20426868)
>     at [...]/emacs/src/xterm.c:7543
>         dpy = Variable "dpy" is not available.
> (gdb) xbacktrace 
> (gdb) p x_error_message
> $1 = (struct x_error_message_stack *) 0x0
> (gdb) 
> --8<---------------cut here---------------end--------------->8---

What's the C backtrace?


        Stefan

Re: SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu)

[Reiner Steib]

On Mon, Feb 20 2006, Stefan Monnier wrote:

>> --8<---------------cut here---------------start------------->8---
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00000000004fe8b0 in x_catch_errors_unwind (dummy=20426868)
>>     at [...]/emacs/src/xterm.c:7543
>> warning: Source file is more recent than executable.
>
>> 7543      Display *dpy = x_error_message->dpy;
>> (gdb) bt full
>> #0  0x00000000004fe8b0 in x_catch_errors_unwind (dummy=20426868)
>>     at [...]/emacs/src/xterm.c:7543
>>         dpy = Variable "dpy" is not available.
>> (gdb) xbacktrace 
>> (gdb) p x_error_message
>> $1 = (struct x_error_message_stack *) 0x0
>> (gdb) 
>> --8<---------------cut here---------------end--------------->8---
>
> What's the C backtrace?

Sorry, I thought `bt full' (as suggested by `report-emacs-bug') would
print the full C backtrace.

--8<---------------cut here---------------start------------->8---
(gdb) backtrace 
#0  0x00000000004fe8b0 in x_catch_errors_unwind (dummy=20426868)
    at [...]/emacs/src/xterm.c:7543
#1  0x00000000005c24f7 in unbind_to (count=5, value=10808305)
    at [...]/emacs/src/eval.c:3233
#2  0x000000000048a34d in display_mode_line (w=Variable "w" is not available.
)
    at [...]/emacs/src/xdisp.c:16231
#3  0x000000000048a818 in display_mode_lines (w=0x246f610)
    at [...]/emacs/src/xdisp.c:16177
#4  0x00000000004993d1 in redisplay_window (window=38204948, just_this_one_p=0)
    at [...]/emacs/src/xdisp.c:13019
#5  0x000000000049b6bd in redisplay_window_0 (window=Variable "window" is not available.
)
    at [...]/emacs/src/xdisp.c:11450
#6  0x00000000005c3268 in internal_condition_case_1 (
    bfun=0x49b690 <redisplay_window_0>, arg=38204948, handlers=10790613, 
    hfun=0x463270 <redisplay_window_error>)
    at [...]/emacs/src/eval.c:1506
#7  0x000000000047ce6f in redisplay_windows (window=38204948)
    at [...]/emacs/src/xdisp.c:11429
#8  0x000000000047cddb in redisplay_windows (window=50459380)
    at [...]/emacs/src/xdisp.c:11423
#9  0x00000000004901d5 in redisplay_internal (preserve_echo_area=Variable "preserve_echo_area" is not available.
)
    at [...]/emacs/src/xdisp.c:10989
#10 0x0000000000542436 in read_char (commandflag=1, nmaps=7, 
    maps=0x7fbfffd490, prev_event=10808305, used_mouse_menu=0x7fbfffd534)
    at [...]/emacs/src/keyboard.c:2549
#11 0x0000000000546e7b in read_key_sequence (keybuf=0x7fbfffd6d0, bufsize=30, 
    prompt=10808305, dont_downcase_last=0, can_return_switch_frame=1, 
    fix_current_buffer=1)
    at [...]/emacs/src/keyboard.c:8874
#12 0x000000000054a6b2 in command_loop_1 ()
    at [...]/emacs/src/keyboard.c:1536
#13 0x00000000005c3581 in internal_condition_case (
    bfun=0x54a3f0 <command_loop_1>, handlers=10901729, 
    hfun=0x540f10 <cmd_error>)
    at [...]/emacs/src/eval.c:1465
#14 0x000000000053fd3a in command_loop_2 ()
    at [...]/emacs/src/keyboard.c:1328
#15 0x00000000005c36d0 in internal_catch (tag=Variable "tag" is not available.
)
    at [...]/emacs/src/eval.c:1211
#16 0x0000000000540938 in command_loop ()
    at [...]/emacs/src/keyboard.c:1307
#17 0x00000000005409d1 in recursive_edit_1 ()
    at [...]/emacs/src/keyboard.c:1000
#18 0x0000000000540b70 in Frecursive_edit ()
    at [...]/emacs/src/keyboard.c:1061
#19 0x0000000000530796 in main (argc=5, argv=0x7fbfffdf58)
    at [...]/emacs/src/emacs.c:1789
--8<---------------cut here---------------end--------------->8---

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu)

[Chong Yidong]

If these crashes are caused by the changes made to avoid allocating
lisp strings in the x error handler, maybe we can just go back to the
old system, since we now block input in the allocation functions.

Re: SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu)

[Richard M. Stallman]

I think I fixed the x_error_message problem yesterday
with a change in xterm.c.

Re: SEGV in x_catch_errors_unwind (x86_64-unknown-linux-gnu)

[Richard M. Stallman]

    If these crashes are caused by the changes made to avoid allocating
    lisp strings in the x error handler, maybe we can just go back to the
    old system, since we now block input in the allocation functions.

Perhaps so, but first, let's see if my small fix fixed it.