search

emacs-ess / ESS

Emacs Speaks Statistics: ESS
https://ess.r-project.org/
GNU General Public License v3.0
613 stars 160 forks source link

C-level Debugging of R now quickly gets to "no process" #1091

Closed mmaechler closed 3 years ago

mmaechler commented 3 years ago 
C-u M-x R  <Enter>   -d gdb  <Enter>

open gdb in the *R* buffer (and you must typically switch there yourself). There, you type r at the gdb prompt (gdb) so indeed, R starts running seemingly regularly.

Now, e.g., you press C-c C-c with which you go into the debugger and then e.g.,

   C-c C-c
Program received signal SIGINT, Interrupt.
0x00007ffff7160f7a in select () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install bzip2-libs-1.0.8-2.fc32.x86_64 libgcc-10.2.1-9.fc32.x86_64 libgfortran-10.2.1-9.fc32.x86_64 libgomp-10.2.1-9.fc32.x86_64 libicu-65.1-2.fc32.x86_64 libstdc++-10.2.1-9.fc32.x86_64 ncurses-libs-6.1-15.20191109.fc32.x86_64 pcre2-10.36-1.fc32.x86_64 readline-8.0-4.fc32.x86_64 sssd-client-2.4.0-1.fc32.x86_64 xz-libs-5.2.5-1.fc32.x86_64
(gdb) br do_names
Breakpoint 1 at 0x45cfb0: file ../../../R/src/main/attrib.c, line 1016.
(gdb) c
Continuing.

>

with 'c' ('continue') I go back to the R prompt after having set a (C) breakpoint at the do_names() C function which is called from R's names() function.

This is all as it has worked for many years with ESS and R.

But since relatively recently (I discovered ~ a week ago; but I had n't tried to run R in the C level debugger for quite a few weeks), very quickly the R session seems to "lose the process": The emacs status line then suddenly changes from

(iESS [R] run Eldoc)

to

(iESS [R] no process Eldoc)

and I also get a message in the minibuffer

Current buffer has no process

and from then on, I cannot run any command anymore in the iESS buffer.

It may be that this only happens when I press [Tab] for R completion of function names, etc.

lionel- commented 3 years ago

I can't reproduce with lldb, though I do see this in Messages:

Error running timer ‘ess--idle-timer-function’: (wrong-type-argument stringp nil)

Can you please find out when exactly this happens? Tracing ESS functions would be great. Also bisecting the faulty commit would be useful.

r2evans commented 3 years ago

Perhaps related, I'm getting "no process" without C-level debugging (four times today). (But the process is still alive, I've seen it "do work" when something else within R was working.) The only way to fix it is to kill the process and restart R.

ess-version: 18.10.3snapshot [elpa: 20210109.1455] (loaded from c:/Users/r2/.emacs.d/elpa/ess-20210109.1455/)

lionel- commented 3 years ago

Bummer. I have merged #1076 so you can now call M-x ess-elisp-trace-mode to trace ESS functions. Given the amount of output this generates, this is probably not really practical unless you have a short reprex procedure though. Maybe the dribble buffer can help provide some context?

r2evans commented 3 years ago

dribble buffer?

lionel- commented 3 years ago

The logging buffer of ESS: https://github.com/emacs-ess/ESS/blob/19de88d2/lisp/ess-utils.el#L1032-L1037

Enabled with (setq ess-verbose t)

vspinu commented 3 years ago

I started seeing this after ESS update. Probably a recent change, 1~2 months max.

lionel- commented 3 years ago

Thanks for reporting everyone. I've merged an attempt at fixing this (#1106). Can you please try it once melpa has updated and see if that fixes it for you please?

If you're no longer seeing this issue, can you please also try with this:

(setq ess--command-default-timeout 1)

This will cause the timeout errors you've been seeing with remotes (we've bumped the default timeout to 30s in the mean time). It'd be helpful if you could confirm that the process is not lost, i.e. you don't see "Current buffer has no process" after a timeout error.