When max-lisp-eval-depth is exceeded and that error invokes the Lisp
Debugger, it prints an error message, doesn't produce a backtrace, and
leaves Emacs in a borked state.  In Emacs 25.3.1, the Debugger works
in this situation although the rest of Emacs doesn't work well due to
being near the stack limit, but you can exit the Debugger and things
will go back to normal.

The reason for the regression is that backtrace printing is now done
in Lisp, in cl-print, instead of in C.  If cl-print isn't yet
loaded, being at the stack limit can cause it to fail to load.

To reproduce, from emacs -Q, enter this code into a buffer and
evaluate it:

(toggle-debug-on-error)
(defun my-func (arg)
  (+ (length arg) (my-func arg)))
(my-func "hello")

Result:

Instead of the *Backtrace* buffer, Emacs instead shows *Compile-Log*,
which in my case contains:

/nix/store/s6ji5vn6jbsjpp6wwbix2daigkcsvj7h-emacs-26.1.50/share/emacs/26.1.50/lisp/emacs-lisp/cl-print.elc:Error: Lisp nesting exceeds ‘max-lisp-eval-depth’

In the echo area, this message appears:

cl--generic-make-next-function: Symbol’s function definition is void: t

Emacs is at this point barely usable because it is inside the
debugger's recursive edit and at its stack limit, making
max-lisp-eval-depth errors easy to encounter.  The *Backtrace* buffer
exists but is empty and in Fundamental mode, so you can't use it to
quit the debugger.  You can recover from the situation with
M-x top-level RET.

If cl-print is already loaded the above example will work, but if you
evaluate the following, the Debugger buffer will appear with a
truncated backtrace:

(my-func '(1 (2 (3 (4 (5 (6 (7 (8)))))))))

Here's a patch to give the Debugger and cl-print more stack space
during the recursive edit: