Looks perfectly "normal" to me: the \NNN you see are bytes in the bytecode of the functions that have been used to run your code.
It's somewhat annoying to see them in the backtrace, indeed, so after a few decades of living with it, Emacs-26 finally changed to provide a prettier representation.
Nope. There is no simple solution ready-to-hand. As far as I know, users just manually remove the bytecode from backtraces they report. That's what I do, at least.
This has been requested more than once, including with Emacs bug #6991.
The bug was summarily closed immediately -- no reason given. Eventually it was reopened and relegated to the "wishlist".
Do you see the same problem when you start Emacs using emacs -Q (no init file)? If not then recursively bisect your init file to find out what is causing the problem (e.g. *Backtrace* seeming to disappear and Emacs becoming dysfunctional).
If you still see the problem with emacs -Q then consider reporting an Emacs bug.
If buffer *Backtrace* has not been ...
The advice framework is good for this sort of thing. You could advise low-level functions like write-region and insert-file-contents (those probably offer good coverage). One way would be to use a function that logs both the filename and a stack trace. Something like the following:
(lambda (&rest args)
Use M-x set-variable RET debug-on-error RET t RET.
(Or M-: (setq debug-on-error t).)
That will open the debugger when the error is raised. You can see who called that recentf-mode, what arguments it was passed, etc.
The problem you see is that recentf-mode was expecting a string argument and it received a nil argument (or possibly no argument).
To debug ...
@npostavs was able to track the problem down in the Emacs bug report 27571: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=27571
In a nutshell, the error is caused because the ulimit stack size is too low to handle this particular situation. ulimit -S -s unlimited resolves this issue.
In the event the Emacs team implements a fix, or if another solution is ...
The easiest thing to do is to create your own debugger in the environment in which the error occurs. That goes something like this:
(defun my-debugger (&rest debugger-args)
(message "BACKTRACE: %s"
(let ((standard-output (current-buffer)))
Setting edebug options doesn't actually help here. Errors that are listed in debug-ignored-errors are ignored even while executing under Edebug. This isn't mentioned in the manual (as of Emacs 24.5) but it is mentioned in the docstring of debug-on-error (for which edebug-on-error is just a proxy). (I don't understand why debug-ignored-errors has any ...