bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#28430: 26.0.50; Segfault on unexpected connection loss


From: Daniel Kraus
Subject: bug#28430: 26.0.50; Segfault on unexpected connection loss
Date: Thu, 14 Sep 2017 10:27:08 +0800

Eli Zaretskii <address@hidden> writes:

>> From: Daniel Kraus <address@hidden>
>> Cc: address@hidden
>> Date: Wed, 13 Sep 2017 17:12:14 +0800
>>
>> >> Open new buffer (e.g. 'test.rest') and `M-x restclient-mode`.
>> >> Type:
>> >> `GET http://127.0.0.1:6543/`
>> >> and then press `C-c C-c`
>> >>
>> >> Switch to the netcat window and Ctrl-C to break up the connection.
>> >> Emacs segfaults:
>> >> #+BEGIN_QUOTE
>> >> Fatal error 11: Segmentation fault
>> >
>> > Can you please run this under GDB, and when Emacs segfaults, produce
>> > the C backtrace and post it here?
>>
>> --cut--
>> #0  0x00007ffff017bc40 in raise () at /usr/lib/libpthread.so.0
>> #1  0x0000000000597ab9 in terminate_due_to_signal (sig=6, 
>> backtrace_limit=2147483647) at emacs.c:394
>> #2  0x0000000000632a74 in die (msg=0x778761 "CONSP (data)", file=0x7786d1 
>> "keyboard.c", line=999) at alloc.c:7419
>> #3  0x000000000059c3e1 in cmd_error_internal (data=..., context=0x798c6c 
>> "error in process sentinel: ") at keyboard.c:999
>> #4  0x00000000006c5edd in exec_sentinel_error_handler (error_val=...) at 
>> process.c:7105
>> #5  0x0000000000657d51 in internal_condition_case_1 (bfun=0x6c2b0d 
>> <read_process_output_call>, arg=..., handlers=..., hfun=0x6c5ebe 
>> <exec_sentinel_error_handler>) at eval.c:1352
>> #6  0x00000000006c609c in exec_sentinel (proc=..., reason=...) at 
>> process.c:7158
>> #7  0x00000000006c6303 in status_notify (deleting_process=0x0, 
>> wait_proc=0x0) at process.c:7260
>
> Thanks.  This seems to be a slightly different problem: the signal
> here is 6 (SIGABRT), not SIGSEGV.

Before I had Emacs compiled with compiler optimisations and stripped debug 
symbols.. maybe that's why?


> In any case, can you show what these GDB commands produce, after the
> crash is triggered, and you wind up in 'raise'?
>
>  (gdb) frame 4
>  (gdb) pp error_val
>
> After "frame 4", you should be in this function:
>
>    #4  0x00000000006c5edd in exec_sentinel_error_handler (error_val=...) at 
> process.c:7105
>
> If not, adjust the argument 4 as needed.

Hmm, not sure that's what you're looking for.
`pp` gave `Undefined command`. I started gdb from another Emacs instance
like described in the DEBUG document if that matters.

--cut--

(gdb) r
Starting program: 
/home/daniel/repos/emacs-git/src/emacs-git/src/bootstrap-emacs -Q
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffe5694700 (LWP 9879)]
[New Thread 0x7fffdffff700 (LWP 9880)]
[New Thread 0x7fffdf670700 (LWP 9881)]
[New Thread 0x7fffe402ca40 (LWP 10179)]
[Thread 0x7fffe402ca40 (LWP 10179) exited]

Thread 1 "bootstrap-emacs" received signal SIGABRT, Aborted.
0x00007ffff017bc40 in raise () from /usr/lib/libpthread.so.0
(gdb) frame 4
#4  0x00000000006c5edd in exec_sentinel_error_handler (error_val=...) at 
process.c:7105
7105      cmd_error_internal (error_val, "error in process sentinel: ");
(gdb) pp error_val
Undefined command: "pp".  Try "help".
(gdb) print error_val
$1 = {i = 0}

--cut--

Let me know if/how I should further investigate.

Thanks,
  Daniel





reply via email to

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