bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 10 Jan 2015 12:43:44 +0100
> From: martin rudalics <rudalics@gmx.at>
> 
> With today's trunk/master and _my init files_ I currently see the
> following problem.  After coming up with the initial frame and hitting
> C-x 5 2 I get
> 
> Debugger entered--Lisp error: (void-function xref-marker-stack-empty-p)
>    (xref-marker-stack-empty-p)
>    (not (xref-marker-stack-empty-p))
>    x-create-frame(((visibility) (bottom-divider-width . 6) (right-divider-width . 6) (horizontal-scroll-bars . t) (tool-bar-lines . 0)))
>    x-create-frame-with-faces(((bottom-divider-width . 6) (right-divider-width . 6) (horizontal-scroll-bars . t) (cursor-color . "red3") (tool-bar-lines . 0)))
>    make-frame()
>    make-frame-command()
>    funcall-interactively(make-frame-command)
>    call-interactively(make-frame-command nil nil)
>    command-execute(make-frame-command)
> 
> and no frame is created.  I leave the Backtrace open and do C-x 5 2.
> Now a new frame is created.  If I now do C-x C-c Emacs decides to die as
> follows.
> 
> Breakpoint 1, terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:352
> 352	  signal (sig, SIG_DFL);
> (gdb) bt
> #0  terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:352
> #1  0x0118363a in die (msg=0x14c1575 "glyph_matrix_count == 0", file=0x14c10dc "dispnew.c", line=2260) at alloc.c:7138
> #2  0x0100693b in check_glyph_memory () at dispnew.c:2260

Calling the Lisp debugger in some sensitive place during creating a
frame is known to cause this.  If you can track this down and see
why we increment the reference count of the new frame where we
shouldn't, or declare the frame "official" too soon, perhaps this can
be fixed.  But it's a low-priority issue, because this assertion
disappears in an optimized binary anyway.  The main problem to tackle
is why do you get a Lisp error in this scenario -- that's the real
problem to fix.