connecting to a lost server process

connecting to a lost server process

[Madhu]

I'm having problems with the behaviour of emacs --daemon.  Under some
circumstances when the emacsclient -t dies (say when the GNU screen
dungeon collapses), The server file and server directory gets
unexpectedly deleted.  In this case the server is left running but one
cannot connect to it.

The socket is still open as can be seen in /proc/<emacspid>/fd/ - is
there some linux arcana that can be exploited to connect to it?

Earlier it used to be possible to gdb attach to the emacs process and
to restart the server. Something like
Feval(Fcar(Fread_from_string(build_string("(server-start)"),Qnil,Qnil)),Qnil)
But for some time now that route hits a
terminate_due_to_signal. (Apparently make-network-process tries to
signal an error which calls emacs_abort which ends the show)

[Unfortunately recently the robustness of the server mechanism has gone
down - (especially since elogind).  Typically I set
XDG_RUNTIME_DIR=/dev/shm/<username> in my environment and start a
server which i expect to survive restarts in dbus, elogind etc.  That
seems no longer possible even when using a --without-x emacs.]

Re: connecting to a lost server process

[Eli Zaretskii]

> Date: 12 Jul 2019 06:20:57 -0000
> From: Madhu <enometh@meer.net>
> 
> The socket is still open as can be seen in /proc/<emacspid>/fd/ - is
> there some linux arcana that can be exploited to connect to it?
> 
> Earlier it used to be possible to gdb attach to the emacs process and
> to restart the server. Something like
> Feval(Fcar(Fread_from_string(build_string("(server-start)"),Qnil,Qnil)),Qnil)
> But for some time now that route hits a
> terminate_due_to_signal. (Apparently make-network-process tries to
> signal an error which calls emacs_abort which ends the show)

Please report a bug with the details of that crash, it may or may not
be a bug.

> [Unfortunately recently the robustness of the server mechanism has gone
> down - (especially since elogind).  Typically I set
> XDG_RUNTIME_DIR=/dev/shm/<username> in my environment and start a
> server which i expect to survive restarts in dbus, elogind etc.  That
> seems no longer possible even when using a --without-x emacs.]

Did you try to bind a function to sigusr1 or sigusr2 event, and have
that function restore the server file?

bug#36648: emacs signals under gdb - [Re: connecting to a lost server process

[Madhu]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

[sorry if this is not the correct bug format, I'm replying to a message
on gnu.emacs.help]

* Eli Zaretskii <mailman.985.1562918079.2688.help-gnu-emacs@gnu.org> :
Wrote on Fri, 12 Jul 2019 10:54:28 +0300:

>> Date: 12 Jul 2019 06:20:57 -0000
>> From: Madhu <enometh@meer.net>
>>
>> Earlier it used to be possible to gdb attach to the emacs process and
>> to restart the server. Something like
>> Feval(Fcar(Fread_from_string(build_string("(server-start)"),Qnil,Qnil)),Qnil)
>> But for some time now that route hits a
>> terminate_due_to_signal. (Apparently make-network-process tries to
>> signal an error which calls emacs_abort which ends the show)
>
> Please report a bug with the details of that crash, it may or may not
> be a bug.

I noticed a couple of different failure modes but this problem seems to
be related to pselect.  I'm appending one backtrace. Note within the
transcript emacs is started with

args:  -Q --eval '(progn (load-library "custom") (load-library "server") (setq server-name "emacs-test"))'

After emacs is started by gdb I send it a TSTP to make it enter the
debugger.


[-- Attachment #2: gdb backtrace --]
[-- Type: text/plain, Size: 9607 bytes --]

Reading symbols from emacs-27-athena...
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = :0
TERM = dumb
Breakpoint 1 at 0x41657c: file /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/emacs.c, line 377.
Breakpoint 2 at 0x4c4b20: file /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/xterm.c, line 10041.

(gdb) set args  -Q --eval '(progn (load-library "custom") (load-library "server") (setq server-name "emacs-test"))'

(gdb) r
Starting program: /usr/bin/emacs-27-athena -Q --eval '(progn (load-library "custom") (load-library "server") (setq server-name "emacs-test"))'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
desired fingerprint: 4f725133cab4014b55eba47d01b62b95cf9f5c2332a7167947770875a0da328e
found fingerprint: 87155434115e758f6db5abaf07c65b6b14264b02baec22545448e62abb35872f
[New Thread 0x7ffff4b5b700 (LWP 10762)]

Thread 1 "emacs-27-athena" received signal SIGTSTP, Stopped (user).
0x00007ffff6b47926 in __pselect (nfds=7, readfds=0x7fffffffcf50, 
    writefds=0x7fffffffcfd0, exceptfds=0x0, timeout=<optimized out>, 
    sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:69
69	  result = CALL_PSELECT6 (nfds, readfds, writefds, exceptfds, timeout,

(gdb) p Feval(Fcar(Fread_from_string(build_string("(server-start)"),Qnil,Qnil)),Qnil)

Thread 1 "emacs-27-athena" hit Breakpoint 1, terminate_due_to_signal (
    sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/emacs.c:377
377	
The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(Feval) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) back
#0  terminate_due_to_signal (sig=sig@entry=6, 
    backtrace_limit=backtrace_limit@entry=40)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/emacs.c:377
#1  0x0000000000416a50 in emacs_abort ()
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/sysdep.c:2437
#2  0x0000000000418a90 in signal_or_quit (error_symbol=XIL(0x58e0), 
    data=XIL(0xdd5663), keyboard_quit=<optimized out>)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/eval.c:1595
#3  0x0000000000418aa9 in Fsignal (error_symbol=<optimized out>, 
    data=data@entry=XIL(0xdd5663))
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/eval.c:1565
#4  0x0000000000417118 in xsignal (data=XIL(0xdd5663), 
    error_symbol=<optimized out>)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/lisp.h:4101
#5  report_file_errno (string=<optimized out>, name=name@entry=XIL(0xdd55f3), 
    errorno=<optimized out>)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/fileio.c:222
#6  0x000000000041a663 in connect_network_socket (proc=XIL(0xd7f415), 
    addrinfos=<optimized out>, use_external_socket_p=<optimized out>)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/process.c:3633
#7  0x00000000005a2cc6 in Fmake_network_process (nargs=<optimized out>, 
    args=<optimized out>)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/process.c:4246
#8  0x000000000055f533 in Ffuncall (nargs=11, args=args@entry=0x7fffffffc298)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/lisp.h:2087
#9  0x0000000000599e60 in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=<optimized out>, 
    args=<optimized out>)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/bytecode.c:633
#10 0x000000000055f4bf in Ffuncall (nargs=2, args=args@entry=0x7fffffffc688)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/eval.c:2817
#11 0x0000000000599e60 in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=<optimized out>, 
    args=<optimized out>)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/bytecode.c:633
#12 0x0000000000560ec1 in apply_lambda (fun=XIL(0xaee9f5), 
    args=<optimized out>, count=count@entry=6)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/eval.c:2935
#13 0x00000000005611f3 in eval_sub (form=<optimized out>)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/eval.c:2349
#14 0x0000000000562d89 in Feval (form=XIL(0xdd5543), lexical=<optimized out>)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/eval.c:2103
#15 <function called from gdb>
#16 0x00007ffff6b47926 in __pselect (nfds=7, readfds=0x7fffffffcf50, 
    writefds=0x7fffffffcfd0, exceptfds=0x0, timeout=<optimized out>, 
    sigmask=<optimized out>) at ../sysdeps/unix/sysv/linux/pselect.c:69
#17 0x00000000005bead0 in really_call_select (arg=0x7fffffffce80)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/thread.c:586
#18 0x00000000005bf3e7 in thread_select (func=<optimized out>, 
    max_fds=max_fds@entry=7, rfds=rfds@entry=0x7fffffffcf50, 
    wfds=wfds@entry=0x7fffffffcfd0, efds=efds@entry=0x0, 
    timeout=timeout@entry=0x7fffffffd550, sigmask=0x0)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/thread.c:616
#19 0x00000000005dd722 in xg_select (fds_lim=7, 
    rfds=rfds@entry=0x7fffffffd660, wfds=wfds@entry=0x7fffffffd6e0, 
    efds=efds@entry=0x0, timeout=timeout@entry=0x7fffffffd550, 
    sigmask=sigmask@entry=0x0)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/xgselect.c:117
#20 0x00000000005a3fa4 in wait_reading_process_output (
    time_limit=time_limit@entry=0, nsecs=nsecs@entry=0, 
    read_kbd=read_kbd@entry=-1, do_display=true, 
    wait_for_cell=wait_for_cell@entry=XIL(0), wait_proc=wait_proc@entry=0x0, 
    just_wait_proc=0)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/process.c:5440
#21 0x00000000004f15c9 in kbd_buffer_get_event (end_time=0x0, 
    used_mouse_menu=0x7fffffffdebb, kbp=<synthetic pointer>)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/lisp.h:1058
#22 read_event_from_main_queue (used_mouse_menu=0x7fffffffdebb, 
    local_getcjmp=0x7fffffffdb50, end_time=0x0)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/keyboard.c:2138
#23 read_decoded_event_from_main_queue (used_mouse_menu=<optimized out>, 
    prev_event=<optimized out>, local_getcjmp=<optimized out>, 
    end_time=<optimized out>)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/keyboard.c:2202
#24 read_char (commandflag=1, map=XIL(0xdb7d13), prev_event=XIL(0), 
    used_mouse_menu=0x7fffffffdebb, end_time=0x0)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/keyboard.c:2810
#25 0x00000000004f3256 in read_key_sequence (keybuf=<optimized out>, 
    prompt=XIL(0), dont_downcase_last=<optimized out>, 
    can_return_switch_frame=true, fix_current_buffer=true, 
    prevent_redisplay=<optimized out>)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/keyboard.c:9125
#26 0x00000000004f4b8e in command_loop_1 ()
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/lisp.h:1058
#27 0x000000000055e857 in internal_condition_case (
    bfun=bfun@entry=0x4f49b0 <command_loop_1>, 
    handlers=handlers@entry=XIL(0x50d0), hfun=hfun@entry=0x4ec060 <cmd_error>)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/eval.c:1352
#28 0x00000000004e703c in command_loop_2 (ignore=ignore@entry=XIL(0))
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/lisp.h:1058
#29 0x000000000055e7b1 in internal_catch (tag=tag@entry=XIL(0xc9f0), 
    func=func@entry=0x4e7020 <command_loop_2>, arg=arg@entry=XIL(0))
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/eval.c:1113
#30 0x00000000004e6fe4 in command_loop ()
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/lisp.h:1058
#31 0x00000000004ebc76 in recursive_edit_1 ()
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/keyboard.c:714
#32 0x00000000004ebfa0 in Frecursive_edit ()
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/keyboard.c:786
#33 0x000000000041c2c3 in main (argc=4, argv=0x7fffffffe338)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/emacs.c:2126

Lisp Backtrace:
"make-network-process" (0xffffc2a0)
"server-running-p" (0xffffc690)
"server-start" (0xffffcbc0)

(gdb) up 5
#5  report_file_errno (string=<optimized out>, name=name@entry=XIL(0xdd55f3), 
    errorno=<optimized out>)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/fileio.c:222
222	  xsignal (Fcar (data), Fcdr (data));

(gdb) pp data
(file-missing "make client process failed" "No such file or directory" :name "server-client-test" :family local :server nil :noquery t :service "/dev/shm/madhu/emacs/emacs-test")

(gdb) up
#6  0x000000000041a663 in connect_network_socket (proc=XIL(0xd7f415), 
    addrinfos=<optimized out>, use_external_socket_p=<optimized out>)
    at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/process.c:3633
3633		  unbind_to (count, Qnil);
(gdb) 

[-- Attachment #3: Type: text/plain, Size: 704 bytes --]


Additional notes:
- make-network-process signals a (file-missing "make client process failed" "No such file or directory" :name "server-client-test" :family local :server nil :noquery t :service "/dev/shm/madhu/emacs/emacs-test")
  which is not supposed to happen since the file would be created by the
  system call to socket.  I suspect a wrong error is being reported
  because of some problem with pselect (which is interrupted when we
  enter gdb)

- load custom.el to try to avoid an unrelated emacs-abort which
  otherwise seems to happen from within the custom mechanism
- another unrelated emacs-bug. M-x gud-gdb -- emacs .. with the above
  arg line fails to pass the quoted arguments to gdb.

bug#36648: emacs signals under gdb - [Re: connecting to a lost server process

[Eli Zaretskii]

> From: Madhu <enometh@meer.net>
> Date: Sun, 14 Jul 2019 17:30:52 +0530
> 
> >> Earlier it used to be possible to gdb attach to the emacs process and
> >> to restart the server. Something like
> >> Feval(Fcar(Fread_from_string(build_string("(server-start)"),Qnil,Qnil)),Qnil)
> >> But for some time now that route hits a
> >> terminate_due_to_signal. (Apparently make-network-process tries to
> >> signal an error which calls emacs_abort which ends the show)
> >
> > Please report a bug with the details of that crash, it may or may not
> > be a bug.
> 
> I noticed a couple of different failure modes but this problem seems to
> be related to pselect.  I'm appending one backtrace. Note within the
> transcript emacs is started with
> 
> args:  -Q --eval '(progn (load-library "custom") (load-library "server") (setq server-name "emacs-test"))'
> 
> After emacs is started by gdb I send it a TSTP to make it enter the
> debugger.

The data you collected shows that your attempt to restart the server
signals an error:

> #1  0x0000000000416a50 in emacs_abort ()
>     at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/sysdep.c:2437
> #2  0x0000000000418a90 in signal_or_quit (error_symbol=XIL(0x58e0), 
>     data=XIL(0xdd5663), keyboard_quit=<optimized out>)
>     at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/eval.c:1595
> #3  0x0000000000418aa9 in Fsignal (error_symbol=<optimized out>, 
>     data=data@entry=XIL(0xdd5663))
>     at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/eval.c:1565
> #4  0x0000000000417118 in xsignal (data=XIL(0xdd5663), 
>     error_symbol=<optimized out>)
>     at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/lisp.h:4101
> #5  report_file_errno (string=<optimized out>, name=name@entry=XIL(0xdd55f3), 
>     errorno=<optimized out>)
>     at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/fileio.c:222
> #6  0x000000000041a663 in connect_network_socket (proc=XIL(0xd7f415), 
>     addrinfos=<optimized out>, use_external_socket_p=<optimized out>)
>     at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/process.c:3633
> #7  0x00000000005a2cc6 in Fmake_network_process (nargs=<optimized out>, 
>     args=<optimized out>)
>     at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/process.c:4246

See the call to report_file_errno in frame #5?  Signaling an error
while waiting for input is fatal in Emacs, so it aborts.

> Lisp Backtrace:
> "make-network-process" (0xffffc2a0)
> "server-running-p" (0xffffc690)
> "server-start" (0xffffcbc0)
> 
> (gdb) up 5
> #5  report_file_errno (string=<optimized out>, name=name@entry=XIL(0xdd55f3), 
>     errorno=<optimized out>)
>     at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/fileio.c:222
> 222	  xsignal (Fcar (data), Fcdr (data));
> 
> (gdb) pp data
> (file-missing "make client process failed" "No such file or directory" :name "server-client-test" :family local :server nil :noquery t :service "/dev/shm/madhu/emacs/emacs-test")

So here's the reason for the problem: the way you try to restart the
server fails because the socket no longer exists.

> Additional notes:
> - make-network-process signals a (file-missing "make client process failed" "No such file or directory" :name "server-client-test" :family local :server nil :noquery t :service "/dev/shm/madhu/emacs/emacs-test")
>   which is not supposed to happen since the file would be created by the
>   system call to socket.  I suspect a wrong error is being reported
>   because of some problem with pselect (which is interrupted when we
>   enter gdb)

I don't think the error is wrong.  Look at the function
server-running-p: it attempts to determine whether the server is
already running by creating a client process of the server.  This
happens _before_ restarting the server.  IOW, Emacs attempts to clean
up if the server is already running.  In your case, the socket
doesn't exist, so this method of restarting the server can no longer
be used safely, because when you attach GDB to Emacs, Emacs will
almost always be waiting for input, where every error is fatal.

Instead, I suggest to restart the server by binding a function to the
sigusr1 or sigusr2 event.  These events can be triggered by the
corresponding signals.

> - another unrelated emacs-bug. M-x gud-gdb -- emacs .. with the above
>   arg line fails to pass the quoted arguments to gdb.

Sorry, I don't think I understand what exactly do you mean by "with
the above arg line".  Can you please show a full sequence of commands
that produce this problem?

Thanks.

bug#36648: emacs signals under gdb - [Re: connecting to a lost server process

[Madhu]

[-- Attachment #1: Type: Text/Plain, Size: 4573 bytes --]

*  Eli Zaretskii <eliz@gnu.org> <8336j3zz07.fsf@gnu.org>
Wrote on Thu, 18 Jul 2019 08:35:04 +0300

>> From: Madhu <enometh@meer.net>
>> Date: Sun, 14 Jul 2019 17:30:52 +0530
>>
>> #5  report_file_errno (string=<optimized out>, name=name@entry=XIL(0xdd55f3),
>>     errorno=<optimized out>)
>>     at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/fileio.c:222
>> #6  0x000000000041a663 in connect_network_socket (proc=XIL(0xd7f415),
>>     addrinfos=<optimized out>, use_external_socket_p=<optimized out>)
>>     at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/process.c:3633
>> #7  0x00000000005a2cc6 in Fmake_network_process (nargs=<optimized out>,
>>     args=<optimized out>)
>>     at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/process.c:4246
>
> See the call to report_file_errno in frame #5?  Signaling an error
> while waiting for input is fatal in Emacs, so it aborts.
>
>> Lisp Backtrace:
>> "make-network-process" (0xffffc2a0)
>> "server-running-p" (0xffffc690)
>> "server-start" (0xffffcbc0)
>>
>> (gdb) up 5
>> #5  report_file_errno (string=<optimized out>, name=name@entry=XIL(0xdd55f3),
>>     errorno=<optimized out>)
>>     at /var/tmp/portage/app-editors/emacs-27.0.50-r3/work/emacs-27.0.50/src/fileio.c:222
>> 222	  xsignal (Fcar (data), Fcdr (data));
>>
>> (gdb) pp data
>> (file-missing "make client process failed" "No such file or directory" :name "server-client-test" :family local :server nil :noquery t :service "/dev/shm/madhu/emacs/emacs-test")
>
> So here's the reason for the problem: the way you try to restart the
> server fails because the socket no longer exists.
>
>> Additional notes:
>> - make-network-process signals a (file-missing "make client process failed" "No such file or directory" :name "server-client-test" :family local :server nil :noquery t :service "/dev/shm/madhu/emacs/emacs-test")
>>   which is not supposed to happen since the file would be created by the
>>   system call to socket.  I suspect a wrong error is being reported
>>   because of some problem with pselect (which is interrupted when we
>>   enter gdb)
>
> I don't think the error is wrong.  Look at the function
> server-running-p: it attempts to determine whether the server is
> already running by creating a client process of the server.  This
> happens _before_ restarting the server.  IOW, Emacs attempts to clean
> up if the server is already running.  In your case, the socket
> doesn't exist, so this method of restarting the server can no longer
> be used safely, because when you attach GDB to Emacs, Emacs will
> almost always be waiting for input, where every error is fatal.

server-running-p tries to start a server, and if it fails with a file
error, then the condition-case is expected to catch it and the
function is supposed to return nil.  If I modify this function (see
patch [1]) to test for the file instead of trying to catch an error
from make-network-process, then this particular example (of restarting
the server from gdb) works.

From the point of view of elisp, no error should be signalled - it
should be caught by the condition-case.

If I'm running an emacs compiled without X, when I suspend emacs and
enter gdb on the same terminal, then no error is signalled (presumably
because emacs is not waiting for input).

> Instead, I suggest to restart the server by binding a function to the
> sigusr1 or sigusr2 event.  These events can be triggered by the
> corresponding signals.

Thank you, I will take up this suggestion. The default SIGUSR is
very useful to unwedge emacs.

However there seems to be room for improvement around the "abort when
awaiting for input behaviour" - as there are other situations within
gdb which are not "really" error situations which unnecessarily abort
emacs.

>> - another unrelated emacs-bug. M-x gud-gdb -- emacs .. with the above
>>   arg line fails to pass the quoted arguments to gdb.
>
> Sorry, I don't think I understand what exactly do you mean by "with
> the above arg line".  Can you please show a full sequence of commands
> that produce this problem?

M-x gud-gdb RET
gdb --args emacs --arg -Q --eval '(progn (load-library "custom") (load-library "server") (setq server-name "emacs-test"))' RET

=>

|Reading symbols from emacs...
(gdb) show args
Argument list to give program being debugged when it is started is "--arg -Q --eval \'\(progn \(load-library custom \) \(load-library server \) \(setq server-name emacs-test \)\)\'".
(gdb)

i.e. the arguments are not correctly quoted when passed to gdb.

[1]

[-- Attachment #2: avoid-condition-case-in-server-running-p.patch --]
[-- Type: Text/X-Patch, Size: 795 bytes --]

diff --git a/lisp/server.el b/lisp/server.el
index 436a44a7e9..2bd512f52c 100644
--- a/lisp/server.el
+++ b/lisp/server.el
@@ -763,6 +763,9 @@ server-running-p
 Emacs process.  To check from a Lisp program whether a server was started
 by the current Emacs process, use the `server-process' variable."
   (unless name (setq name server-name))
+  (if (and (not server-use-tcp)
+	   (not (file-exists-p (expand-file-name name server-socket-dir))))
+      nil
   (condition-case nil
       (if server-use-tcp
 	  (with-temp-buffer
@@ -778,7 +781,7 @@ server-running-p
 	  :name "server-client-test" :family 'local :server nil :noquery t
 	  :service (expand-file-name name server-socket-dir)))
 	t)
-    (file-error nil)))
+    (file-error nil))))
 
 ;;;###autoload
 (define-minor-mode server-mode

bug#36648: emacs signals under gdb - [Re: connecting to a lost server process

[Eli Zaretskii]

> Date: Thu, 18 Jul 2019 20:28:21 +0530 (IST)
> Cc: 36648@debbugs.gnu.org
> From: Madhu <enometh@meer.net>
> 
> >From the point of view of elisp, no error should be signalled - it
> should be caught by the condition-case.

You called those functions directly, from outside of the Lisp machine,
so the condition-case machinery is not working.

> However there seems to be room for improvement around the "abort when
> awaiting for input behaviour" - as there are other situations within
> gdb which are not "really" error situations which unnecessarily abort
> emacs.

There are inherent difficulties that require this behavior, sorry.

> M-x gud-gdb RET
> gdb --args emacs --arg -Q --eval '(progn (load-library "custom") (load-library "server") (setq server-name "emacs-test"))' RET
> 
> =>
> 
> |Reading symbols from emacs...
> (gdb) show args
> Argument list to give program being debugged when it is started is "--arg -Q --eval \'\(progn \(load-library custom \) \(load-library server \) \(setq server-name emacs-test \)\)\'".

I suggest to use "M-x gdb", not "M-x gud-gdb".  The latter is an old
and semi-deprecated way of running GDB from Emacs.

I guess we can close this bug report?

bug#36648: emacs signals under gdb - [Re: connecting to a lost server process

[Madhu]

*  Eli Zaretskii <eliz@gnu.org> <838ssvwek9.fsf@gnu.org>
Wrote on Thu, 18 Jul 2019 18:24:54 +0300

>> Date: Thu, 18 Jul 2019 20:28:21 +0530 (IST)
>> Cc: 36648@debbugs.gnu.org
>> From: Madhu <enometh@meer.net>
>>
>> >From the point of view of elisp, no error should be signalled - it
>> >should be caught by the condition-case.
>
> You called those functions directly, from outside of the Lisp machine,
> so the condition-case machinery is not working.

The Lisp Language specifies how conditions are to be handled.  The
Lisp machine can only be a virtual machine on which that lisp code
runs.  If the behaviour of a piece of lisp code (however it is
invoked) isn't according to the lisp specification, it is a bug in the
implementation.  The behaviour here can be deemed to be a bug in the
implementation of condition-case rather than a design-bug in
condition-case.

>> However there seems to be room for improvement around the "abort when
>> awaiting for input behaviour" - as there are other situations within
>> gdb which are not "really" error situations which unnecessarily abort
>> emacs.
>
> There are inherent difficulties that require this behavior, sorry.

I'm sure there is some way to mitigate it, though I probably will not
be able to find it.

>> M-x gud-gdb RET
>> gdb --args emacs --arg -Q --eval '(progn (load-library "custom") (load-library "server") (setq server-name "emacs-test"))' RET
>>
>> =>
>>
>> |Reading symbols from emacs...
>> (gdb) show args
>> Argument list to give program being debugged when it is started is "--arg -Q --eval \'\(progn \(load-library custom \) \(load-library server \) \(setq server-name emacs-test \)\)\'".
>
> I suggest to use "M-x gdb", not "M-x gud-gdb".  The latter is an old
> and semi-deprecated way of running GDB from Emacs.

[Unfortunately for me gud-gdb is the only way I can use gdb under
emacs. I was using M-x gdb in emacs19, but was unable to use gdb under
emacs for some time when it was replaced by gdb-mi - where it seemed a
superhuman adversary would rearrange my windows and impede my workflow
in myraid ways - until I discovered gud-gdb]

> I guess we can close this bug report?

Yes please.

bug#36648: emacs signals under gdb - [Re: connecting to a lost server process

[Eli Zaretskii]

> Date: Fri, 19 Jul 2019 07:23:39 +0530 (IST)
> Cc: 36648@debbugs.gnu.org
> From: Madhu <enometh@meer.net>
> 
> > I suggest to use "M-x gdb", not "M-x gud-gdb".  The latter is an old
> > and semi-deprecated way of running GDB from Emacs.
> 
> [Unfortunately for me gud-gdb is the only way I can use gdb under
> emacs. I was using M-x gdb in emacs19, but was unable to use gdb under
> emacs for some time when it was replaced by gdb-mi - where it seemed a
> superhuman adversary would rearrange my windows and impede my workflow
> in myraid ways - until I discovered gud-gdb]

My suggestion is still to use "M-x gdb", but do that in a separate
frame.  Then the dedicated windows used by gdb-mi.el will not get in
the way of your other windows.

> > I guess we can close this bug report?
> 
> Yes please.

Thanks, done.