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

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

[martin rudalics]

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
#3  0x01108c7c in shut_down_emacs (sig=0, stuff=...) at emacs.c:2004
#4  0x01108b4a in Fkill_emacs (arg=...) at emacs.c:1917
#5  0x011a4211 in Ffuncall (nargs=1, args=0x82c588) at eval.c:2707
#6  0x011e9879 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82c8f0) at bytecode.c:919
#7  0x011a4a73 in funcall_lambda (fun=..., nargs=1, arg_vector=0x82c8ec) at eval.c:2874
#8  0x011a442f in Ffuncall (nargs=2, args=0x82c8e8) at eval.c:2756
#9  0x011e9879 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82cd1c) at bytecode.c:919
#10 0x011a4a73 in funcall_lambda (fun=..., nargs=1, arg_vector=0x82cd18) at eval.c:2874
#11 0x011a442f in Ffuncall (nargs=2, args=0x82cd14) at eval.c:2756
#12 0x0119b17c in Ffuncall_interactively (nargs=2, args=0x82cd14) at callint.c:258
#13 0x011a40fe in Ffuncall (nargs=3, args=0x82cd10) at eval.c:2687
#14 0x0119d379 in Fcall_interactively (function=..., record_flag=..., keys=...) at callint.c:864
#15 0x011a4266 in Ffuncall (nargs=4, args=0x82cfbc) at eval.c:2714
#16 0x011e9879 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82d320) at bytecode.c:919
#17 0x011a4a73 in funcall_lambda (fun=..., nargs=1, arg_vector=0x82d31c) at eval.c:2874
#18 0x011a442f in Ffuncall (nargs=2, args=0x82d318) at eval.c:2756
#19 0x011a3d07 in call1 (fn=..., arg1=...) at eval.c:2560
#20 0x0110badd in command_loop_1 () at keyboard.c:1518
#21 0x011a0cea in internal_condition_case (bfun=0x110b29b <command_loop_1>, handlers=..., hfun=0x110a987 <cmd_error>) at eval.c:1334
#22 0x0110aecd in command_loop_2 (ignore=...) at keyboard.c:1139
#23 0x011a0220 in internal_catch (tag=..., func=0x110aea2 <command_loop_2>, arg=...) at eval.c:1095
#24 0x0110adf8 in command_loop () at keyboard.c:1110
#25 0x0110a4e5 in recursive_edit_1 () at keyboard.c:728
#26 0x0110a6d9 in Frecursive_edit () at keyboard.c:799
#27 0x011a41f4 in Ffuncall (nargs=1, args=0x82d650) at eval.c:2704
#28 0x011e9879 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=2, args=0x82d9b4) at bytecode.c:919
#29 0x011a4a73 in funcall_lambda (fun=..., nargs=2, arg_vector=0x82d9b4) at eval.c:2874
#30 0x011a442f in Ffuncall (nargs=3, args=0x82d9b0) at eval.c:2756
#31 0x011a36e1 in Fapply (nargs=2, args=0x82da48) at eval.c:2323
#32 0x011a3cc1 in apply1 (fn=..., arg=...) at eval.c:2544
#33 0x0119de08 in call_debugger (arg=...) at eval.c:309
#34 0x011a1b0b in maybe_call_debugger (conditions=..., sig=..., data=...) at eval.c:1712
#35 0x011a139d in Fsignal (error_symbol=..., data=...) at eval.c:1530
#36 0x011a14b9 in xsignal (error_symbol=..., data=...) at eval.c:1567
#37 0x011a14ff in xsignal1 (error_symbol=..., arg=...) at eval.c:1582
#38 0x011a2ff1 in eval_sub (form=...) at eval.c:2216
#39 0x011a2d18 in eval_sub (form=...) at eval.c:2153
#40 0x011a25dd in Feval (form=..., lexical=...) at eval.c:1982
#41 0x01118cf8 in eval_dyn (form=...) at keyboard.c:7642
#42 0x011a0e08 in internal_condition_case_1 (bfun=0x1118cd7 <eval_dyn>, arg=..., handlers=..., hfun=0x1118c41 <menu_item_eval_property_1>) at eval.c:1358
#43 0x01118d5a in menu_item_eval_property (sexpr=...) at keyboard.c:7653
#44 0x01119665 in parse_menu_item (item=..., inmenubar=0) at keyboard.c:7762
#45 0x01087dff in single_menu_item (key=..., item=..., dummy=..., skp_v=0x82e004) at menu.c:334
#46 0x01123e27 in map_keymap_item (fun=0x1087dda <single_menu_item>, args=..., key=..., val=..., data=0x82e004) at keymap.c:560
#47 0x01124118 in map_keymap_internal (map=..., fun=0x1087dda <single_menu_item>, args=..., data=0x82e004) at keymap.c:599
#48 0x01124492 in map_keymap_canonical (map=..., fun=0x1087dda <single_menu_item>, args=..., data=0x82e004) at keymap.c:662
#49 0x01087c57 in single_keymap_panes (keymap=..., pane_name=..., prefix=..., maxdepth=9) at menu.c:300
#50 0x01088450 in single_menu_item (key=..., item=..., dummy=..., skp_v=0x82e1f4) at menu.c:443
#51 0x01123e27 in map_keymap_item (fun=0x1087dda <single_menu_item>, args=..., key=..., val=..., data=0x82e1f4) at keymap.c:560
#52 0x01124118 in map_keymap_internal (map=..., fun=0x1087dda <single_menu_item>, args=..., data=0x82e1f4) at keymap.c:599
#53 0x01124492 in map_keymap_canonical (map=..., fun=0x1087dda <single_menu_item>, args=..., data=0x82e1f4) at keymap.c:662
#54 0x01087c57 in single_keymap_panes (keymap=..., pane_name=..., prefix=..., maxdepth=10) at menu.c:300
#55 0x01088b55 in parse_single_submenu (item_key=..., item_name=..., maps=...) at menu.c:572
#56 0x012277b1 in set_frame_menubar (f=0x5a64788, first_time=true, deep_p=true) at w32menu.c:366
#57 0x01227c6e in initialize_frame_menubar (f=0x5a64788) at w32menu.c:522
#58 0x0121d6e4 in w32_window (f=0x5a64788, window_prompting=0, minibuffer_only=0) at w32fns.c:4237
#59 0x0121ece7 in Fx_create_frame (parameters=...) at w32fns.c:4659
#60 0x011a4211 in Ffuncall (nargs=2, args=0x82e794) at eval.c:2707
#61 0x011e9879 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x0) at bytecode.c:919
#62 0x011a4eb0 in funcall_lambda (fun=..., nargs=1, arg_vector=0x12dc1cd) at eval.c:2940
#63 0x011a442f in Ffuncall (nargs=2, args=0x82eafc) at eval.c:2756
#64 0x011e9879 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x82ee68) at bytecode.c:919
#65 0x011a4a73 in funcall_lambda (fun=..., nargs=0, arg_vector=0x82ee68) at eval.c:2874
#66 0x011a442f in Ffuncall (nargs=1, args=0x82ee64) at eval.c:2756
#67 0x011e9879 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=0, args=0x82f35c) at bytecode.c:919
#68 0x011a4a73 in funcall_lambda (fun=..., nargs=0, arg_vector=0x82f35c) at eval.c:2874
#69 0x011a442f in Ffuncall (nargs=1, args=0x82f358) at eval.c:2756
#70 0x0119b17c in Ffuncall_interactively (nargs=1, args=0x82f358) at callint.c:258
#71 0x011a40fe in Ffuncall (nargs=2, args=0x82f354) at eval.c:2687
#72 0x011a3294 in Fapply (nargs=3, args=0x82f354) at eval.c:2275
#73 0x0119b60d in Fcall_interactively (function=..., record_flag=..., keys=...) at callint.c:404
#74 0x011a4266 in Ffuncall (nargs=4, args=0x82f53c) at eval.c:2714
#75 0x011e9879 in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1, args=0x82f8a0) at bytecode.c:919
#76 0x011a4a73 in funcall_lambda (fun=..., nargs=1, arg_vector=0x82f89c) at eval.c:2874
#77 0x011a442f in Ffuncall (nargs=2, args=0x82f898) at eval.c:2756
#78 0x011a3d07 in call1 (fn=..., arg1=...) at eval.c:2560
#79 0x0110badd in command_loop_1 () at keyboard.c:1518
#80 0x011a0cea in internal_condition_case (bfun=0x110b29b <command_loop_1>, handlers=..., hfun=0x110a987 <cmd_error>) at eval.c:1334
#81 0x0110aecd in command_loop_2 (ignore=...) at keyboard.c:1139
#82 0x011a0220 in internal_catch (tag=..., func=0x110aea2 <command_loop_2>, arg=...) at eval.c:1095
#83 0x0110ae72 in command_loop () at keyboard.c:1118
#84 0x0110a4e5 in recursive_edit_1 () at keyboard.c:728
#85 0x0110a6d9 in Frecursive_edit () at keyboard.c:799
#86 0x0110857f in main (argc=1, argv=0xa32858) at emacs.c:1612

Lisp Backtrace:
Attempt to extract a component of a value that is not a structure.
(gdb)

Adding (require 'xref) to my .emacs solves the problem.

In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
  of 2015-01-10 on MACHNO
Repository revision: c2208b3d913c2e53b96d7f11b31422a57366f601
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
  `configure --prefix=/c/emacs-git/trunk --enable-checking=yes
  --enable-check-lisp-object-type=yes 'CFLAGS=-O0 -g3'
  CPPFLAGS=-DGLYPH_DEBUG=1'

martin

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

[Eli Zaretskii]

> 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]

 > 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.

I suppose it's the same as bug#10296 then.

 > The main problem to tackle
 > is why do you get a Lisp error in this scenario -- that's the real
 > problem to fix.

Indeed.  Another clue might be that when I try to access the menu bar
with the mouse I get

Debugger entered--Lisp error: (void-function xref-marker-stack-empty-p)
   (xref-marker-stack-empty-p)
   (not (xref-marker-stack-empty-p))

martin

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

[martin rudalics]

A simpler scenario: With emacs -Q I evaluate

  (let ((params '((height . 25))))
   (make-frame params)  ;; f1
   (modify-frame-parameters (make-frame) params))  ;; f2

in *scratch*.  Gets me the now familiar

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) (height . 25)))
   x-create-frame-with-faces(((height . 25)))
   make-frame(((height . 25)))
   (let ((params (quote ((height . 25))))) (make-frame params) (modify-frame-parameters (make-frame) params))
   eval((let ((params (quote ((height . 25))))) (make-frame params) (modify-frame-parameters (make-frame) params)) nil)
   elisp--eval-last-sexp(nil)
   eval-last-sexp(nil)
   funcall-interactively(eval-last-sexp nil)
   call-interactively(eval-last-sexp nil nil)
   command-execute(eval-last-sexp)

martin

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

[Eli Zaretskii]

> Date: Mon, 12 Jan 2015 09:01:22 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 19554@debbugs.gnu.org
> 
> A simpler scenario: With emacs -Q I evaluate
> 
>   (let ((params '((height . 25))))
>    (make-frame params)  ;; f1
>    (modify-frame-parameters (make-frame) params))  ;; f2
> 
> in *scratch*.  Gets me the now familiar
> 
> 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) (height . 25)))
>    x-create-frame-with-faces(((height . 25)))
>    make-frame(((height . 25)))
>    (let ((params (quote ((height . 25))))) (make-frame params) (modify-frame-parameters (make-frame) params))
>    eval((let ((params (quote ((height . 25))))) (make-frame params) (modify-frame-parameters (make-frame) params)) nil)
>    elisp--eval-last-sexp(nil)
>    eval-last-sexp(nil)
>    funcall-interactively(eval-last-sexp nil)
>    call-interactively(eval-last-sexp nil nil)
>    command-execute(eval-last-sexp)

Doesn't happen to me here with the current master.

Could it be that you have stale *.elc files that need to be
recompiled?

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

[martin rudalics]

 > Doesn't happen to me here with the current master.

I understand that meanwhile.

 > Could it be that you have stale *.elc files that need to be
 > recompiled?

Might be, but where?  I spent an hour boostrapping yesterday after make
distclean and the oldest .elc file in my entire trunk is cconv.elc.

I also don't have the slightest idea where `xref-marker-stack-empty-p'
could get called from.

martin

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

[Dmitry Gutov]

On 01/12/2015 07:35 PM, martin rudalics wrote:

> I also don't have the slightest idea where `xref-marker-stack-empty-p'
> could get called from.

It's called from lisp/menu-bar.el:384 (find-grep call could have told 
you that, too).

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

[martin rudalics]

 >> I also don't have the slightest idea where `xref-marker-stack-empty-p'
 >> could get called from.
 >
 > It's called from lisp/menu-bar.el:384 (find-grep call could have told you that, too).

Hmmm... indeed.  No idea why I never found it.  So maybe it's a missing

;;;###autoload

before the definition of `xref-marker-stack-empty-p'?

martin

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

[Eli Zaretskii]

> Date: Mon, 12 Jan 2015 18:06:01 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 19554@debbugs.gnu.org
> 
>  >> I also don't have the slightest idea where `xref-marker-stack-empty-p'
>  >> could get called from.
>  >
>  > It's called from lisp/menu-bar.el:384 (find-grep call could have told you that, too).
> 
> Hmmm... indeed.  No idea why I never found it.  So maybe it's a missing
> 
> ;;;###autoload
> 
> before the definition of `xref-marker-stack-empty-p'?

Try

   $ make -C lisp autoloads && make

and see if that helps.

   

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

[martin rudalics]

 >> Hmmm... indeed.  No idea why I never found it.  So maybe it's a missing
 >>
 >> ;;;###autoload
 >>
 >> before the definition of `xref-marker-stack-empty-p'?
 >
 > Try
 >
 >     $ make -C lisp autoloads && make
 >
 > and see if that helps.

I added an autoload cookie now.  If someone has an idea why it would be
_not_ needed please tell me so.  Meanwhile closing this bug.

Thanks, martin

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

[martin rudalics]

 > 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.

This part fixed in commit e946a9a..cc59a3e.  Bug closed.

martin

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

[Glenn Morris]

martin rudalics wrote:

> I added an autoload cookie now.  If someone has an idea why it would be
> _not_ needed please tell me so.

I suggest instead

  :visible (and (featurep 'xref) (not (xref-marker-stack-empty-p)))

to avoid needless autoloading.

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

[Dmitry Gutov]

On 01/12/2015 11:01 AM, martin rudalics wrote:
> A simpler scenario: With emacs -Q I evaluate
>
>   (let ((params '((height . 25))))
>    (make-frame params)  ;; f1
>    (modify-frame-parameters (make-frame) params))  ;; f2

On my machine, that still doesn't raise an error. Could it be that menu 
items swallow errors with some toolkits, such as GTK3?

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

[Dmitry Gutov]

On 01/12/2015 09:14 PM, Glenn Morris wrote:

> I suggest instead
>
>    :visible (and (featurep 'xref) (not (xref-marker-stack-empty-p)))
>
> to avoid needless autoloading.

The autoload won't hurt in other uses, but this indeed looks like a 
better solution to me. Installed.

If we're going to force autoloading of xref, we could as well preload it.

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

[Stefan Monnier]

>> :visible (and (featurep 'xref) (not (xref-marker-stack-empty-p)))

It's generally better to use (and (fboundp 'xref-marker-stack-empty-p)
(not (xref-marker-stack-empty-p))).  E.g. the compiler understands it
(tho in this case, the compiler doesn't see this code anyway).


        Stefan

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

[Glenn Morris]

Stefan Monnier wrote:

>>> :visible (and (featurep 'xref) (not (xref-marker-stack-empty-p)))
>
> It's generally better to use (and (fboundp 'xref-marker-stack-empty-p)
> (not (xref-marker-stack-empty-p))).  E.g. the compiler understands it
> (tho in this case, the compiler doesn't see this code anyway).

But autoloaded-but-not-yet-loaded functions are fboundp,
so it isn't the same.

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

[Stefan Monnier]

>>>> :visible (and (featurep 'xref) (not (xref-marker-stack-empty-p)))
>> It's generally better to use (and (fboundp 'xref-marker-stack-empty-p)
>> (not (xref-marker-stack-empty-p))).  E.g. the compiler understands it
>> (tho in this case, the compiler doesn't see this code anyway).

> But autoloaded-but-not-yet-loaded functions are fboundp,
> so it isn't the same.

Duh!  Right!  Thanks for the reminder,


        Stefan