[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subseque
From: |
Eli Zaretskii |
Subject: |
bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort |
Date: |
Sat, 10 Jan 2015 14:17:33 +0200 |
> 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.
- bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort, martin rudalics, 2015/01/10
- bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort,
Eli Zaretskii <=
- bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort, martin rudalics, 2015/01/10
- bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort, martin rudalics, 2015/01/12
- bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort, Eli Zaretskii, 2015/01/12
- bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort, martin rudalics, 2015/01/12
- bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort, Dmitry Gutov, 2015/01/12
- bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort, martin rudalics, 2015/01/12
- bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort, Eli Zaretskii, 2015/01/12
- bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort, martin rudalics, 2015/01/12
- bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort, Glenn Morris, 2015/01/12
- bug#19554: 25.0.50; void-function xref-marker-stack-empty-p and subsequent abort, Dmitry Gutov, 2015/01/12