Many Emacs functions (including build-in ones) become nil time to time - how to debug?

Sometimes I have to restart Emacs daemon because accidentely many Emacs functions become nil, and I could not `save-buffer` and do many other things. It happens suddenly, and I have no idea how to find out the reason for it. How to find out what couse it? Maybe there is something like `debug-on-variable-change` for watching functions (I've checked, it doesn't work for functions).

(I run emacs in short edit sessions, so I don't have direct experience with debugging such an error.) One possibility is that the garbage collector is forgetting the functions to save memory. Try increasing `gc-cons-threshold`. It's also a good idea to close buffers as soon as you're done with them, avoid global variables in functions, et cetera.

>One possibility is that the garbage collector is forgetting the functions to save memory. Try increasing gc-cons-threshold. > >It's also a good idea to close buffers as soon as you're done with them, avoid global variables in functions, et cetera. Thank you for your advice! I don't thing that this happens but the the lack of memory as I don't use many buffers (maybe \~20). But just in case, can I log what the garbage collector forgets?

> many Emacs functions become nil Specifically what do you mean by that? Is the function unbound? Literally fset to nil? Something else? Is there an error? If so, quote it. Your problem is very unclear.

For example, when I press C-x C-s I get the error "`Symbol's function definition is void: save-buffer`". The similar errors I get when I press many other keys (but not all: e.g., I still can move the point).

> One possibility is that the garbage collector is forgetting the functions to save memory That's a radical and exciting interpretation of "garbage" you have there. Catastrophic bugs aside, that is *not* what garbage collectors do. > It's also a good idea to close buffers as soon as you're done with them There is no particular need to do that. Emacs can have hundreds of buffers without it being troublesome. > avoid global variables in functions Vast amounts of Emacs are global state, and functions are *expected* to refer to it. (And until lexical binding was added, only about 10 years ago, there was nothing *but* global variables.) Sorry, but none of these suggestions seem to have any sensible basis.

That's an exciting bug. All I can suggest is that you figure out a recipe to reproduce the issue, and then bisect your config until you track down what's causing it.

It’s been quite a while since it happened, so I’m not 100% sure this is the same issue – but I think I had something very similar happen once when I upgraded emacs to a newer version while I had an instance still running. That running instance then started behaving in a similar way to this – and even kill-emacs wasn’t working, so I couldn’t exit cleanly. I would guess this was because *.el from the older running version had been removed so it could no longer load anything from them. After killing the running emacs process and starting the newer one, everything worked properly again. Since then I’ve been more careful when upgrading, and now close any running emacs first.

Check the Messages buffer and see if you can get better info about the error. Normally, I use emacs 29 built from master, which works without problems. I was having this problem with emacs 27 (the version provided by Debian testing - it's the version that "File open" calls by default for certain file types); the only way to close the program was to find the process ID and `kill` it. I uninstalled then reinstalled package, and it's now at the point where it closes properly, but there are still issues. The `modus` themes don't load properly (though they work fine in emacs 29). In the Message buffer, I get: Eager macro-expansion failure: (void-function make-closure) [2 times] Failed to enable theme(s): modus-vivendi I use v. 29 for almost everything, so I've never bothered to track this down any further. Check the Messages buffer!

I guess it is not my case, unfortunately, as it happens while I don't update Emacs.

So you expirienced the same issue? I haven't found any useful information in Message buffer (except `Symbol's function definition is void: ...`), but I'm looking for ways to get more verbose log, maybe by tracing some functions. The problem is that I have no idea which functions I need to trace:)

Same error message (`Symbol's function definition is void ...`) as you got when I tried to *exit* emacs - I think it also occurred on trying to *save* files. And again, this was only on v. 27, the "official" Debian testing version - no problem on either v. 28 or v. 29 built from master. (Actually, you might try building from master and seeing if the latest version works better for you - it's pretty easy.)

I'll note that `save-buffer` is defined in `files.el` which is loaded by `loadup.el` and hence that definition comes from the portable dump file (if you're using 27.1 or later, and assuming you hadn't taken explicit steps to compile Emacs without that feature). If something went awry with the dump file, perhaps that could explain the issue. I don't actually know how the dump file is used in detail, though. My *expectation* had always been that it was loaded when Emacs starts, and thereafter the file itself would not be used; but if the dump file is used directly on an ongoing basis, perhaps it's conceivable that something messing with it could affect existing Emacs processes. The comment by /u/SirRuthven "I think I had something very similar happen once when I upgraded emacs to a newer version while I had an instance still running." might tie into that theory as well. You could try uninstalling Emacs (and verifying that you don't have more than one version installed), and then reinstall it and see whether that fixes the issue. If there really is something weird going on with the dump file, this *might* deal with it. If, OTOH, the problem encompasses custom and/or third-party functions as well as default Emacs functions, then the dump file almost certainly isn't the explanation (but reinstalling probably wouldn't hurt to try, regardless). If this turns out to be an Emacs bug and you can figure out how to reproduce it, be sure to `M-x report-emacs-bug`.