This bug has been reproducible since at least the emacs23 days, and is available in emacs in both stretch/testing/sid as well
as ubuntu from 9.04 'jaunty' through to 18.04 'bionic'

Heavily recursive emacs lisp functions are hitting some limit, that is not the limit of how much memory emacs has access to.
To hit this limit you need a simple file that is made by 2 parts.

1) seq 11718 > seqfile

you can then edit seqfile with emacs and copy the contents.  you'll need that for later.

2) some helper functions (F, nullp & map), 2 setqs to set max-lisp-eval-depth and max-specsdl-size and the function G

File Edit Options Buffers Tools Help
(defun nullp (l)
"is this null?"
(equal '() l))
(defun map (f l)
 "map function?"
 (if
 (nullp l)
  '()
  (if (listp l)
   (if (= 1 (length l))
      (list (funcall f (car l)))
  (if (> (length l) 1)
    (cons (map f (car l))
     (map f (cdr l)))))
   (funcall f l)
 )))
 (setq max-lisp-eval-depth (expt 2 17))
 (setq max-specpdl-size (expt 2 17))
 (defun F (L)
  (message ".") )
(defun G (L) (map 'F L))
(G
'(
<insert file seqfile here>
))

then run the above, line by line.  if you try to run G

...the result is a crash of emacs in its entirety.

themusicgod1@wicksell:~/emacs$ emacs seqfile0-simple
Fatal error 11: Segmentation fault
Backtrace:
emacs[0x50a5fe]
emacs[0x4f0bf9]
emacs[0x508d4e]
emacs[0x508f08]
emacs[0x508f95]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7fcbe20fe0c0]
emacs[0x44515b]
emacs[0x447985]
emacs[0x44e961]
emacs[0x4517ce]
emacs[0x432568]
emacs[0x455ff6]
emacs[0x4562ff]
emacs[0x45646c]
emacs[0x55adee]
emacs[0x565bc9]
emacs[0x5660bd]
emacs[0x563b2b]
emacs[0x565bc9]
emacs[0x566365]
emacs[0x5659d9]
emacs[0x566365]
emacs[0x5659d9]
emacs[0x5660bd]
emacs[0x566263]
emacs[0x5657f8]
emacs[0x5658da]
emacs[0x5659d9]
emacs[0x566365]
emacs[0x5659d9]
emacs[0x5659d9]
emacs[0x566365]
emacs[0x5659d9]
emacs[0x5660bd]
emacs[0x566263]
emacs[0x5657f8]
emacs[0x5658da]
emacs[0x5659d9]
emacs[0x566365]
emacs[0x5659d9]
emacs[0x5659d9]
...
Segmentation fault

I've looked a little bit at the stack trace of what this crash looks like in the ubuntu bug report.
As you can imagine with a highly recursive program, it's deep.

https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/508618

one thing that is *not* causing this is the memory of emacs being exhausted, since monitoring the memory used by the
process in question leads to observing it's using a small % of the system memory on any machine I've tested.

What should happen is that emacs should give some error message(some suggested in the ubuntu ticket), and not crash.
Or it should be documented somewhere what this limit is, and why is it in emacs.  Segfaulting at random when you have
hundreds of frames can be quite...jolting :)