GNU bug report logs -
#28430
26.0.50; Segfault on unexpected connection loss
Previous Next
Reported by: Daniel Kraus <daniel <at> kraus.my>
Date: Tue, 12 Sep 2017 06:43:01 UTC
Severity: normal
Found in version 26.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #17 received at 28430 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Daniel Kraus <daniel <at> kraus.my>
>> Cc: 28430 <at> debbugs.gnu.org
>> 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
This bug report was last modified 7 years and 336 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.